Relayed and Brokered Messaging
Updated: April 23, 2014
The messaging pattern associated with the initial releases of Microsoft Azure Service Bus is referred to as relayed messaging, but Service Bus also supports brokered messaging. The brokered messaging scheme can also be thought of as asynchronous messaging.
The central component of Service Bus is a centralized (but highly load-balanced) relay service that supports a variety of different transport protocols and Web services standards. This includes SOAP, WS-*, and even REST. The relay service provides a variety of different relay connectivity options and can even help negotiate direct peer-to-peer connections when it is possible. Service Bus is optimized for .NET developers who use the Windows Communication Foundation (WCF), both with regard to performance and usability, and provides full access to its relay service through SOAP and REST interfaces. This makes it possible for any SOAP or REST programming environment to integrate with it.
The relay service supports traditional one-way messaging, request/response messaging, and peer-to-peer messaging. It also supports event distribution at Internet-scope to enable publish/subscribe scenarios and bi-directional socket communication for increased point-to-point efficiency. In the relayed messaging pattern, an on-premise service connects to the relay service through an outbound port and creates a bi-directional socket for communication tied to a particular rendezvous address. The client can then communicate with the on-premises service by sending messages to the relay service targeting the rendezvous address. The relay service will then “relay” messages to the on-premises service through the bi-directional socket already in place. The client does not need a direct connection to the on-premises service nor is it required to know where the service resides, and the on-premises service does not need any inbound ports open on the firewall.
You must initiate the connection between your on-premise service and the relay service, using a suite of WCF “relay” bindings. Behind the scenes, the relay bindings map to new transport binding elements designed to create WCF channel components that integrate with the Service Bus in the cloud.
Relayed messaging provides many benefits, but requires the server and client to both be online at the same time in order to send and receive messages. This is not optimal for HTTP-style communication, in which the requests may not be typically long lived, nor for clients that connect only occasionally, such as browsers, mobile applications, and so on. Brokered messaging supports decoupled communication, and has its own advantages; clients and servers can connect when needed and perform their operations in an asynchronous manner.
In contrast to the relayed messaging scheme, brokered messaging can be thought of as asynchronous, or “temporally decoupled.” Producers (senders) and consumers (receivers) do not have to be online at the same time. The messaging infrastructure reliably stores messages in a “broker” (such as a queue) until the consuming party is ready to receive them. This allows the components of the distributed application to be disconnected, either voluntarily; for example, for maintenance, or due to a component crash, without affecting the entire system. Furthermore, the receiving application may only have to come online during certain times of the day, such as an inventory management system that only is required to run at the end of the business day.
The core components of the Service Bus brokered messaging infrastructure are Service Bus Queues, Topics, and Subscriptions. These components enable new asynchronous messaging scenarios, such as temporal decoupling, publish/subscribe, and load balancing. For more information about these structures, see the next section.
As with the relayed messaging infrastructure, the brokered messaging capability is provided for WCF and programmers, and also via REST.