Live News, Features and Article Updates Covering Oracle Technologies

Oracle on Ulitzer

Subscribe to Oracle on Ulitzer: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Oracle on Ulitzer: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Oracle Authors: Elizabeth White, Yakov Fain, Liz McMillan, Pat Romanski, Carmen Gonzalez

Related Topics: Java EE Journal, Oracle Journal, Apache Web Server Journal, OSGi, SOA & WOA Magazine

J2EE Journal: Article

Universal Middleware: What's Happening With OSGi and Why You Should Care

Containers - Is It Time for Another One?

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.

More Stories By Dave Chappell

David Chappell is vice president and chief technologist for SOA at Oracle Corporation, and is driving the vision for Oracle’s SOA on App Grid initiative.

More Stories By Khanderao Kand

Khanderao Kand is a Lead Architect for Oracle Fusion Middleware at Oracle Corp. He is involved in the development of Oracle’s SOA Suite covering various Integration and BPM technologies including BPEL and ESB. He also provides Architectural consultancy for Oracle’s next generation Fusion Applications to architect their solutions around SOA and BPM. He has been involved in the development of various industry standards like BPEL 2.0, SCA-Assembly, SCA-BPEL etc. In his two decades of Software Development experience, he played various roles like an Enterprise Architect of Peopletools, an architect in CRM and others. Being a code slinger, he plays around with various emerging tools and technologies. Occasionally he writes in technical magazines like Java Developers Journal, Web Services Journal, SOA World etc. He also speaks at various conferences like Oracle Open World, JAX Conference, and Software Development Best Practices.

Comments (2) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
Costin Leau 02/03/08 06:23:49 AM EST

It's worth mentioning that Spring Dynamic Modules for OSGi Service Platforms (or the Spring OSGi integration in short), had its 1.0 final release, after 3 milestones and 3 release candidates, on January 25th, 2008.

The official announcement can be found at: http://www.springsource.com/web/guest/2008/spring-dm-intro

Richard Nicholson 02/03/08 04:45:32 AM EST

Those interested in a commercial distributed runtime, built from the ground up using OSGi R4 and SCA, may be interested in the Infiniflow Service Fabric - see www.paremus.com, or its open source relation newton.codecauldron.org.

In addition to having leveraged these important industry developments for the last 18 months, Infiniflow, described by analysts as a Cloud OS or virtual application server, augments these with industry unique self-managing, self-scaling behaviors, and with transparent runtime support for Spring Dynamic Modules.