Paul Fremantle is CTO at WSO2, where he leads the technical team in the most dynamic Open Source Middleware company. He has been the chair of the WSRX TC at OASIS and he is VP of Apache Synapse at the Apache Software Foundation. Paul has co-authored two books on XML and Web Services and is a regular speaker at conferences. Previously Paul was a Senior Technical Staff Member at IBM where he led development of the IBM Web Services Gateway. In his spare time Paul plays traditional music on the tin whistle. Paul is a DZone MVB and is not an employee of DZone and has posted 15 posts at DZone. You can read more from them at their website. View Full User Profile

Using OSGi as the core of a middleware platform

  • submit to reddit
Ross Mason of Mulesoft recently blogged: "OSGi - no thanks". Ross is a smart guy and he usually has something interesting to say. In this case, I think Ross has made a lot of good points:

1. Ross is right - OSGi is a great technology for middleware vendors.
2. Ross is right - Developers shouldn't be forced to mess with OSGi.
3. Ross is wrong - You can make both of these work together.

At WSO2 we went through exactly the same issues. We simply came to a different conclusion - that we can provide the benefits of OSGi (modularity, pluggability, dynamic loading) without giving pain to end-users. In WSO2 Carbon, customers can deploy their systems in exactly the same way that worked pre-OSGi.

Why did we choose OSGi? We also looked at building our own dynamic loading schemes. In fact, we've had dynamic classloading capabilities in our platform from day one. The reasons we went with OSGi are:
  • A structured and versioned approach to dynamic classloading
  • An industry standard approach - hence better understood, better skills, better resources
  • It solves more than just dynamic loading: as well as providing versions and dynamic loading, it also really gives proper modularity - which means hiding classes as much as exposing classes.
  • It provides (through Equinox p2) a proper provisioning model.
It wasn't easy. We struggled with OSGi to start with, but in the end we have a much stronger solution than if we had built our own. And we have done some great improvements. Our new Carbon Studio tooling gives a simple model to build complete end-to-end applications and hides OSGi completely from the end-user. The web admin consoles and deployment models allow complete deployment with zero OSGi. Drop a JAR in and we take care of the OSGi bundling for you.

The result - the best of both worlds - ease of use for developers and great middleware.
Published at DZone with permission of Paul Fremantle, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Kristian Rink replied on Fri, 2010/11/26 - 3:36pm


would you mind providing a few pointers or hints regarding the overall architecture of an application used on top of this platform? I am asking out of curiosity because, at the moment, we are working at providing our customers with a new end-user interface built on top of Eclipse RAP (web) and RCP (internal), so far trying to figure out what is the best infrastructure and technology environment for implementing "backend" functionality, server-sided business logic and so forth. We thought about a system being "all-OSGi" front to end, but so far I have no clue about whether or not this would work out in the end, and whether or how OSGi is up for supporting such an application structure yet, talking about server-sided OSGi to start with. But I am not sure whether this is the use case your platform is trying to address...

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.