The C++ Micro Services Blog

C++ Micro Services 2.1.0 released

2014-01-11T00:00:00-08:00

Version 2.1.0 of the C++ Micro Services library has just been released. You can get the sources at the download page or directly from the GitHub releases page.

This release introduces full support for Mac OS X Mavericks and fixes a couple of bugs. See the Release Notes for details. It is a minor release and fully backwards compatible with client code written for version 2.0.0.

C++ Micro Services 2.0.0 released

2013-12-23T00:00:00-08:00

Today, the C++ Micro Services library version 2.0.0 has been released. You can get the sources at the download page or directly from the GitHub releases page.

This release marks a significant milestone in the evolution of the C++ Micro Services API. The most notable changes and new features are:

Service objects do not need to inherit from a common base class any more.
New templated service layer API leading to Improved compile time type checking.
Added module and service hooks as specified in the OSGi Core Release 5.
Implemented RFC 195 Service Scopes.
Modules can retrieve a module specific file-system path for storing persistent data.

For a detailed description of the new features, please read the next section.

New features

The following paragraphs demonstrate the usage of the main new features and changes in the 2.0.0 API.

No service base class

Version 1.0.0 required service implementations to inherit from a common base class. This requirement has been removed and services now just need to inherit from the interfaces against which they will be registered with the service registry:

struct MyInterface
{
  virtual ~MyInterface();
  
  // API ...
};
US_DECLARE_SERVICE_INTERFACE(MyInterface, "com.mycompany.myinterface")

class MyService : public MyInterface
{
  // implementation ...
};

Templated service layer API

The service layer API has been templated and classes like ServiceReference and ServiceRegistration are now templates. This improves compile time type checking when working with (multiple) service interfaces. Registering and retrieving services now looks like:

us::ModuleContext* context = us::GetModuleContext();
MyInterface* service = new MyService();
us::ServiceRegistration<MyInterface> reg = context->RegisterService(service);

us::ServiceReference<MyInterface> ref = context->GetServiceReference<MyInterface>();
MyInterface* myInterface = context->GetService(ref);

// ...

reg.Unregister();
delete service;

Module and Service Hooks

The OSGi service layer specifies module and service hooks, which offer clients an API to closely interact with the service registry. See the Service Hooks documentation for an overview or read the original OSGi Core specifications for an in-depth description.

Service Scopes

RFC 195 Service Scopes has been implemented in the C++ Micro Services library. In version 1.0.0, services essentially had two scopes - singleton and module scope - although they weren’t named as such. Service objects were either shared among all clients or module-specific service instances were provided by the service registry if the service inherited the us::ServiceFactory class. The same mechanism is still supported, but the additional prototype scope was added. Services can now support three kind of scopes:

Singleton - One service instance for all clients
Module - One service instance per module (constructed via us::ServiceFactory)
Prototype (new) - As many instances as requested (constructed via us::PrototypeServiceFactory)

The newly introduced service property SERVICE_SOPE allows clients to look up the supported scope of a ServiceReference object.

Here is an example how to provide and consume services with prototype scope:

class MyServicePrototypeFactory : public us::PrototypeServiceFactory
{
public:

  us::InterfaceMap GetService(us::Module* /*caller*/,
                              const us::ServiceRegistrationBase& /*reg*/)
  {
    MyService* service = new MyService();
    return us::MakeInterfaceMap<MyInterface>(service);
  }

  void UngetService(us::Module* /*caller*/,
                    const us::ServiceRegistrationBase& /*reg*/,
                    const us::InterfaceMap& service)
  {
    delete us::ExtractInterface<MyInterface>(service);
  }
};

// Register the prototype factory
us::ModuleContext* context = us::GetModuleContext();
us::ServiceFactory* myPrototypeFactory = new MyServicePrototypeFactory();
us::ServiceRegistration<MyInterface> reg =
    context->RegisterService<MyInterface>(myPrototypeFactory);

// Get new service instances based on the prototype
us::ServiceReference<MyInterface> ref = context->GetServiceReference<MyInterface>();
if (ref.GetProperty(us::ServiceConstants::SERVICE_SCOPE()).ToString() !=
    us::ServiceConstants::SCOPE_PROTOTYPE())
{
  // Not a prototype scope service. Keep going or bail out ...
}

