JP3558887B2 - 分散システム、その制御方法、および記憶媒体 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は複数のコンピュータが接続されてなる分散システムに関し、特に、要求された処理の実行位置決定の改良に関する。
【０００２】
【従来の技術】
近年のコンピュータ・通信技術の発達により、コンピュータは単体で使用するよりも、ＬＡＮ，ＷＡＮあるいはインターネット等の種々の形態のネットワークシステムを構築し、そのネットワークの中で資源共有等を行って使用される場合が多くなってきている。このようなネットワークシステムの中で、処理を要求するコンピュータ（クライアントホスト）に対して何らかの処理を行う他のコンピュータ（サーバホスト）が存在するシステムは、クライアント・サーバシステムあるいは分散システム（以下、本明細書では分散システムと称する）と呼ばれている。このような分散システムによれば、クライアントホストの要求する処理を、その時のネットワークシステムの状況や処理内容に応じて当該クライアントホスト以外のサーバホスト等で実行させることも可能である。
【０００３】
従来の分散システムは大きく３種類に分類される。以下それぞれについて説明する。
【０００４】
第１の形態は、メインフレームに代表される垂直型分散システムである。垂直型分散システムでは基本的にはクライアントホストからサーバホストヘ処理を依頼し、サーバホストはその処理を実行し、クライアントホストはその処理結果をサーバから受け取る。
【０００５】
このような垂直型の分散システムでは次に示すような問題点がある。
【０００６】
（１）クライアントホストが多数のサーバホストヘ接続されている場合、サーバホストへの過負荷が原因で処理全体のスループットが低下する。
【０００７】
（２）処理を依頼するたびにネットワーク経由での通信を行なうため、ネットワークトラフィックが増大する。
【０００８】
第２の形態は、水平型分散システムである。水平型分散システムでは、必要なデータをサーバホストに存在するデータベースマネジメントシステム（ＤＭＢＳ）などへ要求し、それから得られた情報に対する処理はクライアントホストで行うようにする。これにより、上記垂直型分散システムの問題点（１）、（２）をある程度克服できる。
【０００９】
ただし、このシステムでは次のような問題点が挙げられる。
【００１０】
（３）クライアントホストにある程度の処理能力やリソースが必要となる。
【００１１】
（４）クライアントホストとデータベースマネンジメントシステムが密接に関わっているため、データベースマネンジメントシステムの変更等に対処するためのシステムの柔軟性が低い。
【００１２】
（５）クライアントホスト毎にアプリケーションプログラム管理を行なわなければならない。
【００１３】
第３の形態は、２次記憶（ＨＤＤなど）を持たないネットワークコンピュータ（ＮＣ）や、モバイル環境向けのモバイルネットワークコンピュータ（ＭＮＣ）などによって構成される分散ネットワークシステムである。なお、分散ネットワークシステムでは、通常のパーソナルコンピュータ（ＰＣ）やワークステーション（ＷＳ）も当然に端末となりうる。この分散ネットワークシステムでは、クライアントがサーバヘ処理を要求するとその処理を実行するサーバコンポーネントがクライアントホストヘ送られてきて、その処理をクライアントホスト上で実行する。近年のＪａｖａアプレットがこれに相当する。
【００１４】
このシステムでは、水平分散システムの（５）の問題点が克服される。ただし、（３）の問題点は逆に強調されてしまう。クライアントホストが処理能力の高いパーソナルコンピュータやワークステーションの場合であればまだしも、ネットワークコンピュータやモバイルネットワークコンピュータはそれらに比べれば処理能力が低いためである。またそれに伴い、次のような問題点もある。
【００１５】
（６）サーバが低負荷な場合であれば、クライアント側で処理を実行するよりもサーバ側で処理を実行するほうが、処理全体のスループットが向上する。
【００１６】
また、これらの問題点の他に、上記３つの形態のシステムにおいて、共通に次の問題点がある。
【００１７】
（７）ソフトウェアの構造（処理コンポーネントの実行位置）が静的に決められているので、動的に変動するネットワーク環境に対して柔軟性に欠ける。
【００１８】
（８）システム設計（どのホストにどの処理を実行させるかを決定する）が難しく、また柔軟性に欠けるため、後からの変更や新しい仕様の追加においても、問題が発生する可能性がある。
【００１９】
なお、分散環境における負荷分散システムやモバイル環境向けのエージェントシステムでは、ネットワーク上での処理コンポーネントの動的な移動／配置を行い、システムの柔軟性を向上する従来例がある。しかし、このようなシステムにおいても、次のような問題点がある。
【００２０】
（９）クライアントホスト側で実行する場合、通常、クライアントコンポーネントとサーバコンポーネントが別コンポーネントであるため、コンポーネント間通信が必要であり、そのためのオーバヘッドが問題となる。
【００２１】
【発明が解決しようとする課題】
このように従来の分散システムでは、特定の処理を提供するコンポーネントの実行場所はそのシステムの開発者によって静的に決められてる。したがって、あるコンポーネントは必ずクライアントホスト側で実行され、またある別のコンポーネントは必ずサーバホスト側で実行されることになる。
【００２２】
また、従来技術では、形態１、形態２、形態３と進むにつれて問題点が少なくなっているように見えるが必ずしもそうではない。つまり、ネットワークシステムでは、コンピュータ環境が動的に変化するものであり、このコンピュータ環境の動的変化と、上記コンポーネント実行場所の固定性とが相俟って処理効率の向上を容易に行えないものとなっている。
【００２３】
したがって、上記いずれ形態の分散システムをとったとしても、環境の動的変化のため、常に理想的な状態で処理を行えるとは限らず、そのシステム本来の機能を発揮できない。例えば、あるサーバに非常に多くのクライアントが接続し、サーバの負荷が大きくなるために、垂直型システムから水平型又は分散ネットワークシステムに変更したとしても、分散化が進みすぎて逆にサーバが低負荷となり、ある処理はサーバ側で処理を実行するほうが、処理全体のスループットが向上するということになりかねない。
【００２４】
このようなコンピュータ環境の動的な変化に対応しつつ、処理のスループットを向上させるためには、処理を行うコンポーネントの実行位置を動的に変更できる仕組みを作ることが望ましい。
【００２５】
また、システムのスケーラビリティを考慮した種々のネットワークシステムの開発においても、実行位置は静的に決められているよりも動的に変化可能であることが好ましい。
【００２６】
処理の実行位置を動的に決定するためには、処理を実装したプログラム（実行可能な形式にされたもの）を対象とするコンピュータ全てに予めインストールしておくことが必要である。これにより、処理の実行位置をこれらのコンピュータの中から実行時に選択して、そのコンピュータに処理を実行させることが可能でなる。フォールトトレランスや負荷分散の目的でこのような分散システムを構築することが可能である。
【００２７】
しかし、全てのコンピュータに対するプログラムのインストールや保守管理は非常に大変であり、現実的ではない。
【００２８】
また、処理の実行位置を処理の実行後に切り替えるものとしてモバイルエージェントと呼ばれるものがある。これは分散システム上の指定されたコンピュータを対象とし、それらを巡回しながら処理を行なうものである。具体的には、あるコンピュータで処理を行ない、その終了後に別のコンピュータに移り、同様の処理を行なう。以降、これを指定された全てのコンピュータ上で行なうよう繰り返す。このような分散システムは、主に情報収集やシステム監視などの目的で利用される。
【００２９】
しかし、モバイルエージェントでは、基本的に、処理に関係するプログラムが１つのまとまりとなって、その全てが対象となるコンピュータへ移動し（配送され）、動作する。そのため、特定のコンピュータの資源を利用するような構造をモバイルエージェント自身が持つことができない。
【００３０】
さらに、上述の第３の形態でも説明したＪａｖａアプレットのように、処理プログラムを提供するサーバホストから処理を要求したクライアントホストへ処理プログラムを配信し、クライアントホスト側で実行するようなシステムもある。これにより、処理プログラムは一箇所にのみインストールすればよく、処理プログラムの保守管理やインストール作業が容易になる。
【００３１】
しかし、このシステムでも、処理の実行場所は静的に決まっており、分散システムの構成（処理を分散システム内のどのコンピュータで実行するか）を柔軟に変更することができない。そのため、負荷分散などの目的には使えない。
【００３２】
さらに、上記した各従来例では、モバイルエージェントを除き、基本的に、一度実行した場所を途中で変更することはできない。また、モバイルエージェントの場合は通常、一連の移動−処理が終了するまで、処理を依頼したクライアントとの接続を切断する。すなわち、常時接続されているわけではないため、処理中に何らかの指示をクライアント側から与えることが難しい。
【００３３】
本発明は、このような実情を考慮してなされたもので、クライアントが要求した処理の実行位置をクライアント側にするか、サーバ側にするかを動的に変更し、システム構成を柔軟に変化させることが可能な分散システムを提供することを目的とする。
【００３４】
【課題を解決するための手段】
前記課題を解決し目的を達成するために、本発明は以下に示す手段を用いている。
【００３５】
（１）本発明の分散システムは、クライアントとサーバからなる分散システムにおいて、
前記クライアントは処理の要求を発するアプリケーション基本部分と、コンポーネントローダとを具備し、
前記サーバは前記アプリケーション基本部分が要求する処理を実行するサーバコンポーネントを管理する管理手段と、前記アプリケーション基本部分からの要求を受け取り、当該処理を実行するサーバコンポーネントを前記クライアント又は前記サーバのいずれで実行するかを決定する実行位置決定手段と、前記アプリケーション基本部分から要求された処理を実行するサーバコンポーネントを前記管理手段から取得し、取得した当該サーバコンポーネントを前記実行位置決定手段における決定結果に従って処理するサーバコンポーネント引渡手段とを具備し、前記サーバコンポーネントは、要求される処理を実装しているサーバコンポーネント本体と、前記サーバと通信を行うクライアント側アダプタ、前記クライアントと通信を行うサーバ側アダプタとを具備し、
前記サーバコンポーネント引渡手段は、
クライアントで実行すると決定した場合、サーバコンポーネント本体をクライアントのコンポーネントローダへ送り、コンポーネントローダにサーバコンポーネント本体から実行可能なサーバコンポーネントオブジェクトを生成させる手段と、
サーバで実行すると決定した場合、管理手段から指定されたサーバコンポーネントのクライアント側アダプタとサーバコンポーネント本体を受け取り、サーバコンポーネント本体から実行可能なサーバコンポーネントオブジェクトを生成し、サーバ側アダプタについてのオブジェクトを生成し、処理の要求を発したクライアントのコンポーネントローダへクライアント側アダプタを送り、コンポーネントローダにクライアント側アダプタを実行可能なスタブオブジェクトを生成させる手段とを具備し、
クライアントで実行すると決定した場合、クライアントアプリケーション基本部分にサーバコンポーネント本体を利用して処理を実行させ、
サーバで実行すると決定した場合、クライアントアプリーション基本部分にスタブオブジェクト、サーバ側アダプタを通してサーバホスト上に生成されたサーバコンポーネント本体にアクセスし処理を実行させる分散システム。
【００３６】
これによれば、処理の実行位置を動的に変更し、システム構成を柔軟に変化させることができる。
【００３９】
（２）本発明の分散システムは、上記（１）に記載した分散システムであって、かつ前記サーバ及び前記クライアントの負荷情報、前記サーバ及び前記クライアントの処理能力に関する情報、前記サーバ及び前記クライアントを接続するネットワークの転送速度、又は前記サーバコンポーネントのサイズ情報、又は前記サーバコンポーネントの計算量情報のうち、少なくとも１つ以上を取得し、前記実行位置決定手段に提供するネットワークモニタ手段をさらに具備し、前記実行位置決定手段は、前記ネットワークモニタ手段から提供された情報に基づいて前記サーバコンポーネントの実行位置を決定するものである。
【００４０】
これによれば、クライアントからの処理要求を、処理結果が速く得られるようにサーバコンポーネントの実行位置を切り替えることができ、スループットの向上につながる。
【００４１】
（４）本発明の分散システムは、上記（２）に記載した分散システムであって、かつ前記サーバは前記クライアントのユーザ情報又は前記アプリケーション基本部分の識別情報に基づき、当該アプリケーション基本部分の発する処理要求を受け付けるか否かを判定するアクセス制御監視手段を具備し、前記実行位置決定手段は、前記アクセス制御監視手段の判定結果に基づき、前記サーバコンポーネントを実行させるか否かをも決定するものである。
【００４２】
これによれば、クライアントのユーザ情報やクライアントホスト情報によりサーバコンポーネントへのアクセスを制御することが可能である。
【００４３】
（５）本発明の分散システムは、上記（２）に記載した分散システムであって、かつ前記サーバコンポーネントは、要求される処理を実装しているサーバコンポーネント本体と、前記サーバと通信を行うクライアント側アダプタ、前記クライアントと通信を行うサーバ側アダプタと、前記サーバコンポーネント本体と前記クライアント側アダプタとの共通のインターフェースを定義する共通インターフェースとを具備するものである。
【００４４】
これによれば、サーバコンポーネント本体は１つですむので、サーバコンポーネント開発者は同一のプログラムを一度だけ実装すればよい。さらに、サーバコンポーネント本体とクライアント側アダプタが共通のインターフェースを実装しているため、クライアントから両者へ一様にアクセスすることができる。サーバコンポーネント本体をクライアントホスト側で実行する場合は、クライアントホストアプリケーション基本部分とサーバコンポーネント本体の間に通信のためのアダプタを使用しないため、処理要求におけるオーバーヘッドが無い。
【００４５】
（６）本発明の分散システムは、上記（５）に記載した分散システムであって、かつ前記サーバコンポーネントは、クライアントリソースへアクセスするクライアントリソースアクセス部と、サーバリソースへアクセスするサーバリソースアクセス部と、サーバコンポーネント本体がクライアント側で実行される場合に、サーバリソースアクセス部と通信するためのサーバリソースアクセス用クライアント側アダプタ及びサーバリソースアクセス用サーバ側アダプタとをさらに具備するものである。
【００４６】
これにより、処理本体は移動可能であり、かつクライアントホスト上のリソースやサーバホスト上のリソースへアクセスするような移動可能な処理コンポーネントを開発可能となる。
【００４７】
（７）本発明の分散システムは、上記（５）に記載した分散システムであって、かつ前記サーバコンポーネントは、クライアントリソースへアクセスするクライアントリソースアクセス部と、サーバリソースへアクセスするサーバリソースアクセス部と、サーバコンポーネント本体がクライアント側で実行される場合に、サーバリソースアクセス部と通信するためのサーバリソースアクセス用クライアント側アダプタ及びサーバリソースアクセス用サーバ側アダプタと、サーバコンポーネント本体がサーバ側で実行される場合に、クライアントリソースアクセス部と通信するためのクライアントリソースアクセス用クライアント側アダプタ及びクライアントリソースアクセス用サーバ側アダプタとをさらに具備するものである。
【００４８】
これにより、処理本体は移動可能であり、かつクライアントホスト上のリソースやサーバホスト上のリソースへアクセスするような移動可能な処理コンポーネントを開発可能となる。さらに、処理をサーバコンポーネント本体に集中させることが可能となり、サーバコンポーネントの開発が容易になる。
【００４９】
（８）本発明のサーバコンポーネント生成装置は、処理の要求を発するアプリケーション基本部分を有するクライアントと、前記アプリケーション基本部分が要求する処理を実行するサーバコンポーネントを管理する管理手段と、前記アプリケーション基本部分からの要求を受け取り、当該処理を実行するサーバコンポーネントを前記クライアント又は前記サーバのいずれで実行するかを決定する実行位置決定手段と、前記アプリケーション基本部分から要求された処理を実行するサーバコンポーネントを前記管理手段から取得し、取得した当該サーバコンポーネントを前記実行位置決定手段における決定結果に従って前記クライアント又は前記サーバに引き渡すサーバコンポーネント引渡手段とを有するサーバとを具備する分散システムに用いられるサーバコンポーネントを生成するサーバコンポーネント生成装置であって、サーバコンポーネントの複数のテンプレートを提供するテンプレート提供手段と、前記サーバコンポーネントに関する情報を提供する情報提供手段と、前記テンプレートを組み合わせ、また、テンプレートに前記情報を当てはめることでサーバコンポーネントを生成するプログラム生成手段と、を具備するものである。
【００５０】
（９）本発明の分散システムは、クライアントから要求される処理の実行位置を、実行前に任意のコンピュータに決定し、処理を実行するサーバコンポーネントを管理する管理手段から当該処理を実行するサーバコンポーネントを取得し、取得した当該サーバコンポーネントを決定したコンピュータに引き渡し、決定したコンピュータから処理結果を受け取り、クライアントへ引き渡すメーンサーバを具備するものである。
【００５１】
（１０）本発明の分散システムは、上記（９）に記載した分散システムであって、かつ前記メインサーバは、一度実行位置を決定し、決定したコンピュータで実行しているサーバコンポーネントの実行位置を他の計算機に変更するものである。
【００５２】
（１１）本発明のクライアントとサーバからなる分散システムを制御するプログラムを記録するコンピュータ読取り可能な記録媒体は、前記クライアントのアプリケーション基本部分が要求する処理のサーバコンポーネントを管理する管理手段と、前記アプリケーション基本部分からの要求を受け取り、前記サーバコンポーネントを前記クライアント又は前記サーバのいずれで実行するかを決定する実行位置決定手段と、前記サーバコンポーネントを前記管理手段から取得し、取得した当該サーバコンポーネントを前記実行位置決定手段における決定結果に従って前記クライアント又は前記サーバに引き渡すサーバコンポーネント引渡手段とを実行するプログラムを記録したコンピュータ読み取り可能な記録媒体である。
【００５３】
（１２）本発明のクライアントとサーバからなり、前記クライアント上のアプリケーション基本部分が要求する処理をクライアントで実行させるかサーバで実行させるかを動的に変更可能とする分散システムを制御するプログラムを記録するコンピュータ読取り可能な記録媒体は、前記クライアント上のアプリケーション基本部分が要求する処理をクライアント又はサーバいずれにおいても実行可能とするサーバコンポーネント手段と、このサーバコンポーネント手段をサーバで実行させる場合に、前記アプリケーション基本部分と間の通信を確保するための通信処理手段とを実行するプログラムを記録したコンピュータ読み取り可能な記録媒体である。
【００５４】
【発明の実施の形態】
以下、図面を参照して本発明による分散システムの実施形態を説明する。
【００５５】
（第１実施形態）
図１は本発明の第１実施形態に係る分散システムのハードウエア構成例を示すブロック図である。
【００５６】
この分散システムは、クライアントホスト１とサーバホスト２とがネットワーク３を介して接続されて構成されている。クライアントホスト１とはクライアントアプリケーションプログラムが存在し、処理を行う要求を発するホストマシンを指し、サーバホスト２とはクライアントからの要求を受けて、処理を実行するホストマシンを指す。複数のホストマシンが存在する場合、クライアントホスト以外のホストマシンは全てサーバホストとなり得る。クライアントホスト１としては、パーソナルコンピュータ、ワークステーション、ネットワークコンピュータ（ＮＣ）あるいはモバイルネットワークコンピュータ（ＭＮＣ）等が用いられ、サーバホスト２としては、パーソナルコンピュータ、ワークステーション、大型コンピュータ（メインフレーム）等が用いられる。
【００５７】
ネットワーク３としては、高速なＬＡＮや低速な公衆回線、無線ＬＡＮ等が用いられる。したがって、このネットワークシステムは、ＬＡＮ，ＷＡＮ，ＶＰＮ（バーチャルプライベートネットワーク），インターネット等として構成される。なお、本システムでは、クライアントホスト１とサーバホスト２とは常時接続されている必要はない。
【００５８】
サーバホスト２は、ハードディスク（ＨＤＤ）等からなる記憶装置４と接続され、当該記憶装置４には多数の処理プログラムであるサーバコンポーネント５が格納されて、一種のデータベースをなしている。このデータベースをコンポーネントリポジトリ（Ｃｏｍｐｏｎｅｎｔ Ｒｅｐｏｓｉｔｏｒｙ）ともいう。なお、記憶装置４は、図１に示すように、ＳＣＳＩ等によって直接サーバホスト２と接続されていてもよいし、記憶装置管理サーバを搭載する別ホストを介してサーバホスト２と接続されていてもよい。
【００５９】
サーバコンポーネント５については後述するが、簡単にいえばクライアントホスト１が要求する処理を実行するプロセス、あるいはプロセス群である。本実施形態は、このサーバコンポーネント５における要求処理部分をサーバ側とクライアント側の何れで実行させるかを自動的に決定し、さらに、その決定に従って実際に処理を実行できる状態を作り上げることを主たる目的としている。
【００６０】
次に、この分散システムにおけるシステム論理構成（ソフトウェアリソース）について説明する。
【００６１】
図２は本実施形態の分散システムにおけるソフトウェア論理構成を示す図である。
【００６２】
同図において、中央の破線より左側がクライアントホスト１側、右側がサーバホスト２側を示している。サーバコンポーネント５はクライアントホスト１、サーバホスト２の何れのホストマシンででも実行できるので、ここでは同図のように破線上に配置した。
【００６３】
クライアントホスト１には、クライアントアプリケーション基本部分１１、コンポーネントローダ１２、コンポーネントキャッシュ１３及びクライアントホスト１にて実行するように決定されたサーバコンポーネント５が設けられる。
【００６４】
一方、サーバホスト２には、コンポーネントサーバ１４、実行位置決定部１５、コンポーネントマネージャ１６、アクセス制御監視部１７、ネットワークモニタ１８及びサーバホスト２にて実行するように決定されたサーバコンポーネント５が設けられる。なお、ネットワークモニタ１８は、ネットワークシステム上の他のホストに設けられる場合もあり、その場合にはサーバホスト２はネットワーク３を介して当該ネットワークモニタ１８から必要な情報を得る。コンポーネントマネージャ１６には記憶装置４が接続される。
【００６５】
クライアントアプリケーション基本部分１１からコンポーネントローダ１２を介してコンポーネントサーバ１４へ処理プロセスであるサーバコンポーネント５を要求する。コンポーネントサーバ１４では要求されたサーバコンポーネント５をサーバホスト２、クライアントホスト１のどちらで動作させるかを決定する。
【００６６】
上記各部について具体的に説明する前に、クライアントホスト１が要求する処理、及びその処理実現のためにサーバコンポーネント５がどのようになっているのかについて説明する。
【００６７】
クライアントホスト１は、その使用者の要求に応じて種々の処理を実現する。多くの場合、アプリケーションプログラムは、単一の処理のみから構成されるのではなく、複数の処理からなっている。したがって、これを最も基本的な部分と、その他の各処理の部分に分けることができる。
【００６８】
図３は本実施形態のアプリケーションプログラムの構成例を示す図である。
【００６９】
本実施形態のシステムでは、同図（ａ）に示すようにアプリケーションプログラムがクライアントアプリケーション基本部分１１と、サーバコンポーネント５とに分割されている。なお、サーバコンポーネント５は複数個あってもよい。
【００７０】
ここで、クライアントアプリケーション基本部分１１は、アプリケーションプログラムの最も基本となる部分で、アプリケーションプログラムの起動と最小限の機能、サーバコンポーネント５のリクエスト発行、サーバコンポーネント５を利用した処理結果の表示等を行う。したがって、この基本部分１１は図２に示すように、クライアントホスト１に置かれる。一方、サーバコンポーネント５は、そのアプリケーションプログラムにおける実体的な処理の部分である。
【００７１】
図３（ｂ）では、具体例として、アプリケーションプログラムが画像処理ソフトウエアであったときの構成を示す。この例では、クライアントアプリケーション基本部分１１は画像処理アプリケーション基本部分１１ａであり、サーバコンポーネント５として平滑化処理用コンポーネント５ａが設けられている。
【００７２】
本実施形態は、クライアント側で動作する処理プロセスと、サーバ側で動作する処理プロセスとを二重に開発することを避けるために、サーバコンポーネントの開発者は同様の処理ロジックを一度だけ実装すればよい（すなわち、同じような実装を複数箇所に分散させない）ように構成されている。また、クライアントはサーバコンポーネントの実行位置に依存すること無く、処理を実行できるようにするために、サーバ側で動作する場合とクライアント側で動作する場合とで、クライアント側から見たサーバコンポーネントのインターフェース（サーバコンポーネントへのアクセス方法、より具体的にはメソッド名、引数の型と数、返り値の型；シグネチャと呼ばれる）を一致させている。さらに、処理をサーバ側で実行する場合は、サーバコンポーネントとクライアントの間で何らかの通信手段を用いて分散オブジェクト間通信を行う必要がある。また、ＧＵＩを表示したり（基本的には常にクライアント側へ表示）、サーバ側にあるデータベースマネジメントシステムへアクセスしたりする場合、すなわち固有のホストリソースへアクセスするようなサーバコンポーネントも考えられる。また、クライアント側のアプリケーションプログラムと非同期に通信を行う可能性もある。
【００７３】
このような要求を実現するために、本発明の移動可能なサーバコンポーネントは幾つかの要素に分けて構成する。
【００７４】
図４は第１実施形態におけるサーバコンポーネント５の構成例を示す図である。
【００７５】
同図に示すように、サーバコンポーネント５は、サーバコンポーネント本体２１、クライアント側アダプタ２２、サーバ側アダプタ２４からなり、クライアント側アダプタ２２とサーバ側アダプタ２４とは分散オブジェクト間通信２３により接続される。このうちサーバコンポーネント本体２１及びクライアント側アダプタ２２には、共通インタフェース２５が実装される。また、サーバ側アダプタ２４にはインターフェースが実装される場合もある。なお、サーバホスト２の記憶装置４には、上記のうち分散オブジェクト間通信２３を除く各部分に対応するファイルがサーバコンポーネント５として格納されている。
【００７６】
ここで、サーバコンポーネント本体２１は、クライアントアプリケーション基本部分１１が本来要求する処理を実行する部分であり、アプリケーションにおける実体的な処理部分である。すなわちサーバコンポーネント本体２１には、そのサーバコンポーネント５が提供する処理が実装されている。処理をクライアント側で実行する場合には、この本体２１がクライアント側へ送られ、実行可能な状態にされた後、クライアント側からの処理を受け付ける。この場合、コンポーネント本体２１がクライアント側から直接呼出されるために、アダプタ２２等を通すオーバーヘッドは存在しない。これに対し、サーバ側で処理を実行する場合は、本体２１とそれに接続するサーバ側アダプタ２４がサーバ側で実行可能な状態にされる。クライアントホスト１へはクライアント側アダプタ２２が送られる。このクライアント側アダプタ２２がクライアント側で実行可能な状態にされ、サーバ側アダプタ２４との接続を行い通信の準備を行う。クライアントホスト１はクライアントアダプタ２２、サーバ側アダプタ２４を通してコンポーネント本体２１の処理を実行させる。すなわち、両アダプタ２２、２４は分散オブジェクト間通信を用いて処理の呼出しをリレーするだけの部品である。このため、サーバコンポーネント本体２１は１つのみでよく、クライアント側で動作する処理プロセスと、サーバ側で動作する処理プロセスとを二重に開発することを避けることができる。
【００７７】
共通インタフェース２５の定義はそのサーバコンポーネントに処理を実行させるためのアクセス方式（メソッド（関数）名、引数の型や数、返り値）を定義している。クライアント側アダプタ２２（リモート接続用スタブ）は、サーバコンポーネント本体２１へのリモートの接続を行うためのスタブである。なお、以下特に断らないが、サーバコンポーネント本体２１及びクライアント側アダプタ２２には、共通インタフェース２５が必ず実装される。これにより、クライアントアプリケーション基本部１１からは共通インタフェース定義で決められているアクセス方式に従って、直接にアクセスする相手がサーバコンポーネント本体２１、又はクライアント側アダプタ２２のどちらであっても、一様にアクセスすることができるようになる。このため、クライアントホストはサーバコンポーネントの実行位置に依存すること無く、処理を実行できる。
【００７８】
分散オブジェクト間通信２３としては、どのような技術を用いてもよい。例えば、ＣＯＲＢＡ、ＪａｖａＲＭＩ、ＰＤＯ等を用いることができる。これらの実装の差異は両ホストのアダプタで吸収される。これにより、特定のオブジェクト間通信技術に依存すること無く、本システムを実装できる。また、通信の実装を変更する場合の対処も容易になる。
【００７９】
図４に示す各構成は、その全てが常に使用されるのではなく、サーバコンポーネント本体２１がクライアントホスト１又はサーバホスト２の何れで実行されるかにより、その組み合わせが動的に変更されるものである。
【００８０】
図５はサーバコンポーネント本体２１がクライアントホスト１で実行される場合と、サーバホスト２で実行される場合の構成を示す図である。
【００８１】
同図（ａ）には、サーバコンポーネント本体２１がクライアントホスト１で実行される場合を示す。この場合には、共通インターフェース２５及びサーバコンポーネント本体２１がクライアントホスト１内に設けられ、クライアントアプリケーション基本部分１１、共通インターフェース２５及びサーバコンポーネント本体２１がサーバコンポーネント５を構成する。クライアントアプリケーション基本部分１１は、共通インターフェース２５を介してサーバコンポーネント本体２１に要求を出す。
【００８２】
同図（ｂ）には、サーバコンポーネント本体２１がサーバホスト２で実行される場合を示す。この場合には、共通インターフェース２５が実装されているクライアント側アダプタ２２、サーバ側アダプタ２４及び共通インターフェース２５実装のサーバコンポーネント本体２１がサーバコンポーネント５を構成する。クライアント側アダプタ２２とサーバ側アダプタ２４とは分散オブジェクト間通信２３により接続される。クライアントアプリケーション基本部分１１は、各部２５，２２，２３，２４，２５を介してサーバホスト２に設けられたサーバコンポーネント本体２１に要求を出す。
【００８３】
なお、記憶装置４に当初格納され、また、コンポーネントマネージャ１６に管理されているサーバコンポーネント５の当初状態は図４に示した通りである。この当初状態のサーバコンポーネント５の各要素が記憶装置４から取り出され、図５（ａ），（ｂ）に示されたようにクライアントホスト１及びサーバホスト２上で処理実行機能として構成された場合も、これらは全体としてサーバコンポーネント５である。ただし、その構成要素及び構成要素のホスト１，２での配置は状況によって異なることになる。
【００８４】
さて、図２に示した各部１２，１３，１４，１５，１６，１７，１８，４は、図５に示すような動的に変更し得るサーバコンポーネント５の実行位置，具体的にはサーバコンポーネント本体２１の配置位置を決定し、図５（ａ）、（ｂ）の何れかの状態を作るための処理を行うものである。なお、コンポーネントキャッシュ１３はコンポーネントローダ１２に、実行位置決定部１５及びアクセス制御監視部１７はコンポーネントサーバ１４に本来含まれるものであるが、後の動作説明の都合上、図２ではこれらを独立した手段として示している。以下、これらの構成について説明する。
【００８５】
図６はコンポーネントローダ１２の構成例を示す図である。
【００８６】
コンポーネントローダ１２は、クライアントアプリケーション基本部分１１から生じるサーバコンポーネント５のリクエストに応じてサーバコンポーネント本体２１もしくはそれへ接続するためのクライアント側アダプタ２２（リモート接続用スタブ）を受け取る。なお、以下特に断らない限りは、サーバコンポーネント本体２１又はクライアント側アダプタ２２には、共通インタフェース２５が実装される、または既に実装されているものとする。
【００８７】
このコンポーネントローダ１２には、その機能を実現させるために、インスタンス生成部３１、コンポーネント復号化部３２、コンポーネント解凍部３３及びコンポーネントキャッシュ１３が設けられる。なお、コンポーネントキャッシュ１３は図２に示すものと同じである。
【００８８】
コンポーネントキャッシュ１３は、コンポーネントサーバ１４からクライアントホスト１へダウンロードされたサーバコンポーネント５を一時的に保管しておき、二重ロードの防止に使用される。
【００８９】
図７はコンポーネントサーバ１４の構成例を示す図である。
【００９０】
コンポーネントサーバ１４は、コンポーネントローダ１２から要求があったサーバコンポーネント５に対し、それの実行位置を実行位置決定部１５によって決定し、それに応じたサーバコンポーネント本体２１もしくはクライアント側アダプタ２２等を準備し、コンポーネントローダ１２へ返す。また、サーバホスト２側でサーバコンポーネント本体２１を実行する場合には、サーバホスト２上に必要なサーバコンポーネント本体２１等を生成する。
【００９１】
コンポーネントサーバ１４には、その機能を実現させるために、実行位置決定部１５、インスタンス生成部３６、アクセス制御監視部１７、コンポーネント暗号化部３７及びコンポーネント圧縮部３８が設けられている。なお、実行位置決定部１５及びアクセス制御監視部１７は図２に示すものと同じである。
【００９２】
実行位置決定部１５は、クライアント／サーバの両ホスト情報やネットワーク接続に関する情報、要求されたサーバコンポーネント５の情報に基づいて、そのサーバコンポーネント５をクライアント／サーバのどちらのホスト側で動作させるべきかを判断する。
【００９３】
アクセス制御部１７は、ユーザ認証部ともいい、要求があったサーバコンポーネント５に対して現在のクライアントホスト１（もしくはその使用者）が当該サーバコンポーネント５を使用可能かどうかを調べる。
【００９４】
図８はコンポーネントマネージャ１６の構成例を示す図である。
【００９５】
コンポーネントマネージャ１６は、記憶装置４とアクセス可能に構成され、サーバコンポーネント５やその情報について管理を行う。具体的にはサーバコンポーネント５の登録／削除、検索などである。
【００９６】
コンポーネントマネージャ１６には、その機能を実現させるために、コンポーネント抽出部４１、コンポーネント情報抽出部４２及びコンポーネント登録管理部４３が設けられている。
【００９７】
ネットワークモニタ１８は、サーバホスト２及びクライアントホスト１の負荷情報、サーバホスト２及びクライアントホスト１の処理能力に関する情報、ネットワークの転送速度、又はサーバコンポーネント本体２１のサイズ情報、又はサーバコンポーネント本体２１の計算量情報を取得し、実行位置決定部１５に提供する。
【００９８】
次に、以上のように構成された本発明の実施の形態に係る分散システムの動作について説明する。
【００９９】
（システム起動）
本分散システムでは、クライアントホスト１においてクライアントアプリケーション基本部分１１の起動等をいかに行うかについては特に制限していない。例えばクライアントホスト１を起動した時点で、クライアントアプリケーション基本部分１１がクライアントホスト１に既に存在していてもよく、また最初は存在せず、クライアントホスト１のユーザのリクエストによってサーバホスト２からダウンロードされアプリケーションプログラムとして起動されもよい。以下、本実施形態では既にクライアントホスト１にクライアントアプリケーション基本部分１１が存在し、アプリケーションプログラムとして起動されていることとして説明を進める。
【０１００】
ここでは、図３（ｂ）に示すように画像処理アプリケーションプログラムを例に説明する。画像処理アプリケーションプログラムは図３（ｂ）に示すような画像処理アプリケーション基本部分１１ａと平滑化処理用コンポーネント５ａの２つに分割されているものとする。
【０１０１】
画像処理アプリケーション基本部分１１ａは画像の表示、平滑化処理用コンポーネント５ａの呼び出し／利用を行う。平滑化処理用コンポーネント５ａは与えられた画像データやパラメータを基に平滑化を行う。
【０１０２】
次に図９，図１０及び図１１により図２のソフトウェア構成において、いかにサーバコンポーネント５が呼び出されるかについて説明し、また、その処理の流れを図１２〜図１５を用いて説明する。
【０１０３】
図９はサーバコンポーネント５への処理要求から実行位置の決定までの処理を示す。
【０１０４】
図１０はサーバコンポーネント５をクライアントホスト１側で実行させる場合の実行位置決定から実行までの処理を示す。
【０１０５】
図１１はサーバコンポーネント５をサーバホスト２側で実行させる場合の実行位置決定から実行までの処理を示す。
【０１０６】
図１２はサーバコンポーネント５への処理要求から処理実行までの処理全体を示す流れ図である。
【０１０７】
図１３は図１２におけるリモートでサーバ本体２１を使用するための処理を示す流れ図である。
【０１０８】
図１４は図１２におけるコンポーネントローダ１２がコンポーネントを受け取る処理を示す流れ図である。
【０１０９】
図１５は図１２におけるコンポーネントキャッシュ１３に存在するコンポーネントを使用するための処理を示す流れ図である。
【０１１０】
（サーバコンポーネント要求から実行位置の決定まで）
この処理を図９及び図１２を用いて説明する。
【０１１１】
（１）クライアントアプリケーションプログラムのユーザはクライアントアプリケーション基本部分１１を通じて希望するサーバコンポーネント５の提供する処理の実行を命ずる（図９の信号ａ）。
【０１１２】
（２）クライアントアプリケーション基本部分１１はコンポーネントローダ１２に対して指定されたサーバコンポーネント５の要求を行う（図９の信号ｂ，図１２のステップＳＴ１）。
【０１１３】
（３）コンポーネントローダ１２は要求のあったサーバコンポーネント５がコンポーネントキャッシュ１３に既にロードされているかどうかを確認し（図９の信号ｃ，図１２のステップＳＴ２）、まだロードしていなければ、リモートのサーバホスト２に存在するコンポーネントサーバ１４と通信を行い、指定されたサーバコンポーネント５の要求を行う（図９の信号ｄ，図１２のステップＳＴ３）。その際、クライアントホスト１のロードアベレージやメモリ残量、スワップの可否などの情報（クライアントホスト情報）を生成し、コンポーネントサーバ１４へ通知する（図９の信号ｄ’）。なお、既にロードしているサーバコンポーネント５であった場合は後述する（図１２のステップＳＴ１０，図１５）。
【０１１４】
（４）コンポーネントサーバ５はサーバホスト２の情報（サーバホスト情報）や接続しているネットワークに関する情報をネットワークモニタ１８から収集する（図９の信号ｅ）。ネットワークモニタ１８は、例えば回線その使用量、トラフィック等に基づくその時点でのネットワーク情報や、ネットワークカードのＩＤでわかる回線速度等の機器性能を調べることで上記ネットワークに関する情報を収集する。また、当該情報はシステム管理者が事前に設定したものでもよい。
【０１１５】
コンポーネントサーバ５は、実行位置決定部１５に対して収集されたネットワーク情報を通知するとともに、指定されたサーバコンポーネント５をクライアント／サーバのどちらのホストで実行すべきかを問い合わせる（図９の信号ｆ）。
【０１１６】
（５）実行位置決定部１５は先ず、アクセス制御監視部１７により指定されたサーバコンポーネント５について、その要求してきたクライアントホスト１（もしくはそのユーザ）によるそのサーバコンポーネント５の使用の可否や使用上の制限などがあるか否かを調べる（図９の信号ｇ）。アクセス制御監視部１７は、使用上の制限でクライアント側もしくはサーバ側での実行が強制される場合にはその旨をコンポーネントサーバ１４へ通知する。この場合は、クライアントホスト１（もしくはそのユーザ）は当該サーバコンポーネント５の使用資格を有しない場合であるので、以下の処理は行われない。
【０１１７】
（６）次に、使用可能であった場合に、実行位置決定部１５はコンポーネントサーバ１４から渡された両ホストの情報、ネットワーク情報に加え、コンポーネントマネージャ１６から指定されたサーバコンポーネント５に関する情報（サーバコンポーネント情報）を入手し、これらの情報を基に、指定されたサーバコンポーネント５がクライアント／サーバのどちらのホストで動作すべきかを決定する（図９の信号ｈ，図１２のステップＳＴ４）。なお、決定アルゴリズムとしては種々のものが考えられるが、その例については後述する。その後、決定した実行位置をコンポーネントサーバ１４へ通知する（図９の信号ｉ，図１２のステップＳＴ５）。
【０１１８】
以上の処理を画像処理アプリケーションプログラムの例に適合させて説明すると、次のようになる。先ず画像処理アプリケーション基本部分１１ａが画像を表示している状態で、ユーザが画像処理アプリケーション基本部分１１ａに対して平滑化処理を命じる。すると、画像処理アプリケーション基本部分１１ａはコンポーネントローダ１２に対して平滑化処理用コンポーネント５ａの要求を行う。コンポーネントローダ１２はクライアントホスト情報を入手後、コンポーネントサーバ１４へ平滑化処理用コンポーネント５ａを要求する。コンポーネントサーバ１４はサーバホスト情報、ネットワーク情報を収集し、実行位置決定部１５に対して平滑化処理用コンポーネント５ａの実行位置を問い合わせる。実行位置決定部１５はコンポーネントマネージャ１６から、平滑化処理用コンポーネント５ａのコンポーネント情報を入手後、各情報を基に実行位置を決定し、コンポーネントサーバ１４へ通知する。
【０１１９】
次に、実行位置決定部１５における実行位置の決定アルゴリズムについて説明する。
【０１２０】
スループット向上を目的にした場合、クライアント／サーバの両ホストの情報、ネットワークの転送速度、サーバコンポーネントに関する情報を用いて判断する。すなわち、クライアントホスト１でサーバコンポーネント本体２１を実行した場合と、サーバホスト２でサーバコンポーネント本体２１を実行した場合とで、それぞれで必要と考えられる処理時間を計算（予想）し、処理時間が小さくなるほうでサーバコンポーネント本体２１を実行するように判断する。
【０１２１】
画像処理アプリケーションプログラムの例では、ユーザ要求から平滑化対象となる画像データのデータサイズ（転送量）が渡されるとすると、例えば、処理の予想時間は以下の計算式により計算することにする。
【０１２２】
Ｔ＝ｈｐｔ（ｈｗ，ｃｐ，ｃｃ）＋ｈｓｔ（ｈｍ，ｃｓ，ｄｓ，ｈｓｃ）＋ｎｔｔ（ｄｓ，ｔｓ） …（１）
Ｔは処理予想時間、関数ｈｐｔはそのホストの現在の負荷ｈｗと計算能力ｃｐ及びサーバコンポーネントの計算量ｃｃから得られる処理時間を返す関数、関数ｈｓｔはメモリ残量ｈｍ、コンポーネントサイズｃｓ、処理データサイズｄｓ及びスワップに必要なコストｈｓｃから計算されるスワップが生じた場合のそれに要する時間を返す関数、関数ｎｔｔは処理データサイズ（サーバホスト側で実行する場合；返り値も同サイズである場合は２倍にしておく）もしくはコンポーネントサイズ（クライアント側で実行する場合）ｄｓ及びネットワークの転送速度ｔｓから計算される転送に要する時間を返す関数である。上記Ｔを両ホストで実行した場合を計算し、値が小さいほうで処理を実行することにする。
【０１２３】
この他の判断手法として、従量制ネットワークにおいて課金を最も少なくするようにデータの転送量で実行位置を判断したり、コンポーネント開発者の意志や、クライアントホストの環境による必然性などから、ある条件においては定位置で実行するなどの判断を行うことが可能である。もちろん、スループットを向上させる場合にも、他の値を用いて計算することもあると考えられる。
【０１２４】
（クライアント側で実行すると決定した場合の処理）
次に、サーバコンポーネント５をクライアントホスト１側で動作させることを決定した場合の一連の処理を、図１０及び図１２並びに図１４を用いて説明する。
【０１２５】
（１）実行位置決定部１５からの決定通知（図９の信号ｉ）を受けたコンポーネントサーバ１４は、コンポーネントマネージャ１６から指定されたサーバコンポーネント本体２１（実行可能なオブジェクトのデータ）を記憶装置４から受け取る（図１０の信号ｊ）。
【０１２６】
（２）コンポーネントサーバ１４は、サーバホスト２から要求を発したコンポーネントローダ１２へ、サーバコンポーネント本体２１をサーバコンポーネント５として送る（図１０の信号ｋ，図１２のステップＳＴ６）。
【０１２７】
（３）クライアントホスト１上のコンポーネントローダ１２は、得られたサーバコンポーネント本体２１から実行可能なサーバコンポーネントオブジェクトを生成し（図１０の信号ｌ，図１２のステップＳＴ７，図１４のステップＳＴ１２）、クライアントアプリケーション基本部分１１にそのポインタを渡す（図１０の信号ｍ，図１２のステップＳＴ７，図１４のステップＳＴ１３）。これによりクライアントアプリケーション基本部分１１は、サーバコンポーネント本体２１にその処理を実行させることができるようになる。なお、サーバコンポーネント本体２１には共通インターフェース２５が実装されている。また、同一のサーバコンポーネントの二重ロード防止のため、コンポーネントローダ１２は、受け取ったサーバコンポーネント５を、その受け取りと同時にコンポーネントキャッシュ１３に保存する（図１０の信号ｎ，図１２のステップＳＴ７，図１４のステップＳＴ１１）。
【０１２８】
（４）クライアントアプリケーション基本部分１１は、渡されたサーバコンポーネント本体２１を利用し、ユーザが指定した処理を実行する（図１０の信号ｏ，図１２のステップＳＴ８）。
【０１２９】
以上の処理を画像処理アプリケーションプログラムの例に適合させて説明すると、以下のようになる。
【０１３０】
先ず、コンポーネントサーバ１４が平滑処理用コンポーネント５ａの本体のバイト列をコンポーネントマネージャ１６を介して記憶装置４から受け取り、それをコンポーネントローダ１２へ送る。コンポーネントローダ１２は受け取ったバイト列を基に実行可能なオブジェクト（サーバコンポーネント２１）を生成し、そのポインタを画像処理アプリケーション基本部１１ａへ渡す。画像処理アプリケーション基本部１１ａは受け取った平滑化処理用コンポーネント５ａのオブジェクトの平滑化処理メソッドを呼出すことで、平滑化処理を行う。
【０１３１】
（サーバ側で実行すると決定した場合の処理）
次に、サーバコンポーネント５をサーバホスト２側で動作させることを決定した場合の一連の処理を、図１１及び図１２並びに図１３，図１４を用いて説明する。
【０１３２】
（１）実行位置決定部１５からの決定通知（図９の信号ｉ）を受けたコンポーネントサーバ１４は、コンポーネントマネージャ１６から指定されたサーバコンポーネント５のクライアント側アダプタ２２（リモート接続用スタブ）とサーバコンポーネント本体２１等を受け取る（図１１の信号ｐ）。
【０１３３】
（２）コンポーネントサーバ１４は、サーバホスト２上でサーバコンポーネント本体２１から実行可能なサーバコンポーネントオブジェクトを生成する（図１１の信号ｑ，図１２のステップＳＴ９，図１３のステップＳＴ２１）。
【０１３４】
（３）コンポーネントサーバ１４は、使用する分散オブジェクト間通信技術（Ｊａｖａ，ＣＯＲＶＡ等）に応じた準備を行う（図１１の信号ｒ，図１２のステップＳＴ９，図１３のステップＳＴ２２）。このために、サーバ側アダプタ２４についてのオブジェクトを生成し、分散オブジェクト間通信が可能となる処理を行う。
【０１３５】
（４）次に、コンポーネントサーバ１４は、サーバホスト２から要求を発したコンポーネントローダ１２へクライアント側アダプタ２２をサーバコンポーネント５として送る（図１１の信号ｓ，図１２のステップＳＴ９，図１３のステップＳＴ２３）。また二重ロード防止のため、クライアントホスト１のコンポーネントローダ１２は、その受け取り同時にこのサーバコンポーネント５をコンポーネントキャッシュ１３に保存する（図１１の信号ｔ，図１２のステップＳＴ７，図１４のステップＳＴ１１）。
【０１３６】
（５）コンポーネントローダ１２は、受け取ったクライアント側アダプタ２２を実行可能なスタブオブジェクトを生成する（図１１の信号ｕ，図１２のステップＳＴ７，図１４のステップＳＴ１２）。
【０１３７】
（６）コンポーネントローダ１２は、生成したスタブオブジェクトのポインタをクライアントアプリーション基本部分１１に引き渡す（図１１の信号ｖ，図１２のステップＳＴ７，図１４のステップＳＴ１３）。
【０１３８】
（７）こうしてクライアントアプリーション基本部分１１は、クライアント側アダプタ２２であるスタブオブジェクトを通し、サーバホスト２上に生成されたリモートのサーバコンポーネント本体２１にアクセスし、処理を実行する（図１１の信号ｗ，図１２のステップＳＴ８）。
【０１３９】
以上の処理を画像処理アプリケーションプログラムの例に適合させて説明すると、以下のようになる。
【０１４０】
先ず、コンポーネントサーバ１４が平滑化処理用コンポーネントのスタブ２２と本体２１のバイト列をコンポーネントマネージャ１６から受け取る。サーバホスト側で平滑化処理を行う本体２１からオブジェクト２１，２５を生成し、リモートの呼び出しを受け付けられるよう、既存の分散オブジェクト間通信技術を用いて、サーバオブジェクトとして登録する。また、スタブ２２はそのままコンポーネントローダ１２へ送られる。コンポーネントローダ１２は受け取ったスタブ２２からオブジェクト２２，２５を生成する。生成されたスタブオブジェクト２２，２５はその生成／初期化の段階でサーバホスト上の本体２１，２５と接続を行う。生成されたスタブ２２，２５は画像処理アプリケーション基本部分１１ａへ渡される。画像処理アプリケーション基本部分１１ａはこのスタブ２２，２５を介して平滑化処理を行うリモートのオブジェクト５ａ（２１，２５）へアクセスし、処理を行う。
【０１４１】
（コンポーネントキャッシュにサーバコンポーネントがある場合の処理）
一度、クライアントホスト１側でサーバコンポーネント本体２１、もしくはクライアント側アダプタ２２を生成した後は、そのクライアントプロセスが終了するまで、もしくはサーバホスト２からロードしたオブジェクトを破棄するまで、そのオブジェクトは何度でも再利用することは可能である。すなわち図１２のステップＳＴ２でステップＳＴ１０に進む場合である。この場合は処理のたびにサーバホスト２からサーバコンポーネント５を再ロードする必要はない。
【０１４２】
具体的には次の手順に従う。
【０１４３】
（１）クライアントアプリケーション基本部分１１がサーバコンポーネント５の要求をコンポーネントローダ１２へ送る（図９の信号ｂ，図１２のステップＳＴ１）。
【０１４４】
（２）コンポーネントローダ１２は指定されたサーバコンポーネント５が既にロードされているかをコンポーネントキャッシュ１３に問い合わせる（図９の信号ｃ，図１２のステップＳＴ２，ＳＴ１０，図１５のステップＳＴ３１）。
【０１４５】
（３）既にロードされていた場合は、その情報を基にオブジェクトを生成し（図１０の信号ｌまたは図１１の信号ｕ，図１２のステップＳＴ１０，図１５のステップＳＴ３２）、クライアントアプリケーション基本部分１１へ返す（図１０の信号ｍまたは図１１の信号ｖ，図１２のステップＳＴ１０，図１５のステップＳＴ３３）。
【０１４６】
（４）クライアントアプリケーション基本部分１１は返されたオブジェクトを利用して所望の処理を行う（図１０の信号ｏまたは図１１の信号ｗ，図１２のステップＳＴ８）。
【０１４７】
上述したように、本発明の第１の実施の形態に係る分散システムは、クライアントアプリケーション基本部分１１が要求する処理を実行するサーバコンポーネント本体２１と、分散オブジェクト間通信２３により互いに接続されるクライアント側アダプタ２２、サーバ側アダプタ２４とからなるサーバコンポーネント５を設け、クライアントアプリケーション基本部分１１の要求に応じて実行位置決定部１５がクライアント／サーバのいずれのホストでサーバコンポーネント本体２１を処理するかを判断して、その判断結果に応じたホストでサーバコンポーネント本体２１による処理を実行するようにしたので、処理の実行場所を動的に切り替えることが可能になり、システムの柔軟性を向上させることができる。
【０１４８】
また、実行位置決定部１５は、ネットワークモニタ１８からのハードウエアやネットワーク状況等の情報に基づき実行位置を決定するので、クライアントホスト１からの処理要求に対し、処理結果が速く得られるようにサーバコンポーネント５の実行位置を切り替えることができる。これにより、スループットを向上させることができる。
【０１４９】
さらに、アクセス制御監視部１７を設け、クライアントのユーザ情報やクライアントホスト情報に基づいて、要求を行うクライアントアプリケーション基本部分１１に要求権限があるか否かを判断することができ、サーバコンポーネント５へのアクセスを制御することができる。
【０１５０】
また、要求される処理の実装はサーバコンポーネント本体２１に対してのみ、すなわち１か所に行われるので、サーバコンポーネント開発者は同一の実装を２重に行なう必要が無くなる。つまり、要求処理の動的変更システムを構築する上で、サーバホスト側実行用，クライアントホスト側実行用を分けてプログラムを開発する必要をなくすことができる。
【０１５１】
また、サーバコンポーネント本体２１とクライアント側アダプタ２４が共通のインタフェース２５を実装しているため、クライアントホスト１から両者に対して一様にアクセスすることができる。したがって、プログラム（プロセス）構成を簡易なものとし、その分高速化を図ることもできる。
【０１５２】
さらに、サーバコンポーネント本体２１をクライアントホスト側で実行する場合は、クライアントアプリケーション基本部分１１とサーバコンポーネント本体２１の間に通信のためのアダプタが不要であるので、処理要求におけるオーバーヘッドをなくすことができる。
【０１５３】
なお、本実施形態では、クライアントホスト１とサーバホスト２が一つづつある場合を例にとって説明したが、サーバ側ではクラスタ，すなわちネットワーク内にサーバホストが複数存在するようなマルチサーバ環境において負荷分散や集中管理などを行うための仮想システム等を利用することで、実際には複数のホストを実行位置の対象とすることができる。
【０１５４】
なお、ここでサーバホストと呼んでいるのはクライアントホスト以外のホストを指している。すなわち、本実施形態の場合、クライアントアプリケーション基本部分１１が存在して、処理の要求を発するホストがクライアントホスト１であり、クライアントホスト以外でその処理を実行するホストのことをサーバホスト２と呼ぶ。従って、一般に、端末として呼ばれるクライアントホストは本実施形態のクライアントホストとは必ずしも対応しない。
【０１５５】
なお、本実施形態では、実行位置の決定を自動で行う場合を説明したが、予め実行位置の設定をしておくことで、事実上サーバコンポーネント本体２１の実行位置の設定を手動で行うこともできる。また、これらの両方を混在させることも可能である。
【０１５６】
なお、上記各効果は、その機能構成が重複する部分については以下の各実施形態あるいは各実施形態においても同様に奏されるものである。
【０１５７】
（第２実施形態）
本実施形態は第１実施形態におけるサーバコンポーネント５の構成に改良を加えるものであり、その他の部分は第１実施形態と同様である。したがって、図１〜図１５と同一部分には同一符号を付してその詳細説明を省略する。
【０１５８】
すなわち、図４に示した第１実施形態のサーバコンポーネント５は、発明を実現するための基本的な構成である。しかし、かかる基本的なコンポーネント構成によっては、場合により必要な当該サーバコンポーネント本体２１が果たすべき機能を実現できないことがある。第１実施形態では実現できないことは、ホストリソースへアクセスするコンポーネントと、クライアント側のアプリケーションプログラムと非同期に通信するコンポーネント（コンポーネントからクライアント側のアプリケーションプログラムへ通信する）である。
【０１５９】
ホストリソースへアクセスするサーバコンポーネント５としては次の２つがある。１つはクライアントホストのリソース（画面表示（ＧＵＩ）やローカルのファイルシステム等）へアクセスするサーバコンポーネントであり、もう１つはサーバホスト２やさらにそのバックに存在するリソース（サーバ側のファイルシステムやデータベース等）へアクセスするサーバコンポーネントである。
【０１６０】
例えばＧＵＩを表示するサーバコンポーネント５であれば、サーバコンポーネント本体２１がサーバホスト２にあろうとクライアントホスト１にあろうと、ＧＵＩはクライアントホスト１に表示しなければならない。このような問題を解決するためには、クライアントリソースへアクセスする部分はサーバコンポーネント本体２１の位置に関わらず、クライアントホスト１側へ移動させなければならない。
【０１６１】
また、例えばサーバホスト２側のデータベースマネンジメントシステムへ接続しているようなサーバコンポーネント５であれば、たとえサーバコンポーネント本体２１がクライアントホスト１ヘ送られた場合でも、データベースマネンジメントシステムとやり取りする部分はサーバホスト２ヘ残ってデータベースマネンジメントシステムとやり取りができる状態を保たなければならない。
【０１６２】
このような条件を考えると上記した場合のサーバコンポーネント本体は、本来の機能実行部分（第１実施形態のサーバコンポーネント本体２１）と、クライアントリソースにアクセスする部分及び／又はサーバ（もしくはそれ以降の）リソースヘアクセスする部分とに分割した構成とする必要がある。この点を考慮して本実施形態では、サーバコンポーネント５を図１６に示すような構成としている。
【０１６３】
図１６は本発明の第２実施の形態におけるサーバコンポーネント５の構成例を示す図である。
【０１６４】
このサーバコンポーネント５は、図４に示した構成に加えて、クライアントリソース対応部５１と、サーバリソース対応部５２が付加される。
【０１６５】
ここで、クライアントリソース対応部５１は、クライアントリソースアクセス部５３からなる。一方、サーバリソース対応部５２は、サーバリソースアクセス用クライアント側アダプタ５４と、サーバリソースアクセス用サーバ側アダプタ５６と、サーバリソースアクセス部５７とからなり、サーバリソースアクセス用クライアント側アダプタ５４とサーバリソースアクセス用サーバ側アダプタ５６とは分散オブジェクト間通信５５を介して接続される。なお、サーバリソースアクセス用クライアント側アダプタ５４及びサーバリソースアクセス部５７にはサーバリソースアクセス部共通インタフェース５８が実装される。
【０１６６】
クライアントリソースアクセス部５３は、クライアントホスト１のリソースにアクセスするための処理を行う。サーバリソースアクセス部５７は、サーバホスト２のリソースにアクセスするための処理を行う。サーバリソースアクセス用クライアント側アダプタ５４及びサーバリソースアクセス用サーバ側アダプタ５６は、分散オブジェクト間通信５５を行うためのアダプタである。
【０１６７】
このように第２実施形態では、サーバコンポーネント本体５をクライアントリソースにアクセスする部分（クライアントアプリケーションへの非同期通信も含む）と、サーバリソースにアクセスする部分と、どちらでも動作可能な部分に３分割されている。
【０１６８】
本実施形態では、記憶装置４に格納されるサーバコンポーネント５は、図１６に示すようなものとなるが、図２に示す各処理は第１実施形態の場合と同様である。図２に示す各部は、クライアントホスト側、サーバホスト側のいずれかでサーバコンポーネント本体２１を実行するにあたって、本実施形態でサーバコンポーネント５に新たに付加された部分の移動やその対応するオブジェクトの発生が必要となる点でのみ異なる。
【０１６９】
次に、以上のように構成された本発明の実施の形態に係る分散システムの動作について説明する。
【０１７０】
（サーバ側で処理を行う場合）
図１７はサーバコンポーネント本体２１をサーバホスト２側で動作させる場合のサーバコンポーネント５の構成を示す図である。
【０１７１】
サーバコンポーネント本体２１をサーバホスト２側で動作させる場合には、クライアントホスト１側ヘはクライアント側アダプタ２２とクライアントリソースアクセス部５７がコンポーネントサーバ１４によって送られる。クライアントリソースアクセス部５７はクライアントホスト１側でコンポーネントローダ１２によりインスタンス化された後、コンポーネントローダ１２からサーバコンポーネント本体２１へ参照渡し（ポインタの引き渡し）される。
【０１７２】
サーバホスト２側ではサーバコンポーネント本体２１が直接サーバリソースアクセス部５７を保持し、やりとりを行うこととなる。
【０１７３】
なお、パフォーマンスを考慮して、クライアント側アダプタ２２が直接クライアントリソースアクセス部５３とやり取りする場合も考えられる。
【０１７４】
（クライアント側で処理を行う場合）
図１８はサーバコンポーネント本体をクライアントホスト１側で動作させる場合のサーバコンポーネントの構成を示す図である。
【０１７５】
次に、サーバコンポーネント本体２１をクライアントホスト１側で動作させる場合には、クライアントホスト１側へはサーバコンポーネント本体２１とクライアントリソースアクセス部５３、サーバリソースアクセス用クライアント側アダプタ５４がコンポーネントサーバ１４によって送られる。
【０１７６】
このときクライアントホスト１側で生成されたサーバコンポーネント本体２１はクライアントリソースを直接所持する。また、サーバリソースアクセス部５７はサーバホスト２側に残る必要がある。そのため、サーバコンポーネント本体２１とサーバリソースアクセス部５７の間を分散オブジェクト間通信５５を行うために、図５（ｂ）の場合におけるサーバコンポーネント５の構成と似たような構造を設ける。すなわち、図１８に示すように、サーバリソースアクセス用のアダプタ５４，５６をサーバ側／クライアント側のホストに用意し使用する。
【０１７７】
サーバコンポーネント本体２１からみた場合、サーバリソースアクセス用クライアント側アダプタ５４とサーバリソースアクセス部５７は一様の手順でアクセスできるべきであるので、それぞれはサーバリソースアクセス用の共通インタフェース５８を実装することにし、サーバコンポーネント５はこれら要素をサーバリソースアクセス用共通インタフェースの型として保持することとする。
【０１７８】
また同様に、クライアントリソースアクセス部５３はサーバコンポーネント本体２１とクライアント側アダプタ２２を一様にアクセスできるようにするため、これらを共通インタフェースの型として保持することにする。
【０１７９】
これらの所有関係は、各要素がコンポーネントローダ１２やサーバコンポーネント１４により、実行可能な状態にされる際の初期化によって実現される。このようにして図１７又は図１８に示す構成により、各ホスト１，２のリソースへアクセスするできるサーバコンポーネント５が実現される。
【０１８０】
上述したように、本発明の第２実施形態に係る分散システムは、第１実施形態と同様な構成に加えて、サーバコンポーネント５に、クライアントリソースアクセス部５３、サーバリソースアクセス用クライアント側アダプタ５４、分散オブジェクト間通信５５、サーバリソースアクセス用サーバ側アダプタ５６及びサーバリソースアクセス部５７を設け、サーバコンポーネント本体２１がクライアント／サーバいずれの側のホストにあるときでも、クライアント／サーバのリソースにアクセスできるようにしたので、第１実施形態と同様な効果が得られるとともに、アプリケーション基本部分１１に依頼される形式の処理のみでなく、ＧＵＩやデータベースアクセス等、クライアント／サーバのリソースにアクセスしないと実行できないような処理もサーバコンポーネント５により実現することができる。
【０１８１】
なお、上記の構成においても分散オブジェクト間通信については種々の技術を適用することができる。ＪａｖａとＲＭＩを用いる場合には分散オブジェクト間通信のサーバとなるオブジェクトはｊａｖａ．ｒｍｉ．Ｒｅｍｏｔｅを継承する必要がある。
【０１８２】
また、本実施形態で示したクライアントリソース対応部５１、サーバリソース対応部５２についてはそのコンポーネントにおいて必要な場合にのみ基本部分へ付加すればよい。これらが不要な場合はそれぞれ省略できる。
【０１８３】
（第３実施形態）
本実施形態は第２実施形態におけるサーバコンポーネント５の構成に改良を加えるものであり、その他の部分は第２実施形態と同様である。したがって、図１〜図１８と同一部分には同一符号を付してその詳細説明を省略する。
【０１８４】
第２実施形態によれば、各ホスト１，２のリソースヘアクセスするようなサーバコンボーネントも実現可能となる。しかし、これを実現するためには、クライアントホスト１からサーバホスト２への参照渡し（ポインタの引き渡し）ができることが必要である。参照渡しができないような分散環境では別の手段（コンポーネント構成）を考えなければならない。そうしなければ、図１７の場合にサーバコンボーネン卜本体２１からクライアントリソースアクセス部５３ヘメッセージを送ることができず、実現可能な処理の種類が限定される。
【０１８５】
本実施形態は、このような事情を考慮してサーバコンポーネント５の構成を改良したものである。
【０１８６】
図１９は本発明の第３実施形態におけるサーバコンポーネント５の構成例を示す図である。
【０１８７】
このサーバコンポーネント５は、クライアントリソース対応部５１の構成に変更が加えられる以外は、図１６に示す第２実施形態のサーバコンポーネント５と同様に構成されている。
【０１８８】
ここで、クライアントリソース対応部５１は、第２実施形態と同様なクライアントリソースアクセス部５３と、クライアントリソースアクセス用クライアント側アダプタ６１と、クライアントリソースアクセス用サーバ側アダプタ６３とからなり、クライアントリソースアクセス用のクライアント側アダプタ６１とサーバ側アダプタ６３とは分散オブジェクト間通信６２により接続される。なお、クライアントリソースアクセス用サーバ側アダプタ６３及びクライアントリソースアクセス部５３にはクライアントリソースアクセス部共通インタフェース６４が実装される。
【０１８９】
クライアントリソースアクセス部５３は、第２実施形態と同様にクライアントホスト１のリソースにアクセスするための処理を行う。クライアントリソースアクセス用クライアント側アダプタ６１及びクライアントリソースアクセス用サーバ側アダプタ６３は、分散オブジェクト間通信６２を行うためのアダプタである。
【０１９０】
次に、以上のように構成された本発明の第３実施形態に係る分散システムの動作について説明する。
【０１９１】
図２０はサーバコンポーネント本体をサーバホスト２側で動作させる場合のサーバコンポーネントの構成を示す図である。
【０１９２】
このようなサーバコンポーネント構成を生成する手続きは、第１及び第２実施形態の場合と同様である。ただし、本実施形態の場合は、クライアントリソースアクセス部５３からサーバコンポーネント本体２１への参照渡しは行われない。
【０１９３】
つまり、クライアントリソースアクセス部５３はサーバコンポーネント本体２１と両アダプタ６１，６３を介し分散環オブジェクト間通信６２を介してのみ関連する。したがって、たとえクライアントリソースアクセス部５３からサーバコンポーネント本体２１に参照渡しができなくても、両者間の通信が実現される。
【０１９４】
また、サーバコンポーネント本体２１をクライアントホスト１側で動作させる場合には、ホスト１，２間での参照渡しの問題は生じない。したがって、サーバコンポーネント５の構成は、第２実施形態における図１８の場合と同じになる。
【０１９５】
上述したように、本発明の第３実施形態に係る分散システムは、第１実施形態と同様な構成に加えて、クライアントリソースアクセス用クライアント側アダプタ６１、分散オブジェクト間通信６２及びクライアントリソースアクセス用サーバ側アダプタ６３を設けたので、第１実施形態と同様な効果が得られる他に、サーバコンポーネント本体２１がサーバホスト２側にある場合に、分散オブジェクト間通信６２でたとえ参照渡しができなくても、サーバコンポーネント本体２１〜クライアントアクセスリソース部５３間で通信を行うことができ、クライアントリソースにアクセスすることができる。したがって、サーバコンポーネント５を利用するシステムの適用範囲が一層向上する。
【０１９６】
このような構成にすることで、参照渡しできない場合にクライアントリソースアクセス部５３に設けられるべき処理をも、サーバコンポーネント本体２１に集中させることが可能になるため、サーバコンポーネント５の開発容易性が一層向上する。
【０１９７】
（第４実施形態）
図２１（ａ）は、図４に示した基本的なサーバコンポーネント５を、図３（ｂ）に示すような画像処理アプリケーションプログラムに適用した場合の例である。この例は、プログラミング言語としては仮想言語Ｊを用い、通信は仮想分散オブジェクト技術Ｊ ＲＭＩを用いる。
【０１９８】
（第５実施形態）
図２１（ｂ）は、画像処理アプリケーションプログラムに限らず一般のアプリケーションプログラムに適用した例である。第４実施形態と異なり、プログラミング言語としてはＪａｖａを用い、通信は分散オブジェクト間通信技術Ｊａｖａ
ＲＭＩを用いる。
【０１９９】
（第６実施形態）
図２１（ｃ）は、図１６に示した第２実施形態の（サーバ／クライアントへのリソースアクセスを可能とした）サーバコンポーネント５に対応するものである。この例は、プログラミング言語としてはＪａｖａを用い、通信は分散オブジェクト間通信技術Ｊａｖａ ＲＭＩを用いる。
【０２００】
（第７実施形態）
上記各実施形態では、サーバコンポーネント５を使用してサーバコンポーネント本体２１の実行位置をクライアントホスト１〜サーバホスト２間で動的に変更できる分散システム並びにそのシステムで使用されるサーバコンポーネント５の構成について説明してきた。しかし、ソフトウエア開発者がサーバコンポーネント５を作成するに当たっては多数の構成要素（ファイル）を開発する必要がある。
【０２０１】
本実施形態では、このサーバコンポーネント５の各ファイルを自動生成することで開発者の負担を少なくする技術について説明する。ここでは、生成するサーバコンポーネント５としては、図２１（ｂ）に示す第５実施形態を例にとって説明する。なお、本実施形態においても、上記各実施形態の各図におけるものと同一な構成部分については同一符号を付し、説明を省略する。
【０２０２】
図２１（ｂ）の場合、サーバコンポーネント５の構成要素として、共通インターフェース２５、クライアント側アダプタ２２、サーバ側アダプタ２４、サーバコンポーネント本体２１及びＲＭＩ用インタフェース２４ａの５つのクラスファイルを作成し、記憶装置４に登録する必要がある。
【０２０３】
図２２は本発明の第７実施形態に係るサーバコンポーネント自動生成システムの構成例を示すブロック図である。
【０２０４】
このサーバコンポーネント自動生成システムは、開発用計算機７１に、情報提供部７２、テンプレート提供部７３、クラスファイル自動生成部７４、クラスファイル部７５、本体処理内容作成部７６及び本体処理内容提供部７７が設けられて構成されている。
【０２０５】
情報提供部７２は、クラス名やメゾット名等のサーバコンポーネント５に関する各情報を格納し、これをクラスファイル自動生成部２４に入力するようになっている。
【０２０６】
テンプレート提供部７３は、例えば図２３〜図２７に示す共通インターフェース２５、クライアント側アダプタ２２、サーバ側アダプタ２４、サーバコンポーネント本体２１及びＲＭＩ用インタフェース２４ａの５つのクラス／インターフェースに対応するテンプレートを保持し、そのテンプレートをクラスファイル自動生成部２４に提供する。なお、図２３〜図２７は、そのテンプレートを基に作成されたクラス／インタフェースの例である。
【０２０７】
図２３は本実施形態におけるＪａｖａによる共通インタフェースの一例を示す図である。
【０２０８】
図２４は本実施形態におけるＪａｖａによるサーバコンポーネント本体２１の一例を示す図である。
【０２０９】
図２５は本実施形態におけるＪａｖａによるサーバ側アダプタクラスの一例を示す図である。
【０２１０】
図２６は本実施形態におけるＪａｖａによるサーバ側アダプタクラスのＲＭＩ用インタフェースの一例を示す図である。
【０２１１】
図２７は本実施形態におけるＪａｖａによるクライアント側アダプタの一例を示す図である。
【０２１２】
クラスファイル自動生成部７４は、情報提供部７２及びテンプレート提供部７３からの提供情報に基づき、上記５つの各クラスファイルを生成し、クラスファイル部７５に出力する。この時点で出力されるクラスファイルには、サーバコンポーネント本体２１の実体的な処理内容（処理ロジック）は実装されていない。
【０２１３】
本体処理内容作成部７６は、この実体的な処理内容，すなわち本体処理内容を作成するための処理部である。
【０２１４】
本体処理内容提供部７７は、本体処理内容作成部７６で作成された本体処理内容を、クラスファイル部７５の各クラスファイルのうち、サーバコンポーネント本体２１に対応するものに実装する。
【０２１５】
また、図示しない登録手段は、こうして作成された各クラスファイルをサーバコンポーネント５の構成要素として、記憶装置４に登録する。
【０２１６】
次に、以上のように構成された本発明の実施の形態に係るサーバコンポーネント自動生成システムの動作について説明する。
【０２１７】
先ず、図２２及び図２３〜図２７を用いて本実施形態の概念的な動作を説明する。
【０２１８】
サーバコンボーネント本体２１の本体処理内容を除くと他のクラス／インタフェースは単にメソッドコールをリレーしているだけであるため、サーバコンポーネント本体２１以外のクラス／インタフェースは以下のようにすることで自動生成することが可能である。
【０２１９】
クラス名については予め定めた命名規約に従ってサーバコンボーネント本体２１のクラス名から自動的に決定することができる。
【０２２０】
また、メソッドについては両アダプタ２２，２３は基本的に中継するだけの存在であるので、クライアント側アダプタ２２はサーバ側アダプタ２３のメソッド、サーバ側アダプタ２３はサーバコンボーネント本体２１のメソッドを呼出すようにする。ここで注意しなければならないことは返り値についてである。ｖｏｉｄ以外で宣言されたメソッドについては，中継メソッドの結果をｒｅｔｕｒｎ（リターン）するように定義する必要がある。ｖｏｉｄ宣言されたメソッドについては特になにもリターンする必要はない。
【０２２１】
なお、１つのサーバコンボーネント５が複数のメソッドを提供することは可能である。
【０２２２】
以上により、サーバコンボーネント５のサーバコンボーネント本体２１のクラス名及びメソッドに関する情報が情報提供部７２から与えられ、さらに図２３〜図２７に示した各リストＬ−１〜Ｌ−５に対応する各テンプレートがテンプレート提供部７３から与えられることによって、クラスファイル自動生成部７４は上記５つのクラス全てを自動生成することが可能となる。
【０２２３】
図２２はこの概念を図で表したものでもある。例えば図２３〜図２７に示す例では、クラス名がＦｏｏ、メソッドは１つで、メソッド名がｆｏｏＭｅｔｈｏｄ、引数の型がｃｈａｒ、引数名がｃ，返り値の型がｉｎｔである。
【０２２４】
ただし，本来の処理ロジックである本体処理内容は当然開発者がコーディングすることになる。このため、開発用計算機７１には、本体処理内容作成部７６が設けられている。さらに本体処理内容提供部７７によってその作成された本体処理内容がサーバコンポーネント本体２１のクラスファイルに実装される。
【０２２５】
最終的には、上記で作成したものすべてが、コンポーネントマネージャ１６（ハードウエア的には記憶装置４）へ登録される。この際、必要に応じてコンポーネント情報やアクセス制御のための情報等が併せて登録される。
【０２２６】
次に、流れ図を用いて上記Ｊａｖａを用いた場合のサーバコンポーネント５の各要素の自動生成について、より具体的に説明する。
【０２２７】
図２３〜図２７のリストは本発明の自動生成装置を通して得られる結果であり、図２８、図２９のリストはテンプレートと呼ばれているリストである。図２３〜図２７のリストは、クラス名Ｆｏｏ、メソッド名ｆｏｏＭｅｔｈｏｄ等の条件を本発明の自動生成装置に入力し、それらが図２８、図２９のテンプレートに埋め込めれて生成される。
【０２２８】
図２８はテンプレート提供部が提供するテンプレートに対応するリストＬＣ−１（コンポーネント本体のクラス定義）、ＬＣ−２（コンポーネント本体のメソッド定義）、ＬＣ−３（共通インターフェースのインターフェース定義）、ＬＣ−４（共通インターフェースのメソッド定義）、ＬＣ−５（サーバ側アダプタのクラス定義）、ＬＣ−６（返り値の型が非ｖｏｉｄの場合のサーバ側アダプタのメソッド定義）、ＬＣ−７（返り値の型がｖｏｉｄの場合のサーバ側アダプタのメソッド定義）を示す図である。
【０２２９】
図２９はテンプレート提供部が提供するテンプレートに対応するリストＬＣ−８（サーバ側アダプタのＲＭＩインターフェースのインターフェース定義）、ＬＣ−９（サーバ側アダプタのＲＭＩインターフェースのメソッド定義）、ＬＣ−１０（クライアント側アダプタのクラス定義）、ＬＣ−１１（返り値の型が非ｖｏｉｄの場合のクライアント側アダプタのメソッド定義）、ＬＣ−１２（返り値の型がｖｏｉｄの場合のクライアント側アダプタのメソッド定義）を示す図である。
【０２３０】
サーバコンポーネント５を生成する際に、先ず、情報提供部７２によって以下に示す情報がクラスファイル自動生成部７４に与えられる。
【０２３１】
・サーバコンポーネント名
・メソッド名
・返り値の型
・引数の型と引数名
また、クラスファイル自動生成部７４は、図２８及び図２９に示す各クラス／インタフェースのテンプレート（スケルトンともいう）から目的のファイル作成に対応するテンプレートを呼び出す。さらに上記情報提供部７２からの情報によって、テンプレート内の［ ］で囲まれた部分の情報を置きかえることで、サーバコンポーネント本体２１等のクラスファイルを自動生成する。これを繰り返すことで全ファイルを生成する。以下、このクラスファイル自動生成部７４による処理を図３０〜図３４の流れ図を用いて具体的に説明する。
【０２３２】
図３０はクラスファイル自動生成の全体の処理流れを示す流れ図である。
【０２３３】
図３１はサーバコンポーネント本体２１のスケルトン生成を示す流れ図である。
【０２３４】
図３２は共通インタフェースの自動生成を示す流れ図である。
【０２３５】
図３３はサーバ側アダプタクラスの自動生成を示す流れ図である。
【０２３６】
図３４はアダプタクラスの定義へ中継用メゾットを埋め込む処理を示す流れ図である。
【０２３７】
全体的な処理の流れを図３０により説明すると、先ず、情報提供部７２からの情報によりサーバコンポーネント名が調べられ（ステップＳＴ４１）、次にサーバコンポーネント本体２１のスケルトンファイルが作成される（ステップＳＴ４２）。次に共通インターフェース２５のファイルが作成され（ステップＳＴ４３）、続けてサーバ側アダプタ用インタフェース２４ａのファイルが作成される（ステップＳＴ４４）。そしてサーバ側アダプタクラスのファイルが作成され（ステップＳＴ４５）、クライアント側アダプタクラスのファイルが作成されて（ステップＳＴ４６）、これらの各ファイルがクラスファイル部７５に出力される。
【０２３８】
また、図３１に示すように、サーバコンポーネント本体２１のスケルトン生成においては、先ず、図２８のリストＬＣ−１（コンポーネント本体のクラス定義）がテンプレート提供部７３から呼び出されて、情報提供部７２からの情報によりテンプレート［ ］部分について情報置き換えが行われる（ステップＳＴ５１）。次に、図２８のリストＬＣ−２（コンポーネント本体のメソッド定義）が呼び出され、同様に情報置き換えが全メゾットについて行われる（ステップＳＴ５２，ＳＴ５３）。すべてのメゾットの情報置き換えが終了すればサーバコンポーネント本体２１のスケルトン生成が完了する（ステップＳＴ５３）。
【０２３９】
次に、図３２に示すように、共通インタフェースの自動生成においては、先ず、図２８のリストＬＣ−３（共通インターフェースのインターフェース定義）が呼び出され、情報置き換えが行われる（ステップＳＴ６１）。次に、図２８のリストＬＣ−４（共通インターフェースのメソッド定義）が呼び出され、情報置き換えが全メゾットについて行われる（ステップＳＴ６２，ＳＴ６３）。すべてのメゾットの情報置き換えが終了すれば共通インタフェースの自動生成が完了する（ステップＳＴ６３）。
【０２４０】
次に、図３３に示すように、サーバ側アダプタクラスの自動生成においては、先ず、図２８のリストＬＣ−５（サーバ側アダプタのクラス定義）が呼び出され、情報置き換えが行われる（ステップＳＴ７１）。次に、サーバ側アダプタのメゾット定義のリスト（図２８のリストＬＣ−６（返り値の型が非ｖｏｉｄの場合のサーバ側アダプタのメソッド定義）もしくはＬＣ−７（返り値の型がｖｏｉｄの場合のサーバ側アダプタのメソッド定義））が呼び出され、情報置き換えが全メゾットについて行われる（ステップＳＴ７２，ＳＴ７３）。すべてのメゾットの情報置き換えが終了すればサーバ側アダプタクラスの自動生成が完了する（ステップＳＴ７３）。なお、ステップＳＴ７２の処理はさらに具体的には、図３４に示される。すなわち、先ず、返り値の型が情報提供部７２からの情報により調べられ（ステップＳＴ８１）、返り値がｖｏｉｄ以外の場合には図２８のリストＬＣ−６が呼び出されて情報置き換えが行われ（ステップＳＴ８２）、ｖｏｉｄの場合には図２８のリストＬＣ−７が呼び出されて情報置き換えが行われる（ステップＳＴ８３）。
【０２４１】
以上のようにして、クラスファイル自動生成部７４によるファイル生成がなされる。
【０２４２】
なお、クライアント側アダプタクラスの生成については、図３３及び図３４に示すサーバ側アダプタクラスの場合と同様であるので、説明を省略する。
【０２４３】
また、上記処理において、サーバコンポーネント名については、キャピタルレター形式（単語の先頭が大文字で残りが小文字、複数の単語がつながる場合は、各単語の先頭を大文字にして繋げたもの）で、メソッド名と引数名については最初が小文宇で始まるキャピタルレター形式で記述されているとする。また［サーバコンポーネント名（小文字）］とはサーバコンポーネント名を全て小文宇で表記したものである。［返り値のデフオルト値］その型の任意のデフォルトの値である。
【０２４４】
上述したように、本発明の第７実施形態に係るサーバコンポーネント自動生成システムは、クラスファイル自動生成部７４により、テンプレート提供部７３からのテンプレートを組み合わせ、また情報提供部７２からの情報を当てはめてクラスファイルを生成するようにしたので、サーバコンポーント５の構成要素を自動的に生成することができる。
【０２４５】
したがって、たとえサーバコンポーネント５に多くの構成要素があっても、本発明を利用することで各構成要素のほどんどが自動生成され、開発者の負担が軽減される。このため開発者が実際にプログラムしなければならないのはアプリケーションプログラム要求処理の実装に関する部分（本体処理内容）のみとなる。
【０２４６】
（第８実施形態）
第７実施形態では、図２１（ｂ）の場合、すなわち図４に示す基本的なサーバコンポーネント５をＪａｖａ ＲＭＩで構成させる場合のクラスファイル自動生成について説明した。次に、第８実施形態として、図２１（ｃ）の場合、すなわち図１６に示すサーバコンポーネント５をＪａｖａ ＲＭＩで構成させる場合のサーバコンポーネント５の各要素の自動生成について説明する。なお、図１９に示すサーバコンポーネントについても本実施形態及び第７実施形態で示す技術を応用して各構成要素、クラスファイルの自動生成を行うことができる。
【０２４７】
図３５は第８実施形態におけるサーバコンポーネント自動生成システムの構成例を示すブロック図であり、図２２と同一部分には同一符号を付してその説明を省略する。
【０２４８】
この自動生成システムは、開発用計算機７１Ａに、情報提供部７２Ａ、テンプレート提供部７３Ａ、クラスファイル自動生成部７４Ａ、クラスファイル部７５、本体処理内容作成部７６及び本体処理内容提供部７７が設けられて構成されている。
【０２４９】
情報提供部７２Ａは、サーバコンポーネント５機能の拡張に伴って提供する情報が増えた以外は、図２２と同様に構成されている。
【０２５０】
テンプレート提供部７３Ａは、サーバコンポーネント５機能の拡張に伴って提供するテンプレート数が増えた以外は、図２２と同様に構成されている。
【０２５１】
クラスファイル自動生成部７４Ａは、図２２のクラスファイル自動生成部７４と同様な考え方で図２１（ｃ）に示す１２個のクラス／インターフェースを生成する。なお、具体的な処理は図５７〜図６４に示す。
【０２５２】
また、図３６〜図４７に自動生成される１２個のクラス／インターフェースの一例をリストＬＬ−１（Ｊａｖａによる共通インターフェースの例）、ＬＬ−２（Ｊａｖａによるサーバコンポーネント本体の例）、ＬＬ−３（Ｊａｖａによるサーバ側アダプタクラスの例）、ＬＬ−４（サーバ側アダプタクラスのＲＭＩインターフェースの例）、ＬＬ−５（クライアント側アダプタの例）、ＬＬ−６（サーバ側リソースアクセス部共通インターフェースの例）、ＬＬ−７（サーバ側リソースアクセス部の例）、ＬＬ−８（サーバ側リソースアクセス用サーバ側アダプタのＲＭＩ用インターフェースの例）、ＬＬ−９（サーバ側リソースアクセス用サーバ側アダプタの例）、ＬＬ−１０（サーバ側リソースアクセス用クライアント側アダプタの例）、ＬＬ−１１（クライアント側リソースアクセス部のＲＭＩ用インターフェースの例）、ＬＬ−１２（クライアント側リソースアクセス部の例）として示す。
【０２５３】
さらに、図４８〜図５６にテンプレート提供部７３Ａが提供する各テンプレート（スケルトン）のリストＣ−１（コンポーネント本体のクラス定義）、Ｃ−２（Ｃ−１用クライアント側での実行用初期化メソッド）、Ｃ−３（Ｃ−２用クライアント側リソースアクセス部生成部）、Ｃ−４（Ｃ−２用サーバ側リソースアクセス部生成部）、Ｃ−５（Ｃ−１用サーバ側での実行用初期化メソッド）、Ｃ−６（Ｃ−１用クライアントリソース部設定メソッド）、Ｃ−７（Ｃ−１，Ｃ−６０，Ｃ−ｂ０用メソッド定義）、Ｃ−８（Ｃ−１用クライアント側リソースアクセス部用属性）、Ｃ−９（Ｃ−１用サーバ側リソースアクセス部用属性）、Ｃ−ａ（Ｃ−１用クライアントアプリケーション設定メソッド）、Ｃ−１０（共通インターフェースのインターフェース定義）、Ｃ−１１（Ｃ−１０，Ｃ−５０用のメソッド定義）、Ｃ−１２（Ｃ−１０，Ｃ−ａ０用クライアントアプリケーション設定メソッド）、Ｃ−２０（サーバ側アダプタのＲＭＩ用インターフェース定義）、Ｃ−２１（Ｃ−２０用中継用メソッド定義）、Ｃ−２２（Ｃ−２０用クライアントリソースアクセス部設定メソッド）、Ｃ−３０（サーバ側アダプタのクラス定義）、Ｃ−３１（Ｃ−３０用クライアント側リソースアクセス部設定メソッド）、Ｃ−３２（返り値の型が非ｖｏｉｄの場合のＣ−３０，Ｃ−８０用サーバ側アダプタの中継用メソッド定義）、Ｃ−３３（返り値の型がｖｏｉｄの場合のＣ−３０，Ｃ−８０用サーバ側アダプタの中継用メソッド定義）、Ｃ−３４（Ｃ−３０用サーバ初期化）、Ｃ−４０（クライアント側アダプタのクラス定義）、Ｃ−４１（Ｃ−４０用クライアント側リソースアクセス部用属性）、Ｃ−４２（Ｃ−４０用クライアント側リソースアクセス部生成）、Ｃ−４３（Ｃ−４０用クライアント側アダプタの本体への設定部）、Ｃ−４４（Ｃ−４０用クライアントアプリケーション設定部）、Ｃ−４５（返り値の型が非ｖｏｉｄの場合のＣ−４０，Ｃ−９０用クライアント側アダプタの中継用メソッド定義）、Ｃ−４６（返り値の型がｖｏｉｄの場合のＣ−４０，Ｃ−９０用クライアント側アダプタの中継用メソッド定義）、Ｃ−５０（サーバ側リソースアクセス部共通インターフェース定義）、Ｃ−６０（サーバ側リソースアクセス部のクラス定義）、Ｃ−７０（サーバ側リソースアクセス用サーバ側アダプタのＲＭＩインターフェース定義）、Ｃ−８０（サーバ側リソースアクセス用サーバ側アダプタのクラス定義）、Ｃ−９０（サーバ側リソースアクセス用クライアント側アダプタのクラス定義）、Ｃ−ａ０（クライアント側リソースアクセス部のＲＭＩ用インターフェース定義）、Ｃ−ａ１（Ｃ−ａ０用クライアントアプリケーション設定メソッド）、Ｃ−ｂ０（クライアント側リソースアクセス部のクラス定義）、Ｃ−ｂ１（Ｃ−ｂ０用クライアントアプリケーション用属性）、Ｃ−ｂ２（Ｃ−ｂ０用クライアントアプリケーション設定メソッド）を示す。なお、図５７〜図６４の流れ図に示されるリスト番号は、この図４８〜図５６のものに対応する。
【０２５４】
次に、この１２個のクラス／インターフェースを自動生成する処理について説明する。
【０２５５】
サーバコンポーネント５を生成する際には、情報提供部７２Ａからクラスファイル自動生成部７４Ａへ以下に示す情報が与えられる。
【０２５６】
１． サーバコンポーネント名
２． サーバ側リソースへアクセスするか？
３． クライアント側リソースへアクセスするか？
４． コンポーネント本体がクライアントアプリケーションプログラムを呼出すか？
５． メソッド名（必要に応じて上記１，２，３の各部へ振り分ける）
・ 返り値の型
・ 引数の型と引数名
これらの情報を基に、以下に示す各クラス、インタフェースのテンプレート（スケルトン）の［ ］でくくられた部分を与えられた情報に置きかえたり、オプション部を付加したりすることによって、それぞれが自動生成される。なお、サーバコンポーネント名については、キャピタルレター形式で、メソッド名と引数名については最初が小文字で始まるキャピタルレター形式で記述されていることとする。また［サーバコンポーネント名（小文字）］とはサーバコンポーネント名を全て小文字で表記したものである。［返り値のデフォルト値］はその型の任意のデフォルトの値である。
【０２５７】
具体的にはクラスファイル自動生成部７４Ａの処理を示す図５７〜図６４の流れ図に従う。
【０２５８】
なお、これらの流れ図のうち、サーバ側アダプタのＲＭＩ用インタフェースとクライアント側リソースアクセス部のＲＭＩ用インタフェースは共通インタフェースに、サーバ側リソースアクセス部とサーバ側リソースアクセス用サーバ側アダプタのＲＭＩインタフェースはサーバ側リソースアクセス共通インタフェースに、サーバ側リソースアクセス用サーバ側アダプタとクライアント側リソースアクセス部はサーバ側アダプタに、サーバ側リソースアクセス用クライアント側アダプタはクライアント側アダプタに類似している（条件の違いや挿入リスト、挿入箇所は前述もしくは後述の通り）ので、これらの流れ図は省略する。
【０２５９】
また、クライアント側アダプタクラス、サーバ側リソースアクセス部の各クラス／インタフェース、クライアント側リソースアクセス部のクラス／インタフェースについては、サーバ側アダプタクラスの流れ図と類似しているので、省略する。また各流れ図中の分岐におけるＱ１，Ｑ２，Ｑ３はそれぞれ以下のことを意味する。
【０２６０】
Ｑ１：サーバ側リソースヘアクセスするか？
Ｑ２：クライアント側リソースヘアクセスするか？
Ｑ３：コンポーネント本体がクライアントアプリケーションプログラムを呼出すか？
以下、各構成要素の生成について具体的に説明する。
【０２６１】
先ず、サーバコンポーネント本体２１のソースでは先ず、リストＣ−１（図４８）が用意される。次にいずれかのオプション設定がある場合 （上記２，３，４）、リストＣ−２（図４８）がリストＣ−１（図４８）の該当場所へ挿入される。挿入場所の記述は、“／／＜＜リストＣ−ｎ＞＞”と書かれてある場所でこの場合、その場所にリストＣ−ｎを挿入する。次に上記３（クライアント側リソースへアクセスする）または上記４（コンポーネント本体がクライアントアプリケーションプログラムを呼出す）の場合、リストＣ−３（図４８）をリストＣ−２（図４８）へ、リストリストＣ−６（図４９）とリストＣ−８（図４９）をリストＣ−１（図４８）へ挿入する。上記２（サーバ側リソースヘアクセスする）の場合、リストＣ−４（図４８）をリストＣ−２（図４８）へ、リストＣ−５（図４９）とリストＣ−９（図４９）をリストＣ−１（図４８）へ挿入する。さらに上記４の場合にはリストＣ−ａ（図４９）をリストＣ−１（図４８）へ挿入する。あとは必要な分だけ（サーバコンポーネント本体２１が提供するメソッドの数だけ）リストＣ−７（図４９）をリストＣ−１（図４８）へ挿入する。
【０２６２】
次に、共通インタフェース２５のソースは先ず、リストＣ−１０（図５０）が用意される。次にリストＣ−１１（図５０）を必要な分だけ挿入する。上記４の場合はリストＣ−１（図４８）２をリストＣ−１０（図５０）へ挿入する。
【０２６３】
次に、サーバ側アダプタ２４のＲＭＩ用インタフェース２４ａは先ず、リストＣ−２０（図５０）が用意される。次に必要な数だけリストＣ−２１（図５０）をリストＣ−２０（図５０）へ挿入する。また、上記３または４の場合、リストＣ−２０（図５０）にリストＣ−２２（図５０）を挿入する。
【０２６４】
次に、サーバ側アダプタ２４のソースは先ず、リストＣ−３０（図５１）が用意される。次に上記３及び４の場合、リストＣ−３１（図５１）とリストＣ−３４（図５１）をリストＣ−３０（図５１）へ挿入する。あとは、必要な分だけリストＣ−３２（図５１）もしくはリストＣ−３３（図５１）をリストＣ−３０（図５１）へ挿入する。
【０２６５】
次に、クライアント側アダプタ２２のソースは先ず、リストＣ−４０（図５２）を用意する。上記３及び４の場合、リストＣ−４１（図５２）とリストＣ−４２（図５２）、リストＣ−４３（図５３）をリストＣ−４０（図５２）へ挿入する。また上記４の場合はリストＣ−４４（図５３）をリストＣ−４０（図５２）へ挿入する。あとは必要な数だけリストＣ−４５（図５３）もしくはリストＣ−４６（図５３）を挿入する。
【０２６６】
次に、サーバ側リソースアクセス部共通インタフェース５８のソースは上記２の場合に作成する。先ずリストＣ−５０（図５４）を用意する。次に必要な数だけリストＣ−１１（図５０）をＣ−５０（図５４）に挿入する。
【０２６７】
次に、サーバ側リソースアクセス部５７のソースは上記２の場合に作成する。先ずリストリストＣ−６０（図５４）を用意する。次に必要な数だけリストＣ−７（図４９）をリストＣ−６０（図５４）に挿入する。
【０２６８】
次に、サーバ側リソースアクセス用サーバ側アダプタ５６のＲＭＩインタフェース５６ａのソースは上記２の場合に作成する。先ずリストＣ−７０（図５４）を用意する。次に必要な数だけリストＣ−２１（図５０）をリストＣ−７０（図５４）に挿入する。
【０２６９】
次に、サーバ側リソースアクセス用サーバ側アダプタ５６のソースは上記２の場合に作成する。またリストＣ−８０（図５４）を用意する。次に必要な数だけリストＣ−３２、Ｃ−３３（図５１）をリストＣ−８０（図５４）に挿入する。
【０２７０】
次に、サーバ側リソースアクセス用クライアント側アダプタ５４のソースは上記２の場合に作成する。先ずリストＣ−９０（図５５）を用意する。次に必要な数だけリストＣ−４５、Ｃ−４６（図５３）をリストＣ−９０（図５５）に挿入する。
【０２７１】
次に、クライアント側リソースアクセス部５３のＲＭＩ用インタフェース５３ａのソースは上記３もしくは４の場合に作成する。先ずリストＣ−ａ０（図５５）を用意する。次に必要な数だけリストＣ−２１（図５０）をリストＣ−ａ０（図５５）へ挿入する。上記４の場合はリストＣ−ａ１（図５５）をリストＣ−ａ０（図５５）へ挿入する。
【０２７２】
次に、クライアント側リソースアクセス部５３のソースは上記３もしくは４の場合に作成する。先ずリストＣ−ｂ０（図５６）を用意する。次に必要な数だけリストＣ−３２（図５１）をリストＣ−ｂ０（図５６）へ挿入する。上記４の場合はリストＣ−ｂ１，Ｃ−ｂ２（図５６）をリストＣ−ａ０（図５５）へ挿入する。
【０２７３】
以上により、生成された各クラス／インタフェースにおいて、コンポーネント開発者はリストＣ−７（図４９）が挿入された部分を本体内容提供部７７により実装することでサーバコンポーネント５を開発することができる。
【０２７４】
また、本実施形態での記述はＪａｖａ言語を対象としたが、分散オブジェクト間通信にＣＯＲＢＡを用いたり、言語としてＣ＋＋を使用した場合でも少ない変更で対処することが可能である。
【０２７５】
（第９実施形態）
上記した実施形態によれば、Ｊａｖａアプレットでは処理の実行位置は必ずクライアント側であるという静的なシステム構造であったものを、実行時に処理の実行位置をサーバ側にするか、クライアント側にするかを決定できるような動的なシステム構造を持つことのできる分散システムが構築可能である。しかし、上記した実施形態では、サーバコンポーネントを提供するサーバとなるコンピュータは１つであり、クライアントとなるコンピュータとサーバとなるコンピュータ以外のネットワーク内の他のコンピュータを処理を実行する場所（サーバ）として用いることはできない。そこで、サーバ処理の実装をネットワーク内の任意のコンピュータで動作させることができる実施形態を次に説明する。
【０２７６】
本実施形態では、サーバコンポーネントの保守管理やインストール作業の軽減の観点から、サーバコンポーネントを扱うのは１つのサーバホストとなるコンピュータにする。
【０２７７】
他のコンピュータ（サブサーバホストと呼ぶ）上で実行する場合にはこのサーバホストからサーバコンポーネントを配送し実行する。そのため、サブサーバホストではサーバホストから送られてくる処理コンポーネントを受け取り実行可能な状態にし、その他必要な準備を行なう。
【０２７８】
配送されるサーバコンポーネントは特定のコンピュータ資源でもアクセスできるように、サーバコンポーネントを基本部、クライアント側リソースアクセス部、サーバ側リソースアクセス部から構成する。
【０２７９】
また実行場所を決定し、そこへサーバコンポーネントを配信し、処理を行なった後、さらにそこから実行場所を変更可能とするため、実行位置指示部やクライアント側アプリケーションプログラムのコールバック用インタフェースを設ける。
【０２８０】
図６５はこのような原理に基づく第９実施形態の分散システムの構成（ハードウェア構成、及びソフトウェアリソース）を示す。
【０２８１】
本システムは、クライアントホスト１５０とメインサーバホスト１２０、サブサーバホスト１３０とがネットワークを介して接続されて構成されている。
【０２８２】
メインサーバホスト１２０はサーバコンポーネント１１０と接続される。サーバコンポーネント１１０は図４に示すような基本部分１１１と、図６、図１９等に示すクライアント側リソースアクセス部１１２とサーバ側リソースアクセス部１１３と、サーバコンポーネント情報１１４とからなる。
【０２８３】
クライアントホスト１５０は、クライアント用コンポーネントローダ１５２、コールバック用インターフェース１５１とからなり、入力装置１８０、ディスプレイ１９０が接続される。
【０２８４】
メインサーバホスト１２０は、コンポーネントマネージャ１２１、コンポーネントサーバ１２２、実行位置決定部１２３とからなり、コンポーネントサーバ１２２はクライアント用コンポーネントローダ１５２、コールバック用インターフェース１５１に接続される。
【０２８５】
サブサーバホスト１０３は、サブサーバ用コンポーネントローダ１３１を有し、サブサーバ用コンポーネントローダ１３１はコンポーネントサーバ１２２に接続される。
【０２８６】
入力装置１７０、ディスプレイ１６０が接続される実行位置指示部１４０が実行位置決定部１２３に接続される。
【０２８７】
アプリケーションユーザは入力装置１８０とディスプレイ１９０を介してクライアントホスト１５０を操作する。クライアントホスト１５０はユーザの要求に応じた処理を行なうサーバコンポーネント１１０をメインサーバホスト１２０に対して要求する。具体的には、クライアントホスト１５０内のクライアント用コンポーネントローダ１５２を介してメインサーバホスト１２０内のコンポーネントサーバ１２２に対してサーバコンポーネント１１０の要求を行なう。その際、コンポーネントサーバ１２２に対してコールバック用インタフェース１１８を渡しておく。
【０２８８】
コンポーネントサーバ１２２はコンポーネントマネージャ１２１に指定されたサーバコンポーネント１１０を要求し、それを受け取る。また、コンポーネントサーバ１２２は指定されたサーバコンポーネント１１０を実行するコンピュータを実行位置決定部１２３を用いて決定する。
【０２８９】
メインサーバホスト１２０でサーバコンポーネント１１０を実行する場合は、サーバコンポーネント１１０の基本部１１２をコンポーネントサーバ１２２が実行可能な状態に（インスタンス生成）し、初期化等の準備を行なう。
【０２９０】
サブサーバホスト１０３でサーバコンポーネント１１０を実行する場合は、コンポーネントサーバ１２２はサーバコンポーネント１１０の基本部１１２をサブサーバ用コンポーネントローダ１３１に配送する。サブサーバ用コンポーネントローダ１３１は必要なクラスをコンポーネントサーバ１２２から受け取り、それをインスタンス生成し、初期化等の準備を行なう。
【０２９１】
クライアントホスト１５０側でサーバコンポーネント１１０を実行する場合は、コンポーネントサーバ１２２はサーバコンポーネント１１０の基本部１１２をクライアントホスト１５０のクライアント用コンポーネントローダ１５２に配送する。クライアント用コンポーネントローダ１５２は必要なクラスをコンポーネントサーバ１２２から受け取りそれをインスタンス生成し、初期化等の準備を行なう。
【０２９２】
クライアントホスト１５０は上記のいづれかの場合でインスタンス生成されたサーバコンポーネント１１０の基本部１１２に対してネットワーク経由もしくはインプロセスで接続し、それを利用し処理を実行する。
【０２９３】
なお、サーバコンポーネント１１０がクライアント側リソースアクセス部１１２を有する場合は、コンポーネントサーバ１２２がこれをクライアントホスト１５０のクライアント用コンポーネントローダ１５２に配送する。クライアント用コンポーネントローダ１５２はそれをインスタンス生成し、サーバコンポーネント１１０の基本部１１２に設定する。サーバコンポーネント１１０がサーバ側リソースアクセス部１１３を有する場合は、サーバコンポーネント情報１１４に記載される「サーバ側リソースアクセス部１１３を実行するコンピュータ」上のサブサーバホスト１０３のサブサーバ用コンポーネントローダ１３１にサーバ側リソースアクセス部１１３を配送する。サブサーバ用コンポーネントローダ１３１はそれをインスタンス生成し、サーバコンポーネント１１０の基本部１１２に設定する。サーバ側リソースアクセス部１１３をメインサーバホスト１２０で動作させる場合はコンポーネントサーバ１２２がインスタンス生成し、サーバコンポーネント１１０の基本部１１２に設定する。
【０２９４】
実行位置の決定（指示）についてはシステム管理者が入力装置１７０、ディスプレイ１６０を介して実行位置指示部１４０に指示する。実行位置指示部１４０は実行位置決定部１２３に対してシステム管理者の指示を伝達する。実行位置決定部１２３は以後の実行位置判定においてこの情報を基に実行位置を判定する。また、実行位置決定部１２３はコンポーネントサーバ１２２から依頼された実行位置を決定後、その内容を実行位置指示部１４０にも伝える。この情報を基に、実行位置指示部１４０はディスプレイ１６０に現在実行中のサーバコンポーネント１１０とその実行位置とを表示する。
【０２９５】
システム管理者はこの情報を基に、現在実行中のコンポーネントに対して、入力装置１７０を介して次の実行位置を指定することもできる。システム管理者が指示した「次の実行場所」の情報が実行位置指示部１４０から実行位置決定部１２３へ伝わると、実行位置決定部１２３はさらにコンポーネントサーバ１２２にその内容を伝え、サーバコンポーネント１１０の再配置を行なう処理を行なう。具体的には現在実行中のサーバコンポーネント１１０を一旦終了し、新たに指示された場所にサーバコンポーネント１１０を配送し、インスタンス生成等を行なう。そして、コンポーネントサーバ１２２はサーバコンポーネント１１０の再配置があったことをコールバック用インタフェース１１８を用いてクライアントホスト１５０に伝え、新しい場所を指示する。クライアントホスト１５０はその情報を基に新たなサーバコンポーネント１１０に対して再接続等の初期化処理を行なう。
【０２９６】
このような第９実施形態によれば、上に述べた実施形態の効果に加えて、サーバ処理の実装をネットワーク内の任意のコンピュータで動作させることができるとともに、サーバ処理の実装において、特定のコンピュータ上での動作も可能にすることができる効果を有する。
【０２９７】
（第１０実施形態）
図６６は本発明の分散システムの第１０実施形態の物理構成を示すブロック図、図６７は第１０実施形態の論理構成を示すブロック図である。ここでは、デーベースへアクセスし、簡単な処理を行なうアプリケーションプログラムを例として示してある。
【０２９８】
図６６に示すように、第１０実施形態の分散システムにおいては、ネットワーク３１０に接続されたメインサーバマシン３３０にメインサーバホスト１２０が、サブサーバマシン（Ｂ）３５０にサブサーバホスト２３０が、サブサーバマシン（Ｂ）３５０にサブサーバホスト２３０とデータベース４００が、管理者用マシン３２０に実行位置指示部２４０が、クライアントマシン３６０にデータベースアクセス用クライアントホスト２５０がそれぞれインストールされている。ここで、インストールの意味は、プログラムを計算機に組み込み、実行するための準備をすることである。
【０２９９】
図６７に示すように、分散システムはデータベースアクセス用サーバコンポーネント２１０、メインサーバホスト２２０、サブサーバホスト２３０、実行位置指示部２４０、データベースアクセス用クライアントホスト２５０、データベース４００から構成される。さらにサーバコンポーネント２１０はデータベース（ＤＢ）アクセス基本部２１１とクライアント側リソースアクセス部２１２、サーバ側リソースアクセス部２１３、サーバコンポーネント情報２１４から構成され、クライアント側リソースアクセス部２１２はさらにＧＵＩ２１２ａを含む。なお、クライアント側リソースアクセス部２１２とサーバ側リソースアクセス部２１３は必ず設ける必要は無く、省略可能な場合もある。
【０３００】
サーバコンポーネント情報２１４の一例を図６８に示す。ここでは、コンポーネント名、サーバ側リソースアクセス部の実行場所、クライアント側リソースアクセス部の有無がサーバコンポーネント情報２１４となっている。
【０３０１】
メインサーバホスト２２０はコンポーネントマネージャ２２１、コンポーネントサーバ２２２、実行位置決定部２２３から構成される。
【０３０２】
サブサーバホスト２３０はサブサーバ用コンポーネントローダ２３１を含む。
【０３０３】
実行位置表示部２４０はＧＵＩ２４１を含む。
【０３０４】
データベースアクセス用クライアントホスト２５０はクライアント用コンポーネントローダ２５２、コールバック用インタフェース２５３、ＧＵＩ２５０から構成される。
【０３０５】
このように構成される本実施形態の分散システムの動作として、サーバコンポーネント２１０の実行位置の決定、配置、実行並びに、実行後の再配置について、図６７に示すデータベースアクセスアプリケーションプログラムの実行順に合わせて説明する。なお、ここで例としてあげるデータベースアクセスアプリケーションプログラムは図６９に示すような簡単な売り上げ管理データベースへアクセスして、ある特定の購入者の合計購入金額を表示するようなアプリケーションプログラムとする。
【０３０６】
このアプリケーションプログラムのクライアントホスト２５０のＧＵＩ２５３を図７０に示す。
【０３０７】
図７１は、本実施形態におけるサーバコンポーネント２１０の実行位置の決定、配置、実行、再配置の一連の流れを示す。実行位置決定は、アプリケーションプログラムのユーザがデータベースアクセスを行なうため、クライアントホスト２５０からメインサーバホスト２２０に対してサーバコンポーネント２１０を要求し、それに対して実行位置決定部２２３が実行位置を判定することである。配置は、決定した実行位置に応じたサーバコンポーネント２１０の配送、インスタンス生成、準備からクライアントホスト２５０との接続処理である。実行は、実際のデータベースアクセス処理である。再配置は、管理者によるサーバコンポーネント２１０の実行後の再配置である。なお、このデータベースアクセスアプリケーションプログラムはあくまで説明の便宜上のものであり、本発明はどのようなアプリケーションプログラムにも適用可能である。
【０３０８】
（１）［実行位置決定］サーバコンポーネント２１０の要求までの流れ
データベースアプリケーションプログラムのユーザは、先ず検索したい購入者の名前を購入者名入力部６１０に入力する（ステップＳＴ１０２）。次に検索ボタン５０６を押す（ステップＳＴ１０４）。クライアントホスト２５０は既にサーバコンポーネント２１０を使える状態にあるかどうかを調べる（ステップＳＴ１０６）。もし既に使える状態であれば、それを利用して検索等の処理を行ない（ステップＳＴ１１４）、結果を表示する（ステップＳＴ１６）。
【０３０９】
そうでなければ、クライアントホスト２５０はコンポーネントサーバ２２２へサーバコンポーネント２１０の要求を行なう（ステップＳＴ１０８）。コンポーネントサーバ２２２は実行位置決定部２２３に依頼し、クライアントホスト２５０がコンポーネントサーバ２２０へ要求したサーバコンポーネント２１０の実行位置を決定する（ステップＳＴ１１０）。
【０３１０】
（２）［配置］実行位置決定後からサーバコンポーネント２１０が使用可能になるまでの流れ
実行位置決定後からサーバコンポーネント２１０が使用可能になるまでの一連の流れを図７２を参照して説明する。また、この処理の時にサーバコンポーネント２１０が有するサーバコンポーネント情報２１４の一例を図７３に示す。サーバコンポーネント情報２１４は、コンポーネント名としてはサーバコンポーネント２１０、サーバ側リソースアクセス部の実行場所としてはサブサーバマシン（Ｂ）３５０、クライアント側リソースアクセス部の有無としては有りが格納される。
【０３１１】
コンポーネントサーバ２２２は要求されたサーバコンポーネント２１０の実行位置を決定するために、先ずコンポーネントマネージャ２２１を介してサーバコンポーネント２１０のサーバコンポーネント情報２１４を参照し、ＤＢアクセス基本部２１１を動作させるコンピュータが指定されているかどうかを調査する。この情報はオプションであり、無い場合もある。本実施形態では特に指定していない。
【０３１２】
次に、実行位置決定部２２３に実行位置を尋ねる。本実施形態ではサブサーバマシン（Ａ）３４０であるとする。なお、サーバコンポーネント情報２１４にサーバコンポーネント基本部（データベースアクセス基本部２１１）の実行位置が指定されている場合で、実行位置決定部２２３の決定結果と指定場所が異なる場合、どちらを実行場所とするかはそのシステムが任意に決定できる。例えば、サーバコンポーネント情報２１４の情報を優先することにするように設定できる。
【０３１３】
図７２では、サーバコンポーネント２１０の実行位置の判定（ステップＳＴ１２０）の結果、すなわちＤＢアクセス基本部２１１の実行位置はサブサーバホスト２３０となったとするので、コンポーネントサーバ２２２はコンポーネントマネージャ２２１からＤＢアクセス基本部２１１を受け取り、それをサブサーバマシン（Ａ）３４０のサブサーバ用コンポーネントローダ２３１に配送する（ステップＳＴ１２８）。サブサーバ用コンポーネントローダ２３１は受け取ったＤＢアクセス基本部２１１をインスタンス生成し、初期化（初期値の設定やクライアントホスト２５０からの接続を受けるための準備）を行なう（ステップＳＴ１３０）。そして、コンポーネントサーバ２２２はクライアント用コンポーネントローダ２５２に対して、要求されたサーバコンポーネント２１０をサブサーバマシン（Ａ）３４０で動作させたことを通知する。クライアントホスト２５０はその情報を基にサブサーバマシン（Ａ）３４０で動作しているＤＢアクセス基本部２１１に対して接続を行なう。
【０３１４】
サーバコンポーネント情報２１４より、サーバコンポーネント２１０はクライアント側リソースアクセス部２１２を持っていることがわかるので（ステップＳＴ１３２）、コンポーネントサーバ２２２はクライアント側リソースアクセス部２１２をクライアントホスト２５０のクライアント用コンポーネントローダ２５２に送る（ステップＳＴ１３４）。クライアント用コンポーネントローダ２５２は受け取ったクライアント側リソースアクセス部２１２をインスタンス生成し、初期化を行なう（ステップＳＴ１３６）。そしてそれをサブサーバマシン（Ａ）３４０で実行しているＤＢアクセス基本部２１１に設定する（ステップＳＴ１３８）。
【０３１５】
同じく、サーバコンポーネント情報２１４より“サーバ側リソースアクセス部２１３の実行場所”が指定されていることから、サーバコンポーネント２１０はサーバ側リソースアクセス部２１３も持っていることがわかるので（ステップＳＴ１４０）、コンポーネントサーバ２２２はサーバ側リソースアクセス部２１３を動作させるべきコンピュータをサーバコンポーネント情報２１４から調べる（ステップＳＴ１４２）。なお、“サーバ側リソースアクセス部２１３の実行場所”が指定されていない場合は、そのサーバコンポーネント２１０はサーバ側リソースアクセス部２１３を持たないことを示す。この例では、サブサーバホスト２３０で動作させるので、コンポーネントサーバ２２２はサーバ側リソースアクセス部２１３をサブサーバホスト２３０のサブサーバホスト２３０のサブサーバ用コンポーネントローダ２３１へ送る（ステップＳＴ１４６）。サーバ側リソースアクセス部２１３を受け取ったサブサーバ用コンポーネントローダ２３１はそれをインスタンス生成し、初期化を行なう（ステップＳＴ１４８）。そしてそれをサブサーバマシン（Ａ）３４０で実行しているＤＢアクセス基本部２１１に設定する。
【０３１６】
以上の一連の流れにより、本実施形態のデータベースアクセスに必要なシステム構成（クライアント−サーバ間の関係）が全て成立する。
【０３１７】
（３）［実行］実際のデータベースアクセス処理の流れ
本発明とは直接関係しないが、本実施形態のデータベースアクセスについて、図７４を参照して説明する。
【０３１８】
クライアントホスト２５０は購入者名入力部に入力された購入者名をＤＢアクセス基本部２１１へ送る（ステップＳＴ１６０）。ＤＢアクセス基本部２１１はサーバ側リソースアクセス部２１３に購入者名を渡し、データベースにアクセスするよう命ずる（ステップＳＴ１６２）。サーバ側リソースアクセス部２１３は渡された購入者名を含むデータをデータベースから得、その結果をＤＢアクセス基本部２１１へ返す（ステップＳＴ１６４）。ＤＢアクセス基本部２１１ではその結果の値段の値を合計する。そしてその値をクライアントホスト２５０へ返す（ステップＳＴ１６６）。結果を受け取ったクライアントホスト２５０はＧＵＩの合計購入金額表示部にその結果を表示する（ステップＳＴ１６８）。
【０３１９】
（４）［再配置］管理者によるサーバコンポーネント２１０の実行後の再配置コンポーネントサーバ２２２はＤＢアクセス基本部２１１をインスタンス化もしくは他のコンポーネントローダへ配信する際に、該当するサーバコンポーネント２１０（ＤＢアクセス基本部２１１）とそれを実行した場所を実行位置決定部２２３に知らせる。実行位置決定部２２３はこのような情報をリストとして保持し、必要に応じて実行位置指示部２４０に伝え、ＧＵＩを用いて表示する。本実施形態におけるＧＵＩを図７５に示す。
【０３２０】
この動作を図７６に示すフローチャートを参照して説明する。
【０３２１】
ＧＵＩは図７５に示すように実行位置決定部２２３が保持している現在実行中のサーバコンポーネント２１０に関する情報を表示するため、サーバコンポーネント名表示部と現在の実行場所表示部、再配置場所指定部、再配置実行ボタン、終了ボタンを有している。サーバコンポーネント名表示部と再配置場所指定部はそれぞれプルダウンメニューのようになっており、各部の右側のボタンを押すと選択可能な候補のリストが表示され、システム管理者はこの表示の中から選ぶことになる。サーバコンポーネント名表示部でサーバコンポーネント２１０を指定すると現在の実行場所表示部に選択されたサーバコンポーネント２１０が動作している場所が表示される（ステップＳＴ１７０）。この情報は実行位置決定部２２３が保持している。
【０３２２】
次にシステム管理者がＧＵＩの再配置場所指定部にて再配置先としてメインサーバホスト２２０マシンを指定する（ステップＳＴ１７２）。なお再配置場所として選択可能な項目に関するデータは実行位置決定部２２３が保存しており、この実施形態の場合はメインサーバマシン３３０、サブサーバマシン（Ａ）３４０、サブサーバマシン（Ｂ）２３０、クライアントマシン３６０が選択対象となる。これらのデータはシステム起動時にメインサーバホスト２２０やサブサーバホスト２３０、クライアントホスト２５０の間のやりとりによって収集される。例えば、メインサーバホスト２２０は起動した際に、ネットワーク内に存在するサブサーバホスト２３０を探して、見つかったものを実行位置決定部２２３に知らせる。サブサーバホスト２３０は起動した際にメインサーバホスト２２０に連絡し、コンポーネントを介して実行位置決定部２２３に知らせる。クライアントホスト２５０はサーバコンポーネント２１０をメインサーバホスト２２０に要求する際にコンポーネントサーバ２２２を介して実行位置決定部２２３に知らせる。
【０３２３】
そしてシステム管理者が再配置ボタンを押すと指定したサーバコンポーネント２１０と再配置先（メインサーバホスト２２０）の情報が実行位置指定部から実行位置決定部２２３へ送られる（ステップＳＴ１７４）。実行位置決定部２２３はその内容をコンポーネントサーバ２２２に伝え（ステップＳＴ１７６）、再配置処理を開始する（ステップＳＴ１７８）。
【０３２４】
システム管理者がサーバコンポーネント２１０をサブサーバマシン（Ａ）３４０からメインサーバマシン３３０へ再配置する例を図７７に示す。基本的には上記（２）の「実行位置決定後からサーバコンポーネント２１０が使用可能になるまで」とほとんど同じ処理となるので、ここでは簡単に説明する。
【０３２５】
再配置先がメインマシンであるのでＤＢアクセス基本部２１１をコンポーネントサーバ２２２がインスタンス生成し、初期化等を行なう（ステップＳＴ２０４）。再配置が発生したことをクライアントホスト２５０へ伝え、これまで動作させていたサーバコンポーネント２１０を破棄する（ステップＳＴ２１２）。破棄する対象が他のサブサーバホスト２３０やクライアントである場合はそれを破棄するように伝達し、伝達された側が破棄を行なう。
【０３２６】
サーバコンポーネント２１０はクライアント側リソースアクセス部２１２を持つのでその準備を行なう（ステップＳＴ２１４〜ＳＴ２２０）。また、同じくサーバコンポーネント２１０はサーバ側リソースアクセス部２１３を持つので、その準備を行なう（ステップＳＴ２２２〜ＳＴ２３２）。
【０３２７】
以上により再配置が終了する。
【０３２８】
再配置終了後は継続して上記（３）に示したデータベースアクセス処理を継続できる。
【０３２９】
第１０実施形態によれば、上に述べた実施形態の効果に加えて、実行後のサーバ処理の実行位置を変更（再配置）することができる。
【０３３０】
本発明は、上述した各実施形態に限定されるものでなく、その要旨を逸脱しない範囲で種々に変形することが可能である。例えば、実施形態に記載した手法は、コンピュータに実行させることができるプログラム（ソフトウエア手段）として、例えば磁気ディスク（フロッピーディスク、ハードディスク等）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤ等）、半導体メモリ等の記録媒体に格納し、また通信媒体により伝送して頒布することもできる。なお、媒体側に格納されるプログラムには、コンピュータに実行させるソフトウエア手段（実行プログラムのみならずテーブルやデータ構造も含む）をコンピュータ内に構成させる設定プログラムをも含むものである。本装置を実現するコンピュータは、記録媒体に記録されたプログラムを読み込み、また場合により設定プログラムによりソフトウエア手段を構築し、このソフトウエア手段によって動作が制御されることにより上述した処理を実行する。
【０３３１】
【実施例】
次に、本発明の分散システムの具体例を実施例として次に説明する。
【０３３２】
（第１実施例）
本発明の分散システムは、画像処理アプリケーションプログラムに応用することができる。
【０３３３】
画像処理アプリケーションプログラムにおいては、処理を行うためのデータ転送量（引数や返り値）は大きいが、処理自体は単純な繰り返しが多いため、サーバコンポーネント本体のサイズが小さくできる場合が多い。したがって、画像処理アプリケーションプログラムでは、クライアント／サーバの両ホストの計算能力やネットワークの状態によって、より速く処理結果が得られるような実行位置が変わってくるからである。したがって、本システムを画像処理アプリケーションプログラムに適用すればスループットが向上する。
【０３３４】
サーバコンポーネントへの具体的な適用例としては、実施例で示したように画像の平滑化処理がある。
【０３３５】
（第２実施例）
本発明の分散システムは、モバイル環境でのコンポーネントビジネスへ利用することができる。
【０３３６】
コンポーネントの流通においてネットワークの利用は最も有効な手段の一つであると考えられる。本分散システムをインフラとして用いた場合には、有効なコンポーネント販売システムを構築できる。
【０３３７】
このような利用形態の場合はどちらかといえば、ＬＡＮのような常時接続されたネットワーク環境よりも、むしろモバイル環境や公衆回線を通した一般家庭のインターネット接続などが対象となりやすいと考えられる。
【０３３８】
ユーザ（クライアントホスト１側）はコンポーネントを提供するコンポーネントプロバイダに接続し、必要なコンポーネントの購入を行なう。その際、「試しに試用してから、購入を考えたい」というユーザに対しては、サーバコンポーネント本体をサーバホスト２側でのみ動作させるようにする。必要に応じて、使用回数や使用時間などについて制限を設ける。その制限機構は、例えばクライアント側アダプタ２２に設けておけばよい。そして、購入することになったユーザに対してはサーバコンポーネント本体をクライアントホスト１側ヘダウンロードし、クライアントホスト１側のローカルのディスクへ保存できるようにする。
【０３３９】
コンポーネント開発者はサーバコンポーネントを、どちらの状況で利用されるかを意識せずに開発できるため、上述した自動生成技術と相俟って、上記のような使い方をしてもコンポーネント開発者へかかる負担は従来のコンポーネント開発と変わらない。
【０３４０】
また、このような利用の場合には、サーバコンポーネント本体に相当するものは処理プロセスだけでなく、各種データなどの場合も考えられる。例えば、戦略シミュレーションゲームにおける新しいマップコンポーネントの提供や、ニュースコンポーネント（ヘッドラインはクライアントヘ、本文はコンポーネント本体として扱う）、リリースされた新曲コンポーネント（クライアントへ最初送られるのは一部のパートのみ、もしくは音質の低い（サンプリングが荒い）もの）などが考えられる。
【０３４１】
一例として、ニュースコンポーネントの販売が考えられる。ニュースコンポーネントの販売システムでは、クライアント側アダプタ２２がヘッドラインや要約などの簡単な情報のみを提供するようにする。そしてコンポーネント本体２１でニュースの詳細な内容や写真などを提供する。このシステムではサーバ側アダプタ２４はほとんど機能する必要はない。例えば、一部の音声情報などのサーバコンポーネント本体にある情報も、クライアント側アダプタ２２から利用するような場合には必要となる。
【０３４２】
クライアントホスト１５０からは、対象とするニュースコンポーネントを試し見する際は、クライアント側アダプタ２２を介して参照できる簡単な内容のみを見ることができ、実際にそれを購入し本体を手元にダウンロードした時点で詳細な情報を参照できるようになる。
【０３４３】
この以外は、ＰＵＳＨ技術（プッシュ技術）などのソフトウェア配信と組み合わせることで、より幅広いサービスの提供が可能となる。
【０３４４】
（第３実施例）
本分散システムは、分散コンポーネント開発システムへ利用することができる。
【０３４５】
ネットワークを介して使用されることが前提となるアプリケーション／コンポーネントの開発においても、本システムをインフラとして用いることで、効率よく開発が行なえるようになると考えられる。
【０３４６】
例えばコンポーネントの開発者はβ版の段階のものを、サーバホスト２側でのみ動作させるという条件をつけて、コンポーネントをシステムに登録する。β版はサーバホスト２側でのみ実行できるので、エラーログの収集が容易でり、またクライアントホスト１側も比較的安全である。もちろん、βテストを行なえるクライアントのユーザの限定も行なえる。完成したコンポーネントはそのまま条件（サーバホスト２側でのみ実行可能とした条件）を変更することで、それ以降は通常のコンポーネントとして配布することができる。そのため、試験などの段階で特別なスタブなどを作成しなくても済むため、開発効率の面で有効であると考えられる。
【０３４７】
（第４実施例）
本分散システムは、実行環境の違いを吸収可能なシステム関発へ利用することができる。
【０３４８】
Ｊａｖａのような日進月歩な言語環境などでは、バージョンの違いによってＡＰＩが追加・変更されたりし、実行環境ごとに差が生じる可能性も考えられる。このような実行環境の違いを吸収するのにも本システムは有効であると考えられる。
【０３４９】
例えばサーバホストと第１のクライアントホストと第２のクライアントホストがネットワークで接続されている場合に、第１のクライアントホストでは、全てのＪａｖａＡＰＩがサポートされるが、第２のクライアントホストでは、Ｊａｖａの拡張ＡＰＩがサポートされていないとする。
【０３５０】
ここで、クライアントから要求される処理コンポーネントがある拡張ＡＰＩを必要としている場合、第１のクライアントから処理要求が発生すると、クライアント／サーバのいずれのホストでも実行可能であるので、例えば負荷が少ないほうのホストで処理を実行することができる。しかし、第２のクライアントから要求が発せられた場合には、クライアントホスト側でその処理を実行することはできないので、必ずサーバホスト側で動作させるようにする。
【０３５１】
したがって、このようにすれば実行環境の違いがある場合においても処理を柔軟に実行できるようになる。これを応用すれば、例えば組み込み／マイコン系などで使用される制限された実行環境においても有効に利用できると考えられる。
【０３５２】
（第５実施例）
本分散システムは、通常ＤＢシステムに適用すればネットワークトラフィックを削減できることが考えられる。
【０３５３】
通常の業務アプリケーションプログラムを考えた場合、データベースとなるサーバホストやクライアントホストが多数存在し、そのネットワークの物理的な構成も様々な形態を取ることになる。
【０３５４】
例えばＬＡＮが２つのセグメントから構成され、サーバコンポーネントを提供するコンポーネントサーバがＬＡＮの第２セグメント上にあり、提供されるコンポーネントは特定のＤＢへアクセスするような処理コンポーネントであり、クライアントはそれを利用する、という場合を考える。
【０３５５】
この場合で、例えば第１セグメント上にある第１クライアントが、第１セグメント上のＤＢサーバへアクセスするためのコンポーネントを要求した場合、それを第２セグメント上のコンポーネントサーバで実行する場合と、第１セグメント上の第１クライアントで実行する場合では、ネットワークトラフィックの観点から後者のほうが良いと考えられる。
【０３５６】
通常このような分散型の業務システムを構築する場合、システム全体を設計する段階でこのような物理的な構成を考慮に入れることが考えられるが、クライアントホストやＤＢを頻繁に追加、削除したりしてネットワーク構成などを変更しなければならなくなった場合に、対応が難しい。しかしながら、本クライアントシステムをベースに分散型業務システムを構築していれば、コンポーネントの実行位置の変更だけでネットワーク構成の変更にも対応でき、最適な分散システムを継続して使用することができるようになると考えられる。
【０３５７】
【発明の効果】
以上説明したように、本発明の分散システムによれば、２つ以上のコンピュータが接続されるネットワーク環境下において、以下のことが可能となる。
【０３５８】
（１）処理の実行本体をサーバで管理してその実行位置を決定するようにしたので、処理プロセスの実行位置を動的に変更してシステム構成を柔軟に変化させることが可能となる。
【０３５９】
（２）サーバコンポーネントの開発者は処理ロジックをサーバ側の処理を１箇所（サーバホスト）のみに実装すればよいので、クライアント側で動作する処理プロセスとサーバ側で動作する処理プロセスを別々に二重に開発する必要が無いとともに、処理ロジックの保守管理やインストール作業が軽減できる。
【０３６０】
（３）サーバコンポーネントを基本部、クライアント側リソースアクセス部、サーバ側リソースアクセス部から構成したので、特定の計算機資源でもサーバコンポーネントをアクセスすることができる。
【０３６１】
（４）メインサーバ以外に複数のサブサーバがあり、サブサーバで実行する場合は、メインサーバからサブサーバへサーバコンポーネントを配送し、サブサーバではそれを受け取り、実行可能な状態にする。
【０３６２】
（５）実行位置を決定し、そこへサーバコンポーネントを配信し、処理を行った後、さらにそこから実行位置を変更（再配置）できる。
【図面の簡単な説明】
【図１】本発明の第１実施形態に係る分散システムのハードウエア構成例を示すブロック図。
【図２】第１実施形態の分散システムにおけるソフトウェア論理構成を示す図。
【図３】第１実施形態のアプリケーションプログラムの構成例を示す図。
【図４】第１実施形態におけるサーバコンポーネントの構成例を示す図。
【図５】サーバコンポーネント本体がクライアントホストで実行される場合と、サーバホストで実行される場合の構成を示す図。
【図６】コンポーネントローダの構成例を示す図。
【図７】コンポーネントサーバの構成例を示す図。
【図８】コンポーネントマネージャの構成例を示す図。
【図９】サーバコンポーネントへの処理要求から実行位置の決定までを示す図。
【図１０】サーバコンポーネントをクライアントホスト側で実行させる場合にその実行位置決定から実行までについて示す図。
【図１１】サーバコンポーネントをサーバホスト側で実行させる場合にその実行位置決定から実行までについて示す図。
【図１２】サーバコンポーネントへの処理要求から処理実行までの処理全体を示す流れ図。
【図１３】図１２におけるリモートでサーバ本体を使用するための処理を示す流れ図。
【図１４】図１２におけるコンポーネントローダのコンポーネントを受け取る処理を示す流れ図。
【図１５】図１２におけるキャッシュに存在するコンポーネントを使用するための処理を示す流れ図。
【図１６】本発明の第２実施形態におけるサーバコンポーネントの構成例を示す図。
【図１７】サーバコンポーネント本体をサーバホスト側で動作させる場合のサーバコンポーネントの構成を示す図。
【図１８】サーバコンポーネント本体をクライアントホスト側で動作させる場合のサーバコンポーネントの構成を示す図。
【図１９】本発明の第３実施形態におけるサーバコンポーネントの構成例を示す図。
【図２０】サーバコンポーネント本体をサーバホスト側で動作させる場合のサーバコンポーネントの構成を示す図。
【図２１】特定のプログラミング言語でサーバコンポーネントを開発した時の様子を示す図。
【図２２】本発明の第７実施形態に係るサーバコンポーネント自動生成システムの構成例を示すブロック図。
【図２３】同実施形態におけるＪａｖａによる共通インタフェースの一例を示す図。
【図２４】同実施形態におけるＪａｖａによるサーバコンポーネント本体の一例を示す図。
【図２５】同実施形態におけるＪａｖａによるサーバ側アダプタクラスの一例を示す図。
【図２６】同実施形態におけるＪａｖａによるサーバ側アダプタクラスのＲＭＩ用インタフェースの一例を示す図。
【図２７】同実施形態におけるＪａｖａによるクライアント側アダプタの一例を示す図。
【図２８】テンプレート提供部が提供するテンプレートに対応するリストＬＣ−１〜ＬＣ７を示す図。
【図２９】テンプレート提供部が提供するテンプレートに対応するリストＬＣ−８〜ＬＣ１２を示す図。
【図３０】クラスファイル自動生成の全体の処理流れを示す流れ図。
【図３１】サーバコンポーネント本体のスケルトン生成を示す流れ図。
【図３２】共通インタフェースの自動生成を示す流れ図。
【図３３】サーバ側アダプタクラスの自動生成を示す流れ図。
【図３４】アダプタクラスの定義へ中継用メゾットを埋め込む処理を示す流れ図。
【図３５】本発明の第８実施形態におけるサーバコンポーネント自動生成システムの構成例を示すブロック図。
【図３６】同実施形態におけるＪａｖａによる共通インタフェースの一例を示す図。
【図３７】同実施形態におけるＪａｖａによるサーバコンポーネント本体の一例を示す図。
【図３８】同実施形態におけるＪａｖａによるサーバアダプタクラスの一例を示す図。
【図３９】同実施形態におけるＪａｖａによるサーバアダプタクラスのＲＭＩ用インタフェースの一例を示す図。
【図４０】同実施形態におけるＪａｖａによるクライアント側アダプタの一例を示す図。
【図４１】同実施形態におけるＪａｖａによるサーバ側リソースアクセス部共通インタフェースの一例を示す図。
【図４２】同実施形態におけるＪａｖａによるサーバ側リソースアクセス部の一例を示す図。
【図４３】同実施形態におけるＪａｖａによるＲＭＩ用インタフェースの一例を示す図。
【図４４】同実施形態におけるＪａｖａによるサーバ側リソースアクセス用サーバ側アダプタの一例を示す図。
【図４５】同実施形態におけるＪａｖａによるサーバ側リソースアクセス用クライアント側アダプタの一例を示す図。
【図４６】同実施形態におけるＪａｖａによるクライアント側リソースアクセス部のＲＭＩ用インタフェースの一例を示す図。
【図４７】同実施形態におけるＪａｖａによるクライアント側リソースアクセス部の一例を示す図。
【図４８】テンプレート提供部が提供するテンプレートに対応するリストＣ−１〜Ｃ−４を示す図。
【図４９】テンプレート提供部が提供するテンプレートに対応するリストＣ−５〜Ｃ−９，Ｃ−ａを示す図。
【図５０】テンプレート提供部が提供するテンプレートに対応するリストＣ−１０〜Ｃ−２２を示す図。
【図５１】テンプレート提供部が提供するテンプレートに対応するリストＣ−３０〜Ｃ−３４を示す図。
【図５２】テンプレート提供部が提供するテンプレートに対応するリストＣ−４０〜Ｃ−４２を示す図。
【図５３】テンプレート提供部が提供するテンプレートに対応するリストＣ−４３〜Ｃ−４６を示す図。
【図５４】テンプレート提供部が提供するテンプレートに対応するリストＣ−５０〜Ｃ−８０を示す図。
【図５５】テンプレート提供部が提供するテンプレートに対応するリストＣ−９０，Ｃ−ａ０，Ｃ−ａ１を示す図。
【図５６】テンプレート提供部が提供するテンプレートに対応するリストＣ−ｂ０〜Ｃ−ｂ２を示す図。
【図５７】自動生成の全体の処理を示す流れ図。
【図５８】サーバ側リソースアクセス部の各ファイルの作成処理を示す流れ図。
【図５９】サーバコンポーネント本体のスケルトン生成処理を示す流れ図。
【図６０】共通インタフェースの自動生成処理を示す流れ図。
【図６１】サーバ側アダプタクラスの自動生成処理を示す流れ図。
【図６２】中継用メソッド定義の作成処理を示す流れ図。
【図６３】クライアント側アダプタファイルの自動生成処理を示す流れ図。
【図６４】サーバ側リソースアクセス部の共通インタフェースファイルの自動生成処理を示す流れ図。
【図６５】本発明の第９実施形態に係る分散システムのハードウエア構成例を示すブロック図。
【図６６】本発明の第１０実施形態に係る分散システムの物理構成例を示すブロック図。
【図６７】第１０実施形態に係る分散システムの論理構成例を示すブロック図。
【図６８】サーバコンポーネント情報の一例を示す図。
【図６９】データベースアプリケーションプログラムが対象とするデータベースの一例を示す図。
【図７０】データベースアプリケーションプログラムのクライアントホストのＧＵＩの一例を示す図。
【図７１】第１０実施形態の全体の動作を示すフローチャート。
【図７２】サーバコンポーネントを動的に配置する際の動作を示すフローチャート。
【図７３】サーバコンポーネントを動的に配置する際のサーバコンポーネント情報の一例を示す図。
【図７４】データベースアクセスの際の動作を示すフローチャート。
【図７５】コンポーネントマネージャのＧＵＩの一例を示す図。
【図７６】再配置の全体の流れを示すフローチャート。
【図７７】図７６の再配置処理の詳細なフローチャート。
【符号の説明】
１…クライアントホスト
２…サーバホスト
３…ネットワーク
４…記憶装置
５…サーバコンポーネント
１１…クライアントホスト基本部分
１２…コンポーネントローダ
１３…コンポーネントキャッシュ
１４…コンポーネントサーバ
１５…実行位置決定部
１６…コンポーネントマネージャ
１７…アクセス制御監視部
１８…ネットワークモニタ
２１…サーバコンポーネント本体
２２…クライアント側アダプタ
２３…分散オブジェクト間通信
２４…サーバ側アダプタ
２５…共通インタフェース
３１…インスタンス生成部
３２…コンポーネント復号化部
３３…コンポーネント解凍部
３６…インスタンス生成部
３７…コンポーネント暗号化部
３８…コンポーネント圧縮部
４１…コンポーネント抽出部
４２…コンポーネント情報抽出部
４３…コンポーネント登録管理部
５１…クライアントリソース対応部
５２…サーバリソース対応部
５３…クライアントリソースアクセス部
５４…サーバリソースアクセス用クライアント側アダプタ
５５…分散オブジェクト間通信
５６…サーバリソースアクセス用サーバ側アダプタ
５７…サーバリソースアクセス部
５８…サーバリソースアクセス部共通インタフェース
６１…クライアントリソースアクセス用クライアント側アダプタ
６２…分散オブジェクト間通信
６３…クライアントリソースアクセス用サーバ側アダプタ
６４…クライアントリソースアクセス部共通インタフェース
７１…開発用計算機
７２…情報提供部
７３…テンプレート提供部
７４…クラスファイル自動生成部
７５…クラスファイル部
７６…本体処理内容作成部
７７…本体処理内容提供部

