The Open Services Gateway initiative (OSGi) is a component model for Java that defines a standard method to manage standalone Java applications. Users of the Java EE specification understand the benefit of a standard model for the deployment, restart, and upgrade of enterprise applications. However, until the OSGi was formed, this was missing for Java SE applications. The OSGi Alliance, which is comprised of a group of software vendors, such as Ericsson, IBM, Sun, Oracle, and many others, are responsible for its ongoing definition. Take a look at osgi.org/About/Members for a full list.
One of the most popular OSGi-compliant software packages available is Eclipse. The component model is used for the Eclipse plug-in implementation, and provides a standard model for developers to build new Eclipse extensions. OSGi also allows Eclipse to be dynamically updated via software downloads. Further, OSGi defines a software lifecycle model, a registry to post and locate new modules, and a security model.
iPronto
Other products based on OSGi incude Philips' iPronto device, which is meant for home audio, video, and security automation (see http://www.pronto.philips.com). This neat wireless device comes with a 6.4" LCD screen, lots of connectivity options, and is based on Linux, Java, and the OSGi component model. In fact, iPronto is part of the Pronto is a family of products that includes control panels, receivers, handsets for the home, and remote controls. OSGi allows the software on the devices to be extended through a standard plug-in model, opening the door to third-party software, and a potential ecosystem around Pronto.
SpringSource
A new entry in the OSGi mix is SpringSource, which has released its SpringSource dm Server. It's a completely modular OSGi-based Java application server (not Java EE applications server), built with Tomcat and the Spring Framework, to deploy Spring applications on (see http://www.springsource.com/products/suite/dmserver). With OSGi, dm Server offers a standalone component model and management system without committing to the entire, bloated, Java EE specification. With OSGi, there's also better support for dynamic application updates to running servers, which don't require the restart of the running systems. This creates a more stress-free upgrade path for organizations that need to offer 24x7 application uptime.
Perhaps the biggest productivity gain is that it also makes development and debugging easier, as it integrates with development environments, and doesn't require the constant shutdown, copy, startup and wait, debug cycles that Java EE-based development does.
Following a period of time of slow growth, OSGi appears to be taking off. I'm sure you'll increasingly find this Java component model used in software products across the Java ecosystem.
Happy coding!
-EJB
