CLAID ModuleAPI

The ModuleAPI is the core component of CLAID, that all higher level functionality (e.g. Collectors, MLAlgorithms) is based upon. The ModuleAPI provides different functionalities that are realized in separate components, which you can see in the following image.

_{Fig. 1: Components of the ModuleAPI.}

What functionalities does the ModuleAPI provide ?

The following sections provide a brief overview of components/functionalities provided by the ModuleAPI. For detailed explanations, descriptions and implementation details, please check the following subpages (you can also choose the component you are interested in in the picture above).

Modules

Center piece of the ModuleAPI are, of course, Modules. Modules are indepdent entities/objects, that can communicate with each other using Channels (see below). They can be seen as the "working units" of an application. Using CLAID, applications are built by combining different Modules.

As quick reference, please note the following statements.

Most important aspects of Modules

• Modules can subscribe to and publish any amount of Channels.
• Modules can be passive (e.g., only react based on data they receive) or active (e.g., continuously recording Microphone audio data). Of course, they also can be both at the same time.
• Modules can run tasks at a specific intervall rate (periodic code).
• Modules can execute blocking code, however during that time are not able to receive data from Channels (see blocking code in the Module subpage).
• Modules run in their own thread
• Modules can spawn SubModules, that either run in the same or in another independent thread.
• Configuration: Usually, Modules are loaded when CLAID is started. Which Modules to load can be specified in XML configurations
  • Modules can have properties (e.g. internal private variables), which can be specified when loading a Module; their values can be set in the XML configuration aswell.
  • No code needs to be written in order to load Modules. Different Modules can easily be combined by writing an appropriate XML configuration.

Communication

The ModuleAPI implements Channels, that allow to sent arbitrary data types between Modules. Communication can happen locally or remotely. From a user's perspective, there is no difference between local or remote communication when using the API. In both cases, data is posted to channels. If there are multiple CLAID instances connected to each other, data posted to a Channel is automatically tunelled if necessary. That means, if data is posted to a Channel in one instance of CLAID, it is automatically sent (in the background) to any other remotely connected instance of CLAID, as long as any Module in that remote instance has subscribed to the Channel aswell. In other words: Remote communication happens automatically in the background, if a Module running in another instance of CLAID has subscribed to a Channel that data was posted to in any other connected instance of CLAID. Data in Channels that have subscribers only in one instance, but not in the other, will not be sent remotely.

De-/Serialization

De-/Serialization allows to automatically convert data types (classes, structs, primitives) between different representations. For example, a custom class could be represented in XML.), binary or others. See the example below.

De-/Serialization example

Class representationXMLBinary/Hexadecimal

class Person
{
    private:
        string name = "Einstein";
        int age = 42;
        string profession = "Researcher";

    public:
        template<typename Reflector>
        void reflect(Reflector& r)
        {
            r.reflect("Name", name, "Name of the person");
            r.reflect("Age", age, "Age of the person");
            r.reflect("Profession", profession, "Profession of the person");
        }
}

<Person>
    <Name>Einstein</Name>
    <Age>42</Age>
    <Profession>Researcher</Profession>
</Person>

Byte-wise (hexadecimal) representation of the class.

Often, this requires to hardcode the serialization and deserialization methods, i.e. how to turn a object/class representation into an XML file. CLAID, however, employs a powerful reflection system, that allows implementation of automatic de-/serialization for arbitrary, complex datatypes. Currently, CLAID uses XML and binary de-/serialization. However, with CLAID's reflection system, the implementation of custom de-/serialization is easily possible.