次の方法で共有


ルーティングの概要

ルーティング サービスは、メッセージの内容に基づいてメッセージをルーティングできる汎用のプラグ可能な SOAP 中継局を提供します。 ルーティング サービスを使用すると、サービス集約、サービスのバージョン管理、優先順位ルーティング、マルチキャスト ルーティングなどのシナリオを実装できる複雑なルーティング ロジックを作成できます。 ルーティング サービスには、プライマリ宛先エンドポイントへの送信時にエラーが発生した場合にメッセージが送信されるバックアップ エンドポイントの一覧を設定できるエラー処理も用意されています。

このトピックは、ルーティング サービスを初めて使用するユーザーを対象としており、ルーティング サービスの基本的な構成とホスティングについて説明します。

コンフィギュレーション

ルーティング サービスは、クライアント アプリケーションからメッセージを受信し、メッセージを 1 つ以上の宛先エンドポイントにルーティングする 1 つ以上のサービス エンドポイントを公開する WCF サービスとして実装されます。 サービスは、サービスによって公開されるサービス エンドポイントに適用される RoutingBehaviorを提供します。 この動作は、サービスの動作のさまざまな側面を構成するために使用されます。 構成ファイルを使用するときの構成を容易にするために、 RoutingBehavior でパラメーターを指定します。 コード ベースのシナリオでは、これらのパラメーターは RoutingConfiguration オブジェクトの一部として指定され、 RoutingBehavior に渡すことができます。

この動作を開始すると、メッセージの SOAP 処理を実行するために使用される SoapProcessingBehaviorがクライアント エンドポイントに追加されます。 これにより、ルーティング サービスは、メッセージが受信されたエンドポイントとは異なる MessageVersion を必要とするエンドポイントにメッセージを送信できます。 RoutingBehavior は、実行時にルーティング サービスの構成を変更するためのアクセシビリティ ポイントを提供するサービス拡張機能 (RoutingExtension) も登録します。

RoutingConfiguration クラスは、ルーティング サービスの構成を構成および更新するための一貫した手段を提供します。 これには、ルーティング サービスの設定として機能するパラメーターが含まれており、サービスの開始時に RoutingBehavior を構成するために使用されるか、実行時にルーティング構成を変更するために RoutingExtension に渡されます。

メッセージのコンテンツ ベースのルーティングを実行するために使用されるルーティング ロジックは、複数の MessageFilter オブジェクトをフィルター テーブル (MessageFilterTable<TFilterData> オブジェクト) にグループ化することによって定義されます。 受信メッセージは、フィルター テーブルに含まれるメッセージ フィルターに対して評価され、メッセージに一致する 各 MessageFilter が宛先エンドポイントに転送されます。 メッセージのルーティングに使用するフィルター テーブルは、 RoutingBehavior を構成で使用するか、 RoutingConfiguration オブジェクトを使用してコードを使用して指定します。

エンドポイントの定義

使用するルーティング ロジックを定義して構成を開始する必要があるようですが、最初の手順は、メッセージのルーティング先のエンドポイントの形状を実際に決定することです。 ルーティング サービスでは、メッセージの送受信に使用されるチャネルの形状を定義するコントラクトが使用されるため、入力チャネルの形状は出力チャネルの形状と一致する必要があります。 たとえば、要求/応答チャネル図形を使用するエンドポイントにルーティングする場合は、受信エンドポイントで互換性のあるコントラクト ( IRequestReplyRouterなど) を使用する必要があります。

つまり、宛先エンドポイントが複数の通信パターン (一方向と双方向の操作を混在させるなど) でコントラクトを使用する場合、メッセージを受信してすべてのエンドポイントにルーティングできる 1 つのサービス エンドポイントを作成することはできません。 互換性のある図形を持つエンドポイントを決定し、宛先エンドポイントにルーティングされるメッセージを受信するために使用される 1 つ以上のサービス エンドポイントを定義する必要があります。

複数の通信パターン (一方向と双方向の操作の組み合わせなど) を指定するコントラクトを使用する場合、回避策は、ルーティング サービスで双方向コントラクト ( IDuplexSessionRouter など) を使用することです。 ただし、これは、バインディングが双方向通信に対応している必要があることを意味します。これは、すべてのシナリオで不可能な場合があります。 これが不可能なシナリオでは、通信を複数のエンドポイントに組み込んだり、アプリケーションを変更したりする必要があります。

ルーティング コントラクトの詳細については、「 ルーティング コントラクト」を参照してください。

サービス エンドポイントが定義されたら、 RoutingBehavior を使用して、特定の RoutingConfiguration を エンドポイントに関連付けることができます。 構成ファイルを使用してルーティング サービスを構成する場合、 RoutingBehavior は、このエンドポイントで受信したメッセージを処理するために使用されるルーティング ロジックを含むフィルター テーブルを指定するために使用されます。 ルーティング サービスをプログラムで構成する場合は、 RoutingConfiguration を使用してフィルター テーブルを指定できます。

次の例では、ルーティング サービスによって使用されるサービスエンドポイントとクライアント エンドポイントを、プログラムと構成ファイルの両方で定義します。

<services>
  <!--ROUTING SERVICE -->
  <service behaviorConfiguration="routingData"
            name="System.ServiceModel.Routing.RoutingService">
    <host>
      <baseAddresses>
        <add baseAddress="http://localhost:8000/routingservice/router"/>
      </baseAddresses>
    </host>
    <!-- Define the service endpoints that are receive messages -->
    <endpoint address=""
              binding="wsHttpBinding"
              name="reqReplyEndpoint"
              contract="System.ServiceModel.Routing.IRequestReplyRouter" />
  </service>
</services>
<behaviors>
  <serviceBehaviors>
    <behavior name="routingData">
      <serviceMetadata httpGetEnabled="True"/>
      <!-- Add the RoutingBehavior and specify the Routing Table to use -->
      <routing filterTableName="routingTable1" />
    </behavior>
  </serviceBehaviors>
</behaviors>
<client>
<!-- Define the client endpoint(s) to route messages to -->
  <endpoint name="CalculatorService"
            address="http://localhost:8000/servicemodelsamples/service"
            binding="wsHttpBinding" contract="*" />
</client>
//set up some communication defaults
string clientAddress = "http://localhost:8000/servicemodelsamples/service";
string routerAddress = "http://localhost:8000/routingservice/router";
Binding routerBinding = new WSHttpBinding();
Binding clientBinding = new WSHttpBinding();
//add the endpoint the router uses to receive messages
serviceHost.AddServiceEndpoint(
     typeof(IRequestReplyRouter),
     routerBinding,
     routerAddress);
//create the client endpoint the router routes messages to
ContractDescription contract = ContractDescription.GetContract(
     typeof(IRequestReplyRouter));
ServiceEndpoint client = new ServiceEndpoint(
     contract,
     clientBinding,
     new EndpointAddress(clientAddress));
//create a new routing configuration object
RoutingConfiguration rc = new RoutingConfiguration();
….
rc.FilterTable.Add(new MatchAllMessageFilter(), endpointList);
//attach the behavior to the service host
serviceHost.Description.Behaviors.Add(
     new RoutingBehavior(rc));

この例では、ルーティング サービスを構成して、ルーティングするメッセージを受信するために使用される http://localhost:8000/routingservice/router のアドレスを持つ単一のエンドポイントを公開します。 メッセージは要求/応答エンドポイントにルーティングされるため、サービス エンドポイントは IRequestReplyRouter コントラクトを使用します。 この構成では、メッセージがルーティングされる http://localhost:8000/servicemodelsample/service の単一のクライアント エンドポイントも定義されます。 "routingTable1" という名前のフィルター テーブル (表示されていません) には、メッセージのルーティングに使用されるルーティング ロジックが含まれており、 RoutingBehavior (構成ファイルの場合) または RoutingConfiguration (プログラムによる構成の場合) を使用してサービス エンドポイントに関連付けられます。

ルーティング ロジック

メッセージのルーティングに使用するルーティング ロジックを定義するには、受信メッセージに含まれるデータを一意に処理できるかどうかを決定する必要があります。 たとえば、同じ SOAP アクションを共有するためにルーティングするすべての宛先エンドポイントがある場合、メッセージ内に含まれるアクションの値は、メッセージのルーティング先となる特定のエンドポイントを示す適切なインジケーターではありません。 メッセージを 1 つの特定のエンドポイントに一意にルーティングする必要がある場合は、メッセージのルーティング先エンドポイントを一意に識別するデータをフィルター処理する必要があります。

