BT

Is OSGi the Right Foundation for Java Middleware?

by Jean-Jacques Dubray on Nov 11, 2010 |

The OSGi working group started in 1997 as the JSR 8, mostly focusing on embedded Java with the goal of supporting modular updates to embedded software. OSGi became mainstream after solving the inextricable dependencies of Eclipse plugins.  Right about 2005, several approaches converged towards bringing more modularity to Enterprise Java by leveraging assembly mechanisms and well defined dependencies, including Spring and Service Component Architecture while EJBs, slowly faded away. Today most Enterprise Java vendors have rewritten their middleware on an OSGi foundation.

Yet, there has been lots of frustration with the technology and Ross Mason, founder of MuleSource, let it all out on his blog a couple of days ago. 

OSGi was going to change everything, dependencies would be completely isolated (no more tripping over conflicting dependency versions), visibility and would be strictly enforced between each ‘bundle’. I was so bought into the promise of OSGi, like many others, I focused our engineering team on making Mule OSGi-enabled.
After months of our team wrangling with manifests, packaging our own bundles and endless fiddling with our build, the benefits of OSGi started to dwindle. ‘No pain no gain’ we thought, but then we hit our roadblock. 

His engineering team could not see how to hide the complexity of OSGi to middleware developers. He sees the problem stemming from the embedded roots of OSGi

OSGi is a great specification for middleware vendors, ...[but] OSGi was never build for application developer consumption. Its roots lie in set-top boxes that needed to have software updates deployed to them remotely without any user intervention. It is a great specification for this type of software deployment since only the vendors needed to deal with deploying bundles.

Modularization and versioning are two core problems in middleware projects. Service implementations change often (sometimes on a quarterly basis) and in the past large organizations often deployed all their services in a single ear file, every three month, creating major synchronization issues between consumers and service providers, not to mention testing all the services all the time, even though many in the ear might have never changed nor relied on the new or updated services. One could argue that poor modularization and lack of versioning alone are responsible for most of the claims that SOA is a failure. Ross adds:  

[OSGi] It promises to modularize software stacks and enable plug n’ play of your middleware infrastructure. Unfortunately, not even these promises are easily delivered with some bundles not working the same way across different containers.

Ross sees the principles behind OSGi as being the right ones for an evermore heterogenous stack. But for him:

the user interaction part of it needs to be re-thought now that OSGi is being targeted at regular application development. As it stands modularization and hot deployment is very possible on the JVM without OSGi and the pain of day-to-day development with OSGi out-weighs its benefits.

Neil Bartlett responded to Ross:

tools like bnd do already make OSGi nearly invisible to the developer. The problem right now, I believe, is that the choice of alternative approaches and tools for developing on OSGi is overwhelming. I remain convinced that the pain of day-to-day JVM development *without* OSGi out-weighs any of the short-term benefits....When’s the last time you wrote a .class file by hand? Probably never, you compile it from Java source. The OSGi manifest is the same kind of thing, it should be the output of a compiler-like tool. 

Joe sampson shared his experience with OSGi which he found hard to use from a testing and build perspective. Hani Suleiman noted

OSGi is a good model on a conceptual level, it’d just too hampered by the language not natively supporting it. The reluctance to start over with all that we’ve learned has meant that it’ll always remain an obnoxious unwieldy framework that nobody (that I know of, obviously if all you hang out is OSGi fruits then your experience will differ) honestly enjoys using.

Richard S. Hall added a word of caution:

If you come to OSGi and expect all legacy JARs to work perfectly and still reap all of the benefits of modularity, then you might as well not even try. That’s sort of like switching from C to C++ back in the 1980s and just hoping that everything automatically becomes object oriented.

Paul Fremantle, CTO of WSO2, responded to Ross, explaining that WSO2 Carbon is not only built on OSGi but completely hides OSGi from the developer. He acknowledge that it was not easy, but it was easier than building their own approach to modularization, versioning and provisioning.

What is your take on OSGi? Did you struggle ? Is it transparent to you? Is your middleware modular enough and support a world class versioning strategy? Could it be that we will always be bound to hit an architectural dead end as the core problem of modern architectures will always be the lack and mismatch of semantics with the ones of the underlying programming language, as Hani pointed out?

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

hide complexity by Christopher Brind

"His engineering team could not see how to hide the complexity of OSGi to middleware developers."


