The OSGi Alliance has just released the OSGi 4.2 specification. Although early drafts of it have been made available, this is the final release version.
Some engines, like Equinox and Felix, have already begun working towards providing 4.2 compatibility with their earlier 3.5 and 2.0 releases (respectively). However, as OSGi 4.2 had not been released at the time, they couldn't claim to be OSGi 4.2 compliant. Now that the release has been done, it's a matter of time before the teams on each determine what still needs to be done (if anything) in order to meet the specs.
What does the release hold? InfoQ covered a sneak preview of what to expect, but now that the spec is finally here, these are the things to know:
-
Framework launching. Although it's been possible to run embedded OSGi engines from with Java applications (such as Equinox's servlet bridge), these approaches have been tied to a specific engine. Wrappers, like Pax Runner, have made it relatively easy to bootstrap any engine but by encoding engine-specific knowledge in them. Now, these will be launchable by a transparent mechanism which means it should be possible to launch an OSGi runtime without worrying which is used. This should allow an application to be tested under both Equinox and Felix simply by replacing the appropriate JAR on the bootstrap classpath.
-
Remote Services. Formerly known as Distributed OSGi and RFC 119, Remote Services is the new name for the technology that will connect OSGi VMs together. Remote Services takes the concept of a service (which is key to most dynamic OSGi applications) and provides a mechanism to export those services to remote consumers (and to be able to consume remote services locally). Unlike other approaches (such as RMI) a remote service does not need to implement a different interface or throw checked exceptions. It also doesn't try to pretend that everything will work; but given that OSGi services are dynamic, the expectation is that a service can come and go in an OSGi environment in any case.
- Blueprint Service. Those who are familiar with Spring's inversion of control and dependency injection will see immediate similarities with the Blueprint Service. This allows clients to determine what services they are wired to from an external configuration file, and have those services wired up dynamically. Like declarative services, you can specify constraints on the types of service that can be used (such as whether it is mandatory or not); but unlike Declarative Services, the Blueprint Service can provide a proxy in the absence of the service being available. When the client code tries to interact with the service, the client is blocked until a service is located. Finally, using something like the Blueprint Service allows you to avoid any container-specific code in your application, which may be useful if your system runs both inside and outside of an OSGi runtime.
-
Bundle Tracker. OSGi has long had a Service Tracker, which keeps an eye on services that come and go; the Bundle Tracker is an extension of that concept for tracking bundles. It was previously possible for a service to see bundles coming and going dynamically with a BundleListener, but the BundleTracker takes it to the same usability as the ServiceTracker does for ServiceListener. This can be used to perform the kind of dynamic registrations that the Blueprint Service or Declarative Service does in reading (and processing) metadata. For example, a web based engine might automatically scan newly installed bundles for
web.xmland auto-register servlets via the HttpService on their behalf. -
Service Hooks. In addition to determining what services are present, it's also possible to intercept events between services, and optionally, filter them. This could be used to implement a role-based permissioning model or to enable different sets of functionality based on product capability. Another approach is to provide proxying (or load balancing) by intercepting another bundle's events and hiding them, to be proxied by another mechanism (such as Distributed Services) at a later stage. In addition, listener hooks could bring these up on demand without having been first registered.
- Conditional permissions. An upgrade to the permissioning in OSGi 4.2 includes the ability to DENY access as well as to allow it. This, combined with combinations of certificate signing, can explicitly give permissions for what operations are done on a subset of bundles. This is likely to help the creation of secure OSGi platforms which can lock down the installation of unsigned bundles.
There are a number of other changes to the specification, such as OSGi bundles being given their own MIME type (application/vnd.osgi.bundle), the ability to specify a Bundle-Icon and Bundle-License, and changes to declarative services to permit a reduced set of permissions (package friendly instead of protected). The DS schema also permits other XML elements which can help in passing in service-specific information. In addition, applications managed by the application admin now have a mechanism to acquire the return value of the application when it is finished.
Equinox 3.5 already provided some of the OSGi 4.2 support, and Apache Felix had a passing test set earlier on in the month (prior to the 4.2 spec being passed). It is likely that the official results of the 4.2 spec and test kit will be clarified before the end of the month.
InfoQ asked Richard Nicholson, Founder and CEO of Paremus, makers of the Paremus Service Fabric OSGi cloud, what they thought of the new release:
"Our experience building distributed OSGi-based systems over the last few years makes us especially pleased to see the arrival of the OSGi 4.2 specification release which introduces a standard for Remote Services and the Blueprint Service."
What do you think is the most noteworthy part of OSGi 4.2?
