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

...

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

...

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 requirement requirements of the implementation / component type. For example, the container description can declares declare that some 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 factories 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 content : generally an object of the implementation class
• The container : managing the instance!img1.png|align=center!

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:Image Modified

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.

...

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.

...

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 create extends extend the component model by creating your own handler.

...

• Service dependency handler managing OSGi services 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 ...)

...