Niestandardowy filtr komunikatów

W przykładzie MessageFilter pokazano, jak zastąpić filtry komunikatów używane przez program Windows Communication Foundation (WCF) do wysyłania komunikatów do punktów końcowych.

Uwaga / Notatka

Procedura instalacji i instrukcje kompilacji dla tego przykładu znajdują się na końcu tego tematu.

Gdy pierwszy komunikat w kanale pojawi się na serwerze, serwer musi określić, które (jeśli istnieją) punktów końcowych skojarzonych z tym identyfikatorem URI, powinny otrzymać komunikat. Proces ten jest kontrolowany przez obiekty MessageFilter dołączone do EndpointDispatcher.

Każdy punkt końcowy usługi ma jeden EndpointDispatcherelement . Obiekt EndpointDispatcher ma zarówno AddressFilter jak i ContractFilter. Połączenie tych dwóch filtrów to filtr komunikatu używany dla tego punktu końcowego.

Domyślnie AddressFilter punkt końcowy odpowiada dowolnemu komunikatowi, który jest adresowany do adresu pasującego do EndpointAddress punktu końcowego usługi. Domyślnie ContractFilter dla punktu końcowego analizuje akcję przychodzącego komunikatu i dopasowuje dowolny komunikat, którego akcja odpowiada jednej z akcji operacji kontraktu punktu końcowego usługi (uwzględniane są tylko IsInitiating=true akcje). W związku z tym domyślnie filtr dla punktu końcowego jest zgodny tylko wtedy, gdy nagłówek Do komunikatu jest EndpointAddress punktem końcowym, a akcja komunikatu jest zgodna z jedną z akcji operacji punktu końcowego.

Te filtry można zmienić przy użyciu zachowania. W przykładzie usługa tworzy obiekt IEndpointBehavior , który zastępuje element AddressFilter i ContractFilter w elemencie EndpointDispatcher:

class FilteringEndpointBehavior : IEndpointBehavior
{
    //...
}

Zdefiniowano dwa filtry adresów:

// Matches any message whose To address contains the letter 'e'
class MatchEAddressFilter : MessageFilter { }
// Matches any message whose To address does not contain the letter 'e'
class MatchNoEAddressFilter : MessageFilter { }

Element FilteringEndpointBehavior jest konfigurowalny i umożliwia korzystanie z dwóch różnych odmian.

public class FilteringEndpointBehaviorExtension : BehaviorExtensionElement { }

Odmiana 1 pasuje tylko do adresów zawierających "e" (ale które mają dowolną akcję), podczas gdy odmiana 2 pasuje tylko do adresów, które nie mają znaku "e":

if (Variation == 1)
    return new FilteringEndpointBehavior(
        new MatchEAddressFilter(), new MatchAllMessageFilter());
else
    return new FilteringEndpointBehavior(
        new MatchNoEAddressFilter(), new MatchAllMessageFilter());

W pliku konfiguracji usługa rejestruje nowe zachowanie:

<extensions>
    <behaviorExtensions>
        <add name="filteringEndpointBehavior" type="Microsoft.ServiceModel.Samples.FilteringEndpointBehaviorExtension, service" />
    </behaviorExtensions>
</extensions>

Następnie usługa tworzy endpointBehavior konfiguracje dla każdej odmiany:

<endpointBehaviors>
    <behavior name="endpoint1">
        <filteringEndpointBehavior variation="1" />
    </behavior>
    <behavior name="endpoint2">
        <filteringEndpointBehavior variation="2" />
    </behavior>
</endpointBehaviors>

Na koniec punkt końcowy usługi odwołuje się do jednego z następujących elementów behaviorConfigurations:

<endpoint address=""
        bindingConfiguration="ws"
        listenUri=""
        binding="wsHttpBinding"
        contract="Microsoft.ServiceModel.Samples.IHello"
        behaviorConfiguration="endpoint2" />

Implementacja aplikacji klienckiej jest prosta; aplikacja tworzy dwa kanały do identyfikatora URI usługi, przekazując tę wartość jako drugi parametr (via) do CreateChannel(EndpointAddress), i wysyła jedną wiadomość na każdym kanale, używając jednak różnych adresów końcowych dla każdego z nich. W związku z tym komunikaty wychodzące od klienta mają inne oznaczenia Do, a serwer odpowiada odpowiednio, jak pokazano w danych wyjściowych klienta:

Sending message to urn:e...
Exception: The message with To 'urn:e' cannot be processed at the receiver, due to an AddressFilter mismatch at the EndpointDispatcher. Check that the sender and receiver's EndpointAddresses agree.

Sending message to urn:a...
Hello

Przełączenie odmiany w pliku konfiguracji serwera powoduje zamianę filtra, a klient widzi odwrotne zachowanie (komunikat do urn:e powiedzie się, podczas gdy komunikat do urn:a kończy się niepowodzeniem).

<endpoint address=""
          bindingConfiguration="ws"
          listenUri=""
          binding="wsHttpBinding"
          contract="Microsoft.ServiceModel.Samples.IHello"
          behaviorConfiguration="endpoint1" />

Aby skonfigurować, skompilować i uruchomić przykładowy program

1. Aby skompilować rozwiązanie, postępuj zgodnie z instrukcjami w temacie Building the Windows Communication Foundation Samples (Tworzenie przykładów programu Windows Communication Foundation).

2. Aby uruchomić przykład w konfiguracji pojedynczej maszyny, postępuj zgodnie z instrukcjami w temacie Uruchamianie przykładów programu Windows Communication Foundation.

3. Aby uruchomić przykład w konfiguracji między maszynami, postępuj zgodnie z instrukcjami w artykule Uruchamianie przykładów programu Windows Communication Foundation i zmień następujący wiersz w Client.cs.

   Uri serviceVia = new Uri("http://localhost/ServiceModelSamples/service.svc");
   

   Zastąp ciąg localhost nazwą serwera.

   Uri serviceVia = new Uri("http://servermachinename/ServiceModelSamples/service.svc");