Page 2 of 3   « previous page   next page »

For example, a customer relationship management (CRM) solution would have modules such as sales, marketing, call center, and customer service. These modules use services exposed by other modules. To implement such a modular SOA pattern in Java-based enterprise systems there are often issues such as class conflict, unintended use of internal functions, interrupted upgrades, and multiple versions. Problems such as bundling, abstractions, dependencies, dynamic loading, lifecycle management, and side-by-side versioning are programmers' nightmares. Ideally containers should take care of these common issues, freeing application developers to solve the business problems.

Unfortunately many containers, including Enterprise JavaBeans (EJB), don't solve these issues satisfactorily. In this article, we'll explain how an Open Services Gateway initiative (OSGi) container would solve them. We'll begin with an introduction to the OSGi's solution to the problem, concepts, and platform, and then we'll delve into the evolution of the OSGi from its past in the world of embedded devices to its future in enterprise systems. We'll also explain the relationship between the OSGi and other initiatives, containers, and technologies to provide a comprehensive picture of the OSGi from the perspective of software development.

OSGi's Background
In March 1999, the OSGi Alliance was formed to provide a dynamic component model for service gateways to develop networked embedded systems.

The OSGi specifications developed provide a standardized, component-oriented platform for Java-based software. The platform solves the dynamic loading, versioning, and lifecycle management issues for Java-based services and also provides services to develop an ecosystem around it. In the last few years, OSGi has progressed far enough beyond embedded systems that its promoters are positioning it as universal middleware.

In retrospect, the use of "G" for "gateway" in the OSGi acronym is something of a misnomer. Universal middleware has a broader scope than just gateways, which are typically brokers on a network edge that provide interaction between external and internal networks. The use of the OSGi specification has broadened beyond embedded devices. This trend is noticeable in the alliance's supporting organizations too. Initially most of the supporting organizations were from the embedded space. Currently they've expanded to include major J2EE application vendors, ESB and middleware vendors.

Introduction to OSGi's Solution and Its Architecture
OSGi provides a component-oriented, lightweight container framework to host dynamically managed services. A module, called bundles in the OSGi, is a jar containing interfaces, their implementations, other classes, and a manifest. A bundle is a basic module for packaging, deploying, and managing the lifecycle of a group of services.

OSGi Bundles Provide an Isolation Model
Each OSGi bundle encapsulates packaged services and controls their visibility through metadata in a manifest file. As shown in Figure 1, a package or service in a module can be made available to other modules by explicitly exporting it. Other modules can't access any internal, non-exported interfaces or their implementations or other internal classes. In Figure 1, notice the import statements. Classes from other bundles can use these exported services by explicitly declaring imports.

OSGi Container Manages Lifecycle & Supports Dynamic Loading
Modules go through lifecycle events such as deploy (install), start, stop, redeploy, and uninstall. When a module (bundle) is being installed, the container checks all the dependencies (imports). If all the dependencies are satisfied, the module is ready to start. Figure 2 shows the lifecycle management of OSGi bundles. The OSGi runtime container provides a lightweight microkernel in which modules can be dynamically added or removed.

OSGi Natively Supports Dynamic Versioning of Services
During the long life span of enterprise software, business and technology changes. The software must reflect these changes and upgrade different modules independently of each other. For example, a company might have a customer data model (CDM) for its sales, order capture, and marketing systems. When there's an upgrade of the CDM, the company might choose to upgrade sales and marketing systems. However, upgrading the order capture system could have implications for business process or stability and so might not be upgraded at the same time, resulting in a need to support two versions of the CDM simultaneously.

The OSGi specification natively supports versioning with version attributes in the export and import instructions (see Figure 1) in the manifest files. It also provides additional control via arbitrary export/import attributes. The selection of an imported service or bundle is based on its version and attribute(s). OSGi also provides a unique isolation model in which multiple versions of the same service can co-exist and each service instance is isolated from the potential problems of class conflicts. A service consumer can get a reference to the correct version by specifying a version and other attributes in a filter as shown in Figure 3.

OSGi Provides a Service-Oriented Programming Model
OSGi also provides a programming model based on SOA. It's important to note that OSGi natively provides service-oriented programming in a dynamic environment. Unlike the RMI service registry, the OSGi service registry is native to the container - the services are automatically registered during the load without having to register them programmatically. A publisher can register a service using the registerService method in its BundleContext. Similarly, a service requester can discover a service using the getServiceReference method from its BundleContext. Unlike EJB or RMI, the services don't need to implement any remotable interface. It's all POJO!

OSGi Can Handle the Dynamic Lifecycle of Services
Again, in enterprise software you can add or remove modules. Since the container automatically manages the registration and deregistration, application programmers have to understand that services come and go at any time. OSGi provides a framework to track and react to lifecycle changes in the service, sending notifications of the registrations and deregistrations to a service layer that also provides a service tracker utility to help client programming in this dynamic environment (Figure 3). There's also a declarative model to handle lifecycle changes. Other containers like EJB/RMI don't handle such changes in lifecycle.

OSGi and Spring: Providing a Stable Proxy in a Dynamic Environment
The OSGi/Spring combination further enriches the solution to the dynamic lifecycle problem. Interface21 is already working to develop OSGi/Spring integration, and in March 2007 provided a first milestone drop for download. The current specification is version 0.7 and is still being evolved. The specification's stated goal is to provide an "easier path to build Spring applications that can be deployed in an OSGi execution environment and that can take advantage of the services offered by the OSGi framework."

The goal of the OSGi/Spring effort is to combine the best features of both OSGi and the Spring framework. This integrated framework inherits isolations and modularity, side-by-side versioning, dynamic deployment, and updates and dynamic discovery from OSGi. Spring provides an easy-to-use framework based on dependency injection (DI) and aspect-oriented programming (AOP), powered by various services.

Spring provides a simple, familiar programming model that enterprise developers can use to exploit the features of the OSGi platform. The OSGi/Spring combination also manages the switching of services in the background. Spring provides a stable proxy for services that can dynamically come and go. If a service in use needs a behind-the-scenes upgrade, the Spring-based proxy lets you to bring down the service and replace it without a glitch in the stateless environment. In stateful Web Services, clients must track the lifecycle of the target service. The OSGi/Spring combination provides a service binder framework to track and react to the binding and unbinding of the target services. The Spring framework provides a stable proxy in a dynamic environment, and the OSGi platform provides dynamic lifecycle and versioning.

Page 2 of 3   « previous page   next page »