Explorați sarcinile utile și serializarea mesajelor magistralei de service

  • 3 minute

Mesajele poartă o sarcină utilă și metadate. Metadatele sunt sub formă de proprietăți pereche cheie-valoare, descriu sarcina utilă și oferă instrucțiuni de manipulare magistralei de service și aplicațiilor. Ocazional, doar aceste metadate sunt suficiente pentru a transporta informațiile pe care expeditorul dorește să le comunice receptorilor, iar sarcina utilă rămâne goală.

Modelul obiect al clienților Service Bus oficiali pentru hărțile .NET și Java către și de la protocoalele de cablu acceptate de Service Bus.

Un mesaj Service Bus constă dintr-o secțiune binară de sarcină utilă pe care Service Bus nu o gestionează niciodată sub nicio formă pe partea de service și două seturi de proprietăți. Proprietățile brokerului sunt definite de sistem. Aceste proprietăți predefinite fie controlează funcționalitatea la nivel de mesaj în interiorul brokerului, fie se mapează la elemente de metadate comune și standardizate. Proprietățile utilizatorului sunt o colecție de perechi cheie-valoare definite și setate de aplicație.

Rutarea și corelarea mesajelor

Un subset al proprietăților brokerului, în special To, ReplyTo, , ReplyToSessionId, MessageIdși CorrelationIdSessionId, ajută aplicațiile să direcționeze mesajele către anumite destinații. Următoarele modele descriu rutarea:

  • Cerere/răspuns simplu: un editor trimite un mesaj într-o coadă și așteaptă un răspuns de la consumatorul mesajului. Editorul deține o coadă pentru a primi răspunsurile. Adresa acelei cozi este conținută ReplyTo în proprietatea mesajului de ieșire. Când consumatorul răspunde, copiază MessageId mesajul gestionat în CorrelationId proprietatea mesajului de răspuns și livrează mesajul la destinația indicată de ReplyTo proprietate. Un mesaj poate genera mai multe răspunsuri, în funcție de contextul aplicației.

  • Solicitare/răspuns cu difuzare multiplă: ca variantă a modelului anterior, un editor trimite mesajul într-un subiect și mai mulți abonați devin eligibili să consume mesajul. Fiecare dintre abonați ar putea răspunde în modul descris anterior. Dacă ReplyTo indică un subiect, un astfel de set de răspunsuri de descoperire poate fi distribuit unui public.

  • Multiplexare: Această caracteristică de sesiune permite multiplexarea fluxurilor de mesaje conexe printr-o singură coadă sau abonament, astfel încât fiecare sesiune (sau grup) de mesaje conexe, identificate prin potrivirea SessionId valorilor, să fie direcționate către un anumit receptor în timp ce receptorul ține sesiunea sub blocare. Aflați mai multe despre detaliile sesiunilor aici.

  • Cerere/răspuns multiplexat: Această caracteristică de sesiune permite răspunsuri multiplexate, permițând mai multor editori să partajeze o coadă de răspuns. Prin setarea ReplyToSessionId, editorul poate instrui unul sau mai mulți consumatori să copieze acea valoare în SessionId proprietatea mesajului de răspuns. Coada sau subiectul de publicare nu trebuie să fie conștient de sesiune. Când mesajul este trimis, editorul poate aștepta ca o sesiune cu dat SessionId să se materializeze pe coadă prin acceptarea condiționată a unui receptor de sesiune.

Rutarea în interiorul unui spațiu de nume Magistrală de servicii utilizează înlănțuirea automată înainte și regulile de abonare la subiecte. Rutarea între spațiile de nume poate fi efectuată utilizând Azure LogicApps. Proprietatea To este rezervată pentru utilizare ulterioară. Aplicațiile care implementează rutarea ar trebui să facă acest lucru pe baza proprietăților utilizatorului și să nu se bazeze pe proprietate; totuși, acest lucru acum nu va cauza probleme de To compatibilitate.

Serializarea sarcinii utile

Când este în tranzit sau depozitat în interiorul magistralei de servicii, sarcina utilă este întotdeauna un bloc binar opac. Proprietatea ContentType permite aplicațiilor să descrie sarcina utilă, formatul sugerat pentru valorile proprietății fiind o descriere a tipului de conținut MIME conform RFC2045 IETF; de exemplu, application/json;charset=utf-8.

Spre deosebire de variantele Java sau .NET Standard, versiunea .NET Framework a API-ului Service Bus acceptă crearea BrokeredMessage de instanțe prin trecerea obiectelor .NET arbitrare în constructor.

Protocolul SBMP moștenit serializează obiectele cu serializatorul binar implicit sau cu un serializator furnizat extern. Protocolul AMQP serializează obiectele într-un obiect AMQP. Receptorul poate prelua acele obiecte cu metoda GetBody<T>() , furnizând tipul așteptat. Cu AMQP, obiectele sunt serializate într-un grafic AMQP de ArrayList și IDictionary<string,object> obiecte, iar orice client AMQP le poate decoda.

În timp ce această magie de serializare ascunsă este convenabilă, dacă aplicațiile ar trebui să preia controlul explicit al serializării obiectelor și să-și transforme graficele de obiecte în fluxuri înainte de a le include într-un mesaj, ar trebui să facă operația inversă pe partea receptorului. În timp ce AMQP are un model puternic de codificare binară, este legat de ecosistemul de mesagerie AMQP, iar clienții HTTP au probleme cu decodarea unor astfel de sarcini utile.