Przewodnik po protokole AMQP 1.0 w usłudze Azure Service Bus i usłudze Event Hubs
Advanced Message Queueing Protocol 1.0 to ustandaryzowany protokół framingu i transferu na potrzeby asynchronicznego, bezpiecznego i niezawodnego przesyłania komunikatów między dwiema stronami. Jest to podstawowy protokół komunikatów usługi Azure Service Bus i usługi Azure Event Hubs.
AMQP 1.0 jest wynikiem szerokiej współpracy branżowej, która połączyła dostawców oprogramowania pośredniczącego, takich jak Microsoft i Red Hat, z wieloma użytkownikami oprogramowania pośredniczącego obsługi komunikatów, takimi jak JP Morgan Chase reprezentujący branżę usług finansowych. Techniczne forum standaryzacji dla protokołu AMQP i specyfikacji rozszerzenia jest OASIS i osiągnął formalne zatwierdzenie jako międzynarodowy standard iso/IEC 19494:2014.
Cele
W tym artykule przedstawiono podsumowanie podstawowych pojęć specyfikacji obsługi komunikatów amQP 1.0 wraz ze specyfikacjami rozszerzeń opracowanymi przez Komitet Techniczny aplikacji OASIS AMQP oraz wyjaśniono, jak usługa Azure Service Bus implementuje i opiera się na tych specyfikacjach.
Celem jest każdy deweloper korzystający z dowolnego istniejącego stosu klienta protokołu AMQP 1.0 na dowolnej platformie, aby móc korzystać z usługi Azure Service Bus za pośrednictwem protokołu AMQP 1.0.
Typowe stosy amQP ogólnego przeznaczenia 1.0, takie jak Apache Qpid Proton lub AMQP.NET Lite, implementują wszystkie podstawowe elementy protokołu AMQP 1.0, takie jak sesje lub łącza. Te podstawowe elementy są czasami opakowane przy użyciu interfejsu API wyższego poziomu; Apache Proton oferuje nawet dwa, imperatywne interfejs API Messenger i reaktywny interfejs API Reactor.
W poniższej dyskusji przyjęto założenie, że zarządzanie połączeniami, sesjami i linkami protokołu AMQP oraz obsługą transferów ramek i sterowanie przepływem jest obsługiwane przez odpowiedni stos (taki jak Apache Proton-C) i nie wymaga zbyt dużej uwagi od deweloperów aplikacji. Abstrakcyjnie zakładamy istnienie kilku elementów pierwotnych interfejsu API, takich jak możliwość nawiązywania połączenia, oraz tworzenie jakiejś formy obiektów abstrakcji nadawcy i odbiorcy , które następnie mają jakiś kształt send() operacji i receive() odpowiednio.
Podczas omawiania zaawansowanych możliwości usługi Azure Service Bus, takich jak przeglądanie komunikatów lub zarządzanie sesjami, te funkcje są wyjaśnione w kategoriach AMQP, ale także jako warstwowa pseudo-implementacja na podstawie tego zakładanego abstrakcji interfejsu API.
Co to jest AMQP?
AMQP to protokół framingu i transferu. Framing oznacza, że zapewnia strukturę strumieni danych binarnych, które przepływają w obu kierunkach połączenia sieciowego. Struktura zapewnia podział na odrębne bloki danych, nazywane ramkami, które mają być wymieniane między połączonymi stronami. Możliwości transferu zapewniają, że obie strony komunikujące się mogą ustalić wspólną wiedzę na temat tego, kiedy ramy zostaną przeniesione, a kiedy transfery zostaną uznane za ukończone.
W przeciwieństwie do wcześniejszych wersji roboczych wygasłych wersji grupy roboczej AMQP, które są nadal używane przez kilku brokerów komunikatów, końcowych grupy roboczej i ustandaryzowanego protokołu AMQP 1.0 nie określa obecności brokera komunikatów ani żadnej konkretnej topologii dla jednostek wewnątrz brokera komunikatów.
Protokół może służyć do symetrycznej komunikacji równorzędnej między elementami równorzędnymi w celu interakcji z brokerami komunikatów, które obsługują kolejki i publikują/subskrybuj jednostki, tak jak usługa Azure Service Bus. Można go również używać do interakcji z infrastrukturą obsługi komunikatów, gdzie wzorce interakcji różnią się od zwykłych kolejek, podobnie jak w przypadku usługi Azure Event Hubs. Centrum zdarzeń działa jak kolejka, gdy zdarzenia są do niego wysyłane, ale działa bardziej jak usługa magazynu szeregowego, gdy zdarzenia są odczytywane z niego; nieco przypomina stację taśm. Klient wybiera przesunięcie do dostępnego strumienia danych, a następnie obsłuży wszystkie zdarzenia z tego przesunięcia do najnowszej dostępnej wersji.
Protokół AMQP 1.0 został zaprojektowany tak, aby był rozszerzalny, umożliwiając dalsze specyfikacje w celu zwiększenia jego możliwości. Trzy specyfikacje rozszerzeń omówione w tym dokumencie ilustrują je. W przypadku komunikacji za pośrednictwem istniejącej infrastruktury protokołu HTTPS/WebSocket konfigurowanie natywnych portów TCP protokołu AMQP może być trudne. Specyfikacja powiązania definiuje sposób warstwy protokołu AMQP za pośrednictwem obiektów WebSocket. W celu interakcji z infrastrukturą obsługi komunikatów w sposób żądania/odpowiedzi na potrzeby zarządzania lub zapewnienia zaawansowanych funkcji specyfikacja zarządzania amQP definiuje wymagane podstawowe typy pierwotne interakcji. W przypadku integracji modelu autoryzacji federacyjnej specyfikacja zabezpieczeń oparta na oświadczeniach protokołu AMQP definiuje sposób kojarzenia i odnawiania tokenów autoryzacji skojarzonych z linkami.
Podstawowe scenariusze protokołu AMQP
W tej sekcji opisano podstawowe użycie protokołu AMQP 1.0 w usłudze Azure Service Bus, w tym tworzenie połączeń, sesji i łączy oraz przesyłanie komunikatów do i z jednostek usługi Service Bus, takich jak kolejki, tematy i subskrypcje.
Najbardziej autorytatywnym źródłem, aby dowiedzieć się, jak działa protokół AMQP, jest specyfikacja AMQP 1.0, ale specyfikacja została napisana w celu dokładnego przewodnika implementacji i nie uczenia protokołu. Ta sekcja koncentruje się na wprowadzeniu jak najwięcej terminologii do opisania sposobu, w jaki usługa Service Bus używa protokołu AMQP 1.0. Aby zapoznać się z bardziej kompleksowym wprowadzeniem do protokołu AMQP i szerszym omówieniem protokołu AMQP 1.0, zapoznaj się z tym kursem wideo.
Połączenia i sesje
Protokół AMQP wywołuje kontenery komunikujących się programów. Zawierają one węzły, które są jednostkami komunikującymi się wewnątrz tych kontenerów. Kolejka może być takim węzłem. Protokół AMQP umożliwia multipleksowanie, więc jedno połączenie może być używane dla wielu ścieżek komunikacji między węzłami; na przykład klient aplikacji może jednocześnie odbierać z jednej kolejki i wysyłać do innej kolejki za pośrednictwem tego samego połączenia sieciowego.
Połączenie sieciowe jest zatem zakotwiczone w kontenerze. Jest inicjowany przez kontener w roli klienta, tworząc wychodzące połączenie gniazda TCP z kontenerem w roli odbiorcy, który nasłuchuje i akceptuje przychodzące połączenia TCP. Uzgadnianie połączenia obejmuje negocjowanie wersji protokołu, deklarowanie lub negocjowanie korzystania z protokołu Transport Level Security (TLS)/Secure Sockets Layer (SSL) oraz uzgadnianie uwierzytelniania/autoryzacji w zakresie połączenia opartego na protokole SASL.
Usługa Azure Service Bus lub Azure Event Hubs wymaga używania protokołu TLS przez cały czas. Obsługuje połączenia za pośrednictwem portu TCP 5671, gdzie połączenie TCP jest najpierw nakładane przy użyciu protokołu TLS przed wejściem uzgadniania protokołu AMQP, a także obsługuje połączenia za pośrednictwem portu TCP 5672, gdzie serwer natychmiast oferuje obowiązkowe uaktualnienie połączenia z protokołem TLS przy użyciu modelu określonego przez protokół AMQP. Powiązanie protokołu WebSocket protokołu AMQP tworzy tunel za pośrednictwem portu TCP 443, który jest wówczas odpowiednikiem połączeń PROTOKOŁU AMQP 5671.
Po skonfigurowaniu połączenia i protokołu TLS usługa Service Bus oferuje dwie opcje mechanizmu SASL:
- SASL PLAIN jest często używany do przekazywania poświadczeń nazwy użytkownika i hasła do serwera. Usługa Service Bus nie ma kont, ale nazwanych reguł zabezpieczeń dostępu współdzielonego, które nadają prawa i są skojarzone z kluczem. Nazwa reguły jest używana jako nazwa użytkownika, a klucz (jako tekst zakodowany w formacie base64) jest używany jako hasło. Prawa skojarzone z wybraną regułą zarządzają operacjami dozwolonymi na połączeniu.
- SASL ANONYMOUS jest używany do pomijania autoryzacji SASL, gdy klient chce użyć modelu zabezpieczeń opartych na oświadczeniach (CBS), który został opisany w dalszej części. Dzięki tej opcji połączenie klienta można nawiązać anonimowo przez krótki czas, w którym klient może korzystać tylko z punktu końcowego CBS, a uzgadnianie CBS musi zostać ukończone.
Po nawiązaniu połączenia transportowego kontenery deklarują maksymalny rozmiar ramek, które są skłonne obsłużyć, a po przekroczeniu limitu czasu bezczynności jednostronnie rozłączą się, jeśli nie ma aktywności w połączeniu.
Deklarują również liczbę obsługiwanych kanałów współbieżnych. Kanał to jednokierunkowa, wychodząca, wirtualna ścieżka transferu na szczycie połączenia. Sesja pobiera kanał z każdego z połączonych kontenerów, aby utworzyć dwukierunkową ścieżkę komunikacji.
Sesje mają model sterowania przepływem opartym na oknie; po utworzeniu sesji każda strona deklaruje, ile ramek jest skłonnych zaakceptować w oknie odbierania. W miarę wymiany ramek strony, przeniesione ramki wypełniają to okno i transfery zatrzymują się, gdy okno jest pełne i aż okno zostanie zresetowane lub rozwinięte przy użyciu przepływu performatywne (performative jest termin AMQP dla gestów na poziomie protokołu wymienianych między obie strony).
Ten model oparty na oknach jest w przybliżeniu analogiczny do koncepcji TCP sterowania przepływem opartym na oknach, ale na poziomie sesji wewnątrz gniazda. Koncepcja protokołu pozwalająca na wiele współbieżnych sesji istnieje tak, że ruch o wysokim priorytecie może być pędzony obok ograniczonego normalnego ruchu, jak na autostradzie express lane.
Usługa Azure Service Bus obecnie używa dokładnie jednej sesji dla każdego połączenia. Maksymalny rozmiar ramki usługi Service Bus to 262 144 bajtów (256-K bajtów) dla usługi Service Bus Standard. Jest to 1048576 (100 MB) dla usług Service Bus Premium i Event Hubs. Usługa Service Bus nie nakłada żadnych okien ograniczania na poziomie sesji, ale regularnie resetuje okno w ramach sterowania przepływem na poziomie łącza (zobacz następną sekcję).
Połączenia, kanały i sesje są efemeryczne. Jeśli połączenie bazowe zostanie zwinięte, połączenia, tunel TLS, kontekst autoryzacji SASL i sesje muszą zostać ponownie wydane.
Wymagania dotyczące portów wychodzących protokołu AMQP
Klienci korzystający z połączeń AMQP za pośrednictwem protokołu TCP wymagają otwarcia portów 5671 i 5672 w zaporze lokalnej. Oprócz tych portów może być konieczne otwarcie dodatkowych portów, jeśli włączono funkcję EnableLinkRedirect . EnableLinkRedirect to nowa funkcja obsługi komunikatów, która pomaga pominąć jeden przeskok podczas odbierania komunikatów, co pomaga zwiększyć przepływność. Klient zacznie komunikować się bezpośrednio z usługą zaplecza w zakresie portów 104XX, jak pokazano na poniższej ilustracji.
Klient platformy .NET zakończy się niepowodzeniem z użyciem elementu SocketException ("Podjęto próbę uzyskania dostępu do gniazda w sposób zabroniony przez jego uprawnienia dostępu"), jeśli te porty zostaną zablokowane przez zaporę. Tę funkcję można wyłączyć, ustawiając EnableAmqpLinkRedirect=false w parametry połączenia, co wymusza na klientach komunikację z usługą zdalną przez port 5671.
Powiązanie protokołu WebSocket protokołu AMQP zapewnia mechanizm tunelowania połączenia amQP za pośrednictwem transportu protokołu WebSocket. To powiązanie tworzy tunel za pośrednictwem portu TCP 443, który jest odpowiednikiem połączeń AMQP 5671. Użyj obiektów WebSocket protokołu AMQP, jeśli stoisz za zaporą, która blokuje połączenia TCP przez porty 5671, 5672, ale zezwala na połączenia TCP za pośrednictwem portu 443 (https).
Linki
Protokół AMQP przesyła komunikaty za pośrednictwem łączy. Link to ścieżka komunikacji utworzona przez sesję, która umożliwia przesyłanie komunikatów w jednym kierunku; negocjacje w sprawie stanu transferu są ponad połączeniem i dwukierunkowym między połączonymi stronami.
Łącza mogą być tworzone przez dowolny kontener w dowolnym momencie i przez istniejącą sesję, co sprawia, że protokół AMQP różni się od wielu innych protokołów, w tym protokołu HTTP i MQTT, gdzie inicjowanie transferów i ścieżki transferu jest wyłącznym uprawnieniem jednostki tworzącej połączenie gniazda.
Kontener inicjujący łącze prosi przeciwny kontener o zaakceptowanie linku i wybierze rolę nadawcy lub odbiorcy. W związku z tym kontener może inicjować tworzenie jednokierunkowych lub dwukierunkowych ścieżek komunikacyjnych, a drugi modelowany jako pary łączy.
Łącza są nazwane i skojarzone z węzłami. Jak określono na początku, węzły to komunikujące się jednostki wewnątrz kontenera.
W usłudze Service Bus węzeł jest bezpośrednio odpowiednikiem kolejki, tematu, subskrypcji lub podzapytania kolejki lub subskrypcji. Nazwa węzła używana w usłudze AMQP jest zatem względną nazwą jednostki w przestrzeni nazw usługi Service Bus. Jeśli kolejka ma nazwę myqueue, jest to również nazwa węzła AMQP. Subskrypcja tematu jest zgodna z konwencją interfejsu API PROTOKOŁU HTTP, sortując je do kolekcji zasobów "subskrypcje", a tym samym podsieć subskrypcji w temacie mytopic ma nazwę węzła AMQP mytopic/subscriptions/sub.
Klient łączący jest również wymagany do używania nazwy węzła lokalnego do tworzenia linków; Usługa Service Bus nie jest nakazowa dla tych nazw węzłów i nie interpretuje ich. Stosy klientów protokołu AMQP 1.0 zwykle używają schematu w celu zapewnienia, że te nazwy węzłów efemerycznych są unikatowe w zakresie klienta.
Przeniesienia
Po ustanowieniu linku komunikaty mogą być przesyłane za pośrednictwem tego linku. W usłudze AMQP transfer jest wykonywany za pomocą jawnego gestu protokołu ( wykonawcy transferu ), który przenosi komunikat z nadawcy do odbiorcy za pośrednictwem łącza. Przeniesienie jest kompletne, gdy jest "rozliczane", co oznacza, że obie strony ustaliły wspólne zrozumienie wyniku tego przeniesienia.
W najprostszym przypadku nadawca może wybrać wysyłanie komunikatów "wstępnie rozliczonych", co oznacza, że klient nie jest zainteresowany wynikiem, a odbiorca nie udziela żadnych opinii na temat wyniku operacji. Ten tryb jest obsługiwany przez usługę Service Bus na poziomie protokołu AMQP, ale nie jest uwidaczniony w żadnym z interfejsów API klienta.
Zwykły przypadek polega na tym, że komunikaty są wysyłane niespokojne, a odbiorca wskazuje akceptację lub odrzucenie przy użyciu dyspozycji performatywnej. Odrzucenie występuje, gdy odbiorca nie może zaakceptować komunikatu z jakiegokolwiek powodu, a komunikat o odrzuceniu zawiera informacje o przyczynie, która jest strukturą błędów zdefiniowaną przez protokół AMQP. Jeśli komunikaty są odrzucane z powodu błędów wewnętrznych wewnątrz usługi Service Bus, usługa zwraca dodatkowe informacje wewnątrz tej struktury, które mogą służyć do dostarczania wskazówek diagnostycznych dla personelu pomocy technicznej, jeśli zgłaszasz żądania pomocy technicznej. Więcej informacji o błędach znajdziesz później.
Szczególną formą odrzucenia jest zwolniony stan, który wskazuje, że odbiorca nie ma zastrzeżeń technicznych do przeniesienia, ale także nie ma interesu w rozstrzyganiu przeniesienia. Ten przypadek istnieje, na przykład gdy komunikat jest dostarczany do klienta usługi Service Bus, a klient decyduje się "porzucić" komunikat, ponieważ nie może wykonać pracy wynikającej z przetwarzania komunikatu; samo dostarczanie komunikatów nie jest wadliwe. Odmiana tego stanu to zmodyfikowany stan, który umożliwia zmianę komunikatu podczas jego wydawania. Ten stan nie jest obecnie używany przez usługę Service Bus.
Specyfikacja amQP 1.0 definiuje kolejny stan dyspozycji nazywany odebranym, który w szczególności pomaga w obsłudze odzyskiwania łącza. Odzyskiwanie linków umożliwia ponowne utworzenie stanu łącza i wszystkich oczekujących dostaw na podstawie nowego połączenia i sesji, gdy poprzednie połączenie i sesja zostały utracone.
Usługa Service Bus nie obsługuje odzyskiwania linków; jeśli klient utraci połączenie z usługą Service Bus z oczekującym transferem komunikatów, ten transfer komunikatów zostanie utracony, a klient musi ponownie nawiązać połączenie, ponownie opublikować link i ponowić próbę przeniesienia.
W związku z tym usługi Service Bus i Event Hubs obsługują transfer "co najmniej raz", w którym nadawca może mieć pewność, że wiadomość została zapisana i zaakceptowana, ale nie obsługuje transferów "dokładnie raz" na poziomie protokołu AMQP, gdzie system podejmie próbę odzyskania łącza i będzie nadal negocjować stan dostawy, aby uniknąć duplikowania transferu komunikatów.
Aby zrekompensować możliwe zduplikowane wysyłanie, usługa Service Bus obsługuje wykrywanie duplikatów jako opcjonalną funkcję w kolejkach i tematach. Wykrywanie duplikatów rejestruje identyfikatory komunikatów wszystkich komunikatów przychodzących w oknie czasowym zdefiniowanym przez użytkownika, a następnie dyskretnie usuwa wszystkie komunikaty wysyłane z tymi samymi identyfikatorami komunikatów w tym samym oknie.
Sterowanie przepływem
Oprócz modelu sterowania przepływem na poziomie sesji, który został wcześniej omówiony, każdy link ma własny model sterowania przepływem. Sterowanie przepływem na poziomie sesji chroni kontener przed koniecznością obsługi zbyt wielu ramek jednocześnie, kontrolka przepływu na poziomie łącza umieszcza aplikację za liczbę komunikatów, które chce obsłużyć z linku i kiedy.
Na linku transfery mogą wystąpić tylko wtedy, gdy nadawca ma wystarczającą ilość środków na łącze. Środki linku to licznik ustawiony przez odbiorcę przy użyciu funkcji performatywnej przepływu , która jest ograniczona do łącza. Gdy nadawca ma przypisane środki na łącze, próbuje wykorzystać ten kredyt, dostarczając komunikaty. Każde dostarczanie komunikatów dekrementuje pozostałe środki na łącze o 1. Po użyciu środków na połączenie dostawy zatrzymają się.
Gdy usługa Service Bus znajduje się w roli odbiorcy, natychmiast udostępnia nadawcy bardzo szczegółowe środki, dzięki czemu komunikaty mogą być wysyłane natychmiast. W miarę użycia środków linku usługa Service Bus od czasu do czasu wysyła do nadawcy przepływ , aby zaktualizować saldo środków linku.
W roli nadawcy usługa Service Bus wysyła komunikaty, aby wykorzystać wszystkie zaległe środki na łącze.
Wywołanie "odbierania" na poziomie interfejsu API przekłada się na przepływ , który jest przesyłany do usługi Service Bus przez klienta, a usługa Service Bus zużywa ten kredyt, przyjmując pierwszy dostępny, odblokowany komunikat z kolejki, blokując go i przesyłając go. Jeśli nie ma komunikatu łatwo dostępnego do dostarczenia, wszelkie zaległe środki przez dowolny link ustanowiony z tym konkretnym podmiotem pozostają rejestrowane w kolejności przybycia, a wiadomości są zablokowane i przekazywane w miarę ich dostępności, aby korzystać z wszelkich zaległych środków.
Blokada komunikatu jest zwalniana, gdy transfer zostanie rozstrzygnięty w jednym z stanów terminalu zaakceptowanych, odrzuconych lub zwolnionych. Komunikat zostanie usunięty z usługi Service Bus po zaakceptowaniu stanu terminalu. Pozostaje w usłudze Service Bus i jest dostarczany do następnego odbiornika, gdy transfer dociera do dowolnego z innych stanów. Usługa Service Bus automatycznie przenosi komunikat do kolejki zakleszczenia jednostki, gdy osiągnie maksymalną dozwoloną liczbę dostaw dla jednostki z powodu powtarzających się odrzuceń lub wydań.
Mimo że interfejsy API usługi Service Bus nie uwidaczniają obecnie takiej opcji bezpośrednio, klient protokołu AMQP niższego poziomu może użyć modelu połączenia kredytowego, aby przekształcić interakcję "pull-style" wydawania jednej jednostki środków dla każdego żądania odbioru do modelu "push-style", wydając dużą liczbę środków linków, a następnie odbierać komunikaty, gdy staną się dostępne bez dalszej interakcji. Wypychanie jest obsługiwane za pośrednictwem ustawień właściwości ServiceBusProcessor.PrefetchCount lub ServiceBusReceiver.PrefetchCount . Gdy są one inne niż zero, klient AMQP używa go jako środków linku.
W tym kontekście ważne jest, aby zrozumieć, że zegar wygaśnięcia blokady komunikatu wewnątrz jednostki rozpoczyna się, gdy komunikat jest pobierany z jednostki, a nie wtedy, gdy komunikat jest umieszczany w przewodzie. Za każdym razem, gdy klient wskazuje gotowość do odbierania komunikatów poprzez wydawanie środków na łącze, oczekuje się, że będzie aktywnie ściągać komunikaty w całej sieci i być gotowy do ich obsługi. W przeciwnym razie blokada komunikatu mogła wygasła, zanim wiadomość zostanie nawet dostarczona. Użycie sterowania przepływem połączenia kredytowego powinno bezpośrednio odzwierciedlać natychmiastową gotowość do obsługi dostępnych komunikatów wysyłanych do odbiorcy.
Podsumowując, w poniższych sekcjach przedstawiono schematowy przegląd przepływu wydajności podczas różnych interakcji interfejsu API. W każdej sekcji opisano inną operację logiczną. Niektóre z tych interakcji mogą być "leniwe", co oznacza, że mogą być wykonywane tylko w razie potrzeby. Utworzenie nadawcy komunikatów może nie spowodować interakcji sieciowej do momentu wysłania lub wysłania pierwszego komunikatu.
Strzałki w poniższej tabeli pokazują kierunek przepływu wydajności.
Tworzenie odbiornika komunikatów
| Klient | Service Bus |
|---|---|
--> attach(<br/>name={link name},<br/>handle={numeric handle},<br/>role=**receiver**,<br/>source={entity name},<br/>target={client link ID}<br/>) |
Klient dołącza do jednostki jako odbiornik |
| Usługa Service Bus odpowiada dołączając jego koniec linku | <-- attach(<br/>name={link name},<br/>handle={numeric handle},<br/>role=**sender**,<br/>source={entity name},<br/>target={client link ID}<br/>) |
Tworzenie nadawcy wiadomości
| Klient | Service Bus |
|---|---|
--> attach(<br/>name={link name},<br/>handle={numeric handle},<br/>role=**sender**,<br/>source={client link ID},<br/>target={entity name}<br/>) |
Brak akcji |
| Brak akcji | <-- attach(<br/>name={link name},<br/>handle={numeric handle},<br/>role=**receiver**,<br/>source={client link ID},<br/>target={entity name}<br/>) |
Tworzenie nadawcy komunikatów (błąd)
| Klient | Service Bus |
|---|---|
--> attach(<br/>name={link name},<br/>handle={numeric handle},<br/>role=**sender**,<br/>source={client link ID},<br/>target={entity name}<br/>) |
Brak akcji |
| Brak akcji | <-- attach(<br/>name={link name},<br/>handle={numeric handle},<br/>role=**receiver**,<br/>source=null,<br/>target=null<br/>)<br/><br/><-- detach(<br/>handle={numeric handle},<br/>closed=**true**,<br/>error={error info}<br/>) |
Zamknij odbiorcę/nadawcę komunikatów
| Klient | Service Bus |
|---|---|
--> detach(<br/>handle={numeric handle},<br/>closed=**true**<br/>) |
Brak akcji |
| Brak akcji | <-- detach(<br/>handle={numeric handle},<br/>closed=**true**<br/>) |
Wyślij (powodzenie)
| Klient | Service Bus |
|---|---|
--> transfer(<br/>delivery-id={numeric handle},<br/>delivery-tag={binary handle},<br/>settled=**false**,,more=**false**,<br/>state=**null**,<br/>resume=**false**<br/>) |
Brak akcji |
| Brak akcji | <-- disposition(<br/>role=receiver,<br/>first={delivery ID},<br/>last={delivery ID},<br/>settled=**true**,<br/>state=**accepted**<br/>) |
Wyślij (błąd)
| Klient | Service Bus |
|---|---|
--> transfer(<br/>delivery-id={numeric handle},<br/>delivery-tag={binary handle},<br/>settled=**false**,,more=**false**,<br/>state=**null**,<br/>resume=**false**<br/>) |
Brak akcji |
| Brak akcji | <-- disposition(<br/>role=receiver,<br/>first={delivery ID},<br/>last={delivery ID},<br/>settled=**true**,<br/>state=**rejected**(<br/>error={error info}<br/>)<br/>) |
Pobierz
| Klient | Service Bus |
|---|---|
--> flow(<br/>link-credit=1<br/>) |
Brak akcji |
| Brak akcji | < transfer(<br/>delivery-id={numeric handle},<br/>delivery-tag={binary handle},<br/>settled=**false**,<br/>more=**false**,<br/>state=**null**,<br/>resume=**false**<br/>) |
--> disposition(<br/>role=**receiver**,<br/>first={delivery ID},<br/>last={delivery ID},<br/>settled=**true**,<br/>state=**accepted**<br/>) |
Brak akcji |
Odbieranie wielu komunikatów
| Klient | Service Bus |
|---|---|
--> flow(<br/>link-credit=3<br/>) |
Brak akcji |
| Brak akcji | < transfer(<br/>delivery-id={numeric handle},<br/>delivery-tag={binary handle},<br/>settled=**false**,<br/>more=**false**,<br/>state=**null**,<br/>resume=**false**<br/>) |
| Brak akcji | < transfer(<br/>delivery-id={numeric handle+1},<br/>delivery-tag={binary handle},<br/>settled=**false**,<br/>more=**false**,<br/>state=**null**,<br/>resume=**false**<br/>) |
| Brak akcji | < transfer(<br/>delivery-id={numeric handle+2},<br/>delivery-tag={binary handle},<br/>settled=**false**,<br/>more=**false**,<br/>state=**null**,<br/>resume=**false**<br/>) |
--> disposition(<br/>role=receiver,<br/>first={delivery ID},<br/>last={delivery ID+2},<br/>settled=**true**,<br/>state=**accepted**<br/>) |
Brak akcji |
Wiadomości
W poniższych sekcjach wyjaśniono, które właściwości ze standardowych sekcji komunikatów protokołu AMQP są używane przez usługę Service Bus i jak są mapowane na zestaw interfejsu API usługi Service Bus.
Każda właściwość, którą aplikacja musi zdefiniować, powinna być mapowana na mapę protokołu AMQP application-properties .
Nagłówek
| Nazwa pola | Użycie | Nazwa interfejsu API |
|---|---|---|
| trwały | - | - |
| priority | - | - |
| czas wygaśnięcia | Czas wygaśnięcia tej wiadomości | TimeToLive |
| first-acquirer | - | - |
| liczba dostaw | - | DeliveryCount |
Właściwości
| Nazwa pola | Użycie | Nazwa interfejsu API |
|---|---|---|
message-id |
Zdefiniowany przez aplikację identyfikator wolnego formularza dla tego komunikatu. Służy do wykrywania duplikatów. | Identyfikator komunikatu |
user-id |
Identyfikator użytkownika zdefiniowany przez aplikację, który nie jest interpretowany przez usługę Service Bus. | Dostęp za pośrednictwem interfejsu API usługi Service Bus jest niedostępny. |
to |
Identyfikator docelowy zdefiniowany przez aplikację, który nie jest interpretowany przez usługę Service Bus. | Do |
subject |
Identyfikator przeznaczenia komunikatu zdefiniowanego przez aplikację, który nie jest interpretowany przez usługę Service Bus. | Temat |
reply-to |
Wskaźnik ścieżki odpowiedzi zdefiniowanej przez aplikację, który nie jest interpretowany przez usługę Service Bus. | OdpowiedzDo |
correlation-id |
Identyfikator korelacji zdefiniowanej przez aplikację, który nie jest interpretowany przez usługę Service Bus. | Identyfikator korelacji |
content-type |
Wskaźnik typu zawartości zdefiniowanej przez aplikację dla treści, a nie interpretowany przez usługę Service Bus. | Typ zawartości |
content-encoding |
Wskaźnik kodowania zawartości zdefiniowanej przez aplikację dla treści, a nie interpretowany przez usługę Service Bus. | Dostęp za pośrednictwem interfejsu API usługi Service Bus jest niedostępny. |
absolute-expiry-time |
Deklaruje, w którym bezwzględne natychmiastowe wygaśnięcie komunikatu. Ignorowane w danych wejściowych (zaobserwowano czas wygaśnięcia nagłówka), autorytatywne dla danych wyjściowych. | Dostęp za pośrednictwem interfejsu API usługi Service Bus jest niedostępny. |
creation-time |
Deklaruje, kiedy wiadomość została utworzona. Nieużytowane przez usługę Service Bus | Dostęp za pośrednictwem interfejsu API usługi Service Bus jest niedostępny. |
group-id |
Identyfikator zdefiniowany przez aplikację dla powiązanego zestawu komunikatów. Służy do sesji usługi Service Bus. | Identyfikator sesji |
group-sequence |
Licznik identyfikujący względny numer sekwencji komunikatu wewnątrz sesji. Ignorowane przez usługę Service Bus. | Dostęp za pośrednictwem interfejsu API usługi Service Bus jest niedostępny. |
reply-to-group-id |
- | ReplyToSessionId |
Adnotacje komunikatów
Istnieje kilka innych właściwości komunikatów usługi Service Bus, które nie są częścią właściwości komunikatu protokołu AMQP i są przekazywane wraz z MessageAnnotations komunikatem.
| Klucz mapy adnotacji | Użycie | Nazwa interfejsu API |
|---|---|---|
x-opt-scheduled-enqueue-time |
Deklaruje, kiedy komunikat powinien pojawić się w jednostce | ScheduledEnqueueTime |
x-opt-partition-key |
Klucz zdefiniowany przez aplikację, który określa partycję, w której powinien znajdować się komunikat. | PartitionKey |
x-opt-via-partition-key |
Wartość klucza partycji zdefiniowana przez aplikację, gdy transakcja ma być używana do wysyłania komunikatów za pośrednictwem kolejki transferu. | TransactionPartitionKey |
x-opt-enqueued-time |
Zdefiniowana przez usługę godzina UTC reprezentująca rzeczywisty czas kolejkowania komunikatu. Ignorowane na danych wejściowych. | EnqueuedTime |
x-opt-sequence-number |
Zdefiniowana przez usługę unikatowa liczba przypisana do komunikatu. | Numer sekwencji |
x-opt-offset |
Zdefiniowany przez usługę numer sekwencji w kolejce komunikatu. | EnqueuedSequenceNumber |
x-opt-locked-until |
Zdefiniowane przez usługę. Data i godzina, do której komunikat zostanie zablokowany w kolejce/subskrypcji. | LockedUntil |
x-opt-deadletter-source |
Zdefiniowane przez usługę. Jeśli komunikat zostanie odebrany z kolejki utraconych komunikatów, reprezentuje źródło oryginalnego komunikatu. | DeadLetterSource |
Możliwość transakcji
Transakcja grupuje razem co najmniej dwie operacje w zakresie wykonania. Z natury taka transakcja musi zapewnić, że wszystkie operacje należące do danej grupy operacji kończą się powodzeniem lub niepowodzeniem wspólnie.
Operacje są grupowane według identyfikatora txn-id.
W przypadku interakcji transakcyjnej klient działa jako transaction controller element , który kontroluje operacje, które powinny być zgrupowane razem. Usługa Service Bus działa jako element transactional resource i wykonuje pracę zgodnie z żądaniem .transaction controller
Klient i usługa komunikują się za pośrednictwem control link elementu , który jest ustanawiany przez klienta. Komunikaty declare i discharge są wysyłane przez kontroler za pośrednictwem linku kontrolnego w celu przydzielenia i ukończenia transakcji odpowiednio (nie reprezentują demarcation pracy transakcyjnej). Rzeczywiste wysyłanie/odbieranie nie jest wykonywane na tym linku. Każda żądana operacja transakcyjna jest jawnie identyfikowana z żądanym txn-id elementem i dlatego może wystąpić na dowolnym linku w połączeniu. Jeśli link kontrolny zostanie zamknięty, gdy istnieją niepodładowane transakcje, które zostały utworzone, wszystkie takie transakcje zostaną natychmiast wycofane, a próby wykonania dalszej pracy transakcyjnej na nich doprowadzi do niepowodzenia. Komunikaty w linku sterującym nie mogą być wstępnie rozliczone.
Każde połączenie musi zainicjować własne łącze sterujące, aby móc rozpocząć i zakończyć transakcje. Usługa definiuje specjalny element docelowy, który działa jako coordinator. Klient/kontroler ustanawia link kontrolny do tego obiektu docelowego. Link kontrolny znajduje się poza granicą jednostki, czyli tego samego linku sterującego można użyć do inicjowania i zwalniania transakcji dla wielu jednostek.
Uruchamianie transakcji
Aby rozpocząć pracę transakcyjną, kontroler musi uzyskać element txn-id od koordynatora. Robi to, wysyłając declare komunikat typu. Jeśli deklaracja zakończy się powodzeniem, koordynator odpowie wynikiem dyspozycji, który niesie przypisany txn-idelement .
| Klient (kontroler) | Kierunek | Service Bus (koordynator) |
|---|---|---|
attach(<br/>name={link name},<br/>... ,<br/>role=**sender**,<br/>target=**Coordinator**<br/>) |
------> | |
| <------ | attach(<br/>name={link name},<br/>... ,<br/>target=Coordinator()<br/>) |
|
transfer(<br/>delivery-id=0, ...)<br/>{ AmqpValue (**Declare()**)} |
------> | |
| <------ | disposition( <br/> first=0, last=0, <br/>state=**Declared**(<br/>**txn-id**={transaction ID}<br/>)) |
Rozładowanie transakcji
Kontroler kończy pracę transakcyjną discharge , wysyłając komunikat do koordynatora. Kontroler wskazuje, że chce zatwierdzić lub wycofać pracę transakcyjną, ustawiając flagę fail w treści zrzutu. Jeśli koordynator nie może ukończyć zrzutu, komunikat zostanie odrzucony z tym wynikiem niosącym .transaction-error
Uwaga: fail=true odnosi się do wycofywania transakcji, a fail=false odnosi się do zatwierdzenia.
| Klient (kontroler) | Kierunek | Service Bus (koordynator) |
|---|---|---|
transfer(<br/>delivery-id=0, ...)<br/>{ AmqpValue (Declare())} |
------> | |
| <------ | disposition( <br/> first=0, last=0, <br/>state=Declared(<br/>txn-id={transaction ID}<br/>)) |
|
| . . . Praca transakcyjna na innych linkach . . . |
||
transfer(<br/>delivery-id=57, ...)<br/>{ AmqpValue (<br/>**Discharge(txn-id=0,<br/>fail=false)**)} |
------> | |
| <------ | disposition( <br/> first=57, last=57, <br/>state=**Accepted()**) |
Wysyłanie komunikatu w transakcji
Wszystkie prace transakcyjne są wykonywane ze stanem transactional-state dostawy transakcyjnej, który niesie ze sobą txn-id. Podczas wysyłania komunikatów stan transakcyjny jest przenoszony przez ramkę transferu komunikatu.
| Klient (kontroler) | Kierunek | Service Bus (koordynator) |
|---|---|---|
transfer(<br/>delivery-id=0, ...)<br/>{ AmqpValue (Declare())} |
------> | |
| <------ | disposition( <br/> first=0, last=0, <br/>state=Declared(<br/>txn-id={transaction ID}<br/>)) |
|
transfer(<br/>handle=1,<br/>delivery-id=1, <br/>**state=<br/>TransactionalState(<br/>txn-id=0)**)<br/>{ payload } |
------> | |
| <------ | disposition( <br/> first=1, last=1, <br/>state=**TransactionalState(<br/>txn-id=0,<br/>outcome=Accepted()**)) |
Usuwanie komunikatu w transakcji
Dyspozycja komunikatów obejmuje operacje, takie jak CompleteDeadLetter / DeferAbandon / / . Aby wykonać te operacje w ramach transakcji, przekaż element transactional-state z dyspozycją.
| Klient (kontroler) | Kierunek | Service Bus (koordynator) |
|---|---|---|
transfer(<br/>delivery-id=0, ...)<br/>{ AmqpValue (Declare())} |
------> | |
| <------ | disposition( <br/> first=0, last=0, <br/>state=Declared(<br/>txn-id={transaction ID}<br/>)) |
|
| <------ | transfer(<br/>handle=2,<br/>delivery-id=11, <br/>state=null)<br/>{ payload } |
|
disposition( <br/> first=11, last=11, <br/>state=**TransactionalState(<br/>txn-id=0,<br/>outcome=Accepted()**)) |
------> |
Zaawansowane możliwości usługi Service Bus
W tej sekcji opisano zaawansowane możliwości usługi Azure Service Bus oparte na projektach rozszerzeń protokołu AMQP, które są obecnie opracowywane w Komitecie Technicznym OASIS dla protokołu AMQP. Usługa Service Bus implementuje najnowsze wersje tych wersji roboczych i przyjmuje zmiany wprowadzone w miarę osiągnięcia standardowego stanu tych wersji roboczych.
Uwaga
Zaawansowane operacje obsługi komunikatów usługi Service Bus są obsługiwane za pośrednictwem wzorca żądania/odpowiedzi. Szczegółowe informacje o tych operacjach opisano w artykule AMQP 1.0 w usłudze Service Bus: operacje oparte na żądaniach.
Zarządzanie usługą AMQP
Specyfikacja zarządzania amQP jest pierwszym z wersji roboczych rozszerzeń omówionych w tym artykule. Ta specyfikacja definiuje zestaw protokołów warstwowych na podstawie protokołu AMQP, który umożliwia interakcje zarządzania z infrastrukturą obsługi komunikatów za pośrednictwem protokołu AMQP. Specyfikacja definiuje ogólne operacje, takie jak tworzenie, odczytywanie, aktualizowanie i usuwanie jednostek wewnątrz infrastruktury obsługi komunikatów oraz zestaw operacji zapytań.
Wszystkie te gesty wymagają interakcji żądania/odpowiedzi między klientem a infrastrukturą obsługi komunikatów, a zatem specyfikacja definiuje sposób modelowania tego wzorca interakcji na podstawie protokołu AMQP: klient łączy się z infrastrukturą obsługi komunikatów, inicjuje sesję, a następnie tworzy parę łączy. Na jednym linku klient działa jako nadawca, a drugi działa jako odbiorca, tworząc w ten sposób parę łączy, które mogą działać jako kanał dwukierunkowy.
| Operacja logiczna | Klient | Service Bus |
|---|---|---|
| Tworzenie ścieżki odpowiedzi żądania | --> attach(<br/>name={*link name*},<br/>handle={*numeric handle*},<br/>role=**sender**,<br/>source=**null**,<br/>target=”myentity/$management”<br/>) |
Brak akcji |
| Tworzenie ścieżki odpowiedzi żądania | Brak akcji | \<-- attach(<br/>name={*link name*},<br/>handle={*numeric handle*},<br/>role=**receiver**,<br/>source=null,<br/>target=”myentity”<br/>) |
| Tworzenie ścieżki odpowiedzi żądania | --> attach(<br/>name={*link name*},<br/>handle={*numeric handle*},<br/>role=**receiver**,<br/>source=”myentity/$management”,<br/>target=”myclient$id”<br/>) |
|
| Tworzenie ścieżki odpowiedzi żądania | Brak akcji | \<-- attach(<br/>name={*link name*},<br/>handle={*numeric handle*},<br/>role=**sender**,<br/>source=”myentity”,<br/>target=”myclient$id”<br/>) |
Mając tę parę linków, implementacja żądania/odpowiedzi jest prosta: żądanie jest komunikatem wysyłanym do jednostki wewnątrz infrastruktury obsługi komunikatów, która rozumie ten wzorzec. W tym żądaniu-komunikat pole reply-to w sekcji properties jest ustawione na identyfikator docelowy linku, na który ma być dostarczana odpowiedź. Jednostka obsługująca przetwarza żądanie, a następnie dostarcza odpowiedź za pośrednictwem linku, którego identyfikator docelowy odpowiada wskazanemu identyfikatorowi odpowiedzi.
Wzorzec oczywiście wymaga, aby kontener klienta i identyfikator wygenerowany przez klienta dla miejsca docelowego odpowiedzi był unikatowy dla wszystkich klientów i ze względów bezpieczeństwa również trudne do przewidzenia.
Wymiana komunikatów używana dla protokołu zarządzania i wszystkich innych protokołów, które używają tego samego wzorca, mają miejsce na poziomie aplikacji; nie definiują nowych gestów na poziomie protokołu AMQP. Jest to zamierzone, dzięki czemu aplikacje mogą natychmiast korzystać z tych rozszerzeń ze zgodnymi stosami protokołu AMQP 1.0.
Usługa Service Bus nie implementuje obecnie żadnych podstawowych funkcji specyfikacji zarządzania, ale wzorzec żądania/odpowiedzi zdefiniowany przez specyfikację zarządzania jest podstawą funkcji zabezpieczeń opartych na oświadczeniach i prawie wszystkich zaawansowanych funkcji omówionych w poniższych sekcjach:
Autoryzacja oparta na oświadczeniach
Wersja robocza specyfikacji AMQP Claims-Based-Authorization (CBS) opiera się na wzorzec żądania/odpowiedzi specyfikacji zarządzania i opisuje uogólniony model używania federacyjnych tokenów zabezpieczeń za pomocą protokołu AMQP.
Domyślny model zabezpieczeń protokołu AMQP omówiony we wprowadzeniu jest oparty na protokole SASL i integruje się z uzgadnianiem połączenia AMQP. Użycie sygnatury dostępu współdzielonego ma przewagę nad tym, że zapewnia rozszerzalny model, dla którego zdefiniowano zestaw mechanizmów, z którego każdy protokół, który formalnie opiera się na protokole SASL, może przynieść korzyści. Wśród tych mechanizmów są "PLAIN" do transferu nazw użytkowników i haseł, "EXTERNAL" w celu powiązania z zabezpieczeniami na poziomie protokołu TLS, "ANONYMOUS" w celu wyrażenia braku jawnego uwierzytelniania/autoryzacji oraz szerokiej gamy dodatkowych mechanizmów, które umożliwiają przekazywanie poświadczeń uwierzytelniania i/lub autoryzacji lub tokenów.
Integracja sygnatury dostępu współdzielonego protokołu AMQP ma dwie wady:
- Wszystkie poświadczenia i tokeny są ograniczone do połączenia. Infrastruktura obsługi komunikatów może chcieć zapewnić zróżnicowaną kontrolę dostępu dla poszczególnych jednostek; na przykład umożliwienie elementu nośnego tokenu do wysłania do kolejki A, ale nie do kolejki B. Przy użyciu kontekstu autoryzacji zakotwiczonego w połączeniu nie można użyć jednego połączenia, ale używać różnych tokenów dostępu dla kolejki A i kolejki B.
- Tokeny dostępu są zwykle ważne tylko przez ograniczony czas. Ta ważność wymaga od użytkownika okresowego ponownego pobierania tokenów i umożliwia wystawcy tokenów odmowę wystawienia nowego tokenu, jeśli uprawnienia dostępu użytkownika uległy zmianie. Połączenia protokołu AMQP mogą trwać przez długi czas. Model SASL zapewnia tylko możliwość ustawienia tokenu w czasie połączenia, co oznacza, że infrastruktura obsługi komunikatów musi odłączyć klienta po wygaśnięciu tokenu lub musi zaakceptować ryzyko zezwolenia na ciągłą komunikację z klientem, który ma prawa dostępu, mógł zostać odwołany w międzyczasie.
Specyfikacja CBS protokołu AMQP zaimplementowana przez usługę Service Bus umożliwia eleganckie obejście obu tych problemów: umożliwia klientowi skojarzenie tokenów dostępu z każdym węzłem oraz zaktualizowanie tych tokenów przed ich wygaśnięciem bez przerywania przepływu komunikatów.
CbS definiuje wirtualny węzeł zarządzania o nazwie $cbs, który ma być udostępniany przez infrastrukturę obsługi komunikatów. Węzeł zarządzania akceptuje tokeny w imieniu innych węzłów w infrastrukturze obsługi komunikatów.
Gest protokołu jest wymianą żądań/odpowiedzi zgodnie ze specyfikacją zarządzania. Oznacza to, że klient ustanawia parę łączy z węzłem $cbs , a następnie przekazuje żądanie w linku wychodzącym, a następnie czeka na odpowiedź na link przychodzący.
Komunikat żądania ma następujące właściwości aplikacji:
| Klucz | Opcjonalnie | Typ wartości: | Zawartość wartości |
|---|---|---|---|
operation |
Nie. | string | put-token |
type |
Nie. | string | Typ umieszczanego tokenu. |
name |
Nie. | string | "Odbiorcy", do których stosuje się token. |
expiration |
Tak | timestamp | Czas wygaśnięcia tokenu. |
Właściwość name identyfikuje jednostkę, z którą jest skojarzony token. W usłudze Service Bus jest to ścieżka do kolejki lub tematu/subskrypcji. Właściwość type identyfikuje typ tokenu:
| Typ tokenu | Opis tokenu | Typ treści | Uwagi |
|---|---|---|---|
jwt |
Token internetowy JSON (JWT) | Wartość protokołu AMQP (ciąg) | |
servicebus.windows.net:sastoken |
Token sygnatury dostępu współdzielonego usługi Service Bus | Wartość protokołu AMQP (ciąg) | - |
Tokeny dają prawa. Usługa Service Bus wie o trzech podstawowych prawach: opcja "Wyślij" umożliwia wysyłanie, "Nasłuchiwanie" umożliwia odbieranie i "Zarządzanie" umożliwia manipulowanie jednostkami. Tokeny SAS usługi Service Bus odnoszą się do reguł skonfigurowanych w przestrzeni nazw lub jednostce, a te reguły są konfigurowane z prawami. Podpisywanie tokenu przy użyciu klucza skojarzonego z tą regułą powoduje, że token wyraża odpowiednie prawa. Token skojarzony z jednostką przy użyciu tokenu put umożliwia połączonemu klientowi interakcję z jednostką zgodnie z prawami tokenu. Link, w którym klient przejmuje rolę nadawcy , wymaga prawa "Wyślij", a przejęcie roli odbiorcy wymaga prawa "Nasłuchiwanie".
Komunikat odpowiedzi ma następujące wartości właściwości aplikacji
| Klucz | Opcjonalnie | Typ wartości: | Zawartość wartości |
|---|---|---|---|
status-code |
Nie. | int | Kod odpowiedzi HTTP [RFC2616]. |
status-description |
Tak | string | Opis stanu. |
Klient może wielokrotnie wywoływać token put-token i dla dowolnej jednostki w infrastrukturze obsługi komunikatów. Tokeny są ograniczone do bieżącego klienta i zakotwiczone w bieżącym połączeniu, co oznacza, że serwer odrzuca wszystkie zachowane tokeny, gdy połączenie spadnie.
Bieżąca implementacja usługi Service Bus zezwala tylko na cbs w połączeniu z metodą SASL "ANONYMOUS". Połączenie SSL/TLS musi zawsze istnieć przed uzgadnianiem SASL.
Dlatego mechanizm ANONYMOUS musi być obsługiwany przez wybranego klienta protokołu AMQP 1.0. Dostęp anonimowy oznacza, że uzgadnianie początkowego połączenia, w tym tworzenie sesji początkowej odbywa się bez znajomości, kto tworzy połączenie.
Po nawiązaniu połączenia i sesji dołączanie linków do węzła $cbs i wysyłanie żądania put-token są jedynymi dozwolonymi operacjami. Prawidłowy token należy ustawić pomyślnie przy użyciu żądania put-token dla niektórych węzłów jednostki w ciągu 20 sekund po nawiązaniu połączenia, w przeciwnym razie połączenie zostanie jednostronnie porzucone przez usługę Service Bus.
Klient jest następnie odpowiedzialny za śledzenie wygaśnięcia tokenu. Po wygaśnięciu tokenu usługa Service Bus natychmiast pominie wszystkie łącza w połączeniu z odpowiednią jednostką. Aby zapobiec wystąpieniu problemu, klient może zastąpić token węzła nowym węzłem w dowolnym momencie za pomocą wirtualnego węzła zarządzania $cbs za pomocą tego samego gestu put-token i bez przechodzenia w sposób ruchu ładunku, który przepływa na różnych linkach.
Funkcja wysyłania za pośrednictwem
Nadawca wysyłania/transferu to funkcja umożliwiająca usłudze Service Bus przekazywanie danego komunikatu do jednostki docelowej za pośrednictwem innej jednostki. Ta funkcja służy do wykonywania operacji między jednostkami w ramach jednej transakcji.
Dzięki tej funkcji utworzysz nadawcę i ustanowisz link do .via-entity Podczas ustanawiania linku przekazywane są dodatkowe informacje w celu ustalenia prawdziwego miejsca docelowego komunikatów/transferów na tym linku. Po pomyślnym zakończeniu dołączania wszystkie komunikaty wysyłane do tego linku są automatycznie przekazywane do jednostki docelowej za pośrednictwem jednostki.
Uwaga: Przed nawiązaniem tego linku należy przeprowadzić uwierzytelnianie zarówno dla jednostki za pośrednictwem, jak i dla jednostki docelowej.
| Klient | Kierunek | Service Bus |
|---|---|---|
attach(<br/>name={link name},<br/>role=sender,<br/>source={client link ID},<br/>target=**{via-entity}**,<br/>**properties=map [(<br/>com.microsoft:transfer-destination-address=<br/>{destination-entity} )]** ) |
------> | |
| <------ | attach(<br/>name={link name},<br/>role=receiver,<br/>source={client link ID},<br/>target={via-entity},<br/>properties=map [(<br/>com.microsoft:transfer-destination-address=<br/>{destination-entity} )] ) |
Powiązana zawartość
Aby dowiedzieć się więcej na temat protokołu AMQP, zobacz Service Bus AMQP overview (Omówienie protokołu AMQP w usłudze Service Bus).