連載 ビジネスWebサービス最新事情（7）
BtoB基盤となるWebサービス・トランザクション

Webサービスをビジネスで利用するために、高度なセキュリティやトランザクション処理、複数のWebサービスの連携などを実現するさまざまな仕様が策定されようとしている。本連載では、これらの仕様を理解するための解説を行っていく。（編集局）

日本アイオナテクノロジーズ（株）
小野沢 博文
2004/3/11

　前回の「混迷するWebサービス・トランザクション制御」では、特定の仕様によらないWebサービス・トランザクションのベーシックな部分を解説しました。今回は、こうした基本機能が具体的にどのように実現されるのかを、WS-CAFを例に解説します。そして最後に、Webサービス・トランザクションをめぐる標準化戦争の行方を議論してみたいと思います｡

■WS-CAFの仕組み

　トランザクション・サービスは、複数のWebサービスにまたがる非常に複雑な処理を実行します。この複雑な処理を、SOAPのような単純なプロトコル上に実装するためには、Webサービス間のコーディネーション（調整）や、トランザクションのコンテキスト情報伝搬のための仕組みを実現しなければなりません。この2つの機能 ― コーディネーションとコンテキスト伝搬 ― をトランザクション・サービス仕様の中に包含してしまうことも可能ですが、WS-CAFでは、これらをトランザクション・サービスから独立したフレームワーク・サービスとして切り出しています｡

　WS-CAF（Web Services Composite Applications Framework）は、WS-CTX（Web Services Context）、WS-CF（Web Services Coordination Framework）、WS-TXM（Web Services Transaction Management）の3つの仕様から構成されており、それぞれがコンテキスト伝搬、コーディネーション、トランザクション管理を担当しています。

　トランザクション仕様として現在提案されている、BTP（Business Transaction Protocol）、WS-Transaction、およびWS-CAFのそれぞれの仕様の構成を図1に示します｡BTPは、コンテキスト伝搬やコーディネーションを独立した仕様として切り出すことなく、一枚岩の仕様として構成しています。これに対して、WS-Transactionでは、WS-Coordinationがコンテキスト伝搬とコーディネーションを担当し、その上のWS-AtomicTransactionとWS-BusinessActivityがトランザクション管理を担当しています。

図1　各トランザクション仕様の構成

　WS-CAFのように基盤サービスをトランザクション管理と切り離して仕様化する方法には、一長一短があります。もしWS-CTXやWS-CFのような基盤サービスがトランザクション管理以外の、例えばセキュリティやセッション管理といったサービスからも共通に利用されるとしたら、確かにメリットがあります。しかし、基盤サービスを利用するほかの上位サービスが将来的に出現しない場合には、単に仕様を重くするだけかもしれません。

　以下では、WS-CAFを構成するWS-CTX、WS-CF、およびWS-TXMを順番に解説していきましょう。

■WS-CTX（コンテキスト伝搬）

　WS-CTXは、アクティビティとそれに付随するコンテキストを管理、伝搬するためのコンテキスト・サービスの仕様です。アクティビティとは、セッションやトランザクションといった1つのまとまった仕事の単位です。1つのアクティビティには、1つ以上のWebサービスにおけるサービス実行（オペレーション呼び出し）が含まれます｡ただし、何をもってアクティビティと定義するのかは、セッション管理やトランザクション管理のような上位サービスに任されています｡

　コンテキスト・サービスは、アクティビティごとにコンテキストの管理を行います｡クライアント・アプリケーションがサーバを呼び出す際には、SOAPメッセージのボディ部にアプリケーション・データが格納されますが、セッション情報やトランザクション情報のようなコンテキスト情報は、メッセージのヘッダ部分に格納されて伝搬されます。このコンテキスト情報の内容は上位サービスに依存したものになりますが、WS-CTXではその共通構造を規定しています。

コンテキスト・サービスとALS

　上位サービスに依存したコンテキスト情報の作成や解釈は、コンテキスト・サービスとは独立したアクティビティ・ライフサイクル・サービス（ALS）が担当します。WS-CTXでは、コンテキスト・サービスとALSの間のインターフェイスだけを規定しており、個々のALSの設計は上位サービスに任されています｡別のいい方をすると、ALSはコンテキスト・サービスに対するプラグインという位置付けで、ここに上位サービスに依存する機能をカプセル化できるようになっています。

