Purpose
The purpose of this document is to record describe the functionality the Message Broker provides to the Router/API application in YOUnite MDM.
Ideally, this will be a thin facade that provides a YOUnite specific layer:
- for connecting to the message bus
- for sending messages on the message bus
- for receiving messages from the message bus
- for implementing asynchronous request-response protocol
- that enforces the authentication and authorizations
Requirements
Description
The functionality that the YOUnite Router requires from the Message Broker is relatively straightforward and is typical of most Message Bus systems. A Router is a component that is responsible for routing data throughout the ecosystem (and data transfer between adaptors). It is comprised of the Data Record Assembler and ACL Manager.
From the Router’s standpoint, the Message Bus Broker is the way the Router communicates with the Adaptors. There will be one queue set up for each adaptor for The Message Broker encompasses queues.
- When an adaptor is created, YOUnite creates one queue for it to receive incoming messages from the Router.
...
- This queue will be used for state and data messages.
...
- Each adaptor will have one queue for data and
...
- one queue for state
...
- , where it can put messages on to be sent to and received by the Router.
There will also be a Topic that all adaptors would subscribe to and that messages could be broadcast on for the Router to post messages on.
...
All adaptors subscribe to a Topic, which broadcasts messages that are posted there by the Router.
The Router uses one set of queues will be used by the router to maintain adaptor state, ; one of the these states is to effectively “pause” “pauses” the adaptor from processing data messages. In In order to achieve this, the MB will need to support Message Broker supports the temporary halting of delivery of certain types of messages. In In other words, it’s possible a queue may be put into a “paused_read-only” state where it should not process write messages, but should respond for any read requests for data.
Since an adaptor may be paused, data messages can queue up indefinitely. HenceHence, it will be highly desirable to be able to get information on the data queue Data Queue for a paused adaptor so a zone admin Zone Admin can see how many data messages have been queued up and are awaiting await processing.
So, to To summarize the Router will need the following:
Be able to connect Connects to the Message Broker and reestablish all reestablishes connections (i.e. resume resumes queue listeners) to durable but , dynamically-defined queues.
Create durable Creates data queues for each adaptor upon adaptor creation
Destroy durable Destroys data queues upon adaptor deletion
Be able to Can readMessage off a queue
Be able to Can postMessages to a queue
Be able to Can postMessage to a topic
Be able to Can temporarily halt delivery of certain types of messages
Be able to Can resume delivery of certain types of messages
Be able to Can inspect a queue (get overall stats--, such as messages in wait, longest wait in queue, etc.)
...