...
- Messages are not persistent on a topic, messages will only be received if someone listens at the time of the message.
- Topics can have multiple listeners that will receive a message.
- Topic are globally created and managed
Queues
Properties:
- Messages are persistent on the queue, meaning that if a listener looses connection or is restarted, it can pick up hte messages when it comes back.
- Only one listener will receive a message if there are multiple listeners.
- Queue are globally created and managed
Persistent topics
Properties:
- Multiple listeners can all receive a message, like a topic
- Messages are persistent, that is they are remembered until all known listeners have acknowledged them, even if the listener is not currently available. (Danger of flooding the queue if a listener never returns to acknowledge messages)
- Persistent topics are globally created and managed
Temporary queues
Properties:
- 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.
...
LISTENERS: One specific pillar
MESSAGES: <Op>Request
NAMING: "<sla-id>.<pillar-id>"
DISCUSSION: This topic is the interface for operations on a pillar.
IMPLEMENTATION: A pillar in the protocol is given it's id in configuration, and for each SLA listeners connect to this topic.
GENERATION: These topics are generated for each pillar by the message bus administrator when a new SLA is added.
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.
...
Persistent Topics
Queues Persistent topics are used for following up on operations. (Operations ending in ...Response or ...Complete)
Individual for one client/pillar. Only one listener should be allowed per queue. It seems appropriate for followup operations that they are persistent, so they are picked up when the listener regains contact to the JMS server.
The dedicated client
...
persistent topic:
LISTENERS: One specific client
MESSAGE: IdentifyPillarFor<Op>Response, <Op>Response, <Op>Complete
NAMING: "<sla-id>.<client-id>client"
DISCUSSION: This queue is intended to receive replies to requests sent to the pillarsclients.
IMPLEMENTATION: A client in the protocol is given the SLA id in it's id in configuration, and for each SLA listeners connect listener connects to this queue.
GENERATION: These queues are This persistent topic is generated for each client by the message bus administrator when a new SLA is added.
ALTERNATIVES: It is protocol-safe to make a different choice for making client destinations on a per-client basis. This can be replaced with a persistent topic queue or a temporary queue, and the naming is quite optional. A queue persistent destination seems appropriate, since it will ensure that replies are received and processed, even if the listener is not available when the message was sent. However, it might be reasonable to choose a persistent topic, to allow multiple listeners, or it may be considered desirable to use temporary queues, so the queue name will never be reused in a later operation.