The OSGi 4.2 Enterprise Release is out!

Today the OSGi EEG reached a very important milestone. The OSGi 4.2 Enterprise Release is finished and publicly available! You can download it from here: http://www.osgi.org/Download/Release4V42

The specifications in the release address a number of important Enterprise use-cases and greatly enhance the OSGi programming model. Besides bringing a number of JEE technologies to OSGi, there are also a number of specs that nicely enhance the OSGi programming model.

Here's a high-level overview of the specs developed by the EEG in this release:

• The Blueprint specification is a standard based on Spring-DM. It provides an IOC container for OSGi and really makes developing with OSGi services very easy. Spring has many fans and the Spring-DM project has shown that integrating Spring with OSGi is a very elegant combination. The Blueprint standard helps developers by not binding their code to a single implementation. There are already a number of Blueprint implementations available.
  
  
• Remote Services and Remote Services Admin. These specifications started out under the name Distributed OSGi and bring Distributed Computing to the OSGi Service model. The Remote Services spec is for bundle developers. It describes how the OSGi Services Programming model is enhanced with a number of properties that turn your services into Remote Services. It's a very simple spec with big possibilities.
  Remote Service Admin standardizes on a high level the internal components that a typical Remote Services implementation consists of. It defines the API for the Distribution Provider (the thing that makes the remote invocation), a distributed Discovery System (that can make your OSGi framework aware of suitable remote services) and a component called a Topology Manager that provides the decision policy over what services to export and import. RSA provides users with the capability to mix and match these components from various implementations. A user might use the Distribution Provider from CXF while taking the SCA-enabled Topology Manager from Tuscany combining that with maybe a yet another implementation of Discovery that might use a UDDI server.
  
  
• Web Applications - while deploying .war files in an OSGi Framework was already possible with technologies such as PAX-Web the Webapps spec describes a standard way to do this. Besides providing some new standard Manifest headers (like one to describe what context path your webapp lives on) it also describes a standard way for the Web Application to interact with the other bundles in the OSGi Framework. The Servlet Context will contain a new attribute 'osgi-bundlecontext' that gives your Servlet access to other OSGi Bundles and Services and allows the servlet to register OSGi Services of its own. Other OSGi bundles can interact with Servlets as the Servlet Context(s) of a successfully started Web Application is registered in OSGi Service Registry.
  
  
• The JDBC specification nicely solves problems that database users previously had while using OSGi. Obtaining a database driver was typically ugly and most of the time required exporting and importing private database packages. With the new specification JDBC Database drivers simply register themselves under a standardized DataSourceFactory class in the OSGi Service Registry. It has APIs to create a DataSource (variants for Pooled and XA are also provided) or obtain the underlying java.sql.Driver object. No exposure of internal classes any more.
  
  
• JPA is a highly popular Database Persistence framework and the OSGi-JPA specification describes how to use it from within OSGi. While there is a 'traditional' mode of using JPA in OSGi which is identical to using it in JSE, the recommendation is to obtain a JPA EntityManagerFactory from the OSGi Service Registry. This provides additional lifecycle support (you can update your JPA implementation without restarting the container) and it also allows the existence of multiple JPA providers in the system. OSGi-JPA implementations normally work well with the OSGi-JDBC providers described above.
  
  
• The JNDI spec provides a bridge between JNDI and the OSGi service registry. It enables the lookup of an OSGi Service or BundleContext through JNDI. It also describes how you to obtain a JNDI Initial Context from the OSGi Service registry in case your bundle needs to do a JNDI lookup or bind.
  
  
• Like the OSGi-JDBC spec, the OSGi-JTA spec provides access to JTA APIs such as javax.transaction.UserTransaction and javax.transaction.TransactionManager through the OSGi Service Registry. If you have a JTA implementation in your framework they will simply appear there.
  
  
• Finally, the JMX specification provides JMX access to the OSGi Framework. It enables controlling the Bundle Lifecycle (like installing, uninstalling, starting, stopping a bundle) from JMX and also provides Bundle and Service information through JMX. Additionally JMX APIs are defined for a number of standard OSGi Services such as Package Admin and Configuration Admin.

Besides the new specs a number of existing OSGi specs are also included in the document. Specifications like Event Admin, Configuration Admin, Declarative Service and others are also included as they are also relevant to Enterprise use of OSGi.

Oh, and as a side node, I don't expect Enterprise OSGi Frameworks to deploy all of these specs at the same time. Take only what you need, keep your framework nice and lean :)

Implementations for all of the above are available. Good places to look for them are the Apache Aries and Eclipse Gemini projects. And, of course, Apache CXF provides Remote Services and Remote Services Admin implementations in the CXF Distributed OSGi project.