OSGi Lite for C++

青旅半醒 2023-06-02 10:52 4阅读 0赞

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 basewith complex dependencies to an OSGi based system. This applies both to Java projects as well as C/C++ projectstrying to migrate to one of the [ C/C++ OSGi frameworks][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* worldof 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 establishedframework 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 beendiscussed a lot in the past, for example here:

*  [OSGi Discontent - No Migration Path!][OSGi Discontent - No Migration Path] (25/3/09)
 *  [OSGi - Feast or Famine?][OSGi - Feast or Famine] (13/4/10)
 *  [OSGi: Complexity is NOT the Problem][OSGi_ Complexity is NOT the Problem] (15/4/10)
 *  [OSGi? No Thanks][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 impressionthat 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 thevisibility 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, youhave to completely migrate your project to OSGi. While this might pay off in the long run, it is not a smooth migrationpath 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*][OSGi Lite] started coming up again (here is[another blog post][] from Peter Kriens about it). It essentiallyis a service registry (like specified in the OSGi specs) without an OSGi framework, especially without the module layer. A Javaproject 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][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 fullblown OSGi framework should be much smoother.

In my previous post about existing [ C/C++ OSGi frameworks][C_C_ OSGi frameworks] I ranted about thelack of a C/C++ OSGi community. There are certainly many reasons for that: Most frameworks are still rather young and thetarget audience is not the average Joe programmer. Another reason I can think of is that C/C++ programmers tend to be moreconservative in a sense that introducing a new framework (requiring [ Inversion of Control][Inversion of Control]) needs much more convincing. However, the OSGi module layer solves aJava specific problem which does not directly map to C/C++. In C/C++, the visibility of symbols defined in shared librariescan be effectively controlled by various means (for example on Windows, all symbols are hidden by default anyway). The symbol searchpath 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 stilla problem, but many projects have full control over the set of deployed libraries and may not need that level of complexity. Let alone theneed for a dynamic module system or updates at runtime. These projects would probably benefit the most from a C/C++ OSGi framework withoutthe module layer. This is what the [ C++ Micro Services][C_ Micro Services] library aims to provide.

## C++ Micro Services ##

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

Originally, the main motivation for creating the C++ Micro Services library was the need to gain control over the life-cycleand dependencies of singletons in an existing large code base I was working on. Over the years, the number of singletons grew and dependenciesbetween them were introduced, which lead to a static (de-)initialization order fiasco. Migrating the whole code baseto a OSGi-like C++ framework to replace singletons with services was not an option (due to several reasons) but the power ofthe 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 indeveloping the [ CTK Plugin Framework][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 orto 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++ MicroServices library. For details, please see the [ Build Instructions][Build Instructions].

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

[C_C_ OSGi frameworks]: http://blog.cppmicroservices.org/2012/03/29/osgi-and-c++/
[OSGi Discontent - No Migration Path]: http://techdistrict.kirkk.com/2009/03/25/osgi-discontent-no-migration-path/
[OSGi - Feast or Famine]: http://java.dzone.com/articles/osgi-feast-or-famine
[OSGi_ Complexity is NOT the Problem]: http://techdistrict.kirkk.com/2010/04/15/osgi-complexity-is-not-the-problem/
[OSGi_ No Thanks]: http://blogs.mulesoft.org/osgi-no-thanks/
[OSGi Lite]: http://www.osgi.org/blog/2011/04/osgi-lite.html
[another blog post]: http://www.osgi.org/blog/2011/04/osgi-lite_05.html
[PojoSR]: http://code.google.com/p/pojosr/
[PojoSR or _OSGi_ uServices for the rest of us]: http://www.slideshare.net/OSGiUsers/pojosr-or-osgi-services-for-the-rest-of-us
[Inversion of Control]: http://stackoverflow.com/questions/3057526/framework-vs-toolkit-vs-library
[C_ Micro Services]: http://cppmicroservices.org/
[CTK Plugin Framework]: http://www.commontk.org/index.php/Documentation/Plugin_Framework
[Build Instructions]: http://cppmicroservices.org/doc_latest/BuildInstructions.html