サービスステーション : WCF ルーターを構築する (第 2 部)

サービスステーション

WCF ルーターを構築する (第 2 部)

Michele Leroux Bustamante

コードのダウンロード : ServiceStation2008_06.exe (340 KB)
オンラインでのコードの参照

パススルールーターのシナリオ
Action ヘッダーによる転送
カスタムヘッダーを使用した転送
サービスを登録する
メッセージを検査する
ルーターとトランスポートセッション
二重ルーター
混在トランスポートセッション

2008 年 4 月号のサービスステーションでは、呼び出し元のクライアントとターゲットサービスとの間でメッセージが透過的に流れるようにする単純なルーターの作成方法を示しました。そこでは、Windows® Communication Foundation (WCF) のアドレス指定とメッセージフィルタに関する重要なセマンティクスについて確認し、型指定のないメッセージを処理するルーターコントラクトの設計方法を学習し、メッセージがルーターで変更されずに通過できるようにするバインドおよび動作の構成方法を学習しました。今回の記事では、議論の続きとして、より実際的なシナリオをルーターに採用する場合に問題となる、実装の詳細についてより詳しく見ていきます。

パススルールーターのシナリオ

第 1 部で述べたように、クライアントとサービスの間にパススルールーターを挿入した場合、クライアントはルーターとの間にではなくターゲットサービスとの間に関係を結ぶことになります。メッセージは確かに、ルーターが理解できるトランスポートプロトコルとメッセージエンコーダを使用して送信する必要がありますが、メッセージの内容全体 (たとえば、セキュリティヘッダーおよび信頼できるセッションを含む) をルーターでは処理しません。パススルールーターが適用する可能性のあるわずかな処理としては、負荷分散、コンテンツベースのルーティング、メッセージ変換などがあります。

サーバーリソース間での負荷分散および作業の分配には、ネットワーク負荷分散 (NLB) が有効であり、またはハードウェア負荷分散デバイスを用いるとさらに効果的です。それでも、そのような機能を持たない環境でサーバーをホストしている場合や、直接制御できない物理インターフェイスにサービスがインストールされている場合、またはドメイン固有のロジックに基づいたルーティングが必要な場合や、アプリケーションが単純に、構成の簡単な軽量のルーティングソリューションを必要としている場合などには、WCF ルーターを負荷分散に利用できます。そのような WCF ルーターを使用することで、同じマシン上の複数のプロセスや、マシン間で分散された複数のプロセスでホストされているサービスに対して、メッセージを配信できます。

使用する分散モデルに関係なく、負荷分散ルーターには必ずいくつかの中核機能が必要となります。サービスを負荷分散に含めるには、そのサービスを何らかの方法でルーターに登録する必要があります。ルーターは、正しくメッセージを転送するために、サービスの種類および関連付けられたエンドポイントを決定できる必要があります。また、ルーターには、古典的なラウンドロビンアプローチや、何らかの形式の優先度ベースのルーティングなど、負荷を分散するためのアルゴリズムが必要です。

負荷分散とは対照的に、サービス間のメッセージ配信がメッセージの内容に基づいて処理される場合もあります。一般に、コンテンツベースのルーターは、メッセージヘッダーまたはメッセージ本文を検査してルーティング情報を取得します。たとえば、有効なライセンスキーを持つクライアントからのメッセージは、高い処理能力を持つサーバーマシンの大きなプールに、高い優先度で転送されますが、試用ライセンスによるメッセージは、能力の比較的低いサーバーの小さなプールに転送されます。このシナリオでは、ルーターはメッセージの転送先を知る必要があるだけでなく、転送先を決定する前に各メッセージとそのヘッダーまたは本文の内容を検査する能力を持つ必要があります。以降のセクションでは、これらのシナリオをサポートする関連ルーティング機能を説明します。

Action ヘッダーによる転送

ルーターで受信されたメッセージには、メッセージを正しいサービスに転送するために利用できる 2 つのアドレス指定ヘッダーがあります。

