Web サービス・ビジネス・プロセス言語の変換機能の試作
和田 清美 秋藤 俊介日立製作所 システム開発研究所
１．はじめに ・ インタラクション型は、送受信するドキュメ
ン ト の 有 無 に よ っ て 、 ５ 種 類 （ Send 型 、 Receive 型 、 SendReceive 型 、 ReceiveSend 型、Empty 型）に分けられる。
W3C などを中心に複数の Web サービスを連携す るためのビジネス・プロセス言語の標準化が活 発になっている。今回、ビジネス・プロセス言 語 の １ つ で あ る Web Services Conversation Language:WSCL[1]から、当社ワークフロー管理 システム WorkCoordinator[2]の記述言語への変 換方式を開発した。本稿では、WSCL のサービス 間の遷移情報に対して、開始から終了まで自動 的に流れるサービス・フローを定義するための 課題と解決方法および実現方法を報告する。 ・ 送受信ドキュメントは、識別子とドキュメン ト型からなる。 ・ ドキュメント型は、XML スキーマで記述する が、実際は XML スキーマのファイルを参照す る URL を指定する。 ・ 遷移は、遷移元と遷移先と遷移条件からなる。 ・ 遷移元と遷移先は、それぞれインタラクショ ン識別子で表す。 ・ 遷移条件は、送信ドキュメントの識別子で表 す。 ２．遷移情報モデルの比較 変換の対象となる WSCL と WorkCoordinator 言 語の遷移情報モデルを、図１に示す。 (2) WorkCoordinator の遷移情報モデル ・ WorkCoordinator は、４種類のノード（業務、 制御、ソース、シンク）と遷移の２つの要素 からなる。 ・ 業務ノードは、識別子と発生条件と完了条件 からなる。但し、発生条件と完了条件は必須 ではない。 ・ 制御ノードは、識別子と制御型からなる。 ・ 制御型は、先着（後続停止あり／なし）、待 合、分岐、分業の５種類がある。 ・ 遷移は、遷移元と遷移先と遷移条件からなる。 ・ 遷移元と遷移先は、それぞれノードの識別子 とノードタイプ（業務／制御）で表す。 ・ 遷移条件は、true/false を出力とする数式 をもつ。 図１．遷移情報モデル n3 インタラクション 遷移 n1 から n3 へ n2 から n1 へ 遷移 n2 インタラクション n1 インタラクション 入力 出力 入力 出力 入力 出力 n1 制御 ノード n3 遷移 遷移 n3 から n4 へ n0 から n1 へ 制御 ノード n2 業務ノード (発生条件) (完了条件) WSCL遷移情報モデル WorkCoordinator遷移情報モデル ３．WSCL から WCO への変換方式の開発 (1) WSCL の遷移情報モデル WSCL は Web サービス間の遷移を定義するが、 ワークフローのように、開始から終了まで自動 的に流れるサービス・フローを定義できない。 これは、あるサービスから別のサービスに遷移 する際、複数の遷移先があり、遷移先が一意に 決まらないために、処理が自動的に流れていか ないからである。そこで、処理の流れを決定す るために、リクエスタからの要求に応じたサー ビスへ遷移できるように、分岐先を指定するた めのノードを追加する。 ・ WSCL は、インタラクション、送受信ドキュ メント、遷移の３つの要素からなる。 ・ インタラクションは、インタラクション型と 識別子をもつ。 D K
evelopment of Transformation of Web Services business process language
iyomi Wada, Shunsuke Akifuji
System Development Laboratory, Hitachi, Ltd.
1099 Ohzenji, Asao, Kawasaki, 215-0013 Japan また、WorkCoordinator 言語では、業務ノード に出入りする遷移は１つと限られており、複数
4−17
の遷移は、制御ノード（先着、待合、分岐、分 業）によって取捨選択される。 そこで、WSCL から WorkCoordinator 言語へ変 換するとき、必要に応じて、分岐先指定ノード と制御ノードを追加し、遷移を変更することに より、サービス・フローを定義した。 変換は、サービス毎に、流入数が複数のとき、 サービスの直前に先着ノードを挿入し、流出数 が複数のとき、サービスの後ろに分岐ノードを 挿入した。また、遷移条件に重複があれば、サ ービスの直後に分岐先指定ノードを挿入した。 これは、各案件が、逐次処理されることを前提 としており、一時に１つのサービスの提供を受 けるが、複数のサービスの提供は受けないとい うことを意味する。なぜなら、WSCL には、案件 に対して並行処理するための記述がないからで ある。 ４．プロトタイプの実装 図２に、ビジネス・プロセス変換プログラム の構成を示す。ビジネス・プロセス変換プログ ラムは、構文解析部、インタラクション情報変 換部、遷移情報変換部、ワークフロー生成部か ら構成される。構文解析部では、WSCL で記述さ れた XML ファイルを入力し、サービス毎の流出 入数を求め、内部情報テーブル（インタラクシ ョン情報と遷移情報）に登録する。インタラク ション情報変換部では、内部情報に基づいて、 インタラクション情報をノード情報（業務ノー ドと制御ノード）に変換する。遷移情報変換部 では、追加した制御ノードと分岐先指定ノード に応じて、遷移情報を変更する。ワークフロー 生成部では、ノード情報と遷移情報を入力して、 WorkCoordinator 言語で記述された XML ファイル を出力する。 http://www.w3.org/TR/wscl10/ 図２．ビジネス・プロセス変換プログラム構成 ５．変換結果 図３に、電子商取引に対する変換結果を示す。 カタログ情報 問合せ ログイン ログアウト 見積もり 発注 出荷 開始 終了 変換前 ログイン カタログ情報 問合せ 見積もり 発注 ログアウト 出荷 在庫あり 在庫なし カタログ請求 発注請求 見積もり請求 ログアウト要求 分岐先指定 先着 分岐 先着 先着 分岐先指定 分岐先指定 分岐 分岐 分岐 見積もり 請求 カタログ 請求 先着 先着 開始 終了 ログアウト要求 発注請求 変換後 在庫あり 在庫なし 図３．電子商取引に対する変換結果 ６．おわりに 標準的な Web サービス・ビジネス・プロセス 言語からワークフローを生成する汎用的な変換 の仕組みをつくるため、Web サービス・ビジネ ス・プロセス言語の１つである WSCL から、当社 ワークフロー管理システム WorkCoordinator の 記述言語への変換方式を定めた。変換プログラ ムを開発し、WSCL 仕様書に記載されている例題 プログラムを用いて、本変換方法の妥当性を確 認した。 構文解析部 WSCL 遷移情報 テーブル WCO言語 インタラクション 情報テーブル ワークフロー生成部 ノード情報 テーブル 遷移情報変換部 ビジネス・プロセス変換プログラム インタラクション情報変換部 WSCL はサービス提供者を定義しないので、 WorkCoordinator で業務の担当者を決める振り分 けルールを定義できなかった。サービス提供者 を静的に定義する場合は、人手で振り分けルー ルを追加できる。 ７．参考文献
[1] Beringer,D., 他 『 Web Services
Conversation Language 1.0』
[2] 船橋他『NetCom ライブラリ-ネットベース・ アプリケーション』裳華房, pp.114-118
