Raible Designs

[TSE] Spring-OSGI with Adrian Colyer

Adrian has CTO as his title on his slides. Wasn't he hired as "Chief Scientist" originally? I wonder why his title changed? Maybe having the CTO title is a better way of getting more cash when the buyout happens? What buyout you ask? I don't know, but I can't help but think that Interface21 is on the radar of major organizations like Oracle and BEA. While it might suck for those guys to answer to a larger organization, it would be nice to see Rod, Juergen, et. al. benefit ($$) from all their hard work.

Agenda

• What is OSGi?
• What problems does it help us to solve?
• How does it work?
• Where does Spring fit in?
• Spring-OSGi

One of the first questions people ask about OSGi is "what the heck is it?"

The 2nd question is "what's with the lowercase i?" Seriously - does anyone know?

Most people don't even know what it is. OSGi stands for Open Services Gateway initiative. From the very beginning, it was designed to be lightweight and dynamic. This is the major difference between it and other containers. It's always been designed to have things added and removed. Now it's tagline is: "The Dynamic Module System for Java".

It's designed to allow you to partition a system into a number of modules (a.k.a. bundles). There's strict visibility rules (similar to protected and private). There's a resolution process (dependencies are satisfied) and it understands versioning.

It's dynamic! Modules can be installed, started, stopped, uninstalled and updated - all at runtime.

It's even service oriented (no wonder IBM loves it). Bundles can publish services (dynamically). The Service Registry allows other bundles to find services and bind to them. Services come and go at runtime, all taken care of for you.

Where does OSGi come from? It's backed by the OSGi Alliance. Unfortunately, this site makes it difficult to figure out exactly what OSGi is. The founders of OSGi understood it needed to be lightweight and dynamic from day one. It started in 1999, and was originally focues on embedded Java nd networked devices. In 2003 it was exteneded to support to mobile devices. In 2004, it had significant ope source community opttion with Eclipse. In 2006 and 2007, it's moving into server-side Java.

Who's doing OSGi containers?

• Open-source implementations: Equinox, Felix (Apache), Knopflerfish
• Significant Enterprise usage: Eclipse, IBM (WebSphere, Lotus), JOnAS, interest from BEA and Oracle

So what? What problems does OSGi solve?

Visibility By default, a bundle is a black box. It's completely protected and you can't see inside it, not even with reflection or any other classloading trickery. Only exported packages are visible outside of the exporting bundle. This stops unintended coupling between modules, enables independent development, faster development cycles and security.

Operational Control
An OSGi container allows you to see all modules and their status - using the OSGi console or JMX. You can get information on wiring, install new bundles, activate bundles (and publish services), deactivate bundles (and unregister services), refresh bundles, stop bundles and uninstall bundles. The beauty? You can do all of this without stopping or restarting the application!

What is an OSGi bundle?
It's just a jar file. There's no complicated tools or sophisticated packaging required. All you need is a symbolic name in your META-INF/MANIFEST.MF file. For example:

Bundle-SymbolicName: org.swf.beans

There are a number of other attributes you can specify, but the SymbolicName is the only required one.

There's a Maven OSGi Plugin. The major change from a regular JAR project is <packaging>jar</packaging> -> <packaging>osgi-bundle</packaging>.

Sidenote: You have to love how Maven is so Google un-friendly. Searching for Maven OSGi Plugin doesn't seem to provide a definitive answer to the Maven plugin that Adrian is talking about. I'm guessing Maven has OSGi support natively?

Eclipse has fantastic tooling support for OSGi via "plug-ins". You can create a new "plug-in project" and use Eclipse to create/edit your OSGi manifest. Eclipse calls bundles "plug-ins" - so creating a plug-in project is the same thing as creating a new bundle.

Export-Package is a header (a.k.a. manifest entry) used to export types for other bundles to use. If it's not exported, it's not visible. For example:

Export-Package: org.xyz.m1.service, 
                org.xyz.m2.service, 
                org.xyz.m3.service

You can also specify a version by adding a semicolon after the package and specifying "version=#". For example:

Export-Package: org.xyz.m1.service; version=1.0, 
                org.xyz.m2.service; version=1.0, 
                org.xyz.m3.service; version=1.0

In addition to specifying specific versions, there's syntax to control a specific versions. For the examples above, OSGi will actually get any version 1.0 and above.

