...
Topics are used for initiating operations (Operations ending in ...Request). This seems appropriate for initiating an operation. Topic semantics are required for the Identify...Request operations. Followup messages MAY be sent to a topic, but in this case replies are not persistent, so queues are suggested.
The General Topic
LISTENERS: Everybody.
MESSAGES: None defined, but all can be sent to this topic
NAMING: "GENERAL"
DISCUSSION: This topic is a fallback, if for any reason the proper communication channels are not available.
IMPLEMENTATION: A participant in the protocol is given the topic name ("GENERAL") in configuration, and all listeners connect to this topic.
GENERATION: This topic is generated by the message bus administrator when first setting up the system.
The per-SLA topic
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.
The per-pillar topic
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.
...
The dedicated client queue:
LISTENERS: One specific client
MESSAGE: IdentifyPillarFor<Op>Response, <Op>Response, <Op>Complete
NAMING: "<sla-id>.<client-id>"
DISCUSSION: This queue is intended to receive replies to requests sent to the pillars.
IMPLEMENTATION: A client in the protocol is given it's id in configuration, and for each SLA listeners connect to this queue.
GENERATION: These queues are 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 or a temporary queue, and the naming is quite optional. A queue seems appropriate, since it will ensure that replies are received and processed. 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.