JP4145477B2 - オブジェクト連携装置 - Google Patents
オブジェクト連携装置 Download PDFInfo
- Publication number
- JP4145477B2 JP4145477B2 JP2000339165A JP2000339165A JP4145477B2 JP 4145477 B2 JP4145477 B2 JP 4145477B2 JP 2000339165 A JP2000339165 A JP 2000339165A JP 2000339165 A JP2000339165 A JP 2000339165A JP 4145477 B2 JP4145477 B2 JP 4145477B2
- Authority
- JP
- Japan
- Prior art keywords
- cooperation
- class
- conversion rule
- object class
- path
- 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.)
- Expired - Fee Related
Links
Images
Landscapes
- Multi Processors (AREA)
- Stored Programmes (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、コンピュータ群もしくはオブジェクト群の対話・協調などの連携処理を実施するオブジェクト連携装置に関する。特に、利用者が連携させる各オブジェクトのインタフェースの詳細を知らない場合でもオブジェクト同士を自動連携させてシステムを構築するオブジェクト連携装置に関する。
【０００２】
【従来の技術】
近年、ネットワーク化が進み、ネットワーク上に分散した複数のオブジェクトが互いに連携して処理を行うシステムが増大してきている。このような複数のオブジェクトが連携して処理を行うための技法として、オブジェクト指向型プログラミングやコンポーネント技術などの研究がなされている。
【０００３】
オブジェクト指向型プログラミングの一例として、オブジェクト指向技術の標準化と普及を目指して設立された業界団体ＯＭＧ（Object Management Group）によって定められた分散オブジェクト運用のための共通仕様ＣＯＲＢＡ（The Common Object Request Broker : Architecture and Specification）がある。
【０００４】
図２１に、ＣＯＲＢＡに基づいたクライアント／サーバシステムにおけるオブジェクト連携の例を示す。このシステムは、クライアントアプリケーションとサーバ・アプリケーションとが連携して、つまりオブジェクト連携により一連の処理を行うものである。
【０００５】
アプリケーション開発者は、クライアントおよびサーバそれぞれが提供するサービスのインターフェースをＩＤＬ（Interface Definition Language）で記述する。また、インターネットのワールドワイドウェブでのサービスのインタフェースはＷＳＤＬ（World wide web Service Definition Language）で記述する。インターフェースとして定義する内容は、オブジェクトに依頼できるオペレーション群であり、各々のオペレーションは、オペレーション名、パラメタの定義、戻り値の定義、エラー発生時の例外処理、付加情報などが定義される。
【０００６】
ＩＤＬなどで定義された内容を専用のコンパイラでコンパイルすることにより、クライアント用のスタブとサーバ用のスケルトンが生成される。スタブは、クライアントアプリケーションにＩＤＬなどで定義されたオペレーション群へのアクセスを提供するルーチン群である。クライアントアプリケーションは、スタブで提供されるルーチンを呼び出すことにより、オペレーションが起動される。スケルトンは、サーバ・アプリケーションが提供するメソッドルーチンヘのディスパッチングルーチンを提供する。
【０００７】
スタブおよびスケルトンは、対応するクライアントアプリケーションあるいはサーバ・アプリケーションが使用するプログラミング言語で生成される。たとえば、使用されるプログラミング言語がＣ言語であったとすると、スタブはＣ言語の関数群として生成され、クライアントアプリケーションは、実行したいオペレーションに対応する関数を呼び出すことにより、スタブ、ＯＲＢランタイム、スケルトンを経由してサーバ・アプリケーションの該当ルーチンが呼び出され、所定の処理が実行されたあと、その処理結果が呼び出し元のクライアントアプリケーションに返される。
【０００８】
【発明が解決しようとする課題】
このように、ＣＯＲＢＡなどによりオブジェクト連携処理を構築することは、容易になってきている。しかし、実際にこのような連携処理を構築しようとすると、前述のＣＯＲＢＡであれば、ＣＯＲＢＡそのものの理解とともに、ＣＯＲＢＡの仕様に応じたオブジェクトの設計およびＩＤＬやＷＳＤＬによる定義が必要となる。つまりシステムを構築する者は、ＩＤＬやＷＳＤＬで記述されたオブジェクトインタフェースの詳細およびその利用方法を熟知する必要がある。また、それぞれのオブジェクトの関係を強く意識する必要がある。つまり、それぞれのオブジェクトがどういう処理を行うのか、その処理を行うために必要となる受渡しのパラメタは何かなどを明確にしておかなければならない。例えば、サーバオブジェクトを利用する場合、そのオブジェクトに対応するＩＤＬ記述のインタフェースなどからスタブを作成し、そのスタブに対する操作をプログラムすることで利用可能となる。しかし、ＩＤＬ記述はインタフェースの羅列であり、その記述でオブジェクトの利用法を理解するには相当の経験を要することとなる。
【０００９】
また、連携がプログラム作成時に固定される点も問題点として挙げられる。複数のサーバオブジェクトを目的に合わせ連携させるとき、連携用のクライアントオブジェクトが必要となり、開発者は、該当するサーバオブジェクトのＩＤＬインタフェースやＷＳＤＬインタフェースを理解し、連携用のクライアントオブジェクトを作成する必要がある。作成されたオブジェクトはＩＤＬやＷＳＤＬを組み込むために固定的なものとなり、動的に変化させることはできない。従って連携させるサーバオブジェクトが異なるたびに連携用のクライアントオブジェクトが必要となる。このように連携用のクライアントオブジェクトはサーバオブジェクトの組み合わせの数だけ必要となる。ＩＤＬやＷＳＤＬを直接組み込むことなく動的にサーバオブジェクトを起動するダイナミックインボケーションなどのテクニックがあるが、メソッドのパラメタの意味をあらかじめ熟知してプログラムする必要があることから、すべてのサーバオブジェクトについてインプリメントすることは現実的ではない。
【００１０】
このように、従来のオブジェクト連携による分散処理方法は、あくまでもオブジェクトとオブジェクトの関係は固定であることを前提しており、このような自由な関係を持った分散処理を実現するオブジェクト連携システムの構築は困難であり、ＣＯＲＢＡやあるいはＤＣＯＭに代表されるオブジェクトアクセスを提供するための枠組みや分散オブジェクトのインターフェイスに関する枠組みは、オブジェクト間の連携をいかに動的に構築していくかという問題に十分に答えるものではない。
【００１１】
本発明のオブジェクト連携システムは、上記問題点に鑑み、各オブジェクトのインタフェースの記述を解析してオブジェクトの連携関係を簡潔に表現し、利用者の目的に応じた処理を実行できるオブジェクト間の連携関係を自動的に検出し、それらオブジェクト群の連携処理を柔軟に構築するオブジェクト連携装置を提供することを目的とする。
【００１２】
【課題を解決するための手段】
上記目的を達成するため、本発明のオブジェクト連携装置は、ネットワーク上のオブジェクトのインタフェース情報を入力して解析し、オブジェクト間の連携関係を変換ルールの集合として記述するルール記述部と、オブジェクト連携関係の始点となるオブジェクトクラスと終点となるオブジェクトクラスを指定するオブジェクトクラス指定部と、前記変換ルールに従ってオブジェクト間の連携関係を調べ、前記始点となるオブジェクトクラスと前記終点となるオブジェクトクラスをつなぐオブジェクトクラス間の連携パスを検出するオブジェクト連携パス検出部と、前記検出された連携パスに応じてオブジェクト間の連携関係の実行環境を構築するオブジェクト連携構築部と、前記始点となるオブジェクトクラスの値を指定する値指定部と、前記与えられた始点となるオブジェクトクラスの値を基に連携処理を実行するオブジェクト群とを備えたことを特徴とする。
【００１３】
上記構成により、オブジェクト連携装置は、各オブジェクトのインタフェースの記述を解析してオブジェクトの連携関係をルールの集合として簡潔に表現でき、当該ルールによりオブジェクト間の連携関係を調べることにより、利用者の利用目的に応じ、始点となるオブジェクトから終点となるオブジェクトまでのオブジェクト間の連携パスを自動的に検出でき、また、それらオブジェクト群の連携処理を柔軟に構築することができる。
【００１４】
ここで、前記オブジェクト連携構築部は、前記オブジェクト群の連携においてオブジェクト間に構造化メッセージと当該構造化メッセージに対する反応であるアクションとの関係づけによる連携関係を構築するものであり、連携元のオブジェクトに送信すべき構造化メッセージパターンを通知して実装させ、連携先のオブジェクトに受信により反応すべき前記構造化メッセージパターンおよび当該構造化メッセージパターンに対するアクションとを通知して実装させることが好ましく、また、前記オブジェクト群の各オブジェクトが、ネットワーク上に送信される構造化メッセージをモニタして取り込むメッセージ受信部と、構造化メッセージと構造化メッセージに対する反応であるアクションのセットを記憶する反応テーブルと、前記アクションの内容に従って処理を実行するアクション実行部を備え、前記メッセージ・アクションの反応関係に従って駆動することが好ましい。
【００１５】
上記構成により、利用者の目的に応じて発見されたオブジェクト間の連携パスに沿い、フィールドリアクターモデルを用いて各々のオブジェクト連携関係を構築することができ、オブジェクト連携の自動的かつ柔軟な構築が可能となる。ここでフィールドリアクターモデルとは、フィールド上に存在するオブジェクト同士が、構造表現された構造化メッセージと当該構造化メッセージに対する反応アクションとの関係づけに沿って連携し合う仕組みを言う。
【００１６】
さらに、前記オブジェクト連携パス検出部が、連携パスが複数検出された場合に一つの連携パスを利用者に選択させる連携パス選択部を備えることが好ましい。
【００１７】
なぜなら、インタフェース記述に曖昧性がある場合、一意に連携パスが定まらない場合もあり得るからである。かかる場合に連携パスを一意に定める。
【００１８】
さらに、前記オブジェクト連携パス検出部が、検出した一つながりの連携パスを構成する個々のサブ連携パスに分離し、各々のサブ連携パスを区別して連携パスの実行時コンテキストを生成し、前記連携パスをオブジェクトクラス間の連携パスから連携実行時に渡される値を変数としたオブジェクト連携実行用パターンの連携パスに変換するオブジェクト連携実行用パターン生成部を備えることが好ましい。
【００１９】
上記構成により、オブジェクト連携実行用パターンの連携パスを準備しておけば、オブジェクト連携実行時には当該変数に対する値を与えるのみでオブジェクトインスタンスレベルでのオブジェクト連携を簡単に実行できる。
【００２０】
ここで、前記オブジェクト連携構築部がオブジェクト間に連携関係を構築する場合、前記連携パスにおいて、複数のオブジェクト連携元とオブジェクト連携関係を持つオブジェクト連携先がある場合、前記オブジェクト連携先は前記複数のオブジェクト連携元の各々から個別に構造化メッセージを受信し、前記反応テーブルのアクションが発火するために必要なすべての引数が揃ったことを契機としてアクションを発火させる構造化メッセージパターン・反応アクションの関係づけを持つことが好ましい。
【００２１】
上記構成により、複数のオブジェクト連携元の処理を、いわゆるＡＮＤ演算の形で受け、所定複数のオブジェクト元との連携成立を契機としてオブジェクト連携先が反応するように連携関係を制御することができる。なお、このように複数のオブジェクト連携元との連携成立を契機としてオブジェクト連携先が反応する関係を「ジョイン（Ｊｏｉｎ）関係」と呼ぶ。また、前記ジョイン関係とは異なるバリエーションとして、複数のオブジェクト連携元の処理を、いわゆるＯＲ演算の形で受け、一又は所定組み合わせのオブジェクト元との連携成立を契機としてオブジェクト連携先が反応するように連携関係を制御することもできる。
【００２２】
さらに、前記オブジェクト連携パス検出部が連携パス検出の学習機能を備え、前記オブジェクトクラス指定部から与えられた始点となるオブジェクトクラスと終点となるオブジェクトクラスをつなぐオブジェクトクラス間の連携パスの検出結果を知識として蓄積し、連携パス検出処理に用いることが好ましい。
【００２３】
上記構成により、利用者の目的に応じたオブジェクト連携パスを学習でき、学習知識の蓄積とともに処理効率向上を図ることができる。
【００２４】
なお、上記の各構成において、前記オブジェクトのインタフェース情報がＩＤＬまたはＷＳＤＬのいずれかで記述された情報とすれば、ＣＯＲＢＡなど普及しつつあるオブジェクト連携システムに対して本発明を適用することが容易となる。
【００２５】
また、上記オブジェクト連携装置を実現する処理プログラムを記録した記録媒体を提供することにより、パーソナルコンピュータなどに記録媒体からオブジェクト連携装置を構成する処理プログラムを読み取らせて、安価かつ手軽に本発明のオブジェクト連携装置を実現することができる。
【００２６】
【発明の実施の形態】
（実施形態１）
本発明のオブジェクト連携システムは、各オブジェクトのインタフェース情報を解析してオブジェクトの連携関係を簡潔に表現し、利用者の目的に応じた処理を実行できるオブジェクト間の連携関係を自動的に検出し、それらオブジェクト群の連携処理を柔軟に構築するオブジェクト連携装置を提供するものである。本発明のオブジェクト連携装置が実行するオブジェクトの自動連携とは、利用者の利用目的に応じ、連携を開始するオブジェクトクラスの集合を出発点とし、ユーザが欲するオブジェクトクラスを終点とし、出発点から終点に至るまでのオブジェクトの連携を構成することである。ここでは連携を開始するオブジェクトクラスを始点オブジェクトクラスと呼び、最終的に目的のオブジェクトクラスを終点オブジェクトクラスと呼ぶことにする。なお以下では、便宜上、オブジェクトのインタフェース情報がＩＤＬで与えられている場合を例として説明する。
【００２７】
本実施形態１のオブジェクト連携装置は、第一の仕組みとして、ＩＤＬやＷＳＤＬなどの言語で定義された各オブジェクトのインタフェースの記述を解析し、オブジェクト間の連携関係の表現形式をそれら言語表現形式からオブジェクト間の連携関係を変換ルールの集合として記述した表現形式に変換する手段を備えている。
【００２８】
また、本実施形態１のオブジェクト連携装置は、第二の仕組みとして、利用者の目的に応じてオブジェクト連携関係の始点となるオブジェクトクラスと終点となるオブジェクトクラスを指定する手段と、変換ルールに従ってオブジェクト間の連携関係を調べ、始点となるオブジェクトクラスと終点となるオブジェクトクラスをつなぐオブジェクトクラス間の連携パスを検出する手段を備えている。
【００２９】
また、実施形態１のオブジェクト連携装置は、第三の仕組みとして、上記の第二の仕組みにおいて検出されたオブジェクト同士の連携パスをもとに、それらオブジェクト間の連携関係の実行環境を自動構築する仕組みを備えている。
【００３０】
さらに、実施形態１のオブジェクト連携装置は、第四の仕組みとして、実際のオブジェクト連携実行手段として、始点となるオブジェクトクラスの値を指定する手段と、与えられた始点となるオブジェクトクラスの値を基に連携処理を実行するオブジェクト群とを備えている。
【００３１】
図１にオブジェクト連携構築処理の概要を示す。まず、本発明のオブジェクト連携処理において、上記第一の仕組みとしてオブジェクト間の連携関係を示す変換ルール集合１０１を利用する。ＩＤＬはインタフェースの記述と同時にオブジェクトクラスおよびデータ型等についても定義している。そこでメソッドの入出力オブジェクトのクラスの関係に着目すると、メソッドは入力オブジェクトのクラス名から出力オブジェクトのクラス名への変換ルールと捉えることが可能である。この場合プリミティブなInt，Stringなどのデータ型は、システム定義のクラス名となる。また、継承関係も変換ルールとして表現する。このようにＩＤＬによって定義されたインタフェースを変換ルールとして、ユーザから与えられるＩＤＬ定義インタフェースの集合を変換ルール集合１０１として蓄積する。簡単な例を図２に示す。図２（ａ）はＩＤＬ記述によるインタフェース情報の例、図２（ｂ）は図２（ａ）のインタフェース情報から生成した変換ルールの例である。変換ルールの集合から各オブジェクトと変換ルールとの関係を模式的に図示した例が図３である。図３（ａ）の６つの変換ルールから図３（ｂ）のオブジェクトおよび変換ルールの関係が得られる。
【００３２】
次に、本発明のオブジェクト連携処理において、上記第二の仕組みとして連携パスの検出処理１０２を行う。オブジェクト連携順序は、変換ルールの適用順序として捉えることができる。ここでは変換ルールの適用順序を連携パスと呼ぶ。まず、ユーザは、始点オブジェクトクラスと終点オブジェクトクラスを連携パスの検出処理１０２に与え、連携パスの検出処理１０２はユーザから与えられた始点オブジェクトクラスから変換ルールを適用し、終点オブジェクトクラスへ到達するまでの変換ルールの適用順序を計算する。得られた変換ルールの適用順序をメソッドヘ逆変換することで、オブジェクトのメソッド呼び出しの関係を得ることができ、オブジェクトの連携を構築することができる。
【００３３】
なお、連携パスの検出方法としては複数の方法がある。第一には、指定された始点となるオブジェクトクラスから出発してオブジェクトの連携関係を順方向に拡大してゆき、終点となるオブジェクトクラスへ到達するパスを発見する方法がある。第二には、指定された終点となるオブジェクトクラスから出発してオブジェクトの連携関係を逆方向に拡大してゆき、始点となるオブジェクトクラスへ到達するパスを発見する方法がある。第三には指定された始点となるオブジェクトクラスおよび終点となるオブジェクトクラスの双方から出発して、始点となるオブジェクトクラスからはオブジェクトの連携関係を順方向に拡大してゆき、終点となるオブジェクトクラスからはオブジェクトの連携関係を逆方向に拡大してゆき、両者を結ぶパスを発見する方法がある。
【００３４】
ここで、連携パスが複数発見される場合があり得る。変換ルールは、インタフェース定義から生成されることから、この場合インタフェース定義に曖昧性が存在していることになる。複数の連携パスを発見した場合、開発者に曖昧性がある部分と複数個の連携パスを提示する。開発者は、提示された複数の連携から1つを選択するか、あるいは、指摘されたインタフェースの曖昧性がなくなるようＩＤＬ記述のインタフェースを修正する必要がある。インタフェース定義に曖昧性がなく、連携を考慮されている場合は、連携を自動的に構成する。
【００３５】
図４は連携パスの検出例を模式的に示した図である。図３（ｂ）に示したオブジェクトおよび変換ルールの関係に対して、始点オブジェクトクラスをＴ７とＴ５とし、終点オブジェクトクラスをＴ１として連携パスを検索した例である。この例では連携パス１および連携パス２の２つの連携パスが検出されている。例えば、利用者は連携パス１を選択したものとする。
【００３６】
次に、本発明のオブジェクト連携処理は、上記第三の仕組みとして、得られた連携パスをもとに実際のオブジェクト連携の構築処理１０３を行う。連携パスの変換ルールをメソッドに変換していくことで、オブジェクトのメソッド呼び出しの関係が構築される。
【００３７】
なお、連携パスからメッセージパターンの関係への変換にあたり、検出されたつながりの連携パスを構成する個々のサブ連携パスに分離し、各々のサブ連携パスに固有のＩＤ情報を割り振るなどして区別して連携パスの実行時コンテキストを生成し、前記連携パスをオブジェクトクラス間の連携パスから連携実行時に渡される値を変数としたオブジェクト連携実行用パターンの連携パスに変換する必要がある。サブ連携パスに分離する理由は以下である。フィールドリアクターモデルに従って実際のオブジェクト連携の実行時にはメッセージパターン・アクションの反応関係により行われ、複数のサブ連携パスに同じオブジェクトを含む場合がある。リアクターが備える反応テーブルがサブ連携パスを区別しない形のメッセージパターン・アクションの反応関係を持つ場合には、当該オブジェクトの処理がどのサブ連携パスにおける実行であるのか明確ではなくなり、サブ連携パス間での混乱が生じる。このようにサブ連携パス間での混乱が生じると全体の連携パスに沿ったオブジェクト間連携は正常に実行できなくなってしまう。そこで全体の連携パスをサブ連携パスに分離してサブ連携パスを区別し、連携パスの実行時コンテキストを加味した連携パターンを決定する。
【００３８】
例えば、生成規則((Ｃ1..,Ｃn)ｆＣ0)の実行時コンテキストは、(((Ｃ1:ｉ)..(Ｃn:ｊ))ｆ(Ｃ0:ｋ))のように表現される。なお、このコンテキストを生成するまでにＣ1はｉ回，Ｃnはｊ回，Ｃ0はｋ回出現したとする。以上の実行フロー処理の結果、ＩＤを付加された連携パスをもとに実行用パターンが生成される。
【００３９】
なお、オブジェクト連携を行うためには、オブジェクトインスタンスを特定する必要がある。オブジェクトインスタンスに固有のＩＤを割り付け、インスタンスＩＤとして取り扱う。オブジェクトインスタンスは、システムの実行時にはじめて決定するため、インスタンスＩＤの値を予めパターンに埋め込むことはできない。そこでインスタンスＩＤは、パターン中の変数に代入して取り扱う。また、生成規則を適用するためには、必要な項が全てが揃う必要がある。そのため、入力用パターンにｊｏｉｎを用いて項が全て揃うことを待つ。例えば、実行時コンテキストが生成された生成規則(((Ｃ1:ｉ)・・・(Ｃn:ｊ))ｆ(Ｃ0:k))は入力用パターンＰ=(ｊｏｉｎ((Ｃ1:$ｉｎｓｔ1)・・・(Ｃn:ｊ$ｉｎｓｔn)))である。出力用パターンＱ=(Ｃ0:ｋ$ｉｎｓｔl)となり、以下のように表現される。なお、Ｒは、関数ｆを持つシステムが提供するリアクターである。
【００４０】
ｆ∈Ｒ
(join((Ｃ1：ｉ$inst1)・・・(Ｃn：ｊ$instn)))⇒(Ｃ0：ｋ$instl)
連携パスについて以上の操作を行い、実行用パターンを生成する。
【００４１】
本実施形態１ではメソッドの呼び出しをフィールドリアクターモデルのパターン連携で行うことによりオブジェクトの関係をメッセージパターンの関係に変換する。ここで、フィールドリアクターモデルとは、構造表現された構造化メッセージパターンと当該構造化メッセージパターンに対する反応アクションとの関係づけの連鎖によりオブジェクト間の連携処理を実現するモデルである。実際のオブジェクト連携は、フィールドを介して構造化メッセージパターンとその反応アクションの関係づけによるオブジェクト間の連携として行われる。
【００４２】
リアクターは入力用パターンＰ、関数ｆ、出力用パターンＱを1組とした計算実行体(ＰｆＱ)を複数持つ。計算実行体(ＰｆＱ)は、応用の開発者によって予め定義される。各計算実行体は、互いに異なる入力用パターンＰを持つ。複数のリアクターは、それぞれ並列に自律的に動作し、１つのリアクターは、メッセージを受信した順序で処理する。リアクターは、自身の持つすべての計算実行体に対し、（１）パターンマッチ、（２）ユーザ関数呼び出し、（３）メッセージ生成を行う。パターンマッチでは、パターンＰを用いて、メッセージＭから置換θを取り出す。Ｐと共に定義されたユーザ関数ｆを取り出された置換θと共に呼び出し、関数出力として置換θ'を得る。関数出力より得た置換θ'をメッセージ生成用パターンＱの変数に代入することにより、メッセージＭ'を生成する。これらの処理を以下に表現する。パターンＰがマッチしない場合、（２）（３）の処理は実行しない。
【００４３】
（１）(θ,ｆ)=Mａｔｃｈ（Ｐ，Ｍ）
（２）θ'=ｆ(θ)
（３）Ｍ'=Ｑ・θ'
ここで、Ｍａｔｃｈはパターンマッチ関数であり、パターンＰとメッセージＭを引数とし、置換θおよび対応するユーザ関数ｆを出力する。ユーザ関数ｆは、置換を引数とし、置換を返す関数である。メッセージの生成は、出力用パターンＱの変数部に対し、置換θ'を代入することにより行う。
【００４４】
その模式的な構造は図５のようになる。フィールドリアクターモデルによれば、各リアクター２００は、関数および手続き２０６などの計算実行体であるアクション実行部２０５を内部に持つ抽象的計算主体であり、また、当該計算実行体とは独立したメッセージに対する入出力用パターンを反応テーブル２０４という形で持ち、計算実行体と連携を分離している。フィールド２０７は通信媒体であり、メッセージ送信部２０２を介して送信メッセージをフィールド２０７上の他のリアクターへ分配する。リアクター２００は、入力用の構造化メッセージパターンを用いてメッセージ受信部２０１を介してフィールド２０７からメッセージを取捨選択し、反応テーブル２０４に応じてアクション実行部２０５を起動し、出力用パターンを用いて生成したメッセージをフィールド２０７へ送出する。リアクター２００間の連携は、入出力用パターンの関係によって決定する。そのため、リアクター２００内に存在する計算実行体の連携も、計算実行体とは独立にメッセージパターンによって決定される。アプリケーションは、複数のリアクターとフィールド２０７によって構成される。連携動作は次の通りである。あるリアクターがメッセージをフィールド２０７へ送出する。各リアクターは、フィールド２０７からのそのメッセージを受け、自身が持つ複数の入力用パターンとパターンマッチを行い、メッセージを取捨選択する。選択されたメッセージは、入力用パターンに対応するアクション実行部２０５により処理され、その結果と出力用パターンを用いてメッセージを生成し、そのメッセージをフィールド２０７へ送出される。フィールドリアクターモデルでは、このような動作を繰り返す。
【００４５】
以上がフィールドリアクターモデルにおけるリアクターの基本構造である。
【００４６】
上記フィールドリアクターモデルを前提として実行フローとなるオブジェクト連携の構築にあたっては、連携パスを解析し、実行時コンテキストを生成し、実行時コンテキストを加味したパターンを作成する。
【００４７】
（１）実行時コンテキストの生成
（２）実行用パターンの生成
上記２つのステップにより実行フローとなるオブジェクト連携を構築する。
【００４８】
図６はオブジェクトの関係をメッセージパターンの関係に変換した様子を模式的に示した図である。なお、各メッセージパターンには固有に区別するＩＤ番号が割り振られている。例えば、３つあるメッセージパターンＴ５にはそれぞれ、Ｔ５：０、Ｔ５：１、Ｔ５：２というＩＤ番号が与えられている。
【００４９】
このように本発明のオブジェクト連携装置ではフィールドリアクターモデルを用いてメッセージパターン連携を通して実際のオブジェクト連携を行う。もっとも、オブジェクト連携はフィールドリアクターモデルによる連携に限定されることはない。
【００５０】
次に、本発明のオブジェクト連携処理は、上記第四の仕組みとして、構築した実際のオブジェクト連携処理１０４を実行するため、オブジェクトクラスの値を決めて連携の始点となるオブジェクトに与え、オブジェクトインスタンスレベルでのオブジェクト連携処理１０４を実行し、結果を得る。
【００５１】
上記のような仕組みにより、利用者の利用目的に応じたオブジェクト連携処理を構築して実行する。
【００５２】
以上、本実施形態１のオブジェクト連携装置は、ＩＤＬやＷＳＤＬなどの言語で定義された各オブジェクトのインタフェースの記述を解析してオブジェクト間の連携関係を変換ルールの集合として記述でき、当該変換ルールに従ってオブジェクト間の連携関係を調べ、始点となるオブジェクトクラスと終点となるオブジェクトクラスをつなぐオブジェクトクラス間の連携パスを検出し、それらオブジェクト間の連携関係の実行環境を自動構築することにより、与えられた値を基に連携処理を実行することができる。
【００５３】
（実施形態２）
次に、オブジェクト連携装置の具体的構成の一例と実際のアプリケーションの実例を挙げつつ説明する。
【００５４】
まず、本実施形態２のオブジェクト連携装置の概略構成を述べる。図７は、実施形態２にかかる本発明のオブジェクト連携装置の概略を示した図である。図７において、１０はオブジェクトインタフェース情報入力部、２０は変換ルール生成部、３０は変換ルールデータベース、４０は利用者インタフェース、５０は連携パス検出部、６０はオブジェクト連携関係構築部、７０はオブジェクト連携実行部、１００はオブジェクト群である。
【００５５】
オブジェクトインタフェース情報入力部１０は、ＩＤＬやＷＳＤＬなどインタフェースを定義する言語で記述された各オブジェクトのインタフェース情報を入力する部分である。入力にあたって利用者自身がＩＤＬやＷＳＤＬなどのインタフェース記述の詳細について熟知する必要はなく、ネットワーク上に存在する利用可能なオブジェクトに関するインタフェース情報を入力すれば良い。もちろん利用者からオブジェクトインタフェース情報に関しての詳細なデータの入力を受け付けることも可能である。
【００５６】
変換ルール生成部２０は、オブジェクトインタフェース情報入力部１０から入力されたＩＤＬやＷＳＤＬなどの言語で定義された各オブジェクトのインタフェース情報を解析し、オブジェクト間の連携関係の表現形式を言語による表現形式から変換ルールの集合とした表現形式に変換する部分である。
【００５７】
変換ルールデータベース３０は、変換ルール生成部２０において生成された変換ルールの集合を蓄積するデータベースである。
【００５８】
利用者インタフェース４０は、利用者インタフェースであり、利用者は利用者インタフェース４０を介してオブジェクト連携システムに対して必要なデータを入力する。利用者が構築したい処理内容に関するデータを入力する。この例では、オブジェクトクラス指定部４１と連携パス選択部４２と値指定部４３を備えている。オブジェクトクラス指定部４１は利用者が利用目的に応じてオブジェクト連携関係の始点となるオブジェクトクラスと終点となるオブジェクトクラスを指定する部分である。連携パス選択部４２は後述するように連携パス検出部５０において複数の連携パスの候補が得られた場合に、一つの連携パスを選択し、または一つの連携パスが選択できるようにオブジェクトインタフェース情報を追加する部分である。値指定部４３は後述するように、連携パスに沿ってオブジェクト連携構築部６０が構築したオブジェクト連携において実際にオブジェクト連携を実行するにあたり、始点となるオブジェクトクラスの値を指定・入力する部分である。
【００５９】
連携パス検出部５０は、利用者インタフェース４０から指定された始点となるオブジェクトクラスと終点となるオブジェクトクラスをつなぐ連携パスを検出する部分である。
【００６０】
ここで、オブジェクトインタフェース情報に曖昧性が存在する場合、オブジェクト連携ルールにも曖昧性が存在することとなり、連携パスが一意に定まらず複数の連携パスが検出される場合が想定できる。この場合、利用者に曖昧性が存在する部分と検出された複数の連携パスを利用者に提示し、連携パス選択部４２を介して利用者にそれら複数の連携パスから１つの連携パスを選択させるか、あるいは、指摘されたインタフェース記述の曖昧性がなくなるように利用者インタフェース４０を介してＩＤＬやＷＳＤＬの記述自体を修正させる。後者の場合はＩＤＬやＷＳＤＬなどの記述についての知識が必要となるが、前者の場合であればＩＤＬやＷＳＤＬの記述についての詳細な知識は必要とならない。
【００６１】
また、この例では、オブジェクト連携パス検出部５０は、オブジェクト連携実行用パターン生成部５１を備えている。オブジェクト連携実行用パターン生成部５１は、オブジェクト連携パス検出部５０において検出した一つながりの連携パスを構成する個々のサブ連携パスに分離し、各々のサブ連携パスに固有のＩＤ情報を割り振るなどして区別して連携パスの実行時コンテキストを生成し、前記連携パスをオブジェクトクラス間の連携パスから連携実行時に渡される値を変数としたオブジェクト連携実行用パターンの連携パスに変換する部分である。
【００６２】
なお、実際のオブジェクト連携実行時は、オブジェクトインスタンスを特定する必要があるが、オブジェクトインスタンスはシステム実行時に初めて決定されるため、オブジェクトインスタンスの値を予め規定することはできない。そこで連携実行時に渡される値を変数としたオブジェクト連携実行用パターンを生成しておけば良い。オブジェクト連携パス検出部５０は、オブジェクト連携実行用パターン生成部５１を用いて、連携パスをオブジェクトクラス間の連携パスから連携実行時に渡される値を変数としたオブジェクト連携実行用パターンの連携パスに変換する。
【００６３】
オブジェクト連携関係構築部６０は、連携パス検出部５０により検出された連携パスをもとに実際の実行フローとなるオブジェクト連携を構築する部分である。連携パスを形成するオブジェクト間を結ぶ変換ルールをメソッドに変換していくことで、オブジェクトのメソッド呼び出しの関係が構築されてオブジェクト間連携が構築される。本実施形態１のオブジェクト連携装置では、このメソッドの呼び出し関係をフィールドリアクターモデルを用いて構築することとし、構造化されたメッセージパターンと当該メッセージにより呼び出されるメソッドの関係として記述する。オブジェクト連携関係構築部６０は、連携元のオブジェクトに送信すべき構造化メッセージパターンを通知して実装させ、連携先のオブジェクトに受信により反応すべき前記構造化メッセージパターンおよび当該構造化メッセージパターンに対するアクションとを通知して実装させる。このように実際のオブジェクト間の連携は、フィールド上を流れるメッセージパターンとその反応となるアクションという関係でオブジェクト間の連携関係が構築されて行き、始点オブジェクトから終点オブジェクトに至るオブジェクト間連携が構築される。
【００６４】
オブジェクト連携実行部７０は、実際のオブジェクト連携の実行が行われるモジュールであり、値指定部４３を介して始点となるオブジェクトクラスの値がオブジェクト連携実行用パターンの変数部分に与えられ、オブジェクト群１００において実際のオブジェクト連携が実行される。
【００６５】
オブジェクト群１００は、ネットワーク上に存在するオブジェクト群であり、連携関係が構築される。本実施形態１ではオブジェクト連携関係はフィールドリアクターモデルにより構築されている。各オブジェクトは図５に示したフィールドリアクターモデルを実現する構成を含んでおり、ネットワーク上に送信される構造化メッセージをモニタして取り込むメッセージ受信部２０１と、構造化メッセージと構造化メッセージに対する反応であるアクションのセットを記憶する反応テーブル２０４と、各種関数やアプリケーション２０６を含み、アクションの内容に従って処理を実行するアクション実行部２０５と、アクションの一環として生成されたメッセージをフィールド上に送るメッセージ送信部２０２と、制御部２０３を備え、メッセージ・アクションの反応関係に従って駆動する。
【００６６】
次に、オブジェクト連携構築処理をアプリケーション例を挙げつつ、詳しく述べる。以下の例では、具体例としてＩＤＬで定義されているオブジェクトを利用した銀行の口座振り込み処理、ＷＳＤＬで定義されているオブジェクトを利用した旅行予約処理というを例を挙げつつ説明する。また、オブジェクト連携関係の構築はフィールドリアクターモデルで構築する例を説明する。
【００６７】
以下、大別して以下の４つの処理工程に分けて説明する。第一の処理工程は、入力されたＩＤＬやＷＳＤＬで記述された各オブジェクトのインタフェース情報を基にオブジェクト間の連携関係を簡潔に示すルールの集合を作成する処理工程である。第二の処理工程は、利用者から入力されたオブジェクト連携の始点となるオブジェクトクラスから終点となるオブジェクトクラスへ至るオブジェクト連携パスを検出する処理工程である。第三の処理工程は、検出したオブジェクト連携パスから実行フローを生成し、フィールドリアクターモデルの構造化メッセージ・反応アクション連携関係に基づいたオブジェクト連携関係を構築する処理工程である。第四の処理工程は、実際のオブジェクト連携実行処理であり、始点となるオブジェクトクラスの値を指定し、与えられた始点となるオブジェクトクラスの値を基に連携処理を実行する工程である。
【００６８】
第一の処理工程であるオブジェクト間の連携関係を簡潔に示すルールの集合を作成する処理工程の具体例を説明する。
【００６９】
この工程では、オブジェクトインタフェース記述入力部１０を介して各オブジェクトのＩＤＬで定義されたインタフェース記述情報を入力し、変換ルール生成部２０がこれら情報からＩＤＬによって定義されたオブジェクトクラスを変換ルールとして簡潔に表現する。オブジェクトクラスはメソッドおよびメンバー変数から構成される。ここで、オブジェクトクラスを記号と捉え、クラスの持つメソッドを引数のクラスから帰り値であるクラスへの連携ルールとみなす。例えば、クラスＣの持つメソッドｆは、はオブジェクトのリスト（Ｃ1，・・・，Ｃn）を引数とし、オブジェクトＣ0を返すとき、連携ルールを（Ｃ1・・・ＣnＣ）ＣfＣ0）と表現する。また、メンバー変数は仮想的なメソッドを適応し、得られた結果とする。例えば、クラスＣの型Ｔのメンバー変数ｗがあるとき、型Ｔを返す仮想メソッドＣｗとし、連携ルールとして表現する。また、ｉｎｔ，ｆｌｏａｔなどはＣＯＲＢＡが定義する基本型であり、これらの型を返す関数ｆφは、型ｎｉｌから基本型を返す関数と捉え、同様に連携ルールとして表現する。このようにＩＤＬで定義されるすべてのインタフェースを連携ルールとして表現し、変換ルールの集合を作成する。生成された変換ルールは変換ルールデータベース３０に格納される。図８は、銀行口座振り込み処理を実行するアプリケーション例において、オブジェクトインタフェース記述入力部１０を介して入力される各オブジェクトのＩＤＬで定義されたインタフェース記述情報の例である。図８に示したＩＤＬ記述によるインタフェース情報から変換ルール生成部２０が抽出した変換ルールは図９のようになる。図１０は、変換ルール生成部２０が図９の変換ルールの集合から生成したクラス間の関係を模式的に示した図である。
【００７０】
また、ＷＳＤＬで記述されたインタフェース情報に関しては以下のように考える。インターネットのウェブサービスを、入出力ポートを持つネットワークノードと考え、入力タイプと出力タイプを定義する。このように入出力タイプを定義することにより、ウェブサービスを、入力タイプのデータを出力タイプのデータに変換するルールと捉えることができる。図１１はＷＳＤＬで記述されたインタフェース情報の例を示す図であり、４つのウェブサービスのものが示されている。それぞれのタイプ定義も示されている。図１２は、変換ルール生成部２０が変換ルールの集合から生成したタイプ間の関係を模式的に示した図である。
【００７１】
次に、第二の処理工程であるオブジェクト連携パスを検出する処理工程の具体例を説明する。この処理工程では、利用者の利用目的に応じた処理を実現するオブジェクト間の連携パスを発見する。まず、利用者インタフェース４０のオブジェクト指定部４１を介して利用者の利用目的に応じ、オブジェクト連携の始点となるオブジェクトクラスの集合｛ＣＳ1，・・・，ＣＳn｝と終点オブジェクトのクラスＣgを指定する。連携パス検出部５０は、始点のオブジェクトクラスの集合および終点オブジェクトクラスの指定を受け、変換ルールデータベース３０のオブジェクト連携ルールを適用して始点のオブジェクトクラスの集合から終点オブジェクトクラスまで到達する変換ルールの適用順序を見つけ出す。適用順序の発見方法は、上述したように、指定された始点となるオブジェクトクラスから出発してオブジェクトの連携関係を順方向に拡大して終点となるオブジェクトクラスへ到達するパスを発見する方法や、指定された終点となるオブジェクトクラスから出発してオブジェクトの連携関係を逆方向に拡大して始点となるオブジェクトクラスへ到達するパスを発見する方法やその折衷方法などがある。
【００７２】
連携パス検出部５０が実行する連携パス検索処理を関数という形で記述する場合のアルゴリズムの一例を図１３に示す。関数ＦｉｎｄＰａｔｈは、始点オブジェクトクラスのリストＬS＝｛ＣＳ1，・・・，ＣＳn｝と終点オブジェクトのクラスＣｇを引数とし、連携パス集合を返す。もし連携パスが存在しないとき、ｎｉｌを返す。なお、ルールの集合Ｓ＝｛（Ｐ1ｆ1Ｑ1），・・・，（ＰnｆnＱn）｝、Ｐk＝（ｐ1・・・ｐn）である。ループによる無限展開の発生を抑えるため、ヒストリリストＨを用意する。ヒストリリストＨは既に検索した型の集合である。初期値はＨ：＝｛｝である。また、関数ＳｅａｒｃｈＲｕｌｅｓは、引数として型Ｃｇおよびルール集合Ｓをとる。この関数は、ルール集合ＳからＣｇを出力用パターンとする要素を取り出し、集合Ｓ＝｛（ＰkｆkＱk）∈Ｓ｜Ｑk＝Ｃg｝を返す。
【００７３】
図１４は、銀行口座振り込み処理を実行するアプリケーション例において、発見した変換ルールの適用順序を模式的に示す図である。図１４の例では始点となるオブジェクトクラスはＡｃｃｏｕｎｔＭａｎａｇｅｒ，ＡｃｃｏｕｎｔＩＤ，ｐａｙｍｅｎｔの３つであり終点となるオブジェクトクラスはｐａｙＲｅｓである。この例では一意に連携パスが定まったが、複数発見された場合、連携パス検出部５０は利用者インタフェース４０を介して複数の連携パスの候補があることを知らせ、連携パス指定部４２を介して利用者に連携パスを選択させる。
【００７４】
図１５は、出張予約処理を実行するアプリケーション例において、発見した変換ルールの適用順序を模式的に示す図である。図１５の例では始点となるタイプは、出発・到着場所（ｌｏｃａｔｉｏｎ），出発・帰省日（Ｄａｔｅ），出発時間（Ｔｉｍｅ）の３つであり終点となるタイプは出張前処理（ＣｏｏｒｄｉｎａｔｅＤｏｎｅ）である。この例では一意に連携パスが定まったが、複数発見された場合、連携パス検出部５０は利用者インタフェース４０を介して複数の連携パスの候補があることを知らせ、連携パス指定部４２を介して利用者に連携パスを選択させる。
【００７５】
次に、第三の処理工程であるオブジェクト連携関係を構築する処理工程の具体例を説明する。この処理工程は、第二の処理工程で検出したオブジェクト連携パスに基づいて実行フローを生成し、フィールドリアクターモデルによる構造化メッセージ・反応アクション連携関係を構築する処理工程である。本実施形態２ではＣＯＲＢＡを用いた場合の実行用パターンの生成について説明する。
【００７６】
図１６は、ＣＯＲＢＡを用いる場合の実行用パターンの生成処理の実行環境を示す図である。ＣＯＲＢＡオブジェクトプール３２０は、連携パス実行中にシステムが生成したＣＯＲＢＡオブジェクト３５０を管理し、オブジェクトに対する操作インタフェースを持つ。また、インスタンスＩＤを管理し、実体であるオブジェクトインスタンスヘのマッピングを行う。ＣＯＲＢＡオブジェクトファクトリ３３０は、ＣＯＲＢＡオブジェクト３５０をＣＯＲＢＡネーミングサービスを通して取得し、ＣＯＲＢＡオブジェクトファクトリ３３０が生成したオブジェクトをＣＯＲＢＡオブジェクトプール３２０ヘ渡す。オブジェクトファクトリ３３０は、リアクターであり、フィールドに対してネーミングサービスを提供する。ＣＯＲＢＡオブジェクトファクトリ３３０は、指定の名のオブジェクトを検索し、インスタンスＩＤを返す。パターンフォルダ３１０も同様にリアクターであり、連携パスを元に実行フローを生成・保持し、実行用パターンに応じて、ＣＯＲＢＡオブジェクト３５０をＣＯＲＢＡオブジェクトプール３２０を通して操作する。ユーザリアクター２００は、ＣＯＲＢＡオブジェクト３５０を操作する上で、ＩＤＬを意識する必要はなく、フィールド上のパターン連携によってＣＯＲＢＡオブジェクト３５０を取り扱うことができる。
【００７７】
フィールド２０７では、ＣＯＲＢＡオブジェクト３５０は全てインスタンスＩＤとして取り扱われ、パターンフォルダ３１０によってオブジェクトの実体に対して操作される。パターンフォルダ３１０は、メッセージに従いＣＯＲＢＡオブジェクト３５０を操作する。パターンフォルダ３１０は、オブジェクトの汎用的なメソッド起動関数Ｒ=Invoke(Ｏ,ｍ,Ｐ)を持つ。この関数は・オブジェクトのインスタンスＩＤ“Ｏ”、呼び出すメソッド名“ｍ”およびメソッド起動に必要なパラメータ列“Ｐ=(ｐ1,・・・,ｐn)”を引数とする。ＣＯＲＢＡオブジェクトプール３２０を通して、メソッドを起動した後、結果Ｒを返す。パラメータ列もインスタンスＩＤで表現する。実行用パターンは、各パターンに対応する起動関数と共にセットされる。パターンと共に設定された起動関数は、パターンマッチによって得られた置換を使用し、関数Invokeを呼び出す。Invokeの帰り値を置換に変換し、出力用パターンにその置換を適用しメッセージを生成する。
【００７８】
次に、第四の処理工程である実際のオブジェクト連携実行処理を説明する。
【００７９】
実際のオブジェクト連携の実行にあたり、値指定部４３を介して始点となるオブジェクトクラスの値を指定し、与えられた始点となるオブジェクトクラスの値を基に連携処理を実行する。起動はリアクターからスタートメッセージをフィールドへ流すことで行われる。スタートメッセージにより、パターンフォルダは実行フローに沿って、ＣＯＲＢＡオブジェクトの連携を開始し、連携パスを実行していく。実行は、フィールドを通して行われ、パターンフォルダを通してＣＯＲＢＡオブジェクトの実体が連携し、目的のオブジェクトが生成されるまで繰り返される。パターンの終点である目的のオブジェクトが生成された時点で終了する。
【００８０】
銀行口座振り込み処理を実行するアプリケーション例では、図１７に示すように、値として“振込元の銀行名”、“振込元の口座番号”、“振込先の銀行名”、“振込先の口座番号”、“振込金額”が与えられ、オブジェクト間の連携が実行され、銀行口座振り込み処理が実行される。
【００８１】
出張の予約処理を実行するアプリケーション例では、図１８に示すように、値として“出発場所（ｌｏｃａｔｉｏｎ）”、“到着場所（ｌｏｃａｔｉｏｎ）”、“出発日（Ｄａｔｅ）”、“帰省日（Ｄａｔｅ）”、“出発時間（Ｔｉｍｅ）”が与えられ、それぞれのオブジェクトに対応する値が与えられ、出張予約処理が実行される。
【００８２】
なお、図１８に示すように、同一データの使い回しやプロファイルデータを利用した自動データ入力も可能である。
【００８３】
以上、本発明の実施形態２のオブジェクト連携装置によれば、各オブジェクトのインタフェースの記述を解析してオブジェクトの連携関係をルールの集合として簡潔に表現でき、当該ルールによりオブジェクト間の連携関係を調べることにより、利用者の利用目的に応じ、始点となるオブジェクトから終点となるオブジェクトまでのオブジェクト間の連携パスを自動的に検出でき、また、それらオブジェクト群の連携処理を柔軟に構築することができる。
【００８４】
（実施形態３）
実施形態３のオブジェクト連携システムは、オブジェクト連携パス検出部が連携パス検出の学習機能を備え、前記オブジェクトクラス指定部から与えられた始点となるオブジェクトクラスと終点となるオブジェクトクラスをつなぐオブジェクトクラス間の連携パスの検出結果を知識として蓄積し、連携パス検出処理に用いる機能を備えたものである。
【００８５】
図１９は、実施形態３のオブジェクト連携システムの構成概略図である。オブジェクトインタフェース情報入力部１０、変換ルール生成部２０、変換ルールデータベース３０、利用者インタフェース４０、オブジェクト連携関係構築部６０、オブジェクト連携実行部７０、オブジェクト群１００は実施形態２で示した図７と同様であるが、連携パス検出部５０ａはオブジェクト連携実行用パターン生成部５１に加え、学習部５２、連携パス知識部５３を備えている。学習部５２および連携パス知識部５３は連携パス検出処理の学習機能を有し、連携パス検出部５０ａによる連携パス検出処理結果が得られると、学習部５２は、オブジェクトクラス指定部４１から与えられた始点となるオブジェクトクラスと終点となるオブジェクトクラスの入力に対し、検出された連携パスを結果として対応づけて学習し、その知識を連携パス知識部５３に格納する。連携パス検出部５０ａは次回以降の連携パス検出処理にあたり、連携パス知識部５３に格納された連携パス知識を活用して連携パスの検出処理を実行する。次回以降の連携パス検出処理において与えられた始点となるオブジェクトクラスと終点となるオブジェクトクラスが連携パス知識部５３に格納された連携パス知識のものと同様であれば、当該知識を活用して連携パスの検出処理が実行できる。
【００８６】
なお、ネットワーク上のオブジェクトの追加、削除、保守などによるサービス停止など、ネットワークの状態は動的に変化することもあるので、連携パス知識部５２に格納された連携パス知識を固定的なデータとして参照することはできない点に注意を要する。
【００８７】
以上、実施形態３のオブジェクト連携システムによれば、オブジェクト連携パス検出部が連携パス検出の学習機能を備え、オブジェクトクラス指定部から与えられた始点となるオブジェクトクラスと終点となるオブジェクトクラスをつなぐオブジェクトクラス間の連携パスの検出結果を知識として蓄積し、連携パス検出処理に用いることができる。
【００８８】
（実施形態４）
本発明のオブジェクト連携装置は、上記に説明した構成を実現する処理ステップを記述したプログラムをコンピュータ読み取り可能な記録媒体に記録して提供することにより、各種コンピュータを用いて構築することができる。本発明のオブジェクト連携装置を実現する処理ステップを備えたプログラムを記録した記録媒体は、図２０に図示した記録媒体の例に示すように、ＣＤ−ＲＯＭ１００２やフレキシブルディスク１００３等の可搬型記録媒体１００１だけでなく、ネットワーク上にある記録装置内の記録媒体１０００や、コンピュータのハードディスクやＲＡＭ等の記録媒体１００５のいずれであっても良く、プログラム実行時には、プログラムはコンピュータ１００４上にローディングされ、主メモリ上で実行される。
【００８９】
本発明のオブジェクト連携装置に関し、さらに以下の項を開示する。
【００９０】
（付記１）ネットワーク上のオブジェクトのインタフェース情報を入力して解析し、オブジェクト間の連携関係を変換ルールの集合として記述するルール記述部と、
オブジェクト連携関係の始点となるオブジェクトクラスと終点となるオブジェクトクラスを指定するオブジェクトクラス指定部と、
前記変換ルールに従ってオブジェクト間の連携関係を調べ、前記始点となるオブジェクトクラスと前記終点となるオブジェクトクラスをつなぐオブジェクトクラス間の連携パスを検出するオブジェクト連携パス検出部と、
前記検出された連携パスに応じてオブジェクト間の連携関係の実行環境を構築するオブジェクト連携構築部と、
前記始点となるオブジェクトクラスの値を指定する値指定部と、
前記与えられた始点となるオブジェクトクラスの値を基に連携処理を実行するオブジェクト群とを備えたことを特徴とするオブジェクト連携装置（１）。
【００９１】
（付記２）前記オブジェクト連携構築部は、前記オブジェクト群の連携においてオブジェクト間に構造化メッセージと当該構造化メッセージに対する反応であるアクションとの関係づけによる連携関係を構築するものであり、連携元のオブジェクトに送信すべき構造化メッセージパターンを通知して実装させ、連携先のオブジェクトに受信により反応すべき前記構造化メッセージパターンおよび当該構造化メッセージパターンに対するアクションとを通知して実装させる付記１に記載のオブジェクト連携装置（２）。
【００９２】
（付記３）前記オブジェクト群の各オブジェクトが、ネットワーク上に送信される構造化メッセージをモニタして取り込むメッセージ受信部と、構造化メッセージと構造化メッセージに対する反応であるアクションのセットを記憶する反応テーブルと、前記アクションの内容に従って処理を実行するアクション実行部を備え、前記メッセージ・アクションの反応関係に従って駆動する付記１または付記２に記載のオブジェクト連携装置（３）。
【００９３】
（付記４）前記オブジェクト連携パス検出部が、連携パスが複数検出された場合に一つの連携パスを利用者に選択させる連携パス選択部を備えた付記１から３のいずれかに記載のオブジェクト連携装置。
【００９４】
（付記５）前記オブジェクト連携パス検出部が、検出した一つながりの連携パスを構成する個々のサブ連携パスに分離し、各々のサブ連携パスを区別して連携パスの実行時コンテキストを生成し、前記連携パスをオブジェクトクラス間の連携パスから連携実行時に渡される値を変数としたオブジェクト連携実行用パターンの連携パスに変換するオブジェクト連携実行用パターン生成部を備えた付記１から３のいずれかに記載のオブジェクト連携装置（４）。
【００９５】
（付記６）前記連携パスにおいて、複数のオブジェクト連携元とオブジェクト連携関係を持つオブジェクト連携先がある場合、前記オブジェクト連携先は前記複数のオブジェクト連携元の各々から個別に構造化メッセージを受信し、前記反応テーブルのアクションが発火するために必要なすべての引数が揃ったことを契機としてアクションを発火させる構造化メッセージパターン・反応アクションの関係づけを持つ付記１から３のいずれかに記載のオブジェクト連携装置。
【００９６】
（付記７）前記連携パスにおいて、複数のオブジェクト連携先とオブジェクト連携関係を持つオブジェクト連携元がある場合、前記オブジェクト連携元はフィールドに構造化メッセージを送信し、前記複数のオブジェクト連携先の各々は前記構造化メッセージが受信されたことを契機として反応アクションを発火させる構造化メッセージパターン・反応アクションの関係づけを持つ付記１から３のいずれかに記載のオブジェクト連携装置。
【００９７】
（付記８）前記オブジェクト連携パス検出部が連携パス検出の学習機能を備え、前記オブジェクトクラス指定部から与えられた始点となるオブジェクトクラスと終点となるオブジェクトクラスをつなぐオブジェクトクラス間の連携パスの検出結果を知識として蓄積し、連携パス検出処理に用いる付記１から３のいずれかに記載のオブジェクト連携装置。
【００９８】
（付記９）前記オブジェクトのインタフェース情報がＩＤＬまたはＷＳＤＬのいずれかで記述された情報である付記１から３のいずれかに記載のオブジェクト連携装置。
【００９９】
（付記１０）オブジェクト間にオブジェクト連携関係を構築するオブジェクト連携装置を実現する処理プログラムを記録したコンピュータ装置読み取り可能な記録媒体であって、
ネットワーク上のオブジェクトのインタフェース情報を入力して解析し、オブジェクト間の連携関係を変換ルールの集合として記述するルール記述処理ステップと、
オブジェクト連携関係の始点となるオブジェクトクラスと終点となるオブジェクトクラスを指定するオブジェクトクラス指定処理ステップと、
前記変換ルールに従ってオブジェクト間の連携関係を調べ、前記始点となるオブジェクトクラスと前記終点となるオブジェクトクラスをつなぐオブジェクトクラス間の連携パスを検出するオブジェクト連携パス検出処理ステップと、
前記検出された連携パスに応じてオブジェクト間の連携関係の実行環境を構築するオブジェクト連携構築処理ステップと、
前記始点となるオブジェクトクラスの値を指定する値指定処理ステップと、
前記与えられた始点となるオブジェクトクラスの値を基に連携処理を実行するオブジェクトを生成する処理ステップとを備えた処理プログラムを記録したことを特徴とする記録媒体（５）。
【０１００】
【発明の効果】
本発明のオブジェクト連携装置によれば、各オブジェクトのインタフェースの記述を解析してオブジェクトの連携関係をルールの集合として簡潔に表現でき、当該ルールによりオブジェクト間の連携関係を調べることにより、利用者の利用目的に応じ、始点となるオブジェクトから終点となるオブジェクトまでのオブジェクト間の連携パスを自動的に検出でき、また、それらオブジェクト群の連携処理を柔軟に構築することができる。
【０１０１】
本発明のオブジェクト連携装置によれば、入力されたインタフェース記述に曖昧性がある場合でも、連携パスを一意に定め、オブジェクト間の実行フローを形成することができる。
【０１０２】
本発明のオブジェクト連携装置によれば、複数のオブジェクト連携元の処理を、いわゆるＡＮＤ演算の形で受け、所定複数のオブジェクト元との連携成立を契機としてオブジェクト連携先が反応するように連携関係を制御することができる。また、複数のオブジェクト連携元の処理を、いわゆるＯＲ演算の形で受け、一又は所定組み合わせのオブジェクト元との連携成立を契機としてオブジェクト連携先が反応するように連携関係を制御することもできる。
【０１０３】
さらに、連携パス検出の学習機能を備えることができ、オブジェクトクラス指定部から与えられた始点となるオブジェクトクラスと終点となるオブジェクトクラスをつなぐオブジェクトクラス間の連携パスの検出結果を知識として蓄積し、連携パス検出処理に用いることができ、処理効率向上を図ることができる。
【図面の簡単な説明】
【図１】 本発明の実施形態１にかかるオブジェクト連携構築処理の概要を模式的に示した図
【図２】 （ａ）はＩＤＬ記述によるインタフェース情報の例、（ｂ）は（ａ）のインタフェース情報から生成した変換ルールの例を示す図
【図３】 本発明の実施形態１にかかる変換ルールの集合から各オブジェクトと変換ルールとの関係を模式的に示した図
【図４】 本発明の実施形態１にかかる連携パスの検出例を模式的に示した図
【図５】 本発明の実施形態１にかかるフィールドリアクターモデルにおけるリアクターの模式的な構造を示した図
【図６】 本発明の実施形態１にかかるオブジェクトの関係をメッセージパターンの関係に変換した様子を模式的に示した図
【図７】 本発明の実施形態２にかかるオブジェクト連携装置の概略を示した図
【図８】 本発明の実施形態２にかかる銀行口座振り込み処理を実行するアプリケーション例における各オブジェクトのＩＤＬで定義されたインタフェース記述情報の例を示した図
【図９】 本発明の実施形態２にかかる図８に示したＩＤＬ記述によるインタフェース情報から変換ルール生成部２０が抽出した変換ルールを示す図
【図１０】 本発明の実施形態２にかかる図９の変換ルールの集合からルール生成部２０が生成したクラス間の関係を模式的に示した図
【図１１】 本発明の実施形態２にかかるＷＳＤＬで記述されたインタフェース情報の例を示す図
【図１２】 本発明の実施形態２にかかる図１１に示したＷＳＤＬ記述によるインタフェース情報から生成した変換ルールの集合におけるタイプ間の関係を模式的に示した図
【図１３】 本発明の実施形態２にかかる連携パス検出部５０が実行する連携パス検索処理を関数という形で記述する場合のアルゴリズムの一例を示す図
【図１４】 本発明の実施形態２にかかる銀行口座振り込み処理を実行するアプリケーション例において、発見した変換ルールの適用順序を模式的に示す図
【図１５】 本発明の実施形態２にかかる出張予約処理を実行するアプリケーション例において、発見した変換ルールの適用順序を模式的に示す図
【図１６】 本発明の実施形態２にかかるＣＯＲＢＡを用いる場合の実行用パターンの生成処理の実行環境を示す図
【図１７】 本発明の実施形態２にかかる銀行口座振り込み処理を実行するアプリケーション例におけるオブジェクト連携実行を示す図
【図１８】 本発明の実施形態２にかかる出張の予約処理を実行するアプリケーション例におけるオブジェクト連携実行を示す図
【図１９】 本発明の実施形態３にかかるオブジェクト連携装置の概略を示した図
【図２０】 本発明の実施形態４のオブジェクト連携装置を実現する処理プログラムを記録した記録媒体の例を示す図
【図２１】 従来技術のＣＯＲＢＡに基づいたクライアント／サーバシステムにおけるオブジェクト連携の例を示す図
【符号の説明】
１０ オブジェクトインタフェース情報入力部
２０ 変換ルール生成部
３０ 変換ルールデータベース
４０ 利用者インタフェース
４１ オブジェクトクラス指定部
４２ 連携パス選択部
４３ 値指定部
５０，５０ａ 連携パス検出部
５１ オブジェクト連携実行用パターン生成部
５２ 学習部
５３ 連携パス知識部
６０ オブジェクト連携関係構築部
７０ オブジェクト連携実行部
１００ オブジェクト群
１０１ 変換ルール集合
１０２ 連携パスの検出処理
１０３ オブジェクト連携の構築処理
１０４ オブジェクト連携処理
２００ リアクター
２０１ メッセージ受信部
２０２ メッセージ送信部
２０３ 制御部
２０４ 反応テーブル
２０５ アクション実行部
２０６ アクション実行部２０５が管理する各種関数、アプリケーション
２０７ フィールド
３１０ パターンフォルダ
３２０ ＣＯＲＢＡオブジェクトプール
３２１ スタブ
３３０ ＣＯＲＢＡオブジェクトファクトリ
３４０ オブジェクトリクエストブローカ
３５０ ＣＯＲＢＡオブジェクト
３６０ ＣＯＲＢＡホームサービス
１０００ 回線先のハードディスク等の記録媒体
１００１ ＣＤ−ＲＯＭやフレキシブルディスク等の可搬型記録媒体
１００２ ＣＤ−ＲＯＭ
１００３ フレキシブルディスク
１００４ コンピュータ
１００５ コンピュータ上のＲＡＭ／ハードディスク等の記録媒体
【発明の属する技術分野】
本発明は、コンピュータ群もしくはオブジェクト群の対話・協調などの連携処理を実施するオブジェクト連携装置に関する。特に、利用者が連携させる各オブジェクトのインタフェースの詳細を知らない場合でもオブジェクト同士を自動連携させてシステムを構築するオブジェクト連携装置に関する。
【０００２】
【従来の技術】
近年、ネットワーク化が進み、ネットワーク上に分散した複数のオブジェクトが互いに連携して処理を行うシステムが増大してきている。このような複数のオブジェクトが連携して処理を行うための技法として、オブジェクト指向型プログラミングやコンポーネント技術などの研究がなされている。
【０００３】
オブジェクト指向型プログラミングの一例として、オブジェクト指向技術の標準化と普及を目指して設立された業界団体ＯＭＧ（Object Management Group）によって定められた分散オブジェクト運用のための共通仕様ＣＯＲＢＡ（The Common Object Request Broker : Architecture and Specification）がある。
【０００４】
図２１に、ＣＯＲＢＡに基づいたクライアント／サーバシステムにおけるオブジェクト連携の例を示す。このシステムは、クライアントアプリケーションとサーバ・アプリケーションとが連携して、つまりオブジェクト連携により一連の処理を行うものである。
【０００５】
アプリケーション開発者は、クライアントおよびサーバそれぞれが提供するサービスのインターフェースをＩＤＬ（Interface Definition Language）で記述する。また、インターネットのワールドワイドウェブでのサービスのインタフェースはＷＳＤＬ（World wide web Service Definition Language）で記述する。インターフェースとして定義する内容は、オブジェクトに依頼できるオペレーション群であり、各々のオペレーションは、オペレーション名、パラメタの定義、戻り値の定義、エラー発生時の例外処理、付加情報などが定義される。
【０００６】
ＩＤＬなどで定義された内容を専用のコンパイラでコンパイルすることにより、クライアント用のスタブとサーバ用のスケルトンが生成される。スタブは、クライアントアプリケーションにＩＤＬなどで定義されたオペレーション群へのアクセスを提供するルーチン群である。クライアントアプリケーションは、スタブで提供されるルーチンを呼び出すことにより、オペレーションが起動される。スケルトンは、サーバ・アプリケーションが提供するメソッドルーチンヘのディスパッチングルーチンを提供する。
【０００７】
スタブおよびスケルトンは、対応するクライアントアプリケーションあるいはサーバ・アプリケーションが使用するプログラミング言語で生成される。たとえば、使用されるプログラミング言語がＣ言語であったとすると、スタブはＣ言語の関数群として生成され、クライアントアプリケーションは、実行したいオペレーションに対応する関数を呼び出すことにより、スタブ、ＯＲＢランタイム、スケルトンを経由してサーバ・アプリケーションの該当ルーチンが呼び出され、所定の処理が実行されたあと、その処理結果が呼び出し元のクライアントアプリケーションに返される。
【０００８】
【発明が解決しようとする課題】
このように、ＣＯＲＢＡなどによりオブジェクト連携処理を構築することは、容易になってきている。しかし、実際にこのような連携処理を構築しようとすると、前述のＣＯＲＢＡであれば、ＣＯＲＢＡそのものの理解とともに、ＣＯＲＢＡの仕様に応じたオブジェクトの設計およびＩＤＬやＷＳＤＬによる定義が必要となる。つまりシステムを構築する者は、ＩＤＬやＷＳＤＬで記述されたオブジェクトインタフェースの詳細およびその利用方法を熟知する必要がある。また、それぞれのオブジェクトの関係を強く意識する必要がある。つまり、それぞれのオブジェクトがどういう処理を行うのか、その処理を行うために必要となる受渡しのパラメタは何かなどを明確にしておかなければならない。例えば、サーバオブジェクトを利用する場合、そのオブジェクトに対応するＩＤＬ記述のインタフェースなどからスタブを作成し、そのスタブに対する操作をプログラムすることで利用可能となる。しかし、ＩＤＬ記述はインタフェースの羅列であり、その記述でオブジェクトの利用法を理解するには相当の経験を要することとなる。
【０００９】
また、連携がプログラム作成時に固定される点も問題点として挙げられる。複数のサーバオブジェクトを目的に合わせ連携させるとき、連携用のクライアントオブジェクトが必要となり、開発者は、該当するサーバオブジェクトのＩＤＬインタフェースやＷＳＤＬインタフェースを理解し、連携用のクライアントオブジェクトを作成する必要がある。作成されたオブジェクトはＩＤＬやＷＳＤＬを組み込むために固定的なものとなり、動的に変化させることはできない。従って連携させるサーバオブジェクトが異なるたびに連携用のクライアントオブジェクトが必要となる。このように連携用のクライアントオブジェクトはサーバオブジェクトの組み合わせの数だけ必要となる。ＩＤＬやＷＳＤＬを直接組み込むことなく動的にサーバオブジェクトを起動するダイナミックインボケーションなどのテクニックがあるが、メソッドのパラメタの意味をあらかじめ熟知してプログラムする必要があることから、すべてのサーバオブジェクトについてインプリメントすることは現実的ではない。
【００１０】
このように、従来のオブジェクト連携による分散処理方法は、あくまでもオブジェクトとオブジェクトの関係は固定であることを前提しており、このような自由な関係を持った分散処理を実現するオブジェクト連携システムの構築は困難であり、ＣＯＲＢＡやあるいはＤＣＯＭに代表されるオブジェクトアクセスを提供するための枠組みや分散オブジェクトのインターフェイスに関する枠組みは、オブジェクト間の連携をいかに動的に構築していくかという問題に十分に答えるものではない。
【００１１】
本発明のオブジェクト連携システムは、上記問題点に鑑み、各オブジェクトのインタフェースの記述を解析してオブジェクトの連携関係を簡潔に表現し、利用者の目的に応じた処理を実行できるオブジェクト間の連携関係を自動的に検出し、それらオブジェクト群の連携処理を柔軟に構築するオブジェクト連携装置を提供することを目的とする。
【００１２】
【課題を解決するための手段】
上記目的を達成するため、本発明のオブジェクト連携装置は、ネットワーク上のオブジェクトのインタフェース情報を入力して解析し、オブジェクト間の連携関係を変換ルールの集合として記述するルール記述部と、オブジェクト連携関係の始点となるオブジェクトクラスと終点となるオブジェクトクラスを指定するオブジェクトクラス指定部と、前記変換ルールに従ってオブジェクト間の連携関係を調べ、前記始点となるオブジェクトクラスと前記終点となるオブジェクトクラスをつなぐオブジェクトクラス間の連携パスを検出するオブジェクト連携パス検出部と、前記検出された連携パスに応じてオブジェクト間の連携関係の実行環境を構築するオブジェクト連携構築部と、前記始点となるオブジェクトクラスの値を指定する値指定部と、前記与えられた始点となるオブジェクトクラスの値を基に連携処理を実行するオブジェクト群とを備えたことを特徴とする。
【００１３】
上記構成により、オブジェクト連携装置は、各オブジェクトのインタフェースの記述を解析してオブジェクトの連携関係をルールの集合として簡潔に表現でき、当該ルールによりオブジェクト間の連携関係を調べることにより、利用者の利用目的に応じ、始点となるオブジェクトから終点となるオブジェクトまでのオブジェクト間の連携パスを自動的に検出でき、また、それらオブジェクト群の連携処理を柔軟に構築することができる。
【００１４】
ここで、前記オブジェクト連携構築部は、前記オブジェクト群の連携においてオブジェクト間に構造化メッセージと当該構造化メッセージに対する反応であるアクションとの関係づけによる連携関係を構築するものであり、連携元のオブジェクトに送信すべき構造化メッセージパターンを通知して実装させ、連携先のオブジェクトに受信により反応すべき前記構造化メッセージパターンおよび当該構造化メッセージパターンに対するアクションとを通知して実装させることが好ましく、また、前記オブジェクト群の各オブジェクトが、ネットワーク上に送信される構造化メッセージをモニタして取り込むメッセージ受信部と、構造化メッセージと構造化メッセージに対する反応であるアクションのセットを記憶する反応テーブルと、前記アクションの内容に従って処理を実行するアクション実行部を備え、前記メッセージ・アクションの反応関係に従って駆動することが好ましい。
【００１５】
上記構成により、利用者の目的に応じて発見されたオブジェクト間の連携パスに沿い、フィールドリアクターモデルを用いて各々のオブジェクト連携関係を構築することができ、オブジェクト連携の自動的かつ柔軟な構築が可能となる。ここでフィールドリアクターモデルとは、フィールド上に存在するオブジェクト同士が、構造表現された構造化メッセージと当該構造化メッセージに対する反応アクションとの関係づけに沿って連携し合う仕組みを言う。
【００１６】
さらに、前記オブジェクト連携パス検出部が、連携パスが複数検出された場合に一つの連携パスを利用者に選択させる連携パス選択部を備えることが好ましい。
【００１７】
なぜなら、インタフェース記述に曖昧性がある場合、一意に連携パスが定まらない場合もあり得るからである。かかる場合に連携パスを一意に定める。
【００１８】
さらに、前記オブジェクト連携パス検出部が、検出した一つながりの連携パスを構成する個々のサブ連携パスに分離し、各々のサブ連携パスを区別して連携パスの実行時コンテキストを生成し、前記連携パスをオブジェクトクラス間の連携パスから連携実行時に渡される値を変数としたオブジェクト連携実行用パターンの連携パスに変換するオブジェクト連携実行用パターン生成部を備えることが好ましい。
【００１９】
上記構成により、オブジェクト連携実行用パターンの連携パスを準備しておけば、オブジェクト連携実行時には当該変数に対する値を与えるのみでオブジェクトインスタンスレベルでのオブジェクト連携を簡単に実行できる。
【００２０】
ここで、前記オブジェクト連携構築部がオブジェクト間に連携関係を構築する場合、前記連携パスにおいて、複数のオブジェクト連携元とオブジェクト連携関係を持つオブジェクト連携先がある場合、前記オブジェクト連携先は前記複数のオブジェクト連携元の各々から個別に構造化メッセージを受信し、前記反応テーブルのアクションが発火するために必要なすべての引数が揃ったことを契機としてアクションを発火させる構造化メッセージパターン・反応アクションの関係づけを持つことが好ましい。
【００２１】
上記構成により、複数のオブジェクト連携元の処理を、いわゆるＡＮＤ演算の形で受け、所定複数のオブジェクト元との連携成立を契機としてオブジェクト連携先が反応するように連携関係を制御することができる。なお、このように複数のオブジェクト連携元との連携成立を契機としてオブジェクト連携先が反応する関係を「ジョイン（Ｊｏｉｎ）関係」と呼ぶ。また、前記ジョイン関係とは異なるバリエーションとして、複数のオブジェクト連携元の処理を、いわゆるＯＲ演算の形で受け、一又は所定組み合わせのオブジェクト元との連携成立を契機としてオブジェクト連携先が反応するように連携関係を制御することもできる。
【００２２】
さらに、前記オブジェクト連携パス検出部が連携パス検出の学習機能を備え、前記オブジェクトクラス指定部から与えられた始点となるオブジェクトクラスと終点となるオブジェクトクラスをつなぐオブジェクトクラス間の連携パスの検出結果を知識として蓄積し、連携パス検出処理に用いることが好ましい。
【００２３】
上記構成により、利用者の目的に応じたオブジェクト連携パスを学習でき、学習知識の蓄積とともに処理効率向上を図ることができる。
【００２４】
なお、上記の各構成において、前記オブジェクトのインタフェース情報がＩＤＬまたはＷＳＤＬのいずれかで記述された情報とすれば、ＣＯＲＢＡなど普及しつつあるオブジェクト連携システムに対して本発明を適用することが容易となる。
【００２５】
また、上記オブジェクト連携装置を実現する処理プログラムを記録した記録媒体を提供することにより、パーソナルコンピュータなどに記録媒体からオブジェクト連携装置を構成する処理プログラムを読み取らせて、安価かつ手軽に本発明のオブジェクト連携装置を実現することができる。
【００２６】
【発明の実施の形態】
（実施形態１）
本発明のオブジェクト連携システムは、各オブジェクトのインタフェース情報を解析してオブジェクトの連携関係を簡潔に表現し、利用者の目的に応じた処理を実行できるオブジェクト間の連携関係を自動的に検出し、それらオブジェクト群の連携処理を柔軟に構築するオブジェクト連携装置を提供するものである。本発明のオブジェクト連携装置が実行するオブジェクトの自動連携とは、利用者の利用目的に応じ、連携を開始するオブジェクトクラスの集合を出発点とし、ユーザが欲するオブジェクトクラスを終点とし、出発点から終点に至るまでのオブジェクトの連携を構成することである。ここでは連携を開始するオブジェクトクラスを始点オブジェクトクラスと呼び、最終的に目的のオブジェクトクラスを終点オブジェクトクラスと呼ぶことにする。なお以下では、便宜上、オブジェクトのインタフェース情報がＩＤＬで与えられている場合を例として説明する。
【００２７】
本実施形態１のオブジェクト連携装置は、第一の仕組みとして、ＩＤＬやＷＳＤＬなどの言語で定義された各オブジェクトのインタフェースの記述を解析し、オブジェクト間の連携関係の表現形式をそれら言語表現形式からオブジェクト間の連携関係を変換ルールの集合として記述した表現形式に変換する手段を備えている。
【００２８】
また、本実施形態１のオブジェクト連携装置は、第二の仕組みとして、利用者の目的に応じてオブジェクト連携関係の始点となるオブジェクトクラスと終点となるオブジェクトクラスを指定する手段と、変換ルールに従ってオブジェクト間の連携関係を調べ、始点となるオブジェクトクラスと終点となるオブジェクトクラスをつなぐオブジェクトクラス間の連携パスを検出する手段を備えている。
【００２９】
また、実施形態１のオブジェクト連携装置は、第三の仕組みとして、上記の第二の仕組みにおいて検出されたオブジェクト同士の連携パスをもとに、それらオブジェクト間の連携関係の実行環境を自動構築する仕組みを備えている。
【００３０】
さらに、実施形態１のオブジェクト連携装置は、第四の仕組みとして、実際のオブジェクト連携実行手段として、始点となるオブジェクトクラスの値を指定する手段と、与えられた始点となるオブジェクトクラスの値を基に連携処理を実行するオブジェクト群とを備えている。
【００３１】
図１にオブジェクト連携構築処理の概要を示す。まず、本発明のオブジェクト連携処理において、上記第一の仕組みとしてオブジェクト間の連携関係を示す変換ルール集合１０１を利用する。ＩＤＬはインタフェースの記述と同時にオブジェクトクラスおよびデータ型等についても定義している。そこでメソッドの入出力オブジェクトのクラスの関係に着目すると、メソッドは入力オブジェクトのクラス名から出力オブジェクトのクラス名への変換ルールと捉えることが可能である。この場合プリミティブなInt，Stringなどのデータ型は、システム定義のクラス名となる。また、継承関係も変換ルールとして表現する。このようにＩＤＬによって定義されたインタフェースを変換ルールとして、ユーザから与えられるＩＤＬ定義インタフェースの集合を変換ルール集合１０１として蓄積する。簡単な例を図２に示す。図２（ａ）はＩＤＬ記述によるインタフェース情報の例、図２（ｂ）は図２（ａ）のインタフェース情報から生成した変換ルールの例である。変換ルールの集合から各オブジェクトと変換ルールとの関係を模式的に図示した例が図３である。図３（ａ）の６つの変換ルールから図３（ｂ）のオブジェクトおよび変換ルールの関係が得られる。
【００３２】
次に、本発明のオブジェクト連携処理において、上記第二の仕組みとして連携パスの検出処理１０２を行う。オブジェクト連携順序は、変換ルールの適用順序として捉えることができる。ここでは変換ルールの適用順序を連携パスと呼ぶ。まず、ユーザは、始点オブジェクトクラスと終点オブジェクトクラスを連携パスの検出処理１０２に与え、連携パスの検出処理１０２はユーザから与えられた始点オブジェクトクラスから変換ルールを適用し、終点オブジェクトクラスへ到達するまでの変換ルールの適用順序を計算する。得られた変換ルールの適用順序をメソッドヘ逆変換することで、オブジェクトのメソッド呼び出しの関係を得ることができ、オブジェクトの連携を構築することができる。
【００３３】
なお、連携パスの検出方法としては複数の方法がある。第一には、指定された始点となるオブジェクトクラスから出発してオブジェクトの連携関係を順方向に拡大してゆき、終点となるオブジェクトクラスへ到達するパスを発見する方法がある。第二には、指定された終点となるオブジェクトクラスから出発してオブジェクトの連携関係を逆方向に拡大してゆき、始点となるオブジェクトクラスへ到達するパスを発見する方法がある。第三には指定された始点となるオブジェクトクラスおよび終点となるオブジェクトクラスの双方から出発して、始点となるオブジェクトクラスからはオブジェクトの連携関係を順方向に拡大してゆき、終点となるオブジェクトクラスからはオブジェクトの連携関係を逆方向に拡大してゆき、両者を結ぶパスを発見する方法がある。
【００３４】
ここで、連携パスが複数発見される場合があり得る。変換ルールは、インタフェース定義から生成されることから、この場合インタフェース定義に曖昧性が存在していることになる。複数の連携パスを発見した場合、開発者に曖昧性がある部分と複数個の連携パスを提示する。開発者は、提示された複数の連携から1つを選択するか、あるいは、指摘されたインタフェースの曖昧性がなくなるようＩＤＬ記述のインタフェースを修正する必要がある。インタフェース定義に曖昧性がなく、連携を考慮されている場合は、連携を自動的に構成する。
【００３５】
図４は連携パスの検出例を模式的に示した図である。図３（ｂ）に示したオブジェクトおよび変換ルールの関係に対して、始点オブジェクトクラスをＴ７とＴ５とし、終点オブジェクトクラスをＴ１として連携パスを検索した例である。この例では連携パス１および連携パス２の２つの連携パスが検出されている。例えば、利用者は連携パス１を選択したものとする。
【００３６】
次に、本発明のオブジェクト連携処理は、上記第三の仕組みとして、得られた連携パスをもとに実際のオブジェクト連携の構築処理１０３を行う。連携パスの変換ルールをメソッドに変換していくことで、オブジェクトのメソッド呼び出しの関係が構築される。
【００３７】
なお、連携パスからメッセージパターンの関係への変換にあたり、検出されたつながりの連携パスを構成する個々のサブ連携パスに分離し、各々のサブ連携パスに固有のＩＤ情報を割り振るなどして区別して連携パスの実行時コンテキストを生成し、前記連携パスをオブジェクトクラス間の連携パスから連携実行時に渡される値を変数としたオブジェクト連携実行用パターンの連携パスに変換する必要がある。サブ連携パスに分離する理由は以下である。フィールドリアクターモデルに従って実際のオブジェクト連携の実行時にはメッセージパターン・アクションの反応関係により行われ、複数のサブ連携パスに同じオブジェクトを含む場合がある。リアクターが備える反応テーブルがサブ連携パスを区別しない形のメッセージパターン・アクションの反応関係を持つ場合には、当該オブジェクトの処理がどのサブ連携パスにおける実行であるのか明確ではなくなり、サブ連携パス間での混乱が生じる。このようにサブ連携パス間での混乱が生じると全体の連携パスに沿ったオブジェクト間連携は正常に実行できなくなってしまう。そこで全体の連携パスをサブ連携パスに分離してサブ連携パスを区別し、連携パスの実行時コンテキストを加味した連携パターンを決定する。
【００３８】
例えば、生成規則((Ｃ1..,Ｃn)ｆＣ0)の実行時コンテキストは、(((Ｃ1:ｉ)..(Ｃn:ｊ))ｆ(Ｃ0:ｋ))のように表現される。なお、このコンテキストを生成するまでにＣ1はｉ回，Ｃnはｊ回，Ｃ0はｋ回出現したとする。以上の実行フロー処理の結果、ＩＤを付加された連携パスをもとに実行用パターンが生成される。
【００３９】
なお、オブジェクト連携を行うためには、オブジェクトインスタンスを特定する必要がある。オブジェクトインスタンスに固有のＩＤを割り付け、インスタンスＩＤとして取り扱う。オブジェクトインスタンスは、システムの実行時にはじめて決定するため、インスタンスＩＤの値を予めパターンに埋め込むことはできない。そこでインスタンスＩＤは、パターン中の変数に代入して取り扱う。また、生成規則を適用するためには、必要な項が全てが揃う必要がある。そのため、入力用パターンにｊｏｉｎを用いて項が全て揃うことを待つ。例えば、実行時コンテキストが生成された生成規則(((Ｃ1:ｉ)・・・(Ｃn:ｊ))ｆ(Ｃ0:k))は入力用パターンＰ=(ｊｏｉｎ((Ｃ1:$ｉｎｓｔ1)・・・(Ｃn:ｊ$ｉｎｓｔn)))である。出力用パターンＱ=(Ｃ0:ｋ$ｉｎｓｔl)となり、以下のように表現される。なお、Ｒは、関数ｆを持つシステムが提供するリアクターである。
【００４０】
ｆ∈Ｒ
(join((Ｃ1：ｉ$inst1)・・・(Ｃn：ｊ$instn)))⇒(Ｃ0：ｋ$instl)
連携パスについて以上の操作を行い、実行用パターンを生成する。
【００４１】
本実施形態１ではメソッドの呼び出しをフィールドリアクターモデルのパターン連携で行うことによりオブジェクトの関係をメッセージパターンの関係に変換する。ここで、フィールドリアクターモデルとは、構造表現された構造化メッセージパターンと当該構造化メッセージパターンに対する反応アクションとの関係づけの連鎖によりオブジェクト間の連携処理を実現するモデルである。実際のオブジェクト連携は、フィールドを介して構造化メッセージパターンとその反応アクションの関係づけによるオブジェクト間の連携として行われる。
【００４２】
リアクターは入力用パターンＰ、関数ｆ、出力用パターンＱを1組とした計算実行体(ＰｆＱ)を複数持つ。計算実行体(ＰｆＱ)は、応用の開発者によって予め定義される。各計算実行体は、互いに異なる入力用パターンＰを持つ。複数のリアクターは、それぞれ並列に自律的に動作し、１つのリアクターは、メッセージを受信した順序で処理する。リアクターは、自身の持つすべての計算実行体に対し、（１）パターンマッチ、（２）ユーザ関数呼び出し、（３）メッセージ生成を行う。パターンマッチでは、パターンＰを用いて、メッセージＭから置換θを取り出す。Ｐと共に定義されたユーザ関数ｆを取り出された置換θと共に呼び出し、関数出力として置換θ'を得る。関数出力より得た置換θ'をメッセージ生成用パターンＱの変数に代入することにより、メッセージＭ'を生成する。これらの処理を以下に表現する。パターンＰがマッチしない場合、（２）（３）の処理は実行しない。
【００４３】
（１）(θ,ｆ)=Mａｔｃｈ（Ｐ，Ｍ）
（２）θ'=ｆ(θ)
（３）Ｍ'=Ｑ・θ'
ここで、Ｍａｔｃｈはパターンマッチ関数であり、パターンＰとメッセージＭを引数とし、置換θおよび対応するユーザ関数ｆを出力する。ユーザ関数ｆは、置換を引数とし、置換を返す関数である。メッセージの生成は、出力用パターンＱの変数部に対し、置換θ'を代入することにより行う。
【００４４】
その模式的な構造は図５のようになる。フィールドリアクターモデルによれば、各リアクター２００は、関数および手続き２０６などの計算実行体であるアクション実行部２０５を内部に持つ抽象的計算主体であり、また、当該計算実行体とは独立したメッセージに対する入出力用パターンを反応テーブル２０４という形で持ち、計算実行体と連携を分離している。フィールド２０７は通信媒体であり、メッセージ送信部２０２を介して送信メッセージをフィールド２０７上の他のリアクターへ分配する。リアクター２００は、入力用の構造化メッセージパターンを用いてメッセージ受信部２０１を介してフィールド２０７からメッセージを取捨選択し、反応テーブル２０４に応じてアクション実行部２０５を起動し、出力用パターンを用いて生成したメッセージをフィールド２０７へ送出する。リアクター２００間の連携は、入出力用パターンの関係によって決定する。そのため、リアクター２００内に存在する計算実行体の連携も、計算実行体とは独立にメッセージパターンによって決定される。アプリケーションは、複数のリアクターとフィールド２０７によって構成される。連携動作は次の通りである。あるリアクターがメッセージをフィールド２０７へ送出する。各リアクターは、フィールド２０７からのそのメッセージを受け、自身が持つ複数の入力用パターンとパターンマッチを行い、メッセージを取捨選択する。選択されたメッセージは、入力用パターンに対応するアクション実行部２０５により処理され、その結果と出力用パターンを用いてメッセージを生成し、そのメッセージをフィールド２０７へ送出される。フィールドリアクターモデルでは、このような動作を繰り返す。
【００４５】
以上がフィールドリアクターモデルにおけるリアクターの基本構造である。
【００４６】
上記フィールドリアクターモデルを前提として実行フローとなるオブジェクト連携の構築にあたっては、連携パスを解析し、実行時コンテキストを生成し、実行時コンテキストを加味したパターンを作成する。
【００４７】
（１）実行時コンテキストの生成
（２）実行用パターンの生成
上記２つのステップにより実行フローとなるオブジェクト連携を構築する。
【００４８】
図６はオブジェクトの関係をメッセージパターンの関係に変換した様子を模式的に示した図である。なお、各メッセージパターンには固有に区別するＩＤ番号が割り振られている。例えば、３つあるメッセージパターンＴ５にはそれぞれ、Ｔ５：０、Ｔ５：１、Ｔ５：２というＩＤ番号が与えられている。
【００４９】
このように本発明のオブジェクト連携装置ではフィールドリアクターモデルを用いてメッセージパターン連携を通して実際のオブジェクト連携を行う。もっとも、オブジェクト連携はフィールドリアクターモデルによる連携に限定されることはない。
【００５０】
次に、本発明のオブジェクト連携処理は、上記第四の仕組みとして、構築した実際のオブジェクト連携処理１０４を実行するため、オブジェクトクラスの値を決めて連携の始点となるオブジェクトに与え、オブジェクトインスタンスレベルでのオブジェクト連携処理１０４を実行し、結果を得る。
【００５１】
上記のような仕組みにより、利用者の利用目的に応じたオブジェクト連携処理を構築して実行する。
【００５２】
以上、本実施形態１のオブジェクト連携装置は、ＩＤＬやＷＳＤＬなどの言語で定義された各オブジェクトのインタフェースの記述を解析してオブジェクト間の連携関係を変換ルールの集合として記述でき、当該変換ルールに従ってオブジェクト間の連携関係を調べ、始点となるオブジェクトクラスと終点となるオブジェクトクラスをつなぐオブジェクトクラス間の連携パスを検出し、それらオブジェクト間の連携関係の実行環境を自動構築することにより、与えられた値を基に連携処理を実行することができる。
【００５３】
（実施形態２）
次に、オブジェクト連携装置の具体的構成の一例と実際のアプリケーションの実例を挙げつつ説明する。
【００５４】
まず、本実施形態２のオブジェクト連携装置の概略構成を述べる。図７は、実施形態２にかかる本発明のオブジェクト連携装置の概略を示した図である。図７において、１０はオブジェクトインタフェース情報入力部、２０は変換ルール生成部、３０は変換ルールデータベース、４０は利用者インタフェース、５０は連携パス検出部、６０はオブジェクト連携関係構築部、７０はオブジェクト連携実行部、１００はオブジェクト群である。
【００５５】
オブジェクトインタフェース情報入力部１０は、ＩＤＬやＷＳＤＬなどインタフェースを定義する言語で記述された各オブジェクトのインタフェース情報を入力する部分である。入力にあたって利用者自身がＩＤＬやＷＳＤＬなどのインタフェース記述の詳細について熟知する必要はなく、ネットワーク上に存在する利用可能なオブジェクトに関するインタフェース情報を入力すれば良い。もちろん利用者からオブジェクトインタフェース情報に関しての詳細なデータの入力を受け付けることも可能である。
【００５６】
変換ルール生成部２０は、オブジェクトインタフェース情報入力部１０から入力されたＩＤＬやＷＳＤＬなどの言語で定義された各オブジェクトのインタフェース情報を解析し、オブジェクト間の連携関係の表現形式を言語による表現形式から変換ルールの集合とした表現形式に変換する部分である。
【００５７】
変換ルールデータベース３０は、変換ルール生成部２０において生成された変換ルールの集合を蓄積するデータベースである。
【００５８】
利用者インタフェース４０は、利用者インタフェースであり、利用者は利用者インタフェース４０を介してオブジェクト連携システムに対して必要なデータを入力する。利用者が構築したい処理内容に関するデータを入力する。この例では、オブジェクトクラス指定部４１と連携パス選択部４２と値指定部４３を備えている。オブジェクトクラス指定部４１は利用者が利用目的に応じてオブジェクト連携関係の始点となるオブジェクトクラスと終点となるオブジェクトクラスを指定する部分である。連携パス選択部４２は後述するように連携パス検出部５０において複数の連携パスの候補が得られた場合に、一つの連携パスを選択し、または一つの連携パスが選択できるようにオブジェクトインタフェース情報を追加する部分である。値指定部４３は後述するように、連携パスに沿ってオブジェクト連携構築部６０が構築したオブジェクト連携において実際にオブジェクト連携を実行するにあたり、始点となるオブジェクトクラスの値を指定・入力する部分である。
【００５９】
連携パス検出部５０は、利用者インタフェース４０から指定された始点となるオブジェクトクラスと終点となるオブジェクトクラスをつなぐ連携パスを検出する部分である。
【００６０】
ここで、オブジェクトインタフェース情報に曖昧性が存在する場合、オブジェクト連携ルールにも曖昧性が存在することとなり、連携パスが一意に定まらず複数の連携パスが検出される場合が想定できる。この場合、利用者に曖昧性が存在する部分と検出された複数の連携パスを利用者に提示し、連携パス選択部４２を介して利用者にそれら複数の連携パスから１つの連携パスを選択させるか、あるいは、指摘されたインタフェース記述の曖昧性がなくなるように利用者インタフェース４０を介してＩＤＬやＷＳＤＬの記述自体を修正させる。後者の場合はＩＤＬやＷＳＤＬなどの記述についての知識が必要となるが、前者の場合であればＩＤＬやＷＳＤＬの記述についての詳細な知識は必要とならない。
【００６１】
また、この例では、オブジェクト連携パス検出部５０は、オブジェクト連携実行用パターン生成部５１を備えている。オブジェクト連携実行用パターン生成部５１は、オブジェクト連携パス検出部５０において検出した一つながりの連携パスを構成する個々のサブ連携パスに分離し、各々のサブ連携パスに固有のＩＤ情報を割り振るなどして区別して連携パスの実行時コンテキストを生成し、前記連携パスをオブジェクトクラス間の連携パスから連携実行時に渡される値を変数としたオブジェクト連携実行用パターンの連携パスに変換する部分である。
【００６２】
なお、実際のオブジェクト連携実行時は、オブジェクトインスタンスを特定する必要があるが、オブジェクトインスタンスはシステム実行時に初めて決定されるため、オブジェクトインスタンスの値を予め規定することはできない。そこで連携実行時に渡される値を変数としたオブジェクト連携実行用パターンを生成しておけば良い。オブジェクト連携パス検出部５０は、オブジェクト連携実行用パターン生成部５１を用いて、連携パスをオブジェクトクラス間の連携パスから連携実行時に渡される値を変数としたオブジェクト連携実行用パターンの連携パスに変換する。
【００６３】
オブジェクト連携関係構築部６０は、連携パス検出部５０により検出された連携パスをもとに実際の実行フローとなるオブジェクト連携を構築する部分である。連携パスを形成するオブジェクト間を結ぶ変換ルールをメソッドに変換していくことで、オブジェクトのメソッド呼び出しの関係が構築されてオブジェクト間連携が構築される。本実施形態１のオブジェクト連携装置では、このメソッドの呼び出し関係をフィールドリアクターモデルを用いて構築することとし、構造化されたメッセージパターンと当該メッセージにより呼び出されるメソッドの関係として記述する。オブジェクト連携関係構築部６０は、連携元のオブジェクトに送信すべき構造化メッセージパターンを通知して実装させ、連携先のオブジェクトに受信により反応すべき前記構造化メッセージパターンおよび当該構造化メッセージパターンに対するアクションとを通知して実装させる。このように実際のオブジェクト間の連携は、フィールド上を流れるメッセージパターンとその反応となるアクションという関係でオブジェクト間の連携関係が構築されて行き、始点オブジェクトから終点オブジェクトに至るオブジェクト間連携が構築される。
【００６４】
オブジェクト連携実行部７０は、実際のオブジェクト連携の実行が行われるモジュールであり、値指定部４３を介して始点となるオブジェクトクラスの値がオブジェクト連携実行用パターンの変数部分に与えられ、オブジェクト群１００において実際のオブジェクト連携が実行される。
【００６５】
オブジェクト群１００は、ネットワーク上に存在するオブジェクト群であり、連携関係が構築される。本実施形態１ではオブジェクト連携関係はフィールドリアクターモデルにより構築されている。各オブジェクトは図５に示したフィールドリアクターモデルを実現する構成を含んでおり、ネットワーク上に送信される構造化メッセージをモニタして取り込むメッセージ受信部２０１と、構造化メッセージと構造化メッセージに対する反応であるアクションのセットを記憶する反応テーブル２０４と、各種関数やアプリケーション２０６を含み、アクションの内容に従って処理を実行するアクション実行部２０５と、アクションの一環として生成されたメッセージをフィールド上に送るメッセージ送信部２０２と、制御部２０３を備え、メッセージ・アクションの反応関係に従って駆動する。
【００６６】
次に、オブジェクト連携構築処理をアプリケーション例を挙げつつ、詳しく述べる。以下の例では、具体例としてＩＤＬで定義されているオブジェクトを利用した銀行の口座振り込み処理、ＷＳＤＬで定義されているオブジェクトを利用した旅行予約処理というを例を挙げつつ説明する。また、オブジェクト連携関係の構築はフィールドリアクターモデルで構築する例を説明する。
【００６７】
以下、大別して以下の４つの処理工程に分けて説明する。第一の処理工程は、入力されたＩＤＬやＷＳＤＬで記述された各オブジェクトのインタフェース情報を基にオブジェクト間の連携関係を簡潔に示すルールの集合を作成する処理工程である。第二の処理工程は、利用者から入力されたオブジェクト連携の始点となるオブジェクトクラスから終点となるオブジェクトクラスへ至るオブジェクト連携パスを検出する処理工程である。第三の処理工程は、検出したオブジェクト連携パスから実行フローを生成し、フィールドリアクターモデルの構造化メッセージ・反応アクション連携関係に基づいたオブジェクト連携関係を構築する処理工程である。第四の処理工程は、実際のオブジェクト連携実行処理であり、始点となるオブジェクトクラスの値を指定し、与えられた始点となるオブジェクトクラスの値を基に連携処理を実行する工程である。
【００６８】
第一の処理工程であるオブジェクト間の連携関係を簡潔に示すルールの集合を作成する処理工程の具体例を説明する。
【００６９】
この工程では、オブジェクトインタフェース記述入力部１０を介して各オブジェクトのＩＤＬで定義されたインタフェース記述情報を入力し、変換ルール生成部２０がこれら情報からＩＤＬによって定義されたオブジェクトクラスを変換ルールとして簡潔に表現する。オブジェクトクラスはメソッドおよびメンバー変数から構成される。ここで、オブジェクトクラスを記号と捉え、クラスの持つメソッドを引数のクラスから帰り値であるクラスへの連携ルールとみなす。例えば、クラスＣの持つメソッドｆは、はオブジェクトのリスト（Ｃ1，・・・，Ｃn）を引数とし、オブジェクトＣ0を返すとき、連携ルールを（Ｃ1・・・ＣnＣ）ＣfＣ0）と表現する。また、メンバー変数は仮想的なメソッドを適応し、得られた結果とする。例えば、クラスＣの型Ｔのメンバー変数ｗがあるとき、型Ｔを返す仮想メソッドＣｗとし、連携ルールとして表現する。また、ｉｎｔ，ｆｌｏａｔなどはＣＯＲＢＡが定義する基本型であり、これらの型を返す関数ｆφは、型ｎｉｌから基本型を返す関数と捉え、同様に連携ルールとして表現する。このようにＩＤＬで定義されるすべてのインタフェースを連携ルールとして表現し、変換ルールの集合を作成する。生成された変換ルールは変換ルールデータベース３０に格納される。図８は、銀行口座振り込み処理を実行するアプリケーション例において、オブジェクトインタフェース記述入力部１０を介して入力される各オブジェクトのＩＤＬで定義されたインタフェース記述情報の例である。図８に示したＩＤＬ記述によるインタフェース情報から変換ルール生成部２０が抽出した変換ルールは図９のようになる。図１０は、変換ルール生成部２０が図９の変換ルールの集合から生成したクラス間の関係を模式的に示した図である。
【００７０】
また、ＷＳＤＬで記述されたインタフェース情報に関しては以下のように考える。インターネットのウェブサービスを、入出力ポートを持つネットワークノードと考え、入力タイプと出力タイプを定義する。このように入出力タイプを定義することにより、ウェブサービスを、入力タイプのデータを出力タイプのデータに変換するルールと捉えることができる。図１１はＷＳＤＬで記述されたインタフェース情報の例を示す図であり、４つのウェブサービスのものが示されている。それぞれのタイプ定義も示されている。図１２は、変換ルール生成部２０が変換ルールの集合から生成したタイプ間の関係を模式的に示した図である。
【００７１】
次に、第二の処理工程であるオブジェクト連携パスを検出する処理工程の具体例を説明する。この処理工程では、利用者の利用目的に応じた処理を実現するオブジェクト間の連携パスを発見する。まず、利用者インタフェース４０のオブジェクト指定部４１を介して利用者の利用目的に応じ、オブジェクト連携の始点となるオブジェクトクラスの集合｛ＣＳ1，・・・，ＣＳn｝と終点オブジェクトのクラスＣgを指定する。連携パス検出部５０は、始点のオブジェクトクラスの集合および終点オブジェクトクラスの指定を受け、変換ルールデータベース３０のオブジェクト連携ルールを適用して始点のオブジェクトクラスの集合から終点オブジェクトクラスまで到達する変換ルールの適用順序を見つけ出す。適用順序の発見方法は、上述したように、指定された始点となるオブジェクトクラスから出発してオブジェクトの連携関係を順方向に拡大して終点となるオブジェクトクラスへ到達するパスを発見する方法や、指定された終点となるオブジェクトクラスから出発してオブジェクトの連携関係を逆方向に拡大して始点となるオブジェクトクラスへ到達するパスを発見する方法やその折衷方法などがある。
【００７２】
連携パス検出部５０が実行する連携パス検索処理を関数という形で記述する場合のアルゴリズムの一例を図１３に示す。関数ＦｉｎｄＰａｔｈは、始点オブジェクトクラスのリストＬS＝｛ＣＳ1，・・・，ＣＳn｝と終点オブジェクトのクラスＣｇを引数とし、連携パス集合を返す。もし連携パスが存在しないとき、ｎｉｌを返す。なお、ルールの集合Ｓ＝｛（Ｐ1ｆ1Ｑ1），・・・，（ＰnｆnＱn）｝、Ｐk＝（ｐ1・・・ｐn）である。ループによる無限展開の発生を抑えるため、ヒストリリストＨを用意する。ヒストリリストＨは既に検索した型の集合である。初期値はＨ：＝｛｝である。また、関数ＳｅａｒｃｈＲｕｌｅｓは、引数として型Ｃｇおよびルール集合Ｓをとる。この関数は、ルール集合ＳからＣｇを出力用パターンとする要素を取り出し、集合Ｓ＝｛（ＰkｆkＱk）∈Ｓ｜Ｑk＝Ｃg｝を返す。
【００７３】
図１４は、銀行口座振り込み処理を実行するアプリケーション例において、発見した変換ルールの適用順序を模式的に示す図である。図１４の例では始点となるオブジェクトクラスはＡｃｃｏｕｎｔＭａｎａｇｅｒ，ＡｃｃｏｕｎｔＩＤ，ｐａｙｍｅｎｔの３つであり終点となるオブジェクトクラスはｐａｙＲｅｓである。この例では一意に連携パスが定まったが、複数発見された場合、連携パス検出部５０は利用者インタフェース４０を介して複数の連携パスの候補があることを知らせ、連携パス指定部４２を介して利用者に連携パスを選択させる。
【００７４】
図１５は、出張予約処理を実行するアプリケーション例において、発見した変換ルールの適用順序を模式的に示す図である。図１５の例では始点となるタイプは、出発・到着場所（ｌｏｃａｔｉｏｎ），出発・帰省日（Ｄａｔｅ），出発時間（Ｔｉｍｅ）の３つであり終点となるタイプは出張前処理（ＣｏｏｒｄｉｎａｔｅＤｏｎｅ）である。この例では一意に連携パスが定まったが、複数発見された場合、連携パス検出部５０は利用者インタフェース４０を介して複数の連携パスの候補があることを知らせ、連携パス指定部４２を介して利用者に連携パスを選択させる。
【００７５】
次に、第三の処理工程であるオブジェクト連携関係を構築する処理工程の具体例を説明する。この処理工程は、第二の処理工程で検出したオブジェクト連携パスに基づいて実行フローを生成し、フィールドリアクターモデルによる構造化メッセージ・反応アクション連携関係を構築する処理工程である。本実施形態２ではＣＯＲＢＡを用いた場合の実行用パターンの生成について説明する。
【００７６】
図１６は、ＣＯＲＢＡを用いる場合の実行用パターンの生成処理の実行環境を示す図である。ＣＯＲＢＡオブジェクトプール３２０は、連携パス実行中にシステムが生成したＣＯＲＢＡオブジェクト３５０を管理し、オブジェクトに対する操作インタフェースを持つ。また、インスタンスＩＤを管理し、実体であるオブジェクトインスタンスヘのマッピングを行う。ＣＯＲＢＡオブジェクトファクトリ３３０は、ＣＯＲＢＡオブジェクト３５０をＣＯＲＢＡネーミングサービスを通して取得し、ＣＯＲＢＡオブジェクトファクトリ３３０が生成したオブジェクトをＣＯＲＢＡオブジェクトプール３２０ヘ渡す。オブジェクトファクトリ３３０は、リアクターであり、フィールドに対してネーミングサービスを提供する。ＣＯＲＢＡオブジェクトファクトリ３３０は、指定の名のオブジェクトを検索し、インスタンスＩＤを返す。パターンフォルダ３１０も同様にリアクターであり、連携パスを元に実行フローを生成・保持し、実行用パターンに応じて、ＣＯＲＢＡオブジェクト３５０をＣＯＲＢＡオブジェクトプール３２０を通して操作する。ユーザリアクター２００は、ＣＯＲＢＡオブジェクト３５０を操作する上で、ＩＤＬを意識する必要はなく、フィールド上のパターン連携によってＣＯＲＢＡオブジェクト３５０を取り扱うことができる。
【００７７】
フィールド２０７では、ＣＯＲＢＡオブジェクト３５０は全てインスタンスＩＤとして取り扱われ、パターンフォルダ３１０によってオブジェクトの実体に対して操作される。パターンフォルダ３１０は、メッセージに従いＣＯＲＢＡオブジェクト３５０を操作する。パターンフォルダ３１０は、オブジェクトの汎用的なメソッド起動関数Ｒ=Invoke(Ｏ,ｍ,Ｐ)を持つ。この関数は・オブジェクトのインスタンスＩＤ“Ｏ”、呼び出すメソッド名“ｍ”およびメソッド起動に必要なパラメータ列“Ｐ=(ｐ1,・・・,ｐn)”を引数とする。ＣＯＲＢＡオブジェクトプール３２０を通して、メソッドを起動した後、結果Ｒを返す。パラメータ列もインスタンスＩＤで表現する。実行用パターンは、各パターンに対応する起動関数と共にセットされる。パターンと共に設定された起動関数は、パターンマッチによって得られた置換を使用し、関数Invokeを呼び出す。Invokeの帰り値を置換に変換し、出力用パターンにその置換を適用しメッセージを生成する。
【００７８】
次に、第四の処理工程である実際のオブジェクト連携実行処理を説明する。
【００７９】
実際のオブジェクト連携の実行にあたり、値指定部４３を介して始点となるオブジェクトクラスの値を指定し、与えられた始点となるオブジェクトクラスの値を基に連携処理を実行する。起動はリアクターからスタートメッセージをフィールドへ流すことで行われる。スタートメッセージにより、パターンフォルダは実行フローに沿って、ＣＯＲＢＡオブジェクトの連携を開始し、連携パスを実行していく。実行は、フィールドを通して行われ、パターンフォルダを通してＣＯＲＢＡオブジェクトの実体が連携し、目的のオブジェクトが生成されるまで繰り返される。パターンの終点である目的のオブジェクトが生成された時点で終了する。
【００８０】
銀行口座振り込み処理を実行するアプリケーション例では、図１７に示すように、値として“振込元の銀行名”、“振込元の口座番号”、“振込先の銀行名”、“振込先の口座番号”、“振込金額”が与えられ、オブジェクト間の連携が実行され、銀行口座振り込み処理が実行される。
【００８１】
出張の予約処理を実行するアプリケーション例では、図１８に示すように、値として“出発場所（ｌｏｃａｔｉｏｎ）”、“到着場所（ｌｏｃａｔｉｏｎ）”、“出発日（Ｄａｔｅ）”、“帰省日（Ｄａｔｅ）”、“出発時間（Ｔｉｍｅ）”が与えられ、それぞれのオブジェクトに対応する値が与えられ、出張予約処理が実行される。
【００８２】
なお、図１８に示すように、同一データの使い回しやプロファイルデータを利用した自動データ入力も可能である。
【００８３】
以上、本発明の実施形態２のオブジェクト連携装置によれば、各オブジェクトのインタフェースの記述を解析してオブジェクトの連携関係をルールの集合として簡潔に表現でき、当該ルールによりオブジェクト間の連携関係を調べることにより、利用者の利用目的に応じ、始点となるオブジェクトから終点となるオブジェクトまでのオブジェクト間の連携パスを自動的に検出でき、また、それらオブジェクト群の連携処理を柔軟に構築することができる。
【００８４】
（実施形態３）
実施形態３のオブジェクト連携システムは、オブジェクト連携パス検出部が連携パス検出の学習機能を備え、前記オブジェクトクラス指定部から与えられた始点となるオブジェクトクラスと終点となるオブジェクトクラスをつなぐオブジェクトクラス間の連携パスの検出結果を知識として蓄積し、連携パス検出処理に用いる機能を備えたものである。
【００８５】
図１９は、実施形態３のオブジェクト連携システムの構成概略図である。オブジェクトインタフェース情報入力部１０、変換ルール生成部２０、変換ルールデータベース３０、利用者インタフェース４０、オブジェクト連携関係構築部６０、オブジェクト連携実行部７０、オブジェクト群１００は実施形態２で示した図７と同様であるが、連携パス検出部５０ａはオブジェクト連携実行用パターン生成部５１に加え、学習部５２、連携パス知識部５３を備えている。学習部５２および連携パス知識部５３は連携パス検出処理の学習機能を有し、連携パス検出部５０ａによる連携パス検出処理結果が得られると、学習部５２は、オブジェクトクラス指定部４１から与えられた始点となるオブジェクトクラスと終点となるオブジェクトクラスの入力に対し、検出された連携パスを結果として対応づけて学習し、その知識を連携パス知識部５３に格納する。連携パス検出部５０ａは次回以降の連携パス検出処理にあたり、連携パス知識部５３に格納された連携パス知識を活用して連携パスの検出処理を実行する。次回以降の連携パス検出処理において与えられた始点となるオブジェクトクラスと終点となるオブジェクトクラスが連携パス知識部５３に格納された連携パス知識のものと同様であれば、当該知識を活用して連携パスの検出処理が実行できる。
【００８６】
なお、ネットワーク上のオブジェクトの追加、削除、保守などによるサービス停止など、ネットワークの状態は動的に変化することもあるので、連携パス知識部５２に格納された連携パス知識を固定的なデータとして参照することはできない点に注意を要する。
【００８７】
以上、実施形態３のオブジェクト連携システムによれば、オブジェクト連携パス検出部が連携パス検出の学習機能を備え、オブジェクトクラス指定部から与えられた始点となるオブジェクトクラスと終点となるオブジェクトクラスをつなぐオブジェクトクラス間の連携パスの検出結果を知識として蓄積し、連携パス検出処理に用いることができる。
【００８８】
（実施形態４）
本発明のオブジェクト連携装置は、上記に説明した構成を実現する処理ステップを記述したプログラムをコンピュータ読み取り可能な記録媒体に記録して提供することにより、各種コンピュータを用いて構築することができる。本発明のオブジェクト連携装置を実現する処理ステップを備えたプログラムを記録した記録媒体は、図２０に図示した記録媒体の例に示すように、ＣＤ−ＲＯＭ１００２やフレキシブルディスク１００３等の可搬型記録媒体１００１だけでなく、ネットワーク上にある記録装置内の記録媒体１０００や、コンピュータのハードディスクやＲＡＭ等の記録媒体１００５のいずれであっても良く、プログラム実行時には、プログラムはコンピュータ１００４上にローディングされ、主メモリ上で実行される。
【００８９】
本発明のオブジェクト連携装置に関し、さらに以下の項を開示する。
【００９０】
（付記１）ネットワーク上のオブジェクトのインタフェース情報を入力して解析し、オブジェクト間の連携関係を変換ルールの集合として記述するルール記述部と、
オブジェクト連携関係の始点となるオブジェクトクラスと終点となるオブジェクトクラスを指定するオブジェクトクラス指定部と、
前記変換ルールに従ってオブジェクト間の連携関係を調べ、前記始点となるオブジェクトクラスと前記終点となるオブジェクトクラスをつなぐオブジェクトクラス間の連携パスを検出するオブジェクト連携パス検出部と、
前記検出された連携パスに応じてオブジェクト間の連携関係の実行環境を構築するオブジェクト連携構築部と、
前記始点となるオブジェクトクラスの値を指定する値指定部と、
前記与えられた始点となるオブジェクトクラスの値を基に連携処理を実行するオブジェクト群とを備えたことを特徴とするオブジェクト連携装置（１）。
【００９１】
（付記２）前記オブジェクト連携構築部は、前記オブジェクト群の連携においてオブジェクト間に構造化メッセージと当該構造化メッセージに対する反応であるアクションとの関係づけによる連携関係を構築するものであり、連携元のオブジェクトに送信すべき構造化メッセージパターンを通知して実装させ、連携先のオブジェクトに受信により反応すべき前記構造化メッセージパターンおよび当該構造化メッセージパターンに対するアクションとを通知して実装させる付記１に記載のオブジェクト連携装置（２）。
【００９２】
（付記３）前記オブジェクト群の各オブジェクトが、ネットワーク上に送信される構造化メッセージをモニタして取り込むメッセージ受信部と、構造化メッセージと構造化メッセージに対する反応であるアクションのセットを記憶する反応テーブルと、前記アクションの内容に従って処理を実行するアクション実行部を備え、前記メッセージ・アクションの反応関係に従って駆動する付記１または付記２に記載のオブジェクト連携装置（３）。
【００９３】
（付記４）前記オブジェクト連携パス検出部が、連携パスが複数検出された場合に一つの連携パスを利用者に選択させる連携パス選択部を備えた付記１から３のいずれかに記載のオブジェクト連携装置。
【００９４】
（付記５）前記オブジェクト連携パス検出部が、検出した一つながりの連携パスを構成する個々のサブ連携パスに分離し、各々のサブ連携パスを区別して連携パスの実行時コンテキストを生成し、前記連携パスをオブジェクトクラス間の連携パスから連携実行時に渡される値を変数としたオブジェクト連携実行用パターンの連携パスに変換するオブジェクト連携実行用パターン生成部を備えた付記１から３のいずれかに記載のオブジェクト連携装置（４）。
【００９５】
（付記６）前記連携パスにおいて、複数のオブジェクト連携元とオブジェクト連携関係を持つオブジェクト連携先がある場合、前記オブジェクト連携先は前記複数のオブジェクト連携元の各々から個別に構造化メッセージを受信し、前記反応テーブルのアクションが発火するために必要なすべての引数が揃ったことを契機としてアクションを発火させる構造化メッセージパターン・反応アクションの関係づけを持つ付記１から３のいずれかに記載のオブジェクト連携装置。
【００９６】
（付記７）前記連携パスにおいて、複数のオブジェクト連携先とオブジェクト連携関係を持つオブジェクト連携元がある場合、前記オブジェクト連携元はフィールドに構造化メッセージを送信し、前記複数のオブジェクト連携先の各々は前記構造化メッセージが受信されたことを契機として反応アクションを発火させる構造化メッセージパターン・反応アクションの関係づけを持つ付記１から３のいずれかに記載のオブジェクト連携装置。
【００９７】
（付記８）前記オブジェクト連携パス検出部が連携パス検出の学習機能を備え、前記オブジェクトクラス指定部から与えられた始点となるオブジェクトクラスと終点となるオブジェクトクラスをつなぐオブジェクトクラス間の連携パスの検出結果を知識として蓄積し、連携パス検出処理に用いる付記１から３のいずれかに記載のオブジェクト連携装置。
【００９８】
（付記９）前記オブジェクトのインタフェース情報がＩＤＬまたはＷＳＤＬのいずれかで記述された情報である付記１から３のいずれかに記載のオブジェクト連携装置。
【００９９】
（付記１０）オブジェクト間にオブジェクト連携関係を構築するオブジェクト連携装置を実現する処理プログラムを記録したコンピュータ装置読み取り可能な記録媒体であって、
ネットワーク上のオブジェクトのインタフェース情報を入力して解析し、オブジェクト間の連携関係を変換ルールの集合として記述するルール記述処理ステップと、
オブジェクト連携関係の始点となるオブジェクトクラスと終点となるオブジェクトクラスを指定するオブジェクトクラス指定処理ステップと、
前記変換ルールに従ってオブジェクト間の連携関係を調べ、前記始点となるオブジェクトクラスと前記終点となるオブジェクトクラスをつなぐオブジェクトクラス間の連携パスを検出するオブジェクト連携パス検出処理ステップと、
前記検出された連携パスに応じてオブジェクト間の連携関係の実行環境を構築するオブジェクト連携構築処理ステップと、
前記始点となるオブジェクトクラスの値を指定する値指定処理ステップと、
前記与えられた始点となるオブジェクトクラスの値を基に連携処理を実行するオブジェクトを生成する処理ステップとを備えた処理プログラムを記録したことを特徴とする記録媒体（５）。
【０１００】
【発明の効果】
本発明のオブジェクト連携装置によれば、各オブジェクトのインタフェースの記述を解析してオブジェクトの連携関係をルールの集合として簡潔に表現でき、当該ルールによりオブジェクト間の連携関係を調べることにより、利用者の利用目的に応じ、始点となるオブジェクトから終点となるオブジェクトまでのオブジェクト間の連携パスを自動的に検出でき、また、それらオブジェクト群の連携処理を柔軟に構築することができる。
【０１０１】
本発明のオブジェクト連携装置によれば、入力されたインタフェース記述に曖昧性がある場合でも、連携パスを一意に定め、オブジェクト間の実行フローを形成することができる。
【０１０２】
本発明のオブジェクト連携装置によれば、複数のオブジェクト連携元の処理を、いわゆるＡＮＤ演算の形で受け、所定複数のオブジェクト元との連携成立を契機としてオブジェクト連携先が反応するように連携関係を制御することができる。また、複数のオブジェクト連携元の処理を、いわゆるＯＲ演算の形で受け、一又は所定組み合わせのオブジェクト元との連携成立を契機としてオブジェクト連携先が反応するように連携関係を制御することもできる。
【０１０３】
さらに、連携パス検出の学習機能を備えることができ、オブジェクトクラス指定部から与えられた始点となるオブジェクトクラスと終点となるオブジェクトクラスをつなぐオブジェクトクラス間の連携パスの検出結果を知識として蓄積し、連携パス検出処理に用いることができ、処理効率向上を図ることができる。
【図面の簡単な説明】
【図１】 本発明の実施形態１にかかるオブジェクト連携構築処理の概要を模式的に示した図
【図２】 （ａ）はＩＤＬ記述によるインタフェース情報の例、（ｂ）は（ａ）のインタフェース情報から生成した変換ルールの例を示す図
【図３】 本発明の実施形態１にかかる変換ルールの集合から各オブジェクトと変換ルールとの関係を模式的に示した図
【図４】 本発明の実施形態１にかかる連携パスの検出例を模式的に示した図
【図５】 本発明の実施形態１にかかるフィールドリアクターモデルにおけるリアクターの模式的な構造を示した図
【図６】 本発明の実施形態１にかかるオブジェクトの関係をメッセージパターンの関係に変換した様子を模式的に示した図
【図７】 本発明の実施形態２にかかるオブジェクト連携装置の概略を示した図
【図８】 本発明の実施形態２にかかる銀行口座振り込み処理を実行するアプリケーション例における各オブジェクトのＩＤＬで定義されたインタフェース記述情報の例を示した図
【図９】 本発明の実施形態２にかかる図８に示したＩＤＬ記述によるインタフェース情報から変換ルール生成部２０が抽出した変換ルールを示す図
【図１０】 本発明の実施形態２にかかる図９の変換ルールの集合からルール生成部２０が生成したクラス間の関係を模式的に示した図
【図１１】 本発明の実施形態２にかかるＷＳＤＬで記述されたインタフェース情報の例を示す図
【図１２】 本発明の実施形態２にかかる図１１に示したＷＳＤＬ記述によるインタフェース情報から生成した変換ルールの集合におけるタイプ間の関係を模式的に示した図
【図１３】 本発明の実施形態２にかかる連携パス検出部５０が実行する連携パス検索処理を関数という形で記述する場合のアルゴリズムの一例を示す図
【図１４】 本発明の実施形態２にかかる銀行口座振り込み処理を実行するアプリケーション例において、発見した変換ルールの適用順序を模式的に示す図
【図１５】 本発明の実施形態２にかかる出張予約処理を実行するアプリケーション例において、発見した変換ルールの適用順序を模式的に示す図
【図１６】 本発明の実施形態２にかかるＣＯＲＢＡを用いる場合の実行用パターンの生成処理の実行環境を示す図
【図１７】 本発明の実施形態２にかかる銀行口座振り込み処理を実行するアプリケーション例におけるオブジェクト連携実行を示す図
【図１８】 本発明の実施形態２にかかる出張の予約処理を実行するアプリケーション例におけるオブジェクト連携実行を示す図
【図１９】 本発明の実施形態３にかかるオブジェクト連携装置の概略を示した図
【図２０】 本発明の実施形態４のオブジェクト連携装置を実現する処理プログラムを記録した記録媒体の例を示す図
【図２１】 従来技術のＣＯＲＢＡに基づいたクライアント／サーバシステムにおけるオブジェクト連携の例を示す図
【符号の説明】
１０ オブジェクトインタフェース情報入力部
２０ 変換ルール生成部
３０ 変換ルールデータベース
４０ 利用者インタフェース
４１ オブジェクトクラス指定部
４２ 連携パス選択部
４３ 値指定部
５０，５０ａ 連携パス検出部
５１ オブジェクト連携実行用パターン生成部
５２ 学習部
５３ 連携パス知識部
６０ オブジェクト連携関係構築部
７０ オブジェクト連携実行部
１００ オブジェクト群
１０１ 変換ルール集合
１０２ 連携パスの検出処理
１０３ オブジェクト連携の構築処理
１０４ オブジェクト連携処理
２００ リアクター
２０１ メッセージ受信部
２０２ メッセージ送信部
２０３ 制御部
２０４ 反応テーブル
２０５ アクション実行部
２０６ アクション実行部２０５が管理する各種関数、アプリケーション
２０７ フィールド
３１０ パターンフォルダ
３２０ ＣＯＲＢＡオブジェクトプール
３２１ スタブ
３３０ ＣＯＲＢＡオブジェクトファクトリ
３４０ オブジェクトリクエストブローカ
３５０ ＣＯＲＢＡオブジェクト
３６０ ＣＯＲＢＡホームサービス
１０００ 回線先のハードディスク等の記録媒体
１００１ ＣＤ−ＲＯＭやフレキシブルディスク等の可搬型記録媒体
１００２ ＣＤ−ＲＯＭ
１００３ フレキシブルディスク
１００４ コンピュータ
１００５ コンピュータ上のＲＡＭ／ハードディスク等の記録媒体
Claims (5)
- 各オブジェクトの各メソッドの入力オブジェクトクラスと出力オブジェクトクラスと間の変換関係を示す変換ルールが格納される変換ルール記録部と、
利用可能なオブジェクト各々における各メソッドの入オブジェクトクラスおよび出力オブジェクトクラスを示す情報を含むインタフェース情報を解析することにより、前記各メソッドについて変換ルールを生成し、前記変換ルール記録部へ格納する変換ルール生成部と、
オブジェクト連携関係の始点となるオブジェクトのオブジェクトクラスと終点となるオブジェクトのオブジェクトクラスの指定を利用者から受け付けるオブジェクトクラス指定部と、
前記始点となるオブジェクトクラスから前記変換ルールを順に適用してオブジェクトクラスを変換し、前記終点となるオブジェクトクラスへ変換されるまでの前記変換ルールの適用順序を、変換ルール記録部に格納された前記変換ルールを用いて計算することにより、前記始点となるオブジェクトクラスと前記終点となるオブジェクトクラスを前記変換ルールによりつなぐオブジェクトクラス間の連携パスを検出するオブジェクト連携パス検出部と、
前記連携パスにおける前記オブジェクトクラス間をつなぐ各変換ルールをメソッドに変換することにより、前記始点となるオブジェクトクラスのオブジェクトが生成されてから前記終点となるオブジェクトクラスのオブジェクトが生成されるまでに生成される各オブジェクトの関係を示すデータである実行フローを生成するオブジェクト連携関係構築部と、
前記始点となるオブジェクトクラスに対応するオブジェクトの値の指定を利用者から受け付ける値指定部と、
前記始点となるオブジェクトクラスのオブジェクトの値を用いて、前記始点となるオブジェクトクラスのオブジェクトを生成し、前記実行フローに沿ってオブジェクトの生成およびメソッドの呼び出しを実行することによりオブジェクトを連携させて前記終点となるオブジェクトクラスのオブジェクトを生成するオブジェクト連携実行部とを備えたことを特徴とするオブジェクト連携装置。 - 前記オブジェクト連携構築部は、前記連携パスにおける前記オブジェクトクラス間をつなぐ各変換ルールについて、入力オブジェクトクラスに対応するメッセージと、当該メッセージにより呼び出されるアクションであって、出力オブジェクトクラスに対応するメッセージを出力するアクションとを関連付けるメッセージ・アクション反応関係データに変換することにより、前記実行フローを生成する、請求項１に記載のオブジェクト連携装置。
- オブジェクト連携実行部は、ネットワーク上に送信されるメッセージをモニタして取り込むメッセージ受信部と、当該メッセージ受信部が受信したメッセージと当該メッセージに対する反応であるアクションのセットを記憶する反応テーブルと、前記アクションの内容に従って処理を実行するアクション実行部を含み、
前記反応テーブルには、前記メッセージ・アクション反応関係データが記憶されることを特徴とする、請求項２に記載のオブジェクト連携装置。 - オブジェクト連携パス検出部は、オブジェクトクラス間の変換ルールでつながれた連携パスにおける各変換ルールにＩＤ情報を割り振ることにより、各々の変換ルールを区別して連携パスの実行時コンテキストを生成し、前記連携パスをオブジェクトクラス間の連携パスから連携実行時に渡される値を変数としたオブジェクト連携実行用パターンの連携パスに変換するオブジェクト連携実行用パターン生成部を備えた請求項１から３のいずれかに記載のオブジェクト連携装置。
- オブジェクト間にオブジェクト連携関係を構築し、各オブジェクトの各メソッドの入力オブジェクトクラスと出力オブジェクトクラスと間の変換関係を示す変換ルールが格納される変換ルール記録部、変換ルール生成部、オブジェクトクラス指定部、オブジェクト連携パス検出部、オブジェクト連携関係構築部、値指定部、オブジェクト連携実行部とを備えたオブジェクト連携装置を実現する処理プログラムを記録したコンピュータ装置読み取り可能な記録媒体であって、
前記変換ルール生成部が、利用可能なオブジェクト各々における各メソッドの入オブジェクトクラスおよび出力オブジェクトクラスを示す情報を含むインタフェース情報を解析することにより、前記各メソッドについて変換ルールを生成し、前記変換ルール記録部へ格納する変換ルール生成ステップと、
前記オブジェクトクラス指定部が、オブジェクト連携関係の始点となるオブジェクトのオブジェクトクラスと終点となるオブジェクトのオブジェクトクラスの指定を利用者から受け付けるオブジェクトクラス指定ステップと、
前記オブジェクト連携パス検出部が、前記始点となるオブジェクトクラスから前記変換ルールを順に適用してオブジェクトクラスを変換し、前記終点となるオブジェクトクラスへ変換されるまでの前記変換ルールの適用順序を、前記変換ルール記録部に格納された変換ルールを用いて計算することにより、前記始点となるオブジェクトクラスと前記終点となるオブジェクトクラスを前記変換ルールによりつなぐオブジェクトクラス間の連携パスを検出するオブジェクト連携パス検出ステップと、
前記オブジェクト連携関係構築部が、前記連携パスにおける前記オブジェクトクラス間をつなぐ各変換ルールをメソッドに変換することにより、前記始点となるオブジェクトクラスのオブジェクトが生成されてから前記終点となるオブジェクトクラスのオブジェクトが生成されるまでに生成される各オブジェクトの関係を示すデータである実行フローを生成するオブジェクト連携関係構築ステップと、
前記値指定部が、前記始点となるオブジェクトクラスに対応するオブジェクトの値の指定を利用者から受け付ける値指定ステップと、
前記オブジェクト連携実行が、前記始点となるオブジェクトクラスの値を用いて、前記始点となるオブジェクトクラスのオブジェクトを生成し、前記実行フローに沿ってオブジェクトの生成およびメソッドの呼び出しを実行することによりオブジェクトを連携させて前記終点となるオブジェクトクラスのオブジェクトを生成するオブジェクト連携実行ステップとをコンピュータに実行させる処理プログラムを記録したコンピュータ装置読み取り可能な記録媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000339165A JP4145477B2 (ja) | 2000-11-07 | 2000-11-07 | オブジェクト連携装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000339165A JP4145477B2 (ja) | 2000-11-07 | 2000-11-07 | オブジェクト連携装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002149405A JP2002149405A (ja) | 2002-05-24 |
| JP4145477B2 true JP4145477B2 (ja) | 2008-09-03 |
Family
ID=18814272
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000339165A Expired - Fee Related JP4145477B2 (ja) | 2000-11-07 | 2000-11-07 | オブジェクト連携装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4145477B2 (ja) |
Families Citing this family (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1685680B1 (en) | 2003-11-20 | 2012-01-04 | Panasonic Corporation | Association control apparatus, association control method and service association system |
| US7624141B2 (en) * | 2004-01-23 | 2009-11-24 | Microsoft Corporation | Deterministic rule-based dispatch of objects to code |
| KR101190597B1 (ko) * | 2008-12-19 | 2012-10-15 | 한국전자통신연구원 | 로봇 소프트웨어 컴포넌트를 위한 메소드 포트 장치 및 구성 방법 |
| JP5084760B2 (ja) * | 2009-02-20 | 2012-11-28 | 日本電信電話株式会社 | シナリオ開発支援装置、およびシナリオ開発支援方法 |
| CN102334101B (zh) * | 2009-03-31 | 2014-10-08 | 三菱电机株式会社 | 执行顺序决定装置 |
| JP5631270B2 (ja) * | 2011-07-01 | 2014-11-26 | 三菱電機株式会社 | 支援装置及び支援システム及びコンピュータプログラム及び支援方法 |
| CN107506355B (zh) * | 2016-06-14 | 2020-09-29 | 阿里巴巴集团控股有限公司 | 对象分组方法及装置 |
| ES2765415T3 (es) * | 2016-10-21 | 2020-06-09 | Fujitsu Ltd | Aparato, método y programa de procesamiento de datos basado en microservicios |
-
2000
- 2000-11-07 JP JP2000339165A patent/JP4145477B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2002149405A (ja) | 2002-05-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Sauro et al. | Next generation simulation tools: the Systems Biology Workbench and BioSPICE integration | |
| Geist | PVM: Parallel virtual machine: a users' guide and tutorial for networked parallel computing | |
| US7313552B2 (en) | Boolean network rule engine | |
| Li et al. | A petri net approach to analyzing behavioral compatibility and similarity of web services | |
| JP5894724B2 (ja) | グラフ型計算の分散サービス | |
| Bennaceur et al. | Automated synthesis of mediators to support component interoperability | |
| JPH11119986A (ja) | 通信連携情報生成装置、３階層クライアント／サーバシステムおよび通信連携情報生成プログラムを記録した媒体 | |
| WO2004072851A1 (en) | System and method for managing distributed computer processes | |
| JP4145477B2 (ja) | オブジェクト連携装置 | |
| Taher et al. | Adaptation of web service interactions using complex event processing patterns | |
| Eden | A theory of object-oriented design | |
| JP4125005B2 (ja) | メッセージの型を利用するオブジェクト連携装置 | |
| Pahl et al. | A semantical framework for the orchestration and choreography of web services | |
| WO2000020966A1 (fr) | Dispositif de cooperation objets | |
| Anke et al. | A service-oriented middleware for integration and management of heterogeneous smart items environments | |
| Yu et al. | Object-oriented Petri nets based architecture description language for multi-agent systems | |
| Walton et al. | An agent-based e-science experiment builder | |
| Mokarizadeh et al. | Applying semantic web service composition for action planning in multi-robot systems | |
| Kamal et al. | Modeling architectural patterns’ behavior using architectural primitives | |
| Feijs | Modelling Microsoft COM using π-calculus | |
| Davis et al. | Toward formalizing service integration glue code | |
| Liu | A distributed data flow model for composing software services | |
| Li | Towards a resilient service oriented computing based on ad-hoc web service compositions in dynamic environments | |
| Cui et al. | Detect and analyse the concurrent flaws of the BPEL process in a VPN-based approach | |
| Guidi et al. | Formalizing Mobility in Service Oriented Computing. |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050308 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080325 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080526 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080617 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080618 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110627 Year of fee payment: 3 |
|
| LAPS | Cancellation because of no payment of annual fees |