Exportar (0) Imprimir
Expandir todo

Novedades del SDK de Azure 2.0 (abril de 2013)

Actualizado: enero de 2014

La versión de abril de 2013 de Microsoft Azure Service Bus contiene diversas características y capacidades nuevas. Este tema resume las características nuevas y contiene vínculos a más información.

noteNota
Estas características no se admiten en Service Bus para Windows Server.

La exploración de mensajes permite ver los mensajes disponibles en una cola sin necesidad de bloquear el mensaje ni realizar ninguna operación de recepción explícita. Esto es muy útil para la depuración, así como en escenarios que implican supervisión.

Una llamada a Microsoft.ServiceBus.Messaging.QueueClient.Peek devuelve todas las propiedades y el cuerpo de los mensajes. Como alternativa, el método Microsoft.ServiceBus.Messaging.QueueClient.Peek(System.Int64) permite ver las propiedades de los mensajes comenzando en un número de secuencia específico. Por ejemplo:

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

Para obtener más información, vea

Esta característica permite suspender y reanudar el envío y la recepción de mensajes a y desde colas y temas. Puede habilitarlo usando la enumeración Microsoft.ServiceBus.Messaging.EntityStatus y estableciendo la propiedad Status. Por ejemplo:

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

Para obtener más información, vea

La eliminación automática permite establecer un intervalo tras el cual una cola, un tema o una suscripción inactivos se eliminan automáticamente (el intervalo mínimo es de 5 minutos). Si no se produce ninguna actividad de envío o recepción durante el período especificado en la propiedad AutoDeleteOnIdle, se elimina la entidad. Sin embargo, si hay llamadas de recepción en la cola o suscripción, no se elimina la entidad (incluso si no contiene mensajes). Por ejemplo:

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

Para obtener más información, vea

Esta característica introduce un modelo de programación de mensajería controlada por eventos, o "de inserción", que constituye una alternativa a un bucle de recepción. Admite el procesamiento de mensajes concurrentes y habilita el procesamiento de mensajes a velocidades variables. Este modelo ofrece las siguientes ventajas respecto a un bucle de recepción codificado de forma explícita:

  • Los bucles de recepción son más complejos de escribir porque requieren determinar explícitamente cuándo finalizan. El modelo de bombeo de mensajes es más fácil de codificar.

  • Los bucles de recepción requieren un comando wait estático para controlar el ritmo del bucle. El modelo de bombeo de mensajes permite el procesamiento a una velocidad variable, no es necesario controlar el ritmo.

  • El bucle de recepción debe finalizarse de forma explícita y puede ser difícil determinar cuándo finalizarlo. El bombeo de mensajes se detiene cuando se llama a Close() en la entidad de mensajería en el cliente.

La clase Microsoft.ServiceBus.Messaging.OnMessageOptions permite especificar opciones adicionales para el bombeo de mensajes. Las propiedades siguientes están disponibles:

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);
}

Para obtener más información, vea

Las API basadas en tareas ahora admiten versiones basadas en System.Threading.Tasks.Task de todas las API asincrónicas. Las API asincrónicas (API que tienen el par Begin/End) tienen ahora una versión Async también. Estas versiones no requieren la semántica explícita de Begin y End. Por ejemplo, Microsoft.ServiceBus.NamespaceManager.BeginQueueExists(System.String,System.AsyncCallback,System.Object) y Microsoft.ServiceBus.NamespaceManager.EndQueueExists(System.IAsyncResult) tienen ahora una versión Microsoft.ServiceBus.NamespaceManager.QueueExistsAsync(System.String).

Por ejemplo, el siguiente código comprueba la existencia de una cola usando el modelo asincrónico:

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”); 
}

Si se usan API basadas en tareas, el mismo código tiene el siguiente aspecto:

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

Para obtener más información, vea

Las aplicaciones se pueden autenticar en Microsoft Azure Service Bus mediante autenticación SAS (firma de acceso compartido) o mediante el Active Directory Access Control de Microsoft Azure (también conocido como Access Control Service o ACS). La autenticación SAS permite a las aplicaciones autenticarse en Service Bus usando una clave de acceso configurada en el espacio de nombres de servicio, o en la entidad que tiene derechos específicos asociados. Esta clave se puede usar después para generar un token SAS que los clientes usan para su autenticación en Service Bus. Para obtener más información sobre SAS, vea Autenticación y autorización de Service Bus y Autenticación con firma de acceso compartido en Service Bus.

Mostrar:
© 2014 Microsoft