« Versioning and .NET's run-time | Main | The multi core processor quandry for software developmet - can and will you take advantage of it »

February 19, 2009

OSGi's service model, more than just versioning

In an earlier post I described OSGi versioning and Java's run-time and how the former is often discussed with the latter, since Java lacks run-time versioning. In this post I will describe another OSGi feature, one that although not as fresh a concept as Java versioning, is still central to OSGi: The OSGi service model.

[Entry continues to the left and below ad ]

In order to get a clearer picture as to where OSGi's service model fits in the overall scheme of your Java development process and so you can understand if its of any value to you, I will start with a common scenario of packaging and using Java classes.

Scenario: You need to use some functionality in a JAR named Shopping.jar, this particular JAR will contain classes like Checkout.class, SalesTax.class, Catalog.class, Courier.class, etc. In order to use this JAR's functionality, you will need to import each and whatever class is needed to fulfill a certain business process into another class in your application. Straightforward Java import statements, this is how its always done.

But how about instead of importing each and every required class from Shopping.jar -- and trying to figure out how they work and need to be put together -- you could instead import a service from the same JAR, one which already performed more elaborate logic than one or two classes? Well, this is OSGi's service model.

What the OSGi service model allows is for JARs to import and export services, which can be made up of classes in the JAR itself or classes available in other JARs. But why on earth would you want to make services, as well as classes available in a JAR? For the same reason coarser grained methods and classes are often desirable, just to access business logic in a more straightforward fashion.

You can of course still import classes from the same JAR in the typical import keyword statements, but the JAR will also have the ability to offer services. And there is one very important aspect about these OSGi services, especially if you've been immersed in the REST, SOAP/WSDL services world, OSGi services occur at the JAR/JVM level, so there are no servers, ports, sockets or descriptors to deal with.

Ok, so how do these services contained in JARs communicate with each other? Its up to OSGi to keep a service registry for all JARs installed on a Java run-time(JVM). Ok, so how does the OSGi registry know they exist? Once a JAR file is installed, OSGi will inspect the JAR and install whatever OSGi services it can find on it. Still, how do you get a hold of an OSGi service? Instead of an application importing individual Java classes it simply looks up an OSGi service in the registry.

If you've done web services or enterprise Java for a while this process will be 'deja-vu' for sure, with the way WSDL/SOAP/UDDI and the JNDI API register/lookup process works. While in principle the process is the same, keep in mind OSGi services are different in the sense they operate inside the same JVM footprint and at the JAR level. And given OSGi's size, OSGi's presence is almost negligible in Java's run-time compared to these two other services register/lookup mechanisms.

So there has to be an OSGi API somewhere right? Well of course, the process of registering and looking up OSGi services has to somehow communicate with the OSGi registry. This requires using OSGi's API, much like JNDI is used in Java EE applications to lookup/register things like data sources and user credentials.

So is OSGi's service model better or greater than other approaches? Its up to you, its yet another choice for exposing business logic in your Java applications, with the advantage of working inside the same JVM space, but if you add to this OSGi's run-time versioning support , you might be more compelled by OSGi in general.

On related notes. There is also work under way for distributed OSGi which makes it possible for this service model to be transparent across JVMs. And if you're not to keen on learning the OSGi API for registering and looking up OSGi services in your applications, you can also leverage the Spring Dynamic Modules for OSGi(tm) Service Platforms that allows you to use dependency injection for registering and looking up OSGi services. ( Much like the Spring framework offers dependency injection for other Java related areas).

If your interested in reading more about this OSGi service model -- including a working sample of an OSGi web application -- you can read a sample Chapter on OSGi (to the left hand side in 'Book Extras') from a book I recently finished on the Spring Dynamic Modules for OSGi™ Service Platforms.

Of course, if your looking for more in-depth OSGi coverage and are into server-side Java development, you might want to take a look at the entire book:

Update: Found this very nice post on developing a series of OSGi services based on Java, Groovy and Scala classes. It illustrates OSGi's service model perfectly, not to mention it shows of how an OSGi service's language implementation is 'hidden'. Calls and lookups are made between Java, Groovy and Scala transparently. Take a look: OSGi services with Scala, Java and Groovy

Posted by Daniel at February 19, 2009 2:46 PM