Appendix B. The OSGi ecosystem

This appendix explains where OSGi came from, who owns it, and where it’s going. It also gives an overview of the various OSGi specifications and how they relate to each other.

B.1. The OSGi Alliance

OSGi as a technology is owned by the OSGi Alliance, a nonprofit industry consortium funded by a large number of member companies. The OSGi Alliance is responsible for developing and releasing OSGi standards, as well as maintaining Compliance Test suites for the standards that they create. Importantly, the OSGi Alliance also ensures that reference implementations for the various standards are available under reasonably business-friendly software licenses, but typically it doesn’t maintain them. The ongoing maintenance and development of OSGi specification implementations typically resides with the open source project or company that created them. Most OSGi standards have more than one implementation available.

The OSGi Alliance is organized into a number of different Expert Groups. An Expert Group consists of a number of OSGi experts from various OSGi Alliance member companies who are interested in particular applications of OSGi. These experts meet regularly to discuss bugs, new requirements, potential new specifications, and specification drafts. Of the several Expert Groups within the alliance, two are particularly relevant to enterprise OSGi developers. These are the Core Platform Expert Group (CPEG) and the Enterprise Expert Group (EEG).

The Core Platform Expert Group

CPEG’s purview is, unsurprisingly, the core OSGi platform. CPEG’s role is to guide the growth of the OSGi framework, and it also provides a small level of oversight to the other Expert Groups. CPEG introduces comparatively few standards into the core, primarily because only broad use cases need support within the Core Specification, but also because there’s a significant effort made to keep the core platform small. Keeping the core platform small is important to OSGi because the core platform must be shared by all OSGi users, whether they’re running an embedded system inside a car radio or on an enterprise production server with hundreds of gigabytes of memory.

The Enterprise Expert Group

The EEG is a comparatively new member of the OSGi Alliance, having only been set up in 2008, but as with most new standardization efforts, a lot happened quickly. Many of the technologies used in the examples in this book are OSGi Enterprise Specification standards, or are heavily based on them. EEG’s focus is, as you would expect, enterprise-level technology. This means that EEG specifications typically focus on technologies that will be useful on hardware scales running from laptops to mainframes. Primary requirements for EEG specifications are typically qualities of service, data access, and remote communication. The Enterprise Expert Group also works toward making OSGi a more suitable container for large-scale applications.

B.2. OSGi specifications

Although we tend to talk about OSGi, there are several different OSGi specifications. Each one defines a range of services and technologies, although some chapters are duplicated across the various noncore specifications.

We’ve been discussing core OSGi, but OSGi is a big platform. In addition to the Core Specification, there are a number of other specifications, each defining a range of extra services and technologies. It’s important to know about the various OSGi specifications to understand why there are lots of OSGi-related open source projects, each of which seems to provide a different set of features.

There are four OSGi specifications—the Core Specification, the Services Compendium, the Enterprise Specification, and the Mobile Specification. The relationship between the specifications is illustrated in figure B.1. The Compendium, Enterprise, and Mobile Specifications all build on the Core Specification. These three specifications also have a lot of overlap in terms of their content.

Figure B.1. The OSGI service platform includes a number of specifications. The Core Specification is the foundation on which the other specifications are built. The Compendium Specification defines a range of extra services. The Enterprise and Mobile Specifications are subsets of the standards defined in the Compendium Specification. Some elements of the Enterprise Specification were defined after the most recent version of the Compendium Specification and will be rolled back into the next version.

B.2.1. The Core Specification

The Core Specification is the oldest and most important part of OSGi. The Core Specification defines the APIs for interacting with the framework, the structure of an OSGi bundle, and its manifest metadata. The module layer, lifecycle layer, service layer, and security layer are all defined by the OSGi core. Without these rules it would be impossible to build anything at all.

The Core Specification also defines a handful of value-added services. For example, there’s a service that allows bundles to be started conditionally based on a start level, and a service that allows bundle wirings to be reflectively explored.

Because it’s so fundamental, implementing the Core Specification is required for something to call itself an OSGi framework. It doesn’t matter if you’re running on a tiny embedded processor in a car entertainment system or on a gigantic supercomputer with terabytes of memory—if it’s in there you have to do it to be compliant. As a result this means the Core Specification tends to change more slowly than some of the other specifications, and most importantly it has to stay small. New features are only added when it isn’t possible to implement them any other way.

