以下、本発明のオブジェクト連携装置の実施形態について、図面を参照しながら説明する。
本発明は、分散したオブジェクト間の通信や対話、協調などの連携処理をオブジェクト間で行うオブジェクト連携装置であり、共通のフィールドとして定義されるような通信路を流れるメッセージに対して、オブジェクトとしての個々のコンピュータシステムあるいはコンピュータシステム内で動作する個々のアプリケーションプログラムが反応する形で処理を実行し、メッセージとアクションとの反応関係の変更によりシステム全体の動作を柔軟に変更するものである。
本発明は、連携するオブジェクト同士の関係を、互いの内部状態や内部関数に依存しあうような密な関係とはしないで、連携するオブジェクトの緩やかな関係を規定したオブジェクト間の連携によって機能を動的に構成する。
本発明の理解には、人間同士のコミュニケーションや相互に連携した行動において見られるAwarenessモデルが役に立つ。本発明は、分散オブジェクト間の連携において、オブジェクト間に、人間同士に介在するAwarenessと同様の情報処理を行い、検知したAwarenessに基づくオブジェクト同士の連携処理が前提となる。以下、まず、最初に本発明のオブジェクト連携装置の前提となるAwarenessアナロジーに基づく分散オブジェクトの連携について説明し、次に、分散オブジェクトの連携をより柔軟にする方式の説明を具体的な実施形態と併せて述べる。
Awarenessアナロジーに基づく分散オブジェクトの連携について説明する。Awarenessアナロジーに基づく分散オブジェクトの連携もしくはコンピュータの連携は、以下のような構成によって実現することができる。
1.Awarenessメッセージは、共有もしくはBroadcastされている。
2.Awarenessメッセージを受信するオブジェクトは、メッセージとアクションとの対応関係をそれぞれ独自に持っている。
3.Awarenessメッセージを送信もしくは受信するオブジェクトにおいて、メッセージとアクションとの関係は分離されている。
Awarenessアナロジーにおけるメッセージとアクションとが分離されている、あるいは分離可能であるという性質を利用することによって、オブジェクト間の相互作用として参加と介入という二つの重要な要素を付け加えることができ、ネットワークに接続されたオブジェクトとオブジェクトの連携あるいはコンピュータとコンピュータの連携の自由度を高めることが可能となる。
図1は、Awarenessアナロジーにおけるオブジェクト間の緩やかな連携を模式的に示した図である。
図1において201はオブジェクトA,202はオブジェクトBであり、それぞれAwarenessメッセージを送受信する主体であるオブジェクトである。M1はメッセージであり、Awarenessメッセージを示す。a1はオブジェクトA(201)中に規定されたアクション、a2はオブジェクトB(202)中に規定されたアクションを示す。なお、図中の矢印は、起点がオブジェクトのときメッセージの送出を、終点がオブジェクトのときメッセージの受信を示している。またそれぞれのオブジェクトは内部状態としてのアクションをそれぞれ独自に持っているとする。
図1において、オブジェクトA(201)とオブジェクトB(202)の連携は、メッセージM1を介して行われている。AwarenessアナロジーにおいてオブジェクトA(201)は、オブジェクトB(202)についてもオブジェクトB(202)の持つ内部関数についても基本的には関知せずにメッセージを送出する。また、オブジェクトB(202)自体を特定してメッセージを送出する必要もなく、オブジェクトA(201)は自己の状態、処理内容に基づいてメッセージM1を送出する。オブジェクトB(202)は通信路上を流れるメッセージをモニタしており、メッセージM1を検知し、M1がオブジェクトBにとって有為であるとき、反応してアクションa2を起動する。このようにオブジェクトAとオブジェクトBとは有為な連携を取り得るが、それはオブジェクトA(201)とオブジェクトB(202)の直接の結び付きによるものではなく、メッセージM1とオブジェクトB(202)のアクションa2とが結び付けられている帰結といえる。逆にメッセージがM1とは異なるものであれば、オブジェクトB(202)は当該メッセージがM1と同様の受理可能範囲にあるかあるいは他に当該メッセージと結び付けられているアクションがない限り反応しないこととなる。このようにオブジェクト間の連携が緩やかにメッセージを介して行われることにより、オブジェクト間の連携の自由度が増すこととなる。つまり、従来のコンピュータネットワーク通信のように通信相手のアドレスおよび処理依頼内容を特定する必要がなく、ネットワーク上に自らの状態、処理結果などを表わすAwarenessメッセージを流し、ネットワークをモニタしている各端末がそのメッセージを検知し、対応するアクションが規定されていれば自律的に反応を起こすものである。
なお、Awarenessアナロジーにおいて通信路は単にLANなどの物理的ネットワークだけではなく無線・音声・光などの共通に受信できる媒体を介在するものであれば特に限定する必要はない。また、共通に呼び出し可能なメモリ等の記録媒体であってもかまわない。さらに通信路のポートアドレスなどにより仮想的な存在であってもかまわない。
以上が、Awarenessアナロジーに基づく分散オブジェクトの連携の基本原理である。
次に、本発明の分散オブジェクトの連携をより柔軟にする方式を適用したオブジェクト連携装置を説明する。本発明のオブジェクト連携装置では、上記のAwarenessアナロジーに基づく分散オブジェクトの連携の柔軟性を増し、かつ分散オブジェクトの連携関係を動的に変更する方式を導入する。ここでは、以下の実施形態1から実施形態5により、連携挿入、連携の連結、連携の外部介入、受信側連携参加、送信側連携参加の5つの方式を順に説明する。さらに、実施形態6により、オブジェクト間の連携における連携条件を設け、当該連携条件が満たされた場合に当該オブジェクト間の連携が実行される連携条件設定機能を持たせたオブジェクト連携装置の実施形態を説明する。また、実施形態7により、オブジェクト連携関係を検知して利用者に陽に提示するオブジェクト連携関係提示機能を持たせたオブジェクト連携装置の実施形態を説明する。また、実施形態8により、オブジェクト連携が、塊としてオブジェクト連携関係を維持するオブジェクト連携コア部分と、前記オブジェクト連携コア部分と他のオブジェクトとの連携をとりもつオブジェクト連携インタフェース部分を備え、オブジェクト連携関係の変更が生じた場合に、前記オブジェクト連携コア部分の関係はそのまま維持し、前記オブジェクト連携インタフェース部分の連携先を変更することによりオブジェクト連携関係の変更を行なうオブジェクト連携装置の実施形態を説明する。また、実施形態9により、始点となるオブジェクトから終点となるオブジェクトに至るまでの間をつなぐ連携関係を形成するオブジェクトを探索することにより、オブジェクト連携を形成する機能を持たせたオブジェクト連携装置の実施形態を説明する。また、実施形態10により、本発明のオブジェクト連携装置を実現する処理ステップを備えた処理プログラムを記録したコンピュータ読み取り可能な記録媒体の例を示した実施形態を説明する。
(実施の形態1)
本実施形態1は、Awarenessアナロジーに基づく分散オブジェクト連携におけるオブジェクト連携挿入の基本原理と本原理を適用したオブジェクト連携装置を説明する。
オブジェクト連携挿入とは、ある一連のオブジェクト連携がある場合に、当該一連のオブジェクト連携の一部に他のオブジェクトとの新たなオブジェクト連携関係を挿入することをいい、当該一連のオブジェクト連携の一部を分離し、分離した前後のオブジェクトと、挿入する他のオブジェクトとの間をそれぞれ連携関係を構築することにより、連携を分離した前方のオブジェクトから挿入する新たなオブジェクトへ連携し、さらに挿入した新たなオブジェクトから、連携を分離した後方のオブジェクトへ連携し、新たな一連のオブジェクト連携を構築することをいう。
図2は、オブジェクト連携挿入の基本原理を図式化して示した図である。オブジェクト、メッセージ、オブジェクトのアクション部分を概念的に抜き出して表示したものである。図2(a)は、オブジェクト連携挿入前の様子を示している。図2(b)はオブジェクト連携挿入後の様子を示している。図2において、201はオブジェクトA、202はオブジェクトB、203はオブジェクトCを表わしており、それぞれメッセージを送受信する主体であるオブジェクトである。M1,M2はメッセージを表わしている。a1はオブジェクトA(201)中に規定されたアクション、a2はオブジェクトB(202)中に規定されたアクション、a3はオブジェクトC(203)中に規定されたアクションを示す。なお、以下の実施形態において図中の矢印は、起点がオブジェクトのときメッセージの送出を、終点がオブジェクトのときメッセージの受信を示している。また、それぞれのオブジェクトは内部状態としてのアクションをそれぞれ独自に持っているとする。
まず、図2(a)に示すように、オブジェクトA(201)とオブジェクトB(202)との間にはメッセージM1を介してオブジェクト連携関係が構築されている。オブジェクト連携の基本原理でも説明したように、このオブジェクト連携はメッセージM1を介した緩やかな連携となっている。メッセージM1は送信相手のアドレスを指定して送信する必要はなく、送信するオブジェクトはネットワークフィールド(通信メディア)上にメッセージを流し、受信するオブジェクトはネットワークフィールドをモニタして当該メッセージを任意に取り込むことができるものである。つまり、オブジェクトA(201)は、オブジェクトB(202)およびアクションa2を意識する必要はなく、ネットワーク上にメッセージM1を送信している。つまり、どのようなオブジェクト連携関係があるかに関わらない。
ここで、オブジェクトB(202)のメッセージ・アクションの反応関係を書き換えることにより、図2(b)のようにオブジェクトC(203)のオブジェクト連携を挿入することが可能となる。つまり、オブジェクトBのメッセージ・アクションの反応関係を書き換え、アクションa2をメッセージM2に対して反応するアクションとして定義し、さらにオブジェクトC(203)が保持するメッセージ・アクションの反応関係として、メッセージM1に反応するアクションをa3とし、アクションa3によりメッセージM1を送信するものを構築すれば、オブジェクト連携関係として、オブジェクトC(203)という新たなオブジェクトの挿入が可能となる。
このオブジェクト連携挿入は、多段とすることが可能であることは言うまでもない。その様子を図3に示す。図3では、連携挿入を2段階としたものを示している。上記の図2(a)から見て、図3は、オブジェクトA(201)とオブジェクトB(202)のオブジェクト連携に対して、オブジェクトC(203)とオブジェクトD(204)が挿入され、メッセージM1→アクションa3→メッセージM2→アクションa4→メッセージM3→アクションa2というメッセージ・アクション反応関係が構築され、オブジェクトの連携が実現されている。
また、オブジェクト連携挿入の逆の処理としてオブジェクト連携の縮退も可能であることは言うまでもない。
次に、上記オブジェクト連携挿入の基本原理を適用したオブジェクト連携装置を示す。図4はオブジェクト連携装置の概略構成ブロック図である。
図4において、101は、ネットワーク上に送信されるメッセージをモニタして取り込むメッセージ受信部である。102は、メッセージに対する反応であるアクション内容とメッセージとの関係を記憶するメッセージ・アクション反応関係記憶部であり、メッセージ・アクション反応関係記憶部102は、メッセージ・アクション反応関係を保持するメッセージ・アクション反応テーブル(反応テーブル)103を備えている。ここでメッセージ・アクション反応関係記憶部102はメッセージ・アクション反応テーブル103にあるメッセージのパターンと101によって受信したメッセージとの比較を行ない、受信したメッセージが自らの持つメッセージのパターンと一致するかあるいは包含されるとき、対応するアクション内容を実行する。104は、指定されたアクション内容に従って処理を実行するアクション実行部である。105は、メッセージ・アクション反応関係を更新する必要性に応じてメッセージ・アクション反応関係記憶部102に記憶されたメッセージ・アクション反応関係の更新を制御するメッセージ・アクション反応関係更新制御部であり、メッセージ・アクション反応関係記憶部102中のメッセージ・アクション対応関係を分離するメッセージ・アクション反応関係分離部106と、指定されたメッセージに対して指定されたアクションを関係づけるメッセージ・アクション反応関係構築部107を備えている。
また、108は、必要に応じてネットワーク上にメッセージを送信するメッセージ送信部、109は通信インタフェース、110は通信メディアであるフィールドであり、コンピュータ間の通信などのネットワークも含む概念である。
いま、本発明のオブジェクト連携装置の具体的な実施形態として、ファイル共有表示を行う例を取り挙げて動作を説明する。
図5は、本実施形態1のオブジェクト連携挿入前のオブジェクト連携の概念を示している。501は共有表示機能を持たないファイル表示オブジェクト、502は共有表示機能を持たないディスプレイオブジェクトである。ファイル表示オブジェクト501およびディスプレイオブジェクト502とも図4に示す構成を持つものとする。
いま、ファイル表示オブジェクト501がファイルAをディスプレイ上に表示する処理を行いたい場合、メッセージ送信部108および通信インタフェース109を介してメッセージM3をフィールド110に送出する。ここでメッセージM3は例えば(Display, FileA, x400, y300)とし、ファイルAをXY座標(400,300)を起点として表示するものとする。ディスプレイオブジェクト502はフィールド110をモニタしており、通信インタフェース109を介してメッセージ受信部108によりメッセージM3を検知して取り込む。
図5(b)はディスプレイオブジェクト502のメッセージ・アクション反応関係記憶部102が保持している、メッセージ・アクション反応テーブル(反応テーブル)103の内容を表わしている。テーブルの左側にメッセージ、テーブルの右側に対応するアクションが記述されている。ここで、メッセージは(Display,*, *, *)と記述されているが、“*”はワイルドカードを意味し、記述内容の如何にかかわらずすべてが該当する。つまり、“Display”を第1項目として始まるメッセージはすべて該当することとなる。アクションは“Draw”とされ、ディスプレイオブジェクトがディスプレイ上に描画処理を実行することを指す。ディスプレイオブジェクト502は、メッセージM3を受信するとメッセージ・アクション反応テーブル103の内容を参照し、アクション“Draw”が得られ、アクション実行部104が描画処理を実行する。
次に、オブジェクト連携の挿入を行う場合を説明する。ここでは、新たに共有オブジェクトを導入し、新たなオブジェクト連携を挿入してシステムに共有表示機能を導入する例を示す。
図6(a)が新たに共有オブジェクト503を挿入した様子である。図6(a)に示すように、オブジェクトの連携は、ファイル表示オブジェクト501からディスプレイオブジェクト502へ連携するが、その後、共有オブジェクト503への連携を経て再度ディスプレイオブジェクト502へ連携しており、共有オブジェクト503への連携が挿入された形態となっている。
まず、メッセージ・アクション反応関係更新制御部105は、例えば、利用者からの指示やオブジェクト分散システムの負荷状況改善の必要性などから、メッセージ・アクション反応関係の更新内容が与えられると、メッセージ・アクション反応関係分離部106により、ディスプレイオブジェクト502のメッセージ・アクション反応関係記憶部102中のメッセージ・アクション対応関係を分離する。ここでは、メッセージ(Display,*, *, *)とアクション(Draw)の関係付けを解消することを意味し、それらをディスプレイオブジェクト502のメッセージ・アクション反応テーブル103のエントリから一時消去しても良い。次に、メッセージ・アクション反応関係更新制御部105は、メッセージ・アクション反応関係構築部107により、図6(b)に示すメッセージ・アクション反応テーブル103をディスプレイオブジェクト502に構築する。メッセージ(Display,*,*,*)に対してアクション(Status)が関係づけられ、新たにメッセージ(Display-shared,*,*,*)とアクション(Shared draw)のメッセージ・アクション対応関係およびメッセージ(Display-unshared,*,*,*)とアクション(Unshared draw)を追加構築する。さらに、共有オブジェクト503において、メッセージ・アクション反応関係更新制御部105は、メッセージ・アクション反応関係構築部107により、図6(c)に示すメッセージ・アクション反応テーブル103を構築する。新たにメッセージ(Check-status,*,*,*)とアクション(Share)のメッセージ・アクション対応関係を構築する。
以上のメッセージ・アクション反応テーブル103の更新により、オブジェクト連携装置の動作は、以下のようになる。まず、ファイル表示オブジェクト501から送信されたメッセージM3(Display,File-A, x400, y300)が送出され、ディスプレイオブジェクト502はメッセージ・アクション反応テーブル103に基づいて反応し、アクション“Status”が実行される。ここで、アクション“Status”はメッセージM4(Check-status, File-A, x400, y300)を送出するようにプログラミングされており、メッセージM4をフィールド110上に送出する。次に、フィールド110をモニタしている共有オブジェクト503がメッセージM4を通信インタフェース109およびメッセージ受信部108を介して取り込む。共有オブジェクト503は、図6(c)に示すメッセージ・アクション反応テーブル103に従って反応し、アクション“Share”を実行する。ここでアクション“Share”はメッセージM4の第2項で指定されたFile-Aが共有状態にあるファイルか否かをチェックし、共有状態であればディスプレイ上でファイル共有状態表示であることをユーザに通知した上でメッセージM5(Display-share, File-A, x400, y300)を送出し、共有状態でなければユーザにファイル共有状態にはないことを通知した上でM6(Display-unshared, File-A, x400, y300)を送出する。Fig5(a)では、ファイルAは共有状態とし、共有オブジェクト503はメッセージM5(Display-shared, File-A, x400, y300)を送出する例を示している。ディスプレイオブジェクト502はメッセージ・アクション反応テーブル103に従って反応し、アクション“Draw”を実行する。
以上示したように、本来共有状態表示を持たなかった図5の構成によるオブジェクト連携装置が、本発明にかかるオブジェクト連携挿入を実施して図6に示す構成とすることにより、共有オブジェクト(オブジェクト)503と連携して共有状態表示が可能となった。
ここで注目すべき点は、第1に、ファイル表示を依頼したファイル表示オブジェクト501には一切変更が加えられていない点が挙げられる。第2に、ディスプイオブジェクト502への変更は動作状態において動的に可能である点が挙げられる。通常の従来のプログラミング技法によるオブジェクト連携では、ディスプレイオブジェクト502に対して行った変更は、プログラミングコードの再コンパイルやファイル表示オブジェクト501側での関数の変更が必要となるが、本発明にかかるオブジェクト連携挿入方式では、そのような作業は必要ではなく、より容易かつ柔軟に複数オブジェクトの連携関係の挿入、変更が可能となる。
(実施形態2)
本実施形態2は、分散オブジェクト連携におけるオブジェクト連携の連結の基本原理と本原理を適用したオブジェクト連携装置を説明する。
オブジェクト連携の連結とは、ある2つのオブジェクト連携が相互に独立して存在する場合に、当該2つのオブジェクト連携間の間を連結するブリッジの役割を果たすオブジェクトの連携関係を新たに構築し、2つの相互に独立したオブジェクト連携を一連のオブジェクト連携にすることをいう。つまり、当該2つのオブジェクト連携のうち一方のオブジェクト連携に続く新たなオブジェクト連携を挿入し、かつ、その新たなオブジェクト連携を上記2つのオブジェクト連携の他方へ連携させるものである。
図7は、オブジェクト連携の連結の基本原理を図式化したものである。図5と同様、オブジェクト、メッセージ、オブジェクトのアクション部分を概念的に抜き出して表示したものである。図7(a)はオブジェクト連携を連結する前の相互に独立したオブジェクト連携がある様子を示しており、図7(b)がオブジェクト連携の連結後の様子を示している。図7において、701〜705はそれぞれオブジェクトA〜オブジェクトEであり、M7〜M10はメッセージである。
図7(a)において、オブジェクトA701とオブジェクトB702はメッセージM7を介して連携しており、オブジェクトC703とオブジェクトD704はメッセージM8を介して連携している。オブジェクトB702はアクションの一環においてメッセージM9をフィールド上に送信するが、オブジェクトC703およびオブジェクトD704は反応しない。ここでオブジェクトC703はメッセージM10に反応するものとする。このように、それぞれ2つのオブジェクト連携同士は相互に独立しており、オブジェクト連携関係を持っていない。
ここで、図7(b)に示すように、新たなメッセージ・アクション反応関係を持つオブジェクトE705を追加し、2つの独立したオブジェクト連携を連結することを考える。オブジェクトE705が、メッセージM9に反応してアクションa5を起動し、メッセージM10をフィールド上に送出するものとすると、上記一のオブジェクト連携であるオブジェクトA701〜オブジェクトB702のオブジェクト連携後に送出されるメッセージM9が、オブジェクトE705に取り込まれ、アクションa5を介してメッセージM10がフィールド上に送信され、上記他方のオブジェクト連携であるオブジェクトC703がメッセージM10に対して反応してオブジェクトC703〜オブジェクトD704のオブジェクト連携が起動する。このように図7(a)では相互に独立していたオブジェクト連携が図7(b)に示すように一連のオブジェクト連携として連結される。以上がオブジェクト連携の連結の基本原理である。
次に、オブジェクト連携連結の基本原理を適用した本発明のオブジェクト連携装置の実施形態を以下に示す。
メモ転送サービスを具体例として説明する。
本オブジェクト連携装置の概略構成ブロック図は、図4に示すものと同様で良いのでここでは詳細な説明は適宜省略する。
図8は、本実施形態2のオブジェクト連携の連結前のオブジェクト連携の概念を示している。801は第1のメモ送信オブジェクト(オブジェクト)、802は第1のメモ受信オブジェクトでディスプレイ上に受信内容を表示するオブジェクト、803は第2のメモ送信オブジェクト、804は第2のメモ受信オブジェクトでディスプレイ上に受信内容を表示するオブジェクトである。ここでは、相互に独立した2つのオブジェクト連携があり、第1のメモ送信オブジェクト801と第1のメモ受信オブジェクト802のオブジェクト連携と、第2のメモ送信オブジェクト803と第2のメモ受信オブジェクト804のオブジェクト連携がある。
今、メモ送信者Sが第1のメモ送信オブジェクト801を利用してメモ受信者RにファイルBからなるメモ1を送信する場合を考える。通常、メモ送信者Sが第1のメモ送信オブジェクト801が存在するコンピュータを利用し、メッセージM11を送信するアクションを起動させる。メッセージM11は(Memo, user-S, user-R, File-B)のごとくなるものとする。メモ受信者Rが使っているコンピュータのメッセージ受信オブジェクト802は、図8(b)に示すようなメッセージ・アクション反応テーブルを持ち、メッセージ(Memo,*,*,*)とアクション(Show memo)のメッセージ・アクション対応関係が保持されている。メモ受信オブジェクト802は、メッセージM11に対して反応することとなり、アクション(Show memo)が起動され、メモ受信者Rが使っているコンピュータのディスプレイ上にファイルBが表示される。
ここで、メモ受信者Rが外出し、例えば、遠隔場所に移動したとする。この場合、上記オブジェクト連携だけでは、実際にメモ受信Rがメモを受信することができない。もし、メモ受信者Rの外出先にコンピュータがあり、そこには第2のメモ送信オブジェクト803と第2のメモ受信オブジェクト804のオブジェクト連携が存在し、第2のメモ受信オブジェクトが表示するディスプレイをメモ受信者Rが見られる環境にある場合を想定する。
ここで、図9(a)のようにオブジェクト連携の連結を考える。メモ受信者Rは外出前、受信メモを転送するように新しいオブジェクト連携を構築してメモが第2のメモ受信オブジェクト804までオブジェクト連携を連結する。メモ受信者Rは、第1のメモ受信オブジェクト802が存在するオブジェクト連携装置のメッセージ・アクション反応関係更新制御部105により、図8(b)に示したメッセージ・アクション反応テーブル103の内容を図9(b)に示すように(Memo,*,*,*)とアクション(Ask transfer)のメッセージ・アクション反応関係に更新し、さらに、転送オブジェクト805を新たに構築し、転送オブジェクト805のメッセージ・アクション反応関係構築部107を介して、図9(c)に示すようにメッセージ(Transfer,*,*,*)とアクション(Send)からなるメッセージ・アクション反応テーブル103をメッセージ・アクション反応関係記憶部102上に構築する。
一方、第2のメモ送信オブジェクト803は、図9(d)に示すメッセージ・アクション反応テーブル103を保持しており、第2のメモ受信オブジェクト804は、図9(e)に示すメッセージ・アクション反応テーブル103を保持している。
以上のように構築されたオブジェクト連携の連結の動作を説明する。
まず、メモ送信者Sが第1のメモ送信オブジェクト801が存在するコンピュータを利用し、メッセージM11(Memo,user-S,user-R,File-B)を送信するアクションを起動させる。この点は、図8(a)と同様である。メモ受信者Rが使っているコンピュータのメモ受信オブジェクト802は、図9(b)に示すメッセージ・アクション対応関係に応じてメッセージM11に反応してアクション“Ask transfer”が実行される。ここでアクション“Ask transfer”はメッセージM11の第4項で指定されたFile-Bの転送を依頼するメッセージM12を出力する。メッセージM12は(Transfer,user-S,user-R,File-B)のごとくである。転送オブジェクト805は図9(c)に示すメッセージ・アクション反応テーブルに従い、メッセージM12に反応してアクション“Send”を起動する。“Send”はメッセージM12の第4項で指定されたFile-Bを転送するメッセージM13を送信する。転送にあたりあらかじめメモ受信者Rが外出先にあるコンピュータまたは当該コンピュータを含むネットワークの範囲を限定して転送しても良い。メッセージM13は(Ask-show,user-S,user-R’,File-B)のごとくである。ここで第3項のuser-R’は転送先を示している。メモ受信者Rの外出先のコンピュータの第2のメッセージ送信オブジェクト803は、図9(d)に示すようなメッセージ・アクション反応テーブルを持ち、メッセージ(Ask-show,*,*,*)とアクション(Request show)のメッセージ・アクション対応関係が保持されており、メモ送信オブジェクト803は、メッセージM13に対して反応することとなり、アクション(Request-show)が起動され、メッセージM14を持ってメモ内容を送信する。メモ受信者Rの外出先のコンピュータに存在する第2のメッセージ受信オブジェクト804は、図9(e)に示すメッセージ・アクション反応テーブルを持ち、メッセージ(Memo,*,*,*)とアクション(Show memo)のメッセージ・アクション対応関係が保持されている。第2のメモ受信オブジェクト804は、メッセージM14に対して反応することとなり、アクション(Show
memo)が起動され、メモ受信者Rの外出先のコンピュータのディスプレイ上にファイルBが表示される。
以上示したように、本来図8(a)に示すように相互に独立した2つのオブジェクト連携同士に対して、図9(a)に示すようにオブジェクト連携を連結して一連のオブジェクト連携を構築することが可能となる。
ここで、図8に示した第1のメモ送信オブジェクト801と第1のメモ受信オブジェクト802の組と、第2のメモ送信オブジェクト803と第2のメモ受信オブジェクト804の組は等価である必要はなく、それぞれが図1で示した基本原理に基づいて動作するものであればかまわない。従って上記メモ送信オブジェクトと受信オブジェクトの組みが実際に動作する機器、OS、記述言語は独立であってかまわない。また、それぞれが図1に基づくメッセージ交換をするとき、メッセージのフォーマットが同じものである必要性はかならずしもなく、図9に示した両者の組の間を仲介する転送オブジェクト805が両者間のフォーマットの変換機能を備えていれば良い。
本実施形態においてのメモ転送のオブジェクト連携装置で注目すべき点の一つに、メモ転送を依頼した第1のメモ送信オブジェクト801には一切変更が加えられていない点が挙げられる。第2に、第1の受信オブジェクト802、転送オブジェクト805の変更は動作状態において動的に可能である点が挙げられる。通常の従来のプログラミング技法によるオブジェクト連携では、第1の受信オブジェクト802、転送オブジェクト805の変更は、プログラミングコードの再コンパイルや関数の変更が必要となるが、本発明にかかるオブジェクト連携連結方式では、そのような作業は必要ではなく、より容易かつ柔軟に複数独立したオブジェクトの連携の連結、変更が可能となる。
(実施形態3)
本実施形態3は、分散オブジェクト連携におけるオブジェクト連携の外部介入の基本原理と本原理を適用したオブジェクト連携装置を説明する。
オブジェクト連携の外部介入とは、あるメッセージ・アクション反応関係により連携しているオブジェクト連携に対して他のオブジェクトが外部から介入し、当初のメッセージ・アクション反応関係を切断し、オブジェクト連携の流れを自らに取り込み所定のアクションを実行した後、オブジェクト連携の流れを元のオブジェクトに返すものであり、実施形態1で説明したオブジェクト連携の挿入による介入の過程を外部にある他のオブジェクトによる介入として模式的に表したものである。実施形態1で説明したオブジェクト連携の多段挿入による介入の過程の説明はここでは適宜省略する。図10に示す外部介入の例において分かるように、オブジェクト連携の外部介入は次に3段階からなる。つまり、オブジェクトAの内部でメッセージ・アクションの切断の第1段階、オブジェクト連携先の付け替えの第2段階、新たなメッセージ・アクションの結合・外部オブジェクトによる介入実行の第3段階という3つの段階を経て行なわれている。この外部介入によってオブジェクトAのみでは存在しなかった機能が、外部のオブジェクトBとの相互作用を通して追加されたことになる。図10の例で明らかなように、メッセージとアクションとの分離は、新たなオブジェクトとの相互作用の可能性を開く。Awarenessアナロジ一の観点から見ても、分散オブジェクトの緩やかな連携における自由度は、メッセージ・アクションの連鎖の分離と再結合が可能であることによって生まれている。
次に、オブジェクト連携の外部介入の基本原理を適用した本発明のオブジェクト連携装置の実施形態を以下に示す。
タスクの依頼・応答を具体例として説明する。特に、当初外部からの負荷実行要求に対して単調な反応しか行うことの出来なかったオブジェクト群が、集団による負荷分散を実現できるように動的に変化する例を示す。
本オブジェクト連携装置の概略構成ブロック図は、図4に示すものと同様で良いのでここでは詳細な説明は適宜省略する。
図11は、本実施形態3のオブジェクト連携の外部介入前のオブジェクト連携の概念を示しており、負荷に対して単調な反応を示す場合の例である。この例ではタスクオブジェクト1101の持つアクションはフィールドに“query”というメッセージM19を流している。このメッセージを受けて、メッセージ・アクション反応テーブルに“query‐serve”というメッセージ・アクションの組を持つサーブオブジェクト1102が反応している。この図11に示す例では“query”というメッセージに反応するサーブオブジェクト1102が複数存在したとしても、それぞれのサーブオブジェクト1102はそれぞれが独立にアクション“Serve”を実行することになる。
次に、図12は、本実施形態3のオブジェクト連携の外部介入によるオブジェクト連携の概念を示しており、外部オブジェクトとして仲介オブジェクト1103がサーブオブジェクト1102のメッセージ・アクション反応テーブルを書き換え、図11に示したメッセージ“query”とアクション“serve”というメッセージ・アクションのオブジェクト連携を切断し、仲介オブジェクト1103自らが介入し、“query(M19)”→“Bid”→“apply(M20)”→“Decide”→“action(M21)”→“Serve”というオブジェクト連携へと変更している。
以上のオブジェクト連携の外部介入によって、タスクオブジェクトは図11と同様に“query”メッセージを発信している点では全く同じ動作であるが、サーブオブジェクト1102はこのメッセージ“query”に単純に反応するのではなく、仲介オブジェクト1103への“Bid”(応札)、“Decide”(落札)を受けてから“Serve”アクションを起こすように変化している。したがって仲介オブジェクトに競合する二つ以上のサーブオブジェクト1102の選別機能を持たせれば、負荷の低いサーブオブジェクト1102にタスクオブジェクト1101からの“query”を実行させるような負荷分散機能を持たせたことが可能となる。ここで重要なことは、システム設計においてあらかじめ図12のオブジェクト連携の状態を想定する必要はなく、図11の単純なオブジェクト連携の状態を設計したのち、必要に応じて後から新たに仲介オブジェクトを追加した図12のシステム形態への拡張設計を可能にしている点である。通常の従来のプログラミング技法によるオブジェクト連携では、タスクオブジェクト1101、サーブオブジェクト1102の変更は、プログラミングコードの再コンパイルや関数の変更が必要となるが、本発明にかかるオブジェクト連携外部介入方式では、そのような作業は必要ではなく、より容易かつ柔軟に外部オブジェクトの介入によるオブジェクトの連携の変更が可能となる。
(実施形態4)
本実施形態4は、Awarenessアナロジーに基づく分散オブジェクトの連携における受信側連携参加の基本原理と本原理を適用したオブジェクト連携装置を説明する。
受信側連携参加とは、ある一つのメッセージによって連携しているオブジェクト連携がある場合に、他のオブジェクトが当該メッセージに対して反応するメッセージ・アクション反応関係を追加することにより、新たなオブジェクト連携を構築し、前記のオブジェクト連携に対して参加することをいう。つまり、一つのAwarenessメッセージに対するオブジェクト連携に複数のオブジェクトが反応して参加することが可能となる。
図13は、オブジェクト連携の受信側参加の基本原理を示す図であり、オブジェクトA(1301)の送信したメッセージM22に対し、オブジェクトB(1302),C(1303),D(1304)がそれぞれ独自に反応している様子を示している。もちろんオブジェクトB(1302),C(1303),D(1304)におけるアクションは同じものであっても、それぞれ別のものであってもかまわない。このときオブジェクトB(1302)にとって、他のオブジェクトC(1303),D(1304)が存在しても存在しなくても影響はない。したがって図13におけるオブジェクトB(1302),C(1303),D(1304)などの追加・削除は新規オブジェクトの参加や離脱によるアプリケーションの生成・消滅に他ならない。
オブジェクト連携の受信側参加の基本原理を適用した本発明のオブジェクト連携装置の実施形態を図14に説明する。図14は、実施形態1の図5で説明したファイル内容のディスプレイ表示の例において受信側参加した例である。実施形態1と同様、ファイル表示オブジェクト1401がファイルAをディスプレイ上に表示する処理を実行するためメッセージ送信部108および通信インタフェース109を介してメッセージM22(Display, FileA, x400, y300)をフィールド110に送出する。フィールド110上には、図14(b)に示すメッセージM22に反応するメッセージ・アクション反応テーブル103を保持しているディスプレイオブジェクト1402a〜ディスプレイオブジェクト1402cの3つのディスプレイオブジェクトが存在している。これらはフィールド110をモニタしており、フィールド110上を流れるメッセージM22を検知して取り込む。
ここではディスプレイオブジェクト1402a〜ディスプレイオブジェクト1402cの3つのオブジェクトがM22の(Display, FileA, x400, y300)に反応し、アクション“Draw”を実行してファイルAをディスプレイ上にそれぞれ表示する。もちろんここで1402a,1402b,1402cは異なったマシンに対する異なったアクションで良く、すなわちそれぞれのオブジェクトが表示するディスプレイは同一である必要はなく、また表示形式や表示内容も同一である必要はない。
このように、一のメッセージに対して反応するアクションを持つオブジェクト連携に対して、並行して当該一のメッセージに反応するアクションを持つオブジェクトを追加することによりオブジェクト連携の受信側に参加することができる。
(実施形態5)
本実施形態5は、Awarenessアナロジーに基づく分散オブジェクトの連携における送信側連携参加の基本原理と本原理を適用したオブジェクト連携装置を説明する。
送信側連携参加とは、ある一つのメッセージによって連携しているオブジェクト連携がある場合に、他のオブジェクトが当該一のメッセージをフィールド110上に送信することにより、新たなオブジェクト連携を構築し、前記のオブジェクト連携に対して送信側から参加することをいう。つまり、一つのAwarenessメッセージに対するオブジェクト連携に複数のオブジェクトが同じメッセージを送信して参加することが可能となる。
図15はオブジェクト連携の送信側参加の基本原理を示す図であり、図15に示すように、オブジェクトA(1501)とB(1502)が同一のメッセージM23を送出し、オブジェクトC(1503)とメッセージM23とが結び付けられている。この場合、オブジェクトC(1503)はメッセージM23がオブジェクトA(1501)から送信されたメッセージであるかオブジェクトB(1502)から送信されたメッセージであるかは関係なく、反応してアクションを起動する。これはオブジェクトの連携において送出側での参加を許容しているということになる。これは見方を変えるとオブジェクトA(1501)とオブジェクトC(1503)との連携にオブジェクトB(1502)が送信者側として介入しているということができる。
このように、一のメッセージに対して反応するアクションを持つオブジェクト連携に対して、並行して当該一のメッセージを送信するアクションを持つオブジェクトを追加することによりオブジェクト連携の送信側に参加することができる。
オブジェクト連携の送信側参加の基本原理を適用した本発明のオブジェクト連携装置の実施形態を図16に説明する。図16は、実施形態1の図5で説明したファイル内容のディスプレイ表示の例において送信側参加した例である。実施形態1と同様、ファイル表示オブジェクト1601aがファイルAをディスプレイ上に表示する処理を実行するためメッセージ送信部108および通信インタフェース109を介してメッセージM24(Display, FileA, x400, y300)をフィールド110に送出する。フィールド110上には、ファイル表示オブジェクト1601aの他にアクションとしてメッセージM24を送信するファイル表示オブジェクト1601b〜1601cが存在している。ディスプレイオブジェクト1602は、フィールド110をモニタしており、メッセージM24を検知して取り込むため、送信側オブジェクトが3つ存在することとなる。ここではディスプレイオブジェクト1602が図15(b)に示すメッセージ・アクション反応テーブル103を保持しており、メッセージM24に反応してアクション“Draw”を実行し、それぞれの送信側オブジェクト1601a〜1601cから送信されたファイルをディスプレイ上に表示する。
このように、一のメッセージに対して反応するアクションを持つオブジェクト連携に対して、並行して当該一のメッセージを送信するアクションを持つ送信オブジェクトを追加することによりオブジェクト連携の送信側に参加することができる。
(実施形態6)
本発明の実施形態6のオブジェクト連携装置は、さらに、メッセージ・アクション反応条件設定部を備え、オブジェクトごとに受信したメッセージに対応するアクションが実行されるためのメッセージ・アクション反応条件を設定しておくもので、メッセージ・アクション反応関係記憶部が、メッセージ・アクション反応関係とメッセージ・アクション反応条件とを関連付けて記憶し、前記アクション実行部は、前記メッセージ・アクション反応条件が満たされた場合に受信したメッセージに対するアクションを実行するものである。
図17は本実施形態6のオブジェクト連携装置の概略構成ブロック図である。本実施形態6のオブジェクト連携装置は、図17に示すように、メッセージ・アクション反応条件設定部120を備えている。また、メッセージ・アクション反応関係記憶部102のメッセージ・アクション反応テーブル103aは、メッセージに対して関係付けられたアクションに加えて、当該メッセージ・アクション反応が実行されるためのメッセージ・アクション反応条件が関係付けられている。このメッセージ・アクション反応条件はメッセージ・アクション反応条件設定部120により設定される。設定されるメッセージ・アクション反応条件は、メッセージの特定のパラメタが設定範囲内にあるか否かというものでも良く、また、負荷条件などオブジェクトプラットフォームの環境が設定範囲内にあるか否かというものでも良い。なお、他の構成要素については実施形態1の図4で説明したものと同様のものについては同じ番号を付し、ここでの説明は省略する。
本実施形態6のオブジェクト連携装置によるオブジェクト間の連携の概念を図18に示す。これはメッセージ・アクション反応条件の働きを概念的に表わしたものである。図18に示すように、オブジェクトB1802にはメッセージ・アクション反応条件1803が設けられている。概念的には受信したメッセージに対するフィルタとして働き、条件を満たす場合のみ受け入れを許可し、条件を満たさない場合には受け入れを拒否する。オブジェクトA1801から発信されたメッセージM25はオブジェクトBに受信された後、メッセージ・アクション反応条件1803が満たされているか否かをチェックする。どのようなメッセージ・アクション反応条件を設定するかは、運用による。例えば、メッセージを受信したオブジェクトのプラットフォームとしての負荷率に注目した反応条件を設定することができる。反応条件が負荷率0.5以下とすると、負荷率が0.5を超えているような負荷の大きいオブジェクトは、備えているメッセージ・アクション反応テーブル103aにおいて、受信したメッセージに対してアクションが記述されていても、与えられているメッセージ・アクション反応条件が満足されていないのでアクション反応を実行することはない。
メッセージ・アクション反応条件を設けることにより、以下のような効果を得ることができる。
第1には、メッセージ・アクションの反応関係をより柔軟に記述することができる。実際の運用において利用者が実現したい処理や制御は複雑であったり、特定の条件が関係することがあり、メッセージとアクションの1対1の関係の記述のみですべてを記述することは困難である場合が想定される。本実施形態のオブジェクト連携装置によれば、複雑で特定の条件が関係する実運用の処理や制御をメッセージ・アクション反応テーブル102を用いて容易に記述することができる。
第2には、フィールド110によりネットワークを形成しているオブジェクト連携装置全体において調和された負荷分散処理を実現することができる。メッセージとアクションの1対1の関係の記述のみであれば、メッセージ・アクション反応テーブルに記述されたメッセージを受信すればアクションを起こすことになる。受信したオブジェクトの稼動状況などは考慮されない。多数のオブジェクトから頻繁に発信されるメッセージの反応が記述されているオブジェクトは頻繁にアクションを実行することとなり、一時的に過負荷に陥る場合も想定され、負荷が集中することがある。本実施形態6のオブジェクト連携装置によれば、メッセージ・アクション反応条件として負荷率の上限値を設けておけば負荷の集中を防止することができ、調和のとれた負荷分散を実現できる。また、本実施形態6のオブジェクト連携装置によれば、二つの特定のメッセージが受理されたときにアクションを実行するようなAND論理演算処理を実現することもできる。
(実施形態7)
本実施形態7は、分散オブジェクト連携装置におけるオブジェクト連携関係をオブジェクトを表わすアイコンと、オブジェクト連携関係を表わすリンク線とにより表現したビジュアルチャートなどにより、外部に対して陽に示すものである。
図19は、本実施形態7のオブジェクト連携装置の基本原理を説明する図である。図19の例では説明の便宜上、フィールド110には3つのオブジェクト連携装置A1910、オブジェクト連携装置B1920、オブジェクト連携装置C1930のみが接続されている。原理的には接続されるオブジェクト連携装置の数には制限はなく、フィールド110は多数のフィールドがインターネットなどのネットワーク上で接続されたものでも良い。また、図19の例では説明の便宜上、オブジェクト連携装置内の構成要素は適宜省略しており、オブジェクト連携装置A1910は、通信インタフェース109、メッセージ・アクション反応テーブル103、メッセージ・アクション反応関係情報収集部130、オブジェクト連携関係解析部140オブジェクト連携関係提示部150のみが図示されているが、それ以外の構成要素も図4または図17に示した構成要素と同様のものを備えている。また、オブジェクト連携装置B1920、オブジェクト連携装置C1930については内部の構成要素をすべて省略して図示している。
分散オブジェクト連携装置におけるオブジェクト連携関係の抽出とその可視化方法を説明する。まず、各オブジェクト連携装置はメッセージ・アクション反応関係情報収集部130により自らが備えるオブジェクト、各オブジェクトのメッセージ・アクション反応テーブル103からメッセージと関係付けられたアクションの関係を示す情報を抽出する。次に、当該メッセージ・アクション反応関係情報を他のオブジェクト連携装置間で交換し合う。メッセージ・アクション反応関係情報をメッセージとしてメッセージ送信部108および通信インタフェース109を介してフィールド110上に流し、他のオブジェクト連携装置に与える。逆に、他のオブジェクト連携装置から発信されるメッセージ・アクション反応関係情報のメッセージを通信インタフェース109およびメッセージ受信部101を介して受信して得る。
次に、得られた各オブジェクト連携装置のオブジェクト、各オブジェクトのメッセージ・アクション反応関係情報をオブジェクト連携関係解析部140により解析し、フィールド上に存在するオブジェクトの連携関係を解析・抽出する。まず、各オブジェクトをアイコンとして表示する。オブジェクトごとについて、反応しうるメッセージ、当該メッセージに対して反応するアクション、当該アクションが起動された場合に発信されるメッセージを抽出する。さらに、当該発信されたメッセージに反応するアクションを持つオブジェクトを洗い出してゆく。つまり、このメッセージ・アクション反応関係はオブジェクト間の連携を意味する。当該連携をオブジェクトアイコン間のリンク線として引く。上記処理をすべてのオブジェクトとその保持するメッセージ・アクション反応関係について行ない、オブジェクト連携関係をビジュアルチャートとして陽にオブジェクト連携関係表示部150上に表示する。ビジュアルチャートの例を図20に示す。
四角のアイコンはオブジェクトであり、下欄にはアクションが示されている。矢印はリンク線であり、矢印始点のオブジェクトの発信したメッセージに対して矢印終点のオブジェクトが反応しうることを示している。矢印にはフィールド上に流れるメッセージが添えられている。
本実施形態7のオブジェクト連携装置によれば、以下の有利な効果が得られる。
第1には、複雑であるオブジェクト連携関係を可視的なビジュアルチャートに表現することができ、連携関係が直感的に分かりやすく把握しやすくなる。
第2には、1つのオブジェクトから起こりうるアクション反応を事前に知ることができる。オブジェクト同士は、メッセージとアクションの反応関係により緩やかに連携しており、本来、1つのオブジェクトからは他のオブジェクトがどのメッセージに対してどのようなアクション反応を起こすかは事前に把握することが困難な場合があるが、本実施形態7のオブジェクト連携装置によれば、起こりうるメッセージ・アクション反応関係、オブジェクト連携関係をビジュアルチャートとして事前に提供することができる。
(実施形態8)
本発明の実施形態8のオブジェクト連携装置は、オブジェクト連携が、塊としてオブジェクト連携関係を維持するオブジェクト連携コア部分と、オブジェクト連携コア部分と他のオブジェクトとの連携をとりもつオブジェクト連携インタフェース部分を備え、オブジェクト連携関係の変更が生じた場合に、オブジェクト連携コア部分の関係はそのまま維持し、オブジェクト連携インタフェース部分の連携先を変更することによりオブジェクト連携関係の変更を行なう例を説明する。
このオブジェクト連携インタフェース部分は、オブジェクト連携の流れにおいて、オブジェクト連携コア部分の後方に位置する場合は、当該オブジェクト連携コア部分の出力メッセージパターンに反応するアクション部分(出力範囲インタフェース)となり、当該アクション内容の書き換えによりオブジェクト連携先を柔軟に変更できる。また、オブジェクト連携コア部分の前方に位置する場合は、当該オブジェクト連携コア部分が反応しうる入力メッセージパターン(入力範囲インタフェース)となり、他のオブジェクトは当該入力メッセージパターンに合致するようにメッセージを発信すれば当該オブジェクト連携コア部分に対してオブジェクト連携を持つことができる。
図21は、オブジェクト連携が、オブジェクト連携コア部分とオブジェクト連携インタフェース部分とを備えた構成を持っている例を示す図である。
図21(a)において、実線2100で囲まれた2つのオブジェクト2100a〜2100bがオブジェクト連携コア部分2100を形成しており、また、実線2110で囲まれた2つのオブジェクト2110a〜2110bが別のオブジェクト連携コア部分2110を形成しており、これらはオブジェクト連携が、塊としてオブジェクト連携関係を維持する部分である。
オブジェクト連携コア部分2100において、オブジェクト2100aはそのメッセージアクション反応テーブル103の記述によりメッセージM26に反応し、アクションa26を起動し、メッセージM27を発するように構成されている。オブジェクト2100bはそのメッセージアクション反応テーブル103の記述によりメッセージM27に反応し、アクションa27を起動し、メッセージM28を発するように構成されている。
オブジェクト連携コア部分2110において、オブジェクト2110aはそのメッセージアクション反応テーブル103の記述によりメッセージM29に反応し、アクションa29を起動し、メッセージM30を発するように構成されている。オブジェクト2110bはそのメッセージアクション反応テーブル103の記述によりメッセージM30に反応し、アクションa30を起動し、メッセージM31を発するように構成されている。
図21(a)に示すようにオブジェクト連携コア部分2100と2110の間には点線で囲まれたオブジェクト連携インタフェース部分2101が設けられている。このオブジェクト連携インタフェース部分は、オブジェクト連携コア部分と他のオブジェクトとの連携をとりもつ部分であり、オブジェクト連携関係の変更が生じた場合に、オブジェクト連携コア部分の関係はそのまま維持し、オブジェクト連携インタフェース部分の連携先を変更することによりオブジェクト連携関係の変更を行なう。オブジェクト連携インタフェース部分は、オブジェクト連携の流れにおいてオブジェクト連携コア部分2100および2110の前方、後方にも設けることができるが、ここでは説明の便宜上、両者の間についてのインタフェースであるオブジェクト連携インタフェース部分2101に注目して説明する。
オブジェクト連携インタフェース部分2101は、1つのメッセージアクション反応テーブル103により制御されているオブジェクトである。メッセージM28に対してアクションa28の関係付けが記述されている。当該アクションa28は、アクションの一部としてメッセージM29を送信する内容となっている。このメッセージM28に反応し、アクションa28を起動するという働きをもってオブジェクト連携コア部分2100の出力範囲インタフェース2102として機能し、また、送信したメッセージM29はオブジェクト連携コア部分2110が反応するのでオブジェクト連携コア部分2110の入力範囲インタフェース2103としても機能している。このオブジェクト連携コア部分2100の出力範囲インタフェース2102とオブジェクト連携コア部分2110の入力範囲インタフェース2103とは、記述されたアクションa28がそのアクションの一部としてメッセージM29を送信するという働きをもって関係づけられている。
今、オブジェクト連携インタフェース部分2101であるオブジェクトにおいて、メッセージアクション反応テーブル103に記述されたアクションa28がそのアクションの一部としてメッセージM29を送信するという関係を断ち切る。つまり、メッセージアクション反応テーブル103中のアクションの内容を書き換える。このオブジェクト連携インタフェース部分2101であるオブジェクトのメッセージアクション反応テーブル103中のアクションの内容を書き換えることにより、オブジェクト連携コア部分2100の出力範囲インタフェース2102とオブジェクト連携コア部分2110の入力範囲インタフェース2103との関係は断ち切られるが、両者はそれぞれオブジェクト連携コア部分のインタフェースとしての機能は失われていない。つまり、出力範囲インタフェース2102と入力範囲インタフェース2103はインタフェースとして機能し、フレキシブルに新たなオブジェクトとの連携を構築することが可能となる。その様子を図21(b)に示す。メッセージアクション反応テーブル103中のアクションの内容を書き換え、アクションa28がアクションの一部としてM32を送信するように記述すれば、あたかも出力範囲インタフェース2102の出力先が、オブジェクト2120に切り替わった効果が得られる。オブジェクト2120もその出力段において(出力範囲インタフェースを持っていることも想定できる)、入力範囲インタフェース2103に合致するように、メッセージM29を送信することとすれば、オブジェクト連携コア部分2110に連携する。このように、オブジェクト連携インタフェース部分の持つインタフェース機能を活用すれば、フレキシブルにオブジェクト連携関係を変更することが可能となる。この様子を図22に示す。
以上の本実施形態8のオブジェクト連携装置の概略構成ブロック図を図23に示す。本実施形態8のオブジェクト連携装置は、図23に示すように、メッセージ・アクション反応関係構築部107aが、アクション内容変更部111とインタフェース検知部112を備えている。このアクション内容変更部111は、メッセージ・アクション反応関係構築部107aによるメッセージ・アクション反応テーブル103の内容の更新の際にアクション内容を書き換える部分である。インタフェース検知部112は、フィールド110上に存在するオブジェクト連携インタフェース部分が構成している入力範囲インタフェース、出力範囲インタフェースを検知し、当該インタフェース情報を管理しておく部分である。メッセージ・アクション反応関係構築部107aは新たなオブジェクト連携関係を構築したいオブジェクトが持つ入力範囲インタフェース、出力範囲インタフェースとつながるように管理するオブジェクトのアクション内容を書き換え、合致するメッセージを送信するように変更し、新たなオブジェクト連携関係を構築する。なお、他の構成要素については実施形態1の図4で説明したものと同様のものについては同じ番号を付し、ここでの説明は省略する。
以上、本実施形態8のオブジェクト連携装置によれば、オブジェクト連携が、塊としてオブジェクト連携関係を維持するオブジェクト連携コア部分と、オブジェクト連携コア部分と他のオブジェクトとの連携をとりもつオブジェクト連携インタフェース部分を備え、オブジェクト連携関係の変更が生じた場合に、オブジェクト連携コア部分の関係はそのまま維持し、オブジェクト連携インタフェース部分の連携先を変更することによりオブジェクト連携関係の変更を行なうことが可能となる。
(実施形態9)
実施形態9は、始点となるオブジェクトから終点となるオブジェクトに至るまでの間をつなぐ連携関係を形成するオブジェクトを探索することにより、オブジェクト連携を形成する機能を持たせたオブジェクト連携装置を説明する。
このオブジェクト連携の形成は、オブジェクト連携を構築したい始点となるオブジェクトと終点となるオブジェクトが決まっており、両者の間をつなぐオブジェクトの連携を探索して連携関係を形成する。本実施形態9のオブジェクト連携装置はオブジェクト探索部113の働きによりオブジェクト連携の探索を実行してゆく。
本実施形態9の探索機能を備えたオブジェクト連携の基本原理を以下に説明する。探索機能としては複数のパターンの例を挙げることができる。例えば、前方向探索、後方向探索、前後両方向探索などがある。以下に後方向探索を例として実施形態9のオブジェクト連携装置およびそのオブジェクト探索機能の基本原理を説明する。
図24は、本発明の実施形態9のオブジェクト連携装置の概略構成ブロック図である。図24に示すように、本実施形態9のオブジェクト連携装置は、オブジェクト探索部113を備えている。オブジェクト探索部113は、入力メッセージパターン、出力メッセージパターンを探索キーとして、フィールド110上に存在する当該入力メッセージパターン、出力メッセージパターンを持つオブジェクトを探索する部分である。なお、オブジェクト探索部113は、探索キーとしてアスタリスク「*」をワイルドカードする探索が可能であり、例えば、探索キーとして入力メッセージパターンが「*」、出力メッセージパターンがjpeg形式と与えられれば、出力メッセージパターンがjpeg形式のものであれば、入力メッセージパターンは任意のもので良く、該当する全てのオブジェクトが結果として得られることとなるものである。オブジェクト探索部113は、オブジェクトメッセージパターン検知部114を備え、前記オブジェクトメッセージパターン検知部114により、指定されたオブジェクトの入力メッセージパターン、出力メッセージパターンを検知することができる。また、後述する図25などに示すように、検知したオブジェクトの入力メッセージパターン、出力メッセージパターンはビジュアルに図示できることが好ましい。なお、他の構成要素については実施形態1の図4で説明したものと同様のものについては同じ番号を付し、ここでの説明は省略する。
図25は、始点となるオブジェクトから終点となるオブジェクトに至るまでのオブジェクト連携を後方向探索方式により探索する基本原理を説明する図である。ここでは例として、「i」形式のデータ(例えば、ビットマップ形式のデータ)を「k」形式のデータ(例えば、JPEG形式の圧縮データ)に変換したいという利用者の要求があり、オブジェクトの連携により当該変換を実行する例を示す。またこの例では、オブジェクト探索部113の探索処理におけるフィールド上のオブジェクト間でのメッセージにおいてオブジェクトの入力メッセージパターン情報と出力メッセージパターン情報は、タグとして記述し、オブジェクトの連携関係はタグを含むプログラム記述言語、例えば、xml言語中のタグという形で記述している。図26に、本実施形態で用いられる入力メッセージ、出力メッセージをあらわすdtdを示す。
第1ステップとして、まず、オブジェクト探索部113は、オブジェクトメッセージパターン検知部114を用いて、始点と終点の提示を示すxml形式のメッセージにより、始点となるオブジェクトの出力メッセージパターンと終点となるオブジェクトの入力メッセージパターンを検知する。
図25(a)に示した例において、左側にあるものは始点となるオブジェクトの出力メッセージパターン(2401)を表わしている。ここでは、「i」形式である。右側にあるものは終点となるオブジェクトの入力メッセージパターン(2402)を表わしている。ここでは、「k」形式である。つまり、始点となるオブジェクトの出力メッセージパターン2401から出発し、終点となるオブジェクトの入力メッセージパターン2402に至るまでのオブジェクト連携が構築できれば、「i」形式のデータを「k」形式のデータに変換できることとなる。
図27にオブジェクト探索部113が第1のステップにおいて送出するメッセージの例を示す。図27のメッセージにおいて“MATRIX NAME”、“FmtTranslate”は、構築される連携の名称および連携のタイプを表すものであり、プロトコル、オントロジー、コンテンツ記述言語等、モジュール間の連携を規定するものの総称である。ENTRY ITEMの"Action" "request"は、このメッセージが、連携の始点と終点を提示すると同時に始点のファイルフォーマットから終点のファイルフォーマットへの変換を求めることを意味する。ENTRY ITEMの"Sender" "ui serv"は、このメッセージの送信者を示す。ENTRY ITEMの"RequestID" "dumy1"は、モジュール間の連携のconversation−idを示すものである。ENTRY ITEMの"OriginalMessageType" "「i」"は、始点となるファイルフォーマットが拡張子「i」を持つファイルであることを示すと同時に、始点となるアウトプットパターンが「i」であることを示している。ENTRY ITEMの"TargetMessageType" "「k」"は、終点となるファイルフォーマットが拡張子「k」を持つファイルであることを示すと同時に、終点となるアウトプットパターンが「k」であることを示している。ENTRY ITEMの"MessageKey"は、対象となる「i」ファイルの所在を示すもので、この例ではuriで示されたui.phxというモジュールに936244885600というキーを渡すことででデータが取得できることを示している。本実施形態において図27に示したメッセージを受理するオブジェクト(後述のimagearbiter.phx)は、"Action","Request"という部分に反応することが可能な入力パターンを持っており、また"Original MessageType","TargetMessageType"といったタグで示された内容に対する操作を持っている。
第2ステップとして、この例では、後方向探索方式により探索するのでオブジェクト探索部113は、入力メッセージパターンをワイルドカードとし、出力メッセージパターンを終点となるオブジェクトの入力メッセージパターン2402、つまり「k」として探索キーを設定し、探索を実行する。ここでワイルドカードとは任意のメッセージパターンを指す。この様子を概念的に示したものが図25(b)である。
図28にオブジェクト探索部113が第2のステップにおいて送出するメッセージの例を示す。図28において、ENTRY ITEMの"Action" "in-request"は、このメッセージが、パターンに包含されるモジュールに対して返答を要求していることを意味している。ENTRY ITEMの"Sender"でuri形式でしめされているimagearbiter.phxは、このメッセージの送信者を示す。imagearbiter.phxは、FmtTranslate"をファイル変換を行うための連鎖を構築するための契約ネットをコントロールする仲介者に相当する。ENTRY ITEMの"RequestID" "dumy1"は、モジュール間の連携のconversation-idであり、図27のメッセージに続く一連のメッセージであることを示すものである。ENTRY ITEMの"OriginalMessageType"はアスタリスク "*"で示されている。アスタリスク"*"はワイルドカードとして利用しており、「任意のファイルフォーマット形式」を意味している。すなわち、始点となるファイルフォーマットの拡張子がなんであってもよいことを意味している。ENTRY ITEMの"TargetMessageType" "「k」"は、終点となるファイルフォーマットが拡張子「k」を持つファイルであることを示すと同時に、終点となるアウトプットパターンが「k」であることを示している。ENTRY ITEMの"MessageKey"は、対象となる「i」ファイルの所在を示すもので、図27に示されたファイルの所在をそのまま記述している。本実施形態において図28で示したメッセージを受理するオブジェクト(後述の「j」2「k」.phx)は"Action","in-request"という部分に反応することが可能な入力パターンを持っている。また図28で"Original MessageType"がワイルドカードであることは、受理する側のオブジェクトの入力パターンがなにか特定のもの(例えば本実施形態の「j」2「k」.phxの場合は「j」)であっても、「j」がワイルドカードとしての"*"に包含されるため受理可能となることを示している。
第3ステップとしてオブジェクト探索部113は、第2ステップで問い合わせたメッセージに反応して返される回答を受け付ける。この回答を得れば、終点となるオブジェクトの入力メッセージパターン2402につながるオブジェクト連携が得られたこととなる。この様子を概念的に示したものが図25(c)である。このように、探索されたオブジェクト2403から終点となるオブジェクトの入力メッセージパターン2402への連携が行なわれる。
図29にオブジェクト探索部113が第3のステップにおいて受信したメッセージの例を示す。図29において、ENTRY ITEMの"Action" "bid"は、このメッセージが、in-requestに対する回答であり、in-requestのパターンに包含されるインプットパターンを持っていることを示している。ENTRY ITEMの"Sender"でuri形式でしめされている「j」2「k」.phxは、このメッセージの送信者を示す。「j」2「k」.phxは、FmtTranslate"をファイル変換を行うための連鎖を構築するための契約ネットを構成するサービスを提供する。、以下に示すように「j」形式から「k」形式へのファイルフォーマットの変換を行うことが可能なモジュールである。ENTRY ITEMの"RequestID" "dumy1"は、モジュール間の連携のconversation-idであり、図27、図28のメッセージに続く一連のメッセージであることを示すものである。ENTRY ITEMの"OriginalMessageType"が「j」であるのは、「j」2「k」.phxというモジュールが「j」ファイルを変換元とすることを示すと同時に、インプットパターンとして「j」という型を持っていることを示している。この「j」という型は図28のアスタリスク"*"で示された型に包含されている。ENTRY ITEMの"TargetMessageType" "「k」"は、終点となるファイルフォーマットが拡張子「k」を持つファイルであることを示すと同時に、終点となるアウトプットパターンが「k」であることを示している。ENTRY ITEMの"MessageKey"は、図28と同様であるが、出力対象となる「k」ファイルの出力先を示すもので、出力されたファイルはこのキーを用いて取得することができる。ENTRY ITEMの"PathHistory"は、連鎖の構築が一段なされたことを示している。
次に、オブジェクト連携が未だ始点のオブジェクト2401の出力メッセージパターンまで至っていない場合は、さらに連携するオブジェクトを探索すべく第2のステップと第3のステップを繰り返す。ここでは第2のステップの問い合わせ処理をもう一度実行する。オブジェクト2403の入力メッセージパターンは「j」形式であるので、入力メッセージパターンをワイルドカードとし、「j」形式を出力メッセージパターンとして探索キーを設定し、探索を実行する。この様子を概念的に示したものが図25(d)である。
図30にオブジェクト探索部113が繰り返しの第2のステップにおいて送出するメッセージの例を示す。図30において、メッセージの"Action"は図27と同様in-requestであり、メッセージの送信者はimagearbiter.phxである。MessageKeyとPathHistoryは図29のものが用いられており、RequestIDは図27以下同じものが用いられている。
次に、オブジェクト探索部113は、繰り返しの第2ステップで問い合わせたメッセージに反応して返される回答を受け付ける。この回答を得れば、終点となるオブジェクト2402から始点のオブジェクト2401に向かう2つの段階のオブジェクト連携が得られたこととなる。この様子を概念的に示したものが図25(e)である。ここでは、得られた回答の中に入力メッセージパターンが「i」形式であるオブジェクト2404が存在したとする。このオブジェクト2404を選ぶ。このように、後方向探索方式により、終点となるオブジェクトの入力メッセージパターン2402からオブジェクト2403、さらにオブジェクト2404への連携が行なわれ、始点となるオブジェクトの出力メッセージパターン2401に至るオブジェクト連携が探索できる。つまり、始点となるオブジェクト2401の出力メッセージパターン「i」形式からオブジェクト2404、2403の連携を経て、終点となるオブジェクト2402の入力メッセージ「k」形式にファイルが変換されるというオブジェクト連携が構築できる。
図31にオブジェクト探索部113が繰り返しの第3のステップにおいて受信したメッセージの例を示す。図31において、メッセージの"Action"は図29と同様bidで、メッセージの送信者は変換サービスを提供することができるwin2s.phxになっている。PathHistoryは図29に追加される形で示している。"OriginMessageType"がアスタリスク"*"であるのは、任意のファイルを「j」形式に変換する能力をwin2「j」.phxが持っていることを示している。図29および図31に示されたbidによって、任意のファイル形式が「k」ファイルに変換できるという回答が得られたことになり、図27のrequestであるbmpファイルから「k」ファイルへの変換が可能であるという回答が得られたことになる。本実施形態9では図28に続くメッセージのコントロールを行っているimagearbiter.phxが図27以下のメッセージをモニターすることでチェックした。
次に、第5のステップとして、得られたオブジェクト連携を用いて実際にファイルを変換する。図32は、図31までに得られた結果を用いたファイル変換依頼のメッセージの例を示す図である。図32ではメッセージの"Action"はin-serveとなっており、これはファイル変換サービスの実施を要求するものである。メッセージの送信者はimagearbiter.phxであり、契約ネットでいうところの応札者は、ITEM"Contract"によってwin2「j」.phxを指定している。
次に、第6のステップとして、依頼したオブジェクト連携の結果を受け取る。図33は、図32の結果を返すメッセージの例を示す図である。ここでは、さらに、図34に示すように、図33の結果を受けて再度、仲介オブジェクトとなるimgearbiter.phxがファイル変換を依頼している。
図32のActionは再びin-serveであり、OriginalMessageTypeとTargetMessageTypeが今度は「j」と「k」にそれぞれ書き換えられている。またサービスの実行者は図33のPathHistoryを逆にたどることにより、「j」2「k」が選ばれており、選ばれたことはContractの項で示している。
図33のActionはin-informであり、これはファイル変換が無事終了したことを通知するものである。図33では図32に比べPathHistoryが一段短くなっている。これはwin2「j」によって処理が行われたためである。変換されたファイルを取得するためにMessageKeyの部分は書き換えられている。
図34のActionは再びin-serveであり、OriginalMessageTypeとTargetMessageTypeが今度は「j」と「k」にそれぞれ書き換えられている。またサービスの実行者は図32のPathHistoryを逆にたどることにより、「j」2「k」が選ばれており、選ばれたことはContractの項で示している
そして図35は、図34と同様、ファイル変換が無事終了したことを示すものである。図35が図34と異なる点はPathHistoryにもう項が残っていないことである。このことによっても図27によって誘起された一連の処理が終了したことが示されている。TargetMessageTypeが「k」であることは、最終的なファイルフォーマットが「k」であることを示すと同時に、インプットパターンとして「k」を持ち、TargetMessageTypeが「k」というパターンとなることを待っているモジュールに処理が接続可能となったことを意味している。本実施形態では図27のメッセージを送ったui servがインプットパターンとしてTargetMessageTypeの「k」というパターンに反応して「k」ファイルを表示する。
以上の処理ステップにより、本実施形態9のオブジェクト連携装置は、オブジェクト連携を構築したい始点となるオブジェクトと終点となるオブジェクトを指定し、両者の間をつなぐオブジェクトの連携を探索して連携関係を形成することができる。
上記処理においても分かるように、本実施形態のオブジェクト連携装置では、オブジェクトの連携関係探索において、入力メッセージパターンを特定して探索キーとして与え、出力メッセージパターンをワイルドカードとして連携する範囲を緩和しつつ(範囲を拡げつつ)探索を実行している。始点から終点に向けて範囲を絞って行くやり方に比べ、始点から始めて範囲を拡げつつ、終点を包含する写像が得られたときに始点から終点に至るオブジェクト連携を発見するという手法を用いるためより柔軟性のあるオブジェクト連携の探索法が実現できる。
(実施形態10)
本発明のオブジェクト連携装置は、上記に説明した構成を実現する処理ステップを記述したプログラムをコンピュータ読み取り可能な記録媒体に記録して提供することにより、各種コンピュータを用いて構築することができる。本発明のオブジェクト連携装置を実現する処理ステップを備えたプログラムを記録した記録媒体は、図36に図示した記録媒体の例に示すように、CD−ROM3602やフレキシブルディスク3603等の可搬型記録媒体3601だけでなく、ネットワーク上にある記録装置内の記録媒体3600や、コンピュータのハードディスクやRAM等の記録媒体3605のいずれであっても良く、プログラム実行時には、プログラムはコンピュータ3604上にローディングされ、主メモリ上で実行される。
さらに、ソースプログラムをコンパイルしたもののみならず、いわゆるネットワークを介してクライアントコンピュータに中間言語形式のアプレットを送信し、クライアントコンピュータ上でインタープリタ実行して動作する構成であっても良い。