エンドポイントアドレス

すべてのエンドポイントには、エンドポイントを特定して識別するために使用されるアドレスが関連付けられています。このアドレスは、主にエンドポイントの場所を指定する URI (Uniform Resource Identifier) で構成されます。エンドポイントアドレスは、 EndpointAddress クラスによって Windows Communication Foundation (WCF) プログラミングモデルで表されます。このクラスには、メッセージを交換する他のエンドポイントによるエンドポイントの認証を可能にするオプションの Identity プロパティと、サービスに到達するために必要なその他の SOAP ヘッダーを定義するオプションの Headers プロパティのセットが含まれています。オプションのヘッダーは、サービスエンドポイントを識別または操作するための追加の詳細なアドレス指定情報を提供します。エンドポイントのアドレスは、WS-Addressing エンドポイント参照 (EPR) としてネットワーク上で表されます。

アドレスの URI 構造

ほとんどのトランスポートのアドレス URI には 4 つの部分があります。たとえば、URI http://www.fabrikam.com:322/mathservice.svc/secureEndpoint の 4 つの部分を次のように項目化できます。

スキーム： http:
マシン: www.fabrikam.com
(省略可能)ポート: 322
パス : /mathservice.svc/secureEndpoint

サービスのアドレスの定義

サービスのエンドポイントアドレスは、コードを使用して命令的に指定することも、構成を通じて宣言によって指定することもできます。通常、コードでのエンドポイントの定義は実用的ではありません。デプロイされたサービスのバインドとアドレスは、通常、サービスの開発中に使用されるものとは異なるためです。一般に、コードではなく構成を使用してサービスエンドポイントを定義する方が実用的です。バインディングとアドレス指定の情報をコードから除外すると、アプリケーションを再コンパイルまたは再デプロイしなくても変更できます。

構成でのアドレスの定義

構成ファイルでエンドポイントを定義するには、 <endpoint> 要素を使用します。詳細と例については、「エンドポイントアドレスの指定」を参照してください。

コードでのアドレスの定義

エンドポイントアドレスは、 EndpointAddress クラスを使用してコード内に作成できます。詳細と例については、「エンドポイントアドレスの指定」を参照してください。

WSDL のエンドポイント

エンドポイントアドレスは、対応するエンドポイントの wsdl:port 要素内の WS-Addressing EPR 要素として WSDL で表すこともできます。 EPR には、エンドポイントのアドレスと任意のアドレスプロパティが含まれます。詳細と例については、「エンドポイントアドレスの指定」を参照してください。

.NET Framework 3.5 での複数の IIS バインドのサポート

多くの場合、インターネットサービスプロバイダーは、サイト密度を高め、総保有コストを削減するために、同じサーバーとサイトで多くのアプリケーションをホストします。通常、これらのアプリケーションは異なるベースアドレスにバインドされます。インターネットインフォメーションサービス (IIS) Web サイトには、複数のアプリケーションを含めることができます。サイト内のアプリケーションには、1 つ以上の IIS バインドを使用してアクセスできます。

IIS バインディングには、バインディングプロトコルとバインディング情報という 2 つの情報が用意されています。バインディングプロトコルは通信を行うスキームを定義し、バインディング情報はサイトへのアクセスに使用される情報です。

次の例は、IIS バインドに存在できるコンポーネントを示しています。

バインドプロトコル: HTTP
バインディング情報: IP アドレス、ポート、ホストヘッダー

IIS では、各サイトに複数のバインドを指定できます。その結果、スキームごとに複数のベースアドレスが作成されます。 .NET Framework 3.5 より前では、WCF はスキーマに対して複数のアドレスをサポートしておらず、指定されている場合は、アクティブ化中に ArgumentException をスローしていました。

.NET Framework 3.5 を使用すると、インターネットサービスプロバイダーは、同じサイト上の同じスキームに対して異なるベースアドレスを持つ複数のアプリケーションをホストできます。

たとえば、サイトには次のベースアドレスが含まれる場合があります。

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

.NET Framework 3.5 では、構成ファイルの AppDomain レベルでプレフィックスフィルターを指定します。これは、プレフィックスの一覧を含む <baseAddressPrefixFilters> 要素を使用して行います。 IIS によって提供される受信ベースアドレスは、オプションのプレフィックスリストに基づいてフィルター処理されます。既定では、プレフィックスが指定されていない場合、すべてのアドレスがパススルーされます。プレフィックスを指定すると、そのスキームの一致するベースアドレスのみがパススルーされます。

プレフィックスフィルターを使用する構成コードの例を次に示します。

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

前の例では、 net.tcp://payroll.myorg.com:8000 と http://shipping.myorg.com:8000 が、それぞれのスキームの唯一のベースアドレスであり、渡されます。

