<div class="content">

Introduction

iPOJO is an extensible, service-oriented component model implemented on the top of the OSGi ? framework that aims to simplify the development of OSGi? OSGi™ applications. iPOJO follows a POJO-based component approach using external metadata to describe how POJO components should be managed by the iPOJO runtime. Some of the standard features of iPOJO include automatic service dependency management, service publication, and configuration property injection.

Another standard feature of iPOJO is component factories. As stated previously, an iPOJO component is described by its metadata. In iPOJO, the metadata describes a component type. For each component type, iPOJO registers a factory service that can be used to create instances of the component type described by the metadata.

In addition to these features, iPOJO also provides a service-oriented composition model. iPOJO's composition model tries to merge:

• Component-based structural composition and
• Dynamic service flexibility.

This document presents iPOJO's structural hierarchical service composition concepts and a simple example to illustrate them.

Motivation

Component composition occurs in two fashions:

...

Typically, at runtime, a component composition is an unmodifiable set of connected component instances. The main motivation of iPOJO is to remove this limitation and introduce a more dynamic and flexible approach. iPOJO achieves its goals by applying service-oriented concepts to component orientation. Dynamic horizontal composition is supported by iPOJO's dependency injection mechanism described elsewhere link? (How to write your own handler) and dynamic vertical composition is supported by iPOJO's structural hierarchical composition mechanism described below.

iPOJO structural hierarchical composition tries to merge structural component composition and dynamic service flexibility to allow:

...

The result is a flexible, yet easy-to-use service-oriented component model.

...

Hierachical Service Composition

iPOJO essentially provides a kind of service-oriented architecture definition language (ADL). This service-oriented ADL allows you to define composite components. The main differences between a traditional component-oriented composite and an iPOJO composite is that the iPOJO composite's constituent entities are described in terms of abstract service interfaces instead of specific component types/instances and bindings are inferred from dependency metadata data rather than explicitly declared. This approach means that composite components in iPOJO are not concrete component implementations; rather, they are abstract implementations whose precise implementation selection is deferred until run time.

...

A composite can be thought of as a service registry or a scoping mechanism of the global OSGi? OSGi™ service registry. Composites can contain other composite, creating a hierarchy of service registries. The OSGi? OSGi™ service registry is the root composite.

A composite can:

• Contain services.
• Import Require services from its parent composite.
• Provide services to its parent composite.

A service contained in a composite is a sub-service, which is isomorphic to sub-components in traditional component-oriented composites. A sub-service is a service instance created from a component factory. Sub-services are not visible outside of the composite and can only see other services that reside in the composite service registry. The set of services in the composite service registry are all sub-services as well as all imported required services. Sub-services are not aware of the fact that they are inside of a composite and provide and use services normally within their composite.

"Hello World" Composite

This section describes a simple composite example that imports requires an aggregated set of services from the parent composite, contains 3 sub-services, and provides one service to the parent composite.

The "Killer" Application

To illustrate composite we design a "Hello World" application named HelloComposition. This composite offers a service for dispatching a "Hello" message to each person listed in a Directory service. Each person is published as a service and is used by the composition to get the name of the person in order to write the message.
The composite provides the HelloDispatcher service:

...

The next section describes the abstract composite implementation.

Composite Design

To implement this composite, we reuse existing service implementations;we have three off-the-shelf services:

• Hello service: Returns a "Hello" message in a particular language.
• Directory service: Aggregates Person services.
• Dispatch service: Requires Hello and Directory services to dispatch a "Hello" message to each person contained in the Directory.Image Modified
  The following code snippet shows the Hello service interface:

  Code Block
  public interface Hello { public void hello(String name); public String getLanguage(); }

  The following code snippet shows the Directory service interface:

  Code Block
  public interface Directory { public Person getPerson(String name); public List<Person> getPersons(); public void addPerson(String name, String address); public void removePerson(String name); }

  The following code snippet shows the Person service interface:

  Code Block
  public interface Person { public String getName(); public String getAddress(); }

  The following code snippet shows the Dispatch service interface:

  Code Block
  public interface Dispatcher { public void dispatch(); }

  These services define the overall abstract implementation of the composite.

Composite Description

To describe our composite, we use the iPOJO service-oriented ADL:

<composite name="HelloComposition">
    <import<requires specification="org.apache.felix.ipojo.composition.ex1.person.Person" aggregate="true"/>
    <service specification="org.apache.felix.ipojo.composition.ex1.hello.Hello"/>
    <service specification="org.apache.felix.ipojo.composition.ex1.say.Dispatcher"/>
    <service specification="org.apache.felix.ipojo.composition.ex1.directory.Directory"/>
    <provides specification="org.apache.felix.ipojo.composition.ex1.compo.HelloDispatcher"/>
</composite>

The composite is described in term of service specification, resulting in an abstract component implementation; it declares:

• An import requirement for all available Person services from the parent composite.
• Sub-services for Hello, Dispatcher, and Directory services.
• A provided HelloDispatcher service to the parent composite.

When this composite is instantiated, all Person services from the parent composite are made available in the composite service registry and instances of the Hello, Dispatcher, and Directory are created from available factory services and their corresponding services are published in the composite service registry. The provided HelloDispatcher service is based on method delagation to sub-service specifications as depicted in the following image:
The delegation of HelloDispatcher service methods to sub-service methods is automatically performed by iPOJO based on method name and method parameter matching.

