Enterprise Integration Zone is brought to you in partnership with:

Mitch Pronschinske is the Lead Research Analyst at DZone. Researching and compiling content for DZone's research guides is his primary job. He likes to make his own ringtones, watches cartoons/anime, enjoys card and board games, and plays the accordion. Mitch is a DZone Zone Leader and has posted 2577 posts at DZone. You can read more from them at their website. View Full User Profile

Turning Ordinary OSGi Services Into Remote OSGi Services

12.23.2009
| 15484 views |
  • submit to reddit
The Distributed OSGi (DOSGi) subproject of the Apache CXF project recently released the 1.1 of its reference implementation for the Distributed OSGi specification.  DZone spoke with David Bosschaert and Eoghan Glynn, who are both members of the OSGi Enterprise Expert Group (EEG) and committers on the Apache CXF project, about the history of the DOSGi project and how it harnesses CXF and the OSGi Remote Services spec to turn basic OSGi services into remote OSGi services.

First, Eoghan Glynn gave DZone an overview of Apache CXF, which is a framework for people to write web services using a variety of different models.  CXF arose from the merging of Objectweb Celtix and Codehaus XFire.  The project uses front-end APIs such as JAX-WS and JAX-RS, which is similar to Jersey.  The services use RESTful HTTP, SOAP, XML/HTTP, or CORBA.  CXF also provides pluggable data bindings for mapping Java objects to XML and pluggable transports. Glynn said pluggability at every level of the stack is a big feature for CXF.  CXF applications also have a wide range of deployability options.  Applications can be deployed to a bare JVM, numerous application servers, or it can be deployed as an OSGi bundle.  This deployment is growing in popularity, Glynn said.  

The DOSGi subproject fits into CXF as it leverages the CXF technology to realize the OSGi Remote Services specification.  David Bosschaert said when the OSGi EEG first formed, companies wanted to add distributed computing to OSGi.  This led to the creation of a requirements document, which the EEG calls an RFP, and a technical design document, called an RFC.  RFC 119 became the spec for Distributed OSGi.  Before this specification, Bosschaert said, OSGi services couldn't go to other machines for their execution.  Bosschaert says the OSGi services model was well suited for distributed computing.  

RFC 119 resulted in an OSGi specification called Remote Services, which was released in the 4.2 OSGi spec last summer.  Bosschaert said, "Once the RFC (119) was well underway, we wanted to create a reference implementation of that.  We thought CXF was a really good technology to realize distributed services.  So that's where we started the DOSGi subproject."  Bosschaert describes the subproject as a thin wrapper around CXF that makes it compatible with the OSGi Remote Services spec.

Bosschaert explained how OSGi service and DOSGi services are useful.  "With OSGi services you register POJOs in the OSGi service registry and make them available to service consumers," said Bosschaert.  "The services are just any old Java object.  They don't have to implement a particular interface or adhere to any special signature.  They're just Java objects that are registered in a service registry, and OSGi consumers can use those services by looking them up in the OSGi service registry."  The look up can be done in various ways, Bosschaert says.  You can even look up transaction services by price to find the cheapest one.  

Bosschaert says for Distributed OSGi you have to look at your service's API and make sure it's suitable for distributed computing, otherwise you might get a chatty connection.  "Once you have a POJO with a suitable interface for distribution, you can register that just like any other POJO as an OSGi service, but Remote Services gives you a few extra properties that you can put on that POJO to make it available remotely."  Using this method to add a few properties, Bosschaert says you can turn an ordinary OSGi service into a remote OSGi service.  "Similarly, when you consume an OSGi service, depending on your setup, you can consume a remote service without doing anything special.  You just register the Remote Services discovery implementation and if you have that registered in your system, you can actually consume remote OSGi services as if they were local OSGi services."  However, Bosschaert says in some cases you may have to add some extra configuration to tell the system that a remote service is there.  "The nice thing is that you stay within the OSGi services model for your remote computing," said Bosschaert.  This functionality is now available in version 1.1 of Apache CXF-DOSGi.

Recently, the DOSGi subproject reached version 1.1.  Bosschaert says, "In version 1.1, we are basically are complying with the [Remote Services] spec.  We actually did a version 1.0 that we thought was going to be compliant, but then some details in the spec changed fairly late in the process, so we had to do a 1.1 to be compliant with the Remote Services spec of OSGi," said Bosschaert.

Currently the CXF-DOSGi team is working on enhancing the DOSGi specification to be compliant with another specification called Remote Services Admin, due out in Q1 2010.  This spec resulted from a split in the RFC 119 spec.  Bosschaert said that a deeper integration of distribution providers is described in Remote Services Admin.  He says the next version of the DOSGi RI will be released when the project is compliant with the Remote Services Admin spec.

For a simple example of Distributed OSGi, go to David Bosschaert's blog.