In this book, when we say that the framework does something, what we mean is “the OSGi Core Specification requires the framework to do xxx.” This is likely to be the only interaction your application has with the Core Specification. Although in many senses the Core Specification is the most important of all the OSGi specifications, it isn’t the main focus of this book. What we think is exciting is what you can do with the tools built on top of the Core Specification in the other specifications!

B.2.2. The Compendium Specification

The OSGi programming model is extremely service-oriented. Apart from the core framework, almost every OSGi feature is defined as a service. The Core Specification includes some particularly essential services, but there are many more services that would be useful. A large number of these are defined in the OSGi Service Compendium. The Compendium is an enormous document; at 732 pages, it’s almost three times the size of the Core Specification. It includes services for almost everything, from preferences, to remote services, to configuration admin, to HTTP communication, to universal plug-and-play devices. It also includes some extensions to the OSGi programming model. For example, it includes a standard for Declarative Services, and an API for tracking services.

Unlike the Core Specification, which lays out a cohesive platform, the Compendium Specification is much more of an amalgamation of bits and pieces. It would be strange for an implementer to implement only part of the Core Specification, and there’s a Technology Compatibility Kit (TCK) that verifies implementations comply with the entire Core Specification. Most implementations of the Core Specification (such as Equinox and Felix) also provide a JAR that includes Compendium interfaces. But not all of these interfaces have backing implementations. For example, the Log Service and HTTP Service are implemented by Felix and Equinox, and the Wire Admin Service is implemented by Equinox only. This can make understanding what’s in the compendium and where to get implementations tricky.

We don’t refer to the compendium too often in this book because it isn’t within the scope of what we’re discussing. This isn’t to say that the compendium services aren’t useful, but describing them is best left to books on core OSGi. Most of the things in the Compendium Specification that are useful to the enterprise are also reproduced in the Enterprise Specification.

B.2.3. The Enterprise Specification

Because it’s so broad, the OSGi compendium doesn’t stand on its own as a programming model. The Enterprise Specification was introduced to provide a much more coherent programming model for an enterprise audience. The Enterprise Specification is sometimes referred to as a profile, because it selects a subset of specifications. It also adds some new service definitions that aren’t in the compendium to provide interoperability between Java EE standards and core OSGi.

Because the Enterprise Specification has a tighter focus than the compendium, it’s much more natural for implementers to provide the whole of the specification. For example, Apache Aries and Eclipse Gemini are both specifically designed as enterprise OSGi implementations, and both implement almost the whole specification. But several of the other servers we described in chapter 13 only implement selected chapters of the Enterprise Specification.

Whereas the OSGi Enterprise Specification is based around enterprise grade services, the OSGi compendium focuses on tools, features, and containers that are useful for OSGi client runtimes. This does lead to some functional overlap between different services in the two specifications, such as the Http Service and Web Applications, or Declarative Services and Blueprint. The key point to remember is that the compendium is generally most useful for small-scale work, and the enterprise for large scale work. For example, the Http Service allows you to register servlets individually, but web applications can deploy hundreds or thousands of servlets at a time using metadata.

The main purpose of the Enterprise Specification is to provide application developers with access to enterprise services, the majority of which are already available in Java EE. One of the guiding rules of the OSGi Enterprise Specification is that where a enterprise service is already available in Java EE, the OSGi version of that service should be as similar as possible. This means that it should use the same API, have the same semantics, and be accessible in a similar way. This isn’t always possible, but for the most part it is. In addition to maintaining the existing behavior of Java EE services, the Enterprise Specifications also try to make any enterprise service as OSGi-friendly as possible. One of the more common (and unsurprising) results of this is that OSGi-enabled enterprise services are usually available in the OSGi Service Registry, which allows them to be dynamically swapped at runtime.

Table B.1 and figure B.2 list the contents of the Enterprise Specification, and show the extent of the overlap with the Core and Compendium Specifications. At the time of writing, version 4.3 of the Core Specification, and versions 4.2 of the Compendium and Enterprise Specification were released. We expect version 4.3 of the Compendium Specification will also include all the new specifications introduced in version 4.2 of the Enterprise Specification. The focus of this book is these new specifications, rather than the entire contents of the Enterprise Specification.

