Hybrid Messaging

Message bridging between Cloud-based Messaging Platform and on-premise Messaging Platform.

Pattern Definition

Problem How do I integrate on-premises messaging with Cloud-based messaging?
Context This pattern is applicable when there is a desire to integrate an on-premises Messaging Platform with a Cloud-based Messaging Platform.
Forces
  • Need a strategic and comprehensive messaging approach
  • Need to handle combinations of cloud to on-premises, on-premises to on-premises
  • Want to extend an established on-premises Messaging Platform
  • Quickly attach to existing on-premises messaging while leveraging Cloud-based messaging
Solution The Message Bridge pattern employs a Messaging Platform both in the Cloud and on premises. While this increases the cost and complexity of the overall solution it also provides the greatest flexibility. On-premises messaging can be done using the on-premises Messaging Platform while intra-Cloud messaging can be done using the Cloud-based Application Integration Platform. Both Messaging Platforms come into play when the messaging is between on premises and Cloud.
ConsequencesPros:
  • Provides the greatest flexibility.
  • Encapsulates on-premises messaging and intra-Cloud messaging.
  • Cloud to on-premises communication only required when messaging on premises to Cloud (or vice versa).
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 on-premises and 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. 

Interaction

Message transmitted from Cloud to on premises:

  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 on-premises Messaging Platform.
  5. The on-premises consumer receives the message.

Message transmitted from on premises to Cloud:

  1. An on-premises message producer sends a message to the on-premises Messaging Platform.
  2. The bridging software retrieves the message from the on-premises Messaging Platform.
  3. The bridging software sends the message to the Messaging platform.
  4. 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 on-premises 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
  5. Messaging Platform, the message will be lost.
  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). 

Interaction

Message transmitted from Cloud to on premises:

  1. The Cloud-based producer posts a message to the Messaging platform. The producer may be SaaS, PaaS,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 on-premises Messaging Platform.
  5. The bridging software commits the transaction.
  6. The on-premises consumer receives the message.

Notes

  1. The bridging software tends to be custom built (e.g. java)
  2. If the on-premises Messaging Platform allows transactions, then the message flow could be reversed as well i.e. on-premises producer with Cloud-based consumer.
  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 on-premises Messaging Platform, and then fails before committing the transaction, the message will still be awaiting retrieval in the Messaging platform.
  5. 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

Interaction

Messages transmitted from Cloud to on premises:

  1. The Cloud-based producer posts multiple messages to the Messaging platform. The producer may be SaaS, PaaS, 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 on premise Messaging Platform.
  5. The bridging software commits the transaction.
  6. The on-premise consumer receives the aggregated message.

Notes

  1. The bridging software tends to be custom built (e.g. java)
  2. If the on-premise Messaging Platform allows transactions, then the message flow could be reversed as well i.e. on-premise producer with Cloud-based consumer.
  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 on-premise 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. 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. 

Interaction

Messages transmitted from Cloud to on premises:

  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 on-premises Messaging Platform.
  5. The bridging software commits the transaction.
  6. The on-premises consumers receive the messages.

Notes

  1. The bridging software tends to be custom built (e.g. java)
  2. If the on-premises Messaging Platform allows transactions, then the message flow could be reversed as well i.e. on-premises producer with Cloud-based consumer 
  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 on-premises 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. This interaction does not include the set-up calls to the Messaging platform to create messaging contexts, sessions, connections, queues, etc.