ルーティング サービスには、アドレス、アクション、エンドポイント名、XPath クエリなど、メッセージ内の特定の値を検査する MessageFilter 実装がいくつか用意されています。 これらの実装のいずれもニーズを満たさない場合は、カスタム MessageFilter 実装を作成できます。 メッセージ フィルターの詳細とルーティング サービスで使用される実装の比較については、「 メッセージ フィルターフィルターの選択」を参照してください。

複数のメッセージ フィルターがフィルター テーブルに編成され、各 MessageFilter が宛先エンドポイントに関連付けられます。 必要に応じて、フィルター テーブルを使用して、転送エラーが発生した場合にルーティング サービスがメッセージの送信を試みるバックアップ エンドポイントの一覧を指定することもできます。

既定では、フィルター テーブル内のすべてのメッセージ フィルターが同時に評価されます。ただし、メッセージ フィルターを特定の順序で評価する Priority を指定できます。 優先度が最も高いエントリはすべて最初に評価され、優先順位の低いメッセージ フィルターは、一致するエントリが優先度の高いレベルで見つかった場合は評価されません。 フィルター テーブルの詳細については、「 メッセージ フィルター」を参照してください。

次の例では、すべてのメッセージのtrueに評価されるMatchAllMessageFilterを使用します。 この MessageFilter が "routingTable1" フィルター テーブルに追加され、 MessageFilter が "CalculatorService" という名前のクライアント エンドポイントに関連付けられます。 次 に、RoutingBehavior は、このテーブルを使用して、サービス エンドポイントによって処理されるメッセージをルーティングするように指定します。

<behaviors>
  <serviceBehaviors>
    <behavior name="routingData">
      <serviceMetadata httpGetEnabled="True"/>
      <!-- Add the RoutingBehavior and specify the Routing Table to use -->
      <routing filterTableName="routingTable1" />
    </behavior>
  </serviceBehaviors>
</behaviors>
<!--ROUTING SECTION -->
<routing>
  <filters>
    <filter name="MatchAllFilter1" filterType="MatchAll" />
  </filters>
  <filterTables>
    <table name="routingTable1">
      <filters>
        <add filterName="MatchAllFilter1" endpointName="CalculatorService" />
      </filters>
    </table>
  </filterTables>
</routing>
//create a new routing configuration object
RoutingConfiguration rc = new RoutingConfiguration();
//create the endpoint list that contains the endpoints to route to
//in this case we have only one
List<ServiceEndpoint> endpointList = new List<ServiceEndpoint>();
endpointList.Add(client);
//add a MatchAll filter to the Router's filter table
//map it to the endpoint list defined earlier
//when a message matches this filter, it is sent to the endpoint contained in the list
rc.FilterTable.Add(new MatchAllMessageFilter(), endpointList);

既定では、ルーティング サービスはメッセージのヘッダーのみを評価します。 フィルターがメッセージ本文にアクセスできるようにするには、 RouteOnHeadersOnlyfalse に設定する必要があります。

マルチキャスト

多くのルーティング サービス構成では、1 つの特定のエンドポイントにのみメッセージをルーティングする排他フィルター ロジックが使用されますが、特定のメッセージを複数の宛先エンドポイントにルーティングすることが必要な場合があります。 メッセージを複数の宛先にマルチキャストするには、次の条件が満たされている必要があります。

  • 要求に対してクライアント アプリケーションが受信できる応答は 1 つだけであるため、チャネル図形は要求/応答 (一方向または二重の場合があります) にすることはできません。

  • 複数のフィルターは、メッセージを評価するときに true を返す必要があります。

これらの条件が満たされた場合、メッセージは、 trueに評価されるすべてのフィルターのすべてのエンドポイントにルーティングされます。 次の例では、メッセージ内のエンドポイント アドレスが http://localhost:8000/routingservice/router/rounding場合に両方のエンドポイントにメッセージがルーティングされるルーティング構成を定義します。

<!--ROUTING SECTION -->
<routing>
  <filters>
    <filter name="MatchAllFilter1" filterType="MatchAll" />
    <filter name="RoundingFilter1" filterType="EndpointAddress"
            filterData="http://localhost:8000/routingservice/router/rounding" />
  </filters>
  <filterTables>
    <table name="routingTable1">
      <filters>
        <add filterName="MatchAllFilter1" endpointName="CalculatorService" />
        <add filterName="RoundingFilter1" endpointName="RoundingCalcService" />
      </filters>
    </table>
  </filterTables>
