Questa pagina è stata utile?
I suggerimenti relativi al contenuto di questa pagina sono importanti. Comunicaceli.
Altri suggerimenti?
1500 caratteri rimanenti
Esporta (0) Stampa
Espandi tutto

Code, argomenti e sottoscrizioni del bus di servizio

Aggiornamento: maggio 2015

Bus di servizio di Microsoft Azure supporta un set di tecnologie middleware orientate ai messaggi e basate sul cloud, incluso l'accodamento dei messaggi affidabile e la messaggistica di pubblicazione e sottoscrizione permanente. Queste funzionalità di messaggistica "negoziata" possono essere considerate come funzionalità di messaggistica asincrone o disaccoppiate che supportano scenari di pubblicazione e sottoscrizione, disaccoppiamento temporale e bilanciamento del carico tramite l'infrastruttura di messaggistica Bus di servizio. La comunicazione disaccoppiata presenta molti vantaggi, ad esempio client e server possono connettersi quando necessario ed eseguire le relative operazioni in modo asincrono.

Le entità di messaggistica che costituiscono le funzionalità di messaggistica negoziata di base in Bus di servizio sono code, argomenti/sottoscrizioni, regole/azioni e hub eventi.

Le code consentono un recapito dei messaggi di tipo FIFO (First In, First Out) a uno o più consumer concorrenti. In altri termini, i messaggi in genere vengono ricevuti ed elaborati dai ricevitori secondo l'ordine temporale in cui sono stati aggiunti alla coda e ogni messaggio viene ricevuto ed elaborato da un solo consumer. Il vantaggio principale derivante dall'uso delle code è quello di ottenere un "disaccoppiamento temporale" dei componenti applicativi, ovvero non è necessario che i producer e i consumer inviino e ricevano i messaggi contemporaneamente in quanto i messaggi restano archiviati nella coda. Il producer inoltre non deve attendere la risposta del consumer per continuare a elaborare e inviare messaggi.

Un vantaggio correlato è quello del "livellamento del carico", che permette ai producer e ai consumer di inviare e ricevere i messaggi con ritmi diversi. In molte applicazioni, il carico del sistema varia nel tempo, tuttavia, il tempo di elaborazione necessario per ogni unità è in genere costante. L'interposizione di una coda tra producer e consumer di messaggi implica che è necessario solo eseguire il provisioning dell'applicazione consumer per gestire un carico medio invece di un carico massimo. In base alla variazione del carico in ingresso, si verificherà un incremento o una riduzione della profondità della coda, con un risparmio diretto in termini economici rispetto alle risorse infrastrutturali richieste per gestire il carico dell'applicazione. Con l'aumento del carico, è possibile aggiungere altri processi di lavoro per la lettura della coda. Ogni messaggio viene elaborato da un solo processo di lavoro. Inoltre, il bilanciamento del carico di tipo pull permette un uso ottimale dei computer di lavoro anche quando questi presentano una potenza di elaborazione diversa. Ogni computer effettuerà infatti il pull dei messaggi alla propria velocità massima. Questo modello viene spesso definito modello del "consumer concorrente".

L'uso di code da interporre tra producer e consumer di messaggi fornisce un accoppiamento intrinseco di tipo regime di controllo libero tra i componenti. Poiché producer e consumer sono indipendenti gli uni dagli altri, è possibile aggiornare un consumer senza causare alcun effetto sul producer.

La creazione di una coda è un processo che prevede più passaggi. Le operazioni di gestione per le entità di messaggistica di Bus di servizio (code e argomenti) vengono eseguite tramite la classe Microsoft.ServiceBus.NamespaceManager che viene costruita tramite la fornitura dell'indirizzo di base dello spazio dei nomi e delle credenziali utente di Bus di servizio. NamespaceManager fornisce i metodi per creare, enumerare ed eliminare le entità di messaggistica. Dopo aver creato un oggetto Microsoft.ServiceBus.TokenProvider da un nome emittente, una chiave condivisa e un oggetto di gestione spazio dei nomi servizio, è possibile usare il metodo Microsoft.ServiceBus.NamespaceManager.CreateQueue(Microsoft.ServiceBus.Messaging.QueueDescription) per creare la coda. Ad esempio:

