(57)【特許請求の範囲】
【請求項１】
ネットワーク化された分散システム上に構築され、エラー処理の機能を有するとともに、前記ネットワーク化分散システムが、クライアントと、複数のサービスプロバイダと、コミュニティとを含み、前記コミュニティが、ルックアップサービスとジェネリック・エバリュエータとを含む、総合サービス管理システムであって、
サービスプロバイダがサービスプロバイダ自身の情報をそれぞれコミュニティに提供するためのレジストレーション・スキームを実行する手段と、コミュニティ内に記憶された情報を検索してサービスプロバイダの選定を行うためのサーチ・アンド・エグゼキューション・スキームを実行する手段と、実行時のエラーの発生を検出し、エラーを生じたサービスプロバイダを他のサービスプロバイダと置換するためのディテクション・アンド・リプレースメント・スキームを実行する手段とを含み、
前記レジストレーション・スキームを実行する手段が、
前記複数のサービスプロバイダのそれぞれが、前記コミュニティを発見するステップを実行する手段と、
前記コミュニティが、前記ルックアップサービスを、前記コミュニティを発見するステップにおいてコミュニティを発見した前記複数のサービスプロバイダに提供するステップを実行する手段と、
前記複数のサービスプロバイダが、複数のコントラクトを、前記コミュニティの前記ルックアップサービスに提供するステップを実行する手段と、
前記コミュニティが、前記複数のサービスプロバイダのそれぞれについてレジストレーションを開始するステップを実行する手段と、
前記コミュニティが、前記複数のサービスプロバイダの前記コントラクトを発行するステップを実行する手段と、
前記サービスプロバイダが、前記複数のコントラクトのそれぞれのコントラクト項目を設定してジェネリック・エバリュエータに送出するステップを実行する手段と、
前記ジェネリック・エバリュエータが、前記複数のサービスプロバイダのそれぞれのクレジット値に、デフォールト値を設定し、かつ前記複数のコントラクトのコントラクト項目と前記複数のサービスプロバイダのそれぞれの前記クレジット値とを、コミュニティ内のデータベースに記憶させ、それによって前記複数のサービスプロバイダのそれぞれをモニタするステップを実行する手段とを含み、
前記サーチ・アンド・エグゼキューション・スキームを実行する手段が、
前記クライアントが、前記コミュニティを発見するステップを実行する手段と、
所望のサービスプロバイダを発見するために、前記コミュニティによって、サーチングサービスおよび前記複数のコントラクトのそれぞれの内容を、前記コミュニティを発見したクライアントに提供するステップを実行する手段と、
前記クライアントが、前記複数のコントラクトのそれぞれの内容および該コントラクトを提供した前記サービスプロバイダのクレジット値を検査するステップを実行する手段と、
前記クライアントが、所望のコントラクトが取得されたかどうかを検査し、結果が「ノー」である場合に、クライアントによるサーチングの実行を停止するステップを実行する手段と、
前記所望のコントラクトが取得されたかどうかの検査の結果が「イエス」の場合には、前記クライアントが、前記複数のサービスプロバイダから第１サービスプロバイダを選定するステップを実行する手段と、
前記第１サービスプロバイダの少なくとも１つのプロキシをコミュニティのルックアップサービスからダウンロードするステップを実行する手段と、
前記クライアントによって、サービスプロバイダを選択する手段を実行するのが１回目であるかどうかを検査するステップを実行する手段と、
サービスプロバイダを選択する手段を実行するのが１回目であるかどうかの前記検査の結果が「イエス」であれば、前記クライアントが、前記第１サービスプロバイダからサービスを要求するステップを実行する手段と、
前記第１サービスプロバイダが、前記クライアントからのサービス要求に応答して、所望のサービスを準備して、前記ジェネリック・エバリュエータの少なくとも１つのスレッドの起動を実行するステップを実行する手段と、
前記ジェネリック・エバリュエータが、前記少なくとも１つのスレッドを実行し、周期的に第１サービスプロバイダの実行状態のバックアップを前記データベースに作成するステップを実行する手段と、
前記ジェネリック・エバリュエータの前記少なくとも１つのスレッドが、前記第１サービスプロバイダによって提供されるサービスを検査するステップを実行する手段と、
前記第１サービスプロバイダのサービスを検査する前記手段がエラーを発見しないか、または前記第１サービスプロバイダが正常に実行した場合に、前記ジェネリック・エバリュエータが、第１サービスプロバイダの前記クレジット値を増加させるステップを実行する手段と、
前記クレジット値を増加させる手段を実行した後に、コミュニティが、前記ジェネリック・エバリュエータの前記少なくとも１つのスレッドを終了させるステップを実行する手段とを含み、
前記ディテクション・アンド・リプレースメント・スキームが、
前記第１サービスプロバイダに実行のエラーが発生した場合に、前記ジェネリック・エバリュエータが、例外イベントを検出して警告を送出するステップを実行する手段と、
前記ジェネリック・エバリュエータが、前記警告を送出する手段を実行した後に、前記第１サービスプロバイダのクレジット値を減少させるステップを実行する手段と、
前記コミュニティが、前記クレジット値を減少させる手段を実行した後に、前記ジェネリック・エバリュエータの前記少なくとも１つのスレッドを終了させる前記ステップを実行する手段と、
前記コミュニティが、前記警告を送出する手段を実行した後に、実行時にエラーが発生した第１サービスプロバイダの置換の実行を開始し、次いで前記サーチ・アンド・エグゼキューション・スキームの上記ステップを反復して、少なくとも１つの第２サービスプロバイダを取得するステップを実行する手段と、
前記クライアントが、エラーが発生する直前に保存されたバックアップデータを取得するステップを実行する手段と、
前記クライアントが、前記バックアップデータを前記少なくとも１つの第２サービスプロバイダに設定して、前記所望のサービスの要求を開始するステップを実行する手段とを含む、前記総合サービス管理システム。
【請求項２】
ジェネリック・エバリュエータがクレジット関数を含み、前記クレジット関数が、
報奨関数であって、前記複数のサービスプロバイダが正常に実行されたとき、前記ジェネリック・エバリュエータが、該報奨関数にしたがって、前記複数のサービスプロバイダに対する前記複数のクレジット値を増加させる、前記報奨関数と、
懲罰関数であって、前記複数のサービスプロバイダに実行異常が発生したときに、前記ジェネリック・エバリュエータが、該懲罰関数にしたがって、前記複数のサービスプロバイダに対する前記複数のクレジット値を減少させる、前記懲罰関数とを含む、請求項１に記載の総合サービス管理システム。
【請求項３】
ネットワーク化された分散システム上に構築され、エラー処理の機能を有するとともに、前記ネットワーク化分散システムが、クライアントと、複数のサービスプロバイダと、コミュニティとを含み、前記コミュニティが、ルックアップサービスとジェネリック・エバリュエータとを含む、総合サービス管理システムの管理方法であって、
サービスプロバイダがサービスプロバイダ自身の情報をそれぞれコミュニティに提供するためのレジストレーション・スキームと、コミュニティ内に記憶された情報を検索してサービスプロバイダの選定を行うためのサーチ・アンド・エグゼキューション・スキームと、実行時のエラーの発生を検出し、エラーを生じたサービスプロバイダを他のサービスプロバイダと置換するためのディテクション・アンド・リプレースメント・スキームとを含み、
前記レジストレーション・スキームが、
前記複数のサービスプロバイダのそれぞれが、前記コミュニティを発見するステップと、
前記コミュニティが、前記ルックアップサービスを、前記コミュニティを発見するステップにおいてコミュニティを発見した前記複数のサービスプロバイダに提供するステップと、
前記複数のサービスプロバイダが、複数のコントラクトを、前記コミュニティの前記ルックアップサービスに提供するステップと、
前記コミュニティが、前記複数のサービスプロバイダのそれぞれについてレジストレーションを開始するステップと、
前記コミュニティが、前記複数のサービスプロバイダの前記コントラクトを発行するステップと、
前記サービスプロバイダが、前記複数のコントラクトのそれぞれのコントラクト項目を設定してジェネリック・エバリュエータに送出するステップと、
前記ジェネリック・エバリュエータが、前記複数のサービスプロバイダのそれぞれのクレジット値に、デフォールト値を設定し、かつ前記複数のコントラクトのコントラクト項目と前記複数のサービスプロバイダのそれぞれの前記クレジット値とを、コミュニティ内のデータベースに記憶させ、それによって前記複数のサービスプロバイダのそれぞれをモニタするステップとを含み、
前記サーチ・アンド・エグゼキューション・スキームが、
前記クライアントが、前記コミュニティを発見するステップと、
所望のサービスプロバイダを発見するために、前記コミュニティによって、サーチングサービスおよび前記複数のコントラクトのそれぞれの内容を、前記コミュニティを発見したクライアントに提供するステップと、
前記クライアントが、前記複数のコントラクトのそれぞれの内容および該コントラクトを提供した前記サービスプロバイダのクレジット値を検査するステップと、
前記クライアントが、所望のコントラクトが取得されたかどうかを検査し、結果が「ノー」である場合に、クライアントによるサーチングの実行を停止するステップと、
前記所望のコントラクトが取得されたかどうかの検査の結果が「イエス」の場合には、前記クライアントが、前記複数のサービスプロバイダから第１サービスプロバイダを選定するステップと、
前記第１サービスプロバイダの少なくとも１つのプロキシをコミュニティのルックアップサービスからダウンロードするステップと、
前記クライアントによって、サービスプロバイダを選択するのが１回目であるかどうかを検査するステップを実行する手段と、
サービスプロバイダを選択するのが１回目であるかどうかの前記検査の結果が「イエス」であれば、前記クライアントが、前記第１サービスプロバイダからサービスを要求するステップと、
前記第１サービスプロバイダが、前記クライアントからのサービス要求に応答して、所望のサービスを準備して、前記ジェネリック・エバリュエータの少なくとも１つのスレッドの起動を実行するステップと、
前記ジェネリック・エバリュエータが、前記少なくとも１つのスレッドを実行し、周期的に第１サービスプロバイダの実行状態のバックアップを前記データベースに作成するステップと、
前記ジェネリック・エバリュエータの前記少なくとも１つのスレッドが、前記第１サービスプロバイダによって提供されるサービスを検査するステップと、
前記第１サービスプロバイダのサービスを検査する前記ステップがエラーを発見しないか、または前記第１サービスプロバイダが正常に実行した場合に、前記ジェネリック・エバリュエータが、第１サービスプロバイダの前記クレジット値を増加させるステップと、
前記クレジット値を増加させるステップの後に、コミュニティが、前記ジェネリック・エバリュエータの前記少なくとも１つのスレッドを終了させるステップとを含み、
前記ディテクション・アンド・リプレースメント・スキームが、
前記第１サービスプロバイダに実行のエラーが発生した場合に、前記ジェネリック・エバリュエータが、例外イベントを検出して警告を送出するステップと、
前記ジェネリック・エバリュエータが、前記警告を送出するステップの後に、前記第１サービスプロバイダのクレジット値を減少させるステップと、
前記コミュニティが、前記クレジット値を減少させるステップの後に、前記ジェネリック・エバリュエータの前記少なくとも１つのスレッドを終了させる前記ステップを実行するステップと、
前記コミュニティが、前記警告を送出するステップの後に、実行時にエラーが発生した第１サービスプロバイダの置換の実行を開始し、次いで前記サーチ・アンド・エグゼキューション・スキームの上記ステップを反復して、少なくとも１つの第２サービスプロバイダを取得するステップと、
前記クライアントが、エラーが発生する直前に保存されたバックアップデータを取得するステップと、
前記クライアントが、前記バックアップデータを前記少なくとも１つの第２サービスプロバイダに設定して、前記所望のサービスの要求を開始するステップとを含む、前記総合サービス管理システム。
【請求項４】
ジェネリック・エバリュエータがクレジット関数を含み、前記クレジット関数が、
報奨関数であって、前記複数のサービスプロバイダが正常に実行されたとき、前記ジェネリック・エバリュエータが、該報奨関数にしたがって、前記複数のサービスプロバイダに対する前記複数のクレジット値を増加させる、前記報奨関数と、
懲罰関数であって、前記複数のサービスプロバイダに実行異常が発生したときに、前記ジェネリック・エバリュエータが、該懲罰関数にしたがって、前記複数のサービスプロバイダに対する前記複数のクレジット値を減少させる、前記懲罰関数とを含む、請求項３に記載の総合サービス管理システム。
【発明の詳細な説明】
【０００１】
【産業上の利用分野】
本発明は、一般的には総合サービス管理システムに関し、より具体的にはエラー検出および機能交換の機能を有する総合サービス管理システムに関する。
【０００２】
【従来の技術】
ネットワーク時代の到来によって、分散オブジェクト指向技術に基づいてソフトウエアを構築することが益々一般化している。ソフトウエアシステム開発会社は、ソフトウエアシステムの信頼性を向上させること、異常状態のサービスプロバイダを検出すること、および未完のジョブを実行するために、この異常サービスプロバイダを、予備サービスプロバイダなどで遅れなく置換するという目的に多大の労力を費やしている。半導体生産システムなどの生産システムの精度要求および設備コストが増大するにつれて、半導体設備マネジャなどのサービスプロバイダは通常、複数の設備を同時に制御し、全半導体製造工程が１つの連続工程となっている。このため、エラー発生の直後から未完のジョブを継続して実行するため、異常半導体設備マネジャを置換しなければ、莫大な生産ロスを発生させることになる。
【０００３】
これまで数人の研究者が、個々のアプリケーションソフトウエアの信頼性の改善方法を報告している。例えば、メイヤ(Mayer)（非特許文献１および２参照）は、クライアントとサービスプロバイダとの間の相互合意を表すために、デザイン・バイ・コントラクト（design by contract）の手法を用いることによって、従来式の防御型プログラミングを代替して例外処理を容易化すると共にバグを減少させることを提案している。その後の研究において、多くの研究者が、コントラクトの概念を現行のソフトウエア開発環境に応用しており、例えば、統合モデリング言語（UML：Unified Modeling Language）を用いて、オブジェクト指向分析および設計のアプリケーション中にコントラクトを記述すること、ジャバ(Java(登録商標))プログラミングのアプリケーション中でJava(登録商標)によりコントラクトを実行すること、またフレームワークの設計にコントラクトを応用することなどが行われている。ミッチェル(Mitchell), ハウス(Howse) およびハミエ (Hamie) (非特許文献３)によると、仕様（specification）をコントラクトに変換する方法が示されており、この方法では、コントラクト指向仕様を用いて、従来型の等式仕様（equational specification）を表し、プログラム中のコントラクトを表すための方法に直接マッピングすることによって、通常の仕様をコントラクトに直接的に変換することができる。
【０００４】
さらに、他のいくつかの研究においては、やはりアプリケーションプロセスの信頼性と回復性とを向上させる方法が開発されている。例えば、ファストウォッチ(FirstWatch) (非特許文献４)、ワッチド(Watchd) (非特許文献５)、およびウォルフパック(Wolfpack) (非特許文献６)はすべて、個々のアプリケーションプログラムの信頼性を向上させるツールを提供したが、分散オブジェクト指向技術によって構築されるソフトウエアシステム全体の信頼性を対象にしていない。
【０００５】
分散オブジェクト指向システムの全体的な信頼性および安定性を向上させる分野では、オスマン(Osman) およびバーギエラ (Bargiela) (非特許文献７) は、分散アプリケーションプログラムの実行信頼性を促進するＦＡＤＩ環境を提供している。このＦＡＤＩでは、ユーザプロセスの故障およびノードクラッシュをモニタすることによってエラーの発生を検出することが可能であると共に、エラーが発生する以前に記憶させたバックアップデータを検索する回復動作のために、非ブロック化チェックポイント・メカニズム（non-blocking checkpoint mechanism）が提供される。ＦＡＤＩはいかなるオブジェクト指向技術にも好適であるが、プロセッサノードのクラッシュおよびハードウエアの一時故障のみが検出可能であり、通信リンクの欠陥の中には、例えば不適切メッセージの配信、誤ったノードへのメッセージ転送など検出できないものがある。またＦＡＤＩには、エラーが発生する以前にアプリケーションプロセスの状態をバックアップすると共に復元するために非ブロック化チェックポイント・ポリスが実装される。バックアップは、故障ノードが修理する場合に使用される。しかし、ＦＡＤＩは故障したノードを置換するためのスペアノードを準備しない。したがって、故障ノードが自力で回復しない限り、システムは継続して作動することができない。
【０００６】
ジニ(Jini)テクノロジ（非特許文献８）はサービスプロバイダのグループを連合させるソフトウエアである。連合とは、部分間の緩やかな協調を意味し、ネットワークからサービスプロバイダを自由に追加または削除することができる。サービスプロバイダが存在する場合には、任意の関係者がこれを使用することができる。しかし、サービスプロバイダが突然に終了した場合には、このことによって、その他のサービスプロバイダのいかなる種類の破局故障をも発生することはなく、そのサービスプロバイダが使用から除外される。Jiniは、ディスカバリ（Discovery）、ルックアップ（Lookup）、リーシング（Leasing）、イベント（Event）サービスを提供する。ディスカバリサービスは、Jiniの自発的コミュニティ構築機能（spontaneous community-building capability）をサポートする。ルックアップサービスは、クライアントが、所望のサービスプロバイダを探索することを可能にする。リーシングサービスは、Jiniの自己回復（self-healing）をサポートする。しかしJiniが、所望のサービス管理システムの要件に合致するためには、まだいくつかの機能的な拡張が必要である。これらの拡張機能を以下に示す。リーシングサービスは、サービスプロバイダがクラッシュしているかどうかを検出するのに使用できるが、その他の異常挙動（性能低下や、誤った内容を含むメッセージの配信など）はリーシングによっては検出できない。ルックアップサービスは、所望のサービスプロバイダを探索するのに応用できるが、サービスプロバイダ間の信頼度レベル（level of confidence）を区別することはできない。またJiniは、故障前に実行状態とパラメータを記録するバックアップスキームを備えていない。
【０００７】
既存の特許に関しては、分散システム内で転送されたメッセージが正しいかどうかを検出し、メッセージが誤っている場合には、送信側にメッセージ再転送することを依頼することによりシステム信頼性を改善する、インテリジェント・エージェントを提案するものがある（特許文献１）。しかし同特許（特許文献１）においては、受信側のメンバにシステムクラッシュなどの故障が発生している場合には、送信側がメッセージを再送信しても自力で正常復帰することはできない。また同特許（特許文献１）にしたがって構築された分散オブジェント指向システムまたは環境においては、異常メンバをバックアップかつ置換する機能がなく、したがってシステム内のサービスプロバイダが異常である場合に、クライアントは、システム内の別の正常なサービスプロバイダを自由に選択することによって、その故障したものを置換することができない。
【０００８】
その他の既存特許については、マザーボードの動作に応用された特許（特許文献２）は、コンピュータメインユニット内の無効なハードウエアを回復する方法を提供している。システムバス中に多数の処理ボードを設けることによって、処理ボードの１つにエラーが発生すると、別の処理ボードが発見されて、無効な処理ボードを代替することが記載されている。コンピュータハードウエアシステムに応用された別の特許（特許文献３参照）では、データ処理システムの各メンバに、１つから数個のバックアップメンバを実装するステップと、実行中のメンバが異常であるかどうかを、ウォッチドッグ回路から送信されるメッセージから判定するステップと、次いで継続実行のためにジョブをバックアップメンバに移管するステップとを含む方法が提案されている。宇宙船技術に応用された特許（特許文献４参照）においては、無効なハードウエアを代替するソフトウエアを使用して、宇宙船内の異常要素を部分的に置換し、宇宙船が任務を達成できるようにする方法が提案されている。ネットワーク伝送技術に応用された特許（特許文献５参照）では、メッセージ伝送を継続するために、混雑度の少ない経路を自動的に選択することによって故障経路を置換する方法が提案されている。別の特許（特許文献６参照）には、ディスクアレイシステムを使用し、ハードディスク中に記憶させたデータの多重バックアップを作成することによって、データアクセスに対するエラー許容性を改善する方法が記載されている。しかしながら、前記のいずれの特許も、分散オブジェクト指向システムの全体信頼性を向上させるために設計されてはいない。
【０００９】
【特許文献１】
米国特許第６２１２６４９号明細書
【特許文献２】
米国特許第５８１２７５７号明細書
【特許文献３】
米国特許第５５０２８１２号明細書
【特許文献４】
米国特許第６１２８５５５号明細書
【特許文献５】
米国特許第６１２２７５３号明細書
【特許文献６】
米国特許第５８４８２２９号明細書
【非特許文献１】
「デザイン・バイ・コントラクトの応用（Applying “Design by Contract”）」、アイ・トリプル・イー・コンピュータ（IEEE Computer）、１９９２年１０月、第２５巻、第１０号、ｐ．４０−５１
【非特許文献２】
［オブジェクト・オリエンティッド・ソフトウエアの構築（Object-Oriented Software Construction）、プレンティス・ホール（Prentice Hall）、米国、ニュージャージ、１９９７年
【非特許文献３】
ミッチェル、ハウス、ハミー著（R. Mitchell, J. Howse, and A. Hamie）、「コントラクト・オリエンティッド・スペシフィケーション（Contract-Oriented Specifications）」、アイ・トリプル・イー・プロシーディングス・オフ・テクノロジ・オフ・オブジェクト・オリエンティッド・ランゲッジズ（IEEE Proceedings of Technology of Object-Oriented Languages）」、１９９８年、ｐ１３１−１４０
【非特許文献４】
ベリタス（Veritas）、「ベリタス・ファーストウォッチ（Veritas FirstWatch）」
【非特許文献５】
フアン、キンタラ著（Y. Huang and C. Kintala）、「ソフトウエア・インプレメンティッド・フォールト・トレランス：テクノロジー・アンド・イクスペリエンス（Software Implemented Fault Tolerance: Technologies and Experience）」、第２３回インターナショナル・シンポジウム・オン・フォールト・トレランス・コンピューティング（ＦＴＣＳ）（the 23rd International Symposium on Fault-tolerance Computing (FTCS)）」、フランス、ツールーズ、１９９３年６月、ｐ２−１０
【非特許文献６】
エム・エス・シー・エス（MSCS）、「マイクロソフト・ＮＴ・サーバー・エディション（Microsoft NT Server Edition）」
【非特許文献７】
オスマン、バージェラ著（T. Osman and A. Bargiela）、「ＦＡＤＩ：オープン分散コンピューティングのためのフォールト・トレラント・エンバイロメント（FADI: A Fault Tolerant Environment for Open Distributed Computing）」、アイ・トリプル・イー・プロシーディングス・オフ・ソフトウエア（IEEE Proceedings of Software）、２０００年６月、第１４７巻、第３号、ｐ９１−９３
【非特許文献８】
アーノルドら著（K. Arnord, B. O'sullivan, R.W. Sheifler, J. Waldo, A. Wollrath）、「ザ・ジニー・スペシフィケーション（The Jini Specification）」、アディソン・ウエスレー（Adison-Wesley）、１９９９年
【００１０】
【発明が解決しようとする課題】
したがって、システム中の無効なサービスプロバイダを検出、かつ置換することによって、無効なプロバイダが除去された時点から、未完のジョブを継続することを可能にするために、エラー検出と機能代替の機能を有する総合サービス管理システムを早急に開発するニーズがある。
【００１１】
【課題を解決するための手段】
前述の方法から考察すると、これらの技術は個々のアプリケーションプログラムの信頼性を向上させるだけのものであり、分散オブジェクト指向技術で構築されるソフトウエアシステムの全体的な信頼性を向上させることはできない。また異常オブジェクトが自発的に回復できない限りは、システムが継続して作動することはできない。さらにサービスプロバイダにエラーが発生した場合に、エラー発生前の全ての実行状態およびパラメータを他の正常なサービスプロバイダに移管して、未完のジョブを継続して実行することができない。さらにシステム内のサービスプロバイダが故障した場合に、クライアントが、異常なサービスプロバイダを置換するためにシステム内の別の正常なサービスプロバイダを自由に選択することができない。またこれらの技術は、分散オブジェクト指向システムの全体的信頼性を向上させるようには設計されていない。このために、本発明は、従来方法の前記の短所を克服するための、総合サービス管理システムを提供する。
【００１２】
本発明の一目的は、システムクラッシュ、誤りメッセージの伝送、性能低下などの、サービスプロバイダの異常挙動を効果的に検出する総合サービス管理システムを提供することである。
本発明の別の目的は、無効なサービスプロバイダを置換するために、より高いクレジット値（credit value）を有するサービスプロバイダを選択することのできる総合サービス管理システムを提供することである。
【００１３】
本発明の別の目的は、サービスプロバイダの実行状態およびパラメータを周期的にバックアップすることによって、サービスプロバイダが異常の場合に、異常が排除された時点から未完のジョブを継続して実行することのできる総合サービス管理システムを提供し、これによって分散オブジェクト指向システムの信頼性を向上させるという目的を達成することである。
本発明の別の目的は、ネットワークによって接続された様々な生産システム、特に半導体産業および光通信産業などの様々な電子通信産業における使用に適した、総合サービス管理システムを提供することである。
【００１４】
前記目的に従って、本発明は総合サービス管理システムを開示する。エラー処理機能を有する総合サービス管理システムは、ネットワーク化分散システム上で構築され、ネットワーク化分散システムは、クライアント、複数のサービスプロバイダ、コミュニティを含む。コミュニティは、ルックアップサービスおよびジェネリック・エバリュエータ（ＧＥＶ）を含む。本発明の総合サービス管理システムは、レジストレーション・スキーム、サーチ・アンド・エグゼキューション・スキーム、およびディテクション・アンド・リプレースメント・スキームを含む。本発明は主として、エラー検出およびデータバックアップの機能を有するＧＥＶを提供し、Jiniインフラストラクチャを、デザイン・バイ・コントラクトのプログラミング技術と組み合わせる。ＧＥＶは、すべてのサービスプロバイダのクレジット値を維持し、それによってクライアント（ファクトリマネジャなど）が、より高いクレジット値を有するサービスプロバイダ（設備マネジャなど）を選択できるようにする。さらに、ＧＥＶは周期的にサービスプロバイダの実行状態およびパラメータをバックアップすることによって、サービスプロバイダが無効になったときに、故障したサービスプロバイダのバックアップされた実行状態およびパラメータを、別のサービスプロバイダに割り当て、未完のジョブを継続して実行することができる。
本発明の一態様によれば、ネットワーク化された分散システム上に構築され、エラー処理の機能を有するとともに、前記ネットワーク化分散システムが、クライアントと、複数のサービスプロバイダと、コミュニティとを含み、前記コミュニティが、ルックアップサービスとジェネリック・エバリュエータとを含む、総合サービス管理システムであって、
サービスプロバイダがサービスプロバイダ自身の情報をそれぞれコミュニティに提供するためのレジストレーション・スキームを実行する手段と、コミュニティ内に記憶された情報を検索してサービスプロバイダの選定を行うためのサーチ・アンド・エグゼキューション・スキームを実行する手段と、実行時のエラーの発生を検出し、エラーを生じたサービスプロバイダを他のサービスプロバイダと置換するためのディテクション・アンド・リプレースメント・スキームを実行する手段とを含み、
前記レジストレーション・スキームを実行する手段が、
前記複数のサービスプロバイダのそれぞれが、前記コミュニティを発見するステップを実行する手段と、
前記コミュニティが、前記ルックアップサービスを、前記コミュニティを発見するステップにおいてコミュニティを発見した前記複数のサービスプロバイダに提供するステップを実行する手段と、
前記複数のサービスプロバイダが、複数のコントラクトを、前記コミュニティの前記ルックアップサービスに提供するステップを実行する手段と、
前記コミュニティが、前記複数のサービスプロバイダのそれぞれについてレジストレーションを開始するステップを実行する手段と、
前記コミュニティが、前記複数のサービスプロバイダの前記コントラクトを発行するステップを実行する手段と、
前記サービスプロバイダが、前記複数のコントラクトのそれぞれのコントラクト項目を設定してジェネリック・エバリュエータに送出するステップを実行する手段と、
前記ジェネリック・エバリュエータが、前記複数のサービスプロバイダのそれぞれのクレジット値に、デフォールト値を設定し、かつ前記複数のコントラクトのコントラクト項目と前記複数のサービスプロバイダのそれぞれの前記クレジット値とを、コミュニティ内のデータベースに記憶させ、それによって前記複数のサービスプロバイダのそれぞれをモニタするステップを実行する手段とを含み、
前記サーチ・アンド・エグゼキューション・スキームを実行する手段が、
前記クライアントが、前記コミュニティを発見するステップを実行する手段と、
所望のサービスプロバイダを発見するために、前記コミュニティによって、サーチングサービスおよび前記複数のコントラクトのそれぞれの内容を、前記コミュニティを発見したクライアントに提供するステップを実行する手段と、
前記クライアントが、前記複数のコントラクトのそれぞれの内容および該コントラクトを提供した前記サービスプロバイダのクレジット値を検査するステップを実行する手段と、
前記クライアントが、所望のコントラクトが取得されたかどうかを検査し、結果が「ノー」である場合に、クライアントによるサーチングの実行を停止するステップを実行する手段と、
前記所望のコントラクトが取得されたかどうかの検査の結果が「イエス」の場合には、前記クライアントが、前記複数のサービスプロバイダから第１サービスプロバイダを選定するステップを実行する手段と、
前記第１サービスプロバイダの少なくとも１つのプロキシをコミュニティのルックアップサービスからダウンロードするステップを実行する手段と、
前記クライアントによって、サービスプロバイダを選択する手段を実行するのが１回目であるかどうかを検査するステップを実行する手段と、
サービスプロバイダを選択する手段を実行するのが１回目であるかどうかの前記検査の結果が「イエス」であれば、前記クライアントが、前記第１サービスプロバイダからサービスを要求するステップを実行する手段と、
前記第１サービスプロバイダが、前記クライアントからのサービス要求に応答して、所望のサービスを準備して、前記ジェネリック・エバリュエータの少なくとも１つのスレッドの起動を実行するステップを実行する手段と、
前記ジェネリック・エバリュエータが、前記少なくとも１つのスレッドを実行し、周期的に第１サービスプロバイダの実行状態のバックアップを前記データベースに作成するステップを実行する手段と、
前記ジェネリック・エバリュエータの前記少なくとも１つのスレッドが、前記第１サービスプロバイダによって提供されるサービスを検査するステップを実行する手段と、
前記第１サービスプロバイダのサービスを検査する前記手段がエラーを発見しないか、または前記第１サービスプロバイダが正常に実行した場合に、前記ジェネリック・エバリュエータが、第１サービスプロバイダの前記クレジット値を増加させるステップを実行する手段と、
前記クレジット値を増加させる手段を実行した後に、コミュニティが、前記ジェネリック・エバリュエータの前記少なくとも１つのスレッドを終了させるステップを実行する手段とを含み、
前記ディテクション・アンド・リプレースメント・スキームが、
前記第１サービスプロバイダに実行のエラーが発生した場合に、前記ジェネリック・エバリュエータが、例外イベントを検出して警告を送出するステップを実行する手段と、
前記ジェネリック・エバリュエータが、前記警告を送出する手段を実行した後に、前記第１サービスプロバイダのクレジット値を減少させるステップを実行する手段と、
前記コミュニティが、前記クレジット値を減少させる手段を実行した後に、前記ジェネリック・エバリュエータの前記少なくとも１つのスレッドを終了させる前記ステップを実行する手段と、
前記コミュニティが、前記警告を送出する手段を実行した後に、実行時にエラーが発生した第１サービスプロバイダの置換の実行を開始し、次いで前記サーチ・アンド・エグゼキューション・スキームの上記ステップを反復して、少なくとも１つの第２サービスプロバイダを取得するステップを実行する手段と、
前記クライアントが、エラーが発生する直前に保存されたバックアップデータを取得するステップを実行する手段と、
前記クライアントが、前記バックアップデータを前記少なくとも１つの第２サービスプロバイダに設定して、前記所望のサービスの要求を開始するステップを実行する手段とを含む、前記総合サービス管理システムが提供される。
前記の態様および本発明に付属する利点の多くは、以下の説明を、添付の図面を合わせ読むことによって、簡単かつ詳細に理解できるであろう。
【００１５】
【発明の実施の形態】
図１、図２および図３を参照すると、本発明に従って、図１は総合サービス管理システムのレジストレーション・スキームの動作を示す概略図であり、図２は総合サービス管理システムのサーチ・アンド・エグゼキューション・スキームの動作を示す概略図であり、図３は総合サービス管理システムのディテクション・アンド・リプレースメント・スキームの動作を示す概略図である。本発明の総合サービス管理システムのメンバは、ネットワーク化された分散システム上に構築され、クライアント３５と、１３、１６、１９などの符号がつけられた複数のサービスプロバイダと、コミュニティ（共同体）１０とを含み、コミュニティ１０はルックアップサービス１１およびジェネリック・エバリュエータ（ＧＥＶ）１５を含む。本発明の総合サービス管理システムは、レジストレーション・スキーム（レジストレーション機構、レジストレーション方法）２００と、サーチ・アンド・エグゼキューション・スキーム（調査実行機構、調査実行方法）２２０と、ディテクション・アンド・リプレースメント・スキーム（検出置換機構、検出置換方法）２４０とを含む。
【００１６】
図１に示すレジストレーション・スキーム２００においては、サービスプロバイダ１３、１６、１９は、それぞれコミュニティ１０にそのコントラクト（契約）４３、４６、４９を提供し（ステップＡ）、そのプロキシ５３、５６、５９をルックアップサービス１１内に記憶することによって、クライアント（図示せず）がコミュニティ内の適正なサービスプロバイダを探索し、かつ発見したサービスプロバイダからサービスを要求できるようにする。図２に示すサーチ・アンド・エグゼキューション・スキームにおいては、クライアント３５がコミュニティ１０の適正なサービスプロバイダを探索するのと同時に、クライアント３５は、所望のサービスプロバイダを選択するために、コントラクトを検査し、かつサービスプロバイダ１３を選択するステップＢで示したように、ＧＥＶ１５からサービスプロバイダのクレジット値を問い合わせすることができる。
【０００１７】
その後、サービスプロバイダ１３からのサービスを要求するために、ステップＣが実行され、サービスプロバイダ１３のプロキシ５３が、ルックアップサービス１１からダウンロードされる。この間、サービスプロバイダ１３は、そのコントラクト項目を、監督のためにＧＥＶ１５に与えると共に、データベースにバックアップを作成するために、実行状況およびパラメータをＧＥＶ１５に送信する。ＧＥＶ１５はスレッド３３を実行し、サービスプロバイダ１３をモニタする（ステップＤ）。図３に示す、ディテクション・アンド・リプレースメント・スキーム２４０においては、サービスプロバイダ１３にエラーが発生すれば、サービスプロバイダ１３は異常となり終了させられることになるが、この場合にプロキシ５３も実行を停止され、消去される（ステップＥ）。この間、ＧＥＶ１５は、サービスプロバイダ１３が異常であることを検出し、クライアント３５に通知する。
【００１８】
エラーが検出された後、ＧＥＶ１５はスレッド３３を終了させる（ステップＦ）と共に、警告を送出する（ステップＧ）ことによって、クライアント３５がコミュニティ１０内の別のサービスプロバイダを探索できるようにする。コントラクトおよびクレジット値が検査された後に、サービスプロバイダ１６が選択され（ステップＢ）、クライアント３５は、サービスプロバイダ１６からのサービスを要求する（ステップＣ）と共に、コントラクトの内容について継続的に処理を行うために、ルックアップサービス１１からサービスプロバイダ１６のプロキシ５６をダウンロードし、異常なサービスプロバイダ１３を取り替える。その間、ＧＥＶ１５は、スレッド３６を開始し、サービスプロバイダ１６をモニタする（ステップＤ）。
【００１９】
図４（図４Ａおよび図４Ｂ）を参照すると、図４は本発明による総合サービス管理システムの全体フローチャートである。図１および図４を参照して、本発明のレジストレーション・スキーム２００のフロープロセスを以下に述べる。サービスプロバイダ１３の初期化（ステップ３００）の後、適正なコミュニティを発見するためのステップ３０２が実行される。次いで、ステップ３０４が、Jiniのディスカバリサービスを介して、指定のコミュニティ１０内のルックアップサービス１１を探索するために実行され、サービスプロバイダ１３にルックアップサービスが提供される。その後に、コミュニティ１０内のルックアップサービス１１にコントラクト４３を提供するために、ステップ３０６が実行されて、次いでレジストレーションを開始するためにステップ３０８が実行される。レジストレーションサービスを実行し、コントラクトを発行（ステップ３１０）した後に、コントラクト４３のアイテムが設定され（ステップ３１２）、ＧＥＶ１５に設定される（ステップ３１４）。次いでＧＥＶ１５が、サービスプロバイダ１３にデフォールトのクレジット値（例えば０．５）を割り当て、サービスプロバイダをモニタするために、コントラクト項目およびクレジット値をデータベースに記憶させる。その後、サービスプロバイダ１３はスタンバイ状態になる（ステップ３１６）。サービスプロバイダ１３と同様に、他のサービスプロバイダ１６、１９についても、このレジストレーション・スキームにおける前記のステップを実行する必要がある。
【００２０】
図２および図４を参照して、本発明のサーチ・アンド・エグゼキューション・スキーム２２０を次に説明する。クライアント３５の初期化（ステップ４００）後、適正なコミュニティを発見するためにステップ４０２が実行される。次いで、ルックアップサービスとコントラクト内容を提供するためにステップ４０４が実行される。Jiniのディスカバリサービスを介して、クライアント３５はコミュニティ１０内のルックアップサービス１１を探索し、これによって検索サービスおよびコントラクト内容が所望のサービスプロバイダを探索するために提供される。その後、クライアント３５は、適正なサービスプロバイダを選択するために、コントラクト内容、および各サービスプロバイダのクレジット値を検査する（ステップ４０６）。次いで、所望のコントラクトが得られたかどうかを調べるために、ステップ４０８が実行される。この結果「ｎｏ」であれば、次いでステップ７５４が実行されて、クライアント３５の実行が停止される。また結果が「ｙｅｓ」のときには、ステップ４１０が、サービスプロバイダを選択するために実行されて、例えばサービスプロバイダ１３が選択された後に、サービスプロバイダ１３のプロキシ５３がダウンロードされることによって、プロキシ５３を介してサービスプロバイダ１３からサービスを要求することができる。
【００２１】
次いで、サービスプロバイダを選択するのが１回目かどうかを調べるために、ステップ４１２が実行される。ステップ４１２の結果が「ｙｅｓ」であれば、ステップ４２０が実行されて、サービスの要求が開始される。クライアント３５がサービスプロバイダ１３からサービスを要求し始める一方で、クライアント３５はまた、サービスプロバイダ１３が異常の場合にはクライアント３５にイベント通知を通知することをＧＥＶに要求するために、ＧＥＶ１５に登録する。サービスプロバイダ１３が、サービス要求を受け取った後に、所望のサービスを準備し、ＧＥＶ１５のスレッド３３を開始するために、ステップ３２０が実行され、その後にサービスプロバイダ１３が実行状態に入る（ステップ３２２）。クライアント３５がサービスを使用している間（ステップ４３８）、ＧＥＶ１５はスレッド３３を実行し、バックアップサービスデータを作成し（ステップ４２２）、この場合にＧＥＶ１５はサービスプロバイダ１３によって実行されるコントラクト項目の合理的な実行時間をモニタするために、スレッド３３を初期化し、周期的にサービスプロバイダの実行状態のバックアップをデータベース中に作成する。
【００２２】
その後に、サービスプロバイダ１３のコントラクト４３の実行を調べるために、ステップ４２４が実行される。ステップ４２４の結果、サービスプロバイダ１３のサービス挙動が正常であると分かった場合には、サービスプロバイダ１３はサービスの使用を終了し（ステップ４４０）、その実行を停止する（ステップ７５４）。その間、サービスクレジット値を増大させるためにステップ４２６がＧＥＶ１５によって実行されて、この場合にＧＥＶ１５は、クライアント３５が要求されたサービスを終了した後に、サービスプロバイダ１３のクレジット値を増大する。次いで、ステップ４３４が実行されて、ＧＥＶ１５のスレッド３３を終了し、スレッド３３の実行が停止される（ステップ７５０）。他方で、サービス使用状態にあるクライアント３５も、サービスの使用を直接的に停止されて（ステップ４４０）、また実行も停止される（ステップ７５４）。
【００２３】
図３および図４を参照して、本発明のディテクション・アンド・リプレースメント・スキーム２４０を次に説明する。ステップ４２４の検査結果から、サービスプロバイダ１３のサービス挙動が異常であることがわかると、サービスプロバイダ１３は異常に終了して（ステップ３２８）、実行が停止される（ステップ７５０）。ＧＥＶ１５がサービスプロバイダ１３の異常な例外を検出した後に（ステップ４２８）、ＧＥＶ１５は警報を送出して（ステップ４３０）、クライアント３５にプロバイダ１３の異常な実行を通知し、直ちにサービスプロバイダ１３のサービスクレジット値を減少させる（ステップ４３２）。次いで、サービスプロバイダ１３をモニタするＧＥＶ１５のスレッド３３を終了させるためにステップ４３４が実行されると共に、スレッド３３の実行を停止するために、ステップ７５２が実行される。
【００２４】
引き続き図３および図４について説明する。警告が送出された（ステップ４３０）後に、サービスプロバイダ１３の置換の実行を開始するためにステップ４３６が実行される（ステップ４３６）。適正なコミュニティが発見された（ステップ４０２）後に、サーチングサービスおよびコントラクト内容とを提供して必要条件を備えたサービスプロバイダを発見するために、クライアント３５は、指定されたコミュニティ１０内で、Jiniのディスカバリサービスを介してルックアップサービス１１を探索する（ステップ４０４）。その後、クライアント３５が、その中のサービスプロバイダを選択するために、各サービスプロバイダから提供されるコントラクト内容とクレジット値とを調べる（ステップ４０６）。次いで、所望のコントラクトが得られたかどうかを調べるために、ステップ４０８が実行される。ステップ４０８の結果が「ｙｅｓ」の場合には、サービスプロバイダを選択するためにステップ４１０が実行され、例えばサービスプロバイダ１６がクライアント３５によって選択された後に、プロキシ５６を介してサービスプロバイダ１６からのサービスを要求するために、サービスプロバイダ１６のプロキシ５６がダウンロードされる。
【００２５】
次いで、サービスプロバイダを選択するのが最初かどうかを調べるために、ステップ４１２が実行される。ステップ４１２の結果が「ｎｏ」である場合には（置換中は、結果は「ｎｏ」）、ステップ４１４が実行されて回復手順を開始する。クライアント３５は、ＧＥＶ１５を介してバックアップデータを提供する（ステップ４１６）。サービスプロバイダ１３にエラーが発生する直前に記憶された実行状態とパラメータが、最初に検索されて、次いで状態バックアップデータを設定するためにステップ４１８が実行される。これらの実行状態およびパラメータが、サービスプロバイダ１６に設定された後に、サービスプロバイダからのサービスの要求を開始するために、ステップ４２０が実行される。クライアント３５がサービスプロバイダ１６からのサービスの要求を開始する一方で、クライアント３５はまた、サービスプロバイダ１６が異常の場合には、クライアント３５にイベント通知をするようにＧＥＶ１５に要求するために、ＧＥＶ１５に登録する。サービスプロバイダ１６がサービス要求を受け取った後に、所望のサービスを準備して、ＧＥＶ１５のスレッド３６を起動するために、ステップ３２０が実行される。
【００２６】
その後、ＧＥＶ１５がそのスレッド３６を実行すると共に、バックアップサービスデータを作成し（ステップ４２２）、ここでＧＥＶ１５は、サービスプロバイダ１６によって実行されるコントラクト項目の合理的な時間をモニタすると共に、サービスプロバイダ１６の実行状態のバックアップをデータベース中に作成するために、スレッド３６を初期化する。その後、サービスプロバイダのコントラクトの実行を調べるために、ステップ４２４が実行される。ステップ４２４の結果、サービスプロバイダ１６のサービス挙動が正常であるとわかると、ＧＥＶ１５によってステップ４２６が実行されて、クライアント３５が要求されたサービスを終了した後に、サービスプロバイダ１６のクレジット値を増加させる。もちろんのこと、サービスプロバイダ１６にエラーが発生した場合には、別のサービスプロバイダを探索するために、上記のステップが反復されて、未完のジョブの実施が継続されることになる。
【００２７】
さらに、実行状態にあるサービスプロバイダ１３または１６の実行を検査するために、ステップ３２４が実行される。実行が未実施の場合には、サービスプロバイダ１３または１６の実行が継続される（ステップ３２２）。実行が異常の場合には、サービスプロバイダ１３または１６は、異常に終了し（ステップ３２８）、その実行は停止される（ステップ７５０）。実行が正常に終了した場合には、クライアント３５がサービスの使用を終了し（ステップ４４０）、実行を停止する（ステップ７５４）と共に、同時に、ＧＥＶ１５にサービスプロバイダ１３または１６のクレジット値を増加させることを要求するために、ステップ４２６が実行され、次いで、ＧＥＶ１５のスレッド３３または３６を終了させるために、ステップ４３４が実行される。その後に、スレッド３３または３６の実行が停止され（ステップ７５０）、次いでサービスプロバイダ１３または１６が、サービスの提供（ステップ３２６）および実行を停止する（ステップ７５０）。
【００２８】
本発明の総合サービス管理システムは、クライアントとサービスプロバイダとの間の相互合意としてコントラクトを使用することが特徴であり、このコントラクトは、コミュニティのサービスプロバイダによって提示される。コントラクトが実行されている間、サービスプロバイダは、クライアントがコントラクトの条件に合致するかどうかを検査すると共に、コントラクトが実行されるときに、自己検査されることになる。ＧＥＶは、サービスプロバイダにエラーが発生したかどうかを判定するために、コントラクト項目の合理的な実行時間をモニタする。コントラクトの詳細な説明を以下に記す。
【００２９】
図５を参照すると、図５はJiniインフラストラクチャのルックアップサービス内に維持されるサービス項目を示す概略図である。本来のJiniインフラストラクチャにおいては、サービスプロバイダは、クライアントがそのサービスプロバイダによって提供されるサービスを探索できるように、提供されたサービス項目をルックアップサービスに登録する。図５に示すように、サービスアイテムは２つの部分を含む。それはプロキシおよびアトリビュート（属性）のリストであり、プロキシはサービスプロバイダによって提供されるインタフェース・インプリメンテーションであり、クライアント端にダウンロード可能なオブジェクトとすることによって、サービスプロバイダによって提供されるサービスをプロキシを介してクライアントが使用可能になる。アトリビュートは、サービスプロバイダそれ自体の記述であり、それによってクライアントは所望のサービスプロバイダを、簡単、迅速、かつ効率的に発見することができる。
【００３０】
本発明においては、コントラクトとは、「プロキシ」に「アトリビュート」、それに「デザイン・バイ・コントラクト」プログラミング技法を加えたものである。サービスプロバイダは、問い合わせのためにコミュニティ内のコントラクトを、クライアントに提供する。サービスプロバイダによって提供されるコントラクトは、単にサービスプロバイダによって提供されるサービスを指すのではなく、サービスプロバイダとクライアントとによって互いに編集される規制も含んでおり、コミュニティ内のサービスプロバイダによって提示される。本願においてコントラクトは、前述のMeyerによって提供されるデザイン・バイ・コントラクトの概念を含む、Jiniサービス項目であり、Jiniによって定義される本来のインタフェースに、事前条件および事後条件が追加される。簡単に言うと、コントラクトとは、デザイン・バイ・コントラクトによる方法によって定義されるサービスプロバイダのインタフェースであり、このインタフェースはプロキシ内に実装される。
【００３１】
本発明においては、サービスプロバイダによるインタフェースプロバイダは、デザイン・バイ・コントラクト法によって実施される。クライアントがサービスプロバイダにサービスの提供を要求する前に、クライアントはコントラクト内に記述された事前条件に合致しなくてはならない。提供されるサービスが終了した後に、サービスプロバイダは、コントラクに記述された事後条件が達成されていることを保証しなくてはならず、それによってクライアントにコントラクトの履行を保証する。本発明は、サービスプロバイダ内のコントラクトを実施するためにプロキシ法を用いており、クライアントは、サービスプロバイダにプロキシを介してコントラクト内容を履行することを要求と共に、プロキシ内で、クライアントおよびサービスプロバイダ自体がコントラクトを履行したかどうかを調べることを要求するために、コントラクトの規制に合致しなくてはならない。Meyerの提供するデザイン・バイ・コントラクト法およびKramerの提供するiContract Systemを用いて、クライアントがプロキシを介して遠隔サービスプロバイダを呼び出すときに、クライアントがコントラクトに記述された事前条件に合致しない場合には、プロキシはクライアントに例外を送信することになる。まとめると、本発明のサービスプロバイダがコントラクトを実行するとき、クライアントがコントラクト合致するかどうかを検査し、サービスプロバイダがコントラクトを正しく履行したかどうかを判定するのは、サービスプロバイダのプロキシである。
【００３２】
サービスプロバイダのエラーの検出を強化するために、本発明は、Jiniコミュニティ内にＧＥＶを開発することによって、クライアントがＧＥＶを使って、所望のサービスプロバイダにエラーが発生しているかどうかを検出することができることに特徴がある。さらに、ＧＥＶはサービスプロバイダの実行状態とパラメータのバックアップを周期的に作成し、それによって置換先に適切なバックアップ情報およびデータを提供し、エラーの発生したサービスプロバイダからの未完のジョブが円滑に継続される。検出機能に加えて、サービスプロバイダにエラーが発生した場合に、ＧＥＶはまた、すべてのサービスプロバイダのクレジット値を記録かつ維持するが、このクレジット値はコミュニティ内のサービスプロバイダが蓄積したサービス評判を意味し、クライアントがサービスプロバイダを選択する基準として使用される。クレジットの詳細な説明を以下に示す。
【００３３】
人の社会においては、信用（credit）は多くの成功を徐々に蓄積することによって構築され、単に１回または２回の不誠実によって急速に低下するのが常である。前述の概念に基づいて、本発明は、チン−テング  リン(Chin-Teng Lin)およびシー．エス．ジョージ  リー(C.S. George Lee)による出版「ニューラル・ファジイ・システム（Neural Fuzzy Systems）」を参照して、そこに記述されている数式を、徐々に上昇すると共に急激に下降するカーブに修正することによって、サービスプロバイダに対するクレジット関数を導き、その関数をサービスプロバイダの評判（reputation）を測る尺度として用いた。
【００３４】
本発明においては、サービスプロバイダのクレジット値は、ＧＥＶによって維持される。クレジット値は、サービスプロバイダによって蓄積された評判を表し、クライアントがサービスプロバイダを選択する基準として使用される。本発明のクレジット関数は、報奨関数と懲罰関数とを含む。プロバイダが正常に実行されると、ＧＥＶは、サービスプロバイダのクレジット値を報奨関数に従って増加させる。そしてサービスプロバイダが異常実行をすると、ＧＥＶは懲罰関数に従ってサービスプロバイダのクレジット値を低下させる。
【００３５】
サービスプロバイダに対するクレジット関数は、以下の式で表される。
報奨関数：  Ｐi（Ｉ）＝μ（Ｉ,λi）
懲罰関数：
【数１】
0003872412.tif 000002
各記号の意味は以下のとおりである。
λ  ＝  勾配値
λi  ＝  報酬関数の勾配値
λu  ＝  懲罰関数の勾配値
η  ＝  懲罰度合：−１＜η＜０
I  ＝  指標値
γ  ＝  指標のオフセット
【００３６】
図６を参照すると、図６は本発明による報奨関数と懲罰関数のカーブを示す概略図であり、この図ではλi＝０．２、λu＝０．３、η＝−０．９、γ＝３０である。サービスプロバイダがクライアントの要求したサービスを完了した後に、ＧＥＶがサービスプロバイダのクレジット値を、図６に示す報奨関数および懲罰関数に従ってサービスプロバイダのクレジット値を調整する。サービスプロバイダが正常のときにはクレジット値を増加させ、サービスプロバイダが異常のときにはクレジット値を低減する方法を以下に示す。
【００３７】
（１）正常作動：  点Ａ、Ｂ、ＣおよびＤは、それぞれ指標３０、３１、３２、３３および３３に対応するクレジット値である。サービスプロバイダの初期値を０．５（指標＝３０）とすると、図６に示す点Ａの位置のように、クライアントがサービスプロバイダからのサービスを要求し、そのサービスが正常に実行された場合には、ＧＥＶは指標Ｉに１を加え、報奨関数Ｐi（Ｉ）に従って、図６の点Ｂに対応するクレジット値を獲得するように、サービスプロバイダのクレジット値を増加させる。同様に、実行が成功する度に、ＧＥＶは指標Ｉに１を加えて、報奨関数Ｐi（I）に従ってサービスプロバイダのクレジット値を、図６において点Ａを点Ｂに、点Ｂを点Ｃに、また点Ｃを点Ｄになるように増加させる。
【００３８】
（２）異常作動：サービスプロバイダに実行エラーが発生すると、指標Ｉを固定することによって懲罰関数Ｐｕ（Ｉ）に従ってサービスプロバイダに対するクレジット値を求め、次いで、そのクレジット値を報奨関数Ｐi（I）に対応させることによって新指標Ｉを求める。新指標Iを丸めた後に、その整数部をとって次の実行のクレジット値が求められる。つまり新指標Iの整数部を使用して、図６に示す経路ＤからＥのように、サービスプロバイダのクレジット値が変更される。
【００３９】
さらに本発明のＧＥＶは、図４に示すステップ４２２において、サービスプロバイダがコントラクト項目を実行するのに要する合理的な実行時間などの、あるコントラクトパラメータをモニタすることによって、サービスプロバイダが異常かどうかを判定することに特徴がある。サービスプロバイダがコントラクトをコミュニティに提供した後に、サービスプロバイダはコントラクト項目をＧＥＶに設定し、次いでクライアントがサービスプロバイダからのサービスを要求するときに、サービスプロバイダは実行パラメータをＧＥＶに提供する。ここでＧＥＶは、コントラクト実行項目に基づいて、収集されたデータを分類すると共に、各分類の平均値
【数２】
0003872412.tif 000003
と標準偏差（σｉ）を計算し、これらがサービスプロバイダが異常かどうかを判定する基本として使用される。図７を参照すると、図７は本発明の総合サービス管理システムによる、コントラクトパラメータをモニタするＧＥＶのフローチャートである。コントラクトパラメータをモニタするＧＥＶの機能の実行ステップを以下に説明する。
【００４０】
データＣｉ＋１を収集するためにステップ７００が実行され、ＧＥＶがコントラクトの実行をモニタできるようにる。最初に、サービスプロバイダは、Jiniコミュニティに参加後に、そのコントラクト項目をＧＥＶに設定しなくてはならず、クライアントがサービスプロバイダからのサービスを要求した後に、サービスプロバイダは、そのコントラクト項目の実行パラメータをＧＥＶに提供し、次いでＧＥＶが、コントラクト実行項目およびそれらのパラメータに基づいて、サービスプロバイダが異常かどうかを判定する。その後に、データを分類するためにステップ７０２が実行され、一組の新規データが収集された後に、サービスプロバイダによって提供されるコントラクト項目のパラメータに従って、ＧＥＶがデータを分類する。
【００４１】
その後に、同一分類のデータ収集数が、所定の統計的サンプル数ＳＮより大きいかどうかを判定するためにステップ７０４が実行され、ステップ７０４の結果が「ｎｏ」であれば、データをデータベースに記憶させ、十分なサンプルサイズが蓄積されるまでデータ収集を継続するために、ステップ７００に戻る。ステップ７０４の結果が「ｙｅｓ」である場合には、同一分類された以前のＳＮセットのデータの平均値
【数３】
0003872412.tif 000004
および標準偏差（σｉ）を計算するために、ステップ７０６が実行される。ここで、十分な数のサンプルが蓄積されると、あるコントラクトパラメータ、例えばあるコントラクト項目の実行時間などが合理的かどうかを判定するために、同一分類されたデータの平均値および標準偏差をＧＥＶが計算する。
【００４２】
その後に、
【数４】
0003872412.tif 000005
が成り立つかどうかを判定するためにステップ７０８が実行される。ここでＧＥＶが、同一分類のコントラクトパラメータの平均値
【数５】
0003872412.tif 000006
および標準偏差（σｉ）を計算した後に、Ｃｉ＋１が、
【数６】
0003872412.tif 000007
との間に入るかどうかを判定し、この範囲にあれば、サービスプロバイダのコントラクパラメータは合理的であると判定し、この範囲でなければ、このコントラクトパラメータが合理的でないと判定する。ステップ７０８の結果が「ｙｅｓ」であれば、同一分類の最も古いデータを消去し、Ｃｉ＋１を追加するためにステップ７１０が実行される。ここでデータベースサンプルを正しく更新するために、コントラクトパラメータＣｉ＋１が合理的である場合には、ＧＥＶは新規データをデータベースに追加し、同一分類下の最も古いデータを消去し、次いでデータＣｉ＋１を収集するためにステップ７００に復帰する。
【００４３】
ステップ７０８の結果が「ｎｏ」である場合には、ステップ７１２が実行されて、コントラクトパラメータが、２つの連続するサイクルについて合理的でないかどうかが判定される。サービスプロバイダが２つの連続する不合理なコントラクトパラメータを示さない場合には、この単一の不合理なコントラクトパラメータはノイズによって発生した可能性が高く、このためにＧＥＶは新規Ｃｉ＋１データの収集を継続する。コントラクトパラメータＣｉ＋１が2回連続のサイクルで合理的でない場合には、ＧＥＶはサービスプロバイダが異常であると判断する。ステップ７１２の結果が「ｎｏ」である場合には、データＣｉ＋１を収集するためにステップ７００に復帰する。ステップ７１２の結果が「ｙｅｓ」である場合には、クライアントにサービスプロバイダが異常であることを通知するためにステップ７１４が実行される。ここで、ＧＥＶがサービスプロバイダが異常であると判定した場合には、ＧＥＶはサービスプロバイダが異常であることをクライアントに通知するイベント通知を送り、次いでＧＥＶは実行を停止する（ステップ７６０）。
【００４４】
本発明の総合サービス管理システムは、半導体製造システムや光通信生産システムなどの、ネットワークによって接続された様々な生産システムでの使用に適している。ＩＣパッケージングプラントに応用する好適な実施態様について以下に説明する。
図８、図９および図１０を参照すると、図８は、本発明の好適な実施態様による総合サービス管理システムのレジストレーション・スキームの動作を示す概略図である。図９は、本発明の好適な実施態様による総合サービス管理システムのサーチ・アンド・エグゼキューション・スキームの動作を示す概略図である。図１０は、本発明の好適な実施態様による総合サービス管理システムのディテクション・アンド・リプレースメント・スキームの動作を示す概略図である。
【００４５】
ファクトリマネジャ６５は、１１の設備マネジャ７１〜８１を統括している。設備マネジャの１つが、ファクトリマネジャから命令を受け取った後に、設備マネジャは、それが制御する８つの設備にジョブを分配する。プラント全体に、８０の設備がある場合には、正常な状況においては１０の設備マネジャだけが必要であり、別の１つは予備として使用される。ファクトリマネジャ６５は、主として、受け取ったジョブを設備マネジャに割り当てることに責任をおっている。指定された設備マネジャが、割り当てられたジョブを終了したときには、ジョブ完了メッセージをファクトリマネジャに返し、設備マネジャは主として設備の作動挙動と状態をモニタ、かつ制御しており、その機能には、設備パラメータの設定および設備運転の遠隔制御、設備へのジョブの発送、配合表の管理、設備のイベントおよび警報の収集、収集された情報のファクトリマネジャへの報告などが含まれる。本実施態様においては、設備マネジャは、本発明の総合サービス管理システムのサービスプロバイダとして働き、ファクトリマネジャがその中のクライアントとして働く。設備マネジャの１つが故障すると、ファクトリマネジャは別の正常な設備マネジャを探索して、異常な設備マネジャを置換して、設備が、異常な設備マネジャが残した未完のジョブを継続するように監督することができる。
【００４６】
以下の説明は、本発明による総合サービス管理システムの３つの主要スキームに従って記述してある。
図８に示すレジストレーション・スキームのように、設備マネジャ７１は、コミュニティ６０にコントラクトを提供し、したがってファクトリマネジャ６５は、コミュニティ６０の設備マネジャ７１を発見して、この設備マネジャ７１からのサービスを要求することができる。詳細なステップを次に記述する。Jiniのディスカバリサービスを介して、設備マネジャ７１〜８１は、コミュニティ６０のルックアップサービス２１を探索し、次いで、コントラクトを提供するステップＡのように、ルックアップサービス２１にコントラクトを提供する。次いで設備マネジャ７１〜８１は、コントラクト項目を提供するステップＨのように、そのコントラクト項目をＧＥＶに設定する。ＧＥＶ２５は、各設備マネジャにデフォールトクレジット値（例えば０．５）を与え、次いで設備マネジャ７１〜８１をモニタリングするために、コントラクト項目およびクレジット値をデータベース９０中に記憶させる。
【００４７】
図９に示すサーチ・アンド・エグゼキューション・スキームのように、ファクトリマネジャ６５は、コミュニティ６０内の設備マネジャ７１〜８１を探索し、設備マネジャ７１〜８１のクレジット値を発見し、これによって設備マネジャ７１〜８１を所望の設備マネジャとして選択し、それらのサービスを要求する。その間、設備プロバイダは、コントラクト項目の実行状態を、監督のためにＧＥＶ２５に供給する。詳細なステップを以下に説明する。Jiniのディスカバリ・ステップを介して、ファクトリマネジャ６５は、コミュニティ６０内のルックアップサービス２１を探索すると共に、ファクトリマネジャ６５は、ルックアップサービス２１によって提供される各設備マネジャのコントラクトおよびＧＥＶ２５によって提供される各設備マネジャのクレジット値を獲得し、ステップＢで示すような、そのニーズに合致する１０の設備マネジャを探索する。次いでファクトリマネジャは、ステップＣに示すように、設備マネジャ７１〜８１からのサービスを要求することを選択する。その後、各設備マネジャは、接続を起動するためのステップＩに示すように、それに属する設備に接続される。次いで、ＧＥＶ２５は、例えば設備マネジャ７１〜８０のコントラクト項目の合理的な実行時間をモニタするために、ステップＤで示すように、１０のスレッドを開始し、データベース９０内に、各設備マネジャの実行状態のバックアップを作成する。
【００４８】
図１０に示す、ディテクション・アンド・リプレースメント・スキームのように、設備マネジャにエラーが発生したときには、ＧＥＶ２５は設備マネジャ８０の異常挙動を検出し、ファクトリマネジャに通知することによって、ファクトマネジャ６５は、コミュニティ６０内の別の設備マネジャを探索して、コントラクト項目を継続して完成させるために、異常設備マネジャを置換する。詳細なステップを、以下に説明する。ステップＥのように、設備マネジャ８０の実行中にエラーが発生したと仮定する。設備マネジャ８０のエラーを検出した後に、ＧＥＶ２５は直ちに設備マネジャ８０のクレジット値を減少させ、ステップＦのように、設備マネジャ８０の実行をモニタするスレッドを終了させる。
【００４９】
ＧＥＶ２５は、ステップＧのように、ファクトリマネジャ６５に、設備マネジャ８０が異常であることを通知する。Jiniのディスカバリサービスを介して、指定のコミュニティ内のルックアップサービス２１を探索して、かつステップＢのように、所望の設備マネジャを探索する。ファクトリマネジャ６５は、設備マネジャ８１を選択し、ステップＣのように、それからのサービスを要求し、ＧＥＶ２５を介して、設備マネジャ８０にエラーが発生する直前に記憶された実行状態及びパラメータが検索されて、設備マネジャ８０を置換するために、設備マネジャ８１に設定される。次いで、設備マネジャ８１を、本来設備マネジャ８０によって制御される設備に接続するためにステップＩが実行され、それによって設備マネジャ８０の未完のジョブを継続して完了させる。
【００５０】
【発明の効果】
本発明の利点は、サービスプロバイダの異常挙動を効率的に検出することが可能な、総合サービス管理システムを提供することである。システムクラッシュに加えて、本発明によって検出されるエラーは、メッセージ伝送エラーまたは誤ったノードに伝送されたメッセージ、および性能低下などを含む。本発明の別の利点は、サービスプロバイダが蓄積する評判を表す、信頼の概念を用いることによって、クライアントが、適切さとクレジット値に従って、無効のサービスプロバイダを置換するために、適切なサービスプロバイダを選択することができることである。本発明の別の利点は、サービスプロバイダの実行状態及びパラメータをデータベースにバックアップし、それによってサービスプロバイダが異常のときに、バックアップを検索して、未完のジョブを継続して実行するために、選択された予備のサービスプロバイダに設定することが可能であり、それによって分散オブジェクト指向システムの信頼性を向上させる目的を達成することのとできる、バックアップ機能を有する総合サービス管理システムを提供することである。本発明の別の利点は、ネットワークによって接続された様々な生産システム、特に半導体産業および光通信産業などの様々な電子通信産業における使用に適する、総合サービス管理システムを提供することである。まとめると、本発明の総合サービス管理システムは、生産効率を大幅に向上させ、労力と材料の無駄を低減し、それによって高度な産業適用価値を有する。
【００５１】
当業者であれば理解するように、本発明の前記の好適な実施態様は、本発明を制限するものではなく、本発明を説明するためのものである。本発明は、添付の特許請求項の趣旨と範囲において、様々な変更形態および類似の配設を含むものであり、本発明に付与されるべき範囲は、そのようなすべての変更形態および類似構造を含む、最も広い範囲である。
【図面の簡単な説明】
【図１】本発明による総合サービス管理システムのレジストレーション・スキームの動作を示す、概略図である。
【図２】本発明による総合サービス管理システムのサーチ・アンド・エグゼキューション・スキームの動作を示す、概略図である。
【図３】本発明による総合サービス管理システムのディテクション・アンド・リプレースメント・スキームの動作を示す、概略図である。
【図４Ａ】図４は本発明による総合サービス管理システムの全体フローチャートで、図４Ａがフローチャートの前部である。
【図４Ｂ】図４Ａの続きのフローチャートである。
【図５】  Jiniインフラストラクチャのルックアップサービス内に維持されるサービス項目を示す概略図である。
【図６】本発明による、報奨関数および懲罰関数の曲線を示すグラフである。
【図７】本発明の総合サービス管理システムによる、コントラクトパラメータをモニタするＧＥＶのフローチャートである。
【図８】本発明の好適な実施形態による、総合サービス管理システムのレジストレーション・スキームの動作を示す概略図である。
【図９】本発明の好適な実施形態による、総合サービス管理システムのサーチ・アンド・エグゼキューション・スキームの動作を示す概略図である。
【図１０】本発明の好適な実施形態による、総合サービス管理システムのディテクション・アンド・リプレースメント・スキームの動作を示す概略図である。
【符号の説明】
１０、６０  コミュニティ
１１、２１  ルックアップサービス
１３、１６、１９、２１  ルックアップサービス
２５  ＧＥＶ（ジェネリック・エバリュエータ）
３５  クライアント
４３、４６、４９  コントラクト
５３、５６、５９  プロキシ
６５  ファクトリマネジャ
７１〜８１  設備マネジャ
Ｐｉ（Ｉ）  報奨関数
Ｐｕ（Ｉ）  懲罰関数
【数７】0003872412.tif 000008
σｉ  標準偏差
【図１】
0003872412.tif 000009
【図２】
0003872412.tif 000010
【図３】
0003872412.tif 000011
【図４Ａ】
0003872412.tif 000012
【図４Ｂ】
0003872412.tif 000013
【図５】
0003872412.tif 000014
【図６】
0003872412.tif 000015
【図７】
0003872412.tif 000016
【図８】
0003872412.tif 000017
【図９】
0003872412.tif 000018
【図１０】
0003872412.tif 000019