Eksplorowanie ładunków komunikatów i serializacji komunikatów usługi Service Bus

Komunikaty zawierają ładunek i metadane. Metadane są w postaci właściwości pary klucz-wartość i opisują ładunek oraz zawierają instrukcje obsługi usługi Service Bus i aplikacji. Od czasu do czasu same metadane są wystarczające do przenoszenia informacji, które nadawca chce komunikować się z odbiorcami, a ładunek pozostaje pusty.

Model obiektów oficjalnych klientów usługi Service Bus dla platformy .NET i języka Java mapuje na i z protokołów przewodowych obsługiwane przez usługę Service Bus.

Komunikat usługi Service Bus składa się z sekcji ładunku binarnego, którą usługa Service Bus nigdy nie obsługuje w żadnej formie po stronie usługi i dwa zestawy właściwości. Właściwości brokera są definiowane przez system. Te wstępnie zdefiniowane właściwości kontrolują funkcjonalność na poziomie komunikatów wewnątrz brokera lub są mapowane na typowe i ustandaryzowane elementy metadanych. Właściwości użytkownika są kolekcją par klucz-wartość zdefiniowanych i ustawionych przez aplikację.

Routing i korelacja komunikatów

Podzbiór właściwości brokera, w szczególności To, ReplyTo, ReplyToSessionId, MessageIdCorrelationId, i SessionId, ułatwiają aplikacjom kierowanie komunikatów do określonych miejsc docelowych. Następujące wzorce opisują routing:

• Proste żądanie/odpowiedź: Wydawca wysyła wiadomość do kolejki i oczekuje odpowiedzi od odbiorcy wiadomości. Wydawca jest właścicielem kolejki w celu otrzymania odpowiedzi. Adres tej kolejki znajduje się we ReplyTo właściwości komunikatu wychodzącego. Gdy odbiorca odpowie, kopiuje MessageId on obsłużony komunikat do CorrelationId właściwości komunikatu odpowiedzi i dostarcza komunikat do miejsca docelowego wskazanego ReplyTo przez właściwość . Jeden komunikat może zwracać wiele odpowiedzi w zależności od kontekstu aplikacji.

• Żądanie/odpowiedź multiemisji: jako odmiana poprzedniego wzorca wydawca wysyła wiadomość do tematu, a wielu subskrybentów kwalifikuje się do korzystania z wiadomości. Każdy z subskrybentów może odpowiedzieć w sposób opisany wcześniej. Jeśli ReplyTo wskazuje temat, taki zestaw odpowiedzi odnajdywania może być dystrybuowany do odbiorców.

• Multipleksowanie: Ta funkcja sesji umożliwia multipleksowanie strumieni powiązanych komunikatów za pośrednictwem jednej kolejki lub subskrypcji, tak aby każda sesja (lub grupa) powiązanych komunikatów, zidentyfikowana przez pasujące SessionId wartości, są kierowane do określonego odbiornika, podczas gdy odbiorca przechowuje sesję pod blokadą. Dowiedz się więcej o szczegółach sesji tutaj.

• Multipleksowane żądanie/odpowiedź: ta funkcja sesji umożliwia multipleksowane odpowiedzi, dzięki czemu kilku wydawców może współużytkować kolejkę odpowiedzi. ReplyToSessionIdUstawiając wartość , wydawca może poinstruować co najmniej jednego użytkownika, aby skopiował tę wartość do SessionId właściwości wiadomości odpowiedzi. Kolejka publikowania lub temat nie musi być świadoma sesji. Po wysłaniu komunikatu wydawca może poczekać na sesję z daną SessionId , aby zmaterializować się w kolejce, warunkowo akceptując odbiornik sesji.

Serializacja ładunku

Podczas przesyłania lub przechowywania wewnątrz usługi Service Bus ładunek jest zawsze nieprzezroczystym blokiem binarnym. Właściwość ContentType umożliwia aplikacjom opisywanie ładunku z sugerowanym formatem wartości właściwości będących opisem typu zawartości MIME zgodnie z RFC2045 IETF, na przykład application/json;charset=utf-8.

W przeciwieństwie do wariantów języka Java lub .NET Standard wersja .NET Framework interfejsu API usługi Service Bus obsługuje tworzenie BrokeredMessage wystąpień przez przekazanie dowolnych obiektów .NET do konstruktora.

Starszy protokół SBMP serializuje obiekty z domyślnym serializatorem binarnym lub serializatorem dostarczanym zewnętrznie. Protokół AMQP serializuje obiekty w obiekcie AMQP. Odbiornik może pobrać te obiekty za pomocą GetBody<T>() metody , podając oczekiwany typ. W przypadku protokołu AMQP obiekty są serializowane w grafie ArrayList protokołu AMQP obiektów i IDictionary<string,object> , a każdy klient amQP może je dekodować.

Chociaż ta ukryta magia serializacji jest wygodna, jeśli aplikacje powinny przejąć jawną kontrolę nad serializacji obiektów i przekształcić wykresy obiektów w strumienie przed dołączeniem ich do komunikatu, powinny wykonać operację odwrotną po stronie odbiornika. Protokół AMQP ma zaawansowany model kodowania binarnego, ale jest powiązany z ekosystemem obsługi komunikatów protokołu AMQP, a klienci HTTP mają problemy z dekodowaniem takich ładunków.