Wiele punktów końcowych w pojedynczym identyfikatorze ListenUri

Przykład MultipleEndpointsSingleUri przedstawia usługę, która hostuje wiele punktów końcowych w jednym obiekcie ListenUri. Ten przykład jest oparty na wprowadzenie , który implementuje usługę kalkulatora.

Uwaga

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

Jak pokazano w przykładzie Wiele punktów końcowych , usługa może hostować wiele punktów końcowych, z których każda ma różne adresy, a także różne powiązania. W tym przykładzie pokazano, że istnieje możliwość hostowania wielu punktów końcowych pod tym samym adresem. W tym przykładzie przedstawiono również różnice między dwoma rodzajami adresów, które ma punkt końcowy usługi: EndpointAddress i ListenUri.

Jest EndpointAddress to logiczny adres usługi. Jest to adres, do którego adresowane są komunikaty PROTOKOŁU SOAP. Jest ListenUri to fizyczny adres usługi. Zawiera on informacje o porcie i adresie, w którym punkt końcowy usługi w rzeczywistości nasłuchuje komunikatów na bieżącej maszynie. W większości przypadków nie ma potrzeby różnicowania tych adresów; jeśli element ListenUri nie jest jawnie określony, domyślnie jest to identyfikator URI EndpointAddress punktu końcowego. W kilku przypadkach warto je odróżnić, na przykład podczas konfigurowania routera, co może akceptować komunikaty adresowane do wielu różnych usług.

Usługa

Usługa w tym przykładzie ma dwa kontrakty i ICalculatorIEcho. Oprócz niestandardowego IMetadataExchange punktu końcowego istnieją trzy punkty końcowe aplikacji, jak pokazano w poniższym kodzie.

<endpoint address="urn:Stuff"
        binding="wsHttpBinding"
        contract="Microsoft.ServiceModel.Samples.ICalculator"
        listenUri="http://localhost/servicemodelsamples/service.svc" />
<endpoint address="urn:Stuff"
        binding="wsHttpBinding"
        contract="Microsoft.ServiceModel.Samples.IEcho"
        listenUri="http://localhost/servicemodelsamples/service.svc" />
<endpoint address="urn:OtherEcho"
        binding="wsHttpBinding"
        contract="Microsoft.ServiceModel.Samples.IEcho"
        listenUri="http://localhost/servicemodelsamples/service.svc" />

Wszystkie trzy punkty końcowe są hostowane w tym samym ListenUri miejscu i używają tego samego — punkty końcowe w tym samym ListenUri miejscu muszą mieć to binding samo powiązanie, ponieważ współużytkują jeden stos kanału, który nasłuchuje komunikatów pod tym adresem fizycznym na maszynie. Każdy address punkt końcowy jest identyfikatorem URI, chociaż zazwyczaj adresy reprezentują lokalizacje fizyczne, w rzeczywistości adres może być dowolnym rodzajem identyfikatora URI, ponieważ adres jest używany do dopasowywania i filtrowania celów, jak pokazano w tym przykładzie.

Ponieważ wszystkie trzy punkty końcowe współużytkują ten sam ListenUrielement , gdy pojawi się komunikat, program Windows Communication Foundation (WCF) musi zdecydować, dla którego punktu końcowego jest przeznaczony komunikat. Każdy punkt końcowy ma filtr komunikatu składający się z dwóch części: filtr adresu i filtr kontraktu. Filtr adresu odpowiada To adresowi punktu końcowego usługi komunikatu PROTOKOŁU SOAP. Na przykład tylko adresowane To "Urn:OtherEcho" komunikaty są kandydatami do trzeciego punktu końcowego tej usługi. Filtr kontraktu jest zgodny z akcjami skojarzonymi z operacjami określonego kontraktu. Na przykład komunikaty z akcją IEcho. Echo Pasuje do filtrów kontraktu zarówno drugiego, jak i trzeciego punktu końcowego tej usługi, ponieważ oba te punkty końcowe hostują IEcho kontrakt.

W związku z tym kombinacja filtru adresów i filtr kontraktu umożliwia kierowanie każdego komunikatu, który dociera do tej usługi ListenUri do poprawnego punktu końcowego. Trzeci punkt końcowy różni się od pozostałych dwóch, ponieważ akceptuje komunikaty wysyłane do innego adresu od innych punktów końcowych. Pierwsze i drugie punkty końcowe różnią się od siebie na podstawie ich kontraktów (akcja przychodzącego komunikatu).

Klient

Podobnie jak punkty końcowe na serwerze mają dwa różne adresy, punkty końcowe klienta również mają dwa adresy. Na serwerze i kliencie adres logiczny jest nazywany EndpointAddress. Jednak adres fizyczny jest wywoływany ListenUri na serwerze, na kliencie, adres fizyczny jest nazywany Via.

Podobnie jak na serwerze, domyślnie te dwa adresy są takie same. Aby określić Via wartość na kliencie, który różni się od adresu punktu końcowego, ClientViaBehavior jest używany:

Uri via = new Uri("http://localhost/ServiceModelSamples/service.svc");
CalculatorClient calcClient = new CalculatorClient();
calcClient.ChannelFactory.Endpoint.Behaviors.Add(
        new ClientViaBehavior(via));

Jak zwykle adres pochodzi z pliku konfiguracji klienta, który został wygenerowany przez Svcutil.exe. Element Via (odpowiadający ListenUri usłudze) nie jest wyświetlany w metadanych usługi i dlatego te informacje muszą być przekazywane do klienta poza pasmem (podobnie jak adres metadanych usługi).

Klient w tym przykładzie wysyła komunikaty do każdego z trzech punktów końcowych aplikacji serwera, aby zademonstrować, że może komunikować się z (i rozróżnić) wszystkie trzy punkty końcowe, mimo że wszystkie mają te same Via.

Aby skonfigurować, skompilować i uruchomić przykład

1. Upewnij się, że wykonano procedurę instalacji jednorazowej dla przykładów programu Windows Communication Foundation.

2. Aby skompilować wersję rozwiązania w języku C# lub Visual Basic .NET, postępuj zgodnie z instrukcjami w temacie Building the Windows Communication Foundation Samples (Tworzenie przykładów programu Windows Communication Foundation).

3. Aby uruchomić przykład w konfiguracji pojedynczej lub między maszynami, postępuj zgodnie z instrukcjami w temacie Uruchamianie przykładów programu Windows Communication Foundation.

   Uwaga

   W przypadku maszyny krzyżowej należy zastąpić localhost w pliku Client.cs nazwą maszyny usługi.