| 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:
...
LISTENERS: Every client or pillar recognising this SLA
MESSAGES: IdentifyPillarFor<Op>Request, probably alarms, other messages MAY be sent on this topic
NAMING: "<sla-id>"
DISCUSSION: This topic is the abstraction layer, that makes it possible to use the protocol with no knowledge of other players.
IMPLEMENTATION: A participant in the protocol is given a list of all SLA's it should recognise in configuration, and all listeners connect to this topic.
GENERATION: This topic is generated by the message bus administrator when a new SLA is added.
...
Persistent topics are used for following up on operations. (Operations ending in ...Response or ...Complete)
Individual for one client. 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"
DISCUSSION: This queue persistent topic is intended to receive replies to requests sent to the clients.
IMPLEMENTATION: A client in the protocol is given the SLA id in it's configuration, and each listener connects to this queuepersistent topic.
GENERATION: This persistent topic is generated for each client SLA 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 queue or a temporary queue, and the naming is quite optional. A 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 may be considered desirable to use temporary queues, so the queue name will never be reused in a later operation.
Alarms
Alarms are probably best modelled in separate destinations. Currently it is expected that two destinations for alarms are reasonable:
The general alarm persistent topic
LISTENERS: An alarm service
MESSAGE: Alarms
NAMING: "ALARMS"
DISCUSSION: This topic is intended to receive alarms that are general for the system.
IMPLEMENTATION: All participants in the protocol are given the topic name ("ALARMS") in configuration, and send general alarms to this topic. The ALARM service also listens to this topic.
GENERATION: This topic is generated by the message bus administrator when first setting up the system.
ALTERNATIVES: The GENERAL topic could be used instead, or all known SLA topic destinations.
The SLA alarm persistent topic
LISTENERS: One specific client
MESSAGE: Alarms
NAMING: "<sla-id>.alarms"
DISCUSSION: This queue is intended to receive alarms that are reported during a SLA-specific conversation.
IMPLEMENTATION: All participants in the protocol are given the SLA id in it's configuration, and send SLA-specific alarms to this topic.
GENERATION: This persistent topic is generated for each SLA by the message bus administrator when a new SLA is added.
ALTERNATIVES: The SLA topic could be used instead.