The design and implementation details of the OSGi Service Adaptor mechanisms go out of the scope of this paper. We will focus here on the core idea of converting plain 3rd party classes and resources into OSGi components and making them available for the framework and applications. At the 1st step, developers package related sets of classes and resources together to form component bundles and identify bundle level dependencies. These dependencies are specified by using OSGi bundle manifests. At the 2nd step, the OSGi Service Adaptor adds the services layer to the 3rd party component bundles. This services layer is responsible for registering components as OSGi service objects, which provide the unified component service interface. Applications can discover available 3rd party components in the OSGi Service Registry, and use the component service interface to get access to their resources and other necessary data. This idea is illustrated in the Figure 3. The black arrows show component level dependencies between the application, the framework libraries and the 3rd party components. The green arrows illustrate the process of registering component service objects in the OSGi Service Registry. The blue dotted arrow illustrates the application request to the OSGi Service Registry. We identify the following 2 types of the 3rd party components, as shown in the Figure 3:
•  Active components, which need to register their service objects in order to be independently discovered by applications. Each active component has its services layer, provided by the Adaptor. Examples - Comp 1, Comp 2 and Comp 3.
•  Inactive components, which do not need to be independently discovered by applications, and thus, do not need to register their service objects. In order to share their resources, inactive components need to be wired to other components. Inactive components do not have the services layer. Examples - Resource A, Resource B.

Figure 3. OSGi Service Adaptor adds services layer to 3rd party components

UIMA Framework overview Our case study technology - Unstructured Information Management Architecture (UIMA) - has been designed by IBM Research as integration platform for broad set of multi-modal software analytics processing unstructured information in order to extract certain structured data or knowledge (see [6]-[10]). Conceptually, this platform can be characterized by the two major features: (1) declarative descriptors specifying metadata pertaining to each resource, such as analysis engine or linguistic resource, and (2) common data structure, named Common Annotation Structure (CAS), which is used to exchange analysis results between analytics. UIMA is realized as extensible and scalable UIMA Framework that supports an application through all information processing stages from acquisition of original unstructured information to its analysis and, ultimately, to the utilization of results.

UIMA positions itself as "component software architecture" (see [7]), but the notion of component in UIMA has a rather declarative nature. UIMA Framework operates with declarative descriptors of analytical 'components', leaving all the operational environment issues, such as organizing class space for Java resources or setting environment variables and system options, to application developers. Declarative descriptors of UIMA analytics refer to other descriptors and resources that are expected to be found in the application class space. Analytics in UIMA Framework are integrated at the level of declarative descriptors. The analytics, included in the analysis pipe, are automatically deployed and run by the framework, and the results of analysis are automatically passed from one node to another in CAS objects (see Figure 4). UIMA Java Framework utilizes two basic mechanisms for resolving local references: (1) using path to resource files in the local file system and (2) using application class space or custom context class loader to locate resources. In the second case, the application is fully responsible for setting the class space boundaries, like adding certain folders or JAR files to the class path.

Figure 4. Basic control flow of a typical UIMA application

UIMA analytics produce the results of analysis in a form of typed objects (annotations) with valued attributes. The types of annotation objects are organized in a hierarchical annotation Type System (TS). UIMA Framework defines few built-in primitive types, like Integer or String, and all annotation types are constructed from these primitive types. UIMA analytics can reuse or extend existing type systems or define their own types independently of any existing type system. Annotation type systems in UIMA Framework are declared by using TS descriptors.
The CAS system manages the organization and storage of all typed annotations in CAS objects. To facilitate the access to CAS objects for Java developers UIMA Framework provides a Java based object-oriented programming interface to the CAS, named JCas (see [11]). The JCas mechanism generates JCas TS classes directly from TS descriptors and allows developers to treat typed annotations as regular Java objects.