Meerdere eindpunten op één listenuri

Het voorbeeld MultipleEndpointsSingleUri demonstreert een service die als host fungeert voor meerdere eindpunten op één ListenUri. Dit voorbeeld is gebaseerd op de Aan de slag die een rekenmachineservice implementeert.

Notitie

De installatieprocedure en build-instructies voor dit voorbeeld bevinden zich aan het einde van dit onderwerp.

Zoals gedemonstreerd in het voorbeeld meerdere eindpunten , kan een service meerdere eindpunten hosten, elk met verschillende adressen en mogelijk ook verschillende bindingen. In dit voorbeeld ziet u dat het mogelijk is om meerdere eindpunten op hetzelfde adres te hosten. In dit voorbeeld ziet u ook de verschillen tussen de twee soorten adressen die een service-eindpunt heeft: EndpointAddress en ListenUri.

Dit EndpointAddress is het logische adres van een service. Het is het adres waarnaar SOAP-berichten zijn geadresseerd. Het ListenUri is het fysieke adres van de service. Het bevat de poort- en adresgegevens waar het service-eindpunt daadwerkelijk luistert naar berichten op de huidige computer. In de meeste gevallen is het niet nodig dat deze adressen verschillen; wanneer een ListenUri niet expliciet is opgegeven, wordt deze standaard ingesteld op de URI van het EndpointAddress eindpunt. In een paar gevallen is het handig om ze te onderscheiden, zoals bij het configureren van een router, die mogelijk berichten accepteert die zijn geadresseerd aan een aantal verschillende services.

Service

De service in dit voorbeeld heeft twee contracten en ICalculatorIEcho. Naast het aangepaste IMetadataExchange eindpunt zijn er drie toepassingseindpunten, zoals wordt weergegeven in de volgende code.

<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" />

Alle drie de eindpunten worden op hetzelfde ListenUri gehost en gebruiken dezelfde binding - eindpunten op hetzelfde ListenUri moeten dezelfde binding hebben, omdat ze één kanaalstack delen die luistert naar berichten op dat fysieke adres op de computer. Het address van elk eindpunt is een URN; hoewel adressen doorgaans fysieke locaties vertegenwoordigen, kan het adres elk type URI zijn, omdat het adres wordt gebruikt voor overeenkomende en filterdoeleinden, zoals in dit voorbeeld wordt gedemonstreerd.

Omdat alle drie de eindpunten hetzelfde ListenUridelen, moet windows Communication Foundation (WCF) bepalen voor welk eindpunt het bericht is bestemd wanneer er een bericht binnenkomt. Elk eindpunt heeft een berichtfilter dat uit twee delen bestaat: het adresfilter en het contractfilter. Het adresfilter komt overeen met het To SOAP-bericht met het adres van het service-eindpunt. Alleen geadresseerde To "Urn:OtherEcho" berichten zijn bijvoorbeeld kandidaten voor het derde eindpunt van deze service. Het contractfilter komt overeen met de acties die zijn gekoppeld aan de bewerkingen van een bepaald contract. Bijvoorbeeld berichten met de actie van IEcho. Echo komt overeen met de contractfilters van zowel de tweede als de derde eindpunten van deze service, omdat beide eindpunten het IEcho contract hosten.

De combinatie van adresfilter en contractfilter maakt het dus mogelijk om elk bericht dat bij deze service ListenUri aankomt, naar het juiste eindpunt te routeren. Het derde eindpunt wordt onderscheiden van de andere twee omdat het berichten accepteert die worden verzonden naar een ander adres dan de andere eindpunten. De eerste en tweede eindpunten onderscheiden zich van elkaar op basis van hun contracten (de actie van het binnenkomende bericht).

Klant

Net zoals eindpunten op de server twee verschillende adressen hebben, hebben clienteindpunten ook twee adressen. Op zowel de server als de client wordt het logische adres de EndpointAddress. Maar terwijl het fysieke adres de ListenUri server wordt genoemd, wordt het fysieke adres op de client het fysieke adres genoemd Via.

Net als op de server zijn deze twee adressen standaard hetzelfde. Als u een Via op de client wilt opgeven die verschilt van het adres van het eindpunt, ClientViaBehavior wordt het volgende gebruikt:

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

Zoals gebruikelijk is het adres afkomstig van het clientconfiguratiebestand, dat is gegenereerd door Svcutil.exe. De Via (die overeenkomt met de ListenUri service) wordt niet weergegeven in de metagegevens van de service en deze informatie moet dus worden gecommuniceerd naar de client buiten de band (net als het metagegevensadres van de service).

De client in dit voorbeeld verzendt berichten naar elk van de drie toepassingseindpunten van de server, om te laten zien dat deze kan communiceren met alle drie de eindpunten (en onderscheid kan maken), ook al hebben ze allemaal hetzelfde Via.

Het voorbeeld instellen, compileren en uitvoeren

1. Zorg ervoor dat u de eenmalige installatieprocedure voor de Windows Communication Foundation-voorbeelden hebt uitgevoerd.

2. Als u de C# of Visual Basic .NET-editie van de oplossing wilt bouwen, volgt u de instructies in het bouwen van de Windows Communication Foundation-voorbeelden.

3. Als u het voorbeeld wilt uitvoeren in een configuratie met één of meerdere computers, volgt u de instructies in Het uitvoeren van de Windows Communication Foundation-voorbeelden.

   Notitie

   Voor meerdere computers moet u localhost in het Client.cs-bestand vervangen door de naam van de servicemachine.