When building applications for specific domains, we often face a more and more important issue: how do I build the runtime required by the application? For enterprise applications, JEE application servers provide a technical stack containing all required services, but for desktop applications, or communication gateways there are no all-in-one solutions. Indeed, the runtime must fit to the environment and application requirements, making it complex to achieve in a flexible way.

akquinet launched the OW2 Chameleon project in 2009. Chameleon provides a way to build OSGi-based runtimes including the required services and your application. This article explains the motivations behind Chameleon and how Chameleon makes our software development more flexible, robust and efficient.

Creating dedicated application runtimes

Bootstrapping a Java project can be difficult. You should carefully define the runtime you will use to succeed. Unfortunately, if JEE is not eligible, you may be quickly lost in the depths of the Java classpath hell. Identifying the best libraries to use, detecting incompatibilities, trying to reduce as much as possible the dependency on a specific framework (in order to change later if need be) make the setup and the maintenance of the runtime nightmarish. Defining and configuring the infrastructure is crucial to the project’s success. Unfortunately, there is no silver bullet to provide the perfect runtime environment, but … Chameleon aims to make your life simpler by providing a flexible way to build this environment.

Chameleon

The goal of Chameleon is to provide a flexible way to build OSGi applications. The resulting runtimes are like chameleon colors: fitting into the environment. Chameleon is based on OSGi to enforce the modularity of the application, but especially focuses on the service interactions in order to build applications by assembling loosely coupled components. Thanks to OSGi, we are rid of the classpath hell and assemble the runtime and the application just by adding the applicable components.

A common structure

The first feature of Chameleon is to provide a ‘template’ to assemble your application. This template is divided in four parts:

• The core, containing the launcher (common to all applications), and common bundles (configuration, component framework, log support)
• The runtime contains components used by your application (so-called technical services)
• The application itself, containing your application
• The deploy folder, acting as a hot-deploy directory (containing both components and configurations).

Thanks to this common shape, bootstrapping a Chameleon is pretty simple. This template was used in numerous projects and so was validated in several domains.
The core part contains a lightweight / minimal environment common to all projects. It contains the launcher, the logging support (SLF4J), the configuration manager and a component framework (simplifying the development of service-oriented applications – iPOJO).

The runtime directory contains the components required by your application. It basically provides libraries and technical services used by your application. Technical service implementations are carefully chosen according to the constraints of your environment.

The application directory contains your application packaged into one or several OSGi bundles. The application can rely on services deployed in the runtime directory. As chameleon automatically provides it, we recommend using the iPOJO component framework to deal with services. iPOJO proposes a fairly simple development model suitable for Java 1.3 (J2ME compliant) to Java 6 (annotations support). However, other frameworks such as SCR or Blueprint can also be used.
Finally, the deploy directory is a hot-folder from which components and configurations can be automatically deployed.

A set of technical services

The Chameleon project also aims to define and implement common services used by applications. Those services are carefully tailored in order to avoid any dependency on specific implementations, thus allowing substitutions. Moreover, the designed API tries to simplify the interactions with those services.
Chameleon already provides numerous services such as JSON, scheduler, mail, Twitter and syndication.

The json-service provides an easy way to transform objects to JSON strings and vice-versa. The mail service allows the sending and receiving of mails without the complexity of dealing with javax.mail or any other library. The Twitter service allows the reception and the sending of tweets without having to deal with the Twitter API. Finally, the syndication service allows easy reading and writing of feeds (RSS, ATOM…). Chameleon services are also designed to integrate seamlessly with the OSGi event admin. Other services are also available on the Chameleon Service Catalog.

Conclusion

The Chameleon project was created by akquinet in 2009, and is now an OW2 mature project (since April 2011). The goals of the Chameleon project are twofold:

• Proposing a common but flexible way to assemble OSGi-based runtimes and applications.
• Providing technical tailored services usable by your application to reduce the complexity of the application development.

Chameleon also provides utilities for testing and deployment. Chameleon is an open source project licensed under the Apache License 2.0.

Chameleon has already been used in several projects exhibiting a high degree of flexibility and adaptability. If the Chameleon project interests you, feel free to sign up for the Chameleon mailing lists, or contact us.