To: このヘッダーは、エンドポイントの名前を示します。このヘッダーがターゲットサービスと一致し、ルーターと一致しない場合は、メッセージの宛先であるサービスエンドポイントの URL を示しています。

Action: このヘッダーは、メッセージの目的であるサービス操作を示しますが、必ずしも有効な URL 自体を表すものではありません。

ただし、多くの場合、To ヘッダーはルーターアドレスと一致してサービスとは一致せず、Action ヘッダーがメッセージの正しい宛先に関するより信頼できる情報源となります。Action ヘッダーは、サービスコントラクトの名前空間、サービスコントラクト名、および操作名から派生されることを思い出してください。これは、コントラクトが異なる種類のサービス間で共有されていないと仮定した場合、ルーターがターゲットサービスを一意に識別するために十分な情報となります。次に示すサービスコントラクトが、それぞれ異なる種類のサービスに実装されていると考えてください。

[ServiceContract(Namespace = 
"http://www.thatindigogirl.com/samples/2008/01")]
public interface IServiceA {
  [OperationContract]
  string SendMessage(string msg);
}
[ServiceContract(Namespace = 
  "http://www.thatindigogirl.com/samples/2008/01")]
public interface IServiceB {
  [OperationContract]
  string SendMessage(string msg);
}
public class ServiceA : IServiceA {...}
public class ServiceB : IServiceB{...}

図 1 に示されるように、ルーターは、各サービスコントラクトのコントラクト名前空間とメッセージの宛先であるサービスエンドポイントとの間のマッピングを利用できます。

図 1 コントラクト名前空間をサービスエンドポイントにマッピングする (クリックすると拡大画像が表示されます)

次のコードに示す辞書は、各コントラクト名前空間エントリと、使用する正しいチャネル構成設定を示す構成要素との間で、マッピングを行うよう初期化されています。

static public IDictionary<string, string> RegistrationList = 
  new Dictionary<string, string>();

RegistrationList.Add(
  "http://www.thatindigogirl.com/samples/2008/01/IServiceA", 
  "ServiceA");
RegistrationList.Add(
  "http://www.thatindigogirl.com/samples/2008/01/IServiceB", 
  "ServiceB");

チャネルを初期化するコードは、次のようになります。

string contractNamespace = 
  requestMessage.Headers.Action.Substring(0, 
  requestMessage.Headers.Action.LastIndexOf("/"));

string configurationName = 
  RouterService.RegistrationList[contractNamespace];

using (ChannelFactory<IRouterService> factory = 
  new ChannelFactory<IRouterService>(configurationName))
{...}

このシナリオには、注意を要する重要な設計上の依存事項がいくつかあります。

構成を単純にし、複数のルーターインスタンスをサポートするために、ほとんどの場合、コントラクトからサービスへのマッピングはデータベース内に保持されます。
コントラクトを実装するすべてのサービスでメッセージを処理できる場合を除き、サービスコントラクトを複数の種類のサービスに実装することはできません。
サーバーファーム内にサービスのインスタンスが複数ある場合、各エンドポイントに対する構成は、物理的なロードバランサが後で適切に分散できるような仮想アドレスにマッピングされる必要があります。
アプリケーションサービス用以外のアクションヘッダーを含むメッセージはサポートされません。

この最後の点は重要です。なぜなら、アプリケーションサービスに対して安全なセッションや信頼できるセッションが有効になっている場合、実際のアプリケーションサービスメッセージの前に、これらのセッションを確立するために追加のメッセージが送信されるためです。これらのメッセージは、それぞれのプロトコルに対して Action ヘッダーを使用し、アプリケーションサービスとは完全に独立しています。これは、メッセージの転送に、Action ヘッダーの代替手段を使用する必要があることを意味します。

カスタムヘッダーを使用した転送

クライアントが通信しようとするアプリケーションサービスを適切に示すルーティングヘッダーがすべてのメッセージに確実に含まれるようにするため、次に示すように、アプリケーションサービスのエンドポイント構成セクションにカスタムヘッダーを指定できます。

