JP3768748B2 - Method invocation method - Google Patents

Method invocation method Download PDF

Info

Publication number
JP3768748B2
JP3768748B2 JP33142499A JP33142499A JP3768748B2 JP 3768748 B2 JP3768748 B2 JP 3768748B2 JP 33142499 A JP33142499 A JP 33142499A JP 33142499 A JP33142499 A JP 33142499A JP 3768748 B2 JP3768748 B2 JP 3768748B2
Authority
JP
Japan
Prior art keywords
request
information
management unit
class
unit
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
Application number
JP33142499A
Other languages
Japanese (ja)
Other versions
JP2001147811A (en
Inventor
美昭 寺島
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mitsubishi Electric Corp
Original Assignee
Mitsubishi Electric Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Mitsubishi Electric Corp filed Critical Mitsubishi Electric Corp
Priority to JP33142499A priority Critical patent/JP3768748B2/en
Publication of JP2001147811A publication Critical patent/JP2001147811A/en
Application granted granted Critical
Publication of JP3768748B2 publication Critical patent/JP3768748B2/en
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Landscapes

  • Multi Processors (AREA)

Description

【０００１】
【発明の属する技術分野】
本発明は、データとメソッドをカプセル化した単位であるオブジェクトを備えたサーバに対してオブジェクト実行環境部がクライアントにて行われたアプリケーションインタフェース呼び出し情報をメッセージ通信によりサーバへ伝達し、この情報を受信したサーバでは、一旦リクエストをキューに蓄積した後、キューイングされたリクエストを、例えば、登録時間の古いものから順番に分析し、この結果から該当するオブジェクトのメソッド起動を行い、このメソッドの処理結果をクライアントのプログラミング呼び出しの結果として返す、クライアント／サーバ型のアプリケーションを実現する分散オブジェクト指向システムのメソッド起動方式に関するものである。
【０００２】
【従来の技術】
従来例の構成を説明する。
図２９は、特開平４−２３０５４３「オブジェクト指向システムに於いて使用するデータ構造」に示される一般的なオブジェクト指向システム構成の一例を示す図である。
図２９に一例として示すシステムは、ＲＡＭ（３００９）とＣＰＵ（３０１０）と入出力インタフェース（３０１１）を内蔵し、端末装置（３０１３）とデータ記憶装置（３０１８）とプリンタ（３０２１）などの外部装置を収容している計算機システムである。この計算機システムでは、これらのハードウェアをプログラマブルに制御するためのマイクロ命令コード（３００７）とオペレーティングシステム（３００６）とデータ管理装置（３００５）によるプラットフォーム（３００２）を隠蔽するために、オブジェクト指向プログラミングシステム（３００４）を備える。これにより、アプリケーションプログラム（３００３）をオブジェクト指向の考えに基づき構築できるようにした分散オブジェクト指向システムを実現構成している。
【０００３】
また、オブジェクト指向の考えに基づくアプリケーション構築のために、図３０に一例として示すメッセンジャシステムの構成により、オブジェクトはクラスにより一つ以上に分類され、オブジェクトの作用としてメソッドを起動するために、メッセンジャ（３１３０）によりメッセージが送られる。
【０００４】
オブジェクトを識別するデータ構造は、図３１に一例として示すように、独自のオブジェクト識別子を有する固定的な部分としてのオブジェクト識別欄（３０１２）と、データ記憶装置（３０１８）内のデータフレーム内のアクセスアドレス（３１０３）であるインスタンスデータフレームアドレス（３１０９）により構成される非固定的な部分により構成されており、この従来例では状況に応じてメッセージ送信先を最適に決定できるように設定することができる。
【０００５】
この従来例では、図２９のように、コンピュータプログラム（３００１）は、アプリケーションプログラムとオブジェクト指向プログラミングシステムが一体となった構成となっている。図３０に一例として示すメッセンジャ（３１３０）及び図３１に一例として示すオブジェクト管理表を使用して、複数のアプリケーションプログラム（３００３）の間でメソッド起動を要求する場合を考える。一のアプリケーションプログラム（要求側）（３００３）が、他のアプリケーションプログラム（３００３）に対してメッセージ通信により処理を要求する場合、要求側アプリケーションプログラム（３００３）は、そのシステムのオブジェクト指向プログラミングシステム（３００４）を介して、メッセージを送ることになる。この時のメッセージは、図３０に示すメッセンジャ（３１３０）によりメッセージを送る。ここでメッセンジャ（３１３０）は、図３１に示すオブジェクト管理表（３１２３）を参照する事により、要求先アプリケーションプログラム（３００１）を該当するクラス識別子（３１０５）、インスタンス識別子（３１０６）等から特定したアプリケーションプログラム（３００１）へメッセージを伝える。
このような構成ではアプリケーションプログラム（３００３）間で行われるメソッド起動を、オブジェクト指向プログラミングシステム（３００４）にて集中的に管理しており、この結果メッセージにて要求されるオブジェクト管理表（３１２３）の情報から一意にメソッドとしてのオブジェクトを識別するように構成しているため、クライアントからの複数のメッセージの蓄積数や登録時間などの情報を考慮した処理を実現する事が出来ない。
【０００６】
【発明が解決しようとする課題】
従来のオブジェクト指向システムのメソッド起動方式は、以上のように構成されている。このため、リクエストは個別に蓄積されている。従って、各リクエストの内容を比較することなく、メソッド起動を独立に実行すると、次のような不具合がある。例えば、同一リクエストが複数存在する場合には、その存在するリクエストの数分の同一メソッド起動を実行することになる。このため、時間、メモリ、ＣＰＵなど計算機資源を浪費し、他のリクエストによるメソッド起動の待ち状態が発生する。クライアントは、サーバへ要求した処理結果を期待するリアルタイムに取得できないという問題点があった。
【０００７】
また、リクエストスケジューリングにおいて、あるクライアントが発行したリクエストに対する処理が、それ以前にリクエストを蓄積するリクエストキューに蓄積されたリクエストによる予測不可能なメソッド動作時間の間ブロック（処理されずに、待ち状態になっていること）されてしまうため、リクエストがリクエストキューに蓄積されてから実行されるまでの時間に制約を加えることができず、クライアントはメソッド処理結果を適切なタイミングで得られないという問題点があった。
【０００８】
クラス毎にリクエストスケジューリングのリアルタイム性能を規定するクラスポリシィについて、各クラス間の比較を行い規定しなければならず、実際にサーバにて実行されているリクエストの傾向に対応した適切な値の定義が難しいという問題点があった。
【０００９】
同一のクラスの同一のメソッドに対して計算を依頼するリクエストに対して、このリクエストがキューに蓄積されている時間内に発生する状況の変化により、改めて異なるパラメータによる計算を依頼するリクエストを再発行する場合、先に発行したパラメータによるリクエストによるメソッド起動を無駄に実行することに加え、新たな状況に対応したパラメータによるメソッド起動を行うリクエストの処理がブロックされるという問題点があった。
【００１０】
あるクラスのメソッドに対する計算の依頼が集中した場合、この集中によるメソッド起動の重要度を考慮せず、リクエストがキューに蓄積された時間によるリクエストスケジューリングが行われるため、多くのクライアントが要求している計算を迅速に処理できず、かつ、リクエスト数分の同一計算を実行することによる資源の無駄が発生するという問題点があった。
【００１１】
あるクラスのメソッドに対する計算をキューにリクエストに蓄積されている回数分実行することにより、計算機資源の無駄が発生するという問題点があった。
【００１２】
クラスポリシィが更新された場合に、その情報が既に動作しているサーバのリクエストスケジューリングに反映されないという問題点があった。
【００１３】
複数のサーバに対して同一のリクエストが要求された場合に、これらのサーバの間で同一のメソッド処理結果を共有することができないため、各サーバで計算機資源の無駄が発生するという問題点があった。
【００１４】
この発明は、上記のような問題点を解決するために、１のリクエストを処理して処理結果を取得する際に、複数の同じリクエストへ取得した処理結果を返信することによって複数のリクエストを処理するメソッド起動方式を実現させることを目的とする。
【００１５】
【課題を解決するための手段】
この発明に係るメソッド起動方式は、クライアントから発信される、データを処理するメソッドを起動するリクエストを受信するメソッド起動方式において、
メソッドを起動するサーバと、
上記クライアントからのリクエストを受信し、受信したリクエストをサーバへ発信するオブジェクト実行環境部とを備え、
上記オブジェクト実行環境部は、さらに、メソッドを特定するメソッド情報と、複数のリクエストをまとめて処理する条件を規定する複数処理条件とをクラスポリシィとして、複数のクラスポリシィを記憶するクラスポリシィリポジトリを備え、
上記サーバは、さらに、上記クラスポリシィリポジトリを検索して、受信したリクエストが所属するクラスポリシィをメソッド情報に基づいて特定し、特定したクラスポリシィの複数処理条件と、リクエストを受信した状況としてのリクエスト蓄積状況とを管理するリクエストキュー管理部と、
リクエストキュー管理部によって管理される複数処理条件とリクエスト蓄積状況とを記憶するメソッド呼び出しテーブルと、
メソッドを起動して処理結果を取得するとともに、上記メソッド呼び出しテーブルを参照し、リクエストが属するクラスポリシィのリクエスト蓄積状況が複数処理条件を満たしている場合には、上記処理結果を、リクエストを発信した複数のクライアントそれぞれへ返信して複数のリクエストをまとめて処理するリクエストディスパッチ部とを備えたことを特徴とする。
【００１６】
上記メソッド起動方式は、さらに、上記クラスポリシィを入力するクラスポリシィ入力インタフェースを備え、
上記オブジェクト実行環境部は、入力されたクラスポリシィを受信し、受信したクラスポリシィを上記クラスポリシィリポジトリへ書き込むクラスポリシィ管理部を備えたことを特徴とする。
【００１７】
上記リクエスト蓄積状況は、受信したリクエストの蓄積数であり、
上記複数処理条件は、上記リクエストディスパッチ部が複数のリクエストをまとめて処理する場合のリクエスト蓄積数の境界値を定める境界蓄積数を含み、
上記リクエストディスパッチ部は、上記リクエスト蓄積数が上記境界蓄積数以上である場合に複数のリクエストを処理することを特徴とする。
【００１８】
上記複数処理条件は、リクエストがリクエストキュー管理部に受信されてからリクエストが処理されるまでの限界の時間を示す限界時間を含み、
上記サーバは、さらに、リクエストを受信した順番にリクエストを登録するリクエストキューテーブルを備え、
上記リクエストキュー管理部は、上記リクエストキューテーブルに、受信したリクエストを登録するとともに、リクエストを受信した時間を登録時間として登録し、
上記メソッド呼び出しテーブルは、複数処理条件として上記限界時間を記憶し、
上記リクエストディスパッチ部は、リクエストの属するクラスポリシィの限界時間をメソッド呼び出しテーブルから取得し、起動するメソッドのメソッド情報と同じメソッド情報を有するメソッドを起動するリクエストを上記リクエストキューテーブルから検出し、検出したリクエストの登録時間より上記限界時間を超えたリクエストを抽出し、抽出したリクエストを発信したクライアントへ上記処理結果を返信することを特徴とする。
【００１９】
上記オブジェクト実行環境部は、上記メソッド呼び出しテーブルから、クラスポリシィ毎のリクエスト蓄積状況を読み込み、読み込んだリクエスト蓄積状況を解析することによって、上記複数処理条件を変更するクラスポリシィ統計処理部を備えたことを特徴とする。
【００２０】
上記メソッド情報は、メソッドの処理内容を特定するメソッド種別と、クライアントがメソッドに受け渡すパラメータとを含むこと特徴とする。
【００２１】
上記メソッド情報は、メソッドの処理内容を特定するメソッド種別を含み、
上記リクエストディスパッチ部は、上記メソッド情報が同じリクエストの内、メッセージ管理部によって最後に受信されたリクエストによって指定されているメソッドに受け渡すパラメータを使用してメソッドを起動すること特徴とする。
【００２２】
上記リクエストディスパッチ部は、上記リクエストキュー管理部がリクエストを受信した順番にリクエストを処理し、処理するリクエストの蓄積数が上記境界蓄積数に達している場合に、複数のリクエストを処理することを特徴とする。
【００２３】
上記リクエストディスパッチ部は、クラスポリシィ毎に蓄積されたリクエストの蓄積数を検索して、リクエストの蓄積数が上記境界蓄積数以上蓄積しているクラスポリシィを検出し、検出したクラスポリシィに属するリクエストを処理することを特徴とする。
【００２４】
上記オブジェクト実行環境部は、さらに、クラスポリシィ入力インタフェースから入力されたクラスポリシィを上記クラスポリシィ管理部から受信し、受信したクラスポリシィの複数処理条件を更新情報としてサーバのリクエストキュー管理部に配信するクラスポリシィ更新情報配信部を備え、
上記リクエストキュー管理部は、受信した複数処理条件をメソッド呼び出しテーブルに書き込むことを特徴とする。
【００２５】
上記リクエスト蓄積状況は、受信したリクエストの蓄積数であり、
上記複数処理条件は、上記リクエストディスパッチ部が複数のリクエストをまとめて処理する場合のリクエスト蓄積数の下限値を定める最小蓄積数を含み、
上記リクエストキュー管理部は、メソッド呼び出しテーブルを検索して上記リクエスト蓄積数が上記最小蓄積数以上になったリクエストを検出し、検出したリクエストを上記リクエストディスパッチ部へ通知し、
上記リクエストディスパッチ部は、上記リクエストキュー管理部から通知を受けたリクエストについて、複数のリクエストを処理することを特徴とする。
【００２６】
上記メソッド起動方式は、複数のサーバを備え、
リクエストディスパッチ部は、メソッドを起動した処理結果を記憶し、
サーバは、さらに、自己が起動するメソッドとメソッド情報が同じメソッドを起動する他のサーバを比較して検索し、検索したサーバへ記憶した処理結果を配信するリクエスト比較部を備えたことを特徴とする。
【００２７】
この発明に係る記録媒体は、クライアントから発信される、データを処理するメソッドを起動するリクエストを受信するメソッド起動方式としてコンピュータに動作させるためのプログラムを記録したコンピュータ読取可能な記録媒体において、
メソッドを起動するサーバと、
上記クライアントからのリクエストを受信し、受信したリクエストをサーバへ発信するオブジェクト実行環境部とを備え、
上記オブジェクト実行環境部は、さらに、メソッドを特定するメソッド情報と、複数のリクエストをまとめて処理する条件を規定する複数処理条件とをクラスポリシィとして、複数のクラスポリシィを記憶するクラスポリシィリポジトリを備え、
上記サーバは、さらに、上記クラスポリシィリポジトリを検索して、受信したリクエストが所属するクラスポリシィをメソッド情報に基づいて特定し、特定したクラスポリシィの複数処理条件と、リクエストを受信した状況としてのリクエスト蓄積状況とを管理するリクエストキュー管理部と、
リクエストキュー管理部によって管理される複数処理条件とリクエスト蓄積状況とを記憶するメソッド呼び出しテーブルと、
メソッドを起動して処理結果を取得するとともに、上記メソッド呼び出しテーブルを参照し、リクエストが属するクラスポリシィのリクエスト蓄積状況が複数処理条件を満たしている場合には、上記処理結果を、リクエストを発信した複数のクライアントそれぞれへ返信して複数のリクエストをまとめて処理するリクエストディスパッチ部とを備えたメソッド起動方式としてコンピュータに動作させるためのプログラムを記録したコンピュータ読取可能な記録媒体を備えたことを特徴とする。
【００２８】
【発明の実施の形態】
実施の形態１．
この実施の形態は、予めクラス毎に同一のメソッド起動を要求するリクエストが、同時にキューイングされる最大数をクラスポリシィとして規定し、規定したクラスポリシィを利用してメソッド起動を実施することを特徴とする。また、以下の実施の形態では、オブジェクト指向システムで実現する例を一例として説明する。
【００２９】
図１は、この実施の形態で一例として説明するこの発明のメソッド起動方式を実現するオブジェクト指向システムを示している。
このオブジェクト指向システムは、クライアント／サーバモデルに基づく分散オブジェクト指向によるアプリケーション構成を実現するオブジェクト実行環境部（１）と、クラスポリシィを入力するインタフェース機能を備えたクラスポリシィ入力インタフェース（２）と、クライアントとして動作し、メソッドを起動するリクエストを発信するクライアント（３）と、サーバとして動作するサーバ（４）により構成される。
【００３０】
オブジェクト実行環境部（１）は、以下の構成要素を備える。
オブジェクト管理部（１０１）は、サーバの状態や存在する位置などを管理する。
クラスポリシィ管理部（１０２）は、クラスポリシィを管理する。
クラスポリシィリポジトリ（１０３）は、メソッドを特定するメソッド情報と、複数のリクエストをまとめて処理する条件を規定する複数処理条件とをクラスポリシィとして、複数のクラスポリシィを記憶する。
従って、クラスポリシィは、予め、クライアントがクラス毎に期待するリクエストスケジューリングによるメソッド起動方法を定めることになる。
メッセージ通信管理部（１０４）は、クライアントとサーバ間のメッセージ通信を管理する。
また、リクエストとはメソッド起動の要求であり、リクエスト情報とはリクエストによって起動を要求するメソッドを特定し、起動条件を特定する情報をいう。従って、１つのリクエストにはそれぞれリクエスト情報が特定されている。この明細書では、リクエストにはリクエスト情報を含むものとする。
【００３１】
クライアント（３）は、以下の構成要素を備える。
クライアントロジック部（３０１）は、クライアントとして動作するアプリケーションである。
クライアントメッセージ通信管理部（３０２）は、クライアントロジック部（３０１）にて呼び出されるプログラミングインタフェース情報をメッセージ通信にてオブジェクト実行管理部（１）へ伝える。
【００３２】
サーバ（４）は、以下の構成要素を備える。
サーバロジック部（４０１）は、サーバとして動作するアプリケーションである。
リクエストキュー管理部（４０２）は、上記クラスポリシィリポジトリ（１０３）を検索して、受信したリクエストが所属するクラスポリシィをメソッド情報に基づいて特定し、特定したクラスポリシィの複数処理条件と、リクエストを受信した状況としてのリクエスト蓄積状況とを管理し、リクエストを受信した状況としてのリクエスト蓄積状況とを後述するメソッド呼び出しテーブルへ登録する。さらに、受信したリクエストを後述するリクエストキューテーブル（４０３）へ登録する。この実施の形態では、複数処理条件として、クラスポリシィ毎のリクエストの蓄積数の境界値を境界蓄積数として設定している。
リクエストキューテーブル（４０３）は、実際にリクエストを格納するデータベースである。
リクエストディスパッチ部（４０４）は、メソッドを起動して処理結果を取得するとともに、メソッド呼び出しテーブル（４０６）を参照し、リクエストが属するクラスポリシィのリクエスト蓄積状況が複数処理条件を満たしている場合には、上記処理結果を、リクエストを発信した複数のクライアントそれぞれへ返信して複数のリクエストをまとめて処理する。
なお、以降の説明では、メソッドを起動して得た結果を「処理結果」又は「実行結果」ということがあるが、同じ意味で用いている。
メソッド呼び出しテーブル（４０６）は、リクエストキュー管理部（４０２）によって管理される複数処理条件とリクエスト蓄積状況とを記憶する。クラスポリシィとメソッド種別との対応づけを行っている。
【００３３】
また、以下に説明するこの発明に係るメソッド起動方式は、コンピュータに動作させるためのプログラムによって実現される。従って、このメソッド起動方式を実現するためのプログラムは、コンピュータで読取可能な記録媒体に記録することができるものである。
サーバ（４）のサーバロジック部（４０１）は、クラスより生成されたインスタンスであるオブジェクト部（４０１２）を備える。さらに、オブジェクト部（４０１２）は、クラスにて規定されるメソッド（４０１１）を備える。
【００３４】
図２は、リクエストキューテーブル（４０３）の一例を示している。
リクエストキューテーブル（４０３）は、一のサーバ（４）に蓄積されるリクエストを登録するデータベースである。また、登録された時間が古いリクエストから順番に蓄積番号（Ｔ０１０１）が振られ、各リクエスト情報として起動するメソッドの特定に必要なメソッド特定情報と、メソッドの起動に必要な起動情報を記憶する。メソッド特定情報として、オブジェクト種別（Ｔ０１０２）とメソッド種別（Ｔ０１０３）を含み、リクエストにより起動されるメソッドを特定する。また、メソッド毎のメソッド情報として、パラメータ１情報（Ｔ０１０４）、パラメータ２情報（Ｔ１０１５）及びリターン情報（Ｔ０１０６）を含む。また、以下では、パラメータ１情報（Ｔ０１０４）とパラメータ２情報（Ｔ１０１５）とをパラメータ情報（Ｔ０１０４，Ｔ０１０５）として表わすこともある。
【００３５】
図３は、クラスポリシィリポジトリ（１０３）の一例を示す図である。
クラスポリシィリポジトリ（１０３）は、メソッドを特定するメソッド情報と、複数のリクエストをまとめて処理する条件を規定する複数処理条件とをクラスポリシィとして記憶する。
この実施の形態では、メソッド情報は、メソッド特定情報と、メソッド起動情報とからなる。メソッド特定情報として、クラス種別（Ｔ０２０１）とクラス毎に規定されるメソッド種別（Ｔ０２０２）とを含む。さらに、メソッド毎のメソッド起動情報として、パラメータ１情報（Ｔ０２０３）、パラメータ２情報（Ｔ０２０４）及びリターン情報（Ｔ０２０５）とを含む。また、以下では、パラメータ１情報（Ｔ０２０３）とパラメータ２情報（Ｔ０２０４）とをパラメータ情報（Ｔ０２０３，Ｔ０２０４）として表わすこともある。
クラス種別は、オブジェクトの型を決めるためのメソッドと変数を定義するひな形である。
メソッド種別は、メソッドの種類を特定する。
また、複数処理条件は、一のサーバ（４）のメッセージキューテーブル（４０１）に同時に登録されることが許される最大リクエスト数である境界蓄積数（Ｔ０２０６）とする場合を説明する。
【００３６】
図４は、メソッド呼び出しテーブル（４０６）の一例を示す図である。
一のサーバ（４）に蓄積されているリクエスト種別と、クラスポリシィにより規定されるこのリクエストにより起動されるメソッドに許された同時蓄積するの関係を管理するデータベースである。
この実施の形態では、オブジェクト種別（Ｔ０３０１）と、メソッド情報（Ｔ０３０２〜Ｔ０３０５）と、複数処理条件として、複数のリクエストをまとめて処理することを判断する境界となる蓄積数である境界蓄積数（Ｔ０３０６）と、リクエストを受信した状況としてのリクエスト蓄積状況として、リクエストキュー管理部が受信したリクエストの蓄積数（Ｔ０３０６）とを記憶する。
オブジェクト種別は、クラス種別とメソッド種別とから、サーバにおいて特定される。
メソッド呼び出しテーブル（４０６）は、Ｔ０３０２〜Ｔ０３０５に基づいて、リクエストを上記クラスポリシィリポジトリ（１０３）毎に分類して記憶しており、さらに、サーバ（４）のサーバロジック部（４０１）において、メソッドを管理する単位であるオブジェクト種別（Ｔ０３０１）と、上記クラスポリシィとを関連付けて記憶している。
上記で説明した情報は、リクエストキュー管理部（４０２）によって、登録される。
このように、この実施の形態のメソッド呼び出しテーブルは、リクエスト蓄積状況として、リクエストをカウントして蓄積数を記憶することより、メソッド呼び出しカウントテーブルとも呼ぶ。
【００３７】
次に、この実施の形態におけるオブジェクト指向システムの動作を説明する。まず、このオブジェクト指向システムを動作させるにあたっては、クラスポリシィをクラスポリシィリポジトリ（１０３）へ登録する「クラスポリシィ登録処理」が実行されていることが前提となる。
そこで、まず、「クラスポリシィ登録処理」の動作について説明する。次に、この発明の特徴となる、「リクエストカウンタ登録処理」及び「メソッド呼び出しカウンタ処理」について説明する。
「リクエストカウンタ登録処理」とは、サーバ（４）がオブジェクト実行環境部（１）のクラスポリシィリポジトリ（１０３）に登録されているクラスポリシィを取得し、内部のメソッド呼び出しテーブル（４０６）に登録する処理をいう。
「メソッド呼び出しカウンタ処理」とは、クラスポリシィリポジトリ（１０３）からメソッド呼び出しテーブル（４０６）を生成する処理をいう。これは、リクエストキュー管理部（４０２）によって実施される。
次に、クライアント（３）がメソッドを起動するリクエストを発信してからサーバ（４）によって、メソッドを起動するまでの処理を「通常のメソッド起動処理」と「同一リクエストによるメソッド起動処理」とに分けて説明する。
なお、以下の図５〜図１０の説明では、各構成要素間の情報の伝達は、メッセージを用いている場合を説明する。メッセージは、Ｍｘｘｘｘ（ｘｘｘｘは番号）で表わしている。
【００３８】
まず、図５を用いて「クラスポリシィ登録処理」の動作について説明する。
クラスポリシィは、システム管理者が指定する。システム管理者は、クラスポリシィ入力インタフェース（２）からクラスポリシィを入力する。入力されたクラスポリシィは、メッセージＭ０１０１（以下、「メッセージ」は省略する）によりオブジェクト実行環境部（１）のクラスポリシィ管理部（１０２）へ伝えられる。Ｍ０１０１を受信したクラスポリシィ管理部（１０２）は、クラスポリシィ登録処理として、Ｍ０１０１によって受信した、登録することを要求されたクラスポリシィをクラスポリシィリポジトリ（１０３）に格納することにより動作を終了する。
【００３９】
次に、図６を用いて「リクエストカウンタ登録処理」の動作について説明する。
「リクエストカウンタ登録処理」は、以下に説明する「リクエストカウンタ分析処理」と、「クラスポリシィ検索処理」と、「メソッド呼び出しテーブル生成処理」とを含む。この「リクエストカウンタ登録処理」は、この発明の特徴となるクラスポリシィに基づいて、クライアント（３）からオブジェクト実行環境部（１）を介してサーバ（４）へ送信されたリクエストを登録する工程である。
サーバ（４）のサーバメッセージ通信管理部（１０４）は、受信したリクエストをリクエストキュー管理部（４０２）へ渡す。リクエストキュー管理部（４０２）は、リクエストを解析して、リクエストカウンタ登録処理を実施する。
サーバ（４）は、リクエストを受信すると、まず、「リクエストカウンタ分析処理」を行う。「リクエストカウンタ分析処理」は、メソッド呼び出しテーブル（４０６）に基づいて、受信したリクエストと同一リクエストが存在するかどうかの分析を行う。この実施の形態における同一のリクエストとは、リクエストが同一オブジェクト種別、同一メソッド種別であり、さらに、同一パラメータ情報と同一リターン情報にてメソッド起動を要求しているリクエストをさす。
この分析により、既に同一リクエストがメソッド呼び出しテーブル（４０６）に存在する場合は、メソッド呼び出しテーブル（４０６）の該当するテーブルの蓄積数（Ｔ０３０７）（図４）をインクリメントする。同一リクエストが存在しない場合は、以下に説明する「クラスポリシィ検索処理」及び「メソッド呼び出しテーブル生成処理」を実行する。
【００４０】
次に、「リクエストカウンタ分析処理」の結果、同一リクエストが存在しない場合の動作を図６を用いて説明する。
リクエストカウンタテーブル（４０６）は、サーバ内に実装されているオブジェクトに対応したクラスポリシィをオブジェクト実行環境部（１）から取得するために、サーバメッセージ通信管理部（４０５）へクラスポリシィを特定する情報をＭ０２０１によって送る。この実施の形態では、クラスポリシィを特定する情報は、メソッド情報と複数処理条件とが該当するが、これに限られるわけではない。
Ｍ０２０１を受信したサーバメッセージ通信管理部（４０５）は、Ｍ０２０１によって受信したクラスポリシィを特定する情報を、Ｍ０２０２によってオブジェクト実行環境部（１）のメッセージ通信管理部（１０４）へ送る。
Ｍ０２０２を受信したメッセージ通信管理部（１０４）は、Ｍ０２０２の情報をＭ０２０３によって、クラスポリシィ管理部（１０２）へ送る。
Ｍ０２０３を受信したクラスポリシィ管理部（１０２）は、Ｍ０２０３によって伝えられたクラスポリシィを特定する情報からクラスポリシィを取得するために、「クラスポリシィ検索処理」を実行する。
「クラスポリシィ検索処理」は、クラスポリシィリポジトリ（１０３）から、クラスポリシィを特定する情報によって要求されたクラスに該当するクラスポリシィを検索する。
検索されたクラスポリシィは、Ｍ０２０４によってクラスポリシィ管理部（１０２）からメッセージ通信管理部（１０４）へ送られる。
Ｍ０２０４を受信したメッセージ通信管理部（１０４）は、Ｍ０２０４の情報をＭ０２０５によって、サーバ（４）のサーバメッセージ通信管理部（４０５）へ送る。
Ｍ０２０５を受信したサーバメッセージ通信管理部（４０５）は、Ｍ０２０５の情報をＭ０２０６によってメソッド呼び出しテーブル（４０６）へ送る。
この結果、メソッド呼び出しテーブル（４０６）は、Ｍ０２０６によって該当するクラスポリシィを取得し、次に、「メソッド呼び出しカウンタ生成処理」を実行する。
【００４１】
続いて、図３と図４を用いて「メソッド呼び出しカウンタ生成処理」の動作を説明する。
取得したクラスポリシィの構造は、図３に示すように、クラス種別（Ｔ０２０１）毎に、そのクラスに規定されている１つ以上のメソッドメソッド情報であるメソッド種別（Ｔ０２０２）、及びパラメータ情報（Ｔ０２０３，Ｔ０２０４）、リターン情報（Ｔ０２０５）、さらに、そのメソッド毎に１つのサーバ（４）のリクエストキューテーブル（４０３）に蓄積されるリクエストを複数まとめて処理することを判断する境界となる境界蓄積数（Ｔ０２０６）により構成されている。この情報の中で受信したリクエストによって要求されているメソッドメソッド情報が特定され、図４に示すメソッド呼び出しテーブル構成の１つのテーブルに展開される。例えば、リクエストによりクラス種別がクラス＿１から生成されたオブジェクト“Ｏｂｊｅｃｔ＿１”のメソッド“ｍｅｔｈｏｄ＿１”に対して、パラメータが“ｉｎ ｉｎｔ １０００”，“ｉｎ ｉｎｔ １０”，．．．、及びリターン情報が“ｉｎｔ”により返される要求を行った場合、図３に示すクラス種別（Ｔ０２０１）がクラス＿１のテーブルがクラスポリシィとして取得され、この情報から図４に示す１番目のテーブルが作成される。
なお、メソッド呼び出しテーブル（４０６）の境界蓄積数（Ｔ０３０６）が空欄の場合（取得したクラスポリシィの境界蓄積数（Ｔ０２０６）が空欄であること）は、境界蓄積数が無限であることを意味している。
【００４２】
次に、図７と図８と図２を用いて、「通常のメソッド起動処理」の動作を説明する。
通常のメソッド起動処理の動作は、最も基本的な動作をいい、クライアントがリクエストを発行し、該当するサーバのメソッドの処理結果を得るまでの動作である。
また、後述する同一リクエストによるメソッド起動処理の動作では、複数のリクエストをまとめて処理する場合を説明する。
【００４３】
クライアント（３）のクライアントロジック部（３０１）は、予め用意されているアプリケーションインタフェースを呼び出し、このアプリケーションインタフェースを用いてリクエストを発行する。この際、リクエストに関するリクエスト情報も生成される。このリクエストは、リクエスト情報とともにＭ０３０１によりクライアントメッセージ通信管理部（３０２）へ送られる。
Ｍ０３０１を受信したクライアントメッセージ通信管理部（３０２）は、この情報をメッセージによって送信できる形式に変換し、Ｍ０３０２にてオブジェクト実行環境部（１）のメッセージ通信管理部（１０４）へ送る。
Ｍ０３０２を受信したメッセージ通信管理部は、Ｍ０３０２の情報をＭ０３０３にてオブジェクト管理部（１０１）へ送る。
【００４４】
Ｍ０３０３を受信したオブジェクト管理部（１０１）は、Ｍ０３０３にて受け取ったリクエスト情報から、「サーバ分析処理」としてサーバ（４）の存在する場所と動作状態を分析し、該当サーバ（４）がリクエストを受け取ることができる状態であることを確認した後、リクエスト情報を該当サーバ（４）へ送信するために、Ｍ０３０４にてメッセージ通信管理部（１０４）へ情報を送る。
Ｍ０３０４を受信したメッセージ通信管理部（１０４）は、Ｍ０３０４の情報をＭ０３０５にて、該当サーバ（４）のサーバメッセージ通信管理部（４０５）へ送る。
【００４５】
Ｍ０３０５を受信したサーバメッセージ通信管理部（４０５）は、Ｍ０３０５の情報をＭ０３０６にてリクエストキュー管理部（４０２）へ送る。
Ｍ０３０６を受信したリクエストキュー管理部（４０２）は、Ｍ０３０６の情報をＭ０３０７にてメソッド呼び出しテーブル（４０６）へ送る。
Ｍ０３０７を受信したメソッド呼び出しテーブル（４０６）では、リクエストキュー管理部（４０２）の指示によって、「リクエストカウンタ登録処理」が実行される。「リクエストカウンタ登録処理」の詳細は前述したので、ここでは説明を省略する。
メソッド呼び出しテーブル（４０６）は、リクエストカウンタ登録処理が実施された後に、処理の完了をＭ０３０８にてリクエストキュー管理部（４０２）へ送る。
【００４６】
Ｍ０３０８を受信したリクエストキュー管理部（４０２）は、メソッド呼び出しテーブル（４０６）に対して「リクエスト登録処理」の実行を指示する。
「リクエスト登録処理」は、Ｍ０３０６にて伝えられたリクエスト情報をリクエストキューテーブルに登録する。
【００４７】
「リクエスト登録処理」の操作を、図２を用いて説明する。
図２は、リクエストキューテーブル（４０３）の構造を示しており、新たに登録するリクエスト情報は蓄積番号（Ｔ０１０１）として既に登録されている番号から連続した値を割り当てられる。そして、オブジェクト種別（Ｔ０１０２）、メソッド種別（Ｔ０１０３）、パラメータ情報（Ｔ０１０４，Ｔ０１０５等）、リターン情報（Ｔ０１０６）にリクエスト情報が展開されることにより登録が完了する。
以上のリクエスト登録処理の完了により、サーバ（４）に対してリクエストの登録が完了し、クライアント（３）はリクエスト応答待ち状態となる（図７）。
【００４８】
リクエスト応答待ち状態になると、サーバ（４）のリクエストディスパッチ部（４０４）は、「リクエストディスパッチ処理」を実施する（図７）。
「リクエストディスパッチ処理」は、リクエストディスパッチ部（４０４）がＭ０３０９をリクエストキュー管理部（４０２）へ送ることによって、次に処理すべきリクエストを取得する。
Ｍ０３０９を受信したリクエストキュー管理部（４０２）では、「該当リクエスト分析処理」によって、次に処理すべきリクエストの検索を行う。
「該当リクエスト分析処理」は、リクエストキューテーブル（４０３）から蓄積番号（Ｔ０１０１）が１を示すリクエストを取り出し、取り出したリクエストを同じリクエストがメソッド呼び出しテーブルに存在するか否かを分析する。具体的には、「該当リクエスト分析処理」は、リクエストキューテーブル（４０３）のテーブルの中から蓄積番号（Ｔ０１０１）が“１”のリクエストを取得し、このリクエスト情報のオブジェクト種別（Ｔ０１０２）、メソッド種別（Ｔ０１０３）、パラメータ情報（Ｔ０１０４，Ｔ０１０５）及びリターン情報（Ｔ０１０６）が、メソッド呼び出しテーブル（４０６）のオブジェクト種別（Ｔ０３０１）、メソッド種別（Ｔ０３０２）、パラメータ情報（Ｔ０３０４，Ｔ０３０５）及びリターン情報（Ｔ０３０６）の全てが一致する場合に、その蓄積数（Ｔ０３０７）が境界蓄積数（Ｔ０３０６）に達しているかどうかを判断し、境界蓄積数（Ｔ０３０６）に達していない場合は「通常のメソッド起動」と判断し、境界蓄積数（Ｔ０３０６）に達している場合には「同一リクエストによるメソッド起動」と判断する。
【００４９】
Ｍ０３１０を受信したメソッド呼び出しテーブル（４０６）では、メソッド呼び出しテーブル（４０６）とリクエストキューテーブルの比較を行い、この結果をＭ０３１１にてリクエストキュー管理部（４０２）へ送る。
以上により、「該当リクエスト分析処理」が終了する。「該当リクエスト分析処理」の結果が「通常のメソッド起動」の場合を以降に説明し、「同一リクエストによるメソッド起動」の場合の動作を後の「同一リクエストによるメソッド起動の動作」にて説明する。
【００５０】
「該当リクエスト分析処理」により「通常のメソッド起動」を判断したリクエストキュー管理部（４０２）は、次に処理されるリクエストが「通常のメソッド起動」であることと、次に処理すべきリクエストの情報をＭ０３１２にてリクエストディスパッチ部（４０４）へ送る。
Ｍ０３１２を受信したリクエストディスパッチ部（４０４）は、次に処理すべきリクエストの情報から起動するメソッドを特定し、メソッド起動をＭ０３１３にてサーバロジック部（４０１）へ指示する。
Ｍ０３１３にてメソッド起動を指示されたサーバロジック部（４０１）は、指定されたオブジェクト（４０１２）のメソッド（４０１１）のメソッド起動を指示し、その処理結果をＭ０３１４にてリクエストディスパッチ部（４０４）へ送る。
Ｍ０３１４を受信したリクエストディスパッチ部（４０４）は、Ｍ０３１４の情報をＭ０３１５にてリクエストキュー管理部（４０２）へ送る。
Ｍ０３１５を受信したリクエストキュー管理部（４０２）は、Ｍ０３１６によりメソッド呼び出しテーブル（４０６）に対して、処理を実施したメソッド呼び出しカウンタの蓄積数（Ｔ０３０７）のデクリメントを行う「リクエストカウンタ削除処理」を指示する。
Ｍ０３１６を受信したメソッド呼び出しテーブル（４０６）では、リクエストカウンタ削除処理を実行する。ここでデクリメントした蓄積数（Ｔ０３０７）が“０”の場合は、そのクラスポリシィのデータを削除する。
Ｍ０３１６を送信したリクエストキュー管理部（４０２）は、処理が終了したリクエストキューテーブル（４０３）の蓄積番号（Ｔ１０１０）が“１”のリクエストを削除し、残りのリクエストに割り当てられている蓄積番号（Ｔ０１０１）をすべてデクリメントする。
続いて、リクエストキュー管理部（４０２）は、Ｍ０３１５の情報をＭ０３１７にてサーバメッセージ通信管理部（４０５）へ送る。
Ｍ０３１７を受信したサーバメッセージ通信管理部（４０５）は、Ｍ０３１７の情報をＭ０３１８にてオブジェクト実行管理部（１）のメッセージ通信管理部（１０４）へ送る。
Ｍ０３１８を受信したメッセージ通信管理部は、Ｍ０３１８の情報をＭ０３１９にてオブジェクト管理部（１０１）へ送る。
Ｍ０３１９を受信したオブジェクト管理部は、Ｍ０３１９の情報をＭ０３２０にて、メッセージ通信管理部（１０４）へ送る。
【００５１】
Ｍ０３２０を受信したメッセージ通信管理部（１０４）は、Ｍ０３２０の情報Ｍ０３２１にてクライアント（３）のクライアントメッセージ通信管理部（３０２）へ送る。
Ｍ０３２１を受信したクライアントメッセージ通信管理部（３０２）は、Ｍ０３２１にて受け取ったメソッド処理結果をメッセージからプログラミングインタフェースへ変換し、Ｍ０３２２にてクライアントロジック部へ送る。
以上の処理の結果、クライアントロジック部は、プログラミングインタフェースにより要求したリクエストの結果を取得する処理が完了する。
【００５２】
図９と図１０と図１１を用いて「同一リクエストによるメソッド起動」の動作について説明する。
この動作は、「通常のメソッド起動」と同様に、「該当リクエスト分析処理」が実行され、この結果が「同一リクエストによるメソッド起動」を判断した場合の動作であり、この判断以前の動作は既に説明した「通常のメソッド起動」の動作と同様である。従って、図９は、図７に表わした「リクエスト応答待ち状態」になるまでの動作を省略して表わしている。
【００５３】
該当リクエスト分析処理の結果が「同一リクエストによるメソッド起動」と判断したリクエストキュー管理部（４０２）は、「同一リクエストによるメソッド起動」であることと、次に処理されるリクエストの情報とを、Ｍ０４０２にてリクエストディスパッチ部（４０４）へ送る（図９）。
Ｍ０４０２を受信したリクエストディスパッチ部（４０４）は、次に処理すべきリクエストの情報から起動するメソッドを特定し、メソッド起動をＭ０４０３にてサーバロジック部（４０１）へ指示する。
Ｍ０４０３にてメソッド起動を指示されたサーバロジック部（４０１）は、指定されたオブジェクト（４０１２）のメソッド（４０１１）のメソッド起動を指示し、その処理結果をＭ０４０４にてリクエストディスパッチ部（４０４）へ送る。
Ｍ０４０４によりメソッド処理結果を取得したリクエストディスパッチ部（４０４）は、この結果を同一リクエストを発行した全てのクライアント（３）へ返送を判断する。
【００５４】
以降のメソッド処理結果の返送の動作は、一例として、図１０に示すクライアントＡとクライアントＢへ応答を返送する場合について説明する。
図１０の例では、クライアントＡ（３）の方がクライアントＢ（３）よりもリクエストを発行した時間が古いとする。
Ｍ０４０４を受信したリクエストディスパッチ部（４０４）は、同一リクエストを発行したクライアントＡ（３）とクライアントＢ（３）へ、Ｍ０４０４の情報をそれぞれＭ０４０５，Ｍ０４１０にてリクエストキュー管理部（４０２）へ送る。
【００５５】
以下に、計算結果を送信する場合の動作の詳細を説明する。
初めに、クライアントＡ（３）へメソッド処理結果を送信する場合の動作を説明する。
リクエストキュー管理部（４０２）は、最も古い時間に登録されたリクエストとしてリクエストキューテーブル（４０３）の蓄積番号（Ｔ０１０１）が“１”に該当するリクエストが属するクラスポリシィのメソッド呼び出しテーブル（４０６）の蓄積数（Ｔ０３０７）をデクリメントするリクエストカウンタ削除処理をＭ０４０６にてメソッド呼び出しテーブル（４０６）へ指示する。
Ｍ０４０６を受信したメソッド呼び出しテーブル（４０６）では、リクエストカウンタ削除処理を実行する。
リクエストカウンタ削除処理では、メソッド呼び出しテーブル（４０６）の該当するテーブルの蓄積数（Ｔ０３０７）をデクリメントする。この説明の例では、デクリメントの結果は“１”となる。
【００５６】
リクエストキュー管理部（４０２）では、Ｍ０４０６を送信した後、受信したＭ０４０５の情報をクライアントＡへ伝えるために、Ｍ０４０７にてサーバメッセージ通信管理部（４０５）へ送る。
Ｍ０４０７を受信したサーバメッセージ通信管理部（４０５）は、Ｍ０４０７の情報オブジェクト実行環境部（１）を介して、Ｍ０４０８にてクライアントＡ（３）のクライアントメッセージ通信管理部（３０２）へ送る。
この間のオブジェクト実行環境部（１）の動作は、「通常のメソッド起動」の場合と全く同じであるため、説明を省略する。
【００５７】
Ｍ０４０８を受信したクライアントメッセージ通信管理部（３０２）は、Ｍ０４０８にて受け取ったメソッド処理結果をメッセージからプログラミングインタフェースへ変換し、Ｍ０４０９にてクライアントロジック部へ送る。
以上の処理の結果、クライアントＡ（３）のクライアントロジック部は、プログラミングインタフェースにより要求したリクエストの結果を取得するメソッド実行結果取得が完了する。
【００５８】
引き続き同一リクエストを発行したクライアントＢ（３）がメソッド処理結果を取得する動作を説明する。
Ｍ０４１０によりメソッド処理結果を取得したリクエストキュー管理部（４０２）は、リクエストキューテーブル（４０３）の蓄積番号（Ｔ０１０１）が最も古いリクエストが属するクラスポリシィのメソッド呼び出しテーブル（４０６）の蓄積数（Ｔ０３０７）をデクリメントするリクエストカウンタ削除処理をＭ０４１１にてメソッド呼び出しテーブル（４０６）へ指示する。
Ｍ０４１１を受信したメソッド呼び出しテーブル（４０６）では、リクエストカウンタ削除処理を実行する。
リクエストカウンタ削除処理では、メソッド呼び出しテーブル（４０６）の該当するテーブルの蓄積数（Ｔ０３０７）をデクリメントする。この説明の例ではデクリメントの結果は“０”となるはずであり、この場合は、該当するクラスポリシィのデータ全体を削除する。
【００５９】
リクエストキュー管理部（４０２）では、Ｍ０４１１を送信した後、Ｍ０４１２の情報をクライアントＢへ伝えるために、Ｍ０４１２にてサーバメッセージ通信管理部（４０５）へ送る。
Ｍ０４１２を受信したサーバメッセージ通信管理部（４０５）は、Ｍ０４１２の情報オブジェクト実行環境部（１）を介して、Ｍ０４１３にてクライアントＢ（３）のクライアントメッセージ通信管理部（３０２）へ送る。
この間のオブジェクト実行環境部（１）の動作は、「通常のメソッド起動」の場合と全く同じであるため、説明を省略する。
【００６０】
Ｍ０４１３を受信したクライアントメッセージ通信管理部（３０２）は、Ｍ０４１３にて受け取ったメソッド処理結果をメッセージからプログラミングインタフェースへ変換し、Ｍ０４１４にてクライアントロジック部へ送る。
以上の処理の結果、クライアントＡ（３）のクライアントロジック部は、プログラミングインタフェースにより要求したリクエストの結果を取得するメソッド実行結果取得が完了する。
【００６１】
図１１を用いて同一リクエストによるメソッド起動により、クラスポリシィにて設定されたリアルタイムメソッド起動が保証される動作をリクエストキューテーブル（４０３）の動きを中心に説明する。
リクエストキューテーブル（４０３）には、クライアント（３）から発信されたリクエストに蓄積番号が振られて蓄積される。これに対して、リクエストキュー管理部（４０２）は、蓄積番号（Ｔ０１０１）が“１”から順番に取り出しメソッド起動を実施する。
この場合、図１１の例のように、蓄積番号２，３，７が全く同じ要求を実施した場合において、同一の要求が蓄積される最大数をクラスポリシィにより規定し、この限界に達した場合には、１つのリクエスト起動にて蓄積番号２，３，７へメソッド処理結果を返送する処理を同一リクエストによりメソッド起動として実現している。
【００６２】
以上のように、サーバのキューに蓄積された各リクエストが期待するメソッド起動を監視し、キューイングされた同一リクエストがクラスポリシィにて規定した数に達した場合には、次に同一リクエストの中で最も古いリクエストに対するメソッド起動が判断されたタイミングで、該当リクエストに対応して実施されたメソッドの処理結果を他の同一リクエストを行った全てのクライアントが取得する事により、アプリケーションソフトウェアとは独立に規定するクラスポリシィに基づいて、クライアントとサーバから透過にメソッド起動を実現することができる。
【００６３】
このようにして、予めクラス毎に期待するリクエストスケジューリングによるメソッド起動方法をクラスポリシィとしてクライアント（３）とサーバ（４）とは無関係に管理するオブジェクト実行環境部（１）と、サーバ（４）のリクエストスケジューリングにおいて、サーバ（４）のリクエストキュー管理部（４０２）は、リクエストキューテーブル（４０３）に蓄積されているリクエストと、クラスポリシィとを比較し、クラスポリシィに基づいた方法に従って、メソッド起動をリクエストディスパッチ部（４０４）へ指示することにより、クラス毎に異なるリアルタイム性を保証したメソッド起動を実現する。
【００６４】
また、このようにして、リクエストスケジューリングにおいて、同一リクエストの中で最もキューへの登録時間が古いものが処理されるタイミングでメソッド起動を行い、この結果を同一リクエストを発行した全てのクライアントへ応答として返送するという、同一のメソッドの実行回数を最低限に押さえることによるリクエストスケジューリング時に発生する不必要な計算機資源浪費の回避により、他のメソッド呼び出しのブロックを最低限に押さえたメソッド起動を、クラスポリシィに基づいてクライアントのクライアントロジックとサーバのサーバロジックから透過に実現することを特徴とするリアルタイムメソッド起動方式を実現する。
【００６５】
実施の形態２．
図１２は、実施の形態１におけるこの発明のメソッド起動方式を実現するオブジェクト指向システム構成図に対して、メソッド呼び出しテーブルを構成する項目を変えている。この実施の形態では、メソッド呼び出しテーブルをメソッド呼び出し限界時間テーブル（４０７）として説明する。
【００６６】
図１３は、この実施の形態のリクエストキューテーブルの一例を示している。図１３は、実施の形態１におけるリクエストキューテーブル構成に対して、各リクエスト毎の登録時間（Ｔ０１０７）を追加した構成である。
図１４は、この実施の形態のクラスポリシィリポジトリの一例を示している。図１４は、実施の形態１におけるクラスポリシィリポジトリ構成に対して、境界蓄積数を削除し、限界時間（Ｔ０２０７）を追加した構成である。
図１５は、この実施の形態のメソッド呼び出し限界時間テーブル（４０７）の一例を示している。
図１５は、サーバにおいて、リクエストにより要求されているメソッド起動種別毎にキューイングされる限界時間を登録したテーブルであり、クラス種別（Ｔ０４０１）、メソッド種別（Ｔ０４０２）、限界時間（Ｔ０４０３）を含む構成となっている。
【００６７】
次に、実施の形態２の動作を説明する。
実施の形態２の動作は、実施の形態１の動作に対して、リクエストカウンタ登録処理の代わりとなるリクエスト限界時間登録処理の動作を説明し、続いてメソッド呼び出し生成処理の代わりとなるメソッド呼び出し限界時間生成処理の動作を説明し、続いて実施の形態２の場合のリクエストディスパッチ処理の動作を説明する。
【００６８】
実施の形態２のリクエスト限界時間登録処理の処理フローは、実施の形態１のリクエストカウンタ登録処理場合に対して、サーバ（４）のメソッド呼び出しテーブル（４０６）の代わりにメソッド呼び出し限界時間テーブル（４０７）を置き、メソッド呼び出しカウンタ生成処理の代わりにメソッド呼び出し限界時間生成処理を置く以外は全く同じである。このため、以降では実施の形態２独自の動作について説明する。
【００６９】
リクエスト限界時間登録処理は、サーバ（４）がリクエストを受信すると、「リクエストカウンタ分析処理」として、メソッド呼び出し限界時間テーブル（４０７）により、既に同一リクエストが存在するかどうかの判断を行う。この実施の形態の同一リクエストとは、実施の形態１とは異なり同じオブジェクトの同じメソッドに対してメソッド起動を要求しているリクエストとして判断する。この分析により既に同一リクエストが存在しない場合には、オブジェクト実行環境のクラスポリシィリポジトリに登録されているクラスポリシィを取得し、メソッド呼び出し限界時間テーブル（４０７）の該当するテーブルを作成する。
【００７０】
図１３と図１４を用いてメソッド呼び出し限界時間生成処理の動作を説明する。
取得したクラスポリシィの構造は、図１４に示すように、クラス種別（Ｔ０２０１）毎に、そのクラスに規定されている１つ以上のメソッドメソッド情報であるメソッド種別（Ｔ０２０２）及びパラメータ情報（Ｔ０２０３，Ｔ０２０４）、リターン情報（Ｔ０２０５）、さらに、そのメソッドが通常のメソッド起動にて処理される最大時間である限界時間（Ｔ０２０７）により構成されている。この情報の中で受信したリクエストにて要求されているメソッドメソッド情報が特定され、図１５に示すメソッド呼び出し限界時間テーブルに展開される。例えば、リクエストによりクラス種別がクラス＿１から生成されたオブジェクトＯｂｊｅｃｔ＿１のメソッドｍｅｔｈｏｄ＿１に対して、パラメータが“ｉｎ ｉｎｔ１０００”，“ｉｎ ｉｎｔ １０”，．．．及びリターン情報が“ｉｎｔ”により返される要求を行った場合、図１４に示すクラス種別（Ｔ０２０１）がクラス＿１のテーブルがクラスポリシィとして取得され、この情報から図１５に示す１番目のテーブルが作成される。
なお、メソッド呼び出し限界時間テーブル（４０７）の限界時間（Ｔ０２０７）が空欄の場合は、通常のメソッド起動しか行われないことを意味している。
【００７１】
実施の形態２の該当リクエスト分析処理の動作について説明する。
リクエストキュー管理部（４０２）が実行する該当リクエスト分析処理では、初めに、リクエストキューテーブル（４０３）のテーブルの中から蓄積番号（Ｔ０１０１）が“１”のリクエストを取得し、このリクエスト情報のオブジェクト種別（Ｔ０１０２）、メソッド種別（Ｔ０１０３）とメソッド呼び出し限界時間テーブル（４０７）のクラス種別（Ｔ０４０１）、メソッド種別（Ｔ０４０２）の全てが一致する場合を検索し、該当する限界時間（Ｔ０４０３）を取得する。次にリクエストキューテーブル（４０３）の各テーブルを検索し、蓄積番号“１”のリクエストを取得し、リクエスト情報のオブジェクト種別（Ｔ０１０２）、メソッド種別（Ｔ０１０３）、パラメータ情報（Ｔ０１０４，Ｔ０１０５）及びリターン情報（Ｔ０１０６）の全てが一致する場合のリクエストについて、各登録時間（Ｔ０１０７）を参照し、取得した該当限界時間を過ぎているものを「同一リクエストによるメソッド起動」と判断する。該当限界時間を過ぎているものが１つ（蓄積番号“１”のリクエスト）、あるいは全く無い場合には、「通常のメソッド起動」と判断して処理を続行する。
【００７２】
以上のように、サーバのキューに蓄積されたリクエストを監視し、同一リクエストがクラスポリシィにて規定された時間以上にキューイングされ実行待ちの状態にある場合には、次に同一リクエストの中で最も古いリクエストに対するメソッド起動が判断された時に、該当リクエストに対応して実施されたメソッドの処理結果を他の同一リクエストを行った全てのクライアントへ返送することにより、クライアントからのリクエストがキューイングされている時間に制約を加えたメソッド起動ができる。
【００７３】
実施の形態３．
図１６は、実施の形態１におけるこの発明のメソッド起動方式を実現するオブジェクト指向システム構成のオブジェクト実行へクラスポリシィ統計処理を追加した構成の一例である。
１０５は、メソッド呼び出しテーブル（４０６）から、クラスポリシィ毎のリクエスト蓄積状況を読み込み、読み込んだリクエスト蓄積状況を解析することによって、上記複数処理条件を変更するクラスポリシィ統計処理部（１０５）である。
この実施の形態では、リクエスト蓄積状況は、リクエストの蓄積数である場合を一例として説明する。
【００７４】
次に、図１７を用いて実施の形態３の動作を説明する。
初めに、クラスポリシィリポジトリ（１０３）を周期的に更新するクラスポリシィ定期更新処理の動作を説明する。
続いて、クラスポリシィを実際に行われているリクエストの数から統計的に計算するために、各サーバからリクエストにより行われるメソッドメソッド情報を収集するクラスポリシィ統計処理の動作を説明する。
【００７５】
図１７を用いて、クラスポリシィ統計処理の動作を説明する。
この動作は、実施の形態１における通常のメソッド起動動作において、サーバ（４）によってリクエスト登録処理が実行され、リクエスト応答待ち状態になる前に実行される処理である。
【００７６】
リクエストキュー管理部（４０２）がリクエスト登録処理を実行した後に、登録したリクエストに基づいて起動するオブジェクトのメソッドの元となるクラスとメソッド情報をＭ０５０１にてサーバメッセージ通信管理部（４０５）へ送る。
Ｍ０５０１を受信したサーバメッセージ通信管理部（４０５）は、Ｍ０５０１の情報をＭ０５０２にてオブジェクト実行環境部（１）のメッセージ通信管理部（１０４）へ送る。
Ｍ０５０２を受信したメッセージ通信管理部（１０４）では、Ｍ０５０２の情報をＭ０５０３にてクラスポリシィ統計処理部（１０５）へ送る。
Ｍ０５０３を受信したクラスポリシィ統計処理部（１０５）は、受信したクラスとメソッド情報を蓄積する。
【００７７】
クラスポリシィ定期更新処理の動作について説明する。
オブジェクト指向システム全体にて要求されるメソッド起動のためのクラスとメソッド情報を収集しているクラスポリシィ統計処理部（１０５）では、予め規定された周期毎に収集している情報から適切なクラスポリシィの境界蓄積数を計算し、クラスポリシィ管理部（１０２）へクラスポリシィリポジトリの更新を指示する。この指示を受けたクラスポリシィ管理部（１０２）では、クラスポリシィリポジトリ（１０３）の内容を更新する。
【００７８】
以上のように、クラス毎にメソッド起動のリアルタイム性を規定するクラスポリシィを、実際にオブジェクト指向システム内で実行されているクライアントからサーバに対するリクエスト状況を監視し一定時間周期に統計的に計算することにより、常に最新の状況に応じたクラスポリシィを自動的に設定することができる。
【００７９】
また、サーバに対して送信されるリクエスト送信の状況を反映したクラスポリシィの値を一定時間毎に自動的に更新することができる。
【００８０】
実施の形態４．
図１８は、実施の形態１におけるこの発明のメソッド起動方式を実現するオブジェクト指向システム構成へメソッド呼び出しテーブル（４０６）を構成する項目を変えている。この実施の形態では、メソッド呼び出しテーブル（４０６）をメソッド呼び出し集計テーブル（４０８）として説明する。
図１９は、メソッド呼び出し集計テーブル（４０８）の構成を示しており、クラス種別（Ｔ０５０１）、メソッド種別（Ｔ０５０２）、蓄積数（Ｔ０５０３）により構成されている。
【００８１】
次に、実施の形態４の動作を説明する。
初めに、実施の形態１のリクエストカウンタ登録処理の代わりに実行されるリクエスト集計登録処理の動作を説明する。
続いて、実施の形態１のメソッド呼び出し集計生成処理の代わりに実行されるメソッド呼び出し集計処理の動作を説明し、続いてリクエストディスパッチ処理と同一リクエストによるメソッド起動処理の動作を説明する。
【００８２】
実施の形態４のリクエスト集計登録処理の処理フローは実施の形態１によるリクエストカウンタ登録処理とほぼ同じであるが、以下の動作が異なる。
リクエスト集計登録処理は、サーバ（４）がリクエストを受信すると、「リクエスト集計分析処理」として、メソッド呼び出し集計テーブル（４０８）により、既に同一リクエストが存在するかどうかの判断が行われる。この実施の形態の同一リクエストとは、実施の形態１とは異なり同じオブジェクトの同じメソッドに対してメソッド起動を要求しているリクエストとして判断する。具体的には、メソッド呼び出し集計テーブル（４０８）のクラス種別（Ｔ０５０１）とメソッド種別（Ｔ０５０２）とが同一の場合をいう。この分析により、既に同一リクエストが存在する場合には、メソッド呼び出し集計テーブル（４０８）の該当するテーブルの蓄積数（Ｔ０５０３）をインクリメントし、存在しない場合にはオブジェクト実行環境部のクラスポリシィリポジトリに登録されているクラスポリシィを取得し、「メソッド呼び出し集計テーブル生成処理」による動作が起動される。
【００８３】
この実施の形態のメソッド起動方式は、クライアント（３）が、リクエストによって要求したメソッド起動の処理結果を、最新のパラメータによってメソッドが処理した処理結果を取得したい場合に適用できる。従って、パラメータがリクエストを発信したときと同一でなければならないリクエストの場合は、実施の形態１のメソッド起動方式を適用する必要がある。
【００８４】
図３と図１９を用いて、メソッド呼び出し集計生成処理の動作を説明する。
取得したクラスポリシィの構造は、図３に示すように、クラス種別（Ｔ０２０１）毎に、そのクラスに規定されている１つ以上のメソッドメソッド情報であるメソッド種別（Ｔ０２０２）及びパラメータ情報（Ｔ０２０３，Ｔ０２０４）、リターン情報（Ｔ０２０５）、さらに、そのメソッドが通常のメソッド起動にて処理される最大キューイング数である境界蓄積数（Ｔ０２０６）により構成されている。この情報の中で受信したリクエストにて要求されているメソッドメソッド情報が特定され、図１９に示すメソッド呼び出し集計テーブル構成の１つのテーブルに展開される。例えば、リクエストによりクラス種別がクラス＿１から生成されたオブジェクトＯｂｊｅｃｔ＿１のメソッドｍｅｔｈｏｄ＿１に対して、パラメータが“ｉｎ ｉｎｔ １０００”，“ｉｎ ｉｎｔ １０”，．．．及びリターン情報が“ｉｎｔ”により返される要求を行った場合、図１９に示すクラス種別（Ｔ０２０１）がクラス＿１、メソッド種別（Ｔ０５０２）がｍｅｔｈｏｄ＿１のテーブルがクラスポリシィとして取得され、この情報から図１９に示す１番目のテーブルが作成される。
【００８５】
実施の形態４の該当リクエスト分析処理の動作について説明する。
リクエストキュー管理部（４０２）が実行する該当リクエスト分析処理では、初めに、リクエストキューテーブル（４０３）のテーブルの中から蓄積番号（Ｔ０１０１）が“１”のリクエストを取得し、このリクエスト情報のオブジェクト種別（Ｔ０１０２）、メソッド種別（Ｔ０１０３）と呼び出し集計テーブル（４０８）のクラス種別（Ｔ０５０１）、メソッド種別（Ｔ０５０２）の全てが一致する場合を検索し、該当する蓄積数（Ｔ０５０３）を取得する。この蓄積数（Ｔ０５０３）が“１”の場合は、「通常のメソッド起動」と判断する。蓄積数（Ｔ０５０３）が“１”では無い場合はリクエストキューテーブル（４０３）の各テーブルを検索し、蓄積番号“１”と同一のリクエストを検索する。同一のリクエストとは、リクエスト情報のオブジェクト種別（Ｔ０１０２）、メソッド種別（Ｔ０１０３）及びリターン情報（Ｔ０３０５）が一致する場合を同一リクエストとして「同一リクエストによるメソッド起動」を判断する。
【００８６】
この実施の形態による同一リクエストによるメソッド起動処理の動作は、実施の形態１による同一リクエストによるメソッド起動処理の動作とほぼ同様である。しかし、以下に説明するメソッドを起動する処理が異なる。
該当リクエスト分析処理の結果が「同一リクエストによるメソッド起動」と判断したリクエストキュー管理部（４０２）は、「同一リクエストによるメソッド起動」であることと、次に処理されるリクエストの情報をＭ４０２にてリクエストディスパッチ部（４０４）へ送る。ただし、次に処理されるリクエストの情報は、リクエストキューテーブル（４０３）の蓄積番号（Ｔ０１０１）が最も大きなリクエストのパラメータ情報（Ｔ０１０４，Ｔ０１０５）とリターン情報（Ｔ０１０６）を用いる。
【００８７】
以上のように、サーバのキューに蓄積されたリクエストを監視し、蓄積された同一オブジェクトの同一メソッドに対するリクエストがクラスポリシィにて規定する数に達した場合は、次に同一リクエストの中で最も古いリクエストに対するメソッド起動が実行されるタイミングで、同一リクエストの中で最新のパラメータ情報とリターン情報からメソッド計算を指示することにより、クライアントは常に最新のメソッド計算の結果を得ることができる。
【００８８】
実施の形態５．
図２０は、この実施の形態５における該当リクエスト分析処理フロー図である。
次に、図２０を用いて実施の形態５の該当リクエスト分析処理の動作を説明する。
実施の形態５では、実施の形態１の動作に対して該当リクエスト分析処理の動作が異なる。
以下に、図１，図３，図２０を用いて動作を説明する。
リクエストキュー管理部（４０２）にて起動される該当リクエスト分析処理では、リクエストキューテーブル（４０３）に登録されている蓄積番号（Ｔ０１０１）が“１”のリクエストの情報を、Ｍ０６０１にてメソッド呼び出しテーブル（４０６）へ送る。
Ｍ０６０１を受信したメソッド呼び出しテーブル（４０６）では、受信したリクエストの情報のクラス種別とメソッド種別とパラメータ情報とリターン情報がそれぞれ、メソッド呼び出しテーブル（４０６）のオブジェクト種別（Ｔ０３０１）とメソッド種別（Ｔ０３０２）とパラメータ情報（Ｔ０３０３，Ｔ０３０４）とリターン情報（Ｔ０３０５）が全く同じテーブルを検索し、該当するテーブルの蓄積数（Ｔ０３０７）が境界蓄積数（Ｔ０３０６）に達しているものがあるかどうかを分析し、達していれば「同一リクエスト」と判断し、達していなければ「同一リクエストでは無い」と判断し、この結果をＭ０６０２にてリクエストキュー管理部（４０２）へ返送する。
【００８９】
Ｍ０６０２を受信したリクエストキュー管理部（４０２）では、同一リクエストが通知された場合は、そのリクエストに対して同一リクエストによるメソッド起動処理が行われる。
同一リクエストではないことが通知された場合は、リクエストキューテーブル（４０３）の次の蓄積番号（Ｔ０１０１）について同様に、Ｍ０６０１とＭ０６０２による判断が行われ、Ｍ０６０２により同一リクエストでは無いとの通知を受けた場合は、さらに処理を継続する。
以上の処理によりリクエストキューテーブル（４０３）の全てのリクエストが同一リクエストでは無いと判断された場合には、蓄積番号“１”のリクエストについて、通常のメソッド起動の処理が行われる。
【００９０】
以上のように、サーバのキューに蓄積されたリクエストを監視し、同一リクエストの数がクラスポリシィにて規定する数に達した場合は、この登録の後の最初のリクエストスケジューリングのタイミングで、優先して同一リクエストの中で最も登録時間の古いリクエストに対応したメソッド起動を実行し、この結果を同一リクエストを発行した全てのクライアントへ返送することにより、同一の要求が多いことによる重要度に従ったメソッド起動ができる。
【００９１】
また、このようにして、クライアントがリクエストを発行した時間に捕らわれないクラスポリシィに従ったメソッド起動を実現する。
【００９２】
実施の形態６．
図２１は、この実施の形態６におけるクラスポリシィリポジトリの構成図である。
図２２は、この実施の形態６におけるメソッド呼び出しテーブル構成図である。
図２１は、この実施の形態６におけるクラスポリシィリポジトリの一例を示す図である。図２１は、実施の形態１におけるクラスポリシィリポジトリに対して、境界蓄積数（Ｔ０２０６）に代わって、最小蓄積数（Ｔ０２０８）を追加した構成である。
図２２は、この実施の形態６におけるメソッド呼び出しテーブルの一例を示す図である。図２２は、実施の形態１におけるメソッド呼び出しテーブルに対して、境界蓄積数（Ｔ０３０６）に代わって、最小蓄積数（Ｔ０３０８）を追加した構成である。
【００９３】
次に、実施の形態６における動作を説明する。
初めに、実施の形態１と異なるメソッド呼び出しカウンタ生成処理の動作について説明し、続いて、実施の形態１と異なるリクエストディスパッチ処理の動作を説明する。
【００９４】
図２１と図２２を用いて、メソッド呼び出しカウンタ生成処理の動作を説明する。
取得したクラスポリシィの構造は、図２１に示すように、クラス種別（Ｔ０２０１）毎に、そのクラスに規定されている１つ以上のメソッドメソッド情報であるメソッド種別（Ｔ０２０２）及びパラメータ情報（Ｔ０２０３，Ｔ０２０４）、リターン情報（Ｔ０２０５）、さらに、そのメソッドが通常のメソッド起動にて処理される最低限の蓄積数である最小蓄積数（Ｔ０２０８）により構成されている。この情報の中で受信したリクエストにて要求されているメソッドメソッド情報が特定され、図２２に示すメソッド呼び出しテーブル構成の１つのテーブルに展開される。例えば、リクエストによりクラス種別がクラス＿１から生成されたオブジェクトＯｂｊｅｃｔ＿１のメソッドｍｅｔｈｏｄ＿１に対して、パラメータが“ｉｎ ｉｎｔ １０００”，“ｉｎ ｉｎｔ １０”，．．．及びリターン情報が“ｉｎｔ”により返される要求を行った場合、図２２に示すクラス種別（Ｔ０２０１）がクラス＿１のテーブルがクラスポリシィとして取得され、この情報から図２２に示す１番目のテーブルが作成される。
なお、メソッド呼び出しテーブル（４０７）の最小蓄積数（Ｔ０３０８）が空欄の場合は、通常のメソッド起動しか行われないことを意味している。
【００９５】
実施の形態６の該当リクエスト分析処理の動作について説明する。
リクエストキュー管理部（４０２）が実行する該当リクエスト分析処理では、初めに、リクエストキューテーブル（４０３）のテーブルの中から蓄積番号（Ｔ０１０１）が“１”のリクエストを取得し、このリクエスト情報のオブジェクト種別（Ｔ０１０２）とメソッド種別（Ｔ０１０３）とパラメータ情報（Ｔ０１０４，Ｔ０１０５）とリターン情報（Ｔ０１０６）のそれぞれが、メソッド呼び出しテーブル（４０６）のオブジェクト情報メソッド呼び出しテーブルのオブジェクト種別（Ｔ０３０１）とメソッド種別（Ｔ０３０２）とパラメータ種別（Ｔ０３０３，Ｔ０３０４）とリターン情報（Ｔ０３０５）と一致する場合を検索する。該当するテーブルが存在すれば、そのテーブルの蓄積数（Ｔ０３０７）が最小蓄積数（Ｔ０３０８）に達しているかどうかを判断し、達している場合は「同一リクエストによるメソッド起動」と判断する。また、該当するテーブルが存在しない場合には、「通常のメソッド起動」と判断する。該当するテーブルが存在するがそのテーブルの蓄積数（Ｔ０３０７）が最小蓄積数（Ｔ０３０８）に達していない場合は、リクエストキューテーブル（４０３）のテーブルの中から蓄積番号（Ｔ０１０１）が“２”のリクエストを取得し、同様に、「通常のメソッド起動」か「同一リクエストによるメソッド起動」かの判断を行い、決定できない場合は、さらに、次の蓄積番号（Ｔ０１０１）のリクエストについて分析を続ける。
上記では、メソッドの同一を判断する場合に、パラメータ情報も一致する場合を説明したが、パラメータが同一でない場合を、同一のメソッドであると判断する実施の形態も考えられる。
また、上記では、複数処理条件としてリクエスト蓄積数を採用したが、さらに、実施の形態２で説明した、限界時間を複数処理条件として追加して設定することも考えられる。
【００９６】
以上のように、サーバのキューに蓄積されたリクエストを監視し、キューイングされた同一リクエストがクラスポリシィに規定する数に達しない場合には、次に同一リクエストの中で最も古いリクエストに対するメソッド起動が判断された場合にもメソッド起動を保留し、規定する数に達した場合に同一リクエストの中で最も登録時間の古いリクエストに対応したメソッド起動を実行し、この結果を同一リクエストを発行した全てのクライアントへ返送することにより、リクエストに対応して実行するメソッド起動の数を最低限に押さえることができる。
【００９７】
実施の形態７．
図２３は、実施の形態１におけるオブジェクト指向システムに対してオブジェクト実行環境部にクラスポリシィ更新情報配信部（１０６）を追加した構成の一例である。
次に、図２４を用いて実施の形態７におけるクラスポリシィ更新情報配信処理の動作について説明する。
クラスポリシィ更新情報配信処理は、実施の形態１にて説明したクラスポリシィ登録処理の動作において、オブジェクト実行環境部（１）のクラスポリシィ管理部（１０２）がＭ０１０１を受信し、クラスポリシィリポジトリ登録処理を実行する際に、クラスポリシィの更新情報を関連するサーバ（４）へ配信する処理である。
【００９８】
クラスポリシィ管理部（１０２）では、クラスポリシィリポジトリ登録処理を実行した後に、更新クラスポリシィ情報をＭ０７０１にてクラスポリシィ更新情報配信部（１０６）へ通知する。
Ｍ０７０１を受信したクラスポリシィリポジトリ更新情報配信部（１０６）では、更新クラスポリシィ情報を関連するサーバ（４）へ配信する目的で起動中のサーバ（４）の検索を、Ｍ０７０２にてオブジェクト管理部（１０１）へ問い合わせる。
Ｍ０７０２を受信したオブジェクト管理部（１０１）では、動作中のサーバ（４）の情報をＭ０７０３にてクラスポリシィ更新情報配信部（１０６）へ返送する。
Ｍ０７０３を受信したクラスポリシィ更新情報配信部（１０６）では、取得した動作中のサーバ（４）全てに対して更新クラスポリシィ情報を通知する。
【００９９】
以降の説明では、１つのサーバ（４）に対して更新クラスポリシィ情報を通知する動作について説明する。
クラスポリシィ更新情報配信部（１０６）は、更新クラスポリシィ情報をＭ０７０４にて、メッセージ通信管理部（１０４）へ送る。
Ｍ０７０４を受信したメッセージ通信管理部は、Ｍ０７０４の情報をＭ０７０５にてサーバ（４）のサーバメッセージ通信管理部（４０５）へ送る。
Ｍ０７０５を受信したサーバメッセージ通信管理部（４０５）では、Ｍ０７０５の情報をＭ０７０６にてリクエストキュー管理部（４０２）へ送る。
Ｍ０７０５を受信したリクエストキュー管理部（４０２）では、メソッド呼び出しテーブル（４０６）を参照し、更新クラスポリシィ情報のオブジェクト種別（Ｔ０１０２）とメソッド種別（Ｔ０１０３）とパラメータ情報（Ｔ０１０４，Ｔ０１０５）とリターン情報（Ｔ０１０６）の全てが一致するテーブルが存在すれば、そのテーブルの境界蓄積数（Ｔ０３０６）を更新クラスポリシィ情報の値に更新する。
【０１００】
以上のように、クラスポリシィが更新された時に、オブジェクト指向システム内で既に実行されているサーバへ更新情報を配信することにより、常に最新のクラスポリシィに基づくメソッド起動を行うことができる。
【０１０１】
実施の形態８．
図２５は、実施の形態１のオブジェクト指向システムのサーバにリクエスト比較部（４０９）を追加した構成である。
リクエスト比較部（４０９）は、自己が起動するメソッドとメソッド情報が同じメソッドを起動する他のサーバを比較して検索し、検索したサーバへ記憶した処理結果を配信する。
図２６は、実施の形態１のリクエストキューテーブル（４０３）に対して、処理結果（Ｔ０１０８）を追加した構成である。
この実施の形態では、一例として、リクエストディスパッチ部（４０４）によって、リクエストキューテーブル（４０３）へ処理結果を記憶する場合を説明する。
【０１０２】
次に、実施の形態８の動作を説明する。
実施の形態８では、実施の形態１にて説明した処理により、サーバ（４）においてメソッド実行が行われ、この結果がＭ０３１４とＭ０３１５にてリクエストキュー管理部（４０２）に伝えられた以降に、サーバ（４）に同一リクエストを発行しているクライアント（３）と、同一のリクエストがキューイングされている他のサーバにメソッド実行結果を登録する。
このため、初めに、図２８を用いてメソッド実行を行ったサーバ（４）Ａが動作中の他のサーバを検索する処理を動作サーバ検索処理として説明する。
続いて、図２７を用いてこの中の１つのサーバ（４）Ｂへメソッド実行結果を登録する同一リクエスト比較処理の動作を説明する。
次に、サーバ（４）Ｂにおける該当リクエスト分析処理と、実際にメソッド起動処理を行う動作を説明する。
【０１０３】
図２８を用いてサーバ（４）がオブジェクト実行環境部（１）のオブジェクト管理部（１０１）に、動作中の他のサーバを検査する動作を説明する。
サーバ（４）のリクエスト比較部（４０９）では、Ｍ０９０１にてサーバメッセージ通信管理部（４０５）に対して、動作サーバ検索を依頼する。
Ｍ０９０１を受信したサーバメッセージ通信管理部（４０５）では、Ｍ０９０１の情報をＭ０９０２にてオブジェクト実行環境部（１）のメッセージ通信管理部（１０４）へ送る。
Ｍ０９０２を受信したメッセージ通信管理部（１０４）では、Ｍ０９０２の情報を、Ｍ０９０３にてオブジェクト管理部（１０１）へ送る。
Ｍ０９０３を受信したオブジェクト管理部（１０１）では、動作中のサーバ一覧情報をＭ０９０４にてメッセージ通信管理部（１０４）へ送る。
Ｍ０９０４を受信したメッセージ通信管理部は、Ｍ０９０４の情報を、Ｍ０９０５にてサーバ（４）のサーバメッセージ通信管理部（４０５）へ送る。
Ｍ０９０５を受信したサーバメッセージ通信管理部（４０５）は、Ｍ０９０５の情報を、Ｍ０９０６にてリクエスト比較部（４０９）へ送る。
【０１０４】
図２７を用いて、同一リクエスト比較処理の動作を説明する。
この処理は、実施の形態１においてメソッド実行が行われ、メソッド実行結果がＭ０４０５にてサーバ（４）Ａに通知された以降、この情報を他の動作中サーバへ送信する処理である。
サーバ（４）Ａのリクエストキュー管理部（４０２）は、Ｍ０８０１にてメソッドメソッド情報とメソッド実行結果をリクエスト比較部（４０９）へ送る。
Ｍ０８０１を受信したリクエスト比較部（４０９）では、動作サーバ検索処理を実行し、既に説明した動作により動作中の他のサーバを検索する。以降では、動作サーバ検索処理の結果から、サーバ（４）Ｂへメソッドメソッド情報とメソッド実行結果を通知する動作を説明する。
【０１０５】
サーバ（４）Ｂに対するメソッド実行結果の通知を判断したリクエスト比較部（４０９）は、Ｍ０８０１にて受信した情報を、Ｍ０８０２にてサーバメッセージ通信管理部（４０５）へ送る。
Ｍ０８０２を受信したサーバメッセージ通信管理部（４０５）は、Ｍ０８０２の情報をＭ０８０３にてサーバ（４）Ｂのサーバメッセージ通信管理部（４０５）へ送る。
Ｍ０８０３を受信したサーバメッセージ通信管理部（４０５）は、Ｍ０８０３の情報をＭ０８０４にて、リクエスト比較部（４０９）へ送る。
Ｍ０８０４を受信したリクエスト比較部（４０）は、Ｍ０８０４の情報をＭ０８０５にてリクエストキュー管理部（４０２）へ送る。
Ｍ０８０５を受信したリクエストキュー管理部（４０２）は、処理結果登録処理を実行する。
処理結果登録処理は、リクエストキューテーブル（４０３）を検索し、０８０５にて受信したメソッドメソッド情報のオブジェクト種別とメソッド種別とパラメータ情報とリターン情報のそれぞれのが、オブジェクト種別（Ｔ０１０２）とメソッド種別（Ｔ０１０３）とパラメータ情報（Ｔ０１０４，Ｔ０１０５）とリターン情報（Ｔ０１０６）が一致するテーブルがあれば、そのテーブルの処理結果（Ｔ０１０８）にメソッド実行結果を登録する。
【０１０６】
実施の形態８の該当リクエスト分析処理の動作について説明する。
リクエストキュー管理部（４０２）が実行する該当リクエスト分析処理では、初めに、リクエストキューテーブル（４０３）のテーブルの中から蓄積番号（Ｔ０１０１）が“１”のリクエストを取得し、このリクエスト情報の処理結果（Ｔ０１０８）にメソッド実行結果が登録されているかどうかを参照し、登録されている場合には「メソッド実行結果登録済み」と判断し、登録されていない場合には「メソッド実行結果登録無し」と判断する。次に、リクエストキューテーブル（４０３）の各テーブルを検索し、実施の形態１の場合と同様に、「同一リクエストによるメソッド起動」あるいは「通常のメソッド起動」を判断する。
【０１０７】
Ｍ０３１０を受信したメソッド呼び出しテーブル（４０６）では、メソッド呼び出しテーブル（４０６）とリクエストキューテーブルの比較を行い、この結果をＭ０３１１にてリクエストキュー管理部（４０２）へ送る。
以上により、該当リクエスト分析処理が終了する。この結果が「メソッド実行結果登録無し」の場合は、実施の形態１の場合と同様に処理が続けられるが、「メソッド実行結果登録済み」の場合には、オブジェクト実行方法が異なるため、以下に異なる処理を説明する。
【０１０８】
該当リクエスト分析処理により「メソッド実行結果登録済み」を判断したリクエストキュー管理部（４０２）は、次に処理されるリクエストが「メソッド実行結果登録済み」であることと、リクエストキューテーブル（４０３）の該当テーブルの処理結果（Ｔ０１０８）をメソッド実行結果としてＭ０３１２にてリクエストディスパッチ部（４０４）へ送る。
Ｍ０３１２を受信したリクエストディスパッチ部（４０４）は、次に処理すべきリクエストの結果が、メソッド実行結果であるとして、この情報を処理結果としてＭ０３１４にてリクエストディスパッチ部（４０４）へ送る。以降は、実施の形態１と同様の処理を行う。
【０１０９】
以上のように、サーバのキューに蓄積されたリクエストを監視し、同一リクエストが境界蓄積数に達した場合には、次に同一リクエストの中で最も古いリクエストに対するメソッド起動が判断されたタイミングで、該当リクエストに対応して実施されたメソッドの処理結果を他の同一リクエストを行ったクライアントへ返送するだけでなく、他のサーバの中で同一リクエストが蓄積されている場合に、そのサーバ内のリクエストスケジューリングにおいて、次に同一リクエストの中で最も古いリクエストに対するメソッド起動が判断された場合にはメソッド起動を行わずに、既に取得されているメソッド実行結果を送信することにより、異なるサーバ間で同一のメソッド起動の数を最低限に押さえることができる。
【０１１０】
実施の形態９．
上記の実施の形態では、複数処理条件として、境界蓄積数、限界時間、及び最小蓄積数を一例として説明したが、これに限られるわけではない。上記以外の所定の複数処理条件を設定して、この発明に係るメソッド起動方式を実現することは可能であることは言うまでもない。
また、上記の実施の形態では、クライアント及びサーバは、それぞれ複数あってもかまわないし、一つでもかまわない。
また、この発明に係るメソッド起動方式を、一例としてオブジェクト指向システムにおいて実現する場合を説明したが、これに限られるわけではない。オブジェクト指向システム以外のシステムであって、データを処理するメソッドを起動するシステムに適用することも可能である。
【０１１１】
【発明の効果】
以上のように、本発明に係るメソッド起動方式によれば、サーバのキューに蓄積された各リクエストがクラスポリシィにて規定した数に達した場合には、次に同一リクエストの中で最も古いリクエストに対するメソッド起動による処理結果を同一リクエストを行った全てのクライアント間で共有することが可能であるため、アプリケーションソフトウェアとは独立に規定するクラスポリシィに基づいて、アプリケーションソフトウェアの自由度を妨げること無く、計算機資源の有効的な利用によるリアルタイムなメソッド起動を実現できるという効果がある。
【０１１２】
以上のように、本発明によれば、同一リクエストがクラスポリシィにて規定された時間以上にキューイングされ実行待ちの状態にある場合には、次に同一リクエストの中で最も古いリクエストに対するメソッド起動が判断された時に、該当リクエストに対応して実施されたメソッドの処理結果を他の同一リクエストを行ったクライアント間で共有することが可能であるため、クライアントからのリクエストの予測できないキューイング時間に対してクラスポリシィに基づいて制約を加えることができるという効果がある。
【０１１３】
以上のように、本発明によれば、クラス毎にメソッド起動のリアルタイム性を規定するクラスポリシィを実際にオブジェクト指向システム内で実行されているクライアントからサーバに対するリクエスト状況から動的に計算することが可能であるため、常に最新の状況を反映したクラスポリシィに基いてメソッド起動を行えるという効果がある。
【０１１４】
以上のように、本発明によれば、同一オブジェクトの同一メソッドに対するリクエストがクラスポリシィにて規定する数に達した場合は、次に同一リクエストの中で最も古いリクエストに対するメソッド起動が実行されるタイミングで、最新のリクエストのパラメータ情報とリターン情報からのメソッド計算を実行し、その結果をクライアント間で共有することが可能であるため、クライアントはリクエスト送信のタイミングに関係なく、常に最新メソッド処理結果を取得できるという効果がある。
【０１１５】
以上のように、本発明によれば、同一リクエストの数がクラスポリシィにて規定する数に達した場合は、この登録の後の最初のリクエストスケジューリングのタイミングでキューイングされている時間的な順番に関係なく、優先してメソッド起動を実行する事が可能なため、リクエストを発行した時間だけでなく同一の要求が集中する状況に応じてメソッド起動の優先処理を行えるという効果がある。
【０１１６】
以上のように、本発明によれば、キューイングされた同一リクエストの数がクラスポリシィの規定数に達した段階でメソッド起動を行うことが可能であるため、メソッド起動の実行回数を最低限に押さえたリクエストスケジューリングが行えるという効果がある。
【０１１７】
以上のように、本発明によれば、クラスポリシィの更新情報を、オブジェクト指向システム内で既に実行されているサーバへ配信することが可能であるため、常に最新のクラスポリシィを反映したメソッド起動を行えるという効果がある。
【０１１８】
以上のように、本発明によれば、同一リクエストによるメソッド起動の制限を複数のサーバ間で共有することが可能であるため、クラスポリシィに基づくメソッド起動を複数のサーバに適用することが可能であるため、分散オブジェクト指向システム全体でメソッド起動を最低限に押さえた計算機資源の有功利用によるリアルタイムなメソッド起動方式を行えるという効果がある。
【図面の簡単な説明】
【図１】 実施の形態１におけるこの発明に係るメソッド起動方式を実施するオブジェクト指向システム構成の一例を示す図である。
【図２】 実施の形態１におけるリクエストキューテーブル構成図である。
【図３】 実施の形態１におけるクラスポリシィリポジトリ構成図である。
【図４】 実施の形態１におけるメソッド呼び出しテーブル構成図である。
【図５】 実施の形態１におけるクラスポリシィ登録処理フロー図である。
【図６】 実施の形態１におけるリクエストカウンタ登録処理フロー図である。
【図７】 実施の形態１における通常のメソッド起動処理フロー図である。
【図８】 実施の形態１における通常のメソッド起動処理フロー図である。
【図９】 実施の形態１における同一リクエストによるメソッド起動処理フロー図である。
【図１０】 実施の形態１における同一リクエストによるメソッド起動処理フロー図である。
【図１１】 実施の形態１における該当リクエスト分析処理である。
【図１２】 実施の形態２におけるこの発明に係るメソッド起動方式を実施するオブジェクト指向システム構成の一例を示す図である。
【図１３】 実施の形態２におけるリクエストキューテーブル構成図である。
【図１４】 実施の形態２におけるクラスポリシィリポジトリ構成図である。
【図１５】 実施の形態２におけるメソッド呼び出し限界時間テーブル構成図である。
【図１６】 実施の形態３におけるこの発明に係るメソッド起動方式を実施するオブジェクト指向システム構成の一例を示す図である。
【図１７】 実施の形態３におけるクラスポリシィ統計処理フロー図である。
【図１８】 実施の形態４におけるこの発明に係るメソッド起動方式を実施するオブジェクト指向システム構成の一例を示す図である。
【図１９】 実施の形態４におけるメソッド呼び出し集計テーブル構成の一例を示す図である。
【図２０】 実施の形態５における該当リクエスト分析処理フロー図である。
【図２１】 実施の形態６におけるクラスポリシィリポジトリ構成の一例を示す図である。
【図２２】 実施の形態６におけるメソッド呼び出しテーブル構成図である。
【図２３】 実施の形態７におけるこの発明に係るメソッド起動方式を実施するオブジェクト指向システム構成の一例を示す図である。
【図２４】 実施の形態７におけるクラスポリシィリポジトリ更新情報配信処理フロー図である。
【図２５】 実施の形態８におけるこの発明に係るメソッド起動方式を実施するオブジェクト指向システム構成の一例を示す図である。
【図２６】 実施の形態８におけるリクエストキューテーブル構成の一例を示す図である。
【図２７】 実施の形態８における同一リクエスト比較処理フローである。
【図２８】 実施の形態８における同一サーバ検索処理フロー図である。
【図２９】 従来例のシステム構成図である。
【図３０】 従来例のメッセージシステムを示す図である。
【図３１】 従来例のデータ構造を示す図である。
【符号の説明】
１ オブジェクト実行環境部、２ クラスポリシィ入力インタフェース、３ クライアント、４ サーバ、１０１ オブジェクト管理部、１０２ クラスポリシィ管理部、１０３ クラスポリシィリポジトリ、１０４ メッセージ通信管理部、１０５ クラスポリシィ統計処理部、１０６ クラスポリシィ更新情報配信部、３０１ クライアントロジック部、３０２ クライアントメッセージ通信管理部、４０１ サーバロジック部、４０２ リクエストキュー管理部、４０３ リクエストキューテーブル、４０４ リクエストディスパッチ部、４０５ サーバメッセージ通信管理部、４０６ メソッド呼び出しテーブル、４０７ メソッド呼び出し限界時間テーブル、４０８ メソッド呼び出し集計テーブル、４０９リクエスト比較部、４０１１ メソッド、４０１２ オブジェクト部、Ｔ０１０１ 蓄積番号、Ｔ０１０２ オブジェクト種別、Ｔ０１０３ メソッド種別、Ｔ０１０４ パラメータ１情報、Ｔ０１０５ パラメータ２情報、Ｔ０１０６ リターン情報、Ｔ０１０７ 登録時間、Ｔ０１０８ 処理結果、Ｔ０２０１ クラス種別、Ｔ０２０２ メソッド種別、Ｔ０２０３ パラメータ１情報、Ｔ０２０４ パラメータ２情報、Ｔ０２０５ リターン情報、Ｔ０２０６ 境界蓄積数、Ｔ０２０７ 限界時間、Ｔ０２０８ 最小蓄積数、Ｔ０３０１ オブジェクト種別、Ｔ０３０２ メソッド種別、Ｔ０３０３ パラメータ１情報、Ｔ０３０４パラメータ２情報、Ｔ０３０５ リターン情報、Ｔ０３０６ 境界蓄積数、Ｔ０３０７ 蓄積数、Ｔ０３０８ 最小蓄積数、Ｔ０４０１ クラス種別、Ｔ０４０２ メソッド種別、Ｔ０４０３ 限界時間、Ｔ０５０１ クラス種別、Ｔ０５０２ メソッド種別、Ｔ０５０３ 蓄積数、Ｍ０１０１〜Ｍ０１０２，Ｍ０２０１〜Ｍ０２０６，Ｍ０３０１〜Ｍ０３２３，Ｍ０４０２〜Ｍ０４１４，Ｍ０５０１〜Ｍ０５０３，Ｍ０６０１〜Ｍ０６０２，Ｍ０７０１〜Ｍ０７０６，Ｍ０８０１〜Ｍ０８０５，Ｍ０９０１〜Ｍ０９０６ メッセージ、３００１ コンピュータプログラム、３００２ コンピュータプラットフォーム、３００３ アプリケーションプログラム、３００４ オブジェクト指向プログラミング、３００５ データベース管理装置、３００６ オペレーティングシステム、３００７ マイクロ命令コード、３００８ 入出力インタフェース、３００９ ＲＡＭ、３０１０ ＣＰＵ、３０１１ 入出力インタフェース、３０１２ 接続ケーブル、３０１３ 端末装置、３０１４ 接続ケーブル、３０１６ ユーザ、３０１７ 接続ケーブル、３０１８ データ記憶装置、３０１９ 外部データベース、３０２０接続ケーブル、３０２１ プリンタ、３１２１ メソッドＡ、３１２２ メソッドＢ、３１２３ オブジェクト管理表、３１２４ データフレーム、３１２５ロード済みクラス表、３１２６ 信号線、３１２７ 信号線、３１２８ 信号線、３１２９ 信号線、３１３０ メッセンジャ、３１０１ オブジェクト識別構成、３１０２ オブジェクト識別欄、３１０３ アクセスアドレス、３１０４形式、３１０５ クラス識別子、３１０６ インスタンス識別子、３１０７ オブジェクト管理表（ＯＭＴ）、３１０８ オブジェクト識別欄、３１０９ インスタンスデータフレームアドレス。[0001]
BACKGROUND OF THE INVENTION
In the present invention, the object execution environment section transmits the application interface call information made by the client to the server by the message communication to the server having the object which is a unit encapsulating data and the method, and receives this information. The server once accumulates the requests in the queue, and then analyzes the queued requests, for example, in order from the one with the oldest registration time, and starts the method of the corresponding object from this result, and the processing result of this method Relates to a method invocation method of a distributed object-oriented system that realizes a client / server type application that returns a client as a result of a programming call of a client.
[0002]
[Prior art]
The configuration of the conventional example will be described.
FIG. 29 is a diagram showing an example of a general object-oriented system configuration disclosed in Japanese Patent Laid-Open No. 4-230543 “Data Structure Used in Object-Oriented System”.
The system shown as an example in FIG. 29 includes a RAM (3009), a CPU (3010), and an input / output interface (3011), and external devices such as a terminal device (3013), a data storage device (3018), and a printer (3021). Is a computer system that houses In this computer system, an object-oriented programming system is used to conceal the platform (3002) of the microinstruction code (3007), the operating system (3006), and the data management device (3005) for controlling these hardware in a programmable manner. (3004). As a result, a distributed object-oriented system in which the application program (3003) can be constructed based on the object-oriented concept is realized.
[0003]
Further, in order to construct an application based on the object-oriented concept, the object system is classified into one or more by class according to the configuration of the messenger system shown in FIG. 30 as an example, and the messenger ( 3130) sends a message.
[0004]
As shown in FIG. 31 as an example, the data structure for identifying an object includes an object identification field (3012) as a fixed part having a unique object identifier, and access in a data frame in the data storage device (3018). This is composed of a non-fixed part composed of the instance data frame address (3109) which is the address (3103). In this conventional example, the message transmission destination can be set so as to be optimally determined according to the situation. it can.
[0005]
In this conventional example, as shown in FIG. 29, the computer program (3001) has a configuration in which an application program and an object-oriented programming system are integrated. Consider a case in which method activation is requested between a plurality of application programs (3003) using the messenger (3130) shown as an example in FIG. 30 and the object management table shown as an example in FIG. When one application program (requesting side) (3003) requests processing by message communication to the other application program (3003), the requesting side application program (3003) has the object-oriented programming system (3004) of the system. ) To send a message. The message at this time is sent by the messenger (3130) shown in FIG. Here, the messenger (3130) refers to the object management table (3123) shown in FIG. 31 to identify the requested application program (3001) from the corresponding class identifier (3105), instance identifier (3106), etc. Send a message to the program (3001).
In such a configuration, method activation performed between the application programs (3003) is centrally managed by the object-oriented programming system (3004), and as a result, the object management table (3123) requested by the message is stored. Since it is configured to uniquely identify an object as a method from information, it is not possible to realize processing that takes into account information such as the number of accumulated messages from a client and registration time.
[0006]
[Problems to be solved by the invention]
The method activation method of the conventional object-oriented system is configured as described above. For this reason, requests are stored individually. Therefore, if the method activation is executed independently without comparing the contents of each request, there are the following problems. For example, when there are a plurality of identical requests, the same method activation is executed for the number of the existing requests. For this reason, computer resources such as time, memory, and CPU are wasted, and a method activation wait state due to another request occurs. There was a problem that the client could not obtain the processing result requested to the server in real time.
[0007]
Also, in request scheduling, processing for a request issued by a client is blocked during the unpredictable method operation time due to the request accumulated in the request queue that accumulates the request before that. The problem is that the client cannot obtain the method processing result at an appropriate timing because the time from when the request is accumulated in the request queue until it is executed cannot be restricted. was there.
[0008]
The class policy that defines the real-time performance of request scheduling for each class must be defined by comparing each class, and an appropriate value corresponding to the trend of the requests actually executed on the server must be defined. There was a problem that it was difficult.
[0009]
For requests that request calculation for the same method of the same class, reissue a request to request calculation with different parameters due to a change in the situation that occurs within the time that this request is accumulated in the queue In this case, there is a problem in that processing of a request for invoking a method by a parameter corresponding to a new situation is blocked in addition to wastefully executing a method invocation by a request by a previously issued parameter.
[0010]
When calculation requests for methods of a certain class are concentrated, request scheduling is performed according to the time when requests are accumulated in the queue without considering the importance of method activation due to this concentration, so many clients request it. There is a problem that the calculation cannot be processed quickly, and resources are wasted by executing the same calculation for the number of requests.
[0011]
There has been a problem that computer resources are wasted by executing a calculation for a method of a certain class for the number of times accumulated in the request in the queue.
[0012]
When the class policy is updated, the information is not reflected in the request scheduling of the already operating server.
[0013]
When the same request is issued to multiple servers, the same method processing result cannot be shared among these servers, and there is a problem that computer resources are wasted in each server. It was.
[0014]
In order to solve the above problems, the present invention processes a plurality of requests by returning a processing result acquired to a plurality of the same requests when processing a request and acquiring a processing result. The purpose is to realize the method invocation method.
[0015]
[Means for Solving the Problems]
The method invocation method according to the present invention is a method invocation method for receiving a request for initiating a method for processing data transmitted from a client.
A server that invokes the method;
An object execution environment unit that receives a request from the client and transmits the received request to a server;
The object execution environment unit further includes a class policy repository for storing a plurality of class policies, using method information for specifying a method and a plurality of processing conditions for specifying a condition for processing a plurality of requests collectively as a class policy. ,
The server further searches the class policy repository, identifies the class policy to which the received request belongs based on the method information, the multiple processing conditions of the identified class policy, and the request as the status of receiving the request A request queue management unit for managing the accumulation status;
A method call table for storing multiple processing conditions and request accumulation status managed by the request queue management unit;
Invoke the method to obtain the processing result, refer to the method call table above, and if the request accumulation status of the class policy to which the request belongs satisfies multiple processing conditions, send the request to the processing result And a request dispatch unit that replies to each of a plurality of clients and processes a plurality of requests collectively.
[0016]
The method invocation method further includes a class policy input interface for inputting the class policy.
The object execution environment unit includes a class policy management unit that receives an input class policy and writes the received class policy to the class policy repository.
[0017]
The above request accumulation status is the accumulated number of received requests.
The multiple processing condition includes a boundary accumulation number that defines a boundary value of the request accumulation number when the request dispatch unit processes a plurality of requests collectively,
The request dispatch unit processes a plurality of requests when the request accumulation number is equal to or greater than the boundary accumulation number.
[0018]
The multiple processing conditions include a limit time indicating a limit time from when the request is received by the request queue management unit until the request is processed,
The server further includes a request queue table for registering requests in the order in which the requests are received,
The request queue management unit registers the received request in the request queue table, registers the time when the request is received as the registration time,
The method call table stores the time limit as a multiple processing condition,
The request dispatch unit obtains the time limit of the class policy to which the request belongs from the method call table, and detects a request for starting a method having the same method information as the method information of the method to be started from the request queue table. A request that exceeds the limit time from the request registration time is extracted, and the processing result is returned to the client that has transmitted the extracted request.
[0019]
The object execution environment unit includes a class policy statistical processing unit that reads the request accumulation status for each class policy from the method call table, and analyzes the read request accumulation status to change the multiple processing conditions. It is characterized by.
[0020]
The method information includes a method type for specifying a processing content of the method and a parameter passed from the client to the method.
[0021]
The above method information includes a method type that identifies the processing content of the method,
The request dispatch unit is characterized in that, among the requests having the same method information, the method is started using a parameter passed to the method specified by the request last received by the message management unit.
[0022]
The request dispatch unit processes requests in the order in which the request queue management unit receives the requests, and processes a plurality of requests when the accumulated number of requests to be processed reaches the boundary accumulated number. And
[0023]
The request dispatch unit searches the accumulated number of requests for each class policy, detects a class policy in which the accumulated number of requests is greater than or equal to the boundary accumulated number, and selects requests belonging to the detected class policy. It is characterized by processing.
[0024]
The object execution environment unit further receives the class policy input from the class policy input interface from the class policy management unit, and distributes the received multiple processing conditions of the class policy as update information to the request queue management unit of the server. It has a class policy update information distribution unit,
The request queue management unit writes the received multiple processing conditions in a method call table.
[0025]
The above request accumulation status is the accumulated number of received requests.
The multiple processing condition includes a minimum accumulation number that defines a lower limit value of the request accumulation number when the request dispatch unit processes a plurality of requests collectively.
The request queue management unit searches the method call table to detect a request in which the accumulated number of requests exceeds the minimum accumulated number, and notifies the detected request to the request dispatch unit.
The request dispatch unit processes a plurality of requests for the request received from the request queue management unit.
[0026]
The method activation method includes a plurality of servers,
The request dispatch unit stores the processing result of starting the method,
The server further includes a request comparison unit that compares and searches other servers that start the method that has the same method information as the method that the server starts and distributes the processing result stored to the searched server. To do.
[0027]
A recording medium according to the present invention is a computer-readable recording medium recorded with a program for causing a computer to operate as a method activation method for receiving a request to activate a method for processing data, transmitted from a client.
A server that invokes the method;
An object execution environment unit that receives a request from the client and transmits the received request to a server;
The object execution environment unit further includes a class policy repository for storing a plurality of class policies, using method information for specifying a method and a plurality of processing conditions for specifying a condition for processing a plurality of requests collectively as a class policy. ,
The server further searches the class policy repository, identifies the class policy to which the received request belongs based on the method information, the multiple processing conditions of the identified class policy, and the request as the status of receiving the request A request queue management unit for managing the accumulation status;
A method call table for storing multiple processing conditions and request accumulation status managed by the request queue management unit;
Invoke the method to obtain the processing result, refer to the method call table above, and if the request accumulation status of the class policy to which the request belongs satisfies multiple processing conditions, send the request to the processing result A computer-readable recording medium recording a program for causing a computer to operate as a method activation method including a request dispatch unit that replies to each of a plurality of clients and processes a plurality of requests collectively To do.
[0028]
DETAILED DESCRIPTION OF THE INVENTION
Embodiment 1 FIG.
This embodiment is characterized in that the maximum number of requests that request the same method activation for each class in advance is queued at the same time as the class policy, and the method activation is performed using the defined class policy. And In the following embodiments, an example realized by an object-oriented system will be described as an example.
[0029]
FIG. 1 shows an object-oriented system that implements the method invocation method of the present invention described as an example in this embodiment.
This object-oriented system includes an object execution environment unit (1) that realizes a distributed object-oriented application configuration based on a client / server model, a class policy input interface (2) having an interface function for inputting a class policy, and a client And a client (3) that transmits a request for invoking a method, and a server (4) that operates as a server.
[0030]
The object execution environment unit (1) includes the following components.
The object management unit (101) manages the state of the server and the existing position.
The class policy management unit (102) manages class policies.
The class policy repository (103) stores a plurality of class policies by using, as a class policy, method information for specifying a method and a plurality of processing conditions for defining a condition for processing a plurality of requests collectively.
Therefore, the class policy predetermines a method activation method by request scheduling that the client expects for each class.
The message communication management unit (104) manages message communication between the client and the server.
A request is a method activation request, and request information is information that identifies a method that requests activation by a request and identifies an activation condition. Therefore, request information is specified for each request. In this specification, the request includes request information.
[0031]
The client (3) includes the following components.
The client logic unit (301) is an application that operates as a client.
The client message communication management unit (302) transmits the programming interface information called by the client logic unit (301) to the object execution management unit (1) by message communication.
[0032]
The server (4) includes the following components.
The server logic unit (401) is an application that operates as a server.
The request queue management unit (402) searches the class policy repository (103), identifies the class policy to which the received request belongs based on the method information, and specifies the multiple processing conditions of the identified class policy and the request. The request accumulation status as the received status is managed, and the request accumulation status as the received status is registered in the method call table described later. Further, the received request is registered in a request queue table (403) described later. In this embodiment, a boundary value of the number of accumulated requests for each class policy is set as the boundary accumulation number as a plurality of processing conditions.
The request queue table (403) is a database that actually stores requests.
The request dispatch unit (404) activates the method to acquire the processing result, and refers to the method call table (406). When the request accumulation status of the class policy to which the request belongs satisfies a plurality of processing conditions, The above processing result is returned to each of the plurality of clients that sent the requests, and the plurality of requests are processed together.
In the following description, a result obtained by starting a method may be referred to as “processing result” or “execution result”, but they are used in the same meaning.
The method call table (406) stores a plurality of processing conditions and request accumulation status managed by the request queue management unit (402). Class policies are associated with method types.
[0033]
Further, the method activation method according to the present invention described below is realized by a program for causing a computer to operate. Therefore, the program for realizing this method activation method can be recorded on a computer-readable recording medium.
The server logic unit (401) of the server (4) includes an object unit (4012) that is an instance generated from the class. Furthermore, the object part (4012) includes a method (4011) defined by the class.
[0034]
FIG. 2 shows an example of the request queue table (403).
The request queue table (403) is a database for registering requests accumulated in one server (4). Further, an accumulation number (T0101) is assigned in order from the request with the oldest registered time, and method identification information necessary for identifying a method to be activated as each request information and activation information necessary for method activation are stored. As the method specifying information, the object type (T0102) and the method type (T0103) are included, and the method activated by the request is specified. Further, the method information for each method includes parameter 1 information (T0104), parameter 2 information (T1015), and return information (T0106). In the following, parameter 1 information (T0104) and parameter 2 information (T1015) may be expressed as parameter information (T0104, T0105).
[0035]
FIG. 3 is a diagram showing an example of the class policy repository (103).
The class policy repository (103) stores method information for specifying a method and a plurality of processing conditions for defining a condition for processing a plurality of requests collectively as a class policy.
In this embodiment, the method information includes method specifying information and method activation information. The method identification information includes a class type (T0201) and a method type (T0202) defined for each class. Further, the method activation information for each method includes parameter 1 information (T0203), parameter 2 information (T0204), and return information (T0205). Hereinafter, the parameter 1 information (T0203) and the parameter 2 information (T0204) may be expressed as parameter information (T0203, T0204).
A class type is a template that defines methods and variables for determining the type of an object.
The method type specifies the type of method.
A case will be described in which the multiple processing condition is the boundary accumulation number (T0206), which is the maximum number of requests allowed to be registered simultaneously in the message queue table (401) of one server (4).
[0036]
FIG. 4 shows an example of the method call table (406).
This is a database that manages the relationship between the request type stored in one server (4) and the simultaneous storage allowed for the method activated by this request specified by the class policy.
In this embodiment, as the object type (T0301), method information (T0302 to T0305), and a plurality of processing conditions, a boundary accumulation number (which is a boundary number for determining whether to process a plurality of requests collectively) T0306) and the number of requests accumulated (T0306) received by the request queue manager as the request accumulation status as the status of receiving a request.
The object type is specified in the server from the class type and the method type.
The method call table (406) stores requests classified by the class policy repository (103) on the basis of T0302 to T0305, and in the server logic unit (401) of the server (4), Are stored in association with the object type (T0301), which is a unit for managing the above, and the class policy.
The information described above is registered by the request queue management unit (402).
As described above, the method call table of this embodiment is also called a method call count table by counting requests and storing the accumulated number as the request accumulation status.
[0037]
Next, the operation of the object-oriented system in this embodiment will be described. First, in order to operate this object-oriented system, it is premised that a “class policy registration process” for registering a class policy in the class policy repository (103) is executed.
First, the operation of the “class policy registration process” will be described. Next, “request counter registration processing” and “method call counter processing”, which are features of the present invention, will be described.
The “request counter registration process” means that the server (4) acquires the class policy registered in the class policy repository (103) of the object execution environment unit (1) and registers it in the internal method call table (406). Refers to processing.
The “method call counter process” refers to a process for generating the method call table (406) from the class policy repository (103). This is implemented by the request queue management unit (402).
Next, the processes from when the client (3) sends a request for starting a method to when the server (4) starts the method are referred to as “normal method start processing” and “method start processing by the same request”. Separately described.
In the following description of FIGS. 5 to 10, a case where a message is used for transmission of information between each component will be described. The message is represented by Mxxxx (xxxx is a number).
[0038]
First, the operation of the “class policy registration process” will be described with reference to FIG.
The class policy is specified by the system administrator. The system administrator inputs the class policy from the class policy input interface (2). The input class policy is transmitted to the class policy management unit (102) of the object execution environment unit (1) by a message M0101 (hereinafter, “message” is omitted). The class policy management unit (102) that has received M0101 ends the operation by storing the class policy requested to be registered received by M0101 in the class policy repository (103) as the class policy registration process.
[0039]
Next, the operation of the “request counter registration process” will be described with reference to FIG.
The “request counter registration process” includes a “request counter analysis process”, a “class policy search process”, and a “method call table generation process” described below. This "request counter registration process" is a process of registering a request transmitted from the client (3) to the server (4) via the object execution environment unit (1) based on the class policy which is a feature of the present invention. is there.
The server message communication manager (104) of the server (4) passes the received request to the request queue manager (402). The request queue management unit (402) analyzes the request and performs a request counter registration process.
Upon receiving the request, the server (4) first performs “request counter analysis processing”. The “request counter analysis process” analyzes whether the same request as the received request exists based on the method call table (406). The same request in this embodiment refers to a request in which the request is the same object type and the same method type, and the method is requested to start the method with the same parameter information and the same return information.
As a result of this analysis, if the same request already exists in the method call table (406), the accumulation number (T0307) (FIG. 4) of the corresponding table in the method call table (406) is incremented. When the same request does not exist, “class policy search processing” and “method call table generation processing” described below are executed.
[0040]
Next, an operation when the same request does not exist as a result of the “request counter analysis process” will be described with reference to FIG.
The request counter table (406) is information for identifying the class policy to the server message communication management unit (405) in order to obtain the class policy corresponding to the object mounted in the server from the object execution environment unit (1). Is sent by M0201. In this embodiment, the information specifying the class policy corresponds to method information and a plurality of processing conditions, but is not limited thereto.
Upon receiving M0201, the server message communication management unit (405) sends the information specifying the class policy received by M0201 to the message communication management unit (104) of the object execution environment unit (1) by M0202.
The message communication management unit (104) that has received M0202 transmits the information of M0202 to the class policy management unit (102) through M0203.
Upon receiving M0203, the class policy management unit (102) executes “class policy search processing” in order to acquire the class policy from the information specifying the class policy transmitted by M0203.
The “class policy search process” searches the class policy repository (103) for a class policy corresponding to the class requested by the information specifying the class policy.
The retrieved class policy is sent from the class policy management unit (102) to the message communication management unit (104) by M0204.
The message communication management unit (104) that has received M0204 sends the information of M0204 to the server message communication management unit (405) of the server (4) by M0205.
Upon receiving M0205, the server message communication management unit (405) sends M0205 information to the method call table (406) by M0206.
As a result, the method call table (406) acquires the corresponding class policy by M0206, and then executes “method call counter generation processing”.
[0041]
Next, the operation of “method call counter generation processing” will be described with reference to FIGS. 3 and 4.
As shown in FIG. 3, the acquired class policy structure includes, for each class type (T0201), one or more method method information (T0202) defined by the class, and parameter information (T0203). , T0204), return information (T0205), and the boundary accumulation number that serves as a boundary for judging that a plurality of requests accumulated in the request queue table (403) of one server (4) are processed together for each method. (T0206). The method method information requested by the received request is specified in this information, and is expanded into one table of the method call table configuration shown in FIG. For example, the parameters “in int 1000”, “in int 10”,... For the method “method_1” of the object “Object_1” whose class type is generated from the class_1 by the request. . . , And the return information is returned as “int”, the table with the class type (T0201) shown in FIG. 3 of class_1 is acquired as the class policy, and the first table shown in FIG. Created.
If the boundary accumulation number (T0306) of the method call table (406) is blank (the boundary accumulation number (T0206) of the acquired class policy is blank), it means that the boundary accumulation number is infinite. ing.
[0042]
Next, the operation of “normal method activation processing” will be described with reference to FIGS.
The operation of the normal method activation process is the most basic operation, and is an operation from when a client issues a request to obtaining a processing result of a corresponding server method.
Also, in the operation of the method activation process by the same request described later, a case where a plurality of requests are processed together will be described.
[0043]
The client logic unit (301) of the client (3) calls an application interface prepared in advance and issues a request using this application interface. At this time, request information related to the request is also generated. This request is sent to the client message communication management unit (302) by M0301 together with the request information.
Upon receiving M0301, the client message communication management unit (302) converts this information into a format that can be transmitted by a message, and sends the information to the message communication management unit (104) of the object execution environment unit (1) in M0302.
The message communication management unit that has received M0302 sends the information of M0302 to the object management unit (101) in M0303.
[0044]
The object management unit (101) that has received M0303 analyzes the location and operation state of the server (4) as “server analysis processing” from the request information received in M0303, and the corresponding server (4) issues a request. After confirming that it can be received, in order to transmit the request information to the corresponding server (4), the information is sent to the message communication management unit (104) in M0304.
The message communication management unit (104) that has received M0304 sends the information of M0304 to the server message communication management unit (405) of the corresponding server (4) in M0305.
[0045]
Receiving M0305, the server message communication manager (405) sends the information of M0305 to the request queue manager (402) in M0306.
The request queue management unit (402) that has received M0306 sends the information of M0306 to the method call table (406) in M0307.
In the method call table (406) that has received M 0307, “request counter registration processing” is executed according to an instruction from the request queue management unit (402). Since the details of the “request counter registration process” have been described above, the description thereof is omitted here.
The method call table (406) sends the completion of the process to the request queue management unit (402) in M0308 after the request counter registration process is performed.
[0046]
Upon receiving M0308, the request queue management unit (402) instructs the method call table (406) to execute “request registration processing”.
The “request registration process” registers the request information transmitted in M0306 in the request queue table.
[0047]
The operation of “request registration process” will be described with reference to FIG.
FIG. 2 shows the structure of the request queue table (403). Request information to be newly registered is assigned a continuous value from the number already registered as the accumulation number (T0101). Registration is completed by expanding the request information into the object type (T0102), method type (T0103), parameter information (T0104, T0105, etc.), and return information (T0106).
Upon completion of the above request registration process, registration of the request to the server (4) is completed, and the client (3) enters a request response waiting state (FIG. 7).
[0048]
In the request response waiting state, the request dispatch unit (404) of the server (4) performs "request dispatch processing" (FIG. 7).
In the “request dispatch process”, the request dispatch unit (404) sends M0309 to the request queue management unit (402) to acquire the next request to be processed.
The request queue management unit (402) that has received M0309 searches for a request to be processed next by “corresponding request analysis processing”.
The “corresponding request analysis process” extracts a request whose accumulation number (T0101) is 1 from the request queue table (403), and analyzes whether the same request exists in the method call table. Specifically, the “corresponding request analysis process” obtains a request whose accumulation number (T0101) is “1” from the table of the request queue table (403), and obtains the object type (T0102) and method of this request information. The type (T0103), parameter information (T0104, T0105), and return information (T0106) are the object type (T0301), method type (T0302), parameter information (T0304, T0305), and return information (T0306) of the method call table (406). When all of T0306) match, it is determined whether the accumulated number (T0307) has reached the boundary accumulated number (T0306). If the boundary accumulated number (T0306) has not been reached, “normal method activation” is determined. The boundary accumulation number (T030 If it is judged to) it is determined that the "method starting with the same request."
[0049]
The method call table (406) that received M0310 compares the method call table (406) with the request queue table, and sends the result to the request queue management unit (402) in M0311.
Thus, the “request analysis process” is completed. The case where the result of the “request analysis process” is “normal method invocation” will be explained below, and the operation in the case of “method invocation by the same request” will be explained in “method invocation of method by the same request” .
[0050]
The request queue management unit (402) that has determined “normal method activation” by “corresponding request analysis processing” indicates that the next request to be processed is “normal method activation” and the request to be processed next. Information is sent to the request dispatch unit (404) in M0312.
Upon receiving M0312, the request dispatch unit (404) identifies the method to be activated from the information of the next request to be processed, and instructs the server logic unit (401) to activate the method at M0313.
The server logic unit (401) instructed to start the method in M0313 instructs the method dispatch of the method (4011) of the designated object (4012), and the processing result is sent to the request dispatch unit (404) in M0314. send.
Upon receiving M0314, the request dispatch unit (404) sends the information of M0314 to the request queue management unit (402) in M0315.
Upon receiving M0315, the request queue management unit (402) instructs “request counter deletion processing” to decrement the number of accumulated method call counters (T0307) for the method call table (406) by M0316. To do.
In the method call table (406) that has received M0316, a request counter deletion process is executed. If the accumulated number decremented here (T0307) is “0”, the data of the class policy is deleted.
The request queue management unit (402) that has transmitted M0316 deletes the request whose accumulation number (T1010) is “1” in the request queue table (403) that has been processed, and the accumulation number ( Decrement all T0101).
Subsequently, the request queue management unit (402) sends the information of M0315 to the server message communication management unit (405) in M0317.
The server message communication management unit (405) that has received M0317 sends the information of M0317 to the message communication management unit (104) of the object execution management unit (1) in M0318.
The message communication management unit that has received M0318 sends the information of M0318 to the object management unit (101) in M0319.
The object management unit that has received M0319 sends the information of M0319 to the message communication management unit (104) in M0320.
[0051]
The message communication management unit (104) that has received M0320 sends the message M0320 to the client message communication management unit (302) of the client (3) using the information M0321 of M0320.
Upon receiving M0321, the client message communication management unit (302) converts the method processing result received in M0321 from a message to a programming interface, and sends it to the client logic unit in M0322.
As a result of the above process, the client logic unit completes the process of acquiring the result of the request requested by the programming interface.
[0052]
The operation of “method activation by the same request” will be described using FIG. 9, FIG. 10, and FIG.
This operation is the same as “normal method activation”, when “corresponding request analysis processing” is executed, and this result is “method activation by the same request”. This is the same as the operation of “normal method invocation” described above. Therefore, FIG. 9 omits the operations until the “request response waiting state” shown in FIG. 7 is reached.
[0053]
The request queue management unit (402) that has determined that the result of the corresponding request analysis process is “method activation by the same request” indicates that it is “method activation by the same request” and information of the next request to be processed. To the request dispatch unit (404) (FIG. 9).
Upon receiving M0402, the request dispatch unit (404) specifies a method to be activated from the information of the next request to be processed, and instructs the server logic unit (401) to activate the method at M0403.
The server logic unit (401) instructed to start the method in M0403 instructs to start the method of the method (4011) of the designated object (4012), and the processing result is sent to the request dispatching unit (404) in M0404. send.
The request dispatch unit (404) that has acquired the method processing result by M0404 determines whether to return this result to all clients (3) that issued the same request.
[0054]
The operation of returning the method processing result thereafter will be described as an example in which a response is returned to the client A and the client B shown in FIG.
In the example of FIG. 10, it is assumed that the client A (3) has issued a request earlier than the client B (3).
Upon receiving M0404, the request dispatch unit (404) sends the information of M0404 to the request queue management unit (402) at M0405 and M0410 to client A (3) and client B (3) that issued the same request.
[0055]
Below, the detail of operation | movement when transmitting a calculation result is demonstrated.
First, the operation when the method processing result is transmitted to the client A (3) will be described.
The request queue management unit (402) stores the request in the class policy method call table (406) to which the request corresponding to the accumulation number (T0101) of the request queue table (403) corresponding to “1” is registered as the request registered at the oldest time. Request counter deletion processing for decrementing the accumulated number (T0307) is instructed to the method call table (406) in M0406.
In the method call table (406) that has received M0406, a request counter deletion process is executed.
In the request counter deletion process, the accumulated number (T0307) of the corresponding table in the method call table (406) is decremented. In the example of this explanation, the decrement result is “1”.
[0056]
After transmitting M0406, the request queue management unit (402) sends the received M0405 information to the server message communication management unit (405) in M0407 in order to transmit it to the client A.
The server message communication management unit (405) that has received M0407 sends the message to the client message communication management unit (302) of client A (3) at M0408 via the information object execution environment unit (1) of M0407.
Since the operation of the object execution environment unit (1) during this period is exactly the same as in the case of “normal method activation”, the description thereof is omitted.
[0057]
Upon receiving M0408, the client message communication management unit (302) converts the method processing result received in M0408 from a message to a programming interface, and sends it to the client logic unit in M0409.
As a result of the above processing, the client logic unit of the client A (3) completes the method execution result acquisition for acquiring the request result requested by the programming interface.
[0058]
Next, an operation in which the client B (3) that has issued the same request acquires the method processing result will be described.
The request queue management unit (402) that has acquired the method processing result by M0410 stores the number (T0307) of the method call table (406) of the class policy to which the request with the oldest storage number (T0101) of the request queue table (403) belongs. In M0411, a request counter deletion process for decrementing is issued to the method call table (406).
In the method call table (406) that has received M0411, a request counter deletion process is executed.
In the request counter deletion process, the accumulated number (T0307) of the corresponding table in the method call table (406) is decremented. In this example, the decrement result should be “0”. In this case, the entire data of the corresponding class policy is deleted.
[0059]
In the request queue management unit (402), after transmitting M0411, in order to transmit the information of M0412 to the client B, the request queue management unit (402) sends the message to the server message communication management unit (405).
The server message communication management unit (405) that received M0412 sends the message to the client message communication management unit (302) of client B (3) at M0413 via the information object execution environment unit (1) of M0412.
Since the operation of the object execution environment unit (1) during this period is exactly the same as in the case of “normal method activation”, the description thereof is omitted.
[0060]
Upon receiving M0413, the client message communication management unit (302) converts the method processing result received in M0413 from a message to a programming interface, and sends it to the client logic unit in M0414.
As a result of the above processing, the client logic unit of the client A (3) completes the method execution result acquisition for acquiring the request result requested by the programming interface.
[0061]
An operation in which real-time method activation set in the class policy is guaranteed by method activation by the same request will be described with reference to FIG. 11 centering on the movement of the request queue table (403).
In the request queue table (403), an accumulation number is assigned to a request transmitted from the client (3) and accumulated. In response to this, the request queue management unit (402) takes out the accumulation number (T0101) in order from “1” and activates the method.
In this case, as shown in the example of FIG. 11, when the storage numbers 2, 3 and 7 execute the same request, the maximum number of the same request stored is defined by the class policy, and this limit is reached. In this case, the process of returning the method processing result to the accumulation numbers 2, 3, and 7 by one request activation is realized as the method activation by the same request.
[0062]
As described above, the method invocation expected by each request accumulated in the server queue is monitored, and if the number of the same queued requests reaches the number specified in the class policy, Independent of the application software by acquiring the processing result of the method executed in response to the request at the timing when the method activation for the oldest request is determined by Based on the defined class policy, method invocation can be realized transparently from the client and the server.
[0063]
In this way, the object execution environment unit (1) which manages the method invocation method by request scheduling expected for each class in advance as a class policy regardless of the client (3) and the server (4), and the server (4) In the request scheduling, the request queue management unit (402) of the server (4) compares the request stored in the request queue table (403) with the class policy, and activates the method according to the method based on the class policy. By instructing the request dispatch unit (404), method activation that guarantees different real-time properties for each class is realized.
[0064]
Also, in this way, in request scheduling, the method is activated at the timing when the oldest registered request in the queue is processed, and this result is sent as a response to all clients that issued the same request. Class policy policy activation that minimizes the block of other method calls is avoided by avoiding unnecessary computer resource waste during request scheduling by minimizing the number of times the same method is executed. Based on the above, the real-time method starting method is realized, which is realized transparently from the client logic of the client and the server logic of the server.
[0065]
Embodiment 2. FIG.
FIG. 12 differs from the object-oriented system configuration diagram for realizing the method invocation method of the present invention in Embodiment 1 in the items constituting the method call table. In this embodiment, the method call table is described as a method call limit time table (407).
[0066]
FIG. 13 shows an example of the request queue table of this embodiment. FIG. 13 shows a configuration in which the registration time (T0107) for each request is added to the request queue table configuration in the first embodiment.
FIG. 14 shows an example of the class policy repository of this embodiment. FIG. 14 shows a configuration in which the boundary accumulation number is deleted and a time limit (T0207) is added to the class policy repository configuration in the first embodiment.
FIG. 15 shows an example of the method call limit time table (407) of this embodiment.
FIG. 15 is a table in which limit time queued for each method activation type requested by a request in the server is registered, and includes class type (T0401), method type (T0402), and limit time (T0403). It has a configuration.
[0067]
Next, the operation of the second embodiment will be described.
The operation of the second embodiment describes the operation of the request limit time registration process that replaces the request counter registration process with respect to the operation of the first embodiment, and then the method call limit that replaces the method call generation process. The operation of the time generation process will be described, followed by the operation of the request dispatch process in the case of the second embodiment.
[0068]
The processing flow of the request time limit registration process of the second embodiment is the same as that of the request counter registration process of the first embodiment, except that the method call time limit table (407) instead of the method call table (406) of the server (4). ) And a method call limit time generation process instead of a method call counter generation process. Therefore, hereinafter, the operation unique to the second embodiment will be described.
[0069]
In the request limit time registration process, when the server (4) receives the request, it is determined as “request counter analysis process” based on the method call limit time table (407) whether or not the same request already exists. Unlike the first embodiment, the same request in this embodiment is determined as a request that requests method activation for the same method of the same object. If the same request does not already exist as a result of this analysis, the class policy registered in the class policy repository of the object execution environment is acquired, and a corresponding table of the method call limit time table (407) is created.
[0070]
The operation of the method call limit time generation process will be described with reference to FIGS.
As shown in FIG. 14, the acquired class policy structure includes, for each class type (T0201), one or more method method information (T0202) defined by the class and parameter information (T0203, T0204), return information (T0205), and a limit time (T0207) that is the maximum time for which the method is processed by normal method activation. In this information, the method method information requested by the received request is specified and developed in the method call limit time table shown in FIG. For example, the parameters “in int1000”, “in int 10”,... For the method method_1 of the object Object_1 generated from the class_1 by the request. . . 14 and the return information is returned as “int”, the table with the class type (T0201) shown in FIG. 14 of class_1 is acquired as the class policy, and the first table shown in FIG. 15 is created from this information. Is done.
If the limit time (T0207) in the method call limit time table (407) is blank, it means that only normal method activation is performed.
[0071]
The operation of the corresponding request analysis process according to the second embodiment will be described.
In the corresponding request analysis process executed by the request queue management unit (402), first, a request having an accumulation number (T0101) of “1” is acquired from the table of the request queue table (403), and this request information object The case where the type (T0102), the method type (T0103), the class type (T0401) and the method type (T0402) in the method call limit time table (407) all match is searched, and the corresponding limit time (T0403) is acquired. To do. Next, each table of the request queue table (403) is searched, a request with the accumulation number “1” is acquired, the object type (T0102), method type (T0103), parameter information (T0104, T0105) of the request information, and return With respect to a request in the case where all of the information (T0106) matches, each registration time (T0107) is referred to, and a request that has passed the corresponding limit time is determined as “method activation by the same request”. If there is one that has passed the relevant limit time (request with accumulation number “1”) or none at all, it is determined that “normal method activation” and processing is continued.
[0072]
As described above, the requests accumulated in the server queue are monitored, and if the same request is queued for more than the time specified in the class policy and is waiting to be executed, When the method invocation for the oldest request is determined, the request from the client is queued by returning the processing result of the method executed in response to the request to all other clients that have made the same request. The method can be invoked with constraints on the current time.
[0073]
Embodiment 3 FIG.
FIG. 16 shows an example of a configuration in which class policy statistical processing is added to the object execution of the object-oriented system configuration for realizing the method invocation method of the present invention in the first embodiment.
Reference numeral 105 denotes a class policy statistical processing unit (105) that reads the request accumulation status for each class policy from the method call table (406) and analyzes the read request accumulation status to change the multiple processing conditions.
In this embodiment, a case where the request accumulation status is the number of accumulated requests is described as an example.
[0074]
Next, the operation of the third embodiment will be described with reference to FIG.
First, the operation of the class policy periodic update process for periodically updating the class policy repository (103) will be described.
Subsequently, in order to statistically calculate the class policy from the number of requests actually performed, the operation of the class policy statistical processing for collecting method method information performed by the request from each server will be described.
[0075]
The operation of the class policy statistical process will be described with reference to FIG.
This operation is a process that is executed before the request registration process is executed by the server (4) and the request response waiting state is entered in the normal method starting operation in the first embodiment.
[0076]
After the request queue management unit (402) executes the request registration process, the class and method information that is the source of the method of the object that is activated based on the registered request is sent to the server message communication management unit (405) in M0501.
Upon receiving M0501, the server message communication management unit (405) sends the M0501 information to the message communication management unit (104) of the object execution environment unit (1) in M0502.
Upon receiving M0502, the message communication management unit (104) sends the information of M0502 to the class policy statistical processing unit (105) in M0503.
Upon receiving M0503, the class policy statistical processing unit (105) accumulates the received class and method information.
[0077]
The operation of the class policy periodic update process will be described.
In the class policy statistical processing unit (105) that collects the method activation class and method information required in the entire object-oriented system, an appropriate class policy is obtained from the information collected every predetermined period. And the class policy management unit (102) is instructed to update the class policy repository. Upon receiving this instruction, the class policy management unit (102) updates the contents of the class policy repository (103).
[0078]
As described above, the class policy that defines the real-time property of method invocation for each class must be statistically calculated at regular intervals by monitoring the request status from the client that is actually executed in the object-oriented system to the server. Thus, the class policy corresponding to the latest situation can always be automatically set.
[0079]
Further, the value of the class policy reflecting the status of request transmission transmitted to the server can be automatically updated at regular intervals.
[0080]
Embodiment 4 FIG.
FIG. 18 changes the items constituting the method call table (406) to the object-oriented system configuration for realizing the method activation method of the present invention in the first embodiment. In this embodiment, the method call table (406) will be described as a method call total table (408).
FIG. 19 shows the structure of the method call totaling table (408), which is composed of a class type (T0501), a method type (T0502), and an accumulated number (T0503).
[0081]
Next, the operation of the fourth embodiment will be described.
First, the operation of the request aggregation registration process that is executed instead of the request counter registration process of the first embodiment will be described.
Subsequently, an operation of a method call aggregation process executed instead of the method call aggregation generation process of the first embodiment will be described, and then an operation of a method activation process by the same request as the request dispatch process will be described.
[0082]
The processing flow of the request counting registration process according to the fourth embodiment is almost the same as the request counter registration process according to the first embodiment, but the following operations are different.
In the request aggregation registration process, when the server (4) receives a request, it is determined as “request aggregation analysis process” based on the method call aggregation table (408) whether or not the same request already exists. Unlike the first embodiment, the same request in this embodiment is determined as a request that requests method activation for the same method of the same object. Specifically, the class type (T0501) and the method type (T0502) in the method call aggregation table (408) are the same. As a result of this analysis, if the same request already exists, the accumulated number (T0503) of the corresponding table in the method call aggregation table (408) is incremented, and if it does not exist, it is registered in the class policy repository of the object execution environment section. The obtained class policy is acquired, and the operation by the “method call aggregation table generation process” is started.
[0083]
The method invocation method of this embodiment can be applied when the client (3) wants to obtain the processing result of the method invocation by the latest parameter, and the processing result of the method invocation requested by the request. Therefore, in the case of a request whose parameters must be the same as when the request is transmitted, it is necessary to apply the method activation method of the first embodiment.
[0084]
The operation of the method call total generation process will be described with reference to FIGS.
As shown in FIG. 3, the acquired class policy has a structure of one or more method method information (T0202) and parameter information (T0203, T0203) defined for the class for each class type (T0201). T0204), return information (T0205), and the boundary accumulation number (T0206) that is the maximum queuing number of the method that is processed by normal method activation. The method method information requested by the received request is specified in this information, and is expanded into one table of the method call aggregation table configuration shown in FIG. For example, the parameters “in int 1000”, “in int 10”,... For the method method_1 of the object Object_1 generated from the class_1 by the request. . . 19 and the return information is returned as “int”, the table shown in FIG. 19 having the class type (T0201) of class_1 and the method type (T0502) of method_1 is acquired as a class policy. The first table shown in FIG.
[0085]
The operation of the corresponding request analysis process according to the fourth embodiment will be described.
In the corresponding request analysis process executed by the request queue management unit (402), first, a request having an accumulation number (T0101) of “1” is acquired from the table of the request queue table (403), and this request information object A case where the type (T0102), the method type (T0103), the class type (T0501) and the method type (T0502) in the call count table (408) match is searched, and the corresponding accumulated number (T0503) is acquired. When the accumulated number (T0503) is “1”, it is determined that “normal method activation”. When the accumulation number (T0503) is not “1”, each table of the request queue table (403) is searched, and the same request as the accumulation number “1” is searched. The same request is determined as “method activation by the same request” when the object type (T0102), method type (T0103), and return information (T0305) of the request information match.
[0086]
The operation of the method activation process by the same request according to this embodiment is almost the same as the operation of the method activation process by the same request according to the first embodiment. However, the process for starting the method described below is different.
The request queue management unit (402) that has determined that the result of the corresponding request analysis process is “method activation by the same request” indicates that it is “method activation by the same request” and information of the next request to be processed in M402. It is sent to the request dispatch unit (404). However, request information to be processed next uses parameter information (T0104, T0105) and return information (T0106) of the request having the largest accumulation number (T0101) in the request queue table (403).
[0087]
As described above, the requests accumulated in the server queue are monitored, and when the number of requests for the same method of the same object reaches the number specified in the class policy, the oldest next among the same requests By instructing the method calculation from the latest parameter information and return information in the same request at the timing when the method activation for the request is executed, the client can always obtain the latest method calculation result.
[0088]
Embodiment 5. FIG.
FIG. 20 is a flowchart of corresponding request analysis processing in the fifth embodiment.
Next, the operation of the corresponding request analysis process according to the fifth embodiment will be described with reference to FIG.
In the fifth embodiment, the operation of the corresponding request analysis process is different from the operation of the first embodiment.
The operation will be described below with reference to FIGS.
In the corresponding request analysis process activated by the request queue management unit (402), the information of the request whose accumulation number (T0101) registered in the request queue table (403) is “1” is stored in the method call table in M0601. (406).
In the method call table (406) that has received M0601, the class type, method type, parameter information, and return information of the received request information are the object type (T0301) and method type (T0302) of the method call table (406), respectively. And the parameter information (T0303, T0304) and the return information (T0305) are searched for exactly the same table, and it is analyzed whether there is a table whose accumulated number (T0307) reaches the boundary accumulated number (T0306). If it has reached, it is determined that the request is the same, and if it has not reached, it is determined that it is not the same request, and the result is returned to the request queue management unit (402) in M0602.
[0089]
In the request queue management unit (402) that has received M0602, when the same request is notified, a method activation process is performed on the request by the same request.
When it is notified that they are not the same request, the M0601 and M0602 are similarly determined for the next accumulation number (T0101) in the request queue table (403), and M0602 receives a notification that they are not the same request. If so, continue processing.
When it is determined by the above processing that all requests in the request queue table (403) are not the same request, normal method activation processing is performed for the request with the accumulation number “1”.
[0090]
As described above, requests accumulated in the server queue are monitored, and if the number of identical requests reaches the number specified in the class policy, priority is given to the timing of the first request scheduling after this registration. By executing the method invocation corresponding to the request with the oldest registration time among the same requests and returning the result to all clients that issued the same request, the importance due to the large number of the same requests was followed. Method invocation is possible.
[0091]
In addition, in this way, method invocation according to a class policy that is not caught at the time when a client issues a request is realized.
[0092]
Embodiment 6 FIG.
FIG. 21 is a configuration diagram of the class policy repository according to the sixth embodiment.
FIG. 22 is a method call table configuration diagram according to the sixth embodiment.
FIG. 21 is a diagram showing an example of a class policy repository according to the sixth embodiment. FIG. 21 shows a configuration in which a minimum accumulation number (T0208) is added to the class policy repository in the first embodiment instead of the boundary accumulation number (T0206).
FIG. 22 is a diagram showing an example of a method call table according to the sixth embodiment. FIG. 22 shows a configuration in which a minimum accumulation number (T0308) is added to the method call table in the first embodiment instead of the boundary accumulation number (T0306).
[0093]
Next, the operation in the sixth embodiment will be described.
First, the operation of the method call counter generation process different from that of the first embodiment will be described, and then the operation of the request dispatch process different from that of the first embodiment will be described.
[0094]
The operation of the method call counter generation process will be described with reference to FIGS.
As shown in FIG. 21, the acquired class policy structure includes, for each class type (T0201), one or more method method information (T0202) defined by the class and parameter information (T0203, T0204), return information (T0205), and a minimum accumulation number (T0208) that is the minimum accumulation number that the method can be processed by normal method activation. The method method information requested by the received request is specified in this information, and is expanded into one table of the method call table configuration shown in FIG. For example, the parameters “in int 1000”, “in int 10”,... For the method method_1 of the object Object_1 generated from the class_1 by the request. . . 22 and the return information is returned as “int”, the table with the class type (T0201) shown in FIG. 22 of class_1 is acquired as the class policy, and the first table shown in FIG. 22 is created from this information. Is done.
When the minimum accumulation number (T0308) in the method call table (407) is blank, it means that only normal method activation is performed.
[0095]
The operation of the corresponding request analysis process according to the sixth embodiment will be described.
In the corresponding request analysis process executed by the request queue management unit (402), first, a request having an accumulation number (T0101) of “1” is acquired from the table of the request queue table (403), and this request information object The type (T0102), method type (T0103), parameter information (T0104, T0105), and return information (T0106) are respectively the object type (T0301) and method type (T0301) of the object information method call table of the method call table (406). A search is made for a case that matches T0302), parameter type (T0303, T0304), and return information (T0305). If the corresponding table exists, it is determined whether or not the accumulated number (T0307) of the table has reached the minimum accumulated number (T0308), and if it has reached, it is determined that “method activation by the same request”. If there is no corresponding table, it is determined that “normal method activation”. If the corresponding table exists but the accumulated number (T0307) of the table does not reach the minimum accumulated number (T0308), the accumulation number (T0101) of the request queue table (403) is “2”. The request is acquired, and similarly, “normal method activation” or “method activation by the same request” is determined. If it cannot be determined, the request for the next accumulation number (T0101) is further analyzed.
In the above description, the case where the parameter information also matches when the method is determined to be the same has been described. However, an embodiment in which it is determined that the method is the same when the parameters are not the same is also conceivable.
In the above description, the number of accumulated requests is used as the multiple processing condition, but it is also conceivable that the limit time described in the second embodiment is additionally set as the multiple processing condition.
[0096]
As described above, the requests accumulated in the server queue are monitored, and if the same queued requests do not reach the number specified in the class policy, then the method is invoked for the oldest request among the same requests. Even if it is judged, the method activation is suspended, and when the specified number is reached, the method activation corresponding to the request with the oldest registration time is executed among the same requests, and all the results that issued the same request By returning to the client, the number of method invocations executed in response to the request can be minimized.
[0097]
Embodiment 7 FIG.
FIG. 23 shows an example of a configuration in which a class policy update information distribution unit (106) is added to the object execution environment unit in the object-oriented system in the first embodiment.
Next, the operation of the class policy update information distribution process in the seventh embodiment will be described with reference to FIG.
In the class policy update information distribution process, in the class policy registration process described in the first embodiment, the class policy management unit (102) of the object execution environment unit (1) receives M0101, and the class policy repository registration process is performed. Is executed, the class policy update information is distributed to the associated server (4).
[0098]
After executing the class policy repository registration process, the class policy management unit (102) notifies the updated class policy information to the class policy update information distribution unit (106) in M0701.
The class policy repository update information distribution unit (106) that has received M0701 searches the active server (4) for the purpose of distributing the update class policy information to the related server (4). In M0702, the object management unit ( 101).
The object management unit (101) that has received M0702 returns the information of the server (4) in operation to the class policy update information distribution unit (106) in M0703.
In the class policy update information distribution unit (106) that has received M0703, the update class policy information is notified to all of the acquired servers (4) in operation.
[0099]
In the following description, an operation for notifying one server (4) of update class policy information will be described.
The class policy update information distribution unit (106) sends the update class policy information to the message communication management unit (104) in M0704.
The message communication management unit that has received M0704 sends the information of M0704 to the server message communication management unit (405) of the server (4) in M0705.
The server message communication manager (405) that has received M0705 sends the information of M0705 to the request queue manager (402) in M0706.
In the request queue management unit (402) that has received M0705, the method call table (406) is referred to, the object type (T0102), method type (T0103), parameter information (T0104, T0105), and return information of the updated class policy information. If there is a table in which all of (T0106) match, the boundary accumulation number (T0306) of that table is updated to the value of the update class policy information.
[0100]
As described above, when the class policy is updated, the update information is distributed to a server that is already executed in the object-oriented system, so that the method activation based on the latest class policy can always be performed.
[0101]
Embodiment 8 FIG.
FIG. 25 shows a configuration in which a request comparison unit (409) is added to the server of the object-oriented system of the first embodiment.
The request comparison unit (409) compares and searches other servers that start the method that has the same method information as the method that it starts, and distributes the stored processing results to the searched server.
FIG. 26 shows a configuration in which a processing result (T0108) is added to the request queue table (403) of the first embodiment.
In this embodiment, as an example, a case will be described in which the request dispatch unit (404) stores the processing result in the request queue table (403).
[0102]
Next, the operation of the eighth embodiment will be described.
In the eighth embodiment, method execution is performed in the server (4) by the processing described in the first embodiment, and after this result is transmitted to the request queue management unit (402) in M0314 and M0315, The method execution result is registered in the client (3) issuing the same request to the server (4) and the other server in which the same request is queued.
Therefore, first, a process for searching for another server in operation by the server (4) A that has executed the method will be described as an operation server search process with reference to FIG.
Next, the operation of the same request comparison process for registering the method execution result in one of the servers (4) B will be described with reference to FIG.
Next, the corresponding request analysis process in the server (4) B and the operation for actually executing the method activation process will be described.
[0103]
The operation of the server (4) inspecting another server in operation to the object management unit (101) of the object execution environment unit (1) will be described with reference to FIG.
The request comparison unit (409) of the server (4) requests the server message communication management unit (405) to search for an operation server in M0901.
Upon receiving M0901, the server message communication management unit (405) sends the information of M0901 to the message communication management unit (104) of the object execution environment unit (1) in M0902.
The message communication management unit (104) that has received M0902 sends the information of M0902 to the object management unit (101) in M0903.
The object management unit (101) that has received M0903 sends the operating server list information to the message communication management unit (104) in M0904.
The message communication management unit that has received M0904 sends the information of M0904 to the server message communication management unit (405) of the server (4) in M0905.
The server message communication management unit (405) that has received M0905 sends the information of M0905 to the request comparison unit (409) in M0906.
[0104]
The operation of the same request comparison process will be described with reference to FIG.
This process is a process of transmitting this information to another operating server after the method execution is performed in the first embodiment and the method execution result is notified to the server (4) A in M0405.
The request queue management unit (402) of the server (4) A sends the method method information and the method execution result to the request comparison unit (409) in M0801.
Upon receiving M0801, the request comparison unit (409) executes an operation server search process, and searches for another server that is operating by the operation already described. Hereinafter, an operation for notifying the server method (4) B of the method method information and the method execution result from the result of the operation server search process will be described.
[0105]
The request comparison unit (409) that has determined the notification of the method execution result to the server (4) B sends the information received in M0801 to the server message communication management unit (405) in M0802.
Receiving M0802, the server message communication management unit (405) sends the information of M0802 to the server message communication management unit (405) of server (4) B using M0803.
Upon receiving M0803, the server message communication management unit (405) sends the information of M0803 to the request comparison unit (409) in M0804.
Upon receiving M0804, the request comparison unit (40) sends the information of M0804 to the request queue management unit (402) in M0805.
The request queue management unit (402) that has received M0805 executes processing result registration processing.
In the processing result registration process, the request queue table (403) is searched, and the object type, method type, parameter information, and return information of the method method information received in 0805 are the object type (T0102) and method type ( If there is a table in which T0103), parameter information (T0104, T0105), and return information (T0106) match, the method execution result is registered in the processing result (T0108) of the table.
[0106]
The operation of the corresponding request analysis process according to the eighth embodiment will be described.
In the corresponding request analysis process executed by the request queue management unit (402), first, a request whose accumulation number (T0101) is “1” is acquired from the table of the request queue table (403), and processing of this request information is performed. It is determined whether or not a method execution result is registered in the result (T0108). If it is registered, it is determined that “method execution result has been registered”. If it is not registered, “no method execution result has been registered”. Judge. Next, each table of the request queue table (403) is searched, and “method activation by the same request” or “normal method activation” is determined as in the first embodiment.
[0107]
The method call table (406) that received M0310 compares the method call table (406) with the request queue table, and sends the result to the request queue management unit (402) in M0311.
Thus, the corresponding request analysis process ends. When this result is “no method execution result registration”, the processing is continued as in the case of the first embodiment. However, when “method execution result has been registered”, the object execution method is different. Different processing will be described.
[0108]
The request queue management unit (402) that has determined “method execution result registered” by the corresponding request analysis processing indicates that the next request to be processed is “method execution result registered” and that the request queue table (403) The processing result (T0108) of the corresponding table is sent as a method execution result to the request dispatch unit (404) in M0312.
Upon receiving M0312, the request dispatch unit (404) sends the information as a processing result to the request dispatch unit (404), assuming that the result of the next request to be processed is a method execution result. Thereafter, the same processing as in the first embodiment is performed.
[0109]
As described above, the requests accumulated in the server queue are monitored, and when the same request reaches the boundary accumulation number, the next time the method activation for the oldest request among the same requests is determined, In addition to returning the processing result of the method implemented in response to the request to the client that made the same request, if the same request is accumulated in another server, the request in that server In scheduling, when the next method invocation is determined for the same request, the method execution is not performed and the already acquired method execution result is transmitted, so that the same method can be used between different servers. The number of method invocations can be minimized.
[0110]
Embodiment 9 FIG.
In the above-described embodiment, the boundary accumulation number, the limit time, and the minimum accumulation number have been described as examples of the multiple processing conditions. However, the present invention is not limited to this. Needless to say, it is possible to set a predetermined plurality of processing conditions other than those described above to realize the method activation method according to the present invention.
In the above embodiment, there may be a plurality of clients and servers, or a single client and server.
Moreover, although the case where the method invocation method according to the present invention is implemented in an object-oriented system as an example has been described, it is not limited to this. The present invention can also be applied to a system other than an object-oriented system that starts a method for processing data.
[0111]
【The invention's effect】
As described above, according to the method invocation method according to the present invention, when the number of requests accumulated in the server queue reaches the number specified in the class policy, the oldest request among the same requests is next requested. Because it is possible to share the processing result by method activation for all clients that have made the same request, based on the class policy defined independently from the application software, without hindering the flexibility of the application software, There is an effect that real-time method activation can be realized by effective use of computer resources.
[0112]
As described above, according to the present invention, when the same request is queued for more than the time specified in the class policy and is waiting to be executed, the method activation for the oldest request among the same requests is performed next. When it is determined, it is possible to share the processing result of the method executed in response to the corresponding request among other clients that have made the same request, so the request from the client is unpredictable queuing time. On the other hand, there is an effect that a constraint can be added based on the class policy.
[0113]
As described above, according to the present invention, the class policy that defines the real-time property of method activation for each class can be dynamically calculated from the request status from the client to the server that is actually executed in the object-oriented system. Since it is possible, there is an effect that the method can be invoked based on the class policy that always reflects the latest situation.
[0114]
As described above, according to the present invention, when the number of requests for the same method of the same object reaches the number specified in the class policy, the timing at which the method activation for the oldest request among the same requests is executed next. Because the method calculation can be performed from the parameter information and return information of the latest request and the result can be shared between clients, the client always displays the latest method processing result regardless of the request transmission timing. There is an effect that it can be acquired.
[0115]
As described above, according to the present invention, when the number of identical requests reaches the number specified in the class policy, the temporal order queued at the timing of the first request scheduling after the registration. Regardless of the method, since it is possible to execute method invocation preferentially, there is an effect that priority processing of method invocation can be performed not only according to the time when the requests are issued but also according to the situation where the same requests are concentrated.
[0116]
As described above, according to the present invention, method activation can be performed when the number of the same queued requests reaches the specified number of class policies. There is an effect that the suppressed request scheduling can be performed.
[0117]
As described above, according to the present invention, it is possible to distribute class policy update information to a server that is already executed in the object-oriented system. Therefore, the method activation always reflecting the latest class policy is performed. There is an effect that can be done.
[0118]
As described above, according to the present invention, the method activation restriction due to the same request can be shared among a plurality of servers. Therefore, the method activation based on the class policy can be applied to a plurality of servers. For this reason, there is an effect that a real-time method activation method can be performed by the effective use of computer resources with minimum method activation in the entire distributed object-oriented system.
[Brief description of the drawings]
FIG. 1 is a diagram showing an example of an object-oriented system configuration that implements a method activation method according to the present invention in a first embodiment;
FIG. 2 is a configuration diagram of a request queue table in the first embodiment.
FIG. 3 is a configuration diagram of a class policy repository according to the first embodiment.
FIG. 4 is a method call table configuration diagram according to the first embodiment;
FIG. 5 is a flowchart of class policy registration processing in the first embodiment.
FIG. 6 is a flowchart of request counter registration processing in the first embodiment.
FIG. 7 is a flowchart of a normal method activation process in the first embodiment.
FIG. 8 is a flowchart of a normal method activation process in the first embodiment.
FIG. 9 is a method invocation process flowchart according to the same request in the first embodiment.
FIG. 10 is a method invocation process flowchart according to the same request in the first embodiment.
FIG. 11 shows a corresponding request analysis process in the first embodiment.
FIG. 12 is a diagram showing an example of an object-oriented system configuration for implementing a method activation method according to the present invention in a second embodiment.
FIG. 13 is a configuration diagram of a request queue table in the second embodiment.
FIG. 14 is a configuration diagram of a class policy repository according to the second embodiment.
FIG. 15 is a configuration diagram of a method call limit time table according to the second embodiment.
FIG. 16 is a diagram showing an example of an object-oriented system configuration for implementing a method activation method according to the present invention in a third embodiment.
FIG. 17 is a flowchart of class policy statistical processing in the third embodiment.
FIG. 18 is a diagram showing an example of an object-oriented system configuration that implements a method activation method according to the present invention in a fourth embodiment;
FIG. 19 is a diagram showing an example of a method call aggregation table configuration in the fourth embodiment.
FIG. 20 is a flowchart of corresponding request analysis processing in the fifth embodiment.
FIG. 21 is a diagram showing an example of a class policy repository configuration according to the sixth embodiment.
FIG. 22 is a configuration diagram of a method call table according to the sixth embodiment.
FIG. 23 is a diagram showing an example of an object-oriented system configuration that implements a method activation method according to the present invention in a seventh embodiment;
FIG. 24 is a class policy repository update information distribution processing flow diagram according to the seventh embodiment.
FIG. 25 is a diagram showing an example of an object-oriented system configuration that implements a method invocation method according to the present invention in an eighth embodiment;
FIG. 26 is a diagram showing an example of a request queue table configuration in the eighth embodiment.
FIG. 27 is the same request comparison process flow in the eighth embodiment.
FIG. 28 is a flowchart of the same server search process according to the eighth embodiment.
FIG. 29 is a system configuration diagram of a conventional example.
FIG. 30 is a diagram illustrating a conventional message system.
FIG. 31 is a diagram showing a data structure of a conventional example.
[Explanation of symbols]
1 object execution environment part, 2 class policy input interface, 3 client, 4 server, 101 object management part, 102 class policy management part, 103 class policy repository, 104 message communication management part, 105 class policy statistical processing part, 106 class policy Update information distribution unit, 301 client logic unit, 302 client message communication management unit, 401 server logic unit, 402 request queue management unit, 403 request queue table, 404 request dispatch unit, 405 server message communication management unit, 406 method call table, 407 Method call limit time table, 408 Method call total table, 409 request comparison unit, 4011 method, 4012 Object part, T0101 Storage number, T0102 Object type, T0103 Method type, T0104 Parameter 1 information, T0105 Parameter 2 information, T0106 Return information, T0107 Registration time, T0108 Processing result, T0201 Class type, T0202 Method type, T0203 Parameter 1 information, T0204 parameter 2 information, T0205 return information, T0206 boundary accumulation number, T0207 time limit, T0208 minimum accumulation number, T0301 object type, T0302 method type, T0303 parameter 1 information, T0304 parameter 2 information, T0305 return information, T0306 boundary accumulation number, T0307 accumulation number, T0308 minimum accumulation number, T0401 class type, T0402 method type, T0403 limit Time, T0501 class type, T0502 method type, T0503 Accumulated number, M0101 to M0102, M0201 to M0206, M0301 to M0323, M0402 to M0414, M0501 to M0503, M0601 to M0602, M0701 to M0706, M0801 to M0805, M0901 to M0906 , 3001 computer program, 3002 computer platform, 3003 application program, 3004 object-oriented programming, 3005 database management device, 3006 operating system, 3007 microinstruction code, 3008 input / output interface, 3009 RAM, 3010 CPU, 3011 input / output interface, 3012 connection Cable, 301 Terminal device, 3014 connection cable, 3016 user, 3017 connection cable, 3018 data storage device, 3019 external database, 3020 connection cable, 3021 printer, 3121 method A, 3122 method B, 3123 object management table, 3124 data frame, 3125 loaded Class table, 3126 signal line, 3127 signal line, 3128 signal line, 3129 signal line, 3130 messenger, 3101 object identification configuration, 3102 object identification column, 3103 access address, 3104 format, 3105 class identifier, 3106 instance identifier, 3107 object management Table (OMT), 3108 Object identification field, 3109 Instance data frame address.

