osgi-like c++ implementation

http://blog.cppmicroservices.org/2012/03/29/osgi-and-c++/

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 towrite 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 ahigh-level overview of the Native OSGi landscape.

• Introduction
• Native and Universal OSGi
• C/C++ Projects
  • Poco OSP
  • SOF
  • CTK Plugin Framework
  • nOSGi
  • Celix
• Comparison
• Conclusion

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 theUniversal OSGi mailing-list followed and Peter Kriens blogged about the ideahere. In short, the idea was to be able to access service objectswritten 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 anative OSGi framework will have a much bigger impact if it provides Java interoperability in the sense of Universal OSGi (hence beinga super set in terms of provided functionality). You can find a short discussion aboutthe 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 approachfor handling interoperability between native (C++) and Java services. Unfortunately, I could not find the native code anywhere (theJava 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, and4) but it surely is not (yet?) mainstream.Another blog post by Peter Kriens from October 2010picks up the Universal OSGi idea again and points to a proposal for an Apache Incubator projectproviding a C implementation of OSGi. I will provide some details about the current state of art concerning Native OSGi implementationsin 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 andC++ 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 theirpublic 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 sourcesfrom 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 theframeworks, 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++ Istumbled 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 commercialproduct 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 supportsremote 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 SourceForgein early 2008 and seems to be one of the earliest usable open-source C++ OSGi implementations. It implements a subset of theOSGi 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 ofMedical and Biological Informatics at the German Cancer Research Center. The first iteration was part ofa larger framework called openCherry which has been developed during 2007/2008 and focused on providing a C++ implementation of theEclipse RCP based on a C++ component model(similar to Equinox). The project was later renamed to BlueBerrywhich is the foundation for the MITK Application Framework (BlueBerry itself is ageneric application platform, not tied to specific use cases). The OSGi related C++ code in BlueBerry has been rewritten in 2009 and isknown as the CTK Plugin Framework.

The CTK Plugin Framework is based on the Qt Core library and implements almostthe complete OSGi Framework API. It makes use of the Qt plugin system, the resource system, and signal/slots to support all OSGi Frameworkfunctionalities. 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 commentin this blog post. Its developer wrote a very nicepaper 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). Itis a OSGi like implementation in C initially developed by Luminis. Celix focuses on following theOSGi 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 thegrowth of a C/C++ OSGi community and to raise the open-source communities awareness of such projects (see themailing list discussion here).

Comparison

I will provide a high-level comparison of the mentioned native OSGi projects below. Please note that although I triedto 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

¹ The earliest copyright year in the white-paper.
² From SourceForge project details, but there is no license information in the sources.
³ 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 thefollowing implementation details:

• Service Query Language Query the bundle context for services and allow adding service listeners using filterexpressions (on the service properties).
• Service/Bundle Tracker Provide utility classes to track services and bundles (basically, providing animplementation 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

¹ Thread safety must be enabled by the user by supplying a custom threading policy class as a template argumentto the launcher.
² Only supported when registering service listeners

Here is a (possibly incomplete) list of implemented OSGi specifications. The level of API similarity to the original OSGispecifications 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	?

¹ While the Poco OSP provides these functionalities in terms of services, they do not seem to complywith the OSGi specifications.
² There is some code and examples in the SVN repository, but no documentation onthe website yet. Status unclear.

Finally, the last table summarizes a few code metrics for the open-source projects, using the source code versions as statedat 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 sufficientinterest in the industry. I believe in the C++ Renaissanceand that for embedded systems as well as for large-scale component-based applications, a native OSGisolution will be very beneficial (also think about the increasedperformance per dollar ratio).

On the technical side, I did not discuss many important details in the OSGi specifications and how they are implementedin 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.