Dışarıya aktar (0) Yazdır
Tümünü Genişlet
Bu içerik dilinizde bulunmamaktadır ancak İngilizce sürümüne buradan bakabilirsiniz.

Best Practices for Leveraging Azure Service Bus Brokered Messaging API

Updated: March 19, 2014

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 Azure Service Bus. The recommendations supplied in this article come directly from recent customer projects. While building real-world solutions with 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 Service Bus. This article intends to share these lessons with the developer community.

Relayed vs Brokered Messaging

Microsoft 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 Service Bus.

The second messaging solution 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 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



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.


Represents a messaging object that enables sending and receiving messages from a Service Bus queue.


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).


Represents a messaging object that enables sending messages to a Service Bus topic.


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).


Represents a messaging object that enables receiving messages from a Service Bus subscription.


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).


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.


Represents a factory object responsible for instantiating, tracking and managing the lifecycle of the messaging entity clients such as TopicClient, QueueClient and SubscriptionClient.


Represents an abstract messaging object that supports rich messaging functionality with a particular focus on the message receive operations.


Represents an abstract messaging object that supports rich messaging functionality with a particular focus on the message send operations.


Represents a message session that enables grouping of related messages for processing in a single transaction.


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.


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 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:

Topluluk İçeriği

© 2014 Microsoft