Skip to content
EN FR

Service Runtime Plane

Documentation status: architecture — see Maturity and evidence.

The Service Runtime Plane describes technical services surrounding the execution of a logiCells application: capability exposure, communication, messaging, synchronization, discovery, or adaptation to external systems.

This layer must be distinguished from business publication. A published action or collection is a model contract; a Runtime service provides a way to transport, host, route, or orchestrate that contract.

Positioning

application model
    -> published capabilities
    -> service adapter
    -> runtime service / transport
    -> process, node, site or external system

Three responsibilities not to confuse

Area Responsibility
Publication decide which model capabilities are exposed
Communication transport calls, messages, events, or streams across boundaries
Service Runtime Plane host, configure, and operate the required adapters and services

Service families

Depending on version and installed modules, the Runtime may be associated with several families:

  • HTTP / service endpoints;
  • messaging and external brokers;
  • channels or RPC;
  • discovery and registry;
  • synchronization;
  • WebSocket / interactive streams;
  • adapters to external systems.

The presence of a family in the architecture does not guarantee that a particular service type, configuration tag, or protocol is a stable public contract in every version.

Public contract vs internal configuration

Public documentation should prioritize:

  • the published capability;
  • observable behavior;
  • security requirements;
  • transport guarantees;
  • lifetime, retry, idempotency, and compatibility rules where applicable.

Private engine class names, uncertified historical configuration tags, and internal instantiation details are not public contracts.

Local and remote

The same programming model should preserve its business contracts when execution moves from a local Runtime to a remote boundary. Operational differences — latency, network errors, authentication, timeout, cancellation, or retry — must remain explicit.

Detailed pages

Pages under Service-types/ are published as architecture and operational patterns. They no longer expose historical internal classes or legacy tags as stable contracts. Exact configuration formats still need to be validated against the installed Runtime/module version.

Detailed service patterns