| Excerpt |
|---|
Messages are sent over the message bus. For optimal performance, messages may be sent over dedicated queues and topics. This page describes a suggested use of queues and topics. |
| Table of Contents |
|---|
Types of destinations
The destinations are split into different categories, inspired by Java JMS. There are four types of possible JMS destinations:
...
- Only one listener receives the message, like a queue
- Messages are not persistent (since the queue disappears with the client).
- Queue is generated by a client.
Concrete destinations in a
...
repository
The following sections documents the destinations used in the reference system architecture together with alternatives. Note all destinations in the reference system are architecture are local to a given collection, but the protocol supports cross-collection destinationsrepository.
The
...
repository topic
LISTENERS: Every component participating in a Collectiona Bit Repository.
MESSAGES: IdentifyPillarFor<Op>Request.
NAMING: "type:<collection<repository-id>"
DISCUSSION: This topic is the abstraction layer, that makes it possible to use the protocol with no knowledge of other participants. The destination is used to send the initial 'Identify...' requests used to start a conversation. See See Message flow documentation for details.
IMPLEMENTATION: The topic is defined in the Collection settingsthe RepositorySettings.
ALTERNATIVES:
- The collection topic might be used for other message types. It might in fact be used for all the messages in a collection, if the separation recommended here isn't necessary.
- It is possible to define dedicated topics for broadcasting pillar, audittrail and status specific requests in the RepositorySettings. This can be used to optimize the Identify request broadcast, so the requests are only distributed to the relevant components.
The per-pillar topic
LISTENERS: One specific pillar
MESSAGES: <Op>Request
NAMING: "type:<collection-id>.<pillar-id>"
DISCUSSION: This topic is the interface for requesting operations on a pillar.
IMPLEMENTATION: Pillar topics are identified through the IdentifyPillarFor<Op>Responses returned as a result of a IdentifyPillarFor<Op>Request.
GENERATION: These topics are generated for each pillar by the message bus administrator when a new Collection is setup.
ALTERNATIVES: It is protocol-safe to make a different choice for making pillar destinations on a per-pillar basis. This can be replaced with a queue or a temporary queue, and the naming is quite optional. A topic seems appropriate, since it will not have persistent messages lying around if the pillar is not available at the time of request. However, there could also be advantages of a queue, since you could replicate you pillar instances and only one would receive the message. It may be considered desirable to use temporary queues, so the queue name will never be reused in a later operation.
...