Tech Road Map: OSGi Spreads Its Wings

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.

MOVABLE PAST

OSGi's target platform was originally mobile or embedded systems, but today OSGi is being used for enterprise applications. Is it right for you? Two main requirements for enterprise OSGi are distributed computing support and multilanguage compatibility. Although the OSGi specification is not bound to a specific programming language, Java is the preferred implementation choice. OSGi, however, isn't Sun Microsystems' preferred solution for Java modularity. Rather, Sun backs its own Java Specification Request (JSR) 277: Java Module System, which appears to significantly overlap OSGi. While there's no official statement to this effect from Sun, it appears the company is leaning in the direction of building overlapping technology rather than adopting and improving on OSGi. Sun voted against JSR 291, which is simply a reference to the OSGi core specification version R4.1, but the specification request still passed--an indication that there's significant momentum here.

While OSGi is growing in popularity, the buzz is still relatively quiet. But whether or not Sun changes its view, as OSGi begins to support basic enterprise IT requirements, we expect its popularity to grow. That's because OSGi fills an important void in enterprise software and offers to IT significant benefits that aren't available in other technologies. While mainstream adoption of OSGi may be a few years out, its momentum cannot be denied. There's much potential for the use of OSGi in the enterprise to build an ecosystem around runtimes, much the way its use in the Eclipse platform built an ecosystem around development tools.

TOTAL ECLIPSE: A HISTORYIn 2003, the Eclipse Foundation began searching for a way to better modularize its Eclipse open development platform. The Eclipse Foundation converged on OSGi and decided to use it as the run-time component model for its Eclipse 3.0 release. The Eclipse Foundation developed an implementation of the OSGi R4 core framework specification, code-named Equinox. When Eclipse 3.0 was released in June 2004, OSGi became the platform on which thousands of developers would launch software. Incidentally, an ecosystem around development tools was formed. The adoption of OSGi by Eclipse was a significant milestone--it placed OSGi on many software vendors' radar.

Today, OSGi has become the platform of choice for many software vendors. The majority of Java Enterprise Edition application servers support or plan to support the technology, for example. In addition, many open source initiatives have already begun to integrate OSGi into their server-side frameworks. This trend certainly will facilitate adoption of OSGi in the enterprise. For the first time, we might have one software component model that allows for the convergence of embedded, desktop, and enterprise software development. It's about time.

Erik Pieczkowski is an InformationWeek and NWC.com contributing editor and an enterprise architect with Synegen. His architecture experience ranges from the design and development of high-performing, message-driven systems to building and deploying scalable SOAs. Write to him at [email protected]