Claims (9)

1. クライアントとサーバからなる分散システムにおいて、
   前記クライアントは処理の要求を発するアプリケーション基本部分と、コンポーネントローダとを具備し、
   前記サーバは前記アプリケーション基本部分が要求する処理を実行するサーバコンポーネントを管理する管理手段と、前記アプリケーション基本部分からの要求を受け取り、当該処理を実行するサーバコンポーネントを前記クライアント又は前記サーバのいずれで実行するかを決定する実行位置決定手段と、前記アプリケーション基本部分から要求された処理を実行するサーバコンポーネントを前記管理手段から取得し、取得した当該サーバコンポーネントを前記実行位置決定手段における決定結果に従って処理するサーバコンポーネント引渡手段とを具備し、前記サーバコンポーネントは、要求される処理を実装しているサーバコンポーネント本体と、前記サーバと通信を行うクライアント側アダプタ、前記クライアントと通信を行うサーバ側アダプタとを具備し、
   前記サーバコンポーネント引渡手段は、
   クライアントで実行すると決定した場合、サーバコンポーネント本体をクライアントのコンポーネントローダへ送り、コンポーネントローダにサーバコンポーネント本体から実行可能なサーバコンポーネントオブジェクトを生成させる手段と、
   サーバで実行すると決定した場合、管理手段から指定されたサーバコンポーネントのクライアント側アダプタとサーバコンポーネント本体を受け取り、サーバコンポーネント本体から実行可能なサーバコンポーネントオブジェクトを生成し、サーバ側アダプタについてのオブジェクトを生成し、処理の要求を発したクライアントのコンポーネントローダへクライアント側アダプタを送り、コンポーネントローダにクライアント側アダプタを実行可能なスタブオブジェクトを生成させる手段とを具備し、
   クライアントで実行すると決定した場合、クライアントアプリケーション基本部分にサーバコンポーネント本体を利用して処理を実行させ、
   サーバで実行すると決定した場合、クライアントアプリーション基本部分にスタブオブジェクト、サーバ側アダプタを通してサーバホスト上に生成されたサーバコンポーネント本体にアクセスし処理を実行させる分散システム。
