JP4266507B2 - オブジェクト連携モニタシステム - Google Patents
オブジェクト連携モニタシステム Download PDFInfo
- Publication number
- JP4266507B2 JP4266507B2 JP2000289299A JP2000289299A JP4266507B2 JP 4266507 B2 JP4266507 B2 JP 4266507B2 JP 2000289299 A JP2000289299 A JP 2000289299A JP 2000289299 A JP2000289299 A JP 2000289299A JP 4266507 B2 JP4266507 B2 JP 4266507B2
- Authority
- JP
- Japan
- Prior art keywords
- message
- error
- field
- cooperation
- error processing
- 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
- Debugging And Monitoring (AREA)
- Multi Processors (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、コンピュータ群もしくはオブジェクト群の対話・協調などの連携処理を実施するオブジェクト連携システムに関し、分散型計算機環境などのオブジェクト指向環境において複数のプロセスが作りだされ、コンピュータフィールドを通じて、環境の変化に柔軟に対応し、漸進的に変化するシステム構築のためのオブジェクト連携システムに関する。特に、分散したオブジェクト間の通信や対話、協調など連携処理を行う際のエラー処理仲介に関するものであり、特に共通のフィールドとして定義されるような通信路を流れるメッセージとして種々の情報にオブジェクトとして個々のコンピュータシステムあるいはコンピュータシステム内で動作する個々のアプリケーションプログラムが独自に反応する形で処理が行われるとき、システム全体としてエラー処理をハンドリングすることに関する。
【０００２】
【従来の技術】
近年、フィールド化が進み、フィールド上に分散した複数のオブジェクトが互いに連携して処理を行うシステムが増えている。このような複数のオブジェクトが連携して処理を行うための技法として、オブジェクト指向型プログラミングやコンポーネント技術などの研究がなされている。
【０００３】
オブジェクト指向型プログラミングの一例として、オブジェクト指向技術の標準化と普及を目指して設立された業界団体ＯＭＧ（Object Management Group）によって定められた分散オブジェクト運用のための共通仕様ＣＯＲＢＡ（The Common Object Request Broker : Architecture and Specification）がある。
【０００４】
図１１に、ＣＯＲＢＡに基づいたクライアント／サーバシステムにおけるオブジェクト連携の例を示す。このシステムは、クライアントアプリケーションとサーバ・アプリケーションとが連携することにより、つまりオブジェクト連携により一連の処理を行うものである。
【０００５】
アプリケーション開発者は、クライアントおよびサーバそれぞれが提供するサービスのインターフェースをＩＤＬ（Interface Definition Language）で記述する。インターフェースとして定義する内容は、オブジェクトに依頼できるオペレーション群であり、各々のオペレーションは、オペレーション名、パラメタの定義、戻り値の定義、エラー発生時の例外処理、付加情報などが定義される。
【０００６】
ＩＤＬで定義された内容を専用のコンパイラでコンパイルすることにより、クライアント用のスタブとサーバ用のスケルトンが生成される。スタブとは、クライアントアプリケーションにＩＤＬで定義されたオペレーション群へのアクセスを提供するルーチン群である。クライアントアプリケーションは、スタブで提供されるルーチンを呼び出すことにより、各種オペレーションが起動される。スケルトンは、サーバ・アプリケーションが提供するメソッドルーチンヘのディスパッチングルーチンを提供する。
【０００７】
スタブおよびスケルトンは、対応するクライアントアプリケーションあるいはサーバ・アプリケーションが使用するプログラミング言語で生成される。たとえば、使用されるプログラミング言語がＣ言語であったとすると、スタブはＣ言語の関数群として生成され、クライアントアプリケーションは、実行したいオペレーションに対応する関数を呼び出すことにより、スタブ、ＯＲＢランタイム、スケルトンを経由してサーバ・アプリケーションの該当ルーチンが呼び出され、所定の処理が実行されたあと、その処理結果が呼び出し元のクライアントアプリケーションに返される。
【０００８】
【発明が解決しようとする課題】
従来のＣＯＲＢＡなどの技術を用いてオブジェクト間の連携処理を構築することは容易になってきており、エラー処理についてもオブジェクト内に記述したエラー発生時の例外処理として取り扱われている。
【０００９】
しかし、実際にこのようなオブジェクト間の連携処理におけるエラー処理を上記のＣＯＲＢＡを用いて実現するためには、以下の問題がある。
【００１０】
ＣＯＲＢＡ技術そのものの深い理解が必要となり、さらに、ＣＯＲＢＡ仕様に応じたオブジェクトの設計およびＩＤＬによる定義づけが必要となってしまうという問題があった。つまり、ＣＯＲＢＡの利用に関する技術内容・情報をシステム構築者が熟知する必要がある。これは一般には困難なものである。
【００１１】
また、システム構築者は、個々のオブジェクトの関係を強く意識しつつシステムを構築する必要があるという問題がある。つまり、それぞれオブジェクトがどういう処理を行うものであるか、その処理を行うために必要となる受け渡しのパラメタはどのようなものであるかという点などを厳密に定義しておかなければならない。
【００１２】
このように、従来のＣＯＲＢＡを用いたオブジェクト間の連携処理システムの構築によれば、オブジェクト間のインタフェースが共通化されることにより、オブジェクトの独立性が高まったとは言え、あくまでもオブジェクトとオブジェクトとの間には固定的な関係が存在することが前提となっている。このことはシステム全体にわたって統一されたシステム動作に関するトップダウンの設計がなければエラー処理自体を設計することができないことを意味している。
【００１３】
本発明は上記問題点を解決し、フィールドに接続されたオブジェクトとオブジェクトの連携をメッセージを介して行うオブジェクト連携システムにおいて、エラー処理仲介を行うオブジェクトを導入し、エラー処理の自由度を高め、柔軟なシステム構築を可能とするオブジェクト連携に関するシステムを提供することを目的とする。
【００１４】
【課題を解決するための手段】
上記目的を達成するため、本発明のオブジェクト連携モニタシステムは、フィールド上で他のオブジェクトとメッセージをやり取りするメッセージ送受信部と、メッセージの要素とその要素に対するルールとの組を備えたルール判定部と、前記組に従い、受信メッセージにマッチングしたルール内容であるアクションを実行するアクション実行部を備えたオブジェクト間の連携を管理するシステムであって、前記メッセージ送受信部と、前記ルール判定部と、前記アクション実行部と、前記メッセージ送受信部を介して前記フィールド上を流れるメッセージをモニタし、あるメッセージに対して予定される正常なオブジェクト連携が実行されているか否かを検知するオブジェクト連携検知部と、前記オブジェクト連携検知部が正常なオブジェクト連携が実行されていないと検知した場合に対応するエラーメッセージを出力してエラー処理の仲介を実行するエラー処理仲介部を備えたエラー処理仲介オブジェクトを備えたことを特徴とする。
【００１５】
上記構成により、オブジェクトは、エラー処理仲介オブジェクトを意識することなく、通常の処理に従ってフィールドリアクターモデルに従って動作し、エラー処理仲介オブジェクトが自律的にエラーを検知し、フィールドリアクターモデルに従ったエラー処理仲介を実行してオブジェクトにエラー処理を実行させることができ、柔軟かつ動的にオブジェクト連携のエラー処理を構築することが可能となる。
【００１６】
ここで、前記オブジェクト連携検知部が、オブジェクトの障害を検知するオブジェクト障害検知部を備え、前記メッセージ送受信部において前記オブジェクト障害検知部により障害が検知されているオブジェクトが応答すべきメッセージがモニタされた場合、前記エラー処理仲介部が対応するエラー処理仲介を実行することが好ましい。
【００１７】
上記構成により、あらかじめ、障害の発生しているオブジェクトを検知しておくことにより、該障害オブジェクトがフィールドリアクターモデルに従って反応すべきメッセージに対する不具合発生を予見することができ、速やかにエラー処理仲介実行を開始することができる。
【００１８】
また、前記オブジェクト連携検知部が、オブジェクトの障害を検知するオブジェクト障害検知部を備え、前記オブジェクト障害検知部が、前記メッセージ送受信部においてモニタされたメッセージに応答中のオブジェクトにおける障害を検知した場合、前記エラー処理仲介部が対応するエラー処理仲介を実行することが好ましい。
【００１９】
上記構成により、フィールドリアクターモデルに従ってメッセージに反応してアクション実行中のオブジェクトに発生した障害を検知することができ、アクションが未完了となる不具合発生を予見することができ、速やかにエラー処理仲介実行を開始することができる。
【００２０】
また、正常なオブジェクト連携処理の間に、エラー処理を挿入・追加するため、各オブジェクトは、前記ルール判定部に従って前記フィールドからメッセージを受信した場合に、該メッセージのメッセージ要素に反応して受信したことを示す受理メッセージを前記メッセージ送受信部により送信し、前記エラー処理仲介オブジェクトは、前記ルール判定部において前記受理メッセージのメッセージ要素を組の要素として持ち、該メッセージ要素を持つ受理メッセージが前記メッセージ送受信部から一定時間内に得られない場合、前記エラー処理仲介部が対応するエラーメッセージを前記メッセージ送受信部を介して出力し、前記メッセージを送信したオブジェクトは、前記ルール判定部において前記エラーメッセージのメッセージ要素を組の要素として持ち、前記エラーメッセージのメッセージ要素に反応してエラーメッセージを取り込み、用意されているエラー処理を実行し、正常なオブジェクト連携処理の間に、エラー処理を挿入・追加することが好ましい。
【００２１】
上記構成により、オブジェクトはフィールドリアクターモデルに従ったオブジェクト連携処理を実行する環境に対して、外部的にエラー処理仲介を挿入・追加することができ、エラー処理を高い自由度で柔軟に構築することが可能となる。
【００２２】
また、上記目的を達成するため、本発明のオブジェクト連携モニタ方法は、フィールド上のオブジェクトのメッセージを介した連携処理の間に、エラー処理を挿入・追加する方法であって、フィールド上のオブジェクトのメッセージを介した連携処理の間に、エラー処理を挿入・追加する方法であって、フィールド上で他のオブジェクトとメッセージをやり取りするメッセージ送受信部と、メッセージ要素に対する反応であるアクション内容を管理するルール判定部と、前記ルール判定部に従い、受信メッセージの持つメッセージ要素にマッチングしたアクション内容に従って処理を実行するアクション実行部を備えたオブジェクトがメッセージを介した連携処理を実行し、フィールド上を流れるメッセージをモニタし、あるメッセージに対して予定される正常なオブジェクト連携が実行されているか否かを検知し、正常なオブジェクト連携が実行されていないと検知した場合に前記メッセージを送信したオブジェクトに対するエラー処理仲介を実行し、前記メッセージを送信したオブジェクトが前記エラー処理仲介を受け、用意されているエラー処理を実行し、正常なオブジェクト連携処理の間にエラー処理を挿入・追加することを特徴とする。
【００２３】
上記方法を用いれば、フィールドリアクターモデルに従ったオブジェクト連携処理を実行する環境に対して、外部的にエラー処理仲介を挿入・追加することができ、エラー処理を高い自由度で柔軟に構築することが可能となる。
【００２４】
本発明のエラー処理仲介オブジェクトを用いたオブジェクト連携モニタシステムを実現する処理プログラムを記録したコンピュータ読み取り可能な記録媒体を提供すれば、コンピュータ装置を利用して本発明のオブジェクト連携モニタシステムを構築することができる。
【００２５】
【発明の実施の形態】
以下、本発明のオブジェクト連携モニタシステムの実施形態について、図面を参照しながら説明する。
【００２６】
（実施形態１）
本発明のエラー処理仲介オブジェクトを設けたオブジェクト連携モニタシステムは、オブジェクトの障害によりオブジェクト間の正常なオブジェクト連携が実現できない場合、オブジェクトにおいて必要なエラー処理が実行されるように仲介し、オブジェクト同士の連携に直接含まれていないエラー処理を、エラー処理仲介オブジェクトの働きにより、挿入・追加するものである。ここで、エラー処理仲介オブジェクトは、メッセージ送受信部と、メッセージの要素とその要素に対するルールとの組を備えたルール判定部と、前記組に従い、受信メッセージにマッチングしたルール内容であるアクションを実行するアクション実行部に加え、メッセージ送受信部によりフィールド上を流れるメッセージをモニタし、あるメッセージに対して予定される正常なオブジェクト連携が実行されているか否かを検知するオブジェクト連携検知部と、前記オブジェクト連携検知部が正常なオブジェクト連携が実行されていないと検知した場合に対応するエラー処理仲介を実行するエラー処理仲介部を備えたものである。
【００２７】
以下、図面を参照しつつ、本発明のエラー処理仲介オブジェクトを設けたオブジェクト連携モニタシステムの実施形態を説明する。
【００２８】
ここでは、本発明のオブジェクト連携モニタシステムの一実施形態として、フィールドリアクターモデルにより構成した例を挙げる。フィールドリアクターモデルとは、フィールドを流れるメッセージのメッセージ構造と当該メッセージ構造に対応するアクションの関係によってオブジェクト同士を結び付けることによりオブジェクト同士の連携を構築し、当該メッセージとアクションの関係の記述を柔軟かつ動的に更新することによりオブジェクト連携関係を柔軟かつ動的に構築するものである。つまり、本発明で言う、メッセージの要素とその要素に対するルールとの組の例として、メッセージ構造とそのメッセージ構造に対応付けられるアクションの関係を反応テーブルという形で用意した例を説明する。このように実施形態１は、フィールドを流れるメッセージの要素とその要素に対するルールとの組によるオブジェクト同士の連携の一例として、メッセージ構造とアクションの関係を記述した反応テーブルを用いたオブジェクト同士の連携という形で説明する。
【００２９】
以下、本実施形態１ではオブジェクト連携モニタシステムの概念を説明し、その一実施形態として、フィールドリアクターモデルを前提とした構成を中心に説明する。
【００３０】
以下、オブジェクトの連携処理に対するエラー処理仲介を実行する本発明のオブジェクト連携モニタシステムを３つのパートに分けて順を追って説明する。
【００３１】
第１のパートでは、実施形態１としてオブジェクト連携モニタシステムが用いるフィールドリアクターモデルの動作原理、フィールドリアクターモデル用いた場合のオブジェクト連携システムの構成を説明する。
【００３２】
第２のパートでは、エラー処理仲介オブジェクトを用いたオブジェクト連携モニタシステムによるエラー処理仲介の概念を説明する。
【００３３】
第３のパートでは、フィールドリアクターモデル用いたオブジェクト連携システムにおいてエラー処理仲介オブジェクトを設けたオブジェクト連携モニタシステムの構成とエラー仲介動作の一例について説明する。
【００３４】
まず、第１のパートとして、フィールドリアクターモデルの動作原理、メッセージを用いたオブジェクト同士の連携の概念を説明する。
【００３５】
本発明のオブジェクト連携モニタシステムがエラー処理仲介を行う対象であるフィールドリアクターモデルにより構築されたオブジェクト連携システムは、オブジェクト間でやり取りされるメッセージの要素とそのメッセージ要素に対するアクションとの関係づけを用いている。
【００３６】
以下、共通のフィールドとして定義される通信路を流れるメッセージに対して、オブジェクトとしての個々のコンピュータシステムあるいはコンピュータシステム内で動作する個々のアプリケーションプログラムが反応する形で処理を実行するので、メッセージとアクションとの対応づけを変更・調整することによりシステム全体の動作も柔軟に変更することができる。つまり、互いの内部状態や内部関数に依存しあうような密な関係とはしないで、連携するオブジェクトの緩やかな関係を規定したオブジェクト間の連携によって機能を動的に構成することができる。
【００３７】
図１は、オブジェクト間の緩やかな連携を模式的に示した図である。
【００３８】
図１において２０１はオブジェクトＡ，２０２はオブジェクトＢであり、それぞれメッセージを送受信する主体であるオブジェクトである。Ｍ１はメッセージであり、ａ１はオブジェクトＡ（２０１）中に規定されたアクション、ａ２はオブジェクトＢ（２０２）中に規定されたアクションを示す。なお、図中の矢印は、起点がオブジェクトのときメッセージの送出を、終点がオブジェクトのときメッセージの受信を示している。またそれぞれのオブジェクトは内部状態としてのアクションをそれぞれ独自に持っているとする。
【００３９】
図１において、オブジェクトＡ（２０１）とオブジェクトＢ（２０２）の連携は、メッセージＭ１を介して行われている。オブジェクトＡ（２０１）は、オブジェクトＢ（２０２）についてもオブジェクトＢ（２０２）の持つ内部関数についても基本的には関知せずにメッセージを送出する。また、オブジェクトＢ（２０２）自体を特定してメッセージを送出する必要もなく、オブジェクトＡ（２０１）は自己の状態、処理内容に基づいてメッセージＭ１を送出する。オブジェクトＢ（２０２）は通信路上を流れるメッセージをモニタしており、メッセージＭ１を検知し、Ｍ１がオブジェクトＢにとって有為であるとき、反応してアクションａ２を起動する。このようにオブジェクトＡとオブジェクトＢとは有為な連携を取り得るが、それはオブジェクトＡ（２０１）とオブジェクトＢ（２０２）の直接の結び付きによるものではなく、メッセージＭ１とオブジェクトＢ（２０２）のアクションａ２とが結び付けられている帰結といえる。逆にメッセージがＭ１とは異なるものであれば、オブジェクトＢ（２０２）は当該メッセージがＭ１と同様の受理可能範囲にあるかあるいは他に当該メッセージと結び付けられているアクションがない限り反応しないこととなる。このようにオブジェクト間の連携が緩やかにメッセージを介して行われることにより、オブジェクト間の連携の自由度が増すこととなる。つまり、従来のコンピュータネットワーク通信のように通信相手のアドレスおよび処理依頼内容を特定する必要がなく、ネットワーク上に自らの状態、処理結果などを表わすメッセージを流し、ネットワークをモニタしている各端末がそのメッセージを検知し、対応するアクションが規定されていれば自律的に反応を起こすものである。
【００４０】
フィールドとなる通信路は単にＬＡＮなどの物理的ネットワークだけではなく無線・音声・光などの共通に受信できる媒体を介在するものであれば特に限定する必要はない。また、共通に呼び出し可能なメモリ等の記録媒体であってもかまわない。さらに通信路のポートアドレスなどにより仮想的な存在であってもかまわない。
【００４１】
次に、オブジェクト連携システムの構成例を示す。図２は、オブジェクト連携システムの概略構成例を示す図である。１００はオブジェクトを表わしており、フィールド上に送信されるメッセージを取り込むメッセージ送受信部１０と、メッセージの構造とそのメッセージ構造に対応づけられたアクションを記述した反応テーブル２１を格納した反応テーブル記憶部２０と、反応テーブル２１に従ってアクションを実行するアクション実行部３０を備えている。４００はフィールドである。
【００４２】
メッセージ生成部３１は、アクション実行部３０による処理内容の実行の一環としてメッセージを生成する部分である。
【００４３】
メッセージがフィールド４００からメッセージ送受信部１０を介して受信されると、反応テーブル２１に記述された当該メッセージ構造に対応するアクション内容が起動される。このように、他のオブジェクトが発したメッセージを介してオブジェクトが連携することとなる。
【００４４】
なお、メッセージ・アクション反応テーブル２０には、メッセージ構造とメッセージタグの組み合わせが与えられている。例えば、図３に記載した入力メッセージ構造がメッセージ・アクション反応テーブル２０に記載されている。
【００４５】
図３に示した入力メッセージ構造を持つメッセージがフィールド４００から受信されるとメッセージ・アクション反応テーブル２０の記述に従い、入力メッセージパターンマッチングが成立し、対応するアクションが起動される。このように、他のオブジェクトが発したメッセージを介してオブジェクトが連携することとなる。
【００４６】
フィールドリアクターモデルとは、上記のように、メッセージ構造を用いたパターンマッチングによるメッセージとアクションの反応関係により、受信メッセージのメッセージ構造に対して発火（反応）して対応するアクションを実行し、メッセージ−アクションの連携動作によりオブジェクト同士が連携する仕組みである。フィールドリアクターモデルでは、共通のフィールドとして定義されるような通信路を流れるメッセージに対して、オブジェクトとしての個々のコンピュータシステムあるいはコンピュータシステム内で動作する個々のアプリケーションプログラムが反応する形で処理を実行するので、メッセージとアクションとの反応関係を変更・調整することによりシステム全体の動作も柔軟に変更することができる。つまり、互いの内部状態や内部関数に依存しあうような密な関係とはしないで、連携するオブジェクトの緩やかな関係を規定したオブジェクト間の連携によって機能を動的に構成することができる。
【００４７】
次に、第２のパートとして、エラー処理仲介オブジェクトを用いたオブジェクト連携モニタシステムによる仲介処理の概念を説明する。
【００４８】
上記に見たように、フィールドリアクターモデルを用いてオブジェクト連携システムを構築している場合、以下の特徴がある。
【００４９】
（１）オブジェクト間でやり取りされるメッセージは、共有もしくはブロードキャストされている。
【００５０】
（２）メッセージを受信するオブジェクトはそれぞれ独立に、反応し得るメッセージのパターンと反応としてのアクションを持っている。
【００５１】
（３）メッセージを送信もしくは受信するオブジェクトにおいて、メッセージとアクションとの関係は分離されている。このことにより送信側と受信側との関係もまた分離されている。
【００５２】
メッセージとアクションとが分離されているという性質を利用することによってオブジェクト間にエラー処理仲介の挿入・追加という処理を行い、当該エラー処理仲介の挿入・追加により、本来エラー処理を持っていないオブジェクト間の連携において外部的にエラー処理を仲介し、本来のオブジェクト連携処理の流れとは独立なエラー処理動作の実行を実現するものである。エラー処理に対して高い自由度と柔軟性を持たせることが可能となる。
【００５３】
図４は、本発明のオブジェクト連携モニタシステムの動作を模式的に示した図である。１００ａ〜１００ｃは図２に示した構成を持つオブジェクト、２００はエラー処理仲介オブジェクトである。エラー処理仲介オブジェクトの構成例は後述するのでここでは示していない。４００はフィールドであり、メッセージ交換の場として利用されている。各オブジェクトは上記に示したように、メッセージ構造のマッチングによりメッセージアクション反応テーブルに従って連携している。エラー処理仲介オブジェクト２００は、フィールド４００に接続し、他のオブジェクト１００ａ〜１００ｃ間でやり取りされているメッセージをモニタする。例えば、入力メッセージパターンとして、依頼メッセージが共通的に持つメッセージパターンをメッセージアクション反応テーブル２０に持っておけば、フィールド上を流れる依頼メッセージにすべて反応して取り込むことができる。また、個別にモニタを予定するメッセージのメッセージパターンをメッセージアクション反応テーブル２０に保持しておくことでも良い。
【００５４】
オブジェクト１００ａ〜１００ｃ同士はこのようにメッセージを介して連携するが、エラー処理仲介オブジェクト２００は、このメッセージアクション関係に基づくオブジェクト連携が正常に実行されているか否かを検知し、正常なオブジェクト連携が実行されていないと検知した場合には、対応するエラーメッセージを出力するというエラー処理の仲介を実行する。例えば、オブジェクト１００ａが依頼メッセージを出力し、当該メッセージをオブジェクトｂとオブジェクトｃが受信したとする。当該メッセージのメッセージ構造が、オブジェクトｂのメッセージアクション反応テーブルの入力メッセージ構造にマッチングした場合、オブジェクトｂが対応するアクションを実行することによりオブジェクトａとオブジェクトｂ間のオブジェクトの連携を実現する。ここで、エラー処理仲介オブジェクト２００による正常なオブジェクト連携が実行の有無を検知する方法の一つとして、以下の処理を実行する。オブジェクト１００ｂは取り込んだメッセージ構造によりマッチングが成立した場合、即座にマッチングしたことを示す受理メッセージを出力し、当該受理メッセージ出力後にアクションを実行する。エラー処理仲介オブジェクト２００は、自らの反応テーブルに受理メッセージを入力メッセージ構造とする要素を持つ。この処理によれば、フィールド上に流れたメッセージに対して正常に反応したオブジェクトが存在するか否かを検知することができる。受理メッセージが受信することができなければ、正常なオブジェクト連携が実行されていないことを検知することができる。この場合、エラー処理仲介オブジェクト２００は、対応するエラーメッセージを出力してエラー処理を仲介する。このエラーメッセージも同様にフィールドを流れ、オブジェクト１００ａにより受信され、エラーメッセージのメッセージ構造に対応するアクションであるエラー処理が実行される。このように、本来、オブジェクト１００ａとオブジェクト１００ｂ間のオブジェクト連携処理には含まれていないエラー処理が、エラー処理仲介オブジェクトにより仲介され、挿入・追加される。
【００５５】
また、エラー処理仲介オブジェクト２００は、受理メッセージを受信した場合、どのオブジェクトが反応してアクションを実行中かを検知することができるので、当該オブジェクトにおいてアクション実行中に何らかの障害が発生したことを検知すれば、正常なオブジェクト連携が実行されていないことを検知することができ、この場合も同様に、エラー処理仲介オブジェクト２００は、対応するエラーメッセージを出力してエラー処理を仲介する。
【００５６】
以上が、エラー処理仲介オブジェクトを用いたオブジェクト連携モニタシステムによる仲介処理の概念である。
【００５７】
次に、第３のパートとして、エラー処理仲介オブジェクトを設けたオブジェクト連携モニタシステムの構成を説明する。
【００５８】
図５は、実施形態１のオブジェクト連携モニタシステムの構成例を示す図である。図２のオブジェクト連携モニタシステムの各構成要素と同じ番号のものは同様のものである。１００は図２で示した一般のオブジェクト、２００はエラー処理仲介オブジェクトである。エラー処理仲介オブジェクト２００は、フィールド上に送信されるメッセージを取り込むメッセージ送受信部１０と、メッセージ構造に対する反応であるアクション内容を管理するメッセージ・アクション反応テーブル２０と、メッセージ・アクション反応テーブル２０に従い、受信メッセージの持つメッセージ構造にマッチングしたアクション内容に従って処理を実行するアクション実行部３０、メッセージ生成部３１というフィールドリアクターモデルにおけるオブジェクトが備える構成に加え、オブジェクト連携検知部４０とエラー処理仲介部５０を備えている。
【００５９】
オブジェクト連携検知部４０は、メッセージ送受信部１０によりフィールド４００上を流れるメッセージをモニタし、あるメッセージに対して予定される正常なオブジェクト連携が実行されているか否かを検知する部分である。
【００６０】
エラー処理仲介部５０は、オブジェクト連携検知部４０が正常なオブジェクト連携が実行されていないと検知した場合に対応するエラー処理仲介を実行する部分である。
【００６１】
図６は、オブジェクト連携モニタシステムによるエラー処理仲介の概念を模式的に簡単に説明した図である。図６において、１００ａ〜１００ｃはオブジェクト、２００はエラー処理仲介オブジェクト、４００はフィールドである。なお、メッセージ・アクション反応テーブルを分かりやすいように模式的に記述した。
【００６２】
オブジェクト１００ａにはメッセージ・アクション反応テーブルとして、簡単に３つのメッセージ・アクションの関係を記述している。１つめは依頼メッセージパターン＜request1＞を出力するアクション“Rfunc request1out”を要素に持つもの、２つめは依頼に対する正常な応答メッセージを受けるための入力メッセージパターン＜reply1＞と依頼に関する処理を完了させるアクション“Rfunc end”とを要素に持つもの、３つめはエラーメッセージを受けるための入力メッセージパターン＜error1＞とエラー処理アクション“Rfunc error1exe”とを要素に持つものである。オブジェクト１００ｂにはメッセージ・アクション反応テーブルとして、簡単に３つのメッセージ・アクションの関係を記述している。１つは依頼メッセージ＜request1＞を受けるための入力メッセージパターンと受理メッセージ＜accept1＞を出力するアクション“Rfunc accept1out”を要素に持つもの、２つめは依頼メッセージ＜request1＞を受けるための入力メッセージパターンと依頼内容を実行するアクション“Rfunc request1exe”を要素に持つものである。３つめは依頼内容が終了した場合にその結果を返す応答メッセージ＜reply1＞を出力するアクション“Rfunc reply1out”を要素に持つものである。エラー処理仲介オブジェクト２００には簡単に３つのメッセージ・アクションの関係を記述している。１つめは受理メッセージ＜accept1＞を受けるための入力メッセージパターンと後述する応答メッセージをモニタする処理であるアクション“Rfunc monitor1”を要素に持つもの、２つめは、依頼に対する正常な応答メッセージ＜reply1＞を受けるための入力メッセージパターンと依頼に関する処理を完了させるアクション“Rfunc end”とを要素に持つもの、３つめはアクション（エラー仲介処理）としての出力エラーメッセージ＜error1＞を出力するアクション“Rfunc error1out”を要素に持つものである。
【００６３】
なお、図６のメッセージアクション反応テーブル中、対応するメッセージが−−−となっているアクションは、オブジェクトが自律的に内部処理により実行できるアクションである。
【００６４】
図６に示したオブジェクト連携の動作は以下のようになる。まず、オブジェクト１００ａとオブジェクト１００ｂが正常に連携する場合を説明する。
【００６５】
オブジェクト１００ａは、依頼のため、例えば、以下のメッセージ構造を持つ依頼メッセージ、(request1(search printer))をフィールド４００に流す。
【００６６】
オブジェクト１００ｂとエラー処理仲介オブジェクト２００はそれぞれメッセージ・アクション反応テーブルに従って依頼メッセージパターン＜request1＞に反応してフィールド４００から当該メッセージを取り込む。オブジェクト１００ｂにおいて２つのアクションが実行される。１つのアクションは以下のメッセージ構造を持つ受理メッセージ、(accept1(search printer))をフィールド４００に流すものである。
【００６７】
エラー処理仲介オブジェクト２００は、この受理メッセージのメッセージパターン＜accept1＞を入力メッセージパターンとして持っているのでメッセージ・アクション反応テーブルに従って発火（反応）し、フィールド４００から当該受理メッセージを取り込む。これによりオブジェクト連携検知部４０は、オブジェクト１００ａの発した依頼メッセージに対してオブジェクト１００ｂが正常に反応（オブジェクト連携）したことを検知する。
【００６８】
一方、オブジェクト１００ｂは、依頼メッセージパターン＜request1＞に対してもう一つのアクション、つまり、依頼内容を実行するアクション“＜Rfunc request1exe＞”が起動されている。オブジェクト１００ｂは、依頼内容を実行するアクションが完了すれば、応答メッセージ＜reply1＞をフィールド４００上に流す。
【００６９】
オブジェクト１００ｂとエラー処理仲介オブジェクト２００はそれぞれメッセージ・アクション反応テーブルに従ってフィールド４００から当該応答メッセージ＜reply1＞を取り込む。オブジェクト１００ｂは依頼に対する正常な応答結果を得ることができ、エラー処理仲介オブジェクト２００のオブジェクト連携検知部４０は、依頼に対する正常な応答結果が返され、正常なオブジェクト連携が完了したことを確認できる。
【００７０】
次に、オブジェクト１００ａとオブジェクト１００ｂが正常に連携できなかった場合の動作を参照しつつ説明する。
【００７１】
オブジェクト１００ａは、上記と同様、依頼メッセージをフィールド４００に流し、オブジェクト１００ｂとエラー処理仲介オブジェクト２００はそれぞれメッセージ・アクション反応テーブルに従って依頼メッセージパターン＜request1＞に反応してフィールド４００から当該メッセージを取り込む。この際、オブジェクト１００ｂに何らかの障害が発生しており、正常な動作が実行できない状態であるものとする。例えば、第１の障害ケースとして、当初から障害があり、依頼メッセージに対する受理メッセージをフィールド４００に流すことができないケースを想定する。この場合、エラー処理仲介オブジェクト２００は、所定時間が経過しても受理メッセージ＜accept1＞がフィールド上から得られないこととなり、これによりオブジェクト連携検知部４０は、オブジェクト１００ａの発した依頼メッセージに対してオブジェクト１００ｂが正常に反応（オブジェクト連携）できなかったことを検知する。エラー処理仲介オブジェクト２００は、対応するエラーメッセージを出力するアクション“Rfunc error1out”によりエラーメッセージ＜error1＞をフィールド４００上に出力する。
【００７２】
オブジェクト１００ｂはメッセージ・アクション反応テーブルに従ってフィールド４００から当該エラーメッセージ＜error1＞を取り込む。オブジェクト１００ｂはエラーメッセージパターン＜error1＞に対してエラー処理を実行するアクション“＜Rfunc error1exe＞”を起動し、エラー処理を実行する。このように、オブジェクト１００ａとオブジェクト１００ｂの連携には直接含まれていないエラー処理が、エラー処理仲介オブジェクト２００の働きにより、挿入・追加されることが分かる。
【００７３】
次に、第２の障害ケースとして、当初は障害がなく、依頼メッセージに対して反応し、受理メッセージをフィールド４００に流し、依頼内容に関する処理を実行したが、その過程で障害が発生したケースを想定する。この場合、エラー処理仲介オブジェクト２００のオブジェクト連携検知部４０は、受理メッセージ＜accept1＞をフィールド４００上から得ているので、オブジェクト１００ａの発した依頼メッセージに対してオブジェクト１００ｂが正常に反応（オブジェクト連携）したことを検知している。しかし、所定時間が経過しても、エラー処理仲介オブジェクト２００は、オブジェクト１００ｂから、依頼内容を実行した結果を含む応答メッセージ＜reply1＞をフィールド４００上から得ることができない。これによりオブジェクト連携検知部４０は、オブジェクト１００ａの発した依頼メッセージに対してオブジェクト１００ｂが正常に反応（オブジェクト連携）を完了できなかったことを検知する。エラー処理仲介オブジェクト２００は、対応するエラーメッセージを出力するアクション“Rfunc error1out”によりエラーメッセージ＜error1＞をフィールド４００上に出力する。
【００７４】
オブジェクト１００ｂはメッセージ・アクション反応テーブルに従ってフィールド４００から当該エラーメッセージ＜error1＞を取り込み、対応するエラー処理を実行するアクション“＜Rfunc error1exe＞”を起動し、エラー処理を実行する。この第２の障害ケースにおいても、オブジェクト１００ａとオブジェクト１００ｂの連携には直接含まれていないエラー処理が、エラー処理仲介オブジェクト２００の働きにより、挿入・追加されることが分かる。
【００７５】
図７は、本発明のエラー処理仲介オブジェクトを設けたオブジェクト連携モニタシステムの処理の流れの一例を示したフローチャートである。
【００７６】
エラー処理仲介オブジェクト２００はフィールド４００上を流れる依頼メッセージをモニタする（ステップＳ７０１）。
【００７７】
依頼メッセージがモニタされると（ステップＳ７０１：Ｙ）、その後、ステップＳ７０１でモニタした依頼メッセージに対する受理メッセージを所定時間モニタする（ステップＳ７０２）。
【００７８】
受理メッセージがモニタされると（ステップＳ７０２：Ｙ）、オブジェクト連携検知部４０は、オブジェクト間で正常な連携が実行されていることを検知する（ステップＳ７０３）。
【００７９】
受理メッセージが所定時間内にモニタされない場合（ステップＳ７０２：Ｎ）、依頼メッセージに応答できるオブジェクトが存在せず、オブジェクト間で正常な連携が実行されていないことを検知し、対応するエラーメッセージを出力し（ステップＳ７０４）、ステップＳ７０１に戻る。
【００８０】
受理メッセージがモニタされ、オブジェクト間で正常な連携が行われていることが検知されている場合、依頼メッセージを受けたオブジェクトから依頼内容を実行した結果を含む応答メッセージを所定時間モニタする（ステップＳ７０５）。
【００８１】
応答メッセージがモニタされると（ステップＳ７０５：Ｙ）、オブジェクト連携検知部４０は、オブジェクト間で正常な連携実行が完了したことを検知し（ステップＳ７０６）、ステップＳ７０１に戻る。
【００８２】
応答メッセージが所定時間内にモニタされない場合（ステップＳ７０５：Ｎ）、依頼メッセージを受理したオブジェクトに何らかの障害が発生したため、オブジェクト間で正常な連携が実行されていないことを検知し、対応するエラーメッセージを出力し（ステップＳ７０４）、ステップＳ７０１に戻る。
【００８３】
以上、本発明のエラー処理仲介オブジェクトを設けたオブジェクト連携モニタシステムによれば、オブジェクトの障害によりオブジェクト間の正常なオブジェクト連携が実現できない場合、エラー処理が実行されるように仲介することができ、オブジェクト同士の連携に直接含まれていないエラー処理を、エラー処理仲介オブジェクト２００の働きにより、挿入・追加することができる。
【００８４】
（実施形態２）
実施形態２のエラー処理仲介オブジェクトを設けたオブジェクト連携モニタシステムは、オブジェクト連携検知部が、オブジェクトの障害を検知するオブジェクト障害検知部を備え、オブジェクト障害検知部により障害が検知されているオブジェクトが応答すべきメッセージがモニタされた場合、正常なオブジェクト連携が実行されないことを予見し、エラー処理仲介部が対応するエラー処理仲介を実行するものである。また、当初障害が検知されず、依頼メッセージに反応してアクションを実行中のオブジェクトにおいて障害が発生した場合、オブジェクト障害検知部により当該オブジェクトにおける障害を検知し、エラー処理仲介部が対応するエラー処理仲介を実行するものである。
【００８５】
図８は、実施形態２のオブジェクト連携モニタシステムの構成例を示す図である。図５のオブジェクト連携モニタシステムの各構成要素と同じ番号のものは同様のものである。１００は一般のオブジェクト、２００ｂはエラー処理仲介オブジェクトであり、エラー処理仲介オブジェクト２００は、メッセージ送受信部１０、メッセージ・アクション反応テーブル２０、アクション実行部３０、オブジェクト連携検知部４０ａ、エラー処理仲介部５０を備えている。オブジェクト連携検知部４０ａは、オブジェクト障害検知部４１を備えている。オブジェクト障害検知部４１は、オブジェクトの障害を検知する部分である。オブジェクト連携検知部４０ａは、オブジェクト障害検知部４１を用いて、モニタするオブジェクト１００のうち、どのオブジェクトに障害が発生しているかを検知できる構成になっている。なお、障害検知部４１がオブジェクトに発生した障害を検知する方法は特に限定されず、様々な方法が可能である。例えば、障害検知部４１がメッセージ送受信部１０を介して一定間隔で各オブジェクトとの間で、障害問い合わせメッセージと、障害なしを知らせる応答メッセージとを定期的にやり取りする方法や、ネットワーク管理者からの通知を受ける方法などがある。
【００８６】
このようにオブジェクト連携検知部４０ａがオブジェクト障害検知部４１を備える構成とすれば、当初障害が検知されていないオブジェクト１００が、あるメッセージに反応して対応するアクションを実行している間に何らかの障害が発生してしまった事実を検知することができ、エラー処理仲介部５０に対して対応するエラー処理仲介の実行を指示することができる。
【００８７】
例えば、本発明のエラー処理仲介オブジェクトが介在する場合は、図９に示すような処理が可能となる。オブジェクトＡからオブジェクトＢに対して、メッセージ形式１のメッセージをメッセージ形式２のメッセージとするエンコーディングを依頼した場合のエラー処理の仲介を想定する。まず、オブジェクトＡがメッセージをメッセージ形式１からメッセージ形式２にエンコーディングする依頼が出される。エラー仲介オブジェクトは依頼メッセージを検知する（ステップＳ９０１：Ｙ）。当該依頼を受けたオブジェクトＢにおいて何らかの障害が発生しており、メッセージをメッセージ形式１からメッセージ形式２にエンコーディングすることができないとする。オブジェクトＢからオブジェクトＡに対してエンコーディングができない旨のエラーメッセージが返される。エラー処理仲介オブジェクトが介在しない場合はオブジェクトＡ自身が当該エラーメッセージに対するエラー処理を持っていなければならない。しかし、本発明のエラー処理仲介オブジェクトが介在する場合は、エラー処理仲介オブジェクトもオブジェクトＢからのエラーメッセージを受信しており（ステップＳ９０２：Ｙ）、当該エラーメッセージに対するエラー処理を実行する。例えば、依頼を代行処理できるオブジェクトを探知、つまり、メッセージをメッセージ形式１からメッセージ形式２にエンコーディングすることができるオブジェクトを探知し（ステップＳ９０３）、探知したオブジェクトにエンコーディング処理を代行実行させ（ステップＳ９０４）、エンコーディング処理された結果を受け取り、その結果をオブジェクトＢにまたは依頼元のオブジェクトＡに直接返すというエラー処理を実行する（ステップＳ９０５）。このように本発明のエラー処理仲介オブジェクトが介在する場合は、オブジェクトＡ自身がエラーメッセージに対するエラー処理を持っていない場合でもオブジェクト連携においてエラー処理を仲介・実行することができる。
【００８８】
上記の例では、依頼メッセージのエンコーディングができない旨のエラーメッセージが出力された場合、当該エラーメッセージを受信したエラー処理仲介オブジェクトが適切なエンコーダを探知して依頼メッセージのエンコーディング作業を代替依頼し、エンコーディング結果をエラーメッセージを発したオブジェクトまたは依頼を出したオブジェクトに返すことによりエラー処理を仲介し、代替実行して一連の処理を継続して行くことができる。
【００８９】
上記の構成によれば、実施形態１で示したように、依頼に反応したオブジェクトから流される受理メッセージ＜accept1＞などをフィールド４００上に流れるか否かをモニタすることにより正常なオブジェクト連携の実行の有無を検知する必要はなく、障害検知部４１が障害発生を検知したオブジェクトに対する依頼メッセージをモニタした場合には即座に正常なオブジェクト連携が実行できないことが検知できるので、対応するエラーメッセージ＜error1＞などを遅滞なく出力し、エラー処理を仲介することが可能となる。
【００９０】
また、同様に、オブジェクト連携検知部４０ａがオブジェクト障害検知部４１を備える構成とすれば、オブジェクト障害検知部４１により障害が検知されているオブジェクト１００に対してアクションを実行するように求めるメッセージがフィールド４００上に流れたことをメッセージ送受信部１０のモニタにより検知した場合には、オブジェクト連携が正常に行われない結果となることをあらかじめ予見することができ、エラー処理仲介部５０に対して対応するエラー処理仲介の実行を指示することができる。
【００９１】
この場合、エラー処理仲介オブジェクト２００は、モニタした依頼メッセージに対して本来いずれのオブジェクトが応答すべきであるのかを予め把握しておく必要がある。例えば、エラー処理仲介オブジェクト２００はメッセージアクション反応テーブルにおいて、すべての依頼メッセージに反応する入力メッセージパターンを用意しておき、そのアクションとしてモニタして取り込んだ依頼メッセージに対してどのオブジェクトが反応するべきかをチェックするチェックプログラムを起動することにより反応すべきオブジェクトを把握する。
【００９２】
その他の方法としては、オブジェクト同士でCookieに相当する情報を交換し合う場合において、依頼メッセージ中に含まれる当該Cookieに相当する情報を手掛かりとして反応すべきオブジェクトを把握する方法も可能である。Cookieとは、ワールドワイドウェブ（以下、ＷＷＷと略記する）上でユーザを管理を実現する仕組みを言い、ＷＷＷサーバがユーザを識別する識別文字列情報Cookieを生成し、ＷＷＷサーバとブラウザ双方に格納しておき、２回目のアクセス時にはブラウザから当該CookieをＨＴＴＰで送信し、サーバ側に格納されているCookieと照合してユーザを特定する仕組みである。つまり、あるオブジェクトとあるオブジェクトとの１回目のアクセスにおいて、オブジェクトを識別するCookieに相当する識別文字列情報を交換して格納し合い、２回目のアクセス時には当該Cookieに相当する識別文字列情報により相手を特定する仕組みを用いた場合、エラー処理仲介オブジェクトがオブジェクト間で用いられるすべてのCookieに相当する情報を取り込んで管理し、フィールド上を流れるメッセージに含まれるCookieに相当する情報をチェックし、障害が発生しているオブジェクトが連携の一方になっているメッセージと判断すれば、即座に正常なオブジェクト連携が実行できないことを検知できる。
【００９３】
以上、本発明のエラー処理仲介オブジェクトを用いたオブジェクト連携モニタシステムによれば、オブジェクトの障害を検知し、オブジェクト間の正常なオブジェクト連携が実現できないことを予見し、エラー処理が実行されるように仲介することができ、オブジェクト同士の連携に直接含まれていないエラー処理を、エラー処理仲介オブジェクトの働きにより、挿入・追加することができる。
【００９４】
（実施形態３）
本発明のオブジェクト連携モニタシステムおよびオブジェクト連携モニタシステムを用いたオブジェクト連携仲介システムは、上記に説明した構成を実現する処理ステップを記述したプログラムをコンピュータ読み取り可能な記録媒体に記録して提供することにより、各種コンピュータを用いて構築できる。本発明のオブジェクト連携モニタシステムおよびオブジェクト連携モニタを用いたオブジェクト連携仲介システムを実現する処理ステップを備えたプログラムを記録した記録媒体は、図１０に図示した記録媒体の例に示すように、ＣＤ−ＲＯＭ１００２やフレキシブルディスク１００３等の可搬型記録媒体１００１だけでなく、フィールド上にある記録装置内の記録媒体１０００や、コンピュータのハードディスクやＲＡＭ等の記録媒体１００５のいずれであっても良く、プログラム実行時には、プログラムはコンピュータ１００４上にローディングされ、主メモリ上で実行される。
【００９５】
さらに、ソースプログラムをコンパイルしたもののみならず、フィールドを介してクライアントコンピュータに中間言語形式のアプレットを送信し、クライアントコンピュータ上でインタープリタ実行して動作する構成であっても良い。
【００９６】
本発明のオブジェクト連携モニタシステムに関し、以下の項を開示する。
【００９７】
（付記１） フィールド上のオブジェクトのメッセージを介した連携処理の間に、エラー処理を挿入・追加するオブジェクト連携モニタ方法であって、
フィールド上で他のオブジェクトとメッセージをやり取りするメッセージ送受信部と、メッセージの要素とその要素に対するルールとの組を備えたルール判定部と、前記組に従い、受信メッセージにマッチングしたルール内容であるアクションを実行するアクション実行部を備えたオブジェクトがメッセージを介した連携処理を実行し、
フィールド上を流れるメッセージをモニタし、
あるメッセージに対して予定される正常なオブジェクト連携が実行されているか否かを検知し、
正常なオブジェクト連携が実行されていないと検知した場合に前記メッセージを送信したオブジェクトに対するエラー処理仲介を実行し、
前記メッセージを送信したオブジェクトが前記エラー処理仲介を受け、用意されているエラー処理を実行し、正常なオブジェクト連携処理の間にエラー処理を挿入・追加することを特徴とするオブジェクト連携モニタ方法（１）。
【００９８】
（付記２）前記オブジェクト連携検知部が、オブジェクトの障害を検知するオブジェクト障害検知部を備え、前記オブジェクト障害検知部により障害が検知されているオブジェクトが応答すべき依頼メッセージがモニタされた場合、前記エラー処理仲介部が対応するエラー処理仲介を実行する上記付記１に記載のオブジェクト連携モニタシステム（２）。
【００９９】
（付記３）前記オブジェクト連携検知部が、オブジェクトの障害を検知するオブジェクト障害検知部を備え、前記オブジェクト障害検知部が、モニタされた依頼メッセージに応答中のオブジェクトにおける障害を検知した場合、前記エラー処理仲介部が対応するエラー処理仲介を実行する上記付記１に記載のオブジェクト連携モニタシステム（３）。
【０１００】
（付記４）各オブジェクトは、前記ルール判定部に従って前記フィールドからメッセージを受信した場合に、該メッセージのメッセージ要素に反応して受信したことを示す受理メッセージを前記メッセージ送受信部により送信し、
前記エラー処理仲介オブジェクトは、前記ルール判定部において前記受理メッセージのメッセージ要素を組の要素として持ち、該メッセージ要素を持つ受理メッセージが前記メッセージ送受信部から一定時間内に得られない場合、前記エラー処理仲介部が対応するエラーメッセージを前記メッセージ送受信部を介して出力し、
前記メッセージを送信したオブジェクトは、前記ルール判定部において前記エラーメッセージのメッセージ要素を組の要素として持ち、前記エラーメッセージのメッセージ要素に反応してエラーメッセージを取り込み、用意されているエラー処理を実行し、
正常なオブジェクト連携処理の間に、エラー処理を挿入・追加した上記付記１に記載のオブジェクト連携モニタシステム（４）。
【０１０１】
（付記５）前記エラー処理仲介において、前記メッセージに対するエラーメッセージを検知し、前記エラーメッセージに対するエラー処理を代行処理できるオブジェクトを探知し、探知したオブジェクトにエラー処理を代行実行させることにより、エラー処理を仲介する上記付記１に記載のオブジェクト連携モニタ方法。
【０１０２】
（付記６）フィールド上のオブジェクトのメッセージを介した連携処理の間に、エラー処理を挿入・追加する方法であって、
フィールド上で他のオブジェクトとメッセージをやり取りするメッセージ送受信部と、メッセージの要素とその要素に対するルールとの組を備えたルール判定部と、前記組に従い、受信メッセージにマッチングしたルール内容であるアクションを実行するアクション実行部を備えたオブジェクトがメッセージを介した連携処理を実行し、
フィールド上を流れるメッセージをモニタし、
あるメッセージに対して予定される正常なオブジェクト連携が実行されているか否かを検知し、
正常なオブジェクト連携が実行されていないと検知した場合に前記メッセージを送信したオブジェクトに対するエラー処理仲介を実行し、
前記メッセージを送信したオブジェクトが前記エラー処理仲介を受け、用意されているエラー処理を実行し、正常なオブジェクト連携処理の間にエラー処理を挿入・追加することを特徴とするオブジェクト連携モニタ方法（５）。
【０１０３】
（付記７）フィールド上のオブジェクトのメッセージを介した連携処理の間に、エラー処理を挿入・追加する処理プログラムを記録したコンピュータ読み取り可能な記録媒体であって、
フィールド上で他のオブジェクトとメッセージをやり取りするメッセージ送受信部と、メッセージの要素とその要素に対するルールとの組を備えたルール判定部と、前記組に従い、受信メッセージにマッチングしたルール内容であるアクションを実行するアクション実行部を備えたオブジェクト間におけるメッセージを介した連携処理を実行する処理ステップと、
フィールド上を流れるメッセージをモニタする処理ステップと、
あるメッセージに対して予定される正常なオブジェクト連携が実行されているか否かを検知する処理ステップと、
正常なオブジェクト連携が実行されていないと検知した場合に前記メッセージを送信したオブジェクトに対するエラー処理仲介を実行する処理ステップと、
前記メッセージを送信したオブジェクトにおいて、前記エラー処理仲介を受け、用意されているエラー処理を実行する処理ステップを記録した処理プログラムを記録したことを特徴とする記録媒体。
【０１０４】
【発明の効果】
本発明のエラー処理仲介オブジェクトを用いたオブジェクト連携モニタシステムによれば、オブジェクトの障害によりオブジェクト間の正常なオブジェクト連携が実現できない場合、エラー処理仲介オブジェクトにより、オブジェクトにおいてエラー処理が実行されるように仲介することができ、オブジェクト同士の連携に直接含まれていないエラー処理を、エラー処理仲介オブジェクトの働きにより、挿入・追加することができる。
【０１０５】
また、本発明のエラー処理仲介オブジェクトを用いたオブジェクト連携モニタシステムによれば、オブジェクトの障害を検知し、オブジェクト間の正常なオブジェクト連携が実現できないことを予見し、エラー処理が実行されるように仲介することができ、オブジェクト同士の連携に直接含まれていないエラー処理を、エラー処理仲介オブジェクトの働きにより、挿入・追加することができる。
【図面の簡単な説明】
【図１】 本発明のオブジェクト連携モニタシステムが前提とするフィールドリアクターモデルに基づくオブジェクト間の緩やかな連携を模式的に示した図
【図２】 フィールドリアクターモデルに基づくオブジェクトの概略構成例を示す図
【図３】 フィールドリアクターモデルに基づくオブジェクト連携システムの入力メッセージ構造の例を示す図
【図４】 本発明のエラー処理仲介オブジェクトを用いたオブジェクト連携モニタシステムの動作を模式的に示した図である。
【図５】 本発明の実施形態１のオブジェクト連携モニタシステムの構成例を示す図
【図６】 本発明の実施形態１のオブジェクト連携モニタシステムのエラー処理仲介の動作を模式的に示した図
【図７】 実施形態１のオブジェクト連携モニタシステムの動作例を示したフローチャート
【図８】 実施形態２のオブジェクト連携モニタシステムの構成例を示す図
【図９】 実施形態２のオブジェクト連携モニタシステムによりオブジェクトに障害が発生した場合のエラー処理仲介の動作の流れを示すフローチャート
【図１０】 実施形態３におけるオブジェクト連携モニタシステムを実現する処理プログラムを記録した記録媒体の例を示す図
【図１１】 従来技術のＣＯＲＢＡに基づいたクライアント／サーバシステムにおけるオブジェクト連携の例を示す図
【符号の説明】
１０ メッセージ送受信部
２０ メッセージ・アクション反応テーブル
３０ アクション実行部
３１ メッセージ生成部
４０ オブジェクト連携検知部
４１ 障害検知部
５０ エラー処理仲介部
１００，１００ｂ オブジェクト
２００ エラー処理仲介オブジェクト
４００ フィールド
１０００ 記録装置内の記録媒体
１００１ 可搬型記録媒体
１００２ ＣＤ−ＲＯＭ
１００３ フレキシブルディスク
１００４ コンピュータ
１００５ コンピュータのハードディスクやＲＡＭ等の記録媒体
【発明の属する技術分野】
本発明は、コンピュータ群もしくはオブジェクト群の対話・協調などの連携処理を実施するオブジェクト連携システムに関し、分散型計算機環境などのオブジェクト指向環境において複数のプロセスが作りだされ、コンピュータフィールドを通じて、環境の変化に柔軟に対応し、漸進的に変化するシステム構築のためのオブジェクト連携システムに関する。特に、分散したオブジェクト間の通信や対話、協調など連携処理を行う際のエラー処理仲介に関するものであり、特に共通のフィールドとして定義されるような通信路を流れるメッセージとして種々の情報にオブジェクトとして個々のコンピュータシステムあるいはコンピュータシステム内で動作する個々のアプリケーションプログラムが独自に反応する形で処理が行われるとき、システム全体としてエラー処理をハンドリングすることに関する。
【０００２】
【従来の技術】
近年、フィールド化が進み、フィールド上に分散した複数のオブジェクトが互いに連携して処理を行うシステムが増えている。このような複数のオブジェクトが連携して処理を行うための技法として、オブジェクト指向型プログラミングやコンポーネント技術などの研究がなされている。
【０００３】
オブジェクト指向型プログラミングの一例として、オブジェクト指向技術の標準化と普及を目指して設立された業界団体ＯＭＧ（Object Management Group）によって定められた分散オブジェクト運用のための共通仕様ＣＯＲＢＡ（The Common Object Request Broker : Architecture and Specification）がある。
【０００４】
図１１に、ＣＯＲＢＡに基づいたクライアント／サーバシステムにおけるオブジェクト連携の例を示す。このシステムは、クライアントアプリケーションとサーバ・アプリケーションとが連携することにより、つまりオブジェクト連携により一連の処理を行うものである。
【０００５】
アプリケーション開発者は、クライアントおよびサーバそれぞれが提供するサービスのインターフェースをＩＤＬ（Interface Definition Language）で記述する。インターフェースとして定義する内容は、オブジェクトに依頼できるオペレーション群であり、各々のオペレーションは、オペレーション名、パラメタの定義、戻り値の定義、エラー発生時の例外処理、付加情報などが定義される。
【０００６】
ＩＤＬで定義された内容を専用のコンパイラでコンパイルすることにより、クライアント用のスタブとサーバ用のスケルトンが生成される。スタブとは、クライアントアプリケーションにＩＤＬで定義されたオペレーション群へのアクセスを提供するルーチン群である。クライアントアプリケーションは、スタブで提供されるルーチンを呼び出すことにより、各種オペレーションが起動される。スケルトンは、サーバ・アプリケーションが提供するメソッドルーチンヘのディスパッチングルーチンを提供する。
【０００７】
スタブおよびスケルトンは、対応するクライアントアプリケーションあるいはサーバ・アプリケーションが使用するプログラミング言語で生成される。たとえば、使用されるプログラミング言語がＣ言語であったとすると、スタブはＣ言語の関数群として生成され、クライアントアプリケーションは、実行したいオペレーションに対応する関数を呼び出すことにより、スタブ、ＯＲＢランタイム、スケルトンを経由してサーバ・アプリケーションの該当ルーチンが呼び出され、所定の処理が実行されたあと、その処理結果が呼び出し元のクライアントアプリケーションに返される。
【０００８】
【発明が解決しようとする課題】
従来のＣＯＲＢＡなどの技術を用いてオブジェクト間の連携処理を構築することは容易になってきており、エラー処理についてもオブジェクト内に記述したエラー発生時の例外処理として取り扱われている。
【０００９】
しかし、実際にこのようなオブジェクト間の連携処理におけるエラー処理を上記のＣＯＲＢＡを用いて実現するためには、以下の問題がある。
【００１０】
ＣＯＲＢＡ技術そのものの深い理解が必要となり、さらに、ＣＯＲＢＡ仕様に応じたオブジェクトの設計およびＩＤＬによる定義づけが必要となってしまうという問題があった。つまり、ＣＯＲＢＡの利用に関する技術内容・情報をシステム構築者が熟知する必要がある。これは一般には困難なものである。
【００１１】
また、システム構築者は、個々のオブジェクトの関係を強く意識しつつシステムを構築する必要があるという問題がある。つまり、それぞれオブジェクトがどういう処理を行うものであるか、その処理を行うために必要となる受け渡しのパラメタはどのようなものであるかという点などを厳密に定義しておかなければならない。
【００１２】
このように、従来のＣＯＲＢＡを用いたオブジェクト間の連携処理システムの構築によれば、オブジェクト間のインタフェースが共通化されることにより、オブジェクトの独立性が高まったとは言え、あくまでもオブジェクトとオブジェクトとの間には固定的な関係が存在することが前提となっている。このことはシステム全体にわたって統一されたシステム動作に関するトップダウンの設計がなければエラー処理自体を設計することができないことを意味している。
【００１３】
本発明は上記問題点を解決し、フィールドに接続されたオブジェクトとオブジェクトの連携をメッセージを介して行うオブジェクト連携システムにおいて、エラー処理仲介を行うオブジェクトを導入し、エラー処理の自由度を高め、柔軟なシステム構築を可能とするオブジェクト連携に関するシステムを提供することを目的とする。
【００１４】
【課題を解決するための手段】
上記目的を達成するため、本発明のオブジェクト連携モニタシステムは、フィールド上で他のオブジェクトとメッセージをやり取りするメッセージ送受信部と、メッセージの要素とその要素に対するルールとの組を備えたルール判定部と、前記組に従い、受信メッセージにマッチングしたルール内容であるアクションを実行するアクション実行部を備えたオブジェクト間の連携を管理するシステムであって、前記メッセージ送受信部と、前記ルール判定部と、前記アクション実行部と、前記メッセージ送受信部を介して前記フィールド上を流れるメッセージをモニタし、あるメッセージに対して予定される正常なオブジェクト連携が実行されているか否かを検知するオブジェクト連携検知部と、前記オブジェクト連携検知部が正常なオブジェクト連携が実行されていないと検知した場合に対応するエラーメッセージを出力してエラー処理の仲介を実行するエラー処理仲介部を備えたエラー処理仲介オブジェクトを備えたことを特徴とする。
【００１５】
上記構成により、オブジェクトは、エラー処理仲介オブジェクトを意識することなく、通常の処理に従ってフィールドリアクターモデルに従って動作し、エラー処理仲介オブジェクトが自律的にエラーを検知し、フィールドリアクターモデルに従ったエラー処理仲介を実行してオブジェクトにエラー処理を実行させることができ、柔軟かつ動的にオブジェクト連携のエラー処理を構築することが可能となる。
【００１６】
ここで、前記オブジェクト連携検知部が、オブジェクトの障害を検知するオブジェクト障害検知部を備え、前記メッセージ送受信部において前記オブジェクト障害検知部により障害が検知されているオブジェクトが応答すべきメッセージがモニタされた場合、前記エラー処理仲介部が対応するエラー処理仲介を実行することが好ましい。
【００１７】
上記構成により、あらかじめ、障害の発生しているオブジェクトを検知しておくことにより、該障害オブジェクトがフィールドリアクターモデルに従って反応すべきメッセージに対する不具合発生を予見することができ、速やかにエラー処理仲介実行を開始することができる。
【００１８】
また、前記オブジェクト連携検知部が、オブジェクトの障害を検知するオブジェクト障害検知部を備え、前記オブジェクト障害検知部が、前記メッセージ送受信部においてモニタされたメッセージに応答中のオブジェクトにおける障害を検知した場合、前記エラー処理仲介部が対応するエラー処理仲介を実行することが好ましい。
【００１９】
上記構成により、フィールドリアクターモデルに従ってメッセージに反応してアクション実行中のオブジェクトに発生した障害を検知することができ、アクションが未完了となる不具合発生を予見することができ、速やかにエラー処理仲介実行を開始することができる。
【００２０】
また、正常なオブジェクト連携処理の間に、エラー処理を挿入・追加するため、各オブジェクトは、前記ルール判定部に従って前記フィールドからメッセージを受信した場合に、該メッセージのメッセージ要素に反応して受信したことを示す受理メッセージを前記メッセージ送受信部により送信し、前記エラー処理仲介オブジェクトは、前記ルール判定部において前記受理メッセージのメッセージ要素を組の要素として持ち、該メッセージ要素を持つ受理メッセージが前記メッセージ送受信部から一定時間内に得られない場合、前記エラー処理仲介部が対応するエラーメッセージを前記メッセージ送受信部を介して出力し、前記メッセージを送信したオブジェクトは、前記ルール判定部において前記エラーメッセージのメッセージ要素を組の要素として持ち、前記エラーメッセージのメッセージ要素に反応してエラーメッセージを取り込み、用意されているエラー処理を実行し、正常なオブジェクト連携処理の間に、エラー処理を挿入・追加することが好ましい。
【００２１】
上記構成により、オブジェクトはフィールドリアクターモデルに従ったオブジェクト連携処理を実行する環境に対して、外部的にエラー処理仲介を挿入・追加することができ、エラー処理を高い自由度で柔軟に構築することが可能となる。
【００２２】
また、上記目的を達成するため、本発明のオブジェクト連携モニタ方法は、フィールド上のオブジェクトのメッセージを介した連携処理の間に、エラー処理を挿入・追加する方法であって、フィールド上のオブジェクトのメッセージを介した連携処理の間に、エラー処理を挿入・追加する方法であって、フィールド上で他のオブジェクトとメッセージをやり取りするメッセージ送受信部と、メッセージ要素に対する反応であるアクション内容を管理するルール判定部と、前記ルール判定部に従い、受信メッセージの持つメッセージ要素にマッチングしたアクション内容に従って処理を実行するアクション実行部を備えたオブジェクトがメッセージを介した連携処理を実行し、フィールド上を流れるメッセージをモニタし、あるメッセージに対して予定される正常なオブジェクト連携が実行されているか否かを検知し、正常なオブジェクト連携が実行されていないと検知した場合に前記メッセージを送信したオブジェクトに対するエラー処理仲介を実行し、前記メッセージを送信したオブジェクトが前記エラー処理仲介を受け、用意されているエラー処理を実行し、正常なオブジェクト連携処理の間にエラー処理を挿入・追加することを特徴とする。
【００２３】
上記方法を用いれば、フィールドリアクターモデルに従ったオブジェクト連携処理を実行する環境に対して、外部的にエラー処理仲介を挿入・追加することができ、エラー処理を高い自由度で柔軟に構築することが可能となる。
【００２４】
本発明のエラー処理仲介オブジェクトを用いたオブジェクト連携モニタシステムを実現する処理プログラムを記録したコンピュータ読み取り可能な記録媒体を提供すれば、コンピュータ装置を利用して本発明のオブジェクト連携モニタシステムを構築することができる。
【００２５】
【発明の実施の形態】
以下、本発明のオブジェクト連携モニタシステムの実施形態について、図面を参照しながら説明する。
【００２６】
（実施形態１）
本発明のエラー処理仲介オブジェクトを設けたオブジェクト連携モニタシステムは、オブジェクトの障害によりオブジェクト間の正常なオブジェクト連携が実現できない場合、オブジェクトにおいて必要なエラー処理が実行されるように仲介し、オブジェクト同士の連携に直接含まれていないエラー処理を、エラー処理仲介オブジェクトの働きにより、挿入・追加するものである。ここで、エラー処理仲介オブジェクトは、メッセージ送受信部と、メッセージの要素とその要素に対するルールとの組を備えたルール判定部と、前記組に従い、受信メッセージにマッチングしたルール内容であるアクションを実行するアクション実行部に加え、メッセージ送受信部によりフィールド上を流れるメッセージをモニタし、あるメッセージに対して予定される正常なオブジェクト連携が実行されているか否かを検知するオブジェクト連携検知部と、前記オブジェクト連携検知部が正常なオブジェクト連携が実行されていないと検知した場合に対応するエラー処理仲介を実行するエラー処理仲介部を備えたものである。
【００２７】
以下、図面を参照しつつ、本発明のエラー処理仲介オブジェクトを設けたオブジェクト連携モニタシステムの実施形態を説明する。
【００２８】
ここでは、本発明のオブジェクト連携モニタシステムの一実施形態として、フィールドリアクターモデルにより構成した例を挙げる。フィールドリアクターモデルとは、フィールドを流れるメッセージのメッセージ構造と当該メッセージ構造に対応するアクションの関係によってオブジェクト同士を結び付けることによりオブジェクト同士の連携を構築し、当該メッセージとアクションの関係の記述を柔軟かつ動的に更新することによりオブジェクト連携関係を柔軟かつ動的に構築するものである。つまり、本発明で言う、メッセージの要素とその要素に対するルールとの組の例として、メッセージ構造とそのメッセージ構造に対応付けられるアクションの関係を反応テーブルという形で用意した例を説明する。このように実施形態１は、フィールドを流れるメッセージの要素とその要素に対するルールとの組によるオブジェクト同士の連携の一例として、メッセージ構造とアクションの関係を記述した反応テーブルを用いたオブジェクト同士の連携という形で説明する。
【００２９】
以下、本実施形態１ではオブジェクト連携モニタシステムの概念を説明し、その一実施形態として、フィールドリアクターモデルを前提とした構成を中心に説明する。
【００３０】
以下、オブジェクトの連携処理に対するエラー処理仲介を実行する本発明のオブジェクト連携モニタシステムを３つのパートに分けて順を追って説明する。
【００３１】
第１のパートでは、実施形態１としてオブジェクト連携モニタシステムが用いるフィールドリアクターモデルの動作原理、フィールドリアクターモデル用いた場合のオブジェクト連携システムの構成を説明する。
【００３２】
第２のパートでは、エラー処理仲介オブジェクトを用いたオブジェクト連携モニタシステムによるエラー処理仲介の概念を説明する。
【００３３】
第３のパートでは、フィールドリアクターモデル用いたオブジェクト連携システムにおいてエラー処理仲介オブジェクトを設けたオブジェクト連携モニタシステムの構成とエラー仲介動作の一例について説明する。
【００３４】
まず、第１のパートとして、フィールドリアクターモデルの動作原理、メッセージを用いたオブジェクト同士の連携の概念を説明する。
【００３５】
本発明のオブジェクト連携モニタシステムがエラー処理仲介を行う対象であるフィールドリアクターモデルにより構築されたオブジェクト連携システムは、オブジェクト間でやり取りされるメッセージの要素とそのメッセージ要素に対するアクションとの関係づけを用いている。
【００３６】
以下、共通のフィールドとして定義される通信路を流れるメッセージに対して、オブジェクトとしての個々のコンピュータシステムあるいはコンピュータシステム内で動作する個々のアプリケーションプログラムが反応する形で処理を実行するので、メッセージとアクションとの対応づけを変更・調整することによりシステム全体の動作も柔軟に変更することができる。つまり、互いの内部状態や内部関数に依存しあうような密な関係とはしないで、連携するオブジェクトの緩やかな関係を規定したオブジェクト間の連携によって機能を動的に構成することができる。
【００３７】
図１は、オブジェクト間の緩やかな連携を模式的に示した図である。
【００３８】
図１において２０１はオブジェクトＡ，２０２はオブジェクトＢであり、それぞれメッセージを送受信する主体であるオブジェクトである。Ｍ１はメッセージであり、ａ１はオブジェクトＡ（２０１）中に規定されたアクション、ａ２はオブジェクトＢ（２０２）中に規定されたアクションを示す。なお、図中の矢印は、起点がオブジェクトのときメッセージの送出を、終点がオブジェクトのときメッセージの受信を示している。またそれぞれのオブジェクトは内部状態としてのアクションをそれぞれ独自に持っているとする。
【００３９】
図１において、オブジェクトＡ（２０１）とオブジェクトＢ（２０２）の連携は、メッセージＭ１を介して行われている。オブジェクトＡ（２０１）は、オブジェクトＢ（２０２）についてもオブジェクトＢ（２０２）の持つ内部関数についても基本的には関知せずにメッセージを送出する。また、オブジェクトＢ（２０２）自体を特定してメッセージを送出する必要もなく、オブジェクトＡ（２０１）は自己の状態、処理内容に基づいてメッセージＭ１を送出する。オブジェクトＢ（２０２）は通信路上を流れるメッセージをモニタしており、メッセージＭ１を検知し、Ｍ１がオブジェクトＢにとって有為であるとき、反応してアクションａ２を起動する。このようにオブジェクトＡとオブジェクトＢとは有為な連携を取り得るが、それはオブジェクトＡ（２０１）とオブジェクトＢ（２０２）の直接の結び付きによるものではなく、メッセージＭ１とオブジェクトＢ（２０２）のアクションａ２とが結び付けられている帰結といえる。逆にメッセージがＭ１とは異なるものであれば、オブジェクトＢ（２０２）は当該メッセージがＭ１と同様の受理可能範囲にあるかあるいは他に当該メッセージと結び付けられているアクションがない限り反応しないこととなる。このようにオブジェクト間の連携が緩やかにメッセージを介して行われることにより、オブジェクト間の連携の自由度が増すこととなる。つまり、従来のコンピュータネットワーク通信のように通信相手のアドレスおよび処理依頼内容を特定する必要がなく、ネットワーク上に自らの状態、処理結果などを表わすメッセージを流し、ネットワークをモニタしている各端末がそのメッセージを検知し、対応するアクションが規定されていれば自律的に反応を起こすものである。
【００４０】
フィールドとなる通信路は単にＬＡＮなどの物理的ネットワークだけではなく無線・音声・光などの共通に受信できる媒体を介在するものであれば特に限定する必要はない。また、共通に呼び出し可能なメモリ等の記録媒体であってもかまわない。さらに通信路のポートアドレスなどにより仮想的な存在であってもかまわない。
【００４１】
次に、オブジェクト連携システムの構成例を示す。図２は、オブジェクト連携システムの概略構成例を示す図である。１００はオブジェクトを表わしており、フィールド上に送信されるメッセージを取り込むメッセージ送受信部１０と、メッセージの構造とそのメッセージ構造に対応づけられたアクションを記述した反応テーブル２１を格納した反応テーブル記憶部２０と、反応テーブル２１に従ってアクションを実行するアクション実行部３０を備えている。４００はフィールドである。
【００４２】
メッセージ生成部３１は、アクション実行部３０による処理内容の実行の一環としてメッセージを生成する部分である。
【００４３】
メッセージがフィールド４００からメッセージ送受信部１０を介して受信されると、反応テーブル２１に記述された当該メッセージ構造に対応するアクション内容が起動される。このように、他のオブジェクトが発したメッセージを介してオブジェクトが連携することとなる。
【００４４】
なお、メッセージ・アクション反応テーブル２０には、メッセージ構造とメッセージタグの組み合わせが与えられている。例えば、図３に記載した入力メッセージ構造がメッセージ・アクション反応テーブル２０に記載されている。
【００４５】
図３に示した入力メッセージ構造を持つメッセージがフィールド４００から受信されるとメッセージ・アクション反応テーブル２０の記述に従い、入力メッセージパターンマッチングが成立し、対応するアクションが起動される。このように、他のオブジェクトが発したメッセージを介してオブジェクトが連携することとなる。
【００４６】
フィールドリアクターモデルとは、上記のように、メッセージ構造を用いたパターンマッチングによるメッセージとアクションの反応関係により、受信メッセージのメッセージ構造に対して発火（反応）して対応するアクションを実行し、メッセージ−アクションの連携動作によりオブジェクト同士が連携する仕組みである。フィールドリアクターモデルでは、共通のフィールドとして定義されるような通信路を流れるメッセージに対して、オブジェクトとしての個々のコンピュータシステムあるいはコンピュータシステム内で動作する個々のアプリケーションプログラムが反応する形で処理を実行するので、メッセージとアクションとの反応関係を変更・調整することによりシステム全体の動作も柔軟に変更することができる。つまり、互いの内部状態や内部関数に依存しあうような密な関係とはしないで、連携するオブジェクトの緩やかな関係を規定したオブジェクト間の連携によって機能を動的に構成することができる。
【００４７】
次に、第２のパートとして、エラー処理仲介オブジェクトを用いたオブジェクト連携モニタシステムによる仲介処理の概念を説明する。
【００４８】
上記に見たように、フィールドリアクターモデルを用いてオブジェクト連携システムを構築している場合、以下の特徴がある。
【００４９】
（１）オブジェクト間でやり取りされるメッセージは、共有もしくはブロードキャストされている。
【００５０】
（２）メッセージを受信するオブジェクトはそれぞれ独立に、反応し得るメッセージのパターンと反応としてのアクションを持っている。
【００５１】
（３）メッセージを送信もしくは受信するオブジェクトにおいて、メッセージとアクションとの関係は分離されている。このことにより送信側と受信側との関係もまた分離されている。
【００５２】
メッセージとアクションとが分離されているという性質を利用することによってオブジェクト間にエラー処理仲介の挿入・追加という処理を行い、当該エラー処理仲介の挿入・追加により、本来エラー処理を持っていないオブジェクト間の連携において外部的にエラー処理を仲介し、本来のオブジェクト連携処理の流れとは独立なエラー処理動作の実行を実現するものである。エラー処理に対して高い自由度と柔軟性を持たせることが可能となる。
【００５３】
図４は、本発明のオブジェクト連携モニタシステムの動作を模式的に示した図である。１００ａ〜１００ｃは図２に示した構成を持つオブジェクト、２００はエラー処理仲介オブジェクトである。エラー処理仲介オブジェクトの構成例は後述するのでここでは示していない。４００はフィールドであり、メッセージ交換の場として利用されている。各オブジェクトは上記に示したように、メッセージ構造のマッチングによりメッセージアクション反応テーブルに従って連携している。エラー処理仲介オブジェクト２００は、フィールド４００に接続し、他のオブジェクト１００ａ〜１００ｃ間でやり取りされているメッセージをモニタする。例えば、入力メッセージパターンとして、依頼メッセージが共通的に持つメッセージパターンをメッセージアクション反応テーブル２０に持っておけば、フィールド上を流れる依頼メッセージにすべて反応して取り込むことができる。また、個別にモニタを予定するメッセージのメッセージパターンをメッセージアクション反応テーブル２０に保持しておくことでも良い。
【００５４】
オブジェクト１００ａ〜１００ｃ同士はこのようにメッセージを介して連携するが、エラー処理仲介オブジェクト２００は、このメッセージアクション関係に基づくオブジェクト連携が正常に実行されているか否かを検知し、正常なオブジェクト連携が実行されていないと検知した場合には、対応するエラーメッセージを出力するというエラー処理の仲介を実行する。例えば、オブジェクト１００ａが依頼メッセージを出力し、当該メッセージをオブジェクトｂとオブジェクトｃが受信したとする。当該メッセージのメッセージ構造が、オブジェクトｂのメッセージアクション反応テーブルの入力メッセージ構造にマッチングした場合、オブジェクトｂが対応するアクションを実行することによりオブジェクトａとオブジェクトｂ間のオブジェクトの連携を実現する。ここで、エラー処理仲介オブジェクト２００による正常なオブジェクト連携が実行の有無を検知する方法の一つとして、以下の処理を実行する。オブジェクト１００ｂは取り込んだメッセージ構造によりマッチングが成立した場合、即座にマッチングしたことを示す受理メッセージを出力し、当該受理メッセージ出力後にアクションを実行する。エラー処理仲介オブジェクト２００は、自らの反応テーブルに受理メッセージを入力メッセージ構造とする要素を持つ。この処理によれば、フィールド上に流れたメッセージに対して正常に反応したオブジェクトが存在するか否かを検知することができる。受理メッセージが受信することができなければ、正常なオブジェクト連携が実行されていないことを検知することができる。この場合、エラー処理仲介オブジェクト２００は、対応するエラーメッセージを出力してエラー処理を仲介する。このエラーメッセージも同様にフィールドを流れ、オブジェクト１００ａにより受信され、エラーメッセージのメッセージ構造に対応するアクションであるエラー処理が実行される。このように、本来、オブジェクト１００ａとオブジェクト１００ｂ間のオブジェクト連携処理には含まれていないエラー処理が、エラー処理仲介オブジェクトにより仲介され、挿入・追加される。
【００５５】
また、エラー処理仲介オブジェクト２００は、受理メッセージを受信した場合、どのオブジェクトが反応してアクションを実行中かを検知することができるので、当該オブジェクトにおいてアクション実行中に何らかの障害が発生したことを検知すれば、正常なオブジェクト連携が実行されていないことを検知することができ、この場合も同様に、エラー処理仲介オブジェクト２００は、対応するエラーメッセージを出力してエラー処理を仲介する。
【００５６】
以上が、エラー処理仲介オブジェクトを用いたオブジェクト連携モニタシステムによる仲介処理の概念である。
【００５７】
次に、第３のパートとして、エラー処理仲介オブジェクトを設けたオブジェクト連携モニタシステムの構成を説明する。
【００５８】
図５は、実施形態１のオブジェクト連携モニタシステムの構成例を示す図である。図２のオブジェクト連携モニタシステムの各構成要素と同じ番号のものは同様のものである。１００は図２で示した一般のオブジェクト、２００はエラー処理仲介オブジェクトである。エラー処理仲介オブジェクト２００は、フィールド上に送信されるメッセージを取り込むメッセージ送受信部１０と、メッセージ構造に対する反応であるアクション内容を管理するメッセージ・アクション反応テーブル２０と、メッセージ・アクション反応テーブル２０に従い、受信メッセージの持つメッセージ構造にマッチングしたアクション内容に従って処理を実行するアクション実行部３０、メッセージ生成部３１というフィールドリアクターモデルにおけるオブジェクトが備える構成に加え、オブジェクト連携検知部４０とエラー処理仲介部５０を備えている。
【００５９】
オブジェクト連携検知部４０は、メッセージ送受信部１０によりフィールド４００上を流れるメッセージをモニタし、あるメッセージに対して予定される正常なオブジェクト連携が実行されているか否かを検知する部分である。
【００６０】
エラー処理仲介部５０は、オブジェクト連携検知部４０が正常なオブジェクト連携が実行されていないと検知した場合に対応するエラー処理仲介を実行する部分である。
【００６１】
図６は、オブジェクト連携モニタシステムによるエラー処理仲介の概念を模式的に簡単に説明した図である。図６において、１００ａ〜１００ｃはオブジェクト、２００はエラー処理仲介オブジェクト、４００はフィールドである。なお、メッセージ・アクション反応テーブルを分かりやすいように模式的に記述した。
【００６２】
オブジェクト１００ａにはメッセージ・アクション反応テーブルとして、簡単に３つのメッセージ・アクションの関係を記述している。１つめは依頼メッセージパターン＜request1＞を出力するアクション“Rfunc request1out”を要素に持つもの、２つめは依頼に対する正常な応答メッセージを受けるための入力メッセージパターン＜reply1＞と依頼に関する処理を完了させるアクション“Rfunc end”とを要素に持つもの、３つめはエラーメッセージを受けるための入力メッセージパターン＜error1＞とエラー処理アクション“Rfunc error1exe”とを要素に持つものである。オブジェクト１００ｂにはメッセージ・アクション反応テーブルとして、簡単に３つのメッセージ・アクションの関係を記述している。１つは依頼メッセージ＜request1＞を受けるための入力メッセージパターンと受理メッセージ＜accept1＞を出力するアクション“Rfunc accept1out”を要素に持つもの、２つめは依頼メッセージ＜request1＞を受けるための入力メッセージパターンと依頼内容を実行するアクション“Rfunc request1exe”を要素に持つものである。３つめは依頼内容が終了した場合にその結果を返す応答メッセージ＜reply1＞を出力するアクション“Rfunc reply1out”を要素に持つものである。エラー処理仲介オブジェクト２００には簡単に３つのメッセージ・アクションの関係を記述している。１つめは受理メッセージ＜accept1＞を受けるための入力メッセージパターンと後述する応答メッセージをモニタする処理であるアクション“Rfunc monitor1”を要素に持つもの、２つめは、依頼に対する正常な応答メッセージ＜reply1＞を受けるための入力メッセージパターンと依頼に関する処理を完了させるアクション“Rfunc end”とを要素に持つもの、３つめはアクション（エラー仲介処理）としての出力エラーメッセージ＜error1＞を出力するアクション“Rfunc error1out”を要素に持つものである。
【００６３】
なお、図６のメッセージアクション反応テーブル中、対応するメッセージが−−−となっているアクションは、オブジェクトが自律的に内部処理により実行できるアクションである。
【００６４】
図６に示したオブジェクト連携の動作は以下のようになる。まず、オブジェクト１００ａとオブジェクト１００ｂが正常に連携する場合を説明する。
【００６５】
オブジェクト１００ａは、依頼のため、例えば、以下のメッセージ構造を持つ依頼メッセージ、(request1(search printer))をフィールド４００に流す。
【００６６】
【００６７】
【００６８】
一方、オブジェクト１００ｂは、依頼メッセージパターン＜request1＞に対してもう一つのアクション、つまり、依頼内容を実行するアクション“＜Rfunc request1exe＞”が起動されている。オブジェクト１００ｂは、依頼内容を実行するアクションが完了すれば、応答メッセージ＜reply1＞をフィールド４００上に流す。
【００６９】
オブジェクト１００ｂとエラー処理仲介オブジェクト２００はそれぞれメッセージ・アクション反応テーブルに従ってフィールド４００から当該応答メッセージ＜reply1＞を取り込む。オブジェクト１００ｂは依頼に対する正常な応答結果を得ることができ、エラー処理仲介オブジェクト２００のオブジェクト連携検知部４０は、依頼に対する正常な応答結果が返され、正常なオブジェクト連携が完了したことを確認できる。
【００７０】
次に、オブジェクト１００ａとオブジェクト１００ｂが正常に連携できなかった場合の動作を参照しつつ説明する。
【００７１】
オブジェクト１００ａは、上記と同様、依頼メッセージをフィールド４００に流し、オブジェクト１００ｂとエラー処理仲介オブジェクト２００はそれぞれメッセージ・アクション反応テーブルに従って依頼メッセージパターン＜request1＞に反応してフィールド４００から当該メッセージを取り込む。この際、オブジェクト１００ｂに何らかの障害が発生しており、正常な動作が実行できない状態であるものとする。例えば、第１の障害ケースとして、当初から障害があり、依頼メッセージに対する受理メッセージをフィールド４００に流すことができないケースを想定する。この場合、エラー処理仲介オブジェクト２００は、所定時間が経過しても受理メッセージ＜accept1＞がフィールド上から得られないこととなり、これによりオブジェクト連携検知部４０は、オブジェクト１００ａの発した依頼メッセージに対してオブジェクト１００ｂが正常に反応（オブジェクト連携）できなかったことを検知する。エラー処理仲介オブジェクト２００は、対応するエラーメッセージを出力するアクション“Rfunc error1out”によりエラーメッセージ＜error1＞をフィールド４００上に出力する。
【００７２】
オブジェクト１００ｂはメッセージ・アクション反応テーブルに従ってフィールド４００から当該エラーメッセージ＜error1＞を取り込む。オブジェクト１００ｂはエラーメッセージパターン＜error1＞に対してエラー処理を実行するアクション“＜Rfunc error1exe＞”を起動し、エラー処理を実行する。このように、オブジェクト１００ａとオブジェクト１００ｂの連携には直接含まれていないエラー処理が、エラー処理仲介オブジェクト２００の働きにより、挿入・追加されることが分かる。
【００７３】
次に、第２の障害ケースとして、当初は障害がなく、依頼メッセージに対して反応し、受理メッセージをフィールド４００に流し、依頼内容に関する処理を実行したが、その過程で障害が発生したケースを想定する。この場合、エラー処理仲介オブジェクト２００のオブジェクト連携検知部４０は、受理メッセージ＜accept1＞をフィールド４００上から得ているので、オブジェクト１００ａの発した依頼メッセージに対してオブジェクト１００ｂが正常に反応（オブジェクト連携）したことを検知している。しかし、所定時間が経過しても、エラー処理仲介オブジェクト２００は、オブジェクト１００ｂから、依頼内容を実行した結果を含む応答メッセージ＜reply1＞をフィールド４００上から得ることができない。これによりオブジェクト連携検知部４０は、オブジェクト１００ａの発した依頼メッセージに対してオブジェクト１００ｂが正常に反応（オブジェクト連携）を完了できなかったことを検知する。エラー処理仲介オブジェクト２００は、対応するエラーメッセージを出力するアクション“Rfunc error1out”によりエラーメッセージ＜error1＞をフィールド４００上に出力する。
【００７４】
オブジェクト１００ｂはメッセージ・アクション反応テーブルに従ってフィールド４００から当該エラーメッセージ＜error1＞を取り込み、対応するエラー処理を実行するアクション“＜Rfunc error1exe＞”を起動し、エラー処理を実行する。この第２の障害ケースにおいても、オブジェクト１００ａとオブジェクト１００ｂの連携には直接含まれていないエラー処理が、エラー処理仲介オブジェクト２００の働きにより、挿入・追加されることが分かる。
【００７５】
図７は、本発明のエラー処理仲介オブジェクトを設けたオブジェクト連携モニタシステムの処理の流れの一例を示したフローチャートである。
【００７６】
エラー処理仲介オブジェクト２００はフィールド４００上を流れる依頼メッセージをモニタする（ステップＳ７０１）。
【００７７】
依頼メッセージがモニタされると（ステップＳ７０１：Ｙ）、その後、ステップＳ７０１でモニタした依頼メッセージに対する受理メッセージを所定時間モニタする（ステップＳ７０２）。
【００７８】
受理メッセージがモニタされると（ステップＳ７０２：Ｙ）、オブジェクト連携検知部４０は、オブジェクト間で正常な連携が実行されていることを検知する（ステップＳ７０３）。
【００７９】
受理メッセージが所定時間内にモニタされない場合（ステップＳ７０２：Ｎ）、依頼メッセージに応答できるオブジェクトが存在せず、オブジェクト間で正常な連携が実行されていないことを検知し、対応するエラーメッセージを出力し（ステップＳ７０４）、ステップＳ７０１に戻る。
【００８０】
受理メッセージがモニタされ、オブジェクト間で正常な連携が行われていることが検知されている場合、依頼メッセージを受けたオブジェクトから依頼内容を実行した結果を含む応答メッセージを所定時間モニタする（ステップＳ７０５）。
【００８１】
応答メッセージがモニタされると（ステップＳ７０５：Ｙ）、オブジェクト連携検知部４０は、オブジェクト間で正常な連携実行が完了したことを検知し（ステップＳ７０６）、ステップＳ７０１に戻る。
【００８２】
応答メッセージが所定時間内にモニタされない場合（ステップＳ７０５：Ｎ）、依頼メッセージを受理したオブジェクトに何らかの障害が発生したため、オブジェクト間で正常な連携が実行されていないことを検知し、対応するエラーメッセージを出力し（ステップＳ７０４）、ステップＳ７０１に戻る。
【００８３】
以上、本発明のエラー処理仲介オブジェクトを設けたオブジェクト連携モニタシステムによれば、オブジェクトの障害によりオブジェクト間の正常なオブジェクト連携が実現できない場合、エラー処理が実行されるように仲介することができ、オブジェクト同士の連携に直接含まれていないエラー処理を、エラー処理仲介オブジェクト２００の働きにより、挿入・追加することができる。
【００８４】
（実施形態２）
実施形態２のエラー処理仲介オブジェクトを設けたオブジェクト連携モニタシステムは、オブジェクト連携検知部が、オブジェクトの障害を検知するオブジェクト障害検知部を備え、オブジェクト障害検知部により障害が検知されているオブジェクトが応答すべきメッセージがモニタされた場合、正常なオブジェクト連携が実行されないことを予見し、エラー処理仲介部が対応するエラー処理仲介を実行するものである。また、当初障害が検知されず、依頼メッセージに反応してアクションを実行中のオブジェクトにおいて障害が発生した場合、オブジェクト障害検知部により当該オブジェクトにおける障害を検知し、エラー処理仲介部が対応するエラー処理仲介を実行するものである。
【００８５】
図８は、実施形態２のオブジェクト連携モニタシステムの構成例を示す図である。図５のオブジェクト連携モニタシステムの各構成要素と同じ番号のものは同様のものである。１００は一般のオブジェクト、２００ｂはエラー処理仲介オブジェクトであり、エラー処理仲介オブジェクト２００は、メッセージ送受信部１０、メッセージ・アクション反応テーブル２０、アクション実行部３０、オブジェクト連携検知部４０ａ、エラー処理仲介部５０を備えている。オブジェクト連携検知部４０ａは、オブジェクト障害検知部４１を備えている。オブジェクト障害検知部４１は、オブジェクトの障害を検知する部分である。オブジェクト連携検知部４０ａは、オブジェクト障害検知部４１を用いて、モニタするオブジェクト１００のうち、どのオブジェクトに障害が発生しているかを検知できる構成になっている。なお、障害検知部４１がオブジェクトに発生した障害を検知する方法は特に限定されず、様々な方法が可能である。例えば、障害検知部４１がメッセージ送受信部１０を介して一定間隔で各オブジェクトとの間で、障害問い合わせメッセージと、障害なしを知らせる応答メッセージとを定期的にやり取りする方法や、ネットワーク管理者からの通知を受ける方法などがある。
【００８６】
このようにオブジェクト連携検知部４０ａがオブジェクト障害検知部４１を備える構成とすれば、当初障害が検知されていないオブジェクト１００が、あるメッセージに反応して対応するアクションを実行している間に何らかの障害が発生してしまった事実を検知することができ、エラー処理仲介部５０に対して対応するエラー処理仲介の実行を指示することができる。
【００８７】
例えば、本発明のエラー処理仲介オブジェクトが介在する場合は、図９に示すような処理が可能となる。オブジェクトＡからオブジェクトＢに対して、メッセージ形式１のメッセージをメッセージ形式２のメッセージとするエンコーディングを依頼した場合のエラー処理の仲介を想定する。まず、オブジェクトＡがメッセージをメッセージ形式１からメッセージ形式２にエンコーディングする依頼が出される。エラー仲介オブジェクトは依頼メッセージを検知する（ステップＳ９０１：Ｙ）。当該依頼を受けたオブジェクトＢにおいて何らかの障害が発生しており、メッセージをメッセージ形式１からメッセージ形式２にエンコーディングすることができないとする。オブジェクトＢからオブジェクトＡに対してエンコーディングができない旨のエラーメッセージが返される。エラー処理仲介オブジェクトが介在しない場合はオブジェクトＡ自身が当該エラーメッセージに対するエラー処理を持っていなければならない。しかし、本発明のエラー処理仲介オブジェクトが介在する場合は、エラー処理仲介オブジェクトもオブジェクトＢからのエラーメッセージを受信しており（ステップＳ９０２：Ｙ）、当該エラーメッセージに対するエラー処理を実行する。例えば、依頼を代行処理できるオブジェクトを探知、つまり、メッセージをメッセージ形式１からメッセージ形式２にエンコーディングすることができるオブジェクトを探知し（ステップＳ９０３）、探知したオブジェクトにエンコーディング処理を代行実行させ（ステップＳ９０４）、エンコーディング処理された結果を受け取り、その結果をオブジェクトＢにまたは依頼元のオブジェクトＡに直接返すというエラー処理を実行する（ステップＳ９０５）。このように本発明のエラー処理仲介オブジェクトが介在する場合は、オブジェクトＡ自身がエラーメッセージに対するエラー処理を持っていない場合でもオブジェクト連携においてエラー処理を仲介・実行することができる。
【００８８】
上記の例では、依頼メッセージのエンコーディングができない旨のエラーメッセージが出力された場合、当該エラーメッセージを受信したエラー処理仲介オブジェクトが適切なエンコーダを探知して依頼メッセージのエンコーディング作業を代替依頼し、エンコーディング結果をエラーメッセージを発したオブジェクトまたは依頼を出したオブジェクトに返すことによりエラー処理を仲介し、代替実行して一連の処理を継続して行くことができる。
【００８９】
上記の構成によれば、実施形態１で示したように、依頼に反応したオブジェクトから流される受理メッセージ＜accept1＞などをフィールド４００上に流れるか否かをモニタすることにより正常なオブジェクト連携の実行の有無を検知する必要はなく、障害検知部４１が障害発生を検知したオブジェクトに対する依頼メッセージをモニタした場合には即座に正常なオブジェクト連携が実行できないことが検知できるので、対応するエラーメッセージ＜error1＞などを遅滞なく出力し、エラー処理を仲介することが可能となる。
【００９０】
また、同様に、オブジェクト連携検知部４０ａがオブジェクト障害検知部４１を備える構成とすれば、オブジェクト障害検知部４１により障害が検知されているオブジェクト１００に対してアクションを実行するように求めるメッセージがフィールド４００上に流れたことをメッセージ送受信部１０のモニタにより検知した場合には、オブジェクト連携が正常に行われない結果となることをあらかじめ予見することができ、エラー処理仲介部５０に対して対応するエラー処理仲介の実行を指示することができる。
【００９１】
この場合、エラー処理仲介オブジェクト２００は、モニタした依頼メッセージに対して本来いずれのオブジェクトが応答すべきであるのかを予め把握しておく必要がある。例えば、エラー処理仲介オブジェクト２００はメッセージアクション反応テーブルにおいて、すべての依頼メッセージに反応する入力メッセージパターンを用意しておき、そのアクションとしてモニタして取り込んだ依頼メッセージに対してどのオブジェクトが反応するべきかをチェックするチェックプログラムを起動することにより反応すべきオブジェクトを把握する。
【００９２】
その他の方法としては、オブジェクト同士でCookieに相当する情報を交換し合う場合において、依頼メッセージ中に含まれる当該Cookieに相当する情報を手掛かりとして反応すべきオブジェクトを把握する方法も可能である。Cookieとは、ワールドワイドウェブ（以下、ＷＷＷと略記する）上でユーザを管理を実現する仕組みを言い、ＷＷＷサーバがユーザを識別する識別文字列情報Cookieを生成し、ＷＷＷサーバとブラウザ双方に格納しておき、２回目のアクセス時にはブラウザから当該CookieをＨＴＴＰで送信し、サーバ側に格納されているCookieと照合してユーザを特定する仕組みである。つまり、あるオブジェクトとあるオブジェクトとの１回目のアクセスにおいて、オブジェクトを識別するCookieに相当する識別文字列情報を交換して格納し合い、２回目のアクセス時には当該Cookieに相当する識別文字列情報により相手を特定する仕組みを用いた場合、エラー処理仲介オブジェクトがオブジェクト間で用いられるすべてのCookieに相当する情報を取り込んで管理し、フィールド上を流れるメッセージに含まれるCookieに相当する情報をチェックし、障害が発生しているオブジェクトが連携の一方になっているメッセージと判断すれば、即座に正常なオブジェクト連携が実行できないことを検知できる。
【００９３】
以上、本発明のエラー処理仲介オブジェクトを用いたオブジェクト連携モニタシステムによれば、オブジェクトの障害を検知し、オブジェクト間の正常なオブジェクト連携が実現できないことを予見し、エラー処理が実行されるように仲介することができ、オブジェクト同士の連携に直接含まれていないエラー処理を、エラー処理仲介オブジェクトの働きにより、挿入・追加することができる。
【００９４】
（実施形態３）
本発明のオブジェクト連携モニタシステムおよびオブジェクト連携モニタシステムを用いたオブジェクト連携仲介システムは、上記に説明した構成を実現する処理ステップを記述したプログラムをコンピュータ読み取り可能な記録媒体に記録して提供することにより、各種コンピュータを用いて構築できる。本発明のオブジェクト連携モニタシステムおよびオブジェクト連携モニタを用いたオブジェクト連携仲介システムを実現する処理ステップを備えたプログラムを記録した記録媒体は、図１０に図示した記録媒体の例に示すように、ＣＤ−ＲＯＭ１００２やフレキシブルディスク１００３等の可搬型記録媒体１００１だけでなく、フィールド上にある記録装置内の記録媒体１０００や、コンピュータのハードディスクやＲＡＭ等の記録媒体１００５のいずれであっても良く、プログラム実行時には、プログラムはコンピュータ１００４上にローディングされ、主メモリ上で実行される。
【００９５】
さらに、ソースプログラムをコンパイルしたもののみならず、フィールドを介してクライアントコンピュータに中間言語形式のアプレットを送信し、クライアントコンピュータ上でインタープリタ実行して動作する構成であっても良い。
【００９６】
本発明のオブジェクト連携モニタシステムに関し、以下の項を開示する。
【００９７】
（付記１） フィールド上のオブジェクトのメッセージを介した連携処理の間に、エラー処理を挿入・追加するオブジェクト連携モニタ方法であって、
フィールド上で他のオブジェクトとメッセージをやり取りするメッセージ送受信部と、メッセージの要素とその要素に対するルールとの組を備えたルール判定部と、前記組に従い、受信メッセージにマッチングしたルール内容であるアクションを実行するアクション実行部を備えたオブジェクトがメッセージを介した連携処理を実行し、
フィールド上を流れるメッセージをモニタし、
あるメッセージに対して予定される正常なオブジェクト連携が実行されているか否かを検知し、
正常なオブジェクト連携が実行されていないと検知した場合に前記メッセージを送信したオブジェクトに対するエラー処理仲介を実行し、
前記メッセージを送信したオブジェクトが前記エラー処理仲介を受け、用意されているエラー処理を実行し、正常なオブジェクト連携処理の間にエラー処理を挿入・追加することを特徴とするオブジェクト連携モニタ方法（１）。
【００９８】
（付記２）前記オブジェクト連携検知部が、オブジェクトの障害を検知するオブジェクト障害検知部を備え、前記オブジェクト障害検知部により障害が検知されているオブジェクトが応答すべき依頼メッセージがモニタされた場合、前記エラー処理仲介部が対応するエラー処理仲介を実行する上記付記１に記載のオブジェクト連携モニタシステム（２）。
【００９９】
（付記３）前記オブジェクト連携検知部が、オブジェクトの障害を検知するオブジェクト障害検知部を備え、前記オブジェクト障害検知部が、モニタされた依頼メッセージに応答中のオブジェクトにおける障害を検知した場合、前記エラー処理仲介部が対応するエラー処理仲介を実行する上記付記１に記載のオブジェクト連携モニタシステム（３）。
【０１００】
（付記４）各オブジェクトは、前記ルール判定部に従って前記フィールドからメッセージを受信した場合に、該メッセージのメッセージ要素に反応して受信したことを示す受理メッセージを前記メッセージ送受信部により送信し、
前記エラー処理仲介オブジェクトは、前記ルール判定部において前記受理メッセージのメッセージ要素を組の要素として持ち、該メッセージ要素を持つ受理メッセージが前記メッセージ送受信部から一定時間内に得られない場合、前記エラー処理仲介部が対応するエラーメッセージを前記メッセージ送受信部を介して出力し、
前記メッセージを送信したオブジェクトは、前記ルール判定部において前記エラーメッセージのメッセージ要素を組の要素として持ち、前記エラーメッセージのメッセージ要素に反応してエラーメッセージを取り込み、用意されているエラー処理を実行し、
正常なオブジェクト連携処理の間に、エラー処理を挿入・追加した上記付記１に記載のオブジェクト連携モニタシステム（４）。
【０１０１】
（付記５）前記エラー処理仲介において、前記メッセージに対するエラーメッセージを検知し、前記エラーメッセージに対するエラー処理を代行処理できるオブジェクトを探知し、探知したオブジェクトにエラー処理を代行実行させることにより、エラー処理を仲介する上記付記１に記載のオブジェクト連携モニタ方法。
【０１０２】
（付記６）フィールド上のオブジェクトのメッセージを介した連携処理の間に、エラー処理を挿入・追加する方法であって、
フィールド上で他のオブジェクトとメッセージをやり取りするメッセージ送受信部と、メッセージの要素とその要素に対するルールとの組を備えたルール判定部と、前記組に従い、受信メッセージにマッチングしたルール内容であるアクションを実行するアクション実行部を備えたオブジェクトがメッセージを介した連携処理を実行し、
フィールド上を流れるメッセージをモニタし、
あるメッセージに対して予定される正常なオブジェクト連携が実行されているか否かを検知し、
正常なオブジェクト連携が実行されていないと検知した場合に前記メッセージを送信したオブジェクトに対するエラー処理仲介を実行し、
前記メッセージを送信したオブジェクトが前記エラー処理仲介を受け、用意されているエラー処理を実行し、正常なオブジェクト連携処理の間にエラー処理を挿入・追加することを特徴とするオブジェクト連携モニタ方法（５）。
【０１０３】
（付記７）フィールド上のオブジェクトのメッセージを介した連携処理の間に、エラー処理を挿入・追加する処理プログラムを記録したコンピュータ読み取り可能な記録媒体であって、
フィールド上で他のオブジェクトとメッセージをやり取りするメッセージ送受信部と、メッセージの要素とその要素に対するルールとの組を備えたルール判定部と、前記組に従い、受信メッセージにマッチングしたルール内容であるアクションを実行するアクション実行部を備えたオブジェクト間におけるメッセージを介した連携処理を実行する処理ステップと、
フィールド上を流れるメッセージをモニタする処理ステップと、
あるメッセージに対して予定される正常なオブジェクト連携が実行されているか否かを検知する処理ステップと、
正常なオブジェクト連携が実行されていないと検知した場合に前記メッセージを送信したオブジェクトに対するエラー処理仲介を実行する処理ステップと、
前記メッセージを送信したオブジェクトにおいて、前記エラー処理仲介を受け、用意されているエラー処理を実行する処理ステップを記録した処理プログラムを記録したことを特徴とする記録媒体。
【０１０４】
【発明の効果】
本発明のエラー処理仲介オブジェクトを用いたオブジェクト連携モニタシステムによれば、オブジェクトの障害によりオブジェクト間の正常なオブジェクト連携が実現できない場合、エラー処理仲介オブジェクトにより、オブジェクトにおいてエラー処理が実行されるように仲介することができ、オブジェクト同士の連携に直接含まれていないエラー処理を、エラー処理仲介オブジェクトの働きにより、挿入・追加することができる。
【０１０５】
また、本発明のエラー処理仲介オブジェクトを用いたオブジェクト連携モニタシステムによれば、オブジェクトの障害を検知し、オブジェクト間の正常なオブジェクト連携が実現できないことを予見し、エラー処理が実行されるように仲介することができ、オブジェクト同士の連携に直接含まれていないエラー処理を、エラー処理仲介オブジェクトの働きにより、挿入・追加することができる。
【図面の簡単な説明】
【図１】 本発明のオブジェクト連携モニタシステムが前提とするフィールドリアクターモデルに基づくオブジェクト間の緩やかな連携を模式的に示した図
【図２】 フィールドリアクターモデルに基づくオブジェクトの概略構成例を示す図
【図３】 フィールドリアクターモデルに基づくオブジェクト連携システムの入力メッセージ構造の例を示す図
【図４】 本発明のエラー処理仲介オブジェクトを用いたオブジェクト連携モニタシステムの動作を模式的に示した図である。
【図５】 本発明の実施形態１のオブジェクト連携モニタシステムの構成例を示す図
【図６】 本発明の実施形態１のオブジェクト連携モニタシステムのエラー処理仲介の動作を模式的に示した図
【図７】 実施形態１のオブジェクト連携モニタシステムの動作例を示したフローチャート
【図８】 実施形態２のオブジェクト連携モニタシステムの構成例を示す図
【図９】 実施形態２のオブジェクト連携モニタシステムによりオブジェクトに障害が発生した場合のエラー処理仲介の動作の流れを示すフローチャート
【図１０】 実施形態３におけるオブジェクト連携モニタシステムを実現する処理プログラムを記録した記録媒体の例を示す図
【図１１】 従来技術のＣＯＲＢＡに基づいたクライアント／サーバシステムにおけるオブジェクト連携の例を示す図
【符号の説明】
１０ メッセージ送受信部
２０ メッセージ・アクション反応テーブル
３０ アクション実行部
３１ メッセージ生成部
４０ オブジェクト連携検知部
４１ 障害検知部
５０ エラー処理仲介部
１００，１００ｂ オブジェクト
２００ エラー処理仲介オブジェクト
４００ フィールド
１０００ 記録装置内の記録媒体
１００１ 可搬型記録媒体
１００２ ＣＤ−ＲＯＭ
１００３ フレキシブルディスク
１００４ コンピュータ
１００５ コンピュータのハードディスクやＲＡＭ等の記録媒体
Claims (5)
- 複数のオブジェクト間の連携を管理するシステムであって、
フィールド上で他のオブジェクトとメッセージをやり取りするメッセージ送受信部と、
メッセージの要素とその要素に対するルールとの組を有するルール判定部と、
前記組に従い、受信メッセージにマッチングしたルール内容であるアクションを実行する前記アクション実行部と、
前記メッセージ送受信部を介して前記ルール判定部が有するメッセージの要素にマッチングするメッセージを取り込むことで、前記フィールド上を流れるメッセージをモニタし、あるメッセージに対して予定される正常なオブジェクト連携が実行されているか否かを検知するオブジェクト連携検知部と、
前記オブジェクト連携検知部が正常なオブジェクト連携が実行されていないと検知した場合に対応するエラーメッセージを前記フィールドへ出力してエラー処理の仲介を実行するエラー処理仲介部を有するエラー処理仲介オブジェクトを備え、
前記エラー処理仲介オブジェクトの前記ルール判定部は、前記フィールド上のオブジェクトが、前記フィールドを流れる依頼メッセージを該依頼メッセージのメッセージ要素に正常に反応して受信した場合に前記フィールドに対して送信する受理メッセージのメッセージ要素を組の要素として持ち、
前記エラー処理仲介オブジェクトの前記オブジェクト連携検知部は、前記受理メッセージが前記メッセージ送受信部から、前記依頼メッセージを検知してから一定時間内に得られない場合に、前記オブジェクトでは正常なオブジェクト連携が実行されていないことを検知し、
前記エラー処理仲介部は、前記対応するエラーメッセージを前記フィールドへ出力することによって、前記エラーメッセージのメッセージ要素を組の要素としてルール判定部において持つ前記フィールド上のオブジェクトに、前記エラーメッセージのメッセージ要素に反応することにより前記エラーメッセージを前記フィールドから取り込ませ、前記エラー処理を実行させることを特徴とするオブジェクト連携モニタシステム。 - 前記オブジェクト連携検知部が、オブジェクトの障害を検知するオブジェクト障害検知部を備え、前記オブジェクト障害検知部により障害が検知されているオブジェクトが応答すべき依頼メッセージがモニタされた場合、前記エラー処理仲介部が対応するエラー処理仲介を実行する請求項１に記載のオブジェクト連携モニタシステム。
- 前記オブジェクト連携検知部が、オブジェクトの障害を検知するオブジェクト障害検知部を備え、前記オブジェクト障害検知部が、モニタされた依頼メッセージに応答中のオブジェクトにおける障害を検知した場合、前記エラー処理仲介部が対応するエラー処理仲介を実行する請求項１に記載のオブジェクト連携モニタシステム。
- 各オブジェクトは、前記ルール判定部に従って前記フィールドからメッセージを受信した場合に、該メッセージのメッセージ要素に反応して受信したことを示す受理メッセージを前記メッセージ送受信部により送信し、
前記エラー処理仲介オブジェクトは、前記ルール判定部において前記受理メッセージのメッセージ要素を組の要素として持ち、該メッセージ要素を持つ受理メッセージが前記メッセージ送受信部から、前記依頼メッセージを検知してから一定時間内に得られない場合、前記エラー処理仲介部が対応するエラーメッセージを前記メッセージ送受信部を介して出力し、
前記依頼メッセージを送信したオブジェクトは、前記ルール判定部において前記エラーメッセージのメッセージ要素を組の要素として持ち、前記エラーメッセージのメッセージ要素に反応してエラーメッセージを取り込み、用意されているエラー処理を実行し、
正常なオブジェクト連携処理の間に、エラー処理を挿入・追加した請求項１に記載のオブジェクト連携モニタシステム。 - フィールド上の複数のオブジェクトがメッセージを送受信して連携処理を実行する間に、コンピュータを用いて、エラー処理仲介オブジェクトにエラー処理を挿入・追加させる方法であって、
エラー処理仲介オブジェクトが、前記フィールド上で他のオブジェクトとメッセージを送信または受信するステップと、
エラー処理仲介オブジェクトが、メッセージの要素とその要素に対するルールとの組を有するルール判定部における前記組に従い、受信メッセージにマッチングしたルール内容であるアクションを実行するステップと、
エラー処理仲介オブジェクトが、前記フィールド上を流れる前記メッセージから前記ルール判定部が有するメッセージ要素にマッチングするメッセージを取り込むことにで、前記フィールド上を流れる前記メッセージをモニタするステップと、
エラー処理仲介オブジェクトが、あるメッセージに対して予定される正常なオブジェクト連携が実行されているか否かを検知するステップと、
エラー処理仲介オブジェクトが、正常なオブジェクト連携が実行されていないと検知した場合に、対応するエラーメッセージを前記フィールド上へ出力することにより、前記メッセージを送信したオブジェクトに対するエラー処理仲介を実行するステップと、
前記フィールド上のオブジェクトが前記エラー処理仲介を受け、用意されているエラー処理を実行し、正常なオブジェクト連携処理の間にエラー処理を挿入・追加するステップを含み、
前記エラー処理仲介オブジェクトの前記ルール判定部は、前記フィールド上のオブジェクトが、前記フィールドを流れる依頼メッセージを該依頼メッセージのメッセージ要素に正常に反応して受信した場合に前記フィールドに対して送信する受理メッセージのメッセージ要素を組の要素として持ち、
前記エラー処理仲介オブジェクトは、前記受理メッセージが前記依頼メッセージを検知してから一定時間内に得られない場合に、正常なオブジェクト連携が実行されていないことを検知し、
前記エラー処理仲介オブジェクトが、前記対応するエラーメッセージを前記フィールドへ出力することによって、前記エラーメッセージのメッセージ要素を組の要素としてルール判定部において持つ前記フィールド上のオブジェクトは、前記エラーメッセージのメッセージ要素に反応することにより前記エラーメッセージを前記フィールドから取り込み、前記エラー処理を実行することを特徴とするオブジェクト連携モニタ方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000289299A JP4266507B2 (ja) | 2000-09-22 | 2000-09-22 | オブジェクト連携モニタシステム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000289299A JP4266507B2 (ja) | 2000-09-22 | 2000-09-22 | オブジェクト連携モニタシステム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002099438A JP2002099438A (ja) | 2002-04-05 |
| JP4266507B2 true JP4266507B2 (ja) | 2009-05-20 |
Family
ID=18772727
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000289299A Expired - Fee Related JP4266507B2 (ja) | 2000-09-22 | 2000-09-22 | オブジェクト連携モニタシステム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4266507B2 (ja) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007034896A (ja) * | 2005-07-29 | 2007-02-08 | Toppan Printing Co Ltd | データ状態管理システム、方法、及びプログラム |
| JP5067075B2 (ja) * | 2007-08-29 | 2012-11-07 | 日本電気株式会社 | 疎結合システム、待機系排他制御装置、疎結合システムのリカバリ方法、プログラムおよび記憶媒体 |
-
2000
- 2000-09-22 JP JP2000289299A patent/JP4266507B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2002099438A (ja) | 2002-04-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP5894724B2 (ja) | グラフ型計算の分散サービス | |
| Adacal et al. | Mobile web services: a new agent-based framework | |
| US20060085361A1 (en) | Anomaly detector in a health care system using adapter | |
| Parekh et al. | Retrofitting autonomic capabilities onto legacy systems | |
| US7500251B2 (en) | Method and system for managing programs for web service system | |
| JP4125005B2 (ja) | メッセージの型を利用するオブジェクト連携装置 | |
| Gross et al. | An active events model for systems monitoring | |
| Hellerstein et al. | ETE: A customizable approach to measuring end-to-end response times and their components in distributed systems | |
| May et al. | An RPC design for wireless sensor networks | |
| JP4266507B2 (ja) | オブジェクト連携モニタシステム | |
| CA2561640A1 (en) | Inter-agent communication | |
| EP1730684A1 (en) | Distributed computer | |
| Ezenwoye et al. | A Proxy-Based Approach to Enhancing the Autonomic Behavior in Composite Services. | |
| JP4145477B2 (ja) | オブジェクト連携装置 | |
| Rademacher et al. | Design of a domain-specific language based on a technology-independent web service framework | |
| JP4363752B2 (ja) | リバースプロキシーシステム | |
| Brogi et al. | A service-oriented model for embedded peer-to-peer systems | |
| KR101270746B1 (ko) | 웹 서비스 중개 장치 및 방법 | |
| JP4550085B2 (ja) | メッセージの型を利用するオブジェクト連携装置 | |
| CN103748858B (zh) | 灵活的数据通信 | |
| Lall et al. | Evaluating the second generation Web services specifications for satisfying non-functional requirements | |
| CN116233250B (zh) | 一种服务调用方法及网关设备 | |
| US20060085376A1 (en) | Centralized management of software adapters | |
| JP2001067325A (ja) | 分散オブジェクト管理方法およびシステム | |
| Kolb | Realization of eai patterns with apache camel |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060626 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20080421 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080508 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080707 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20080821 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20081022 |
|
| A911 | Transfer of reconsideration by examiner before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20081028 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20081211 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090116 |
|
| 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: 20090210 |
|
| 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: 20090217 |
|
| 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: 20120227 Year of fee payment: 3 |
|
| LAPS | Cancellation because of no payment of annual fees |