You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Introduction

iPOJO is a component model on the top of OSGi™ aiming to simplify the development of OSGi™ applications. Moreover, iPOJO provide an extensibility mechanism allowing developers to extend the component model.

However, iPOJO provides a composition model too. This composition tries to merge:

  • Component-Based Composition
  • Service Flexibility

This page presents iPOJO composition concepts and a simple example illustrating these concepts.

Motivations

Component Composition is generally declined in two trends:

  • Horizontal Composition : Instances can be bound by linking consistent provided interfaces and required interfaces
  • Vertical Composition : Instances can contain other instances

However, at runtime, this 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.

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

  • Runtime / Late Binding
  • Service dynamics
  • Implementation evolution

Structural Service Composition

iPOJO provides a kind of Service-ADL. This service-ADL defines "composite". The main difference with component composition is this composite is expressed in term of services instead of components/instances.

A composite can be represented as a service registry. Moreover, composite can be contained in other composite. The OSGi™ service registry is the root composite.

A composite can

  • Import services from the parent service registry
  • Export services to the parent service registry
  • Contain "sub-services" instantiated inside the composite registry

Sub-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 3 sub-services and exporting one service.

The killer application

To illustrate the composition we will design a Hello World application named HelloComposition. This application offers a service writing a Hello message for each imported Person. Each person is published as a service and is used by the composition to write the message.

<IMAGE1>

Application Design

To implement this application, we can reuse existing service. Indeed, we have on the shelf 3 "instantiable" services.

  • an Hello Service : returning a Hello message
  • a Directory service : aggregating Person services to create a Directory
  • a Say Hello Service : requiring an Hello Service and a Directory Service to write Hello Service to person contained in the Directory.

An "instantiable" service is a service that we can instantiate through a Factory. The following code snippets show the different service specification:

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

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

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

public interface SayService {
                public void say();
}

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

Application Description

To describe our application, we will use the iPOJO ADL:

<composite name="HelloComposition" factory="Hello" architecture="true">
                <import specification="org.apache.felix.ipojo.composition.ex1.person.Person"  aggregate="true"/>
                <export specification="org.apache.felix.ipojo.composition.ex1.say.SayService"/>                <service specification="org.apache.felix.ipojo.composition.ex1.hello.Hello"/>
                <service specification="org.apache.felix.ipojo.composition.ex1.say.SayService"/>
                <service specification="org.apache.felix.ipojo.composition.ex1.directory.Directory"/>
</composite>

This application is described by a composite. This composite is expressed in term of service specification:

  • Imports all available Person service in the parent composite.
  • Exports the SayService to the parent composite.
  • Instantiates inside the composition a Hello service, a Say Service and a Directory Service.

Packaging

A composite is described in the metadata.xml file of an iPOJO bundle. It is possible to create an instance of the composition in this file:

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

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

Runtime

Imagine that at runtime you have:

  • Two factories that can create Hello service providers
  • A factory that can create SayHello service providers
  • A factory that can create Directory service  providers
  • Several Person services

When you deploy the composition, iPOJO will manage your application:

  • The composite will import all available services.
  • The composite will instantiate a Hello provider, one Directory provider and one SayHello provider inside the composite.
  • The composite will export the SayHello services.

If the factory which creates the Hello provider disappears, the composite will automatically used the second one to re-instantiate the service. If the second one disappears too, the composite will be invalidate (the exported service will be removed), and will wait for the apparition of a new consistent factory. Hello service implementation can be composition too.

When a person service appears this service is automatically inserted inside the composite, as well as if a person service disappear this service is automatically removed.

You can see a demo of this composition here

Composition Features

Service Import

The composite can import services from the parent composite. Each import is describe by an import element in the composite description. An import needs to specify targeted 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
<import specification="...Hello" optional="true" aggregate="true" filter="(language="en)"/>

Service Export

The composite can export services from the composite to the parent composite. Each export is described by an export 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 composite can instantiate a service inside the composition. The composite will track Factories able to create targeted specification providers. The create service is accessible only inside the composite (except if the service is exported). Created instance can be composite too. Each 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.

The instantiation can be filtered. The filter is applied on factories. For example, it is easily possible to set which factory to use. Moreover, the instantiation can contain properties. These properties are used in the configuration to push inside the created instances.  Only factories exposing these properties are used in this case.

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

To display the architecture, use the "arch" command.

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

Composition Model Extensibility

As the rest of iPOJO, the composition model is extensible. Indeed, composite container is composed by "composite handler". These handlers are 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.

 

 

 

 

 

  • No labels