baseAddressPrefixFilterはワイルドカードをサポートしていません。

IIS によって提供されるベースアドレスには、一覧に存在しない他のスキームにバインドされたアドレス baseAddressPrefixFilters 含まれる場合があります。これらのアドレスは除外されません。

.NET Framework 4 以降での IIS バインディングの複数サポート

.NET 4 以降では、1 つのベースアドレスを選択しなくても、IIS で複数のバインドのサポートを有効にできます。そのためには、 ServiceHostingEnvironmentの MultipleSiteBindingsEnabled 設定を true に設定します。このサポートは、HTTP プロトコルスキームに限定されます。

次に、<serviceHostingEnvironment> で multipleSiteBindingsEnabled を使用する構成コードの例を示します。

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

この設定を使用して複数のサイトバインドが有効になっている場合、HTTP プロトコルと非 HTTP プロトコルの両方で baseAddressPrefixFilters 設定は無視されます。

詳細と例については、「複数の MultipleSiteBindingsEnabled」を参照してください。

WCF サービスでのアドレス指定の拡張

WCF サービスの既定のアドレス指定モデルでは、次の目的でエンドポイントアドレス URI が使用されます。

サービスのリッスンアドレス、エンドポイントがメッセージをリッスンする場所を指定するには、
SOAP アドレスフィルターを指定するために、エンドポイントが SOAP ヘッダーとして想定するアドレス。

これらの各目的の値を個別に指定できるため、便利なシナリオに対応するアドレス指定のいくつかの拡張機能を使用できます。

SOAP 中継局: クライアントによって送信されたメッセージは、最終的な宛先に到達する前にメッセージを処理する 1 つ以上の追加サービスを走査します。 SOAP 中継局は、メッセージのキャッシュ、ルーティング、負荷分散、スキーマ検証など、さまざまなタスクを実行できます。このシナリオは、最終的な宛先をターゲットとする論理アドレス (via) だけでなく、中継局を対象とする別の物理アドレス (wsa:To) にメッセージを送信することによって実現されます。
エンドポイントのリッスンアドレスはプライベート URI であり、 listenURI プロパティとは異なる値に設定されます。

viaが指定するトランスポートアドレスは、サービスが配置されている to パラメーターで指定された他のリモートアドレスにメッセージを最初に送信する場所です。ほとんどのインターネットシナリオでは、via URI は、サービスの最終的なUri アドレスのto プロパティと同じです。手動ルーティングを行う必要がある場合にのみ、これら 2 つのアドレスを区別します。

ヘッダーのアドレス指定

エンドポイントは、基本 URI に加えて、1 つ以上の SOAP ヘッダーでアドレス指定できます。これが役立つシナリオの 1 つのセットは、エンドポイントがそのエンドポイントのクライアントに中継局を対象とする SOAP ヘッダーを含める必要がある SOAP 中間シナリオのセットです。

コードまたは構成を使用して、2 つの方法でカスタムアドレスヘッダーを定義できます。

コードでは、 AddressHeader クラスを使用してカスタムアドレスヘッダーを作成し、 EndpointAddressの構築で使用します。
構成では、カスタム <ヘッダー>は、<endpoint> 要素の子として指定されます。

一般に、デプロイ後にヘッダーを変更できるため、構成はコード化することをお勧めします。

カスタム受信アドレス

リッスンアドレスは、エンドポイントの URI とは異なる値に設定できます。これは、公開される SOAP アドレスがパブリック SOAP 中継局の場合の中間シナリオで役立ちます。一方、エンドポイントが実際にリッスンするアドレスはプライベートネットワークアドレスです。

カスタムリッスンアドレスは、コードまたは構成を使用して指定できます。

コードで、エンドポイントの動作コレクションに ClientViaBehavior クラスを追加して、カスタムリッスンアドレスを指定します。
構成で、service > 要素の属性を持つカスタムリッスンアドレスを指定します。

カスタム SOAP アドレスフィルター

Uriは、エンドポイントの SOAP アドレスフィルター (Headers) を定義するために、任意のAddressFilter プロパティと組み合わせて使用されます。既定では、このフィルターは、受信メッセージにエンドポイントの URI と一致する To メッセージヘッダーがあり、必要なすべてのエンドポイントヘッダーがメッセージに存在することを確認します。

一部のシナリオでは、エンドポイントは、適切な To ヘッダーを持つメッセージだけでなく、基になるトランスポートに到着するすべてのメッセージを受信します。これを有効にするには、ユーザーは MatchAllMessageFilter クラスを使用できます。

こちらも参照ください

Last updated on 2025-06-19