1 Overview

Messaging in CEDA is a stack of deliberately separate concerns. At the architectural level, durable application items belong in databases while messages are transient byte sequences used to move those items between processes. At the transport level, TCP connections carry framed, ordered messages without assigning application meaning to their contents. At the invocation level, calls on an interface can be encoded into those messages and replayed on another object.

Keeping these concerns separate is important. Persistence, recovery, causal ordering, and exactly-once processing are properties of the participating databases and their protocols; they are not obtained by inserting a durable message broker between them. The transport libraries can therefore remain small and fast, while higher layers define the meaning and recovery rules for the items being exchanged.

The document first develops this messaging model and its use of transient and persistent queues. It then describes two generations of TCP transport. cxMessage is the original design and includes message identifiers and multiplexing. cxMessage2 is the revised, lower-level Boost.Asio design; it deliberately leaves message identifiers and multiplexing to the layer above it.

The final parts describe two related invocation facilities. cxRmi is an end-to-end remote method invocation system built on the original multiplexed transport. cxRpc isolates the more general operation of efficiently recording and replaying interface method invocations: its buffers may be sent over a network, persisted, or replayed locally. The implementation part retains design notes, benchmark material, and source snapshots needed to understand those libraries.