</routing>
rc.FilterTable.Add(new MatchAllMessageFilter(), calculatorEndpointList);
rc.FilterTable.Add(new EndpointAddressMessageFilter(new EndpointAddress(
    "http://localhost:8000/routingservice/router/rounding")),
    roundingCalcEndpointList);

SOAP 処理

異なるプロトコル間のメッセージのルーティングをサポートするために、 RoutingBehavior は既定で、メッセージがルーティングされるすべてのクライアント エンドポイントに SoapProcessingBehavior を追加します。 この動作により、メッセージをエンドポイントにルーティングする前に新しい MessageVersion が自動的に作成され、要求元のクライアント アプリケーションに返される前に、応答ドキュメントに互換性のある MessageVersion が作成されます。

送信メッセージの新しい MessageVersion を作成する手順は次のとおりです。

要求処理

  • 送信バインディング/チャネルの MessageVersion を取得します。

  • 元のメッセージの本文リーダーを取得します。

  • 同じアクション、本文リーダー、および新しい MessageVersion を使用して、新しいメッセージを作成します。

  • != Addressing.NoneAddressing場合は、宛先、From、FaultTo、および RelatesTo ヘッダーを新しいメッセージにコピーします。

  • すべてのメッセージ プロパティを新しいメッセージにコピーします。

  • 応答の処理中に使用する元の要求メッセージを格納します。

  • 新しい要求メッセージを返します。

応答処理

  • 元の要求 メッセージの MessageVersion を取得します。

  • 受信した応答メッセージの本文リーダーを取得します。

  • 元の要求メッセージの同じアクション、本文リーダー、および MessageVersion を使用して、新しい応答メッセージを作成します。

  • != Addressing.NoneAddressing場合は、宛先、From、FaultTo、および RelatesTo ヘッダーを新しいメッセージにコピーします。

  • メッセージのプロパティを新しいメッセージにコピーします。

  • 新しい応答メッセージを返します。

既定では、 SoapProcessingBehavior は、サービスの開始時に RoutingBehavior によってクライアント エンドポイントに自動的に追加されます。ただし、 SoapProcessingEnabled プロパティを使用して、すべてのクライアント エンドポイントに SOAP 処理を追加するかどうかを制御できます。 また、特定のエンドポイントに直接動作を追加し、SOAP 処理をより細かく制御する必要がある場合は、エンドポイント レベルでこの動作を有効または無効にすることもできます。

元の要求メッセージとは異なる MessageVersion を必要とするエンドポイントに対して SOAP 処理が無効になっている場合は、メッセージを送信先エンドポイントに送信する前に必要な SOAP 変更を実行するためのカスタム メカニズムを提供する必要があります。

次の例では、 soapProcessingEnabled プロパティを使用して、 SoapProcessingBehavior がすべてのクライアント エンドポイントに自動的に追加されないようにします。

<behaviors>
  <!--default routing service behavior definition-->
  <serviceBehaviors>
    <behavior name="routingConfiguration">
      <routing filterTableName="filterTable1" soapProcessingEnabled="false"/>
    </behavior>
  </serviceBehaviors>
</behaviors>
//create the default RoutingConfiguration
RoutingConfiguration rc = new RoutingConfiguration();
rc.SoapProcessingEnabled = false;

動的構成

クライアント エンドポイントを追加する場合、またはメッセージのルーティングに使用するフィルターを変更する必要がある場合は、ルーティング サービスを介して現在メッセージを受信しているエンドポイントへのサービスの中断を防ぐために、実行時に構成を動的に更新する方法が必要です。 どちらの方法でもアプリケーションをリサイクルする必要があるため、構成ファイルまたはホスト アプリケーションのコードを変更するだけでは不十分です。これは、現在転送中のメッセージが失われる可能性があり、サービスの再起動を待機している間にダウンタイムが発生する可能性があるためです。

RoutingConfiguration はプログラムでのみ変更できます。 構成ファイルを使用してサービスを最初に構成することはできますが、実行時に構成を変更するには、新しい RoutingConfiguration を構築し、RoutingExtension サービス拡張機能によって公開されるApplyConfiguration メソッドにパラメーターとして渡す必要があります。 現在転送中のメッセージは引き続き以前の構成を使用してルーティングされますが、 ApplyConfiguration の呼び出し後に受信したメッセージは新しい構成を使用します。 次の例では、ルーティング サービスのインスタンスを作成し、その後構成を変更する方法を示します。