2. 前記サーバ及び前記クライアントの負荷情報、前記サーバ及び前記クライアントの処理能力に関する情報、前記サーバ及び前記クライアントを接続するネットワークの転送速度、又は前記サーバコンポーネントのサイズ情報、又は前記サーバコンポーネントの計算量情報のうち、少なくとも１つ以上を取得し、前記実行位置決定手段に提供するネットワークモニタ手段をさらに具備し、
   前記実行位置決定手段は、前記ネットワークモニタ手段から提供された情報に基づいて前記サーバコンポーネントの実行位置を決定する請求項１記載の分散システム。
3. 前記サーバは前記クライアントのユーザ情報又は前記アプリケーション基本部分の識別情報に基づき、当該アプリケーション基本部分の発する処理要求を受け付けるか否かを判定するアクセス制御監視手段を具備し、
   前記実行位置決定手段は、前記アクセス制御監視手段の判定結果に基づき、前記サーバコンポーネントを実行させるか否かをも決定する請求項１記載の分散システム。
4. 前記サーバコンポーネントは、前記サーバコンポーネント本体と前記クライアント側アダプタとの共通のインターフェースを定義する共通インターフェースをさらに具備する請求項１記載の分散システム。
5. 前記サーバコンポーネントは、クライアントリソースへアクセスするクライアントリソースアクセス部と、
   サーバリソースへアクセスするサーバリソースアクセス部と、
   サーバコンポーネント本体がクライアント側で実行される場合に、サーバリソースアクセス部と通信するためのサーバリソースアクセス用クライアント側アダプタ及びサーバリソースアクセス用サーバ側アダプタとをさらに具備する請求項１記載の分散システム。
