Distinct Endpoints in One Program
In the two preceding examples, each program used only one endpoint. In this third example, we consider a reason that a program might need more than one endpoint.
An endpoint allows a program to access transports so a program can communicate over a rich set of technologies without specifying their arrangement. To a program, an endpoint is like a tap into a message stream. A program with more than one endpoint reflects the need to tap into more than one message stream.
In the preceding diagram, a stock market data feed (Feed) sends a message stream (Inform) that consists of many small messages, produced at high speed, containing time-sensitive data such as trades, buy offers and sell offers. It is crucial that the subscribers (Trade) receive these messages with minimal latency, and act without delay.
As a result of those actions, Trade produces two message streams. Like the Inform stream, the Execute stream is time-sensitive.
In contrast, the Report stream is not time-sensitive. Its messages satisfy regulatory reporting requirements. It is crucial that subscribers (Rpt) receive and process these messages, but speed is not as important. However, it is critical that the Report stream not interfere with the Execute stream, nor slow it in any way.
The architecture of the Trade program reflects these requirements with three separate endpoints:
- EP2 for the inbound Inform stream
- EP3 for the outbound Execute stream
- EP4 for the outbound Report stream
The administrator deploys the programs and arranges transports to satisfy the performance requirements. The Inform and Execute streams require minimal latency, while the Report stream can use a slower transport technology.