Runtime services, messaging and remote communication

Documentation status: guide. Service families and deployment topology are separate choices; not every architectural mechanism is a verified public API.

Select by communication contract

Need	Relevant Runtime boundary	Verify
Host an HTTP or service endpoint	Runtime service declaration and lifecycle	Request identity, authentication, error/status mapping
Execute against another Runtime	Remote channel and session instance	Open/close semantics, timeouts, contract parity
Exchange asynchronous messages	Message bus / MOM queues	Persistence, ordering, correlation, retry semantics
Synchronize data across peers	Data Synchronizer and journal/acknowledgment protocol	Causality, duplication, idempotence and recovery
Explore decentralized/P2P topology	Architectural/source-boundary guide	Actual availability and security evidence on chosen release

A channel definition may be activated and retained in application metadata while an individual channel instance is opened, used, closed and reset for one session. This distinction affects both concurrency and cleanup.

Failure and operational contracts

Do not interpret “message sent” as “business action completed.” Record correlation identities, define bounded timeouts and decide whether retry is safe. Commands with side effects require idempotence or a duplicate-detection contract. Queue acceptance, persistence and consumption are different acknowledgments.

Make communication topology observable: service endpoints, peer identity, queue pressure, connection state and shutdown phase. Treat distributed security and P2P sketches as architectural unless the target source/release verifies the path.

Read next

Runtime service model · HTTP example · Service families · Communication plane · Distributed architecture

LaTeX sources: remote-channels-and-service-endpoints.tex; message-bus-and-publish-subscribe.tex; communication-architecture-recipes.tex; distributed-data-synchronization.tex.