Esporta (0) Stampa
Espandi tutto

Creazione di applicazioni che usano argomenti e sottoscrizioni di Service Bus

Aggiornamento: febbraio 2015

Service Bus 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. Questo articolo si basa sulle informazioni fornite in Creazione di applicazioni che usano code di Service Bus e offre un'introduzione alle funzionalità di pubblicazione/sottoscrizione offerte dagli argomenti di Service Bus. L'articolo non intende essere una descrizione esaustiva di tutte le funzionalità di Service Bus, ma ha l'obiettivo di fornire informazioni sufficienti per iniziare a usare questa nuova funzionalità.

Questo articolo è una prosecuzione dello scenario relativo alla vendita al dettaglio usato in Creazione di applicazioni che usano code di Service Bus. I dati di vendita da singoli terminali di punti vendita devono essere indirizzati a un sistema di gestione dell'inventario, che usa tali dati per determinare quando è necessario un nuovo approvvigionamento. Ogni terminale di punto vendita comunica i dati di vendita tramite l'invio di messaggi alla coda DataCollectionQueue, in cui rimangono finché vengono ricevuti dal sistema di gestione dell'inventario, come illustrato di seguito:

Service-Bus1

Per evolvere questo scenario, al sistema è stato aggiunto un nuovo requisito che consente al proprietario di monitorare le attività del negozio in tempo reale.

Per soddisfare questo requisito, il sistema deve rimuovere il flusso dei dati di vendita. Ogni messaggio inviato dai terminali di punti vendita continua a essere inviato al sistema di gestione dell'inventario, ma risulta disponibile un'altra copia di ogni messaggio che può essere usata per presentare la vista del dashboard al proprietario del negozio.

In situazioni come questa, in cui è necessario che ogni messaggio venga usato da più parti, è possibile usare la funzionalità argomento di Service Bus. Gli argomenti forniscono un modello di pubblicazione/sottoscrizione in cui ciascun messaggio pubblicato viene reso disponibile a una o più sottoscrizioni registrate con l'argomento. Nelle code, invece, ogni messaggio viene ricevuto da un singolo consumer.

La procedura di invio dei messaggi a un argomento è simile a quella usata per l'invio a una coda. I messaggi, tuttavia, non vengono ricevuti direttamente dall'argomento, ma dalle sottoscrizioni. Una 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 è simile a quella usata per la ricezione da parte di una coda.

Nell'ambito dello scenario, è necessario innanzitutto rimuovere la coda di un argomento e aggiungere una sottoscrizione che verrà usata dal componente del sistema di gestione dell'inventario. Di seguito è riportato il nuovo sistema:

Service-Bus2

La nuova configurazione agisce allo stesso modo di quella precedente basata sulla coda, ossia i messaggi inviati all'argomento vengono indirizzati alla sottoscrizione Inventory dove sono disponibili per l'uso da parte del sistema di gestione dell'inventario.

Per supportare il dashboard di gestione, nell'argomento è necessario creare una seconda sottoscrizione, come illustrato di seguito:

Service-Bus3

Questa configurazione rende ogni messaggio nei terminali di punti vendita disponibile alle sottoscrizioni Dashboard e Inventory.

Creazione di applicazioni che usano code di Service Bus descrive come iscriversi a un account di Service Bus e creare uno spazio dei nomi servizio. Per usare lo Service Bus spazio dei nomi servizio, un'applicazione deve fare riferimento all'assembly del Service Bus, in particolare Microsoft.ServiceBus.dll. Il metodo più semplice di fare riferimento alle dipendenze del Service Bus consiste nell'installare il pacchetto Nuget del Service Bus. È anche possibile trovare l'assembly come parte di Azure SDK nelle librerie client di Azure per .NET. Il download è disponibile nella pagina di download di Azure SDK.