And yet, the engineering teams of WS02, Atlassian, and probably many others have ...

and my take by Christopher Brind

OSGi has just made sense to me, and any software developer I've explained it to has claimed to understand it as well. When I started off using OSGi with Activators and ServiceTrackers things were definitely much more complicated than they need to be. But using a DI and IOC technology (such as Declarative Services) is no more difficult than writing simple Java objects in most cases.

When you're designing an architecture or API for external use, sometimes you have to dip in to the complex internals of OSGi in order to make the external boundaries more palatable to developers. For instance, the work I've done on Vaadin for OSGi uses a set of nested Service Trackers to manage a couple of many-to-many relationships that a component could have. I took on that complexity so that developers further up the chain didn't have to.

On another note, Hani's opinions should be ignored, since he is always so quick to invoke Godwin's law.

Re: hide complexity by Christopher Brind

erm, *have not*, sorry

10 year old design that needs revisiting & reflect on how ops do work by William Louth

Every project/developer has to make their own cost/benefit choices by Michael Furtak

I use OSGi extensively in my work and I find the benefits to outweigh the frustrations. At this point, the thought of an unstructured Java classpath without OSGi makes me queasy.

If there are better, more language-integrated options in the future, I'll use them. For now, I'll use OSGi.

Re: Every project/developer has to make their own cost/benefit choices by Christopher Hopkins

I have to echo Mike's thoughts (partially because we work together). We are using OSGi as our primary enabling technology for the majority of our desktop applications. It's all about learning to use it correctly and taking advantage of the (albeit sometimes frustrating) Eclipse PDE tools. I haven't edited a Manifest file in years (thanks, in part, to some additional in-house tools that we've written to make DS easier) and would not want to go back to using "traditional" Java.

Re: Every project/developer has to make their own cost/benefit choices by Gerald Loeffler

We are using OSGi as our primary enabling technology for the majority of our desktop applications


without in any way downplaying the advantages of OSGi, i'd still like to challenge that grand word "primary enabling technology": in that very same sense and on a very comparable level, the following technologies are "enabling" of most applications: the jar file format and indeed the zip algorithm, the Java serialization spec and implementation, the Spring/Guice/CDI dependency injection framework, the Java classpath concept, ... . Just because something is very useful for a software system in its current implementation doesn't make it a "primary enabling technology", in my opinion. To give a counter-example: for the goal of deploying a cross-platform portable client-side application, the JVM is a *true* "primary enabling technology": very hard if not impossible to do without. In my opinion the same does not apply to OSGi.

Some enterprise-class Java middleware based on OSGi by Savas Ali Tokmen

Hello

I'm pretty surprised that thefounder of MuleSource has such a bad view on OSGi. Indeed, there is a product that competes the Mule lightweight ESB, called Apache CAMEL, that is fully OSGi compliant and that has never had major issues with OSGi. Moreover, CAMEL is also an excellent example of application that can be run either as a set of OSGi services, in a Spring container and even as a standalone Java application; which proves the ease of integration of OSGi solutions.

The Java "classic" application that has been most suffering of the JAR hell as well as absence of modularity issues have always been Java EE servers: they need to ship with many libraries, they need to have many services and run a large number of heterogeneous applications at the same time. Years ago, many Java EE server makers have seen OSGi as their "saviour".

The first Java EE server to be eager enough to redesign its architecture on OSGi and a lazy-service-oriented approach has been OW2 JOnAS 5 (jonas.ow2.org). That server is Java EE-certified since march 2009, and smoothly runs large-scale applications. Then came GlassFish 3, which is the first Java EE-6 certified server, also fully based on OSGi. Apache Geronimo and JBoss 7 will also be fully based on OSGi.

Another great added value of OSGi is when it comes to integrating applications. Imagine: you have your Java EE server and would like to integrate a lightweight ESB into it. In a non-OSGi world, you would need to repackage and certify your ESB with your Java EE server. Thanks to OSGi, all that repackaging and recertifying is not necessary anymore, integration is done at the OSGi level; the OW2 JOnAS + Apache CAMEL is a clear proof of this. In that case, OSGi saves a lot of time, avoids bugs and eases version transition without having to interrupt any service.

Cheers

S. Ali Tokmen
ali.tokmen.com/

Re: Some enterprise-class Java middleware based on OSGi by Benoit Pelletier

Hello,

