Monday, December 7, 2009

CXF-DOSGi 1.1 Implements the OSGi Remote Services spec

Last week the Apache CXF implementation of the OSGi Remote Service specification, CXF-DOSGi version 1.1 was released.

The CXF-DOSGi code base has already been supporting the OSGi Remote Service spec (chapter 13 in the OSGi 4.2 Compendium Specification) for some time. Now it's in a released version as well.

Major new features since CXF-DOSGi 1.0:
  • Reference Implementation of the OSGi Remote Service spec.
  • A live Discovery System is now supported. CXF-DOSGi makes use of Apache Zookeeper as the Discovery Server and provides client-side bundles for transparent interaction with Zookeeper.
  • Besides SOAP/HTTP support, it now also provides REST support for JAX-RS-based Remoted Services and Consumers through the configuration type.
For more information see:

In the mean time we're working on refactoring the code to also be compliant with the upcoming Remote Service Admin specification. The RSA spec defines standard interfaces between the Distribution Provider, Topology Manager and Discovery System in a Remote Service implementation. This means you can mix-n-match these from multiple implementations. So for example, you could take the CXF Distribution Provider to give you a Web-Services based remote service and combine that with something like a UDDI-based Discovery system from another project. Then you might want to provide your own Topology Manager since this is the entity that makes the decisions about what gets exported and what gets imported. The RSA spec makes all this possible. Read more about it in chapter 122 of

Tuesday, December 1, 2009

OSGi 4.2 Enterprise Release Early Access Draft 4

In the OSGi Enterprise Expert Group we're working hard to get the Enterprise Release ready some time in Q1 2010. But if you can't wait, we've just released an Early Access Draft of the new specs. As it says, these aren't finished specs yet. Some details are still bound to change, you will see open questions in certain sections and the formatting of the documents is certainly not final yet, but the overall direction of these specs is most likely not going to change.

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: