Skip Navigation LinksAzure Developers Guide > Azure Service Bus > Azure Service Bus Overview > Service Bus Messaging

Training Courses

All course material is in English, and courses are delivered in English. Feel free to contact me for further information. cloudcasts.net@gmail.com

Service Bus Messaging

The Azure Service Bus now contains two distinct messaging models, relayed messaging and brokered messaging.

Relayed Messaging

The AppFabric relayed capabilities were released as a CTP under the name of “BizTalk Services” back in 2007. In October 2008 they were re-branded as “.NET Services”, then rebranded again as “Windows Azure AppFabric Service Bus Relayed Messaging” before the production release in January 2010.

The implementation of relayed messaging has evolved from the original “BizTalk Services” CTP, but the principle remains the same. A service hosted behind a firewall or NAT can expose a public endpoint “in the cloud” that can be consumed by any authenticated client that has access to the internet.

 

This provides some great capabilities that applications can leverage to enable connectivity in situations where it would typically be challenging or impossible to achieve.

Although relayed messaging provides a lot of advantages it is not without its drawbacks.

·        If the service is not running or not connected to the AppFabric service bus the public endpoint is not available.

·        High bursts of traffic from clients can result in reduced performance and timeouts.

·        It is challenging to implement load-balancing on the service, limiting scalability and availability.

 

Brokered Messaging

Brokered messaging derives its name from the fact that there is a broker, or intermediary in the message channel that provides durable storage of in transit messages.

 

In Service Bus brokered messaging queues or topics and subscriptions can be used to broker messages between a client and a service. This provides a number of advantages.

·        If the service goes offline the client can still send messages to the queue, and is not aware of any service disruption. This allows the clients perception of service availability to be dependent on the availability of the brokered messaging service, and not the service processing the messages.

·        If there is a large burst in activity the queue can keep messages in a durable store until they are processed.

·        It is easy add additional service instances to receive and process messaging, providing scalability and availability.

When to Use What

For services using a request-response messaging pattern relayed messaging is usually the best option. The advantages of storing messages in an intermediary are usually mitigated by the expected response time of the service. It is possible to implement a request-response pattern using brokered messaging and implementing message correlation, but this adds complexity and additional latency to the implementation.

For asynchronous one-way messaging brokered messaging can provide better functionality. The advantages of durable storage, handing bursts of messages and high availability of the brokered messaging service are especially suitable for these scenarios.

Relayed messaging does include the option to use message buffers to even out brief bursts in load, but as these capabilities are now superseded by brokered messaging and the recommendation is to consider brokered messaging for these types of implementations.

 

 

Speaking Engagements