Esplorare i payload dei messaggi del bus di servizio e la serializzazione

  • 3 minuti

I messaggi trasportano un payload e metadati. I metadati, sotto forma di proprietà della coppia chiave-valore, descrivono il payload e danno istruzioni di gestione al bus di servizio e alle applicazioni. In alcuni casi, solo i metadati sono sufficienti per trasmettere le informazioni che il mittente vuole comunicare ai destinatari e il payload rimane vuoto.

Il modello a oggetti dei client ufficiali del bus di servizio per .NET e Java esegue il mapping da e verso i protocolli di collegamento supportati dal bus di servizio.

Un messaggio del bus di servizio è costituito da una sezione di payload binario che il bus di servizio non gestisce mai in alcun modulo sul lato servizio e da due set di proprietà. Le proprietà del broker sono definite dal sistema. Queste proprietà predefinite controllano le funzionalità a livello di messaggio all'interno del broker oppure sono mappate a elementi comuni e standardizzati dei metadati. Le proprietà utente sono una raccolta di coppie chiave-valore definite e impostate dall'applicazione.

Routing e correlazione dei messaggi

Un subset delle proprietà del broker, in particolare To, ReplyTo, ReplyToSessionId, MessageId, CorrelationId e SessionId, consente alle applicazioni di instradare i messaggi a destinazioni specifiche. I modelli seguenti descrivono il routing:

  • Richiesta/Risposta semplice: un server di pubblicazione invia un messaggio in una coda e aspetta una risposta dal consumer del messaggio. L'autore possiede una coda per ricevere le risposte. L'indirizzo di tale coda viene espresso nella proprietà ReplyTo del messaggio in uscita. Quando il consumer risponde, copia il valore MessageId del messaggio gestito nella proprietà CorrelationId del messaggio di risposta e recapita il messaggio alla destinazione indicata dalla proprietà ReplyTo. Un messaggio può ottenere più risposte, in base al contesto dell'applicazione.

  • Richiesta/Risposta multicast: variazione del modello precedente in cui un server di pubblicazione invia il messaggio in un argomento e più sottoscrittori diventano consumer idonei del messaggio. Ogni sottoscrittore può rispondere come illustrato in precedenza. Se ReplyTo fa riferimento a un argomento, tale set di risposte di individuazione può essere distribuito a un gruppo di destinatari.

  • Multiplexing: questa funzionalità della sessione consente il multiplexing dei flussi di messaggi correlati tramite una singola coda o sottoscrizione, in modo che ogni sessione o gruppo di messaggi correlati, identificati da valori SessionId corrispondenti, venga indirizzato a un ricevitore specifico mentre il ricevitore applica un blocco alla sessione. Altre informazioni sui dettagli delle sessioni sono disponibili qui.

  • Richiesta/Risposta con multiplexing: questa funzionalità della sessione abilita le risposte con multiplexing, consentendo a diverse entità di pubblicazione di condividere una coda di risposte. Configurando il valore ReplyToSessionId, l'entità di pubblicazione può richiedere ai consumer di copiare tale valore nella proprietà SessionId del messaggio di risposta. Non è necessario che la coda di pubblicazione o l'argomento sia compatibile con la sessione. Quando il messaggio viene inviato, l'autore può attendere che una sessione con il SessionId specificato materializzi nella coda accettando in modo condizionale un ricevitore di sessione.

Il routing all'interno di uno spazio dei nomi del bus di servizio usa regole di concatenamento automatico e sottoscrizione di argomenti. È possibile eseguire il routing tra spazi dei nomi usando App per la logica di Azure. La proprietà To è riservata per utilizzi futuri. Le applicazioni che implementano il routing devono farlo in base alle proprietà dell'utente e non si basano sulla proprietà To; Tuttavia, questa operazione non causerà problemi di compatibilità.

Serializzazione del payload

Quando è in transito o archiviato all'interno del bus di servizio, il payload è sempre un blocco binario opaco. La proprietà ContentType consente all'applicazione di descrivere il payload, con il formato suggerito per i valori della proprietà corrispondente a una descrizione di tipo contenuto MIME basata su IETF RFC2045, ad esempio application/json;charset=utf-8.

A differenza delle varianti Java o .NET Standard, la versione .NET Framework dell'API del bus di servizio supporta la creazione di istanze di BrokeredMessage passando oggetti .NET arbitrari nel costruttore.

Il protocollo SBMP legacy serializza gli oggetti con il serializzatore binario predefinito o con un serializzatore fornito esternamente. Il protocollo AMQP serializza gli oggetti in un oggetto AMQP. Il destinatario può recuperare tali oggetti con il metodo GetBody<T>(), fornendo il tipo previsto. Con AMQP, gli oggetti vengono serializzati in un grafico AMQP di oggetti ArrayList e IDictionary<string,object> e qualsiasi client AMQP può decodificarli.

Anche se questa magia di serializzazione nascosta è utile, se le applicazioni devono assumere il controllo esplicito della serializzazione degli oggetti e trasformare i grafici degli oggetti in flussi prima di includerli in un messaggio, è consigliabile eseguire l'operazione inversa sul lato ricevitore. Anche se AMQP ha un potente modello di codifica binaria, è legato all'ecosistema di messaggistica AMQP e i client HTTP hanno problemi di decodifica di tali payload.