(57)【要約】【課題】  エンタープライズコンピューティング用のメッセージ駆動型ビーンの能力へのアクセスをより良くする。【解決手段】  本発明にかかるプログラムセットにおいて、コンフィギュレーションデータは、ソフトウェアエージェント内に明示的にコード化されず、その外部にあり、例えば、コンフィギュレーションファイル内に存在する。各ソフトウェアエージェントは、それぞれのメッセージ駆動型ビーンを制御するので、プログラマは、メッセージ駆動型ビーン上での直接作業の代わりに、ソフトウェアエージェントによる作業を行い得る。一方、アプリケーションサーバとのみインターフェースするメッセージ駆動型ビーンと異なり、ソフトウェアエージェントは、コンフィギュレーションデータによって指定されるように、相互作用することができる。【選択図】図２
2005071355.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータ可読媒体における、アプリケーションサーバ（１３）およびメッセージ駆動型ビーン（Ｂ１、Ｂ２）を含むＪ２ＥＥ環境で実行されるコンピュータプログラムセットであって、
それぞれメッセージ駆動型ビーンを組み込んでいるソフトウェアエージェント（ＡＧ１、ＡＧ２、ＡＧＮ、ＡＧＩ、ＡＧＲ）と、
前記ソフトウェアエージェントの第１のエージェント（ＡＧＩ）の出力が、前記ソフトウェアエージェントの第２のエージェント（ＡＧ２）への入力として機能できるように、前記ソフトウェアエージェント間の依存関係を決定する前記ソフトウェアエージェントの外部のコンフィギュレーションデータ（１５）と、
前記エージェントおよび前記依存関係を実施するエージェントサーバ（１１）であって、前記アプリケーションサーバ、前記ソフトウェアエージェントおよび前記コンフィギュレーションデータに接続されるエージェントサーバと
を含むコンピュータプログラムセット。
【請求項２】
前記ソフトウェアエージェントは、
前記エージェントサーバの外部のクライアント（３３）からタスク要求を受信するインボーカエージェント（ＡＧＩ）
を含む
請求項１に記載のコンピュータプログラムセット。
【請求項３】
前記インボーカエージェントは、前記タスク要求において指定されたタスクの実行用に、前記第２のエージェントを選択する
請求項２に記載のコンピュータプログラムセット。
【請求項４】
前記インボーカエージェントは、前記コンフィギュレーションデータに応じて前記第２のエージェントを選択する
請求項３に記載のコンピュータプログラムセット。
【請求項５】
前記インボーカエージェントは、
前記第２のエージェントが、前記タスクを実行するために事前に必要なものを有すると判断し、
前記事前に必要なものが、前記要求によって満たされているかどうかを判断し、
前記事前に必要なものが満たされている場合には、前記第２のエージェントを起動し、
前記事前に必要なものが満たされていない場合には、前記第１のエージェントが前記事前に必要なものを満たすよう起動されるように、前記第１のエージェントを起動する
請求項３に記載のコンピュータプログラムセット。
【請求項６】
前記インボーカエージェントは、前記コンフィギュレーションデータに応じて前記第１のエージェントを選択する
請求項５に記載のコンピュータプログラムセット。
【請求項７】
前記第１のエージェントは、前記事前に必要なものが満たされると前記第２のエージェントを起動する
請求項５に記載のコンピュータプログラムセット。
【請求項８】
データベース（ＤＢ１）をさらに含み、
前記インボーカエージェントは、前記データベースに前記要求を記憶する
請求項２に記載のコンピュータプログラムセット。
【請求項９】
前記エージェントのそれぞれは、前記データベースに自身のステータスを記憶する
請求項８に記載のコンピュータプログラムセット。
【請求項１０】
前記エージェントサーバは、コンフィギュレーション可能なエラーハンドリングを提供し、
前記コンフィギュレーションデータは、前記エラーハンドリングのコンフィギュレーションを指定する
請求項１に記載のコンピュータプログラムセット。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ処理に関し、より詳細には、Ｊａｖａ（登録商標）ベースのプログラミング環境に関する。
本発明の主要な目的は、Ｊ２ＥＥ（「Ｊａｖａ  ２．０  エンタープライズ版（Java 2.0 enterprise edition）」）環境用の、強力で使いやすいプログラミングインターフェースを提供することである。
【背景技術】
【０００２】
現代の進歩の多くは、社会のほとんどすべての領域にコンピュータがますます普及したことに関連している。
商業主体は多くの場合、インターネットを介してコンピュータにアクセスする顧客に、使いやすく面白いインターフェースを提供するように試みる。
この目的のため、一定のコンピューティング言語およびコンピューティング環境、例えばＪ２ＥＥ（Sun Microcomputersが提供するＪａｖａプログラミング言語のエンタープライズ「版」）および、．ｎｅｔ（「ドットネット」と発音し、Microsoft Corporationから入手できる）は、サーバコンピュータが顧客のコンピュータにコンパクトコードをインストールすることを可能にし、顧客の観点から高度な対話性を提供する。
【０００３】
顧客に使いやすい対話型インターフェースを提供すると、顧客のコンピュータと供給業者のコンピュータネットワークとの間で、多くの通信が必要となる可能性がある。
一般に同期メッセージングが使用される。
すなわち、メッセージを受信したコンピュータは、受信したことを送り手に応答する。
その間、送り手は応答を待ち続けていることがある。
この待ち続けることにより、コンピュータ性能は一般に悪化する可能性があり、特に、実時間での対話を錯覚させることを阻害する可能性がある。
【０００４】
非同期通信は、上記応答によるいくつかの状況において性能を改善することができる。
しかしながら、送り手にはメッセージが受信されたかどうかが通知されないので、配信を保証することがより重要となる。
この保証は、メッセージングプロトコルによって提供しなければならず、通常、メッセージおよびその配信ステータスを不揮発性メモリ、例えばハードディスクに記憶することを必要とする。
【０００５】
Ｊ２ＥＥでは、非同期通信がＪＭＳ、すなわちＪａｖａメッセージサービス（Java Message Service）によって提供される。
非同期ＪＭＳメッセージの処理は、「メッセージ駆動型ビーン（message-driven bean）」を使用して実行される。
基礎となるＪ２ＥＥアプリケーションサーバは、メッセージ駆動型ビーンにメッセージのフェールセーフ配信を提供する。
原則として、メッセージ駆動型ビーンはＪ２ＥＥの他の部分と共に、エンタープライズコンピューティング用の強力なプログラミング環境を提供する。
他方で、Ｊ２ＥＥプログラミングに必要なトレーニングは、かなり大規模になる可能性がある。
トレーニングの必要がなければＪ２ＥＥの機能を利用したいプログラマにとって、このトレーニングの必要性は障壁として働く。
さらに、言語が複雑であることから、プログラマは多くの場合、実施の細部に注意を払わなければならず、プログラムによって実行される機能に集中することが難しくなる。
【特許文献１】米国特許第５６２３６６３号
【発明の開示】
【発明が解決しようとする課題】
【０００６】
Ｊ２ＥＥおよびエンタープライズコンピューティング用のメッセージ駆動型ビーンの能力へのアクセスをより良くすることが必要とされている。
【課題を解決するための手段】
【０００７】
本発明は、ソフトウェアエージェントと、エージェントサーバと、ソフトウェアエージェント間の依存関係を指定するエージェントコンフィギュレーションデータとを含むソフトウェアプログラムセットを提供する。
このコンフィギュレーションデータは、ソフトウェアエージェント内に明示的にコード化されていないという点で、ソフトウェアエージェントの外部にある。
例えば、コンフィギュレーションデータは、コンフィギュレーションファイルまたはデータベース内に存在することができる。
各ソフトウェアエージェントは、それぞれのメッセージ駆動型ビーンを制御する。
したがって、プログラマは、メッセージ駆動型ビーン上で直接作業を行う代わりに、ソフトウェアエージェントで作業を行うことができる。
しかしながら、アプリケーションサーバとのみインターフェースするメッセージ駆動型ビーンと異なり、ソフトウェアエージェントは、コンフィギュレーションデータによって指定されるように、相互作用することができる。
【０００８】
それ自体ソフトウェアエージェントであるインボーカエージェントは、エージェントサーバの外部から発せられたメッセージの形で、要求を受信することが好ましい。
インボーカエージェントは、要求で説明されているタスクを実行するのに、どのエージェントが必要とされるかを決定する。
次いで、インボーカエージェントは、メッセージ自体の内容によって満たされていない、そのエージェントの事前に必要なものがあるかどうかを判断する。
事前に必要なものが満たされている場合に、インボーカエージェントは、そのエージェントにメッセージを送信し、それによって、そのエージェントを起動する。
事前に必要なものが満たされていない場合に、インボーカエージェントは、コンフィギュレーションデータを調べて、その事前に必要なものを実現できるエージェントを特定する。
【０００９】
タスク実行エージェントの事前に必要なものを実現する事前必要物実現エージェントが存在すると仮定すると、インボーカエージェントは、事前必要物実現エージェントにメッセージを送信し、そのエージェントを起動する。
事前必要物実現エージェントは、必要な情報をタスク実現エージェントに送信し、次いで、タスク実現エージェントは、要求されたタスクを完了することができる。
インボーカエージェントは、複数のエージェントを起動して事前に必要な複数のものを実現するなど、より複雑なワークフロー配置をハンドリングすることができる。
各ソフトウェアエージェントは、ワークフローにおける自身の場所を特定する機能をインボーカエージェントと共有することが好ましい。
または、エージェント間のすべての通信をインボーカエージェントを通じて行うこともできる。
【００１０】
また、本プログラムセットはエージェントサーバデータベースも含むことができる。
インボーカエージェントは、要求と、要求と共に到来したデータとをこのデータベースに記憶する。
さらに、要求を満たすために起動された各エージェントのステータスもデータベースにおいて追跡される。
これにより、各エージェントは自身が提供したデータの宛先を決定することが可能になる。
データベースはタスクの状態を保持するので、データベースをフォールトトレランスに使用することができる。
例えば、再試行のガイドまたはシステム障害からの復旧に使用することができる。
【００１１】
本発明は、非同期通信を利用するアプリケーションの便利なプログラミングを可能にする。
より具体的には、簡単なワークフローの配置を、メッセージ駆動型ビーンを直接使用して定義できるものよりも容易に定義することができる。
さらに、エージェントがコンフィギュレーションデータから分離されているために、プログラミングは高度なモジュール性およびスケーラビリティを有する。
本発明のこれらの特徴および利点ならびに他の特徴および利点は、添付図面を参照してなされる以下の説明から明らかになる。
【発明を実施するための最良の形態】
【００１２】
本発明によれば、エージェントサーバ１１により、メッセージ駆動型ビーンを組み込んだソフトウェアエージェントＡＧ１〜ＡＧＮをＪ２ＥＥアプリケーションサーバ１３上で実行することが可能になる。
Ｊ２ＥＥアプリケーションサーバ１３は、Ｊａｖａ使用可能コンピュータＡＰ１上で実行される。
エージェントサーバ１１は、特定アプリケーション向けソフトウェアエージェントＡＧ１−ＡＧＮに加えて、インボーカ（invoker）エージェントＡＧＩおよび再試行エージェントＡＧＲの２つの必須ソフトウェアエージェントを有する。
ソフトウェアエージェントＡＧＩ、ＡＧＲ、およびＡＧ１〜ＡＧＮのそれぞれは、それぞれのメッセージ駆動型ビーンを組み込んでいる。
エージェントサーバ１１は、エージェントコンフィギュレーションファイル１５を参照する。
このエージェントコンフィギュレーションファイル１５により、簡単なワークフロー関係をエージェントＡＧ１〜ＡＧＮ間で定義することが可能になる。
【００１３】
コンピュータＡＰ１は、アプリケーションサーバ１３を実行することに加えて、関係エージェントサーバデータベースＤＢ１をサポートする。
関係エージェントサーバデータベースＤＢ１は、エージェントサーバ１１が必要とする２つの表として、エージェント要求表ＴＲおよびエージェント起動表ＴＩを含む。
インボーカエージェントＡＧＩは、すべての要求およびあらゆる関連データをエージェント要求表ＴＲに記憶する。
起動時に、各エージェントは自身の現在のステータスをエージェント起動テーブルＴＩに記憶する。
各エージェントはデータベースＤＢ１にアクセスして、要求された目的と一致するために必要とされるワークフロー内における自身の位置を判断することができる。
アプリケーションサーバ１３はデータベースアクセスレイヤ１７を提供する。
このデータベースアクセスレイヤ１７により、エージェントＡＧＩ、ＡＧＲ、ＡＧ１〜ＡＧＮがデータベースＤＢ１にアクセスすることが可能になり、その結果、要求およびエージェント起動を追跡することができる。
さらに、アプリケーションサーバ１３はサーブレットコンテナ２１を提供する。
このサーブレットコンテナ２１は、ＨＴＴＰ／ＪＭＳ翻訳器２３を含む。
【００１４】
インボーカエージェントＡＧＩは、エージェントタスクの実行を要求するＪＭＳメッセージの入力に応答する。
Ｊａｖａ使用可能コンピュータＡＰ１上で実行されるクライアント３１の場合、ＪＭＳがネイティブである可能性がある。
インターネットまたは他のネットワークを介して通信するクライアント３３などのクライアントの場合、翻訳器２３によって、送り手はＨＴＴＰ（「ハイパーテキスト転送プロトコル」）で通信することが可能になる。
ＨＴＴＰはすべてのウェブブラウザによってサポートされている。
この場合、翻訳器２３はＨＴＴＰメッセージをＪＭＳに変換し、ＪＭＳはインボーカエージェントＡＧＩによって読み出される。
また、翻訳器２３は安全なメッセージング用のＨＴＴＰＳ（「ＨＴＴＰセキュア」）も取り扱う。
【００１５】
インボーカエージェントＡＧＩは各要求を調べて、指定された１つまたは複数の目的と、その目的に関係して提供されたあらゆるデータとを特定する。
インボーカエージェントＡＧＩは、要求および関連データをデータベースＤＢ１のエージェント要求表ＴＲに記憶する。
次いで、インボーカエージェントＡＧＩはコンフィギュレーションファイル１５を検索して、指定された目的を達成できるエージェントを得る。
より具体的には、インボーカエージェントＡＧＩは、要求された目的に対応するデータを提供するエージェントを検索する。
【００１６】
次いで、目的を実現するエージェントの必要なデータが調べられる。
データが必要でない場合、または、必要なデータがすべて、要求に付随したデータによって満たされている場合には、インボーカエージェントＡＧＩは、目的を実現するエージェントにＪＭＳメッセージを送信する。
要求において提供されていないデータが必要な場合には、インボーカエージェントＡＧＩはコンフィギュレーションファイル１５を検索して、提供データが目的を実現するエージェントの必要なデータと一致するエージェントを得る。
例えば、エージェントＡＧ１が、目的を実現するエージェントＡＧ２が必要とするデータを提供できるとする。
その場合、インボーカエージェントＡＧＩはＪＭＳメッセージをエージェントＡＧ１に送信する。
その結果、ＡＧ１は起動されると、必要なデータと共にＪＭＳメッセージをエージェントＡＧ２に送信する。
次いで、このＪＭＳメッセージはエージェントＡＧ２を起動し、ＡＧ２は要求された目的を達成する。
【００１７】
エージェントＡＧ１およびＡＧ２について、ソフトウェアエージェントの基本構造を図２に示す。
各エージェントは、対応するＪＭＳキューＱ１、Ｑ２を有する。
メッセージは、それぞれのメッセージ駆動型ビーンＢ１、Ｂ２によって順次ハンドリングされ、メッセージ駆動型ビーンＢ１、Ｂ２は、それらのメッセージをジェネリックソフトウェアエージェントコードＣ１、Ｃ２に渡す。
このコードは、エージェントが起動されたことをタスク表に通知するなどの多数の基本タスクを実行する。
次いで、このジェネリックコードは、そのソフトウェアエージェントの特定アプリケーション向けコードＤ１、Ｄ２をアクティブにする。
エージェントＡＧ１の場合、これはＪＭＳメッセージの形でデータをソフトウェアエージェントＡＧ２に提供することを含むことができる。
そのタスクが完了すると、さらに別のジェネリックソフトウェアエージェントコードＥ１、Ｅ２が、データベースＤＢ１のタスクステータスを更新する。
【００１８】
本発明による一般化された方法Ｍ１は、図３のフローチャートである。
ステップＳ０１において、インボーカエージェントＡＧＩはエージェントに対する目的達成要求を含んだＪＭＳメッセージを受信する。
このメッセージは、目的エージェントを指定することに加えて、目的エージェントが必要とするデータを含むことがある。
【００１９】
ステップＳ０２において、インボーカエージェントＡＧＩは、コンフィギュレーションファイル１５を調べて、事前に必要なもの、例えば目的エージェントが必要とするデータがあるかどうかを判断する。
事前に必要なものがある場合には、インボーカエージェントＡＧＩは、要求メッセージを調べて、事前に必要なすべてのものが満たされているかどうかを判断する。
事前に必要なものがない場合、または、目的エージェントの事前に必要なすべてのものが、要求メッセージによって満たされている場合には、インボーカエージェントＡＧＩは、ステップＳ０３において、目的エージェントを起動する。
次いで、目的エージェントは、要求されたタスクを実行する。
【００２０】
事前に必要なものが満たされていない場合には、エージェントインボーカＡＧＩは、ステップＳ０４において、コンフィギュレーションファイル１５を調べ、満たされていない事前に必要なものを実現する「中間」エージェントを得る。
中間エージェントが発見されたと仮定すると、インボーカエージェントＡＧＩは、ステップＳ０５において、要求データを含むＪＭＳメッセージをその中間エージェントに送信する。
このメッセージは、ステップＳ０６において、中間エージェントによって受信される。
このような中間エージェントが発見されない場合には、人間に可読な通知が生成されて、適切な関係者に送信される。
【００２１】
ステップＳ０７において、中間エージェントは要求されたタスクを実行する。
この要求されたタスクは、自身に「提供されたデータ」を要求に付属したあらゆるデータに追加することを含む。
ステップＳ０８において、中間エージェントは、コンフィギュレーションファイルを調べて、目的エージェントの満たされていない、事前に必要なものが残っているかどうかを判断する。
残っていない場合には、中間エージェントは、要求データおよび自身に提供されたデータを有するメッセージを目的エージェントに送信し、それによって、目的エージェントを起動する。
満たされていない事前に必要なものが少なくとも１つ残っている場合には、中間エージェントは、ステップＳ０９において、コンフィギュレーションファイルを調べ、満たされていない事前に必要なものを実現できる次の中間エージェントを得る。
次いで、ステップＳ１０において、この次の中間エージェントが起動される。
目的エージェントに事前に必要なものすべてが満たされるまで、複数の中間エージェントのこの起動を必要に応じて繰り返し、それぞれの中間エージェントによって提供されたデータをメッセージに編集することができる。
事前に必要なものが複数個満たされていない場合には、オプションとして、コンフィギュレーションデータは２つ以上の中間ソフトウェアエージェントを並列に起動できることを指定できる。
次いで、目的エージェントがステップＳ０３において起動され、方法Ｍ１は完了する。
以下に、ソフトウェアエージェントおよびエージェントサーバソフトウェアのオペレーションをより詳細に説明する。
【００２２】
エージェントサーバ１１は、サーバ側のアプリケーションのハンドリングに必要なタスク（すなわちエージェント）を調整して実行することを担当する。
エージェントサーバ１１は、適応する個数の疎結合エージェントをさまざまな実行時間で実行する、スケーラブルでフェールセーフな基盤を提供する。
エージェントおよびそれらエージェントの相互作用は、事前に定義されている。
【００２３】
エージェントサーバ１１は、ＥＪＢ（「エンタープライズＪａｖａビーン」）２．０またはそれ以上のバージョンをサポートするＪ２ＥＥ環境でホスティングされる。
エージェントは所望の非同期起動を提供するメッセージ駆動型ビーンとして実施され、ＥＪＢコンテナはスケーラビリティに必要とされるＥＪＢプーリング（pooling）を提供する。
メッセージ駆動型ビーンはＪＭＳを使用して構築される。
ＪＭＳプロバイダはＥＪＢコンテナと共に、信頼できるメッセージ配信およびメッセージトランザクション処理を提供する。
【００２４】
エージェントサーバ１１は、単一の必要なコンフィギュレーションファイル１５をドライブオフ（drive off）する。
すべてのアクティブなエージェントは、このファイル１５に登録しなければならない。
各エージェントは、最低限、以下によって記述される。
【００２５】
【表１】
2005071355.tif 000003
【００２６】
コンフィギュレーションファイル１５は、エージェントの登録に加えて、エージェントサーバでの使用に利用可能なすべての非エージェントのデータ名も、表Ｉで定義した「必要データ」として登録する。
利用可能なエージェントは、ＪＭＳクライアントメッセージまたはＨＴＴＰ要求（ＪＭＳメッセージに翻訳される）を使用して起動することができる。
双方の起動メソッドには、インボーカが、既存のエージェントによって供給できないあらゆる（登録された）必要なデータを供給することが必要となる。
【００２７】
エージェントは、Ｊ２ＥＥメッセージ駆動型ビーンのインスタンスであり、したがって、ＪＭＳに依拠する。
エージェント開発者をＥＪＢおよびＪＭＳのアーキテクチャから分離するために、エージェントサーバは可能な限り多くの援助を開発者に提供する。
エージェントサーバは、エージェント開発用のインターフェース／スケルトンクラスを提供する。
エージェントは、この提供されたクラスであるＡｂｓｔｒａｃｔＡｇｅｎｔ（抽象エージェント）を拡張して、エージェントインターフェースのメソッドを無効にすることが予想される。
【００２８】
エージェントはメッセージ駆動型ビーンであり、メッセージ駆動型ビーンはエンタープライズＪａｖａビーンであるので、エージェントを配備する人は必要なＥＪＢ配備記述子を供給する必要がある。
標準的なＸＭＬファイルのエントリは、Ｊ２ＥＥアプリケーションサーバによって提供されたＥＪＢコンテナを有するメッセージ駆動型ビーンを記述して登録する。
【００２９】
エージェントサーバはイベント駆動型システムであり、ＪＭＳメッセージがイベントとして働き、各エージェントが自身のＦＩＦＯイベントキューを処理する。
外部クライアントによって使用される２つの起動メソッドの双方によって、エージェント起動要求はＩｎｖｏｋｅｒＡｇｅｎｔ（インボーカエージェント）（イベント）キューに置かれる。
【００３０】
ＩｎｖｏｋｅｒＡｇｅｎｔは、ＡｇｅｎｔＤａｔａ（エージェントデータ）オブジェクトがそれぞれの新たなエージェント起動要求ごとに存在することを確実にし、必要に応じてＡｇｅｎｔＤａｔａオブジェクトを初期化する。
起動要求が（登録された）データを含む場合に、ＡｇｅｎｔＤａｔａオブジェクトが存在し得ることに留意されたい。
あらゆるエージェントは、自身のオペレーションに必要とされるＡｇｅｎｔＤａｔａオブジェクトにアクセスすることができる。
正常な実行時には、エージェントは自身に提供されたデータをＡｇｅｎｔＤａｔａに追加する。
故障時には、エージェントは、エラー情報をＡｇｅｎｔＤａｔａに提供することになる。
完了時には、エージェントサーバは、起動要求が完了したかどうかを判断するか、または、更新されたＡｇｅｎｔＤａｔａを有するメッセージを次の必要なエージェントに送信することになる。
【００３１】
エージェント起動要求の状態はＡｇｅｎｔＤａｔａオブジェクトに保持されるのであって、エージェントそれ自体には保持されないことを理解することは重要である。
エージェントサーバは、エージェントサーバコンフィギュレーションに記載されている処理ルールをＡｇｅｎｔＤａｔａの「状態」に適用することによって、エージェントを起動する。
例えば、Ａｇｅｎｔ−ＡおよびＡｇｅｎｔ−Ｂを有する単純な２エージェントシステムについて考察する。
【００３２】
Ａｇｅｎｔ−Ａは実行にデータを必要とせず、現時点の地方の気象条件を取り出す。
Ａｇｅｎｔ−ＢはＡｇｅｎｔ−Ａ−Ｄａｔａを必要とし、戸外に出てフリスビーで遊ぶかどうかを判断するルールベースのエージェントである。
【００３３】
Ａｇｅｎｔ−Ｂの起動要求が到来する。
Ａｇｅｎｔ−Ｂを起動することが目的である。
この要求はデータを伴わずに到来する。
ＩｎｖｏｋｅｒＡｇｅｎｔは、Ａｇｅｎｔ−Ｂのデータの必要性を満たすためにＡｇｅｎｔ−Ａを起動する。
Ａｇｅｎｔ−Ａは気象情報を取得し、その気象情報をＡｇｅｎｔＤａｔａに追加する。
更新されたＡｇｅｎｔＤａｔａは、Ａｇｅｎｔ−Ｂを、すぐに起動できるということをエージェントサーバに示す。
要約すると、各エージェント／イベントに対して、エージェントサーバは、以下の方程式を解く。
【００３４】
目的＋データ＋プロセス（ａ．ｋ．ａ．コンフィギュレーション）→動作
【００３５】
ＪＭＳは、エージェントサーバメッセージングによって実施される以下のメッセージングオプションを提供する。
エージェントサーバは、ポイントツーポイント（Ｐ２Ｐ）のキューベースのＪＭＳメッセージ通信モデルを使用する。
これは、各メッセージが１つのコンシューマしか有しないことを意味する。
メッセージプロデューサは、永続的で、自動応答される、終了しないメッセージのみを送信する。
これは、コンシューマ／エージェントが受信を確認するまで、ＪＭＳプロバイダがメッセージを保持する役割を有することを意味する。
これは、プロバイダの故障からの復旧をハンドリングする。
各エージェントはメッセージ駆動型ビーンであり、したがって、ＪＭＳメッセージのコンシューマである。
ＪＭＳキューは、各エージェントに対して定義される。
エージェントのみが自身の関連キューからのメッセージを消費する。
トランザクション処理されたコンシューマまたはクライアント応答コンシューマのいずれかであることによって、例えばエージェントの故障の場合に、エージェントはＪＭＳプロバイダがメッセージを再送することを可能にする。
【００３６】
エージェントサーバの復旧方針には、２つの部分が存在する。
第１の部分はＪＭＳの保証されたメッセージ配信である。
クライアントがエージェントの起動要求に成功すると、その要求が、システムの故障にかかわらず、受信されることが保証される。
（クライアント応答コンシューマおよび／またはトランザクション処理されたコンシューマを介した）ＪＭＳオプションにより、エージェントはメッセージの配信が成功したことを確認する前に、自身の処理の完了を保証することが可能になる。
換言すると、エージェントのクラッシュによって、メッセージの再配信が強制的に行われることになる。
【００３７】
破滅的なクラッシュの場合、永続性記憶装置が復旧の目的で使用される。
復旧は、エージェントサーバの立ち上げ時に行うこともできるし、手動で行うこともできる。
あらゆるエージェント要求（およびそのエージェントデータ）は、処理前にエージェントデータベースに記憶される。
さらに、各エージェント起動もデータベースに記憶される。
復旧時には、その時点までのすべての関連する、成功したエージェント起動を考慮して、完了していないすべてのエージェント要求が再開される。
ステータス情報は、各起動要求と共に記憶されることになる。
【００３８】
また、永続性記憶装置は、エージェントの起動および性能に関する簡単な統計の収集にも使用される。
エージェントサーバは、復旧目的および統計収集のために永続性記憶装置を使用する。
各エージェント要求およびエージェント起動は、データベースに記憶される。
エージェントデータ、継続時間情報、およびステータスは、処理中に更新される。
エージェント要求の完了に成功すると、エントリには、履歴追跡用に完了フラグが立てられる。
【００３９】
【表２】
2005071355.tif 000004
【００４０】
【表３】
2005071355.tif 000005
【００４１】
例として、クライアントアプリケーションがエージェントタスクを要求する。
これは、永続的な終了しないＪＭＳメッセージをＩｎｖｏｋｅｒＡｇｅｎｔキューに送信する。
成功するには、ＪＭＳプロバイダが実行中であり、かつ、ＩｎｖｏｋｅｒＡｇｅｎｔキューがＪＭＳプロバイダで作成されていることが必要とされる。
【００４２】
ＩｎｖｏｋｅｒＡｇｅｎｔはメッセージを消費して、必要なエージェント起動を準備する。
成功するには、１）Ｊ２ＥＥアプリケーションサーバが実行中であること、２）エージェントサーバが配備されていること（エージェントサーバコンフィギュレーションが有効であり、かつ、エージェントＥＪＢ配備記述子が有効であること）、３）エージェントが配備されていること、および４）必要なあらゆる非エージェントデータが供給されていること、が必要とされる。
【００４３】
ＩｎｖｏｋｅｒＡｇｅｎｔはエージェント要求をエージェントサーバデータベースに記録する。
成功するには、１）エージェントデータベースが作動中であること、２）エージェントサーバ表が定義されていること、３）エージェントデータベースへの接続が利用可能であること、および４）エージェント要求が新しいこと（すなわち再送メッセージでないこと）が必要とされる。
【００４４】
必要な各エージェントを起動し、その後、要求されたエージェントが起動する。
データベースは、あらゆるエージェント起動の失敗時のステータスまたは要求されたエージェントの成功時のステータスにより更新される。
エージェントの要求に成功すると、そのタスクが完了する。
【００４５】
例示の実施の形態は、真に独立したエージェントを使用する。
この手法の目的はメッセージングを削減することである。
基本コンセプトはプロセス情報を分散化させることである。
換言すると、この基本コンセプトは、「ａｄｍｉｎ（管理）」コンポーネントをあらゆるエージェントに埋め込むことを意味する。
代替的な手法では、エージェントは完了メッセージを用いて起動メッセージに応答する。
したがって、すべての起動はインボーカエージェントで開始する。
これは、処理ロジックを集中化し、エージェント自体を簡素化する。
しかしながら、メッセージングが２倍になり、インボーカエージェントがボトルネックになる可能性がある。
【００４６】
本実施の形態は、いくつかの障害ハンドリング機能を提供する。
アドミニストレータにすべての要求の失敗に応答するように強制する代わりに、アプリケーションサーバは、デフォルトで人間を介入させる前に、失敗した要求を再試行するように構成される。
詳細なオプションとして以下の表ＩＶを参照されたい。
これらのオプションはタスク要素の属性を追加したものである。
【００４７】
【表４】
2005071355.tif 000006
【００４８】
エージェントの故障がＡｇｅｎｔＳｅｒｖｅｒＦａｔａｌＥｘｃｅｐｔｉｏｎ（エージェントサーバ致命的例外）を投げるエージェントコードまたはいずれかのＪａｖａエラーに起因するものである場合、この再試行メカニズムは無視される。
これらは人間の介入なしでは復旧不可能と考えられる。
【００４９】
エージェントサーバはＪ２ＥＥメッセージ駆動型ビーンに基づく。
換言すると、各エージェントはメッセージ駆動型ビーンであり、このメッセージ駆動型ビーンをアクティブにすることは、メッセージが、そのメッセージ駆動型ビーンに関連したＪＭＳキューに到来することによってトリガされる。
メッセージ駆動型ビーンは、そのホスト環境と、Ｊ２ＥＥアプリケーションサーバと、特にこのアプリケーションサーバのＥＪＢコンテナの利用可能性および正確なオペレーションに依存する。
メッセージングは、ＪＭＳプロバイダ（すなわち、ＪＭＳサーバ）の利用可能性および正確なオペレーションに依存する。
エージェントサーバに組み込まれたエージェント（例えばＩｎｖｏｋｅｒＡｇｅｎｔ）は、サポートデータベースの利用可能性および正確なオペレーションに依存する。
アプリケーションエージェントは、そのアプリケーションに関連する外部依存物に依存し、通常、データベースおよび他のアプリケーションに依存する。
環境は全体として、ホストコンピュータの利用可能性および正確なオペレーションに依存する。
【００５０】
フォールトトレランスについてのエージェントサーバの役割は、（ＪＭＳメッセージとして）正常に配信されたエージェント要求から始まる。
接続性の問題またはＪＭＳサーバが利用できないことが原因で、要求の送信が成功しないクライアントはその状況のハンドリングを担当する。
ＪＭＳサーバは送信に成功すると、メッセージの配信、したがって要求の配信を保証する。
エージェントサーバには、要求メッセージの消費を保証する義務がある。
キューベースのメッセージングでは、ＪＭＳサーバはキューからのメッセージの消費に成功するまで、メッセージを保持する。
したがって、（メッセージの期限切れを許容できる）過度でないダウンタイムを仮定すると、エージェントサーバは消費を保証することができる。
【００５１】
エージェントサーバはキューからメッセージを読み出して、要求を単一のトランザクションとしてデータベースに記憶する。
したがって、メッセージは、エージェントサーバデータベースに記憶されるまで、（ＪＭＳサーバによって）配信されていないとみなされる。
要求はデータベースに記憶されると、障害ハンドリングに利用可能となり、これは、処理が失敗した場合にその要求を再開できることを意味する。
要求データのすべて、すなわち、ＡｇｅｎｔＮａｍｅ、ＴａｓｋＮａｍｅ、およびＡｇｅｎｔＤａｔａは記憶されているので、その後、エージェントサーバは要求をいつでも最初から再開することができる。
ＡｇｅｎｔＤａｔａは、各エージェントの起動が成功に終わった後に更新されるので、複数のエージェント起動を含む要求は最後のエージェント起動に成功した後に再開することができる。
【００５２】
エージェントサーバは、アプリケーションエージェントがどのような作業を行うかを知る手段を有しない。
再起動をハンドリングできるようにすることは、エージェントコードの役割である。
換言すると、前の完了しなかった起動が、再起動の成功に影響を及ぼし得る作業を行った場合、成功を保証する方法で再起動をハンドリングすることが、エージェントの任務である。
エージェントサーバは、エージェントを援助するために、この起動が最初の起動であるのか、それとも再起動であるのかをエージェントコードが知るためのメカニズムを提供する。
【００５３】
フォールトトレランス方式は、表Ｖに説明するように、簡単なステータスを使用して、要求のハンドリングをガイドする。
【００５４】
【表５】
2005071355.tif 000007
【００５５】
サーバが終了すると、制御されていようと予想されないことであろうと、エージェントの起動を完了前に終了することが可能である。
エージェントサーバは、ステータスＡＣＴＩＶＥを有する要求を自動的に再開することによって、これをハンドリングする。
ＰＥＮＤＩＮＧ要求は、標準的な再試行メカニズムによってハンドリングされることになる。
【００５６】
エージェント要求は、１）ＡｇｅｎｔＳｅｒｖｅｒＲｕｎｔｉｍｅＥｘｃｅｐｔｉｏｎ（エージェントサーバランタイム例外）以外のＥｘｃｅｐｔｉｏｎ（例外）を投げること、２）Ｅｒｒｏｒ（エラー）を投げること、または３）の再試行の試みの設定された回数を超えること、のいずれかによって正常には完了しない。
ケース３では、要求のステータスは、ＦＡＩＬＵＲＥに設定される。
ＥｘｃｅｐｔｉｏｎまたはＥｒｒｏｒに関連する文字列が、その問題の詳細な説明と共に記憶される。
【００５７】
失敗した要求は、エージェントサーバ管理アプリケーションを介して検査に利用可能である。
このブラウザベースのアプリケーションは失敗した要求を表示し、このアプリケーションにより、アドミニストレータはその失敗と共に提供された詳細な説明に基づいてその要求を再提出するか、または、終了することができる。
このａｄｍｉｎアプリケーションは、ＪＳＰ／サーブレットコンテナと共にどのアプリケーションサーバにも配備することができる。
【００５８】
エージェント要求をエージェントサーバデータベースに記憶することに成功した後のデータベースの故障は、他のあらゆる故障と同様にハンドリングすることができ、再提出メカニズムを介して取り扱うことができることに留意されたい。
それは、次の節で解説するものと同じ問題ではない。
【００５９】
故障の最も危険な点は、要求を最初に記憶している間のデータベースの故障である。
換言すると、メッセージをキューからポップするのに成功したが、その要求情報をＡＧＥＮＴ＿ＲＥＱＵＥＳＴ（エージェント要求）表に転送することに失敗することである。
配信されたが、記憶されないメッセージは失われた要求を構成する。
できればデータベースの問題が解決された後に、メッセージの内容の記憶を成功させるか、または、後にメッセージを再配信することが必須となる。
【００６０】
フォールトトレランスは、要求情報の記憶に成功するまで、エージェントサーバにメッセージの受信に応答することを拒否させることによって達成される。
データベースに到達できない場合には、エージェントサーバ、具体的にはＩｎｖｏｋｅｒＡｇｅｎｔは、待機／再試行ループの状態になる。
これは、ＩｎｖｏｋｅｒＡｇｅｎｔがスリープ状態になるので、メッセージを有効に停止させる。
アプリケーションサーバまたはホストマシンがこの時間の間に終了すると、メッセージは応答されなかったことになり、したがって、ＪＭＳサーバは後にメッセージを再配信しなければならない。
この時点で、メッセージの処理が成功するか、または、待機／再試行状態が再開することになる。
再試行の期間はコンフィギュレーションファイルで指定され、再試行回数は無制限である。
スリープ／再試行状態になる前に、アプリケーションサーバはエラーのログを記録し、コンフィギュレーションに応じて、電子メール通知がアドミニストレータに送信されることになる。
【００６１】
アプリケーションサーバのスタートアップは、ブート時に自動的に行われるように構成されるべきである。
データベースシステムは、アプリケーションサーバの起動前に利用可能であるべきである。
例示の実施の形態では、ソフトウェアエージェントは順次起動される。
オリジナルのメッセージによって要求されたソフトウェアエージェント以外の各ソフトウェアエージェントは、１つの後続エージェントを起動する。
または、コンフィギュレーションデータは、共通の先行ソフトウェアエージェントが複数のソフトウェアエージェントを並列に起動できることを指定することができる。
これによって、複雑さおよび計算能力を追加するという代償を払うことになるが、オリジナルの要求の達成を高速化することができる。
例示の実施の形態に対するこれらの変形および変更ならびに他の変形および変更は本発明によって提供されるものであり、本発明の範囲は特許請求の範囲によって画定される。
【図面の簡単な説明】
【００６２】
【図１】本発明によるエージェントサーバソフトウェアを組み込んだＪａｖａ使用可能コンピュータシステムを示す図である。
【図２】図１のエージェントサーバソフトウェアの１対のソフトウェアエージェントの構造を示す図である。
【図３】図３は、図１のシステムを使用して実践される本発明の方法のフローチャートである。
【符号の説明】
【００６３】
１１・・・エージェントサーバ、
１３・・・アプリケーションサーバ、
１５・・・エージェントコンフィギュレーションファイル、
１７・・・データベースアクセスレイヤ、
２１・・・サーブレットコンテナ、
２３・・・ＨＴＴＰ→ＪＭＳ翻訳器、
３１，３３・・・クライアント、
【図１】
2005071355.tif 000008
【図２】
2005071355.tif 000009
【図３】
2005071355.tif 000010