<service behaviorConfiguration="serviceBehavior" 
  name="MessageManager.ServiceA">
  <endpoint address="http://localhost:8010/RouterService"
    binding="wsHttpBinding" bindingConfiguration="wsHttp" 
    contract="IServiceA" listenUri="ServiceA">
    <headers>
      <Route 
        xmlns="http://www.thatindigogirl.com/samples/2008/01">
        http://www.thatindigogirl.com/samples/2008/01/IServiceA
      </Route>
    </headers>
  </endpoint>
</service>

カスタムヘッダーには、名前、名前空間、および値があります。ヘッダーがこれより動的な場合もありますが、ここでは、ヘッダーはサービスコントラクトの名前空間を表すように固定されています。Route 要素がヘッダー名を示し、名前空間は xmlns 属性によって示されます。このヘッダーはエンドポイント構成の一部として指定されるため、サービスのメタデータに含まれます。そのため、クライアントがプロキシを生成するときには、次に示すように、ヘッダーを含むクライアント構成も生成します。

<client>
  <endpoint address="http://localhost:8010/RouterService" 
    binding="wsHttpBinding" bindingConfiguration="wsHttp"
    contract="localhost.IServiceA" >
    <headers>
      <Route xmlns="http://www.thatindigogirl.com/samples/2008/01">
        http://www.thatindigogirl.com/samples/2008/01/IServiceA
      </Route>
    </headers>
  </endpoint>
</client>

これにより、ヘッダーの存在がクライアントのコーディング作業に対して透過となり、安全なセッションや信頼できるセッションを確立するためのメッセージも含めて、すべてのメッセージにヘッダーが含まれるようになります。ルーターは、次に示すように、どのメッセージからも名前と名前空間によってヘッダー値を取得できます。

string contractNamespace = 
  requestMessage.Headers.GetHeader<string>(
  "Route", 
  "http://www.thatindigogirl.com/samples/2008/01");

この実装が前の例から変更されている唯一の点は、ルーターがコントラクトの名前空間を確認する方法であり、Action ヘッダーの代わりにカスタム Route ヘッダーを使用しています。これにより、ルーターは、安全なセッションまたは信頼できるセッションに関連したメッセージを適切なサービスエンドポイントに転送できます。

サービスを登録する

アプリケーションサービスのエンドポイントをハードコーディングする代わりに、ルーターは、サービスがオンラインまたはオフラインになったときにサービスを登録または登録解除できるように、サービスのエンドポイントを公開することができます。これにより、ソフトウェアまたはハードウェアのロードバランサが存在しない場合には、アプリケーションサービスのスケールアウトが必要なときや、各エンドポイントアドレスのポートまたはマシン名が変更されたときに、ルーターの構成オーバーヘッドが低減されます。このモデルをサポートするには、次の手順を実行します。

ルーターに対してサービス登録コントラクトを実装し、ファイアウォールの背後のアプリケーションサービスにエンドポイントを公開します。
ルーターに対して登録リストを保持します。
各 ServiceHost の初期化後に、サービスエンドポイントをルーターに登録します。
各 ServiceHost が障害状態となったとき、または終了したときに、サービスエンドポイントをルーターから登録解除します。

図 2 に示す登録プロセスでは、物理エンドポイントアドレスにマッピングされたコントラクト名前空間を保持するエントリが追加されています。

図 2 サービスをルーターに登録する (クリックすると拡大画像が表示されます)

このアプローチの場合、登録に必要なのは、各サービスエンドポイントのコントラクト名前空間と物理アドレスだけです。図 3 に、登録および登録解除時にルーターに渡される、IRegistrationService サービスコントラクトおよび関連付けられた RegistrationInfo の詳細を示します。

図 3 IRegistrationService コントラクトとデータコントラクト

[ServiceContract(Namespace = 
  "http://www.thatindigogirl.com/samples/2008/01")]
