Skip to content
EN FR

Message-Oriented Middleware Service

Documentation status: architecture — see Maturity and evidence.

Purpose

The messaging service family provides asynchronous communication between producers, consumers, runtime processes, and external infrastructure. It is appropriate when work must cross an execution boundary without coupling the producer to a synchronous call.

Positioning

producer
   -> message / event
   -> queue or broker boundary
   -> consumer
   -> application or Runtime operation

Messaging is different from an in-process .NET channel: use host channels for local producer/consumer pipelines, Runtime channels for Runtime execution elements, and message-oriented middleware when work must survive or cross a process, node, or infrastructure boundary.

Public design rules

  • define the message contract independently from a broker-specific API;
  • make delivery assumptions explicit;
  • handle duplicate delivery where retries are possible;
  • bound or monitor queue growth;
  • propagate correlation and trace context;
  • define dead-letter or rejection behavior when supported;
  • drain or abandon work according to an explicit shutdown policy.

Broker adapters

A deployment may use a broker-specific adapter. The broker product, protocol, queue names, credentials, and connection topology are deployment concerns and must not leak into domain semantics.

Configuration status

Historical internal queue classes and module names are not public API. Concrete broker configuration must be validated against the installed Runtime/module version.