For the next 10 minutes, Adrian talked about how class-loading and resolution works. He also pointed out how to bootstrap a bundle (using the BundleActivator interface) and the basics of the Service Registry. The BundleContext allows you to get and remove services.

What about JSR 277 (Java Module System)? It's a very crude version of OSGi with its "RequireBundle" mechanism. The key problem is the lack of dynamics (loading/unloading of modules). Peter Kriens (of the OSGi Alliance) shares his thoughts on this in his JSR 277 Review. JSR 291 (Dynamic Component Support for Java SE) may kill 277 because it relies on OSGi. Its goal:

Establish a JCP specification for a dynamic component framework supporting existing Java SE environments based on the OSGi dynamic component model specifications. "

What about Spring?
OSGi offers an excellent foundation for building enterprise applications. How can you exploit the power and sophistication of OSGi w/o adding complexity? How can you split your application into a number of OSGi bundles? Between bundles, you need an easy way to expose bundles as services and wire service references b/w them. What about testing? How can you test bundles w/o running them inside an OSGi container?

Spring-OSGi hopes to allow you to build on OSGi, but deploy in Tomcat, WebSphere, WebLogic or any other application server. Basically, it gives you an "OSGi powered Web Application".

Project Goals: Bring the benefits of OSGi to enterprise applications and use Spring to configure modules/bundles. In addition, make it easy to code your applications w/o depending on OSGi APIs and make it easy to unit and integration test.

Project Collaborators: Adrian is the lead, and there's active committers from BEA and Oracle. Input to the project's specification has been gathered from OSGi Alliance (technical director and CTO), BEA, Oracle, IBM, Eclipse Equinox, Felix and many individuals.

Spring modules (spring-core, spring-beans, spring-aop) will be shipped as OSGi bundles in Spring 2.1. All the necessary import and export package headers will be pre-defined. This will enable an OSGi application to import and use Spring packages and services.

OsgiBundleXmlApplicationContext is a Spring application context based on an OSGi bundle. It uses the bundle context and classloader to load resources and implements Spring's resource abstraction for OSGi. There is a "bundle:" prefix for specifying an explicit path.

To do integration testing with Spring-OSGi, you can extend ConfigurableBundleCreatorTests. This automatically creates an OSGi bundle containing the tests on the fly. This class handles starting an OSGi container, installs all bundles and runs tests inside OSGi. Currently, it supports Equinox, Felix and Knopflerfish. If you're using Maven, it's simple to switch containers with profiles (i.e. -Pfelix). Adrian did a demo in Eclipse. I didn't seem the OSGi container starting (or him specify which one to use) but the test seemed to finish rather quickly.

To interact with OSGi, there are a number of conveniences that Spring-OSGi provides: BundleContextAware, <osgi:property-placeholder>, <osgi:bundle> (starts other bundles), <osgi:virtual-bundle> (bundle created on the fly).

OSGi-based web applications
It's entirely possible to run an OSGi container embedded in another container. Remember it's lightweight enough to run in a phone! Even OSGi in OSGi is supported.

Equinox is the only OSGi container that currently supports web applications. It uses a "bridge servlet" that acts as a front controller and dispatches servlet requests to bundles. To package your application as and deploy it to Equinox, you basically have to create a WAR with the bridge servlet as the only entry in web.xml and the only JAR in WEB-INF/lib is servletbridge.jar. Everything else is packaged under /WEB-INF/eclipse. Here's what that looks like:

WEB-INF 
    web.xml  
    lib/servletbridge.jar 
    eclipse 
        launch.ini 
        configuration/config.ini 
        features 
        plugins 
            <your-bundles>

Adrian did a demo showing a simple "Hello World" example deployed into an OSGi container. The output from the demo in the browser wasn't much. However, he showed how you could use an OSGi Console to interact (start/stop/refresh) all the different bundles. The fact that you can do this all at runtime has some pretty interesting implications.

My Thoughts
The demo makes Servlet/EJB containers look somewhat primitive. Will OSGi containers be the next generation of application servers? It seems somewhat likely, but as Adrian said, most of this stuff is on the bleeding edge (or even "razors edge" to quote Adrian). My guess is OSGi will be a very interesting space in 2007. However, I don't see myself deploying WARs to OSGi containers anytime soon. Maybe in 2008.

Can OSGi power a web application's plugin architecture? It doesn't seem like it. The web application would have to be deployed in an OSGi container to make this possible. Either that, or the web application would have to be an OSGi container itself.