Andi Egloff's Weblog

Spring DM, Project Fuji and OSGi - thoughts on "three" peas in a pod

Just posted the below blog entry on the aquarium, pointing to the Spring DM support we have in Project Fuji (see the wiki on installing Spring DM framework bundles and the example OSGi bundle)

Sujit has published a blog entry showing a nice example of how to easily leverage Spring DM within OpenESB v3 / Project Fuji; both to either expose a service, or to call existing services on the "bus". The "bus" (a.k.a. normalized message router) adds the option of a message based, loosely coupled and asynchronous contract to an OSGi environment such as Felix or GlassFish v3. The simple API mechanism allows the (interface centric) OSGi services to implement and invoke message based services. Fuji then includes a host of advanced constructs, including the ability to route, transform and augment these messages.

If you're curious about the architecture and design of Project Fuji you might notice that there are no fancy Fuji specific extensions; it just leverages Spring DM's natural abilities to work well with OSGi services. This, as you might have guessed, is by design; Project Fuji not only leverages OSGi to implement it, but it also allows OSGi (and frameworks that build on it) as a programming model.

Now, I have seen the formation of camps on both sides, the "OSGi, it's what's for breakfast - it solves all problems" and the "YAGNI OSGi" sides. As usual, the right answer for your needs typically needs a bit more nuance, and I'll play my typical Swiss role here: OSGi is great for frameworks to give modularity and dynamism, for application programming models you may not need to use it, or not use it directly. And if you do, it probably will increase your productivity if you use a model such as iPojo or Spring DM (or even OSGi DS) on top.

There is no question that adding OSGi to your application programming model increases complexity. OSGi is an "exact science", meaning that if you know it and apply it correctly, it will do exactly what you want. If you don't have time to dive into the details, maybe your needs are simple, maybe you're rapidly prototyping, it can get in your way very quickly.

I think where a lot of rhetoric falls short is in not distinguishing between use of OSGi in the application development model; and the use of it in an underlying framework. Let's take GlassFish v3 or even Project Fuji as examples: just because it is built using OSGi, it doesn't mean you're forced to develop your applications with it. You can continue to develop Java EE apps "as is", you can write simple POJOs, JRuby, you name it; it's just that the containers that load your code now are more modular and dynamic.

Posted at 12:00PM Oct 05, 2009 by Andreas Egloff in Software Architecture  |  Comments[0]