Duration: 54:29

498 views

1

Simon Chemouil - Global Vision Systems

Context
In the Java ecosystem, OSGi has become the de facto standard to deal with modularity and dynamic components. After more than ten years of maturation, elegant techniques and models have been developed and are successfully in use: semantic versioning, fine-grained dependency management, simple yet expressive component models, and a modular core still simple.

Universal OSGi
Native C/C++ OSGi frameworks, an initiative dubbed "Universal OSGi", are bringing the OSGi platform and its service model to our bare operating systems. A few projects have implemented OSGi-like light containers for both C and C++, and an effort is starting to come up with common specifications.

Yet so far an important brick of the OSGi stack has been left aside: Declarative Services, a service component framework that comes with a simple component model, hides OSGi API concepts (and removes dependencies on all but business code), makes component testable and shields the developer from dealing too much with of the dynamism of µServices. All said, it's a formidable enabler and makes OSGi programming easy.

However, Declarative Services is a subtle mix of a service component model and dependency injection, and uses techniques such as reflection that are not available in C++.

Native C++ Declarative Services
This first part of this talk will be about our experience implementing Declaratives Services for C++! We will see why the Declarative Services specification makes sense for C++, how most technical limitations were overcome and which are still open. We will also address the challenge of designing C++ components to achieve modularity in a world without a garbage collector, and see how popular OSGi design patterns have to be adapted!

Universal Declarative Services with Model-Driven Development
Going ``Universal'' is a step further from just having separate Java and C++ implementations of Declarative Services: our long-term goal is to have components in both languages directly interacting through "bridged" services, so the chosen implementation language should be insignificant when designing the components. Model-driven development comes to the rescue!

Using the Eclipse Xtext meta-programming framework, we can easily define a small domain specific language capturing the essence of Declarative Services metadata. Components described in our ADL can then have their skeletons generated in Java or in C++ along with the required configuration.

This top-down, model-driven approach will be presented as one way to develop Universal OSGi systems, mixed with Java or C++ parts (and, later, other languages?!). During the second part of the talk we will see the toolchain -- and Eclipse IDE environment -- we developed, along with the Architecture Description Language (ADL) to make it easy to create components. During a live demo, we will see how C++ DS components can be generated and implemented easily without writing technical code.