OSGi Architecture & Services
Now that you understand OSGi's capabilities, it would make sense to understand its architecture. The OSGi platform provides core framework and platform services. The core framework provides a runtime foundation to run and manage the lifecycle of various applications in a secured and modularized environment. The framework has four layers: security, modularization, lifecycle, and service.

The security layer provides additions to Java security that restrict the public and private exposure of packages and services and also provides permissions to import/export packages and register/access services from the service registry.
The modularization layer handles class loading, versioning, and the import/export of packages. It also manages the dependency resolutions of bundles.

The lifecycle layer manages the lifecycle of bundles and provides a generic API abstraction to enable remote management in a variety of management models.

The service layer adds a dynamic behavior to the OSGi platform in which bundles can come and go. The heart of this layer is a service registry in which services are registered and discovered. The framework handles automatic registration and deregistration and triggers lifecycle events. OSGi further provides a declarative model to express service registrations and dependencies in an XML declaration. This declarative framework supports lazy (delayed) loading of resources by loading them only when they're actually needed.

The OSGi ecosystem platform provides various service interfaces that can be implemented by vendors, depending on the nature of their applications. The OSGi framework may provide a permission admin service, conditional permission admin service, a package admin service, and URL handler service. The OSGi Alliance specifies various system services such as a log service, and administrative services for managing configuration, event administration, users, devices, and applications. The Alliance has also defined an HTTP service so that bundles can provide servlets that can be made available over HTTP. Besides declaration and event services, in release 4, the Alliance defined a wire admin service to manage configuration-based connectivity between a service producer and consumers, enabling data objects to be exchanged over a wire. (Figure 4)

Recent Momentum
Those who are using the Eclipse 3.0 framework are already using OSGi indirectly. When Eclipse-based applications became more complex, Eclipse needed an appropriate framework that could provide a dynamic, modular, and flexible runtime. The Eclipse group found that the OSGi framework satisfied most of their requirements. The Eclipse 3.0+ plug-in framework is based on OSGi. Eclipse's use of OSGi is now being evolved as the Equinox project.

Eclipse's use of OSGi caught the attention of the developer community. Besides Eclipse, there are currently many other open source projects such as Apache's Felix, Newton, Knopflerfish, and OXSA. These open source implementations provide a meaningful way for developers and researchers to adapt the platform. Extensive adoption made 2007 a good year for OSGi. IBM and Cisco announced plans to develop a unified communications and collaboration platform called UC2 based on OSGi. And early last year Spring made its first milestone drop available to the public. Most of the leading application server vendors such as Oracle, IBM, and BEA either have an OSGi container in their stacks already or are working to add it.

With Eclipse, application servers, and other open source projects, OSGi has entered the mainstream to solve the modularization problems (dynamic modular deployment, versioning, and so on) of Java applications. The next step in its evolution is to provide interconnectivity for OSGi servers hosting services that can be moved from one server to another.

Future Evolution of OSGi Distributed OSGi:
A Journey Towards Universal Middleware
The OSGi specification has, by and large, assumed an environment constrained to a single Java virtual machine (JVM) in that its service repository is referenced as local in-memory objects and the bundles are loaded and accessed via direct references in the same JVM. To be universal middleware, OSGi has to tackle the issues related to distributed computing, which it has started to do. There are a few key issues: How does one discover services on the network? And how can one invoke them?

To address the service discovery and remote services issues, OSGi's R3 specification included recommendations to use Jini and universal plug and play (UPnP). Recently, during the Eclipse 2007 conference, a third approach called R-OSGi was introduced. It's based on a discovery protocol called the service location protocol (SLP), a lightweight, decentralized, extensible protocol (see Figure 5).

However, each option has its own set of issues. The issues are mainly incompatibility between the remote service interfaces - Jini attributes don't match with OSGi, and Jini's reference implementation is based on the RMI invocation framework, which is perceived to be too heavy for OSGi devices. UPnP has a separate set of issues. Although UPnP is still recommended in OSGi R4, Jini is thrown out apparently because of issues such as interactions between class loaders and incompatibilities between security models. Although Jini didn't see a lot of momentum and releases, the specification provided a robust platform for some applications, including financial applications. Moreover, there's an open source initiative called Newton, and its commercial product, Infiniflow, which supports OSGi and Jini. Last year, after Sun open sourced its reference implementation, we expected some momentum, but it hasn't materialized.

The R-OSGi prototype uses SLP as a discovery protocol and provides a framework for service invocation based on dynamically generated proxies. R-OSGi also provides a way to define abstract proxies. During an R-OSGi demo, we observed that it has a very small footprint, but it needs some effort to make it robust. Moreover, the R-OSGi's service invocation protocol is optimized but proprietary. A standards-based approach would have been preferable. It seems that R-OSGi doesn't use RMI for performance reasons and issues related to RMI's distributed garbage collection when working with the OSGi lifecycle.

Service discovery and remote invocation doesn't provide complete distributed functionalities to OSGi. A new enterprise expert group was formed inside OSGi to look into the issues of taking OSGi to the enterprise level. The group has proposed works in areas of distributed registry, interaction with external systems, enterprise Web applications, and OSGi with J2EE, SCA, Spring, and so on. However, instead of charting yet-another new course, we believe the OSGi should reuse the appropriately relevant work already done in the J2EE and WS arenas.

OSGi & SCA: A Possible Alliance
Service Component Architecture (SCA) provides an assembly model for building composite applications using services implemented in a variety of technologies. SCA already has support from the major application servers and enterprise service bus (ESB) vendors. The SCA specification has been submitted to OASIS for standardization. Now work can be initiated for an integration plan for SCA and OSGi.

Conceptually both SCA and OSGi provide a composite model for assembling a services-based composite application that can expose some services to the external world as well as invoke external services. In OSGi R4, declarative services define a model to declare a component in XML, capturing its implementation and references. Besides SCA-like component-level information, the OSGi model captures additional information to control runtime behavior. For example, R4 provides bind/unbind methods to track the lifecycle or manage target services dynamically. SCA metadata defines wires between components or from a component to a reference in its composite model. However, SCA doesn't dictate a runtime implementation. OSGi defines wires in a composite model but lets the administrator add and delete wires using wire admin services (see Figure 6).

For OSGi-SCA integration, there are three possible scenarios:

  •   OSGi is a container for the SCA runtime
  •   OSGi and SCA are peers that can import and export each other's services
  •   OSGi as yet-another implementation type of SCA service

Where Do We Go from Here?
We'd like to see OSGi evolve, specifically in the enterprise market. It has definite uses as a microkernel in application servers. Other uses may evolve - service platforms are leveraging powerful combinations of two or more frameworks, such as OSGi, SCA, and Spring. OSGi would be useful for building SOA and enterprise applications, expanding OSGi's applications beyond embedded and network devices and microkernel and application servers. Some ESB vendors would find OSGi's dynamic services capability useful too. Different technologies working together with the OSGi could make a powerful platform to build large, complex enterprise applications.