Java Modularity with OSGi (1)

I am excited: the notion of modularity is once again taking center stage in Java land.

All technology platforms (OS’s, languages, applications, etc) eventually face the struggle of providing an adequate level of abstraction to encapsulate modular code unit. On the MS Windows platform, for instance, there is myriad of technologies including VCL, VBX, OCX, ActiveX, COM, DLL, etc, that emerged over the years designed to provide modular, sharable, and distributable code units for specific domains.

On the Java platform, the story is similar. From the beginning, the JAR file format provided the means to physically package Java code and resources as modules. The file format has served its original purpose well giving the means to distribute and reuse the large number of Java API’s that is available today. However, while the JAR file format works great for physical modularity, it falls short, however, of supporting a logical component model. (NOTE: vendors have developed their own component models to address their specific needs, for instance SpringSource’s Spring Framework, JBoss SAR, Geronimo GBean, JMX MBeans, EJB’s, etc).

OSGi
You have probably heard about OSGi and wonder how it fits in the Java landscape. In short, OSGi extends JAR’s physical modularity into a logical component model (known as bundle). In OSGi, the bundle can be a living entity that provides services, not a mere container for code API. As such, OSGi affords system developers the following capabilities:

• A Framework: This is an execution environment for bundles at run-time. Bundles are loaded, executed, and managed (see OSGi Frameworks below).
• Service Registry: OSGi provides a container where bundles are deployed and can expose services to other registered bundles.
• Life-cycle Services and Events: Allows addition, removal, and update of bundles dynamically at run-time. The framework publish lifecycle events as notifications that can be captured for appropriate reactions.
• Service Model: Ability to expose and discover service interfaces at run-time.
• Bundle Isolation: OSGi adheres to strict isolation rules. Each bundle gets its own class loader. Visibility of a bundle is specified at the package level, not class. A Bundles can export its internal packages or indicate its dependency on existing packages hosted by other bundles running in the framework.
• Version Dependency: Expressive and flexible bundle versioning semantics with automatic dependency resolution.
• Multi-version Coexistence: Multiple versions of same bundle can co-exists without any shadowing effect. Client A can have a dependency on bundle X.1 while client B has a dependency on a different version of bundle X.2 with no risks of class path collisions (commonly known as Jar Hell).
• Dynamic Availability: part of OSGi’s component model is the notion of bundle dynamic availability. A bundle is not guaranteed to be available. This is good because you can remove/reload/restart a bundle at runt time (without restarting the framework). This is not so good because your bundle has to have mechanism to handle dynamic availability of bundles it depends on.

The OSGi Bundle
Because OSGi was designed (from the ground up) to be a component-based platform, an OSGi application is a collection of interacting bundles running within the framework. As stated earlier, an OSGi bundle is based on the traditional JAR file. However, OSGi uses special meta-data in the META-INF/MANIFEST.MF file of the bundle to specify configuration information used by the OSGi framework at runtime. Below is an example of a MANIFES.MF file for a bundle

Some important items to notice in the manifest meta data:

• Bundle-Activator: specifies a class that will react to bundle life-cycle events (when the bundle starts and when the bundle stops). You can use this event as a starting point for functionalities implemented by your bundle (sort of a main() for your OSGi application).
• Bundle-ClassPath: establishes a classpath for your bundle’s internal library of classes (and jar files).
• Import-Package: this entry specifies the name of a package that the bundle depends on (and expected to be available on the platform). Notice the version directive specified in the Import-Package declaration. It uses an interval notation to express dependency on versions 1.0.0 <= X < 2.0.0
• Export-Package: declares a package in the bundle that should be made available at runtime. When the bundle is installed in a framework, package will be visible to other installed packages running.

OSGi Frameworks
You may be wondering where/how do I run an OSGi bundle? You will need a framework. A framework is an implementation of the OSGi service platform specifications that has the ability to execute bundles. The framework itself is a small core with system level logic to load bundles. All of the framework’s functionalities come from installed bundles on the framework. There are several framework implementations available today, the three most popular (and open source) are:

• Apache Felix – A small embeddable, developer friendly port of OSGi service platform. It’s the basis for many popular projects including Glassfish and JOnAS App Servers.
• Eclipse Equinox – This is the base for Eclipse IDE (which a collection of bundles known as plugins in Eclipse parlance). It’s used in many popular products such as SpringSource DM Server and IBM’s WebSphere.
• Knopflerfish – Knopflerfish is one of the earliest implementations from the commercial side (gone open source) with presence in automotive, telecom, and home automation.

Why Should I Care?
You will certainly wonder how OSGi impacts you. Well, if you spend most of your day writing enterprise applications, then OSGi will mean little to you. As a matter of fact, vendors are working hard to keep developers away from OSGi-specific concerns. You will continue to use enterprise semantics that you are already familiar with and produce enterprise artifacts (EJB, WAR, EAR, etc) that you produce today. Life is good, keep coding!

However, if you are system level developer or simply interested in component-based development, OSGi may be of great value. Already, many vendors are decomposing their products into OSGi-ready jars to allow developers easy deployment on OSGi runtimes. There’s also a movement of porting commonly used API’s to OSGi by creating a bundle repository (i.e. Felix Commons and Equinox Orbit).

Another approach to OSGi integartion is to embed an OSGi framwork into your own development to create a component model. Eclipse has become the posterchild for this approach using OSGi to provide a plugin architecture for the IDE. Felix, however, has become the favorite embeddable OSGi framework because of its relative small size, easy licensing, and easy API. One great example of embedded Felix is the SIP-Communicator desktop application which uses OSGi-bundles as plugins to extend the application (I am sure there are others).

Conclusion
I hope this entry got you, at least, interested in OSGi. I think OSGi is a great start toward a unified component model for Java. It will certainly get developers to (hopefully) start viewing their systems in terms of components and not just classes. In future posts, I will look at how to use OSGi practically and integrate into your development efforts.

Even if you don’t plan to adopt OSGi right away, at least check it out .

References
About OSGi – http://en.wikipedia.org/wiki/OSGi
OSGi Alliance – http://osgi.org/
OSGi Articles – http://www.osgi.org/Links/HomePage
OSGi on InfoQ – http://www.infoq.com/osgi
Free OSGi Book By Neil Barlertt (PDF) – http://neilbartlett.name/downloads/osgibook_preview_20090110.pdf
EclipseCon Presentation by Richard S. Hall (PDF) – http://felix.apache.org/site/presentations.data/osgiapachecon-2005121…
Eclipse Equinox – http://www.eclipse.org/equinox/
Apache Felix – http://felix.apache.org/
Knopflerfish – http://www.knopflerfish.org/
SpringSource OSGi – http://www.springsource.org/osgi
Sip-Communicator Presenation – http://archive.fosdem.org/2007/slides/lightningtalks/SIPcommunicator.pdf