　図2にクライアント・アプリケーション、サーバ・アプリケーション、コンテキスト・サービス、およびALSの関係をまとめておきます。コンテキスト・サービスやALSが物理的にどこに配置されるのかは、WS-CTX仕様では規定していません。これらのサービスが独立したWebサービスとして実装されるかもしれませんし、またはクライアントやサーバのプロセスに組み込まれて実装されるかもしれません。

図2　アプリケーション、コンテキスト・サービス、ALSの関係

　それでは、比較的単純なセッション管理を例に、図2に従ってアプリケーションとコンテキスト・サービス、そしてALSの相互作用を説明しましょう（以下の番号は図中の番号に対応します）。

1. クライアント・アプリケーションは、コンテキスト・サービスのbeginオペレーションを呼び出して、新たなセッションを開始します。
2. コンテキスト・サービスは、あらかじめ登録されているセッション管理ALSのbeginオペレーションを呼び出して、アクティビティの開始を通知します。
3. クライアント・アプリケーションがサーバ・アプリケーション（Webサービス）のオペレーションを呼び出すと、コンテキスト・サービスとALSが作成したセッション・コンテキスト情報がアプリケーション・データとともにSOAPメッセージに格納されて、サーバに送られます｡サーバからの応答メッセージにもコンテキスト情報が格納されてクライアントに返却されます。この場合のコンテキスト情報は、例えばHTTPのクッキーのようなものだと考えてください｡
4. ひととおりの処理が完了したら、クライアントはコンテキスト・サービスのcompleteオペレーションを呼び出して、セッションの終了を通知します。
5. コンテキスト・サービスはALSのcompleteオペレーションを呼び出して、アクティビティの終了を通知します｡
6. ALSは、ALS固有のプロトコルを使用して、サーバ・アプリケーションと協力してセッション終了処理を実行します。

　上のように、最後のアクティビティの終了処理は上位サービスに依存するため、ここでは上位サービス依存のプロトコルが使用されます。例えば、ACIDトランザクション処理の場合には、2相コミット・プロトコルが利用されます。WS-CTXの役割は、アクティビティの終了をALSに通知するところまでなのです。

コンテキスト情報の構造

　先に説明したようにSOAPヘッダに格納されるコンテキスト情報は、WS-CTX仕様で基本構造が定義されており、それを上位サービスが拡張できるようになっています。

　まだドラフト仕様の段階で将来的に変更されるかもしれませんので、スキーマ定義は掲載しませんが、コンテキスト情報には、各アクティビティを一意に特定するコンテキスト識別子（必須）、コンテキストを生成したコンテキスト・サービスを特定するURI（オプション）、アクティビティの型（オプション）、アクティビティに参加しているサービスのリスト（オプション）、子アクティビティのリスト（オプション）、コンテキストのタイムアウト値（オプション）、および拡張可能なany型の要素（オプション）が含まれます｡

　上位サービスによってはコンテキスト情報が大きすぎて、すべての情報をその都度SOAPヘッダで運ぶのが適切でないケースもあります。この場合には、ヘッダにコンテキストのフル情報を格納する代わりに、フル情報を提供するコンテキスト・マネージャをWebサービスとして実装し、そのURLをSOAPヘッダのコンテキストに格納することもできます。

■WS-CF（コーディネーション）

　WS-CFはWS-CTXの上位に位置し、トランザクションなどの任意のコーディネーション・プロトコルに対して共通のフレームワークを提供します。具体的には以下のような特徴を持っています。

• WS-CFが提供するコーディネータは、WS-CTXから見るとALSにカプセル化されます。
• コーディネータは、コーディネーション・プロトコルへの参加者（例えば、トランザクション・サービスにおけるリソース・マネージャや下位のコーディネータ）を登録するためのインターフェイスを提供します。
• コーディネーションに必要な情報をクライアント・サーバ間で交換するために、WS-CTXのコンテキストを拡張しています。具体的には、コーディネーション・プロトコルの識別子とコーディネータのエンドポイント情報が追加されています。
• コーディネータは、アクティビティの開始と終了の通知をコンテキスト・サービスから受けて、参加者間のコーディネーションを行います。
• アクティビティの途中で、クライアントが必要としたところで、コーディネーションを実行するためのオペレーションも提供されています。
• 具体的なコーディネーション・プロトコルは、トランザクションなどの上位サービスが定義します。コーディネータは、単にコーディネーション・プロトコル開始のトリガを与えるだけです。

