IBM, BEA and JBoss adopting OSGi
Founded in 1999 by a number of vendors including Ericsson, IBM, Oracle and Sun Microsystems the OSGi Alliance manages and develops the OSGi specification. That specification is a component model that defines component packaging, life-cycle management and service registration for Java environments. Applications or components (coming in the form of bundles for deployment) can be remotely installed, started, stopped, updated and uninstalled without requiring a reboot. Life cycle management is done via APIs which allow for remote downloading of management policies. Initially focused on the mobile and embedded space, OSGi has been used in large desktop applications, most notably the Eclipse IDE, and a recently formed OSGi Enterprise Expert Group is looking to extend the OSGi specification to support the needs of Enterprise Java vendors and developers.
OSGi is already seeing adoption in the Java EE space as vendors look for ways to make their application server products more modular and flexible. IBM's WebSphere 6.1, for example, has been completely re-packaged as a set of OSGi bundles. The WebSphere application runtime classes are now loaded by a network of several class loaders since each OSGi bundle is loaded separately by its own class loader. These are connected to the extensions class loader (and to the rest of the class hierarchy) via an OSGi gateway class loader.
The Open Source Java EE application server JOnAS has undergone a similar OSGi based refactoring to WebSphere for its version 5 release. JOnAS itself is now implemented as a set of OSGi bundles, with technical services (EJB, Mail, etc.) implemented as OSGi services. The new server architecture allows new services to be added, and JOnAS provided services can also be replaced by alternative service implementations. Services can be started, stopped and re-configured at runtime.
Both BEA and JBoss look to be following a similar path. Back in 2006 BEA announced plans to revamp its middleware products around a new microService Architecture (mSA). The plan involves rebuilding the various products of WebLogic Server and BEA's other portal and middleware products using the OSGi standard. Two of BEA's key products - WebLogic Event Server and WebLogic Real Time Server are already using mSA, and the forthcoming WebLogic 10.3 release will also use the architecture. JBoss' R&D are working on an OSGi based class loader initially for the JBoss runtime (services) Ales Justin notes in an interview with Mark Newton. JBoss are also re-engineering their existing Microcontainer to integrate OSGi and have three employees as members of the OSGi Enterprise Expert Group.
Modularisation has clearly become a central theme for many JEE application server vendors even where, as in the case of the Sun backed GlassFish server, OSGi is not being used. Whilst these changes are largely invisible to developers they do signify a marked shift in the way in which vendors are thinking about their Java EE products. Enterprise Java developers and architects are likely to see some impact from OSGi before too long too since, Justin notes, the OSGi Enterprise Group is looking at OSGi support for key components of the Java EE specification including EJB, JSP and JSF.
Boss are also re-engineering their existing Microcomputer to integrate OSGi and have three employees as members of the OSGi Enterprise Expert Group.
I think that should be "Microcontainer" not "Microcomputer".
Thank you very much - I've fixed that typo.
Has Jboss already changed the kernel architecture into OSGi in AS5?
does that mean jboss has changed MC architecture?
Re: Has Jboss already changed the kernel architecture into OSGi in AS5?
Microcontainer is a complete rewrite of our kernel.
But we still support the legacy stuff (services as MBeans), as one of the component models in new MC.
If you mean if we had to change anything to adopt the OSGi in MC, then the answer is no. :-)
OK, there was a small change in how the new deployers interacted with MC, but all the rest, the core, has been left intact. Giving us nice confirmation that our architectural decisions were good.