My Stuff

2010 Conferences

OSGi DevCon @ JAX London

February 23 - Keynote titled OSGi in the Enterprise: Agility, Modularity, and Architecture’s Paradox

EclipseCon

March 22 - 25 - Tutorial on Modular Architecture

Über Conf

June 14 - 17 - Sessions titled Turtles and Architecture and Patterns of Modular Architecture

Catalyst

July 26 - 30 - Two sessions on rich mobile applications and one on agile development. Half day tutorial on software process improvement.

Tweets @ Twitter

re: #apple event "We sold more iPads than any PC manufacturer sold of their entire PC line." 2012-09-12

re: #Apple Event ""Our notebooks now rank #1 in the US in Market share in the last three months." 2012-09-12

Right on. I just won a Best Buy drawing worth $1000. Either that or I won a shiny new virus by clicking the link. Hmm...what to do. 2012-08-29

The #osgi alliance response (http://t.co/KrN8XNWg) to the @mreinhold #jigsaw announcement (http://t.co/9YvcDdqC). 2012-08-29

Good Q&A with @mreinhold on project #jigsaw. http://t.co/9YvcDdqC. Modularity will change the way we design and run apps! 2012-08-28

LinkedIn Profile

The opinions expressed on this site are my own, and not necessarily those of my employer.

OSGi & Modularity

Filed Under Architecture & Design, Java, OSGi, Platforms |  

The .jar file has always been a great unit of modularity on the Java platform. Unfortunately, it also comes with the classpath baggage, and .jar files were never treated as first class components. OSGi is the next generation component platform that will bring greater modularity to the Java platform. In my previous blog, I showed the simplest OSGi components imaginable. Now I want to expand on that slightly by introducing a third component that exposes a key architectural and design benefit enabled by OSGi.

A classic design statement in the GOF book states that we should separate interface from implementation. Java provides first class support for this heuristic through it’s use of interfaces, and we use it all the time. We know it’s good design. But another important design heuristic less often used states that interfaces should be placed separate from the classes that implement them. By placed, I mean the modules containing those interfaces. The result is subtle, yet has an important impact on design quality. The HelloWorld example serves as a good illustration.

The HelloService interface is the specification implemented by the HelloServiceImpl. It decouples HelloClient from the implementation, and adheres to the GOF heuristic of separating interface from implementation. But bundling the interface in the same component as the implementation compromises design quality, and is the basis for the modularity heuristic above. Why? Because while I can still gain extensibility through new implementations of the interface, I lose flexibility in how I manage the implementations if the interface and implementation are deployed in the same component. For instance, in my previous example where the interface and implementation are deployed in service.jar, I don’t have the ability to dynamically replace the existing implementation with another because I can’t remove the implementation from the OSGi run-time if the interface and implementation are deployed together.

But if I move the interface to a separate bundle, call it spec.jar, while leaving the implementation in service.jar, I do have the ability to swap implementations at run-time when using OSGi. In my Google Code repository exists the HelloWorldSpec project. There are four bundles - client.jar, spec.jar, service.jar, and service2.jar. Still a pretty simple example, but it illustrates the key design heuristic.

In my initial deployment to Felix, I install client.jar, spec.jar, and service.jar. The results are the same as in my previous blog entry. But now, if I deploy and start service2.jar, stop service.jar, and stop client.jar, the OSGi run-time has managed to dynamically adapt to the changing conditions and discovers the service2.jar implementation of HelloWorldService. To experiment for yourself, do something like the folllowing after checking out the project from Google Code:

  • Build all four projects using ant build.all from the HelloWorldSpec root directory.
  • Start felix (you may have to modify the script - .bat or .sh - to find the felix.jar).
  • Use HelloWorldSpec as the profile if you want to use the bundles already installed, or create your own profile if you want to install them yourself.
  • If you used HelloWorldSpec as the profile, uninstall the service2.jar bundle. If you created your own profile, install spec.jar, service.jar and client.jar.
  • Stop client.jar and notice the message. Start client.jar back up.
  • Install and start service2.jar
  • Stop service.jar.
  • Stop client.jar again. Notice the message. Cool - an environment adaptable to changing conditions.

As OSGi adoption continues, a new set of design principles are going to emerge surrounding modularity. I show but one example here of the benefit of placing interface in a module separate from implementation. An example of another important design principle enabled by OSGi is a PublishedInterface - public classes in a bundle’s exported packages. Something not supported by the JVM, but enabled by OSGi. In fact, I’ve long been an advocate of the .jar as a first class Java component, and some time ago launched Extensible Java to capture many of these modularity patterns. It’s also why I created JarAnalyzer. It’s time I revisit those ideas.

Comments

9 Responses to “OSGi & Modularity”

  1. Blog bookmarks 04/28/2008 « My Diigo bookmarks on April 28th, 2008 4:53 pm

    [...] OSGi & Modularity : Software & Technology @kirkk.com [...]

  2. OSGi & Spring : Software & Technology @kirkk.com on May 6th, 2008 2:26 pm

    [...] show the simple elegance Spring brings to OSGi development using the HelloWorldSpec sample from the OSGi & Modularity post. But first, a little primer on Spring Dynamic Modules. Spring DM is not an OSGi implementation. [...]

  3. Sebastien Arbogast on May 8th, 2008 1:04 pm

    I still have one issue. When I follow the exact sequence of operations in Felix 1.0.4, when the client is started and I stop the service impl, either to restart the same or switch to another one, when I stop the client after that, I get the “Hello service not available” message. Yet the “ps” command confirms that at least one of the service impls is started. So in my case, I still don’t see the “environment adaptable to changing conditions”. Any idea of why might go wrong?

  4. Sebastien Arbogast on May 8th, 2008 6:11 pm

    I figured out what was wrong: there is an error in the manifest of service2. The bundle activator is not declared and org.osgi.framework package is not imported. Hence the start method for bundle service2 was never called and the service is never registered.

  5. kirk on May 8th, 2008 11:45 pm

    I’ve corrected the mistake in the Google code repository. Appears that when I create the Spring sample, I inadvertently overwrote the Manifest.mf in the HelloWorldSpec project instead of adding it to the HelloWorldSpecSpring project. Not sure how I managed to do that, but thank you for pointing out the mistake.

  6. My OSGi Learning Path (Part 1) on June 2nd, 2008 10:43 pm

    [...] The second one shows how you can really decouple the interface and its different implementations and dynamically switch from one implementation to another one [...]

  7. OSGi and Embedded Jetty : Software & Technology @kirkk.com on February 2nd, 2009 6:25 pm

    [...] application server, into Felix, the OSGi runtime. As with my previous posts (Simple OSGi Service, OSGi & Modularity, and OSGi & Spring), I’m trying to use the simplest tools for the job to maximize the [...]

  8. The Two Faces of Modularity & OSGi : Software & Technology @kirkk.com on June 23rd, 2009 4:12 pm

    [...] It’s important that development teams start modularizing their applications, even if they aren’t deploying to an OSGi runtime. How can we do this? We know a lot about the OSGi runtime model. It’s likely the platform we’re using is leveraging the runtime model internally, even if it’s not exposed to us. We know the unit of modularity is the JAR file, and we can start modularizing our applications today by emphasizing the JAR file as the unit of modularity. [...]

  9. airmaxs96093 on May 20th, 2013 3:56 am

    Howdy, i read your blog occasionally and i own a similar one and i was just wondering if you get a lot of spam comments? If so how do you stop it, any plugin or anything you can suggest? I get so much lately it’s driving me insane so any assistance is very much appreciated.

Leave a Reply