Punkty końcowe usługi i adresowanie kolejki

W tym temacie omówiono sposób, w jaki klienci adresują usługi odczytujące z kolejek i sposób mapowania punktów końcowych usługi na kolejki. Przypominamy, że na poniższej ilustracji przedstawiono klasyczne wdrożenie aplikacji w kolejce programu Windows Communication Foundation (WCF).

Aby klient wysyłał komunikat do usługi, klient wysyła komunikat do kolejki docelowej. Aby usługa odczytywała komunikaty z kolejki, ustawia adres nasłuchiwania na kolejkę docelową. Adresowanie w programie WCF jest oparte na identyfikatorze URI (Uniform Resource Identifier), podczas gdy nazwy kolejek kolejkowania komunikatów (MSMQ) nie są oparte na identyfikatorze URI. Dlatego ważne jest, aby zrozumieć sposób rozwiązywania problemów z kolejkami utworzonymi w usłudze MSMQ przy użyciu programu WCF.

Adresowanie MSMQ

Usługa MSMQ używa ścieżek i nazw formatów do identyfikowania kolejki. Ścieżki określają nazwę hosta i .QueueName Opcjonalnie może istnieć między Private$ nazwą hosta a QueueName wartością wskazującą kolejkę prywatną, która nie jest opublikowana w usłudze katalogowej Active Directory.

Nazwy ścieżek są mapowane na "FormatNames", aby określić dodatkowe aspekty adresu, w tym protokół transferu routingu i menedżera kolejek. Usługa Queue Manager obsługuje dwa protokoły transferu: natywny protokół MSMQ i protokół SOAP Reliable Messaging Protocol (SRMP).

Aby uzyskać więcej informacji na temat nazw ścieżek i formatów MSMQ, zobacz About Message Queuing (Informacje o kolejce komunikatów).

NetMsmqBinding i adresowanie usług

Podczas adresowania komunikatu do usługi schemat w identyfikatorze URI jest wybierany na podstawie transportu używanego do komunikacji. Każdy transport w programie WCF ma unikatowy schemat. System ten musi odzwierciedlać charakter transportu wykorzystywanego do komunikacji. Na przykład net.tcp, net.pipe, HTTP itd.

Transport w kolejce MSMQ w programie WCF uwidacznia schemat net.msmq. Każdy komunikat adresowany przy użyciu schematu net.msmq jest wysyłany przy użyciu NetMsmqBinding kanału transportu w kolejce MSMQ.

Adresowanie kolejki w programie WCF jest oparte na następującym wzorcu:

net.msmq: // <nazwa-hosta> / [private/] <nazwa-kolejki>

gdzie:

• <host-name to nazwa> maszyny, która hostuje kolejkę docelową.

• Opcja [private] jest opcjonalna. Jest on używany podczas adresowania kolejki docelowej, która jest kolejką prywatną. Aby rozwiązać problem z kolejką publiczną, nie można określić prywatności. Należy pamiętać, że w przeciwieństwie do ścieżek MSMQ w formularzu identyfikatora URI programu WCF nie ma żadnego ciągu "$".

• <queue-name> to nazwa kolejki. Nazwa kolejki może również odwoływać się do pod kolejki. W związku z tym nazwa-kolejki <> = <name-of-queue>[;sub-queue-name].

Przykład1: Aby rozwiązać problem z prywatnymi kolejkami PurchaseOrders hostowane na komputerze abc atadatum.com, identyfikator URI będzie miał wartość net.msmq://abc.adatum.com/private/PurchaseOrders.

Przykład2: Aby adresować konta kolejki publicznejPłatne hostowane na komputerze def atadatum.com, identyfikator URI będzie net.msmq://def.adatum.com/AccountsPayable.

Adres kolejki jest używany jako identyfikator URI nasłuchiwania przez odbiornik do odczytywania komunikatów. Innymi słowy, adres kolejki jest odpowiednikiem portu nasłuchiwania gniazda TCP.

Punkt końcowy odczytujący z kolejki musi określić adres kolejki przy użyciu tego samego schematu określonego wcześniej podczas otwierania obiektu ServiceHost. Aby zapoznać się z przykładami, zobacz Net MSMQ Binding (Powiązanie net MSMQ).

Wiele kontraktów w kolejce

