Messaging

The main feature of devel.one is the use of messages.

By the word message, we mean a specialized class consisting of two parts: An envelope that determines the properties of the message and the user data, consisting of one or more records.

We send messages back and forth between objects. So we do not use indirect messaging via queues, and messages are not stored anywhere if the receiver is not available. They are very short-lived, mostly they don't even exist for a millisecond.

Messages are always directed, that is, they have a sender and a receiver. Both sender and recipient have an address similar to a postal address. We distinguish the request (I want to have something, send me an answer) from the notification (information). This only serves to better understand the purpose of a message. Finally, the two message types differ only in one bit (wantAnswer). In the case of an error (on the way, during delivery, during processing by the recipient, during exceptions, etc.) the message is sent back anyway. The system automatically returns the message. The recipient fills only a result code and/or a result text (for logging). The sender can easily check whether a message has been handled by the recipient, since in this case the messages are assigned the result code NOT_HANDLED. If this code is present in the answer, the result code was not set by the receiver (not good!) or the message is not handled (State Machines!).

The system can use the address to find the recipient of the message directly, and no further information is required for delivery. The receiver can also be located on another NODE within the peer-to-peer network. For more information about messages, see here.

The receivers of messages are arranged hierarchically in the system:

  • Targets

    Targets are the objects that can receive and process messages. They are very simple, and have an ID, the target ID, in short TID.

    Targets always get the messages in the same thread, an effective way to avoid problems with concurrency. A group of targets registered in the same thread can easily share resources (databases, files, collections, etc.) because they never access them at the same time.

    For more information about targets, see here.

  • Namespaces

    Namespaces are the next largest organizational unit. They are similar to applications, and have one or more threads. Targets are registered in namespaces and assigned to a specific thread.

    Namespaces also have an ID, the namespace ID (short: NID).

    For more information about namespaces, see here.

  • Kernel

    The devel.one NODE has a kernel with a namespace registry. The namespaces are registered here.

    NODES also have an ID, the NODEID.

    For more information about the kernel, see here.

The address of a target consists of Target ID, Namespace ID and NODE ID. This is enough to address each target in a devel.one network. And therefore, nothing can prevent the targets from being distributed across the network. The written notation of the address reads as follows: TID.NID.NODEID.

Targets implement micro-services, i. e. services for applications. There can be many of them, e. g. several thousand in a car navigation device. It is not necessary for the sender of a message to know the exact address of the target that offers the service. Services are registered in namespaces. To address a service, you send a message to a namespace (without TID, but with the record ID of the service). For more information on services, see here.

Observer can be attached to services. These are addresses of interested targets. All Observers will receive a copy of the message sent to the service. This makes it easy to implement a publish & subscribe process.

devel.one supports complex targets with state machines. Hierachical State Machines (HSM) represent the internal states of a target and ensure, for example, that only messages are processed which are to be processed in the current state. Messages can be rejected or stored until a task is completed (modal). The hierarchy helps to model the states according to UML.

Timers generate one-time or recurring messages.

With monitors, you receive notifications about the registration and deregistration of targets and services.