Why OSGi is cool, but not for most enterprise apps…
There’s been a lot of hype around OSGi over the last year or two in the enterprise space. Last year even Caucho dallied with adding OSGi support to Resin, though we’ve abandoned the idea in the meantime. In this post, I’ll tell you what’s cool about OSGi, why we were initially attracted to it, why we eventually dropped it, and what we did instead. The more I talk to enterprise developers who’ve actually used OSGi, the more I hear this same story.
Update: Rob Harrop informed me that there is an emerging specification called RFC-66 for enterprise web/OSGi integration.
OSGi Features
Service Model
Even though OSGi is relatively new to enterprise developers, it has a long and storied history in the mobile community. The service model promoted by Peter Kriens is also really neat and allows you to add new services to a JVM at runtime. If you’re developing a mobile application, being able to add and remove services without restarting is essential. A service could be something like a mobile application or a communication stack for WiFi or 3G when a network comes into range. So services are a really cool feature of OSGi.
Modularity
Most of the attention that OSGi has been getting from the enterprise developers is related to its modularity features. The core functionality that OSGi provides is a Bundle-based framework in which .jar files have explicitly defined visibility rules. What this means is that you can bundle a group of packages into a .jar, define which packages the .jar provides, which packages it depends upon, throw all your .jars into the OSGi container, and have it sort out the visibility for you. One of the cool features of the dependency resolution is that you can also have multiple versions of the same package/bundle floating around and OSGi can isolate these versions, protecting you from conflicts. This approach to modularity is another awesome feature for mobile because you may need to upgrade components at runtime, but not all the dependent components may be compatible with the upgrade.
Caucho’s journey with OSGi
Based on the demand and some interesting tutorials, we decided to implement OSGi in Resin last year. One of the things we liked is the dependency resolution, but we couldn’t quite figure out how OSGi bundles and services should fit into a web or enterprise world. There are a couple of ideas that are floating around about what’s the right thing to do in this case. One approach is to run your application server as a bundle with the OSGi container controlling the JVM. We rejected this approach, at least for our initial draft, because Resin already has sophisticated startup mechanisms in place which didn’t quite work with that model. The other approach is to run an OSGi container within the application server, which worked better for us. Scott wrote the code necessary to wire together the dependencies, which involved a few crazy classloader tricks, and we were happy with the functionality.
So the next question was, “How do you actually write a web application in OSGi?” Specifically, how do you write a frontend? If you only write business components in OSGi, how do they communicate with the frontend? There’s no lack of ideas about what can be done to solve these problems - draft proposals and independent implementations abound - but there’s no emerging standard that really makes this clear. With this confusion, we set OSGi on the backburner for a while until a standard or even de facto standard became real.
In the meantime, I set to work on our Eclipse plugin and got to work with OSGi first hand. The experience was painful. With hundreds of bundles in the runtime and an obscene number of versions for many of them, the first impression was one of complexity. Once I actually started looking inside of the Eclipse bundles, I realized that they had also added Eclipse-specific metadata. This says to me that OSGi’s model isn’t quite adequate to handle what Eclipse is trying to express. More over, the division of packages within single features seemed arbitrary and overly confusing. Specifically, I was working with the WebTools project framework for the Resin plugin and was confronted with a set of bundles for each subproject. There were separate “core” and “ui” bundles for each subproject, which is logical, but all sorts of crazy tricks were played to import non-exported packages between the two, and between subprojects. That’s a bad sign.
None-the-less, I can understand why Eclipse would choose OSGi - it is a large, complex product with many possible conflicting modules due to its open-source nature. As a side benefit, you’d like to be able to add services at runtime - such as new plugins and features - without having to restart because Eclipse is a bit of a beast. (Of course Eclipse warns you that it would be better if you do restart after adding any new plugins, so it’s questionable if that actually works in practice.)
Moving away from OSGi
After this brief foray into OSGi land, we started evaluating what value OSGi added to the enterprise world. Are many enterprise web apps complicated in the same way that Eclipse is? Specifically, do many real enterprises add tons of experimental plugins and features to their sites that need isolation to make them work together? Hopefully not. Are there significant overlaps in requirements with mobile apps? Specifically, do enterprise applications need to add services at runtime without restarting the JVM? Maybe - it would be a nice feature to have, but if you’re running a large enterprise site, you’d probably prefer to get a clean boot of a system with the new service, test it, then start directing traffic to the server. No matter how clean the framework, administrators will always prefer a freshly booted machine.
How about the component model? Does it improve development? Eclipse showed me how the bundle system encourages over-componentization, but was this problem present for enterprise apps? I saw a talk by Rob Harrop of SpringSource (PDF) at TSSJS in Las Vegas in which he talked about using Spring’s DM server and the discoveries they made while creating a web framework around OSGi. It was a interesting talk and Rob was definitely excited about OSGi and finding best practices. In fact he seemed to make all the same observations that I did - easy temptation to create too many bundles and the need to shift boundaries throughout the development cycle - but came to the conclusion that these were worth solving because of the dependency resolution.
Well, we certainly agree that the dependency resolution features of OSGi are cool, especially given that a lot of projects use many libraries with second-level dependency conflicts. But do you need the complexity of OSGi for that? Moreover, are you ready to switch your entire programming and component structure of existing applications to OSGi? We thought that these are pretty big hurdles, so we decided to morph our OSGi classloader backend into Pomegranate. The idea is simple: start with the dependency metadata many people already have in the form of Maven pom.xml files, then do the same resolution magic on Maven jars instead of OSGi bundles. Pomegranate even handles multiple versions of the same library. That functionality probably solves many of the problems that enterprise developers look at OSGi for, without making you learn a whole new tool set and metadata formats. Certainly Pomegranate doesn’t aim to be a complete replacement for OSGi, but rather a focused approach to solving the real problem of dependency resolution without changing the entire programming model.
Scott wrote a quick overview of Pomegranate and we’ll soon have real docs for it, but I wanted to give the story of how we got to Pomegranate first. What’s your experience with OSGi? Has it helped your development/deployment or just made it more complicated?
Tags: osgi, pomegranate
June 16th, 2009 at 11:44 am
A key issue with OSGi is its focus on Java packages as the key focus, not jars themselves.
In a mobile context, it may make sense to create one package of API interfaces to export, and hide the rest in other packages, but enterprise applications need more flexibility to their package design.
In other words, while the OSGi model of package-use is fine, it’s not the One True Package Architecture, and doesn’t play nicely with enterprise applications.
June 20th, 2009 at 12:46 pm
Hi
My comments on this entry grew to the point where I felt it best to put them up on my own blog:
http://rinswind.blogspot.com/2009/06/current-state-of-affairs.html
June 21st, 2009 at 10:20 am
Thanks for the perspective, rinswind. I certainly agree that if you’re working in the OSGi space to determine best practices and architectures, it’s exciting because there’s a lot of room for innovation. If your approach wins in the end, the payoff could be huge in terms of changing the way enterprise apps are written and perhaps financially as well. On the other hand, if you’re trying to write an enterprise app and deliver it anytime soon, that open field means creating a lot of your own infrastructure. Our plan is to help developers in the latter position now and keep a watchful eye on the developments in the OSGi world to see signs of stability. I think your blog post is helpful in showing the position of those working out the issues with OSGi, so thanks again for sharing it with us.
June 25th, 2009 at 5:22 am
I’ve also been trying to “play” with OSGi and I also saw a bit “overwhelming” for my needs, so I decided to let it mature for a while. From a “simple” application developer perspective, it seems to me that is is a technology to be employed by infrastructure builders to provide transparent facilities for us, not something to be employed directly by “end developers”.
And it must be so many years using Resin, or it might be that I use Resin because my mind is aligned with Caucho guys, but I agree that OSGi might still need a bit of time so something simpler, easier to use, even if not feature-complete, could be useful now, to start changing things and exploring best practices etc.
The only thing I would ask is for web apps to still be compatible with other containers. So, for example, you might allow .jar files to be included in WEB-INF/lib but if you include WEB-INF/pom.xml they are moved/renamed/not taken into account automatically. That means the application as-is can work in other containers but you get all the goodies if you do it inside Resin/Pomegranate.
I’m looking forward to using this and the new GIT/.war features of Resin 4.0 in production :).
S!
Daniel Lopez
June 27th, 2009 at 9:30 pm
rinswind,
The difficulty with OSGi is really when you get to engineering implementation details. If you stick to the 10,000 foot level “modularity and services are good”, then OSGi looks fine. When you start putting it into real engineering practice for enterprise applications, the mismatch becomes apparent.
The two mismatches in OSGi are the package orientation and the entire service model.
OSGi strongly encourages a model where each module export a single package and has a collection or implementation packages. For simple applications, like embedded application, this package structure can work well, but in an enterprise environment it warps the natural enterprise organization to a foreign strict-package model. In other words, the enterprise application is no longer organized naturally to the application itself, but to the foreign OSGi model.
The service model is just a generation behind, basically a service-locator model. There’s nothing intrinsically wrong with the model, but new technologies like Java Injection (JSR-299) are more descriptive and powerful.
July 30th, 2009 at 6:59 am
A thought long and deep if OSGi could help us earn more money, spend less money, be more flexibile and all that. My conclusion: For us redeploying whole servers is easier to manage, continous deployments are better suited for most web applications than OSGi.
Stephan Schmidt
Head of Development b4f
http://twitter.com/codemonkeyism
July 31st, 2009 at 12:47 pm
freg,
I am not convinced there is a “natural” way enterprise applications are organized that clashes with either package level visibility or the service model. I would be grateful for any examples that both constitute a good practice and at the same time fundamentally clash with package-level visibility or services.
To me the greatest barrier to enter OSGi is the lack of support for the big infrastructural services every non-trivial application needs. With this in place the next barrier is the required switch in thinking from the usual app designs to a strong service oriented design. Many traditional isolation practices are hard to use with OSGi because they are no longer required! I think we have trouble grasping the extent to which we need to do *less* with OSGi. We almost don’t need abstract factories, we almost don’t need singletons, we almost don’t need classes in our APIs, consequently we don’t need to control access between the public and private halves of these classes with package-private members and any other tricks. Currently the main weakness of the package-level control is that I can’t expose certain service APIs to collaborating bundles in my application while hiding them from bundles within other applications. However without OSGi any such access control is down to pure convention, so certainly OSGi improves the situation although it does not completely solve the problem. This last hole will be plugged with composite bundles. I.e. a multi-bundle app will look as a single bundle to other apps. In fact Eclipse already has a reference implementation of this.
As for the service model: I think it is not meant to be used directly by developers. I look at it as an extremely simple interoperation layer. It’s job is to capture the absolute minimum of functionality required to share live objects between bundles - the simpler and more straightforward the better. Currently it does a good job at this but I think it needs to be refined and simplified a bit more. Because the service model is so simple it is quite easy to extend it to a full DI runtime. The beauty of this design is that we can have any number of ‘oppinionated’ component/DI runtimes running concurrently within the same OSGi container and interoperating with each other completely transparently. So everyone can use the runtime that suites their application best, drop down to the raw API, or even implement their own DI framework. I am almost certain it will be possible to implement JSR-299 on top of OSGi as well. Btw today there are no less than 5 component/DI runtimes for OSGi an they do interoperate transparently and are free to evolve independently.
August 5th, 2009 at 10:28 am
Take a look at a basic wicket example: http://wicket.apache.org/exampleguestbook.html. Wicket uses its packaging to organize its components in a logical and useful way, and the wicket library is used as a single conceptual unit, not a big collection of packages.
With Maven-style dependency, wicket is easily imported because “wicket” is a conceptual name encompassing the entire wicket library, not just the name of a package. And it’s trivial:
To convince anyone to switch to OSGi, you’d need to explain why redesigning Wicket in an OSGi style was better. If OSGi had real value for the enterprise, either the dependency management would be easier than the Maven example above, or an OSGi-style reorganization of Wicket would be intrinsically superior to the current Wicket architecture. Handwaving about service-oriented design isn’t enough.
Some applications which fit a strong service-oriented design may fit well with OSGi, but that does not imply that all enterprise applications should therefore be converted to use OSGi.
August 17th, 2009 at 6:44 am
Fine point.
Maven and OSGi do not contradict each other. In fact I build OSGi bundles primarily with Maven. I agree Import-Package is too low level for humans to cope. This is why I work at the coarser grained maven level and use a maven plugin to automatically build the low-level OSGi metadata for me.
Also OSGi supports maven-style dependencies at runtime with Require-Bundle. This includes the possibility to have composite facade bundles like say “org.apache.wicket-1.4.0.jar”. At *runtime* both Import-Package and Require-Bundle have their valid use cases. At *buildtime* however we should always use Maven/Require-Bundle level of granularity and tools to get the flexible low-level OSGi metadata.
Here is a blog explaining why this high-low separation is a good idea:
http://www.osgi.org/blog/2008/06/jsr-277-and-import-package.html
As for the service model: I agree it is not for every usecase. Real application are a mix between the service model and the extender model. I think extender is at least as important as the service model and more generic. Here again we are just starting to explore the full potential and to develop clear best practices and standards like OSGi RFC-66.
Anyway my point is that OSGi and the enterprise do not have fundamental contradictions. It is mostly that the raw OSGi is a thin modular layer on top of the JVM. Having runtime modularity is very compelling - but it must also be easy/cheap to use. That’s why rather than reject the best current modularity runtime for Java we should push forward and built it up to a convenient general purpose programming environment. It is also tremendous fun trying to do so