Le operazioni di gestione per le entità di messaggistica di Service Bus (code e argomenti di pubblicazione/sottoscrizione) vengono eseguite mediante la classe NamespaceManager. Service Bus usa un modello di sicurezza basato su attestazioni implementato mediante Microsoft Azure Active Directory Access Control (anche noto come Servizio Access Controll o ACS). Le credenziali appropriate sono necessarie per creare un'istanza di NamespaceManager per un determinato spazio dei nomi servizio. La classe TokenProvider rappresenta un provider di token di sicurezza con metodi factory incorporati che restituiscono alcuni provider di token noti. Verrà usato un metodo CreateSharedAccessSignatureTokenProvider per includere le credenziali delle firme di accesso condiviso. Sarà quindi creata l'istanza di NamespaceManager con l'indirizzo di base dello spazio dei nomi servizio di Service Bus e del provider di token.

La classe NamespaceManager fornisce i metodi per creare, enumerare ed eliminare entità di messaggistica. Il seguente frammento di codice illustra in che modo l'istanza NamespaceManager viene creata e usata per la creazione dell'argomento DataCollectionTopic.

Uri uri = ServiceBusEnvironment.CreateServiceUri("sb", "ingham-blog", string.Empty);
    string name = "RootManageSharedAccessKey";
    string key = "abcdefghijklmopqrstuvwxyz";
     
    TokenProvider tokenProvider = TokenProvider.CreateSharedAccessSignatureTokenProvider(name, key);
    NamespaceManager namespaceManager = new NamespaceManager(uri, tokenProvider);
 
    namespaceManager.CreateTopic("DataCollectionTopic");

Tenere presente che esistono overload del metodo CreateTopic che consentono all'utente di impostare le proprietà dell'argomento. Ad esempio, è possibile impostare il valore TTL (Time-To-Live) predefinito per i messaggi inviati alla coda. Successivamente aggiungere le sottoscrizioni Inventory e Dashboard.

namespaceManager.CreateSubscription("DataCollectionTopic", "Inventory");
    namespaceManager.CreateSubscription("DataCollectionTopic", "Dashboard");

Per operazioni di runtime su entità di Service Bus, ad esempio per l'invio e la ricezione di messaggi, un'applicazione deve prima di tutto creare un oggetto MessagingFactory. Analogamente alla classe NamespaceManager, l'istanza di MessagingFactory sarà creata dall'indirizzo di base dello spazio dei nomi servizio e del provider di token.

MessagingFactory factory = MessagingFactory.Create(uri, tokenProvider);

I messaggi inviati a e ricevuti dagli argomenti di Service Bus sono istanze della classe BrokeredMessage. Questa classe è costituita da un set di proprietà standard, ad esempio Label e TimeToLive, un dizionario usato per contenere le proprietà dell'applicazione e un corpo di dati applicazione arbitrari. Un'applicazione può configurare il corpo passando qualsiasi oggetto serializzabile (il seguente esempio passa un oggetto SalesData che rappresenta di dati di vendita dal terminale di punto vendita), che userà DataContractSerializer per serializzare l'oggetto. In alternativa, è possibile fornire Stream.

BrokeredMessage bm = new BrokeredMessage(salesData);
    bm.Label = "SalesReport";
    bm.Properties["StoreName"] = "Redmond";
    bm.Properties["MachineID"] = "POS_1";

Il modo più semplice per inviare messaggi agli argomenti consiste nell'usare CreateMessageSender per creare un oggetto MessageSender direttamente dall'istanza di MessagingFactory.

MessageSender sender = factory.CreateMessageSender("DataCollectionQueue");
    sender.Send(bm);

Analogamente a quanto avviene usando le code, il modo più semplice per ricevere messaggi da una sottoscrizione consiste nell'usare un oggetto MessageReceiver che può essere creato direttamente da MessagingFactory mediante CreateMessageReceiver. È possibile usare uno dei due metodi di ricezione (ReceiveAndDelete e PeekLock), come descritto in Creazione di applicazioni che usano code di Service Bus.

Tenere presente che quando si crea un oggetto MessageReceiver per una sottoscrizione, il parametro entityPath è nel formato topicPath/subscriptions/subscriptionName. Pertanto, per creare un oggetto MessageReceiver per la sottoscrizione Inventory dell'argomento DataCollectionTopic, il parametro entityPath deve essere DataCollectionTopic/subscriptions/Inventory. Di seguito è riportato il codice:

