Overview
Command Execution Extension service (CEX) extends the communication capability of Kaa Protocol (1/KP) by implementing Command Execution Protocol (11/CEP). CEX supports this extension protocol to deliver commands to endpoint and consume endpoint command execution result. As with other Kaa extension services, CEX uses Extension Service Protocol (4/ESP) for integration with a communication service.
Commands are provided by command invocation caller. CEX implements a proactive command push—commands are sent to an endpoint as soon as possible, and an explicit endpoint subscription is not required. Note that explicit subscription is still recommended.
Interfaces
CEX supports a number of interfaces to perform its functional role. The key supported interfaces are summarized in the following diagram.
For inter-service communication, Kaa services mainly use REST APIs and messaging protocols that run over NATS messaging system.
Command invocation protocol
CEX acts as a command invocation agent according to 12/CIP. This protocol is used to accept command invocation request and return command invocation result back to command invocation caller.
Extension service protocol
CEX uses 4/ESP over NATS to exchange 11/CEP messages with endpoints through a communication service.
Command store
In some scenarios, endpoint can be inaccessible during command invocation request emission, thus it will not get a message with a command.
CEX persists commands for a configurable amount of time. So endpoint has an ability to request already scheduled commands.
The command store is maintained in Redis.
Command execution flow
The overall command invocation and execution sequence diagram can be illustrated as follows:
