JP2002245152A - サービス仲介処理装置，サービス仲介処理方法およびサービス仲介処理用プログラム - Google Patents

Abstract

(57)【要約】 【課題】 計算機上で実現されている複数の要素サービ
スを統合して複合サービスとして提供するシステムを容
易に構築できるようにすることを目的とする。 【解決手段】 仲介エージェント１０は，各要素サービ
スについて，要素サービス主体の識別情報と，その要素
サービスの実現に対して必要とされる情報の宣言的記述
情報と，その要素サービスの処理結果に関する宣言的記
述情報との組み合わせからなるサービス記述情報をサー
ビス記述保存部１７に記憶しておき，ユーザエージェン
ト３０から複合サービスに対する要求メッセージを受信
したときに，依頼計画生成部１３により，サービス記述
情報を利用して複合サービスを要素サービスに分解し，
少なくとも複合サービスを実現するために必要な要素サ
ービス依頼情報と要素サービス主体の識別情報との組み
合わせの列からなる要素サービス依頼計画を生成する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は，計算機上の複数の
要素的なサービスを統合して，複合的なサービスを提供
するサービス統合システムを実現するためのサービス仲
介処理装置に関する。このようなシステムは，ＥＣ（El
ectronic Commerce;電子商取引) 全般や，ＥＡＩ（Ente
rprise Application Integration）, ＥＩＰ（Enterpri
se Information Portal ）などの広汎な分野に応用可能
である。

【０００２】

【従来の技術】ユーザに対して何らかの情報を提供する
ような計算機システム上の複数の情報サービスを統合
し，仮想的な一つの情報源として見せるようなシステム
は，ソフトウェアエージェントの代表的な応用例として
すでに広く知られている。このようなシステムには，複
数の関係データベースを統合するものや，複数の文書検
索エンジンを統合するようなものが知られている。

【０００３】これらの仮想統合システムでは，多くの場
合，複数の情報源を統合するための仲介システムが用い
られている。仲介システムは，情報源が提供可能な情報
内容の宣言的記述を保持しており，これを利用してユー
ザからの問い合わせに対して回答可能な情報源を判断し
た後，そこへ問い合わせを転送するような枠組を採用し
ているものが多い。

【０００４】

【発明が解決しようとする課題】以上のような従来の複
合サービスは，あくまでも複数の情報源の仮想統合に限
定されたものであり，これを情報提供サービスに限定さ
れない，より一般的なサービスの統合に適用することは
できなかった。

【０００５】例えば，すでにフライト予約システムと，
ホテル予約システムとが存在し，これらのシステムが提
供する二つのサービスを統合して旅行予約システムを構
築しようとした場合，既存のフライト予約システムおよ
びホテル予約システムのそれぞれとの固有のインタフェ
ースを持つ仲介システムを作成する必要がある。このた
め，従来，複合サービスを実現するための仲介システム
などの開発コストが大きいという問題があった。

【０００６】さらに，複合サービスに新しい要素サービ
スを追加しようとした場合や，既存の要素サービスのサ
ービス内容を変更しよとした場合などに，仲介システム
の再構築が必要になり，サービスの拡張や変更が困難で
あるという問題があった。具体的には，上記旅行予約シ
ステムに新たにレンタカー予約サービスを組み込みたい
というような要求があった場合に，レンタカー予約サー
ビスを提供する既存のレンタカー予約システムとの間の
固有のインタフェースを仲介システムに組み込む必要が
あり，そのため仲介システムのプログラムを大幅に改変
する必要があった。

【０００７】本発明は上記問題点の解決を図り，計算機
上で実現されている複数の要素サービスを統合して複合
サービスとして提供するようなサービス統合システムを
容易に構築でき，またサービスの拡張や変更に容易に対
応できるシステムを実現することを目的としている。

【０００８】

【課題を解決するための手段】上記課題を解決するた
め，本発明は，計算機上で実現された複数の要素的なサ
ービスを統合した複合サービスを提供するためのサービ
ス仲介処理装置において，要素サービス主体のＩＤ情報
と，その要素サービスの実現に対して必要とされる情報
の宣言的記述情報と，その要素サービスの処理結果に関
する宣言的記述情報との組み合わせを利用して，複合サ
ービスを要素サービスに分解する機構を持ち，複合サー
ビスを実現するために必要な要素サービス依頼情報と，
要素サービス主体ＩＤ情報との組み合わせの列からなる
要素サービス依頼計画を生成する。これにより，複数の
要素的なサービスを使った複合サービスを簡便に使用す
る方法を提供することが可能になる。

【０００９】この要素サービス依頼計画を生成した後
に，実際に要素サービスの主体に要素サービスを依頼
し，その処理結果をまとめて複合サービスの処理結果を
作成する。これにより，複数の要素的なサービスを使っ
た複合サービスを簡便に構築することが可能になる。

【００１０】要素サービス依頼計画を生成した後に，外
部からの要求に応じてその依頼計画を伝達する手段を設
けてもよい。これにより，複数の要素的なサービスを使
った複合サービスを外部プログラムが簡便に使用するこ
とが可能になる。

【００１１】また，上記要素サービス主体のＩＤ情報
と，その要素サービスの実現に対して必要とされる情報
の宣言的記述情報と，その要素サービスの処理結果に関
する宣言的記述情報との組み合わせを要素サービス主体
などの外部から受け取り，それを内部に動的に登録する
機構を持つ。これにより，要素サービスを記述する情報
の変化を動的にシステムに反映させることが可能にな
る。

【００１２】上記要素サービスの処理結果に関する宣言
的記述情報と，そのサービスの実現に対して必要とされ
る情報の宣言的記述情報は，例えばオブジェクト指向言
語のクラスやオブジェクトを用いて表現することもでき
る。これにより，既存の言語処理系を本発明のシステム
構築に利用することが可能になる。

【００１３】要素サービスの処理結果に関する宣言的記
述情報と，そのサービスの実現に対して必要とされる情
報の宣言的記述情報に使用される語彙の定義情報（オン
トロジ）とを独立して管理する。これにより，要素サー
ビスの処理結果の記述情報と，語彙の定義情報とを独立
に扱うことが可能になり，システムの可読性，拡張性が
向上する。

【００１４】また，上記要素サービスの実現に対して必
要とされる情報の宣言的記述情報と，その要素サービス
の処理結果に関する宣言的記述情報以外に，要素サービ
ス主体自体の性質を記述したメタ情報も加味して要素サ
ービス依頼計画を作成することもできる。これにより，
要素サービスに対する多様な情報を依頼計画の作成に反
映させることが可能になる。

【００１５】また，上記サービスの実現に対して必要と
される情報の宣言的記述情報と，その要素サービスの処
理結果に関する宣言的記述情報以外に，ユーザの要素サ
ービスに対するアクセス権情報も加味して要素サービス
依頼計画を作成することもできる。これにより，ユーザ
が使用できる要素サービスが，アクセス権を所持してい
るものだけに制限され，システムのセキュリティが向上
する。また，アクセス権のない要素サービスに対する処
理依頼が起こらないため，無駄なトラヒックや処理の発
生を抑制することができる。

【００１６】さらに，上記サービスの実現に対して必要
とされる情報の宣言的記述情報と，その要素サービスの
処理結果に関する宣言的記述情報以外に，要素サービス
の回線速度や処理速度の情報も加味して要素サービス依
頼計画を作成することもできる。これにより，同種の要
素サービスが複数ある場合には，その通信や処理の効率
が高いものを選択して依頼計画を立てることが可能にな
る。

