Code di Windows Azure e Windows Azure Service Bus: confronto e contrapposizioni

Windows Azure supporta due tipi di meccanismi di code: code di Windows Azure e code del Service Bus.

Le code di Windows Azure, che fanno parte dell'infrastruttura dell'archiviazione Windows Azure, offrono un'interfaccia per operazioni di ricezione/inserimento/visualizzazione basata su REST, che fornisce messaggistica affidabile e persistente in e tra i servizi.

Le code del Service Bus fanno parte di un'infrastruttura di messaggistica di Windows Azure più ampia che supporta l'accodamento insieme ai modelli di pubblicazione, sottoscrizione, comunicazione remota del servizio Web e integrazione.

Anche se entrambe le tecnologie di accodamento sono disponibili contemporaneamente, le code di Windows Azure sono state introdotte prima, come meccanismo di archiviazione delle code dedicato compilato nei servizi di archiviazione Windows Azure. Le code del Service Bus, introdotte con l'ultima versione del Service Bus, vengono compilate nell'infrastruttura di messaggistica negoziata più ampia progettata per integrare applicazioni e componenti delle applicazioni tramite cui è possibile estendere più protocolli di comunicazione, contratti dati, domini trusted e/o ambienti di rete.

In questo articolo vengono confrontate le due tecnologie di accodamento offerte da Windows Azure, illustrando le differenze di comportamento e implementazione delle funzionalità fornite da ognuna. Nell'articolo sono inoltre disponibili informazioni aggiuntive per la scelta delle funzionalità che possono soddisfare meglio le proprie esigenze di sviluppo di applicazioni.

Sia le code di Windows Azure sia quelle del Service Bus sono implementazioni del servizio di accodamento di messaggi attualmente disponibile in Windows Azure. Ciascuna tecnologia presenta un set di funzionalità leggermente diverso, pertanto è possibile scegliere l'una o l'altra, o entrambe, a seconda delle esigenze della particolare soluzione in uso o di un problema aziendale o tecnico da risolvere.

Quando si stabilisce la tecnologia di accodamento che soddisfa lo scopo di una determinata soluzione, è consigliabile che gli architetti e gli sviluppatori di soluzioni tengano in considerazione le indicazioni riportate di seguito. Ulteriori dettagli sono disponibili nella sezione successiva.

In qualità di architetto o sviluppatore di soluzioni, è consigliabile considerare l'utilizzo delle code di Windows Azure quando:

Tramite l'applicazione devono essere archiviati in una coda oltre 5 GB di messaggi la cui durata è inferiore a 7 giorni.
Per l'elaborazione dei messaggi da parte dell'applicazione è necessario un lease flessibile grazie al quale la relativa durata risulta molto breve. In questo modo, se si verifica un arresto anomalo del processo di lavoro, il messaggio può essere elaborato di nuovo rapidamente. Inoltre, tramite il processo di lavoro è possibile estendere il lease in un messaggio se per l'elaborazione di quest'ultimo è richiesto più tempo. Tramite questa operazione è possibile affrontare tempi di elaborazione dei messaggi non deterministici.
Tramite l'applicazione si desidera tenere traccia dello stato dell'elaborazione di un messaggio all'interno del messaggio. Ciò si rivela utile se si verifica un arresto anomalo del processo di lavoro tramite cui si elabora il messaggio. Queste informazioni possono quindi essere utilizzate in un processo di lavoro successivo per continuare nel punto in cui è stato interrotto il processo di lavoro precedente.
A tale scopo, sono inoltre necessari i log sul lato server di tutte le transazioni eseguite nelle code.

In qualità di architetto o sviluppatore di soluzioni, è consigliabile considerare l'utilizzo delle code nel Service Bus di Windows Azure quando:

