Udostępnij przez

Adresy punktów końcowych

  • Artykuł

Każdy punkt końcowy ma skojarzony z nim adres, który służy do lokalizowania i identyfikowania punktu końcowego. Ten adres składa się głównie z identyfikatora URI (Uniform Resource Identifier), który określa lokalizację punktu końcowego. Adres punktu końcowego jest reprezentowany w modelu programowania Windows Communication Foundation (WCF) przez EndpointAddress klasę, która zawiera opcjonalną Identity właściwość, która umożliwia uwierzytelnianie punktu końcowego przez inne punkty końcowe, które wymieniają komunikaty z nim, oraz zestaw opcjonalnych Headers właściwości, które definiują wszelkie inne nagłówki protokołu SOAP wymagane do dotarcia do usługi. Opcjonalne nagłówki zawierają dodatkowe i bardziej szczegółowe informacje dotyczące adresowania w celu zidentyfikowania punktu końcowego usługi lub interakcji z nim. Adres punktu końcowego jest reprezentowany na przewodie jako odwołanie do punktu końcowego adresowania WS (EPR).

Struktura identyfikatora URI adresu

Identyfikator URI adresu dla większości transportów ma cztery części. Na przykład cztery części identyfikatora URI http://www.fabrikam.com:322/mathservice.svc/secureEndpoint można określić w następujący sposób:

  • Schemat: http:

  • Maszyny: www.fabrikam.com

  • (opcjonalnie) Port: 322

  • Ścieżka: /mathservice.svc/secureEndpoint

Definiowanie adresu dla usługi

Adres punktu końcowego dla usługi można określić w sposób imperatywny przy użyciu kodu lub deklaratywnego za pośrednictwem konfiguracji. Definiowanie punktów końcowych w kodzie zwykle nie jest praktyczne, ponieważ powiązania i adresy wdrożonej usługi zwykle różnią się od tych używanych podczas opracowywania usługi. Ogólnie rzecz biorąc, bardziej praktyczne jest definiowanie punktów końcowych usługi przy użyciu konfiguracji, a nie kodu. Utrzymywanie powiązania i adresowania informacji poza kodem umożliwia ich zmianę bez konieczności ponownego kompilowania lub ponownego wdrażania aplikacji.

Definiowanie adresu w konfiguracji

Aby zdefiniować punkt końcowy w pliku konfiguracji, użyj elementu punktu końcowego><. Aby uzyskać szczegółowe informacje i przykład, zobacz Określanie adresu punktu końcowego.

Definiowanie adresu w kodzie

Adres punktu końcowego można utworzyć w kodzie z klasą EndpointAddress . Aby uzyskać szczegółowe informacje i przykład, zobacz Określanie adresu punktu końcowego.

Punkty końcowe w języku WSDL

Adres punktu końcowego może być również reprezentowany w języku WSDL jako element EPR adresowania WS wewnątrz odpowiedniego elementu punktu końcowego wsdl:port . EPR zawiera adres punktu końcowego oraz wszelkie właściwości adresu. Aby uzyskać szczegółowe informacje i przykład, zobacz Określanie adresu punktu końcowego.

Obsługa powiązań wielu usług IIS w programie .NET Framework 3.5

Dostawcy usług internetowych często hostują wiele aplikacji na tym samym serwerze i w tej samej witrynie, aby zwiększyć gęstość lokacji i obniżyć całkowity koszt posiadania. Te aplikacje są zwykle powiązane z różnymi adresami podstawowymi. Witryna sieci Web usług Internet Information Services (IIS) może zawierać wiele aplikacji. Dostęp do aplikacji w witrynie można uzyskać za pośrednictwem co najmniej jednego powiązania usług IIS.

Powiązania usług IIS zawierają dwie informacje: protokół powiązania i informacje o powiązaniu. Protokół powiązania definiuje schemat, w którym odbywa się komunikacja, a informacje powiązania to informacje używane do uzyskiwania dostępu do lokacji.

W poniższym przykładzie przedstawiono składniki, które mogą być obecne w powiązaniu usług IIS:

  • Protokół powiązania: HTTP

  • Informacje o powiązaniu: adres IP, port, nagłówek hosta

Usługi IIS mogą określać wiele powiązań dla każdej lokacji, co powoduje wiele adresów bazowych dla każdego schematu. Przed programem .NET Framework 3.5 program WCF nie obsługiwał wielu adresów schematu i, jeśli zostały określone, rzucił ArgumentException podczas aktywacji.

Program .NET Framework 3.5 umożliwia dostawcom usług internetowych hostowanie wielu aplikacji z różnymi adresami podstawowymi dla tego samego schematu w tej samej witrynie.

Na przykład lokacja może zawierać następujące adresy podstawowe:

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

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

W programie .NET Framework 3.5 należy określić filtr prefiksu na poziomie AppDomain w pliku konfiguracji. Można to zrobić za <pomocą elementu baseAddressPrefixFilters> , który zawiera listę prefiksów. Przychodzące adresy podstawowe dostarczane przez usługi IIS są filtrowane na podstawie opcjonalnej listy prefiksów. Domyślnie, gdy prefiks nie jest określony, wszystkie adresy są przekazywane. Określenie prefiksu powoduje przekazanie tylko pasującego adresu podstawowego dla tego schematu.

Poniżej przedstawiono przykład kodu konfiguracji, który używa filtrów prefiksów.

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

