ルーティングの概要

[アーティクル]
02/24/2011

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

このトピックでは、ルーティングサービスをご存じない方を対象としています。ここでは、ルーティングサービスの基本的な構成とホストについて説明します。

構成

ルーティングサービスは、1 つ以上のサービスエンドポイントを公開する WCF サービスとして実装されます。サービスエンドポイントは、クライアントアプリケーションからメッセージを受信し、受信したメッセージを 1 つ以上の送信先エンドポイントにルーティングします。ルーティングサービスには RoutingBehavior があります。これは、このサービスによって公開されるサービスエンドポイントに適用されます。この動作を使用して、サービスの稼働方法について詳細を構成します。構成ファイルを使用する場合に構成しやすいように、パラメーターを RoutingBehavior に指定します。コードベースのシナリオでは、これらのパラメーターを RoutingConfiguration オブジェクトの一部として指定し、このオブジェクトを RoutingBehavior に渡すことができます。

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

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

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

エンドポイントの定義

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

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

注 :
複数の通信パターン (一方向の操作と双方向の操作の混合など) を指定するコントラクトを使用している場合は、IDuplexSessionRouter など、二重のコントラクトをルーティングサービスで使用して対処します。ただし、この場合は、バインドが二重通信に対応可能である必要があり、シナリオによっては、それが可能でない場合もあります。対応が不可能なシナリオでは、複数のエンドポイントに通信をファクタリングするか、アプリケーションの変更が必要になる可能性があります。

複数の通信パターン (一方向の操作と双方向の操作の混合など) を指定するコントラクトを使用している場合は、IDuplexSessionRouter など、二重のコントラクトをルーティングサービスで使用して対処します。ただし、この場合は、バインドが二重通信に対応可能である必要があり、シナリオによっては、それが可能でない場合もあります。対応が不可能なシナリオでは、複数のエンドポイントに通信をファクタリングするか、アプリケーションの変更が必要になる可能性があります。

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

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

以下に、プログラムによる方法と構成ファイルを使用する方法の両方で、ルーティングサービスが使用するサービスおよびクライアントエンドポイントを定義する例を示します。

<services>
      <!--ROUTING SERVICE -->
      <service behaviorConfiguration="routingData"
               name="System.ServiceModel.Routing.RoutingService">
        <host>
          <baseAddresses>
            <add baseAddress="https://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="https://localhost:8000/servicemodelsamples/service"
                binding="wsHttpBinding" contract="*" />
    </client>

//set up some communication defaults
string clientAddress = "https://localhost:8000/servicemodelsamples/service";
string routerAddress = "https://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));

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

ルーティングロジック

メッセージのルーティングに使用されるルーティングロジックを定義するには、受信メッセージに含まれるデータのうち、一意に識別して処理できるものを特定する必要があります。たとえば、ルーティング先のすべてのエンドポイントが同じ SOAP アクションを共有する場合、メッセージに含まれる Action の値は、メッセージのルーティング先となる特定のエンドポイントを示す値としては不適切です。ある特定のエンドポイントにメッセージを一意にルーティングする必要がある場合は、メッセージのルーティング先エンドポイントを一意に識別できるデータを基に、フィルター処理を行います。

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

複数のメッセージフィルターをまとめて、フィルターテーブルで管理します。このテーブルで、各 MessageFilter と送信先エンドポイントが関連付けられます。または、フィルターテーブルを使用して、通信エラーが発生した場合に、ルーティングサービスがメッセージを送信するバックアップエンドポイントのリストを指定することもできます。

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

次の例では MatchAllMessageFilter を使用しています。これは、すべてのメッセージに対して true に評価されます。この 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);

注 :
既定でルーティングサービスによって評価されるのは、メッセージのヘッダーのみです。フィルターがメッセージ本文にアクセスできるようにするには、RouteOnHeadersOnly を false に設定します。

マルチキャスト

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

要求への応答時にクライアントアプリケーションが受信できるのは 1 つの応答のみであるため、チャネル形状が要求/応答でない (一方向または二重のどちらでもよい) ことが必要である。
複数のフィルターが、メッセージの評価時に true を返す必要がある。

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

<!--ROUTING SECTION -->
<routing>
  <filters>
    <filter name="MatchAllFilter1" filterType="MatchAll" />
    <filter name="RoundingFilter1" filterType="EndpointAddress"
            filterData="https://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(
    "https://localhost:8000/routingservice/router/rounding")),
    roundingCalcEndpointList);

SOAP 処理

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

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

要求の処理

送信バインドおよびチャネルの MessageVersion を取得します。
元のメッセージの本文のリーダーを取得します。
同じ操作、同じ本文のリーダーと、新しい MessageVersion を使用して新しいメッセージを作成します。
Addressing != Addressing.None の場合は、To、From、FaultTo、および RelatesTo の各ヘッダーを新しいメッセージにコピーします。
新しいメッセージにすべてのメッセージプロパティをコピーします。
応答の処理時に使用するために、元の要求メッセージを保存します。
新しい要求メッセージを返します。

応答の処理

