[boost] [gsoc2008] interest for component library?

From: Themis Bourdenas (bourdenas_at_[hidden])
Date: 2008-03-19 12:57:13

Hi, I want to propose a project for participation in Google SoC 2008
with boost. My proposal is a software component library for C++. The
goal is the creation of a library that assists component based
software development, bringing a well defined, existing model to C++.
Is there any interest for such a library?

nesC is an extension to the C language developed in UC Berkeley to
support development in real-time embedded systems running tinyOS. The
extensions to the C language are around the notion of
components/modules and their orchestration (configuration) in order to
deploy a running application. They use a meta-compiler that transforms
nesC code to ANSI C, which then actually runs on the motes. Of course
the nesC programming model is not tied to real-time systems and
translates in large systems as well. My proposal is to provide the
same model in a C++ library, without the need of a meta-compiler, but
providing a DSEL.

If you are unfamiliar with nesC, you can find more in
http://nescc.sourceforge.net/, but below I'll give a quick overview
and glossary of the terms used in the model and how they can translate
in C++.
- interface -- an abstract class that defines an API contains commands
and events
- module -- a class that is a concrete implementation of one or more
interfaces, it provides and uses one or more interfaces
- provide -- the relationship of a module that provides an interface
is similar to the inheritance relationship, the module implements the
interface's declared commands and triggers its declared events
- use -- a module that uses an interface implies that it requires the
existence of a module that implements that interface
- command -- an exported function declared in an interface,
implemented by a module
- event -- a signal declared in an interface, fired by a module
- configuration -- a specification of wiring (mapping) of modules to
interfaces, constructing an entity that can be considered as a
composite module (aka orchestration of components)
- wiring -- instantiation of a module and attachment to an interface
that is used by another module or configuration

The benefits of component based development are obvious; clean
architectural dissemination of software, self-containment of modules
and orchestration of new services and applications based on already
existing ones. I have adjusted the basic concepts behind nesC as
presented in its web site to translate to general programming:
- separation of construction and composition: programs are built out
of components, which are assembled ("wired") to form whole
applications.
- specification of component behavior in terms of set of interfaces.
Interfaces may be provided or used by components. The provided
interfaces are intended to represent the functionality that the
component provides to its user, the used interfaces represent the
functionality the component needs to perform its job.
- interfaces are bidirectional; they specify a set of functions to be
implemented by the interface's provider (commands) and a set of
signals fired to the interface's user (events). This allows a single
interface to represent a complex interaction between components (e.g.,
registration of interest in some event, followed by a callback when
that event happens).
- components can be statically linked to each other via their
interfaces, furthermore components should be linked dynamically (at
run-time) allowing modification of program's behavior.
Below I give an example of orchestration for an IDE application where
you want to setup the environment to handle C++ sources. Setup
compilers, source documents, runtime env, source editor etc.

configuration cpp_ide {
    module<ide>.interface<Compiler> -> module<gcc>
    module<ide>.interface<SourceFile> -> module<CppSource>
    module<ide>.interface<Editor> -> module<CppEditor>
    module<ide>.interface<Output> -> module<Console>
}

In the above simple example we create a configuration of the ide
module, namely cpp_ide, wiring its interfaces to some implemented
modules. The notation of module<> and interface<> is to help you
distinguish between different entities. Alternatively, you could setup
the environment for e.g. python given that you implement the proper
modules, reusing code from some common modules (e.g. console and the
ide infrastructure). I want to support both static configurations like
this and dynamic configuration, (e.g. setup an environment depending
on configuration files).

Of course the true benefits of components come from the fact that they
can be dynamically loaded at runtime. I intend to use the
boost.extension library, which seems to have reached a stable state,
for facilitating this requirement. That would require components to
just depend on interfaces instead of actual implementation. In
addition, I want to expand the library to interoperate with
boost.reflection so that a module's interface can be wired with an
arbitrary module as long as it provides the functional requirements
set by the interface. In the latter case detection of
incompatibilities between modules (i.e. missing functions) are
postponed and handled during runtime, as they can not be resolved
statically.

So, please give me some feedback on whether such a library would be an
interesting contribution to boost and if you want me to elaborate on
my ideas for the project.

Cheers,
Themis