1 out of 1 rated this helpful - Rate this topic

Best Practices for Leveraging Windows Azure Service Bus Brokered Messaging API

Author: Valery Mizonov

Contributors: Seth Manheim, Paolo Salvatori, James Podgorski, Eric Lam, Jayu Katti

This article offers practical guidance for developers working with the .NET managed brokered messaging API in the Windows Azure Service Bus. The recommendations supplied in this article come directly from recent customer projects. While building real-world solutions with the Service Bus, we learned about some key best practices and little-known secrets that will help increase reliability and improve the performance of solutions that use the new brokered messaging capabilities in the Service Bus. This article intends to share these lessons with the developer community.

Relayed vs Brokered Messaging

The Windows Azure Service Bus provides two comprehensive messaging solutions. The first solution is available through a centralized, highly load-balanced “relay” service that runs in the cloud that supports a variety of different transport protocols and Web services standards, including SOAP, WS-*, and REST. The relay service supports direct one-way messaging, request/response messaging, and peer-to-peer messaging. The pattern associated with this kind of messaging solution is referred to as relayed messaging. In the relayed messaging pattern, an on-premises or cloud-based 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 does not have to know where the service resides, and the on-premises service does not need any inbound ports open on the firewall. 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. Relayed messaging has been available since the initial release of the Service Bus.

The second messaging solution, introduced in the latest version of the Service Bus, enables “brokered” messaging capabilities. The brokered messaging scheme can also be thought of as asynchronous or “temporally decoupled” messaging. Producers (senders) and consumers (receivers) do not have to be online at the same time. The messaging infrastructure reliably stores messages 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 whole 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 a business day.

The core components of the Service Bus brokered messaging infrastructure are queues, topics, and subscriptions. These components enable new asynchronous messaging scenarios, such as temporal decoupling, publish/subscribe, load leveling, and load balancing. For more information about these scenarios, see the Additional Resources section.

Brokered Messaging API Overview

Throughout this guidance, you will see many references to various components, classes and types available in the .NET managed brokered messaging API. To put things into context, we list some of the key APIs that deliver and support the brokered messaging capability in the Service Bus.

The following classes are the most frequently-used API members from the Microsoft.ServiceBus and Microsoft.ServiceBus.Messaging namespaces, often involved when you are developing a brokered messaging solution:

Class Name	Description
BrokeredMessage	Represents the unit of communication between Service Bus clients. The serialized instances of the BrokeredMessage objects are transmitted through a wire when messaging clients communicate via queues and topics.
QueueClient	Represents a messaging object that enables sending and receiving messages from a Service Bus queue.
QueueDescription	Represents a metadata object describing a Service Bus queue including queue path, behavioral settings (such as lock duration, default TTL, duplicate detection) and informational data points (such as current queue length and size).
TopicClient	Represents a messaging object that enables sending messages to a Service Bus topic.
TopicDescription	Represents a metadata object describing a Service Bus topic including topic path, behavioral settings (such as duplicate detection) and informational data points (such as current size and maximum topic size).
SubscriptionClient	Represents a messaging object that enables receiving messages from a Service Bus subscription.
SubscriptionDescription	Represents a metadata object describing a Service Bus subscription including subscription name, owing topic path, behavioral settings (such as session support, default TTL, lock duration) and informational data points (such as current message count).
NamespaceManager	Represents a management object responsible for runtime operations with Service Bus messaging entities (queues, topics, subscriptions, rules) including creating, retrieving, deleting and asserting the existence.
MessagingFactory	Represents a factory object responsible for instantiating, tracking and managing the lifecycle of the messaging entity clients such as TopicClient, QueueClient and SubscriptionClient.
MessageReceiver	Represents an abstract messaging object that supports rich messaging functionality with a particular focus on the message receive operations.
MessageSender	Represents an abstract messaging object that supports rich messaging functionality with a particular focus on the message send operations.
MessageSession	Represents a message session that enables grouping of related messages for processing in a single transaction.
Filter	Represents an abstract metadata object that consists of a filter expression and associated action that is executed in the Service Bus subscription evaluation engine. The Filter class serves the purpose of a base class for `TrueFilter`, `FalseFilter`, `SqlFilter` and `CorrelationFilter` which represent the implementations of a metadata object for a given filter type.
TokenProvider	Represents a factory object that provides access to the different types of security token providers responsible for the acquisition of SAML, Shared Secret and Simple Web tokens.

It is recommended that you become familiar with these API artifacts to get a head start on building your first brokered messaging solution with the Service Bus. Please note that this is not an exhaustive list of all classes found in the brokered messaging API. For a complete landscape of all API members, see the MSDN documentation.

Best Practices in Brokered Messaging API

The topics in this section share specific recommendations that were derived from hands-on experience with the .NET managed brokered messaging API. The goal of these recommendations is to encourage developers to apply the techniques and patterns discussed in the following sections, in order to be able to deliver robust messaging solutions. This section contains the following topics:

Did you find this helpful? Yes No

Not accurate

Not enough depth

Need more code examples

(1500 characters remaining)

Community Content Add

FAQ