An OSGi-like C++ dynamic module system and service registry
C++ CMake Python HTML JavaScript CSS
Permalink
Failed to load latest commit information.
cmake Require CMake 3.2 again. Jan 18, 2017
doc Added piwik tracking code for docs. Feb 8, 2017
framework Prevent snippets from crashing when being run. Feb 13, 2017
httpservice Update bundle versions. Feb 6, 2017
shellservice Update bundle versions. Feb 6, 2017
third_party Clean up copyright file header. Feb 6, 2017
tools Clean up copyright file header. Feb 6, 2017
webconsole Do not inherit from a class template to avoid Windows warnings. Feb 7, 2017
.gitignore Initial sphinx documentation plus CMake bug fixes. Jan 18, 2017
.travis.yml Test CI with OS X (#136) Sep 7, 2016
CHANGELOG.rst Fix changelog release dates and rtd doc badge. Feb 8, 2017
CMakeLists.txt Require CMake 3.2 again. Jan 18, 2017
CODEOFCONDUCT.rst Initial sphinx documentation plus CMake bug fixes. Jan 18, 2017
CONTRIBUTING.rst Initial sphinx documentation plus CMake bug fixes. Jan 18, 2017
COPYRIGHT Fixed project url Mar 1, 2016
CTestConfig.cmake Initial commit Feb 28, 2012
CppMicroServicesConfig.cmake.in Use CMake usage requirements, bump CMake version to 3.1. Jan 18, 2017
CppMicroServicesConfigVersion.cmake.in Initial sphinx documentation plus CMake bug fixes. Jan 18, 2017
LICENSE Added LICENSE file and explicit link in README.md. Jan 3, 2013
README.rst Fix changelog release dates and rtd doc badge. Feb 8, 2017
VERSION Bump dev version to 3.1.0. Feb 8, 2017
appveyor.yml Enable Windows release builds again. Nov 18, 2016
conf.py Add / improve bundle documentation for web console and in general. Feb 6, 2017
index.rst Add anchors for individual toc trees. Feb 9, 2017
install_cmake.sh Be more conservative on Travis VMs when compiling CMake. Jan 19, 2017
valgrind_suppressions.txt Clean up valgrind suppression file. Nov 18, 2016
valgrindrc Integrated memcheck and helgrind unit tests. Nov 6, 2015

README.rst

Continuous Integration Status

Branch GCC 4.6 Visual Studio 2013
XCode 6.4 Visual Studio 2015
XCode 7.3 MinGW-w64
master Linux Build Status Windows Build status
development Linux Build Status (development) Windows Build status (development)

Coverity Scan Build Status

C++ Micro Services

Documentation Status (stable) Documentation Status (development)

Download

Introduction

The C++ Micro Services project is a collection of components for building modular and dynamic service-oriented applications. It is based on OSGi, but tailored to support native cross-platform solutions.

Proper usage of C++ Micro Services patterns and concepts leads to systems with one or more of the following properties:

  • Re-use of software components
  • Loose coupling between service providers and consumers
  • Separation of concerns, based on a service-oriented design
  • Clean APIs based on service interfaces
  • Extensible and reconfigurable systems

Requirements

None, except a recent enough C++ compiler. All third-party library dependencies are included and mostly used for implementation details.

Supported Platforms

The library makes use of some C++11 features and compiles on many different platforms.

Minimum required compiler versions:

  • GCC 4.6
  • Clang 3.1
  • Clang from XCode 6.4
  • Visual Studio 2013

Below is a list of tested compiler/OS combinations:

  • GCC 4.6.3 (Ubuntu 12.04) via Travis CI
  • GCC 6.2.1 (Fedora 25)
  • Clang 3.8.0 (Fedora 25)
  • Clang XCode 6.4 (OS X 10.10) via Travis CI
  • Clang XCode 7.3 (OS X 10.11) via Travis CI
  • Visual Studio 2013 via Appveyor
  • Visual Studio 2015 via Appveyor
  • Visual Studio 2017 RC (Windows 7)
  • MinGW-w64 via Appveyor

Legal

The C++ Micro Services project was initially developed at the German Cancer Research Center. Its source code is hosted as a GitHub Project. See the COPYRIGHT file in the top-level directory for detailed copyright information.

This project is licensed under the Apache License v2.0.

Code of Conduct

CppMicroServices.org welcomes developers with different backgrounds and a broad range of experience. A diverse and inclusive community will create more great ideas, provide more unique perspectives, and produce more outstanding code. Our aim is to make the CppMicroServices community welcoming to everyone.

To provide clarity of what is expected of our members, CppMicroServices has adopted the code of conduct defined by contributor-covenant.org. This document is used across many open source communities, and we believe it articulates our values well.

Please refer to the :any:`Code of Conduct <code-of-conduct>` for further details.

Quick Start

Essentially, the C++ Micro Services library provides you with a powerful dynamic service registry on top of a managed lifecycle. The framework manages, among other things, logical units of modularity called bundles that are contained in shared or static libraries. Each bundle within a library has an associated :any:`cppmicroservices::BundleContext` object, through which the service registry is accessed.

To query the registry for a service object implementing one or more specific interfaces, the code would look like this:

#include "cppmicroservices/BundleContext.h"
#include "SomeInterface.h"

using namespace cppmicroservices;

void UseService(BundleContext context)
{
  auto serviceRef = context.GetServiceReference<SomeInterface>();
  if (serviceRef)
  {
    auto service = context.GetService(serviceRef);
    if (service) { /* do something */ }
  }
}

Registering a service object against a certain interface looks like this:

#include "cppmicroservices/BundleContext.h"
#include "SomeInterface.h"

using namespace cppmicroservices;

void RegisterSomeService(BundleContext context, const std::shared_ptr<SomeInterface>& service)
{
  context.RegisterService<SomeInterface>(service);
}

The OSGi service model additionally allows to annotate services with properties and using these properties during service look-ups. It also allows to track the life-cycle of service objects. Please see the Documentation for more examples and tutorials and the API reference. There is also a blog post about OSGi Lite for C++.

Git Branch Conventions

The Git repository contains two eternal branches, master and development. The master branch contains production quality code and its HEAD points to the latest released version. The development branch is the default branch and contains the current state of development. Pull requests by default target the development branch. See the :ref:`CONTRIBUTING <contributing>` file for details about the contribution process.