// Create management credentials
TokenProvider credentials = TokenProvider.CreateSharedSecretTokenProvider(IssuerName, IssuerKey);
// Create namespace client
namespaceManager namespaceClient = new namespaceManager(ServiceBusEnvironment.CreateServiceUri("sb", ServiceNamespace, string.Empty), credentials);

È quindi possibile creare un oggetto coda e una factory di messaggistica usando l'URI di Bus di servizio come argomento. Ad esempio:

QueueDescription myQueue;
myQueue = namespaceClient.CreateQueue("TestQueue");
MessagingFactory factory = MessagingFactory.Create(ServiceBusEnvironment.CreateServiceUri("sb", ServiceNamespace, string.Empty), credentials); 
QueueClient myQueueClient = factory.CreateQueueClient("TestQueue");

Alla coda è possibile inviare messaggi. Se ad esempio si dispone di un elenco di messaggi negoziati denominato MessageList, sarà possibile usare un codice simile al seguente:

for (int count = 0; count < 6; count++)
{
    var issue = MessageList[count];
    issue.Label = issue.Properties["IssueTitle"].ToString();
    myQueueClient.Send(issue);
}

È possibile ricevere messaggi dalla coda, come indicato nell'esempio seguente:

while ((message = myQueueClient.Receive(new TimeSpan(hours: 0, minutes: 0, seconds: 5))) != null)
    {
        Console.WriteLine(string.Format("Message received: {0}, {1}, {2}", message.SequenceNumber, message.Label, message.MessageId));
        message.Complete();

        Console.WriteLine("Processing message (sleeping...)");
        Thread.Sleep(1000);
    }

Quando si usa la modalità ReceiveAndDelete la ricezione è un'operazione a un'unica fase. Quando infatti il Bus di servizio riceve la richiesta, contrassegna il messaggio come usato e lo restituisce all'applicazione. La modalità ReceiveAndDelete rappresenta il modello più semplice ed è adatta per scenari in cui un'applicazione può tollerare la mancata elaborazione di un messaggio in caso di errore. Per meglio comprendere questo meccanismo, prendere in considerazione uno scenario in cui il consumer emette la richiesta di ricezione e si interrompe in modo anomalo prima della sua elaborazione. Poiché Bus di servizio contrassegna il messaggio come usato, quando l'applicazione viene riavviata e inizia a usare nuovamente i messaggi, il messaggio usato prima dell'arresto anomalo risulterà perso.

Con la modalità PeekLock il processo di ricezione diventa un'operazione in due fasi, che rende possibile il supporto di applicazioni che non sono in grado di tollerare messaggi mancanti. Quando il Bus di servizio riceve la richiesta, individua il messaggio successivo da usare, lo blocca per impedirne la ricezione da parte di altri consumer e lo restituisce quindi all'applicazione. Quando l'applicazione ha completato l'elaborazione del messaggio oppure quando lo ha archiviato in modo affidabile per l'elaborazione futura, completa la seconda fase del processo di ricezione mediante la chiamata del metodo Microsoft.ServiceBus.Messaging.BrokeredMessage.Complete sul messaggio ricevuto. Quando il Bus di servizio vede il metodo Complete, contrassegna il messaggio come usato.

Se l'applicazione per qualche motivo non è in grado di elaborare il messaggio, può chiamare il metodo Microsoft.ServiceBus.Messaging.BrokeredMessage.Abandon sul messaggio ricevuto, invece del metodo Complete. In questo modo, il Bus di servizio sbloccherà il messaggio che sarà disponibile per essere nuovamente ricevuto dallo stesso consumer o da un altro consumer concorrente. Inoltre, al blocco è associato un timeout. Se l'applicazione non riesce a elaborare il messaggio prima della scadenza del timeout, ad esempio a causa di un arresto anomalo, il Bus di servizio sbloccherà il messaggio rendendolo nuovamente disponibile per la ricezione.

Si noti che in caso di arresto anomalo dell'applicazione dopo l'elaborazione del messaggio ma prima dell'invio della richiesta Complete, il messaggio verrà nuovamente recapitato all'applicazione al riavvio del sistema. Questo processo di elaborazione viene spesso definito di tipo At-Least-Once, per indicare che ogni messaggio verrà elaborato almeno una volta, ma che in determinate situazioni potrà essere recapitato una seconda volta. Se lo scenario non tollera la doppia elaborazione, sarà necessaria logica aggiuntiva nell'applicazione per il rilevamento dei duplicati in base alla proprietà MessageId del messaggio, che rimane costante per tutti i tentativi di recapito. Questo tipo di elaborazione viene definito di tipo Exactly Once.

