iPOJO library: Declarative Services alternative
iPOJO aims to simplify service-oriented programming on OSGi frameworks; the name iPOJO is an abbreviation for injected POJO. iPOJO provides a new way to develop OSGi service components with the main goal being to simplify service component implementation by transparently managing the dynamics of the environment as well as other non-functional requirements. The iPOJO framework allows developers to more clearly separate functional code (i.e., the POJO) from the non-functional code (i.e., dependecy management, service provision, configuration, etc.). iPOJO combines the functional and non-functional aspects at run time. To achieve this, iPOJO provides a simple and extensible service component model based on POJOs.
iPOJO strength points are :
- components are developed as POJO
- the component model is extensible, you can easily add non-functional properties
- the standard component model manages service providing, service dependencies, dynamic reconfiguration …
- iPOJO manage the component lifecycle and the environment dynamics
A component is implemented in Java in a “POJO” class. This class does not have any links on OSGi. All requirements, as service dependencies, will be injected at runtime when needed.
Several handlers are provided with iPOJO. These “core” handlers target mainly dynamic service environment. The provided handlers are:
- The dependency handler : managing service dependencies
- The provided service handler : managing service publishing and providing
- The configuration handler : managing the configuration and the dynamic reconfiguration of the instance
- The lifecycle callback handler : allows the invocation of method when the instance starts and stops
- The architecture handler : allows to get a description of the instance
An external handler library is currently in construction. Contained handlers will manage events, stream, and service ranking…
iPOJO Component are packaged is bundle. However, iPOJO considers the bundle only as a deployment unit and not as a “functional” component.
The POJO concept
POJO is an acronym for Plain Old Java Object, but it embodies a concept that the simpler and less intrusive the design of a given framework, the better. The name is used to emphasize that a given object is not somehow special, but is an ordinary Java Object. Martin Fowler, Rebecca Parsons and Josh MacKenzie coined the term POJO in September 2000: “We wondered why people were so against using regular objects in their systems and concluded that it was because simple objects lacked a fancy name. So we gave them one, and it’s caught on very nicely.” From the developer’s perspective, the iPOJO framework strives to only require POJOs in as much as it is possible.
iPOJO service component overview
A service component is able to provide and/or require services, where a service is an object that implements a given service interface embodied as a Java interface. Creating components the provide and/or require services comprises the core features of the iPOJO service component model. In addition, iPOJO introduces a callback concept to notify a component about various state changes.
The component is the central concept in iPOJO. In the core IPOJO model, a component describes service dependencies, provided services, and callbacks; this information is recorded in the component’s metadata. Then, the second important concept in iPOJO is component instances. A component instances is a special version of the component. By merging component metadata and instance configuration, the iPOJO runtime is able to manage the component, i.e., manage its life cycle, inject required services, publish provided services, discover needed services.
For further information about iPOJO, visit the iPOJO Web Page at http://cwiki.apache.org/confluence/display/FELIX/iPOJO. You can find iPOJO presentation and published paper on the different sections of this site too.