6. 前記サーバコンポーネントは、クライアントリソースへアクセスするクライアントリソースアクセス部と、サーバリソースへアクセスするサーバリソースアクセス部と、サーバコンポーネント本体がクライアント側で実行される場合に、サーバリソースアクセス部と通信するためのサーバリソースアクセス用クライアント側アダプタ及びサーバリソースアクセス用サーバ側アダプタと、サーバコンポーネント本体がサーバ側で実行される場合に、クライアントリソースアクセス部と通信するためのクライアントリソースアクセス用クライアント側アダプタ及びクライアントリソースアクセス用サーバ側アダプタとをさらに具備する請求項１記載の分散システム。
7. 請求項１記載の分散システムに用いられるサーバコンポーネントを生成するサーバコンポーネント生成装置であって、
   サーバコンポーネントの複数のテンプレートを提供するテンプレート提供手段と、
   前記サーバコンポーネントに関する情報を提供する情報提供手段と、
   前記テンプレートを組み合わせ、また、テンプレートに前記情報を当てはめることでサーバコンポーネントを生成するプログラム生成手段と、
   を具備するサーバコンポーネント生成装置。
8. 処理の要求を発するアプリケーション基本部分と、コンポーネントローダとを具備するクライアントと、
   前記アプリケーション基本部分が要求する処理を実行するサーバコンポーネントを管理する管理手段と、前記アプリケーション基本部分からの要求を受け取り、当該処理を実行するサーバコンポーネントを前記クライアント又は前記サーバのいずれで実行するかを決定する実行位置決定手段と、前記アプリケーション基本部分から要求された処理を実行するサーバコンポーネントを前記管理手段から取得し、取得した当該サーバコンポーネントを前記実行位置決定手段における決定結果に従って処理するサーバコンポーネント引渡手段とを具備し、前記サーバコンポーネントは、要求される処理を実装しているサーバコンポーネント本体と、前記サーバと通信を行うクライアント側アダプタ、前記クライアントと通信を行うサーバ側アダプタとを具備するサーバとからなる分散システムの制御方法において、
   クライアントで実行すると決定した場合、サーバコンポーネント本体をクライアントのコンポーネントローダへ送り、コンポーネントローダにサーバコンポーネント本体から実行可能なサーバコンポーネントオブジェクトを生成させるステップと、
   サーバで実行すると決定した場合、管理手段から指定されたサーバコンポーネントのクライアント側アダプタとサーバコンポーネント本体を受け取り、サーバコンポーネント本体から実行可能なサーバコンポーネントオブジェクトを生成し、サーバ側アダプタについてのオブジェクトを生成し、処理の要求を発したクライアントのコンポーネントローダへクライアント側アダプタを送り、コンポーネントローダにクライアント側アダプタを実行可能なスタブオブジェクトを生成させるステップとを具備し、
   クライアントで実行すると決定した場合、クライアントアプリケーション基本部分にサーバコンポーネント本体を利用して処理を実行させ、
   サーバで実行すると決定した場合、クライアントアプリーション基本部分にスタブオブジェクト、サーバ側アダプタを通してサーバホスト上に生成されたサーバコンポーネント本体にアクセスし処理を実行させる分散システムの制御方法。
