EIP / WS-*

WS-* †

サマリ †

xxx

詳細 †

WS-* †

• SOAP／WSDLベースのWebサービスで、信頼性・セキュリティ・状態保持・QoSを実現するための仕様が出始めている。
• 残念ながら、Webサービス仕様の世界はベンダ連合同士の競争によって重複したバージョンが乱立しており、また実際に実装されているものは少ない。多分近いうちに再編されるだろう。
• しかし、それらの仕様の中で使われるイディオムや戦術は、Webサービスを使ってメッセージングベースの統合をする際の参考になるだろう。
• これらの中で特に注目に値する仕様、トランザクションの実現・信頼性・ルーティング・会話状態の管理・セキュリティを見ていく。

WS-Coordination and WS-Transaction †

• Webサービスはステートレスかつ信頼性が低いので、トランザクション処理で要求されるQoSを達成できない。そのため、実際には、開発者がWebサービスベースの統合メカニズムを作ろうとすると、自分でトランザクションの仕組みを作らなければいけなくなる。商用のMOMシステムではそういった機能は一般に用意されている。WS-Coordination と WS-Transaction はそういった問題を解決するための仕様。
• WS-Coordination はBEA、Microsoft、IBMが作った仕様で、1つのフローに参加するすべてのサービスが、非同期かつ不規則な時間間隔の中でも、コンテキスト情報を生成し伝播できるようにするための方法を定めたもの。この仕様は、アプリケーションやサービスのアクションを連携させるためのプロトコルを生成する、拡張可能なフレームワークを定義する。この連携プロトコルは、XMLベースのコンテキストを生成し、登録することで機能し、そのコンテキストはSOAPメッセージの中に入れられて伝播し、協調動作する全てのエンドポイントにあるコーディネータによって処理される。
• こうしたコンテキストは、分散したトランザクションの結果に対して一貫した合意を得るような用途に使われる。そして、WS-Transaction は WS-Coordination を利用して、複数のサービス呼び出しを跨ぐような分散トランザクションを実現している。
• WS-Transaction は、フロー中の各アクションの成功・失敗をモニタ、計測する方法を定義する。具体的には、SOAPメッセージがエンドポイントに到着すると、連携コンテキストを含んだSOAPヘッダがフィルタされ、メッセージから取り出される（Content FilterやSplitterパターンを使って実装できる）。そのSOAPヘッダは、トランザクションコーディネータに送られて、処理される。
• WS-Transactionのトランザクションに使われる連携コンテキストを含んだSOAPエンベロープの例。このコンテキスト情報から、コーディネータがアプリケーションを登録して、そこにトランザクションへの参加、2PCへの準備、ロールバック、コミットなどのイベントを送る。

     <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2001/12/soap-envelope">
       
       <SOAP-ENV:Header>
         
         <wscoor:CoordinationContext
           xmlns:wscoor="http://schemas.xmlsoap.org/ws/2002/08/wscoor"
           xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility"
           xmlns:myTransactableApp="http://foo.com/baz">
           
           <wsu:Identifier>http://foo.com/baz/bar</wsu:Identifier>
           <wsu:Expires>2004-12-31T18:00:00-08:00</wsu:Expires>
           
           <wscoor:CoordinationType>
             http://schemas.xmlsoap.org/ws/2002/08/wstx
           </wscoor:CoordinationType>
           
           <wscoor:RegistrationService>
             <wsu:Address>
               http://foo.com/coordinationservice/registration
             </wsu:Address>
           </wscoor:RegistrationService>
           
           <myTransactableApp:IsolationLevel>
             RepeatableRead
           </myTransactableApp:IsolationLevel>
           
         </wscoor:CoordinationContext>
         
       </SOAP-ENV:Header>
       
       <!-- SOAP BODY (snipped) -->
       
     </SOAP-ENV:Envelope>

• WS-Transaction には2つの連携型がある：atomic transaction (AT) と business activity (BA)
• ATはいわゆる従来の分散トランザクション（XA）と同じ。比較的短期の処理でのリソースのロックやロールバックに使える。WS-Tx はWebサービスをプロプラなXA実装とのリンクさせる方法も提供する。
• BAは複数のATを含んだ長期のプロセスを指す。BAでは全体のロールバックは望ましくないので、AT単位で代わりに新たなサービスの呼び出しやメッセージ交換を行う。ここでは、補償（compensation）のテクニックが使える。旅行手配の例。
• WS-Coordination と WS-Tx はプロダクトに組み込まれつつあるので、開発者が自分たちでこうした仕組みを作る必要性はなくなっていくだろう。

WS-Reliability and WS-ReliableMessaging? †

• xxx

WS-Conversation †

• WS-Conversation は、送受信者（通常SOAPエンドポイント）間でのステートフルな非同期メッセージ交換を管理するためのプロトコルを定義する。ビジネスプロセスコンポーネントに状態を管理させるのではなく、クライアントーサービス間でのシンプルな状態管理の方法を提案する。
• このプロトコルでは、SOAPヘッダを使ってトークンIDを送信する。ステートフルな会話が始まると、StartHeader? ヘッダに会話IDとコールバックURIを埋め込む。後続のメッセージは、ContinueHeader? と CallbackHeader? を使ってリクエスト・リプライをする。これらのヘッダには、同一の会話IDが使われる。
• この仕様は、Aggregator と Composed Message Processor に加えて Correlation Identifier を使ったものを形式化したものと言える。
• 個々のサービスやコンポーネントがブラックボックスな、より大規模な統合プロジェクトでは、状態管理をプロセスコンポーネントやコレオグラフィに外部化するアプローチの方が有効に見えるが、WS-Conversation はクライアントとサービス共に制御可能な場合に何ができるかを示す例となっている。

WS-Security †

• xxx

WS-Addressing, WS-Policy, and Other WS-* Specifications †

• xxx

担当者のつぶやき †

• 2004年の書籍なので、WS-*の記述的にはけっこう古くなっています。WS-*は2004年以降に栄枯盛衰が激しいので、ここでの記述は参考程度な感じでしょうか。

みんなの突っ込み †