JP2003256391A - サービス探索方法、サービス実行方法、それらのプログラム及び該プログラムを記録した記録媒体 - Google Patents
サービス探索方法、サービス実行方法、それらのプログラム及び該プログラムを記録した記録媒体Info
- Publication number
- JP2003256391A JP2003256391A JP2002057237A JP2002057237A JP2003256391A JP 2003256391 A JP2003256391 A JP 2003256391A JP 2002057237 A JP2002057237 A JP 2002057237A JP 2002057237 A JP2002057237 A JP 2002057237A JP 2003256391 A JP2003256391 A JP 2003256391A
- Authority
- JP
- Japan
- Prior art keywords
- information
- component
- input
- service
- message
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Abstract
(57)【要約】
【課題】ネットワーク上に分散するサービスコンポーネ
ントが、コンポーネントの多様性を維持しつつ、動的に
相手を発見・通信することによりアプリケーションを生
成できるようにする。 【解決手段】コンポーネントの入力インターフェースと
出力インターフェースとを分けて記述し、探索リクエス
ト（メッセージ）に含まれる入力情報が入力インターフ
ェースに合致する場合には（ステップ１０３）、メッセ
ージの通過経路情報に自コンポーネントを追加し（ステ
ップ１０４）、メッセージの入力情報を出力インターフ
ェースで書き換えて（ステップ１０９）、そのメッセー
ジをブロードキャストする（ステップ１１０）。
ントが、コンポーネントの多様性を維持しつつ、動的に
相手を発見・通信することによりアプリケーションを生
成できるようにする。 【解決手段】コンポーネントの入力インターフェースと
出力インターフェースとを分けて記述し、探索リクエス
ト（メッセージ）に含まれる入力情報が入力インターフ
ェースに合致する場合には（ステップ１０３）、メッセ
ージの通過経路情報に自コンポーネントを追加し（ステ
ップ１０４）、メッセージの入力情報を出力インターフ
ェースで書き換えて（ステップ１０９）、そのメッセー
ジをブロードキャストする（ステップ１１０）。
Description
【０００１】
【発明の属する技術分野】本発明は、ソフトウェアの開
発技法に関し、特に、ネットワーク上に分散するサービ
スコンポーネントが動的に相手を発見・通信することに
よりサービスアプリケーションを生成するダイナミック
コンポーネントシステムにおける、サービス探索方法及
びサービス実行方法に関する。
発技法に関し、特に、ネットワーク上に分散するサービ
スコンポーネントが動的に相手を発見・通信することに
よりサービスアプリケーションを生成するダイナミック
コンポーネントシステムにおける、サービス探索方法及
びサービス実行方法に関する。
【０００２】
【従来の技術】オブジェクト指向あるいはオブジェクト
指向プログラミングとは、関連のある手続きと情報を部
品（サービスコンポーネント：以下、コンポーネントと
も略す）として定義し、複数のコンポーネントを組み合
わせることによりソフトウェアを開発するという手法の
ことで、コンポーネントの再利用、カプセル化による実
装隠蔽などの利点を有する。コンポーネントは、ソフト
ウェアオブジェクトとも呼ばれている。
指向プログラミングとは、関連のある手続きと情報を部
品（サービスコンポーネント：以下、コンポーネントと
も略す）として定義し、複数のコンポーネントを組み合
わせることによりソフトウェアを開発するという手法の
ことで、コンポーネントの再利用、カプセル化による実
装隠蔽などの利点を有する。コンポーネントは、ソフト
ウェアオブジェクトとも呼ばれている。
【０００３】オブジェクト指向型プログラミング言語
は、対象となるコンポーネントはすべて同一のホスト上
に存在することを前提としている。ネットワークの普及
により、コンポーネントを複数のホスト上に分散配置
し、あたかも同一ホストに存在しているときと同じよう
に連携させ協調して処理を行わせるという、分散オブジ
ェクトという概念が誕生した。図１は、分散オブジェク
トの概念を説明する図である。ネットワーク１０内に複
数のあるいは多数のサービスコンポーネント１１1〜１
１4が分散して配置されており、これらサービスコンポ
ーネント１１1〜１１ 4は相互に連携し協調して処理を実
行することができるようになっている。ユーザ１２は、
これらのサービスコンポーネントのうちの１つ（サービ
スコンポーネント１１1）に働きかけることによって、
サービスコンポーネントが連携し協調して処理を行った
ことの成果を他のサービスコンポーネント１１2〜１１4
などから受取ることができる。分散オブジェクトによ
り、負荷分散・信頼性の向上などの利点が実現できる。
は、対象となるコンポーネントはすべて同一のホスト上
に存在することを前提としている。ネットワークの普及
により、コンポーネントを複数のホスト上に分散配置
し、あたかも同一ホストに存在しているときと同じよう
に連携させ協調して処理を行わせるという、分散オブジ
ェクトという概念が誕生した。図１は、分散オブジェク
トの概念を説明する図である。ネットワーク１０内に複
数のあるいは多数のサービスコンポーネント１１1〜１
１4が分散して配置されており、これらサービスコンポ
ーネント１１1〜１１ 4は相互に連携し協調して処理を実
行することができるようになっている。ユーザ１２は、
これらのサービスコンポーネントのうちの１つ（サービ
スコンポーネント１１1）に働きかけることによって、
サービスコンポーネントが連携し協調して処理を行った
ことの成果を他のサービスコンポーネント１１2〜１１4
などから受取ることができる。分散オブジェクトによ
り、負荷分散・信頼性の向上などの利点が実現できる。
【０００４】分散オブジェクトを実現させるためにＯＲ
Ｂ(Object Request Broker)（インターネット上のサイ
ト http://www.omg.org/を参照）のＣＯＲＢＡ(Common
Object Request Broker Architecture)やウェブ(web)
におけるＳＯＡＰ(Simple Object Access Protocol)（h
ttp://www.w3.org/TR/SOAP/を参照）、また、単一のウ
ェブサービスを１つのコンポーネントとして扱い、ウェ
ブサービス同士を連携させて様々なサービスを実現する
ための技術として、ＷＳＤＬ(Web Service Description
Language)（http://www.w3.org/TR/wsdlを参照）やＵ
ＤＤＩ(UniversalDescription, Discovery and Integra
tion)（http://www.uddi.org/about.htmlを参照）とい
った技術も誕生している。
Ｂ(Object Request Broker)（インターネット上のサイ
ト http://www.omg.org/を参照）のＣＯＲＢＡ(Common
Object Request Broker Architecture)やウェブ(web)
におけるＳＯＡＰ(Simple Object Access Protocol)（h
ttp://www.w3.org/TR/SOAP/を参照）、また、単一のウ
ェブサービスを１つのコンポーネントとして扱い、ウェ
ブサービス同士を連携させて様々なサービスを実現する
ための技術として、ＷＳＤＬ(Web Service Description
Language)（http://www.w3.org/TR/wsdlを参照）やＵ
ＤＤＩ(UniversalDescription, Discovery and Integra
tion)（http://www.uddi.org/about.htmlを参照）とい
った技術も誕生している。
【０００５】しかしながら、従来の分散オブジェクトの
技術においては、個々のコンポーネントが連携すべき、
または連携可能な相手は、システム設計者によってあら
かじめ設定されているか、コンポーネントの処理フロー
の一部として明示的に相手を探索するという処理を記述
する必要があった。インターネットなどのネットワーク
上において、多数の参加者がそれぞれコンポーネントを
提供するような場合を考慮すると、連携対象が予め設定
されているあるいは明示的に探索する処理を行うという
ことは、それらのコンポーネントを利用することを使い
勝手を著しく損ねることになる。そこで、ネットワーク
上に分散するサービスコンポーネントが動的に相手を発
見・通信することによりサービスアプリケーションを生
成する、ダイナミックコンポーネントシステムが提案さ
れている。
技術においては、個々のコンポーネントが連携すべき、
または連携可能な相手は、システム設計者によってあら
かじめ設定されているか、コンポーネントの処理フロー
の一部として明示的に相手を探索するという処理を記述
する必要があった。インターネットなどのネットワーク
上において、多数の参加者がそれぞれコンポーネントを
提供するような場合を考慮すると、連携対象が予め設定
されているあるいは明示的に探索する処理を行うという
ことは、それらのコンポーネントを利用することを使い
勝手を著しく損ねることになる。そこで、ネットワーク
上に分散するサービスコンポーネントが動的に相手を発
見・通信することによりサービスアプリケーションを生
成する、ダイナミックコンポーネントシステムが提案さ
れている。
【０００６】
【発明が解決しようとする課題】既存の分散オブジェク
ト技術では、２つのコンポーネントが連携する場合、互
いのサービスを利用するためのインターフェースはお互
いあらかじめ知っているという前提に基づいて設計され
ている。一方、ダイナミックコンポーネントシステムに
おいては、コンポーネントの連携は実行時に動的に行わ
れるので、連携相手のインターフェースは連携時に取得
する必要がある。インターフェースを伝播させるには、
インターフェースの定義を何らかの形式で記述できる必
要がある。
ト技術では、２つのコンポーネントが連携する場合、互
いのサービスを利用するためのインターフェースはお互
いあらかじめ知っているという前提に基づいて設計され
ている。一方、ダイナミックコンポーネントシステムに
おいては、コンポーネントの連携は実行時に動的に行わ
れるので、連携相手のインターフェースは連携時に取得
する必要がある。インターフェースを伝播させるには、
インターフェースの定義を何らかの形式で記述できる必
要がある。
【０００７】また、既存の分散オブジェクト技術では、
インターフェースが厳密に一致した場合のみコンポーネ
ント同士が通信できるとしている。これは前述のとおり
分散オブジェクトの場合は互いのインターフェースは既
知であるという前提に基づいた前提条件である。しか
し、ダイナミックコンポーネントシステムにおいては、
コンポーネント実装時においては連携相手のインターフ
ェース情報を知ることはできない。もしコンポーネント
のインターフェースを実装者が勝手に定義してしまう
と、通信できる可能性がほとんどなくなってしまう。定
義できるインターフェースをあらかじめシステム全体で
統一すれば通信の可能性は高まるが、それではコンポー
ネントの多様性が制限されてしまいかねない。
インターフェースが厳密に一致した場合のみコンポーネ
ント同士が通信できるとしている。これは前述のとおり
分散オブジェクトの場合は互いのインターフェースは既
知であるという前提に基づいた前提条件である。しか
し、ダイナミックコンポーネントシステムにおいては、
コンポーネント実装時においては連携相手のインターフ
ェース情報を知ることはできない。もしコンポーネント
のインターフェースを実装者が勝手に定義してしまう
と、通信できる可能性がほとんどなくなってしまう。定
義できるインターフェースをあらかじめシステム全体で
統一すれば通信の可能性は高まるが、それではコンポー
ネントの多様性が制限されてしまいかねない。
【０００８】また、既存の分散オブジェクト技術ではコ
ンポーネントとコンポーネントの集合であるアプリケー
ションを厳密に区別しているが、ダイナミックコンポー
ネントシステムにおいては、両者の区別は難しい。なぜ
なら、ダイナミックコンポーネントシステムにおけるコ
ンポーネントとは、連携することを念頭に設計されてい
ない、言い換えれば、単体でサービスとして機能するこ
とを前提として設計されているものも存在することを仮
定しているからである。したがって、単体のコンポーネ
ントとコンポーネントの集合のどちらの場合においても
アプリケーション（＝エンドユーザサービス）としての
情報をコンポーネント情報として記述できる必要があ
る。
ンポーネントとコンポーネントの集合であるアプリケー
ションを厳密に区別しているが、ダイナミックコンポー
ネントシステムにおいては、両者の区別は難しい。なぜ
なら、ダイナミックコンポーネントシステムにおけるコ
ンポーネントとは、連携することを念頭に設計されてい
ない、言い換えれば、単体でサービスとして機能するこ
とを前提として設計されているものも存在することを仮
定しているからである。したがって、単体のコンポーネ
ントとコンポーネントの集合のどちらの場合においても
アプリケーション（＝エンドユーザサービス）としての
情報をコンポーネント情報として記述できる必要があ
る。
【０００９】さらに、分散オブジェクト技術では、連携
可能なコンポーネントの集合をシステムが動的に発見ま
たは実現するようなメカニズムは定義されていない。
可能なコンポーネントの集合をシステムが動的に発見ま
たは実現するようなメカニズムは定義されていない。
【００１０】そこで本発明の目的は、インターフェース
が厳密には一致しなくても通信相手のコンポーネントを
発見できるようにし、これにより、コンポーネントの連
携チェーンを動的に探索し、実行できるサービス探索方
法及びサービス実行方法を提供することにある。
が厳密には一致しなくても通信相手のコンポーネントを
発見できるようにし、これにより、コンポーネントの連
携チェーンを動的に探索し、実行できるサービス探索方
法及びサービス実行方法を提供することにある。
【００１１】
【課題を解決するための手段】本発明の第１のサービス
探索方法は、ネットワーク上に分散配置されたコンポー
ネントから、コンポーネントの連携チェーンを探索する
サービス探索方法であって、各コンポーネントにおい
て、コンポーネントに入力される情報の条件である入力
インターフェースと、そのコンポーネントがサービスを
実行した結果についての情報である出力インターフェー
スとを分離して定義して記述し、入力インターフェース
において、受容できる入力情報を判別する際の比較条件
を規定するメタ情報を導入し、第１のコンポーネントの
出力インターフェースを入力情報に代入したときにメタ
情報に基づいて第２のコンポーネントの入力インターフ
ェースがその入力情報を受容できるかを判断することを
繰り返すことにより、コンポーネントの連携チェーンを
探索する。
探索方法は、ネットワーク上に分散配置されたコンポー
ネントから、コンポーネントの連携チェーンを探索する
サービス探索方法であって、各コンポーネントにおい
て、コンポーネントに入力される情報の条件である入力
インターフェースと、そのコンポーネントがサービスを
実行した結果についての情報である出力インターフェー
スとを分離して定義して記述し、入力インターフェース
において、受容できる入力情報を判別する際の比較条件
を規定するメタ情報を導入し、第１のコンポーネントの
出力インターフェースを入力情報に代入したときにメタ
情報に基づいて第２のコンポーネントの入力インターフ
ェースがその入力情報を受容できるかを判断することを
繰り返すことにより、コンポーネントの連携チェーンを
探索する。
【００１２】本発明の第２のサービス探索方法は、ネッ
トワーク上に分散配置されたコンポーネントから、コン
ポーネントの連携チェーンを探索するサービス探索方法
であって、各コンポーネントにおいて、コンポーネント
に入力される情報の条件である入力インターフェース
と、そのコンポーネントがサービスを実行した結果につ
いての情報である出力インターフェースとを分離して定
義して記述し、入力インターフェースにおいて、受容で
きる入力情報を判別する際の比較条件を規定するメタ情
報を導入し、入力情報及び返送条件を記述したメッセー
ジをコンポーネントが受信したとき、そのコンポーネン
トにおいて、その入力情報をそのコンポーネントの入力
インターフェースが受容できるか否か判別し、受容でき
る場合には、メッセージの通過経路情報にそのコンポー
ネントを識別する情報を追加し、その入力情報の入力イ
ンタフェースをそのコンポーネントの出力インターフェ
ースで置き換えてメッセージをネットワーク内に送出
し、受容できない場合にはメッセージを破棄し、返送条
件がそのコンポーネントの出力インターフェースを受容
できる場合には、そのコンポーネントの出力結果と通過
経路情報をメッセージの送信者に返送する。
トワーク上に分散配置されたコンポーネントから、コン
ポーネントの連携チェーンを探索するサービス探索方法
であって、各コンポーネントにおいて、コンポーネント
に入力される情報の条件である入力インターフェース
と、そのコンポーネントがサービスを実行した結果につ
いての情報である出力インターフェースとを分離して定
義して記述し、入力インターフェースにおいて、受容で
きる入力情報を判別する際の比較条件を規定するメタ情
報を導入し、入力情報及び返送条件を記述したメッセー
ジをコンポーネントが受信したとき、そのコンポーネン
トにおいて、その入力情報をそのコンポーネントの入力
インターフェースが受容できるか否か判別し、受容でき
る場合には、メッセージの通過経路情報にそのコンポー
ネントを識別する情報を追加し、その入力情報の入力イ
ンタフェースをそのコンポーネントの出力インターフェ
ースで置き換えてメッセージをネットワーク内に送出
し、受容できない場合にはメッセージを破棄し、返送条
件がそのコンポーネントの出力インターフェースを受容
できる場合には、そのコンポーネントの出力結果と通過
経路情報をメッセージの送信者に返送する。
【００１３】本発明の第１のサービス実行方法は、上述
した第１のサービス探索方法を実行して探索された連携
チェーンに含まれる各コンポーネントで順次処理を行わ
せることによりサービスを実行する。ここで、サービス
実行結果が満たすべき条件を返送条件として格納する探
索リクエストを各コンポーネント間で巡回させることに
より、各コンポーネントで順次処理を行わせ、サービス
実行結果が返送条件を満足するときにサービスの実行を
終了するようにすることが好ましい。
した第１のサービス探索方法を実行して探索された連携
チェーンに含まれる各コンポーネントで順次処理を行わ
せることによりサービスを実行する。ここで、サービス
実行結果が満たすべき条件を返送条件として格納する探
索リクエストを各コンポーネント間で巡回させることに
より、各コンポーネントで順次処理を行わせ、サービス
実行結果が返送条件を満足するときにサービスの実行を
終了するようにすることが好ましい。
【００１４】本発明の第２のサービス実行方法は、上述
した第１のサービス探索方法を実行して得られた通過経
路情報での格納順に各コンポーネントを順次起動させ
る。
した第１のサービス探索方法を実行して得られた通過経
路情報での格納順に各コンポーネントを順次起動させ
る。
【００１５】本発明の第３のサービス実行方法は、ネッ
トワーク上に分散配置されたコンポーネントを用い、コ
ンポーネントの連携チェーンによってサービスを実行す
るサービス実行方法であって、各コンポーネントにおい
て、コンポーネントに入力される情報の条件である入力
インターフェースと、そのコンポーネントがサービスを
実行した結果についての情報である出力インターフェー
スとを分離して定義して記述し、入力インターフェース
において、受容できる入力情報を判別する際の比較条件
を規定するメタ情報を導入し、入力情報及び返送条件を
記述したメッセージをコンポーネントが受信したとき、
そのコンポーネントにおいて、その入力情報をそのコン
ポーネントの入力インターフェースが受容できるか否か
判別し、受容できる場合には、その入力情報に基づいて
サービスを実行し、その入力情報を当該コンポーネント
の実行結果で書き換えてメッセージをネットワーク内に
送出し、受容できない場合にはメッセージを破棄し、返
送条件がそのコンポーネントの出力インターフェースを
受容できる場合にはその実行結果をメッセージの送信者
に返送する。ここで、返送条件がそのコンポーネントの
出力インターフェースを受容できる場合には、メッセー
ジのネットワーク内への送出を行わないようにすること
が好ましい。
トワーク上に分散配置されたコンポーネントを用い、コ
ンポーネントの連携チェーンによってサービスを実行す
るサービス実行方法であって、各コンポーネントにおい
て、コンポーネントに入力される情報の条件である入力
インターフェースと、そのコンポーネントがサービスを
実行した結果についての情報である出力インターフェー
スとを分離して定義して記述し、入力インターフェース
において、受容できる入力情報を判別する際の比較条件
を規定するメタ情報を導入し、入力情報及び返送条件を
記述したメッセージをコンポーネントが受信したとき、
そのコンポーネントにおいて、その入力情報をそのコン
ポーネントの入力インターフェースが受容できるか否か
判別し、受容できる場合には、その入力情報に基づいて
サービスを実行し、その入力情報を当該コンポーネント
の実行結果で書き換えてメッセージをネットワーク内に
送出し、受容できない場合にはメッセージを破棄し、返
送条件がそのコンポーネントの出力インターフェースを
受容できる場合にはその実行結果をメッセージの送信者
に返送する。ここで、返送条件がそのコンポーネントの
出力インターフェースを受容できる場合には、メッセー
ジのネットワーク内への送出を行わないようにすること
が好ましい。
【００１６】
【発明の実施の形態】次に、本発明の好ましい実施の形
態について、図面を参照して説明する。
態について、図面を参照して説明する。
【００１７】本発明の実施の一形態のダイナミックコン
ポーネントシステムは、ネットワーク上に複数のサービ
スコンポーネントが分散配置しているとして、これらの
コンポーネントが動的に相手を発見・通信することによ
り、サービスアプリケーションを生成するものである。
ここでは、コンポーネントが連携し協調して処理を行う
ことによって、そのサービスアプリケーションとして機
能することになる。この際、あるコンポーネントのサー
ビスを実行した結果を次のコンポーネントのサービスの
起動に用いるという関係が生じるが、このように関係付
けられる一連のコンポーネントのことを（コンポーネン
トの）連携チェーンを呼ぶ。この実施の形態では、連携
相手のコンポーネントのインターフェースが厳密には一
致しない場合であっても、コンポーネントの連携チェー
ンを動的に検索、生成できるようにしている。
ポーネントシステムは、ネットワーク上に複数のサービ
スコンポーネントが分散配置しているとして、これらの
コンポーネントが動的に相手を発見・通信することによ
り、サービスアプリケーションを生成するものである。
ここでは、コンポーネントが連携し協調して処理を行う
ことによって、そのサービスアプリケーションとして機
能することになる。この際、あるコンポーネントのサー
ビスを実行した結果を次のコンポーネントのサービスの
起動に用いるという関係が生じるが、このように関係付
けられる一連のコンポーネントのことを（コンポーネン
トの）連携チェーンを呼ぶ。この実施の形態では、連携
相手のコンポーネントのインターフェースが厳密には一
致しない場合であっても、コンポーネントの連携チェー
ンを動的に検索、生成できるようにしている。
【００１８】本実施の形態のダイナミックコンポーネン
トシステムを説明するにあたり、まず、ここでの各サー
ビスコンポーネントのインターフェース情報について説
明する。
トシステムを説明するにあたり、まず、ここでの各サー
ビスコンポーネントのインターフェース情報について説
明する。
【００１９】本実施の形態では、コンポーネントのイン
ターフェース情報を入力インターフェースと出力インタ
ーフェースを分離して記述するとともに、コンポーネン
トの多様性を実現しつつ、通信できる可能性を高めるた
めに、ElementSetとConditionSetという記述方法によっ
てインターフェース情報を記述する。
ターフェース情報を入力インターフェースと出力インタ
ーフェースを分離して記述するとともに、コンポーネン
トの多様性を実現しつつ、通信できる可能性を高めるた
めに、ElementSetとConditionSetという記述方法によっ
てインターフェース情報を記述する。
【００２０】入力インターフェースとは、コンポーネン
トが自身のサービスを起動する際に入力される情報の条
件のことであって、出力インターフェースとは、コンポ
ーネントのサービスを実行した結果についての情報のこ
とである。インターフェース情報が入力と出力の対で記
述されるとすれば、コンポーネントの連携によって実現
されるサービスのインターフェース情報は、連携チェー
ンの先頭コンポーネントの入力インターフェースと、チ
ェーンの末尾コンポーネントの出力インターフェースの
対によって記述できる。例えばコンポーネントＡ→Ｂ→
Ｃの連携によって実現されるサービスＳのインターフェ
ースは、｛Ａの入力インターフェース，Ｃの出力インタ
ーフェース｝という形で記述できる。これにより、単体
のコンポーネントのインターフェース情報も連携チェー
ンのインターフェース情報も統一の形式で扱うことがで
きる。
トが自身のサービスを起動する際に入力される情報の条
件のことであって、出力インターフェースとは、コンポ
ーネントのサービスを実行した結果についての情報のこ
とである。インターフェース情報が入力と出力の対で記
述されるとすれば、コンポーネントの連携によって実現
されるサービスのインターフェース情報は、連携チェー
ンの先頭コンポーネントの入力インターフェースと、チ
ェーンの末尾コンポーネントの出力インターフェースの
対によって記述できる。例えばコンポーネントＡ→Ｂ→
Ｃの連携によって実現されるサービスＳのインターフェ
ースは、｛Ａの入力インターフェース，Ｃの出力インタ
ーフェース｝という形で記述できる。これにより、単体
のコンポーネントのインターフェース情報も連携チェー
ンのインターフェース情報も統一の形式で扱うことがで
きる。
【００２１】また、ElementSetとは、（名前、型、値）
で定義されるElementの集合であり、従来の分散オブジ
ェクト指向におけるインターフェース定義とほほ同等で
ある。それに対し、ConditionSetとは、ElementSetに対
してさらにサービス内容を表わすメタ情報を付加したも
ので、メタ情報に応じて比較条件（型一致、型・名前一
致、型・名前・値一致）を変更できる記述方式である。
で定義されるElementの集合であり、従来の分散オブジ
ェクト指向におけるインターフェース定義とほほ同等で
ある。それに対し、ConditionSetとは、ElementSetに対
してさらにサービス内容を表わすメタ情報を付加したも
ので、メタ情報に応じて比較条件（型一致、型・名前一
致、型・名前・値一致）を変更できる記述方式である。
【００２２】本実施の形態では、入力インターフェース
をConditionSetによって、出力インターフェースをElem
entSetによって記述することにより、インターフェース
が完全に一致しなくとも、後述するように、ある程度共
通項を持つインターフェース同士ならば通信が実現でき
る。インターフェース情報が入力インターフェース(Con
ditionSet)と出力インターフェース(ElementSet)で記述
されたコンポーネントが複数存在するシステムにおい
て、ある入力情報(ElementSet)を入力として処理した結
果指定された返送条件(ConditionSet)を満たす結果が実
現できるまで、繰り返し実行することで、コンポーネン
トの連携チェーンを動的に検索または生成できる。
をConditionSetによって、出力インターフェースをElem
entSetによって記述することにより、インターフェース
が完全に一致しなくとも、後述するように、ある程度共
通項を持つインターフェース同士ならば通信が実現でき
る。インターフェース情報が入力インターフェース(Con
ditionSet)と出力インターフェース(ElementSet)で記述
されたコンポーネントが複数存在するシステムにおい
て、ある入力情報(ElementSet)を入力として処理した結
果指定された返送条件(ConditionSet)を満たす結果が実
現できるまで、繰り返し実行することで、コンポーネン
トの連携チェーンを動的に検索または生成できる。
【００２３】以下、本実施の形態におけるElement, Ele
mentSet, Condition, ConditionSetについて、詳しく説
明する。
mentSet, Condition, ConditionSetについて、詳しく説
明する。
【００２４】《ＥｌｅｍｅｎｔとＥｌｅｍｅｎｔＳｅ
ｔ》ElementSetとは、（型、名前、値）で表されるElem
entの集合である。Elementには値を複数指定しても良い
とする。また、ElementSet中に同じ名前を持つElement
は存在しないとする。すなわち、型(type)、名前(nam
e)、値(VALUE)によってelement eが表されるとして、 E=[e1, e2, ...,en] E:ElementSet, e:element e=[name, type, VALUE], VALUE=[v1, v2, ...,vn] ∀e1,e2 ∈ E ⇒ e1.name != e2.name である。
ｔ》ElementSetとは、（型、名前、値）で表されるElem
entの集合である。Elementには値を複数指定しても良い
とする。また、ElementSet中に同じ名前を持つElement
は存在しないとする。すなわち、型(type)、名前(nam
e)、値(VALUE)によってelement eが表されるとして、 E=[e1, e2, ...,en] E:ElementSet, e:element e=[name, type, VALUE], VALUE=[v1, v2, ...,vn] ∀e1,e2 ∈ E ⇒ e1.name != e2.name である。
【００２５】《ｃｏｎｄｉｔｉｏｎ》Conditionとは、
あるElementが与えられたときに、そのElementを受容す
るかどうかの条件を記述するもので、（型、名前、値、
メタ情報）で表される。名前および値は複数存在しても
良いとする。すなわち、メタ情報をattributeとして、 c=[NAME, type, VALUE, attribute] NAME=[name1, ...,namek], VALUE=[v1, v2, ...,vn] である。ここで、conditionにおけるメタ情報には、以
下の種類がある。
あるElementが与えられたときに、そのElementを受容す
るかどうかの条件を記述するもので、（型、名前、値、
メタ情報）で表される。名前および値は複数存在しても
良いとする。すなわち、メタ情報をattributeとして、 c=[NAME, type, VALUE, attribute] NAME=[name1, ...,namek], VALUE=[v1, v2, ...,vn] である。ここで、conditionにおけるメタ情報には、以
下の種類がある。
【００２６】ＥＱＵＡＬＳ
指定されたElementの名前がConditionの名前の中に記述
されていて、かつElementの値がConditionの値と個数・
順序・内容とも完全に一致する場合に受容する。すなわ
ち、 e.name=name[∃name ∈ c.NAME] ∧ e.VALUE=c.VALUE
⇒ TRUE である。
されていて、かつElementの値がConditionの値と個数・
順序・内容とも完全に一致する場合に受容する。すなわ
ち、 e.name=name[∃name ∈ c.NAME] ∧ e.VALUE=c.VALUE
⇒ TRUE である。
【００２７】ＩＮＣＬＵＤＥＳ
指定されたElementの名前がConditionの名前の中に記述
されていて、かつElementのすべての値がConditionの値
の中に記述されている場合に受容する。すなわち、 e.name=name[∃name∈c.NAME] ∧ e.VALUE⊆c.VALUE ⇒
TRUE である。
されていて、かつElementのすべての値がConditionの値
の中に記述されている場合に受容する。すなわち、 e.name=name[∃name∈c.NAME] ∧ e.VALUE⊆c.VALUE ⇒
TRUE である。
【００２８】ＩＮＣＬＵＤＥＤ
指定されたElementの名前がConditionの名前の中に記述
されていて、かつConditionのすべての値がElementの値
の中に記述されている場合に受容する。すなわち、 e.name=name[∃name∈c.NAME] ∧ e.VALUE⊇c.VALUE ⇒
TRUE である。
されていて、かつConditionのすべての値がElementの値
の中に記述されている場合に受容する。すなわち、 e.name=name[∃name∈c.NAME] ∧ e.VALUE⊇c.VALUE ⇒
TRUE である。
【００２９】ＨＡＳ＿ＳＡＭＥ
指定されたElementの名前がConditionの名前の中に記述
されていて、かつElementの値のいずれかがConditionの
値のいずれかと一致する場合に受容する。すなわち、 e.name=name[∃name∈c.NAME] ∧ v=V[∃v∈e.VALUE,
∃V∈c.VALUE] ⇒ TRUE である。
されていて、かつElementの値のいずれかがConditionの
値のいずれかと一致する場合に受容する。すなわち、 e.name=name[∃name∈c.NAME] ∧ v=V[∃v∈e.VALUE,
∃V∈c.VALUE] ⇒ TRUE である。
【００３０】 ＮＯ＿ＣＯＮＤＩＴＩＯＮ
無条件に受容する。すなわち、常にTRUEとするものであ
る。
る。
【００３１】《ｃｏｎｄｉｔｉｏｎＳｅｔ》ConditionS
etとは、あるElementSetが与えられたときに、そのElem
entSetを受容するかどうかの条件を記述したもので、Co
nditionおよびConditionSetの集合とメタ情報で表現さ
れる。すなわち、 C=[COND,attribute] COND=[cl,c2,...cn] C:Condition
Set, cl,c2,...cn:Condition｜ConditionSet である。ここで、ConditionSetのメタ情報には、以下の
種類がある。
etとは、あるElementSetが与えられたときに、そのElem
entSetを受容するかどうかの条件を記述したもので、Co
nditionおよびConditionSetの集合とメタ情報で表現さ
れる。すなわち、 C=[COND,attribute] COND=[cl,c2,...cn] C:Condition
Set, cl,c2,...cn:Condition｜ConditionSet である。ここで、ConditionSetのメタ情報には、以下の
種類がある。
【００３２】ＡＮＤ
与えられたElementSet中に、このConditionSetに含まれ
るすべてのCondition（またはConditionSet）を満たす
（受容する）Elementが存在する場合はTRUEとする。す
なわち、 c satisfies e in [∀c∈C, ∃e∈E] ⇒ TRUE C:ConditionSet, E:ElementSet, c:Condition｜Conditi
onSet, e:Element である。
るすべてのCondition（またはConditionSet）を満たす
（受容する）Elementが存在する場合はTRUEとする。す
なわち、 c satisfies e in [∀c∈C, ∃e∈E] ⇒ TRUE C:ConditionSet, E:ElementSet, c:Condition｜Conditi
onSet, e:Element である。
【００３３】ＯＲ
与えられたElementSet中に、このConditionSetに含まれ
る（またはConditionSet）を満たす（受容する）Elemen
tが１つでも存在する場合は、TRUEとする。すなわち、 c Satisfies e in [∃c∈C, ∃e∈E] ⇒ TRUE である。
る（またはConditionSet）を満たす（受容する）Elemen
tが１つでも存在する場合は、TRUEとする。すなわち、 c Satisfies e in [∃c∈C, ∃e∈E] ⇒ TRUE である。
【００３４】ＩＦ＿ＥＸＩＳＴ
ConditionSetに含まれるCondition（またはConditionSe
t）のうち、与えられたElementSet中に同じ名前と型を
持つElementが存在するものがすべてそのElementを満た
すなら、TRUEとする。そのようなElementが存在する
が、そのElementが対応するConditionによって満たされ
ない場合は、FALSEとする。対応するElementが１つも存
在しない場合はTRUEとする。すなわち、 c satisfies e in [∀c∈C' in [e.name∈c.NAME ∧ e.
type=c.type in [∃c∈C', ∃e∈E]]] ⇒ TRUE である。
t）のうち、与えられたElementSet中に同じ名前と型を
持つElementが存在するものがすべてそのElementを満た
すなら、TRUEとする。そのようなElementが存在する
が、そのElementが対応するConditionによって満たされ
ない場合は、FALSEとする。対応するElementが１つも存
在しない場合はTRUEとする。すなわち、 c satisfies e in [∀c∈C' in [e.name∈c.NAME ∧ e.
type=c.type in [∃c∈C', ∃e∈E]]] ⇒ TRUE である。
【００３５】ＭＥＴＡ
このConditionSetに含まれるCondition（またはConditi
onSet）はメタ情報として扱われる。METAメタ情報のCon
ditionSet中に記述されたCondition（またはConditionS
et）は、比較時は無視される。すなわち常にTRUEとされ
る。
onSet）はメタ情報として扱われる。METAメタ情報のCon
ditionSet中に記述されたCondition（またはConditionS
et）は、比較時は無視される。すなわち常にTRUEとされ
る。
【００３６】以上、本実施の形態における各サービスコ
ンポーネントのインターフェース情報について詳述した
が、本実施の形態で、上述のように各コンポーネントの
インターフェース情報を規定した上で、サービス探索を
実行する。サービス探索とは、またはある入力情報(Ele
mentSet)を入力として処理した結果指定された返送条件
(ConditionSet)を満たす結果が実現できるコンポーネン
トの連携チェーンを動的に発見する行為である。
ンポーネントのインターフェース情報について詳述した
が、本実施の形態で、上述のように各コンポーネントの
インターフェース情報を規定した上で、サービス探索を
実行する。サービス探索とは、またはある入力情報(Ele
mentSet)を入力として処理した結果指定された返送条件
(ConditionSet)を満たす結果が実現できるコンポーネン
トの連携チェーンを動的に発見する行為である。
【００３７】図２は、サービス探索のアルゴリズムを説
明する図である。図において、入力Ｉ／Ｆ及び出力Ｉ／
Ｆは、それぞれ入力インターフェース及び出力インター
フェースのことである。
明する図である。図において、入力Ｉ／Ｆ及び出力Ｉ／
Ｆは、それぞれ入力インターフェース及び出力インター
フェースのことである。
【００３８】まず、図中で［１］で示すように、ネット
ワーク上の各サービスコンポーネント１１に対して、入
力情報(ElementSet)と返送条件(ConditionSet)を含むサ
ービス探索メッセージ（探索リクエスト）をブロードキ
ャストする。探索メッセージを受信した各コンポーネン
ト１１は、図中［２］で示すように、自身の入力インタ
ーフェース(ConditionSet)が受信したメッセージ（探索
リクエスト）中の入力情報(ElementSet)を満たすかどう
かチェックする。満たさない場合にはメッセージを破棄
する。一方、満たす場合には、図中［３］で示すよう
に、メッセージを受信したコンポーネント１１がコンポ
ーネント「Ａ」であるとして、メッセージ（探索リクエ
スト）が過去通過したコンポーネントの履歴に対し、自
身の情報（「Ａ」）を追加し、図中［４］で示すよう
に、メッセージ中の返送条件(ConditionSet)が自身の出
力インターフェース(ElementSet)を満たすかどうかチェ
ックする。満たす場合は、メッセージの通過履歴（＝指
定された入力情報を元に指定された返送条件を満たす結
果を生成できるコンポーネントの連携チェーン）をメッ
セージ送信者に返送する。その後、コンポーネント１１
は、図中［５］で示すように、メッセージの入力情報(E
lementSet)を自身の出力インターフェース(ElementSet)
で置き換え、メッセージ（探索リクエスト）を他のコン
ポーネントに向けてブロードキャストする。
ワーク上の各サービスコンポーネント１１に対して、入
力情報(ElementSet)と返送条件(ConditionSet)を含むサ
ービス探索メッセージ（探索リクエスト）をブロードキ
ャストする。探索メッセージを受信した各コンポーネン
ト１１は、図中［２］で示すように、自身の入力インタ
ーフェース(ConditionSet)が受信したメッセージ（探索
リクエスト）中の入力情報(ElementSet)を満たすかどう
かチェックする。満たさない場合にはメッセージを破棄
する。一方、満たす場合には、図中［３］で示すよう
に、メッセージを受信したコンポーネント１１がコンポ
ーネント「Ａ」であるとして、メッセージ（探索リクエ
スト）が過去通過したコンポーネントの履歴に対し、自
身の情報（「Ａ」）を追加し、図中［４］で示すよう
に、メッセージ中の返送条件(ConditionSet)が自身の出
力インターフェース(ElementSet)を満たすかどうかチェ
ックする。満たす場合は、メッセージの通過履歴（＝指
定された入力情報を元に指定された返送条件を満たす結
果を生成できるコンポーネントの連携チェーン）をメッ
セージ送信者に返送する。その後、コンポーネント１１
は、図中［５］で示すように、メッセージの入力情報(E
lementSet)を自身の出力インターフェース(ElementSet)
で置き換え、メッセージ（探索リクエスト）を他のコン
ポーネントに向けてブロードキャストする。
【００３９】ここで説明した［２］〜［５］の処理を繰
り返すことにより、ブロードキャスト範囲中に存在する
すべてのコンポーネントで実現可能なチェーンのうち、
指定された条件を満たすことができるものを必ず発見す
ることができる。
り返すことにより、ブロードキャスト範囲中に存在する
すべてのコンポーネントで実現可能なチェーンのうち、
指定された条件を満たすことができるものを必ず発見す
ることができる。
【００４０】図３は、あるコンポーネントに着目したと
きに上述の処理がそのコンポーネントでどのように行わ
れるかを示したフローチャートである。
きに上述の処理がそのコンポーネントでどのように行わ
れるかを示したフローチャートである。
【００４１】コンポーネントはまずメッセージ（探索リ
クエスト）の受信を待機する状態にあり（ステップ１０
１）、そこでメッセージを受信する（ステップ１０
２）。メッセージを受信したら、まず、メッセージの入
力情報が自身の入力インターフェースと合致するかを判
断し（ステップ１０３）、合致しない場合にはそのメッ
セージを破棄して（ステップ１０４）、処理を終了す
る。ステップ１０３で合致していた場合には、そのメッ
セージの通過経路情報に自身を追加し（ステップ１０
５）、返送条件が指定されているかどうかを判定する
（ステップ１０６）。返送条件が指定されていない場合
にはステップ１０９に移行し、返送条件が指定されてい
る場合には、自身の出力インターフェースが返送条件に
合致するかどうかを判定し（ステップ１０７）、合致し
ない場合にはそのままステップ１０９に移行し、合致し
ている場合には、メッセージ通過経路情報をメッセージ
の送信者（そのメッセージをブロードキャストしたコン
ポーネントも送信者に含まれる）に返送してから（ステ
ップ１０８）、ステップ１０９に移行する。ステップ１
０９では、メッセージの入力情報をそのコンポーネント
自身の出力インターフェースで置き換え、その後、その
メッセージをブロードキャストして（ステップ１１
０）、そのコンポーネントでの処理は終了する。
クエスト）の受信を待機する状態にあり（ステップ１０
１）、そこでメッセージを受信する（ステップ１０
２）。メッセージを受信したら、まず、メッセージの入
力情報が自身の入力インターフェースと合致するかを判
断し（ステップ１０３）、合致しない場合にはそのメッ
セージを破棄して（ステップ１０４）、処理を終了す
る。ステップ１０３で合致していた場合には、そのメッ
セージの通過経路情報に自身を追加し（ステップ１０
５）、返送条件が指定されているかどうかを判定する
（ステップ１０６）。返送条件が指定されていない場合
にはステップ１０９に移行し、返送条件が指定されてい
る場合には、自身の出力インターフェースが返送条件に
合致するかどうかを判定し（ステップ１０７）、合致し
ない場合にはそのままステップ１０９に移行し、合致し
ている場合には、メッセージ通過経路情報をメッセージ
の送信者（そのメッセージをブロードキャストしたコン
ポーネントも送信者に含まれる）に返送してから（ステ
ップ１０８）、ステップ１０９に移行する。ステップ１
０９では、メッセージの入力情報をそのコンポーネント
自身の出力インターフェースで置き換え、その後、その
メッセージをブロードキャストして（ステップ１１
０）、そのコンポーネントでの処理は終了する。
【００４２】なお、図３に示したフローチャートにおい
て、ステップ１０８の実行後、ステップ１０９に移行す
ることなくそのコンポーネントでの処理を終了すること
すれば、メッセージ（探索リクエスト）に記述された返
送条件を満たす出力インターフェースを有するコンポー
ネントが発見された時点で、サービス探索の処理が打ち
切られることとなり、結果として、最初に与えられたメ
ッセージに記載された入力情報及び返送条件の双方を満
足する連携チェーンが、メッセージにおける通過経過情
報として表わされることになる。すなわち、要求される
サービス実行結果に応じた最短の連携チェーンが得られ
ることになる。
て、ステップ１０８の実行後、ステップ１０９に移行す
ることなくそのコンポーネントでの処理を終了すること
すれば、メッセージ（探索リクエスト）に記述された返
送条件を満たす出力インターフェースを有するコンポー
ネントが発見された時点で、サービス探索の処理が打ち
切られることとなり、結果として、最初に与えられたメ
ッセージに記載された入力情報及び返送条件の双方を満
足する連携チェーンが、メッセージにおける通過経過情
報として表わされることになる。すなわち、要求される
サービス実行結果に応じた最短の連携チェーンが得られ
ることになる。
【００４３】以上の処理において、メッセージの入力情
報がコンポーネント自身の入力インターフェースと合致
するかどうかの判定、コンポーネント自身の出力インタ
ーフェースがメッセージの返送条件に合致するかどうか
の判定が行われている。ここで、これらの判定について
詳しく説明する。この実施の形態において、メッセージ
の入力情報はElementSetで記述され、入力インターフェ
ースはConditionSetで記述されている。上述したよう
に、ConditionSetは、あるElementSetが与えられたとき
にそのElementSetを受容するかどうかの条件を記述した
ものであり、Condition及びConditionSetの集合とメタ
情報（ＡＮＤ、ＯＲ、ＩＦ＿ＥＸＩＳＴ及びＭＥＴＡの
４種類）によって表現されている。そこで、ConditionS
etに含まれるメタ情報に応じてElementSetを受容するか
どうかを調べ、受容するとする場合には入力情報が入力
インターフェースに合致するものと判定し、受容しない
とする場合には、入力情報が入力インターフェースに合
致しないものと判定する。出力インターフェース(Eleme
ntSet)が返送条件(ConditionSet)に合致するかどうか
は、返送条件のConditionSetが出力インターフェースの
ElementSetを受容とするか否かに応じて判定される。
報がコンポーネント自身の入力インターフェースと合致
するかどうかの判定、コンポーネント自身の出力インタ
ーフェースがメッセージの返送条件に合致するかどうか
の判定が行われている。ここで、これらの判定について
詳しく説明する。この実施の形態において、メッセージ
の入力情報はElementSetで記述され、入力インターフェ
ースはConditionSetで記述されている。上述したよう
に、ConditionSetは、あるElementSetが与えられたとき
にそのElementSetを受容するかどうかの条件を記述した
ものであり、Condition及びConditionSetの集合とメタ
情報（ＡＮＤ、ＯＲ、ＩＦ＿ＥＸＩＳＴ及びＭＥＴＡの
４種類）によって表現されている。そこで、ConditionS
etに含まれるメタ情報に応じてElementSetを受容するか
どうかを調べ、受容するとする場合には入力情報が入力
インターフェースに合致するものと判定し、受容しない
とする場合には、入力情報が入力インターフェースに合
致しないものと判定する。出力インターフェース(Eleme
ntSet)が返送条件(ConditionSet)に合致するかどうか
は、返送条件のConditionSetが出力インターフェースの
ElementSetを受容とするか否かに応じて判定される。
【００４４】このようなサービス探索の処理を実行する
ために、各サービスコンポーネント１１は、論理的に、
図３に示すような構造を有する。
ために、各サービスコンポーネント１１は、論理的に、
図３に示すような構造を有する。
【００４５】すなわち、コンポーネント１１では、その
コンポーネント１１が本来実行すべきサービスが、サー
ビス本体実装２４として実装されており、サービス本体
実装２４に対して、入力インターフェース（入力Ｉ／
Ｆ）２３及び出力インターフェース（出力Ｉ／Ｆ）２５
が規定されている。そして、コンポーネント１１は、メ
ッセージを受信するメッセージ受信部２１と、メッセー
ジの入力情報が入力インターフェース２３に合致するか
どうかを判定する入力情報判定部２２と、出力インター
フェース２５がメッセージの返送条件に合致するかどう
かを判定する返送条件判定部２６と、メッセージを転送
するメッセージ転送部２７と、メッセージの通過経路情
報を返送するメッセージ返送部２８と、を備えている。
コンポーネント１１が本来実行すべきサービスが、サー
ビス本体実装２４として実装されており、サービス本体
実装２４に対して、入力インターフェース（入力Ｉ／
Ｆ）２３及び出力インターフェース（出力Ｉ／Ｆ）２５
が規定されている。そして、コンポーネント１１は、メ
ッセージを受信するメッセージ受信部２１と、メッセー
ジの入力情報が入力インターフェース２３に合致するか
どうかを判定する入力情報判定部２２と、出力インター
フェース２５がメッセージの返送条件に合致するかどう
かを判定する返送条件判定部２６と、メッセージを転送
するメッセージ転送部２７と、メッセージの通過経路情
報を返送するメッセージ返送部２８と、を備えている。
【００４６】次に、メッセージの送受信の観点から上述
のサービス探索の処理を説明する。まず、コンポーネン
トの実装者は、図５に示すように、自身のコンポーネン
トの入力インターフェースとしてConditionSetを記述
し、自身の出力インターフェースとしてElementSetを記
述し（ステップ１２１）、そのコンポーネントに格納す
る（ステップ１２２）。このようにインターフェースが
記述され格納されているとして、メッセージの送信者
は、入力情報としてElementSetを、返送条件としてCond
itionSetを指定したメッセージを送信する（ステップ１
３１）。このメッセージはコンポーネントによって受信
され（ステップ１３２）、そのコンポーネントにおい
て、そのコンポーネント自身の入力インターフェースで
あるConditionSetとメッセージ送信者によって指定され
たElementSetとの条件が比較され（ステップ１３３）、
条件一致かどうかが判断される（ステップ１３４）。条
件一致でなければ、メッセージを破棄して（ステップ１
３５）、処理が終了する。一方、ステップ１３４で条件
一致であれば、そのコンポーネントにおいて、メッセー
ジ送信者によるメッセージ通過履歴にそのコンポーネン
トの識別子を追加し（ステップ１３６）、自コンポーネ
ントの出力インターフェースであるElementSetとメッセ
ージの返送条件であるConditionSetの条件を比較し（ス
テップ１３７）、条件一致かどうかを判断する（ステッ
プ１３８）。ここで条件一致であれば、メッセージ送信
者に通過履歴であるコンポーネントの識別子が返送され
て（ステップ１３９）、処理が終了する。一方、ステッ
プ１３８において条件一致でなければ、そのメッセージ
の入力情報をそのコンポーネント自身の出力インターフ
ェースであるElementSetに置き換え（ステップ１４
０）、入力情報が置き換えられたメッセージが送信され
る（ステップ１４１）。その後、次のコンポーネントに
おいてこの送信されたメッセージに関してここで述べた
ような処理を実行するために、ステップ１３６に戻る。
のサービス探索の処理を説明する。まず、コンポーネン
トの実装者は、図５に示すように、自身のコンポーネン
トの入力インターフェースとしてConditionSetを記述
し、自身の出力インターフェースとしてElementSetを記
述し（ステップ１２１）、そのコンポーネントに格納す
る（ステップ１２２）。このようにインターフェースが
記述され格納されているとして、メッセージの送信者
は、入力情報としてElementSetを、返送条件としてCond
itionSetを指定したメッセージを送信する（ステップ１
３１）。このメッセージはコンポーネントによって受信
され（ステップ１３２）、そのコンポーネントにおい
て、そのコンポーネント自身の入力インターフェースで
あるConditionSetとメッセージ送信者によって指定され
たElementSetとの条件が比較され（ステップ１３３）、
条件一致かどうかが判断される（ステップ１３４）。条
件一致でなければ、メッセージを破棄して（ステップ１
３５）、処理が終了する。一方、ステップ１３４で条件
一致であれば、そのコンポーネントにおいて、メッセー
ジ送信者によるメッセージ通過履歴にそのコンポーネン
トの識別子を追加し（ステップ１３６）、自コンポーネ
ントの出力インターフェースであるElementSetとメッセ
ージの返送条件であるConditionSetの条件を比較し（ス
テップ１３７）、条件一致かどうかを判断する（ステッ
プ１３８）。ここで条件一致であれば、メッセージ送信
者に通過履歴であるコンポーネントの識別子が返送され
て（ステップ１３９）、処理が終了する。一方、ステッ
プ１３８において条件一致でなければ、そのメッセージ
の入力情報をそのコンポーネント自身の出力インターフ
ェースであるElementSetに置き換え（ステップ１４
０）、入力情報が置き換えられたメッセージが送信され
る（ステップ１４１）。その後、次のコンポーネントに
おいてこの送信されたメッセージに関してここで述べた
ような処理を実行するために、ステップ１３６に戻る。
【００４７】以上、本実施の形態におけるサービス探索
の処理を説明した。ここでは、説明の簡単のために、メ
ッセージのループ防止や探索時間・探索距離の制限を実
現する処理についてはその詳細に触れなかったが、これ
らは実装上の問題であって、サービス探索の処理におけ
る本質的な事項ではない。当業者は、その必要とすると
ことに応じて、上述したサービス探索の処理に対し、メ
ッセージのループ防止や探索時間・探索距離の制限を実
現する処理を容易に組み込むことができる。
の処理を説明した。ここでは、説明の簡単のために、メ
ッセージのループ防止や探索時間・探索距離の制限を実
現する処理についてはその詳細に触れなかったが、これ
らは実装上の問題であって、サービス探索の処理におけ
る本質的な事項ではない。当業者は、その必要とすると
ことに応じて、上述したサービス探索の処理に対し、メ
ッセージのループ防止や探索時間・探索距離の制限を実
現する処理を容易に組み込むことができる。
【００４８】次に、上述したサービス探索の処理を適用
し、サービス要求を行ってサービスアプリケーションを
実現する処理について説明する。
し、サービス要求を行ってサービスアプリケーションを
実現する処理について説明する。
【００４９】サービス要求とは、あるリクエストがシス
テム上に送信された際、そのリクエストを処理すること
ができるサービスがそのリクエストを受理し、自身のサ
ービスを実行し、その結果をリクエスト送信元に返送す
るという一連の行為のことである。既存のシステムで
は、サービス要求は、サービス探索において発見された
サービスを指定して行われるのが一般的であるが、ダイ
ナミックコンポーネントシステムの場合、各コンポーネ
ントがリクエストを受信した際に各々の判断によって通
信する相手を選択することにより、サービスを探索しつ
つ実行することが可能となる。このようにサービスを探
索しつつ実行することは、サービスの実行結果を指定せ
ずに、システムが過去のサービス利用履歴などに基づい
て自発的にサービスを実現する、というサービス実行形
態の際に、特に有効である。
テム上に送信された際、そのリクエストを処理すること
ができるサービスがそのリクエストを受理し、自身のサ
ービスを実行し、その結果をリクエスト送信元に返送す
るという一連の行為のことである。既存のシステムで
は、サービス要求は、サービス探索において発見された
サービスを指定して行われるのが一般的であるが、ダイ
ナミックコンポーネントシステムの場合、各コンポーネ
ントがリクエストを受信した際に各々の判断によって通
信する相手を選択することにより、サービスを探索しつ
つ実行することが可能となる。このようにサービスを探
索しつつ実行することは、サービスの実行結果を指定せ
ずに、システムが過去のサービス利用履歴などに基づい
て自発的にサービスを実現する、というサービス実行形
態の際に、特に有効である。
【００５０】つまり、ダイナミックコンポーネントシス
テムにおいて実現可能なサービス要求形態には、次の２
通りがある。
テムにおいて実現可能なサービス要求形態には、次の２
通りがある。
【００５１】 サービス探索により発見されたコンポ
ーネントまたはコンポーネント連携チェーンのサービス
を実行する。
ーネントまたはコンポーネント連携チェーンのサービス
を実行する。
【００５２】 サービス探索と同じように入力情報と
返送条件を指定し、それらの条件を満たすことができる
サービスを探索しつつ実行する。
返送条件を指定し、それらの条件を満たすことができる
サービスを探索しつつ実行する。
【００５３】以下、それぞれのサービス要求の形態のメ
カニズムについて説明する。
カニズムについて説明する。
【００５４】上述したサービス探索の処理によって得ら
れる探索結果の情報には、メッセージの通過経路情報に
対して自コンポーネントの識別子を追加する処理が含ま
れていることにより、発見されたサービスを実現するた
めのコンポーネント連携チェーンの順序情報が含まれて
いる。発見されたサービスをこの順序情報に基づいて実
行するには、図７に示すように、以下のようにすればよ
い。
れる探索結果の情報には、メッセージの通過経路情報に
対して自コンポーネントの識別子を追加する処理が含ま
れていることにより、発見されたサービスを実現するた
めのコンポーネント連携チェーンの順序情報が含まれて
いる。発見されたサービスをこの順序情報に基づいて実
行するには、図７に示すように、以下のようにすればよ
い。
【００５５】まず、連携チェーンの先頭のコンポーネン
トの入力インターフェース(ConditionSet)をもとに、リ
クエストの入力情報(ElementSet)を生成する（例えば、
ユーザに入力させる）。ここでは連携チェーンは、図示
Ａのコンポーネントを先頭コンポーネントとし、Ａのコ
ンポーネントによる実行結果に基づいて図示Ｂのコンポ
ーネントが処理を行う者とする。次に、図示［２］に示
すように、入力情報(ElementSet)と実行チェーンの構成
情報を含むサービス実行リクエストを、先頭コンポーネ
ント（コンポーネントＡ）に送信する。サービス実行リ
クエストを受信したコンポーネントは、図示［３］に示
すように、リクエスト中の入力情報(ElementSet)を元に
自身のサービスを実行し、図示［４］に示すように、実
行リクエスト中の実行チェーン情報から先頭の情報（＝
自身の情報）を取り除く。その後、図示［５］に示すよ
うに、実行チェーン情報からその先頭の情報を取り除い
た結果、実行チェーン情報が空になった場合には、自身
の実行結果をリクエスト送信元に返信し、実行チェーン
情報が空でない場合は、実行チェーン情報において新た
に先頭になったコンポーネントに対し、自身のサービス
実行結果(ElementSet)を入力情報とする実行リクエスト
を送信する。
トの入力インターフェース(ConditionSet)をもとに、リ
クエストの入力情報(ElementSet)を生成する（例えば、
ユーザに入力させる）。ここでは連携チェーンは、図示
Ａのコンポーネントを先頭コンポーネントとし、Ａのコ
ンポーネントによる実行結果に基づいて図示Ｂのコンポ
ーネントが処理を行う者とする。次に、図示［２］に示
すように、入力情報(ElementSet)と実行チェーンの構成
情報を含むサービス実行リクエストを、先頭コンポーネ
ント（コンポーネントＡ）に送信する。サービス実行リ
クエストを受信したコンポーネントは、図示［３］に示
すように、リクエスト中の入力情報(ElementSet)を元に
自身のサービスを実行し、図示［４］に示すように、実
行リクエスト中の実行チェーン情報から先頭の情報（＝
自身の情報）を取り除く。その後、図示［５］に示すよ
うに、実行チェーン情報からその先頭の情報を取り除い
た結果、実行チェーン情報が空になった場合には、自身
の実行結果をリクエスト送信元に返信し、実行チェーン
情報が空でない場合は、実行チェーン情報において新た
に先頭になったコンポーネントに対し、自身のサービス
実行結果(ElementSet)を入力情報とする実行リクエスト
を送信する。
【００５６】以上の処理を行うことによって、サービス
探索により発見されたコンポーネントまたはコンポーネ
ント連携チェーンのサービスが実行される。
探索により発見されたコンポーネントまたはコンポーネ
ント連携チェーンのサービスが実行される。
【００５７】一方、指定した入力情報を処理し、その結
果指定した返送条件を満たす出力を得るサービスを探索
しつつ実行するには、サービス探索の場合と同様の処理
を行うようにすればよい。図８はこのような処理の概要
を示す図である。
果指定した返送条件を満たす出力を得るサービスを探索
しつつ実行するには、サービス探索の場合と同様の処理
を行うようにすればよい。図８はこのような処理の概要
を示す図である。
【００５８】まず、図中［１］で示すように、入力情報
(ElementSet)と返送条件(ConditionSet)を含むサービス
要求メッセージ（実行リクエスト）をブロードキャスト
する。この要求メッセージを受信したコンポーネント
は、図中［２］で示すように、自身の入力インターフェ
ース(ConditionSet)が受信したメッセージ中の入力情報
(ElementSet)を満たすかどうかチェックする。満たさな
い場合にはメッセージを破棄する。一方、満たす場合に
は、図中［３］で示すように、リクエスト中の入力情報
(ElementSet)を元に自身のサービスを実行し、実行結果
(ElementSet)を取得し、図中［４］で示すように、メッ
セージ中の返送条件(ConditionSet)が得られた実行結果
(ElementSet)を満たすかどうかチェックする。満たす場
合は、実行結果(ElementSet)をメッセージ送信者に返送
する。その後、そのコンポーネントは、図中［５］に示
すように、メッセージの入力情報(ElementSet)を実行結
果(ElementSet)で置き換え、メッセージをブロードキャ
ストする。
(ElementSet)と返送条件(ConditionSet)を含むサービス
要求メッセージ（実行リクエスト）をブロードキャスト
する。この要求メッセージを受信したコンポーネント
は、図中［２］で示すように、自身の入力インターフェ
ース(ConditionSet)が受信したメッセージ中の入力情報
(ElementSet)を満たすかどうかチェックする。満たさな
い場合にはメッセージを破棄する。一方、満たす場合に
は、図中［３］で示すように、リクエスト中の入力情報
(ElementSet)を元に自身のサービスを実行し、実行結果
(ElementSet)を取得し、図中［４］で示すように、メッ
セージ中の返送条件(ConditionSet)が得られた実行結果
(ElementSet)を満たすかどうかチェックする。満たす場
合は、実行結果(ElementSet)をメッセージ送信者に返送
する。その後、そのコンポーネントは、図中［５］に示
すように、メッセージの入力情報(ElementSet)を実行結
果(ElementSet)で置き換え、メッセージをブロードキャ
ストする。
【００５９】ここで示した［２］〜［５］の処理を繰り
返すことにより、ブロードキャスト範囲中に存在するす
べてのコンポーネントで実現可能なコラボレーションの
うち、指定された入出力条件を満たすことができるもの
のみの実行結果を得ることができる。
返すことにより、ブロードキャスト範囲中に存在するす
べてのコンポーネントで実現可能なコラボレーションの
うち、指定された入出力条件を満たすことができるもの
のみの実行結果を得ることができる。
【００６０】図９は、あるコンポーネントに着目したと
きに、図８を用いて説明した処理がそのコンポーネント
でどのように行われるかを示したフローチャートであ
る。
きに、図８を用いて説明した処理がそのコンポーネント
でどのように行われるかを示したフローチャートであ
る。
【００６１】コンポーネントはまずメッセージ（実行リ
クエスト）の受信を待機する状態にあり（ステップ１１
１）、そこでメッセージを受信する（ステップ１１
２）。メッセージを受信したら、まず、メッセージの入
力情報が自身の入力インターフェースと合致するかを判
断し（ステップ１１３）、合致しない場合にはそのメッ
セージを破棄して（ステップ１１４）、処理を終了す
る。ステップ１１３で合致していた場合には、入力イン
ターフェースを介してその入力情報をサービス実装本体
に渡してサービスを実行させ（ステップ１１５）、サー
ビス実行結果を得る。そののち、返送条件が指定されて
いるかどうかを判定する（ステップ１１６）。返送条件
が指定されていない場合にはステップ１１９に移行し、
返送条件が指定されている場合には、サービス実行結果
が返送条件に合致するかどうかを判定し（ステップ１１
７）、合致しない場合にはそのままステップ１１９に移
行し、合致している場合には、サービス実行結果をメッ
セージの送信者に返送してから（ステップ１１８）、ス
テップ１１９に移行する。ステップ１１９では、メッセ
ージの入力情報をそのサービス実行結果で置き換え、そ
の後、そのメッセージをブロードキャストして（ステッ
プ１２０）、そのコンポーネントでの処理は終了する。
クエスト）の受信を待機する状態にあり（ステップ１１
１）、そこでメッセージを受信する（ステップ１１
２）。メッセージを受信したら、まず、メッセージの入
力情報が自身の入力インターフェースと合致するかを判
断し（ステップ１１３）、合致しない場合にはそのメッ
セージを破棄して（ステップ１１４）、処理を終了す
る。ステップ１１３で合致していた場合には、入力イン
ターフェースを介してその入力情報をサービス実装本体
に渡してサービスを実行させ（ステップ１１５）、サー
ビス実行結果を得る。そののち、返送条件が指定されて
いるかどうかを判定する（ステップ１１６）。返送条件
が指定されていない場合にはステップ１１９に移行し、
返送条件が指定されている場合には、サービス実行結果
が返送条件に合致するかどうかを判定し（ステップ１１
７）、合致しない場合にはそのままステップ１１９に移
行し、合致している場合には、サービス実行結果をメッ
セージの送信者に返送してから（ステップ１１８）、ス
テップ１１９に移行する。ステップ１１９では、メッセ
ージの入力情報をそのサービス実行結果で置き換え、そ
の後、そのメッセージをブロードキャストして（ステッ
プ１２０）、そのコンポーネントでの処理は終了する。
【００６２】なお、図９に示したフローチャートにおい
て、ステップ１１８の実行後、ステップ１１９に移行す
ることなくそのコンポーネントでの処理を終了すること
すれば、メッセージ（実行リクエスト）に記述された返
送条件を満たす出力インターフェースを有するコンポー
ネントが発見された時点で、サービス実行の処理が打ち
切られることとなり、結果として、最初に与えられたメ
ッセージに記載された入力情報及び返送条件（要求され
るサービス実行結果）の双方を満足する最短の連携チェ
ーンによってサービスが実行され、その実行結果が得ら
れることになる。
て、ステップ１１８の実行後、ステップ１１９に移行す
ることなくそのコンポーネントでの処理を終了すること
すれば、メッセージ（実行リクエスト）に記述された返
送条件を満たす出力インターフェースを有するコンポー
ネントが発見された時点で、サービス実行の処理が打ち
切られることとなり、結果として、最初に与えられたメ
ッセージに記載された入力情報及び返送条件（要求され
るサービス実行結果）の双方を満足する最短の連携チェ
ーンによってサービスが実行され、その実行結果が得ら
れることになる。
【００６３】このようにサービスを探索しつつ実行する
処理を実行するために、各サービスコンポーネント１１
は、論理的に、図１０に示すような構造を有する。
処理を実行するために、各サービスコンポーネント１１
は、論理的に、図１０に示すような構造を有する。
【００６４】すなわち、コンポーネント１１では、その
コンポーネント１１が本来実行すべきサービスがサービ
ス本体実装２４として実装されており、サービス本体実
装２４に対して、入力インターフェース（入力Ｉ／Ｆ）
２３及び出力インターフェース（出力Ｉ／Ｆ）２５が規
定されている。そして、コンポーネント１１は、メッセ
ージを受信するメッセージ受信部２１と、メッセージの
入力情報が入力インターフェース２３に合致するかどう
かを判定し、一致している場合に入力インターフェース
２３を介してその入力情報をサービス本体実装２４に渡
す入力情報判定部２２と、出力インターフェース２５を
介してサービス本体実装から得られたサービス実行結果
２９がメッセージの返送条件に合致するかどうかを判定
する返送条件判定部２６と、サービス実行結果２９をメ
ッセージとして転送するメッセージ転送部２７と、サー
ビス実行結果２９がメッセージの返送条件に合致してい
るときにそのサービス実行結果２９をメッセージ送信者
に返送するメッセージ返送部２８と、を備えている。
コンポーネント１１が本来実行すべきサービスがサービ
ス本体実装２４として実装されており、サービス本体実
装２４に対して、入力インターフェース（入力Ｉ／Ｆ）
２３及び出力インターフェース（出力Ｉ／Ｆ）２５が規
定されている。そして、コンポーネント１１は、メッセ
ージを受信するメッセージ受信部２１と、メッセージの
入力情報が入力インターフェース２３に合致するかどう
かを判定し、一致している場合に入力インターフェース
２３を介してその入力情報をサービス本体実装２４に渡
す入力情報判定部２２と、出力インターフェース２５を
介してサービス本体実装から得られたサービス実行結果
２９がメッセージの返送条件に合致するかどうかを判定
する返送条件判定部２６と、サービス実行結果２９をメ
ッセージとして転送するメッセージ転送部２７と、サー
ビス実行結果２９がメッセージの返送条件に合致してい
るときにそのサービス実行結果２９をメッセージ送信者
に返送するメッセージ返送部２８と、を備えている。
【００６５】以上、本発明の好ましい実施の形態を説明
したが、本発明において、コンポーネント（サービスコ
ンポーネント）は、最初に説明したようにソフトウェア
オブジェクトであって、実体的には、コンピュータが実
行可能なプログラムあるいはコードとして存在すること
になる。すなわち、コンポーネントは、図３または図９
のフローチャートに示した処理を実行できるコンピュー
タプログラムあるいはソフトウェア製品であり、あるい
は、図４または図１０に示した論理的な構成を有するコ
ンピュータプログラムあるいはソフトウェア製品であ
る。このようなコンポーネントのプログラムは、パーソ
ナルコンピュータやサーバコンピュータなどのコンピュ
ータに読み込まれ、実行されることになる。コンピュー
タは、コンポーネントのプログラムを実行することによ
り、コンポーネントが規定するサービスを提供すること
になる。コンポーネントのプログラムは、フレキシブル
ディスクやＣＤ−ＲＯＭなどの記録媒体に予め格納され
て各コンピュータに向けて配布してもよいし、インター
ネットなどのネットワークを介してコンピュータがこれ
らのプログラムをダウンロードし実行できるようにして
もよい。
したが、本発明において、コンポーネント（サービスコ
ンポーネント）は、最初に説明したようにソフトウェア
オブジェクトであって、実体的には、コンピュータが実
行可能なプログラムあるいはコードとして存在すること
になる。すなわち、コンポーネントは、図３または図９
のフローチャートに示した処理を実行できるコンピュー
タプログラムあるいはソフトウェア製品であり、あるい
は、図４または図１０に示した論理的な構成を有するコ
ンピュータプログラムあるいはソフトウェア製品であ
る。このようなコンポーネントのプログラムは、パーソ
ナルコンピュータやサーバコンピュータなどのコンピュ
ータに読み込まれ、実行されることになる。コンピュー
タは、コンポーネントのプログラムを実行することによ
り、コンポーネントが規定するサービスを提供すること
になる。コンポーネントのプログラムは、フレキシブル
ディスクやＣＤ−ＲＯＭなどの記録媒体に予め格納され
て各コンピュータに向けて配布してもよいし、インター
ネットなどのネットワークを介してコンピュータがこれ
らのプログラムをダウンロードし実行できるようにして
もよい。
【００６６】コンポーネントのプログラムを実行するコ
ンピュータは、一般に、ＣＰＵ（中央処理装置）と、プ
ログラムやデータを格納するためのハードディスク装置
と、主メモリと、キーボードやマウスなどの入力装置
と、ＣＲＴや液晶表示パネルなどの表示装置と、フレキ
シブルディスクやＣＤ−ＲＯＭ等の記録媒体を読み取る
読み取り装置と、インターネットなどのネットワークと
接続するための通信インターフェースとから構成されて
いる。ハードディスク装置、主メモリ、入力装置、表示
装置、読み取り装置及び通信インターフェースは、いず
れもＣＰＵに接続している。コンポーネントのプログラ
ムがフレキシブルディスクやＣＤ−ＲＯＭ等の記録媒体
に格納されている場合には、その記録媒体を読み取り装
置に装着し、記録媒体からプログラムを読み出してハー
ドディスク装置に格納し、ハードディスク装置に格納さ
れたプログラムをＣＰＵが実行することにより、上述し
たようなサービス探索やサービス実行の処理が実行され
る。ネットワークを介してプログラムが配布される場合
には、通信インターフェースを介して取り込んだプログ
ラムをハードディスク装置に格納し、ハードディスク装
置に格納されたプログラムをＣＰＵが実行することによ
り、上述したようなサービス探索やサービス実行の処理
が実行されることになる。
ンピュータは、一般に、ＣＰＵ（中央処理装置）と、プ
ログラムやデータを格納するためのハードディスク装置
と、主メモリと、キーボードやマウスなどの入力装置
と、ＣＲＴや液晶表示パネルなどの表示装置と、フレキ
シブルディスクやＣＤ−ＲＯＭ等の記録媒体を読み取る
読み取り装置と、インターネットなどのネットワークと
接続するための通信インターフェースとから構成されて
いる。ハードディスク装置、主メモリ、入力装置、表示
装置、読み取り装置及び通信インターフェースは、いず
れもＣＰＵに接続している。コンポーネントのプログラ
ムがフレキシブルディスクやＣＤ−ＲＯＭ等の記録媒体
に格納されている場合には、その記録媒体を読み取り装
置に装着し、記録媒体からプログラムを読み出してハー
ドディスク装置に格納し、ハードディスク装置に格納さ
れたプログラムをＣＰＵが実行することにより、上述し
たようなサービス探索やサービス実行の処理が実行され
る。ネットワークを介してプログラムが配布される場合
には、通信インターフェースを介して取り込んだプログ
ラムをハードディスク装置に格納し、ハードディスク装
置に格納されたプログラムをＣＰＵが実行することによ
り、上述したようなサービス探索やサービス実行の処理
が実行されることになる。
【００６７】
【発明の効果】以上説明したように本発明は、ダイナミ
ックコンポーネントシステムにおいてインターフェース
が厳密には一致しなくても通信相手のコンポーネントを
発見できるようになり、これにより、コンポーネントの
多様性を維持しつつ、コンポーネントの連携チェーンを
効率的に動的に探索し、実行できるようになるという効
果がある。
ックコンポーネントシステムにおいてインターフェース
が厳密には一致しなくても通信相手のコンポーネントを
発見できるようになり、これにより、コンポーネントの
多様性を維持しつつ、コンポーネントの連携チェーンを
効率的に動的に探索し、実行できるようになるという効
果がある。
【図１】分散オグジェクトの概念を説明する図である。
【図２】サービス探索アルゴリズムを説明する図であ
る。
る。
【図３】サービス探索の処理を説明するフローチャート
である。
である。
【図４】サービスコンポーネントの構成を示すブロック
図である。
図である。
【図５】コンポーネント実装者による入出力インターフ
ェースの記述を示すフローチャートである。
ェースの記述を示すフローチャートである。
【図６】メッセージ送受信の処理を説明するフローチャ
ートである。
ートである。
【図７】サービス実行の処理の概要を説明する図であ
る。
る。
【図８】サービスを検索しながら実行する場合の処理の
概要を説明する図である。
概要を説明する図である。
【図９】サービスを検索しながら実行する場合の処理を
説明するフローチャートである。
説明するフローチャートである。
【図１０】サービスコンポーネントの構成の別の例を示
すブロック図である。
すブロック図である。
１０ ネットワーク
１１，１１1〜１１4 コンポーネント
１２ ユーザ
２１ メッセージ受信部
２２ 入力情報判定部
２３ 入力インターフェース
２４ サービス本体実装
２５ 出力インターフェース
２６ 返送条件判定部
２７ メッセージ転送部
２８ メッセージ返送部
２９ サービス実行結果
１０１〜１２２，１３１〜１４１ ステップ
─────────────────────────────────────────────────────
フロントページの続き
(72)発明者 藤井 慶太
アメリカ合衆国 カリフォルニア州 アー
バイン ３ ムラサキ
Ｆターム(参考） 5B045 BB04 BB28 BB42 BB53 GG01
5B076 DD06 DF06
5B098 AA10 GA01 GC11 GC14
5K030 GA14 HB19 MA01 MA03
Claims (12)
- 【請求項１】 ネットワーク上に分散配置されたコンポ
ーネントから、コンポーネントの連携チェーンを探索す
るサービス探索方法であって、 前記各コンポーネントにおいて、コンポーネントに入力
される情報の条件である入力インターフェースと、当該
コンポーネントがサービスを実行した結果についての情
報である出力インターフェースとを分離して定義して記
述し、 前記入力インターフェースにおいて、受容できる入力情
報を判別する際の比較条件を規定するメタ情報を導入
し、 第１のコンポーネントの出力インターフェースを入力情
報に代入したときに前記メタ情報に基づいて第２のコン
ポーネントの入力インターフェースが当該入力情報を受
容できるかを判断することを繰り返すことにより、コン
ポーネントの連携チェーンを探索する、サービス探索方
法。 - 【請求項２】 ネットワーク上に分散配置されたコンポ
ーネントから、コンポーネントの連携チェーンを探索す
るサービス探索方法であって、 前記各コンポーネントにおいて、コンポーネントに入力
される情報の条件である入力インターフェースと、当該
コンポーネントがサービスを実行した結果についての情
報である出力インターフェースとを分離して定義して記
述し、 前記入力インターフェースにおいて、受容できる入力情
報を判別する際の比較条件を規定するメタ情報を導入
し、 入力情報及び返送条件を記述したメッセージをコンポー
ネントが受信したとき、当該コンポーネントにおいて、
当該入力情報を当該コンポーネントの入力インターフェ
ースが受容できるか否か判別し、受容できる場合には、
前記メッセージの通過経路情報に当該コンポーネントを
識別する情報を追加し、当該入力情報の入力インタフェ
ースを当該コンポーネントの出力インターフェースで置
き換えて前記メッセージを前記ネットワーク内に送出
し、受容できない場合には前記メッセージを破棄し、前
記返送条件が当該コンポーネントの出力インターフェー
スを受容できる場合には、当該コンポーネントの出力結
果と前記通過経路情報を前記メッセージの送信者に返送
する、サービス探索方法。 - 【請求項３】 ネットワーク上に分散配置されたコンポ
ーネントを用い、コンポーネントの連携チェーンによっ
てサービスを実行するサービス実行方法であって、 前記各コンポーネントにおいて、コンポーネントに入力
される情報の条件である入力インターフェースと、当該
コンポーネントがサービスを実行した結果についての情
報である出力インターフェースとを分離して定義して記
述し、 前記入力インターフェースにおいて、受容できる入力情
報を判別する際の比較条件を規定するメタ情報を導入
し、 第１のコンポーネントの出力インターフェースを入力情
報に代入したときに前記メタ情報に基づいて第２のコン
ポーネントの入力インターフェースが当該入力情報を受
容できるかを判断することを繰り返すことにより、コン
ポーネントの連携チェーンを探索し、 前記探索された連携チェーンに含まれる各コンポーネン
トで順次処理を行わせることによりサービスを実行す
る、サービス実行方法。 - 【請求項４】 サービス実行結果が満たすべき条件を返
送条件として格納する探索リクエストを前記各コンポー
ネント間で巡回させることにより、前記各コンポーネン
トで順次処理を行わせ、前記サービス実行結果が前記返
送条件を満足するときに前記サービスの実行を終了す
る、請求項３に記載のサービス実行方法。 - 【請求項５】 ネットワーク上に分散配置されたコンポ
ーネントを用い、コンポーネントの連携チェーンによっ
てサービスを実行するサービス実行方法であって、 前記各コンポーネントにおいて、コンポーネントに入力
される情報の条件である入力インターフェースと、当該
コンポーネントがサービスを実行した結果についての情
報である出力インターフェースとを分離して定義して記
述し、 前記入力インターフェースにおいて、受容できる入力情
報を判別する際の比較条件を規定するメタ情報を導入
し、 入力情報及び返送条件を記述したメッセージをコンポー
ネントが受信したとき、当該コンポーネントにおいて、
当該入力情報を当該コンポーネントの入力インターフェ
ースが受容できるか否か判別し、受容できる場合には、
前記メッセージの通過経路情報に当該コンポーネントを
識別する情報を追加し、当該入力情報を当該コンポーネ
ントの出力インターフェースで置き換えて前記メッセー
ジを前記ネットワーク内に送出し、受容できない場合に
は前記メッセージを破棄し、前記返送条件が当該コンポ
ーネントの出力インターフェースを受容できる場合には
前記通過経路情報を前記メッセージの送信者に返送し、 前記通過経路情報での格納順に各コンポーネントを順次
起動させる、サービス実行方法。 - 【請求項６】 ネットワーク上に分散配置されたコンポ
ーネントを用い、コンポーネントの連携チェーンによっ
てサービスを実行するサービス実行方法であって、 前記各コンポーネントにおいて、コンポーネントに入力
される情報の条件である入力インターフェースと、当該
コンポーネントがサービスを実行した結果についての情
報である出力インターフェースとを分離して定義して記
述し、 前記入力インターフェースにおいて、受容できる入力情
報を判別する際の比較条件を規定するメタ情報を導入
し、 入力情報及び返送条件を記述したメッセージをコンポー
ネントが受信したとき、当該コンポーネントにおいて、
当該入力情報を当該コンポーネントの入力インターフェ
ースが受容できるか否か判別し、受容できる場合には、
前記入力情報に基づいてサービスを実行し、当該入力情
報を当該コンポーネントの実行結果で書き換えて前記メ
ッセージを前記ネットワーク内に送出し、受容できない
場合には前記メッセージを破棄し、前記返送条件が当該
コンポーネントの出力インターフェースを受容できる場
合には当該実行結果を前記メッセージの送信者に返送す
る、サービス実行方法。 - 【請求項７】 前記返送条件が当該コンポーネントの出
力インターフェースを受容できる場合には、前記メッセ
ージの前記ネットワーク内への送出を行わない、請求項
６に記載のサービス実行方法。 - 【請求項８】 ネットワーク上に分散配置されるコンポ
ーネントを表わすプログラムであって、 入力される情報の条件である入力インターフェースと、
サービスを実行した結果についての情報である出力イン
ターフェースとを分離して定義して記述し、前記入力イ
ンターフェースにおいて、受容できる入力情報を判別す
る際の比較条件を規定するメタ情報が導入され、 コンピュータに、 入力情報及び返送条件を記述したメッセージを受信した
とき、当該入力情報を前記入力インターフェースが受容
できるか否か判別し、受容できる場合には、前記メッセ
ージの通過経路情報に当該コンポーネントを識別する情
報を追加し、当該入力情報の入力インタフェースを前記
出力インターフェースで置き換えて前記メッセージを前
記ネットワーク内に送出し、受容できない場合には前記
メッセージを破棄し、前記返送条件が前記出力インター
フェースを受容できる場合には、当該コンポーネントの
出力結果と前記通過経路情報を前記メッセージの送信者
に返送する処理を実行させるプログラム。 - 【請求項９】 ネットワーク上に分散配置されるコンポ
ーネントを表わすプログラムであって、 入力される情報の条件である入力インターフェースと、
サービスを実行した結果についての情報である出力イン
ターフェースとを分離して定義して記述し、 前記入力インターフェースにおいて、受容できる入力情
報を判別する際の比較条件を規定するメタ情報が導入さ
れ、 コンピュータに、 コンポーネントの実行順を示す通過経路情報と入力情報
とを含むメッセージを受信したとき、前記入力情報に基
づいてサービスを実行し、前記通過経路情報から自コン
ポーネントの情報を追加してから前記メッセージを前記
ネットワーク内に送出する処理を実行させるプログラ
ム。 - 【請求項１０】 ネットワーク上に分散配置されるコン
ポーネントを表わすプログラムであって、 入力される情報の条件である入力インターフェースと、
サービスを実行した結果についての情報である出力イン
ターフェースとを分離して定義して記述し、 前記入力インターフェースにおいて、受容できる入力情
報を判別する際の比較条件を規定するメタ情報が導入さ
れ、 コンピュータに、 入力情報及び返送条件を記述したメッセージを受信した
とき、当該入力情報を前記入力インターフェースが受容
できるか否か判別し、受容できる場合には、前記入力情
報に基づいてサービスを実行し、当該入力情報を前記サ
ービスの実行結果で書き換えて前記メッセージを前記ネ
ットワーク内に送出し、受容できない場合には前記メッ
セージを破棄し、前記返送条件が前記出力インターフェ
ースを受容できる場合には当該実行結果を前記メッセー
ジの送信者に返送する処理を実行させるプログラム。 - 【請求項１１】 ネットワーク上に分散配置されるコン
ポーネントを表わすプログラムであって、 入力される情報の条件である入力インターフェースと、
サービスを実行した結果についての情報である出力イン
ターフェースとを分離して定義して記述し、 前記入力インターフェースにおいて、受容できる入力情
報を判別する際の比較条件を規定するメタ情報が導入さ
れ、 コンピュータに、 入力情報及び返送条件を記述したメッセージを受信した
とき、当該入力情報を前記入力インターフェースが受容
できるか否か判別し、当該入力情報を受容できない場合
には前記メッセージを破棄し、当該入力情報を受容でき
る場合には前記入力情報に基づいてサービスを実行し、
前記返送条件が前記出力インターフェースを受容できる
場合には当該実行結果を前記メッセージの送信者に返送
し、前記返送条件が受容できない場合には当該入力情報
を前記サービスの実行結果で書き換えて前記メッセージ
を前記ネットワーク内に送出する処理を実行させるプロ
グラム。 - 【請求項１２】 コンピュータが読取り可能な記録媒体
であって、請求項８乃至１１のいずれか１項に記載のプ
ログラムを格納した記録媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002057237A JP2003256391A (ja) | 2002-03-04 | 2002-03-04 | サービス探索方法、サービス実行方法、それらのプログラム及び該プログラムを記録した記録媒体 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002057237A JP2003256391A (ja) | 2002-03-04 | 2002-03-04 | サービス探索方法、サービス実行方法、それらのプログラム及び該プログラムを記録した記録媒体 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2003256391A true JP2003256391A (ja) | 2003-09-12 |
Family
ID=28667554
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002057237A Pending JP2003256391A (ja) | 2002-03-04 | 2002-03-04 | サービス探索方法、サービス実行方法、それらのプログラム及び該プログラムを記録した記録媒体 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2003256391A (ja) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2005234877A (ja) * | 2004-02-19 | 2005-09-02 | Nippon Telegr & Teleph Corp <Ntt> | ナビゲーション方法、ナビゲーションシステムおよびプログラム |
| WO2006134882A1 (ja) * | 2005-06-15 | 2006-12-21 | Yokogawa Electric Corporation | 分散アプリケーションシステムにおける装置 |
| JP2008210227A (ja) * | 2007-02-27 | 2008-09-11 | Nippon Telegr & Teleph Corp <Ntt> | サービス連結情報生成システム、方法、及びプログラム |
| WO2011121873A1 (ja) * | 2010-03-30 | 2011-10-06 | 日本電気株式会社 | プログラム処理方法、プログラム処理装置、およびコンピュータプログラム |
| JP2012033067A (ja) * | 2010-07-30 | 2012-02-16 | Ricoh Co Ltd | 画像形成装置と画像形成装置の連携シナリオ作成方法とプログラムとコンピュータ読み取り可能な記録媒体 |
| JP2015517272A (ja) * | 2012-04-16 | 2015-06-18 | テレフオンアクチーボラゲット エル エム エリクソン（パブル） | ソフトウェア定義型ネットワーキングを用いたインラインサービスの連鎖化 |
-
2002
- 2002-03-04 JP JP2002057237A patent/JP2003256391A/ja active Pending
Cited By (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2005234877A (ja) * | 2004-02-19 | 2005-09-02 | Nippon Telegr & Teleph Corp <Ntt> | ナビゲーション方法、ナビゲーションシステムおよびプログラム |
| JP4619011B2 (ja) * | 2004-02-19 | 2011-01-26 | 日本電信電話株式会社 | ナビゲーション方法、ナビゲーションシステムおよびプログラム |
| WO2006134882A1 (ja) * | 2005-06-15 | 2006-12-21 | Yokogawa Electric Corporation | 分散アプリケーションシステムにおける装置 |
| JP2008210227A (ja) * | 2007-02-27 | 2008-09-11 | Nippon Telegr & Teleph Corp <Ntt> | サービス連結情報生成システム、方法、及びプログラム |
| JP4588731B2 (ja) * | 2007-02-27 | 2010-12-01 | 日本電信電話株式会社 | サービス連結情報生成システム、方法、及びプログラム |
| WO2011121873A1 (ja) * | 2010-03-30 | 2011-10-06 | 日本電気株式会社 | プログラム処理方法、プログラム処理装置、およびコンピュータプログラム |
| US9342382B2 (en) | 2010-03-30 | 2016-05-17 | Nec Corporation | Program processing method, program processing apparatus, and computer program |
| JP2012033067A (ja) * | 2010-07-30 | 2012-02-16 | Ricoh Co Ltd | 画像形成装置と画像形成装置の連携シナリオ作成方法とプログラムとコンピュータ読み取り可能な記録媒体 |
| JP2015517272A (ja) * | 2012-04-16 | 2015-06-18 | テレフオンアクチーボラゲット エル エム エリクソン（パブル） | ソフトウェア定義型ネットワーキングを用いたインラインサービスの連鎖化 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR100322716B1 (ko) | 협력적 프록시 시스템의 개체 랜더링 분산 전개를 위한방법 및 장치 | |
| US9304808B2 (en) | Updating a workflow when a user reaches an impasse in the workflow | |
| JP6408545B2 (ja) | ロケーションニュートラルソフトウェアの需要増大に伴う展開に対するシステム及び方法 | |
| US6721780B1 (en) | Predictive pre-download of network objects | |
| US7117216B2 (en) | Method and apparatus for runtime merging of hierarchical trees | |
| US10430253B2 (en) | Updating workflow nodes in a workflow | |
| US20030055668A1 (en) | Workflow engine for automating business processes in scalable multiprocessor computer platforms | |
| US7532617B2 (en) | Method and apparatus for session initiation protocol application design, development, execution and integration | |
| JP2015008016A (ja) | グラフ型計算の分散サービス | |
| US7996840B2 (en) | Method, system, and apparatus for scheduling pattern based web services | |
| US20090006329A1 (en) | Methods and Apparatus for Evaluating XPath Filters on Fragmented and Distributed XML Documents | |
| US20040194111A1 (en) | Transfer of runtime-based application code | |
| US20030135587A1 (en) | Method and system of state management for data communications | |
| US6934761B1 (en) | User level web server cache control of in-kernel http cache | |
| US20100138544A1 (en) | Method and system for data processing | |
| JP4336363B2 (ja) | ビジネスプロセス実行方法、ビジネスプロセス実行システムおよびプログラム | |
| JP2003256391A (ja) | サービス探索方法、サービス実行方法、それらのプログラム及び該プログラムを記録した記録媒体 | |
| JP2005500741A (ja) | ペイロード検査を介したパケット・ルート付け、及び発行−申し込みネットワークにおける申し込み処理 | |
| JP4215710B2 (ja) | クライアントへのデータ送信および更新データの実行制御方法 | |
| US6128667A (en) | System and method for deferred resolution hypertext links | |
| JP2006508597A (ja) | デジタル通信データに基づいてアクションをトリガーする方法及びコンピュータ・システム | |
| CN114629904A (zh) | 一种分布式事件的处理方法、系统、设备及介质 | |
| De Nicola et al. | A basic calculus for modelling service level agreements | |
| US11546405B2 (en) | Methods for exposing mainframe data as a web service and devices thereof | |
| US8127026B2 (en) | User operation acting device, user operation acting program, and computer readable recording medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040121 |
|
| RD03 | Notification of appointment of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7423 Effective date: 20040121 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20040121 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20050610 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060215 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20060614 |