us::ServiceObjects<MyInterface> svcObjects = context->GetServiceObjects(ref);
MyInterface* myServiceInstance = svcObjects.GetService();
// Do something ...

// The us::ServiceObjects class "ungets" all instances automatically on destruction
// and all pointers to MyInterface instances become invalid. 

reg.Unregister();
delete myPrototypeFactory;

Breaking changes

Version 2.0.0 introduces a couple of breaking API changes compared to version 1.0.0. Please ask for support in the CppMicroservices Forum if you have trouble with migrating to version 2.0.0.

What’s next?

The C++ Micro Services library API will continue to evolve as new OSGi features are specified and fit into the scope of this library. However, the evolution will probably be at a much slower pace when compared to the changes between version 1.0.0 and 2.0.0. Instead, the future development focus will be on implementing OSGi Core and Compendium specifications in separate repositories, based on the C++ Micro Services library. Most likely, the Config Admin and Declarative Services specifications will be worked on first.

C++ Micro Services 1.0.0 released

2013-07-19T00:00:00-07:00

As of today, the C++ Micro Services library version 1.0.0 is available. You can get the sources at the download page or directly from the GitHub releases page.

During the last months a few notable improvements and additions took place. Among these are:

A resources system for embedding arbitrary files into a module.
Install support on all supported platforms, including installation of API documentation.
Performance improvements in the service registry
Added new public class us::SharedLibrary.
General overhaul of the high-level documentation, adding an exhaustive tutorial.

Additionally, the usual bug fixing and maintenance took place. Please report any issues you have with this release.

What’s next?

The 1.0.0 release will be maintained for quite some time, but will likely not receive any more feature additions. Work on version 2 has already started and there will be a couple of important changes and improvements. The goal for version 2 is to get rid of the base class requirement, meaning the service implementations won’t need to inherit from a common base class anymore. Further, the handling of type information of services is going to be improved, similar to the introduction of the generics-based API in OSGi 4.3. Compare the current code for retrieving a service

ServiceReference ref = context->GetServiceReference<IDictionaryService>();
IDictionaryService* dict = context->GetService<IDictionaryService>(ref);

with the version 2 way:

ServiceReference<IDictionaryService> ref = context->GetServiceReference<IDictionaryService>();
IDictionaryService* dict = context->GetService(ref);