Claims (12)

クライアントから発信される、データを処理するメソッドを起動するリクエストを受信するメソッド起動方式において、
メソッドを起動するサーバと、
上記クライアントからのリクエストを受信し、受信したリクエストを上記サーバへ発信するオブジェクト実行環境部とを備え、
上記リクエストは、起動するメソッドを特定するメソッド情報を含み、
上記オブジェクト実行環境部は、メソッド情報と当該メソッド情報を含む複数のリクエストをまとめて処理する条件を規定する複数処理条件とを含むクラスポリシィを複数記憶するクラスポリシィリポジトリを備え、
上記サーバは、上記オブジェクト実行環境部から発信されたリクエストを受信するとともに、上記クラスポリシィリポジトリを検索して、受信したリクエストと同じメソッド情報を含むクラスポリシィを特定し、特定したクラスポリシィに含まれる複数処理条件を取得するリクエストキュー管理部と、上記リクエストキュー管理部により受信されたリクエストを蓄積するリクエストキューテーブルと、上記リクエストキューテーブルに蓄積されたリクエストの内、上記リクエストキュー管理部により受信されたリクエストと同じメソッド情報を含むリクエストの数を示すリクエスト蓄積状況を、上記リクエストキュー管理部により取得された複数処理条件と対応付けて記憶するメソッド呼び出しテーブルと、上記リクエストキューテーブルに蓄積されたリクエストを第１のリクエストとして取得し、上記第１のリクエストに含まれるメソッド情報で特定されるメソッドを起動して、当該メソッドの処理結果を、上記第１のリクエストを発信したクライアントへ返信するとともに、上記第１のリクエストと同じメソッド情報を含み且つリクエスト蓄積状況が上記メソッド呼び出しテーブルに当該リクエスト蓄積状況と対応付けて記憶された複数処理条件を満たしているリクエストを第２のリクエストとして上記リクエストキューテーブルから検出し、上記処理結果を、上記第２のリクエストを発信したクライアントへ返信することにより、上記第１のリクエストと上記第２のリクエストとを含む複数のリクエストをまとめて処理するリクエストディスパッチ部とを備え、
上記リクエストキューテーブルは、上記リクエストディスパッチ部によりまとめて処理された複数のリクエストを削除することを特徴とするメソッド起動方式。In the method invocation method that receives a request sent from a client to invoke a method that processes data,
A server that invokes the method;
An object execution environment unit that receives a request from the client and transmits the received request to the server;
The above request contains method information that identifies the method to be invoked,
The object execution environment unit includes a class policy repository that stores a plurality of class policies including method information and a plurality of processing conditions that define conditions for processing a plurality of requests including the method information collectively.
The server receives a request transmitted from the object execution environment unit, searches the class policy repository, identifies a class policy including the same method information as the received request, and is included in the identified class policy A request queue management unit that acquires multiple processing conditions, a request queue table that accumulates requests received by the request queue management unit, and a request that is received by the request queue management unit among the requests that are accumulated in the request queue table. The method call table that stores the request accumulation status indicating the number of requests including the same method information as the received request in association with the multiple processing conditions acquired by the request queue management unit, and the request queue table Get the product has been requested as a first request to start the method specified by the method information included in the first request, the processing result of the method, the client that originated the first request A request that has the same method information as the first request and that satisfies the multiple processing conditions stored in the method call table in association with the request accumulation status is defined as a second request. detected from the request queue table, the processing result, by replying to the client that originated the second request, to collectively process multiple requests including the above first request and the second request A request dispatch unit,
A method invocation method, wherein the request queue table deletes a plurality of requests processed together by the request dispatch unit. 上記複数処理条件は、上記リクエストディスパッチ部が上記複数のリクエストをまとめて処理する場合のリクエスト蓄積状況の境界値を定める境界蓄積数を含み、
上記リクエストディスパッチ部は、上記複数のリクエストのリクエスト蓄積状況が上記境界蓄積数以上である場合に上記複数のリクエストをまとめて処理することを特徴とする請求項１記載のメソッド起動方式。The multiple processing condition includes a boundary accumulation number that defines a boundary value of a request accumulation situation when the request dispatch unit processes the plurality of requests together,
2. The method invocation method according to claim 1, wherein the request dispatch unit processes the plurality of requests together when the request accumulation status of the plurality of requests is equal to or greater than the boundary accumulation number. クライアントから発信される、データを処理するメソッドを起動するリクエストを受信するメソッド起動方式において、
メソッドを起動するサーバと、
上記クライアントからのリクエストを受信し、受信したリクエストを上記サーバへ発信するオブジェクト実行環境部とを備え、
上記リクエストは、起動するメソッドを特定するメソッド情報を含み、
上記オブジェクト実行環境部は、メソッド情報と当該メソッド情報を含む複数のリクエストをまとめて処理する条件を規定する複数処理条件とを含むクラスポリシィを複数記憶するクラスポリシィリポジトリを備え、
上記サーバは、上記オブジェクト実行環境部から発信されたリクエストを受信するとともに、上記クラスポリシィリポジトリを検索して、受信したリクエストと同じメソッド情報を含むクラスポリシィを特定し、特定したクラスポリシィに含まれる複数処理条件を取得するリクエストキュー管理部と、上記リクエストキュー管理部により受信されたリクエストを蓄積するとともに、当該リクエストが受信された時間を登録時間として記憶するリクエストキューテーブルと、上記リクエストキュー管理部により受信されたリクエストに含まれるメソッド情報を、上記リクエストキュー管理部により取得された複数処理条件と対応付けて記憶するメソッド呼び出しテーブルと、上記リクエストキューテーブルに蓄積されたリクエストを第１のリクエストとして取得し、上記第１のリクエストに含まれるメソッド情報で特定されるメソッドを起動して、当該メソッドの処理結果を、上記第１のリクエストを発信したクライアントへ返信するとともに、上記第１のリクエストと同じメソッド情報を含み且つ登録時間が上記メソッド呼び出しテーブルに当該メソッド情報と対応付けて記憶された複数処理条件を満たしているリクエストを第２のリクエストとして上記リクエストキューテーブルから検出し、上記処理結果を、上記第２のリクエストを発信したクライアントへ返信することにより、上記第１のリクエストと上記第２のリクエストとを含む複数のリクエストをまとめて処理するリクエストディスパッチ部とを備え、
上記リクエストキューテーブルは、上記リクエストディスパッチ部によりまとめて処理された複数のリクエストを削除することを特徴とするメソッド起動方式。In the method invocation method that receives a request sent from a client to invoke a method that processes data,
A server that invokes the method;
An object execution environment unit that receives a request from the client and transmits the received request to the server;
The above request contains method information that identifies the method to be invoked,
The object execution environment unit includes a class policy repository that stores a plurality of class policies including method information and a plurality of processing conditions that define conditions for processing a plurality of requests including the method information collectively.
The server receives a request transmitted from the object execution environment unit, searches the class policy repository, identifies a class policy including the same method information as the received request, and is included in the identified class policy A request queue management unit that acquires a plurality of processing conditions, a request queue table that accumulates requests received by the request queue management unit, and stores a time when the request is received as a registration time, and the request queue management unit first Riku method information included in the received request, the method calls the table in association with the multi-processing condition acquired by the request queue management unit, a request stored in the request queue table by Obtained as strike, to invoke methods specified by the method information included in the first request, the processing result of the method, as well as back to the client that originated the first request, the first A request that includes the same method information as the request and that satisfies the multiple processing conditions stored in the method call table in association with the method information is detected as a second request from the request queue table, and the processing the results, by replying to the client that originated the second request, and a request dispatcher for processing together multiple request including a said first request and the second request,
A method invocation method, wherein the request queue table deletes a plurality of requests processed together by the request dispatch unit. 上記複数処理条件は、上記オブジェクト実行環境部から発信されたリクエストが上記リクエストキュー管理部により受信されてから当該リクエストが処理されるまでの限界の時間を示す限界時間を含み、
上記リクエストディスパッチ部は、上記第１のリクエストと同じメソッド情報を含み且つ登録時間から上記限界時間が経過しているリクエストを上記リクエストキューテーブルから検出することを特徴とする請求項３記載のメソッド起動方式。The multiple processing conditions include a limit time indicating a limit time from when a request transmitted from the object execution environment unit is received by the request queue management unit to when the request is processed,
4. The method invocation according to claim 3, wherein the request dispatch unit detects from the request queue table a request that includes the same method information as the first request and whose limit time has elapsed from a registration time. method. 上記メソッド起動方式は、さらに、上記クラスポリシィを入力するクラスポリシィ入力インタフェースを備え、
上記オブジェクト実行環境部は、入力されたクラスポリシィを受信し、受信したクラスポリシィを上記クラスポリシィリポジトリへ書き込むクラスポリシィ管理部を備えたことを特徴とする請求項１から４のいずれか記載のメソッド起動方式。The method invocation method further includes a class policy input interface for inputting the class policy.
5. The method according to claim 1, wherein the object execution environment unit includes a class policy management unit that receives an input class policy and writes the received class policy to the class policy repository. Startup method. 上記メソッド情報は、メソッドの処理内容を特定するメソッド種別と上記クライアントがメソッドに受け渡すパラメータとを含むことを特徴とする請求項１から４のいずれか記載のメソッド起動方式。  5. The method invocation method according to claim 1, wherein the method information includes a method type for specifying a processing content of the method and a parameter passed to the method by the client. 上記リクエストディスパッチ部は、上記複数のリクエストの内、上記リクエストキュー管理部により最後に受信されたリクエストに含まれるメソッド情報に含まれるパラメータを使用してメソッドを起動することを特徴とする請求項６記載のメソッド起動方式。  The said request dispatch part starts a method using the parameter contained in the method information contained in the request last received by the said request queue management part among the said some requests, The request | requirement is characterized by the above-mentioned. The method invocation method described. 上記リクエストディスパッチ部は、上記リクエストキューテーブルに蓄積されたリクエストを、上記リクエストキュー管理部が当該リクエストを受信した順番に取得することを特徴とする請求項１から４のいずれか記載のメソッド起動方式。  5. The method invocation method according to claim 1, wherein the request dispatch unit acquires the requests accumulated in the request queue table in an order in which the request queue management unit receives the requests. . 上記リクエストディスパッチ部は、上記リクエストキューテーブルに蓄積されたリクエストの内、同じメソッド情報を含み且つリクエスト蓄積状況が上記メソッド呼び出しテーブルに当該リクエスト蓄積状況と対応付けて記憶された複数処理条件を満たしているリクエストを検索して、検索したリクエストを上記第１のリクエストとして取得することを特徴とする請求項１記載のメソッド起動方式。The request dispatch unit includes the same method information among the requests accumulated in the request queue table, and the request accumulation status satisfies a plurality of processing conditions stored in the method call table in association with the request accumulation status. The method invocation method according to claim 1, wherein a request that has been found is retrieved, and the retrieved request is acquired as the first request . 上記オブジェクト実行環境部は、さらに、クラスポリシィ入力インタフェースから入力されたクラスポリシィを上記クラスポリシィ管理部から受信し、受信したクラスポリシィに含まれる複数処理条件を更新情報として上記サーバのリクエストキュー管理部に配信するクラスポリシィ更新情報配信部を備え、
上記リクエストキュー管理部は、上記クラスポリシィ更新情報配信部から配信された複数処理条件を受信し、受信した複数処理条件により上記メソッド呼び出しテーブルに記憶された複数処理条件を書き換えることを特徴とする請求項５記載のメソッド起動方式。The object execution environment unit further receives the class policy input from the class policy input interface from the class policy management unit, and uses the multiple processing conditions included in the received class policy as update information for the request queue management unit of the server. A class policy update information distribution unit that distributes to
The request queue management unit receives the multiple processing conditions distributed from the class policy update information distribution unit, and rewrites the multiple processing conditions stored in the method call table according to the received multiple processing conditions. Item 5. The method activation method according to Item 5. 上記複数処理条件は、上記リクエストディスパッチ部が上記複数のリクエストをまとめて処理する場合のリクエスト蓄積状況の下限値を定める最小蓄積数を含み、
上記リクエストキュー管理部は、上記メソッド呼び出しテーブルを検索して、リクエスト蓄積状況が上記最小蓄積数以上になったリクエストを検出し、検出したリクエストを上記リクエストディスパッチ部へ通知し、
上記リクエストディスパッチ部は、上記リクエストキュー管理部から通知を受けたリクエストを取得することを特徴とする請求項１記載のメソッド起動方式。The plurality of processing conditions include a minimum accumulation number that defines a lower limit value of a request accumulation situation when the request dispatch unit processes the plurality of requests collectively,
The request queue management unit searches the method call table, detects a request having a request accumulation state equal to or greater than the minimum accumulation number, notifies the request dispatch unit of the detected request,
The method invocation method according to claim 1, wherein the request dispatch unit acquires a request notified from the request queue management unit. 上記メソッド起動方式は、複数のサーバを備え、
上記リクエストディスパッチ部は、起動したメソッドの処理結果を記憶し、
上記サーバは、さらに、自己が起動するメソッドとメソッド情報が同じメソッドを起動する他のサーバを比較して検索し、検索したサーバへ上記リクエストディスパッチ部が記憶した処理結果を配信するリクエスト比較部を備えたことを特徴とする請求項１から４のいずれか記載のメソッド起動方式。The method activation method includes a plurality of servers,
The request dispatch unit stores the processing result of the activated method,
The server further includes a request comparison unit that searches and compares other methods that start a method that is the same as the method that is started by itself and that distributes the processing result stored by the request dispatch unit to the searched server. 5. The method invocation method according to claim 1, further comprising a method invocation method.
JP33142499A 1999-11-22 1999-11-22 Method invocation method Expired - Fee Related JP3768748B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP33142499A JP3768748B2 (en) 1999-11-22 1999-11-22 Method invocation method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP33142499A JP3768748B2 (en) 1999-11-22 1999-11-22 Method invocation method

