Using OSGi as the core of a middleware platform
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:
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)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.
The result - the best of both worlds - ease of use for developers and great middleware.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Tags:
Comments
Kristian Rink replied on Fri, 2010/11/26 - 3:36pm
Paul,
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...