Services

C3: Component Diagram for Service Design

Each service follows the same architecture pattern. It contains:

• A proxy to manage inbound/outbound requests received/sent from/to others services or application
• All these requests are split up into 2 groups:
  • Generics for common primitives managed by a service (see table below).
  • Functions for specific primitives exported by a service (see each service api).
• A data model used to store service's data and states.

A proxy and its api are defined in common.h. Each service exposes a set of generic functions, plus a series of specific ones corresponding to its functional role. When Moka is launched, all services need to be registered to the message broker by an orchestrator. The orhestrator plays a global role in the architecture essentially to set initial conditions. A service's proxy basically receives requests from the message broker, and sends backs responses. As a rule, service proxy shall raise only service level errors. Functions' errors are collected by proxy and forwarded through a specific outbound variable that the message broker will forward to the calling level.

Service's Generics

Generic	Identifier	Description
GENERIC_SERVICE_GET_NAME	0x01	Service name
GENERIC_SERVICE_GET_IDENTIFIER	0x02	Unique service type on 1 byte
GENERIC_SERVICE_GET_VERSION	0x03	Stringify version
GENERIC_SERVICE_GET_CHECKSUM	0x04	Checksum on 20 bytes
GENERIC_SERVICE_SETUP	0x05	To be called only once at the beginning of a lifecycle
GENERIC_SERVICE_INITIALIZE	0x06	May be called before of each transaction
GENERIC_SERVICE_SET_PARAMETERS	0x07	Set service data model's state
GENERIC_SERVICE_GET_PARAMETERS	0x08	Get service data model's states
GENERIC_SERVICE_CLEANUP	0x09	May be called after of each transaction
GENERIC_SERVICE_RELEASE	0x0A	To be called only once at the end of a lifecycle