public interface IRegistrationService {
  [OperationContract]
  void Register(RegistrationInfo regInfo);

  [OperationContract]
  void Unregister(RegistrationInfo regInfo);
}

[DataContract(Namespace = 
  "http://schemas.thatindigogirl.com/samples/2008/01")]
public class RegistrationInfo {
  [DataMember(IsRequired = true, Order = 1)]
  public string Address { get; set; }

  [DataMember(IsRequired = true, Order = 2)]
  public string ContractName { get; set; }

  [DataMember(IsRequired = true, Order = 3)]
  public string ContractNamespace { get; set; }

  public override int GetHashCode()   {
    return this.Address.GetHashCode() + 
    this.ContractName.GetHashCode() + 
    this.ContractNamespace.GetHashCode();
  }
}

ルーターはコントラクトごとに 1 つのエントリを格納することもできますが、その場合、各コントラクトに対して複数のサービスは使用できません。複数のエントリにまたがる分散をサポートするには、ルーターは登録ごとに一意のキーを使用する必要があります。このコードでは、各エントリに対して RegistrationInfo インスタンスのハッシュコードを一意に関連付けるための辞書を使用しています。

// registration list
static public IDictionary<int, RegistrationInfo> 
  RegistrationList = 
  new Dictionary<int, RegistrationInfo>();

// to register
if (!RouterService.RegistrationList.ContainsKey(
  regInfo.GetHashCode())) {
  RouterService.RegistrationList.Add(regInfo.GetHashCode(), 
    regInfo);
  }

  // to unregister
  if (RouterService.RegistrationList.ContainsKey(
    regInfo.GetHashCode())) {
    RouterService.RegistrationList.Remove(
      regInfo.GetHashCode());
  }

ルーターは、メッセージを受信すると、コントラクト名前空間を収集し、辞書内で一致する適切な項目を探します。一致する項目が複数ある場合は、選択条件を使用して、適切なサービスエンドポイントにメッセージを送信します (図 4 を参照)。

図 4 メッセージと適切なエンドポイントのマッチング

string contractNamespace = 
  requestMessage.Headers.Action.Substring(0, 
  requestMessage.Headers.Action.LastIndexOf("/"));

// get a list of all registered service entries for 
// the specified contract
var results = from item in RouterService.RegistrationList
  where item.Value.ContractNamespace.Contains(contractNamespace)
  select item;

int index = 0;
// find the next address used ...

// create the channel 
RegistrationInfo regInfo = results.ElementAt<KeyValuePair<int, 
  RegistrationInfo>>(index).Value;

Uri addressUri = new Uri(regInfo.Address);
Binding binding = ConfigurationUtility.GetRouterBinding    (addressUri.Scheme);
EndpointAddress endpointAddress = new EndpointAddress(regInfo.Address);

ChannelFactory<IRouterService> factory = new 
  ChannelFactory<IRouterService>(binding, endpointAddress)
// forward message to the service ...

動的登録は、サービスに対する負荷分散のニーズをマシン間で分散する以外にも、同じマシンでサービスの複数のインスタンスがホストされる可能性があるような状況でも有用です。そのようなインスタンスが Windows サービスでホストされる場合は、複数のポート割り当てが必要となります。

これをサポートするには、サービスがマシンに対して動的ポート割り当てを選択する必要があります。TCP サービスの場合、これはエンドポイント構成でリッスン URI モードを Unique に設定することで実現できます。

<endpoint address="net.tcp://localhost:9000/ServiceA" 
  contract=" IServiceA" binding="netTcpBinding"
  listenUriMode="Unique"/>

ただし、名前付きパイプおよび HTTP に対しては、この設定で一意のポートは選択されません。その代わりに、アドレスに GUID が付加されます。

net.tcp://localhost:64544/ServiceA
http://localhost:8000/ServiceA/66e9c367-b681-4e4f-8d12-80a631b7bc9b
net.pipe://localhost/ServiceA/6660c07e-c9f5-450b-8d40-693ad1a71c6e

