<div class="content">

Introduction

iPOJO is an extensible, service-oriented component model implemented on the top of the OSGi™ OSGi framework that aims to simplify the development of 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.

...

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 hierarchical composition mechanism described below.

...

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.

...

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.

...

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:

...

• 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:

...

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.

...

Service Requirement

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

...

<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.directory.Directory"/>
    <instance component="MyDispatcher"/>
    <provides specification="org.apache.felix.ipojo.composition.ex1.compo.HelloDispatcher"/>
</composite>

...

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.