There will be no need for dynamic casts anymore (which has been hidden in the templated GetService method.

Another planned feature for version 2 is the implementation of Servivce Scopes (RFC 195) as specified in the OSGi Early Draft 2013.03.

RFP 156 Native OSGi available

2013-06-14T00:00:00-07:00

RFP 156 entitled Native OSGi has been published on the OSGi bug tracker a month ago. It aims at reviving parts of RFP 89 (Universal OSGi) with a focus on providing an OSGi Core specification for the C and C++ programming languages.

The joined efforts of different people interested in creating a native OSGi specification and implementation started back in May last year during a Native OSGi Developers Meeting in Hengelo. Since then there have been presentations about the idea of Native OSGi at the OSGi Community Event 2012 (link) and at ApacheCon Europe 2012 (link).

With the help and feedback from people involved in the OSGi specifications, RFP 156 finally was published. I encourage interested parties to contribute to it by adding comments, use cases, requirements, etc. to the Bugzilla ticket.

Native OSGi at the OSGi Community Event 2012

2012-09-09T00:00:00-07:00

Together with Alexander Broekhuis, I will be talking at the OSGi Community Event 2012 in Ludwigsburg (Germany) about Native OSGi. The talk will be a 55 minutes extended talk, organized as two 25 minutes talks (plus discussion). Here is the talk abstract and the second part. There will also be another talk related to Native OSGi, called Universal Declarative Services, at which you should definitely have a look at.

This year, the OSGi Community Event is co-located with EclipseCon Europe 2012 and there is a nice Session Schedule overview available. I am looking forward to many interesting discussions about Native OSGi and to meet some of the community members in real life (again). If you are interested in Native OSGi, you should definitely consider to register for the OSGi Community Event!

First Native OSGi Developers Meeting

2012-05-26T00:00:00-07:00

On the 22nd of May 2012 the first Native OSGi developers meeting was hosted by Thales (Hengelo, Netherlands). Detailed notes about the meeting can be found here.

After a general introduction round, we discussed the current state of the available open-source frameworks (Celix, SOF, nOSGi, and CTK) and tried to identify common needs and goals. The projects had a lot in common, but also differed in some interesting ways.

Another very important discussion was centered about two questions which pop up frequently.

Why is a native (C or C++) OSGi framework needed?

C and C++ as programming languages are here to stay (whether you like it or not).
Traditional application domains (for example in medical imaging, embedded devices, sensor networks, etc.) often use native languages and possibly rely on a large native (legacy) code-base.
Native developers designing scalable, modular platforms for a dynamically reconfigurable (embedded) environment need a light-weight yet powerful module system (just like Java developers).

What are the benefits of a native (C or C++) OSGi framework?

Builds upon a mature API design for a dynamic environment, supporting native developers in creating modular platforms.
Allows the creation of a hybrid Java and C/C++ architecture (via remote services) as an alternative to JNI.
Maximizes the performance per watt ratio for (embedded) devices.
Eases future software migrations of native components to a Java OSGi-based system.

We strongly believe that there is a market (community) for Native OSGi and quickly agreed on trying to draft a C and C++ API in the near future and have it reviewed by the community.

Having a common API would allow us to re-use bundles originating from different projects, as it is common in the Java OSGi community. Additionally, it would hopefully help us in growing a community and to foster collaboration between the existing native OSGi framework implementations.

A large part of the afternoon discussions focused on the meaning of a Module Layer in a native setting and about C and C++ interoperability. I think we are heading in the right directions but there are still many details to work out.

You can follow our collaborative efforts on our NativeOSGi GitHub project and on the Celix Mailinglist.

OSGi Lite for C++

2012-04-15T00:00:00-07:00

OSGi solves the Java modularity problem. This is the major feat of OSGi, as it is claimed by its advocates. While I am definitely pro OSGi, I can also see the difficulties when trying to migrate an existing code base with complex dependencies to an OSGi based system. This applies both to Java projects as well as C/C++ projects trying to migrate to one of the C/C++ OSGi frameworks.

In this blog post, I will discuss the idea of OSGi Lite and how it may be translated to the Native OSGi world of C/C++ OSGi frameworks.

The OSGi Migration Problem

Large software systems usually consist of multiple components (in whatever form) having non trivial dependencies. Modularization promises better encapsulation and re-use of components as well as cleaner dependency management. Using an established framework like OSGi which is especially designed for enabling the creation of modularized applications seems like a no-brainer.

However, modularization itself is hard and the transition of an existing code base to OSGi is a complex task. This has been discussed a lot in the past, for example here:

OSGi Discontent - No Migration Path! (25/3/09)
OSGi - Feast or Famine? (13/4/10)
OSGi: Complexity is NOT the Problem (15/4/10)
OSGi? No Thanks (9/11/10)

Arguably the biggest obstacle when transitioning an existing Java application to OSGi is the (possible) existence of class loader hacks. Another one is the fact that OSGi tends to expose the inherent complexity of a code base, leading to the false impression that OSGi increases complexity instead of helping to manage it.

Usually, the reason for a project to move to OSGi is to achieve cleaner modularity by controlling the visibility of Java packages between bundles. This is where OSGi excels with its module layer specification. A second typical reason is the desire to use the OSGi service layer to realize a service oriented architecture. Unfortunately, the service layer is tightly coupled to the module layer. This means that in order to benefit from OSGi principles, you have to completely migrate your project to OSGi. While this might pay off in the long run, it is not a smooth migration path and might even be a show-stopper because of possible large refactoring requirements.

OSGi Lite to the Rescue?

People like the OSGi service layer so much that recently (in the year 2011) the idea of OSGi Lite started coming up again (here is another blog post from Peter Kriens about it). It essentially is a service registry (like specified in the OSGi specs) without an OSGi framework, especially without the module layer. A Java project based on this idea has been created by Karl Pauls, called PojoSR (Pojo Service Registry). You might also be interested in these slides: PojoSR or (OSGi) uServices for the rest of us.

By not requireing a running (OSGi) framework, the OSGi service layer can now be put to good use in existing projects step-by-step. After having converted direct method calls between Jar files to a service model, the migration to a full blown OSGi framework should be much smoother.

In my previous post about existing C/C++ OSGi frameworks I ranted about the lack of a C/C++ OSGi community. There are certainly many reasons for that: Most frameworks are still rather young and the target audience is not the average Joe programmer. Another reason I can think of is that C/C++ programmers tend to be more conservative in a sense that introducing a new framework (requiring Inversion of Control) needs much more convincing. However, the OSGi module layer solves a Java specific problem which does not directly map to C/C++. In C/C++, the visibility of symbols defined in shared libraries can be effectively controlled by various means (for example on Windows, all symbols are hidden by default anyway). The symbol search path for each library is determined by the link-time dependencies (in reality, it may be a bit more complicated), as opposed to the global class path in Java. Symbol versioning is still a problem, but many projects have full control over the set of deployed libraries and may not need that level of complexity. Let alone the need for a dynamic module system or updates at runtime. These projects would probably benefit the most from a C/C++ OSGi framework without the module layer. This is what the C++ Micro Services library aims to provide.

C++ Micro Services

The C++ Micro Services library is to C++ roughly what PojoSR is to Java. It provides a full implementation of the OSGi service layer and just enough of the module layer to be able to create a module context for each shared or static library. It leaves the handling of library/symbol dependencies and loading of libraries at runtime completely to the dynamic linker of the operating system.

Originally, the main motivation for creating the C++ Micro Services library was the need to gain control over the life-cycle and dependencies of singletons in an existing large code base I was working on. Over the years, the number of singletons grew and dependencies between them were introduced, which lead to a static (de-)initialization order fiasco. Migrating the whole code base to a OSGi-like C++ framework to replace singletons with services was not an option (due to several reasons) but the power of the OSGi service model was still intriguing. After realizing that a complete OSGi framework would probably be overkill for now anyway, we decided that having just the service layer available would be a perfect match for our needs. Building upon our experience in developing the CTK Plugin Framework (a Qt-based C++ OSGi framework), creating the C++ Micro Services library took just a couple of weeks.

Using the library is as simple as using any other C++ library. There is no need to call certain methods to start a framework or to think about deployment issues. Here is a simple code snippet demonstrating how to register and query service objects:

#include <SomeInterface.h>
#include <usGetModuleContext.h>

class MyService : public us::Base, public SomeInterface
{
  void DoSomething() { std::cout << "My service implementation"; }
};

void RegisterService(MyService* myService)
{
  us::ModuleContext* context = us::GetModuleContext();
  context->RegisterService<SomeInterface>(myService);
}

void UseService()
{
  us::ModuleContext* context = us::GetModuleContext();
  
  // Get the highest ranking service, if any
  us::ServiceReference serviceRef = context->GetServiceReference<SomeInterface>();
  if (serviceRef)
  {
    SomeInterface* service = context->GetService<SomeInterface>(serviceRef);
    if (service)
    {
      service->DoSomething();
    }
  }
}

Note that the service implementations base class us::Base can actually be any class, specified during the configuration of the C++ Micro Services library. For details, please see the Build Instructions.

Hopefully, the C++ Micro Services library will lower the adoption barrier for a OSGi service model. If a project later on realizes that it needs a full blown C++ OSGi framework, the migration should be more straight-forward.

OSGi and C++

2012-03-29T00:00:00-07:00

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
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 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 (?)¹
SOF	Linux, Windows	BSD (?)²	C++	2008
CTK	Linux, Windows, Mac OS	Apache License 2.0	C++	2009
nOSGi	POSIX	GPLv3	C++	2009
Celix	Linux³	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 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)¹
CTK	Yes (RFC1960)	Yes/Yes	Yes	Yes	Yes
nOSGi	(Yes)² (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 argument to 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 OSGi specifications can vary a lot from project to project.

	Implemented OSGi Specifications	Planned
Poco OSP	(Preferences, User Admin, Http, Remote Services)¹	?
SOF	Remote Services	?
CTK	Event Admin, Configuration Admin, Metatype Service, Log Service	Remote Services
nOSGi	-	?
Celix	Log Service, (Deployment Admin, Remote Services)²	?

¹ While the Poco OSP provides these functionalities in terms of services, they do not seem to comply with the OSGi specifications.
² 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.

Introduction

2012-03-19T00:00:00-07:00

The C++ micro Services Blog will contain posts about my current technological interests and research.

This includes, but is not limited to, programming languages, software design, and component and service oriented architectures.

Stay tuned for the next post, which will try to give an overview about the state of current efforts of implementing the OSGi specifications (which were written specifically for Java) in C++.