I think the Java developers (especially server side developers) have started looking at OSGi as the next-generation Java Middleware technology. This may not come as a surprise because of the adoption of OSGi by the JEE server vendors and Java (server, desktop and embedded Java) community in general.
OSGi technology:
- Enforces better componentization (separation of concerns) than most existing techniques in JEE (Using one classloader per bundle).
- Provides versioning of components and the ability to deploy multiple versions of the same components in the same VM, unlike JEE.
- Unless you use one ”component” for your entire application/product, OSGi enforces SOA for components using dynamic services (or “Extensions”/”Extension points” for those wanting to use the old Eclipse standard).
- Enforces loose coupling of components (using a publish/find/bind service model).
- Forces the resolution of application dependency problems (requiring explicit declaration of dependencies between components).
- OSGi ”fixes” Application server hot-deployment functionality (ability to deploy/undeploy software components without requiring the Server/JVM).
- There are multiple opensource OSGi implementations available:
- OSGi implementations are quite stable with many applications/servers using or running on them.
- Ricoh has been shipping Printers with OSGi since 2005.
- BMW 5 series cars ship with OSGi.
- JBoss, IBM WAS and BEA Weblogic servers are adopting OSGi.
- Sun’s Glassfish uses OSGi
- SpringSource dm server is built on top of OSGi.
- Mule ESB
- The OSGi implementations generally have a small footprint (With OSGi Jars that are less than 500 kb).
- OSGi has proven itself in the embedded and desktop application world too. The open source Eclipse IDE has been based on OSGi since 2004.
