<div class="content">

Introduction

iPOJO is a an extensible, service-oriented component model implemented on the top of OSGi™ aiming the OSGi framework that aims to simplify the development of OSGi™ applications. Moreover, iPOJO provide an extensibility mechanism allowing developers to extend the component model.. 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 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 However, iPOJO provides a composition model too. This composition tries to merge:

• Component-Based Compositionbased composition and
• Dynamic service flexibility.Service Flexibility

This page document presents iPOJO's hierarchical service composition concepts and a simple example illustrating these conceptsto illustrate them.

...

Motivation

Component Composition is generally declined composition occurs in two trendsfashions:

• Horizontal Composition : Instances can be bound by linking consistent provided interfaces and required interfaces
• Vertical Composition : Instances can contain other instances
• composition: A provided interface from one component instance is bound to corresponding required interface of another component instance.
• Vertical composition: Component instances are contained inside of another component instance.

TypicallyHowever, at runtime, this a component composition is generally an un-modifiable set of instance. On the other side, service oriented computing (SOC) brings required flexibility to adapt application at runtime without modifying the overall application.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 (How to write your own handler) and dynamic vertical composition is supported by iPOJO's hierarchical composition mechanism described below.

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

• Runtime / Late BindingRun-time/late binding.
• Service run-time dynamics.
• Implementation evolution

...

• .

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

Hierachical Service Composition

iPOJO essentially provides a kind of Serviceservice-oriented architecture definition language (ADL). This service-ADL defines "composite"oriented ADL allows you to define composite components. The main difference with component composition is this composite is expressed in term of services instead of components/instancesdifferences 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.

Unlike a POJO component in iPOJO that has code associated with it, a composite component is completely described by its metadata. Similar to a POJO component, however, the metadata describes a component type for which iPOJO registers a factory service that can be used to create instances of the composite component.

A composite can be represented thought of as a service registry or a scoping mechanism of the global OSGi™ service registry. Moreover, composite can be contained in other compositeComposites can contain other composite, creating a hierarchy of service registries. The OSGi™ service registry is the root composite.

A composite can:

• Contain services.
• Require Import services from the its parent service registrycomposite.Export
• Provide services to the parent service registry
• Contain "sub-services" instantiated inside the composite registry
• 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 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 compositeSub-services lives in the composite and use the composite service registry. However, they don't know that they are inside a composite and use services normally.

"Hello World"

...

Composite

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

The

...

"Killer" Application

To illustrate the composition composite we will design a "Hello World" application named HelloComposition. This application composite offers a service writing for dispatching a "Hello" message for each imported Personto 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.Image Removed

...

Image Added
The composite provides the HelloDispatcher service:

public interface HelloDispatcher {
    public void dispatch();
    public String getLanguage();
    public List<Person> getPersons();
}

The next section describes the abstract composite implementation.

Composite Design

To implement this applicationcomposite, we can reuse existing service . Indeed, implementations;we have on three off-the-shelf 3 "instantiable" services.:

• an Hello Service service: returning Returns a "Hello" message in a particular language.
• a Directory service: aggregating Aggregates Person services to create a Directory.
• Dispatch service: Requires Hello and Directory services to dispatch a "Hello" message to each a Say Hello Service : requiring an Hello Service and a Directory Service to write Hello Service to person contained in the Directory.
  Image Removed
  An "instantiable" service is a service that we can instantiate through a Factory. Image Added
  The following code snippets show snippet shows the different Hello service specificationinterface:

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

  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 adressaddress); 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 SayServiceDispatcher { public void saydispatch(); }

  So to design our application we will use these services to obtain the following applications.

...

• These services define the overall abstract implementation of the composite.

Composite Description

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

<composite name="HelloComposition" factory="Hello" architecture="true">
                <import<requires specification="org.apache.felix.ipojo.composition.ex1.person.Person"  aggregate="true"/>
                <export<service specification="org.apache.felix.ipojo.composition.ex1.sayhello.SayServiceHello"/>
                <service specification="org.apache.felix.ipojo.composition.ex1.hellosay.HelloDispatcher"/>
                <service specification="org.apache.felix.ipojo.composition.ex1.saydirectory.SayServiceDirectory"/>
                <service<provides specification="org.apache.felix.ipojo.composition.ex1.directorycompo.DirectoryHelloDispatcher"/>
</composite>

This application The composite is described by a composite. This composite is expressed in term of service specification, resulting in an abstract component implementation; it declares:

• Imports An requirement for all available Person service in services from the parent composite.
• Sub-services for Hello, Dispatcher, and Directory services.
• A provided HelloDispatcher service to the parent composite.
• Exports the SayService to the parent composite.
Instantiates inside the composition a Hello service, a Say Service and a Directory Service

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:Image Added
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.

The main reason for this limitation is that OSGi service specifications are comprised of only two parts:

1. A human-readable document.
2. A Java service interface definition.

