ORE Studio Messaging Reference
Table of Contents
All inter-service and client-server communication in ORE Studio uses NATS with JSON payloads. The transport library is ores.nats (request/reply pattern, subject naming convention, queue groups, JetStream). This page is the cross-service namespace index; each row links to the full subject inventory for that service.
Services
Each domain service owns a subject namespace.
| Service | Subject Namespace | Messaging Reference |
|---|---|---|
| ores.iam | iam.v1.> |
ores.iam Messaging Reference |
| ores.refdata | refdata.v1.> |
ores.refdata Messaging Reference |
| ores.variability | variability.v1.> |
ores.variability Messaging Reference |
| ores.assets | assets.v1.> |
ores.assets Messaging Reference |
| ores.telemetry | telemetry.v1.> |
ores.telemetry Messaging Reference |
| ores.dq | dq.v1.> |
ores.dq Messaging Reference |
| ores.trading | trading.v1.> |
ores.trading Messaging Reference |
| ores.scheduler | scheduler.v1.> |
ores.scheduler Messaging Reference |
| ores.synthetic | synthetic.v1.> |
ores.synthetic Messaging Reference |
| ores.reporting | reporting.v1.> |
ores.reporting Messaging Reference |
Cross-cutting / generic subjects
Every subject must live inside its owning component's namespace, even a generic subject shared conceptually by every entity across every service. There is no bare, ownerless top-level namespace.
The concrete failure mode this rule guards against: ores.history.core
originally exposed one shared subject, history.v1.get, for every
entity's generic history lookup, dispatched by an entity_type field
in the request body rather than the subject itself. Because every
service subscribes under its own queue group, and multiple queue
groups on the same subject each receive their own copy of the
message, this fanned every history request out to every service at
once. Only the service that actually owned the requested entity_type
had a matching provider; every other service replied "not found"
almost instantly (no DB round trip), which usually won the
request/reply race against the owning service's slower, correct reply
— so the client saw the wrong service's error essentially every time,
regardless of how correct the owning service's own logic was.
The fix: the subject is scoped per owning component,
<component>.v1.history.get (e.g. dq.v1.history.get), computed from
the request's entity_type via
ores::history::messaging::history_subject_for(). Only the owning
component's registrar subscribes to its own subject, so a request is
delivered to exactly one recipient — no fan-out, no race. Any future
generic/cross-entity subject must follow the same shape.
See also
- ores.nats — transport library: request/reply, subject naming, queue groups, JetStream.
- NATS — the upstream messaging technology this is built on.
- System Model — overall system architecture.
- ores.cpp.protocol — the literate templates that generate the protocol facet.