Using OSGi as the core of a middleware platform
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.)