(57)【特許請求の範囲】
【請求項１】
分散オブジェクトを利用したクライアントサーバーシステムであって、
通信ネットワークに接続され、オブジェクトに対するアクセス要求を行うクライアントと、
前記クライアントのアクセス要求に基づいて前記オブジェクトによりアプリケーションを実行するアプリケーションサーバーと、
前記クライアントと前記通信ネットワークを介して接続されると共に前記アプリケーションサーバーと接続され、前記オブジェクトの代理オブジェクトであるプロキシーオブジェクトをプーリングし、当該クライアントからのリクエストに応じてプーリングされている前記プロキシーオブジェクトの割り当てを行い、かつ当該アプリケーションサーバーにおける当該オブジェクトの情報であるオブジェクト管理情報を保持するオブジェクトプールサーバーとを備え、
前記アプリケーションサーバーは、前記アプリケーションの状態を管理すると共にその状態変化に応じて前記オブジェクトプールサーバーに対してイベントを通知し、
前記オブジェクトプールサーバーは、当該アプリケーションサーバーからの当該イベントの通知に基づいて前記オブジェクト管理情報を自動更新し、かつ当該オブジェクト管理情報に基づいて使用可能と判断されるプロキシーオブジェクトを前記クライアントに割り当てることを特徴とするクライアントサーバーシステム。
【請求項２】
前記アプリケーションサーバーから通知されるイベントは、前記アプリケーションの実行単位であるプロジェクトの開始処理の結果及びプロジェクトの停止処理の結果の少なくとも１つの結果に基づいて形成されることを特徴とする請求項１記載のクライアントサーバーシステム。
【請求項３】
分散オブジェクトを用いたクライアントサーバーシステムであって、
オブジェクトに対するアクセス要求を出すクライアントと通信ネットワークを介して接続され、オブジェクトをプールすると共にオブジェクト情報を管理するオブジェクトプールと、
前記オブジェクトプールに接続され前記クライアントのアクセス要求に基づいてアプリケーションを実行し、かつ当該アプリケーションの状態を管理すると共にその状態変化に合わせて前記オブジェクトプールに対してイベントを通知するアプリケーション実行環境とを備え、
前記オブジェクトプールは、前記アプリケーション実行環境からのイベント通知に基づいて前記オブジェクト情報を更新し、かつ前記クライアントからのアクセス要求に応じて前記オブジェクトを当該クライアントに割り当てる際に、当該オブジェクト情報に基づき使用可能と判断されるオブジェクトを割り当てることを特徴とするクライアントサーバーシステム。
【請求項４】
前記オブジェクトプールの機能を有するオブジェクトプールサーバーと、前記アプリケーション実行環境にあるアプリケーションサーバーとがネット等を介して接続されると共に、当該オブジェクトプールサーバーは当該アプリケーションサーバーで実行されるオブジェクトの代理オブジェクトであるプロキシーオブジェクトをプールすることを特徴とする請求項３記載のクライアントサーバーシステム。
【請求項５】
前記オブジェクトプールと前記アプリケーション実行環境とは同一のサーバーにて形成されることを特徴とする請求項３記載のクライアントサーバーシステム。
【請求項６】
前記オブジェクトプールは、
前記オブジェクトプールの終了処理時に前記オブジェクト情報を格納するオブジェクト情報記憶部と、
前記オブジェクトプールの開始処理時に前記クライアントからのアクセス要求を待つことなく前記オブジェクト情報記憶部により格納された前記オブジェクト情報に基づいてオブジェクトを生成するオブジェクト生成処理部と、
前記オブジェクト生成処理部により生成されたオブジェクトをプールするオブジェクト管理部とを備えることを特徴とする請求項３記載のクライアントサーバーシステム。
【請求項７】
前記オブジェクト情報記憶部により格納されるオブジェクト情報は、少なくとも前記オブジェクトプールの終了処理の実行前において最後にアクセスされたオブジェクトであることを認識できるように構成され、
前記オブジェクト生成処理部は、最後にアクセスされた前記オブジェクトから生成を開始することを特徴とする請求項６記載のクライアントサーバーシステム。
【請求項８】
オブジェクトに対するアクセス要求を出すクライアントと通信ネットワークを介して接続されると共に、当該オブジェクトを実行するアプリケーション実行環境と接続される、オブジェクトプールにおけるオブジェクトのプール方法であって、
前記アプリケーション実行環境における前記オブジェクトの代理オブジェクトであるプロキシーオブジェクトをプールするステップと、
前記アプリケーション実行環境からの通知に基づいて当該アプリケーション実行環境における前記オブジェクトの状態変化を認識するステップと、
認識された前記状態変化に基づいて前記オブジェクトの管理情報を更新するステップと、
クライアントからのリクエストに応じて前記オブジェクトを当該クライアントに割り当てる場合に、前記管理情報に基づき使用可能と判断される前記オブジェクトを割り当てるステップと
を備えたことを特徴とするオブジェクトのプール方法。
【請求項９】
前記オブジェクトをプールするプロセスの終了処理時に、前記管理情報の内、少なくとも当該オブジェクトのクラスおよび当該オブジェクトを実行するサーバー並びにアプリケーションの情報を含むオブジェクト情報を記憶装置に格納するステップと、
前記サーバーにおけるオブジェクトをプールするプロセスの開始処理時に前記クライアントからのリクエストを待つことなく前記記憶装置に格納された前記オブジェクト情報に基づいてオブジェクトを生成するステップと、
生成されたオブジェクトをプールするステップと
をさらに含むことを特徴とする請求項８に記載のオブジェクトのプール方法。
【請求項１０】
前記オブジェクト情報は所定の優先順位を付して格納され、
前記オブジェクトは前記優先順位の高いものから順に生成されることを特徴とする請求項９記載のオブジェクトのプール方法。
【請求項１１】
分散オブジェクトを利用したアプリケーションを実行するアプリケーションサーバーと、当該アプリケーションの実行を要求するクライアントとに対してネット等を介して接続するコンピュータに実行させるプログラムを当該コンピュータの入力手段が読み取り可能に記憶した記憶媒体において、
前記プログラムは、
前記アプリケーションサーバーが実行するオブジェクトの代理オブジェクトであるプロキシーオブジェクトをプールするオブジェクトプール処理と、
前記アプリケーションサーバーから発行される前記オブジェクトの状態変化を通知するイベントを受信すると共に、当該イベントに基づいて前記オブジェクトの管理情報を更新する更新処理と、
クライアントからのリクエストに応じて前記プロキシーオブジェクトを当該クライアントに割り当てる場合に、前記管理情報に基づき使用可能と判断される前記プロキシーオブジェクトを割り当てる処理と
を前記コンピュータに実行させることを特徴とする記憶媒体。
【請求項１２】
前記オブジェクトをプールするプロセスの終了処理時に、前記管理情報の内、少なくとも当該オブジェクトのクラスおよび当該オブジェクトを実行するサーバー並びにアプリケーションの情報を含むオブジェクト情報を記憶装置に格納する処理と、
前記サーバーにおけるオブジェクトをプールするプロセスの開始処理時に前記クライアントからのリクエストを待つことなく前記記憶装置に格納された前記オブジェクト情報に基づいてオブジェクトを生成する処理と、
生成されたオブジェクトをプールする処理と
をさらに前記コンピュータに実行させることを特徴とする請求項１１に記載の記憶媒体。
【請求項１３】
前記オブジェクト情報は所定の優先順位を付して格納され、
前記オブジェクトは前記優先順位の高いものから順に生成されることを特徴とする請求項１２記載の記憶媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、分散オブジェクトを使用したアプリケーションを実行するクライアントサーバーシステムに関する。
【０００２】
【従来の技術】
近年、ウェブ(Ｗｅｂ)ブラウザをベースとしたアプリケーション形態が急速に増加しており、分散オブジェクトの利用方法が大きく変わってきている。具体的には、以前はクライアントから直接、サーバー上のオブジェクトを生成する方法が主体であったが、現在は、Ｗｅｂサーバー若しくはＷｅｂアプリケーションサーバー上で分散オブジェクト技術を利用して、他のサーバー上のオブジェクトを生成するアプリケーションモデルが普及してきている。実際の実装例としては、マイクロソフト社のASPとMTSとの組合せや、出願人(ＩＢＭ社)のWebSphereとComponentBrokerの組み合わせが挙げられる。
【０００３】
ここで、分散オブジェクトとは、データ、アプリケーション、プロセスなどを部品化したものであり、これらのオブジェクトは場所に関係なく、ネットワークのどこからでもアクセスでき、業務に使用することが可能である。より詳細には、オブジェクト指向におけるメソッド呼び出しを遠隔化できるようにしたものであり、ソケットレベルの上位層にオブジェクト指向的なプログラミングインターフェイスを実現するミドルウェアとして構築されたものである。この分散オブジェクトのプログラミング技術では、離れたマシンにあるオブジェクトがまるで蜃気楼のように自マシンに現れ、それを操作することで遠くにあるオブジェクトを自由に操作することができる。この分散オブジェクトでは、蜃気楼のように現れるオブジェクトをプロキシーオブジェクト(代理オブジェクト)と呼び、離れたマシンにあるオブジェクト(実オブジェクト：リモートオブジェクト)と見かけ上は同じであるが、本物ではなく代理として存在させており、クライアントから最初にアクセスするポイントは、実際のサーバーではなくＷｅｂサーバーとなる形態である。
【０００４】
この分散オブジェクト環境を使用した場合に、ソフトウェア的に最もコストがかかるのはオブジェクトの作成処理である。実際に分散オブジェクトのリモートオブジェクトの生成処理は、他の処理に比べて時間がかかることが知られており、オブジェクト作成時の処理をいかに早くするかが全体のレスポンスタイムを短くする鍵となる。このとき、特開平１０-１１３３９号公報に記載されているようなデータベース管理システムにおけるオブジェクトプーリング技術を転用し、クライアントからのアクセス前に予めオブジェクトを作成しておき、クライアントからオブジェクトの作成要求があったときに、そのプールされたところからオブジェクトを渡すことができれば、結果としてレスポンスタイムの短縮を図ることが可能となる。
【０００５】
【発明が解決しようとする課題】
しかしながら、上記公報に記載されているような既存技術のプーリングは、クライアントからのリクエストを受け、利用し終わったものをプールするメカニズムであるため、サーバー起動時にはプーリングメカニズムが有効とはならず、決められたレスポンスタイムを実現することは困難である。また、既存技術のようなクライアントから来るであろう要求が明確であるデータベースシステムでは、初期化の際に単純に予め決められたオブジェクトを生成することが可能であるが、データベースのような決まりきったオブジェクトではなく、分散オブジェクトのような実行時でないと作られるオブジェクトが解らないような環境下では、既存のプーリングメカニズムを実装するだけでは充分な効果を得ることができない。
【０００６】
また、通常のオブジェクトプールでは、生成されたオブジェクトに対する開放要求でプーリングし、次に同一クラスに対する生成要求によりプール中にあるオブジェクトをクライアントに割り当てるように構成することでパフォーマンスの向上を企図しているが、必ずしも有効なオブジェクトが常にプールされているとは限らない。特に分散オブジェクトを利用したアプリケーションにてプロキシーオブジェクトのプーリングを行う場合には、クライアントからのオブジェクト生成要求に対して、実際のサーバー上では既に無効になってしまったプロキシーオブジェクトを割り当ててしまう可能性がある。かかる不整合が生じた場合には、例えばクライアントが無効になってしまったオブジェクトを使用するとエラーが発生してしまい、オブジェクトプールの意味が無くなる。オブジェクト毎に有効期限を設定し、一定期間使用されなかったオブジェクトを自動的に削除することでオブジェクトの有効性を維持する方法も考えられるが、この機能だけでは実際に有効なオブジェクトもプールから削除される危険性が残る。
【０００７】
この問題点を考慮して、オブジェクトを開放する際にある特定のメソッドを呼び出し、このメソッドの中でユーザーが実装したロジックに基づいて、そのオブジェクトをプールできるか否かを制御できる機能を提供するオブジェクトプールの実装形態もある。この方法は、ユーザーが自由にオブジェクトの動きを制御できる点で柔軟性に富んでいる。しかしながら、一方で、ユーザー自身に対してプログラム作成を強いることとなりユーザーの負担が大きくなると共に、常にそのロジックを通ることとなり処理量が増してしまう。また、このようにオブジェクトの実装としてプール使用時の振る舞いを埋め込む方法では、アプリケーション起動時などのオブジェクトが存在しない期間の動作を制御することが困難となる。
【０００８】
本発明は以上のような技術的課題を解決するためになされたものであって、サーバーの起動後、クライアントから最初にオブジェクトの生成要求があったときの応答時間を短縮することを目的とする。
更に、アプリケーションとオブジェクトプールとの同期を取ることにより、オブジェクトプールの有用性を向上させることを他の目的とする。
【０００９】
【課題を解決するための手段】
かかる目的のもと、本発明は、分散オブジェクトを利用したクライアントサーバーシステムであって、通信ネットワークに接続され、オブジェクトに対するアクセス要求を行うクライアントと、このクライアントのアクセス要求に基づいて実オブジェクトによりアプリケーションを実行するアプリケーションサーバーと、クライアントと通信ネットワークを介して接続されると共にこのアプリケーションサーバーと接続され、実オブジェクトに対応するプロキシーオブジェクトをプーリングすると共に、実オブジェクトの情報である実オブジェクト管理情報を保持するオブジェクトプールサーバーとを備え、このアプリケーションサーバーはアプリケーションの状態変化に応じてオブジェクトプールサーバーに対してイベントを通知すると共に、オブジェクトプールサーバーはアプリケーションサーバーからのイベントの通知に基づいて実オブジェクト管理情報を自動更新することを特徴としている。
【００１０】
このアプリケーションサーバーから通知されるイベントは、プロジェクトの開始処理の結果及びプロジェクトの停止処理の結果の少なくとも１つの結果に基づいて形成されることを特徴とすれば、実際には使用不可能なオブジェクトをクライアントに割り当ててしまう危険性を排除することができる点からも好ましい。このプロジェクトの停止処理は、アプリケーションサーバーのユーザーによるプロジェクトの停止要求に係わるものの他、プロジェクトの異常終了による停止処理をも含むものである。
また、このアプリケーションサーバーとオブジェクトプールサーバーとは必ずしも異なった筐体である必要はなく、同一の筐体に属するものであっても構わない。
【００１１】
また、本発明は、分散オブジェクトを用いたオブジェクトプールであって、オブジェクトに対するアクセス要求を解析するクライアント要求解析部と、オブジェクトプールの終了処理時にオブジェクト情報を格納するオブジェクト情報記憶部と、オブジェクトプールの開始処理時にオブジェクト情報記憶部により格納されたオブジェクト情報に基づいてオブジェクトを生成するオブジェクト生成処理部と、このオブジェクト生成処理部により生成されたオブジェクトをクライアントからのオブジェクトのアクセス前にプールするオブジェクト管理部とを備えたことを特徴としている。
【００１２】
このオブジェクト情報記憶部により格納されるオブジェクト情報は、少なくとも最後にアクセスされたオブジェクトであることを認識できるように構成され、このオブジェクト生成処理部は、最後にアクセスされたオブジェクトから生成を開始することを特徴とすれば、最終アクセスがなされたオブジェクトは再度、利用される可能性が高いことから、オブジェクトプールとして特に効果的である。ここで、このオブジェクト情報として、優先順位が付与されるように構成すれば、動的にオブジェクトをプールすることができる点で好ましい。この優先順位としては、最終アクセス時間の他、アクセス回数(頻度)等、実装の形態によって任意に選択することが可能である。
【００１３】
また、本発明の分散オブジェクトを用いたクライアントサーバーシステムは、オブジェクトに対するアクセス要求を出すクライアントと通信ネットワークを介して接続され、オブジェクトをプールすると共にオブジェクト情報を管理するオブジェクトプールと、このオブジェクトプールに接続されクライアントのアクセス要求に基づいてアプリケーションを実行すると共に、アプリケーションの状態変化に合わせてオブジェクトプールに対してイベントを通知するアプリケーション実行環境とを備え、オブジェクトプールは、このアプリケーション実行環境からのイベント通知に基づいてオブジェクト情報を更新することを特徴としている。
【００１４】
ここで、オブジェクトプールの機能を有するオブジェクトプールサーバーと、アプリケーション実行環境にあるアプリケーションサーバーとがネット等を介して接続されると共に、このオブジェクトプールサーバーはプロキシーオブジェクトとしてのオブジェクトをプールすることを特徴とすることもできる。
また、オブジェクトプールとアプリケーション実行環境とは同一のサーバーにて形成されることを特徴とすることも可能である。
【００１５】
また、本発明は、分散システムにおけるアプリケーションの実行のために特定のサーバーにて予めオブジェクトをプールするオブジェクトのプール方法であって、サーバーにおけるプロセスの終了処理時にオブジェクト情報を格納するステップと、このサーバーにおけるプロセスの開始処理時にオブジェクト情報に基づいてオブジェクトを生成するステップと、生成されたオブジェクトをプールするステップとを含むことを特徴としている。
【００１６】
ここで、オブジェクト情報は所定の優先順位を付して格納されると共に、オブジェクトは優先順位の高いものから順に生成されることを特徴とすれば、お客様のレスポンスタイムに対する一定した要求を満たすことが可能となる点で好ましい。
この優先順位の用い方としては、例えば管理している空きオブジェクトの数が最大プール数に達していたら優先順位の最も低いオブジェクトをプールから外し、実際に削除する等に用いることが可能である。また、サーバープロセスの開始処理時に終了時に保存したデータから優先順位の高い順に、初期プール数に達するまでオブジェクトを生成するように構成すれば、クライアントが使用するであろうオブジェクトの決定を動的に行うことが可能となり、クライアントの要求に対する応答時間の短縮を図ることができる点で優れている。
【００１７】
また、本発明は、オブジェクトに対するアクセス要求を出すクライアントと通信ネットワークを介して接続されると共に、実オブジェクトを実行するアプリケーション実行環境と接続される、クライアントサーバーシステムにおけるオブジェクトのプール方法であって、このアプリケーション実行環境における実オブジェクトに対応するプロキシーオブジェクトをプールするステップと、実オブジェクトの管理情報を記憶するステップと、アプリケーション実行環境における実オブジェクトの状態変化を認識するステップと、この認識された状態変化に基づいて記憶されている実オブジェクトの管理情報を更新するステップとを備えたことを特徴としている。特にこの状態変化を非同期のシグナルであるイベントにより認識できるように構成すれば、最小限のコストでサーバー上のアプリケーションとオブジェクトプール内のオブジェクトとの同期を取ることが可能となる点で好ましい。
【００１８】
また、本発明は、コンピュータに実行させるプログラムをこのコンピュータの入力手段が読取可能に記憶した記憶媒体において、このプログラムは、分散オブジェクトを利用したアプリケーションを実行するプロジェクトの実行状態を監視する監視処理と、この監視処理により監視されたプロジェクトの実行状態に基づいてイベントを生成するイベント生成処理と、このイベント生成処理によって生成されたイベントを発行するイベント発行処理とをこのコンピュータに実行させることを特徴としている。
ここで、このイベント発行処理は、ネット等を介して接続されたオブジェクトプールサーバに対してイベントを発行することを特徴とすれば、例えばアプリケーションを実行するアプリケーションサーバーにてこの記憶媒体を用いて一連の処理を入力することが可能となり、最小限のコストでサーバー上のアプリケーションとオブジェクトプール内のオブジェクトとの同期を取ることを可能とする点で優れている。尚、記憶媒体としてはＣＤ-ＲＯＭやフロッピーディスク等、その種類が問われることはなく、そのソフトウエアが販売される媒体としての記憶媒体を含むものである。
【００１９】
また、本発明は、分散オブジェクトを利用したアプリケーションを実行するアプリケーションサーバーと、アプリケーションの実行を要求するクライアントとに対してネット等を介して接続するコンピュータに実行させるプログラムをコンピュータの入力手段が読取可能に記憶した記憶媒体において、このプログラムは、アプリケーションサーバーが実行する実オブジェクトに対応するプロキシーオブジェクトをプールするオブジェクトプール処理と、アプリケーションサーバーから発行されるイベントを受信すると共に、このイベントに基づいて実オブジェクトの管理情報を更新する更新処理とをコンピュータに実行させることを特徴としており、オブジェクトプールサーバーに対してこのソフトウエアを容易に実行させることが可能となる点で優れている。
更に、このオブジェクトの実行状態を把握してオブジェクト毎に管理する実行状態管理処理と、このクライアントからのオブジェクト生成要求および/またはオブジェクト削除要求を含むリクエストを解析するリクエスト解析処理と、このリクエスト解析処理によるリクエストの解析結果を受け、実行状態管理処理による管理結果に基づいてオブジェクトの生成および/またはオブジェクトの削除を実行する処理とを更にコンピュータに実行させることを特徴とすれば、アプリケーションサーバー上で実行されるアプリケーションの状態変化を適切に把え、プール内のオブジェクトを自動的に更新することが可能となる点で好ましい。尚、記憶媒体の種類を問わない点は前述と同様である。
【００２０】
また、本発明をプログラム伝送装置に適用すると、コンピュータに、分散オブジェクトを利用したアプリケーションの状態変化に応じてイベントを形成するイベント形成処理プログラムと、このイベント形成処理により形成されたイベントに基づいてオブジェクトをプールするオブジェクトプール処理プログラムとを実行させるソフトウェアプロダクトを記憶する記憶手段と、この記憶手段からプログラムを読み出してこのソフトウエアプロダクトを送信する送信手段とを備えたことを特徴としている。
また、本発明のプログラム伝送装置は、コンピュータに、分散オブジェクトを利用したアプリケーションの実行に伴うオブジェクトをサーバーにてプールするオブジェクトプール処理と、サーバーにおいてオブジェクト情報を格納する情報格納処理と、この情報格納処理により格納されたオブジェクト情報に基づいて生成するオブジェクトの順序を決定する生成順序決定処理を実行するプログラムを記憶する記憶手段と、この記憶手段からプログラムを読み出してプログラムを送信する送信手段とを備えたことを特徴としている。このようなプログラム伝送装置により、プログラムの提供形態としてＣＤ-ＲＯＭ等の記憶媒体を介すことなく、お客様に対して本発明の技術を提供することが可能となる。
【００２１】
【発明の実施の形態】
［実施の形態１］
以下、添付図面に示す実施の形態に基づいてこの発明を詳細に説明する。
図１は、本実施の形態におけるクライアントサーバーシステムの全体構成を説明するための図である。同図において、符号１１はクライアントであり、オブジェクトの生成要求や削除要求等の各種リクエストを出しており、クライアントプログラムはオブジェクトへのメソッドの呼び出しを行うという形でサービスの実行を要求している。また、符号２０はアプリケーション実行環境としてのアプリケーションサーバーである。また、符号３０はオブジェクトプールであり、広域ネットワークであるＷＡＮ（Wide Area Network）や構内ネットワークであるＬＡＮ（Local Area Network）によってクライアント１１と接続され、更にアプリケーションサーバー２０と接続されている。ここで、アプリケーションサーバー２０には実オブジェクト１６が、オブジェクトプール３０にはこの実オブジェクト１６に対する代理オブジェクトとしてのプロキシーオブジェクト１７が存在するように構成されている。
【００２２】
図２は、アプリケーション実行環境であるアプリケーションサーバー２０の機能ブロックを説明するための図である。同図に示すプロジェクトは、一まとまりのアプリケーションの実行単位であり、単数または複数のオブジェクトによってアプリケーションが実行できるように構成されている。符号２１はプロジェクトの実行状況に応じてイベントを作成すると共にオブジェクトプール３０のイベント処理部３１(後述)に対してイベントを発行するイベント生成部、２２はアプリケーションサーバー２０のオペレータであるユーザーからのリクエスト内容を解析するユーザー入力処理部である。ここで、このイベントとは、イベントのサプライヤがある特定の事象をイベントのコンシューマに伝えるための非同期のシグナルのことである。また、２３はユーザー入力処理部２２の要求によってプロジェクトの起動を開始するプロジェクト開始処理部、２４はプロジェクトの終了処理を実行するプロジェクト停止処理部である。更に、２５はプロジェクトの実行を監視すると共にイベント生成部２１に対してイベント作成を依頼するプロジェクト実行監視部である。また、２６はプロジェクトの前処理や後処理を実行し、各プロジェクト間を全体として制御するプロジェクト実行制御部である。
【００２３】
図３は、イベント生成部２１において生成されるイベント通知管理テーブルを示すものである。このイベント通知管理テーブルは、オブジェクトプール３０のＩＤであるオブジェクトプールＩＤと、その名称であるホスト名、およびイベントフィルタの対応付けが可能となるテーブルを構成している。このイベントフィルタは、アプリケーションにおいてどのような状態変化が生じたときにどのオブジェクトプール３０に対してイベントを発行するか、を示すものであり、例えば「Ａｌｌ」であれば全ての状態変化が生じたときにイベントを発行し、「Ｏｎｌｙ  Ｅｒｒｏｒ」であればエラー状態のときに、また、「Ｗａｒｎｉｎｇ」であれば予期しない警告状態のときにイベントを発行するように管理される。このイベント管理テーブルに登録された情報に基づいて、イベント生成部２１は、所定の状態変化時に所定のオブジェクトプール３０に対してイベントを発行している。
【００２４】
図４は、プロジェクト実行監視部２５において更新されるプロジェクト実行監視テーブルを示すものである。このプロジェクト実行監視テーブルは、アプリケーションサーバー２０にて実行されるプロジェクトのＩＤであるプロジェクトＩＤとその名称であるプロジェクト名、およびそのプロジェクトにおける実行状態を対応付けしたテーブルである。このプロジェクト実行監視テーブルは、プロジェクト開始処理部２３からのプロジェクトの開始処理の結果に基づいて更新されると共に、この更新されたプロジェクト実行監視テーブルに基づいてイベント生成部２１によるイベントの発行が可能となるように構成されている。
【００２５】
図５は、オブジェクトプール３０の機能ブロックを説明するための図である。同図において、符号３１はイベント処理部、３２はオブジェクト管理部であり、イベント処理部３１は、アプリケーションサーバー２０のイベント生成部２１から通知されたイベントに基づき、オブジェクト管理部３２に対してオブジェクト実行状態の変更を通知している。また、３３は活動中オブジェクト管理部であり、既にクライアント１１に割り当てられているオブジェクトを管理している。更に、３４は空きオブジェクト管理部であり、未だクライアント１１に割り当てられていないオブジェクトを管理している。また、３５はハードディスク等からなるオブジェクト情報記憶部であり、例えばオブジェクトプール３０の終了時にオブジェクト情報を読み取って記憶している。また、３６は開始処理部、３７は終了処理部であり、それぞれ、オブジェクトプール３０の開始時(イニシャル時)や終了時にオブジェクト情報記憶部３５からのオブジェクト情報の読み取りや格納を実施している。
【００２６】
また、図５において、符号４１はクライアント１１からのリクエストの内容を解析するクライアント要求解析部、４２はクライアント要求解析部４１からの依頼に基づいてオブジェクト管理部３２に対してオブジェクトの取得要求を行うオブジェクト生成処理部である。また、４３はメソッドコール処理部であり、クライアント１１からメソッドコール処理要求があった場合にクライアント要求解析部４１からの依頼に基づいてオブジェクト管理部３２に対して処理要求のあったオブジェクトを請求している。更に、４４はクライアント要求解析部４１からの依頼に基づいてオブジェクト管理部３２に対してオブジェクトの削除要求を行うオブジェクト削除処理部である。クライアント要求解析部４１が受けるクライアント１１からのリクエストは、例えば、特定のクライアント１１がＷｅｂのホームページを開いた時点、即ちホームページをダウンロードした時点で、所定のプログラムが呼び込まれ、オブジェクトの生成要求が発行されてＷｅｂページ上に例えばアプレット(Applet)が動作した後、サーバー上のオブジェクトプール３０に対してオブジェクトの生成要求をするように構成することができる。このクライアント１１からのリクエストは、実装の仕方によって変わるもので、例えば後述する図２２に示すオーダーフォーム(Order Form)の画面上にオブジェクト生成ボタンを設けるような形態にて実装することも可能である。
【００２７】
図６は、活動中オブジェクト管理部３３において用いられる活動中オブジェクト管理テーブルを示すものである。このテーブルにおいて、オブジェクトＩＤはクライアント１１に対して既に割り当てられているオブジェクトのＩＤを示している。また、クラス名はオブジェクトの機能や性質を定義する所謂クラスをオブジェクト毎に示したものである。また、サーバー名はオブジェクトが実行されるアプリケーションサーバー２０をオブジェクト単位で管理するものであり、プロジェクト名は一まとまりのアプリケーションの実行単位であるプロジェクトを対応付けして管理している。また、実行状態の項目は、クライアントに割り当てられた後のオブジェクトの実行状態を管理するものであり、イベント処理部３１より通知されたプロジェクトに属するオブジェクトを、オブジェクト管理部３２が選択し、更新した内容が登録される。
【００２８】
図７は、空きオブジェクト管理部３４にて用いられる空きオブジェクト管理テーブルを示すものであり、オブジェクトは作成されているがどのクライアントも使用していないオブジェクトがこのテーブルにて管理される。このテーブルにおける優先順位は、オブジェクトの最終アクセス時間などによって決定されるもので、例えば終了処理部３７によるオブジェクトプールの終了処理時に優先順位を付加した状態でオブジェクト情報記憶部３５にオブジェクト情報を保存する際や、オブジェクトプールの開始処理時にその高い順に初期プールする等、分散オブジェクト環境下におけるダイナミックなオブジェクトプール形成に際して重要な項目である。また、この優先順位は、空きオブジェクトの数が最大プール数に達した場合に、その一番低いオブジェクトから削除する等にも用いられる。また、オブジェクトＩＤは作成されてはいるがクライアント１１に割り当てられていないオブジェクトのＩＤを示し、クラス名はそのオブジェクトのクラスを示したものである。また、サーバー名はオブジェクトが実行されるアプリケーションサーバー２０を管理し、プロジェクト名はそのプロジェクトを対応付けして管理している。また、実行状態は、アプリケーションサーバー２０上での実行状態を示している。この実行状態の管理としては、単に停止中だけではなく、回復処理中や一時停止中等の細かな状態管理を実行することも可能である。
【００２９】
図８は、オブジェクトプールの各種情報を管理するためのオブジェクトプールプロパティ管理テーブルを示している。このテーブルでは、プロパティとして最大プール数と初期プール数が管理されており、この値により、プールされているオブジェクトの削除やイニシャル時におけるオブジェクトの作成を動的に制御することが可能となる。
また、図９は、オブジェクト情報記憶部３５に記憶されるプールオブジェクト情報を示すものであり、優先順位と共にオブジェクトのクラス名、実行するアプリケーションサーバー２０のサーバー名、そのサーバーにて行われるプロジェクト名がそれぞれ格納される。この格納された情報に基づいて、開始処理時であるイニシャル時に動的なオブジェクトプール作業が実行される。
本実施の形態では、このように各種テーブル構造によりオブジェクト情報を管理することで、データ・モデルが理解し易く、検索速度を大幅に高速化することが可能となる。
【００３０】
次に、アプリケーション実行環境であるアプリケーションサーバー２０におけるプロジェクトの開始動作について、図１０のフローチャートを用いて説明する。
まず、ユーザー入力処理部２２は、アプリケーションサーバー２０のユーザーにより入力されたリクエストの内容を解析し、プロジェクト開始処理部２３に対してプロジェクトの開始を要求する(ブロック１０１)。この開始要求を受け、プロジェクト開始処理部２３は、プロジェクトの起動を開始すると共に、プロジェクト実行監視部２５に対してプロジェクトが開始処理に入ったことを通知する(ブロック１０２)。この開始処理に入ると、プロジェクト実行監視部２５は、プロジェクトが準備中であることを示すプロジェクト情報を前述のプロジェクト実行監視テーブルに登録すると同時に、イベント生成部２１に対してイベントの生成を依頼する(ブロック１０３)。イベント生成部２１は、前述のイベント通知管理テーブルに登録された情報に基づき、イベント発行を要するオブジェクトプール３０のイベント処理部３１に対して、プロジェクト準備中のイベントを発行する(ブロック１０４)。一方、プロジェクト開始処理部２３は、プロジェクトの開始処理が完了した時点で、その結果をプロジェクト実行監視部２５に通知する(ブロック１０５)。プロジェクト実行監視部２５は、プロジェクト開始処理部２３から受け取ったこのプロジェクトの開始処理の結果をもとに、プロジェクト実行監視テーブルを更新すると共に、イベント生成部２１に対してイベントの作成を依頼する(ブロック１０６)。イベント生成部２１は、イベント通知管理テーブルに登録された情報に基づき、オブジェクトプール３０のイベント処理部３１に対して、プロジェクト実行中(プロジェクトの開始処理が成功した場合)あるいはプロジェクト停止中(プロジェクトの開始処理が不成功の場合)のイベントを発行し(ブロック１０７)、プロジェクトの開始動作が終了する。
【００３１】
次に、アプリケーションサーバー２０におけるプロジェクトの停止動作について、図１１のフローチャートを用いて説明する。
まず、ユーザー入力処理部２２は、アプリケーションサーバー２０のユーザーが入力したリクエストの内容を解析し、プロジェクト停止処理部２４に対して、プロジェクトの停止を要求する(ブロック１１１)。プロジェクト停止処理部２４は、この要求を受けてプロジェクトの停止処理を開始すると共に、プロジェクト実行監視部２５に対して、プロジェクトが停止処理に入ったことを通知する(ブロック１１２)。この通知を受けたプロジェクト実行監視部２５は、前述したプロジェクト実行監視テーブルに登録されているプロジェクトの実行状態を停止処理中に更新すると共に、イベント生成部２１に対してイベントの生成を依頼する(ブロック１１３)。この依頼を受けたイベント生成部２１は、イベント通知管理テーブルに登録された情報に基づき、オブジェクトプール３０のイベント処理部３１に対して、プロジェクト停止処理中のイベントを発行する(ブロック１１４)。プロジェクト停止処理部２４は、プロジェクトの停止処理が完了した時点で、その結果をプロジェクト実行監視部２５に通知する(ブロック１１５)。この通知を受けたプロジェクト実行監視部２５は、プロジェクト実行監視テーブルに登録されているプロジェクトの実行状態を停止中に更新すると共に、イベント生成部２１に対してイベントの作成を依頼する(ブロック１１６)。この依頼を受けたイベント生成部２１は、イベント通知管理テーブルに登録された情報に基づき、オブジェクトプール３０のイベント処理部３１に対してプロジェクト停止中のイベントを発行し(ブロック１１７)、一連の停止動作が終了する。
【００３２】
次に、アプリケーションサーバー２０におけるプロジェクトの異常終了処理動作について、図１２のフローチャートを用いて説明する。
何らかの理由によりプロジェクトの異常終了があったとき、プロジェクト実行監視部２５は、プロジェクトの異常終了を検知し、プロジェクト停止処理部２４に対してプロジェクトの異常終了処理の開始を要求する。同時に、前述したプロジェクト実行監視テーブルに登録されているプロジェクトの実行状態を異常終了処理中に更新すると共に、イベント生成部２１に対してイベントの生成を依頼する(ブロック１２１)。イベント生成部２１は、イベント通知管理テーブルに登録された情報に基づき、オブジェクトプール３０のイベント処理部３１に対して、プロジェクト異常終了処理中のイベントを発行する(ブロック１２２)。一方、プロジェクト停止処理部２４は、プロジェクトの異常終了処理が完了した時点で、その結果をプロジェクト実行監視部２５に通知する(ブロック１２３)。この通知を受けたプロジェクト実行監視部２５は、プロジェクト実行監視テーブルに登録されているプロジェクトの実行状態を停止中に更新すると共に、イベント生成部２１に対してイベントの作成を依頼する(ブロック１２４)。この依頼を受けたイベント生成部２１は、イベント通知管理テーブルに登録された情報に基づき、オブジェクトプール３０のイベント処理部３１に対して、プロジェクト停止中のイベントを発行し(ブロック１２５)、プロジェクトの異常終了処理動作が終了する。
【００３３】
以上のように、アプリケーション実行環境であるアプリケーションサーバー２０にてイベントが形成されるが、このイベントを受けるオブジェクトプール３０でのイベント受信時の動作について図１３の動作フロー図を用いて説明する。尚、オブジェクトプール３０においてプールされるオブジェクトはプロキシーオブジェクト１７であるが、便宜上、オブジェクトの文言にて説明する。
オブジェクトプール３０におけるイベント処理部３１は、アプリケーションサーバー２０のイベント生成部２１から通知されたイベントに基づき、オブジェクト管理部３２に対してオブジェクト実行状態の変更を通知する(ブロック１３１)。この通知を受けたオブジェクト管理部３２は、活動中オブジェクト管理部３３、空きオブジェクト管理部３４に対してそれぞれのオブジェクト管理テーブルに登録されたオブジョクトのうち、イベント処理部３１より通知されたプロジェクトに属するオブジェクトを選択し、その実行状態を更新する(ブロック１３２)。
【００３４】
このように本実施の形態によれば、アプリケーションサーバー２０にて実行されているアプリケーションの状態が変化した際に、アプリケーションサーバー２０自身がオブジェクトプール３０に対してイベント通知を行うことにより、オブジェクトプール３０にてアプリケーションサーバー２０の状態を把握することができ、プールされたオブジェクトを自動的に更新することが可能となる。その結果、アプリケーションサーバー２０で実行されているアプリケーションの状態変化に迅速に対応することができ、実際には使用不可能なオブジェクトをクライアント１１に割り当ててしまう危険性を回避することが可能となる。言い換えれば、本実施の形態によるオブジェクトプール３０は、ただ単にオブジェクトをプーリングするのではなく、アプリケーションサーバー２０上のアプリケーションの状態を把握することで、常に有効なオブジェクトをプールしておくことが可能となる。そのため、仮にクライアント１１から、ある時点で無効になってしまったオブジェクトに対するアクセス要求があった場合でも、オブジェクトプール３０からクライアント１１に対して現在のオブジェクトの情報を直接通知することができ、アプリケーションサーバー２０へのアクセスなどの冗長な処理を省略でき、オブジェクトプール３０をより効果的に活用することができる。
【００３５】
次に、本実施の形態におけるオブジェクトプール３０の開始動作(イニシャル時)について、図１４のフローチャートを用いて説明する。
まず、オブジェクトプール３０の開始処理部３６は、終了時に保存したプールオブジェクト情報をオブジェクト情報記憶部３５から読み取り、オブジェクトに対して割り当てられた優先順位に基づき、オブジェクト管理部３２に対してオブジェクトの生成要求を行う(ブロック１４１)。この生成要求を受けたオブジェクト管理部３２は、開始処理部３６からの生成要求に従い、該当するオブジェクトを作成し、生成されたオブジェクトの情報を空きオブジェクト管理部３４に通知する(ブロック１４２)。この通知を受けた空きオブジェクト管理部３４は、オブジェクト管理部３２より受け取った情報に基づき、前述した空きオブジェクト管理テーブルに作成されたオブジェクトを登録する(ブロック１４３)。
【００３６】
一方、オブジェクトプール３０の終了動作について、図１５のフローチャートを用いて説明する。
まず、オブジェクトプール３０の終了処理部３７は、オブジェクト管理部３２及びクライアント要求解析部４１に対して終了処理の開始を通知する(ブロック１５１)。クライアント要求解析部４１は、この終了処理開始の通知を受け取ると、以降クライアント１１からの処理要求を拒否する(ブロック１５２)。次に、オブジェクト管理部３２は、空きオブジェクト管理部３４から、空きオブジェクト管理テーブルにあるオブジェクト情報を取得し、終了処理部に転送する(ブロック１５３)。終了処理部３７は、オブジェクト管理部３２から受け取ったオブジェクト情報を、プロセス終了後も消去されないよう、オブジェクト情報記憶部３５に格納する(ブロック１５４)。この格納されるオブジェクト情報は、例えば前述の図９に示すような内容であり、この図９に示す優先順位に基づいて図１４にて説明した開始動作が実行され、例えば優先順位の高いものから順にオブジェクトが生成される。
【００３７】
以上説明したように、本実施の形態におけるオブジェクトプール３０の終了動作および開始動作によれば、データベースのような決まりきったものではない分散オブジェクトにおいても、例えば優先順位に基づいて動的にオブジェクトをプールすることが可能となり、オブジェクトをプールする際にルーティングできず実行時でないと明確にならないオブジェクトに対しても、有効なオブジェクトプールを提供することができる。
【００３８】
次に、本実施の形態におけるクライアント１１からのオブジェクト生成要求時の動作について、図１６のフローチャートを用いて説明する。
まず、オブジェクトプール３０のクライアント要求解析部４１は、クライアント１１からのリクエストの内容を解析し、オブジェクト生成処理部４２へ処理を依頼する(ブロック１６１)。この依頼を受けたオブジェクト生成処理部４２は、生成を要求されたオブジェクトのサーバー名、プロジェクト名、クラス名をオブジェクト管理部３２に転送し、オブジェクトの取得要求を行う(ブロック１６２)。この要求を受けたオブジェクト管理部３２は、空きオブジェクト管理部３４に対して、該当するクラスのオブジェクトの取得要求を行う(ブロック１６３)。この取得要求を受けた空きオブジェクト管理部３４は、空きオブジェクト管理テーブル内に要求されたクラスのオブジェクトが存在する場合、そのオブジェクトの実行状態をチェックした上で、使用可能な状態であればそのオブジェクトをオブジェクト管理部３２に渡し、空きオブジェクト管理テーブルに存在していたそのオブジェクトの項目を削除する。空きオブジェクト管理テーブル内に要求されたオブジェクトが存在している場合でも、オブジェクトが使用できない状態にあるときは、それをオブジェクト管理部３２に通知する(ブロック１６４)。オブジェクト管理部３２は、空きオブジェクト管理部３４から該当するオブジェクトを取得できなかった場合、新たにオブジェクトを生成する。活動中オブジェクト管理部３３に対して、空きオブジェクト管理部３４から取得したオブジェクト、あるいは新たに生成したオブジェクトの情報を、活動中オブジェクト管理テーブルに追加するよう依頼し、オブジェクト生成処理部４２に要求されたオブジェクトを返す。空きオブジェクト管理部３４からオブジェクトが使用不可能な状態にあると通知された場合には、新たなオブジェクトの生成は行わず、その由をオブジェクト生成処理部４２に返し(ブロック１６５)、一連の動作が終了する。
【００３９】
次に、クライアント１１からのオブジェクト削除要求時の動作について、図１７のフローチャートを用いて説明する。まず、オブジェクトプール３０のクライアント要求解析部４１は、クライアント１１からのリクエストの内容を解析し、オブジェクト削除処理部４４へ処理を依頼する(ブロック１７１)。この依頼を受けたオブジェクト削除処理部４４は、削除を要求されたオブジェクトをオブジェクト管理部３２に転送し、オブジェクトの削除要求を行う(ブロック１７２)。この要求を受けたオブジェクト管理部３２は、活動中オブジェクト管理部３３に対して、要求されたオブジェクトを活動中オブジェクト管理テーブルから削除するように依頼すると共に、空きオブジェクト管理部３４に対して、そのオブジェクトの空きオブジェクト管理テーブルへの追加を要求する(ブロック１７３)。この要求を受けた空きオブジェクト管理部３４は、オブジェクト管理部３２からの依頼に基づき、該当オブジェクトの情報を空きオブジェクト管理テーブルへ追加する。続いて、空きオブジェクトの数と予め定められた最大プール数(図８)を比較し、空きオブジェクトの数が最大プール数を超えていた場合、優先順位の一番低いオブジェクトをプールから外し、オブジェクト管理部３２に対して、そのオブジェクトの削除を要求する(ブロック１７４)。オブジェクト管理部３２は、空きオブジェクト管理部３４からのオブジェクトの削除要求に従い、オブジェクトを削除し(ブロック１７５)、削除要求時の動作が終了する。
【００４０】
次に、クライアント１１からのメソッドコール処理要求があった時の動作について、図１８のフローチャートを用いて説明する。
まず、オブジェクトプール３０のクライアント要求解析部４１は、クライアント１１からのリクエストの内容を解析し、メソッドコール処理部４３へ処理を依頼する(ブロック１８１)。この依頼を受けたメソッドコール処理部４３は、オブジェクト管理部３２に対して、処理要求のあったオブジェクトを請求する(ブロック１８２)。処理要求を受けたオブジェクト管理部３２は、要求されたオブジェクトを活動中オブジェクト管理部３３から取得し、メソッドコール処理部４３に引き渡す。この時、活動中オブジェクト管理部３３は、活動中オブジェクト管理テーブルをチェックし、その実行状態も合わせてメソッドコール処理部４３に戻す(ブロック１８３)。メソッドコール処理部４３は、オブジェクト管理部３２から受け取ったオブジェクトの実行状態をチェックし、可能であれば取得したオブジェクトにメソッドを実行させ、結果をクライアント１１に戻す。オブジェクトが実行可能状態にない場合には、クライアント１１に対して即座にエラーを通知し(ブロック１８４)、一連のメソッドコール処理要求時の動作が終了する。
【００４１】
尚、本実施の形態におけるオブジェクトプールの終了動作時(図１５)にて、空きオブジェクト管理テーブル(図７)で実行状態が停止中であり、更に再度起動することがないプロジェクトに関するオブジェクトを消去するか否かは、その実装の形態によって判断される。但し、プロジェクト完全終了時に空きオブジェクト管理テーブルからそのオブジェクトを消去した場合には、クライアント１１からリクエストがあると、アプリケーションを実行するアプリケーションサーバー２０に対してオブジェクト作成を要求し、アプリケーションサーバー２０からのエラー返答を待ってからクライアント１１に対してエラーを返すことになる。一方、そのようなオブジェクトを消去しなかった場合には、アプリケーションサーバー２０からの返答を待たずにクライアント１１に対してエラーを返すことが可能となり、より迅速な対応が可能となる点で優れている。
【００４２】
次に、本実施の形態における優先順位の更新動作について、図１９及び図２０を用いて説明する。
図１９(ａ)、(ｂ)はオブジェクト削除要求処理前の各テーブルエントリーの例を示し、図２０(ａ)、(ｂ)はオブジェクト削除要求処理後の各テーブルエントリーの例を示している。まず、クライアント１１からのオブジェクト削除要求時の動作について説明する。図１９(ａ)、(ｂ)に示すように、例えばある時点で、活動中オブジェクト管理テーブルにはクラス名ＸであるオブジェクトＸが、空きオブジェクト管理テーブルにはクラス名Ａ、ＢであるオブジェクトＡ、Ｂが存在していたものと仮定する。クライアント１１がオブジェクトＸの削除を要求すると、図５に示したオブジェクト削除処理部４４はオブジェクト管理部３２に対してその処理を依頼する。この依頼を受けたオブジェクト管理部３２は、活動中オブジェクト管理部３３および空きオブジェクト管理部３４に命じて、活動中オブジェクト管理テーブルにあったオブジェクトＸ (図１９(ａ))を空きオブジェクト管理テーブルへ移す。このとき、優先順位の算出方法としてそのオブジェクトへの最終アクセス時間を採用していた場合、空きオブジェクト管理部３４はオブジェクトＸに最も高い優先順位を割り振り、オブジェクトＡ、Ｂの優先順位はそれぞれ下げられる。その結果、活動中オブジェクト管理テーブルは図２０(ａ)に示すものとなり、空きオブジェクト管理テーブルは図２０(ｂ)に示すような内容となる。
【００４３】
次に、オブジェクトプール３０でのイベント受信時の優先順位決定動作について、例を挙げて説明する。オブジェクトプール３０のオブジェクト管理部３２は、イベント処理部３１から通知されたイベントに従い、活動中オブジェクト管理部３３と空きオブジェクト管理部３４に対して、それぞれが管理するテーブルの更新を依頼する。このとき、空きオブジェクト管理部３４は、実行順位と共に優先順位の変更を行う。一方、活動中オブジェクト管理テーブルには優先順位の情報が保持されていないので、活動中オブジェクト管理部３３は、オブジェクトのアプリケーション実行環境(アプリケーションサーバー２０)での実行状態のみを更新する。
優先順位の更新としては、例えば、プロジェクトの停止、一時停止、ビジー状態などのイベントを受信した場合に、そのオブジェクトの優先順位を下げるものが挙げられる。また、例えば、プロジェクトの開始処理完了、実行準備完了などのイベントを受信した場合に、そのオブジェクトの優先順位を上げるように構成することも可能である。本実施の形態によれば、実装の形態によってここに掲げた以外にも様々な内容のイベントに対して優先順位をダイナミックに更新することが可能であり、オブジェクトプール３０の立ち上げである起動時にクライアント１１が使用するであろうオブジェクトを有効に決定することで、効果的なオブジェクトプールを構築することが可能となる。
【００４４】
図２１は、本実施の形態を用いたアプリケーションシステムの一例を示す図である。同図において、アプリケーションサーバー７１は、受注・発注処理や、顧客情報、人事管理情報等のアプリケーションを実行するアプリケーション実行環境である。また、サーバー７２は、本実施の形態におけるオブジェクトプールとして機能しており、アプリケーションサーバー７１とは一般的にＬＡＮ等の通信ネットワーク７４を介して接続されている。また、クライアント７３は、例えば希望する作業をメソッドという形で要求してサーバーに対して処理を依頼し、その結果を受け取るもので、ＷＡＮやＬＡＮ等からなる通信ネットワーク７５を介してサーバー７２に接続されている。
【００４５】
今、クライアント７３の１つがＷｅｂを経由して文房具などのオフィス製品を注文する場合を例にとる。図２２は、このクライアントアプリケーションの画面イメージを示した図である。このアプリケーションは、商品をＷｅｂを経由して注文を行うことを可能にする一般的な受発注処理プログラムである。まず、クライアント７３は、クリエイトオブジェクト、即ち、どのサーバー上の(受注処理業務の)受注クラスのオブジェクトを作って欲しい旨を指示する。このクライアントは、例えばアプリケーションサーバーが提供するAppletを使用してサーバーとコミュニケーションを行うことが可能である。図２２のディスプレイ８１のＷｅｂページ上に存在するオーダーボタン８２は、ＨＴＭＬ及びJava Scriptで所定の定義がなされおり、ユーザーがオーダーボタン８２を押下すると、所定の関数が呼ばれ、サーバー７２を経由し、リモートサーバーである受注・発注処理を実行するアプリケーションサーバー７１に定義されている“Ｏｒｄｅｒ”メソッドが実行される。クライアント７３は、オブジェクトプールであるサーバー７２をパススルーし、受注オブジェクトに対して価格や在庫の照会、買いやキャンセル等をメソッドとしてオブジェクトに投げかけるように構成されている。尚、本実施の形態では、サーバー７２でプールされるプロキシーオブジェクトを介してオブジェクトを使用する形態にあり、受注・発注処理のプロジェクトを実行するオブジェクトの状態変化をサーバー７２が認識していることから、例えば異常終了があった場合等にクライアント７３に対して有効なオブジェクトでない旨をいち早く通知でき、冗長な処理を省略することが可能となる。
【００４６】
[実施の形態２]
実施の形態１では、オブジェクトプールがプロキシーオブジェクトの形態でプールし、アプリケーション実行環境は別に備えていたが、本実施の形態では、自らアプリケーション実行環境であるサーバーがオブジェクトプールとして機能するものである。
尚、実施の形態１と同様の構成については同様の符号を付し、ここではその詳細な説明を省略する。
【００４７】
図２３は、実施の形態２におけるクライアントサーバーシステムの全体構成を説明するための図である。同図において、オブジェクトプール９０は、アプリケーション実行環境としてオブジェクト９１を自ら生成すると共に、クライアント１１に対して効果的なオブジェクトプールとして機能している。
図２４は、オブジェクトプール９０の機能ブロックを説明するための図である。実施の形態１におけるオブジェクトプール３０(図５)とは、イベント処理部３１を備えていない点で構成上の異なりがある。
【００４８】
次に、図２４を用いて各処理の流れについて説明する。
まず、クライアント１１からオブジェクト生成要求があった場合、クライアント要求解析部４１は、リクエストのタイプを解析し、オブジェクト生成処理部４２へ処理を依頼する。この依頼を受けたオブジェクト生成処理部４２は、オブジェクト管理部３２にオブジェクトの取得を依頼する。オブジェクト管理部３２では、空きオブジェクト管理部３４に問い合わせ、該当するクラスのオブジェクトがあればそれを渡し、なければオブジェクトを生成してそれを渡す。
また、クライアント１１からオブジェクト削除要求があった場合、クライアント要求解析部４１は、リクエストのタイプを解析し、オブジェクト削除処理部４４へ処理を依頼する。この依頼を受けたオブジェクト削除処理部４４は、オブジェクト管理部３２にオブジェクトの削除を依頼する。オブジェクト管理部３２では、空きオブジェクトとして、空きオブジェクト管理部３４にそのオブジェクトを登録するように要求する。このとき、空きオブジェクトの数が最大プール数に達していたら、優先順位の一番低いオブジェクトをプールから外し、実際に削除する。この優先順位はオブジェクトの最終アクセス時間等で決定することができる。
【００４９】
次に、オブジェクトプール９０であるサーバープロセスを終了する場合には、終了処理部３７は、空きオブジェクト管理部３４からオブジェクトのタイプと優先順位のリストを取得し、オブジェクト情報記憶部３５に保存する。一方、サーバープロセスを開始するイニシャル時には、開始処理部３６は、終了時に保存したデータから優先順位の高い順に、初期プール数に達するまでオブジェクトの生成要求をオブジェクト管理部３２に対して行う。この結果、アプリケーション実行環境にあるサーバーには、分散オブジェクトを利用したアプリケーション下にて、クライアントが使用するであろうオブジェクトをイニシャル時に事前に生成することが可能となり、有効なオブジェクトプールとして機能することができる。特に、例えば、最終アクセスのあったオブジェクトの優先順位を高くした状態にてサーバープロセスが終了され、イニシャル時にその優先順位に基づいて最終アクセスのあったオブジェクトからオブジェクトの生成がなされるように構成することで、再度使用される可能性が高い最終アクセスのあったオブジェクトをまず生成することが可能となる等、オブジェクトプールの有用性を向上させることができる。
【００５０】
尚、これらの実施形態を実行するためのソフトウエアは、ＣＤ-ＲＯＭ等の記憶媒体を介して各サーバーにインストールすることで実行させることができる。そのインストールは、実施の形態１では、オブジェクトプール３０として機能するサーバーへのインストールと、アプリケーションサーバー２０へのインストールの態様が挙げられ、実施の形態２ではオブジェクトプール９０として機能するサーバーへのインストールの態様が挙げられる。また、予めハードディスク等の記憶媒体にインストールされている場合の他、ＣＤ-ＲＯＭ等の記憶媒体を介さずにネット等を介してソフトウエアをダウンロードすることによっても達成できる。その際には、プログラムを記憶する記憶手段と、そのプログラムを読み出して送信する送信手段をＰＣ等に具備させ、インターネット等に接続されたプログラムを実行する他のＰＣからの要求によってそのＰＣにダウンロードさせるように構成すれば良い。また、各クライアントに対しても同様なプログラムインストール方法をもって、これらの実施形態におけるクライアントサーバーシステムを形成することが可能である。
【００５１】
以上説明したように、実施の形態１及び２によれば、オブジェクトプールの立ち上げ時に動的にオブジェクトをプールすることが可能となり、分散オブジェクトを利用したアプリケーションにおけるオブジェクトの作成時に費やされる処理時間を有効に短縮することができる。また、本実施の形態によれば、クライアントから接続されているサーバーのバックエンドに幾つかのアプリケーションサーバーがあり、そのアプリケーションサーバーにて実オブジェクトを作成するようなモデルであっても、そのサーバーで実行されているアプリケーションの状態変化を適切に把握することが可能となり、常に有効なオブジェクトをプールしておくことが可能となる。
【００５２】
更に、本実施の形態による方式では、アプリケーション実行環境とオブジェクトプール内の管理オブジェクトが、直接、イベントの送受信を実行するため、ユーザーがプール制御用のプログラムを用意する必要がなく、更にはアプリケーションの起動時などユーザーオブジェクトが存在しない時点でのオブジェクトプールの制御を行うことも可能である。またこのとき、サーバーとオブジェクトプールの間で発行されるイベントを、ＣＯＲＢＡ(Common ORB Architecture)のイベントサービスなど、分散環境に対応したＯＲＢ(Object Request Broker)を利用することにより、容易にネットワークを介してイベント通知を行うことが可能となる。このＣＯＲＢＡのように公開された標準的な形式でイベントを定義することで、異なるベンダー間での相互接続性も期待できる。
【００５３】
【発明の効果】
以上説明したように、本発明によれば、サーバーの起動後、クライアントから最初にオブジェクトの生成要求があったときの応答時間を短縮することができる。また、アプリケーションの状態を把握することでオブジェクトプールの有用性を向上させることができる。
【図面の簡単な説明】
【図１】  本発明の形態におけるクライアントサーバーシステムの全体構成を説明するための図である。
【図２】  アプリケーション実行環境の機能ブロックを説明するための図である。
【図３】  イベント生成部２１において生成されるイベント通知管理テーブルを示すものである。
【図４】  プロジェクト実行監視部２５において更新されるプロジェクト実行監視テーブルを示すものである。
【図５】  オブジェクトプール３０の機能ブロックを説明するための図である。
【図６】  活動中オブジェクト管理部３３において用いられる活動中オブジェクト管理テーブルを示すものである。
【図７】  空きオブジェクト管理部３４にて用いられる空きオブジェクト管理テーブルを示すものである。
【図８】  本実施の形態におけるオブジェクトプールプロパティ管理テーブルを示すものである。
【図９】  オブジェクト情報記憶部３５に記憶されるプールオブジェクト情報を示すものである。
【図１０】  プロジェクトの開始動作を説明するためのフローチャートである。
【図１１】  プロジェクトの停止動作を説明するためのフローチャートである。
【図１２】  プロジェクトの異常終了処理動作を説明するためのフローチャートである。
【図１３】  イベント受信時の動作を説明するためのフローチャートである。
【図１４】  オブジェクトプールの開始動作を説明するためのフローチャートである。
【図１５】  オブジェクトプールの終了動作説明するためのフローチャートである。
【図１６】  クライアントからのオブジェクト生成要求時の動作について説明するためのフローチャートである。
【図１７】  クライアントからのオブジェクト削除要求時の動作について説明するためのフローチャートである。
【図１８】  クライアントからのメソッドコール処理要求があった時の動作について説明するためのフローチャートである。
【図１９】  (ａ)、(ｂ)はオブジェクト削除要求処理前の各テーブルエントリーの例を示すものである。
【図２０】  (ａ)、(ｂ)はオブジェクト削除要求処理後の各テーブルエントリーの例を示すものである。
【図２１】  本実施の形態を用いたアプリケーションシステムの一例を示す図である。
【図２２】  クライアントアプリケーションの画面イメージを示した図である。
【図２３】  実施の形態２におけるクライアントサーバーシステムの全体構成を説明するための図である。
【図２４】  オブジェクトプールの機能ブロックを説明するための図である。
【符号の説明】
１１…クライアント、１６…実オブジェクト、１７…プロキシーオブジェクト、２０…アプリケーションサーバー/アプリケーション実行環境、２１…イベント生成部、２２…ユーザー入力処理部、２３…プロジェクト開始処理部、２４…プロジェクト停止処理部、２５…プロジェクト実行監視部、２６…プロジェクト実行制御部、３０…オブジェクトプール、３１…イベント処理部、３２…オブジェクト管理部、３３…活動中オブジェクト管理部、３４…空きオブジェクト管理部、３５…オブジェクト情報記憶部、３６…開始処理部、３７…終了処理部、４１…クライアント要求解析部、４２…オブジェクト管理部、４３…メソッドコール処理部、４４…オブジェクト削除処理部、７１…アプリケーションサーバー、７２…サーバー、７３…クライアント、７４、７５…通信ネットワーク、８１…ディスプレイ、８２…オーダーボタン、９０…オブジェクトプール、９１…オブジェクト
【図１】
0003690720.tif 000002
【図２】
0003690720.tif 000003
【図３】
0003690720.tif 000004
【図４】
0003690720.tif 000005
【図５】
0003690720.tif 000006
【図６】
0003690720.tif 000007
【図７】
0003690720.tif 000008
【図８】
0003690720.tif 000009
【図９】
0003690720.tif 000010
【図１０】
0003690720.tif 000011
【図１１】
0003690720.tif 000012
【図１２】
0003690720.tif 000013
【図１３】
0003690720.tif 000014
【図１４】
0003690720.tif 000015
【図１５】
0003690720.tif 000016
【図１６】
0003690720.tif 000017
【図１７】
0003690720.tif 000018
【図１８】
0003690720.tif 000019
【図１９】
0003690720.tif 000020
【図２０】
0003690720.tif 000021
【図２１】
0003690720.tif 000022
【図２２】
0003690720.tif 000023
【図２３】
0003690720.tif 000024
【図２４】
0003690720.tif 000025