Page Comparison

Types of destinations

The destinations are split into different categories, inspired by Java JMS. There are four types of possible JMS destinations:

...

• 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

...

Durable 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 Durable topics are globally created and managed

...

• 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.

Topics

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

...

Concrete destinations in a repository

The following sections documents the  destinations used in the reference architecture together with alternatives. Note all destinations in the reference architecture are local to a given repository.

The repository topic

LISTENERS: Every component participating in a Bit Repository.
MESSAGES: IdentifyPillarFor<Op>Request.
NAMING: "type:<repository-id>"
DISCUSSION: This topic is the abstraction layer, that makes it possible to use the protocol with no knowledge of other playersparticipants. The destination is used to send the initial 'Identify...' requests used to start a conversation. See Message flow documentation for details.
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 topic is defined in the RepositorySettings.
ALTERNATIVES:

• The repository topic might be used for other message types. It might in fact be used for all the messages in a repository, 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: "<slatype:<repository-id>.<pillar-id>"
DISCUSSION: This topic is the interface for requesting 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 topicPillar 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 SLA repository is addedsetup.
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

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

...

per-client temporary queue

LISTENERS: One specific clientClients
MESSAGE: IdentifyPillarFor<Op>Response, <Op>Response, <Op>Complete
NAMING: "<slatype:<repository-id>.client-name.unique-client-identifier"
DISCUSSION: This queue 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 queue.
GENERATION: This persistent topic is generated for each client by the message bus administrator when a new SLA is addedThe reference maintains a conversation state while running, which isen't shared between client, nor persisted. This means replies sent to other clients or previous instances of a client are irrelevant. Thus a client is only interested in replies to it's own responses. 
IMPLEMENTATION: A client initiates a temporary queue on startup with a unique identifier.
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(durable shared) topic, 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 operationIn case of stateless client, clients with persisted state or shared state this might be relevant.

Alarms

Alarms are probably best modelled in a separate destination.

The repository alarm durable topic

LISTENERS: One specific client
MESSAGE: Alarms
NAMING: "type:<repository-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 alarm destination id in it's configuration, and send alarms to this topic.
ALTERNATIVES: The repository topic could be used instead.