Uwaga
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
W tym temacie omówiono, jak klienci adresują usługi, które odczytują z kolejek, oraz jak punkty końcowe usług są mapowane 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 być Private$ między nazwą hosta a QueueName, aby wskazać kolejkę prywatną, która nie jest opublikowana w usłudze katalogowej Active Directory.
Nazwy ścieżek są mapowane do "FormatNames" w celu określenia dodatkowych aspektów adresu, w tym protokołów routingu i transferu 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 serwisów
Podczas adresowania komunikatu do usługi schemat w identyfikatorze URI jest wybierany na podstawie transportu używanego do komunikacji. Każdy transport w 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:
< nazwa hosta> to nazwa maszyny, która obsługuje kolejkę docelową.
Opcja [private] jest opcjonalna. Jest on używany podczas adresowania kolejki docelowej, która jest kolejką prywatną. Aby zająć się kolejką publiczną, nie można określać jej jako prywatnej. Należy pamiętać, że w przeciwieństwie do ścieżek MSMQ, w formie URI programu WCF nie ma znaku "$".
< queue-name> to nazwa kolejki. Nazwa kolejki może również odwoływać się do podkolejki. Zatem <nazwa-kolejki> = <name-of-queue>[;sub-queue-name].
Przykład1: Aby uzyskać dostęp do prywatnej kolejki PurchaseOrders, hostowanej na komputerze abc.adatum.com, identyfikator URI będzie miał wartość net.msmq://abc.adatum.com/private/PurchaseOrders.
Przykład 2: Aby uzyskać dostęp do publicznej kolejki AccountsPayable umieszczonej na komputerze def.adatum.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łuchowego gniazda TCP.
Punkt końcowy odczytujący z kolejki musi określić adres kolejki przy użyciu tego samego schematu podanego wcześniej przy otwieraniu obiektu ServiceHost. Aby zapoznać się z przykładami, zobacz Net MSMQ Binding.
Wiele kontraktów w kolejce
Komunikaty w kolejce mogą wdrażać 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
NetMsmqBindingobiektu. Logika dyspozytorska w ServiceModel używa mechanizmu pompowania komunikatów, który odczytuje komunikaty z kanału transportowego w celu ich przekazania, co ostatecznie demultipleksuje komunikaty na podstawie kontraktu do różnych punktów końcowych. 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żywających tego samego obiektu wiążącego gwarantuje, że jedna pompka komunikatów jest używana do odczytywania komunikatu i rozgałęzienia do odpowiednich punktów końcowych na podstawie kontraktu.
Wiadomości SRMP
Jak wspomniano wcześniej, można użyć protokołu SRMP do transferów między kolejkami. 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, adresuj komunikaty przy użyciu schematu identyfikatora URI net.msmq, jak wspomniano wcześniej, i określ wybór SRMP lub Zabezpieczone SRMP we właściwości QueueTransferProtocol elementu NetMsmqBinding.
Określanie QueueTransferProtocol właściwości jest funkcją wyłącznie do wysyłania. Jest to wskazanie przez klienta, jakiego rodzaju protokół transferu kolejek ma być używany.
Korzystanie z usługi 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 NetMsmqBinding jest wartością logiczną wskazującą, czy kanał w kolejce musi używać usługi Active Directory, aby rozpoznać identyfikator URI kolejki. Domyślnie jest ustawiona wartość false. Jeśli właściwość UseActiveDirectory jest ustawiona na true, to kanał kolejkowany 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 |
Nieprawda | SRMP | DIRECT=http://machine/msmq/private$/abc |
Net.msmq://<machine-name>/private/abc |
Prawda | Ojczysty |
PUBLIC=some-guid (identyfikator GUID kolejki) |
Odczytywanie komunikatów z kolejki Dead-Letter lub kolejki Poison-Message
Aby odczytać komunikaty z kolejki komunikatów trucizny, która jest kolejką podrzędną kolejki docelowej, otwórz element ServiceHost z adresem tej podrzędnej kolejki.
Przykład: usługa, która odczytuje z kolejki komunikatów trucizny kolejki prywatnej PurchaseOrders z komputera lokalnego, adres net.msmq://localhost/private/PurchaseOrders; trucizna.
Aby odczytać komunikaty z systemowej kolejki transakcyjnej nieodebranych wiadomości, 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 wiadomości nieodebranych jest ograniczony do postaci.
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 kwestia, którą muszą rozwiązać usługi nasłuchujące w kolejce błędnie dostarczonych komunikatów, ponieważ wszelkie komunikaty w tej kolejce miały być dostarczone gdzie indziej. Aby odczytać komunikaty z kolejki martwych listów lub z kolejki błędów, należy użyć ServiceBehavior z parametrem Any. Aby zapoznać się z przykładem, zobacz Dead Letter Queues.
MsmqIntegrationBinding i adresowanie usług
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 formatu 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 MsmqIntegrationBinding nie ma potrzeby dodawania /msmq/ w nazwie bezpośredniego formatu, aby ułatwić przekazywanie przez 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.