Software Artist

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.

3 months ago, the day SpringSource announced their acquisition of Covalent, the company behind Tomcat, I knew they were up to something. I even talked about it with Andrew Glover for JavaWorld. And now it’s real: SpringSource has just announced SpringSource Application Platform.

First off, a few links around this announcement:

• The initial announcement of InfoQ
• An introduction to what is SSAP on SpringSource Team blog
• The official web page with other links, where you can register for the beta program and get your hands on the beta version
• A very interesting interview of Rod Johnson on DZone

Now this is very exciting. That’s the kind of inspiring technologies that make me think of tens of ideas for new projects, new tools that were just impossible before and that could now become reality. Adobe Flex had the same effect of unleashing my software artist imagination. Now I’m starting to think about combining the user experience of Flex applications on top of the ease of management, deployment and extensibility of OSGi with SSAP. Jeez, we’re living an incredible period!

A few weeks ago, I’ve been interviewed by Andrew Glover for JavaWorld’s Java Technology Insider podcast and it’s been published today. So without further ado, feel free to check out our talk here.

Now if you want to read it rather than listen to it, I’ve prepared a transcript for you guys. I’ve added a few links inside the transcript for the references I mention.

Continue reading »

I wanted to download the latest version of JBoss AS to deploy it to a new server, and while I was wandering round their site to see what is going on, I found an interview of Ales Justing by Mark Newton about the work they’re doing with OSGi.

Apparently they are not waiting for it to happen. They’re really taking part in it, which is refreshing because ever since Redhat acquired them, I’ve always been afraid of the possibility that they could rest on their achievements and have trouble keeping up with innovation. Obviously I was wrong and since they even have some people inside the Enterprise Expert Group, we can expect some pretty good integration of OSGi into future releases of JBoss.

They are even going as far as reengineering a key part of their architecture, which is the microcontainer, to integrate OSGi. That’s really an excellent thing because I’ve always found that JMX is really a pain to manage. According to the interview, they are totally changing their core classloader:

We could probably use the classloading features of existing OSGi frameworks but it would again mean bending around things to make them work. As we wanted to have a bullet proof implementation, where all the nasty details were hidden away under private/protected modifiers, it was important that we could tightly control access through policies and delegation. From this perspective it made more sense to implement our own classloading layer.

Concerning integration with Spring, apparently they are still taking their distances. I guess it has something to do with the fact they Spring/Hibernate competes with EJBs and has thus encouraged many developers to choose a simple Tomcat server instead of a full-blown JBoss for their deployment. But as long as I can freely deploy my Spring/Hibernate on JBoss and still benefit from features like SOAP, JNDI, JMS and so on, that’s fine with me.

So that’s one other major actor of the enterprise application server market who is moving towards OSGi. Did I already say that it’s going to be big? And OSGi DevCon is certainly going to be very important this year.

That’s official: SpringSource has just acquired Covalent. Or as I explained it to one of my colleagues, “the company behind our IoC framework has bought the one behind our application server”.

My first reaction was satisfaction, because it’s another step forward in the direction of corporate Open Source adoption. It’s always amazed me to see how big companies can be afraid of Open Source. And the fact that there is now one bigger support service offer behind two of the most popular Open Source technologies in the enterprise will certainly reassure some skepticals.

The second “kiss cool effect” was undoubtedly about something I’ve really been playing with lately, since Javapolis: OSGi. The fact that componentization-related JSR’s are so fragmented and so alpha, plus the recent works of Spring Dynamic Modules for OSGi, added to Peter Kriens’ presentation at Javapolis, all of that really got my attention. And now I’m dreaming of building a collaboration platform using Flex for the front-end and OSGi, Spring and Hibernate JPA for the back-end. The only component that’s missing in my big picture is a deployment target platform, i.e. an OSGi application server. Of course, JOnAS is working on that but there’s no documentation on their 5.0 server whatsoever. And I’ve heard Websphere and Weblogic are using OSGi too, but hey, I’m talking about Open Source here! Now have a look at the documentation of both Tomcat and Spring. They’re probably amongst the best Open Source documentations on the planet. Now imagine that quality of documentation for a brand new Tomcat 7 server using OSGi as a core deployment mechanism, and integrating Spring DM libraries to ease the development of web application bundles.

Yummy!