Table B.1. The contents of the OSGi Enterprise Specification. Many of the capabilities of the Enterprise Specification are also included in the Compendium and Core Specifications. The first version of the Compendium Specification was version 4.0, and the first version of the Enterprise Specification was version 4.2.

Capability	Core Specification	Compendium Specification	Enterprise Specification	Chapter
Trackers	v2 and up	v4.1 and up	v4.2 and up	See Osgi in Action
Remote services	v4.3 and up	v4.2 and up	v4.2 and up	10
Remote service admin			v4.2 and up	10
Declarative Services		v4.2 and up	v4.2 and up	6
Blueprint container		v4.2 and up	v4.2 and up	2 and 6
HTTP service	v2 and up	v4.0 and up	v4.2 and up	See Osgi in Action
Web applications			v4.2 and up	2
JNDI service			v4.2 and up	2
JDBC service			v4.2 and up	3
JPA service			v4.2 and up	3
JTA transaction services			v4.2 and up	3
JMX management model			v4.2 and up	See OSGi in Depth
Log service	v2 and up	v4.0 and up	v4.2 and up	See Osgi in Action
Configuration admin	v2 and up	v4.0 and up	v4.2 and up	See OSGi in Depth
Metatype service	v2 and up	v4.0 and up	v4.2 and up	See Osgi in Action
User admin service	v3 and up	v4.0 and up	v4.2 and up
Initial provisioning	v3 and up	v4.0 and up	v4.2 and up
Event admin		v4.0 and up	v4.2 and up	See OSGi in Depth
SCA configuration type			v4.2 and up	10 and 11
XML parser service	v3 and up	v4.0 and up	v4.2 and up

Figure B.2. How the OSGi Enterprise Specification overlaps with the Compendium and Core Specifications. Version 4.3 of the Compendium Specification should be a superset of version 4.2 of the Enterprise Specification.

B.2.4. Other specifications

OSGi includes two other specifications, the Mobile Specification and the Residential Specification. Like the Enterprise Specification, the Mobile Specification is a convenient packaging of bits from the Compendium that are useful for mobile computing, along with some entirely new service definitions. The Mobile Specification on its own isn’t useful for enterprise computing, and we don’t cover it in this book. New in OSGi 4.3 is the Residential Specification, which is designed for devices like home stereo systems, thermostats, and washing machines.

B.3. OSGi—future frontiers

Where next for OSGi? After it makes its mark in the embedded world, the mobile world, and the enterprise, are there any industries left to conquer? Occasionally, discussions about using OSGi as a gaming platform can be heard, but it’s not clear yet that the problems of the gaming industry line up so well with the solutions offered by OSGi. The bigger challenge for OSGi in the future might be its relationship to core Java.

B.3.1. OSGi and Jigsaw

OSGi has had a long relationship with the Java SE specification, but the relationship is slightly uneasy. The first flirtation with incorporating OSGi into Java SE goes all the way back to 1999, with JSR-8. This JSR was withdrawn and never made it into the Java specification. OSGi continued to gain popularity as an independent add-on to Java until the subject of Java modularity was re-introduced with JSR-277, “Java Module System.” JSR-277 was followed by two more JSRs, JSR-291, “Dynamic Component Support for Java SE,” and JSR-291, “Improved Modularity Support in the Java Programming Language.” JSR-291 is based on the OSGi specification, and provides modularity as a layer that sits on top of core Java. JSR-277 and JSR-294, together known as Jigsaw, integrate modularity support into the architecture Java SE platform. The design of JSR-294 and JSR-277, and which release the implementation should be targeted for, has been subject to regular revision. After slipping from Java 7 to Java 8, it’s currently slated for delivery with Java 9. The extent to which these new specifications should borrow ideas from OSGi or interoperate with OSGi is controversial. It does seem that neither Java 7’s nor Java 8’s baked-in modularity will be sufficient to satisfy the requirements currently satisfied by OSGi, and that OSGi won’t be made obsolete by Jigsaw in the near future.