RoutingConfiguration routingConfig = new RoutingConfiguration();
routingConfig.RouteOnHeadersOnly = true;
routingConfig.FilterTable.Add(new MatchAllMessageFilter(), endpointList);
RoutingBehavior routing = new RoutingBehavior(routingConfig);
routerHost.Description.Behaviors.Add(routing);
routerHost.Open();
// Construct a new RoutingConfiguration
RoutingConfiguration rc2 = new RoutingConfiguration();
ServiceEndpoint clientEndpoint = new ServiceEndpoint();
ServiceEndpoint clientEndpoint2 = new ServiceEndpoint();
// Add filters to the FilterTable in the new configuration
rc2.FilterTable.add(new MatchAllMessageFilter(),
       new List<ServiceEndpoint>() { clientEndpoint });
rc2.FilterTable.add(new MatchAllMessageFilter(),
       new List<ServiceEndpoint>() { clientEndpoint2 });
rc2.RouteOnHeadersOnly = false;
// Apply the new configuration to the Routing Service hosted in
routerHost.routerHost.Extensions.Find<RoutingExtension>().ApplyConfiguration(rc2);

この方法でルーティング サービスを更新する場合は、新しい構成のみを渡すことができます。 現在の構成の選択要素のみを変更したり、現在の構成に新しいエントリを追加したりすることはできません。既存の構成を置き換える新しい構成を作成して渡す必要があります。

前の構成を使用して開かれたセッションはすべて、前の構成を引き続き使用します。 新しい構成は、新しいセッションでのみ使用されます。

エラー処理

メッセージの送信中に CommunicationException が発生した場合は、エラー処理が行われます。 これらの例外は、通常、定義されたクライアント エンドポイント ( EndpointNotFoundExceptionServerTooBusyExceptionCommunicationObjectFaultedExceptionなど) との通信を試みている間に問題が発生したことを示します。 また、エラー処理コードは、 TimeoutException が発生したときに送信をキャッチして再試行しようとします。これは、 CommunicationException から派生しないもう 1 つの一般的な例外です。

上記のいずれかの例外が発生すると、ルーティング サービスはバックアップ エンドポイントの一覧にフェールオーバーします。 すべてのバックアップ エンドポイントが通信エラーで失敗した場合、またはエンドポイントが宛先サービス内の障害を示す例外を返した場合、ルーティング サービスはクライアント アプリケーションにエラーを返します。

エラー処理機能は、メッセージを送信しようとしたとき、およびチャネルを閉じようとしたときに発生する例外をキャプチャして処理します。 エラー処理コードは、通信しているアプリケーション エンドポイントによって作成された例外を検出または処理するためのものではありません。サービスによってスローされた FaultException は、ルーティング サービスに FaultMessage として表示され、クライアントに返されます。

ルーティング サービスがメッセージを中継しようとしたときにエラーが発生した場合は、ルーティング サービスがない場合に通常発生するEndpointNotFoundExceptionではなく、クライアント側でFaultExceptionが発生する可能性があります。 したがって、ルーティング サービスは例外をマスクし、入れ子になった例外を調べない限り、完全な透過性を提供しない可能性があります。

例外のトレース

リスト内のエンドポイントにメッセージを送信できない場合、ルーティング サービスは結果の例外データをトレースし、例外の詳細を Exceptions という名前のメッセージ プロパティとして添付します。 これにより、例外データが保持され、ユーザーがメッセージ インスペクターを介してプログラムでアクセスできるようになります。 例外データは、メッセージを送信しようとしたときに検出された例外の詳細にエンドポイント名をマップするディクショナリ内のメッセージごとに格納されます。

バックアップ エンドポイント

フィルター テーブル内の各フィルター エントリでは、必要に応じてバックアップ エンドポイントの一覧を指定できます。バックアップ エンドポイントは、プライマリ エンドポイントへの送信時に伝送エラーが発生した場合に使用されます。 このようなエラーが発生した場合、ルーティング サービスは、バックアップ エンドポイントリストの最初のエントリにメッセージを送信しようとします。 この送信試行でも送信エラーが発生した場合は、バックアップ リスト内の次のエンドポイントが試行されます。 ルーティング サービスは、メッセージが正常に受信されるか、すべてのエンドポイントが送信エラーを返すか、エンドポイントから非送信エラーが返されるまで、一覧の各エンドポイントにメッセージを送信し続けます。

