第18章 XTSで利用されるプロトコルの概要
本章では、各プロトコル仕様にて定義されているように、WS-Coordination、WS-Atomic Transaction、WS-Business Activity プロトコルに関連する基本的なコンセプトについて見ていきます。これらのプロトコルに関する基本情報は、本書で触れている残りの内容を理解する際に重要になってきます。
注記
WS-Coordination、WS-Atomic Transaction、WS-Business Activityについて熟知している場合は、本章は簡単に読み進めていただくだけで結構です。
18.1. WS-Coordination
一般的に、coordinationは、コーディネータとして知られるエンティティにより行われ、ドメイン固有の理由で、多くのパーティシパントに情報を提供します。この理由には、分散トランザクションプロトコルによる決定でコンセンサスを得るため、あるいは、信頼できるマルチキャスト環境などで全パーティシパントが特定のメッセージを取得するようにするためなどです。パーティがコーディネートされると、情報 (coordination contextと呼ばれる)を伝播し、論理的には調整済みの同作業あるいは同アクティビティの一部である操作を統合します。このコンテキスト情報は通常のアプリケーションメッセージと流されるか、あるいはメッセージ交換の明示的部分となります。これは、実行したコーディネーションタイプに固有のものです。
WS-Coordination (WS-C)を支える基本的なアイデアは、コーディネーションインフラストラクチャがWeb Services 環境にて必要であるという点です。WS-C仕様は、様々なコーディネーションプロトコルをプラグインできるフレームワークを定義しており、図18.1「WS-C Architecture」で示されているようにクライアント、サービス、パーティシパント間の作業をコーディネートします。
図18.1 WS-C Architecture
どのコーディネーションプロトコルを利用し、どのドメインでデプロイされていても、同じような一般的な要件が存在します。
WS-C に対する一般要件
- 特定のアプリケーションインスタンスについて、特定のコーディネーションプロトコルへ新規コーディネータをインストールあるいはアクティベート
- コーディネータにパーティシパントを登録し、アプリケーション (アプリケーションの一部) が有効な間にコーディネータのプロトコルメッセージを受信
- アプリケーションを構成するWeb Services 間でコンテキスト情報を伝播
- 完了するまでコーディネーションプロトコルを駆動するエンティティ
WS-C に対する一般要件 の最初から３つのポイントは、WS-Cが直接担当しており、４番目はサードパーティのエンティティが管理しています。サードパーティのエンティティは通常、全アプリケーションの中のクライアントコンポーネントとなっています。これら4つのWS-Cの役割および関係は図18.2「WS-Cでの4つの役割」にて説明されています。
図18.2 WS-Cでの4つの役割
18.1.1. アクティベーション
WS-C フレームワークは、特定のコーディネーションプロトコルに対しコーディネータを作成し、関連コンテキストをリトリーブするActivation Service を公開します。RPC スタイルの交換を使い同期的にActivation Services を呼び出します。そのため、サービスWSDLは、単一のポートを定義し、
CreateCoordinationContext 操作を呼び出します。この操作は、必要なコーディネーションタイプ、タイムアウト、その他の関連情報など、作成すべきトランザクション詳細を指定するインプットを取得します。その後、トランザクション識別子、コーディネーションタイプ、登録サービスURLなど、新たに作成されたトランザクションコンテキストの詳細を含んだアウトプットを返します。
例18.1
<!-- Activation Service portType Declaration -->
<wsdl:portType name="ActivationCoordinatorPortType">
<wsdl:operation name="CreateCoordinationContext">
<wsdl:input message="wscoor:CreateCoordinationContext"/>
<wsdl:output message="wscoor:CreateCoordinationContextResponse"/>
</wsdl:operation>
</wsdl:portType> 注記
1.0 Activation Coordinator サービスは、1方向メッセージ２つから成る非同期メッセージ交換を採用しており、Activation Requester サービスも必要になります。
18.1.2. 登録
Activation Service により返されたコンテキストには、Registration Service のURLが含まれています。Web サービスがトランザクションコンテキストに添付されたサービスリクエストを受け取ると、Registration Service に連絡をし、そのトランザクション内でパーティシパントとして登録します。登録リクエストには、Web サービスがトランザクション内で行いたい役割を定義したパーティシパントプロトコルが含まれています。コーディネーションプロトコルにより、パーティシパントプロトコルを1種類以上の中から選択することができます。
Activation Service のように、Registration Service は同期通信を前提としています。そのため、サービスWSDLは、
Register 操作を宣言している１つのポートを公開します。この操作で、パーティシパントのプロトコルタイプなど、パーティシパント詳細を指定するインプットを取得します。その後、該当のアウトプットレスポンスを返します。
例18.2 Registration ServiceWSDLインターフェース
<!-- Registration Service portType Declaration -->
<wsdl:portType name="RegistrationCoordinatorPortType">
<wsdl:operation name="Register">
<wsdl:input message="wscoor:Register"/>
<wsdl:output message="wscoor:RegisterResponse"/>
</wsdl:operation>
</wsdl:portType>
このRegistration Service を使いコーディネータにパーティシパントが登録されると、コーディネーションメッセージをコーディネータから受信します。2相プロトコルを使っている場合、通常のメッセージには“prepare to complete” や “complete” などのメッセージが含まれます。コーディネータのプロトコルが対応している場合、パーティシパントもコーディネータにメッセージを返信することができます。
注記
1.0 Registration Coordinator サービスは、一方向メッセージ２つで構成された非同期メッセージ交換を採用しており、Registration Requester サービスも必要となります。
18.1.3. 完了
ターミネータの役割は通常、クライアントアプリケーションが果たします。適切な時点で、クライアントがコーディネータに対し、登録したパーティシパントとともに特定のコーディネーション機能を実行するように依頼し、完了までプロトコルを駆動します。完了後、クライアントアプリケーションはアクティビティの結果を通知される場合があります。この結果は、単純な成功通知や失敗通知からアクティビティの状態の詳細を示す構造データなどの範囲であればあらゆる形式を取ることができます。
