iPOJO 1.0.0 and the future

I recently released the version 1.0.0 of the iPOJO framework. This release is a major milestone for iPOJO.

iPOJO was created two years ago in the continuation of the Service Binder effort. The initial goal was to provide an easy way to create dynamic service-based applications on the top of OSGi without losing the OSGi philosophy (small, universal middleware).
At the same time, I was involved in several projects where I realized that iPOJO must focus on different goals:

• Must be simple… (Avoids redundancies, provides annotations)
• Must be extensible to tackle specific requirements
• Must provide a way to design applications

The first requirement comes from the OSGi development model. OSGi is very powerful, but the learning curve is slow and long. A lot of mechanisms (mostly about class loading and threads) must be understood. Hiding or simplifying those mechanisms was a stringent requirement.

The first project using iPOJO was the design and the implementation of a residential gateway. However, we quickly understood that developing such kind of application requires some specific technical services such as a MOM allowing event-based interactions, a scheduler (i.e. Cron) to automate periodic task triggering, a way to administrate applications remotely… Providing such technical services is not too difficult. However, automating the interaction with those technical services was more challenging. From this observation, we decide to provide an extension mechanism allowing adding such kind of features without modifying the core of the project. So, iPOJO can be small as well as providing a lot of functionalities.

Finally, we realize that we need a way to design applications. Traditional ways to design applications are somewhat limited. Generally they are limited to static applications (with no possible evolution at runtime) and the architecture description is lost just after that the application is deployed. After a long work with Richard S. Hall, we propose and implement a new way to design applications on the top of OSGi. iPOJO composite allows isolating services, support dynamism … This is the most innovative part of the iPOJO project.
The iPOJO 1.0.0 release is the result of these two years of development, research, interrogations and experimentations. The iPOJO framework is composed by:

• A core system providing basics functionalities (requiring/providing services, lifecycle, instance introspections…)
• A full integration with the Configuration Admin
• A way to design and execute dynamic applications
• Several external handler extending core capabilities with JMX administration, Event Admin interactions, Temporal service dependency, whiteboard and extender patterns …

The future of iPOJO is also exciting. With the support of my ‘future former’ group, extensions such as distribution and deployment are under development. The distribution framework allows iPOJO instances to interact with remote services (using any protocol) and can be exposed remotely. The deployment support computes OBR descriptions from metadata providing features easing the deployment. Improvements such as providing a control and creation API are also investigated. The future version will see the arriving of new ‘handlers’ handling persistence and scheduling as well as a better integration with the junit4osgi framework.

All those stuffs are really promising… Isn’t it?