次の例では、バックアップ リストを使用するようにルーティング サービスを構成します。

<routing>
  <filters>
    <!-- Create a MatchAll filter that catches all messages -->
    <filter name="MatchAllFilter1" filterType="MatchAll" />
  </filters>
  <filterTables>
    <!-- Set up the Routing Service's Message Filter Table -->
    <filterTable name="filterTable1">
        <!-- Add an entry that maps the MatchAllMessageFilter to the dead destination -->
        <!-- If that endpoint is down, tell the Routing Service to try the endpoints -->
        <!-- Listed in the backupEndpointList -->
        <add filterName="MatchAllFilter1" endpointName="deadDestination" backupList="backupEndpointList"/>
    </filterTable>
  </filterTables>
  <!-- Create the backup endpoint list -->
  <backupLists>
    <!-- Add an endpoint list that contains the backup destinations -->
    <backupList name="backupEndpointList">
      <add endpointName="realDestination" />
      <add endpointName="backupDestination" />
    </backupList>
  </backupLists>
</routing>
//create the endpoint list that contains the service endpoints we want to route to
List<ServiceEndpoint> backupList = new List<ServiceEndpoint>();
//add the endpoints in the order that the Routing Service should contact them
//first add the endpoint that we know is down
//clearly, normally you wouldn't know that this endpoint was down by default
backupList.Add(fakeDestination);
//then add the real Destination endpoint
//the Routing Service attempts to send to this endpoint only if it
//encounters a TimeOutException or CommunicationException when sending
//to the previous endpoint in the list.
backupList.Add(realDestination);
//add the backupDestination endpoint
//the Routing Service attempts to send to this endpoint only if it
//encounters a TimeOutException or CommunicationsException when sending
//to the previous endpoints in the list
backupList.Add(backupDestination);
//create the default RoutingConfiguration option
RoutingConfiguration rc = new RoutingConfiguration();
//add a MatchAll filter to the Routing Configuration's filter table
//map it to the list of endpoints defined above
//when a message matches this filter, it is sent to the endpoints in the list in order
//if an endpoint is down or does not respond (which the first endpoint won't
//since the client does not exist), the Routing Service automatically moves the message
//to the next endpoint in the list and try again.
rc.FilterTable.Add(new MatchAllMessageFilter(), backupList);

サポートされているエラー パターン

次の表では、バックアップ エンドポイント リストの使用と互換性のあるパターンと、特定のパターンのエラー処理の詳細を説明するメモについて説明します。

パターン セッション トランザクション 受信コンテキスト サポートされているバックアップ リスト 注記
One-Way イエス バックアップ エンドポイントでメッセージの再送信を試みます。 このメッセージがマルチキャストの場合、失敗したチャネルのメッセージのみがバックアップ先に移動されます。
One-Way ✔️ いいえ 例外がスローされ、トランザクションがロールバックされます。
One-Way ✔️ イエス バックアップ エンドポイントでメッセージの再送信を試みます。 メッセージが正常に受信されたら、すべての受信コンテキストを完了します。 メッセージがエンドポイントによって正常に受信されない場合は、受信コンテキストを完了しないでください。

このメッセージがマルチキャストの場合、受信コンテキストは、メッセージが少なくとも 1 つのエンドポイント (プライマリまたはバックアップ) によって正常に受信された場合にのみ完了します。 マルチキャスト パス内のどのエンドポイントもメッセージを正常に受信しない場合は、受信コンテキストを完了しないでください。
One-Way ✔️ ✔️ イエス 前のトランザクションを中止し、新しいトランザクションを作成し、すべてのメッセージを再送信します。 エラーが発生したメッセージは、バックアップ先に送信されます。

すべての転送が成功するトランザクションが作成されたら、受信コンテキストを完了し、トランザクションをコミットします。
One-Way ✔️ イエス バックアップ エンドポイントでメッセージの再送信を試みます。 マルチキャスト シナリオでは、エラーが発生したセッションまたはセッションの終了が失敗したセッション内のメッセージのみがバックアップ先に再送信されます。
One-Way ✔️ ✔️ いいえ 例外がスローされ、トランザクションがロールバックされます。
One-Way ✔️ ✔️ イエス バックアップ エンドポイントでメッセージの再送信を試みます。 すべてのメッセージ送信がエラーなしで完了すると、セッションはそれ以上メッセージがないことを示し、ルーティング サービスはすべての送信セッション チャネルを正常に閉じ、すべての受信コンテキストが完了し、受信セッション チャネルが閉じられます。
One-Way ✔️ ✔️ ✔️ イエス 現在のトランザクションを中止し、新しいトランザクションを作成します。 セッション内の以前のすべてのメッセージを再送信します。 すべてのメッセージが正常に送信され、セッションがそれ以上メッセージを示さないトランザクションが作成されると、すべての送信セッション チャネルが閉じられ、受信コンテキストがすべてトランザクションで完了し、受信セッション チャネルが閉じられ、トランザクションがコミットされます。