È necessaria l'integrazione completa con lo stack di comunicazione Windows Communication Foundation (WCF) in .NET Framework.
Tramite la soluzione deve essere possibile eseguire il rilevamento duplicato automatico.
L'utente deve essere in grado di elaborare i messaggi correlati come singolo gruppo logico.
Per la soluzione sono necessari atomicità e comportamento transazionale in caso di invio o ricezione di più messaggi da una coda.
La caratteristica relativa alla durata (TTL) del carico di lavoro specifico dell'applicazione può superare il periodo di 7 giorni.
Tramite l'applicazione vengono gestiti messaggi che possono superare i 64 KB ma che probabilmente non si avvicineranno al limite dei 256 KB.
Tramite la soluzione deve essere garantito il recapito ordinato FIFO (First In First Out) da parte della coda.
Tramite la soluzione deve essere possibile ricevere messaggi senza dover eseguire il polling della coda. Con il Service Bus, questa esigenza può essere soddisfatta utilizzando l'operazione di ricezione con polling prolungato.
È necessario fornire un modello di accesso basato sui ruoli alle code e autorizzazioni/diritti diversi per mittenti e ricevitori.
Le dimensioni della coda non aumenteranno più di 5 GB.
È possibile prevedere un'eventuale migrazione dalla comunicazione punto a punto basata sulla coda a un modello di scambio dei messaggi mediante il quale viene garantita un'integrazione continua di ricevitori aggiuntivi (sottoscrittori), mediante ognuno dei quali vengono ricevute copie separate di alcuni o di tutti i messaggi inviati alla coda. Quest'ultima viene definita funzionalità di pubblicazione/sottoscrizione a livello nativo fornita dal Service Bus.
Tramite la soluzione di messaggistica deve essere garantito il recapito "At-Most-Once" senza che l'utente debba compilare i componenti aggiuntivi dell'infrastruttura.
L'utente desidera essere in grado di pubblicare e utilizzare batch di messaggi.

Nelle tabelle delle sezioni riportate di seguito viene fornito un raggruppamento logico delle funzionalità relative alle code e la possibilità di un confronto immediato delle funzionalità disponibili sia nelle code di Windows Azure sia in quelle del Windows Azure Service Bus.

In questa sezione vengono confrontate alcune delle funzionalità di accodamento fondamentali fornite dalle code di Windows Azure e da quelle del Service Bus.

