I’m more and more convinced that OSGi is going to change the way we develop enterprise applications. In a sense it’s funny because it’s been around for a while in embedded and client-side environment, and it’s only been reaching to us server-side developers for a few months. I think that the fact that the most popular Java component framework, ie Spring, jumped in with Spring OSGi (now Spring Dynamic Modules) has a lot to do with this new awareness. That and the growing interest for modularity and reusability encouraged by the Service-Oriented Architecture fashion. Yes, I agree that SOA has become yet another buzzword encompassing everything and nothing, depending on what software vendors sell to their naive customers. But if customers are ultimately willing to believe false promises, it might be because there is a gap in current technologies. Some see this gap as an opportunity for sales, developers see it as an opportunity for technology improvement. And I really see OSGi as THE technological answer to that and many other problems. Yes, OSGi might be server-side development’s 42!
Now, once you realize the importance OSGi is going to have in the years to come, the question is… sorry, the questions are why, what and how? Of course you could read the entire OSGi specification, but it would be like using a bulldozer to plant a flower. Fortunately for us, there are plenty of articles, blog posts and documents out there to help us understand how to deal with our delicate flower. Here is a possible learning path that will take you through a journey in OSGi world, why it’s useful, what it is, and how you can use it in your own projects.
Why is OSGi interesting?
Kirk Knoernschild wrote two excellent blog posts with sample code that is as simple as it can be and really gives a practical idea of what OSGi is all about.
- The first one introduces the notion of a service in OSGi
- The second one shows how you can really decouple the interface and its different implementations and dynamically switch from one implementation to another one
What I really like about those articles is that they use no external tools like Maven or Eclipse. Just plain text and Ant to compile. Just one thing that can be useful: you might want to download the latest version of Felix (1.0.4 at the time of this writing) and customize osgi/HelloWorld/config.properties (lines 31 to 34):
felix.auto.start.1= \ file:/Library/Apache/felix-1.0.4/bundle/org.apache.felix.shell-1.0.1.jar \ file:/Library/Apache/felix-1.0.4/bundle/org.apache.felix.shell.tui-1.0.1.jar \ file:/Library/Apache/felix-1.0.4/bundle/org.apache.felix.bundlerepository-1.0.3.jar
Those are my own modifications because I downloaded Felix and installed it in /Library/Apache/felix-1.0.4 on my Mac. And of course you will have to adapt startfelix.sh (or startfelix.bat) as well:
java -Dfelix.config.properties=file:./config.properties -jar /Library/Apache/felix-1.0.4/bin/felix.jar
Finally, in the second article, at the time of this writing there is a mistake in the code of the manifest for service2. I’ve left a comment and hopefully Kirk will fix his code in the repository. HelloWorldSpec/service2/META-INF/Manifest.mf should look like this:
Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-Name: Hello Service Impl 2 Bundle-SymbolicName: helloserviceimpl2 Bundle-Version: 1.0.0 Bundle-Activator: com.extensiblejava.hello.service2.impl.HelloServiceImpl Import-Package: org.osgi.framework, com.extensiblejava.hello.service
Then, following those two articles, Kirk modified HelloWorldSpec to integrate Spring Dynamic Modules and show what it brings to the table. More specifically, you can see that Spring Dynamic Modules makes it possible to externalize service registration and consumption in Spring configuration files and have service and client classes as simple POJO’s.
That’s it for the “why?”. I guess you understand why it can be interesting to use OSGi on the server-side by now. In the next article, I’ll try to give you a few links to identify what elements can make up your OSGi development environment.