セッションがマルチキャストされている場合、エラーのないメッセージは以前と同じ宛先に再送信され、エラーが発生したメッセージはバックアップ先に送信されます。
Two-Way イエス バックアップ先に送信します。 チャネルが応答メッセージを返した後、元のクライアントに応答を返します。
Two-Way ✔️ イエス チャネル上のすべてのメッセージをバックアップ先に送信します。 チャネルが応答メッセージを返した後、元のクライアントに応答を返します。
Two-Way ✔️ いいえ 例外がスローされ、トランザクションがロールバックされます。
Two-Way ✔️ ✔️ いいえ 例外がスローされ、トランザクションがロールバックされます。
二連式 いいえ 非セッション双方向通信は現在サポートされていません。
二連式 ✔️ イエス バックアップ先に送信します。

ホスティング

ルーティング サービスは WCF サービスとして実装されるため、アプリケーション内でセルフホステッドするか、IIS または WAS によってホストされている必要があります。 これらのホスティング環境で使用できる自動開始およびライフサイクル管理機能を利用するには、ルーティング サービスを IIS、WAS、または Windows サービス アプリケーションでホストすることをお勧めします。

次の例は、アプリケーションでルーティング サービスをホストする方法を示しています。

using (ServiceHost serviceHost =
                new ServiceHost(typeof(RoutingService)))

IIS または WAS 内でルーティング サービスをホストするには、サービス ファイル (.svc) を作成するか、サービスの構成ベースのアクティブ化を使用する必要があります。 サービス ファイルを使用する場合は、Service パラメーターを使用して RoutingService を指定する必要があります。 次の例には、IIS または WAS を使用してルーティング サービスをホストするために使用できるサンプル サービス ファイルが含まれています。

<%@ ServiceHost Language="C#" Debug="true" Service="System.ServiceModel.Routing.RoutingService,
     System.ServiceModel.Routing, version=4.0.0.0, Culture=neutral,
     PublicKeyToken=31bf3856ad364e35" %>

ルーティング サービスと偽装

WCF ルーティング サービスは、メッセージの送受信の両方で偽装と共に使用できます。 偽装の通常の Windows 制約がすべて適用されます。 独自のサービスを作成するときに偽装を使用するようにサービスまたはアカウントのアクセス許可を設定する必要がある場合は、ルーティング サービスで偽装を使用するために同じ手順を実行する必要があります。 詳細については、「委任と偽装」を参照してください。

ルーティング サービスでの偽装には、互換性モードで ASP.NET 偽装を使用するか、偽装を許可するように構成された Windows 資格情報を使用 ASP.NET 必要があります。 ASP.NET 互換モードの詳細については、「 WCF サービスと ASP.NET」を参照してください。

Warnung

WCF ルーティング サービスでは、基本認証による偽装はサポートされていません。

ルーティング サービス ASP.NET 偽装を使用するには、サービス ホスティング環境で ASP.NET 互換モードを有効にします。 ルーティング サービスは既に互換性モード ASP.NET 許可としてマークされており、偽装は自動的に有効になります。 偽装は、ルーティング サービスとの統合 ASP.NET サポートされている唯一の使用です。

ルーティング サービスで Windows 資格情報の偽装を使用するには、資格情報とサービスの両方を構成する必要があります。 クライアント資格情報オブジェクト (ChannelFactoryからアクセスできるWindowsClientCredential) は、偽装を許可するように設定する必要があるAllowedImpersonationLevel プロパティを定義します。 最後に、サービスで、ImpersonateCallerForAllOperationstrue に設定するようにServiceAuthorizationBehavior動作を構成する必要があります。 ルーティング サービスでは、このフラグを使用して、偽装が有効になっているメッセージを転送するためのクライアントを作成するかどうかを決定します。

こちらも参照ください