Uncategorized

WCF における Binding と Channel の基礎 (WCF のカスタマイズ)

By on • ( 11 Comments )

こんにちは。

  1. WCF と BizTalk、そして LOB Adapter
  2. WCF における Binding と Channel の基礎
  3. WCF LOB Adapter SDK によるカスタムアダプター実装
  4. WCF からの LOB Adapter の使用
  5. BizTalk Server からの LOB Adapter の使用 – schema 編
  6. BizTalk Server からの LOB Adapter の使用 – orchestration 編
  7. BizTalk Server からの LOB Adapter の使用 – deploy 編

今回は、WCF LOB Adapter SDK による開発前の準備として、WCF におけるデータの送受信のパイプラインについてお話します。

(ここで説明している内容については、こちら にサンプルコードを添付しました)

WCF では、送られたデータの処理を多段階で実行できるよう、チャネル スタックという独自のパイプラインを使って処理されます。
さっそくですが、以下がその概念図です。

クライアントから送られたデータは、チャネルスタック (Channel Stack) という上図のような一連のスタックに渡され、各 Channel により順番にバケツリレーのように処理して、次へと渡されていきます。
各チャネルでは、まず BindingElement と呼ばれるオブジェクトを通して ChannelFactory と ChannelListner が build され、適切な Channel の作成やリッスンの処理がおこなわれ、この生成された Channel オブジェクトが実際の処理を担当しています。
各チャネルがおこなっている仕事というのは、例えば、ある Channel の Send メソッドでは Base64 エンコードをして、Receive メソッドではデコードをおこなうといった具合です。
データは、Message (System.ServiceModel.Channels.Message) という型に変換され伝搬され、処理された Message は最後 (上図の一番右の出口) でディスパッチャ (Dispatcher) と呼ばれるオブジェクトに渡されて、このディパッチャーがユーザが作成したコード (WCF で開発者の皆さんが記述する処理のコード) を呼び出します。

そして、これら BindingElement の集合が Binding です。 この 1 つの Binding (BindingElemement を継承したクラス達の集合体) を WCF のフレームワークの中に登録することで、以降はこれをスキーム (Scheme) という文字列で識別して使用できるようになります。
スキーム (Scheme) とは、「net.tcp://」,「http://」, などの URI スキームで表現される「net.tcp」、「http」などのプロトコル文字列のことです。

先ほど各 Channel (つまりは BindingElement) のおこなう仕事について少し触れましたが、もう少しちゃんとイメージできるようにご説明しましょう。
まず、上述した BindingElement のコレクションは何でもカンでも適当に詰め込まれているのかというと、異なります。BindingElement には順序が決まっており、以下の順序で指定する必要があります。(上図では、受信を想定して左から処理される絵としましたが、以下ではその逆に、右から処理するイメージでとらえてください。)

  1. プロトコル バインディング要素
    ここだけは、BindingElement を継承した任意個の数の要素を含めることができます。この要素はメッセージで動作する上位の処理をおこなうもので、Windows Communication Foundation (WCF) には、ReliableSessionBindingElement や SymmetricSecurityBindingElement など、既存の 「プロトコル バインディング要素」 がいくつか含まれています。
    この中に一般的に含める要素を分類すると、以下になります。
  • トランザクションフロー (必須ではありません。一般に TransactionFlowBindingElement 抽象クラスを継承した BindingElement です)
  • 信頼性 (必須でありません, 同様に ReliableSessionBindingElement)
  • セキュリティ (必須ありません, SecurityBindingElement)
  • 複合二重 (必須ありません, CompositeDuplexBindingElement)
  • エンコーディング バインディング要素 (MessageEncodingBindingElement 抽象クラスを継承して作成します)
    この要素では、メッセージのエンコーディング/デコーディングの処理をおこないます。一般的には、このエンコーディングバインディング要素が 1 つだけ含まれます。
    既存のエンコーディングバインディング要素の例としては、MtomMessageEncodingBindingElement、BinaryMessageEncodingBindingElement、TextMessageEncodingBindingElement などがあります。
    この BindingElement は原則必須なのですが、エンコーディングバインディング要素がバインディングに指定されていない場合には、WCF のフレームワークは既定のエンコーディングを設定します (「既定のエンコーディング」とは、トランスポートプロトコルが HTTP/HTTPS の場合は TextMessageEncodingBindingElement、それ以外の場合は BinaryMessageEncodingBindingElement です)。
  • トランスポート バインディング要素 (TransportBindingElement 抽象クラスを継承して作成します)
    この要素では、トランスポートプロトコルでのデータの解釈をおこないます (もっともプリミティブな要素です)。この要素も必須で、TransportBindingElement 抽象クラスから派生したトランスポートバインディング要素を必ず 1 つ含める必要があります。
    トランスポートバインディング要素の例としては、TcpTransportBindingElement、HttpTransportBindingElement、NamedPipeTransportBindingElement などがあります。

