南山大学 数理情報学部 情報通信学科 2007 年度卒業論文要旨集

対話モデルを用いた Web サービスの動的連携に関する研究
2004MT004 浅岡 奈津貴

2004MT006 別所 佑美

2004MT035 伊藤 真智子

指導教員 青山 幹雄

1. はじめに
近年，ユーザ要求の多様化やビジネス環境の急速な変化に柔軟に対応できる Web サービスの開発技術が求められている．現在の Web サービス技術では，サービスの設計時に発見，選択，組み合わせを行ない，実行時に呼び出しを行っている．
本研究は，状況に応じた複合 Web サービスを構築するための対話モデルを用いた Web サービスの動的連携を提案する．

2. Web サービスの動的連携と問題点
2.1. 複合 Web サービス
複合 Web サービスとは，複数の Web サービスを組み合わせて作られた新たな Web サービスである．単体の Webサービスは Web アプリケーションと同様に一つの機能を提供するが，複合 Web サービスは Web サービスの組み合わせによって，さらに高度で新しい機能を提供できる．
2.2. WS-BPEL
WS-BPEL (Web Services Business Process ExecutionLanguage) は XML に基づくビジネスプロセス記述言語であり，複数の Web サービスを組み合わせて複雑な実行フローを記述できる．本研究では複合 Web サービスの構築にWS-BPEL を利用する．
2.3. Web サービスの動的連携
状況によって変化するサービス利用者の要求を満たす
複合 Web サービスを構築するには，Web サービスの動的連携が必要になる．本研究では，動的連携とは，サービスの発見，選択，組み合わせ，呼び出しまでの全てを実行時に行うことと定義した．現状の連携方法である静的連携は，サービスの発見から組み合わせまでを設計時に決定し，サービスの呼び出しのみを実行時に行う．（図 1）
静的連携

動的連携

発見
選択

設計時

組み合わせ
呼び出し

サービス連携の処理の負荷が増大
サービス
要求

選択

呼び出し

サービス
利用

サービス
応答

航空券サービス

結果
宿泊予約サービス

サービスの選択・組み合わせ
複合サービス実行（呼び出し）

サービスリクエスタ

図 1 サービスの動的連携と静的連携の比較

WSDL

UDDI
検索

発見

組み合わせ
実行時

動的連携は静的連携にくらべ，実行時にサービスの発見から組み合わせまでを行うので，その時々の最適なビジネス条件で連携するサービスを決定できる．
2.4. 動的連携の問題点
Web サービスの動的連携の問題を複合 Web サービス構築と実行の二つに分ける．
2.4.1. 複合 Web サービス構築の問題
静的連携では複合Webサービスで利用するサービスの発見，選択，組み合わせを開発者が行っている．動的連携
では，これらの情報を実行時にコンピュータが処理可能な形式で表現しておく必要がある．動的に複合 Web サービスを構築する問題として以下の 2 点があげられる．
(1) サ ー ビ ス の 発 見 に 利 用 さ れ る 情 報 は UDDI
(Universal Description, Discovery and Integration) の照会 API で定義されている．しかし，発見したサービスの中から利用するサービスを選択するために必要な情報の表現方法は定義されていない．
(2) 複合 Web サービスの構築では，利用する Web サー
ビスの選択や実行順序の指定など多数の要求を満たす必要がある．要求の中には同時に満たされなければならないなど要求同士の関連も存在する．これらの相互に関係しあう要求を，コンピュータが処理可能な表現にすることは難しい．
これらを同時に解決し，複合 Web サービスの構築を行うことは困難である．
2.4.2. 複合 Web サービス実行の問題
サービスリクエスタで発見から呼び出しまでを行った場
合の動的連携の仕組みは図 2 のようになる．しかしこの仕組みでは，サービスの情報収集や利用するサービスの選択，組み合わせなどサービスリクエスタ側での処理の負荷が増大するという問題がある．

決済サービス
サービス
要求・応答

サービスプロバイダ

図 2 Web サービスの動的連携の仕組み南山大学 数理情報学部 情報通信学科 2007 年度卒業論文要旨集
対話を用いない場合

対話を用いた場合
サービス
ブローカ

要求
応答

サービス
ブローカ

要求
応答

発見
サービス
リクエスタ

選択

発見
選択

話

組み合わせ

サービス
リクエスタ

対2.5. 前提条件
現在の Web サービスの利用状況において UDDI レジス
トリを利用したサービスの検索，発見の実現例は多くない．
しかし，本研究ではWebサービスはUDDIレジストリに登録され，サービスリクエスタは UDDI レジストリの API を利用してサービスの検索，利用ができると仮定する．

対話を用いた場合

呼び出し

