WebSphere Application Server V8.5 Administration and Configuration Guide for the Full Profile

928 WebSphere Application Server V8.5 Administration and Configuration Guide for the Full Profile

Updates

Bundle and service lifecycles, along with the event notification support that OSGi defines

around them, gives developers the tools to build truly dynamic applications. However, even

with this support, it remains far from trivial to write code that can cope appropriately with a

truly dynamic environment on which services can come and go at any time.

The OSGi model allows you to perform live updates of the module during which time the

environment normally runs the applications. This method forces OSGi to cope with a bundle

that might disappear and then re-appear or be present and active more than once for some

interval. This method minimizes down time of server side applications but alternatively also

requires a good OSGi design.

26.1.3 OSGi Service

OSGi also introduces a service registry layer used for collaboration between bundles. An

OSGi service is published to the service registry under one or more Java interface names

with any optional metadata stored as custom properties.

Bundles publish services to the service registry, and other bundles can discover them by

looking up a service in the service registry. Bundles can filter service registry searches by

using the interface name and custom properties.

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.

Services are fully dynamic, and typically have the same lifecycle as the bundle that provides

them. Provider bundles can be stopped and started causing POJO services to be registered

and de-registered, independently of the lifecycle of the consuming bundles. However, bundles

can choose to publish and retract services dynamically due to changes in the environment,

for example, due to one required service going away or coming back.

26.2 Enterprise OSGi

OSGi was originally targeted to support Java Platform, Standard Edition, but Version 4.2 of

the OSGi specification introduces additional support for Java Platform, Enterprise Edition.

These extensions allow developers to write an OSGi enterprise application using methods

that are similar to writing Java EE applications. The following Java EE technologies are

integrated with the OSGi framework:

 Web Application Specification

Defines how to support the Servlet 3.0 and JSP 2.1 specifications in OSGi. Bundles that

are built on this support are called

web application bundles. Web application bundles must

be marked by the Web-ContextPath bundle manifest header.

For more information, refer to the following website:

http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was

-nd-dist&topic=ca_wab

 JNDI Services Specification

Defines how OSGi bundles can access javax.naming services and how JNDI can be used

to access the OSGi service registry.