Udostępnij przez

Adresy punktów końcowych

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 przewodzie jako referencja punktu końcowego WS-Addressing (EPR).

Struktura URI identyfikatora 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:

  • Maszyna: 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 WSDL

Adres punktu końcowego może być również reprezentowany w języku WSDL jako element WS-Addressing EPR 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 wielu łączeń IIS w ramach .NET Framework 3.5

Dostawcy usług internetowych często hostują wiele aplikacji na tym samym serwerze i na tej samej stronie, aby zwiększyć gęstość strony i obniżyć całkowity koszt utrzymania. 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ół wiążący definiuje schemat, za pomocą którego odbywa się komunikacja, a informacje wiążące to informacje używane do uzyskiwania dostępu do witryny.

W następującym przykładzie przedstawiono składniki, które mogą być obecne w powiązaniach 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 witryny, co powoduje wiele adresów bazowych dla każdego schematu. Przed wersją .NET Framework 3.5, WCF nie obsługiwał wielu adresów dla schematu i, jeśli zostały one określone, wyrzucał 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 skutkuje przekazaniem tylko tego adresu podstawowego, który pasuje do danego 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 bazowymi dla odpowiednich schematów, które są przekazywane.

Element baseAddressPrefixFilter nie obsługuje 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 wielu powiązań IIS w programie .NET Framework 4 lub nowszym

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

Poniżej przedstawiono przykład kodu konfiguracji, który korzysta z funkcji multipleSiteBindingsEnabled w <serviceHostingEnvironment>.

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

Wszystkie ustawienia baseAddressPrefixFilters są ignorowane zarówno dla protokołów HTTP, jak i innych, gdy funkcja wielu powiązań witryn jest aktywna 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, czyli miejsce, w którym punkt końcowy odbiera komunikaty,

  • 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 dla punktu dostępu jest prywatnym identyfikatorem URI i jest ustawiony na inną wartość niż jego listenURI parametr.

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 adresować przy użyciu jednego lub więcej nagłówków 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 bardziej zalecana od kodu, ponieważ umożliwia zmianę nagłówków po wdrożeniu.

Niestandardowe adresy do nasłuchiwania

Adres nasłuchiwania można ustawić na inną wartość niż identyfikator URI punktu końcowego. Jest to przydatne w scenariuszach pośrednich, w których adres protokołu SOAP, który ma być wystawiony, jest adresem publicznego pośrednika SOAP, podczas gdy adres, na którym punkt końcowy rzeczywiście nasłuchuje, jest adresem prywatnej sieci.

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, które dotarły na podkładzie transportowym, a nie tylko te z odpowiednim nagłówkiem To. Aby to włączyć, użytkownik może użyć MatchAllMessageFilter klasy .

Zobacz także

  • Last updated on