Niestandardowy dyspozytor kanału

Przykład CustomChannelDispatcher pokazuje, jak utworzyć stos kanału w niestandardowy sposób, implementując ServiceHostBase bezpośrednio i jak utworzyć niestandardowy dyspozytor kanału w środowisku hosta sieci Web. Dyspozytor kanału współdziała z usługą IChannelListener w celu akceptowania kanałów i pobierania komunikatów ze stosu kanału. Ten przykład zawiera również podstawowy przykład pokazujący, jak utworzyć stos kanału w środowisku hosta sieci Web przy użyciu polecenia VirtualPathExtension.

Niestandardowa baza danych ServiceHostBase

Ten przykład implementuje typ ServiceHostBase podstawowy zamiast ServiceHost pokazać, jak zastąpić implementację stosu Windows Communication Foundation (WCF) niestandardową warstwą obsługi komunikatów na stosie kanału. Zastąpisz metodę InitializeRuntime wirtualną w celu skompilowania odbiorników kanału i dyspozytora kanału.

Aby zaimplementować usługę hostowaną w sieci Web, pobierz rozszerzenie VirtualPathExtension usługi z Extensions kolekcji i dodaj je do BindingParameterCollection niej, aby warstwa transportu wiedziała, jak skonfigurować odbiornik kanału na podstawie ustawień środowiska hostingu, czyli ustawień internetowych usług informacyjnych (IIS)/usługi aktywacji procesów systemu Windows (WAS).

Niestandardowy dyspozytor kanału

Niestandardowy dyspozytor kanału rozszerza typ ChannelDispatcherBase. Ten typ implementuje logikę programowania w warstwie kanału. W tym przykładzie obsługiwany jest tylko IReplyChannel wzorzec wymiany komunikatów z odpowiedzią na żądanie, ale niestandardowy dyspozytor kanału można łatwo rozszerzyć na inne typy kanałów.

Dyspozytor najpierw otwiera odbiornik kanału, a następnie akceptuje pojedynczy kanał odpowiedzi. Wraz z kanałem zaczyna wysyłać komunikaty (żądania) w nieskończonej pętli. Dla każdego żądania tworzy komunikat odpowiedzi i wysyła go z powrotem do klienta.

Tworzenie komunikatu odpowiedzi

Przetwarzanie komunikatów jest implementowane w typie MyServiceManager. W metodzie HandleRequest nagłówek komunikatu jest najpierw sprawdzany, aby sprawdzić, Action czy żądanie jest obsługiwane. Zdefiniowano wstępnie zdefiniowaną akcję http://tempuri.org/HelloWorld/Hello PROTOKOŁU SOAP w celu zapewnienia filtrowania komunikatów. Jest to podobne do koncepcji kontraktu usługi w implementacji programu WCF programu ServiceHost.

W przypadku poprawnego przypadku akcji protokołu SOAP przykład pobiera żądane dane komunikatu i generuje odpowiadającą odpowiedź na żądanie podobne do tego, co jest widoczne w ServiceHost przypadku.

Specjalnie obsłużyliśmy czasownik HTTP-GET, zwracając w tym przypadku niestandardowy komunikat HTML, aby można było przeglądać usługę z przeglądarki, aby zobaczyć, że jest poprawnie skompilowana. Jeśli akcja PROTOKOŁU SOAP nie jest zgodna, wyślij z powrotem komunikat o błędzie, aby wskazać, że żądanie nie jest obsługiwane.

Klientem tego przykładu jest normalny klient WCF, który nie zakłada niczego z usługi. Dlatego usługa jest specjalnie zaprojektowana tak, aby odpowiadała temu, co można uzyskać z normalnej implementacji programu WCFServiceHost . W związku z tym na kliencie jest wymagany tylko kontrakt usługi.

Korzystanie z przykładu

Uruchomienie aplikacji klienckiej powoduje bezpośrednie wygenerowanie następujących danych wyjściowych.

Client is talking to a request/reply WCF service.
Type what you want to say to the server: Howdy
Server replied: You said: Howdy. Message id: 1
Server replied: You said: Howdy. Message id: 2
Server replied: You said: Howdy. Message id: 3
Server replied: You said: Howdy. Message id: 4
Server replied: You said: Howdy. Message id: 5

Możesz również przeglądać usługę z przeglądarki, aby komunikat HTTP-GET był przetwarzany na serwerze. Dzięki temu można poprawnie sformatować tekst HTML.