組み合わせ
サービスブローカ
呼び出し

3. アプローチ
問題解決に向けて取り組む課題は以下の 2 点である．
(1) 動的なサービス構築(2) サービスリクエスタで動的連携を実行する処理の負荷の軽減
処理の負荷の問題については，サービスブローカを使いサービス連携をサービスリクエスタから独立させ，サービスリクエスタの負荷の軽減を行う．また，複合 Web サービスの構築において，サービスリクエスタのサービス要求をより適切に連携に反映させるために，対話による複合 Web サービスの構築を提案する．
3.1. サービスブローカ
動的連携のサービスリクエスタの処理の負荷の問題を解決するためにサービスブローカを用いる．サービスブローカを用いた動的連携の仕組みを図 3 に示す．
サービスブローカを用いた場合，サービスの発見，選択，組み合わせ，呼び出しをサービスブローカが行う．連携はサービスブローカ内で実行するため，ビジネスプロセスを解釈し実行する BPEL エンジンをサービスリクエスタが保持しておく必要がない．サービスブローカを導入することで，サービスリクエスタはサービスの要求と提供を受けるのみとなるため，動的連携のための処理の負荷は軽減する．
サービスブローカ
導入前

サービスリクエスタ
要求
サービス
利用

応答

検索
UDDI
結果
要求

複合サービス実行
応答

サービスリクエスタは要求送信と結果受信のみを行う

サービス
プロバイダ

仲介者を設け連携の処理を割り振る
サービスリクエスタ

サービスブローカ
導入後
サービスリクエスタの処理の負荷を軽減

サービスの選択・
組み合わせ

要求
サービス
利用

応答

サービスブローカ
サービスの選択・
組み合わせ

検索
結果
要求

複合サービス実行
応答

UDDI

サービス
プロバイダ

図 4 通常の流れと対話を用いた場合の比較
対話を用いない場合では，サービスリクエスタはサービスブローカに対し，要求を送るのは最初の1回のみである．
よって，この時点で連携するサービスに関する情報を決定しサービスブローカに送る必要がある．また，応答が返ってくるのはサービスの呼び出し後なので，複合 Web サービスが起動するまで，サービスリクエスタはサービス内容を確認できない欠点がある．それに対し，対話を用いた場合，繰り返し対話をすることで，段階ごとに状況の変化に応じて，サービスリクエスタの要求を反映させることが可能になる．これにより，対話することで自由度の高い Web サービス構築が期待される．ただし，対話に関する処理は増加する．

4. 提案する手法
4.1. 対話モデル
サービスブローカで複合 Web サービスの構築を行う場
合，1回の要求の送信と応答の受信では複合Webサービスに求められる要求を満たすことは難しい．そこで，要求と応答を対話として複数回に分割した対話モデルを提案する．
対話を重ねて複合 Web サービスを構築するには，対話中でサービスリクエスタから送信される要求によって決定される情報を明らかにする必要がある．この情報は複合 Webサービスの構築に必要な情報である．本研究では対話モ
デルにおいて複合 Web サービスの構築に必要な情報を決定するために，WS-BPEL2.0 の仕様とその XML Schema からBPEL文書の記述に必要な情報を抽出する．対話モデルと対話モデルに必要な情報抽出を行う流れを図 5 に示す．
1 対話モデルを導入

要求応答
対サービス
リクエスタ

発見

プロセス構築に必要な対話の手順をモデル化

2 対話で決定する情報の抽出
BPELモデル

3.2. 対話型動的連携
対話型の動的連携ではサービスリクエスタとサービスブローカの対話によって，サービスの発見，選択，組み合わせ，呼び出しを行う．サービスリクエスタ，サービスブローカ間の対話を用いない場合と対話を用いた場合の流れを比較して図 4 に示す．

話

図 3 サービスブローカを用いた動的連携

サービス
ブローカ

WSDLを参照

選択WSDL
WSDL

組み合わせ

記述情報を抽出

呼び出し

3 情報を分類して抽出プロセス構築に必要な情報必要な情報考慮したい情報

図 5 対話モデルと対話モデルのための情報抽出南山大学 数理情報学部 情報通信学科 2007 年度卒業論文要旨集
4.2. プロセス構築に必要な情報の抽出
BPEL で複合 Web サービスの記述に必要な要素を構成要素ごとに抽出する．本研究では複合 Web サービスの構成要素として，以下の三つを挙げる．
(1) 複合 Web サービスに参加する Web サービス
(2) Web サービス間で受け渡すデータ(3) Web サービスの実行順序
4.2.1. 複合 Web サービスに参加する Web サービス
BPEL では，複合 Web サービスと複合 Web サービスに参加する Web サービスとの相互作用をパートナリンクとして表現する．利用する Web サービスの指定は，パートナリンクが参照するパートナリンクタイプで行われる．そのため，複合Web サービスに参加する Web サービスの記述に必要な情報は，パートナリンクの記述に必要な情報から得られる．
パートナリンクの記述に必要な情報の抽出方法を図 6 に示す．
partnerLinkのデータ構造(BPEL)
partnerLinkのデータ構造(BPEL)