Per altre informazioni e per un esempio funzionante di come creare e inviare messaggi alle code e dalle code, vedere Esercitazione sulla messaggistica negoziata del bus di servizio - .NET.

Diversamente dalle code, in cui ogni messaggio viene elaborato da un unico consumer, gli argomenti e le sottoscrizioni offrono una forma di comunicazione di tipo uno a molti tramite un modello di pubblicazione-sottoscrizione. Particolarmente utile per la comunicazione con un numero molto elevato di destinatari, ogni messaggio pubblicato è reso disponibile per ogni sottoscrizione registrata con l'argomento. I messaggi vengono inviati a un argomento e recapitati a una o più sottoscrizioni associate, a seconda delle regole di filtro che possono essere impostate per sottoscrizione. Per limitare i messaggi da ricevere, le sottoscrizioni possono usare filtri aggiuntivi. I messaggi vengono inviati a un argomento nello stesso modo in cui vengono inviati a una coda, con la differenza che i messaggi non vengono ricevuti direttamente dall'argomento. Vengono ricevuti dalle sottoscrizioni. La sottoscrizione a un argomento è simile a una coda virtuale che riceve copie dei messaggi inviati all'argomento. La procedura di ricezione dei messaggi da parte di una sottoscrizione è identica a quella usata per la ricezione da parte di una coda.

Ai fini di un confronto, la funzionalità di invio dei messaggi di una coda è mappata direttamente a un argomento e la funzionalità di ricezione di quest'ultimo è mappata a una sottoscrizione. Questo significa inoltre che le sottoscrizioni supportano gli stessi modelli descritti in precedenza in questa sezione in merito alle code: consumer concorrente, disaccoppiamento temporale, livellamento del carico e bilanciamento del carico.

La procedura per la creazione di un argomento è simile a quella per la creazione di una coda, come illustrato nell'esempio della sezione precedente. Creare l'URI del servizio e quindi usare la classe NamespaceManager per creare il client dello spazio dei nomi. È quindi possibile creare un argomento usando il metodo Microsoft.ServiceBus.NamespaceManager.CreateTopic(System.String). Ad esempio:

TopicDescription dataCollectionTopic = namespaceClient.CreateTopic("DataCollectionTopic");

Quindi, aggiungere le sottoscrizioni desiderate.

SubscriptionDescription myAgentSubscription = namespaceClient.CreateSubscription(myTopic.Path, "Inventory");
SubscriptionDescription myAuditSubscription = namespaceClient.CreateSubscription(myTopic.Path, "Dashboard");

In seguito, verrà creato un client dell'argomento. Ad esempio:

MessagingFactory factory = MessagingFactory.Create(serviceUri, tokenProvider);
TopicClient myTopicClient = factory.CreateTopicClient(myTopic.Path)

Usando il mittente del messaggio, è possibile inviare messaggi all'argomento e riceverli, come illustrato nella sezione precedente. Ad esempio:

foreach (BrokeredMessage message in messageList)
{
    myTopicClient.Send(message);
    Console.WriteLine(
    string.Format("Message sent: Id = {0}, Body = {1}", message.MessageId, message.GetBody<string>()));
}

Come accade per le code, i messaggi vengono ricevuti da una sottoscrizione tramite un oggetto SubscriptionClient anziché un oggetto QueueClient. Creare il client della sottoscrizione, passando il nome dell'argomento, il nome della sottoscrizione e (facoltativamente) la modalità di ricezione come parametri. Ad esempio, con la sottoscrizione Inventory:

// Create the subscription client
MessagingFactory factory = MessagingFactory.Create(serviceUri, tokenProvider); 

SubscriptionClient agentSubscriptionClient = factory.CreateSubscriptionClient("IssueTrackingTopic", "Inventory", ReceiveMode.PeekLock);
SubscriptionClient auditSubscriptionClient = factory.CreateSubscriptionClient("IssueTrackingTopic", "Dashboard", ReceiveMode.ReceiveAndDelete); 