Criteri di confronto	Code di Windows Azure	Code del Service Bus
Garanzia di ordinamento	No	Sì, FIFO (First In First Out) (tramite l'utilizzo di sessioni di messaggistica)
Garanzia di recapito	At-Least-Once	At-Least-Once At-Most-Once
Supporto per le transazioni	No	Sì (tramite l'utilizzo di transazioni locali)
Comportamento di ricezione	Senza blocco (completamento immediato in caso di assenza di nuovi messaggi)	Blocco con/senza timeout (disponibilità di polling prolungato o "tecnica Comet") Senza blocco (solo tramite l'utilizzo dell'API gestita .NET)
Modalità di ricezione	Visualizzazione e lease	Visualizzazione e blocco Ricezione ed eliminazione
Modalità di accesso esclusivo	Basato sul lease	Basato sul blocco
Durata lease/blocco	30 secondi (impostazione predefinita) 7 giorni (durata massima)	60 secondi (impostazione predefinita) È possibile rinnovare il blocco su un messaggio utilizzando l'API RenewLock.
Granularità di lease/blocco	A livello di messaggio (ogni messaggio può disporre di un valore di timeout diverso)	A livello di coda (ogni coda dispone di una granularità di blocco applicata a tutti i relativi messaggi, tuttavia è possibile rinnovare il blocco utilizzando l'API RenewLock).
Ricezione in batch	Sì (specifica esplicita del numero di messaggi durante il recupero di questi ultimi, fino a un massimo di 32 messaggi)	Sì (abilitazione implicita di una proprietà di prelettura o esplicita tramite l'utilizzo di transazioni)
Invio in batch	No	Sì (tramite l'utilizzo di transazioni o invio in batch sul lato client)

Informazioni aggiuntive

Per il modello FIFO garantito nelle code del Service Bus è richiesto l'utilizzo di sessioni di messaggistica. In caso di arresto anomalo dell'applicazione durante l'elaborazione di un messaggio ricevuto nella modalità Peek & Lock, alla prossima accettazione di una sessione di messaggistica da parte di un ricevitore di code, l'avvio verrà eseguito con il messaggio non recapitato dopo la scadenza della relativa durata (TTL).
Le code del Service Bus supportano la garanzia del recapito At-Least-Once. Inoltre, la semantica At-Most-Once può essere supportata tramite lo stato della sessione per archiviare lo stato dell'applicazione e tramite le transazioni per ricevere i messaggi in modo atomico e aggiornare lo stato della sessione. Questa tecnica viene utilizzata dal servizio Flusso di lavoro di Windows Azure per garantire il recapito con semantica At-Most-Once.
Le code del Service Bus offrono supporto per le transazioni locali nel contesto di una singola coda.
La modalità Ricezione ed eliminazione supportata dal Service Bus offre la possibilità di ridurre il numero di operazioni di messaggistica (e relativo costo) in cambio di una garanzia di recapito più bassa.
Le code di Windows Azure forniscono lease con la possibilità di estenderli per i messaggi. In questo modo i processi di lavoro possono gestire lease brevi nei messaggi. Pertanto, se un processo di lavoro viene arrestato in modo anomalo, il messaggio può essere elaborato di nuovo rapidamente da un altro processo di lavoro. Inoltre, tramite un processo di lavoro è possibile estendere il lease in un messaggio se l'elaborazione di quest'ultimo richiede più tempo del lease corrente.
Le code di Windows Azure offrono un timeout di visibilità che può essere impostato durante l'inserimento o la rimozione dalla coda di un messaggio. Inoltre, è possibile aggiornare un messaggio con valori di lease diversi in fase di esecuzione, nonché aggiornare valori diversi nei messaggi nella stessa coda. I timeout dei blocchi del Service Bus vengono definiti nei metadati della coda, tuttavia è possibile rinnovare il blocco chiamando il metodo RenewLock.
Il timeout massimo per un'operazione di ricezione del blocco nelle code del Service Bus è di 24 giorni.
Tramite l'invio in batch sul lato client fornito dal Service Bus è possibile inviare in batch più messaggi in una singola operazione di invio mediante il client coda. L'invio in batch è disponibile solo per le operazioni di invio asincrone.

In questa sezione vengono confrontate le funzionalità avanzate fornite dalle code di Windows Azure e da quelle del Service Bus.

Criteri di confronto	Code di Windows Azure	Code del Service Bus
Recapito pianificato	Sì	Sì
Mancato recapito automatico dei messaggi	No	Sì
Rinvio messaggi	Sì (tramite aggiornamento sul posto di timeout di visibilità)	Sì (fornito tramite una funzione API dedicata)
Supporto messaggi non elaborabili	Sì	Sì
Aggiornamento sul posto	Sì	No
Log delle transazioni sul lato server	Sì	No
Metrica di archiviazione	Sì	No
Funzione di eliminazione della coda	Sì	No
Gruppi di messaggi	No	Sì (tramite l'utilizzo di sessioni di messaggistica)
Rilevamento duplicato	No	Sì (configurabile sul lato del mittente)
Integrazione di WCF	No	Sì (disponibilità di associazioni WCF predefinite)
Integrazione WF	Personalizzata (compilazione di un'attività WF personalizzata necessaria)	Nativo (disponibilità di attività WF predefinite)

Informazioni aggiuntive

A partire dalla versione di novembre 2011 di Windows Azure SDK, tramite entrambe le tecnologie di accodamento è possibile pianificare il recapito di un messaggio in un momento successivo.
Le code di Windows Azure offrono supporto per l'aggiornamento del contenuto del messaggio. Questa funzionalità può essere utilizzata per rendere persistente le informazioni sullo stato e gli aggiornamenti dello stato incrementale nel messaggio in modo che possa essere elaborato dall'ultimo checkpoint noto, anziché iniziare da zero.
Il mancato recapito dei messaggi, supportato solo dalle code del Service Bus, può essere utile per isolare i messaggi che non possono essere elaborati correttamente dall'applicazione ricevente o quando i messaggi non possono essere recapitati a causa di una proprietà di durata (TTL) scaduta. Tramite il valore TTL viene specificata la durata del messaggio nella coda. Con il Service Bus, il messaggio verrà spostato in una coda speciale chiamata $ DeadLetterQueue allo scadere del periodo TTL.
Per trovare messaggi "non elaborabili" nelle code di Windows Azure, durante la rimozione di un messaggio dalla coda, tramite l'applicazione viene esaminata la proprietà DequeueCount del messaggio. Se il valore della proprietà DequeueCount supera il valore di soglia specificato, il messaggio viene spostato dall'applicazione in una coda di "messaggio non recapitabile" definita dall'applicazione.
Tramite le code di Windows Azure è possibile ottenere un log dettagliato di tutte le transazioni eseguite nella coda, nonché la metrica di aggregazione. Questi due elementi sono utili per eseguire il debug e comprendere la modalità di utilizzo delle code di Windows Azure da parte dell'applicazione. Inoltre, sono utili per l'ottimizzazione delle prestazioni dell'applicazione e per la riduzione dei costi di utilizzo delle code.
Con il concetto di "sessioni di messaggio" supportato dal Service Bus i messaggi possono appartenere a un determinato gruppo logico da associare a un ricevitore specificato, tramite cui, a sua volta, viene creata un'affinità simile alla sessione tra i messaggi e i rispettivi ricevitori. Questa funzionalità avanzata può essere abilitata dal Service Bus impostando la proprietà SessionID in un messaggio. I ricevitori possono quindi restare in ascolto su un ID di sessione specifico e ricevere messaggi in cui viene condiviso l'identificatore di sessione specificato.
Tramite la funzionalità di rilevamento di duplicazione supportata dalle code del Service Bus vengono rimossi automaticamente i messaggi duplicati inviati a una coda o a un argomento, in base al valore della proprietà MessageID.

In questa sezione vengono confrontate le code di Windows Azure e quelle del Service Bus relativamente alla capacità e alle quote.

Criteri di confronto	Code di Windows Azure	Code del Service Bus
Dimensioni massime del messaggio	64 KB (48 KB in caso di codifica Base64)	256 KB (inclusi sia l'intestazione sia il corpo, dimensioni massime dell'intestazione: 64 KB)
Dimensioni massime della coda	100 TB (limitate alla capacità di un singolo account di archiviazione)	1, 2, 3, 4 o 5 GB (definite al momento della creazione di una coda)
Durata TTL massima del messaggio	7 giorni	Illimitata
Numero massimo di code	Illimitato	10,000 (per spazio dei nomi del servizio, può essere aumentato)
Numero massimo di client concorrenti	Illimitato	Illimitato (limite di 100 connessioni simultanee applicato solo alla comunicazione basata su protocollo TCP)

Informazioni aggiuntive

Con le code di Windows Azure, se il contenuto del messaggio non è XML-safe, deve essere con codifica Base64. Se per il messaggio non è stata utilizzata la codifica Base64, il payload dell'utente può essere fino a 48 KB, anziché 64.
Con le code del Service Bus, ogni messaggio archiviato in una coda è costituito da due parti: un'intestazione e un corpo. Le dimensioni totali del messaggio non possono superare 256 KB.
Se le comunicazioni tra client e code del Service Bus vengono stabilite tramite il protocollo TCP, il numero massimo di connessioni simultanee a una singola coda del Service Bus è limitato a 100. Questo numero è condiviso tra mittenti e ricevitori. Se questa quota viene raggiunta, le richieste successive per connessioni aggiuntive saranno rifiutate e dal codice chiamante verrà ricevuta un'eccezione. Questo limite non viene imposto ai client tramite cui viene effettuata la connessione alle code mediante l'API basata su REST.
I limiti di dimensioni delle code vengono applicati dal Service Bus. Le dimensioni massime della coda vengono specificate al momento della creazione della coda e possono avere un valore di 1, 2, 3, 4 o 5 GB. Se il valore delle dimensioni della coda impostato al momento della creazione della coda viene raggiunto, i messaggi in arrivo aggiuntivi verranno rifiutati e verrà ricevuta un'eccezione dal codice chiamante. Per ulteriori informazioni sulle quote nel Service Bus, vedere Windows Azure Service Bus Quotas.
Se sono necessarie più di 10.000 code in un singolo spazio dei nomi del servizio del Service Bus, è possibile contattare il team di supporto di Windows Azure e richiedere un aumento. Per ridimensionare più di 10.000 code con il Service Bus, è inoltre possibile creare spazi dei nomi aggiuntivi del servizio tramite il portale di gestione di Windows Azure.

In questa sezione vengono confrontate le funzionalità di gestione fornite dalle code di Windows Azure e da quelle del Service Bus.

Criteri di confronto	Code di Windows Azure	Code del Service Bus
Protocollo di gestione	REST su HTTP/HTTPS	REST su HTTPS
Protocollo runtime	REST su HTTP/HTTPS	REST su HTTPS TCP con TLS
API gestita .NET	Sì (API del client di archiviazione gestita .NET)	Sì (API di messaggistica negoziata gestita .NET)
API Java	Sì	Sì
API PHP	Sì	Sì
API Node.js	Sì	Sì
Supporto metadati arbitrario	Sì	No
Regole di denominazione delle code	Lunghezza massima pari a 63 caratteri (le lettere del nome di una coda devono essere minuscole)	Lunghezza massima pari a 260 caratteri (per i nomi di code non viene fatta distinzione tra maiuscole e minuscole)
Funzione di recupero della lunghezza della coda	Sì (valore approssimativo)	Sì (esatto, valore temporizzato)
Funzione di visualizzazione	Sì	No

Informazioni aggiuntive

Le code di Windows Azure forniscono supporto per gli attributi arbitrari applicabili alla descrizione della coda, nel formato delle coppie nome valore.
Le code di Windows Azure offrono inoltre la possibilità di visualizzare un messaggio senza doverlo bloccare. Questa funzionalità può essere utile quando si implementa uno strumento di esplorazione delle code.
Tramite l'API di messaggistica negoziata gestita .NET per il Service Bus vengono utilizzate le connessioni TCP full duplex per prestazioni migliorate se confrontate con REST su HTTP.
Tramite le code di Windows Azure vengono imposte determinate restrizioni nei nomi delle code. Per ulteriori informazioni, vedere l'articolo relativo alla denominazione di code e metadati.
La lunghezza dei nomi delle code del Service Bus può contenere un massimo di 260 caratteri e presentare regole di denominazione meno restrittive. Nei nomi delle code del Service Bus possono essere inclusi solo lettere, numeri, punti (.), trattini (-) e caratteri di sottolineatura (_).

In questa sezione vengono confrontate le code di Windows Azure e del Service Bus relativamente alle prestazioni.

Criteri di confronto	Code di Windows Azure	Code del Service Bus
Velocità effettiva massima	Fino a 2.000 messaggi al secondo	Fino a 2.000 messaggi al secondo (in base al benchmark con messaggi di 1 KB)
Latenza media	10 ms (con l'algoritmo di Nagle di TCP disabilitato)	100 ms
Comportamento di limitazione	Rifiuto con codice HTTP 503 (le richieste limitate non vengono considerate fatturabili)	Rifiuto con eccezione/HTTP 503 (le richieste limitate non vengono considerate fatturabili)

Criteri di confronto

Code di Windows Azure

Code del Service Bus

Velocità effettiva massima

Fino a 2.000 messaggi al secondo

(in base al benchmark con messaggi di 1 KB)

Latenza media

10 ms

(con l'algoritmo di Nagle di TCP disabilitato)

100 ms

Comportamento di limitazione

Rifiuto con codice HTTP 503

(le richieste limitate non vengono considerate fatturabili)

Rifiuto con eccezione/HTTP 503

(le richieste limitate non vengono considerate fatturabili)

Informazioni aggiuntive

Tramite una singola coda di Windows Azure è possibile elaborare fino a 2.000 transazioni al secondo. Una transazione è un'operazione Put, Get o Delete. L'invio di un singolo messaggio a una coda (Put) viene contato come una transazione, ma la ricezione di un messaggio è spesso un processo a due passaggi che comporta il recupero (Get), seguito da una richiesta di rimozione del messaggio dalla coda (Delete). Di conseguenza, un'operazione di rimozione dalla coda completata comporta in genere due transazioni.
Quando viene raggiunta la velocità effettiva massima di una coda di Windows Azure dall'applicazione, viene in genere restituita una risposta indicante che il server è occupato (HTTP 503) dal servizio relativo alla coda. In questo caso, tramite l'applicazione deve essere attivata la logica di ripetizione tentativi con ritardo esponenziale backoff.
La media della latenza delle code di Windows Azure è 10 millisecondi quando si gestiscono messaggi di piccole dimensioni (minori di 10 KB) da un servizio ospitato posizionato nello stesso percorso (area secondaria) dell'account di archiviazione.
Sia tramite le code di Windows Azure sia tramite quelle del Service Bus viene applicato il comportamento di limitazione rifiutando richieste a una coda limitata. Tuttavia, le richieste limitate non vengono considerate come fatturabili da entrambi i tipi di code.
Tramite i benchmark nelle code del Service Bus è stato dimostrato che la velocità effettiva massima di un messaggio raggiunta da una singola coda è pari a 2.000 messaggi al secondo con dimensioni di un messaggio pari a circa 1 KB. Per ottenere una velocità effettiva più elevata, utilizzare più code. Per ulteriori informazioni sull'ottimizzazione delle prestazioni con il Service Bus, vedere Best Practices for Performance Improvements Using Service Bus Brokered Messaging.
Quando per una coda del Service Bus viene raggiunta la velocità effettiva massima, al client della coda verrà restituito un oggetto ServerBusyException (in caso di utilizzo dell'API di messaggistica negoziata gestita .NET) o una risposta HTTP 503 (in caso di utilizzo dell'API basata su REST), indicando che la coda è limitata.

In questa sezione vengono illustrate le funzionalità di autenticazione e autorizzazione supportate dalle code di Windows Azure e da quelle del Service Bus.

Criteri di confronto	Code di Windows Azure	Code del Service Bus
Autenticazione	Chiave simmetrica	Attestazioni ACS
Controllo accesso basato sui ruoli	No	Sì (tramite l'utilizzo di ruoli ACS)
Federazione del provider di identità	No	Sì

Criteri di confronto

Code di Windows Azure

Code del Service Bus

Autenticazione

Chiave simmetrica

Attestazioni ACS

Controllo accesso basato sui ruoli

No

Sì

(tramite l'utilizzo di ruoli ACS)

Federazione del provider di identità

No

Sì

Informazioni aggiuntive

Ogni richiesta a entrambe le tecnologie di accodamento deve essere autenticata. Le code pubbliche con accesso anonimo non sono supportate.
Per lo schema di autenticazione fornito dalle code di Windows Azure è necessario l'utilizzo di una chiave simmetrica, cioè l'algoritmo Message Authentication Code (HMAC) basato su hash, calcolato con l'algoritmo SHA-256 e codificato come stringa Base64. Per informazioni dettagliate sul relativo protocollo, fare riferimento all'articolo Autenticazione dell'accesso all'account di archiviazione.
Nel Access Control di Active Directory di Windows Azure (anche noto come Servizio Access Control o ACS) supportato dal Service Bus sono disponibili tre ruoli distinti: Amministratore, Mittente e Ricevitore, che non sono supportati attualmente per le code di Windows Azure.
Poiché il Service Bus offre l'integrazione ACS, è possibile eseguire la federazione con Active Directory (tramite l'utilizzo di AFDS) e provider di identità Web comuni quali Live ID, Google, Facebook e Yahoo.

In questa sezione vengono confrontate le code di Windows Azure e del Service Bus relativamente ai costi.

Criteri di confronto	Code di Windows Azure	Code del Service Bus
Costo della transazione della coda	$0.01 (per 10.000 transazioni)	$0.01 (per 10.000 messaggi)
Operazioni fatturabili	Tutte	Solo invio/ricezione (nessun addebito per altre operazioni)
Transazioni inattive	Fatturabili (l'esecuzione di query su una coda vuota viene contata come transazione fatturabile)	Fatturabili (una ricezione in una coda vuota è considerata un messaggio fatturabile)
Costo di archiviazione	$0.14 (per GB/mese)	$0.00
Costi di trasferimento dei dati in uscita	$0.12 - $0.19 (a seconda dell'area geografica)	$0.12 - $0.19 (a seconda dell'area geografica)
Costi di transizioni del Access Control di Active Directory di Windows Azure (anche noto come Servizio Access Control o ACS)	$0.00 (poiché ACS non viene utilizzato)	$1.99 (per 100.000 richieste di token, vedere commento di seguito)

Informazioni aggiuntive

I trasferimenti dei dati vengono addebitati in base alla quantità totale di dati che vengono trasferiti dai data center di Windows Azure tramite Internet in un determinato periodo di fatturazione.
I trasferimenti dei dati tra servizi Windows Azure ubicati all'interno della stessa area secondaria non sono soggetti ad addebito.
Al momento della stesura di questo documento, tutti i trasferimenti dei dati in ingresso non sono soggetti ad addebito.
Il costo di transazioni ACS è trascurabile quando si effettuano operazioni di messaggistica nelle code del Service Bus. Tramite il Service Bus viene acquisito un token ACS per una singola istanza dell'oggetto factory di messaggistica. Il token viene quindi riutilizzato fino alla scadenza, dopo circa 20 minuti. Pertanto, il volume di operazioni di messaggistica nel Service Bus non è direttamente proporzionale alla quantità di transazioni ACS necessarie per supportare queste operazioni.
In base al supporto per polling prolungato, l'utilizzo di code del Service Bus può essere economico in situazioni in cui è richiesto il recapito a bassa latenza.

Nota
Tutti i costi sono soggetti a modifica. Nella tabella sopra indicata sono riportati i prezzi correnti al momento della stesura di questo articolo e non sono incluse eventuali offerte promozionali che possono essere attualmente disponibili. Per informazioni aggiornate sui prezzi, vedere la pagina relativa alla panoramica dei prezzi.

La scelta di utilizzare le code di Windows Azure o quelle del Service Bus si basa chiaramente su vari fattori che possono dipendere soprattutto dalla singole esigenze dell'applicazione in uso e dalla relativa architettura. Se nell'applicazione vengono utilizzate già le funzionalità principali di Windows Azure, è possibile scegliere le code di Windows Azure, specialmente se sono richieste la comunicazione e la messaggistica di base tra servizi o se sono necessarie code che possono avere dimensioni maggiori di 5 GB.

Poiché le code del Service Bus offrono numerose funzionalità avanzate, quali sessioni, transazioni rilevamento duplicato, mancato recapito automatico dei messaggi e funzionalità di pubblicazione e sottoscrizione durevoli, possono rappresentare la soluzione desiderata se si compila un'applicazione ibrida o se comunque queste funzionalità sono richieste dall'applicazione.

Nella parte iniziale di questo articolo è stato presentato un riepilogo di indicazioni normative. Successivamente, sono state elencate e confrontate le funzionalità di ogni tecnologia di accodamento offerta attualmente da Windows Azure. Elencando le funzionalità in gruppi funzionali, nell'argomento è stata fornita un'analisi parallela avanzata da un punto di vista visivo che dovrebbe aiutare a capire le analogie e le differenze tra le code di Windows Azure e quelle del Service Bus.

Acquisendo una comprensione più profonda delle due tecnologie, si sarà in grado di prendere una decisione più oculata circa la tecnologia di coda da utilizzare e il momento in cui adottarla.

Procedure consigliate per l'utilizzo dell'API di messaggistica negoziata del bus di servizio di Windows Azure

Best Practices for Performance Improvements Using Service Bus Brokered Messaging

Modalità di utilizzo delle code di Service Bus

Modalità di utilizzo del servizio di archiviazione delle code

Introduzione alle code e agli argomenti di Service Bus in Azure

Guida per gli sviluppatori a Service Bus

"Analisi dettagliata delle tabelle e delle code di Windows Azure"

Architettura di archiviazione di Windows Azure

"Utilizzo del servizio accodamento in Windows Azure"

Informazioni sulla larghezza di banda, sulle transazioni e sulla capacità per la fatturazione relativa all'archiviazione in Windows Azure