元の要求メッセージの MessageVersion を取得します。
受信した応答メッセージの本文のリーダーを取得します。
同じ操作、同じ本文のリーダー、および、元の要求メッセージの MessageVersion を使用して、新しい応答メッセージを作します。
Addressing != Addressing.None の場合は、To、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 は、プログラムによってのみ変更できます。サービスの初期構成は構成ファイルで実行できますが、実行時に構成を変更する方法は、新しい RoutingConfigution を作成して、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 が発生した場合は、エラー処理が実行されます。これらの例外は、一般的に、EndpointNotFoundException、ServerTooBusyException、CommunicationObjectFaultedException など、定義されているクライアントエンドポイントとの通信を試みている間に問題が発生したことを示します。また、エラー処理コードは、TimeoutException が発生すると、それをキャッチして再送信を試みます。この例外も、CommunicationException から派生したのではない、一般的な例外です。

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

注 :
エラー処理機能は、メッセージの送信時とチャネルの終了時に発生した例外をキャプチャーし、処理します。エラー処理コードは、通信対象のアプリケーションエンドポイントによって作成された例外については、検出も処理も行いません。サービスからスローされた FaultException は、ルーティングサービスでは FaultMessage として扱われ、クライアントに戻されます。

エラー処理機能は、メッセージの送信時とチャネルの終了時に発生した例外をキャプチャーし、処理します。エラー処理コードは、通信対象のアプリケーションエンドポイントによって作成された例外については、検出も処理も行いません。サービスからスローされた FaultException は、ルーティングサービスでは FaultMessage として扱われ、クライアントに戻されます。

例外のトレース

メッセージをリスト内のエンドポイントに送信できなかった場合、ルーティングサービスは、生成された例外データをトレースして、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 doesn't respond (which the first endpoint won't
//since the client doesn't exist), the Routing Service automatically moves the message
//to the next endpoint in the list and try again.
rc.FilterTable.Add(new MatchAllMessageFilter(), backupList);

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

次の表に、バックアップエンドポイントリストを使用できるパターンと、各パターンのエラー処理の詳細な説明を示します。

パターン	サポートされるバックアップリスト	メモ
一方向	はい	バックアップエンドポイントでメッセージの再送を試みます。このメッセージがマルチキャストされる場合は、エラーが発生したチャネルのメッセージのみが、バックアップ先に移動されます。
一方向	いいえ	例外がスローされ、トランザクションがロールバックされます。
一方向	はい	バックアップエンドポイントでメッセージの再送を試みます。メッセージの受信が成功したら、すべての受信コンテキストを完了します。どのエンドポイントでもメッセージを受信できなかった場合は、受信コンテキストを完了しません。このメッセージがマルチキャストされる場合は、少なくとも 1 つのエンドポイント (プライマリでもバックアップでも) でメッセージが受信された場合にのみ、受信コンテキストが完了されます。どのマルチキャストパスのエンドポイントでもメッセージを受信できなかった場合は、受信コンテキストを完了しません。
一方向	はい	前のトランザクションを中止し、新しいトランザクションを作成して、すべてのメッセージを再送します。エラーが発生したメッセージは、バックアップ先に転送されます。すべての転送が成功するトランザクションが作成されたら、受信コンテキストを完了して、転送をコミットします。
一方向	はい	バックアップエンドポイントでメッセージの再送を試みます。マルチキャストセッションの場合は、エラーが発生したセッションまたはセッションを終了できなかったセッションのメッセージのみが、バックアップ先に送信されます。
一方向	いいえ	例外がスローされ、トランザクションがロールバックされます。
一方向	はい	バックアップエンドポイントでメッセージの再送を試みます。エラーが発生せずに、すべてのメッセージ送信が完了したら、セッションが他にメッセージがないことを通知して、ルーティングサービスがすべての送信セッションチャネルを終了します。また、受信コンテキストが完了し、受信セッションチャネルが終了します。
一方向	はい	現在のトランザクションを中止し、新しいトランザクションを作成します。セッションに含まれる、以前のメッセージをすべて再送します。すべてのメッセージ送信が成功したトランザクションが作成され、セッションが他にメッセージがないことを通知すると、すべての送信セッションチャネルが終了します。また、そのトランザクションのすべての受信コンテキストが完了し、受信セッションチャネルが終了して、トランザクションがコミットされます。セッションがマルチキャストされる場合は、エラーが発生していないメッセージが、前回と同じ送信先に再送され、エラーが発生したメッセージはバックアップ先に送信されます。
双方向	はい	バックアップ先に送信します。チャネルが応答メッセージを返した後に、元のクライアントに応答を返します。
双方向	はい	チャネルのすべてのメッセージをバックアップ先に送信します。チャネルが応答メッセージを返した後に、元のクライアントに応答を返します。
双方向	いいえ	例外がスローされ、トランザクションがロールバックされます。
双方向	いいえ	例外がスローされ、トランザクションがロールバックされます。
二重	いいえ	セッションのない二重通信は、現在サポートされていません。
二重	はい	バックアップ先に送信します。

ホスト

ルーティングサービスは 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" %>

参照

概念

メッセージフィルター
 ルーティングコントラクト
 フィルターの選択

次の方法で共有

ルーティングの概要

構成

エンドポイントの定義

ルーティングロジック

SOAP 処理

動的構成

エラー処理

例外のトレース

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

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

ホスト

参照

概念

その他のリソース

次の方法で共有

ルーティングの概要

構成

エンドポイントの定義

ルーティング ロジック

SOAP 処理

動的構成

エラー処理

例外のトレース

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

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

ホスト

参照

概念

その他のリソース

ルーティングロジック

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

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