OSGi Service Adaptor for UIMA Framework
The general architecture of the OSGi Service Adaptor layer for UIMA Framework is similar to the one depicted in Figure 2, where the Java application framework is represented by the UIMA Framework, and the 3rd party components are, actually, UIMA analytic components. As we described earlier in the section 4, the Adaptor adds the services layer to each UIMA analytic component, so that each component registers itself as an OSGi service in the OSGi registry (see Figure 5). We call this operation publishing of UIMA analytic components. Applications find components as services via the adaptor API, and get the UIMA analytic component descriptor and the component bundle class loader, which are necessary for running the analytic in the UIMA Framework. The rest of the control flow is similar to the basic control flow shown in the Figure 4.

This section describes the implementation of the OSGi Service Adaptor for UIMA Framework in more details. The Adaptor is responsible for:
a)  Allowing UIMA applications to manage OSGi bundles encapsulating analytics and other resources. The management capabilities include locating UIMA component bundles and loading them into the OSGi container to make them available for deployment by UIMA Framework. This mechanism is based on the OSGi Framework API.
b)  Providing UIMA applications with easy access to shared resources of UIMA component bundles in order to deploy and use them in UIMA Framework. The shared resources include component descriptors, component class space, metadata and others. This mechanism is based on the OSGi services registered by each analytic component bundle, as detailed further in this section.

Each UIMA analytic component bundle registers its OSGi services including the component reference service and one additional service for each its public component descriptor. UIMA analytic components that register their OSGi service objects are active components, as opposed to inactive components, like type systems or other resource bundles. The OSGi Service Adaptor API provides dynamic access to registered UIMA component services through the OSGi Service Registry.

Figure 5. Basic control flow of a UIMA application in OSGi environment

Logically, the OSGi Service Adaptor comprises the following functional elements:
A.  UIMA Services Integrator - responsible for tracking all standard Adaptor services and notifying applications of UIMA service availability events. This module also provides convenient access to all standard Adaptor services.
B.  UIMA Configurator - responsible for managing UIMA component bundles and notifying applications of UIMA component life cycle events.
C.  UIMA Component Services - responsible for providing access to shared resources of UIMA component bundles, loaded into the OSGi container.
D.  UIMA Component Registry - responsible for looking-up UIMA component bundles loaded into the OSGi container.

UIMA Services Integrator monitors all standard Adaptor services by using the OSGi ServiceTracker capabilities and makes its own OSGi service available only when all other standard Adaptor services are available. The Integrator also monitors its own OSGi service and notifies subscribed applications of the UIMA service availability events.

UIMA Configurator combines several functions:
a)  discovering new UIMA component bundle files in the designated directory;
b)  installing UIMA component bundles in the OSGi container upon application request;
c)  automatically activating UIMA components installed in the OSGi container;
d)  monitoring UIMA component life cycle changes and notifying subscribed applications of UIMA component events

The Configurator registers its own OSGi service that allows installing UIMA component bundles and subscribing for UIMA component events.

UIMA Component Services define the API for accessing shared resources of UIMA component bundles, including:
•  component bundle class loader - the bundle class loader established by OSGi container;
•  component UID - a unique identifier of a component bundle;
•  component metadata, such as symbolic name, version and properties;
•  component descriptor(s), called specifications; each component may have one or more public UIMA descriptors (specifications).

The Component Services also provide the API for publishing UIMA components, i.e. registering OSGi services that belong to UIMA component bundles. Each active UIMA component bundle registers two or more OSGi services at the start-up: (1) component reference service, providing access to component bundle resources, and (2) component specification service(s) for each its public UIMA component descriptor. UIMA component publishing is done by the UIMA Component Publisher OSGi service, which is a part of the Component Services.

UIMA Component Registry defines the API for looking-up instances of UIMA component services in the OSGi Service Registry. The Component Registry allows to look-up both UIMA component references and specifications based on internal bundle ID, component UID and various metadata.

The Figure 6 shows the layered run-time architecture and bundle level dependencies of a modular UIMA application in the OSGi container. The OSGi Service Adaptor includes the API bundle, the implementation bundle and the component service object incorporated in each active component bundle. The bundles in the application layer depend on both the Adaptor API and the UIMA runtime. The active component bundles, like UIMA analytic components, depend on the Adaptor API, the UIMA runtime and their specific resources, like type systems. The Adaptor API bundle does not have any bundle level dependencies on the UIMA runtime or components. The Adaptor implementation bundle depends on the UIMA runtime. Finally, the UIMA runtime does not know anything about the analytic components or their resources.

For more information about the OSGi Service Adaptor for UIMA Framework see [17]. The OSGi Service Adaptor for UIMA Framework is available for download at IBM alphaWorks [18].

Figure 6. Layered run-time architecture of modular UIMA application in OSGi container