9. コンピュータを動作させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体において、
   前記プログラムは、処理の要求を発するアプリケーション基本部分とコンポーネントローダとを具備するクライアントと共に分散システムを構成するサーバコンピュータを
   前記アプリケーション基本部分が要求する処理を実行するサーバコンポーネントを管理する管理手段と、
   前記アプリケーション基本部分からの要求を受け取り、当該処理を実行するサーバコンポーネントを前記クライアント又は前記サーバのいずれで実行するかを決定する実行位置決定手段と、
   前記アプリケーション基本部分から要求された処理を実行するサーバコンポーネントを 前記管理手段から取得し、取得した当該サーバコンポーネントを前記実行位置決定手段における決定結果に従って処理するサーバコンポーネント引渡手段として機能させ、
   前記サーバコンポーネントは、要求される処理を実装しているサーバコンポーネント本体と、前記サーバと通信を行うクライアント側アダプタ、前記クライアントと通信を行うサーバ側アダプタとを具備し、
   前記サーバコンポーネント引渡手段は、
   クライアントで実行すると決定した場合、サーバコンポーネント本体をクライアントのコンポーネントローダへ送り、コンポーネントローダにサーバコンポーネント本体から実行可能なサーバコンポーネントオブジェクトを生成させ、
   サーバで実行すると決定した場合、管理手段から指定されたサーバコンポーネントのクライアント側アダプタとサーバコンポーネント本体を受け取り、サーバコンポーネント本体から実行可能なサーバコンポーネントオブジェクトを生成し、サーバ側アダプタについてのオブジェクトを生成し、処理の要求を発したクライアントのコンポーネントローダへクライアント側アダプタを送り、コンポーネントローダにクライアント側アダプタを実行可能なスタブオブジェクトを生成させ、クライアントアプリーション基本部分にスタブオブジェクト、サーバ側アダプタを通してサーバホスト上に生成されたサーバコンポーネント本体にアクセスし、処理を実行させることを特徴とする記録媒体。

Images