OSGi defines a dynamic module system for Java. The OSGi service platform has a layered architecture, and is designed to run on a variety of standard Java profiles.
OSGi Applications deployed to WebSphere® Application Server run on an Enterprise Java profile that is provided as part of the server runtime environment. This environment also provides the OSGi framework in which OSGi Applications run. Eclipse Equinox is the reference implementation of the OSGi Service Platform Release 4 Version 4.2 Enterprise Specification, and WebSphere Application Server uses Equinox as the framework for OSGi Applications. The precise version of Equinox depends on the service level of WebSphere Application Server.
The unit of deployment in OSGi is a bundle. The modules layer is where the OSGi Framework processes the modular aspects of a bundle. The metadata that enables the OSGi Framework to do this is provided in a bundle manifest file. For more information about this file, see Example: OSGi bundle manifest file.
The bundle life-cycle management layer in OSGi enables bundles to be dynamically installed, started, stopped, and uninstalled, independent from the life cycle of the application server. The life-cycle layer ensures that bundles are started only if all their dependencies are resolved, reducing the occurrence of ClassNotFoundException exceptions at run time. If there are unresolved dependencies, the OSGi Framework reports these and does not start the bundle.
Each bundle can provide a bundle activator class, which is identified in the bundle manifest, that the framework calls on start and stop events. In this way, a bundle can provide special initialization and cleanup code if required, although most OSGi applications that are deployed to WebSphere Application Server should not need to do so. If a bundle needs a template bundle activator, you can use IBM® Rational® Application Developer Version 8 to generate one.
The services layer in OSGi intrinsically supports a service orientated architecture through its non-durable service registry component. Bundles publish services to the service registry, and other bundles can discover these services from the service registry.
These services are the primary means of collaboration between bundles. An OSGi service is a Plain Old Java Object (POJO), published to the service registry under one or more Java interface names, with optional metadata stored as custom properties (name/value pairs). A discovering bundle can look up a service in the service registry by an interface name, and can potentially filter the services that are being looked up based on the custom properties.
Services are fully dynamic, and typically have the same lifecycle as the bundle that provides them. OSGi Applications in WebSphere Application Server usually interact with the OSGi service registry through a Blueprint module definition. POJO bean components that are described in the Blueprint module definition can be registered as services through a <service> element, or can have service references injected into them through a <reference> element.