A Service Bus-üzenet hasznos adatainak és szerializálásának megismerése

  • 3 perc

Az üzenetek hasznos adatokat és metaadatokat hordoznak. A metaadatok kulcs-érték pár tulajdonságok formájában vannak megadva, és ismertetik a hasznos adatokat, és kezelési utasításokat adnak a Service Busnak és az alkalmazásoknak. Időnként ez a metaadatok elegendőek a feladó által a fogadókkal kommunikálni kívánt információk hordozásához, és a hasznos adatok üresek maradnak.

A .NET- és Java-alapú hivatalos Service Bus-ügyfelek objektummodellje a Service Bus által támogatott drótprotokollokra és -protokollokra van leképelve.

A Service Bus-üzenetek egy bináris hasznos adatszakaszból állnak, amelyet a Service Bus soha nem kezel semmilyen formában a szolgáltatás oldalán, és két tulajdonságkészletből. A közvetítő tulajdonságai rendszerként vannak definiálva. Ezek az előre definiált tulajdonságok vagy az üzenetszintű funkciókat vezérli a közvetítőn belül, vagy általános és szabványosított metaadatelemekre vannak leképezve. A felhasználói tulajdonságok az alkalmazás által definiált és beállított kulcs-érték párok gyűjteményei.

Üzenet útválasztása és korrelációja

A közvetítő tulajdonságainak egy részhalmaza, pontosabban To, ReplyTo, ReplyToSessionId, MessageId, CorrelationIdés SessionId, segít az alkalmazásoknak az üzenetek adott célhelyekre való átirányításában. Az alábbi minták az útválasztást írják le:

  • Egyszerű kérés/válasz: A közzétevő üzenetet küld egy üzenetsorba, és választ vár az üzenet fogyasztójától. A válasz fogadásához a közzétevőnek van egy üzenetsora. Az üzenetsor címe a ReplyTo kimenő üzenet tulajdonságában található. Amikor a fogyasztó válaszol, átmásolja a MessageId kezelt üzenetet a CorrelationId válaszüzenet tulajdonságába, és elküldi az üzenetet a ReplyTo tulajdonság által megjelölt célhelyre. Egy üzenet az alkalmazás környezetétől függően több választ is adhat.

  • Csoportos küldési kérés/válasz: A korábbi minta változataként a közzétevő elküldi az üzenetet egy témakörbe, és több előfizető is jogosulttá válik az üzenet használatára. Az egyes előfizetők a korábban ismertetett módon válaszolhatnak. Ha ReplyTo egy témakörre mutat, az ilyen felderítési válaszok eloszthatók a közönség számára.

  • Multiplexing: Ez a munkamenet-funkció lehetővé teszi a kapcsolódó üzenetek streamjeinek multiplexálását egyetlen üzenetsoron vagy előfizetésen keresztül, így a kapcsolódó üzenetek minden munkamenete (vagy csoportja) egy adott SessionId fogadóhoz lesz irányítva, miközben a fogadó zárolva tartja a munkamenetet. A munkamenetek részleteiről itt olvashat bővebben.

  • Multiplexed request/reply: Ez a munkamenet-funkció lehetővé teszi a multiplexált válaszokat, így több közzétevő is megoszthat egy válaszsort. A beállítással ReplyToSessionIda közzétevő utasíthatja a fogyasztó(ka)t, hogy másolja ezt az értéket a SessionId válaszüzenet tulajdonságába. A közzétételi üzenetsornak vagy a témakörnek nem kell munkamenet-tudatosnak lennie. Az üzenet elküldésekor a közzétevő megvárhatja, amíg a megadott SessionId munkamenet létrejön az üzenetsoron egy munkamenet-fogadó feltételes elfogadásával.

A Service Bus-névtéren belüli útválasztás automatikus láncolást és témakör-előfizetési szabályokat használ. A névterek közötti útválasztás az Azure LogicApps használatával hajtható végre. A To tulajdonság jövőbeli használatra van fenntartva. Az útválasztást megvalósító alkalmazásoknak ezt a felhasználói tulajdonságok alapján kell elvégeznie, és nem a To tulajdonságra kell támaszkodnia, azonban ez most nem okoz kompatibilitási problémákat.

Hasznos adatok szerializálása

Amikor a Service Buson belül vannak tárolva, a hasznos adatok mindig átlátszatlan bináris blokkok. A ContentType tulajdonság lehetővé teszi az alkalmazások számára a hasznos adatok leírását, a tulajdonságértékek javasolt formátuma például az IETF RFC2045 szerinti MIME-tartalomtípus leírása, application/json;charset=utf-8például.

A Java vagy a .NET Standard változatoktól eltérően a Service Bus API .NET-keretrendszer verziója támogatja a példányok létrehozását BrokeredMessage úgy, hogy tetszőleges .NET-objektumokat ad át a konstruktornak.

Az örökölt SBMP protokoll szerializálja az objektumokat az alapértelmezett bináris szerializálóval vagy külsőleg megadott szerializálóval. Az AMQP protokoll amqp objektummá szerializálja az objektumokat. A fogadó le tudja kérni ezeket az objektumokat a GetBody<T>() metódussal, és megadja a várt típust. Az AMQP használatával az objektumok AMQP-gráfjába ArrayList és IDictionary<string,object> objektumaiba szerializálódnak, és bármely AMQP-ügyfél dekódolhatja őket.

Bár ez a rejtett szerializálási varázslat kényelmes, ha az alkalmazásoknak explicit módon kell irányítaniuk az objektum szerializálását, és streamekké kell alakítaniuk az objektumgráfjaikat, mielőtt üzenetté alakítanák őket, akkor a fogadó oldalon kell elvégezniük a fordított műveletet. Bár az AMQP hatékony bináris kódolási modellel rendelkezik, az AMQP üzenetkezelési ökoszisztémához van kötve, és a HTTP-ügyfeleknek problémájuk van az ilyen hasznos adatok dekódolásával.