W poprzednim przykładzie net.tcp://payroll.myorg.com:8000 i http://shipping.myorg.com:8000 są jedynymi adresami podstawowymi dla odpowiednich schematów, które są przekazywane.

Symbole baseAddressPrefixFilter wieloznaczne nie obsługują symboli wieloznacznych.

Adresy podstawowe dostarczane przez usługi IIS mogą mieć adresy powiązane z innymi schematami, które nie znajdują się na baseAddressPrefixFilters liście. Te adresy nie są filtrowane.

Obsługa powiązań wielu usług IIS w programie .NET Framework 4 lub nowszym

Począwszy od platformy .NET 4, można włączyć obsługę wielu powiązań w usługach IIS bez konieczności wybierania jednego adresu podstawowego, ustawiając ServiceHostingEnvironmentustawienie wartości MultipleSiteBindingsEnabled true. Ta obsługa jest ograniczona do schematów protokołów HTTP.

Poniżej przedstawiono przykład kodu konfiguracji, który korzysta z wielu elementów MultipleSiteBindingsEnabled w usłudze ServiceHostingEnvironment>.<

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

Wszystkie ustawienia baseAddressPrefixFilters są ignorowane zarówno dla protokołów HTTP, jak i innych niż HTTP, gdy jest włączonych wiele powiązań lokacji przy użyciu tego ustawienia.

Aby uzyskać szczegółowe informacje i przykłady, zobacz Obsługa wielu powiązań witryny usług IIS i MultipleSiteBindingsEnabled.

Rozszerzanie adresowania w usługach WCF

Domyślny model adresowania usług WCF używa identyfikatora URI adresu punktu końcowego w następujących celach:

  • Aby określić adres nasłuchiwania usługi, lokalizacja, w której punkt końcowy nasłuchuje komunikatów,

  • Aby określić filtr adresu PROTOKOŁU SOAP, adres, który punkt końcowy oczekuje jako nagłówek protokołu SOAP.

Wartości dla każdego z tych celów można określić oddzielnie, umożliwiając kilka rozszerzeń adresowania obejmujących przydatne scenariusze:

  • Pośrednicy protokołu SOAP: komunikat wysyłany przez klienta przechodzi przez co najmniej jedną dodatkową usługę, która przetwarza komunikat przed dotarciem do jego końcowego miejsca docelowego. Pośrednicy protokołu SOAP mogą wykonywać różne zadania, takie jak buforowanie, routing, równoważenie obciążenia lub walidacja schematu w komunikatach. Ten scenariusz jest osiągany przez wysyłanie komunikatów do oddzielnego adresu fizycznego (via), który jest przeznaczony dla pośrednika, a nie tylko do adresu logicznego (wsa:To), który jest przeznaczony dla ostatecznego miejsca docelowego.

  • Adres nasłuchiwania punktu końcowego jest prywatnym identyfikatorem URI i jest ustawiony na inną wartość niż jego listenURI właściwość.

Adres transportu określony przez parametr via to lokalizacja, do której początkowo powinien zostać wysłany komunikat w drodze do innego adresu zdalnego określonego to przez parametr, w którym znajduje się usługa. W większości scenariuszy via internetowych identyfikator URI jest taki sam jak Uri właściwość końcowego to adresu usługi. Rozróżniasz tylko te dwa adresy, gdy należy wykonać routing ręczny.

Adresowanie nagłówków

Punkt końcowy można rozwiązać za pomocą co najmniej jednego nagłówka protokołu SOAP oprócz podstawowego identyfikatora URI. Jednym z zestawów scenariuszy, w których jest to przydatne, jest zestaw scenariuszy pośredniczących protokołu SOAP, w których punkt końcowy wymaga od klientów tego punktu końcowego dołączania nagłówków protokołu SOAP przeznaczonych dla pośredników.

Niestandardowe nagłówki adresów można definiować na dwa sposoby— przy użyciu kodu lub konfiguracji:

Konfiguracja jest ogólnie preferowana do kodu, ponieważ umożliwia zmianę nagłówków po wdrożeniu.

Niestandardowe adresy nasłuchiwania

Adres nasłuchiwania można ustawić na inną wartość niż identyfikator URI punktu końcowego. Jest to przydatne w scenariuszach pośredniczących, w których adres PROTOKOŁU SOAP, który ma być uwidoczniony, jest to, że publiczny pośrednik protokołu SOAP, natomiast adres, w którym punkt końcowy rzeczywiście nasłuchuje, jest adresem sieci prywatnej.

Niestandardowy adres nasłuchiwania można określić przy użyciu kodu lub konfiguracji:

  • W kodzie określ niestandardowy adres nasłuchiwania, dodając klasę ClientViaBehavior do kolekcji zachowań punktu końcowego.

  • W konfiguracji określ niestandardowy adres nasłuchiwania z ListenUri atrybutem elementu punktu końcowego> usługi<.

Niestandardowy filtr adresów SOAP

Element Uri jest używany w połączeniu z dowolną Headers właściwością, aby zdefiniować filtr adresu SOAP punktu końcowego (AddressFilter). Domyślnie ten filtr sprawdza, czy komunikat przychodzący ma To nagłówek komunikatu zgodny z identyfikatorem URI punktu końcowego i że wszystkie wymagane nagłówki punktu końcowego znajdują się w komunikacie.

W niektórych scenariuszach punkt końcowy odbiera wszystkie komunikaty odbierające podstawowy transport, a nie tylko te z odpowiednim To nagłówkiem. Aby to włączyć, użytkownik może użyć MatchAllMessageFilter klasy .

Zobacz też