Composite Description Future Work

The composite description presented here does not entirely conform to the ideal model proposed in the earlier sections of this document. Specifically, while the composite is defined in terms of services, the composition as described only really makes sense if we were aware of implementation-specific dependencies of the eventual Dispatcher component type. In other words, for us to choose the Hello and Directory sub-services, we had to know that the eventual implementation of the Dispatcher sub-service would have dependencies on these other sub-services. Unfortunately, this violates the goal of iPOJO to define composites purely in terms of abstract services.

...

As part of the ongoing work of iPOJO, specification-level dependencies (as well as other service specification improvements) will be introduced to the iPOJO model to further refine its service-oriented component model. Using the current example as an illustration, the current approach under investigation for specification-level dependencies looks like this:

Coming soon...

Packaging

A composite component type is described in the metadata.xml file of an iPOJO bundle which means that iPOJO creates a factory service for the composite, like all iPOJO components. Also like all iPOJO components, it is possible to create an instance of the composite in the metadata file by declaring an instance, such as:

<instance component="HelloComposition" name="hello-composition"/>

Run Time

Imagine at run time you have:

...

A flash demo of this composition is available.

Composite Concepts and Features

The following subsections define the various concepts and features of iPOJO's composite components.

Service

...

Requirement

The composite can import require services from the parent composite. Each import requirement is describe by an <import> <requires> element in the composite description. An imported sub- service must specify the target service specification. Additionally, imported required sub-services can specify:

• Cardinality: Indicates whether a single provider instance is imported or an aggregated set of the available providers instances is imported.
• Optionality: Indicates whether the imported sub-service is optional or mandatory.
• Filtering: Indicates how the services available in the parent composite can be further filtered using an LDAP expression evaluated over their service properties.

<import<requires specification="org.apache.felix.ipojo.test.scenarios.service.Hello"
 optional="true" aggregate="true" filter="(language=en)"/>

Service Provisioning

The composite can provide services to its parent composite. Each provided service is described by a <provides> element in the composite description. A provide service must specify provided service specification.

...

<provides specification="org.apache.felix.ipojo.composition.ex1.service.HelloDispatcher"/>

Sub-Service Instantiation

A composite can contain sub-services, which result in private service instances at run time. The composite will track factories able to create targeted specification providers. The created service instances are accessible only inside the composite. Sub-service instances may also be composites. Each sub-service to instantiate is represented in the composite description by a <service> element. The sub-services must specify the desired service specification for the sub-service. Additionally, the sub-service may specify:

• Cardinality: Indicates whether a single provider instance is created or an aggregated set of the available provider instances is imported.
• Optionality: Indicates whether the created sub-service instance is optional or mandatory.
• Filtering: Indicates how the service factories available in the parent composite can be further filtered using an LDAP expression evaluated over their service properties.
• Configuration: Indicates the configuration to inject in the created instances.

<composite name="composite.bar ">
    <service specification="org.apache.felix.ipojo.test.scenarios.service.Hello">
        <property name="language" value="en"/>
    </service>
</composite>

Architecture

Instance injection

A composite can contain instances. These instances does not need to provide any service and are identified by their component types. The composite will track the corresponding factories and create the instances. The instances are accessible only inside the composite and their service requirements are resolved inside the composite too. Each instance to instantiate is represented in the composite description by a <instance> element. The instance can specify the desired configuration. The following code snippet will inject an instance of the Hello factory with the configuration : language=en.

<composite name="composite.bar ">
    <instance component="Hello">
        <property name="language" value="en"/>
    </instance>
</composite>

Instance injection can be use for front end. However, these instances can be used to help a composite to provide a service (despite the instance does not provide a service). Indeed, these instances can be used as glue code to provide a service, containing method implementations of the provided service. For example, in the previous instance we had a Dispatcher service dispatching Hello message to Persons. Instead of this sub-service it is possible to inject in instance containing the dispatch method with a customized dispatching algorithm. A glue code instance can require services as any other iPOJO component.

<composite name="HelloComposition">
    <requires specification="org.apache.felix.ipojo.composition.ex1.person.Person" aggregate="true"/>
    <service specification="org.apache.felix.ipojo.composition.ex1.hello.Hello"/>
    <service specification="org.apache.felix.ipojo.composition.ex1.directory.Directory"/>
    <instance component="MyDispatcher"/>
    <provides specification="org.apache.felix.ipojo.composition.ex1.compo.HelloDispatcher"/>
</composite>

Note: To use instances as glue code be sure that your bundle, containing your composite, imports the implementation of the component type. Moreover, the factory allowing to create the instance must be available when starting your bundle to compute correctly the delegation mapping.

Architecture

iPOJO composites can expose their internal architecture for reflection. iPOJO composites can expose their internal architecture for reflection. This can be useful, for example, when debugging to understand why a given composite is currently invalid, such as when a given import cannot be satisfied. For a composite to expose its internal architecture, it must set the architecture flag, such as:

...

With this flag set, iPOJO publishes an architecture service for the composite. The architecture of the composite can be examined using the "arch" shell command for Felix.

Composition Model Extensibility

Like the rest of iPOJO, the composition model is extensible. The composite container is composed of a "composite handler", which is a special handler designed to support composite components. More documentation to come on this feature.