Publications (2)

Publication Number Publication Date
JP2001147811A JP2001147811A (en) 2001-05-29
JP3768748B2 true JP3768748B2 (en) 2006-04-19

Family

ID=18243523

Family Applications (1)

Application Number Title Priority Date Filing Date
JP33142499A Expired - Fee Related JP3768748B2 (en) 1999-11-22 1999-11-22 Method invocation method

Country Status (1)

Country Link
JP (1) JP3768748B2 (en)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6024115B2 (en) * 2012-02-17 2016-11-09 日本電気株式会社 Request management apparatus, request management method, and request management program

Also Published As

Publication number Publication date
JP2001147811A (en) 2001-05-29

Similar Documents

Publication Publication Date Title
US9369521B2 (en) Naming of distributed business transactions
US11429448B2 (en) Background job processing framework
US20060117059A1 (en) System and method for monitoring and managing performance and availability data from multiple data providers using a plurality of executable decision trees to consolidate, correlate, and diagnose said data
WO2021238796A1 (en) Asynchronous processing method, apparatus, and system for download tasks, and storage medium
JP2007148738A (en) Information monitoring method, system, and program
JPH11353196A (en) Governor for time-scheduled process management
US20090328040A1 (en) Determining Real Time Stateful Business Application Processing In An Otherwise Stateless Service-Oriented Architecture
US20020091695A1 (en) Remote computation framework
KR100754198B1 (en) Method for automatic software update and system thereof
US6959264B2 (en) Autonomous computing probe agent
JP2002324155A (en) Workflow system and program
JP2001092709A (en) Client server system, object pool, method for pooling object, storage medium and program transmitting device
CN115617527A (en) Management method, configuration method, management device and configuration device of thread pool
CN111913784A (en) Task scheduling method and device, network element and storage medium
CN113157426A (en) Task scheduling method, system, equipment and storage medium
JP3768748B2 (en) Method invocation method
CN110162381B (en) Agent execution method in container
US9792419B2 (en) Starvationless kernel-aware distributed scheduling of software licenses
US6938251B1 (en) Deferred-Synchronous messaging software in a non-threaded environment
CN114462388A (en) Handle management or communication method, electronic device, storage medium, and program product
CN111163117B (en) Zookeeper-based peer-to-peer scheduling method and device
US7971206B2 (en) Protocol for message delivery among independently evolving processes
WO2024139011A1 (en) Information processing method
JP3741818B2 (en) Information distribution response system with many computers participating
CN117251264A (en) Task scheduling system

Legal Events

Date Code Title Description
RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20040514

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20041018

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20050927

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20051110

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20051206

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20060111

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: 20060131

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20060202

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: 20100210

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20100210

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110210

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120210

Year of fee payment: 6

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130210

Year of fee payment: 7

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130210

Year of fee payment: 7

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140210

Year of fee payment: 8

LAPS Cancellation because of no payment of annual fees