Komunikaty w kolejce mogą implementować różne kontrakty. W takim przypadku ważne jest, aby jeden z następujących elementów był spełniony, aby pomyślnie odczytać i przetworzyć wszystkie komunikaty:

• Określ punkt końcowy usługi, która implementuje wszystkie kontrakty. Jest to zalecane podejście.

• Określ wiele punktów końcowych z różnymi kontraktami, ale upewnij się, że wszystkie punkty końcowe używają tego samego NetMsmqBinding obiektu. Logika wysyłania w usłudze ServiceModel używa pompy komunikatów, która odczytuje komunikaty z kanału transportu do wysłania, co ostatecznie powoduje anulowanie multipleksów komunikatów na podstawie kontraktu z różnymi punktami końcowymi. Pompa komunikatów jest tworzona dla pary identyfikatora URI/powiązania nasłuchiwania. Adres kolejki jest używany jako identyfikator URI nasłuchiwania przez odbiornik w kolejce. Posiadanie wszystkich punktów końcowych używa tego samego obiektu powiązania gwarantuje, że jedna pompa komunikatów jest używana do odczytywania komunikatu i de-multipleksu do odpowiednich punktów końcowych na podstawie kontraktu.

Obsługa komunikatów SRMP

Jak wspomniano wcześniej, można użyć protokołu SRMP do transferów kolejek do kolejki. Jest to często używane, gdy transport HTTP przesyła komunikaty między kolejką transmisji a kolejką docelową.

Aby użyć protokołu transferu SRMP, adresy komunikatów przy użyciu schematu identyfikatora URI net.msmq, jak wspomniano wcześniej, i określ wybór srMP lub Zabezpieczone SRMP we QueueTransferProtocol właściwości NetMsmqBinding.

Określanie QueueTransferProtocol właściwości jest funkcją tylko do wysyłania. Jest to wskazanie przez klienta, jakiego rodzaju protokół transferu kolejek ma być używany.

Azure Active Directory

Usługa MSMQ jest dostarczana z obsługą integracji z usługą Active Directory. Po zainstalowaniu usługi MSMQ z integracją z usługą Active Directory maszyna musi być częścią domeny systemu Windows. Usługa Active Directory służy do publikowania kolejek na potrzeby odnajdywania; takie kolejki są nazywane kolejkami publicznymi. Podczas rozwiązywania problemów z kolejką kolejkę można rozwiązać przy użyciu usługi Active Directory. Jest to podobne do sposobu, w jaki system nazw domen (DNS) służy do rozpoznawania adresu IP nazwy sieciowej. Właściwość UseActiveDirectory w pliku NetMsmqBinding jest wartością logiczną wskazującą, czy w kolejce kanał musi użyć usługi Active Directory, aby rozpoznać identyfikator URI kolejki. Domyślnie jest ustawiona wartość false. UseActiveDirectory Jeśli właściwość jest ustawiona na true, kanał w kolejce używa usługi Active Directory do konwersji identyfikatora URI net.msmq:// na nazwę formatu.

Właściwość UseActiveDirectory ma znaczenie tylko dla klienta wysyłającego komunikat, ponieważ służy do rozpoznawania adresu kolejki podczas wysyłania komunikatów.

Mapowanie identyfikatora URI net.msmq na nazwy formatów kolejkowania komunikatów

Kanał w kolejce obsługuje mapowanie nazwy identyfikatora URI net.msmq dostarczonego do kanału na nazwy formatów MSMQ. Poniższa tabela zawiera podsumowanie reguł używanych do mapowania między nimi.

Adres kolejki opartej na identyfikatorze URI programu WCF	Używanie właściwości usługi Active Directory	Właściwość Protokołu transferu kolejek	Wynikowe nazwy formatów MSMQ
Net.msmq://<machine-name>/private/abc	False (domyślnie)	Natywna (domyślna)	DIRECT=OS:machine-name\private$\abc
Net.msmq://<machine-name>/private/abc	Fałsz	SRMP	DIRECT=http://machine/msmq/private$/abc
Net.msmq://<machine-name>/private/abc	Prawda	Macierzyste	PUBLIC=some-guid (identyfikator GUID kolejki)

Odczytywanie komunikatów z kolejki utraconych wiadomości lub kolejki komunikatów zatrutych