必須の情報<partnerLink
name=“NCName”
partnerLinkType=“QName”
myRole="NCName"?
partnerRole=“NCName”?
initializePartnerRole="yes|no"?
/>+ポートタイプ名
MEP
インタフェース情報

portTypeのデータ構造（BPEL））
portTypeのデータ構造（BPEL<wsdl:portType name="nmtoken" > *<wsdl:operation name="nmtoken“ parameterOrder="nmtokens"><wsdl:input name="nmtoken"? message="qname"/><wsdl:fault name="nmtoken“ message="qname"/>*記号の意味?: 0回または1回の出現*: 0回以上の出現

図 6 Web サービス決定に必要な情報の抽出方法利用する Web サービスの記述に必要な情報をまとめると以下のようになる．
(1) パートナリンク名，パートナリンクタイプ名，ロール名，ポートタイプ名(2) パートナリンクタイプの相互作用の関係(3) MEP（メッセージ交換パターン）(4) インタフェース情報
インタフェース情報のうち，引数の順序の指定は RPC型を利用する場合にのみ必要である．
4.2.2. Web サービス間で受け渡すデータ
複合 Web サービスでは Web サービス間でデータの受け渡しを行う．Web サービスの連携には，メッセージの型の一致が必要である．メッセージの定義は WSDL の message
要素に記述される．この要素のデータ構造を図 7 に示す．

?: 0回または1回の出現*: 0回以上の出現

表 1 アクティビティの記述に必要な情報

基本アクティビティ

<wsdl:input name="nmtoken"? message="qname"/>リクエスト/レスポンス型の<wsdl:output name="nmtoken"? message="qname"/>
場合

記号の意味

message 要素のデータ構造より，複合Web サービス間のデータのやり取りの表現に必要な情報は以下である．
(1) WSDL の message 要素の name 属性(2) part 要素の name 属性(3) 変数の型指定を行う属性(element 属性 or type 属性)
4.2.3. Web サービスの実行順序
BPEL では構造化アクティビティを再帰的に結合して実行順序を表現する．構造化アクティビティは基本アクティビ
ティと構造化アクティビティで構成される．各アクティビティについて記述に必要な情報を抽出する． 抽出した情報を表 1 に示す．

構造化アクティビティ

ロール名
相互作用の関係
一方向or双方向メッセージ名
変数名変数の定義の形式によって使い分ける

図 7 WSDL の message 要素のデータ構造

パートナリンク
タイプ名

