OSGi and C++ An Overview
Updated on 10/04/2012: Poco OSP facts corrected (source: private mail with the developer)
In September 2011 I attended the OSGi Community Event in Darmstadt and had the opportunity to shortly discuss the state of native C++ implementations of the OSGi specifications with other attendees. Already before this event, I wanted to write a blog post about the current state of projects trying to implement a OSGi - like framework in C/C++. Finally, this blog post gives you a high-level overview of the Native OSGi landscape.
Introduction
I learned about the OSGi component model about seven years ago by creating an Eclipse RCP application. Nowadays, I program mostly in C++ but I am still trying to follow the developments and trends in OSGi and Java in general. Although there are many high-quality C++ libraries which help to create complex systems, the options for a C++ library/framework enabling component (and/or service) oriented designs are limited. Depending on your requirements, this set of options might be reduced substantially. I will try to give a review of active projects which try to implement the OSGi API in C or C++. Complex middleware frameworks (like CORBA) or SCA implementations which allow a service oriented design but which either are not available for C++ or lack development activity (the last Apache Tuscany C++ release is from 2007) will not be discussed.
As you will see below, there is a growing interest in a C++ OSGi framework since a couple of years. Several independent projects picked up the OSGi design principles and try to translate them to C or C++. The biggest drawback of these efforts - in my opinion - is the lack of a C++ OSGi community (if you know of one, please let me know). Although a couple of projects exist, they live pretty much isolated from each other and yet lack a large user base.
Native and Universal OSGi
In 2007, RFP-89 (Request for Proposal) was filed for specifying a system dubbed Universal OSGi. A short discussion on the Universal OSGi mailing-list followed and Peter Kriens blogged about the idea here. In short, the idea was to be able to access service objects written in other languages (not Java) via the OSGi service registry (possibly using some kind if IPC mechanisms under the hood). The central orchestration unit would still be a Java OSGi implementation with additional capabilities for managing native bundles.
The term Native OSGi seems to appear more often in the context of translating OSGi principles to a native OSGi framework implementation (for example implemented in C or C++). Such native frameworks which can be used on their own are the focus of this post. Of course a native OSGi framework will have a much bigger impact if it provides Java interoperability in the sense of Universal OSGi (hence being a super set in terms of provided functionality). You can find a short discussion about the state of Universal OSGi dating from September 2008 here. The mentioned paper The Software Fabric for the Internet of Things (doi) written by Jan Rellermeyer et.al. describes a light-weight JNI based approach for handling interoperability between native (C++) and Java services. Unfortunately, I could not find the native code anywhere (the Java implementation for remote OSGi services can be found here).
The interest in a Native OSGi solution does not seem to vanish (see 1, 2, 3, and 4) but it surely is not (yet?) mainstream. Another blog post by Peter Kriens from October 2010 picks up the Universal OSGi idea again and points to a proposal for an Apache Incubator project providing a C implementation of OSGi. I will provide some details about the current state of art concerning Native OSGi implementations in the next section.
C/C++ Projects
Although the term Native OSGi is not tied to a specific platform or native programming language, people seem to be mostly interested in C and C++ implementations (see links in the previous section). One of the earliest projects is OSGI for C++ which was registered on July 2007 on SourceForge. The project does not have released any source code or binaries and seems to be abandoned. I will describe the currently active C or C++ projects which I know of below, trying to approximately maintain the chronological order of their public appearance (to the best of my knowledge).
Disclaimer: I am the main developer of the CTK Plugin Framework. My information about the other projects is compiled from various sources from the Internet (which I will link to) but is likely to be incomplete. Unfortunately, I do not have time to test and play with all the frameworks, so most of my knowledge about these projects stems from reading the docs and the source code. If you are one of the developers of the mentioned projects and would like to correct/add some information, please contact me.
Poco OSP
In Autumn 2007, the Poco Open Service Platform was the first OSGi-like project written in C++ I stumbled on. The copyright in the white-paper suggests that the project was created sometime in 2007. It differentiates itself from the other C/C++ projects by two facts. First, it is a commercial product and second, it exhibits the least similarities to the OSGi specifications in its API. The concept of bundles and a service registry is, however, modeled after the OSGi principles.
The Poco OSP API documentation lists a couple of services (like Preferences and User Admin), which seem to be related to the corresponding OSGi service specifications, but they have a different API. Further, the platform supports remote services and provides the ability to sign bundles and to interact with the framework via a command shell.
SOF
The Service Oriented Framework (SOF) was registered at SourceForge in early 2008 and seems to be one of the earliest usable open-source C++ OSGi implementations. It implements a subset of the OSGi Framework API and provides an OSGi console, an Eclipse RCP based Admin UI, and support for remote services.
The remote service capabilities of SOF are based on MICO, a C++ CORBA implementation.
CTK Plugin Framework
The CTK Plugin Framework is the third rewrite of a C++ OSGi-like dynamic component framework, developed in the Division of Medical and Biological Informatics at the German Cancer Research Center. The first iteration was part of a larger framework called openCherry which has been developed during 2007/2008 and focused on providing a C++ implementation of the Eclipse RCP based on a C++ component model (similar to Equinox). The project was later renamed to BlueBerry which is the foundation for the MITK Application Framework (BlueBerry itself is a generic application platform, not tied to specific use cases). The OSGi related C++ code in BlueBerry has been rewritten in 2009 and is known as the CTK Plugin Framework.
The CTK Plugin Framework is based on the Qt Core library and implements almost the complete OSGi Framework API. It makes use of the Qt plugin system, the resource system, and signal/slots to support all OSGi Framework functionalities. Additionally, it provides a couple of optional OSGi service specification implementations.
nOSGi
The nOSGi project is another C++ OSGi implementation tailored for POSIX systems, which was developed in 2009 according to a comment in this blog post. Its developer wrote a very nice paper investigating the feasibility of translating OSGi concepts to a native system (POSIX).
nOSGi especially focuses on modelling inter-bundle package dependencies (see the above paper for the definition of a C++ package) by patching the ELF headers of DSOs at runtime. It also provides an OSGi Console to interact with the running framework.
Celix
In 2010, Celix was created as an Apache Incubator project (proposal). It is a OSGi like implementation in C initially developed by Luminis. Celix focuses on following the OSGi API as close as possible and on enabling interoperability between Java OSGi bundles and native C bundles written with Celix.
Celix also provides a OSGi Shell and a Log Service implementation. Additionaly, the Celix team actively tries to stimulate the growth of a C/C++ OSGi community and to raise the open-source communities awareness of such projects (see the mailing list discussion here).
Comparison
I will provide a high-level comparison of the mentioned native OSGi projects below. Please note that although I tried to collect accurate data, it might still be incomplete or wrong. The sources of information were:
- Poco OSP: Official API documentation (from 29/03/2012) and the evaluation package 2011_2.
- SOF: Source code version 1.3 (revision 11090) and documentation on the website.
- CTK: Source code (Git hash 233893) and website documentation (from 29/03/2012).
- nOSGi: Source code (SVN revision 8).
The following table lists the supported platforms, the license, the implementation language, and the creation date (as far as it could be determined).
| Supported Platforms | License | Language | Created | |
|---|---|---|---|---|
| Poco OSP | Linux, Windows, Mac OS, QNX | Commercial | C++ | 2007 (?)1 |
| SOF | Linux, Windows | BSD (?)2 | C++ | 2008 |
| CTK | Linux, Windows, Mac OS | Apache License 2.0 | C++ | 2009 |
| nOSGi | POSIX | GPLv3 | C++ | 2009 |
| Celix | Linux3 | Apache License 2.0 | C | 2010 |
1 The earliest copyright year in the white-paper.
2 From SourceForge project details, but there is no license information in the sources.
3 Basically, the project is cross-platform but seems to concentrate on Linux only.
The OSGi Framework implementations of the five projects differ in various aspects. The table below will highlight the following implementation details:
- Service Query Language Query the bundle context for services and allow adding service listeners using filter expressions (on the service properties).
- Service/Bundle Tracker Provide utility classes to track services and bundles (basically, providing an implementation of the Tracker specifications).
- Bundle Updates Ability to update bundles at runtime.
- Type-safe Services A mechanism to safely cast a service instance to an implemented interface.
- Thread safety Thread safe OSGi Framework API.
| Service Query Language | Service/Bundle Tracker | Bundle Updates | Type-safe Services | Thread-safe | |
|---|---|---|---|---|---|
| Poco OSP | Yes | No/No | Yes | Yes | Yes |
| SOF | No | Yes/No | No | Yes | (Yes)1 |
| CTK | Yes (RFC1960) | Yes/Yes | Yes | Yes | Yes |
| nOSGi | (Yes)2 (RFC1960) | No/No | Yes | No | No |
| Celix | Yes (RFC1960) | Yes/No | Yes | No | Yes |
1 Thread safety must be enabled by the user by supplying a custom threading policy class as a template argument
to the launcher.
2 Only supported when registering service listeners
Here is a (possibly incomplete) list of implemented OSGi specifications. The level of API similarity to the original OSGi specifications can vary a lot from project to project.
| Implemented OSGi Specifications | Planned | |
|---|---|---|
| Poco OSP | (Preferences, User Admin, Http, Remote Services)1 | ? |
| SOF | Remote Services | ? |
| CTK | Event Admin, Configuration Admin, Metatype Service, Log Service | Remote Services |
| nOSGi | - | ? |
| Celix | Log Service, (Deployment Admin, Remote Services)2 | ? |
1 While the Poco OSP provides these functionalities in terms of services, they do not seem to comply
with the OSGi specifications.
2 There is some code and examples in the SVN repository, but no documentation on
the website yet. Status unclear.
Finally, the last table summarizes a few code metrics for the open-source projects, using the source code versions as stated at the beginning of this section. The development costs are based on a basic COCOMO model as used by sloccount. The line counts have been extracted with cloc. Both tools have been applied to the framework code only (no examples, tests, service implementations, etc.).
| Lines of Code | Lines of Comments | Costs | |
|---|---|---|---|
| SOF | 3559 | 2801 | $ 102k |
| CTK | 8770 | 10024 | $ 264k |
| nOSGi | 2208 | 2284 | $ 62k |
| Celix | 8923 | 2450 | $ 269k |
Conclusion
The good news is that native OSGi solutions exist and that there is ongoing development activity. The bad news is that the native OSGi landscape is fragmented. There is not yet a large community or sufficient interest in the industry. I believe in the C++ Renaissance and that for embedded systems as well as for large-scale component-based applications, a native OSGi solution will be very beneficial (also think about the increased performance per dollar ratio).
On the technical side, I did not discuss many important details in the OSGi specifications and how they are implemented in the existing projects. I might do a more in-depth comparison about how the projects handle bundle meta-data, dependencies, versioning, resources, dynamic loading and RTTI problems for example.
blog comments powered by Disqus
