Friday, 17 October 2008

OSGi Primer

I find myself explaining OSGi from time to time, so decided to try and write a very brief primer to describe the essentials of OSGi which I can simply link to in the future. This short entry is aimed at people who no nothing or very little about OSGi and should be just enough to make the penny drop.

Here goes!

Firstly, I'm going presume that the reader is familiar with Eclipse IDE. If so, then the reader has already been using OSGi and probably doesn't even realise it.

The Eclipse IDE is constructed from Plugins. Plugins are effectively OSGi bundles with a bit extra (usually a plugin.xml, sometimes a little more).

Eclipse is built on top of Equinox which is an implementation of the OSGi specification and then goes on to extend it with the Plugin Registry.

At its core an OSGi bundle is a standard Java JAR file with some extra information in the MANIFEST.MF which describes the bundle to the OSGi platform it is deployed to. The manifest describes things like the bundle's name, version, what packages and/or other bundles it depends on, what packages it exposes, and probably a fair chunk of other stuff I haven't mentioned.

OSGi is a service oriented architecture. This is quite an important point to me as most people hear or read SOA and automatically assume Web Services. Well Web Services are just one type of SOA. The specification of OSGi is inherently, and by design, service oriented.

Like I said, bundles can declare what packages they expose, but more importantly they declare and/or register services.

A service is essentially a Java interface and can be implemented by one or more bundles. A bundle that needs to use a particular service looks it up (or "tracks" when services are registered/unregistered) and then decides which service to use either by taking the first one it finds, or by homing in on a service that meets a specific need by specifying some service properties.

The most important thing is that services are dynamic. They can come and go and this is a part of the specification and something that any one who writes bundles has to accept and deal with.

As a result, OSGi has a tightly defined classloader mechanism which manages version control. You can have two bundles installed on your OSGi platform that expose the different versions of the same package, then other bundles can be explicit about which package version they depend on or not.

The OSGi specification consists of a core specification and a service compendium. The core specification is enough to write modular Java applications and the service compendium details a selection of services that OSGi implementations will usually implement a common set of, if not all of. These include things like Logging, Declarative Services (services can be declared using XML), HTTP service (you can expose web resources from a compliant container, some even support JSPs!) and others. See this page for more information:
http://www.osgi.org/Specifications/HomePage

Finally, what I haven't mentioned is that OSGi has been around for nearly a decade. It was originally intended for use as a dynamic platform for embedded devices but IMHO is really starting to make its mark through use on the desktop and (enterprise) server areas, especially in the last couple of years.

When you get in to it, the power of OSGi is mind boggling. Yet OSGi is simple and logical, while remaining comprehensive. OSGi is the modularity that Java is missing.

I hope my brief description of OSGi does it justice. I deliberately wanted to keep it short and sweet and whet some appetites.

3 comments:

Daniel Jomphe said...

This is probably the best and shortest explanation of OSGi I ever read, highlighting very well how OSGi relates to concepts like SOA, WS*, Eclipse, etc.

Thank you Chris.

Andy Latham said...

Like it mate, I'll forward on to the peeps here at Talis as I'm hoping to introduce OSGi to our SOA layer - I;ve been a big fan for a couple of years.

I presume you've seen that the clever dudes over at SpringSource are using OSGi & Spring to create a new app server which is non JEE compliant? I'm keeping an eye on that one with interest....

Chris Brind said...

Thanks Andy.

Yes, I've seen the Spring thing, but I've never been a fan or seen the value of Spring, when most things it lets you do you can do with common sense architecture and without the bloat. Anyway, I know there's a ton of different Spring projects these days and it all just looks like bloatware to me. I've looked at various things from time to time and just ended up thinking, what's the point, they're not really giving Java developers anything they don't already have.

And recently, they seem to have gone from XML to annotations - two technologies that are just as bad as each other.

The app server would be of more interest if wasn't GPL ... because of that, there's no point even looking at it since I can kick off an OSGi container within any J2EE server I might as well use Websphere if I wanted to pay for a server. I know there's more to it than that, but from what I've read, you have to look at OSGi from a different angle to get the benefits - you end with Spring littered through out your code and I'm too much of a purist for that.