iPOJO is a component model on the top of OSGi™. iPOJO is flexible and extensible. It could be adapted in a lot of application context by customizing/extending container. This section presents the concepts of iPOJO.

What does iPOJO mean?

iPOJO means injected POJO. It comes from the fact that iPOJO is based on a byte code manipulation (injection).

What's a POJO?

POJO means Plain Old Java Object. A POJO is a very simple Java class containing only the business logic. A POJO has not dependencies on its execution environment. (http://en.wikipedia.org/wiki/Plain_Old_Java_Object)

In iPOJO, a POJO is a Java class which serve of implementation to a component type. As a content of a component, non-functional requirements of this class will be injected by the container.

What are a component type and an instance?

In component based software engineering (CBSE), there are generally two concepts: Component Types and Instances. By analogy with Object Oriented Programming (OOP), Component Types are Classes and Instances are Objects. In OOP, to create object, you use a constructor, in CBSE you use a factory.

As a component model, iPOJO manages these two entities. Usually, a component type is described by an implementation class and a container configuration. This container configuration describes non-functional requirements of the implementation / component type. For example, the container description can declare that fields are service dependencies, that it provides a service...

For each declared component type, iPOJO will manage a factory. This factory is used to create instances. An instance is the instantiation of a component type. In iPOJO, each instance has a name and can potentially receive an instance configuration. A configuration is a set of property (key, value) which allows two instances from the same factory to be quite different.

By the way, when you declare a component providing a service, the service is provided if at least one instance of this type is created.

The following snippet shows the declaration of a component type and the description of an instance:

<iPOJO>
<component className="...MyPOJO">
                <provides interface="...MyService"/>
                <dependency field="myRequiredService"/>
</component>
<instance component="...MyPOJO" name="MyFirstInstance"/>
</iPOJO>

What's a container?

The separation of concerns is one interesting property of CBSE. Separation of Concerns separates the business logic of the non-functional requirement. (http://en.wikipedia.org/wiki/Separation_of_concerns)

The main technology to support separation of concerns in CBSE is the container approach. An instance is composed by two things:

• The content : generally an object of the implementation class
• The container : managing the instance

The container has to manage all non-functional requirements of the content as the bindings with others instances or resources, the lifecycle ... In iPOJO, the container is described in the component type. If we represent the previously created instance, we have:

What does lifecycle mean?

As said in the previous section, containers manage the lifecycle of instances. The lifecycle is composed by the different state of the life of an instance.

In iPOJO, the lifecycle is minimalist:

• At the beginning, the instance is created and configured.
• Then the instance oscillate between be valid or be invalid according to the container.
• Once stopped, the instance is killed.

The following image illustrates the instance lifecycle:

How is composed the iPOJO Container?

One of the most interesting particularities of iPOJO is its container. The instance container is not a monolithic container. The container is composed by handlers. Each handler manages one non-functional requirement. Required handles are plugged at runtime. Only required handlers are used to avoid performance cost.

The following image represents the iPOJO container of the previous instances.
Moreover, the iPOJO container composition influences the instance lifecycle. Indeed, an instance is valid if all plugged handlers are valid, otherwise the instance is invalid. 

What is a Handler?

A handler is an object who can be plugged on an instance container. A handler manages one non-functional requirement of the instances. Handler can be created and deployed separately from the iPOJO runtime. So everybody can implement its own handler. It is possible to extend the component model by creating your own handler.

However, iPOJO provides in the box handlers (here):

• Service dependency handler managing OSGi service discovery and invocation
• Service Providing handler managing the publication and the providing of OSGi services
• Lifecycle callback handler allowing the invocation of methods when the instance state changes
• Configuration Handler allowing the configuration and the dynamic reconfiguration of the instance
• Architecture Handler allowing to get information about the instance (state, handler ...)

Does iPOJO provides an ADL?

An Architecture Description Language (ADL) is a computer language used to describe software and/or system architectures. (http://en.wikipedia.org/wiki/Architecture_description_language)

iPOJO provides an ADL based of the notion of services. This kind of "composition" can be named Structural Service Composition. Generally, the application is described in terms of components or instances. iPOJO compositions are described in term of services. This composition allows more flexibility and allows service implementations to evolve without breaking the composition.

As a composition can export/implement a service, a composition can be used inside another composition transparently. This brings a hierarchical composition model.

Moreover, as the rest of iPOJO the composition is extensible via "composite handler", which are handler participating to a composition.

The following image represents an iPOJO composition and its description: