An adapter and the service meet at four messages
Table of Contents
1. Summary
An adapter is a separate NATS service that reaches one provider through one route: a live session, a replay file, a test harness or a simulator. It meets the market data service at four messages. It announces itself. It answers a demand request. It publishes ticks. It sends a heartbeat. A live adapter and the simulator send the same four messages, and the service cannot tell them apart from the messages alone.
2. Detail
2.1. The four messages
| Message | Direction | Style | Subject |
|---|---|---|---|
| Announce | adapter to service | request and reply | marketdata.v1.adapters.announce |
| Demand | service to adapter | request and reply | marketdata.v1.adapters.<adapter>.demand |
| Tick | adapter to service | core NATS publish | marketdata.v1.ingress.<adapter>.<id token> |
| Heartbeat | adapter to service | core NATS publish, periodic | marketdata.v1.adapters.<adapter>.heartbeat |
- Announce carries the adapter id, the provider code, and the universe: the set of (id scheme, external id, field) the adapter can serve. The service checks the universe against the installed catalogue. See A system bundle installs the catalogue and the simulator installs its own universe.
- Demand carries the full set of external ids that the parties routed to this adapter need. The set replaces the last one. The adapter answers with the ids it accepts and the ids it rejects, each with a reason. See Demand drives what an adapter publishes.
- Tick carries the id scheme, the external id, the field, the value as decimal text, the vendor time and a per-adapter sequence number. It carries no oresmd URI, no tenant, no party and no source kind.
- Heartbeat carries the adapter id and a counter. A missed heartbeat makes
the adapter
stale. See The adapter lifecycle.
2.2. What an adapter must not do
- It must not publish an oresmd URI. Mapping is the service's job, so the mapping is the same for every source of one provider. See The mapping belongs to the provider and not to the source.
- It must not know a tenant or a party. It runs as a system service. See The identity an adapter runs as.
- It must not store anything. The service owns persistence.
- It must not publish an id it did not announce.
2.3. Why this seam
A narrow seam keeps the vendor translation in one place. A live Bloomberg
adapter turns blpapi subscriptions into ticks. Nothing behind the seam
changes when the adapter changes. The simulator therefore has to match the
seam only, and not the vendor protocol. See The simulator stops at the adapter seam.
3. See also
- Market Data Architecture — the structure note that orders this cluster.
- One service owns market data between the vendors and the parties — completes: the service on the other side of the seam.
- The adapter subjects — completes: the subject grammar and the token rule.
- Vendor adapters — exemplifies: what a live adapter adds behind the seam.
- The simulator stops at the adapter seam — answers: why the simulator stops at this seam.