Overview of the Library

The main class of the library is the Kernel, or the interface IKernel. The library can be used by simply instantiating the class CKernel.

_images/KernelOutline.PNG

Targets

The class with which programmers work most often is the Target class. Targets can send and receive Messages. To make this possible, they are registered in the TargetRegistry. During registration, a target receives an ID, the Target ID (short: TID). It is possible to give targets a user-defined TID, but usually a random ID generated by the TargetRegistry is sufficient.

Targets are bound to a thread during registration. All the messages they receive during their lifetime will always be received in the same thread. Messages are never passed to the target at the same time, but are always processed one after the other. Therefore, there is no need to worry about problems of concurrency.

Services

Targets usually offer micro-services. For this purpose, they register so-called Services in a ServiceRegistry. The services have their own service ID (short: SID). In contrast to the TID, the SIDs are constant, documented and well known. In this way, services can also be used that are offered by third parties in devel. one-NODES.

It is always preferable to use services as an interface.

You can also register Observer, which will receive a copy of each message sent to a service. For this reason, services are also used for event passing, where a message is not intended for a specific recipient, but for a group of interested parties. Notifications are simply sent to a dedicated service and all interested parties receive copies of the notification.

Namespaces

Since several instances of the same application can be executed in a devel. one NODE, a TID alone is not sufficient for the complete identification of a target. Therefore, there are so-called Namespaces, which encapsulate an application. Each namespace receives its own ID, the namespace ID (short: NID) when it is registered.

Each namespace has a target registry, to which targets can be registered. Since namespaces can also have several threads, the message queue ID (short: QID) must also be specified when registering a target. If not specified here, the target is registered for the first thread.

Namespaces also have a service registry. Services are therefore always specific to a namespace.

The devel. one kernel always sets up a namespace SYSTEM on startup. If you want to run services that stand for the entire devel. one NODE, you can register the services in this namespace.

PlugIns register even more namespaces when they are loaded. In particular, this includes the namespace TRANSPORT for all communication services, TEST for test frameworks and MONITOR for the tool user interfaces.

Kernel

Namespaces are registered in a NamespaceRegistry, which belongs to the Kernel. The kernel also has several other subsystems:

  • The TimerManager sends the targets messages after a period of time has elapsed. Timers can also be triggered repeatedly, deleted before expiration and they can also carry data.
  • The ListenerRegistry implements the Observer/Observable Pattern for all targets. Since targets and connections can be omitted in a dynamic system, this service tracks all involved targets. This prevents sending notifications to Observer that have already been deleted.
  • The message database is a catalog of all known messages and is used, for example, by the logging subsystem to give a name for messages and parameters. It is also responsible for registering services at the startup.
  • The NameDb is another name database. Especially IDs are associated with names.
  • The SignalRegistry manages synchronous low level signals and their observers. It also serves as a messaging basis in 1-thread environments such as the swing thread.
  • The data pool is a type of registry for variables that are accessed synchronously or asynchronously with keys. Here too, Observer can be used to be informed about changes of variables. It is also of central importance for the configuration.

Messages

Messages are the central instrument of communication in devel.one. A message transports various data, which is held in so-called Records. Records consist of an ID and Slots (the payload). Usually, a message contains only one record.

The slots of the records are stored in a HashMap, which is accessed via a SlotKey. The SlotKey consists of two IDs. Thus, the access is similar to that in the Windows registry, with Path+Key=Value.

There are currently about three dozen types of slots:

  • Low level types like Boolean, Byte, Char, Short, Integer, Long, String, Float, Double and their arrays
  • composite types like IDs, TargetAddress, GUID etc. and their arrays

Messages are very small (binary) when packed. They are also platform-independent, as their composition is documented. In addition, messages are compressed and sent in encrypted form.