Negli snippet precedenti abbiamo introdotto il ruolo Web Role e il ruolo Worker Role (sembra un gioco di parole...) e abbiamo dato uno squardo a Blob e Table, due dei quattro servizi esposti dai servizi denominati Storage Account.
In questo snippet vediamo storage account Queue (coda), ovvero il terzo servizio che si preoccupa di fornire un sistema di accodamento accessibile via REST/HTTP da qualunque piattaforma.
Il sistema può fare da ponte fra applicazioni on-premises e applicazioni cloud così come da applicazioni mobile a applicazioni on-premises.
Ad esempio un iPhone o un Windows Phone può inserire un messaggio in una coda relativo ad un ordine preso sul campo e una applicazione su Windows Azure, tramite un Worker Role può processare il messaggio stesso. Allo stesso modo, visto che lo storage, security permettendo, è accessibile da ovunque, una applicazione AS/400 on-premises potrebbe fungere da sistema di processing degli ordini inviati dai palmari.
Un altro esempio di utilizzo di un sistema di accodamento può essere un sistema di order entry sviluppato come applicazione ASP.NET e ospitato su un Web Role. Ogni ordine da processare viene inserito come messaggio all'interno di una coda e un Worker Role che gira nel back-end può processare i vari messaggi.
Vediamo insieme il codice per creare una coda per poi soffermarci sull'inserimento di messaggi e sul relativo "dequeue":
CloudStorageAccount account = CloudStorageAccount.FromConfigurationSetting("DataConnectionString");
CloudQueueClient queueClient = account.CreateCloudQueueClient();
CloudQueue queue = queueClient.GetQueueReference("ordini");
queue.CreateIfNotExist();Nel caso di un Worker Role questo codice ha senso inserirlo nell'override del metodo OnStart (si veda lo snippet relativo ai Worker Role). L'impostazione DataConnectionString conviene inserirla nel file ServiceConfiguration.cscfg al posto del classico app.config per poterla modificare direttamente dal portale.
Il codice per inserire un messaggio in coda, supponiamo da una applicazione Windows Presentation Foundation oppure da Windows Phone 7 potrebbe essere il seguente:
CloudStorageAccount account = CloudStorageAccount.Parse(ConfigurationManager.AppSettings["DataConnectionString"]);
CloudQueueClient queueClient = account.CreateCloudQueueClient();
CloudQueue queue = queueClient.GetQueueReference("ordini");
CloudQueueMessage m = new CloudQueueMessage(txtOrdine.Text);
queue.AddMessage(m);Usando il codice che abbiamo già visto nel loop proposta da Visual Studio per la gestione di un Worker Role, potremmo fare quanto segue:
public override void Run()
{
// This is a sample worker implementation. Replace with your logic.
Trace.WriteLine("WorkerRole1 entry point called", "Information");
CloudStorageAccount account = CloudStorageAccount.FromConfigurationSetting("DataConnectionString");
CloudQueueClient queueClient = account.CreateCloudQueueClient();
CloudQueue queue = queueClient.GetQueueReference("ordini");
// Per capire !
while (true)
{
CloudQueueMessage m = queue.GetMessage();
if (m != null)
{
// Processiamo l'ordine
....
// Cancelliamo dalla code
queue.DeleteMessage(m);
Trace.WriteLine(m.AsString, "Information");
}
Thread.Sleep(10000);
}
}A parte il messaggio di trace, recuperiamo le informazioni sullo Storage Account tramite la classe CloudStorageAccount come abbiamo visto negli snippet precedenti, creiamo un oggetto CloudQueueClient che ci consente di ottenere una reference alla coda. Fino a questo punto, nessuna richiesta è stata effettuata verso lo storage.
All'interno del loop, che ovviamente può essere migliorato notevolmente come codice, recuperiamo un messaggio tramite il metodo GetMessage e se era presente un messaggio all'interno della coda (m != null), processiamo l'ordine come preferiamo (codice omesso) e cancelliamo il messaggio dalla coda.
Non esistono attuamente, anche perchè stiamo usando dietro le quinte REST/HTTP, meccanismi di notifica dell'arrivo di un nuovo messaggio in coda come troviamo sui sistemi on-premises come Microsoft MSMQ.
Il sistema di accodamento ha un meccasnismo basato su pop-lock per evitare che due applicazioni riescano a "scodare" lo stesso messaggio. Questo meccanismo si basa su un tempo di ownership che rende invisibile il messaggio ad altre applicazioni e costringe l'applicazione a eliminare il messaggio entro questo periodo di tempo pena l'impossibilità di effettuare l'operazione.
In questo articolo abbiamo solamente introdotto il meccasismo di gestione delle code usando come base teorica quando appreso sullo Storage Account nei precedenti snippet.
L'applicazione Save The Planet, per Windows Phone 7 ad esempio utilizza il meccanismo di accodamento offerto da Windows Azure per inviare tutte le azioni compiute dall'utente dal proprio telefonino. Un "servizio" sviluppato come Worker Role processa i vari messaggi e tramite una semplice logica di business inserisce il dato all'interno di SQL Azure, argomento che tratteremo nei prossimi snippet.