Aby odczytać komunikaty z kolejki komunikatów trucizny, która jest pod kolejką kolejki docelowej, otwórz element ServiceHost z adresem kolejki podrzędnej.

Przykład: usługa, która odczytuje z kolejki komunikatów trucizny kolejki prywatnej PurchaseOrders z komputera lokalnego, adres net.msmq://localhost/private/PurchaseOrders; Trucizny.

Aby odczytać komunikaty z systemowej kolejki transakcyjnej utraconych komunikatów, identyfikator URI musi mieć postać: net.msmq://localhost/system$; DeadXact.

Aby odczytać komunikaty z nietransakcyjnej kolejki utraconych komunikatów systemu, identyfikator URI musi mieć postać: net.msmq://localhost/system$; DeadLetter.

W przypadku korzystania z niestandardowej kolejki utraconych komunikatów należy pamiętać, że kolejka utraconych komunikatów musi znajdować się na komputerze lokalnym. W związku z tym identyfikator URI kolejki utraconych komunikatów jest ograniczony do formularza:

net.msmq: //localhost/ [private/] <custom-dead-letter-queue-name>.

Usługa WCF sprawdza, czy wszystkie odbierane komunikaty zostały skierowane do określonej kolejki, na której nasłuchuje. Jeśli kolejka docelowa komunikatu nie jest zgodna z kolejką, w niej znajduje się, usługa nie przetwarza komunikatu. Jest to problem polegający na tym, że usługi nasłuchujące w kolejce utraconych komunikatów muszą rozwiązać problem, ponieważ wszelkie komunikaty w kolejce utraconych komunikatów miały być dostarczane gdzie indziej. Aby odczytać komunikaty z kolejki utraconych komunikatów lub z kolejki trucizny, ServiceBehavior należy użyć parametru z parametrem Any . Aby zapoznać się z przykładem, zobacz Kolejki utraconych listów.

MsmqIntegrationBinding i adresowanie usługi

Element MsmqIntegrationBinding jest używany do komunikacji z tradycyjnymi aplikacjami MSMQ. Aby ułatwić współdziałanie z istniejącą aplikacją MSMQ, program WCF obsługuje tylko adresowanie nazw formatów. W związku z tym komunikaty wysyłane przy użyciu tego powiązania muszą być zgodne ze schematem identyfikatora URI:

msmq.formatname:<MSMQ-format-name>>

Nazwa-format-MSMQ ma postać określoną przez MSMQ w temacie About Message Queuing (Informacje o kolejce komunikatów).

Należy pamiętać, że podczas odbierania komunikatów z kolejki przy użyciu polecenia MsmqIntegrationBindingmożna używać tylko nazw formatów bezpośrednich oraz nazw formatów publicznych i prywatnych (wymaga integracji z usługą Active Directory). Zaleca się jednak używanie bezpośrednich nazw formatów. Na przykład w systemie Windows Vista użycie dowolnej innej nazwy formatu powoduje błąd, ponieważ system próbuje otworzyć kolejkę podrzędną, którą można otworzyć tylko przy użyciu nazw formatów bezpośrednich.

W przypadku adresowania srMP przy użyciu polecenia MsmqIntegrationBindingnie ma potrzeby dodawania /msmq/ w nazwie bezpośredniego formatu, aby ułatwić wysyłanie usług Internet Information Services (IIS). Na przykład: w przypadku adresowania kolejki abc przy użyciu protokołu SRMP, zamiast DIRECT=http://adatum.com/msmq/private$/abc, należy użyć polecenia DIRECT=http://adatum.com/private$/abc.

Należy pamiętać, że nie można używać adresowania net.msmq:// z MsmqIntegrationBinding. Ponieważ MsmqIntegrationBinding obsługuje adresowanie nazw w formacie MSMQ w dowolnej formie, można użyć usługi WCF, która używa tego powiązania do korzystania z funkcji multiemisji i listy dystrybucyjnej w msMQ. Jednym z wyjątków jest określenie CustomDeadLetterQueue podczas korzystania z elementu MsmqIntegrationBinding. Musi mieć postać net.msmq://, podobną do tego, jak jest określona przy użyciu .NetMsmqBinding

Zobacz też

• Sieć Web hostująca aplikację zakolejkowaną