The OSGi 4.2 Enterprise Release addresses a number of Enterprise use-cases and brings a collection of Enterprise-related Java specs into OSGi. You'll find the following chapters in the Early Access Draft:
- Web Apps - turn your OSGi framework into a web container. This was already possible with components such as pax-web but now there is a standard for it. Besides being able to deploy your WARs as-is you can also make your Web Apps OSGi-aware and interact with the OSGi BundleContext from within a Servlet. Plus every web-application's Servlet Context gets registered in the OSGi Service Registry as a service, so you can interact with it from an OSGi Bundle too.
- Transactions - brings JTA to OSGi. You get hold of a Transaction Manager or User Transaction through the OSGi Service Registry. You can also register a Transaction Synchronization callback object with the Transaction Synchronization Service.
- Remote Service Admin - this specification adds an extra layer on top of the existing Remote Services spec (chapter 13 in the 4.2 Compendium). Remote Service Admin defines standard interfaces for the Distribution Provider, Discovery System and Topology Manager, making it possible to mix-n-match these from multiple implementations. The Distribution Provider registers a RemoteServiceAdmin service that exports and imports services when asked. The Discovery System API (called the EndpointListener) provides a standard view over any Discovery System, regardless of how it's realized or what protocol it uses. The Topology Manager provides a Policy over these things. It decides what services will be exported and for when to look for services in a Discovery System.
- SCA Configuration Type for Remote Services - this chapter provides a standard mechanism to configure Remote Services and provide qualities of service or intents, through SCA configuration metadata and WS-Policy. Remote Service implementations that also implement the SCA config type provide a portable way to configuration.
- Database Access (JDBC) - provides a standard way to look up JDBC Database Drivers through the OSGi Service Registry. Using JDBC in OSGi has been tricky before as it typically involved either using Class.forName() or the META-INF/services SPI model both of which are problematic in OSGi. The Database Access specification uses the OSGi Service Registry to provide you with your database drivers without having to expose any of the implementation classes to your client bundles.
- JMX - provides a JMX API into the OSGi Framework. It can be used to control the lifecycle of bundles in the framework (including install, start & stop etc...) but also provides standardized JMX access to a number of OSGi Services such as Package Admin Service, Configuration Admin Service, User Admin Service.
- JNDI - brings the JNDI and OSGi Service Registry closer together. It provides a way to look up OSGi Service through JNDI and also makes it possible to interact with JNDI through the OSGi Service Registry.
- JPA - brings a proper Database Persistence API to OSGi. It allows you to use JPA from within your OSGi Bundles. Combined with the JDBC and JTA support from the other spec chapters JPA provides a nice way to add database support to your OSGi-based applications.
The Early Access Draft doesn't contain all of the specs that you'll find in the final Enteprise Release, it only contains the ones changed since the 4.2 Core & Compendium release. For example, you will also the Remote Service and Blueprint specifications in the final Enterprise release, but they are not included in the Early Access draft.
You can download the 4.2 Enterprise Early Access draft from this location: http://www.osgi.org/download/osgi-4.2-enterprise-early-draft4.pdf
Great post David. Hope that Apache Aries project will provide such implementation.
ReplyDeleteLot of good specs for the Eclipse Gemini project! Any idea if the JMS spec will be included at some stage?
ReplyDeleteBoth Aries and Gemini are excellent places in the open source ecosystem for implementations of these specs and I expect many to appear in both projects.
ReplyDeleteWrt JMS, it is part of RFP 124 (Asynchronous Communications) which is currently being discussed in the EEG.