Peter Kriens, technical director of the OSGi alliance, gave a presentation this week at the UK OSGi Users Group sponsored by Paremus and held at SkillsMatter in London. The event was recorded, and the video is now available.
The upcoming OSGi 4.2 release (expected to be released to the public by the end of August 2009) covers a number of new features, some of which are already provisionally implemented in Equinox, the OSGi engine behind Eclipse.
The new features of the OSGi core include:
- Standard launching framework which will make launching an OSGi system easier, regardless of underlying implementation (allowing Equinox to be replaced by Felix simply by swapping them on the class path, for example)
- Service Hooks to allow OSGi bundles to intercept and filter services destined for other bundles (such as security provisioning)
- Bundle tracker to allow monitoring of bundles as they are started and stopped
- Enhanced security to allow both positive and negative permissions (allow/deny) to customise authorisation policies
- Standard Bundle-License header so that bundles can define what their licensing requirements are for administration purposes
The OSGi compendium, which covers additional services that may be present, is due out for release following the core, but will include:
- Initial provisioning which will allow provisioning information to be stored in the bundle's manifest
- Declarative services which are now supported by BND has had some of the limitations removed
- Remote services, formerly distributed OSGi (aka RFC 119) will allow OSGi services to be connected between VMs using remoting technology. Configuration external to the bundle can define how these services are wired up. Unlike RMI, these services don't have checked exceptions (though clearly, if a communication error occurs, a
RuntimeExceptionwill be thrown). This is implemented by ECF in Eclipse as well as Felix CXF. - Blueprint extender provides a configuration-driven services model (similar to declarative services) but based on the Spring patterns. Furthermore, the services can be instantiated at start-up and then bound to a proxy, which can change over time.
There was also a report of the Enterprise OSGi services, which will include an OSGi-based Transaction API (on JTA), provide JDBC and JNDI through OSGi services, as well as managing OSGi systems via JMX. The final piece of the Enterprise puzzle is the WebContainer, which allows a WAR to be installed into a running OSGi system, as used by Spring DM Server.
There are also some experimental services (which are not defined in the spec) such as the ability to create nested frameworks (whereupon an OSGi engine instantiates another OSGi engine internally for hosting a walled-off application) and TSL, a shell-like scripting language for interacting with OSGi services and supporting runtime commands. The latter will allow for a standard shell to control any OSGi engine, rather than the per-system shells at the moment. This has already been used in systems like POSH and Pax-Shell.
The approach to experimental services in OSGi is different from how experimental systems are defined in the JCP; instead of spending a long time defining a spec prior to gaining any experience on how it works, the RFCs provide provisional details which multiple implementations (Felix, Knopflerfish, Equinox etc.) are then used to get feedback on how it works. This feedback is then used to refine the spec until it is at a stable point rather than releasing something unfinished and early (c.f. the Date debacle in Java). Having the opportunity to experiment and gain feedback prior to publishing a final spec means that future changes are less likely to impact those once it goes final.
The talk concluded with some opinions of where the JSR294 outcome is headed. At the moment, there's a mix of requirements and implementation being conflated; owing to the way that JavaC handles the meta-module system, there are proposed changes to the way that visibility will work in Java (including the introduction of a new module keyword). This has prompted a recent heated debate on the implications of the meta-modules and the requires keywords. As Richard Hall, Sun employee and Felix commiter, writes:
For me, I share Peter's concerns that we are defining something with only vague meaning and it will ultimately hurt Java's vision of "write once, run anywhere". I would like it if we were defining something more concrete.
Fortunately, there is still time for the JSR 294 to be worked upon and the recent volume of comments on JSR 294 indicate a desire to come to a workable solution for all.