【００１７】さらにまた，上記サービスの実現に対して
必要とされる情報の宣言的記述情報と，その要素サービ
スの処理結果に関する宣言的記述情報以外に，要素サー
ビスのユーザ選好度の情報も加味して要素サービス依頼
計画を作成することができる。これにより，同種の要素
サービスが複数ある場合には，ユーザの選好度が高いも
のを選択して依頼計画を立てることが可能になる。

【００１８】以上の各手段は，サービス仲介処理装置が
備える計算機に実行させるソフトウェア・プログラムに
よって実現することができる。このソフトウェア・プロ
グラムは，計算機が読み取り可能な可搬媒体メモリ，半
導体メモリ，ハードディスクなどの適当な記録媒体に格
納することができる。

【００１９】

【発明の実施の形態】本発明の実施の形態として，計算
機上の一般的な要素的サービスを会話型エージェント系
を用いて統合する場合の例を説明する。ここでいうサー
ビスとは，単なる情報源としての働きに限定せず，ユー
ザに対して何らかの計算機上の処理を提供するもの一般
を考える。また，そのような処理結果を宣言的記述とし
てユーザに返すことも仮定する。

【００２０】「宣言的記述」とは，記述の対象について
これは何であるのか（Ｗｈａｔ）を書いたものである。
これと対比されるものとして「手続き的記述」があり，
こちらは記述の対象について，そのやり方（Ｈｏｗ）を
書いたものである。宣言的記述は，主に事実や規則の記
述に用いられ，手続き的記述は手続きや関数の記述に使
用される。

【００２１】図１は，本発明の実施の形態に係るシステ
ム全体の構成例を示す。本システムは，図１に示すよう
に，仲介エージェント１０，要素サービスエージェント
２０Ａ，２０Ｂ，…，ユーザエージェント３０からな
り，これらは図示省略したネットワークを通して通信可
能に接続されている。

【００２２】これらの各エージェントは，計算機とその
計算機が実行するソフトウェア・プログラムとによって
実現され，各要素サービスエージェント２０Ａ，２０
Ｂ，…は，それぞれ独自の要素サービスＡ，Ｂ，…を提
供する。ユーザエージェント２０は，要素サービスＡ，
Ｂ，…のいくつかを統合した仮想的な複合サービスを享
受する処理装置である。図１では，ユーザエージェント
３０を一つだけ示しているが，もちろんいくつあっても
よい。

【００２３】仲介エージェント１０は，ユーザエージェ
ント２０と各要素サービスエージェント２０Ａ，２０
Ｂ，…との間に介在し，ユーザエージェント２０が各要
素サービスエージェント２０Ａ，２０Ｂ，…の存在を意
識することなく，複合サービスを受けることができるよ
うにする機能を持つ。

【００２４】例えば要素サービスＡはフライト予約サー
ビス，要素サービスＢはホテル予約サービス，…，要素
サービスＣはレンタカー予約サービスといったサービス
であり，これらを提供する各要素サービスエージェント
２０Ａ，２０Ｂ，…は，既存のものをエージェント化し
たものでよい。仲介エージェント１０は，これらの要素
サービスを組み合わせた複合サービスをユーザエージェ
ント３０に対して提供するものであって，後に詳述する
ように，サービス記述保存部１７に記憶した要素サービ
ス主体の識別情報，その要素サービスの実現に対して必
要とされる情報の宣言的記述情報，およびその要素サー
ビスの処理結果に関する宣言的記述情報の組み合わせか
らなるサービス記述情報を利用し，ユーザエージェント
３０からの複合サービスの要求に対して各要素サービス
エージェント２０Ａ，２０Ｂ，…に処理を依頼するため
の依頼計画を生成し，ユーザエージェント３０が複合サ
ービスを享受できるようにする。

【００２５】なお，要素サービスエージェント２０Ｃの
ように，要素サービスエージェントが仲介エージェント
１０との間で統一的な入出力インタフェースを持たない
場合には，要素サービスエージェントと仲介エージェン
ト１０との間に入出力データ変換部４０を設け，入出力
データを所定のフォーマットに変換して入出力インタフ
ェースの統一化を図る。

【００２６】図２は，仲介エージェント（サービス仲介
処理装置）１０の構成例を示している。仲介エージェン
ト１０は，メッセージ送受信部１１，メッセージ処理エ
ンジン１２，依頼計画生成部１３，依頼計画実行部１
４，依頼計画送信部１５，サービス記述登録部１６，サ
ービス記述保存部１７，オントロジ保存部１８を備え
る。

【００２７】メッセージ送受信部１１は，外部のエージ
ェントとの間でメッセージを送受信する。メッセージ処
理エンジン１２は，メッセージの種類に応じて受信した
メッセージに対する処理を行う。

【００２８】依頼計画生成部１３は，複合サービスに対
する要求メッセージに対して，複合サービスを要素サー
ビスに分解し，少なくとも複合サービスを実現するため
に必要な要素サービス依頼情報と，要素サービス主体の
識別情報との組み合わせの列からなる要素サービス依頼
計画を生成する。この依頼計画生成部１３は，要素サー
ビスの実現に対して必要とされる情報の宣言的記述情報
および要素サービスの処理結果に関する宣言的記述情報
以外に，要素サービス主体自体の性質を記述したメタ情
報を加味して要素サービス依頼計画を作成する。メタ情
報として，例えばユーザの要素サービスに対するアクセ
ス権情報，要素サービスの回線速度もしくは処理速度に
関する情報，要素サービスのユーザ選好度の情報を用い
ることができる。

【００２９】依頼計画実行部１４は，依頼計画生成部１
３が生成した要素サービス依頼計画をもとに，実際に各
要素サービス主体である要素サービスエージェント２０
Ａ，２０Ｂ，…に要素サービスを依頼し，その処理結果
をまとめて複合サービスの処理結果を作成し，要求元の
ユーザエージェント３０へメッセージ送受信部１１を介
して通知する。依頼計画送信部１５は，依頼計画生成部
１３が生成した要素サービス依頼計画について，その計
画を実行するのではなく，その計画情報をそのまま要求
元のユーザエージェント３０へ返送する。サービス記述
登録部１６は，外部のエージェントからサービス記述の
登録要求メッセージを受信すると，必要に応じて資格チ
ェックおよび内容チェックを行った後，サービス記述保
存部１７に登録・保存する。

【００３０】サービス記述保存部１７は，各要素サービ
スエージェント２０Ａ，２０Ｂ，…が提供する要素サー
ビスについて，要素サービス主体の識別情報と，その要
素サービスの実現に対して必要とされる情報の宣言的記
述情報と，その要素サービスの処理結果に関する宣言的
記述情報との組み合わせからなるサービス記述情報を記
憶する手段である。要素サービス主体の識別情報とは，
各要素サービスエージェント２０Ａ，２０Ｂ，…に対し
てユニークに付与されたＩＤ情報またはエージェント名
である。

【００３１】オントロジ保存部１８は，要素サービスの
実現に対して必要とされる情報の宣言的記述情報および
要素サービスの処理結果に関する宣言的記述情報に使用
される語彙の定義情報（これをオントロジという）を記
憶する手段である。

【００３２】図３は，サービス記述保存部１７に保存す
るデータの構成例を示す。この例は，サービス記述をテ
ーブル形式で保存する場合の例であり，テーブル名は
「SERVICE 」となっている。図３のテーブルにおいて，
「agent-name」のフィールドには，要素サービスエージ
ェントの名前（識別情報）が格納され，「request-in」
のフィールドには，要素サービスの実現に対して必要と
される宣言的記述情報が格納され，「result-out」のフ
ィールドには，要素サービスの処理結果に関する宣言的
記述情報が格納される。

【００３３】サービス記述保存部１７に，これらの情報
をテーブル形式で保持するのではなく，例えば要素サー
ビスの実現に対して必要とされる情報の宣言的記述情報
および要素サービスの処理結果に関する宣言的記述情報
を，オブジェクト指向言語のクラスまたはオブジェクト
で表現することもできる。

【００３４】図４は，オントロジ保存部１８に保存する
データの構成例を示す。オントロジについてもテーブル
化されたデータ構造を持ち，要素サービスの実現に対し
て必要とされる情報の宣言的記述情報および要素サービ
スの処理結果に関する宣言的記述情報ごとに，それらに
使用される語彙の定義情報がテーブルのフィールド名と
して与えられる。すなわち，オントロジは，フィールド
名だけのテーブルとして表現され，各フィールド値は持
たない。

【００３５】図２中のサービス記述保存部１７，オント
ロジ保存部１８は，仲介エージェント１０の内部にある
データベースとして表現されているが，これらは情報提
供を行う独立した要素サービスとして，仲介エージェン
ト１０の外部にあるエージェントの形で実現することも
可能である。

【００３６】図５は，仲介エージェント１０の処理フロ
ーチャートである。図５の例は，仲介エージェント１０
が依頼計画を生成すると，その依頼計画を実行し，最終
的な処理結果のみをユーザエージェント３０に返信する
場合の例である。

【００３７】仲介エージェント１０は，ユーザエージェ
ント３０からの依頼メッセージ(request) や各要素サー
ビスエージェント２０Ａ，２０Ｂ，…からの回答メッセ
ージ（result）の受信を待つ（ステップＳ１０，Ｓ１
１）。メッセージを受信すると，そのメッセージが依頼
メッセージであるかどうかを判定する（ステップＳ１
２）。依頼メッセージでない場合，ステップＳ１５へ進
む。

【００３８】受信したメッセージがユーザエージェント
３０からの複合サービスの依頼メッセージである場合，
依頼計画生成部１３を起動し，サービス記述保存部１７
が保持するサービス記述と，オントロジ保存部１８が保
持するオントロジとを用いて，複合サービスを要素サー
ビスに分解し，要素サービスエージェント２０Ａ，２０
Ｂ，…への依頼計画を生成する（ステップＳ１３）。

【００３９】依頼計画実行部１４は，依頼計画生成部１
３が生成した依頼計画に基づき，該当する要素サービス
エージェント２０Ａ，２０Ｂ，…に依頼メッセージを送
信し（ステップＳ１４），その応答を待つ。

【００４０】受信したメッセージが要素サービスエージ
ェント２０Ａ，２０Ｂ，…からの回答メッセージであっ
た場合（ステップＳ１５），ステップＳ１６へ進む。な
お，依頼メッセージでも回答メッセージでもなかった場
合，そのメッセージの種類に応じた処理を行う。

【００４１】要素サービスエージェント２０Ａ，２０
Ｂ，…から回答メッセージを受信した場合，その回答結
果を保存し（ステップＳ１６），その回答に応じて新し
い依頼計画の生成が必要であるかどうかを判定し（ステ
ップＳ１７），必要であればステップＳ１３へ移って新
しい依頼計画の生成（前に生成した依頼計画の変更を含
む）を行う。新しい依頼計画の生成が必要でなければ，
依頼計画に基づくすべての依頼メッセージに対する回答
メッセージを受信したかどうかを判定する（ステップＳ
１８）。すべての回答メッセージを受信したならば，各
要素サービスエージェント２０Ａ，２０Ｂ，…からの処
理結果をまとめて，ユーザエージェント３０に対する回
答メッセージを作成し，それをユーザエージェント３０
に返信する（ステップＳ１９）。まだ，すべての回答メ
ッセージを受信していない場合，ステップＳ１０へ戻
り，要素サービスの依頼に対する回答メッセージの受信
を待つか，またはステップＳ１４へ移り，依頼計画にお
いてまだ依頼していない次の依頼メッセージを該当する
要素サービスエージェント２０Ａ，２０Ｂ，…へ送信す
る。以上の処理を各メッセージに対して繰り返す。

【００４２】図６は，仲介エージェント１０の処理フロ
ーチャートであって，特に要素サービスエージェント２
０Ａ，２０Ｂ，…からのサービス記述メッセージに対す
る処理の例を示している。図６のステップＳ２０，Ｓ２
１は，図５のステップＳ１０，Ｓ１１と同じ処理であ
る。

【００４３】仲介エージェント１０は，他のエージェン
トからのメッセージの受信を待ち（ステップＳ２０），
メッセージを受信すると，そのメッセージがサービス記
述メッセージであるかどうかを判定する（ステップＳ２
２）。要素サービスエージェント２０Ａ，２０Ｂ，…，
または他のエージェント等からのサービス記述メッセー
ジであった場合，サービス記述登録部１６を呼び出し，
必要に応じてサービス記述登録に関する資格チェックや
内容チェックを行った後，メッセージ中のサービス記述
をサービス記述保存部１８に保存する。その後，ステッ
プＳ２０へ戻り，次のメッセージを待つ。

【００４４】図７は，仲介エージェント１０の処理フロ
ーチャートであって，ユーザエージェント３０からの依
頼メッセージに対して，要素サービスエージェント２０
Ａ，２０Ｂ，…に対する依頼計画を生成し，その依頼計
画をユーザエージェント３０に返信する場合の例であ
る。依頼計画の実行は，依頼計画を受け取ったユーザエ
ージェント３０が行う。

【００４５】仲介エージェント１０は，ユーザエージェ
ント３０からの依頼メッセージ(request) の受信を待つ
（ステップＳ３０，Ｓ３１）。メッセージを受信する
と，そのメッセージがユーザエージェント３０からの複
合サービスのための依頼計画生成に関する依頼メッセー
ジであるかどうかを判定する（ステップＳ３２）。依頼
メッセージでない場合，メッセージの種類に応じた他の
処理を行う。

【００４６】受信したメッセージがユーザエージェント
３０からの依頼メッセージである場合，依頼計画生成部
１３を起動し，サービス記述保存部１７が保持するサー
ビス記述と，オントロジ保存部１８が保持するオントロ
ジとを用いて，複合サービスを要素サービスに分解し，
要素サービスエージェント２０Ａ，２０Ｂ，…への依頼
計画を生成する（ステップＳ３３）。依頼計画送信部１
５は，依頼計画生成部１３が生成した依頼計画を要求元
のユーザエージェント３０へ通知メッセージを使って送
信する（ステップＳ３４）。その後，ステップＳ３０へ
戻り，次のメッセージの受信を待つ。

【００４７】図８は，本発明を適用したサービス統合シ
ステムの構築フローチャートを示す。要素サービス提供
システムが複数存在する場合に，それらを組み合わせた
複合サービスを提供するためのサービス統合システムを
構築するには，まず，各要素サービス提供システムを会
話型エージェント化する（ステップＳ４０）。このと
き，必要に応じて図１に示す入出力データ変換部４０を
付加する。次に，各要素サービスのサービス記述をサー
ビス記述保存部１７に登録し（ステップＳ４１），また
必要なオントロジをオントロジ保存部１８に登録する
（ステップＳ４２）。

【００４８】次に，サービス統合システムの構築方法や
依頼計画の生成方法などについて，具体例に従って説明
する。以下の具体例は，フライト予約サービスとホテル
予約サービスとが別個のシステムで提供されており，こ
れらを利用して新たに旅行予約サービスを構築する場合
の例である。

【００４９】例えば，ユーザのためにフライト予約を行
うサービスが存在しており，このサービスは，予約者
名，出発空港，到着空港，出発日をユーザが与えると適
切なフライト予約を行うことが可能になっているものと
する。なお，このフライト予約サービスのように，複合
サービスを構成する個々の要素的サービスを，要素サー
ビスという。予約処理が行われた結果として，このサー
ビスは，フライト予約ＩＤ，フライト名，出発空港，到
着空港，出発時刻，到着時刻の情報をユーザに返す。こ
のような状況をフレーム型データ構造を利用して記述す
ると以下のようになる。フレームとは，例えば −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− （［フレーム名］ （＜スロット名＞ ＜スロット値＞） （＜スロット名＞ ＜スロット値＞） ・・・・） ……（式１） −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− というようなシンタックスを持ったデータ構造である。

【００５０】今の場合，このフライト予約サービスは， −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− （［フライト予約要件］ （予約者名 −−−） （出発空港 −−−） （到着空港 −−−） （出発日 −−−）） ……（式２） −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− のようなユーザからの入力を表現したフレーム（スロッ
ト値は省略）を受け入れて，実際にフライト予約を行
い，以下のような予約処理結果を表現したフレーム（ス
ロット値は省略）を返すシステムであるとみなすことが
できる。 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− （［フライト予約］ （フライト予約ＩＤ） （フライト名） （出発空港 −−−） （到着空港 −−−） （出発時刻 −−−） （到着時刻 −−−）） ……（式３） −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− このフライト予約システムを標準的な手法で会話型エー
ジェント化（エージェント名：flight-agent）するに
は，システムを適切なコードでラップして外部との通信
機能を設け，さらに上記のようなフレームを含むメッセ
ージのやりとりを可能にすればよい。なお，システムを
適切なコードでラップするとは，具体的には，既存のフ
ライト予約システムが，上記フレーム形式による入出力
インタフェースを持たない場合に，既存の入出力データ
フォーマットを，上記フレーム形式による入出力のデー
タフォーマットに変換するプログラムを，既存システム
の入出力部分に付加することを意味する。図１に示す入
出力データ変換部４０がこのプログラムに相当するもの
である。

【００５１】例えば，ユーザからの予約を依頼するメッ
セージとして， −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− （request ：content （［フライト予約要件］ （予約者名 "John Doe" ） （出発空港 "成田" ） （到着空港 "ヒースロー" ） （出発日 "2000/01/01" ）） ：sender user-agent ：receiver flight-agent ） ……（式４） −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− というメッセージを定義する。

【００５２】メッセージの冒頭部分は，メッセージの種
別を示すものであり，この場合の「request 」は，「：
content 」でタグ付けされた内容を要件とする処理を依
頼していることを示す。「：sender」と「：receiver」
は，このメッセージを送信するエージェント名と受信す
るエージェント名に付けられるタグである。また，「us
er-agent」は，ユーザに代行してこのようなメッセージ
の送受信を行うエージェント（図１のユーザエージェン
ト３０）の名前である。実際の通信は，通常エージェン
ト系用に外部に用意された通信環境が行う。

【００５３】このような依頼メッセージを受けた「flig
ht-agent」は，フライト予約要件に従って実際にフライ
トの予約を行い，それが成功した場合には，以下のよう
な回答メッセージを返すようにする。 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− （result ：content （［フライト予約］ （フライト予約ＩＤ "#00195" ） （フライト名 "JL333" ） （出発空港 "成田" ） （到着空港 "ヒースロー" ） （出発時刻 "2000/01/01 18:00" ） （到着時刻 "2000/01/02 10:00" ）） ：sender flight-agent ：receiver user-agent ） ……（式５） −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− ここまでで，既存のフライト予約サービスを会話型エー
ジェントの一つとして提供できるようになった。このフ
ライト予約サービスの場合には，回答のフレームはただ
一つであるが，一般的には複数のフレームを回答するよ
うなサービスもあり得る。

【００５４】また，上記のようなフライト予約サービス
とは独立してホテルを予約する要素サービスも存在して
おり，こちらは予約者名，滞在日，滞在都市名を与える
と適切なホテルの予約を行って，その予約のホテル予約
ＩＤ，ホテル名，滞在日を返すようになっていると仮定
する。

【００５５】こちらも同様な会話型エージェント化（エ
ージェント名：hotel-agent ）を行うには，まず以下の
ように各フレームを定義する。 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− （［ホテル予約要件］ （予約者名） （滞在日） （滞在都市名）） ……（式６） −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− （［ホテル予約］ （ホテル予約ＩＤ） （ホテル名） （滞在日) ） ……（式７） −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 次のようなホテル予約依頼メッセージに対応して， −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− （request ：content （［ホテル予約要件］ （予約者名 "John Doe" ） （滞在日 "2000/01/02" ） （滞在都市名 "ロンドン" ）） ：sender user-agent ：receiver hotel-agent） ……（式８） −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− （result ：content （［ホテル予約］ （ホテル予約ＩＤ "#255" ） （ホテル名 "Savoy" ） （滞在日 "2000/01/02" ）） ：sender hotel-agent ：receiver user-agent ） ……（式９） −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− のようなホテル予約回答メッセージを返すエージェント
にすればよい。

【００５６】次に，これらのエージェントを使ってフラ
イトとホテルの予約を統合し，新たな旅行予約サービス
を構築することを考える。「flight-agent」や「hotel-
agent 」を配下に持ち，それらを使用して旅行予約専門
のサービスや専用エージェント化することは当然可能で
あるが，システムの拡張性や汎用性を考慮すると，要素
的なサービス／エージェントを仲介・統合して，より上
位のサービスを仮想的に実現する仲介エージェントを構
築する方が望ましい。これが図１に示す仲介エージェン
ト１０である。