partnerLinkTypeのデータ構造(WSDLを拡張を拡張))
partnerLinkTypeのデータ構造(WSDL</wsdl:operation></wsdl:portType ><message name="nmtoken"> *<part name="nmtoken“
element="qname"?
type="qname"?/> *</message>

パートナリンク名<plnk:partnerLinkType name=“NCName”><plnk:role name=“NCName” portType=“QName” /><plnk:role name="NCName" portType="QName" />?
</plnk:partnerLinkType>

一方向型の場合

messageのデータ構造(WSDL)
messageのデータ構造(WSDL)

アクティビティ名
flow, sequence
scope
if, repeatUntil, whilepickforEach
empty, exit, rethrow
wait
throw
validate
invoke, receive, reply
assign記述に必要な情報
アクティビティ（複数可）
アクティビティ
condition 要素，アクティビティ
onMessage 要素
scope 要素, startCounterValue 要
素 ， finalCounterValue 要 素 ,counterName 属性，parallel 属性
なし
for 要素 or until 要素
faultName 属性
variables 属性
partnerLink 属性，operation属性(extensionAssignOperation 要素
or copy 要素)（複数可）

また，表1 の記述に必要な情報の欄の決定に次のような副次的に情報が必要になる場合がある．
(1) 複数の要素や属性から構成される(2) 複数の要素や属性から必要な情報を選択する(3) 複数列挙が可能な場合，記述順の関係の有無
例として一部を表 2 に示す．
表 2 副次的な情報の記述に必要な情報の一部(1)

副次的な情報onMessage 要素(2)

assign の子要素

(3)

sequence

記述に必要な情報
partnerLink 属性, operation 属性
extensionAssignOperation 要素か
copy 要素の選択情報
アクティビティの順序関連の有無

南山大学 数理情報学部 情報通信学科 2007 年度卒業論文要旨集
4.3. プロセス構築のために考慮したほうが良い情報
複合 Web サービスの構築に考慮したほうが良い情報が存在する．これは BPEL 文書に記述される情報と記述されない情報に分けられる．
4.3.1. BPEL に記述される情報
BPEL 文書のデータ構造で記述が任意である要素や属性が存在する．BPEL 文章上での記述は必須ではないが，サービスリクエスタの要求内容に応じて記述が必要となる．
4.3.2. BPEL に記述されない情報
BPEL 文書には応答時間や信頼性，利用する Web サー
ビスに End-to-End でのセキュリティが確保されているか，といった QoS やセキュリティなど，ビジネスプロセスに対する要求は記述されない．そのため，これらの要求を考慮したい場合は，BPEL 文書から抽出した情報とは別に対話モデル中で考慮する必要がある．

5. 評価と考察
対話モデルを用いた複合 Web サービスの構築に必要な情報を抽出する手法の評価と，この手法が対話モデルの中で果たす役割について考察する．
5.1. プロセス構築に必要な情報の抽出方法の評価
この手法を利用した場合の効果と課題を示す．
5.1.1. 効果(1) 自動的に情報の抽出が可能
情報の抽出は BPEL の XML Schema から行うので，XML 要素と属性の自動的な抽出が可能である．
現在，UDDI レジストリから発見した Web サービスの選択のための統一的な記法はない．そこで，BPEL の仕様から抽出した情報は，複合 Web サービスで利用する Web サービスの決定に必要な情報となるので，Web サービスの選択に利用することも考えられる．
(2) 必須の情報の漏れがない
BPEL はその仕様に沿った BPEL 文書であれば，BPELエンジンで作成したビジネスプロセスの実行が可能である．
そのため，BPEL でのプロセス記述に必要な情報を抽出するこの手法では，実行に必要な情報の不足は起こらない．
5.1.2. 課題(1) XML Schema で表現されない情報の抽出は不可能
BPEL では XML Schema によるデータ定義では要求されないが，プロセスの作成に必要な情報が存在する．これ
らは，仕様書の記述から読み取るかデータ定義の文脈から判断しなければならない．
(2) BPEL に依存
BPEL から抽出した情報は BPEL 独自の情報となる．このため，作成する対話モデル自体が BPEL に依存する．
5.2. プロセス構築に必要な情報の抽出についての考察
プロセス構築に必要な情報の抽出を行うことで，決定する必要がある情報とそうでない情報が明確になった．プロ
セス構築に必要な情報を対話で決定していくことで，従来の対話を用いない方法にくらべプロセスの構築に柔軟性を持たせることが可能になる．

6. 今後の課題
今後の課題として以下の点が挙げられる．
対話モデルの作成
抽出した情報を対話的に決定する手順を表すモデルの作成が必要である．対話モデルの作成には，抽出した情報の間に依存関係が存在するかどうかが問題となる．
(2) QoS やセキュリティなどの情報の記述方法の決定
QoS やセキュリティの情報は，統一的な記述方法が確立されていない．そこで，対話モデルがこれらの要求を受け取る形式を決める必要がある．
(3) 対話の仕組みの決定
サービスブローカとサービスリクエスタ間で行う対話の仕組みが必要である．その際，Web サービスの利点である疎結合性や相互運用性を損なわずに行うことが望まれる．
(1)

7. まとめ
状況の変化に対応した連携を行うために動的連携に注目した．本研究では対話的に複合 Web サービスの構築を行う対話モデルを提案し，対話モデルの中でプロセス構築のために決定する必要のある情報の抽出を行った．情報の抽出により，対話を用いて決定する情報が明らかになった．
抽出した情報を対話的に決定することで，高い柔軟性を持った複合 Web サービスの構築が可能になると期待される．

参考文献
[1]
[2]
[3]

[4]

[5]
[6]

G. Alonso, et al., Web Services, Springer, 2004.
青木 利晴, ほか, Web サービスコンピューティング,
電子情報通信学会, 2005.
E. Christensen, et al., Web Service Definition Language(WSDL),
Version
1.1,Mar.
2001,
http://www.w3.org/TR/2001/NOTE-wsdl-20010315.
D. Jordan, et al., Web Services Business Process
Execution
Language,
V.2.0,
Apr.
2007,
http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-O
S.html.
丸山 宏, ほか, XML と Web サービスのセキュリティ：XML デジタル署名と暗号化，共立出版, 2004．
中村 一仁, 価値モデルに基づく Web サービスの動的選択と価値保証，南山大学大学院数理情報研究科
修士論文, 2006．