Eindpuntadressen

Artikel
03/02/2024

Aan elk eindpunt is een adres gekoppeld, dat wordt gebruikt om het eindpunt te zoeken en te identificeren. Dit adres bestaat voornamelijk uit een URI (Uniform Resource Identifier), waarmee de locatie van het eindpunt wordt opgegeven. Het eindpuntadres wordt weergegeven in het WCF-programmeermodel (Windows Communication Foundation) door de EndpointAddress klasse, dat een optionele Identity eigenschap bevat die de verificatie van het eindpunt mogelijk maakt door andere eindpunten waarmee berichten worden uitgewisseld en een set optionele Headers eigenschappen waarmee andere SOAP-headers worden gedefinieerd die nodig zijn om de service te bereiken. De optionele headers bieden aanvullende en gedetailleerdere adresseringsinformatie om het service-eindpunt te identificeren of ermee te communiceren. Het adres van een eindpunt wordt op de draad weergegeven als een WS-Adresseringseindpuntverwijzing (EPR).

URI-structuur van een adres

De adres-URI voor de meeste transporten heeft vier delen. De vier delen van de URI http://www.fabrikam.com:322/mathservice.svc/secureEndpoint kunnen bijvoorbeeld als volgt worden geitemd:

Scheme: http:
Machine: www.fabrikam.com
(optioneel) Poort: 322
Pad: /mathservice.svc/secureEndpoint

Een adres voor een service definiëren

Het eindpuntadres voor een service kan imperatief worden opgegeven met behulp van code of declaratief via configuratie. Het definiëren van eindpunten in code is meestal niet praktisch omdat de bindingen en adressen voor een geïmplementeerde service doorgaans afwijken van de bindingen en adressen die worden gebruikt terwijl de service wordt ontwikkeld. Over het algemeen is het praktischer om service-eindpunten te definiëren met behulp van configuratie in plaats van code. Door de bindings- en adresseringsgegevens buiten de code te houden, kunnen ze worden gewijzigd zonder de toepassing opnieuw te hoeven compileren of opnieuw te implementeren.

Een adres definiëren in configuratie

Als u een eindpunt in een configuratiebestand wilt definiëren, gebruikt u het eindpuntelement>.< Zie Een eindpuntadres opgeven voor meer informatie en een voorbeeld.

Een adres definiëren in code

Er kan een eindpuntadres worden gemaakt in code met de EndpointAddress klasse. Zie Een eindpuntadres opgeven voor meer informatie en een voorbeeld.

Eindpunten in WSDL

Een eindpuntadres kan ook in WSDL worden weergegeven als een EPR-element voor WS-adressering binnen het bijbehorende eindpuntelement wsdl:port . Het EPR bevat het adres van het eindpunt en alle adreseigenschappen. Zie Een eindpuntadres opgeven voor meer informatie en een voorbeeld.

Ondersteuning voor meerdere IIS-bindingen in .NET Framework 3.5

Internetserviceproviders hosten vaak veel toepassingen op dezelfde server en site om de sitedichtheid te verhogen en de totale eigendomskosten te verlagen. Deze toepassingen zijn doorgaans gebonden aan verschillende basisadressen. Een IIS-website (Internet Information Services) kan meerdere toepassingen bevatten. De toepassingen op een site kunnen worden geopend via een of meer IIS-bindingen.

IIS-bindingen bieden twee stukjes informatie: een bindingsprotocol en bindingsinformatie. Het bindingsprotocol definieert het schema over welke communicatie plaatsvindt en bindingsinformatie is de informatie die wordt gebruikt voor toegang tot de site.

In het volgende voorbeeld ziet u de onderdelen die aanwezig kunnen zijn in een IIS-binding:

Bindingsprotocol: HTTP
Bindingsinformatie: IP-adres, poort, hostheader

IIS kan meerdere bindingen opgeven voor elke site, wat resulteert in meerdere basisadressen voor elk schema. Vóór .NET Framework 3.5 biedt WCF geen ondersteuning voor meerdere adressen voor een schema en, als deze zijn opgegeven, gooide het tijdens de activering.ArgumentException

Met .NET Framework 3.5 kunnen internetproviders meerdere toepassingen hosten met verschillende basisadressen voor hetzelfde schema op dezelfde site.

Een site kan bijvoorbeeld de volgende basisadressen bevatten:

http://payroll.myorg.com/Service.svc
http://shipping.myorg.com/Service.svc

Met .NET Framework 3.5 geeft u een voorvoegselfilter op appdomeinniveau op in het configuratiebestand. U doet dit met het <element baseAddressPrefixFilters> , dat een lijst met voorvoegsels bevat. De binnenkomende basisadressen, geleverd door IIS, worden gefilterd op basis van de optionele lijst met voorvoegsels. Wanneer er geen voorvoegsel is opgegeven, worden standaard alle adressen doorgegeven. Als u het voorvoegsel opgeeft, wordt alleen het overeenkomende basisadres voor dat schema doorgegeven.

Hier volgt een voorbeeld van configuratiecode die gebruikmaakt van de voorvoegselfilters.

<system.serviceModel>  
  <serviceHostingEnvironment>  
     <baseAddressPrefixFilters>  
        <add prefix="net.tcp://payroll.myorg.com:8000"/>  
        <add prefix="http://shipping.myorg.com:8000"/>  
    </baseAddressPrefixFilters>  
  </serviceHostingEnvironment>  
</system.serviceModel>

In het voorgaande voorbeeld net.tcp://payroll.myorg.com:8000 zijn dit http://shipping.myorg.com:8000 de enige basisadressen voor hun respectieve schema's, die worden doorgegeven.

Het baseAddressPrefixFilter biedt geen ondersteuning voor jokertekens.

De basisadressen die door IIS worden geleverd, hebben mogelijk adressen die zijn gebonden aan andere schema's die niet in baseAddressPrefixFilters de lijst voorkomen. Deze adressen worden niet uitgefilterd.

Ondersteuning voor meerdere IIS-bindingen in .NET Framework 4 en hoger

Vanaf .NET 4 kunt u ondersteuning voor meerdere bindingen in IIS inschakelen zonder dat u één basisadres hoeft te kiezen door de instelling waar in MultipleSiteBindingsEnabled te stellenServiceHostingEnvironment. Deze ondersteuning is beperkt tot HTTP-protocolschema's.

Hier volgt een voorbeeld van configuratiecode die gebruikmaakt van multipleSiteBindingsEnabled op <serviceHostingEnvironment>.

<system.serviceModel>  
  <serviceHostingEnvironment multipleSiteBindingsEnabled="true" >  
  </serviceHostingEnvironment>  
</system.serviceModel>

Alle baseAddressPrefixFilters-instellingen worden genegeerd voor zowel HTTP- als niet-HTTP-protocollen wanneer meerdere sitebindingen zijn ingeschakeld met deze instelling.

Zie Ondersteuning voor meerdere IIS-sitebindingen en MultipleSiteBindingsEnabledvoor meer informatie en voorbeelden.

Adressering uitbreiden in WCF-services

Het standaard adresseringsmodel van WCF-services maakt gebruik van de eindpuntadres-URI voor de volgende doeleinden:

Om het luisteradres van de service op te geven, de locatie waar het eindpunt naar berichten luistert,
Als u het SOAP-adresfilter wilt opgeven, wordt het adres dat een eindpunt verwacht als soap-header.

De waarden voor elk van deze doeleinden kunnen afzonderlijk worden opgegeven, waardoor verschillende uitbreidingen van adressering kunnen worden gebruikt voor nuttige scenario's:

SOAP-tussenpersonen: een bericht dat door een client wordt verzonden, doorkruist een of meer aanvullende services die het bericht verwerken voordat het de uiteindelijke bestemming bereikt. SOAP-tussenpersonen kunnen verschillende taken uitvoeren, zoals caching, routering, taakverdeling of schemavalidatie voor de berichten. Dit scenario wordt bereikt door berichten te verzenden naar een afzonderlijk fysiek adres (via) dat gericht is op de intermediair in plaats van alleen op een logisch adres (wsa:To) dat gericht is op de uiteindelijke bestemming.
Het luisteradres van het eindpunt is een privé-URI en is ingesteld op een andere waarde dan de listenURI eigenschap ervan.

Het transportadres dat wordt via opgegeven, is de locatie waarnaar een bericht in eerste instantie moet worden verzonden naar een ander extern adres dat is opgegeven door de to parameter waarop de service zich bevindt. In de meeste internetscenario's is de via URI hetzelfde als de Uri eigenschap van het uiteindelijke to adres van de service. U maakt alleen onderscheid tussen deze twee adressen wanneer u handmatige routering moet uitvoeren.

Adresseringsheaders

Een eindpunt kan worden geadresseerd door een of meer SOAP-headers, naast de basis-URI. Een reeks scenario's waarbij dit nuttig is, is een set SOAP-tussenliggende scenario's waarbij clients van dat eindpunt SOAP-headers moeten bevatten die zijn gericht op tussenpersonen.

U kunt aangepaste adreskoppen op twee manieren definiëren: met behulp van code of configuratie:

Maak in code aangepaste adreskoppen met behulp van de AddressHeader klasse en vervolgens gebruikt in de constructie van een EndpointAddress.
In de configuratie worden aangepaste headers> opgegeven als onderliggende elementen van het< eindpuntelement>.<

De configuratie is over het algemeen de voorkeur aan code, omdat u de headers na de implementatie kunt wijzigen.

Aangepaste luisteradressen

U kunt het luisteradres instellen op een andere waarde dan de URI van het eindpunt. Dit is handig in tussenliggende scenario's waarbij het SOAP-adres dat moet worden weergegeven, is dat van een openbare SOAP-intermediair, terwijl het adres waar het eindpunt daadwerkelijk luistert een privénetwerkadres is.

U kunt een aangepast luisteradres opgeven met behulp van code of configuratie:

Geef in code een aangepast luisteradres op door een ClientViaBehavior klasse toe te voegen aan de gedragverzameling van het eindpunt.
Geef in de configuratie een aangepast luisteradres op met het ListenUri kenmerk van het service-eindpuntelement<>.

Aangepast SOAP-adresfilter

De Uri wordt gebruikt in combinatie met een Headers eigenschap om het SOAP-adresfilter (AddressFilter) van een eindpunt te definiëren. Dit filter controleert standaard of een binnenkomend bericht een To berichtkop bevat die overeenkomt met de URI van het eindpunt en of alle vereiste eindpuntheaders aanwezig zijn in het bericht.

In sommige scenario's ontvangt een eindpunt alle berichten die binnenkomen bij het onderliggende transport, en niet alleen berichten met de juiste To header. Om dit in te schakelen, kan de gebruiker de MatchAllMessageFilter klasse gebruiken.

Delen via