【００５７】この仲介エージェント１０には，要素サー
ビスエージェントが提供するサービスの要件と結果を表
現したフレームのペアを登録するようにすれば，この情
報を用いて種々の仲介サービスが可能になる。具体的に
は，「flight-agent」のサービスを記述するものとし
て，やはりフレームを用いて以下のような記述を登録す
る。 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− （［SERVICE ］ （agent-name flight-agent ） （request-in （［フライト予約要件］）） （result-out （［フライト予約］））） ……（式１０） −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− これは，「flight-agent」が，［フライト予約要件］フ
レームを伴う requestメッセージを受け取った場合，予
約に成功したときには［フライト予約］フレームを結果
として返す能力を持っていることを示している。また，
「hotel-agent」の提供するサービスの同様な記述は，
以下のようになる。 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− （［SERVICE ］ （agent-name hotel-agent） （request-in （［ホテル予約要件］）） （result-out （［ホテル予約］））） ……（式１１） −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 仲介エージェント１０（エージェント名：facilitator
）は，フライトとホテルの予約をまとめた旅行予約サ
ービスを提供可能なエージェントであるが，この場合の
旅行予約をフレームで記述すると以下のようになる。 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− （［旅行予約］ （［フライト予約］） （［ホテル予約］）） ……（式１２） −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− また，ユーザは，ユーザエージェント３０によってこの
仲介エージェント１０に旅行予約を依頼するが，その際
にユーザ情報として以下のフレームのスロット値を埋め
たものを通知してくるので仲介エージェント１０はこれ
を保存する。 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− （［旅行予約要件］ （予約者名） （出発空港） （到着空港） （出発日） （滞在日） （滞在都市名）） ……（式１３） −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− この時点で，仲介エージェント１０は (式１０）および
（式１１) のサービス記述フレームと， (式１２）の
［旅行予約］フレームの定義，（式１３）の［旅行予約
要件］フレームのスロット値が埋められたフレーム知識
を所持している。このような条件下の仲介エージェント
１０は，旅行予約サービス（すなわち［旅行予約］フレ
ームをユーザエージェント３０に返すサービス）を提供
することができるようになる。その過程は，具体的には
以下のような流れに沿ったものである。

【００５８】〈１〉ユーザエージェント３０は，仲介エ
ージェント１０に［旅行予約要件］フレームを含む req
uestメッセージを送信して，［旅行予約］フレームを要
求する。

【００５９】〈２〉［旅行予約］フレームを要求された
仲介エージェント１０は，（式１２）から，［フライト
予約］, ［ホテル予約］フレームがあれば［旅行予約］
フレームが作成可能であると判断する。

【００６０】〈３〉仲介エージェント１０は（式１０）
から，［フライト予約］を得るにはflight-agent に
［フライト予約要件］のデータを含む requestメッセー
ジを送ればよいと判断する。

【００６１】〈４〉仲介エージェント１０は（式１１）
から，［ホテル予約］を得るには hotel-agentに［ホテ
ル予約要件］のデータを含む requestメッセージを送れ
ばよいと判断する。

【００６２】〈５〉仲介エージェント１０は所持してい
る［旅行予約要件］フレームから，［フライト予約要
件］，［ホテル予約要件］のフレーム知識を作成できる
と判断して，次のような依頼計画を立てる。 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− （［依頼計画］ （［要素依頼］ （agent-name flight-agent ） (request-message "(request:content(［フライト予約要件］）...)")） （［要素依頼］ （agent-name hotel-agent） (request-message "(request:content（［ホテル予約要件］）...)")） ……（式１４） −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− なお，（式１４）の ...部には， (式４）および（式
８) のcontent から受け継いだ値が入ってる。

【００６３】この計画は，要素依頼の列であり，各要素
依頼は，依頼するエージェント名と，依頼するためのメ
ッセージのペアからなっている。

【００６４】〈６〉仲介エージェント１０は，立案した
依頼計画に沿って，実際にメッセージを各エージェント
に送信し，その回答として返されるメッセージから，
［フライト予約］と［ホテル予約］のフレーム知識を抽
出し，［旅行予約］フレームを組み立ててユーザに返
す。

【００６５】上の〈５〉で，仲介エージェント１０は，
［旅行予約要件］フレームから［フライト予約要件］，
［ホテル予約要件］のフレームが作れると判断している
が，これは，例えば −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− （＝（［旅行予約要件］ （予約者名）） （［フライト予約要件］ （予約者名））） （＝（［旅行予約要件］ （出発空港）） （［フライト予約要件］ （出発空港））） ……（式１５） −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− のような等号関係をすべての項目について仲介エージェ
ント１０に与えておくことで実現可能である。

【００６６】また，ここで実現されている仲介エージェ
ント１０のサービス記述は， −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− （［SERVICE ］ （agent-name facilitator） （request-in （［旅行予約要件］）） （result-out （［旅行予約］））） ……（式１６） −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− と書くことができるが，この情報が外部に伝達・保存さ
れていれば，ユーザエージェント３０が旅行予約を依頼
できるエージェントを知ることや，この仲介エージェン
ト１０を使うさらに高度なサービスを自動的に組み立て
るシステムを構築することも可能である。

【００６７】ここまで説明してきたような仲介エージェ
ント１０は，旅行予約専門のものではなく，（式１０）
および（式１１）のような宣言的なサービス記述を，種
々のサービスについて登録することにより，多様なサー
ビス統合を実現することができる。すなわち，「flight
-agent」のサービス記述（式１０），「hotel-agent」
のサービス記述（式１１）を，サービス記述保存部１７
に登録する。 (式１０）および（式１１) では，「requ
est-in」と「result-out」のフレームは各一個である
が，一般には複数のフレームを与えてより複雑なサービ
スを記述することも可能である。

【００６８】また，このようなサービス記述は，仲介エ
ージェント１０に設定データとして与える方法ばかりで
なく，要素サービスエージェントからメッセージを送り
つけることにより，動的に登録することも可能である。

【００６９】(式２)(式３)(式６)(式７)(式１２)(式１
３)(式１５) は，エージェント同士がやりとりするメッ
セージの内容で使用される語彙の定義であり，オントロ
ジと呼ばれるものである。オントロジは (式１０）およ
び（式１１) のようなサービス記述とはまた独立のもの
であるから，これらをまとめて別に管理することも可能
である。例えば，［フライト予約要件］に新たにユーザ
の年齢が加わった場合には，このオントロジを更新する
必要があるが，（式１０）のサービス記述を変える必要
はない。

【００７０】また，この節の例では同種の要素サービス
エージェントは一つしかないが，一般には複数個あるこ
とが考えられる。この場合サービス記述さえ条件を充た
せば，どれでもサービスの提供は可能ではあるが，サー
ビス記述とは別の要素サービスエージェントに対するメ
タ記述を用いて，さらに絞り込むことが考えられる。こ
のようなメタ記述の例としては，ユーザのアクセス権，
サービスの処理速度，ユーザの選好度などが挙げられ
る。

【００７１】

【実施例】〔旅行予約依頼に対する処理の例〕図９は，
図２に示す仲介エージェント１０の実施例のフローチャ
ートである。このフローチャートは，実施の形態で説明
した旅行予約システムの例を実現したものである。フロ
ーの前提として，「flight-agent」のサービス記述（式
１０）および「hotel-agent 」のサービス記述が，図３
に示すような形式でサービス記述保存部１７に保存され
ているものとする。

【００７２】また，［フライト予約要件］の定義（式
２），［フライト予約］の定義（式３），［ホテル予約
要件］の定義（式６），［ホテル予約］の定義（式
７），［旅行予約］の定義（式１２），［旅行予約要
件］の定義（式１３），等号関係（式１５）が，図４に
示すような形式でオントロジ保存部１８に保存されてい
るものとする。

【００７３】このような状態にある仲介エージェント１
０へユーザエージェント３０が， −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− （request ：content （［旅行予約要件］ （予約者名 "John Doe" ） （出発空港 "成田" ） （到着空港 "ヒースロー" ） （出発日 "2000/01/01" ） （滞在日 "2000/01/02" ） （滞在都市名 "ロンドン" ）） ：sender user-agent ：receiver facilitator） ……（式１７） −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− を送ってきたところから図９のフローがスタートしてい
る。以下，図９に示す（Ａ）〜（Ｄ）に従って説明す
る。

【００７４】（Ａ）ユーザエージェント３０から送って
きた旅行予約メッセージ（式１７）を，メッセージ送受
信部１１が受け取り，メッセージ処理エンジン１２にわ
たす。

【００７５】（Ｂ）メッセージ処理エンジン１２は，メ
ッセージの受信内容を見て旅行予約依頼であると判断
し，依頼計画生成部１３を呼び出し，依頼計画生成部１
３がサービス記述保存部１７とオントロジ保存部１８に
ある情報を使用して，（式１４）のような依頼計画を生
成する。

【００７６】（Ｃ）次に，メッセージ処理エンジン１２
は，依頼計画実行部１４によって，依頼計画生成部１３
が生成した依頼計画に基づき実際に，依頼メッセージを
外部のフライ予約エージェント（flight-agent），ホテ
ル予約エージェント（hotel-agent ）にメッセージ送受
信部１１から送信して応答結果を待つ。

【００７７】（Ｄ）応答結果の［フライト予約］と［ホ
テル予約］が返ってきたら，メッセージ処理エンジン１
２は，（式１２）の情報を利用して［旅行予約］フレー
ムを組み立てて，ユーザエージェント３０に回答メッセ
ージ（result）で返す。

【００７８】〔サービス記述の動的な登録の例〕図１０
は，図２に示す仲介エージェント１０の実施例のフロー
チャートであって，要素サービスエージェントからの依
頼によって，そのサービス記述をサービス記述保存部１
７に動的に登録して保存する場合の例を示している。

【００７９】要素サービスエージェントの一つであるフ
ライト予約エージェント（flight-agent）に関するサー
ビス記述（式１０）を，仲介エージェント１０が保持し
ておらず，フライト予約エージェント（flight-agent）
が，（式１０）の自分についてのサービス記述を仲介エ
ージェント１０に伝達する状況を考える。このためのメ
ッセージとして，エージェントが他のエージェントに事
実を伝えるための通知メッセージ（tell）を定義する。
具体的には， −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− （tell ：content （［SERVICE ］ （agent-name flight-agent ） （request-in （［フライト予約要件］）） （result-out （［フライト予約］））） ：sender flight-agent ：receiver facilitator） ……（式１８） −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− を，フライト予約エージェント（flight-agent）が，仲
介エージェント（facilitator ）１０に送る。これを受
信したときの仲介エージェント１０の処理のフローチャ
ートは，図１０に示すようになる。

【００８０】（Ａ）フライト予約エージェント（flight
-agent）から送ってきたサービス記述を通知するメッセ
ージ（式１８）を，メッセージ送受信部１１が受け取
り，メッセージ処理エンジン１２にわたす。

【００８１】（Ｂ）メッセージ処理エンジン１２は，メ
ッセージの受信内容を見て，サービス記述であると判断
し，サービス記述登録部１６によってサービス記述保存
部１７に保存する。

【００８２】〔オブジェクト指向言語の利用例〕サービ
ス記述において，要素サービスの実現に対して必要とさ
れる情報の宣言的記述情報および要素サービスの処理結
果に関する宣言的記述情報は，オブジェクト指向言語の
クラスまたはオブジェクトで表現することも可能であ
る。以下に，（式１０）の［フライト予約要件］と，
［フライト予約］とをＪａｖａ言語のクラスで表現した
例を示す。 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− public class フライト予約要件｛ public String 予約者名，出発空港，到着空港，出発日； ｝ public class フライト予約｛ publlic String フライト予約ＩＤ，フライト名，出発空港，到着空港， 出発時刻，到着時刻； ｝ −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 〔メタ情報の利用例〕図２の依頼計画生成部１３は，上
記サービス記述における要素サービスの実現に対して必
要とされる情報の宣言的記述情報および要素サービスの
処理結果に関する宣言的記述情報以外に，要素サービス
主体自体の性質を記述したメタ情報を加味して要素サー
ビス依頼計画を作成することもできる。このメタ情報と
して，例えばユーザの要素サービスに対するアクセス権
情報，要素サービスの回線速度もしくは処理速度に関す
る情報，要素サービスのユーザ選好度の情報などを利用
することができる。

【００８３】＜ユーザのアクセス権の例＞例えば，ある
ユーザのフライ予約エージェント（flight-agent）への
アクセス権の有無を表現した情報として，以下の（式１
９）のような形式の情報が仲介エージェント１０で利用
可能になっている場合，仲介エージェント１０に対して
旅行予約を依頼してきたユーザのうち，この情報に基づ
いてフライト予約エージェントに対してのアクセス権を
持っていると判断されるユーザにだけ，仲介エージェン
ト１０がサービス依頼計画を生成する対象にする。 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− （［アクセス権］ （ユーザ名 "John Doe" ） （エージェント名 "flight-agent" ）） ……（式１９） −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− ＜回線速度の例＞例えば，各要素サービスエージェント
が利用中のネットワークの回線速度を表現した以下の
（式２０）のような形式の情報が仲介エージェント１０
で利用可能になっているとする。この場合，仲介エージ
ェント１０は，回線速度の大きな要素サービスエージェ
ントを優先してサービス依頼計画を立てるようにする。 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− （［回線速度］ （エージェント名 "flight-agent1" ） （帯域 "64kb" ）） （［回線速度］ （エージェント名 "flight-agent2 " ） （帯域 "128kb"）） ……（式２０） −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− ＜ユーザ選好度の例＞例えば，各要素サービスエージェ
ントに対するユーザ個人やグループからの好まれ方を定
量化した以下の（式２１）のような形式の情報が仲介エ
ージェント１０で利用可能となっているとする。この場
合，仲介エージェント１０は，選好度の大きな要素サー
ビスエージェントを優先してサービス依頼計画を立てる
ようにする。 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− （［選好度］ （エージェント名 "flight-agent1" ） （評価値 ５）） （［選好度］ （エージェント名 "flight-agent2" ） （評価値 １０）） ……（式２１） −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 〔旅行予約の依頼計画要求に対する処理の例〕図１１
は，図２に示す仲介エージェント１０の実施例のフロー
チャートであって，実際に個別の要素サービスエージェ
ントへのサービス依頼は行わず，サービスの依頼計画の
みをユーザエージェント３０に返す場合の処理の例を示
している。この場合，この依頼計画を用いた実際のサー
ビス依頼は，ユーザエージェント３０が行うことを想定
している。

【００８４】ここでも実施の形態で説明した旅行予約シ
ステムの例に従って説明する。図１１のフローチャート
は，図９のフローチャートとよく似ているが，個別の要
素サービスエージェントへのサービス依頼はユーザエー
ジェント３０側で行う。

【００８５】（Ａ）ユーザエージェント３０から送って
きた旅行予約メッセージ（式１７）を，メッセージ送受
信部１１が受け取り，メッセージ処理エンジン１２にわ
たす。

【００８６】（Ｂ）メッセージ処理エンジン１２は，メ
ッセージの受信内容を見て旅行予約依頼であると判断
し，依頼計画生成部１３を呼び出し，依頼計画生成部１
３がサービス記述保存部１７とオントロジ保存部１８に
ある情報を使用して，（式１４）のような依頼計画を生
成する。

【００８７】（Ｃ）メッセージ処理エンジン１２は，生
成された依頼計画を依頼計画送信部１５によってメッセ
ージ送受信部１１からユーザエージェント３０へ通知メ
ッセージ（tell）を使って送信する。この通知メッセー
ジ（tell）は，以下のようなものであり，content 部は
（式１４）である。 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− (tell :content ([依頼計画] ([要素依頼] (agent-name flight-agent) (request-message "(request :content ([フライト予約要件])...)")) ([要素依頼] (agent-name hotel-agent) (request-message "(request :content ([ホテル予約要件])...)"))) :sender facilitator :receiver user-agent) ……（式２２） −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 本実施の形態および実施例の特徴を列記すると以下のと
おりである。

【００８８】（付記１）計算機上で実現された複数の要
素的なサービスを統合した複合サービスを提供するため
の装置であって，各要素サービスについて，要素サービ
ス主体の識別情報と，その要素サービスの実現に対して
必要とされる情報の宣言的記述情報と，その要素サービ
スの処理結果に関する宣言的記述情報との組み合わせか
らなるサービス記述情報を記憶する手段と，メッセージ
を送受信する手段と，外部から複合サービスに対する要
求メッセージを受信したときに，上記サービス記述情報
を利用して，複合サービスを要素サービスに分解し，少
なくとも複合サービスを実現するために必要な要素サー
ビス依頼情報と，要素サービス主体の識別情報との組み
合わせの列からなる要素サービス依頼計画を生成する手
段とを備えることを特徴とするサービス仲介処理装置。

【００８９】（付記２）付記１記載のサービス仲介処理
装置において，上記要素サービス依頼計画を生成した後
に，実際に要素サービスの主体に要素サービスを依頼
し，その処理結果をまとめて複合サービスの処理結果を
作成し，要求元へ通知する手段を備えることを特徴とす
るサービス仲介処理装置。

【００９０】（付記３）付記１記載のサービス仲介処理
装置において，上記要素サービス依頼計画を生成した後
に，外部からの要求に応じてその依頼計画を伝達する手
段を備えることを特徴とするサービス仲介処理装置。

【００９１】（付記４）付記１記載のサービス仲介処理
装置において，上記要素サービス主体の識別情報と，そ
の要素サービスの実現に対して必要とされる情報の宣言
的記述情報と，その要素サービスの処理結果に関する宣
言的記述情報との組み合わせからなるサービス記述情報
を外部から受け取り，それを動的に上記サービス記述情
報を記憶する手段に保存する手段を備えることを特徴と
するサービス仲介処理装置。

【００９２】（付記５）付記１記載のサービス仲介処理
装置において，上記要素サービスの実現に対して必要と
される情報の宣言的記述情報および上記要素サービスの
処理結果に関する宣言的記述情報が，オブジェクト指向
言語のクラスまたはオブジェクトで表現されたものであ
ることを特徴とするサービス仲介処理装置。

【００９３】（付記６）付記１記載のサービス仲介処理
装置において，上記要素サービスの実現に対して必要と
される情報の宣言的記述情報および要素サービスの処理
結果に関する宣言的記述情報に使用される語彙の定義情
報を記憶するオントロジ保存手段を備えることを特徴と
するサービス仲介処理装置。

【００９４】（付記７）付記１記載のサービス仲介処理
装置において，上記要素サービス依頼計画を生成する手
段は，上記要素サービスの実現に対して必要とされる情
報の宣言的記述情報および要素サービスの処理結果に関
する宣言的記述情報以外に，要素サービス主体自体の性
質を記述したメタ情報を加味して要素サービス依頼計画
を作成することを特徴とするサービス仲介処理装置。

【００９５】（付記８）付記７記載のサービス仲介処理
装置において，上記要素サービス依頼計画の作成に用い
るメタ情報は，ユーザの要素サービスに対するアクセス
権情報，要素サービスの回線速度もしくは処理速度に関
する情報，または要素サービスのユーザ選好度の情報で
あることを特徴とするサービス仲介処理装置。

【００９６】（付記９）計算機上で実現された複数の要
素的なサービスを統合した複合サービスを提供するため
の方法であって，各要素サービスについて，要素サービ
ス主体の識別情報と，その要素サービスの実現に対して
必要とされる情報の宣言的記述情報と，その要素サービ
スの処理結果に関する宣言的記述情報との組み合わせか
らなるサービス記述情報を記憶しておき，外部から複合
サービスに対する要求メッセージを受信したときに，上
記サービス記述情報を利用して，複合サービスを要素サ
ービスに分解し，少なくとも複合サービスを実現するた
めに必要な要素サービス依頼情報と，要素サービス主体
の識別情報との組み合わせの列からなる要素サービス依
頼計画を生成することを特徴とするサービス仲介処理方
法。

【００９７】（付記１０）計算機上で実現された複数の
要素的なサービスを統合した複合サービスを提供するた
めのプログラムであって，外部から複合サービスに対す
る要求メッセージを受信する処理と，要求メッセージを
受信したときに，あらかじめ各要素サービスについて記
憶している要素サービス主体の識別情報と，その要素サ
ービスの実現に対して必要とされる情報の宣言的記述情
報と，その要素サービスの処理結果に関する宣言的記述
情報との組み合わせからなるサービス記述情報を利用し
て，複合サービスを要素サービスに分解し，少なくとも
複合サービスを実現するために必要な要素サービス依頼
情報と，要素サービス主体の識別情報との組み合わせの
列からなる要素サービス依頼計画を生成する処理とを，
計算機に実行させるためのサービス仲介処理用プログラ
ム。

【００９８】（付記１１）計算機上で実現された複数の
要素的なサービスを統合した複合サービスを提供するた
めのプログラムを記録した記録媒体であって，外部から
複合サービスに対する要求メッセージを受信する処理
と，要求メッセージを受信したときに，あらかじめ各要
素サービスについて記憶している，要素サービス主体の
識別情報と，その要素サービスの実現に対して必要とさ
れる情報の宣言的記述情報と，その要素サービスの処理
結果に関する宣言的記述情報との組み合わせからなるサ
ービス記述情報を利用して，複合サービスを要素サービ
スに分解し，少なくとも複合サービスを実現するために
必要な要素サービス依頼情報と，要素サービス主体の識
別情報との組み合わせの列からなる要素サービス依頼計
画を生成する処理とを，計算機に実行させるためのプロ
グラムを記録したことを特徴とするサービス仲介処理用
プログラム記録媒体。

【００９９】（付記１２）ネットワークを介して接続さ
れたユーザエージェントと，仲介エージェントと，要素
サービスエージェントとからなり，計算機上で実現され
た複数の要素的なサービスを統合した複合サービスを提
供するサービス統合システムであって，前記仲介エージ
ェントは，各要素サービスについて，要素サービス主体
の識別情報と，その要素サービスの実現に対して必要と
される情報の宣言的記述情報と，その要素サービスの処
理結果に関する宣言的記述情報との組み合わせからなる
サービス記述情報を記憶する手段と，メッセージを送受
信する手段と，前記ユーザエージェントから複合サービ
スに対する要求メッセージを受信したときに，上記サー
ビス記述情報を利用して，複合サービスを要素サービス
に分解し，少なくとも複合サービスを実現するために必
要な要素サービス依頼情報と，要素サービス主体との識
別情報の組み合わせの列からなる要素サービス依頼計画
を生成する手段と，生成した依頼計画に基づき要素サー
ビスエージェントに要素サービスを依頼し，その処理結
果をまとめて複合サービスの処理結果を作成し，要求元
のユーザエージェントへ通知する手段とを備えることを
特徴とするサービス統合システム。

【０１００】（付記１３）ネットワークを介して接続さ
れたユーザエージェントと，仲介エージェントと，要素
サービスエージェントとからなり，計算機上で実現され
た複数の要素的なサービスを統合した複合サービスを提
供するサービス統合システムであって，前記仲介エージ
ェントは，各要素サービスについて，要素サービス主体
の識別情報と，その要素サービスの実現に対して必要と
される情報の宣言的記述情報と，その要素サービスの処
理結果に関する宣言的記述情報との組み合わせからなる
サービス記述情報を記憶する手段と，メッセージを送受
信する手段と，前記ユーザエージェントから複合サービ
スに対する要求メッセージを受信したときに，上記サー
ビス記述情報を利用して，複合サービスを要素サービス
に分解し，少なくとも複合サービスを実現するために必
要な要素サービス依頼情報と，要素サービス主体の識別
情報との組み合わせの列からなる要素サービス依頼計画
を生成する手段と，生成した依頼計画を要求元のユーザ
エージェントへ通知する手段とを備え，前記ユーザエー
ジェントは，前記仲介エージェントが生成した依頼計画
に基づき要素サービスエージェントに要素サービスを依
頼する手段を備えることを特徴とするサービス統合シス
テム。

【０１０１】

【発明の効果】以上説明したように，本発明によれば，
計算機上の複数の要素的なサービスを，要素サービスに
関する宣言的記述を用いて仮想的に統合するシステムを
実現し，複数の要素サービスを組み合わせた複合サービ
スを容易に提供することができるようになる。

【図面の簡単な説明】

【図１】本発明の実施の形態に係るシステム全体の構成
例を示す図である。

【図２】仲介エージェント（サービス仲介処理装置）の
構成例を示す図である。

【図３】サービス記述保存部に保存するデータの構成例
を示す図である。

【図４】オントロジ保存部に保存するデータの構成例を
示す図である。

【図５】仲介エージェントの処理フローチャートであ
る。

【図６】仲介エージェントの処理フローチャートであ
る。

【図７】仲介エージェントの処理フローチャートであ
る。

【図８】本発明を適用したサービス統合システムの構築
フローチャートである。

【図９】仲介エージェントの実施例のフローチャートで
ある。

【図１０】仲介エージェントの実施例のフローチャート
である。

【図１１】仲介エージェントの実施例のフローチャート
である。

【符号の説明】

１０ 仲介エージェント １１ メッセージ送受信部 １２ メッセージ処理エンジン １３ 依頼計画生成部 １４ 依頼計画実行部 １５ 依頼計画送信部 １６ サービス記述登録部 １７ サービス記述保存部 １８ オントロジ保存部 ２０Ａ，２０Ｂ，… 要素サービスエージェント ３０ ユーザエージェント

Claims (10)

【特許請求の範囲】
1. 【請求項１】 計算機上で実現された複数の要素的なサ
   ービスを統合した複合サービスを提供するための装置で
   あって，各要素サービスについて，要素サービス主体の
   識別情報と，その要素サービスの実現に対して必要とさ
   れる情報の宣言的記述情報と，その要素サービスの処理
   結果に関する宣言的記述情報との組み合わせからなるサ
   ービス記述情報を記憶する手段と，メッセージを送受信
   する手段と，外部から複合サービスに対する要求メッセ
   ージを受信したときに，上記サービス記述情報を利用し
   て，複合サービスを要素サービスに分解し，少なくとも
   複合サービスを実現するために必要な要素サービス依頼
   情報と，要素サービス主体の識別情報との組み合わせの
   列からなる要素サービス依頼計画を生成する手段とを備
   えることを特徴とするサービス仲介処理装置。
2. 【請求項２】 請求項１記載のサービス仲介処理装置に
   おいて，上記要素サービス依頼計画を生成した後に，実
   際に要素サービスの主体に要素サービスを依頼し，その
   処理結果をまとめて複合サービスの処理結果を作成し，
   要求元へ通知する手段を備えることを特徴とするサービ
   ス仲介処理装置。
3. 【請求項３】 請求項１記載のサービス仲介処理装置に
   おいて，上記要素サービス依頼計画を生成した後に，外
   部からの要求に応じてその依頼計画を伝達する手段を備
   えることを特徴とするサービス仲介処理装置。
4. 【請求項４】 請求項１記載のサービス仲介処理装置に
   おいて，上記要素サービス主体の識別情報と，その要素
   サービスの実現に対して必要とされる情報の宣言的記述
   情報と，その要素サービスの処理結果に関する宣言的記
   述情報との組み合わせからなるサービス記述情報を外部
   から受け取り，それを動的に上記サービス記述情報を記
   憶する手段に保存する手段を備えることを特徴とするサ
   ービス仲介処理装置。
5. 【請求項５】 請求項１記載のサービス仲介処理装置に
   おいて，上記要素サービスの実現に対して必要とされる
   情報の宣言的記述情報および上記要素サービスの処理結
   果に関する宣言的記述情報が，オブジェクト指向言語の
   クラスまたはオブジェクトで表現されたものであること
   を特徴とするサービス仲介処理装置。
6. 【請求項６】 請求項１記載のサービス仲介処理装置に
   おいて，上記要素サービスの実現に対して必要とされる
   情報の宣言的記述情報および要素サービスの処理結果に
   関する宣言的記述情報に使用される語彙の定義情報を記
   憶するオントロジ保存手段を備えることを特徴とするサ
   ービス仲介処理装置。
7. 【請求項７】 請求項１記載のサービス仲介処理装置に
   おいて，上記要素サービス依頼計画を生成する手段は，
   上記要素サービスの実現に対して必要とされる情報の宣
   言的記述情報および要素サービスの処理結果に関する宣
   言的記述情報以外に，要素サービス主体自体の性質を記
   述したメタ情報を加味して要素サービス依頼計画を作成
   することを特徴とするサービス仲介処理装置。
8. 【請求項８】 請求項７記載のサービス仲介処理装置に
   おいて，上記要素サービス依頼計画の作成に用いるメタ
   情報は，ユーザの要素サービスに対するアクセス権情
   報，要素サービスの回線速度もしくは処理速度に関する
   情報，または要素サービスのユーザ選好度の情報である
   ことを特徴とするサービス仲介処理装置。
9. 【請求項９】 計算機上で実現された複数の要素的なサ
   ービスを統合した複合サービスを提供するための方法で
   あって，各要素サービスについて，要素サービス主体の
   識別情報と，その要素サービスの実現に対して必要とさ
   れる情報の宣言的記述情報と，その要素サービスの処理
   結果に関する宣言的記述情報との組み合わせからなるサ
   ービス記述情報を記憶しておき，外部から複合サービス
   に対する要求メッセージを受信したときに，上記サービ
   ス記述情報を利用して，複合サービスを要素サービスに
   分解し，少なくとも複合サービスを実現するために必要
   な要素サービス依頼情報と，要素サービス主体の識別情
   報との組み合わせの列からなる要素サービス依頼計画を
   生成することを特徴とするサービス仲介処理方法。
10. 【請求項１０】 計算機上で実現された複数の要素的な
    サービスを統合した複合サービスを提供するためのプロ
    グラムであって，外部から複合サービスに対する要求メ
    ッセージを受信する処理と，要求メッセージを受信した
    ときに，あらかじめ各要素サービスについて記憶してい
    る要素サービス主体の識別情報と，その要素サービスの
    実現に対して必要とされる情報の宣言的記述情報と，そ
    の要素サービスの処理結果に関する宣言的記述情報との
    組み合わせからなるサービス記述情報を利用して，複合
    サービスを要素サービスに分解し，少なくとも複合サー
    ビスを実現するために必要な要素サービス依頼情報と，
    要素サービス主体の識別情報との組み合わせの列からな
    る要素サービス依頼計画を生成する処理とを，計算機に
    実行させるためのサービス仲介処理用プログラム。