Federated Messaging

Message bridging between Cloud-based messaging platform and another Cloud-based messaging platform.

Pattern Definition

Problem How do I integrate messaging in one Cloud with messaging in another Cloud?
Context This pattern is applicable when there is a desire to integrate a Cloud-based Messaging Platform with another Cloud-based Messaging Platform
Forces
  • Need a strategic and comprehensive messaging approach
  • Need to handle combinations of messaging for cloud to same cloud, cloud to another cloud, on premises to cloud
  • Want to extend a Cloud-based Messaging Platform to another Cloud
Solution The Message Bridge pattern employs a Messaging Platform in two (or more) Clouds. While this increases the cost and complexity of the overall solution it also provides the greatest flexibility. Intra-Cloud messaging can be done by the local Messaging Platform in each Cloud while intre-Cloud messaging can be done using the bridge.
ConsequencesPros:
  • Provides the greatest flexibility.
  • Encapsulates intra-Cloud messaging.
  • Cloud to Cloud communication only required when messaging between Clouds.
Cons:
  • Increased complexity compared to having only one Messaging Platform.
  • Potential latency impact due to messaging going through two Messaging Platforms.
  • May require different skill sets for different Cloud-based Messaging Platforms

Interaction Views

One to One Bridging

Bridging where each message is relayed from one Messaging Platform to the other Messaging Platform. 

Interactions

Message transmitted from left side Cloud to right side Cloud:

  1. The bridging software registers a call-back URL for receiving messages from the Messaging platform.
  2. The Cloud-based producer posts a message to the Messaging platform. The producer may be SaaS, PaaS, or IaaS software.
  3. The bridging software retrieves the message from the Messaging platform.
  4. The bridging software posts the message to the Messaging Platform in the other Cloud.

Message transmitted from right side Cloud to left side Cloud:

  1. The consumer in the other Cloud receives the message.
  2. A message producer in the other Cloud sends a message to the Messaging Platform in the other Cloud.
  3. The bridging software retrieves the message from the Messaging Platform in the other Cloud.
  4. The bridging software sends the message to the Messaging platform.
  5. The Cloud-based consumer receives the message. The consumer may be SaaS, PaaS, or IaaS software.

Notes

  1. The bridging software tends to be custom built (e.g. java)
  2. This interaction could be for queues or for topics. In the case of topics there would likely be more than one consumer for each message.
  3. This interaction shows both message pulls and message pushes for the bridge. Depending on the other Cloud Messaging Platform functionality, the bridge might use all push messaging.
  4. This interaction allows for message loss in the case of bridge failure. If the bridge retrieves a message from one Messaging Platform and then fails before delivering the message to the other Messaging Platform, the message will be lost.
  5. Although not shown in the interaction, producers/consumers could also be on premises.
  6. This interaction does not include the set-up calls to the Messaging platform to create messaging contexts, sessions, connections, queues, etc.

Transacted One-to-One Bridging

Bridging where each message is relayed from one Messaging Platform to the other Messaging Platform with no lost messages (but possible duplicates).

Interactions

Message transmitted from left side Cloud to right side Cloud:

  1. The Cloud-based producer posts a message to the Messaging platform. The producer may be SaaS, PaaS, or IaaS software.
  2. The bridging software begins a transaction on the Messaging platform.
  3. The bridging software retrieves the message from the Messaging platform.
  4. The bridging software posts the message to the Messaging Platform in the other Cloud.
  5. The bridging software commits the transaction.
  6. The consumer in the other Cloud receives the message.

Notes

  1. The bridging software tends to be custom built (e.g. java)
  2. If the Messaging Platform in the other Cloud allows transactions, then the message flow could be reversed as well. 
  3. This interaction could be for queues or for topics. In the case of topics there would likely be more than one consumer for each message.
  4. This interaction eliminates message loss but may cause message duplicates. If the bridge retrieves a message from the Messaging platform, delivers the message to the other Cloud Messaging Platform, and then fails before committing the transaction, the message will still be awaiting retrieval in the Messaging platform.
  5. Although not shown in the interaction, producers/consumers could also be on premises.
  6. This interaction does not include the set-up calls to the Messaging platform to create messaging contexts, sessions, connections, queues, etc.

Message Aggregator

Bridging where multiple messages from one Messaging Platform are aggregated into a single message on the other Messaging Platform.

Interactions

Messages transmitted from left side Cloud to right side Cloud:

  1. The Cloud-based producer posts multiple messages to the Messaging platform. The producer may be SaaS, PaaS, or IaaS software.
  2. The bridging software begins a transaction on the Messaging platform.
  3. The bridging software retrieves multiple messages from the Messaging platform and combines them into a single message.
  4. The bridging software posts the aggregated message to the Messaging Platform in the other Cloud.
  5. The bridging software commits the transaction.
  6. The consumer in the other Cloud receives the aggregated message.

Notes

  1. The bridging software tends to be custom built (e.g. java)
  2. If the other Cloud Messaging Platform allows transactions, then the message flow could be reversed as well.
  3. This interaction could be for queues or for topics. In the case of topics there would likely be more than one consumer for each message.
  4. This interaction eliminates message loss but may cause message duplicates. If the bridge retrieves the messages from the Messaging platform, delivers the aggregated message to the other Cloud Messaging Platform, and then fails before committing the transaction, the messages will still be awaiting retrieval in the Messaging platform.
  5. If the bridge does not use transactions then the interaction would allow message loss but would eliminate message duplicates.
  6. Although not shown in the interaction, producers/consumers could also be on premises.
  7. This interaction does not include the set-up calls to the Messaging platform to create messaging contexts, sessions, connections, queues, etc.

Message Splitter

Bridging where a single message from one Messaging Platform results in multiple messages in the other Messaging Platform.

Interactions

Messages transmitted from left side Cloud to right side Cloud:

  1. The Cloud-based producer posts a message to the Messaging platform. The producer may be SaaS, PaaS, or IaaS software.
  2. The bridging software begins a transaction on the Messaging platform.
  3. The bridging software retrieves the message from the Messaging platform. The bridging software creates multiple messages from the incoming message. This could be duplicate messages or each message could be a portion of the original message.
  4. The bridging software posts the messages to the Messaging Platform in the other Cloud.
  5. The bridging software commits the transaction.
  6. The consumers in the other Cloud receive the messages.

Notes

  1. The bridging software tends to be custom built (e.g. java)
  2. If the other Cloud Messaging Platform allows transactions, then the message flow could be reversed as well.
  3. This interaction eliminates message loss but may cause message duplicates. If the bridge retrieves the message from the Messaging platform, delivers some or all of the split messages to the other Cloud Messaging Platform, and then fails before committing the transaction, the message will still be awaiting retrieval in the Messaging platform.
  4. If the bridge does not use transactions then the interaction would allow message loss but would eliminate message duplicates.
  5. Although not shown in the interaction, producers/consumers could also be on premises.
  6. This interaction does not include the set-up calls to the Messaging platform to create messaging contexts, sessions, connections, queues, etc.