Esporta (0) Stampa
Espandi tutto

Novità di Azure SDK versione 2.0 (aprile 2013)

Aggiornamento: gennaio 2014

Nella versione di Service Bus di Microsoft Azure del mese di aprile 2013 sono disponibili nuove caratteristiche e funzionalità. Di seguito è riportato un riepilogo di tali caratteristiche e vengono forniti i collegamenti per visualizzare ulteriori informazioni.

noteNota
Queste funzionalità non sono supportate in Service Bus per Windows Server.

La funzionalità di esplorazione dei messaggi consente di visualizzare i messaggi disponibili in una coda senza bloccare il messaggio o eseguire un'operazione di ricezione esplicita. Questa funzionalità è utile per eseguire il debug e in scenari di monitoraggio.

Una chiamata a Microsoft.ServiceBus.Messaging.QueueClient.Peek restituisce tutte le proprietà e il corpo del messaggio. In alternativa, il metodo Microsoft.ServiceBus.Messaging.QueueClient.Peek(System.Int64) consente di visualizzare le proprietà del messaggio a partire da un numero di sequenza specifico, Ad esempio:

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

Per altre informazioni, vedere

Questa funzionalità consente di sospendere e riprendere l'invio e la ricezione di messaggi verso e da code e argomenti. È possibile abilitarla utilizzando l'enumerazione Microsoft.ServiceBus.Messaging.EntityStatus e impostando la proprietà Status, Ad esempio:

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

Per altre informazioni, vedere

La funzionalità di eliminazione automatica consente di impostare un intervallo trascorso il quale una coda, un argomento o una sottoscrizione inattiva viene automaticamente eliminata. L'intervallo minimo è di 5 minuti. Se nell'intervallo di tempo specificato nella proprietà AutoDeleteOnIdle non si verificano attività di invio o ricezione, l'entità viene eliminata. Se tuttavia sono presenti chiamate di ricezione sulla coda o sulla sottoscrizione, l'entità non viene eliminata, anche se non contiene messaggi, Ad esempio:

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

Per altre informazioni, vedere

Questa funzionalità introduce un modello di programmazione di messaggi "push" o guidati dagli eventi, che rappresenta un'alternativa a un ciclo di ricezione. La funzionalità supporta elaborazioni simultanee di un messaggio e consente di elaborare i messaggi a velocità variabili. Questo modello offre i seguenti vantaggi su un ciclo di ricezione codificato in modo esplicito:

  • Difficoltà di scrittura dei cicli di ricezione: è necessario determinare in modo esplicito quando terminarli. La codifica del modello di message pump è più semplice.

  • Necessità di un comando wait statico relativo ai cicli di ricezione per controllare la velocità del ciclo. Il modello di message pump consente l'elaborazione a velocità variabili. Non è necessario controllare la velocità.

  • Difficoltà nel definire quando terminare un ciclo di ricezione in modo esplicito. Il message pump viene terminato quando si esegue una chiamata a Close() sull'entità di messaggistica nel client.

La classe Microsoft.ServiceBus.Messaging.OnMessageOptions consente di specificare ulteriori opzioni per il message pump. Sono disponibili le seguenti proprietà:

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

Per altre informazioni, vedere

Le API asincrone basate sulle attività supportano le versioni di tutte le API asincrone basate su System.Threading.Tasks.Task. Anche le coppie di API asincrone, vale a dire le API con inizio e fine, dispongono di una versione di Async, che non richiede la semantica Begin ed End esplicita. Ad esempio, Microsoft.ServiceBus.NamespaceManager.BeginQueueExists(System.String,System.AsyncCallback,System.Object) e Microsoft.ServiceBus.NamespaceManager.EndQueueExists(System.IAsyncResult) dispongono ora di una versione di Microsoft.ServiceBus.NamespaceManager.QueueExistsAsync(System.String).

Il codice riportato di seguito, ad esempio, verifica l'esistenza di una coda che utilizza il modello asincrono:

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

Utilizzando l'API basata sulle attività, lo stesso codice viene visualizzato nel modo seguente:

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

Per altre informazioni, vedere

È ora possibile autenticare le applicazioni a Service Bus di Microsoft Azure utilizzando l'autenticazione della firma di accesso condiviso oppure tramite il Microsoft Azure Active Directory Access Control (anche noto come Servizio di controllo di accesso o ACS), come in precedenza. L'autenticazione della firma di accesso condiviso consente alle applicazioni di eseguire l'autenticazione a Service Bus utilizzando una chiave di accesso configurata nello spazio dei nomi servizio o nell'entità a cui sono associati diritti specifici. È quindi possibile utilizzare questa chiave per generare un token di firma di accesso condiviso di cui possono avvalersi i client per eseguire l'autenticazione a Service Bus. Per altre informazioni sulla firma di accesso condiviso, vedere Autenticazione e autorizzazione di Service Bus e Autenticazione della firma di accesso condiviso con Service Bus.

Mostra:
© 2014 Microsoft