連載 ビジネスWebサービス最新事情(5)
Webサービスを連携させるコレオグラフィ
Webサービスをビジネスで利用するために、高度なセキュリティやトランザクション処理、複数のWebサービスの連携などを実現するさまざまな仕様が策定されようとしている。本連載では、これらの仕様を理解するための解説を行っていく。(編集局) |
日本アイオナテクノロジーズ(株)
服部 和彦
2003/12/16
■コレオグラフィをめぐる2つの仕様
Webサービスは、企業内や企業間におけるアプリケーションの連携や統合を行うための標準技術として大きく期待されています。しかし、Webサービスの基礎技術としてすでに標準化されているWSDLは、ステートレスで単純なWebサービスのインターフェイス定義に限定されるため、Webサービスの複雑な連携を記述するには不十分です。WSDLでは、Webサービスが提供するオペレーションの集合をインターフェイスとして記述しますが、それぞれのオペレーションは独立して記述されるため、複数のオペレーションの依存関係や実行順序などの記述までは行えないからです。
Webサービス・コレオグラフィ記述言語により、WSDLでは記述できない複数のサービスを連携させた、複雑なWebサービス間のプロセス・フローの記述が可能になります。
Webサービスの連携を目的とした仕様としては、OASISで標準化作業が行われているBPEL4WS(Business Process Execution Language for Web Services)と、W3Cで標準化が行われているWSCI(Web Services Choreography Interface)の2つが標準の有力な候補になっています。BPEL4WSとWSCIのどちらの仕様も、WSDLと統合する形でWebサービスの連携を記述します。
しかし、2つの仕様ではそれぞれ異なるアプローチからWebサービスの連携を定義します。BPEL4WSは実行プロセスを中心にWebサービスの連携をコレオグラフィとして記述し、WSCIは個々のWebサービスでの動的なメッセージ交換を中心とした連携をコレオグラフィとして記述します。
■WSCIのプロセス・フロー定義
WSCIは2つのレベルでWebサービスのコレオグラフィを定義します。最初のレベルはWSCIのインターフェイスです。WSCIのインターフェイスは、WSDLで定義されたWebサービスのインターフェイスを基にして、WSDLの複数のオペレーションにまたがるコレオグラフィを定義します。複数のオペレーションにまたがるメッセージ交換の流れを外部的に観察可能な振る舞いとして記述することで、WSCIでは動的なWebサービスのインターフェイスを定義します。WSCIはBPEL4WSと異なり、インターフェイスのメッセージ交換を記述するもので、実際に実行される内部プロセスの記述は行いません。
次のレベルは、WSCIのグローバルモデルです。WSCIのインターフェイスは、メッセージ交換での一方の参加者の観点からのメッセージ交換を記述したものです。複数のWebサービス間でのメッセージ交換の流れにおいては、立場により別のWSCIのインターフェイスを定義する必要があります。WSCIのグローバルモデルでは、WSCIインターフェイスのオペレーションをリンクすることで、複数のWSCIインターフェイス間の関連を定義します。WSCIのグローバルモデルでは、異なるWSCIインターフェイス間のメッセージ交換と、メッセージの流れを中心としたWebサービス全体のプロセス・フローの定義を行います。
図1 WSCIのグローバルモデル |
■BPEL4WSのプロセス・フロー定義
BPEL4WSはWSCIと同様に、WSDLで定義されたWebサービスのインターフェイスを連携させ、複雑なWebサービスのプロセス・フローを実現します。BPEL4WSでは、WSDLによって記述された依存関係にあるWebサービスのインターフェイスを組み合わせて動作させることにより、実行可能なプロセスを定義します。
BPEL4WSで定義されたプロセスは、複数のWebサービスを連携させた複合的なWebサービスになります。Webサービスの連携を実現するためのフローとして記述されたBPEL4WSのプロセスは、オーケストレーション・エンジンやプロセス・エンジンなどで解釈させて実行できます。こうしたプロセス・フローは、プラットフォームや実装方法に依存することなく実行できるように定められています。
図2 BPEL4WSのプロセス・フロー |
■コレオグラフィ記述言語の機能
Webサービスの連携を目的としたコレオグラフィ記述言語は、以下の機能を提供しています。
- 制御構造のサポート
プリミティブなアクティビティから複雑な処理を実現するために制御構造をサポートしています。この制御構造には、直列処理、並列処理、条件分岐、繰り返し処理などがあります。
- 構造化されたスコープのサポート
フローを構造化されたスコープで記述できます。構造化されたスコープにより、トランザクションやそれに関係する補償処理の対象範囲や、例外処理の対象範囲が記述できます。
- コリレーションのサポート
Webサービス間のメッセージ交換の中で、複数のメッセージ間の関連付けを行うのがコリレーションです。コリレーションにより、複雑なWebサービスの処理においてもメッセージの相関性を判断でき、ステートフルなメッセージの交換を行うことが可能になります。
- イベント処理のサポート
メッセージの受信やタイマーからの通知などのイベントにより、アクティビティの開始や再開などの制御を行うことができます。
- 例外処理のサポート
スコープの階層構造を利用した例外処理をサポートします。例外ハンドラはスコープ内で発生した例外に対して適切なアクティビティを実行できます。
- ロング・ランニング・トランザクションの補償処理のサポート
スコープの階層構造を利用したトランザクションの補償処理をサポートします。ロング・ランニング・トランザクションの実行中に例外が発生した場合、トランザクション内のすでに終了した一部のアクティビティや複数アクティビティの状態を、補償処理により取り消しまたは補正します。
■WSCIの記述例
WSDLによるサービスの記述からどのようにWSCIのインターフェイスを記述するのかを、簡単なWebサービスの連携を例に説明します。この例では、顧客は欲しい商品をオンラインショップで予約し、その後十分な検討を行い、商品を購入するかどうか判断できます。購入する場合には、オーダーを送信します。この場合、オンラインショップから購入明細書が送信されます。購入しない場合には、予約のキャンセルを送信します。
まずは、Webサービスの静的なインターフェイスを定義するごく普通のWSDLです。このWSDLのメッセージ定義とポートタイプ定義は、WSCIインターフェイスから参照されます。
<definitions |
リスト1 Webサービスの静的なインターフェイス記述 |
次のWSDLではWSCIのインターフェイスの記述をしています。WSDLのdefinitions要素の中にWSCIインターフェイスを記述します。ItemCorrelationはコリレーションの定義をします。これにより、同じitemIDを持つメッセージを相関関係のあるメッセージと判断できます。
<definitions |
リスト2 WSCIのインターフェイス記述 |
WSCIインターフェイスに含まれるWSCIプロセスにWebサービスの動的な振る舞いを記述します。プロセスには、動的な振る舞いを表すためにアクティビティが含まれます。この場合には、シーケンス(<sequence>)がそれに当たります。シーケンスは、内部に定義されたサブ・アクティビティを順番どおりに実行する構造アクティビティです。シーケンス内部の最初の動作として、パートナーの顧客から商品の予約の処理を行うReceiveReservationアクションが実行され、顧客に予約結果を返却します。
発生するイベントの条件により実行するアクティビティを選択するチョイス(<choice>)が次のアクティビティです。この例では、メッセージの種類により動作が変わるように記述されています。顧客からorderRequestメッセージを受信した場合には、ReceiveOrderアクションを実行します。コリレーションの記述があるので、ReceiveOrderアクションは相関関係にあるReceiveReservationアクションから状態を引き継ぐことができます。そして、orderReplyメッセージを顧客に返却します。次に、同じ条件分岐内のSendStatementアクションが実行され、顧客にstatementメッセージが返却されます。顧客からorderRequestの代わりにcancelRequestが送信された場合には、CancelOrderアクションが実行されます。
図3 WSCIのメッセージ交換フロー |
簡単な例ですが、以上のようにWSCIインターフェイスを記述することで、Webサービスの複数のオペレーションを関連付け、外部とのメッセージ交換のフローを記述できます。
■BPEL4WSの記述例
WSDLによるサービスの記述からどのようにBPEL4WSのプロセスを記述するのかを、簡単なWebサービスのフローの集約を例に説明します。この例では、顧客と工場という2つのパートナーとメッセージを交換する代理店のプロセスを扱います。顧客から商品の発注メッセージを受信すると、代理店は工場に対して発注メッセージを送信し、工場からの応答メッセージを待ちます。工場から発注が可能かどうかの応答メッセージを受信すると、代理店は顧客に応答メッセージを返送します。このプロセス・フローでは、代理店は、工場が代理店に提供しているインターフェイスと同じインターフェイスを顧客に提供しています。
まずは、BPEL4WSのプロセス・フローを構成するWebサービスのインターフェイスを定義する簡単なWSDLです。このWSDLのメッセージ定義とポートタイプの定義を参照し、組み合わせることによりBPEL4WSのプロセス・フローを記述します。
<definitions |
リスト3 Webサービスの静的なインターフェイス記述 |
次のWSDLではプロセス・フローで使用されるサービスのパートナーについて、<partnerLinkType>要素で記述を行います。代理店は工場と同一のインターフェイスを提供しているので、パートナーの役割(ロール)の記述は1つだけです。
<definitions |
リスト4 パートナーとロールを記述 |
リスト3とリスト4の2つのWSDLを基にBPEL4WSのプロセスを構成します。ここでは、プロセスの実行に必要なパートナーとの関係を<parterLinks>要素で記述します。プロセスとパートナーが担う役割はmyRole/partnerRoleで定義します。アクティビティ間のメッセージの受け渡しに使用する<variables>要素を定義します。プロセスにはアクティビティを1つだけ定義できます。この場合には、アクティビティはアクティビティの直列処理を実行するシーケンス(<sequence>)です。シーケンスの最初のアクティビティは、メッセージの送信を待つ<receive>アクティビティです。パートナーである顧客からのメッセージを受信したら、次に<invoke>アクティビティはパートナーである工場のサービスの実行を行い、その結果をプロセスが顧客に提供しているサービスの結果として送信します。
<process |
リスト5 BPEL4WSのプロセス記述 |
プロセス・フローの実行は図4のように行われます。プロセスの実行はパートナーである顧客からのメッセージの受信を待つ<receive>で待機します。顧客からメッセージを受信すると、プロセスのインスタンスが作成されプロセスの実行が開始されます。受信したメッセージはRequest変数に書き込まれます。次に実行される<invoke>アクティビティは、Request変数に書き込まれているメッセージを取り出し、パートナーである工場のサービスを呼び出し、結果をResult変数に入れます。次に<reply>アクティビティが実行され、Result変数からメッセージを組み立て、顧客にサービスの結果が送信されます。
図4 BPEL4WSのプロセス・フロー |
簡単な例ですが、以上のようにBPEL4WSのプロセスを記述することで、Webサービスの複数のオペレーションを集約し、実行可能なプロセス・フローを記述できます。
◆
今回は、簡単な例を含めてWebサービスの連携や統合を行うWebサービスのコレオグラフィ関連仕様であるWSCIとBPEL4WSの解説をしました。次回はWebサービス・トランザクション仕様の最新事情と、トランザクション仕様が実現しようとしている基本機能を解説します。(次回に続く)
注意 今回の解説では例を簡略化するために一部に通知型(Notification)のWebサービスのオペレーションを使用しています。しかし、通知型のオペレーションの使用はWS-Iでは禁止されており、推奨されていない使用方法です。 |
■バックナンバー
1 .複雑化するWebサービスの仕様群を整理する
2. Webサービスのキュリティ技術を詳解する
3. OASIS WS-SecurityとXKMSの構造を知る
4. OASIS SAMLとXACMLの構造を知る
5. Webサービスを連携させるコレオグラフィ
6.
混迷するWebサービス・トランザクション制御
7.
BtoB基盤となるWebサービス・トランザクション(最終回)
ビジネスWebサービス最新事情 |
- QAフレームワーク:仕様ガイドラインが勧告に昇格 (2005/10/21)
データベースの急速なXML対応に後押しされてか、9月に入って「XQuery」や「XPath」に関係したドラフトが一気に11本も更新された - XML勧告を記述するXMLspecとは何か (2005/10/12)
「XML 1.0勧告」はXMLspec DTDで記述され、XSLTによって生成されている。これはXMLが本当に役立っている具体的な証である - 文字符号化方式にまつわるジレンマ (2005/9/13)
文字符号化方式(UTF-8、シフトJISなど)を自動検出するには、ニワトリと卵の関係にあるジレンマを解消する仕組みが必要となる - XMLキー管理仕様(XKMS 2.0)が勧告に昇格 (2005/8/16)
セキュリティ関連のXML仕様に進展あり。また、日本発の新しいXMLソフトウェアアーキテクチャ「xfy technology」の詳細も紹介する
|
|