Eksportér (0) Udskriv
Udvid alt
EN
Dette indhold er ikke tilgængeligt på dit sprog, men her er den engelske version.

What's New in the Azure SDK 2.0 Release (April 2013)

Updated: January 22, 2014

The Microsoft Azure Service Bus April 2013 release contains a number of new features and capabilities. This topic summarizes the new features and contains links to more information.

noteNote
These features are not supported in Service Bus for Windows Server.

Message Browse

Message browsing enables you to view available messages in a queue without locking the message or performing an explicit receive operation. This is useful for debugging, as well as in scenarios that involve monitoring.

A call to Microsoft.ServiceBus.Messaging.QueueClient.Peek returns all message properties and the message body. Alternatively, the Microsoft.ServiceBus.Messaging.QueueClient.Peek(System.Int64) method enables you to view the message properties starting from a specific sequence number. For example:

QueueClient queueClient = QueueClient.Create("myQ");
var message = queueClient.Peek(); // does not lock the message
var message = queueClient.Peek(fromSequenceNumber: 4); // specific starting point
var messages = queueClient.PeekBatch(messageCount: 10); // supports batching

For more information, see

Enable and Disable Send/Receive

This feature gives you the ability to suspend and resume sending and receiving messages to and from queues and topics. You can enable this by using the Microsoft.ServiceBus.Messaging.EntityStatus enumeration and setting the Status property. For example:

QueueDescription qd = namespaceManager.GetQueue("myQ");
qd.Status = EntityStatus.Disabled; //all operations blocked
qd.Status = EntityStatus.SendDisabled; //can continue to de-queue
qd.Status = EntityStatus.ReceiveDisabled; //can continue to en-queue
qd.Status = EntityStatus.Active; //all operations allowed
namespaceManager.UpdateQueue(qd);

For more information, see

Auto-delete for Idle Messaging Entities

Auto-delete enables you to set an interval after which an idle queue, topic, or subscription is automatically deleted (the minimum interval is 5 minutes). If no send or receive activity occurs for the duration specified in the AutoDeleteOnIdle property, the entity is deleted. However, if there are receive calls on the queue or subscription, the entity is not get deleted (even if it contains no messages). For example:

TopicDescription topicDescription = new TopicDescription("myTopic");
topicDescription.AutoDeleteOnIdle = TimeSpan.FromMinutes(30); // minimum is 5 minutes, the default is TimeSpan.MaxValue
namespaceManager.CreateTopic(topicDescription);

For more information, see

Event-Driven Message Programing Model

This feature introduces an event-driven, or “push,” messaging programming model, which is an alternative to a receive loop. This feature supports concurrent message processing, and enables processing messages at variable rates. This model has the following advantages over an explicitly-coded receive loop:

  • Receive loops are harder to write – you must explicitly determine when to end them. The message pump model is easier to code.

  • Receive loops require a static wait command to control the pace of the loop. The message pump model allows for variable rate processing; you do not have to control the pace.

  • You must explicitly end the receive loop, and it can be difficult to determine when to end it. The message pump is stopped when you call Close() on the messaging entity in the client.

The Microsoft.ServiceBus.Messaging.OnMessageOptions class enables you to specify additional options for the message pump. The following properties are available:

OnMessageOptions options = new OnMessageOptions();
options.AutoComplete = true; // Indicates if the message pump should call Complete() on messages after the callback has completed processing.
options.MaxConcurrentCalls = 1; // Indicates the maximum number of concurrent calls to the callback the pump should initiate. 
options.ExceptionReceived += LogErrors; // Enables notification of any errors encountered by the message pump.

// Start receiving messages
queueClient.OnMessage((receivedMessage) => // Initiates the message pump and callback is invoked for each message that is received, calling close on the client will stop the pump.
    {
        // Process the message
        Trace.WriteLine("Processing", receivedMessage.SequenceNumber.ToString());
    }, options);

private void LogErrors(object sender, ExceptionReceivedEventArgs e)
{
    Trace.WriteLine(e.Exception.Message);
}

For more information, see

Task-based Async APIs

Task-based APIs now support System.Threading.Tasks.Task-based versions of all asynchronous APIs. Asynchronous APIs (APIs that have a Begin/End) pair now have an Async version as well. These versions do not require explicit Begin and End semantics. For example, Microsoft.ServiceBus.NamespaceManager.BeginQueueExists(System.String,System.AsyncCallback,System.Object) and Microsoft.ServiceBus.NamespaceManager.EndQueueExists(System.IAsyncResult) now have a Microsoft.ServiceBus.NamespaceManager.QueueExistsAsync(System.String) version.

For example, the following code checks for the existence of a queue using the asynchronous model:

static void QueueCheck()
{
    NamespaceManager namespaceManager = NamespaceManager.Create();
    namespaceManager.BeginQueueExists(“testQueue”, EndQueueCheck, namespaceManager); 
}

Static void EndQueueCheck(IAsyncResult result) 
{
    NamespaceManager namespaceManager = (NamespaceManager) result.AsyncState; 
    bool exists = namespaceManager.EndQueueExists(result); 
    Console.WriteLine(“Queue {0} exists.”, exists ? “does” : “does not”); 
}

Using the task-based API, the same code appears as follows:

NamespaceManager namespaceManager = NamespaceManager.Create();
bool exists = await NamespaceManager.QueueExistsAsync(“testQueue”); 
Console.WriteLine(“Queue {0} exists.”, exists ? “does” : “does not”);

For more information, see

Shared Access Signature (SAS)

Applications can now authenticate to Microsoft Azure Service Bus using either Shared Access Signature (SAS) authentication or, as before, through the Microsoft Azure Active Directory Access Control (also known as Access Control Service or ACS). SAS authentication enables applications to authenticate to Service Bus using an access key configured on the service namespace, or on the entity that has specific rights associated with it. You can then use this key to generate a SAS token that clients can use to authenticate to Service Bus. For more information about SAS, see Service Bus Authentication and Authorization and Shared Access Signature Authentication with Service Bus.


Build Date:

2014-07-11

Fællesskabsindhold

Tilføj
Vis:
© 2014 Microsoft