Apache Celix

Last summer I started working on a project to see if it is possible to implement OSGi concepts in C. After a simple Proof of Concept the idea grew to see if it is possible to not only use the OSGi concepts, but actually implement the OSGi specification. Since the OSGi specification is written for Java, simply implementing it in C cannot be done. So an adaptation is needed.

This adaptation will be based on the previously mentioned proof of concept, and, after being accepted by the Apache Incubator PMC, hosted at apache as an Incubator project named Apache Celix.

With a series of posts I will detail how Celix implements the OSGi specification, where and why it deviates from the original specification. But for a start, why is it created and what will it deliver?

Why?

OSGi provides a dynamic, extensible and easily maintainable environment for complex and distributed architectures. But with one large restriction, it is written for Java based systems only. For embedded/realtime systems there is no alternative, and yet the need for a well defined and modular architecture is becoming more and more important. Besides the dynamics, such architecture also makes it possible to reuse parts of a system, which reduces the time needed to implement and maintain software.

Why OSGi?

Celix uses C functions (Dynamic Loading) that have been around for a long time, so why follow the OSGi specification, and create abstractions to be able to expose the dynamic concepts like OSGi does?

There are three reasons for this, the first being the fact that OSGi solves much more than existing C functions do. For example, dynamic loading only solves how a library can be added at runtime, but for a complete solution a registry is needed to keep track of available libraries and services provided by these libraries. The OSGi specification provides a good and proven specification for this.

This is also where the second reason emerges, since the OSGi specification is implemented by several vendors (commercial and open source), and being used by many organizations and people, it is a well known and proven API. Following this API makes it easier to understand and use Celix.

Finally, implementing the OSGi Compendium specifications for Remote Services also makes it possible to create a seamless, yet flexible, integration between Celix and OSGi implementations.

Why Apache?

As mentioned before, Apache Celix is open sourced at the Apache Incubator. This is mainly for two reasons:

• Community

  As a middleware project, we think Celix can benefit from a large community. Apache provides the means to support such a community.

• Apache Felix

  Several parts of Celix are a direct port of Apache Felix, and with Felix being hosted at Apache, it is a logical choice to also open source Celix at Apache.

While Apache provides a great basis for Celix as an Open Source project, the community still has to grow. Celix is a new project, and user, committers as well as testers are still needed and always welcome. As with all Apache project, communication is done using mailing lists, to subscribe to the development list of Celix send an email to <celix-dev-subscribe@incubator.apache.org>.

The original proposal can be found on the wiki of the Apache Incubator and the status of Celix in the Apache Incubator can be tracked on the project page for Celix.

What will it deliver?

Eventually, the goal is to have an implementation of the full OSGi Core, and part of the Compendium specification in C. But as with all good things, the OSGi specification was written over a longer period, and expecting Celix to implement everything at once, and still deliver a usable product in a reasonable time would be naive.

So for a first release the following goals are set:

• Provide a basic implementation of the OSGi Framework API

• Provide an implementation of Remote Services

  For both Celix <-> Celix but also Celix <-> OSGi

While this is a short list, actually implementing the OSGi Framework API entails a lot of functionality. In the coming blog posts I will detail parts of the specification, and how they are implemented in Celix.

Call for help

Finally, I would like to invite everyone to join the Apache Celix community, and provide us with feedback, ideas, bugs, and maybe even bugfixes and additions to the current code base.