...

• Run-time/late binding.
• Service run-time dynamics.
• Implementation evolution.

The remainder of this document describes how this is realized in iPOJOresult is a flexible, yet easy-to-use service-oriented component model.

Structural 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 will registry a factory service that can be used to create instances of the composite component.

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.

...