■WS-TXM（トランザクション管理）

　上述のように、アクティビティ終了時に実行されるコーディネーション・プロトコルは、WS-CF仕様ではなく、コーディネーションの目的に応じて上位サービスによって定義されます。トランザクション管理はこうした上位サービスの1つで、WS-TXM仕様では、密結合トランザクション向けのACIDトランザクション・プロトコル、および疎結合トランザクション向けのロング・ラニング・アクション・プロトコルとビジネス・プロセス・トランザクション・プロトコルの合計3つのコーディネーション・プロトコルが定義されています。

　密結合トランザクションと疎結合トランザクションのそれぞれの役割については、前回すでに説明していますので、今回は、これらを実現するためにコーディネータとトランザクション参加者との間で、具体的にどのようなメッセージがやりとりされるのかを見ていくことにします。

ACIDトランザクション・プロトコル

　ACIDトランザクション・プロトコルは、その名のとおり、1つ以上のトランザクション参加者の間でリソースのACID性を保証するためのプロトコルで、トランザクション終了時に、2段階の手続きを踏んでリソースを最終状態に移行させる2相コミット・プロトコルが使用されます。ただし、トランザクションに参加するリソースが1つしかない場合には、最適化のために1相コミット・プロトコルを利用したり、リソースに対して読み取りアクセスしかない場合には、そのリソースを2相コミット・プロトコルから除外することもあります。

　それでは、2相コミット・プロトコルを簡単な例で説明しましょう。以下では、図3中の番号に沿って説明します。

1. クライアント・アプリケーションはコンテキスト・サービスのbeginオペレーションを呼び出して、トランザクション（アクティビティ）の開始を宣言します。
2. コンテキスト・サービスは、あらかじめ登録されたトランザクション・コーディネータALS（以下コーディネータ）のbeginオペレーションを呼び出します｡
3. クライアント・アプリケーションは、サーバ・アプリケーション（Webサービス）のオペレーションを呼び出して、何らかのビジネス処理を実行します（例えば、代金引き落とし処理）。その結果、トランザクションのコンテキスト情報がSOAPメッセージのヘッダに格納されてサーバ・アプリケーションに伝搬されます。この中には、コーディネータのエンドポイント情報も含まれています｡
4. サーバ・アプリケーションは初回のオペレーション呼び出しの際に、コーディネータに対して、トランザクション参加者（リソース・マネージャなど）の登録を行います｡その後、リソースの更新処理を実行します。3.と4.の処理は、呼び出し対象のすべてのサーバ・アプリケーションに対して実行されます。
5. すべての処理が終了したところで、クライアント・アプリケーションはコンテキスト・サービスのcompleteオペレーションを呼び出します（図では、サーバ・アプリケーションからの応答を省略していますが、ここではすべてのサーバから正常応答が返ってきたと仮定します）。
6. コンテキスト・サービスは、コーディネータのcompleteオペレーションを呼び出します｡
7. コーディネータは、あらかじめ登録されたすべてのトランザクション参加者のprepareオペレーションを呼び出して、リソースのコミットが可能かどうかを問い合わせます｡
8. トランザクション参加者は、コミット可能な場合にはvoteCommit応答を返却します。
9. すべてのトランザクション参加者からvoteCommit応答が返却された場合には、コーディネータはトランザクションをコミット可能と判断して、すべてのトランザクション参加者のcommitオペレーションを呼び出します｡
10. トランザクション参加者は、リソースの状態をコミットして、committed応答をコーディネータに返却します。
11. コーディネータはコンテキスト・サービスにcompleted応答を返却します。
12. コンテキスト・サービスは、クライアント・アプリケーションにcompleted応答を返却します。

図3　WS-TXMの2相コミット・プロトコルの例（クリックで拡大します）

　上記で3.のクライアント／サーバ間のメッセージ交換では、SOAPヘッダにACIDトランザクションの情報を含むコンテキストが格納されます。トランザクションIDは、WS-CTXの基本コンテキストのコンテキスト識別子要素に格納でき、また、トランザクション・コーディネータのエンドポイントは、WS-CFの拡張コンテキストにすでに該当要素があるため、ACIDトランザクションでコンテキストとして新たに追加している要素は、トランザクションのタイムアウト値だけです。

