In-Depth

The OSGi Approach to Component Integration

Eclipse's plug-in model is based on an initiative that heralds a general-purpose alternative to application integration.

• By Peter Varhol
• May 3, 2007

Integrating different applications and application components has a long, and decidedly mixed, history. After years of creating one-off integrations that were complex and fragile, many software companies began supporting CORBA (Common Object Request Broker Architecture). CORBA offered a common, language-specific, object-oriented API that could be incorporated into applications to provide data connectivity.

To compete with COBRA, Microsoft offered similar technologies for the Windows platform. Microsoft's most competitive technology was COM (Component Object Model). Its extensions included COM+ and DCOM (Distributed Component Object Model), which was designed to work across distributed systems. COM let you create objects that consist of data and logic, and enable those objects to interact with each other or with other applications. COM technologies were used heavily by Microsoft developers, in part, because it was one of the only ways to write applications without a user interface.

But, both of the CORBA and COM approaches had (and still have) significant problems and limitations. Complexity is a big issue. Any of the data that is passed requires very specific formatting, and many of the rules for programming are simply too difficult to follow without encountering errors. Even at the height of their popularity, CORBA was used primarily in large system development staffed by legions of programmers, while COM was used, often reluctantly, by teams of Microsoft developers.

Today, integrating existing code, or writing new code that has to integrate with existing code, is still a large part of software developers' workload. Web services — arguably the biggest software architecture trend in the past five years — are meant to define a loosely-coupled set of interfaces, driven by XML and SOAP (Simple Object Access Protocol), that connect applications and application components. While an improvement over its more tightly-coupled predecessors, Web service interfaces are still fragile and difficult to work with.

Enter the Open Services Gateway initiative (OSGi). OSGi provides a Java-based platform for integrating both Java and non-Java application components. This technology provides the standardized functions for constructing applications from small, individual components and deploying them as a single application.

The core component of OSGi is the OSGi Framework. The OSGi Framework is a very specific class-loading model. In addition to its normal Java execution environment, this framework incorporates an OSGi modules layer that adds private classes for modules and allows for controlled linking between modules. The OSGi Framework also includes life-cycle management for starting, stopping, adding and removing modules, as well as a service registry for sharing objects between modules.

OSGi interfaces enable users to add components to an application, as long as the components conform to the interface provided. For some standard functions and technologies (such as HTTP servers, configuration, logging, security, user administration and XML), OSGi offers pre-built interfaces. These standard interfaces enable software components to connect directly into the OSGi Framework and communicate with other components.

Synergy Between OSGi and Eclipse
The Eclipse platform uses OSGi as the heart of its plug-in architecture. To add a plug-in to the Eclipse platform, you simply drop a module into the appropriate subdirectory under the Eclipse directory tree. Most Eclipse components beyond the base platform (primarily the Rich Client Platform, or RCP) rely on the OSGi-based plug-in architecture to add their capabilities.

To create an Eclipse plug-in, you write the functionality as you would for a standalone application — and, more importantly, you can write your functionality in any language. Ultimately, you have to interface your code with one or more Java packages, so writing code in Java may simplify the development process. But if writing in Java isn't an option, you can use well-known methods (such as Remote Method Invocation) to interface other kinds of code with Java packages.

In addition, the functionality in a plug-in is almost entirely logic, without data (unless data access and manipulation is an important part of that code) and without user interface. From an abstract view, it resembles a simpler Windows COM component.

The Eclipse platform, usually the RCP, provides you with the user interface for creating a plug-in. After writing the functionality, you must write an adapter to connect the plug-in to the RCP. This code, typically written in Java, defines the menus and menu content posted into the RCP, establishes data transfer parameters, and provides access to a number of OSGi services. These services include permissions, package administration, user administration, logging, configuration and event administration. Eclipse documentation and several trade books indicate how you can use these services (and, in general, how to write an Eclipse plug-in).

While it is not a perfect model, OSGi enables the Eclipse platform to be extremely customizable. It also enables you to easily build plug-ins based on other developers' work. However, OSGi's simplification of the customization and plug-in building processes has a downside. By building on specific versions of other plug-ins, you risk creating a complex dependency chain among plug-ins — a dependency chain that makes Windows DLL hell look like a compelling alternative.

The Eclipse Foundation addresses this shortcoming by shipping new versions of the RCP and its core plug-ins simultaneously each year. These synchronized releases are named after the moons of Jupiter, with the Castillo release in 2006 and the Europa release happening later this year. This approach provides a more stable platform for building new plug-ins that have dependencies on the Eclipse code.

Goals of the OSGi Alliance
The OSGi Alliance was founded in 1999 by a consortium of technology companies with a common need to develop interfaces between shared application components. This consortium advances proven and mature processes that promote interoperability of applications and services based on its component integration platform. While OSGi is best known within the Eclipse community, it is also used in other development environments for connecting components to unique application configurations. Specifically, the OSGi Framework is used by vendors (such as Cisco, Siemens and Ricoh) for software solutions across the enterprise. It is also used by companies in embedded systems, mobile computing, telematics and smart home systems.

OSGi technology benefits the software industry in many ways. Perhaps its most significant contribution is that it establishes Java as a language of integration. Both CORBA and COM used C and C++ to achieve their goals. While these languages are flexible, their characteristics introduced some of the complexity inherent in the CORBA and COM technologies. In contrast, OSGi's Java-based integration provides the portability required to support products on many different platforms.

OSGi technology also offers hope for a broader integration solution. Web services, a more universal integration strategy than OSGi, address one class of problems, where loose coupling is important for distance, technology or security, and performance is not an issue. OSGi is well on its way toward filling the industry need for a way to more simply provide sophisticated performance integration based on a shared platform.