What's new in OSGi 4.2?

Question

OSGi 4.2 has just been released which updates the 4.1 specification with a few new RFCs. So, what's particularly new with OSGi 4.2, which frameworks support 4.2 already (or are close to) and why should you target new developments against a 4.2 framework instead of a 4.1?

Answer 1

In most cases, a point release of OSGi (such as 4.1->4.2) doesn't really change much existing behaviour, so it's safe to say that if you have an app that depends on 4.1, it'll run on 4.2 without problem. What is new is that a few items have been standardised which should enable for better interoperability between different OSGi engines (like Equinox, Felix and Knopflerfish).

In fact, although OSGi 4.2 was only released officially on 16th September 2009, early drafts have been available for others to refer to, so previous releases of the products (like Equinox 3.5, Felix 1.8) already have a reasonable support for the standard. Like 802.11n products, they conformed to earlier drafts but the expectation is that they'll be certified as fully compliant against the 4.2 release in the not too distant future.

So, what's new in 4.2?

• Service Hooks
• Framework Launching

And, in the compendium

• Remote Services
• Bundle Tracker
• Blueprint Service

Service Hooks

The Service Hook API allows you to pick up on events that occur at the service layer. For example, you can hook into when a service is requested, when a service has an event delivered, and so on. You can also cause events to be not delivered (for example, hiding events that you're not authorised to see) but can't change any events (as this would complicate the classes being delivered). Service hooks are part of the core specification, so all OSGi releases will need this to be compliant.

Framework launching

Although it's possible to programmatically start an OSGi instance from an existing Java application, the way in which you do this has been dependent on which OSGi runtime you're using. In particular, configuration items (such as where to store transient data, what the bundle boot delegation policy should be and so on) were all defined in an engine-specific manner. This consolidates the properties that get set on the framework by any launching utility.

Remote Services

The Remote Services API allows OGSi services to communicate between VMs (possibly on different machines). The exact mechanism of how they communicate (RMI, WebServices etc.) is open to providers, so it's unlike other distributed technologies (like Corba) which specifically dictate an on the wire format. Clearly, distributed services have different semantics than local ones (communication errors, serialisation issues) and it is left to the individual services to be distributable if needed.

Bundle Tracker

Like the ServiceTracker before it in 4.1, the BundleTracker can be used to keep an eye on which bundles come and go in the system. This can be used by dynamic GUIs to show the evolving state of the OSGi engine without any platform specific knowledge.

Blueprint Service

The blueprint service is similar to Spring as it provides a dependency injection mechanism for configuring bundles. In some regards, it is similar to declarative services; but the blueprint service does things in a different manner. In addition, unlike declarative services (which can only deal with services which are present), the blueprint service can create a proxy placeholder in advance for a service which will come on-line later. Calls to the service proxy will then block until the service can be filled (rather than returning 'null' as declarative services will do). If you are comfortable or familiar with Spring IOC and similar dependency injection, then the Blueprint service will be immediately understandable.