　8.で、トランザクション参加者のうち1つでもvoteCommit応答またはvoteReadonly応答を返却しなかった場合（voteRollback応答を返却するかタイムアウトになった場合のいずれか）には、コーディネータはトランザクションをコミット不可と判断して、トランザクション参加者のrollbackオペレーションを呼び出して、トランザクションをロールバックします。こうすることで、トランザクションの原子性が確保されます。

　ここではACIDトランザクション・プロトコルの簡単な例を紹介しましたが、WS-TXMでは、こうした単純なシナリオ以外に、最適化やリカバリ処理を含む複雑なシナリオもサポートしています。

ロング・ラニング・アクション・プロトコル

　ロング・ラニング・アクション・プロトコル（以下、LRAプロトコル）は、自律性を持ったアクティビティ参加者の処理結果を調整するためのプロトコルです。アクティビティ全体が、最終的には成功または失敗のいずれかの結果で終了する点は、ACIDトランザクションと同じですが、失敗した場合に、どのように処理結果を元に戻すのか、あるいは補償するのかは、アプリケーションの設計に任されます｡LRAプロトコルは、補償トランザクション実行のトリガを与えるだけなのです。

　それでは、LRAプロトコルを簡単な例で説明しましょう。ここでは、アクティビティが失敗して、補償トランザクションが実行されるケースを取り上げます｡以下では、図4中の番号に沿って説明します。

1. クライアント・アプリケーションはコンテキスト・サービスのbeginオペレーションを呼び出して、アクティビティの開始を宣言します。
2. コンテキスト・サービスは、あらかじめ登録されたLRAコーディネータALS（以下、LRAコーディネータ）のbeginオペレーションを呼び出します｡
3. クライアント・アプリケーションは、サーバ・アプリケーション（Webサービス）のオペレーションを呼び出して、何らかのビジネス処理を実行します（例えば、ホテルの予約処理）。その結果、アクティビティのコンテキスト情報がSOAPメッセージのヘッダに格納されてサーバ・アプリケーションに伝搬されます。この中には、LRAコーディネータのエンドポイント情報も含まれています｡
4. サーバ・アプリケーションは初回のオペレーション呼び出しの際に、LRAコーディネータに対して、アクティビティ参加者（コンペンセータ）の登録を行います｡その後、リソースの更新処理を実行します。通常、リソースの更新は各サーバ・アプリケーションに閉じてコミットされます。3.と4.の処理は、呼び出し対象のすべてのサーバ・アプリケーションに対して実行されます。
5. サーバ・アプリケーションは、オペレーション呼び出しの応答をクライアントに返却します。
6. いずれかの処理（例えば航空券予約）が失敗した場合、クライアントはアクティビティを失敗と判断し、コンテキスト・サービスのcompleteWithStatusオペレーションを呼び出してアクティビティの取り消しを指示します｡
7. コンテキスト・サービスは、LRAコーディネータのcompleteWithStatusオペレーションを呼び出します｡
8. LRAコーディネータは、あらかじめ登録されたすべてのコンペンセータのcompensateオペレーションを呼び出して、補償トランザクションの実行を指示します（失敗した航空券予約に対しては補償の必要がないのでforgetオペレーションを呼び出します）。
9. 各コンペンセータは補償トランザクションの結果を、compensatedメッセージでLRAコーディネータに通知します。
10. LRAコーディネータは、コンテキスト・サービスにcompletedWithStatus応答を返却します。
11. コンテキスト・サービスは、クライアント・アプリケーションにcompletedWithStatus応答を返却します。

図4　WS-TXMのロング・ラニング・アクション・プロトコルの例 　　　　 （クリックで拡大します）

　LRAプロトコルの簡単な例を紹介しましたが、WS-TXMでは、こうした簡単なシナリオ以外に、複数のLRAを並列に実行したり、あるLRAの結果によって別のLRAを起動するといった複雑なシナリオもサポートしています。例えば図5のように、レンタカーの予約をLRA1で行い、次に3つの航空会社に対して航空券の予約を同時に実行します（LRA2、LRA3、LRA4）。これらの結果から最適な航空会社に対するLRAを確定し、ほかのLRAはキャンセルします。最後に、これと同様にホテル予約のLRAを同時に実行します（LRA5、LRA6）。このようにLRAを組み合わせることで、複雑なビジネス要求に柔軟に対応することが可能になります。