To realize iPOJO, OSGi service specifications must be extended to contain other information. For example, services must be able to declare specification-level dependencies on other services. Services with specification-level dependencies are referred to as composable services, since it is possible to compose them with other service. In the core OSGi framework, all service dependencies are at the implementation level, thus only component instances are composable.

Composable services are interesting because they make it possible to define services with parameterized behavior or algorithms. For example, a service to select something from a table could have a specification-level dependency on a sorting service, so that sort order is configurable externally. It might appear as if such a scenario were possible with standard OSGi services, but it is not possible unless you make assumptions about the component implementations.

For example, in standard OSGi if component implementation A provides service Foo and requires service Bar, it is not possible to know whether component implementation B, which also provides Foo and requires Bar, uses Bar for the same purpose as A. Composable services makes this possible, since the purpose of such service dependencies can be defined in the service specification. The resulting model obeys two levels of service dependencies:

• Specification-level dependencies: Dependencies that are imposed on all implementations and whose purpose is well defined.
• Implementation-level dependencies: Dependencies that are arbitrarily selected by the component developer for a specific component implementation and whose purpose is unknown.

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 . It 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 composition composite in this filethe metadata file by declaring an instance, such as:

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

 To avoid packages issues, all used "specification" are imported by the bundle containing the composition.

Runtime

Run Time

Imagine at run time Imagine that at runtime you have:

• Two factories that can create Hello service providersprovider instances.
• A factory that can create SayHello Dispatcher service providersprovider instances.
• A factory that can create Directory service  providersprovider instances.
• Several existing Person servicesservice instances.

When you deploy the example composition and create an instance of it, iPOJO will manage your application:all aspects of it are automatically managed by iPOJO:

• All available Person services from the parent composite are imported into the composite.
• One Hello service
• The composite will import all available services.
• The composite will instantiate a Hello provider, one Directory service provider, and one SayHello Dispatcher service provider are instantiated inside the composite.
• The composite will export the SayHello servicesHelloDispatcher service method calls are wired to the constituent sub-services and it is provided into the parent composite.

If the factory which creates the Hello provider disappears (i.e., its instances become invalid), the composite will automatically used switch to the second one to re-instantiate validate the composite service. If the second one Hello provider disappears too, then the composite will be invalidate invalidated (i.e., the exported provided service will be removedrevoked) , and it will wait for the apparition of a new consistent factory . providing Hello service implementation can be composition tooinstances, which may themselves also be composite implementations.

When a person Person service appears this service in the parent composite, it is automatically inserted inside into the composite. Likewise, as well as if a person service disappear this service Person service disappears from the parent composite, it is automatically removed from the composite.

You can see a A flash demo of this composition here

Composition Features

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 import needs to specify targeted imported service must specify the target service specification. Moreover, an import can be:

• Simple / aggregate: one provider is imported / all available providers are imported
• Mandatory /optional: if no providers are available, the composite is invalidated if the import is mandatory
• Filtered: an import can filter providers

Additionally, 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.

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

Service

...

Provisioning

The composite can export provide services from the composite to the its parent composite. Each export provided service is described by an export a <provides> element in the composite description. An export needs to specify targeted specification. Moreover, an export can be:

• Simple / aggregate: one provider is exported / all available providers are exported
• Mandatory /optional: if no providers are available, the composite is invalidated if the export is mandatory
• Filtered: an export can filter providers

<export specification="...Hello" optional="true" aggregate="true" filter="(language=en)"/>

Service Instantiation

A provide service must specify provided service specification.

Service provision is realized by delegating method invocations on the service interface to methods on the sub-service instances contained in the composition. A delegation mapping is automatically created by matching method names and arguments types. If a delegation mapping cannot be determined, the composition is invalidated.

Service specifications can also declare certain methods as optional in the service interface; this is done by declaring that a method throws an UnsupportedOperationException. Optional methods need not have a mapping for delegation purposes. If a non-optional service method does not have a mapping for delegation, then a warning message is issued.

<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 A composite can instantiate a service inside the composition. The composite will track Factories able to create targeted specification providers. The create created service is instances are accessible only inside the composite (except if the service is exported). Created instance can be composite too. Each . Sub-service instances may also be composites. Each sub-service to instantiate is represented in the composite description by a service element.

Instantiation can be simple or aggregate. In the first case, only one provider is instantiated inside the composition. For aggregate instantiation, each consistent factory is used to instantiate one instance in the composite.

Instantiation can be mandatory or optional. If the composite cannot instantiate a mandatory service, the composite is invalidated.

...

<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

Architecture allows a composite to publish its architecture. It allows knowing why a composite is not valid. For example, when an import cannot be fulfilled, the architecture indicates that the composite is not valid because one import is unsatisfied.

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. 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:To display the architecture, use the "arch" command.

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

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

As Like the rest of iPOJO, the composition model is extensible. Indeed, The composite container is composed by of a "composite handler". These handlers are , which is a special handler designed for composite. It is possible to create a composite handler as it is possible to create a (simple) handler without modifying the iPOJO runtime.More documentation on this feature comes soon.to support composite components. More documentation to come on this feature.