TCP および HTTP サービスエンドポイントに対して一意のポートを割り当てるには、コードでベースアドレスまたは明示的なエンドポイントを初期化します。

Uri httpBase = new Uri(string.Format(
  "http://localhost:{0}", 
  FindFreePort()));
Uri tcpBase = new Uri(string.Format(
  "net.tcp://localhost:{0}", 
  FindFreePort()));
Uri netPipeBase = new Uri(string.Format(
  "net.pipe://localhost/{0}", 
  Guid.NewGuid().ToString()));

ServiceHost host = new ServiceHost(typeof(ServiceA), 
  httpBase, tcpBase, netPipeBase);

図 5 では、同じマシンでホストされた複数のサービスをルーターに登録しています。また、この図では、ルーターの単一点障害を取り除くために、インスタンス間で登録呼び出しを分散させるソフトウェアまたは物理ロードバランサが必要な場合があることが示されています。もちろん、登録リストが共有データベースに格納されることも示されています。

図 5 負荷分散ルーターをとおしてサービスを動的ポートに登録する (クリックすると拡大画像が表示されます)

メッセージを検査する

一般にルーターは元のメッセージをアプリケーションサービスに転送しますが、メッセージの内容に基づいた操作を実行する場合もあります。たとえば、コンテンツベースのルーティングでヘッダーまたは本文要素を検査したり、ヘッダーまたは本文要素の有効性に基づいてメッセージを拒否します。

Message 型では、アドレス指定ヘッダーを直接取得したり、カスタムヘッダーを名前と名前空間で取得するための Headers プロパティを公開しているため、ヘッダーの検査は簡単です。次のサービス操作を考えてください。ここでは、メッセージコントラクトを使用して、受信操作に対するカスタム LicenseKey ヘッダーを追加しています。

// operation
[OperationContract]
SendMessageResponse SendMessage(SendMessageRequest message);

// message contract
[MessageContract]
public class SendMessageRequest {
  [MessageHeader]
  public string LicenseKey { get; set; }

  [MessageBodyMember]
  public string Message { get; set; }
}

クライアントは、LicenseKey ヘッダーを含むメッセージを送信します。ライセンスキーを持っていない場合、このヘッダーは空の可能性があります。ルーターは、このヘッダーを次のようにして取得できます。

string licenseKey = 
  requestMessage.Headers.GetHeader<string>(
  "LicenseKey", 
  "http://www.thatindigogirl.com/samples/2008/01");

同じ LicenseKey 値がメッセージ本文内で渡される場合には、ルーターはメッセージ本文を読み取って値にアクセスする必要があります (この情報が Message 型から直接得られないため)。GetReaderAtBodyContents メソッドは、メッセージ本文を読み取るのに使用できる XmlDictionaryReader を次のように返します。

XmlDictionaryReader bodyReader = 
  requestMessage.GetReaderAtBodyContents();

Message の State プロパティは、MessageType の列挙値 Created、Copied、Read、Written、または Closed になります。メッセージは Created 状態から始まり、操作に対して Message パラメータを受信したルーターはメッセージを処理しないため、状態は Created のままです。

メッセージ本文を読み取ると、要求メッセージの状態が Created から Read に遷移します。メッセージの読み取り、書き込み、またはコピーは 1 回しか行えないため、いったん読み取られたメッセージはアプリケーションサービスに転送できません。

コンテンツベースのルーター実装では、メッセージを読み取る前に、メッセージをバッファにコピーする必要があります。このメッセージのバッファコピーを使用して、元のメッセージの新しいコピーを次のように作成して処理に使用できます。

MessageBuffer messageBuffer = 
  requestMessage.CreateBufferedCopy(int.MaxValue);
Message messageCopy = messageBuffer.CreateMessage();
XmlDictionaryReader bodyReader = 
  messageCopy.GetReaderAtBodyContents();

XmlDocument doc = new XmlDocument();
doc.Load(bodyReader);
XmlNodeList elements = doc.GetElementsByTagName("LicenseKey");
string licenseKey = elements[0].InnerText;

