These are my comments on this Caucho blog.
Eclipse - not a good OSGi example
Despite it's huge popularity Eclipse is far from being an archetypal example of OSGi usage. The main anti-OSGi feature of Eclipse is their decision not to use the OSGi service model. Instead they provide a complete replacement for OSGi services: the Extension Registry. As far as I know there are two reasons for this:
- Legacy code: the extension registry was well established when Eclipse moved to OSGi and it would be too costly to toss it out.
- Bootstrap time: Eclipse is a desktop app. It heavily relies on lazy class loading for improved startup times. The code OSGi service model requires the service implementation loaded before a service is exported. A major requirement of Eclipse is the ability to build the UI out of pure metadata and have the code loaded later. This can't be fulfilled using regular OSGi services.
The Eclipse extension registry is much more complex than the real OSGi service model, which is suitable for any app that does not have Eclipse's unique requirements. Also lately various runtimes have emerged on top of the OSGi service layer that allow the users to only load the service API at startup and postpone the loading of the implementation code until needed. Curiously the people from Eclipse seem to have played a significant role in the development of one of these runtimes - OSGi Declarative Services.
The OSGi dilemma
Generally speaking OSGi does not seem to tolerate gradual migration. You either embrace the high-isolation, service oriented model completely or suffer exploding complexity when trying for partial solutions. The problem here is that apparently any non-trivial Java app is organized around it's own specialized modularity (sharing classes), and service orientation (sharing instances) engines. This is especially true for infrastructural frameworks such as component runtimes and persistence managers. This transforms the migration to OSGi into a serious rewrite. As Eclipse shows if you are not satisfied with the OSGi service layer you can roll out your own relatively easily. The modularity however is the killer - you either let OSGi manage all the class loading for you or not use OSGi.
On top of it OSGi is a low level runtime core that merely enables these cool features but does not make it easy to use them. That is in fact a good design because to enable easy usage OSGi would need to specialize in a certain component/application model. The good new is that this modular core can easily be extended with multiple "opinionated" component runtimes. That is exactly what Spring Source are frantically coding right now. The even better news is that all of these component/application runtimes can interoperate transparently through the OSGi core.
Right now OSGi is hovering on the edge of being ready for prime-time. Many of the conveniences an enterprise developer is used to are yet to appear. So we have a double whammy:
- Gradual migration of critical infrastructure is costly because it is either the best possible re-design: strong modularity, strong componentization or nothing.
- This raises the entry cost for new applications and hinders the migration of existing ones.
I think this lack critical mass is the usual dilemma of any game-changing technology.
Join the fun
At the same time the core features of OSGi: strong modularity, service orientation and dynamics, are so compelling that OSGi evolution is rapidly driven by demand. For exmaple currently there are at least four frameworks that allow the writing of POJO applications on top of the OSGi service layer. Also the major enterprise infrastructures are being overhauled to work on OSGi. This is in fact the major focus of the due to be released OSGi 4.2 specification. The field is wide-open! There is no more exciting time to work on OSGi based infrastructure than right now when the future is being shaped.
As for the normal application developers who don't want to risk early adoption - they need to wait until the OSGi environment is properly set up for them. But be prepared. OSGi or something like it is inevitable in the near future.
Posts
8 comments:
I disagree a bit. I think Eclipse is a great example of what you can do with OSGi. The extension registry itself is exposed as an OSGi service... and built upon the service layer... just like things like DS. The extension registry was available before Eclipse really moved to OSGi, so there is some legacy there.
In the end, I think Eclipse demonstrates the power of OSGi and modularity. The Eclipse SDK evolves and maintains backward compatibility due to the power of OSGi.
I think Caucho's main problem was that modular architectures aren't easy... especially when you come from a world that didn't have them before. Also, your point of "you either let OSGi manage all the class loading for you or not use OSGi" is very important and people coming from legacy backgrounds usually get bit with this problem.
Oh well, in the end it's fun to see people finally discussing OSGi ;)
As the first official commenter on my blog you deserve a response :)
To be completely honest I did scorn Eclipse a bit too much. The main reason being to point out that life is simpler with the classical OSGi services. People using Eclipse as their introduction to OSGi confuse the complexity of Eclipse architecture with complexity within OSGi itself.
As for the Eclipse registry: as far as I know although it is maintained by a bundle Eclipse extensions and OSGi services can not interoperate. One way to transparently mix extensions and services appeared quite recently:
http://code.google.com/p/peaberry/wiki/EclipseRegistry
Otherwise I was thoroughly amazed when I discovered what was going on with Eclipse. Now I look at the active part of the bundle lifecycle: starting->active->stopping as "the extender realm". The OSGi service layer itself can be viewed simply as the default/bootstrap extender. I have plans to blog about this some day.
Having used OSGI in a few web projects, I can certainly say that getting started with OSGI is certainly a pain. This is especially true when you mix frameworks (like Hibernate) that needs requires looking up classes from configurations.
The web support (atleast two years ago when I started using it) is/was certainly lacking as Spring DM for OSGI doesn't support (out of the box) commercial (atleast Weblogic) WASes.
Still, I think it's worth the effort because once you set it all up (atleast with Spring DM for OSGI for us), there really isn't too much interfacing with OSGI anyways, but you still get the nice modular infrastructure.
Wer'e building a framework which is OSGi-ready from scratch: http://nibiru.googlecode.com
:)
Post a Comment