図5　複数のLRAによるアプリケーションの構造化

■標準化戦争の行方

　これまで解説してきたように、現在、BTP、WS-Transaction、WS-CAFという3つのWebサービス・トランザクションの仕様が提案されているわけですが、今後の動向を議論するうえで、これらの仕様の特徴を標準化という点から整理しておきましょう。

BTP

• 標準化ステータスは最も進んでいる（OASIS委員会仕様）
• 仕様としての完成度も最も高い
• ACIDトランザクションはカバーしていない
• テクニカル・コミッティの主要メンバー（BEA、オラクル、サン・マイクロシステムズ）が、ほかのトランザクション仕様をサポート

WS-Transaction

• 業界最大手ベンダ（IBM、マイクロソフト、BEA）が推進
• 標準化団体には未提出
• 仕様の検討過程がオープンではない。誰でもが自由に参加できるわけではない
• 仕様がロイヤルティー・フリーでないため、製品化に当たっては知的所有権上の問題が発生する可能性がある
• ACIDトランザクションとロング・ラニング・トランザクションを含む

WS-CAF

• OASISで標準化が進められている
• ロイヤルティー・フリーのため誰でも無償で実装できる
• ACIDトランザクションとロング・ラニング・トランザクションを含む

　ここまでの話は事実なので、おそらく反論の余地はないと思います｡問題は、標準化戦争が今後どのように展開していくのかという点ですが、ここから先は意見が大きく分かれるところです（念のためにお断りしておきますが、筆者はWS-CAFを推進するベンダに属していますが、この記事は会社の主張を代弁しているわけではなく、あくまでも個人の立場で執筆しています）。

　eWeekは2003年4月の「Spec Unified Web Services」という記事で、Zap Thinkのアナリスト、ロン・シュメルツァー（Ron Schmelzer）氏のWS-CAFに関する次のようなコメントを紹介しています。

　「必要とされているのは共通の重要な問題をベンダ各社が協力のうえで解決することであって、複雑に絡み合った全体の中のごく一部しか解決しない仕様を怒濤（どとう）の勢いで作り出すことではない。このようなことをしていると混乱が増すばかりで、おそらく互換性のない仕様ができあがるだろう。」（日本語訳は＠ITニュース記事）

　前回も述べたように、複数の仕様が乱立している現在の状態は、利用者にとってもベンダにとっても非常に不幸で、シュメルツァー氏の意見はもっともです｡ただし、WS-Transactionの仕様化を大手3社が独占している現状で、それを打開しようとしたWS-CAFの陣営を一方的に責めるのも酷な気がします。その一方で、将来WS-CAFがいまのままOASISオープン標準になったとしても、IBMやマイクロソフトといった最大手が支持しなければ、シュメルツァー氏の不安が現実になってしまうでしょう。

　非常に困難な状況ですが、問題解決の方向として少しでも可能性があるのは、次の2つのいずれかではないでしょうか。

• IBM、マイクロソフト、BEAの3社がWS-Transactionとそれに関連する仕様をすべてロイヤルティー・フリーで標準化団体に提供し、これらの仕様をベースにした標準化作業にWS-CAFのメンバーも参加する。つまり、トランザクション仕様をWS-Transactionに一本化する。
  　
• IBM、マイクロソフト、BEAの3社がWS-CAFに参加し、WS-Transactionの優れた点をWS-CAFに反映させて、統一仕様を作成する。つまり、トランザクション仕様をWS-CAFに一本化する。

　並行して進められている標準化作業の参加者が互いに歩み寄り、ベンダや利用者にとって望ましい決着がつくことを望んでいます。（連載終了）

■バックナンバー

　1 .複雑化するWebサービスの仕様群を整理する
　2. Webサービスのキュリティ技術を詳解する
　3. OASIS WS-SecurityとXKMSの構造を知る
　4. OASIS SAMLとXACMLの構造を知る
　5. Webサービスを連携させるコレオグラフィ
　6. 混迷するWebサービス・トランザクション制御
　7. BtoB基盤となるWebサービス・トランザクション（最終回）

ビジネスWebサービス最新事情

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）