while ((message = agentSubscriptionClient.Receive(TimeSpan.FromSeconds(5))) != null)
{
    Console.WriteLine("\nReceiving message from Inventory...");
    Console.WriteLine(string.Format("Message received: Id = {0}, Body = {1}", message.MessageId, message.GetBody<string>()));
    message.Complete();
}          

// Create a receiver using ReceiveAndDelete mode
while ((message = auditSubscriptionClient.Receive(TimeSpan.FromSeconds(5))) != null)
{
    Console.WriteLine("\nReceiving message from Dashboard...");
    Console.WriteLine(string.Format("Message received: Id = {0}, Body = {1}", message.MessageId, message.GetBody<string>()));
}

ImportantImportante
Come descritto nell'argomento Procedura: Pubblicare un servizio nel Registro di sistema del bus di servizio, è possibile usare Microsoft.ServiceBus.ServiceRegistrySettings per indicare se si vuole che il servizio venga individuato dal Bus di servizio. Se il servizio è privato, solo i soggetti a conoscenza dell'URI specifico potranno connettersi. Se è pubblico, chiunque potrà esplorare la gerarchia del Bus di servizio e trovare il listener. Non è tuttavia possibile esporre code, argomenti e sottoscrizioni tramite il Registro di sistema del servizio.

In molti scenari, i messaggi con caratteristiche specifiche devono essere elaborati in modi specifici. A questo scopo, è possibile configurare le sottoscrizioni in modo che trovino i messaggi che presentano le proprietà desiderate e apportare quindi alcune modifiche a tali proprietà. Mentre nelle sottoscrizioni a Bus di servizio tutti i messaggi vengono inviati all'argomento, l'utente può copiare solo un subset di tali messaggi nella coda virtuale delle sottoscrizioni. Questa operazione viene eseguita tramite l'uso di specifici filtri. Queste modifiche sono chiamate Azioni di filtro. Quando viene creata una sottoscrizione, è possibile fornire un'espressione di filtro che agisce sulle proprietà del messaggio, sulle proprietà del sistema, ad esempio Label e sulle proprietà dell'applicazione, come ad esempio la proprietà StoreName, illustrata in precedenza. In questo caso l'espressione di filtro SQL è facoltativa. Senza un'espressione di filtro SQL, qualsiasi azione di filtro definita in una sottoscrizione verrà eseguita in tutti i messaggi di quella sottoscrizione.

Facendo riferimento all'esempio precedente, per filtrare solo i messaggi provenienti da Store1, è necessario creare la sottoscrizione Dashboard come indicato nella procedura seguente:

namespaceManager.CreateSubscription("IssueTrackingTopic", "Dashboard", new SqlFilter("StoreName = 'Store1'"));

Dopo aver creato questo filtro della sottoscrizione, solo i messaggi con la proprietà StoreName impostata su Store1 vengono copiati nella coda virtuale per la sottoscrizione Dashboard.

Per altre informazioni su valori di filtro possibili, vedere la documentazione relativa alle classi Microsoft.ServiceBus.Messaging.SqlFilter e Microsoft.ServiceBus.Messaging.SqlRuleAction. Vedere anche l'esempio relativo a Messaggistica negoziata: filtri avanzati.

Gli hub eventi sono un servizio di inserimento di eventi e vengono usati per fornire l'ingresso dei dati di eventi e telemetria ad Azure su larga scala, con bassa latenza ed elevata affidabilità. Questo servizio, se usato insieme ad altri servizi downstream, è particolarmente utile negli scenari di strumentazione delle applicazioni, elaborazione dell'esperienza utente o dei flussi di lavoro e di Internet delle cose (Internet of Things, IoT).

Gli hub eventi sono un costrutto di streaming dei messaggi e sebbene possano sembrare simili a code e argomenti, presentano caratteristiche molto diverse. Ad esempio, gli hub eventi non forniscono TTL, mancato recapito, transazioni o acknowledgement dei messaggi, in quanto queste sono funzionalità di messaggistica negoziata tradizionale e non di streaming. Gli hub eventi forniscono altre funzionalità correlate ai flussi, ad esempio il partizionamento, il mantenimento dell'ordine e la riproduzione del flusso.

Vedere anche

Mostra:
© 2015 Microsoft