(57)【要約】【課題】ディスクへのアクセスを抑えつつ大量エージェントの最高優先度のメッセージの処理を促進する。【解決手段】装置は、  メモリと、エージェントに挿入されるメッセージにより前記エージェントの優先度を決定し、前記エージェントが前記メモリ上にあるか否か、およびメッセージの有無により、前記エージェントの状態を管理する手段と、前記優先度が最高優先度であるエージェントを検出したことを条件として、前記エージェントが前記メモリ上にあればスレッドを割り当て、前記エージェントが前記メモリ上になければ前記エージェントを前記メモリ上に呼び出してスレッドを割り当てる手段と、スレッドが割り当てられた前記エージェントに関して、所定の基準までメッセージの処理を繰り返すメッセージ処理手段とを備える。【選択図】図４
2006185363.tif 000002
【特許請求の範囲】
【請求項１】
メモリと、
エージェントに挿入されるメッセージにより前記エージェントの優先度を決定し、前記エージェントが前記メモリ上にあるか否か、およびメッセージの有無により、前記エージェントの状態を管理する手段と、
前記優先度が最高優先度であるエージェントを検出したことを条件として、前記エージェントが前記メモリ上にあればスレッドを割り当て、前記エージェントが前記メモリ上になければ前記エージェントを前記メモリ上に呼び出してスレッドを割り当てる手段と、
スレッドが割り当てられた前記エージェントに関して、所定の基準までメッセージの処理を繰り返すメッセージ処理手段と
を有する装置。
【請求項２】
前記スレッドを割り当てる手段が、さらに、前記優先度が最高優先度であるエージェントを検出しないことを条件として、前記メモリ上に無いエージェントに優先して、前記メモリ上にあるエージェントにスレッドを割り当てる、請求項１に記載の装置。
【請求項３】
前記所定の基準が、状況に応じて動的に変更される、請求項１に記載のエージェントのメッセージを処理する装置。
【請求項４】
前記所定の基準が、１つのエージェントにつき所定のメッセージ数を処理し終えたことである、請求項１に記載の装置。
【請求項５】
前記エージェントの状態を管理する手段が、さらに、前記メッセージを処理し終えたあと、残ったメッセージの中で最も優先度が高いメッセージにより前記エージェントの優先度を決定する手段を有する、請求項４に記載の装置。
【請求項６】
前記所定の基準が、前記優先度が最低優先度以外のメッセージを処理し終えたことである、請求項１に記載の装置。
【請求項７】
エージェントに挿入されるメッセージにより前記エージェントの優先度を決定し、前記エージェントのメモリ上の有無およびメッセージの有無により、前記エージェントの状態を管理するステップと、
前記優先度が最高優先度であるエージェントを検出したことを条件として、前記エージェントが前記メモリ上にあればスレッドを割り当て、前記エージェントが前記メモリ上になければ前記エージェントを前記メモリ上に呼び出してスレッドを割り当てるステップと、
スレッドが割り当てられた前記エージェントにおいて、所定の基準までメッセージの処理を繰り返すメッセージ処理ステップと
を有するエージェントのメッセージ処理方法。
【請求項８】
前記スレッドを割り当てるステップが、さらに、前記優先度が最高優先度であるエージェントを検出しないことを条件として、前記メモリ上に無いエージェントに優先して、前記メモリ上にあるエージェントにスレッドを割り当てる、請求項７に記載のエージェントのメッセージ処理方法。
【請求項９】
前記スレッドを割り当てるステップは、前記メモリ上にあるか否かの状態が同一の場合、前記優先度の高いメッセージに優先的にスレッドを割り当てる、請求項８に記載のエージェントのメッセージ処理方法。
【請求項１０】
前記所定の基準が、１つのエージェントにつき所定のメッセージ数を処理し終えたことである、請求項７に記載のエージェントのメッセージ処理方法。
【請求項１１】
前記エージェントの状態を管理するステップが、さらに、前記メッセージを処理し終えたあと、残ったメッセージの中で最も優先度の高いメッセージにより前記エージェントの優先度を決定するステップを有する、請求項１０に記載のエージェントのメッセージ処理方法。
【請求項１２】
前記所定の基準が、前記優先度が最低優先度以外のメッセージを処理し終えたことである、請求項７に記載のエージェントのメッセージ処理方法。
【請求項１３】
エージェントのメッセージを処理する方法であって、
前記エージェントの前記メッセージが最高優先度であるか否かを判断するステップと、
前記メッセージが最高優先度であることを条件として、前記エージェントの状態を最高優先度として管理するステップと、
前記メッセージの優先度が最高であるエージェントを検出するステップと、
前記メッセージの優先度が最高であるエージェントにスレッドを割り当てるステップと、
前記エージェントが前記メッセージを処理するステップと、
前記エージェントが所定の基準まで前記メッセージを処理したか判断するステップと、
前記所定の基準まで前記メッセージを処理したことを条件として、スレッドを開放するステップと、
を有する、エージェントのメッセージ処理方法。
【請求項１４】
前記スレッドを割り当てるステップが、さらに、前記優先度が最高優先度でないエージェントしか検出しないことを条件して、メモリ上にあるエージェントに優先的にスレッドを割り当てる、請求項１３に記載のエージェントのメッセージ処理方法。
【請求項１５】
前記スレッドを割り当てるステップは、前記メモリ上にあるか否かの状態が同一の場合、前記優先度の高いメッセージに優先的にスレッドを割り当てる、請求項１４に記載のエージェントのメッセージ処理方法。
【請求項１６】
前記所定の基準が、１つのエージェントにつき所定のメッセージ数を処理し終えたことである、請求項１３に記載のエージェントのメッセージ処理方法。
【請求項１７】
前記エージェントの状態を管理するステップが、さらに、前記メッセージを処理し終えたあと、残ったメッセージの中で最も優先度が高いメッセージによりエージェントの優先度を決定するステップを有する、請求項１６に記載のエージェントのメッセージ処理方法。
【請求項１８】
前記所定の基準が、前記優先度が最低優先度以外のメッセージを処理し終えたことである、請求項１３に記載のエージェントのメッセージ処理方法。
【請求項１９】
請求項７から１８のいずれかに記載の方法を実現するステップを、コンピュータに実行させるためのプログラム。
【請求項２０】
請求項１９に記載のプログラムを記録した記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、大量エージェントのメッセージを処理する、メッセージ処理装置、メッセージ処理方法、及びメッセージ処理プログラムに関する。
【背景技術】
【０００２】
近年、大量エージェントの処理を、短時間で行うシステムが必要になってきた。例えば、ユーザごとに用意されたエージェントに、各ユーザの嗜好に合わせた情報を鉄道の駅等で提供するシステムが挙げられる。このサービスは、予め登録されたユーザが駅の自動改札機を通過した際に、その駅周辺の情報を、ユーザの嗜好に合わせて検索し、ユーザの携帯端末等に送信するものである。このサービスでは、鉄道路線の全駅において、自動改札機を通過するユーザが対象となり得、同時刻に自動改札を通過するユーザ数の増加に伴って、短時間に大量のエージェントのメッセージを処理することが必要になる。
【０００３】
特許文献１によると、大量のエージェントのメッセージを効率的に処理するため、優先度の高いメッセージを持つエージェントを他のエージェントに優先して処理するようにしている。また、顧客ごとに用意されるエージェントにも、顧客に合わせた優先度により差を設け処理するようにしている。そして、データベースで管理されているエージェントでは、データベースへのアクセス負荷を軽減させるために、エージェントをシステムメモリ上にキャッシュし、メッセージ・キューに格納されているメッセージを、エージェント毎に全て処理し終わってから、またはメッセージの連続処理数の上限を越えたら、次のエージェントの処理に移ることにより、データベースへのアクセスを最小にしようとするものである。即ち、キャッシュ・メモリ上にあるエージェントを優先的に、エージェントおよびメッセージの優先度に合わせて、かつ、１つのエージェントのメッセージを連続処理することにより、データベースへのアクセス回数の削減を図り、メッセージの処理を促進しようとするものである。
【０００４】
【特許文献１】特開２００４−１９２０４７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記特許文献１の技術は、優先度の高いメッセージを持つエージェントを優先して処理するが、そのメッセージの処理は、データベースへのアクセス回数を削減するため、１つのエージェントで優先度の高いメッセージの処理だけでなく併せて優先度の低いメッセージも連続して処理するため、優先度の低いメッセージを処理した後でなければ、次のエージェントの優先度の高いメッセージの処理が行われない。もし、優先度の高いメッセージと低いメッセージを混合して持つエージェントが大量にある場合、各エージェントの優先度の高いメッセージと優先度の低いメッセージのそれぞれが処理されるため、より後に処理されるエージェントの優先度の高いメッセージの処理は、優先度の低いメッセージの処理が間に入るために、大幅に遅れることになる。
【０００６】
例えば、駅周辺情報配信サービスにおいては、遅延の問題が指摘される。駅周辺情報配信サービスとは、自動改札機に定期券を入れた際に、利用者が予め登録していた情報カテゴリに合致するような駅周辺の広告や交通情報を、エージェントから利用者の携帯電話等に送信するサービスである。これらのサービスを行う場合、駅からまだそれほど移動していない時間内に広告情報や交通情報が届かなければならない、情報の内容が各利用者の嗜好情報などに応じたものにしなければならない、などの時間と場所、嗜好情報の制約があり、これらを満たした上で、多くの利用者にサービスを提供しなければならない。これらの処理を行うエージェントは利用者毎に存在し、情報配信だけでなく、利用者に配信すべき新しい広告情報の登録処理も行う。また、広告登録時に利用者毎のサブスクライブ情報でフィルタする必要があるが、自動改札機通過時毎にデータベースの検索処理をして、利用者ごとにカスタマイズするような負荷のかかる処理は避ける必要がある。そのため、利用者ごとに配信対象となる広告情報等を持つようにしている。そして、このサービスでは、利用者が自動改札機を通過したときの情報配信処理については高速性が要求されるが、各利用者に対する広告情報の登録処理のようなものについては、それほど高速性は要求されない。
【０００７】
また、ユーザの携帯電話に内臓のＧＰＳ等でユーザの位置情報を得て、ユーザの要求に応じて、その携帯電話に、ユーザの時間、場所、嗜好に併せたピンポイントでの情報配信サービスなどでも、同様の遅延の問題が生じる可能性がある。すなわち、混雑するショッピングモールや観光地では、お店の広告情報の登録・配信処理のほか、ユーザからの要求によりレストランやカフェの空席情報の登録・配信処理も考えられる。この場合、ユーザへの配信処理にはユーザが情報を要求した場所からそれほど移動しない時間内に処理が必要で高速性が要求される。一方、登録処理においては、レストランやカフェの空席情報では比較的高速性が要求されるが、来月から開催されるセールの広告情報の登録処理などでは、高速性は要求されない。
【０００８】
しかし、上記特許文献１の技術を適用した場合、広範な利用者のカテゴリに合致するような広告情報が登録された時に、大きな遅延が生じる。以下、駅周辺情報配信サービスを中心に説明するが、これは一例であり、本発明の適用の範囲を駅周辺情報配信サービスに限定するものではない。
【０００９】
すなわち、駅周辺情報配信サービスにおいて、エージェントは、利用者が自動改札機を通過した際の情報配信処理のあとに、続けて広告登録処理を行ことになり、鉄道路線の全駅で複数の自動改札機が稼動していることを考えれば、多数の利用者が、ほぼ同時に自動改札を通過することが考えられ、より後に処理される利用者のエージェントからの情報配信は、他の利用者のエージェントの広告登録処理により、著しく遅れる場合がある。
【００１０】
この駅周辺情報配信サービスで、夕方のラッシュ時間帯を狙って広告を配信するということを考えて、以下の具体的場合を想定して簡単な計算をしてみる。
・路線すべての自動改札数を平均１駅１０改札機で５０駅として５００とし、このサービスの利用者は全利用者の１０％とする
・エージェントのキャッシュ・サイズを全エージェント数の５０％とする。
・繁忙期で全自動改札機がフル稼働しているとする。
・利用者が自動改札機に入ると１秒で通過し、すぐに次の利用者が入り始めるとする。
・全駅の半数の２５駅でそれぞれ1件の広告登録が行われ、全体で半数の利用者が登録された広告の配信対象となったとする。
・システムがフル稼働した時の、同時に複数のエージェントが並行して処理されている状況での、エージェントの処理時間は、エージェントがキャッシュ上にある場合で、自動改札通過にかかるエージェントのCPU時間を１８ms、エージェントがキャッシュにない場合で、自動改札通過にかかるエージェントのCPU時間を２１ms、エージェントがキャッシュにある場合で、広告情報登録にかかるエージェントのCPU時間を２０msとする。
・エージェントの処理パターンは下記の４パターンになる。
A) キャッシュにあるエージェントで、広告登録処理の対象となるエージェント
B) キャッシュにあるエージェントで、広告登録処理の対称でないエージェント
C) キャッシュにないエージェントで、広告登録処理の対象となるエージェント
D) キャッシュにないエージェントで、広告登録処理の対称でないエージェント
【００１１】
キャッシュ・サイズが５０％、広告登録処理の対象となるエージェントは全エージェントの半数なので、１秒間に処理されるエージェント数（毎秒５００人が全自動改札を通過し、そのうちの１０％が会員なので、５０エージェント）のうち、それぞれのパターンのエージェント数は１２.５である。ここで、自動改札通過処理を広告登録処理よりも優先して行いたいので、自動改札通過を示すメッセージの優先度を広告登録依頼を示すメッセージよりも高いものに設定する。エージェント・スケジューラは、キャッシュにあるエージェントを選択し、その自動改札通過処理を実行し、引き続き、そのエージェントの広告登録処理を実行する。キャッシュに自動改札通過を示すメッセージを待つエージェントがなくなったら、キャッシュにないエージェントをキャッシュに読み込み、自動改札通過処理を実行し、引き続き、そのエージェントの広告登録処理を実行する。
【００１２】
すべてのキャッシュにあるエージェントの処理が完了するのに要する時間は、
１２.５×１８ms＋１２.５×(１８ms＋２０ms)＝７００ms
キャッシュにないエージェントの処理がすべて完了するまでに要する時間は、
１２.５×２１ms＋１２.５×(２１ms＋２０ms)＝７７５ms
である。この合計は１４７５msであり、１秒を４７５ms超える。１秒を超えると、次の利用者が自動改札に入るため、新たな自動改札通過を示すメッセージが次々とシステムに到着する。すると、エージェント・スケジューラは、またキャッシュ内にあるエージェントの処理を行う。前の１秒の間で処理されなかったエージェント（これらはキャッシュにないエージェント）の処理は後回しにされる。自動改札機には次々と利用者が通過していくため、処理されずに残されるエージェントが累積していく。これは、何人かの利用者へ広告が届かないということを意味する。以上のように、様々な優先度のメッセージが混在する状況で、即応性の高い処理を適切な時間内に処理することはできない。
【００１３】
そこで本発明は、上記の課題を解決することのできる大量エージェントのメッセージを処理する、メッセージ処理装置、メッセージ処理方法、及びメッセージ処理プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１４】
上記課題を解決するために、本発明においては、  メモリと、エージェントに挿入されるメッセージにより前記エージェントの優先度を決定し、前記エージェントが前記メモリ上にあるか否か、およびメッセージの有無により、前記エージェントの状態を管理する手段と、前記優先度が最高優先度であるエージェントを検出したことを条件として、前記エージェントが前記メモリ上にあればスレッドを割り当て、前記エージェントが前記メモリ上になければ前記エージェントを前記メモリ上に呼び出してスレッドを割り当てる手段と、スレッドが割り当てられた前記エージェントに関して、所定の基準までメッセージの処理を繰り返すメッセージ処理手段とを備える装置を提供する。優先度の高いメッセージを持つエージェントにスレッドが割り当てられ、エージェントがメッセージを所定基準まで処理することで、データベース（ディスク）へのアクセス回数を抑えつつ優先度の高いメッセージの処理が進む。
【００１５】
なお、上記の発明の概要は、本発明の必要な特徴の全てを列挙したものではなく、これらの特徴群のサブコンビネーションもまた、発明となりうる。
【発明を実施するための最良の形態】
【００１６】
以下、発明の実施の形態を通じて本発明を説明するが、以下の実施形態は特許請求の範囲にかかる発明を限定するものではなく、また実施形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。
【００１７】
図１は、駅周辺情報配信サービスに本発明を適用した場合の例を示している。構成１０はサービス提供の概略を示す。ネットワーク１１は、インターネットや電話回線その他を含む通信網である。本発明に従うメッセージ処理システム１２、ユーザ広告情報データベース１３、駅の自動改札機１４、情報受信端末１５および情報登録端末１６はネットワーク１１を介して相互にデータおよび各種情報を送受信する。メッセージ処理システム１２は、利用者が駅の自動改札１４を通過したことを契機に、または、その他のことを契機に、ユーザ広告情報データベース１３から各ユーザに最適化された広告情報を検出し、配信情報として該当する情報受信端末１５に配信する。また、情報登録端末１６は、交通情報や広告情報等の駅周辺情報を登録するためのものであり、この駅周辺情報は、メッセージ処理システム１２がユーザごとに選択・編集してユーザ広告情報データベース１３に登録する。
【００１８】
ユーザは予め自分の嗜好や特に興味のある事柄につきキーワードを登録しておく。キーワードとしては、「PCおよび周辺機器」、「家具」、「花」、「洋服」、「アクセサリ」等が例として挙げられる。そして、鉄道路線沿いの駅周辺の店は、広告情報を登録する。この広告情報は、ユーザ毎のキーワードにより取捨選択され、ユーザ広告情報データベース１３にユーザ毎に登録される。登録の際には、広告情報は、ユーザ毎に必要なカスタマイズもされる。キーワードに「洋服」を登録したユーザが電車を降りて駅の自動改札機１４を通過すると、メッセージ処理システムにその情報が送られる。ユーザの識別は、駅自動改札を通過する際に、IDを付与した定期券等を認識することで可能である。メッセージ処理システム１２では、イベント情報を元に、ユーザが降車した駅に洋服に関する広告情報があれば、メッセージを該当するユーザのエージェントのキューに挿入する。このメッセージをエージェントが処理すると、ユーザは情報受信端末１５でこの情報を受信する。情報受信端末１５は携帯電話、ＰＤＡやノート・パソコンを含むが、情報を受信する機能があれば、これらに限られない。
【００１９】
また、広告主等が、情報登録端末１６から広告情報を入力すると、メッセージ処理システム１２にその情報が送られる。メッセージ処理システム１２では、イベント情報を元に、ユーザのエージェント・キューに挿入する。例えば、広告情報がアクセサリに関するものであれば、キーワードに「アクセサリ」を登録しているユーザ広告情報登録データベース１３のユーザ・レコードが広告情報の登録対象となる。このメッセージの処理は、各ユーザ毎にカスタマイズされたアクセサリの広告情報を登録することになる。また、ユーザ広告情報登録データベース１３には、広告情報の他に交通情報なども登録する。
【００２０】
図２は、メッセージ処理システムのハード構成２０の概要である。中央演算処理装置であるCPU２０１は各種ＯＳの制御下で様々なプログラムを実行する。ＣＰＵ２０１はバス２０２を介して、メモリ２０３、ディスク２０４、ディスプレイ・アダプタ２０５、ユーザ・インタフェース２０６およびネットワーク・インタフェース２０７と相互接続される。ユーザ・インタフェース２０６を通して、キーボード２０８およびマウス２０９に接続され、ディスプレイ・アダプタ２０５を通してディスプレイ装置２０８に接続され、ネットワーク・インタフェース２０７を通してネットワークに接続される。メモリ２０３は、主メモリやキャッシュ・メモリを含み、キャッシュ・メモリはエージェントやメッセージをキャッシュするのにも使用される。ハード・ディスク２０４は、エージェント・データベースやサブスクライブ・テーブルの登録に使用される。これは、コンピュータ・システムおよびバス配置の一実施形態の例にすぎず、本発明の特徴は、さまざまなシステム構成で、同一の構成要素を複数有する形態で、また、ネットワーク上に分散された形態で使用することができる。
【００２１】
図３はエージェント処理システム３００を模式的に示したものである。３０１はクライアント、３０２はメッセージ・ブローカ、３０３はメッセージ・リゾルバ、３０４はメッセージング機構、３０５サブスクライブ・テーブル、３０６はキャッシュ・メモリ、３０７はエージェントのデータベースである。メッセージ・ブローカ３０２は、クライアントからの各種情報のやり取りに関する通信を担い、イベント情報をメッセージ・リゾルバ３０３が受け取る。そして、メッセージ・リゾルバ３０３は、イベント情報に対応するエージェント情報をサブスクライブ・テーブル３０５から検出し、メッセージング機構３０４は、そのエージェント情報にしたがって対応するメッセージをメッセージ・キューに挿入する。また、エージェント処理システムは、エージェントをキャッシュ・メモリ３０６に読み込み、また、キャッシュ・メモリ３０６からエージェントを破棄し、またエージェントにスレッドを割り当てる。
【００２２】
図４はメッセージ処理装置の機能を模式的に示したものである。スレッド割り当て手段４０１は、エージェントの管理手段４０２に従い、スレッド４０４を割り当てていく。メッセージ処理手段４０３は、所定基準に達するまで、エージェントのメッセージを処理する。スレッド割り当て手段４０１は、キャッシュ・メモリ３０６にあるエージェントにスレッドを割り当てるほか、データベース３０７からエージェントをキャッシュ・メモリに呼び出し、スレッドを割り当てることもある。エージェントの管理手段４０２は、エージェントの有するメッセージの優先度や、エージェントがキャッシュ・メモリ上にあるか否かにより、スレッド割り当てのスケジューリングを行う。スケジューリングの機構については図５から１２で詳述する。
【００２３】
図５はエージェントの状態を示す変数値を例示する。これらの変数値は後述する図６のエージェントを管理するための機構で使用する。エージェントの状態を示す変数には、RUNNING、IN_FILLED、IN_EMPTY、OUT_FILLED、OUT_EMPTYおよびMAX_PRI_FILLEDが存在する。RUNNINGは、エージェントにスレッドが割り当てられていることを示し、IN_FILLEDは
エージェントがキャッシュ・メモリにあり、メッセージ・キューにメッセージがあることを示し、IN_EMPTYは
エージェントがキャッシュ・メモリにあり、メッセージ・キューが空であることを示し、
OUT_FILLEDはエージェントはキャッシュ・メモリになく、メッセージ・キューにメッセージがあることを示し、OUT_EMPTYは
エージェントがキャッシュ・メモリになく、メッセージ・キューが空であることを示し、MAX_PRI_FILLED
最高優先度のメッセージを持つことを示す。
【００２４】
図６はエージェントのもつメッセージの優先度による状態を管理するための機構を示す。優先度は０から３が存在し、さらに３より上の最高優先度MAX_PRI_FILLEDが存在する場合を例にあげる。優先度が０から３には、RUNNING、IN_FILLED、IN_EMPTY、OUT_FILLED、OUT_EMPTYが存在するが、MAX_PRI_FILLEDには、メモリ上へのIN／OUTの区別はない。これは、優先度が最高であるメッセージを持つ場合、メモリ上の有無に係わらず、状態をMAX_PRI_FILLEDに設定し、処理を優先するためである。
【００２５】
図７は、図６の制御ブロック(ControlBlock)のデータ構造を示している。テーブル７０１は、エージェント・キー(AgentKey)と制御ブロックとの１：１の対応関係を示している。エージェント・キーは、エージェントを識別するものであり、各配信先（ユーザ）に対して１：１に対応している。図７のテーブル７０１では、各エージェント・キーを人名（マイク(Mike)、トム(Tom)、エリック(Eric)）により表している。制御ブロック７０２は、MessageQueue queue、ControlBlock prev、ControlBlock next、byte stateおよびString typeを含む。MessageQueue queueはそれが対応付けられているメッセージ・キューについてのデータを示す。ControlBlock prevは、それが連結される前側の制御ブロックについてのデータを示す。ControlBlock nextは、それが連結される後ろ側の制御ブロックについてのデータを示す。byte stateは、それが今ある状態（IN_FILLEDやIN_EMPTY等）を示す。String typeは、ストリング・タイプのデータを示す。
【００２６】
図８はエージェントの状態遷移を示したものである。エージェントの状態遷移の更新は、この図に基づいて行われる。この状態遷移では、IN_FILLED、IN_EMPTY、OUT_FILLED、OUT_EMPTYの状態から、エージェントが最高優先度のメッセージを受け取ると、MAX_PRI_FILLEDに遷移し、スレッドが空き次第、このエージェントにスレッドを優先的に割り当て、RUNNING状態に移行する。
【００２７】
図９は、メッセージ挿入によるエージェントの状態の更新フローを示す。ステップ９０１でメッセージを受け取ると、ステップ９０２で受け取ったメッセージがエージェントのもつメッセージの中で最も高い優先度か否か判断する。受け取ったメッセージが最も高いメッセージではないと判断した場合は更新処理を抜ける。受け取ったメッセージが現在持つメッセージの中で最も高いメッセージであると判断した場合はステップ９０３に進む。ステップ９０３ではメッセージの優先度が最高であるか否か判断する。優先度が最高である場合はステップ９０４で、エージェントの状態を優先度が最高であるMAX_PRI_FILLEDに更新して、制御ブロックの連結処理の更新も行い、処理を抜ける。優先度が最高でない場合、ステップ９０５で受け取ったメッセージの優先度を決める。この時併せて制御ブロックの連結処理の更新も行う。次にステップ９０６で、エージェントがメッセージを持っていたか否か、即ち、図８のOUT_ FILLEDまたはIN_ FILLEDのどちらかであるか否かを判断する。エージェントがメッセージを持っていた場合は、エージェントの状態をOUT_FILLEDまたはIN_FILLEDでかつエージェントの優先度に応じた状態に更新し、制御ブロックの連結処理の更新も行い、処理を抜ける。一方、エージェントがメッセージを持っていなかった場合、ステップ９０７で図８のReceived Messageに従い、エージェントの状態をOUT_ FILLEDまたはIN_ FILLEDでかつエージェントの優先度に応じた状態に更新して、制御ブロックの連結処理の更新も行い、処理を抜ける。
【００２８】
図１０は、エージェントのスレッド割り当てのフローを示す。ステップ１００１でMAX_PRI_FILLEDのメッセージを持つエージェントはあるか判断する。ないと判断された場合は、ステップ１００２でIN_FILLEDのメッセージはあるか判断する。ないと判断された場合は、ステップ１００３でOUT_FILLEDのメッセージがあるか判断する。メッセージがないと判断された場合は開始に戻る。ステップ１００１、１００２および１００３は、最も優先するメッセージの処理はMAX_PRI_FILLEDであるが、次に優先して処理するのは、キャッシュ・メモリ上にエージェントがあるメッセージである。すなわち、IN_FILLEDを優先する。これは、優先度の高いメッセージを処理することに加え、キャッシュ・メモリへのエージェントの呼び出し回数を低く抑えて、データベースへのアクセスを少なくするためである。また、エージェントのキャッシュ・メモリ上にあるか否かの状態が同一である場合は、より優先度の高いメッセージをもつエージェントに優先的にスレッドを割り当てるようにしてもよい。ステップ１００１、１００２および１００３で、エージェントがある（Ｙｅｓ）と判断された場合は、ステップ１００４でスレッドに空きがあるか否か判断する。スレッドに空きがある場合は、ステップ１００５でエージェントにスレッドを割り当てる。なお、エージェントがキャッシュ・メモリ上に無い場合は、キャッシュ・メモリに呼び出し、スレッドを割り当てる。スレッドに空きが無い場合は、開始に戻る。スレッドに空きが無い場合は、空くまでまってエージェントにスレッドを割り当てるようにしても良い。
【００２９】
図１１は、メッセージの処理のフローを示す。この処理は図１０のスレッドを割り当てるステップ１００５の後に行われる。ステップ１１０１でエージェントがメッセージを処理する。メッセージの処理は、優先度の高いメッセージから行われる。ステップ１１０２でエージェントに未処理のメッセージが残っているか判断する。メッセージが残っていないと判断した場合、ステップ１１０３で図８の状態遷移に従いIN_EMPTYまたはOUT_EMPTYに更新する。その後ステップ１１０６でスレッドを開放する。ステップ１１０２で、メッセージが残っていると判断した場合は、次に、ステップ１１０４で、所定の基準に達するまでメッセージを処理したか否か判断する。所定の基準とは、例えば、そのエージェントが持つすべての最高優先度のメッセージの処理が完了したことであったり、１つのエージェントにつき処理されるメッセージの連続処理数であったり、または、優先度２以上は全て処理するといった基準である。この処理基準は、メッセージ・キューに残る未処理のメッセージ数や、通勤時間帯に入っている等の状況により、動的に変更しても良い。ステップ１１０４でメッセージが所定の基準までメッセージを処理していないと判断した場合は、メセージの処理を繰り返すためにステップ１１０１に戻る。一方、メッセージを所定の基準に達するまで処理したと判断した場合は、ステップ１１０５で残るメッセージの内最も高い優先度にエージェントを更新する。その後ステップ１１０６でスレッドを開放する。
【００３０】
図１２は、図５のエージェントの優先度および状態を管理するための機構の変形例である。図５の優先度が０から３および最高優先度MAX_PRI_FILLEDに対し、図１０では、さらに最低優先度MINが存在する場合を示している。この場合、エージェントのメッセージを連続して処理し、次の処理すべきメッセージが最低優先度MINの場合は、そのエージェントのメッセージの処理は行わずに、エージェントの優先度をMINに設定して、他のエージェントの処理を行うようにする。図１１のステップ１１０５に、所定の基準として、優先度がMINより上のメッセージを処理するということを設定すればよい。これにより、より優先度の高いメッセージを持つエージェントの処理が進むことになる。なお、最低優先度MINは、他の優先度０〜３と同様にIN_FILLED、IN_EMPTY、OUT_FILLED、OUT_EMPTYの状態が存在する。
【００３１】
以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態に記載の範囲には限定されない。上記実施の形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。その様な変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。
【図面の簡単な説明】
【００３２】
【図１】メッセージ処理システムの概略図を示す。
【図２】メッセージ処理システムのハードウェア構成の一例を示す。
【図３】メッセージ処理システムの概要図の一例を示す。
【図４】メッセージ処理システムの機能構成の一例を示す。
【図５】エージェントの状態を示す変数値の一例を示す。
【図６】エージェントの優先度および状態を管理するための機構の一例を示す。
【図７】制御ブロック(ControlBlock)のデータ構造の一例を示す。
【図８】エージェントの状態遷移の一例を示す。
【図９】メッセージ挿入によるエージェントの状態の更新フローの一例を示す。
【図１０】エージェントのスレッド割り当てのフローの一例を示す動作フローである。
【図１１】メッセージの処理のフローの一例を示す。
【図１２】エージェントの優先度および状態を管理するための機構の変形例の一例を示す。
【図１】
2006185363.tif 000003
【図２】
2006185363.tif 000004
【図３】
2006185363.tif 000005
【図４】
2006185363.tif 000006
【図５】
2006185363.tif 000007
【図６】
2006185363.tif 000008
【図７】
2006185363.tif 000009
【図８】
2006185363.tif 000010
【図９】
2006185363.tif 000011
【図１０】
2006185363.tif 000012
【図１１】
2006185363.tif 000013
【図１２】
2006185363.tif 000014