I totally agree with you Ali. Creating its own modularization and service framework seems to me not efficient at all. First, it's time wasting which would have be used to develop its own added value. Second it would be pity not to leverage the powerful OSGi ecosystem.

Link to JOnAS+Camel page : wiki.jonas.ow2.org/xwiki/bin/view/Main/JOnASCamel

Bye

Re: Some enterprise-class Java middleware based on OSGi by Ross Mason

I'm pretty surprised that thefounder of MuleSource has such a bad view on OSGi.


You obviously didn't read my post then. I love the foundations of OSGi but the spec was never designed for developer use (set top boxes, under full control of the vendor). Now that we are trying to use it for everyday application development the spec needs to mature for the new use cases.

CAMEL is also an excellent example of application that can be run either as a set of OSGi services, in a Spring container and even as a standalone Java application; which proves the ease of integration of OSGi solutions.


Camel is a mediation engine, Mule is a application integration platform. The difference is that we'd need to embed the OSGi container as our core runtime. We were not comfortable with this at this time due to the maturity of the OSGi spec with regard to the effort forced on the developer to wire bundles together explicitly. Mule could easily be embedded in an OSGi container, that bit we did already. It was shielding the user from the details of OSGi cleanly that was the challenge. Btw you can embed Mule in Spring, Servlet container, test case, or run stand alone.


The first Java EE server to be eager enough to redesign its architecture on OSGi and a lazy-service-oriented approach has been OW2 JOnAS 5 (jonas.ow2.org). That server is Java EE-certified since march 2009, and smoothly runs large-scale applications. Then came GlassFish 3, which is the first Java EE-6 certified server, also fully based on OSGi. Apache Geronimo and JBoss 7 will also be fully based on OSGi.


This is great news for the community at large and as I said in my post we will revisit OSGi when progress is made on the developer friendly-ness part of the spec. Simplicity is hugely important to us at Mule, we didn't close the door on OSGi, we just deemed OSGi wasn't ready. In my mind its ready when we can move to OSGi and developers don't even know its there.

Cheers,

Ross

Re: Some enterprise-class Java middleware based on OSGi by Ross Mason

I totally agree with you Ali. Creating its own modularization and service framework seems to me not efficient at all. First, it's time wasting which would have be used to develop its own added value. Second it would be pity not to leverage the powerful OSGi ecosystem.


The choices were, create a deployment model in Mule that was super simple or force OSGi on our users. I don't want OSGi to be visible, its a detail of the system that should be managed for you. The fact that a modularization specification has an 'eco-system' tells me it doesn't work the way it should. OSGi drags along a load of new tools to learn. I do think it's crazy that the JVM doesn't have a _transparent_ module system like OSGi (or OSGi+) in this day and age.

Cheers,

Ross

Re: hide complexity by Ross Mason

And yet, the engineering teams of WS02, Atlassian, and probably many others have ...

Ouch :-)

We can do anything in Java but doesn't mean we should. The point of my blog was that we need modularity on the JVM but the OSGi approach needs to mature on the developer facing side it it is to get mass adoption. Also, whatever the solution is we need it to be transparent. Atlassian worked very hard to make this happen and had to introduce 3 levels of plugins. I bet they'd drop all that work in a heartbeat for a transparent solution where they didn't have to work around the spec. I find if you have to work around a spec it was either not scoped well, or you are not using it correctly or it still needs to mature.

Cheers,

Ross

Re: Some enterprise-class Java middleware based on OSGi by Savas Ali Tokmen

Hello, Ross

I do think it's crazy that the JVM doesn't have a _transparent_ module system like OSGi (or OSGi+) in this day and age.


Having a .net background, where library dependency and service injection is automatically managed by the systems in the IDE in a transparent way, I cannot agree more.

As you've said, OSGi needs to evolve in order to become more transparent to the developer. This is slowly becoming a reality: Maven2 plugins and service-level dependency managers such as Apache iPOJO make things become easier. Moreover, all the Java EE-related work that's being done in order to integrate Java EE, OSGi and even Spring together is resulting in interesting standard mixes. OSGi-CDI integration in GlassFish 3.1 is also a very good example to this.

More importantly, badly designed (and commonly used) libraries need to be redesigned in order to have a clear packaging and dependency management.

Cheers

S. Ali Tokmen
ali.tokmen.com/

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

13 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT