Freigeben über

Endpunktadressen

Jedem Endpunkt ist eine Adresse zugeordnet, die zum Suchen und Identifizieren des Endpunkts verwendet wird. Diese Adresse besteht in erster Linie aus einem URI (Uniform Resource Identifier), der den Speicherort des Endpunkts angibt. Die Endpunktadresse wird im Programmiermodell von Windows Communication Foundation (WCF) durch die EndpointAddress Klasse dargestellt, die eine optionale Identity Eigenschaft enthält, die die Authentifizierung des Endpunkts durch andere Endpunkte ermöglicht, die Nachrichten austauschen, und eine Reihe optionaler Headers Eigenschaften, die alle anderen SOAP-Header definieren, die erforderlich sind, um den Dienst zu erreichen. Die optionalen Header bieten zusätzliche und detailliertere Adressierungsinformationen zum Identifizieren oder Interagieren mit dem Dienstendpunkt. Die Adresse eines Endpunkts wird während der Übertragung als WS-Adressierungsendpunktverweis (Endpoint Reference, EPR) dargestellt.

URI-Struktur einer Adresse

Der Adress-URI für die meisten Transporte weist vier Teile auf. Beispielsweise können die vier Teile des URI http://www.fabrikam.com:322/mathservice.svc/secureEndpoint wie folgt itemisiert werden:

  • Scheme (Schema): http:

  • Computer: www.fabrikam.com

  • (optional) Port: 322

  • Pfad: /mathservice.svc/secureEndpoint

Definieren einer Adresse für einen Dienst

Die Endpunktadresse für einen Dienst kann entweder imperativ durch die Verwendung von Code oder deklarativ über die Konfiguration angegeben werden. Das Definieren von Endpunkten im Code ist in der Regel nicht praktikabel, da sich die Bindungen und Adressen für einen bereitgestellten Dienst in der Regel von denen unterscheiden, die während der Entwicklung des Diensts verwendet werden. Im Allgemeinen ist es praktischer, Dienstendpunkte mithilfe von Konfiguration und nicht mit Code zu definieren. Indem Informationen zur Bindung und Adressierung vom Code getrennt werden, können sie geändert werden, ohne die Anwendung neu kompilieren oder erneut deployen zu müssen.

Definieren einer Adresse in der Konfiguration

Verwenden Sie das <Endpunktelement> , um einen Endpunkt in einer Konfigurationsdatei zu definieren. Ausführliche Informationen und ein Beispiel finden Sie unter Angeben einer Endpunktadresse.

Definieren einer Adresse im Code

Eine Endpunktadresse kann im Code mit der EndpointAddress Klasse erstellt werden. Ausführliche Informationen und ein Beispiel finden Sie unter Angeben einer Endpunktadresse.

Endpunkte in WSDL

Eine Endpunktadresse kann auch in WSDL als WS-Addressing EPR-Element innerhalb des entsprechenden Endpunktelements wsdl:port dargestellt werden. Der EPR enthält die Adresse des Endpunkts sowie alle Adresseigenschaften. Ausführliche Informationen und ein Beispiel finden Sie unter Angeben einer Endpunktadresse.

Unterstützung mehrerer IIS-Bindungen in .NET Framework 3.5

Internetdienstanbieter hosten häufig viele Anwendungen auf demselben Server und standort, um die Standortdichte zu erhöhen und die Gesamtbetriebskosten zu senken. Diese Anwendungen sind in der Regel an unterschiedliche Basisadressen gebunden. Eine Iis-Website (Internet Information Services) kann mehrere Anwendungen enthalten. Auf die Anwendungen auf einer Website kann über eine oder mehrere IIS-Bindungen zugegriffen werden.

IIS-Bindungen stellen zwei Informationselemente bereit: ein Bindungsprotokoll und Bindungsinformationen. Das Bindungsprotokoll definiert das Schema, über das die Kommunikation erfolgt, und Bindungsinformationen sind die Informationen, die für den Zugriff auf die Website verwendet werden.

Das folgende Beispiel zeigt die Komponenten, die in einer IIS-Bindung vorhanden sein können:

  • Bindungsprotokoll: HTTP

  • Bindungsinformationen: IP-Adresse, Port, Hostheader

IIS kann für jede Website mehrere Bindungen angeben, was zu mehreren Basisadressen für jedes Schema führt. Vor .NET Framework 3.5 unterstützt WCF nicht mehrere Adressen für ein Schema, und wenn sie angegeben wurden, wurde während der Aktivierung ein ArgumentException Fehler aufgetreten.

Mit .NET Framework 3.5 können Internetdienstanbieter mehrere Anwendungen mit unterschiedlichen Basisadressen für dasselbe Schema auf derselben Website hosten.

Beispielsweise könnte eine Website die folgenden Basisadressen enthalten:

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

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

Mit .NET Framework 3.5 geben Sie einen Präfixfilter auf appDomain-Ebene in der Konfigurationsdatei an. Dazu verwenden Sie das <baseAddressPrefixFilters-Element> , das eine Liste von Präfixen enthält. Die eingehenden Basisadressen, die von IIS bereitgestellt werden, werden basierend auf der optionalen Präfixliste gefiltert. Wenn kein Präfix angegeben wird, werden standardmäßig alle Adressen übergeben. Wenn Sie das Präfix angeben, werden nur die übereinstimmenden Basisadressen für dieses Schema übergeben.

Im Folgenden sehen Sie ein Beispiel für Konfigurationscode, der die Präfixfilter verwendet.

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

Im vorangehenden Beispiel sind net.tcp://payroll.myorg.com:8000 und http://shipping.myorg.com:8000 die einzigen Basisadressen, die für ihre jeweiligen Schemata durchgereicht werden.

Dies baseAddressPrefixFilter unterstützt keine Wildcards.

Die von IIS bereitgestellten Basisadressen enthalten möglicherweise Adressen, die an andere Schemas gebunden sind, die in baseAddressPrefixFilters der Liste nicht vorhanden sind. Diese Adressen werden nicht herausgefiltert.

Unterstützung für mehrere IIS-Bindungen in .NET Framework 4 und höher

Ab .NET 4 können Sie die Unterstützung für mehrere Bindungen in IIS aktivieren, ohne eine Basisadresse auswählen zu müssen. Legen Sie dazu die Einstellung ServiceHostingEnvironment von MultipleSiteBindingsEnabled auf TRUE fest. Diese Unterstützung ist auf HTTP-Protokollschemas beschränkt.

Nachfolgend sehen Sie ein Beispiel für Konfigurationscode, der multipleSiteBindingsEnabled für <serviceHostingEnvironment> verwendet.

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

Alle baseAddressPrefixFilters-Einstellungen werden für HTTP- und nicht-HTTP-Protokolle ignoriert, wenn mehrere Websitebindungen mithilfe dieser Einstellung aktiviert werden.

Ausführliche Informationen und Beispiele finden Sie unter Unterstützen mehrerer IIS-Websitebindungen und MultipleSiteBindingsEnabled.

Erweiterung der Adressierung in WCF-Diensten

Das Standardadressierungsmodell von WCF-Diensten verwendet den Endpunktadressen-URI für die folgenden Zwecke:

  • Um die Abhöradresse des Diensts anzugeben, d. h. den Speicherort, den der Endpunkt auf Nachrichten abhört

  • Um den SOAP-Adressfilter anzugeben, geben Sie die Adresse an, die ein Endpunkt im SOAP-Header erwartet.

Die Werte für beide Situationen können separat angegeben werden. Dadurch werden mehrere Adressierungserweiterungen für nützliche Szenarien möglich:

  • SOAP-Vermittler: Eine von einem Client gesendete Nachricht durchläuft einen oder mehrere zusätzliche Dienste, die die Nachricht verarbeiten, bevor sie das endgültige Ziel erreicht. SOAP-Vermittler können verschiedene Aufgaben ausführen, z. B. Zwischenspeichern, Routing, Lastenausgleich oder Schemaüberprüfung für die Nachrichten. Dieses Szenario wird erreicht, indem Nachrichten an eine separate physische Adresse (via) gesendet werden, die auf einen Vermittler abzielt und nicht nur auf eine logische Adresse (wsa:To), die das eigentliche Ziel ansteuert.

  • Die Abhöradresse des Endpunkts ist ein privater URI und wird auf einen anderen Wert als seine listenURI-Eigenschaft festgelegt.

Die Transportadresse, die der via angibt, ist der Ort, an den eine Nachricht zunächst auf dem Weg zu einer anderen entfernten Adresse gesendet werden soll, die durch den to Parameter angegeben wird, an dem der Dienst sich befindet. In den meisten Internetszenarien ist der via URI mit der Uri Eigenschaft der endgültigen to Adresse des Diensts identisch. Sie unterscheiden nur zwischen diesen beiden Adressen, wenn Sie manuelles Routing ausführen müssen.

Adressierung von Kopfzeilen

Ein Endpunkt kann zusätzlich zu seinem grundlegenden URI von einem oder mehreren SOAP-Headern adressiert werden. Eine Reihe von Szenarien, in denen dies nützlich ist, ist eine Reihe von SOAP-Zwischenszenarien, in denen ein Endpunkt Clients dieses Endpunkts erfordert, SOAP-Header für Vermittler einzuschließen.

Sie können benutzerdefinierte Adressheader auf zwei Arten definieren – entweder mit Code oder Konfiguration:

  • Im Code werden benutzerdefinierte Adressheader mithilfe der AddressHeader-Klasse erstellt und dann bei der Erstellung einer EndpointAddress verwendet.

  • In der Konfiguration werden benutzerdefinierte <headers>-Elemente als untergeordnete Elemente des <endpoint>-Elements angegeben.

Die Konfiguration ist im Allgemeinen dem Code vorzuziehen, da sie es Ihnen ermöglicht, die Header nach der Bereitstellung zu ändern.

Benutzerdefinierte Abhöradressen

Sie können die Abhöradresse auf einen anderen Wert als den URI des Endpunkts festlegen. Dies ist in zwischengeschalteten Szenarien nützlich, in denen die zu veröffentlichende SOAP-Adresse der öffentlichen SOAP-Vermittler ist, während die Adresse, an der der Endpunkt tatsächlich lauscht, eine private Netzwerkadresse ist.

Sie können eine benutzerdefinierte Abhöradresse entweder mithilfe von Code oder Konfiguration angeben.

  • Geben Sie im Code eine benutzerdefinierte Listening-Adresse an, indem Sie der Verhaltenssammlung des Endpunkts eine ClientViaBehavior Klasse hinzufügen.

  • Geben Sie in der Konfiguration eine benutzerdefinierte Lauschadresse mit dem ListenUri-Attribut des <endpoint>-Elements des Diensts an.

Benutzerdefinierter SOAP-Adressfilter

Die Uri Wird in Verbindung mit einer beliebigen Headers Eigenschaft verwendet, um den SOAP-Adressfilter eines Endpunkts (AddressFilter) zu definieren. Standardmäßig überprüft dieser Filter, ob eine eingehende Nachricht über einen To Nachrichtenkopf verfügt, der mit dem URI des Endpunkts übereinstimmt und dass alle erforderlichen Endpunktheader in der Nachricht vorhanden sind.

In einigen Szenarien empfängt ein Endpunkt alle Nachrichten, die beim zugrunde liegenden Transport eingehen, und nicht nur solche mit dem entsprechenden To Header. Um dies zu aktivieren, kann der Benutzer die MatchAllMessageFilter Klasse verwenden.

Siehe auch