Page History

...

To illustrate composite we design a "Hello World" application named HelloComposition. This application composite offers a service for writing 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.

...

Application Design

To implement this applicationcomposite, we can reuse existing service implementation. 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.
• a Dispatch Service service: requiring an Requires Hello Service and a Directory Service services to write Hello Service to dispatch a "Hello" message to each person contained in the Directory.

Image Modified

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

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

The following code snippet shows the Directory service interface:

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:

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

The following code snippet shows the Dispatch service interface:

public interface Dispatch{
                public void saydispatch();
}

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

...

Composite Description

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

...

The providing is based on a method delagation on available specifications as depict in the following image :

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 ideals of iPOJO, which strive 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:

#. A human-readable document.
#. 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 specificaion-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 some 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 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 is described in the metadata.xml file of an iPOJO bundle. It is possible to create an instance of the composition in this file:

...