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 org.apache.cxf.rs configuration type.

For more information see: http://cxf.apache.org/distributed-osgi.html

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 http://www.osgi.org/download/osgi-4.2-enterprise-early-draft4.pdf

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: http://www.osgi.org/download/osgi-4.2-enterprise-early-draft4.pdf

Submit your OSGi talks!

Two OSGi Conferences are currently accepting presentation submissions, so if you have something interesting, cool or noteworthy to say about OSGi, make sure to submit your stuff!

They are:
  OSGi DevCon London (Feb 23, 2010): http://www.osgi.org/DevConLondon2010
and
  OSGi DevCon at EclipseCon 2010 (March 22-25, 2010): http://www.eclipsecon.org/2010/

So come out and show us all what you are using OSGi for!

Felix now fully supports OSGi Fragments

A long awaited feature has finally been completed in Felix: Fragments!
I'm really happy to hear this because in the past it has been a pretty big gap in the support provided by Felix.

Here's the message from Richard Hall: http://www.nabble.com/Re%3A-Status-of-Fragments-in-Felix--p25663384.html

Aries: an Apache project for Enterprise OSGi

Some of you may have noticed the Aries incubator project at Apache: http://incubator.apache.org/aries.

Aries is about building a community specifically around enterprise OSGi components and an enterprise OSGi application programming model. It provides a home for bundles and larger chunks of enterprise OSGi technology independent of the OSGi container, so anything found in Aries should work in a compliant OSGi runtime such as Felix or Equinox.

Part of the proposal focuses on the development of an OSGi Application model for assembling multiple bundles into a larger parts which you can think of as an application.

An application model is one of the things that the OSGi Enterprise Expert Group (EEG) is currently defining and working ahead on an implementation will help making this standard better as experience is always better gained by doing.

Initially the project will provide an implementation of the OSGi 4.2 Blueprint specification (RFC 124), an implementation of JPA support for OSGi and JNDI integration for OSGi.

Like with any Apache project, anyone interested in joining the fun is more than welcome to contribute! Many individuals and people working for a large variety of companies have already joined during the proposal stage and I would expect even more people to join once the project is under way.

Exciting stuff!

OSGi 4.2 Core and Compendium Specs Available

The new OSGi 4.2 Core and Compendium Specifications are now publicly available.

The big new items are:
Remote Services - The Remote Services Specification (Chapter 13 in the Compendium Spec) defines how you can use the OSGi Services Programming model to distribute your services across machines. It brings Distributed Computing to OSGi in a very natural way. The Reference Implementation is provided by Apache CXF.

Blueprint Container - This standardizes the Spring Dynamic Modules development model and allows you to expose simple POJO's as OSGi Services. Additionally, OSGi Service References can be injected into your own POJO through simple setter calls. In a way it is similar to OSGi Declarative Services (and other OSGi Component Frameworks), the difference is that this one works very similar to the way Spring works. The good thing is that all OSGi Component Frameworks works seamlessly with each other. E.g. a Service created with DS can be consumed by Blueprint without any problems, and vice versa. The Blueprint Reference Implementation is worked on at the Spring-DM project.

Service Registry Hooks - This enhancement to the OSGi Core was initially triggered by the Remote Services (Distributed OSGi) work as it needs to know what Services active Bundles are looking for. This information allows the Remote Service implementation to look specifically for the requested service in any of its registries to see if there is a remote one available. Later it turned out that there are many more applications of Service Registry Hooks. They allow you to figure out what services are being looked for, but they also add the possibility to hide certain services for certain bundles making it a building block for Service Proxification. The Hooks (Chapter 12 in the Core Spec) are implemented by both Equinox 3.5 and Felix 1.8.0.

Additionally, many small updates have been made to other specs. You can find the specifications here: http://www.osgi.org/Specifications/HomePage

Meanwhile, the Enterprise Expert Group is working at full speed on the OSGi 4.2 Enterprise Release which contains many additional new Enterprise related specifications.

Co-chairing the Enterprise Expert Group

Last week the OSGi Enterprise Expert group has elected me as their new co-chair after Eric Newcomer is moving on to greener pastures elsewhere. I have to say that I'm thankful for the confidence that the EEG has in me and would like to thank everyone for their support. Obviously I will be taking on the role together with my esteemed co-chair Tim Diekmann, who has been in this role since the EEG started.

Here's a little bit about me. I work for Progress Software in Dublin, Ireland and worked for IONA technologies for about 10 years before they were acquired by Progress. During my time I've worked on a number of products which include Orbix the IONA Corba product, a J2EE Appserver, Mobile Middleware and a Repository product. I've also been involved with the Apache and Eclipse open source projects where I am a committer on CXF and on the STP Policy component respectively. Before I joined IONA, I worked in the Netherlands for a Cap Gemini subsidiary called Bolesian. I've been active in the OSGi EEG since it started in January 2007, and have been one of the drivers behind Distributed OSGi, now called 'Remote Services' which is released in OSGi 4.2.

Looking forward, things will be busy. Within the EEG everybody is working really hard on the 'OSGi 4.2 Enterprise' release, which we're planning to get out at around the end of this year. We're hoping to get a bunch of JavaEE mappings in, things like Webapps, JPA, JTA, JMX, JDBC, JNDI. Being an army of volunteers, its hard to guarantee that they will all make it, but at least I know everyone is doing their very best to get there.

Last but not least, I would like to thank Eric Newcomer, which whom I have worked for many years for the excellent work he has done in OSGi and wishing him the very best for his new job that he is starting soon.