February 23 - Keynote titled OSGi in the Enterprise: Agility, Modularity, and Architecture’s Paradox
March 22 - 25 - Tutorial on Modular Architecture
June 14 - 17 - Sessions titled Turtles and Architecture and Patterns of Modular Architecture
July 26 - 30 - Two sessions on rich mobile applications and one on agile development. Half day tutorial on software process improvement.
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 opinions expressed on this site are my own, and not necessarily those of my employer.
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:
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.