OSGi is big news: the spec formerly known as the Open Services Gateway initiative has grown up and has the potential to change the deployment and runtime model for enterprise applications. By understanding system components, OSGi enables IT to publish services from one component to another and to install, uninstall, stop, start, refresh, and update components. OSGi began in the early 1990s as a lightweight framework for embedded applications and continues to see strong adoption in this space. But it's now breaking out and is well on its way to becoming the first component model that spans embedded, desktop, and server applications into a state-of-the-art core container for server-side enterprise Java.

OSGi facilitates better separation of application logic by forcing a separation of concerns within the application architecture. A separation of concerns is a concept in which large problems are broken down into smaller pieces, which are easier to manage. In service-oriented design, concerns are separated into services. In contrast, OSGi separates concerns into bundles comprising not just application code, but other resources that together can provide services and packages to other bundles. In Java, an OSGi bundle is distributed as a JAR file.

OSGi provides many benefits to application developers and IT admins alike. To the developer, enterprise application development for an OSGi platform isn't emphasized in terms of individual Web applications and portals. Rather, the focus is on defining a clean application programming interface and service provider interface for each component of a system. Enterprise applications can then be dynamically assembled using components that adhere to these contracts. To the administrator, OSGi provides a level of operational control not found in other enterprise runtime environments. For example, OSGi provides the ability to deploy multiple versions of the same bundle concurrently. The concept of versioning allows for a dynamic deployment model across the enterprise. This fills a longstanding void, not to mention is a way to manage the ever-growing complexity of software.

In addition to concurrent deployment of bundles, OSGi provides hot deployment--the ability to dynamically deploy, update, and undeploy bundles in running systems. In a production environment, hot deployment not only enables administrators to tweak app bundles without impacting users, it makes it possible to patch or incrementally install application bundles without having to redeploy the whole app. This flexibility is brought to you courtesy of OSGi's ability to dynamically discover and use services provided by other bundles in the system.

Note that OSGi reduces coupling among bundles and therefore can be thought of as a service platform. Viewing OSGi as only a service platform, however, confuses its architectural goals: In a service-oriented architecture, OSGi can be used as the underlying technology for a SOA platform, providing an extension mechanism, dependency resolution, and service registry capabilities. But SOA is designed for distributed and heterogeneous systems, whereas OSGi is best suited to services running on a homogeneous system. Think of OSGi as a deployment platform, programming model, and runtime environment with significant potential for improving enterprise and SOA applications alike.