The Mule team have blogged about their decision not to adopt OSGi. The decision seems reasonable: OSGi isn't a panacea and I guess the benefits didn't outweigh the costs in their case.
One of their number, Ross Mason, correctly identifies some of the costs of adopting OSGi. He would like OSGi to be almost completely invisible to the developer, leaving him or her free to define an application in terms of modules without dealing directly with manifests, bundles, and build systems. The somewhat messy details of developing and building modular applications with OSGi are partly what led SpringSource to donate the dm Server project to Eclipse as Virgo. The aim is to grow the user community and smooth out the wrinkles in the developer experience.
Adoption is going pretty well. Virgo recently shipped its first release. SAP are adopting Virgo in a strategic way. VMware products in development are using dm Server/Virgo to obtain the benefits of modular application code. Others are using dm Server/Virgo to host substantial applications in sectors including investment banking, networking, healthcare, online gaming, and academic research.
As we prepare to donate the Virgo tooling to Eclipse and collaborate in the OSGi Enterprise Tools project inside Eclipse with the likes of SAP, EclipseSource, and Eteration, I'm optimistic about improving the developer experience.
Dissenting voices such as those of the Mule team are a good reality check. Efforts, such as Mule, to try to find intermediate modularity solutions with some of the benefits of OSGi but with smaller costs should also help by providing data points for comparison with full blown OSGi adoption.
I'm looking forward to more experience reports from application development groups that have adopted OSGi or technologies like Mule so others can make a more informed decision about the technology to adopt. Certainly OSGi users are starting to publish their experience. Perhaps users of Mule will soon do the same.
I was surprised to know that Spring Roo is using Apache Felix as its OSGi container. Do you know why?
ReplyDeleteHi,
ReplyDeleteI work for a company which has strong demand on modularity and extensibility. We have RCP client communicating with a traditionnal J2EE server. The added value of OSGi in our case is obvious : It enforces us to design properly our module with API and Impl, It enforces to deal with backward compatibility, It enforces to work by version range (by default). In other words : It helps us to design clean and perennial modules. This is very good for a middle/long term perspective.
In the same time, we have a loose coupling between modules (through RCP extension points). On the client side, the integration is straightforward, but the server (J2EE) side a much more tricky : we have to make several wars to reproduce modularity, we have to manage by hand the jars embedded with the webapps. I 'm eager to use OSGi on the server side too, without a doubt this will ease our job. I hope we'll have p2 provisionning on the both side. I'm even more eager to use the "OSGi Enterprise Tools" too.
Pascal Leclercq
Hi,
ReplyDeleteI work for a company which has strong demand on modularity and extensibility. We have RCP client communicating with a traditionnal J2EE server. The added value of OSGi in our case is obvious : It enforces us to design properly our module with API and Impl, It enforces to deal with backward compatibility, It enforces to work by version range (by default). In other words : It helps us to design clean and perennial modules. This is very good for a middle/long term perspective.
In the same time, we have a loose coupling between modules (through RCP extension points). On the client side, the integration is straightforward, but the server (J2EE) side a much more tricky : we have to make several wars to reproduce modularity, we have to manage by hand the jars embedded with the webapps. I 'm eager to use OSGi on the server side too, without a doubt this will ease our job. I hope we'll have p2 provisionning on the both side. I'm even more eager to use the "OSGi Enterprise Tools" too.
@Igor, Spring Roo uses Apache Felix as its OSGi container for quite a few reasons, but the critical factor that determined it for us was licensing. Felix is ASLv2, which makes it easy to redistribute with non-EPL open source software.
ReplyDeleteBest regards
Ben Alex
Project Lead, Spring Roo