MessageReceiver receiver = factory.CreateMessageReceiver("DataCollectionTopic/subscriptions/Inventory");
    BrokeredMessage receivedMessage = receiver.Receive();
    try
    {
        ProcessMessage(receivedMessage);
        receivedMessage.Complete();
    }
    catch (Exception e)
    {
        receivedMessage.Abandon();
    }

Fino ad ora nell'articolo è stato descritto come tutti i messaggi inviati all'argomento vengono resi disponibili a tutte le sottoscrizioni registrate. Tenere presente il concetto di "disponibilità". Mentre nelle sottoscrizioni a Service Bus tutti i messaggi vengono inviati all'argomento, l'utente può copiare solo un subset di tali messaggi nella coda virtuale delle sottoscrizioni. Tale operazione viene eseguita tramite l'uso di specifici filtri. Quando si crea una sottoscrizione, è possibile specificare un'espressione filtro nel formato di un predicato di tipo SQL92 in grado di modificare le proprietà del messaggio, sia quelle di sistema, ad esempio Label, sia quelle dell'applicazione, ad esempio StoreName, nel precedente esempio.

Per evolvere lo scenario in modo che rifletta quanto appena descritto, è necessario aggiungere un secondo negozio allo scenario di vendita al dettaglio. I dati di vendita provenienti da tutti i terminali di punti vendita relativi a entrambi i negozi devono essere indirizzati al sistema di gestione dell'inventario centralizzato, tuttavia un gestore di negozio che usa lo strumento dashboard si interessa esclusivamente ai risultati del proprio negozio. A tale scopo, è possibile usare i filtri di sottoscrizione. Tenere presente che quando i terminali di punti vendita pubblicano i messaggi, impostano la proprietà dell'applicazione StoreName sul messaggio. Dati due negozi, ad esempio a Redmond e Seattle, i terminali di punti vendita nel negozio di Redmond timbrano i propri messaggi relativi ai dati di vendita con un valore di StoreName uguale a Redmond, mentre i terminali di punti vendita del negozio di Seattle usano un valore di StoreName uguale a Seattle. Il responsabile del negozio di Redmond desidera visualizzare solo i dati dai terminali di punti vendita del proprio negozio. Di seguito è riportato il sistema:

Service-Bus4

Per configurare questo indirizzamento, si crea la sottoscrizione Dashboard come indicato di seguito:

SqlFilter dashboardFilter = new SqlFilter("StoreName = ‘Redmond’");
  namespaceManager.CreateSubscription("DataCollectionTopic", "Dashboard", dashboardFilter);

Una volta definito questo filtro, verranno copiati nella coda virtuale della sottoscrizione Dashboard solo i messaggi con la proprietà StoreName impostata su Redmond. È importante notare una particolare caratteristica dei filtri di sottoscrizione: le applicazioni possono disporre di più regole filtro per sottoscrizione e della possibilità di modificare le proprietà di un messaggio nel momento in cui viene passato alla coda virtuale di una sottoscrizione.

L'articolo descrive come iniziare a usare la funzionalità di pubblicazione/sottoscrizione basata su argomenti introdotta in Service Bus.

Quanto è stato descritto in Creazione di applicazioni che usano code di Service Bus per l'uso dell'accodamento è applicabile anche agli argomenti, in particolare:

  • Disaccoppiamento temporale: i producer e i consumer di messaggi non devono essere online contemporaneamente.

  • Livellamento del carico: i picchi di carico vengono livellati dall'argomento abilitando il provisioning delle applicazioni consumer affinché gestiscano un carico medio anziché il carico massimo.

  • Bilanciamento del carico: in modo analogo a quanto avviene per una coda, è possibile disporre di più consumer concorrenti in attesa su una singola sottoscrizione e di messaggi trasferiti a uno solo dei consumer, con conseguente carico bilanciato.

  • Accoppiamento di tipo loose: è possibile estendere la rete di messaggistica senza alcun impatto sugli endpoint esistenti, ad esempio aggiungendo sottoscrizioni o modificando i filtri di un argomento per consentire l'aggiunta di nuovi consumer.

Mostra:
© 2015 Microsoft