つまり、受信の際には、下から順番にチャネルにデータが渡されて処理されていくということです。

さて、こんな感じの構成なのですが、上記をおぼえておけば、バインディングに対するさまざまな拡張(カスタマイズ)を理解する助けとなります。
例えば、もっとも簡単なカスタマイズ方法としては、既存の BindingElement を使って、その Collection を独自に組み合わせて独自の Binding (集合) を構成するといったカスタマイズ (Custom Binding) も考えられるでしょう (実はこの程度なら .config の編集のみで可能です)。また、サードパーティが提供する独自プロトコル (トランスポートレイヤ、もしくはその付近のプリミティブなプロトコル) の場合には、独自の BindingElement クラスや Channel クラスを作成して組み込むといった高度なカスタマイズも可能でしょう (Custom Channel)。

また上記でチャネルディパッチャーの話を少ししましたが、カスタムの Channel Dispacher を構築するといったカスタマイズも可能です。
WCF は、コンポーネントの大部分が拡張しやすいフレームワークとなっているということがおわかり頂けるでしょう。実際、米国などでは、IBM MQ 用のカスタムチャネルなど、カスタムチャネルもいくつか存在しており、提供元のベンダからダウンロードして WCF に組み込んで使うことができるようになっています。

このように、「Binding」 というこの処理の形態そのものが世の中のあらゆる通信手段に対応した「中立的なプロトコル」(通信の形態に対する約束事) となっています。次回以降で解説していく WCF LOB Adapter SDK では、上記のトランスポートバインディング自体を「Adapter」というクラスから継承して実装するという開発スタイルになっており、作成される Adapter クラスは TransportBindingElement 抽象クラスから継承されたクラスとなります。(この中のハンドラと呼ばれるクラスで、データベースやパッケージソフトへの接続処理を記述する、などといった開発スタイルになります。)

もっとカスタムチャネルやカスタムディスパッチャーを学習して会社のソリューション構築などに活用したいという方は、小難しい説明を見るよりも、まずは上記の概念を頭に押えて頂き、サンプルコードを覗くほうがはやいかもしれません。(その後で、疑問のあるコードをピンポイントに MSDN などのリファレンスで確認すると効果的です。)
こうしたサンプルコードは、以下にたくさん含まれています。

http://www.microsoft.com/downloads/details.aspx?FamilyId=2611A6FF-FD2D-4F5B-A672-C002F1C09CCD&displaylang=en

尚、BizTalk Server におけるアダプターのメカニズムについては、以前ご紹介した書籍 「プロフェッショナル BizTalk Server 2006」 (2章、3章) が参考になります。

 

Categories: Uncategorized

Tagged as:

11 replies »

  1. こんにちは。 前回 -> 「 WCF と BizTalk、そして LOB Adapter 」 今回は、WCF LOB Adapter SDK による開発前の準備として、WCF におけるデータの送受信のパイプラインについてお話します

    Like

    Reply
  4. Pingback: .NET 4.5 で Active Authentication を実装する – tsmatz
  5. Pingback: カスタムのトラッキング ビヘイビア (Behavior) の作成と使用 – tsmatz
  6. Pingback: 【SOA における WCF の役割 (1)】 WCF と BizTalk、そして LOB Adapter – tsmatz
  7. Pingback: 【SOA における WCF の役割 (3)】 WCF LOB Adapter SDK によるカスタムアダプター実装 – tsmatz
  8. Pingback: 【SOA における WCF の役割 (4)】 WCF からの LOB Adapter の使用 – tsmatz
  9. Pingback: 【SOA における WCF の役割 (5)】 BizTalk Server からの LOB Adapter の使用 – schema 編 – tsmatz
  10. Pingback: 【SOA における WCF の役割 (7)】 BizTalk Server からの LOB Adapter の使用 – deploy 編 – tsmatz
  11. Pingback: 【SOA における WCF の役割 (6)】 BizTalk Server からの LOB Adapter の使用 – orchestration 編 – tsmatz

Leave a Reply