同じバッファを再度使用して、アプリケーションサービスに転送するメッセージを作成できます。この CreateMessage の呼び出しは、元のメッセージに基づいた新しい Message インスタンスを返します。

ルーターとトランスポートセッション

パススルールーターの場合、クライアントはルーターで想定しているトランスポートプロトコルおよびエンコード形式でメッセージを送信する必要があり、ルーターは、アプリケーションサービスで想定しているトランスポートプロトコルおよびエンコード形式でメッセージをアプリケーションサービスに転送する必要があります。ここまでに説明したすべてのルーティング機能は、転送の両方の側が共に HTTP (セッションあり、またはセッションなし) の場合には問題なく動作します。ただし、TCP などのトランスポートセッションを導入すると、いくつかの興味深い課題が発生します。セキュリティが無効で信頼できるセッションがないという最も単純なケースではすべてがうまくいきますが、これらの機能を追加したときに問題が生じます。

アプリケーションサービスに対してセキュリティを有効にした場合、ルーターは署名付きの To ヘッダーを提供する必要があります。これは通常、To ヘッダーをクライアントが送信した状態のまま変更しないことを意味しますが、既定では、手動アドレス指定が有効でない限り、ルーターはメッセージが送信されたときにサービスのアドレスと一致するよう To ヘッダーを変更します。たとえば、ルーターが TCP プロトコルを使用してメッセージをサービスに転送する場合、送信チャネルが要求/応答コントラクトに基づいているときには手動アドレス指定が許可されません。

信頼できるセッションが有効で、ルーターが TCP プロトコルを使用してサービスを呼び出す場合には、また別の問題が生じます。この場合は、ルーターをとおして非同期の受信確認が返されます。したがって、ルーターは非同期の受信確認を受け取るためにサービスとのセッションを維持する必要があります。その結果、クライアントは同じ非同期の受信確認を受け取るために、ルーターとの二重セッションを維持する必要があります。

どちらの問題も、セッションをサポートして受信/送信の二重チャネルを使用するルーターを実装することで、部分的に解決できます。呼び出し元のクライアントもアプリケーションサービスもこれを直接認識する必要はありません。これはルーター内の実装詳細です。ただし、これにはセッション対応のバインディングが必要であり、また、信頼できるセッションで非同期の受信確認を使用する場合には二重通信が必要となります。

二重ルーター

図 6 のコードは、クライアント、ルーター、およびアプリケーションサービスの間でメッセージが TCP を介して送信される状況をサポートするための、二重ルーターコントラクトの例を示しています。これは、従来の要求/応答ルーターコントラクトとは次のように異なります。

ProcessMessage が一方向操作です。
サービスコントラクトにセッションが必要であり、コールバックコントラクトが関連付けられています。この場合、クライアントはコールバックを実装する必要がないことに注意してください。これはルーター内部で処理されます。
コールバックコントラクトには、ルーター呼び出しからアプリケーションサービスへの応答を受信する 1 つの一方向メソッドがあります。また、サービスは応答がコールバックチャネルに送信されていることを認識しません。これらの応答には要求/応答メッセージを使用できます。

図 6 二重ルーターコントラクト

[ServiceContract(Namespace = 
  "http://www.thatindigogirl.com/samples/2008/01", 
  SessionMode = SessionMode.Required, 
  CallbackContract = typeof(IDuplexRouterCallback))]

public interface IDuplexRouterService {
  [OperationContract(IsOneWay=true, Action = "*")]
  void ProcessMessage(Message requestMessage);
}

[ServiceContract(Namespace = 
  "http://www.thatindigogirl.com/samples/2008/01", 
  SessionMode = SessionMode.Allowed)]
public interface IDuplexRouterCallback {
  [OperationContract(IsOneWay=true, Action = "*")]
  void ProcessMessage(Message requestMessage);
}

ご意見やご質問は、sstation@microsoft.com まで英語でお送りください。