JP3558887B2 - Distributed system, control method thereof, and storage medium - Google Patents

Distributed system, control method thereof, and storage medium Download PDF

Info

Publication number
JP3558887B2
JP3558887B2 JP24361498A JP24361498A JP3558887B2 JP 3558887 B2 JP3558887 B2 JP 3558887B2 JP 24361498 A JP24361498 A JP 24361498A JP 24361498 A JP24361498 A JP 24361498A JP 3558887 B2 JP3558887 B2 JP 3558887B2
Authority
JP
Japan
Prior art keywords
server
client
component
server component
unit
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP24361498A
Other languages
Japanese (ja)
Other versions
JP2000076172A (en
Inventor
孝信 安東
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Toshiba Corp
Original Assignee
Toshiba Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Toshiba Corp filed Critical Toshiba Corp
Priority to JP24361498A priority Critical patent/JP3558887B2/en
Priority to US09/383,963 priority patent/US6678715B1/en
Publication of JP2000076172A publication Critical patent/JP2000076172A/en
Application granted granted Critical
Publication of JP3558887B2 publication Critical patent/JP3558887B2/en
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/485—Task life-cycle, e.g. stopping, restarting, resuming execution
    • G06F9/4856—Task life-cycle, e.g. stopping, restarting, resuming execution resumption being on a different machine, e.g. task migration, virtual machine migration
    • G06F9/4862—Task life-cycle, e.g. stopping, restarting, resuming execution resumption being on a different machine, e.g. task migration, virtual machine migration the task being a mobile agent, i.e. specifically designed to migrate

Description

【０００１】
【発明の属する技術分野】
本発明は複数のコンピュータが接続されてなる分散システムに関し、特に、要求された処理の実行位置決定の改良に関する。
【０００２】
【従来の技術】
近年のコンピュータ・通信技術の発達により、コンピュータは単体で使用するよりも、ＬＡＮ，ＷＡＮあるいはインターネット等の種々の形態のネットワークシステムを構築し、そのネットワークの中で資源共有等を行って使用される場合が多くなってきている。このようなネットワークシステムの中で、処理を要求するコンピュータ（クライアントホスト）に対して何らかの処理を行う他のコンピュータ（サーバホスト）が存在するシステムは、クライアント・サーバシステムあるいは分散システム（以下、本明細書では分散システムと称する）と呼ばれている。このような分散システムによれば、クライアントホストの要求する処理を、その時のネットワークシステムの状況や処理内容に応じて当該クライアントホスト以外のサーバホスト等で実行させることも可能である。
【０００３】
従来の分散システムは大きく３種類に分類される。以下それぞれについて説明する。
【０００４】
第１の形態は、メインフレームに代表される垂直型分散システムである。垂直型分散システムでは基本的にはクライアントホストからサーバホストヘ処理を依頼し、サーバホストはその処理を実行し、クライアントホストはその処理結果をサーバから受け取る。
【０００５】
このような垂直型の分散システムでは次に示すような問題点がある。
【０００６】
（１）クライアントホストが多数のサーバホストヘ接続されている場合、サーバホストへの過負荷が原因で処理全体のスループットが低下する。
【０００７】
（２）処理を依頼するたびにネットワーク経由での通信を行なうため、ネットワークトラフィックが増大する。
【０００８】
第２の形態は、水平型分散システムである。水平型分散システムでは、必要なデータをサーバホストに存在するデータベースマネジメントシステム（ＤＭＢＳ）などへ要求し、それから得られた情報に対する処理はクライアントホストで行うようにする。これにより、上記垂直型分散システムの問題点（１）、（２）をある程度克服できる。
【０００９】
ただし、このシステムでは次のような問題点が挙げられる。
【００１０】
（３）クライアントホストにある程度の処理能力やリソースが必要となる。
【００１１】
（４）クライアントホストとデータベースマネンジメントシステムが密接に関わっているため、データベースマネンジメントシステムの変更等に対処するためのシステムの柔軟性が低い。
【００１２】
（５）クライアントホスト毎にアプリケーションプログラム管理を行なわなければならない。
【００１３】
第３の形態は、２次記憶（ＨＤＤなど）を持たないネットワークコンピュータ（ＮＣ）や、モバイル環境向けのモバイルネットワークコンピュータ（ＭＮＣ）などによって構成される分散ネットワークシステムである。なお、分散ネットワークシステムでは、通常のパーソナルコンピュータ（ＰＣ）やワークステーション（ＷＳ）も当然に端末となりうる。この分散ネットワークシステムでは、クライアントがサーバヘ処理を要求するとその処理を実行するサーバコンポーネントがクライアントホストヘ送られてきて、その処理をクライアントホスト上で実行する。近年のＪａｖａアプレットがこれに相当する。
【００１４】
このシステムでは、水平分散システムの（５）の問題点が克服される。ただし、（３）の問題点は逆に強調されてしまう。クライアントホストが処理能力の高いパーソナルコンピュータやワークステーションの場合であればまだしも、ネットワークコンピュータやモバイルネットワークコンピュータはそれらに比べれば処理能力が低いためである。またそれに伴い、次のような問題点もある。
【００１５】
（６）サーバが低負荷な場合であれば、クライアント側で処理を実行するよりもサーバ側で処理を実行するほうが、処理全体のスループットが向上する。
【００１６】
また、これらの問題点の他に、上記３つの形態のシステムにおいて、共通に次の問題点がある。
【００１７】
（７）ソフトウェアの構造（処理コンポーネントの実行位置）が静的に決められているので、動的に変動するネットワーク環境に対して柔軟性に欠ける。
【００１８】
（８）システム設計（どのホストにどの処理を実行させるかを決定する）が難しく、また柔軟性に欠けるため、後からの変更や新しい仕様の追加においても、問題が発生する可能性がある。
【００１９】
なお、分散環境における負荷分散システムやモバイル環境向けのエージェントシステムでは、ネットワーク上での処理コンポーネントの動的な移動／配置を行い、システムの柔軟性を向上する従来例がある。しかし、このようなシステムにおいても、次のような問題点がある。
【００２０】
（９）クライアントホスト側で実行する場合、通常、クライアントコンポーネントとサーバコンポーネントが別コンポーネントであるため、コンポーネント間通信が必要であり、そのためのオーバヘッドが問題となる。
【００２１】
【発明が解決しようとする課題】
このように従来の分散システムでは、特定の処理を提供するコンポーネントの実行場所はそのシステムの開発者によって静的に決められてる。したがって、あるコンポーネントは必ずクライアントホスト側で実行され、またある別のコンポーネントは必ずサーバホスト側で実行されることになる。
【００２２】
また、従来技術では、形態１、形態２、形態３と進むにつれて問題点が少なくなっているように見えるが必ずしもそうではない。つまり、ネットワークシステムでは、コンピュータ環境が動的に変化するものであり、このコンピュータ環境の動的変化と、上記コンポーネント実行場所の固定性とが相俟って処理効率の向上を容易に行えないものとなっている。
【００２３】
したがって、上記いずれ形態の分散システムをとったとしても、環境の動的変化のため、常に理想的な状態で処理を行えるとは限らず、そのシステム本来の機能を発揮できない。例えば、あるサーバに非常に多くのクライアントが接続し、サーバの負荷が大きくなるために、垂直型システムから水平型又は分散ネットワークシステムに変更したとしても、分散化が進みすぎて逆にサーバが低負荷となり、ある処理はサーバ側で処理を実行するほうが、処理全体のスループットが向上するということになりかねない。
【００２４】
このようなコンピュータ環境の動的な変化に対応しつつ、処理のスループットを向上させるためには、処理を行うコンポーネントの実行位置を動的に変更できる仕組みを作ることが望ましい。
【００２５】
また、システムのスケーラビリティを考慮した種々のネットワークシステムの開発においても、実行位置は静的に決められているよりも動的に変化可能であることが好ましい。
【００２６】
処理の実行位置を動的に決定するためには、処理を実装したプログラム（実行可能な形式にされたもの）を対象とするコンピュータ全てに予めインストールしておくことが必要である。これにより、処理の実行位置をこれらのコンピュータの中から実行時に選択して、そのコンピュータに処理を実行させることが可能でなる。フォールトトレランスや負荷分散の目的でこのような分散システムを構築することが可能である。
【００２７】
しかし、全てのコンピュータに対するプログラムのインストールや保守管理は非常に大変であり、現実的ではない。
【００２８】
また、処理の実行位置を処理の実行後に切り替えるものとしてモバイルエージェントと呼ばれるものがある。これは分散システム上の指定されたコンピュータを対象とし、それらを巡回しながら処理を行なうものである。具体的には、あるコンピュータで処理を行ない、その終了後に別のコンピュータに移り、同様の処理を行なう。以降、これを指定された全てのコンピュータ上で行なうよう繰り返す。このような分散システムは、主に情報収集やシステム監視などの目的で利用される。
【００２９】
しかし、モバイルエージェントでは、基本的に、処理に関係するプログラムが１つのまとまりとなって、その全てが対象となるコンピュータへ移動し（配送され）、動作する。そのため、特定のコンピュータの資源を利用するような構造をモバイルエージェント自身が持つことができない。
【００３０】
さらに、上述の第３の形態でも説明したＪａｖａアプレットのように、処理プログラムを提供するサーバホストから処理を要求したクライアントホストへ処理プログラムを配信し、クライアントホスト側で実行するようなシステムもある。これにより、処理プログラムは一箇所にのみインストールすればよく、処理プログラムの保守管理やインストール作業が容易になる。
【００３１】
しかし、このシステムでも、処理の実行場所は静的に決まっており、分散システムの構成（処理を分散システム内のどのコンピュータで実行するか）を柔軟に変更することができない。そのため、負荷分散などの目的には使えない。
【００３２】
さらに、上記した各従来例では、モバイルエージェントを除き、基本的に、一度実行した場所を途中で変更することはできない。また、モバイルエージェントの場合は通常、一連の移動−処理が終了するまで、処理を依頼したクライアントとの接続を切断する。すなわち、常時接続されているわけではないため、処理中に何らかの指示をクライアント側から与えることが難しい。
【００３３】
本発明は、このような実情を考慮してなされたもので、クライアントが要求した処理の実行位置をクライアント側にするか、サーバ側にするかを動的に変更し、システム構成を柔軟に変化させることが可能な分散システムを提供することを目的とする。
【００３４】
【課題を解決するための手段】
前記課題を解決し目的を達成するために、本発明は以下に示す手段を用いている。
【００３５】
（１）本発明の分散システムは、クライアントとサーバからなる分散システムにおいて、
前記クライアントは処理の要求を発するアプリケーション基本部分と、コンポーネントローダとを具備し、
前記サーバは前記アプリケーション基本部分が要求する処理を実行するサーバコンポーネントを管理する管理手段と、前記アプリケーション基本部分からの要求を受け取り、当該処理を実行するサーバコンポーネントを前記クライアント又は前記サーバのいずれで実行するかを決定する実行位置決定手段と、前記アプリケーション基本部分から要求された処理を実行するサーバコンポーネントを前記管理手段から取得し、取得した当該サーバコンポーネントを前記実行位置決定手段における決定結果に従って処理するサーバコンポーネント引渡手段とを具備し、前記サーバコンポーネントは、要求される処理を実装しているサーバコンポーネント本体と、前記サーバと通信を行うクライアント側アダプタ、前記クライアントと通信を行うサーバ側アダプタとを具備し、
前記サーバコンポーネント引渡手段は、
クライアントで実行すると決定した場合、サーバコンポーネント本体をクライアントのコンポーネントローダへ送り、コンポーネントローダにサーバコンポーネント本体から実行可能なサーバコンポーネントオブジェクトを生成させる手段と、
サーバで実行すると決定した場合、管理手段から指定されたサーバコンポーネントのクライアント側アダプタとサーバコンポーネント本体を受け取り、サーバコンポーネント本体から実行可能なサーバコンポーネントオブジェクトを生成し、サーバ側アダプタについてのオブジェクトを生成し、処理の要求を発したクライアントのコンポーネントローダへクライアント側アダプタを送り、コンポーネントローダにクライアント側アダプタを実行可能なスタブオブジェクトを生成させる手段とを具備し、
クライアントで実行すると決定した場合、クライアントアプリケーション基本部分にサーバコンポーネント本体を利用して処理を実行させ、
サーバで実行すると決定した場合、クライアントアプリーション基本部分にスタブオブジェクト、サーバ側アダプタを通してサーバホスト上に生成されたサーバコンポーネント本体にアクセスし処理を実行させる分散システム。
【００３６】
これによれば、処理の実行位置を動的に変更し、システム構成を柔軟に変化させることができる。
【００３９】
（２）本発明の分散システムは、上記（１）に記載した分散システムであって、かつ前記サーバ及び前記クライアントの負荷情報、前記サーバ及び前記クライアントの処理能力に関する情報、前記サーバ及び前記クライアントを接続するネットワークの転送速度、又は前記サーバコンポーネントのサイズ情報、又は前記サーバコンポーネントの計算量情報のうち、少なくとも１つ以上を取得し、前記実行位置決定手段に提供するネットワークモニタ手段をさらに具備し、前記実行位置決定手段は、前記ネットワークモニタ手段から提供された情報に基づいて前記サーバコンポーネントの実行位置を決定するものである。
【００４０】
これによれば、クライアントからの処理要求を、処理結果が速く得られるようにサーバコンポーネントの実行位置を切り替えることができ、スループットの向上につながる。
【００４１】
（４）本発明の分散システムは、上記（２）に記載した分散システムであって、かつ前記サーバは前記クライアントのユーザ情報又は前記アプリケーション基本部分の識別情報に基づき、当該アプリケーション基本部分の発する処理要求を受け付けるか否かを判定するアクセス制御監視手段を具備し、前記実行位置決定手段は、前記アクセス制御監視手段の判定結果に基づき、前記サーバコンポーネントを実行させるか否かをも決定するものである。
【００４２】
これによれば、クライアントのユーザ情報やクライアントホスト情報によりサーバコンポーネントへのアクセスを制御することが可能である。
【００４３】
（５）本発明の分散システムは、上記（２）に記載した分散システムであって、かつ前記サーバコンポーネントは、要求される処理を実装しているサーバコンポーネント本体と、前記サーバと通信を行うクライアント側アダプタ、前記クライアントと通信を行うサーバ側アダプタと、前記サーバコンポーネント本体と前記クライアント側アダプタとの共通のインターフェースを定義する共通インターフェースとを具備するものである。
【００４４】
これによれば、サーバコンポーネント本体は１つですむので、サーバコンポーネント開発者は同一のプログラムを一度だけ実装すればよい。さらに、サーバコンポーネント本体とクライアント側アダプタが共通のインターフェースを実装しているため、クライアントから両者へ一様にアクセスすることができる。サーバコンポーネント本体をクライアントホスト側で実行する場合は、クライアントホストアプリケーション基本部分とサーバコンポーネント本体の間に通信のためのアダプタを使用しないため、処理要求におけるオーバーヘッドが無い。
【００４５】
（６）本発明の分散システムは、上記（５）に記載した分散システムであって、かつ前記サーバコンポーネントは、クライアントリソースへアクセスするクライアントリソースアクセス部と、サーバリソースへアクセスするサーバリソースアクセス部と、サーバコンポーネント本体がクライアント側で実行される場合に、サーバリソースアクセス部と通信するためのサーバリソースアクセス用クライアント側アダプタ及びサーバリソースアクセス用サーバ側アダプタとをさらに具備するものである。
【００４６】
これにより、処理本体は移動可能であり、かつクライアントホスト上のリソースやサーバホスト上のリソースへアクセスするような移動可能な処理コンポーネントを開発可能となる。
【００４７】
（７）本発明の分散システムは、上記（５）に記載した分散システムであって、かつ前記サーバコンポーネントは、クライアントリソースへアクセスするクライアントリソースアクセス部と、サーバリソースへアクセスするサーバリソースアクセス部と、サーバコンポーネント本体がクライアント側で実行される場合に、サーバリソースアクセス部と通信するためのサーバリソースアクセス用クライアント側アダプタ及びサーバリソースアクセス用サーバ側アダプタと、サーバコンポーネント本体がサーバ側で実行される場合に、クライアントリソースアクセス部と通信するためのクライアントリソースアクセス用クライアント側アダプタ及びクライアントリソースアクセス用サーバ側アダプタとをさらに具備するものである。
【００４８】
これにより、処理本体は移動可能であり、かつクライアントホスト上のリソースやサーバホスト上のリソースへアクセスするような移動可能な処理コンポーネントを開発可能となる。さらに、処理をサーバコンポーネント本体に集中させることが可能となり、サーバコンポーネントの開発が容易になる。
【００４９】
（８）本発明のサーバコンポーネント生成装置は、処理の要求を発するアプリケーション基本部分を有するクライアントと、前記アプリケーション基本部分が要求する処理を実行するサーバコンポーネントを管理する管理手段と、前記アプリケーション基本部分からの要求を受け取り、当該処理を実行するサーバコンポーネントを前記クライアント又は前記サーバのいずれで実行するかを決定する実行位置決定手段と、前記アプリケーション基本部分から要求された処理を実行するサーバコンポーネントを前記管理手段から取得し、取得した当該サーバコンポーネントを前記実行位置決定手段における決定結果に従って前記クライアント又は前記サーバに引き渡すサーバコンポーネント引渡手段とを有するサーバとを具備する分散システムに用いられるサーバコンポーネントを生成するサーバコンポーネント生成装置であって、サーバコンポーネントの複数のテンプレートを提供するテンプレート提供手段と、前記サーバコンポーネントに関する情報を提供する情報提供手段と、前記テンプレートを組み合わせ、また、テンプレートに前記情報を当てはめることでサーバコンポーネントを生成するプログラム生成手段と、を具備するものである。
【００５０】
（９）本発明の分散システムは、クライアントから要求される処理の実行位置を、実行前に任意のコンピュータに決定し、処理を実行するサーバコンポーネントを管理する管理手段から当該処理を実行するサーバコンポーネントを取得し、取得した当該サーバコンポーネントを決定したコンピュータに引き渡し、決定したコンピュータから処理結果を受け取り、クライアントへ引き渡すメーンサーバを具備するものである。
【００５１】
（１０）本発明の分散システムは、上記（９）に記載した分散システムであって、かつ前記メインサーバは、一度実行位置を決定し、決定したコンピュータで実行しているサーバコンポーネントの実行位置を他の計算機に変更するものである。
【００５２】
（１１）本発明のクライアントとサーバからなる分散システムを制御するプログラムを記録するコンピュータ読取り可能な記録媒体は、前記クライアントのアプリケーション基本部分が要求する処理のサーバコンポーネントを管理する管理手段と、前記アプリケーション基本部分からの要求を受け取り、前記サーバコンポーネントを前記クライアント又は前記サーバのいずれで実行するかを決定する実行位置決定手段と、前記サーバコンポーネントを前記管理手段から取得し、取得した当該サーバコンポーネントを前記実行位置決定手段における決定結果に従って前記クライアント又は前記サーバに引き渡すサーバコンポーネント引渡手段とを実行するプログラムを記録したコンピュータ読み取り可能な記録媒体である。
【００５３】
（１２）本発明のクライアントとサーバからなり、前記クライアント上のアプリケーション基本部分が要求する処理をクライアントで実行させるかサーバで実行させるかを動的に変更可能とする分散システムを制御するプログラムを記録するコンピュータ読取り可能な記録媒体は、前記クライアント上のアプリケーション基本部分が要求する処理をクライアント又はサーバいずれにおいても実行可能とするサーバコンポーネント手段と、このサーバコンポーネント手段をサーバで実行させる場合に、前記アプリケーション基本部分と間の通信を確保するための通信処理手段とを実行するプログラムを記録したコンピュータ読み取り可能な記録媒体である。
【００５４】
【発明の実施の形態】
以下、図面を参照して本発明による分散システムの実施形態を説明する。
【００５５】
（第１実施形態）
図１は本発明の第１実施形態に係る分散システムのハードウエア構成例を示すブロック図である。
【００５６】
この分散システムは、クライアントホスト１とサーバホスト２とがネットワーク３を介して接続されて構成されている。クライアントホスト１とはクライアントアプリケーションプログラムが存在し、処理を行う要求を発するホストマシンを指し、サーバホスト２とはクライアントからの要求を受けて、処理を実行するホストマシンを指す。複数のホストマシンが存在する場合、クライアントホスト以外のホストマシンは全てサーバホストとなり得る。クライアントホスト１としては、パーソナルコンピュータ、ワークステーション、ネットワークコンピュータ（ＮＣ）あるいはモバイルネットワークコンピュータ（ＭＮＣ）等が用いられ、サーバホスト２としては、パーソナルコンピュータ、ワークステーション、大型コンピュータ（メインフレーム）等が用いられる。
【００５７】
ネットワーク３としては、高速なＬＡＮや低速な公衆回線、無線ＬＡＮ等が用いられる。したがって、このネットワークシステムは、ＬＡＮ，ＷＡＮ，ＶＰＮ（バーチャルプライベートネットワーク），インターネット等として構成される。なお、本システムでは、クライアントホスト１とサーバホスト２とは常時接続されている必要はない。
【００５８】
サーバホスト２は、ハードディスク（ＨＤＤ）等からなる記憶装置４と接続され、当該記憶装置４には多数の処理プログラムであるサーバコンポーネント５が格納されて、一種のデータベースをなしている。このデータベースをコンポーネントリポジトリ（Ｃｏｍｐｏｎｅｎｔ Ｒｅｐｏｓｉｔｏｒｙ）ともいう。なお、記憶装置４は、図１に示すように、ＳＣＳＩ等によって直接サーバホスト２と接続されていてもよいし、記憶装置管理サーバを搭載する別ホストを介してサーバホスト２と接続されていてもよい。
【００５９】
サーバコンポーネント５については後述するが、簡単にいえばクライアントホスト１が要求する処理を実行するプロセス、あるいはプロセス群である。本実施形態は、このサーバコンポーネント５における要求処理部分をサーバ側とクライアント側の何れで実行させるかを自動的に決定し、さらに、その決定に従って実際に処理を実行できる状態を作り上げることを主たる目的としている。
【００６０】
次に、この分散システムにおけるシステム論理構成（ソフトウェアリソース）について説明する。
【００６１】
図２は本実施形態の分散システムにおけるソフトウェア論理構成を示す図である。
【００６２】
同図において、中央の破線より左側がクライアントホスト１側、右側がサーバホスト２側を示している。サーバコンポーネント５はクライアントホスト１、サーバホスト２の何れのホストマシンででも実行できるので、ここでは同図のように破線上に配置した。
【００６３】
クライアントホスト１には、クライアントアプリケーション基本部分１１、コンポーネントローダ１２、コンポーネントキャッシュ１３及びクライアントホスト１にて実行するように決定されたサーバコンポーネント５が設けられる。
【００６４】
一方、サーバホスト２には、コンポーネントサーバ１４、実行位置決定部１５、コンポーネントマネージャ１６、アクセス制御監視部１７、ネットワークモニタ１８及びサーバホスト２にて実行するように決定されたサーバコンポーネント５が設けられる。なお、ネットワークモニタ１８は、ネットワークシステム上の他のホストに設けられる場合もあり、その場合にはサーバホスト２はネットワーク３を介して当該ネットワークモニタ１８から必要な情報を得る。コンポーネントマネージャ１６には記憶装置４が接続される。
【００６５】
クライアントアプリケーション基本部分１１からコンポーネントローダ１２を介してコンポーネントサーバ１４へ処理プロセスであるサーバコンポーネント５を要求する。コンポーネントサーバ１４では要求されたサーバコンポーネント５をサーバホスト２、クライアントホスト１のどちらで動作させるかを決定する。
【００６６】
上記各部について具体的に説明する前に、クライアントホスト１が要求する処理、及びその処理実現のためにサーバコンポーネント５がどのようになっているのかについて説明する。
【００６７】
クライアントホスト１は、その使用者の要求に応じて種々の処理を実現する。多くの場合、アプリケーションプログラムは、単一の処理のみから構成されるのではなく、複数の処理からなっている。したがって、これを最も基本的な部分と、その他の各処理の部分に分けることができる。
【００６８】
図３は本実施形態のアプリケーションプログラムの構成例を示す図である。
【００６９】
本実施形態のシステムでは、同図（ａ）に示すようにアプリケーションプログラムがクライアントアプリケーション基本部分１１と、サーバコンポーネント５とに分割されている。なお、サーバコンポーネント５は複数個あってもよい。
【００７０】
ここで、クライアントアプリケーション基本部分１１は、アプリケーションプログラムの最も基本となる部分で、アプリケーションプログラムの起動と最小限の機能、サーバコンポーネント５のリクエスト発行、サーバコンポーネント５を利用した処理結果の表示等を行う。したがって、この基本部分１１は図２に示すように、クライアントホスト１に置かれる。一方、サーバコンポーネント５は、そのアプリケーションプログラムにおける実体的な処理の部分である。
【００７１】
図３（ｂ）では、具体例として、アプリケーションプログラムが画像処理ソフトウエアであったときの構成を示す。この例では、クライアントアプリケーション基本部分１１は画像処理アプリケーション基本部分１１ａであり、サーバコンポーネント５として平滑化処理用コンポーネント５ａが設けられている。
【００７２】
本実施形態は、クライアント側で動作する処理プロセスと、サーバ側で動作する処理プロセスとを二重に開発することを避けるために、サーバコンポーネントの開発者は同様の処理ロジックを一度だけ実装すればよい（すなわち、同じような実装を複数箇所に分散させない）ように構成されている。また、クライアントはサーバコンポーネントの実行位置に依存すること無く、処理を実行できるようにするために、サーバ側で動作する場合とクライアント側で動作する場合とで、クライアント側から見たサーバコンポーネントのインターフェース（サーバコンポーネントへのアクセス方法、より具体的にはメソッド名、引数の型と数、返り値の型；シグネチャと呼ばれる）を一致させている。さらに、処理をサーバ側で実行する場合は、サーバコンポーネントとクライアントの間で何らかの通信手段を用いて分散オブジェクト間通信を行う必要がある。また、ＧＵＩを表示したり（基本的には常にクライアント側へ表示）、サーバ側にあるデータベースマネジメントシステムへアクセスしたりする場合、すなわち固有のホストリソースへアクセスするようなサーバコンポーネントも考えられる。また、クライアント側のアプリケーションプログラムと非同期に通信を行う可能性もある。
【００７３】
このような要求を実現するために、本発明の移動可能なサーバコンポーネントは幾つかの要素に分けて構成する。
【００７４】
図４は第１実施形態におけるサーバコンポーネント５の構成例を示す図である。
【００７５】
同図に示すように、サーバコンポーネント５は、サーバコンポーネント本体２１、クライアント側アダプタ２２、サーバ側アダプタ２４からなり、クライアント側アダプタ２２とサーバ側アダプタ２４とは分散オブジェクト間通信２３により接続される。このうちサーバコンポーネント本体２１及びクライアント側アダプタ２２には、共通インタフェース２５が実装される。また、サーバ側アダプタ２４にはインターフェースが実装される場合もある。なお、サーバホスト２の記憶装置４には、上記のうち分散オブジェクト間通信２３を除く各部分に対応するファイルがサーバコンポーネント５として格納されている。
【００７６】
ここで、サーバコンポーネント本体２１は、クライアントアプリケーション基本部分１１が本来要求する処理を実行する部分であり、アプリケーションにおける実体的な処理部分である。すなわちサーバコンポーネント本体２１には、そのサーバコンポーネント５が提供する処理が実装されている。処理をクライアント側で実行する場合には、この本体２１がクライアント側へ送られ、実行可能な状態にされた後、クライアント側からの処理を受け付ける。この場合、コンポーネント本体２１がクライアント側から直接呼出されるために、アダプタ２２等を通すオーバーヘッドは存在しない。これに対し、サーバ側で処理を実行する場合は、本体２１とそれに接続するサーバ側アダプタ２４がサーバ側で実行可能な状態にされる。クライアントホスト１へはクライアント側アダプタ２２が送られる。このクライアント側アダプタ２２がクライアント側で実行可能な状態にされ、サーバ側アダプタ２４との接続を行い通信の準備を行う。クライアントホスト１はクライアントアダプタ２２、サーバ側アダプタ２４を通してコンポーネント本体２１の処理を実行させる。すなわち、両アダプタ２２、２４は分散オブジェクト間通信を用いて処理の呼出しをリレーするだけの部品である。このため、サーバコンポーネント本体２１は１つのみでよく、クライアント側で動作する処理プロセスと、サーバ側で動作する処理プロセスとを二重に開発することを避けることができる。
【００７７】
共通インタフェース２５の定義はそのサーバコンポーネントに処理を実行させるためのアクセス方式（メソッド（関数）名、引数の型や数、返り値）を定義している。クライアント側アダプタ２２（リモート接続用スタブ）は、サーバコンポーネント本体２１へのリモートの接続を行うためのスタブである。なお、以下特に断らないが、サーバコンポーネント本体２１及びクライアント側アダプタ２２には、共通インタフェース２５が必ず実装される。これにより、クライアントアプリケーション基本部１１からは共通インタフェース定義で決められているアクセス方式に従って、直接にアクセスする相手がサーバコンポーネント本体２１、又はクライアント側アダプタ２２のどちらであっても、一様にアクセスすることができるようになる。このため、クライアントホストはサーバコンポーネントの実行位置に依存すること無く、処理を実行できる。
【００７８】
分散オブジェクト間通信２３としては、どのような技術を用いてもよい。例えば、ＣＯＲＢＡ、ＪａｖａＲＭＩ、ＰＤＯ等を用いることができる。これらの実装の差異は両ホストのアダプタで吸収される。これにより、特定のオブジェクト間通信技術に依存すること無く、本システムを実装できる。また、通信の実装を変更する場合の対処も容易になる。
【００７９】
図４に示す各構成は、その全てが常に使用されるのではなく、サーバコンポーネント本体２１がクライアントホスト１又はサーバホスト２の何れで実行されるかにより、その組み合わせが動的に変更されるものである。
【００８０】
図５はサーバコンポーネント本体２１がクライアントホスト１で実行される場合と、サーバホスト２で実行される場合の構成を示す図である。
【００８１】
同図（ａ）には、サーバコンポーネント本体２１がクライアントホスト１で実行される場合を示す。この場合には、共通インターフェース２５及びサーバコンポーネント本体２１がクライアントホスト１内に設けられ、クライアントアプリケーション基本部分１１、共通インターフェース２５及びサーバコンポーネント本体２１がサーバコンポーネント５を構成する。クライアントアプリケーション基本部分１１は、共通インターフェース２５を介してサーバコンポーネント本体２１に要求を出す。
【００８２】
同図（ｂ）には、サーバコンポーネント本体２１がサーバホスト２で実行される場合を示す。この場合には、共通インターフェース２５が実装されているクライアント側アダプタ２２、サーバ側アダプタ２４及び共通インターフェース２５実装のサーバコンポーネント本体２１がサーバコンポーネント５を構成する。クライアント側アダプタ２２とサーバ側アダプタ２４とは分散オブジェクト間通信２３により接続される。クライアントアプリケーション基本部分１１は、各部２５，２２，２３，２４，２５を介してサーバホスト２に設けられたサーバコンポーネント本体２１に要求を出す。
【００８３】
なお、記憶装置４に当初格納され、また、コンポーネントマネージャ１６に管理されているサーバコンポーネント５の当初状態は図４に示した通りである。この当初状態のサーバコンポーネント５の各要素が記憶装置４から取り出され、図５（ａ），（ｂ）に示されたようにクライアントホスト１及びサーバホスト２上で処理実行機能として構成された場合も、これらは全体としてサーバコンポーネント５である。ただし、その構成要素及び構成要素のホスト１，２での配置は状況によって異なることになる。
【００８４】
さて、図２に示した各部１２，１３，１４，１５，１６，１７，１８，４は、図５に示すような動的に変更し得るサーバコンポーネント５の実行位置，具体的にはサーバコンポーネント本体２１の配置位置を決定し、図５（ａ）、（ｂ）の何れかの状態を作るための処理を行うものである。なお、コンポーネントキャッシュ１３はコンポーネントローダ１２に、実行位置決定部１５及びアクセス制御監視部１７はコンポーネントサーバ１４に本来含まれるものであるが、後の動作説明の都合上、図２ではこれらを独立した手段として示している。以下、これらの構成について説明する。
【００８５】
図６はコンポーネントローダ１２の構成例を示す図である。
【００８６】
コンポーネントローダ１２は、クライアントアプリケーション基本部分１１から生じるサーバコンポーネント５のリクエストに応じてサーバコンポーネント本体２１もしくはそれへ接続するためのクライアント側アダプタ２２（リモート接続用スタブ）を受け取る。なお、以下特に断らない限りは、サーバコンポーネント本体２１又はクライアント側アダプタ２２には、共通インタフェース２５が実装される、または既に実装されているものとする。
【００８７】
このコンポーネントローダ１２には、その機能を実現させるために、インスタンス生成部３１、コンポーネント復号化部３２、コンポーネント解凍部３３及びコンポーネントキャッシュ１３が設けられる。なお、コンポーネントキャッシュ１３は図２に示すものと同じである。
【００８８】
コンポーネントキャッシュ１３は、コンポーネントサーバ１４からクライアントホスト１へダウンロードされたサーバコンポーネント５を一時的に保管しておき、二重ロードの防止に使用される。
【００８９】
図７はコンポーネントサーバ１４の構成例を示す図である。
【００９０】
コンポーネントサーバ１４は、コンポーネントローダ１２から要求があったサーバコンポーネント５に対し、それの実行位置を実行位置決定部１５によって決定し、それに応じたサーバコンポーネント本体２１もしくはクライアント側アダプタ２２等を準備し、コンポーネントローダ１２へ返す。また、サーバホスト２側でサーバコンポーネント本体２１を実行する場合には、サーバホスト２上に必要なサーバコンポーネント本体２１等を生成する。
【００９１】
コンポーネントサーバ１４には、その機能を実現させるために、実行位置決定部１５、インスタンス生成部３６、アクセス制御監視部１７、コンポーネント暗号化部３７及びコンポーネント圧縮部３８が設けられている。なお、実行位置決定部１５及びアクセス制御監視部１７は図２に示すものと同じである。
【００９２】
実行位置決定部１５は、クライアント／サーバの両ホスト情報やネットワーク接続に関する情報、要求されたサーバコンポーネント５の情報に基づいて、そのサーバコンポーネント５をクライアント／サーバのどちらのホスト側で動作させるべきかを判断する。
【００９３】
アクセス制御部１７は、ユーザ認証部ともいい、要求があったサーバコンポーネント５に対して現在のクライアントホスト１（もしくはその使用者）が当該サーバコンポーネント５を使用可能かどうかを調べる。
【００９４】
図８はコンポーネントマネージャ１６の構成例を示す図である。
【００９５】
コンポーネントマネージャ１６は、記憶装置４とアクセス可能に構成され、サーバコンポーネント５やその情報について管理を行う。具体的にはサーバコンポーネント５の登録／削除、検索などである。
【００９６】
コンポーネントマネージャ１６には、その機能を実現させるために、コンポーネント抽出部４１、コンポーネント情報抽出部４２及びコンポーネント登録管理部４３が設けられている。
【００９７】
ネットワークモニタ１８は、サーバホスト２及びクライアントホスト１の負荷情報、サーバホスト２及びクライアントホスト１の処理能力に関する情報、ネットワークの転送速度、又はサーバコンポーネント本体２１のサイズ情報、又はサーバコンポーネント本体２１の計算量情報を取得し、実行位置決定部１５に提供する。
【００９８】
次に、以上のように構成された本発明の実施の形態に係る分散システムの動作について説明する。
【００９９】
（システム起動）
本分散システムでは、クライアントホスト１においてクライアントアプリケーション基本部分１１の起動等をいかに行うかについては特に制限していない。例えばクライアントホスト１を起動した時点で、クライアントアプリケーション基本部分１１がクライアントホスト１に既に存在していてもよく、また最初は存在せず、クライアントホスト１のユーザのリクエストによってサーバホスト２からダウンロードされアプリケーションプログラムとして起動されもよい。以下、本実施形態では既にクライアントホスト１にクライアントアプリケーション基本部分１１が存在し、アプリケーションプログラムとして起動されていることとして説明を進める。
【０１００】
ここでは、図３（ｂ）に示すように画像処理アプリケーションプログラムを例に説明する。画像処理アプリケーションプログラムは図３（ｂ）に示すような画像処理アプリケーション基本部分１１ａと平滑化処理用コンポーネント５ａの２つに分割されているものとする。
【０１０１】
画像処理アプリケーション基本部分１１ａは画像の表示、平滑化処理用コンポーネント５ａの呼び出し／利用を行う。平滑化処理用コンポーネント５ａは与えられた画像データやパラメータを基に平滑化を行う。
【０１０２】
次に図９，図１０及び図１１により図２のソフトウェア構成において、いかにサーバコンポーネント５が呼び出されるかについて説明し、また、その処理の流れを図１２〜図１５を用いて説明する。
【０１０３】
図９はサーバコンポーネント５への処理要求から実行位置の決定までの処理を示す。
【０１０４】
図１０はサーバコンポーネント５をクライアントホスト１側で実行させる場合の実行位置決定から実行までの処理を示す。
【０１０５】
図１１はサーバコンポーネント５をサーバホスト２側で実行させる場合の実行位置決定から実行までの処理を示す。
【０１０６】
図１２はサーバコンポーネント５への処理要求から処理実行までの処理全体を示す流れ図である。
【０１０７】
図１３は図１２におけるリモートでサーバ本体２１を使用するための処理を示す流れ図である。
【０１０８】
図１４は図１２におけるコンポーネントローダ１２がコンポーネントを受け取る処理を示す流れ図である。
【０１０９】
図１５は図１２におけるコンポーネントキャッシュ１３に存在するコンポーネントを使用するための処理を示す流れ図である。
【０１１０】
（サーバコンポーネント要求から実行位置の決定まで）
この処理を図９及び図１２を用いて説明する。
【０１１１】
（１）クライアントアプリケーションプログラムのユーザはクライアントアプリケーション基本部分１１を通じて希望するサーバコンポーネント５の提供する処理の実行を命ずる（図９の信号ａ）。
【０１１２】
（２）クライアントアプリケーション基本部分１１はコンポーネントローダ１２に対して指定されたサーバコンポーネント５の要求を行う（図９の信号ｂ，図１２のステップＳＴ１）。
【０１１３】
（３）コンポーネントローダ１２は要求のあったサーバコンポーネント５がコンポーネントキャッシュ１３に既にロードされているかどうかを確認し（図９の信号ｃ，図１２のステップＳＴ２）、まだロードしていなければ、リモートのサーバホスト２に存在するコンポーネントサーバ１４と通信を行い、指定されたサーバコンポーネント５の要求を行う（図９の信号ｄ，図１２のステップＳＴ３）。その際、クライアントホスト１のロードアベレージやメモリ残量、スワップの可否などの情報（クライアントホスト情報）を生成し、コンポーネントサーバ１４へ通知する（図９の信号ｄ’）。なお、既にロードしているサーバコンポーネント５であった場合は後述する（図１２のステップＳＴ１０，図１５）。
【０１１４】
（４）コンポーネントサーバ５はサーバホスト２の情報（サーバホスト情報）や接続しているネットワークに関する情報をネットワークモニタ１８から収集する（図９の信号ｅ）。ネットワークモニタ１８は、例えば回線その使用量、トラフィック等に基づくその時点でのネットワーク情報や、ネットワークカードのＩＤでわかる回線速度等の機器性能を調べることで上記ネットワークに関する情報を収集する。また、当該情報はシステム管理者が事前に設定したものでもよい。
【０１１５】
コンポーネントサーバ５は、実行位置決定部１５に対して収集されたネットワーク情報を通知するとともに、指定されたサーバコンポーネント５をクライアント／サーバのどちらのホストで実行すべきかを問い合わせる（図９の信号ｆ）。
【０１１６】
（５）実行位置決定部１５は先ず、アクセス制御監視部１７により指定されたサーバコンポーネント５について、その要求してきたクライアントホスト１（もしくはそのユーザ）によるそのサーバコンポーネント５の使用の可否や使用上の制限などがあるか否かを調べる（図９の信号ｇ）。アクセス制御監視部１７は、使用上の制限でクライアント側もしくはサーバ側での実行が強制される場合にはその旨をコンポーネントサーバ１４へ通知する。この場合は、クライアントホスト１（もしくはそのユーザ）は当該サーバコンポーネント５の使用資格を有しない場合であるので、以下の処理は行われない。
【０１１７】
（６）次に、使用可能であった場合に、実行位置決定部１５はコンポーネントサーバ１４から渡された両ホストの情報、ネットワーク情報に加え、コンポーネントマネージャ１６から指定されたサーバコンポーネント５に関する情報（サーバコンポーネント情報）を入手し、これらの情報を基に、指定されたサーバコンポーネント５がクライアント／サーバのどちらのホストで動作すべきかを決定する（図９の信号ｈ，図１２のステップＳＴ４）。なお、決定アルゴリズムとしては種々のものが考えられるが、その例については後述する。その後、決定した実行位置をコンポーネントサーバ１４へ通知する（図９の信号ｉ，図１２のステップＳＴ５）。
【０１１８】
以上の処理を画像処理アプリケーションプログラムの例に適合させて説明すると、次のようになる。先ず画像処理アプリケーション基本部分１１ａが画像を表示している状態で、ユーザが画像処理アプリケーション基本部分１１ａに対して平滑化処理を命じる。すると、画像処理アプリケーション基本部分１１ａはコンポーネントローダ１２に対して平滑化処理用コンポーネント５ａの要求を行う。コンポーネントローダ１２はクライアントホスト情報を入手後、コンポーネントサーバ１４へ平滑化処理用コンポーネント５ａを要求する。コンポーネントサーバ１４はサーバホスト情報、ネットワーク情報を収集し、実行位置決定部１５に対して平滑化処理用コンポーネント５ａの実行位置を問い合わせる。実行位置決定部１５はコンポーネントマネージャ１６から、平滑化処理用コンポーネント５ａのコンポーネント情報を入手後、各情報を基に実行位置を決定し、コンポーネントサーバ１４へ通知する。
【０１１９】
次に、実行位置決定部１５における実行位置の決定アルゴリズムについて説明する。
【０１２０】
スループット向上を目的にした場合、クライアント／サーバの両ホストの情報、ネットワークの転送速度、サーバコンポーネントに関する情報を用いて判断する。すなわち、クライアントホスト１でサーバコンポーネント本体２１を実行した場合と、サーバホスト２でサーバコンポーネント本体２１を実行した場合とで、それぞれで必要と考えられる処理時間を計算（予想）し、処理時間が小さくなるほうでサーバコンポーネント本体２１を実行するように判断する。
【０１２１】
画像処理アプリケーションプログラムの例では、ユーザ要求から平滑化対象となる画像データのデータサイズ（転送量）が渡されるとすると、例えば、処理の予想時間は以下の計算式により計算することにする。
【０１２２】
Ｔ＝ｈｐｔ（ｈｗ，ｃｐ，ｃｃ）＋ｈｓｔ（ｈｍ，ｃｓ，ｄｓ，ｈｓｃ）＋ｎｔｔ（ｄｓ，ｔｓ） …（１）
Ｔは処理予想時間、関数ｈｐｔはそのホストの現在の負荷ｈｗと計算能力ｃｐ及びサーバコンポーネントの計算量ｃｃから得られる処理時間を返す関数、関数ｈｓｔはメモリ残量ｈｍ、コンポーネントサイズｃｓ、処理データサイズｄｓ及びスワップに必要なコストｈｓｃから計算されるスワップが生じた場合のそれに要する時間を返す関数、関数ｎｔｔは処理データサイズ（サーバホスト側で実行する場合；返り値も同サイズである場合は２倍にしておく）もしくはコンポーネントサイズ（クライアント側で実行する場合）ｄｓ及びネットワークの転送速度ｔｓから計算される転送に要する時間を返す関数である。上記Ｔを両ホストで実行した場合を計算し、値が小さいほうで処理を実行することにする。
【０１２３】
この他の判断手法として、従量制ネットワークにおいて課金を最も少なくするようにデータの転送量で実行位置を判断したり、コンポーネント開発者の意志や、クライアントホストの環境による必然性などから、ある条件においては定位置で実行するなどの判断を行うことが可能である。もちろん、スループットを向上させる場合にも、他の値を用いて計算することもあると考えられる。
【０１２４】
（クライアント側で実行すると決定した場合の処理）
次に、サーバコンポーネント５をクライアントホスト１側で動作させることを決定した場合の一連の処理を、図１０及び図１２並びに図１４を用いて説明する。
【０１２５】
（１）実行位置決定部１５からの決定通知（図９の信号ｉ）を受けたコンポーネントサーバ１４は、コンポーネントマネージャ１６から指定されたサーバコンポーネント本体２１（実行可能なオブジェクトのデータ）を記憶装置４から受け取る（図１０の信号ｊ）。
【０１２６】
（２）コンポーネントサーバ１４は、サーバホスト２から要求を発したコンポーネントローダ１２へ、サーバコンポーネント本体２１をサーバコンポーネント５として送る（図１０の信号ｋ，図１２のステップＳＴ６）。
【０１２７】
（３）クライアントホスト１上のコンポーネントローダ１２は、得られたサーバコンポーネント本体２１から実行可能なサーバコンポーネントオブジェクトを生成し（図１０の信号ｌ，図１２のステップＳＴ７，図１４のステップＳＴ１２）、クライアントアプリケーション基本部分１１にそのポインタを渡す（図１０の信号ｍ，図１２のステップＳＴ７，図１４のステップＳＴ１３）。これによりクライアントアプリケーション基本部分１１は、サーバコンポーネント本体２１にその処理を実行させることができるようになる。なお、サーバコンポーネント本体２１には共通インターフェース２５が実装されている。また、同一のサーバコンポーネントの二重ロード防止のため、コンポーネントローダ１２は、受け取ったサーバコンポーネント５を、その受け取りと同時にコンポーネントキャッシュ１３に保存する（図１０の信号ｎ，図１２のステップＳＴ７，図１４のステップＳＴ１１）。
【０１２８】
（４）クライアントアプリケーション基本部分１１は、渡されたサーバコンポーネント本体２１を利用し、ユーザが指定した処理を実行する（図１０の信号ｏ，図１２のステップＳＴ８）。
【０１２９】
以上の処理を画像処理アプリケーションプログラムの例に適合させて説明すると、以下のようになる。
【０１３０】
先ず、コンポーネントサーバ１４が平滑処理用コンポーネント５ａの本体のバイト列をコンポーネントマネージャ１６を介して記憶装置４から受け取り、それをコンポーネントローダ１２へ送る。コンポーネントローダ１２は受け取ったバイト列を基に実行可能なオブジェクト（サーバコンポーネント２１）を生成し、そのポインタを画像処理アプリケーション基本部１１ａへ渡す。画像処理アプリケーション基本部１１ａは受け取った平滑化処理用コンポーネント５ａのオブジェクトの平滑化処理メソッドを呼出すことで、平滑化処理を行う。
【０１３１】
（サーバ側で実行すると決定した場合の処理）
次に、サーバコンポーネント５をサーバホスト２側で動作させることを決定した場合の一連の処理を、図１１及び図１２並びに図１３，図１４を用いて説明する。
【０１３２】
（１）実行位置決定部１５からの決定通知（図９の信号ｉ）を受けたコンポーネントサーバ１４は、コンポーネントマネージャ１６から指定されたサーバコンポーネント５のクライアント側アダプタ２２（リモート接続用スタブ）とサーバコンポーネント本体２１等を受け取る（図１１の信号ｐ）。
【０１３３】
（２）コンポーネントサーバ１４は、サーバホスト２上でサーバコンポーネント本体２１から実行可能なサーバコンポーネントオブジェクトを生成する（図１１の信号ｑ，図１２のステップＳＴ９，図１３のステップＳＴ２１）。
【０１３４】
（３）コンポーネントサーバ１４は、使用する分散オブジェクト間通信技術（Ｊａｖａ，ＣＯＲＶＡ等）に応じた準備を行う（図１１の信号ｒ，図１２のステップＳＴ９，図１３のステップＳＴ２２）。このために、サーバ側アダプタ２４についてのオブジェクトを生成し、分散オブジェクト間通信が可能となる処理を行う。
【０１３５】
（４）次に、コンポーネントサーバ１４は、サーバホスト２から要求を発したコンポーネントローダ１２へクライアント側アダプタ２２をサーバコンポーネント５として送る（図１１の信号ｓ，図１２のステップＳＴ９，図１３のステップＳＴ２３）。また二重ロード防止のため、クライアントホスト１のコンポーネントローダ１２は、その受け取り同時にこのサーバコンポーネント５をコンポーネントキャッシュ１３に保存する（図１１の信号ｔ，図１２のステップＳＴ７，図１４のステップＳＴ１１）。
【０１３６】
（５）コンポーネントローダ１２は、受け取ったクライアント側アダプタ２２を実行可能なスタブオブジェクトを生成する（図１１の信号ｕ，図１２のステップＳＴ７，図１４のステップＳＴ１２）。
【０１３７】
（６）コンポーネントローダ１２は、生成したスタブオブジェクトのポインタをクライアントアプリーション基本部分１１に引き渡す（図１１の信号ｖ，図１２のステップＳＴ７，図１４のステップＳＴ１３）。
【０１３８】
（７）こうしてクライアントアプリーション基本部分１１は、クライアント側アダプタ２２であるスタブオブジェクトを通し、サーバホスト２上に生成されたリモートのサーバコンポーネント本体２１にアクセスし、処理を実行する（図１１の信号ｗ，図１２のステップＳＴ８）。
【０１３９】
以上の処理を画像処理アプリケーションプログラムの例に適合させて説明すると、以下のようになる。
【０１４０】
先ず、コンポーネントサーバ１４が平滑化処理用コンポーネントのスタブ２２と本体２１のバイト列をコンポーネントマネージャ１６から受け取る。サーバホスト側で平滑化処理を行う本体２１からオブジェクト２１，２５を生成し、リモートの呼び出しを受け付けられるよう、既存の分散オブジェクト間通信技術を用いて、サーバオブジェクトとして登録する。また、スタブ２２はそのままコンポーネントローダ１２へ送られる。コンポーネントローダ１２は受け取ったスタブ２２からオブジェクト２２，２５を生成する。生成されたスタブオブジェクト２２，２５はその生成／初期化の段階でサーバホスト上の本体２１，２５と接続を行う。生成されたスタブ２２，２５は画像処理アプリケーション基本部分１１ａへ渡される。画像処理アプリケーション基本部分１１ａはこのスタブ２２，２５を介して平滑化処理を行うリモートのオブジェクト５ａ（２１，２５）へアクセスし、処理を行う。
【０１４１】
（コンポーネントキャッシュにサーバコンポーネントがある場合の処理）
一度、クライアントホスト１側でサーバコンポーネント本体２１、もしくはクライアント側アダプタ２２を生成した後は、そのクライアントプロセスが終了するまで、もしくはサーバホスト２からロードしたオブジェクトを破棄するまで、そのオブジェクトは何度でも再利用することは可能である。すなわち図１２のステップＳＴ２でステップＳＴ１０に進む場合である。この場合は処理のたびにサーバホスト２からサーバコンポーネント５を再ロードする必要はない。
【０１４２】
具体的には次の手順に従う。
【０１４３】
（１）クライアントアプリケーション基本部分１１がサーバコンポーネント５の要求をコンポーネントローダ１２へ送る（図９の信号ｂ，図１２のステップＳＴ１）。
【０１４４】
（２）コンポーネントローダ１２は指定されたサーバコンポーネント５が既にロードされているかをコンポーネントキャッシュ１３に問い合わせる（図９の信号ｃ，図１２のステップＳＴ２，ＳＴ１０，図１５のステップＳＴ３１）。
【０１４５】
（３）既にロードされていた場合は、その情報を基にオブジェクトを生成し（図１０の信号ｌまたは図１１の信号ｕ，図１２のステップＳＴ１０，図１５のステップＳＴ３２）、クライアントアプリケーション基本部分１１へ返す（図１０の信号ｍまたは図１１の信号ｖ，図１２のステップＳＴ１０，図１５のステップＳＴ３３）。
【０１４６】
（４）クライアントアプリケーション基本部分１１は返されたオブジェクトを利用して所望の処理を行う（図１０の信号ｏまたは図１１の信号ｗ，図１２のステップＳＴ８）。
【０１４７】
上述したように、本発明の第１の実施の形態に係る分散システムは、クライアントアプリケーション基本部分１１が要求する処理を実行するサーバコンポーネント本体２１と、分散オブジェクト間通信２３により互いに接続されるクライアント側アダプタ２２、サーバ側アダプタ２４とからなるサーバコンポーネント５を設け、クライアントアプリケーション基本部分１１の要求に応じて実行位置決定部１５がクライアント／サーバのいずれのホストでサーバコンポーネント本体２１を処理するかを判断して、その判断結果に応じたホストでサーバコンポーネント本体２１による処理を実行するようにしたので、処理の実行場所を動的に切り替えることが可能になり、システムの柔軟性を向上させることができる。
【０１４８】
また、実行位置決定部１５は、ネットワークモニタ１８からのハードウエアやネットワーク状況等の情報に基づき実行位置を決定するので、クライアントホスト１からの処理要求に対し、処理結果が速く得られるようにサーバコンポーネント５の実行位置を切り替えることができる。これにより、スループットを向上させることができる。
【０１４９】
さらに、アクセス制御監視部１７を設け、クライアントのユーザ情報やクライアントホスト情報に基づいて、要求を行うクライアントアプリケーション基本部分１１に要求権限があるか否かを判断することができ、サーバコンポーネント５へのアクセスを制御することができる。
【０１５０】
また、要求される処理の実装はサーバコンポーネント本体２１に対してのみ、すなわち１か所に行われるので、サーバコンポーネント開発者は同一の実装を２重に行なう必要が無くなる。つまり、要求処理の動的変更システムを構築する上で、サーバホスト側実行用，クライアントホスト側実行用を分けてプログラムを開発する必要をなくすことができる。
【０１５１】
また、サーバコンポーネント本体２１とクライアント側アダプタ２４が共通のインタフェース２５を実装しているため、クライアントホスト１から両者に対して一様にアクセスすることができる。したがって、プログラム（プロセス）構成を簡易なものとし、その分高速化を図ることもできる。
【０１５２】
さらに、サーバコンポーネント本体２１をクライアントホスト側で実行する場合は、クライアントアプリケーション基本部分１１とサーバコンポーネント本体２１の間に通信のためのアダプタが不要であるので、処理要求におけるオーバーヘッドをなくすことができる。
【０１５３】
なお、本実施形態では、クライアントホスト１とサーバホスト２が一つづつある場合を例にとって説明したが、サーバ側ではクラスタ，すなわちネットワーク内にサーバホストが複数存在するようなマルチサーバ環境において負荷分散や集中管理などを行うための仮想システム等を利用することで、実際には複数のホストを実行位置の対象とすることができる。
【０１５４】
なお、ここでサーバホストと呼んでいるのはクライアントホスト以外のホストを指している。すなわち、本実施形態の場合、クライアントアプリケーション基本部分１１が存在して、処理の要求を発するホストがクライアントホスト１であり、クライアントホスト以外でその処理を実行するホストのことをサーバホスト２と呼ぶ。従って、一般に、端末として呼ばれるクライアントホストは本実施形態のクライアントホストとは必ずしも対応しない。
【０１５５】
なお、本実施形態では、実行位置の決定を自動で行う場合を説明したが、予め実行位置の設定をしておくことで、事実上サーバコンポーネント本体２１の実行位置の設定を手動で行うこともできる。また、これらの両方を混在させることも可能である。
【０１５６】
なお、上記各効果は、その機能構成が重複する部分については以下の各実施形態あるいは各実施形態においても同様に奏されるものである。
【０１５７】
（第２実施形態）
本実施形態は第１実施形態におけるサーバコンポーネント５の構成に改良を加えるものであり、その他の部分は第１実施形態と同様である。したがって、図１〜図１５と同一部分には同一符号を付してその詳細説明を省略する。
【０１５８】
すなわち、図４に示した第１実施形態のサーバコンポーネント５は、発明を実現するための基本的な構成である。しかし、かかる基本的なコンポーネント構成によっては、場合により必要な当該サーバコンポーネント本体２１が果たすべき機能を実現できないことがある。第１実施形態では実現できないことは、ホストリソースへアクセスするコンポーネントと、クライアント側のアプリケーションプログラムと非同期に通信するコンポーネント（コンポーネントからクライアント側のアプリケーションプログラムへ通信する）である。
【０１５９】
ホストリソースへアクセスするサーバコンポーネント５としては次の２つがある。１つはクライアントホストのリソース（画面表示（ＧＵＩ）やローカルのファイルシステム等）へアクセスするサーバコンポーネントであり、もう１つはサーバホスト２やさらにそのバックに存在するリソース（サーバ側のファイルシステムやデータベース等）へアクセスするサーバコンポーネントである。
【０１６０】
例えばＧＵＩを表示するサーバコンポーネント５であれば、サーバコンポーネント本体２１がサーバホスト２にあろうとクライアントホスト１にあろうと、ＧＵＩはクライアントホスト１に表示しなければならない。このような問題を解決するためには、クライアントリソースへアクセスする部分はサーバコンポーネント本体２１の位置に関わらず、クライアントホスト１側へ移動させなければならない。
【０１６１】
また、例えばサーバホスト２側のデータベースマネンジメントシステムへ接続しているようなサーバコンポーネント５であれば、たとえサーバコンポーネント本体２１がクライアントホスト１ヘ送られた場合でも、データベースマネンジメントシステムとやり取りする部分はサーバホスト２ヘ残ってデータベースマネンジメントシステムとやり取りができる状態を保たなければならない。
【０１６２】
このような条件を考えると上記した場合のサーバコンポーネント本体は、本来の機能実行部分（第１実施形態のサーバコンポーネント本体２１）と、クライアントリソースにアクセスする部分及び／又はサーバ（もしくはそれ以降の）リソースヘアクセスする部分とに分割した構成とする必要がある。この点を考慮して本実施形態では、サーバコンポーネント５を図１６に示すような構成としている。
【０１６３】
図１６は本発明の第２実施の形態におけるサーバコンポーネント５の構成例を示す図である。
【０１６４】
このサーバコンポーネント５は、図４に示した構成に加えて、クライアントリソース対応部５１と、サーバリソース対応部５２が付加される。
【０１６５】
ここで、クライアントリソース対応部５１は、クライアントリソースアクセス部５３からなる。一方、サーバリソース対応部５２は、サーバリソースアクセス用クライアント側アダプタ５４と、サーバリソースアクセス用サーバ側アダプタ５６と、サーバリソースアクセス部５７とからなり、サーバリソースアクセス用クライアント側アダプタ５４とサーバリソースアクセス用サーバ側アダプタ５６とは分散オブジェクト間通信５５を介して接続される。なお、サーバリソースアクセス用クライアント側アダプタ５４及びサーバリソースアクセス部５７にはサーバリソースアクセス部共通インタフェース５８が実装される。
【０１６６】
クライアントリソースアクセス部５３は、クライアントホスト１のリソースにアクセスするための処理を行う。サーバリソースアクセス部５７は、サーバホスト２のリソースにアクセスするための処理を行う。サーバリソースアクセス用クライアント側アダプタ５４及びサーバリソースアクセス用サーバ側アダプタ５６は、分散オブジェクト間通信５５を行うためのアダプタである。
【０１６７】
このように第２実施形態では、サーバコンポーネント本体５をクライアントリソースにアクセスする部分（クライアントアプリケーションへの非同期通信も含む）と、サーバリソースにアクセスする部分と、どちらでも動作可能な部分に３分割されている。
【０１６８】
本実施形態では、記憶装置４に格納されるサーバコンポーネント５は、図１６に示すようなものとなるが、図２に示す各処理は第１実施形態の場合と同様である。図２に示す各部は、クライアントホスト側、サーバホスト側のいずれかでサーバコンポーネント本体２１を実行するにあたって、本実施形態でサーバコンポーネント５に新たに付加された部分の移動やその対応するオブジェクトの発生が必要となる点でのみ異なる。
【０１６９】
次に、以上のように構成された本発明の実施の形態に係る分散システムの動作について説明する。
【０１７０】
（サーバ側で処理を行う場合）
図１７はサーバコンポーネント本体２１をサーバホスト２側で動作させる場合のサーバコンポーネント５の構成を示す図である。
【０１７１】
サーバコンポーネント本体２１をサーバホスト２側で動作させる場合には、クライアントホスト１側ヘはクライアント側アダプタ２２とクライアントリソースアクセス部５７がコンポーネントサーバ１４によって送られる。クライアントリソースアクセス部５７はクライアントホスト１側でコンポーネントローダ１２によりインスタンス化された後、コンポーネントローダ１２からサーバコンポーネント本体２１へ参照渡し（ポインタの引き渡し）される。
【０１７２】
サーバホスト２側ではサーバコンポーネント本体２１が直接サーバリソースアクセス部５７を保持し、やりとりを行うこととなる。
【０１７３】
なお、パフォーマンスを考慮して、クライアント側アダプタ２２が直接クライアントリソースアクセス部５３とやり取りする場合も考えられる。
【０１７４】
（クライアント側で処理を行う場合）
図１８はサーバコンポーネント本体をクライアントホスト１側で動作させる場合のサーバコンポーネントの構成を示す図である。
【０１７５】
次に、サーバコンポーネント本体２１をクライアントホスト１側で動作させる場合には、クライアントホスト１側へはサーバコンポーネント本体２１とクライアントリソースアクセス部５３、サーバリソースアクセス用クライアント側アダプタ５４がコンポーネントサーバ１４によって送られる。
【０１７６】
このときクライアントホスト１側で生成されたサーバコンポーネント本体２１はクライアントリソースを直接所持する。また、サーバリソースアクセス部５７はサーバホスト２側に残る必要がある。そのため、サーバコンポーネント本体２１とサーバリソースアクセス部５７の間を分散オブジェクト間通信５５を行うために、図５（ｂ）の場合におけるサーバコンポーネント５の構成と似たような構造を設ける。すなわち、図１８に示すように、サーバリソースアクセス用のアダプタ５４，５６をサーバ側／クライアント側のホストに用意し使用する。
【０１７７】
サーバコンポーネント本体２１からみた場合、サーバリソースアクセス用クライアント側アダプタ５４とサーバリソースアクセス部５７は一様の手順でアクセスできるべきであるので、それぞれはサーバリソースアクセス用の共通インタフェース５８を実装することにし、サーバコンポーネント５はこれら要素をサーバリソースアクセス用共通インタフェースの型として保持することとする。
【０１７８】
また同様に、クライアントリソースアクセス部５３はサーバコンポーネント本体２１とクライアント側アダプタ２２を一様にアクセスできるようにするため、これらを共通インタフェースの型として保持することにする。
【０１７９】
これらの所有関係は、各要素がコンポーネントローダ１２やサーバコンポーネント１４により、実行可能な状態にされる際の初期化によって実現される。このようにして図１７又は図１８に示す構成により、各ホスト１，２のリソースへアクセスするできるサーバコンポーネント５が実現される。
【０１８０】
上述したように、本発明の第２実施形態に係る分散システムは、第１実施形態と同様な構成に加えて、サーバコンポーネント５に、クライアントリソースアクセス部５３、サーバリソースアクセス用クライアント側アダプタ５４、分散オブジェクト間通信５５、サーバリソースアクセス用サーバ側アダプタ５６及びサーバリソースアクセス部５７を設け、サーバコンポーネント本体２１がクライアント／サーバいずれの側のホストにあるときでも、クライアント／サーバのリソースにアクセスできるようにしたので、第１実施形態と同様な効果が得られるとともに、アプリケーション基本部分１１に依頼される形式の処理のみでなく、ＧＵＩやデータベースアクセス等、クライアント／サーバのリソースにアクセスしないと実行できないような処理もサーバコンポーネント５により実現することができる。
【０１８１】
なお、上記の構成においても分散オブジェクト間通信については種々の技術を適用することができる。ＪａｖａとＲＭＩを用いる場合には分散オブジェクト間通信のサーバとなるオブジェクトはｊａｖａ．ｒｍｉ．Ｒｅｍｏｔｅを継承する必要がある。
【０１８２】
また、本実施形態で示したクライアントリソース対応部５１、サーバリソース対応部５２についてはそのコンポーネントにおいて必要な場合にのみ基本部分へ付加すればよい。これらが不要な場合はそれぞれ省略できる。
【０１８３】
（第３実施形態）
本実施形態は第２実施形態におけるサーバコンポーネント５の構成に改良を加えるものであり、その他の部分は第２実施形態と同様である。したがって、図１〜図１８と同一部分には同一符号を付してその詳細説明を省略する。
【０１８４】
第２実施形態によれば、各ホスト１，２のリソースヘアクセスするようなサーバコンボーネントも実現可能となる。しかし、これを実現するためには、クライアントホスト１からサーバホスト２への参照渡し（ポインタの引き渡し）ができることが必要である。参照渡しができないような分散環境では別の手段（コンポーネント構成）を考えなければならない。そうしなければ、図１７の場合にサーバコンボーネン卜本体２１からクライアントリソースアクセス部５３ヘメッセージを送ることができず、実現可能な処理の種類が限定される。
【０１８５】
本実施形態は、このような事情を考慮してサーバコンポーネント５の構成を改良したものである。
【０１８６】
図１９は本発明の第３実施形態におけるサーバコンポーネント５の構成例を示す図である。
【０１８７】
このサーバコンポーネント５は、クライアントリソース対応部５１の構成に変更が加えられる以外は、図１６に示す第２実施形態のサーバコンポーネント５と同様に構成されている。
【０１８８】
ここで、クライアントリソース対応部５１は、第２実施形態と同様なクライアントリソースアクセス部５３と、クライアントリソースアクセス用クライアント側アダプタ６１と、クライアントリソースアクセス用サーバ側アダプタ６３とからなり、クライアントリソースアクセス用のクライアント側アダプタ６１とサーバ側アダプタ６３とは分散オブジェクト間通信６２により接続される。なお、クライアントリソースアクセス用サーバ側アダプタ６３及びクライアントリソースアクセス部５３にはクライアントリソースアクセス部共通インタフェース６４が実装される。
【０１８９】
クライアントリソースアクセス部５３は、第２実施形態と同様にクライアントホスト１のリソースにアクセスするための処理を行う。クライアントリソースアクセス用クライアント側アダプタ６１及びクライアントリソースアクセス用サーバ側アダプタ６３は、分散オブジェクト間通信６２を行うためのアダプタである。
【０１９０】
次に、以上のように構成された本発明の第３実施形態に係る分散システムの動作について説明する。
【０１９１】
図２０はサーバコンポーネント本体をサーバホスト２側で動作させる場合のサーバコンポーネントの構成を示す図である。
【０１９２】
このようなサーバコンポーネント構成を生成する手続きは、第１及び第２実施形態の場合と同様である。ただし、本実施形態の場合は、クライアントリソースアクセス部５３からサーバコンポーネント本体２１への参照渡しは行われない。
【０１９３】
つまり、クライアントリソースアクセス部５３はサーバコンポーネント本体２１と両アダプタ６１，６３を介し分散環オブジェクト間通信６２を介してのみ関連する。したがって、たとえクライアントリソースアクセス部５３からサーバコンポーネント本体２１に参照渡しができなくても、両者間の通信が実現される。
【０１９４】
また、サーバコンポーネント本体２１をクライアントホスト１側で動作させる場合には、ホスト１，２間での参照渡しの問題は生じない。したがって、サーバコンポーネント５の構成は、第２実施形態における図１８の場合と同じになる。
【０１９５】
上述したように、本発明の第３実施形態に係る分散システムは、第１実施形態と同様な構成に加えて、クライアントリソースアクセス用クライアント側アダプタ６１、分散オブジェクト間通信６２及びクライアントリソースアクセス用サーバ側アダプタ６３を設けたので、第１実施形態と同様な効果が得られる他に、サーバコンポーネント本体２１がサーバホスト２側にある場合に、分散オブジェクト間通信６２でたとえ参照渡しができなくても、サーバコンポーネント本体２１〜クライアントアクセスリソース部５３間で通信を行うことができ、クライアントリソースにアクセスすることができる。したがって、サーバコンポーネント５を利用するシステムの適用範囲が一層向上する。
【０１９６】
このような構成にすることで、参照渡しできない場合にクライアントリソースアクセス部５３に設けられるべき処理をも、サーバコンポーネント本体２１に集中させることが可能になるため、サーバコンポーネント５の開発容易性が一層向上する。
【０１９７】
（第４実施形態）
図２１（ａ）は、図４に示した基本的なサーバコンポーネント５を、図３（ｂ）に示すような画像処理アプリケーションプログラムに適用した場合の例である。この例は、プログラミング言語としては仮想言語Ｊを用い、通信は仮想分散オブジェクト技術Ｊ ＲＭＩを用いる。
【０１９８】
（第５実施形態）
図２１（ｂ）は、画像処理アプリケーションプログラムに限らず一般のアプリケーションプログラムに適用した例である。第４実施形態と異なり、プログラミング言語としてはＪａｖａを用い、通信は分散オブジェクト間通信技術Ｊａｖａ
ＲＭＩを用いる。
【０１９９】
（第６実施形態）
図２１（ｃ）は、図１６に示した第２実施形態の（サーバ／クライアントへのリソースアクセスを可能とした）サーバコンポーネント５に対応するものである。この例は、プログラミング言語としてはＪａｖａを用い、通信は分散オブジェクト間通信技術Ｊａｖａ ＲＭＩを用いる。
【０２００】
（第７実施形態）
上記各実施形態では、サーバコンポーネント５を使用してサーバコンポーネント本体２１の実行位置をクライアントホスト１〜サーバホスト２間で動的に変更できる分散システム並びにそのシステムで使用されるサーバコンポーネント５の構成について説明してきた。しかし、ソフトウエア開発者がサーバコンポーネント５を作成するに当たっては多数の構成要素（ファイル）を開発する必要がある。
【０２０１】
本実施形態では、このサーバコンポーネント５の各ファイルを自動生成することで開発者の負担を少なくする技術について説明する。ここでは、生成するサーバコンポーネント５としては、図２１（ｂ）に示す第５実施形態を例にとって説明する。なお、本実施形態においても、上記各実施形態の各図におけるものと同一な構成部分については同一符号を付し、説明を省略する。
【０２０２】
図２１（ｂ）の場合、サーバコンポーネント５の構成要素として、共通インターフェース２５、クライアント側アダプタ２２、サーバ側アダプタ２４、サーバコンポーネント本体２１及びＲＭＩ用インタフェース２４ａの５つのクラスファイルを作成し、記憶装置４に登録する必要がある。
【０２０３】
図２２は本発明の第７実施形態に係るサーバコンポーネント自動生成システムの構成例を示すブロック図である。
【０２０４】
このサーバコンポーネント自動生成システムは、開発用計算機７１に、情報提供部７２、テンプレート提供部７３、クラスファイル自動生成部７４、クラスファイル部７５、本体処理内容作成部７６及び本体処理内容提供部７７が設けられて構成されている。
【０２０５】
情報提供部７２は、クラス名やメゾット名等のサーバコンポーネント５に関する各情報を格納し、これをクラスファイル自動生成部２４に入力するようになっている。
【０２０６】
テンプレート提供部７３は、例えば図２３〜図２７に示す共通インターフェース２５、クライアント側アダプタ２２、サーバ側アダプタ２４、サーバコンポーネント本体２１及びＲＭＩ用インタフェース２４ａの５つのクラス／インターフェースに対応するテンプレートを保持し、そのテンプレートをクラスファイル自動生成部２４に提供する。なお、図２３〜図２７は、そのテンプレートを基に作成されたクラス／インタフェースの例である。
【０２０７】
図２３は本実施形態におけるＪａｖａによる共通インタフェースの一例を示す図である。
【０２０８】
図２４は本実施形態におけるＪａｖａによるサーバコンポーネント本体２１の一例を示す図である。
【０２０９】
図２５は本実施形態におけるＪａｖａによるサーバ側アダプタクラスの一例を示す図である。
【０２１０】
図２６は本実施形態におけるＪａｖａによるサーバ側アダプタクラスのＲＭＩ用インタフェースの一例を示す図である。
【０２１１】
図２７は本実施形態におけるＪａｖａによるクライアント側アダプタの一例を示す図である。
【０２１２】
クラスファイル自動生成部７４は、情報提供部７２及びテンプレート提供部７３からの提供情報に基づき、上記５つの各クラスファイルを生成し、クラスファイル部７５に出力する。この時点で出力されるクラスファイルには、サーバコンポーネント本体２１の実体的な処理内容（処理ロジック）は実装されていない。
【０２１３】
本体処理内容作成部７６は、この実体的な処理内容，すなわち本体処理内容を作成するための処理部である。
【０２１４】
本体処理内容提供部７７は、本体処理内容作成部７６で作成された本体処理内容を、クラスファイル部７５の各クラスファイルのうち、サーバコンポーネント本体２１に対応するものに実装する。
【０２１５】
また、図示しない登録手段は、こうして作成された各クラスファイルをサーバコンポーネント５の構成要素として、記憶装置４に登録する。
【０２１６】
次に、以上のように構成された本発明の実施の形態に係るサーバコンポーネント自動生成システムの動作について説明する。
【０２１７】
先ず、図２２及び図２３〜図２７を用いて本実施形態の概念的な動作を説明する。
【０２１８】
サーバコンボーネント本体２１の本体処理内容を除くと他のクラス／インタフェースは単にメソッドコールをリレーしているだけであるため、サーバコンポーネント本体２１以外のクラス／インタフェースは以下のようにすることで自動生成することが可能である。
【０２１９】
クラス名については予め定めた命名規約に従ってサーバコンボーネント本体２１のクラス名から自動的に決定することができる。
【０２２０】
また、メソッドについては両アダプタ２２，２３は基本的に中継するだけの存在であるので、クライアント側アダプタ２２はサーバ側アダプタ２３のメソッド、サーバ側アダプタ２３はサーバコンボーネント本体２１のメソッドを呼出すようにする。ここで注意しなければならないことは返り値についてである。ｖｏｉｄ以外で宣言されたメソッドについては，中継メソッドの結果をｒｅｔｕｒｎ（リターン）するように定義する必要がある。ｖｏｉｄ宣言されたメソッドについては特になにもリターンする必要はない。
【０２２１】
なお、１つのサーバコンボーネント５が複数のメソッドを提供することは可能である。
【０２２２】
以上により、サーバコンボーネント５のサーバコンボーネント本体２１のクラス名及びメソッドに関する情報が情報提供部７２から与えられ、さらに図２３〜図２７に示した各リストＬ−１〜Ｌ−５に対応する各テンプレートがテンプレート提供部７３から与えられることによって、クラスファイル自動生成部７４は上記５つのクラス全てを自動生成することが可能となる。
【０２２３】
図２２はこの概念を図で表したものでもある。例えば図２３〜図２７に示す例では、クラス名がＦｏｏ、メソッドは１つで、メソッド名がｆｏｏＭｅｔｈｏｄ、引数の型がｃｈａｒ、引数名がｃ，返り値の型がｉｎｔである。
【０２２４】
ただし，本来の処理ロジックである本体処理内容は当然開発者がコーディングすることになる。このため、開発用計算機７１には、本体処理内容作成部７６が設けられている。さらに本体処理内容提供部７７によってその作成された本体処理内容がサーバコンポーネント本体２１のクラスファイルに実装される。
【０２２５】
最終的には、上記で作成したものすべてが、コンポーネントマネージャ１６（ハードウエア的には記憶装置４）へ登録される。この際、必要に応じてコンポーネント情報やアクセス制御のための情報等が併せて登録される。
【０２２６】
次に、流れ図を用いて上記Ｊａｖａを用いた場合のサーバコンポーネント５の各要素の自動生成について、より具体的に説明する。
【０２２７】
図２３〜図２７のリストは本発明の自動生成装置を通して得られる結果であり、図２８、図２９のリストはテンプレートと呼ばれているリストである。図２３〜図２７のリストは、クラス名Ｆｏｏ、メソッド名ｆｏｏＭｅｔｈｏｄ等の条件を本発明の自動生成装置に入力し、それらが図２８、図２９のテンプレートに埋め込めれて生成される。
【０２２８】
図２８はテンプレート提供部が提供するテンプレートに対応するリストＬＣ−１（コンポーネント本体のクラス定義）、ＬＣ−２（コンポーネント本体のメソッド定義）、ＬＣ−３（共通インターフェースのインターフェース定義）、ＬＣ−４（共通インターフェースのメソッド定義）、ＬＣ−５（サーバ側アダプタのクラス定義）、ＬＣ−６（返り値の型が非ｖｏｉｄの場合のサーバ側アダプタのメソッド定義）、ＬＣ−７（返り値の型がｖｏｉｄの場合のサーバ側アダプタのメソッド定義）を示す図である。
【０２２９】
図２９はテンプレート提供部が提供するテンプレートに対応するリストＬＣ−８（サーバ側アダプタのＲＭＩインターフェースのインターフェース定義）、ＬＣ−９（サーバ側アダプタのＲＭＩインターフェースのメソッド定義）、ＬＣ−１０（クライアント側アダプタのクラス定義）、ＬＣ−１１（返り値の型が非ｖｏｉｄの場合のクライアント側アダプタのメソッド定義）、ＬＣ−１２（返り値の型がｖｏｉｄの場合のクライアント側アダプタのメソッド定義）を示す図である。
【０２３０】
サーバコンポーネント５を生成する際に、先ず、情報提供部７２によって以下に示す情報がクラスファイル自動生成部７４に与えられる。
【０２３１】
・サーバコンポーネント名
・メソッド名
・返り値の型
・引数の型と引数名
また、クラスファイル自動生成部７４は、図２８及び図２９に示す各クラス／インタフェースのテンプレート（スケルトンともいう）から目的のファイル作成に対応するテンプレートを呼び出す。さらに上記情報提供部７２からの情報によって、テンプレート内の［ ］で囲まれた部分の情報を置きかえることで、サーバコンポーネント本体２１等のクラスファイルを自動生成する。これを繰り返すことで全ファイルを生成する。以下、このクラスファイル自動生成部７４による処理を図３０〜図３４の流れ図を用いて具体的に説明する。
【０２３２】
図３０はクラスファイル自動生成の全体の処理流れを示す流れ図である。
【０２３３】
図３１はサーバコンポーネント本体２１のスケルトン生成を示す流れ図である。
【０２３４】
図３２は共通インタフェースの自動生成を示す流れ図である。
【０２３５】
図３３はサーバ側アダプタクラスの自動生成を示す流れ図である。
【０２３６】
図３４はアダプタクラスの定義へ中継用メゾットを埋め込む処理を示す流れ図である。
【０２３７】
全体的な処理の流れを図３０により説明すると、先ず、情報提供部７２からの情報によりサーバコンポーネント名が調べられ（ステップＳＴ４１）、次にサーバコンポーネント本体２１のスケルトンファイルが作成される（ステップＳＴ４２）。次に共通インターフェース２５のファイルが作成され（ステップＳＴ４３）、続けてサーバ側アダプタ用インタフェース２４ａのファイルが作成される（ステップＳＴ４４）。そしてサーバ側アダプタクラスのファイルが作成され（ステップＳＴ４５）、クライアント側アダプタクラスのファイルが作成されて（ステップＳＴ４６）、これらの各ファイルがクラスファイル部７５に出力される。
【０２３８】
また、図３１に示すように、サーバコンポーネント本体２１のスケルトン生成においては、先ず、図２８のリストＬＣ−１（コンポーネント本体のクラス定義）がテンプレート提供部７３から呼び出されて、情報提供部７２からの情報によりテンプレート［ ］部分について情報置き換えが行われる（ステップＳＴ５１）。次に、図２８のリストＬＣ−２（コンポーネント本体のメソッド定義）が呼び出され、同様に情報置き換えが全メゾットについて行われる（ステップＳＴ５２，ＳＴ５３）。すべてのメゾットの情報置き換えが終了すればサーバコンポーネント本体２１のスケルトン生成が完了する（ステップＳＴ５３）。
【０２３９】
次に、図３２に示すように、共通インタフェースの自動生成においては、先ず、図２８のリストＬＣ−３（共通インターフェースのインターフェース定義）が呼び出され、情報置き換えが行われる（ステップＳＴ６１）。次に、図２８のリストＬＣ−４（共通インターフェースのメソッド定義）が呼び出され、情報置き換えが全メゾットについて行われる（ステップＳＴ６２，ＳＴ６３）。すべてのメゾットの情報置き換えが終了すれば共通インタフェースの自動生成が完了する（ステップＳＴ６３）。
【０２４０】
次に、図３３に示すように、サーバ側アダプタクラスの自動生成においては、先ず、図２８のリストＬＣ−５（サーバ側アダプタのクラス定義）が呼び出され、情報置き換えが行われる（ステップＳＴ７１）。次に、サーバ側アダプタのメゾット定義のリスト（図２８のリストＬＣ−６（返り値の型が非ｖｏｉｄの場合のサーバ側アダプタのメソッド定義）もしくはＬＣ−７（返り値の型がｖｏｉｄの場合のサーバ側アダプタのメソッド定義））が呼び出され、情報置き換えが全メゾットについて行われる（ステップＳＴ７２，ＳＴ７３）。すべてのメゾットの情報置き換えが終了すればサーバ側アダプタクラスの自動生成が完了する（ステップＳＴ７３）。なお、ステップＳＴ７２の処理はさらに具体的には、図３４に示される。すなわち、先ず、返り値の型が情報提供部７２からの情報により調べられ（ステップＳＴ８１）、返り値がｖｏｉｄ以外の場合には図２８のリストＬＣ−６が呼び出されて情報置き換えが行われ（ステップＳＴ８２）、ｖｏｉｄの場合には図２８のリストＬＣ−７が呼び出されて情報置き換えが行われる（ステップＳＴ８３）。
【０２４１】
以上のようにして、クラスファイル自動生成部７４によるファイル生成がなされる。
【０２４２】
なお、クライアント側アダプタクラスの生成については、図３３及び図３４に示すサーバ側アダプタクラスの場合と同様であるので、説明を省略する。
【０２４３】
また、上記処理において、サーバコンポーネント名については、キャピタルレター形式（単語の先頭が大文字で残りが小文字、複数の単語がつながる場合は、各単語の先頭を大文字にして繋げたもの）で、メソッド名と引数名については最初が小文宇で始まるキャピタルレター形式で記述されているとする。また［サーバコンポーネント名（小文字）］とはサーバコンポーネント名を全て小文宇で表記したものである。［返り値のデフオルト値］その型の任意のデフォルトの値である。
【０２４４】
上述したように、本発明の第７実施形態に係るサーバコンポーネント自動生成システムは、クラスファイル自動生成部７４により、テンプレート提供部７３からのテンプレートを組み合わせ、また情報提供部７２からの情報を当てはめてクラスファイルを生成するようにしたので、サーバコンポーント５の構成要素を自動的に生成することができる。
【０２４５】
したがって、たとえサーバコンポーネント５に多くの構成要素があっても、本発明を利用することで各構成要素のほどんどが自動生成され、開発者の負担が軽減される。このため開発者が実際にプログラムしなければならないのはアプリケーションプログラム要求処理の実装に関する部分（本体処理内容）のみとなる。
【０２４６】
（第８実施形態）
第７実施形態では、図２１（ｂ）の場合、すなわち図４に示す基本的なサーバコンポーネント５をＪａｖａ ＲＭＩで構成させる場合のクラスファイル自動生成について説明した。次に、第８実施形態として、図２１（ｃ）の場合、すなわち図１６に示すサーバコンポーネント５をＪａｖａ ＲＭＩで構成させる場合のサーバコンポーネント５の各要素の自動生成について説明する。なお、図１９に示すサーバコンポーネントについても本実施形態及び第７実施形態で示す技術を応用して各構成要素、クラスファイルの自動生成を行うことができる。
【０２４７】
図３５は第８実施形態におけるサーバコンポーネント自動生成システムの構成例を示すブロック図であり、図２２と同一部分には同一符号を付してその説明を省略する。
【０２４８】
この自動生成システムは、開発用計算機７１Ａに、情報提供部７２Ａ、テンプレート提供部７３Ａ、クラスファイル自動生成部７４Ａ、クラスファイル部７５、本体処理内容作成部７６及び本体処理内容提供部７７が設けられて構成されている。
【０２４９】
情報提供部７２Ａは、サーバコンポーネント５機能の拡張に伴って提供する情報が増えた以外は、図２２と同様に構成されている。
【０２５０】
テンプレート提供部７３Ａは、サーバコンポーネント５機能の拡張に伴って提供するテンプレート数が増えた以外は、図２２と同様に構成されている。
【０２５１】
クラスファイル自動生成部７４Ａは、図２２のクラスファイル自動生成部７４と同様な考え方で図２１（ｃ）に示す１２個のクラス／インターフェースを生成する。なお、具体的な処理は図５７〜図６４に示す。
【０２５２】
また、図３６〜図４７に自動生成される１２個のクラス／インターフェースの一例をリストＬＬ−１（Ｊａｖａによる共通インターフェースの例）、ＬＬ−２（Ｊａｖａによるサーバコンポーネント本体の例）、ＬＬ−３（Ｊａｖａによるサーバ側アダプタクラスの例）、ＬＬ−４（サーバ側アダプタクラスのＲＭＩインターフェースの例）、ＬＬ−５（クライアント側アダプタの例）、ＬＬ−６（サーバ側リソースアクセス部共通インターフェースの例）、ＬＬ−７（サーバ側リソースアクセス部の例）、ＬＬ−８（サーバ側リソースアクセス用サーバ側アダプタのＲＭＩ用インターフェースの例）、ＬＬ−９（サーバ側リソースアクセス用サーバ側アダプタの例）、ＬＬ−１０（サーバ側リソースアクセス用クライアント側アダプタの例）、ＬＬ−１１（クライアント側リソースアクセス部のＲＭＩ用インターフェースの例）、ＬＬ−１２（クライアント側リソースアクセス部の例）として示す。
【０２５３】
さらに、図４８〜図５６にテンプレート提供部７３Ａが提供する各テンプレート（スケルトン）のリストＣ−１（コンポーネント本体のクラス定義）、Ｃ−２（Ｃ−１用クライアント側での実行用初期化メソッド）、Ｃ−３（Ｃ−２用クライアント側リソースアクセス部生成部）、Ｃ−４（Ｃ−２用サーバ側リソースアクセス部生成部）、Ｃ−５（Ｃ−１用サーバ側での実行用初期化メソッド）、Ｃ−６（Ｃ−１用クライアントリソース部設定メソッド）、Ｃ−７（Ｃ−１，Ｃ−６０，Ｃ−ｂ０用メソッド定義）、Ｃ−８（Ｃ−１用クライアント側リソースアクセス部用属性）、Ｃ−９（Ｃ−１用サーバ側リソースアクセス部用属性）、Ｃ−ａ（Ｃ−１用クライアントアプリケーション設定メソッド）、Ｃ−１０（共通インターフェースのインターフェース定義）、Ｃ−１１（Ｃ−１０，Ｃ−５０用のメソッド定義）、Ｃ−１２（Ｃ−１０，Ｃ−ａ０用クライアントアプリケーション設定メソッド）、Ｃ−２０（サーバ側アダプタのＲＭＩ用インターフェース定義）、Ｃ−２１（Ｃ−２０用中継用メソッド定義）、Ｃ−２２（Ｃ−２０用クライアントリソースアクセス部設定メソッド）、Ｃ−３０（サーバ側アダプタのクラス定義）、Ｃ−３１（Ｃ−３０用クライアント側リソースアクセス部設定メソッド）、Ｃ−３２（返り値の型が非ｖｏｉｄの場合のＣ−３０，Ｃ−８０用サーバ側アダプタの中継用メソッド定義）、Ｃ−３３（返り値の型がｖｏｉｄの場合のＣ−３０，Ｃ−８０用サーバ側アダプタの中継用メソッド定義）、Ｃ−３４（Ｃ−３０用サーバ初期化）、Ｃ−４０（クライアント側アダプタのクラス定義）、Ｃ−４１（Ｃ−４０用クライアント側リソースアクセス部用属性）、Ｃ−４２（Ｃ−４０用クライアント側リソースアクセス部生成）、Ｃ−４３（Ｃ−４０用クライアント側アダプタの本体への設定部）、Ｃ−４４（Ｃ−４０用クライアントアプリケーション設定部）、Ｃ−４５（返り値の型が非ｖｏｉｄの場合のＣ−４０，Ｃ−９０用クライアント側アダプタの中継用メソッド定義）、Ｃ−４６（返り値の型がｖｏｉｄの場合のＣ−４０，Ｃ−９０用クライアント側アダプタの中継用メソッド定義）、Ｃ−５０（サーバ側リソースアクセス部共通インターフェース定義）、Ｃ−６０（サーバ側リソースアクセス部のクラス定義）、Ｃ−７０（サーバ側リソースアクセス用サーバ側アダプタのＲＭＩインターフェース定義）、Ｃ−８０（サーバ側リソースアクセス用サーバ側アダプタのクラス定義）、Ｃ−９０（サーバ側リソースアクセス用クライアント側アダプタのクラス定義）、Ｃ−ａ０（クライアント側リソースアクセス部のＲＭＩ用インターフェース定義）、Ｃ−ａ１（Ｃ−ａ０用クライアントアプリケーション設定メソッド）、Ｃ−ｂ０（クライアント側リソースアクセス部のクラス定義）、Ｃ−ｂ１（Ｃ−ｂ０用クライアントアプリケーション用属性）、Ｃ−ｂ２（Ｃ−ｂ０用クライアントアプリケーション設定メソッド）を示す。なお、図５７〜図６４の流れ図に示されるリスト番号は、この図４８〜図５６のものに対応する。
【０２５４】
次に、この１２個のクラス／インターフェースを自動生成する処理について説明する。
【０２５５】
サーバコンポーネント５を生成する際には、情報提供部７２Ａからクラスファイル自動生成部７４Ａへ以下に示す情報が与えられる。
【０２５６】
１． サーバコンポーネント名
２． サーバ側リソースへアクセスするか？
３． クライアント側リソースへアクセスするか？
４． コンポーネント本体がクライアントアプリケーションプログラムを呼出すか？
５． メソッド名（必要に応じて上記１，２，３の各部へ振り分ける）
・ 返り値の型
・ 引数の型と引数名
これらの情報を基に、以下に示す各クラス、インタフェースのテンプレート（スケルトン）の［ ］でくくられた部分を与えられた情報に置きかえたり、オプション部を付加したりすることによって、それぞれが自動生成される。なお、サーバコンポーネント名については、キャピタルレター形式で、メソッド名と引数名については最初が小文字で始まるキャピタルレター形式で記述されていることとする。また［サーバコンポーネント名（小文字）］とはサーバコンポーネント名を全て小文字で表記したものである。［返り値のデフォルト値］はその型の任意のデフォルトの値である。
【０２５７】
具体的にはクラスファイル自動生成部７４Ａの処理を示す図５７〜図６４の流れ図に従う。
【０２５８】
なお、これらの流れ図のうち、サーバ側アダプタのＲＭＩ用インタフェースとクライアント側リソースアクセス部のＲＭＩ用インタフェースは共通インタフェースに、サーバ側リソースアクセス部とサーバ側リソースアクセス用サーバ側アダプタのＲＭＩインタフェースはサーバ側リソースアクセス共通インタフェースに、サーバ側リソースアクセス用サーバ側アダプタとクライアント側リソースアクセス部はサーバ側アダプタに、サーバ側リソースアクセス用クライアント側アダプタはクライアント側アダプタに類似している（条件の違いや挿入リスト、挿入箇所は前述もしくは後述の通り）ので、これらの流れ図は省略する。
【０２５９】
また、クライアント側アダプタクラス、サーバ側リソースアクセス部の各クラス／インタフェース、クライアント側リソースアクセス部のクラス／インタフェースについては、サーバ側アダプタクラスの流れ図と類似しているので、省略する。また各流れ図中の分岐におけるＱ１，Ｑ２，Ｑ３はそれぞれ以下のことを意味する。
【０２６０】
Ｑ１：サーバ側リソースヘアクセスするか？
Ｑ２：クライアント側リソースヘアクセスするか？
Ｑ３：コンポーネント本体がクライアントアプリケーションプログラムを呼出すか？
以下、各構成要素の生成について具体的に説明する。
【０２６１】
先ず、サーバコンポーネント本体２１のソースでは先ず、リストＣ−１（図４８）が用意される。次にいずれかのオプション設定がある場合 （上記２，３，４）、リストＣ−２（図４８）がリストＣ−１（図４８）の該当場所へ挿入される。挿入場所の記述は、“／／＜＜リストＣ−ｎ＞＞”と書かれてある場所でこの場合、その場所にリストＣ−ｎを挿入する。次に上記３（クライアント側リソースへアクセスする）または上記４（コンポーネント本体がクライアントアプリケーションプログラムを呼出す）の場合、リストＣ−３（図４８）をリストＣ−２（図４８）へ、リストリストＣ−６（図４９）とリストＣ−８（図４９）をリストＣ−１（図４８）へ挿入する。上記２（サーバ側リソースヘアクセスする）の場合、リストＣ−４（図４８）をリストＣ−２（図４８）へ、リストＣ−５（図４９）とリストＣ−９（図４９）をリストＣ−１（図４８）へ挿入する。さらに上記４の場合にはリストＣ−ａ（図４９）をリストＣ−１（図４８）へ挿入する。あとは必要な分だけ（サーバコンポーネント本体２１が提供するメソッドの数だけ）リストＣ−７（図４９）をリストＣ−１（図４８）へ挿入する。
【０２６２】
次に、共通インタフェース２５のソースは先ず、リストＣ−１０（図５０）が用意される。次にリストＣ−１１（図５０）を必要な分だけ挿入する。上記４の場合はリストＣ−１（図４８）２をリストＣ−１０（図５０）へ挿入する。
【０２６３】
次に、サーバ側アダプタ２４のＲＭＩ用インタフェース２４ａは先ず、リストＣ−２０（図５０）が用意される。次に必要な数だけリストＣ−２１（図５０）をリストＣ−２０（図５０）へ挿入する。また、上記３または４の場合、リストＣ−２０（図５０）にリストＣ−２２（図５０）を挿入する。
【０２６４】
次に、サーバ側アダプタ２４のソースは先ず、リストＣ−３０（図５１）が用意される。次に上記３及び４の場合、リストＣ−３１（図５１）とリストＣ−３４（図５１）をリストＣ−３０（図５１）へ挿入する。あとは、必要な分だけリストＣ−３２（図５１）もしくはリストＣ−３３（図５１）をリストＣ−３０（図５１）へ挿入する。
【０２６５】
次に、クライアント側アダプタ２２のソースは先ず、リストＣ−４０（図５２）を用意する。上記３及び４の場合、リストＣ−４１（図５２）とリストＣ−４２（図５２）、リストＣ−４３（図５３）をリストＣ−４０（図５２）へ挿入する。また上記４の場合はリストＣ−４４（図５３）をリストＣ−４０（図５２）へ挿入する。あとは必要な数だけリストＣ−４５（図５３）もしくはリストＣ−４６（図５３）を挿入する。
【０２６６】
次に、サーバ側リソースアクセス部共通インタフェース５８のソースは上記２の場合に作成する。先ずリストＣ−５０（図５４）を用意する。次に必要な数だけリストＣ−１１（図５０）をＣ−５０（図５４）に挿入する。
【０２６７】
次に、サーバ側リソースアクセス部５７のソースは上記２の場合に作成する。先ずリストリストＣ−６０（図５４）を用意する。次に必要な数だけリストＣ−７（図４９）をリストＣ−６０（図５４）に挿入する。
【０２６８】
次に、サーバ側リソースアクセス用サーバ側アダプタ５６のＲＭＩインタフェース５６ａのソースは上記２の場合に作成する。先ずリストＣ−７０（図５４）を用意する。次に必要な数だけリストＣ−２１（図５０）をリストＣ−７０（図５４）に挿入する。
【０２６９】
次に、サーバ側リソースアクセス用サーバ側アダプタ５６のソースは上記２の場合に作成する。またリストＣ−８０（図５４）を用意する。次に必要な数だけリストＣ−３２、Ｃ−３３（図５１）をリストＣ−８０（図５４）に挿入する。
【０２７０】
次に、サーバ側リソースアクセス用クライアント側アダプタ５４のソースは上記２の場合に作成する。先ずリストＣ−９０（図５５）を用意する。次に必要な数だけリストＣ−４５、Ｃ−４６（図５３）をリストＣ−９０（図５５）に挿入する。
【０２７１】
次に、クライアント側リソースアクセス部５３のＲＭＩ用インタフェース５３ａのソースは上記３もしくは４の場合に作成する。先ずリストＣ−ａ０（図５５）を用意する。次に必要な数だけリストＣ−２１（図５０）をリストＣ−ａ０（図５５）へ挿入する。上記４の場合はリストＣ−ａ１（図５５）をリストＣ−ａ０（図５５）へ挿入する。
【０２７２】
次に、クライアント側リソースアクセス部５３のソースは上記３もしくは４の場合に作成する。先ずリストＣ−ｂ０（図５６）を用意する。次に必要な数だけリストＣ−３２（図５１）をリストＣ−ｂ０（図５６）へ挿入する。上記４の場合はリストＣ−ｂ１，Ｃ−ｂ２（図５６）をリストＣ−ａ０（図５５）へ挿入する。
【０２７３】
以上により、生成された各クラス／インタフェースにおいて、コンポーネント開発者はリストＣ−７（図４９）が挿入された部分を本体内容提供部７７により実装することでサーバコンポーネント５を開発することができる。
【０２７４】
また、本実施形態での記述はＪａｖａ言語を対象としたが、分散オブジェクト間通信にＣＯＲＢＡを用いたり、言語としてＣ＋＋を使用した場合でも少ない変更で対処することが可能である。
【０２７５】
（第９実施形態）
上記した実施形態によれば、Ｊａｖａアプレットでは処理の実行位置は必ずクライアント側であるという静的なシステム構造であったものを、実行時に処理の実行位置をサーバ側にするか、クライアント側にするかを決定できるような動的なシステム構造を持つことのできる分散システムが構築可能である。しかし、上記した実施形態では、サーバコンポーネントを提供するサーバとなるコンピュータは１つであり、クライアントとなるコンピュータとサーバとなるコンピュータ以外のネットワーク内の他のコンピュータを処理を実行する場所（サーバ）として用いることはできない。そこで、サーバ処理の実装をネットワーク内の任意のコンピュータで動作させることができる実施形態を次に説明する。
【０２７６】
本実施形態では、サーバコンポーネントの保守管理やインストール作業の軽減の観点から、サーバコンポーネントを扱うのは１つのサーバホストとなるコンピュータにする。
【０２７７】
他のコンピュータ（サブサーバホストと呼ぶ）上で実行する場合にはこのサーバホストからサーバコンポーネントを配送し実行する。そのため、サブサーバホストではサーバホストから送られてくる処理コンポーネントを受け取り実行可能な状態にし、その他必要な準備を行なう。
【０２７８】
配送されるサーバコンポーネントは特定のコンピュータ資源でもアクセスできるように、サーバコンポーネントを基本部、クライアント側リソースアクセス部、サーバ側リソースアクセス部から構成する。
【０２７９】
また実行場所を決定し、そこへサーバコンポーネントを配信し、処理を行なった後、さらにそこから実行場所を変更可能とするため、実行位置指示部やクライアント側アプリケーションプログラムのコールバック用インタフェースを設ける。
【０２８０】
図６５はこのような原理に基づく第９実施形態の分散システムの構成（ハードウェア構成、及びソフトウェアリソース）を示す。
【０２８１】
本システムは、クライアントホスト１５０とメインサーバホスト１２０、サブサーバホスト１３０とがネットワークを介して接続されて構成されている。
【０２８２】
メインサーバホスト１２０はサーバコンポーネント１１０と接続される。サーバコンポーネント１１０は図４に示すような基本部分１１１と、図６、図１９等に示すクライアント側リソースアクセス部１１２とサーバ側リソースアクセス部１１３と、サーバコンポーネント情報１１４とからなる。
【０２８３】
クライアントホスト１５０は、クライアント用コンポーネントローダ１５２、コールバック用インターフェース１５１とからなり、入力装置１８０、ディスプレイ１９０が接続される。
【０２８４】
メインサーバホスト１２０は、コンポーネントマネージャ１２１、コンポーネントサーバ１２２、実行位置決定部１２３とからなり、コンポーネントサーバ１２２はクライアント用コンポーネントローダ１５２、コールバック用インターフェース１５１に接続される。
【０２８５】
サブサーバホスト１０３は、サブサーバ用コンポーネントローダ１３１を有し、サブサーバ用コンポーネントローダ１３１はコンポーネントサーバ１２２に接続される。
【０２８６】
入力装置１７０、ディスプレイ１６０が接続される実行位置指示部１４０が実行位置決定部１２３に接続される。
【０２８７】
アプリケーションユーザは入力装置１８０とディスプレイ１９０を介してクライアントホスト１５０を操作する。クライアントホスト１５０はユーザの要求に応じた処理を行なうサーバコンポーネント１１０をメインサーバホスト１２０に対して要求する。具体的には、クライアントホスト１５０内のクライアント用コンポーネントローダ１５２を介してメインサーバホスト１２０内のコンポーネントサーバ１２２に対してサーバコンポーネント１１０の要求を行なう。その際、コンポーネントサーバ１２２に対してコールバック用インタフェース１１８を渡しておく。
【０２８８】
コンポーネントサーバ１２２はコンポーネントマネージャ１２１に指定されたサーバコンポーネント１１０を要求し、それを受け取る。また、コンポーネントサーバ１２２は指定されたサーバコンポーネント１１０を実行するコンピュータを実行位置決定部１２３を用いて決定する。
【０２８９】
メインサーバホスト１２０でサーバコンポーネント１１０を実行する場合は、サーバコンポーネント１１０の基本部１１２をコンポーネントサーバ１２２が実行可能な状態に（インスタンス生成）し、初期化等の準備を行なう。
【０２９０】
サブサーバホスト１０３でサーバコンポーネント１１０を実行する場合は、コンポーネントサーバ１２２はサーバコンポーネント１１０の基本部１１２をサブサーバ用コンポーネントローダ１３１に配送する。サブサーバ用コンポーネントローダ１３１は必要なクラスをコンポーネントサーバ１２２から受け取り、それをインスタンス生成し、初期化等の準備を行なう。
【０２９１】
クライアントホスト１５０側でサーバコンポーネント１１０を実行する場合は、コンポーネントサーバ１２２はサーバコンポーネント１１０の基本部１１２をクライアントホスト１５０のクライアント用コンポーネントローダ１５２に配送する。クライアント用コンポーネントローダ１５２は必要なクラスをコンポーネントサーバ１２２から受け取りそれをインスタンス生成し、初期化等の準備を行なう。
【０２９２】
クライアントホスト１５０は上記のいづれかの場合でインスタンス生成されたサーバコンポーネント１１０の基本部１１２に対してネットワーク経由もしくはインプロセスで接続し、それを利用し処理を実行する。
【０２９３】
なお、サーバコンポーネント１１０がクライアント側リソースアクセス部１１２を有する場合は、コンポーネントサーバ１２２がこれをクライアントホスト１５０のクライアント用コンポーネントローダ１５２に配送する。クライアント用コンポーネントローダ１５２はそれをインスタンス生成し、サーバコンポーネント１１０の基本部１１２に設定する。サーバコンポーネント１１０がサーバ側リソースアクセス部１１３を有する場合は、サーバコンポーネント情報１１４に記載される「サーバ側リソースアクセス部１１３を実行するコンピュータ」上のサブサーバホスト１０３のサブサーバ用コンポーネントローダ１３１にサーバ側リソースアクセス部１１３を配送する。サブサーバ用コンポーネントローダ１３１はそれをインスタンス生成し、サーバコンポーネント１１０の基本部１１２に設定する。サーバ側リソースアクセス部１１３をメインサーバホスト１２０で動作させる場合はコンポーネントサーバ１２２がインスタンス生成し、サーバコンポーネント１１０の基本部１１２に設定する。
【０２９４】
実行位置の決定（指示）についてはシステム管理者が入力装置１７０、ディスプレイ１６０を介して実行位置指示部１４０に指示する。実行位置指示部１４０は実行位置決定部１２３に対してシステム管理者の指示を伝達する。実行位置決定部１２３は以後の実行位置判定においてこの情報を基に実行位置を判定する。また、実行位置決定部１２３はコンポーネントサーバ１２２から依頼された実行位置を決定後、その内容を実行位置指示部１４０にも伝える。この情報を基に、実行位置指示部１４０はディスプレイ１６０に現在実行中のサーバコンポーネント１１０とその実行位置とを表示する。
【０２９５】
システム管理者はこの情報を基に、現在実行中のコンポーネントに対して、入力装置１７０を介して次の実行位置を指定することもできる。システム管理者が指示した「次の実行場所」の情報が実行位置指示部１４０から実行位置決定部１２３へ伝わると、実行位置決定部１２３はさらにコンポーネントサーバ１２２にその内容を伝え、サーバコンポーネント１１０の再配置を行なう処理を行なう。具体的には現在実行中のサーバコンポーネント１１０を一旦終了し、新たに指示された場所にサーバコンポーネント１１０を配送し、インスタンス生成等を行なう。そして、コンポーネントサーバ１２２はサーバコンポーネント１１０の再配置があったことをコールバック用インタフェース１１８を用いてクライアントホスト１５０に伝え、新しい場所を指示する。クライアントホスト１５０はその情報を基に新たなサーバコンポーネント１１０に対して再接続等の初期化処理を行なう。
【０２９６】
このような第９実施形態によれば、上に述べた実施形態の効果に加えて、サーバ処理の実装をネットワーク内の任意のコンピュータで動作させることができるとともに、サーバ処理の実装において、特定のコンピュータ上での動作も可能にすることができる効果を有する。
【０２９７】
（第１０実施形態）
図６６は本発明の分散システムの第１０実施形態の物理構成を示すブロック図、図６７は第１０実施形態の論理構成を示すブロック図である。ここでは、デーベースへアクセスし、簡単な処理を行なうアプリケーションプログラムを例として示してある。
【０２９８】
図６６に示すように、第１０実施形態の分散システムにおいては、ネットワーク３１０に接続されたメインサーバマシン３３０にメインサーバホスト１２０が、サブサーバマシン（Ｂ）３５０にサブサーバホスト２３０が、サブサーバマシン（Ｂ）３５０にサブサーバホスト２３０とデータベース４００が、管理者用マシン３２０に実行位置指示部２４０が、クライアントマシン３６０にデータベースアクセス用クライアントホスト２５０がそれぞれインストールされている。ここで、インストールの意味は、プログラムを計算機に組み込み、実行するための準備をすることである。
【０２９９】
図６７に示すように、分散システムはデータベースアクセス用サーバコンポーネント２１０、メインサーバホスト２２０、サブサーバホスト２３０、実行位置指示部２４０、データベースアクセス用クライアントホスト２５０、データベース４００から構成される。さらにサーバコンポーネント２１０はデータベース（ＤＢ）アクセス基本部２１１とクライアント側リソースアクセス部２１２、サーバ側リソースアクセス部２１３、サーバコンポーネント情報２１４から構成され、クライアント側リソースアクセス部２１２はさらにＧＵＩ２１２ａを含む。なお、クライアント側リソースアクセス部２１２とサーバ側リソースアクセス部２１３は必ず設ける必要は無く、省略可能な場合もある。
【０３００】
サーバコンポーネント情報２１４の一例を図６８に示す。ここでは、コンポーネント名、サーバ側リソースアクセス部の実行場所、クライアント側リソースアクセス部の有無がサーバコンポーネント情報２１４となっている。
【０３０１】
メインサーバホスト２２０はコンポーネントマネージャ２２１、コンポーネントサーバ２２２、実行位置決定部２２３から構成される。
【０３０２】
サブサーバホスト２３０はサブサーバ用コンポーネントローダ２３１を含む。
【０３０３】
実行位置表示部２４０はＧＵＩ２４１を含む。
【０３０４】
データベースアクセス用クライアントホスト２５０はクライアント用コンポーネントローダ２５２、コールバック用インタフェース２５３、ＧＵＩ２５０から構成される。
【０３０５】
このように構成される本実施形態の分散システムの動作として、サーバコンポーネント２１０の実行位置の決定、配置、実行並びに、実行後の再配置について、図６７に示すデータベースアクセスアプリケーションプログラムの実行順に合わせて説明する。なお、ここで例としてあげるデータベースアクセスアプリケーションプログラムは図６９に示すような簡単な売り上げ管理データベースへアクセスして、ある特定の購入者の合計購入金額を表示するようなアプリケーションプログラムとする。
【０３０６】
このアプリケーションプログラムのクライアントホスト２５０のＧＵＩ２５３を図７０に示す。
【０３０７】
図７１は、本実施形態におけるサーバコンポーネント２１０の実行位置の決定、配置、実行、再配置の一連の流れを示す。実行位置決定は、アプリケーションプログラムのユーザがデータベースアクセスを行なうため、クライアントホスト２５０からメインサーバホスト２２０に対してサーバコンポーネント２１０を要求し、それに対して実行位置決定部２２３が実行位置を判定することである。配置は、決定した実行位置に応じたサーバコンポーネント２１０の配送、インスタンス生成、準備からクライアントホスト２５０との接続処理である。実行は、実際のデータベースアクセス処理である。再配置は、管理者によるサーバコンポーネント２１０の実行後の再配置である。なお、このデータベースアクセスアプリケーションプログラムはあくまで説明の便宜上のものであり、本発明はどのようなアプリケーションプログラムにも適用可能である。
【０３０８】
（１）［実行位置決定］サーバコンポーネント２１０の要求までの流れ
データベースアプリケーションプログラムのユーザは、先ず検索したい購入者の名前を購入者名入力部６１０に入力する（ステップＳＴ１０２）。次に検索ボタン５０６を押す（ステップＳＴ１０４）。クライアントホスト２５０は既にサーバコンポーネント２１０を使える状態にあるかどうかを調べる（ステップＳＴ１０６）。もし既に使える状態であれば、それを利用して検索等の処理を行ない（ステップＳＴ１１４）、結果を表示する（ステップＳＴ１６）。
【０３０９】
そうでなければ、クライアントホスト２５０はコンポーネントサーバ２２２へサーバコンポーネント２１０の要求を行なう（ステップＳＴ１０８）。コンポーネントサーバ２２２は実行位置決定部２２３に依頼し、クライアントホスト２５０がコンポーネントサーバ２２０へ要求したサーバコンポーネント２１０の実行位置を決定する（ステップＳＴ１１０）。
【０３１０】
（２）［配置］実行位置決定後からサーバコンポーネント２１０が使用可能になるまでの流れ
実行位置決定後からサーバコンポーネント２１０が使用可能になるまでの一連の流れを図７２を参照して説明する。また、この処理の時にサーバコンポーネント２１０が有するサーバコンポーネント情報２１４の一例を図７３に示す。サーバコンポーネント情報２１４は、コンポーネント名としてはサーバコンポーネント２１０、サーバ側リソースアクセス部の実行場所としてはサブサーバマシン（Ｂ）３５０、クライアント側リソースアクセス部の有無としては有りが格納される。
【０３１１】
コンポーネントサーバ２２２は要求されたサーバコンポーネント２１０の実行位置を決定するために、先ずコンポーネントマネージャ２２１を介してサーバコンポーネント２１０のサーバコンポーネント情報２１４を参照し、ＤＢアクセス基本部２１１を動作させるコンピュータが指定されているかどうかを調査する。この情報はオプションであり、無い場合もある。本実施形態では特に指定していない。
【０３１２】
次に、実行位置決定部２２３に実行位置を尋ねる。本実施形態ではサブサーバマシン（Ａ）３４０であるとする。なお、サーバコンポーネント情報２１４にサーバコンポーネント基本部（データベースアクセス基本部２１１）の実行位置が指定されている場合で、実行位置決定部２２３の決定結果と指定場所が異なる場合、どちらを実行場所とするかはそのシステムが任意に決定できる。例えば、サーバコンポーネント情報２１４の情報を優先することにするように設定できる。
【０３１３】
図７２では、サーバコンポーネント２１０の実行位置の判定（ステップＳＴ１２０）の結果、すなわちＤＢアクセス基本部２１１の実行位置はサブサーバホスト２３０となったとするので、コンポーネントサーバ２２２はコンポーネントマネージャ２２１からＤＢアクセス基本部２１１を受け取り、それをサブサーバマシン（Ａ）３４０のサブサーバ用コンポーネントローダ２３１に配送する（ステップＳＴ１２８）。サブサーバ用コンポーネントローダ２３１は受け取ったＤＢアクセス基本部２１１をインスタンス生成し、初期化（初期値の設定やクライアントホスト２５０からの接続を受けるための準備）を行なう（ステップＳＴ１３０）。そして、コンポーネントサーバ２２２はクライアント用コンポーネントローダ２５２に対して、要求されたサーバコンポーネント２１０をサブサーバマシン（Ａ）３４０で動作させたことを通知する。クライアントホスト２５０はその情報を基にサブサーバマシン（Ａ）３４０で動作しているＤＢアクセス基本部２１１に対して接続を行なう。
【０３１４】
サーバコンポーネント情報２１４より、サーバコンポーネント２１０はクライアント側リソースアクセス部２１２を持っていることがわかるので（ステップＳＴ１３２）、コンポーネントサーバ２２２はクライアント側リソースアクセス部２１２をクライアントホスト２５０のクライアント用コンポーネントローダ２５２に送る（ステップＳＴ１３４）。クライアント用コンポーネントローダ２５２は受け取ったクライアント側リソースアクセス部２１２をインスタンス生成し、初期化を行なう（ステップＳＴ１３６）。そしてそれをサブサーバマシン（Ａ）３４０で実行しているＤＢアクセス基本部２１１に設定する（ステップＳＴ１３８）。
【０３１５】
同じく、サーバコンポーネント情報２１４より“サーバ側リソースアクセス部２１３の実行場所”が指定されていることから、サーバコンポーネント２１０はサーバ側リソースアクセス部２１３も持っていることがわかるので（ステップＳＴ１４０）、コンポーネントサーバ２２２はサーバ側リソースアクセス部２１３を動作させるべきコンピュータをサーバコンポーネント情報２１４から調べる（ステップＳＴ１４２）。なお、“サーバ側リソースアクセス部２１３の実行場所”が指定されていない場合は、そのサーバコンポーネント２１０はサーバ側リソースアクセス部２１３を持たないことを示す。この例では、サブサーバホスト２３０で動作させるので、コンポーネントサーバ２２２はサーバ側リソースアクセス部２１３をサブサーバホスト２３０のサブサーバホスト２３０のサブサーバ用コンポーネントローダ２３１へ送る（ステップＳＴ１４６）。サーバ側リソースアクセス部２１３を受け取ったサブサーバ用コンポーネントローダ２３１はそれをインスタンス生成し、初期化を行なう（ステップＳＴ１４８）。そしてそれをサブサーバマシン（Ａ）３４０で実行しているＤＢアクセス基本部２１１に設定する。
【０３１６】
以上の一連の流れにより、本実施形態のデータベースアクセスに必要なシステム構成（クライアント−サーバ間の関係）が全て成立する。
【０３１７】
（３）［実行］実際のデータベースアクセス処理の流れ
本発明とは直接関係しないが、本実施形態のデータベースアクセスについて、図７４を参照して説明する。
【０３１８】
クライアントホスト２５０は購入者名入力部に入力された購入者名をＤＢアクセス基本部２１１へ送る（ステップＳＴ１６０）。ＤＢアクセス基本部２１１はサーバ側リソースアクセス部２１３に購入者名を渡し、データベースにアクセスするよう命ずる（ステップＳＴ１６２）。サーバ側リソースアクセス部２１３は渡された購入者名を含むデータをデータベースから得、その結果をＤＢアクセス基本部２１１へ返す（ステップＳＴ１６４）。ＤＢアクセス基本部２１１ではその結果の値段の値を合計する。そしてその値をクライアントホスト２５０へ返す（ステップＳＴ１６６）。結果を受け取ったクライアントホスト２５０はＧＵＩの合計購入金額表示部にその結果を表示する（ステップＳＴ１６８）。
【０３１９】
（４）［再配置］管理者によるサーバコンポーネント２１０の実行後の再配置コンポーネントサーバ２２２はＤＢアクセス基本部２１１をインスタンス化もしくは他のコンポーネントローダへ配信する際に、該当するサーバコンポーネント２１０（ＤＢアクセス基本部２１１）とそれを実行した場所を実行位置決定部２２３に知らせる。実行位置決定部２２３はこのような情報をリストとして保持し、必要に応じて実行位置指示部２４０に伝え、ＧＵＩを用いて表示する。本実施形態におけるＧＵＩを図７５に示す。
【０３２０】
この動作を図７６に示すフローチャートを参照して説明する。
【０３２１】
ＧＵＩは図７５に示すように実行位置決定部２２３が保持している現在実行中のサーバコンポーネント２１０に関する情報を表示するため、サーバコンポーネント名表示部と現在の実行場所表示部、再配置場所指定部、再配置実行ボタン、終了ボタンを有している。サーバコンポーネント名表示部と再配置場所指定部はそれぞれプルダウンメニューのようになっており、各部の右側のボタンを押すと選択可能な候補のリストが表示され、システム管理者はこの表示の中から選ぶことになる。サーバコンポーネント名表示部でサーバコンポーネント２１０を指定すると現在の実行場所表示部に選択されたサーバコンポーネント２１０が動作している場所が表示される（ステップＳＴ１７０）。この情報は実行位置決定部２２３が保持している。
【０３２２】
次にシステム管理者がＧＵＩの再配置場所指定部にて再配置先としてメインサーバホスト２２０マシンを指定する（ステップＳＴ１７２）。なお再配置場所として選択可能な項目に関するデータは実行位置決定部２２３が保存しており、この実施形態の場合はメインサーバマシン３３０、サブサーバマシン（Ａ）３４０、サブサーバマシン（Ｂ）２３０、クライアントマシン３６０が選択対象となる。これらのデータはシステム起動時にメインサーバホスト２２０やサブサーバホスト２３０、クライアントホスト２５０の間のやりとりによって収集される。例えば、メインサーバホスト２２０は起動した際に、ネットワーク内に存在するサブサーバホスト２３０を探して、見つかったものを実行位置決定部２２３に知らせる。サブサーバホスト２３０は起動した際にメインサーバホスト２２０に連絡し、コンポーネントを介して実行位置決定部２２３に知らせる。クライアントホスト２５０はサーバコンポーネント２１０をメインサーバホスト２２０に要求する際にコンポーネントサーバ２２２を介して実行位置決定部２２３に知らせる。
【０３２３】
そしてシステム管理者が再配置ボタンを押すと指定したサーバコンポーネント２１０と再配置先（メインサーバホスト２２０）の情報が実行位置指定部から実行位置決定部２２３へ送られる（ステップＳＴ１７４）。実行位置決定部２２３はその内容をコンポーネントサーバ２２２に伝え（ステップＳＴ１７６）、再配置処理を開始する（ステップＳＴ１７８）。
【０３２４】
システム管理者がサーバコンポーネント２１０をサブサーバマシン（Ａ）３４０からメインサーバマシン３３０へ再配置する例を図７７に示す。基本的には上記（２）の「実行位置決定後からサーバコンポーネント２１０が使用可能になるまで」とほとんど同じ処理となるので、ここでは簡単に説明する。
【０３２５】
再配置先がメインマシンであるのでＤＢアクセス基本部２１１をコンポーネントサーバ２２２がインスタンス生成し、初期化等を行なう（ステップＳＴ２０４）。再配置が発生したことをクライアントホスト２５０へ伝え、これまで動作させていたサーバコンポーネント２１０を破棄する（ステップＳＴ２１２）。破棄する対象が他のサブサーバホスト２３０やクライアントである場合はそれを破棄するように伝達し、伝達された側が破棄を行なう。
【０３２６】
サーバコンポーネント２１０はクライアント側リソースアクセス部２１２を持つのでその準備を行なう（ステップＳＴ２１４〜ＳＴ２２０）。また、同じくサーバコンポーネント２１０はサーバ側リソースアクセス部２１３を持つので、その準備を行なう（ステップＳＴ２２２〜ＳＴ２３２）。
【０３２７】
以上により再配置が終了する。
【０３２８】
再配置終了後は継続して上記（３）に示したデータベースアクセス処理を継続できる。
【０３２９】
第１０実施形態によれば、上に述べた実施形態の効果に加えて、実行後のサーバ処理の実行位置を変更（再配置）することができる。
【０３３０】
本発明は、上述した各実施形態に限定されるものでなく、その要旨を逸脱しない範囲で種々に変形することが可能である。例えば、実施形態に記載した手法は、コンピュータに実行させることができるプログラム（ソフトウエア手段）として、例えば磁気ディスク（フロッピーディスク、ハードディスク等）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤ等）、半導体メモリ等の記録媒体に格納し、また通信媒体により伝送して頒布することもできる。なお、媒体側に格納されるプログラムには、コンピュータに実行させるソフトウエア手段（実行プログラムのみならずテーブルやデータ構造も含む）をコンピュータ内に構成させる設定プログラムをも含むものである。本装置を実現するコンピュータは、記録媒体に記録されたプログラムを読み込み、また場合により設定プログラムによりソフトウエア手段を構築し、このソフトウエア手段によって動作が制御されることにより上述した処理を実行する。
【０３３１】
【実施例】
次に、本発明の分散システムの具体例を実施例として次に説明する。
【０３３２】
（第１実施例）
本発明の分散システムは、画像処理アプリケーションプログラムに応用することができる。
【０３３３】
画像処理アプリケーションプログラムにおいては、処理を行うためのデータ転送量（引数や返り値）は大きいが、処理自体は単純な繰り返しが多いため、サーバコンポーネント本体のサイズが小さくできる場合が多い。したがって、画像処理アプリケーションプログラムでは、クライアント／サーバの両ホストの計算能力やネットワークの状態によって、より速く処理結果が得られるような実行位置が変わってくるからである。したがって、本システムを画像処理アプリケーションプログラムに適用すればスループットが向上する。
【０３３４】
サーバコンポーネントへの具体的な適用例としては、実施例で示したように画像の平滑化処理がある。
【０３３５】
（第２実施例）
本発明の分散システムは、モバイル環境でのコンポーネントビジネスへ利用することができる。
【０３３６】
コンポーネントの流通においてネットワークの利用は最も有効な手段の一つであると考えられる。本分散システムをインフラとして用いた場合には、有効なコンポーネント販売システムを構築できる。
【０３３７】
このような利用形態の場合はどちらかといえば、ＬＡＮのような常時接続されたネットワーク環境よりも、むしろモバイル環境や公衆回線を通した一般家庭のインターネット接続などが対象となりやすいと考えられる。
【０３３８】
ユーザ（クライアントホスト１側）はコンポーネントを提供するコンポーネントプロバイダに接続し、必要なコンポーネントの購入を行なう。その際、「試しに試用してから、購入を考えたい」というユーザに対しては、サーバコンポーネント本体をサーバホスト２側でのみ動作させるようにする。必要に応じて、使用回数や使用時間などについて制限を設ける。その制限機構は、例えばクライアント側アダプタ２２に設けておけばよい。そして、購入することになったユーザに対してはサーバコンポーネント本体をクライアントホスト１側ヘダウンロードし、クライアントホスト１側のローカルのディスクへ保存できるようにする。
【０３３９】
コンポーネント開発者はサーバコンポーネントを、どちらの状況で利用されるかを意識せずに開発できるため、上述した自動生成技術と相俟って、上記のような使い方をしてもコンポーネント開発者へかかる負担は従来のコンポーネント開発と変わらない。
【０３４０】
また、このような利用の場合には、サーバコンポーネント本体に相当するものは処理プロセスだけでなく、各種データなどの場合も考えられる。例えば、戦略シミュレーションゲームにおける新しいマップコンポーネントの提供や、ニュースコンポーネント（ヘッドラインはクライアントヘ、本文はコンポーネント本体として扱う）、リリースされた新曲コンポーネント（クライアントへ最初送られるのは一部のパートのみ、もしくは音質の低い（サンプリングが荒い）もの）などが考えられる。
【０３４１】
一例として、ニュースコンポーネントの販売が考えられる。ニュースコンポーネントの販売システムでは、クライアント側アダプタ２２がヘッドラインや要約などの簡単な情報のみを提供するようにする。そしてコンポーネント本体２１でニュースの詳細な内容や写真などを提供する。このシステムではサーバ側アダプタ２４はほとんど機能する必要はない。例えば、一部の音声情報などのサーバコンポーネント本体にある情報も、クライアント側アダプタ２２から利用するような場合には必要となる。
【０３４２】
クライアントホスト１５０からは、対象とするニュースコンポーネントを試し見する際は、クライアント側アダプタ２２を介して参照できる簡単な内容のみを見ることができ、実際にそれを購入し本体を手元にダウンロードした時点で詳細な情報を参照できるようになる。
【０３４３】
この以外は、ＰＵＳＨ技術（プッシュ技術）などのソフトウェア配信と組み合わせることで、より幅広いサービスの提供が可能となる。
【０３４４】
（第３実施例）
本分散システムは、分散コンポーネント開発システムへ利用することができる。
【０３４５】
ネットワークを介して使用されることが前提となるアプリケーション／コンポーネントの開発においても、本システムをインフラとして用いることで、効率よく開発が行なえるようになると考えられる。
【０３４６】
例えばコンポーネントの開発者はβ版の段階のものを、サーバホスト２側でのみ動作させるという条件をつけて、コンポーネントをシステムに登録する。β版はサーバホスト２側でのみ実行できるので、エラーログの収集が容易でり、またクライアントホスト１側も比較的安全である。もちろん、βテストを行なえるクライアントのユーザの限定も行なえる。完成したコンポーネントはそのまま条件（サーバホスト２側でのみ実行可能とした条件）を変更することで、それ以降は通常のコンポーネントとして配布することができる。そのため、試験などの段階で特別なスタブなどを作成しなくても済むため、開発効率の面で有効であると考えられる。
【０３４７】
（第４実施例）
本分散システムは、実行環境の違いを吸収可能なシステム関発へ利用することができる。
【０３４８】
Ｊａｖａのような日進月歩な言語環境などでは、バージョンの違いによってＡＰＩが追加・変更されたりし、実行環境ごとに差が生じる可能性も考えられる。このような実行環境の違いを吸収するのにも本システムは有効であると考えられる。
【０３４９】
例えばサーバホストと第１のクライアントホストと第２のクライアントホストがネットワークで接続されている場合に、第１のクライアントホストでは、全てのＪａｖａＡＰＩがサポートされるが、第２のクライアントホストでは、Ｊａｖａの拡張ＡＰＩがサポートされていないとする。
【０３５０】
ここで、クライアントから要求される処理コンポーネントがある拡張ＡＰＩを必要としている場合、第１のクライアントから処理要求が発生すると、クライアント／サーバのいずれのホストでも実行可能であるので、例えば負荷が少ないほうのホストで処理を実行することができる。しかし、第２のクライアントから要求が発せられた場合には、クライアントホスト側でその処理を実行することはできないので、必ずサーバホスト側で動作させるようにする。
【０３５１】
したがって、このようにすれば実行環境の違いがある場合においても処理を柔軟に実行できるようになる。これを応用すれば、例えば組み込み／マイコン系などで使用される制限された実行環境においても有効に利用できると考えられる。
【０３５２】
（第５実施例）
本分散システムは、通常ＤＢシステムに適用すればネットワークトラフィックを削減できることが考えられる。
【０３５３】
通常の業務アプリケーションプログラムを考えた場合、データベースとなるサーバホストやクライアントホストが多数存在し、そのネットワークの物理的な構成も様々な形態を取ることになる。
【０３５４】
例えばＬＡＮが２つのセグメントから構成され、サーバコンポーネントを提供するコンポーネントサーバがＬＡＮの第２セグメント上にあり、提供されるコンポーネントは特定のＤＢへアクセスするような処理コンポーネントであり、クライアントはそれを利用する、という場合を考える。
【０３５５】
この場合で、例えば第１セグメント上にある第１クライアントが、第１セグメント上のＤＢサーバへアクセスするためのコンポーネントを要求した場合、それを第２セグメント上のコンポーネントサーバで実行する場合と、第１セグメント上の第１クライアントで実行する場合では、ネットワークトラフィックの観点から後者のほうが良いと考えられる。
【０３５６】
通常このような分散型の業務システムを構築する場合、システム全体を設計する段階でこのような物理的な構成を考慮に入れることが考えられるが、クライアントホストやＤＢを頻繁に追加、削除したりしてネットワーク構成などを変更しなければならなくなった場合に、対応が難しい。しかしながら、本クライアントシステムをベースに分散型業務システムを構築していれば、コンポーネントの実行位置の変更だけでネットワーク構成の変更にも対応でき、最適な分散システムを継続して使用することができるようになると考えられる。
【０３５７】
【発明の効果】
以上説明したように、本発明の分散システムによれば、２つ以上のコンピュータが接続されるネットワーク環境下において、以下のことが可能となる。
【０３５８】
（１）処理の実行本体をサーバで管理してその実行位置を決定するようにしたので、処理プロセスの実行位置を動的に変更してシステム構成を柔軟に変化させることが可能となる。
【０３５９】
（２）サーバコンポーネントの開発者は処理ロジックをサーバ側の処理を１箇所（サーバホスト）のみに実装すればよいので、クライアント側で動作する処理プロセスとサーバ側で動作する処理プロセスを別々に二重に開発する必要が無いとともに、処理ロジックの保守管理やインストール作業が軽減できる。
【０３６０】
（３）サーバコンポーネントを基本部、クライアント側リソースアクセス部、サーバ側リソースアクセス部から構成したので、特定の計算機資源でもサーバコンポーネントをアクセスすることができる。
【０３６１】
（４）メインサーバ以外に複数のサブサーバがあり、サブサーバで実行する場合は、メインサーバからサブサーバへサーバコンポーネントを配送し、サブサーバではそれを受け取り、実行可能な状態にする。
【０３６２】
（５）実行位置を決定し、そこへサーバコンポーネントを配信し、処理を行った後、さらにそこから実行位置を変更（再配置）できる。
【図面の簡単な説明】
【図１】本発明の第１実施形態に係る分散システムのハードウエア構成例を示すブロック図。
【図２】第１実施形態の分散システムにおけるソフトウェア論理構成を示す図。
【図３】第１実施形態のアプリケーションプログラムの構成例を示す図。
【図４】第１実施形態におけるサーバコンポーネントの構成例を示す図。
【図５】サーバコンポーネント本体がクライアントホストで実行される場合と、サーバホストで実行される場合の構成を示す図。
【図６】コンポーネントローダの構成例を示す図。
【図７】コンポーネントサーバの構成例を示す図。
【図８】コンポーネントマネージャの構成例を示す図。
【図９】サーバコンポーネントへの処理要求から実行位置の決定までを示す図。
【図１０】サーバコンポーネントをクライアントホスト側で実行させる場合にその実行位置決定から実行までについて示す図。
【図１１】サーバコンポーネントをサーバホスト側で実行させる場合にその実行位置決定から実行までについて示す図。
【図１２】サーバコンポーネントへの処理要求から処理実行までの処理全体を示す流れ図。
【図１３】図１２におけるリモートでサーバ本体を使用するための処理を示す流れ図。
【図１４】図１２におけるコンポーネントローダのコンポーネントを受け取る処理を示す流れ図。
【図１５】図１２におけるキャッシュに存在するコンポーネントを使用するための処理を示す流れ図。
【図１６】本発明の第２実施形態におけるサーバコンポーネントの構成例を示す図。
【図１７】サーバコンポーネント本体をサーバホスト側で動作させる場合のサーバコンポーネントの構成を示す図。
【図１８】サーバコンポーネント本体をクライアントホスト側で動作させる場合のサーバコンポーネントの構成を示す図。
【図１９】本発明の第３実施形態におけるサーバコンポーネントの構成例を示す図。
【図２０】サーバコンポーネント本体をサーバホスト側で動作させる場合のサーバコンポーネントの構成を示す図。
【図２１】特定のプログラミング言語でサーバコンポーネントを開発した時の様子を示す図。
【図２２】本発明の第７実施形態に係るサーバコンポーネント自動生成システムの構成例を示すブロック図。
【図２３】同実施形態におけるＪａｖａによる共通インタフェースの一例を示す図。
【図２４】同実施形態におけるＪａｖａによるサーバコンポーネント本体の一例を示す図。
【図２５】同実施形態におけるＪａｖａによるサーバ側アダプタクラスの一例を示す図。
【図２６】同実施形態におけるＪａｖａによるサーバ側アダプタクラスのＲＭＩ用インタフェースの一例を示す図。
【図２７】同実施形態におけるＪａｖａによるクライアント側アダプタの一例を示す図。
【図２８】テンプレート提供部が提供するテンプレートに対応するリストＬＣ−１〜ＬＣ７を示す図。
【図２９】テンプレート提供部が提供するテンプレートに対応するリストＬＣ−８〜ＬＣ１２を示す図。
【図３０】クラスファイル自動生成の全体の処理流れを示す流れ図。
【図３１】サーバコンポーネント本体のスケルトン生成を示す流れ図。
【図３２】共通インタフェースの自動生成を示す流れ図。
【図３３】サーバ側アダプタクラスの自動生成を示す流れ図。
【図３４】アダプタクラスの定義へ中継用メゾットを埋め込む処理を示す流れ図。
【図３５】本発明の第８実施形態におけるサーバコンポーネント自動生成システムの構成例を示すブロック図。
【図３６】同実施形態におけるＪａｖａによる共通インタフェースの一例を示す図。
【図３７】同実施形態におけるＪａｖａによるサーバコンポーネント本体の一例を示す図。
【図３８】同実施形態におけるＪａｖａによるサーバアダプタクラスの一例を示す図。
【図３９】同実施形態におけるＪａｖａによるサーバアダプタクラスのＲＭＩ用インタフェースの一例を示す図。
【図４０】同実施形態におけるＪａｖａによるクライアント側アダプタの一例を示す図。
【図４１】同実施形態におけるＪａｖａによるサーバ側リソースアクセス部共通インタフェースの一例を示す図。
【図４２】同実施形態におけるＪａｖａによるサーバ側リソースアクセス部の一例を示す図。
【図４３】同実施形態におけるＪａｖａによるＲＭＩ用インタフェースの一例を示す図。
【図４４】同実施形態におけるＪａｖａによるサーバ側リソースアクセス用サーバ側アダプタの一例を示す図。
【図４５】同実施形態におけるＪａｖａによるサーバ側リソースアクセス用クライアント側アダプタの一例を示す図。
【図４６】同実施形態におけるＪａｖａによるクライアント側リソースアクセス部のＲＭＩ用インタフェースの一例を示す図。
【図４７】同実施形態におけるＪａｖａによるクライアント側リソースアクセス部の一例を示す図。
【図４８】テンプレート提供部が提供するテンプレートに対応するリストＣ−１〜Ｃ−４を示す図。
【図４９】テンプレート提供部が提供するテンプレートに対応するリストＣ−５〜Ｃ−９，Ｃ−ａを示す図。
【図５０】テンプレート提供部が提供するテンプレートに対応するリストＣ−１０〜Ｃ−２２を示す図。
【図５１】テンプレート提供部が提供するテンプレートに対応するリストＣ−３０〜Ｃ−３４を示す図。
【図５２】テンプレート提供部が提供するテンプレートに対応するリストＣ−４０〜Ｃ−４２を示す図。
【図５３】テンプレート提供部が提供するテンプレートに対応するリストＣ−４３〜Ｃ−４６を示す図。
【図５４】テンプレート提供部が提供するテンプレートに対応するリストＣ−５０〜Ｃ−８０を示す図。
【図５５】テンプレート提供部が提供するテンプレートに対応するリストＣ−９０，Ｃ−ａ０，Ｃ−ａ１を示す図。
【図５６】テンプレート提供部が提供するテンプレートに対応するリストＣ−ｂ０〜Ｃ−ｂ２を示す図。
【図５７】自動生成の全体の処理を示す流れ図。
【図５８】サーバ側リソースアクセス部の各ファイルの作成処理を示す流れ図。
【図５９】サーバコンポーネント本体のスケルトン生成処理を示す流れ図。
【図６０】共通インタフェースの自動生成処理を示す流れ図。
【図６１】サーバ側アダプタクラスの自動生成処理を示す流れ図。
【図６２】中継用メソッド定義の作成処理を示す流れ図。
【図６３】クライアント側アダプタファイルの自動生成処理を示す流れ図。
【図６４】サーバ側リソースアクセス部の共通インタフェースファイルの自動生成処理を示す流れ図。
【図６５】本発明の第９実施形態に係る分散システムのハードウエア構成例を示すブロック図。
【図６６】本発明の第１０実施形態に係る分散システムの物理構成例を示すブロック図。
【図６７】第１０実施形態に係る分散システムの論理構成例を示すブロック図。
【図６８】サーバコンポーネント情報の一例を示す図。
【図６９】データベースアプリケーションプログラムが対象とするデータベースの一例を示す図。
【図７０】データベースアプリケーションプログラムのクライアントホストのＧＵＩの一例を示す図。
【図７１】第１０実施形態の全体の動作を示すフローチャート。
【図７２】サーバコンポーネントを動的に配置する際の動作を示すフローチャート。
【図７３】サーバコンポーネントを動的に配置する際のサーバコンポーネント情報の一例を示す図。
【図７４】データベースアクセスの際の動作を示すフローチャート。
【図７５】コンポーネントマネージャのＧＵＩの一例を示す図。
【図７６】再配置の全体の流れを示すフローチャート。
【図７７】図７６の再配置処理の詳細なフローチャート。
【符号の説明】
１…クライアントホスト
２…サーバホスト
３…ネットワーク
４…記憶装置
５…サーバコンポーネント
１１…クライアントホスト基本部分
１２…コンポーネントローダ
１３…コンポーネントキャッシュ
１４…コンポーネントサーバ
１５…実行位置決定部
１６…コンポーネントマネージャ
１７…アクセス制御監視部
１８…ネットワークモニタ
２１…サーバコンポーネント本体
２２…クライアント側アダプタ
２３…分散オブジェクト間通信
２４…サーバ側アダプタ
２５…共通インタフェース
３１…インスタンス生成部
３２…コンポーネント復号化部
３３…コンポーネント解凍部
３６…インスタンス生成部
３７…コンポーネント暗号化部
３８…コンポーネント圧縮部
４１…コンポーネント抽出部
４２…コンポーネント情報抽出部
４３…コンポーネント登録管理部
５１…クライアントリソース対応部
５２…サーバリソース対応部
５３…クライアントリソースアクセス部
５４…サーバリソースアクセス用クライアント側アダプタ
５５…分散オブジェクト間通信
５６…サーバリソースアクセス用サーバ側アダプタ
５７…サーバリソースアクセス部
５８…サーバリソースアクセス部共通インタフェース
６１…クライアントリソースアクセス用クライアント側アダプタ
６２…分散オブジェクト間通信
６３…クライアントリソースアクセス用サーバ側アダプタ
６４…クライアントリソースアクセス部共通インタフェース
７１…開発用計算機
７２…情報提供部
７３…テンプレート提供部
７４…クラスファイル自動生成部
７５…クラスファイル部
７６…本体処理内容作成部
７７…本体処理内容提供部[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a distributed system in which a plurality of computers are connected, and more particularly, to an improvement in determining an execution position of a requested process.
[0002]
[Prior art]
Due to the recent development of computer / communication technology, computers are used by constructing various types of network systems such as LAN, WAN, or the Internet and sharing resources in the network, rather than using the computers alone. The case is getting more. In such a network system, a system in which there is another computer (server host) that performs some processing on a computer (client host) that requests processing is referred to as a client-server system or a distributed system (hereinafter, this specification). The book is called a distributed system). According to such a distributed system, a process requested by a client host can be executed by a server host or the like other than the client host in accordance with the state of the network system and the processing content at that time.
[0003]
Conventional distributed systems are roughly classified into three types. Hereinafter, each will be described.
[0004]
The first form is a vertical distributed system represented by a mainframe. In a vertical distributed system, basically, a client host requests processing to a server host, the server host executes the processing, and the client host receives the processing result from the server.
[0005]
Such a vertical distributed system has the following problems.
[0006]
(1) When a client host is connected to a large number of server hosts, the overall processing throughput is reduced due to an overload on the server host.
[0007]
(2) Since communication via the network is performed every time processing is requested, network traffic increases.
[0008]
The second form is a horizontal distributed system. In a horizontal distributed system, required data is requested to a database management system (DMBS) or the like existing in a server host, and processing of information obtained from the request is performed by a client host. Thus, the problems (1) and (2) of the vertical distributed system can be overcome to some extent.
[0009]
However, this system has the following problems.
[0010]
(3) The client host requires some processing capacity and resources.
[0011]
(4) Since the client host and the database management system are closely related, the flexibility of the system for coping with changes in the database management system is low.
[0012]
(5) Application program management must be performed for each client host.
[0013]
The third mode is a distributed network system including a network computer (NC) having no secondary storage (HDD or the like) and a mobile network computer (MNC) for a mobile environment. In a distributed network system, a normal personal computer (PC) or a workstation (WS) can naturally be a terminal. In this distributed network system, when a client requests processing from a server, a server component that executes the processing is sent to the client host, and the processing is executed on the client host. Recent Java applets correspond to this.
[0014]
This system overcomes the problem (5) of the horizontal distributed system. However, the problem (3) is emphasized on the contrary. If the client host is a personal computer or a workstation having a high processing capacity, the network computer or the mobile network computer has a lower processing capacity as compared with those. In addition, there are also the following problems.
[0015]
(6) If the load on the server is low, executing the processing on the server side rather than executing the processing on the client side improves the overall throughput of the processing.
[0016]
In addition to these problems, the following three problems are common to the above three types of systems.
[0017]
(7) Since the structure of the software (the execution position of the processing component) is statically determined, it lacks flexibility in a dynamically changing network environment.
[0018]
(8) Since it is difficult to design a system (determining which processing is to be executed by which host) and lacks flexibility, a problem may occur even in a later change or addition of a new specification.
[0019]
In a load distribution system in a distributed environment or an agent system for a mobile environment, there is a conventional example in which processing components are dynamically moved / arranged on a network to improve the flexibility of the system. However, such a system also has the following problems.
[0020]
(9) When executed on the client host side, since the client component and the server component are usually separate components, communication between the components is necessary, and the overhead due to this is a problem.
[0021]
[Problems to be solved by the invention]
As described above, in a conventional distributed system, the execution place of a component that provides a specific process is statically determined by a developer of the system. Therefore, one component is always executed on the client host side, and another component is always executed on the server host side.
[0022]
Further, in the related art, it seems that the problem is reduced as the modes 1, 2, and 3 are advanced, but this is not always the case. In other words, in a network system, the computer environment changes dynamically, and the processing efficiency cannot be easily improved due to the dynamic change of the computer environment and the fixedness of the component execution location. It has become.
[0023]
Therefore, even if any of the above-described distributed systems is adopted, processing cannot always be performed in an ideal state due to dynamic changes in the environment, and the functions inherent in the system cannot be exhibited. For example, when a large number of clients connect to a server and the load on the server increases, even if the system is changed from a vertical system to a horizontal system or a distributed network system, the decentralization proceeds too much and the server becomes low. Executing some processing on the server side may increase the throughput of the entire processing.
[0024]
In order to improve the processing throughput while responding to such a dynamic change in the computer environment, it is desirable to create a mechanism that can dynamically change the execution position of the component that performs the processing.
[0025]
Also, in the development of various network systems in consideration of the scalability of the system, it is preferable that the execution position can be dynamically changed rather than statically determined.
[0026]
In order to dynamically determine the execution position of a process, it is necessary to previously install a program (in an executable form) on which the process is mounted on all the target computers. This makes it possible to select the execution position of the processing from these computers at the time of execution, and to cause the computer to execute the processing. Such a distributed system can be constructed for the purpose of fault tolerance and load distribution.
[0027]
However, installation and maintenance management of programs on all computers is very difficult and not practical.
[0028]
There is a so-called mobile agent that switches the execution position of the process after the execution of the process. In this method, processing is performed on designated computers on a distributed system while circulating through them. Specifically, the processing is performed by one computer, and after the processing is completed, the processing is moved to another computer, and the same processing is performed. Thereafter, this operation is repeated so as to be performed on all the designated computers. Such a distributed system is mainly used for purposes such as information collection and system monitoring.
[0029]
However, in a mobile agent, basically, a program related to processing is united, and all of the programs are moved (distributed) to a target computer and operated. Therefore, the mobile agent itself cannot have a structure that uses resources of a specific computer.
[0030]
Further, there is a system in which a processing program is distributed from a server host that provides the processing program to a client host that has requested the processing, and is executed on the client host side, like the Java applet described in the third embodiment. Thus, the processing program needs to be installed only in one place, and maintenance management and installation work of the processing program are facilitated.
[0031]
However, even in this system, the execution place of the process is statically determined, and the configuration of the distributed system (which computer in the distributed system executes the process) cannot be flexibly changed. Therefore, it cannot be used for purposes such as load distribution.
[0032]
Further, in each of the above-described conventional examples, basically, once executed, the location cannot be changed halfway except for the mobile agent. In the case of a mobile agent, the connection with the client that has requested the processing is normally disconnected until a series of movement-processing ends. That is, since the connection is not always made, it is difficult to give some instructions from the client side during the processing.
[0033]
The present invention has been made in consideration of such circumstances, and dynamically changes the execution position of a process requested by a client to a client side or a server side, and flexibly changes a system configuration. It is an object of the present invention to provide a distributed system capable of performing the above-mentioned operations.
[0034]
[Means for Solving the Problems]
In order to solve the above problems and achieve the object, the present invention uses the following means.
[0035]
(1) A distributed system according to the present invention is a distributed system comprising a client and a server,
The client includes an application basic part that issues a request for processing, and a component loader,
The server manages a server component that executes a process requested by the application basic part, and receives a request from the application basic part and executes a server component that executes the process on either the client or the server. An execution position determining unit that determines whether to perform the processing, and a server component that executes a process requested from the application basic part are obtained from the management unit, and the obtained server component is processed according to the determination result in the execution position determining unit. Server component delivery means, wherein the server component includes a server component main body that implements required processing, a client-side adapter that communicates with the server, and a server that communicates with the client. ; And a side adapter,
The server component delivery means,
Means for sending the server component body to the client component loader when it is determined to be executed on the client, and causing the component loader to generate an executable server component object from the server component body;
If it is determined to be executed on the server, it receives the client-side adapter and server component of the specified server component from the management means, generates an executable server component object from the server component, and generates an object for the server-side adapter. Means for sending a client-side adapter to the component loader of the client that issued the processing request, and causing the component loader to generate a stub object capable of executing the client-side adapter,
If it is determined to be executed on the client, make the client application basic part execute the process using the server component itself,
A distributed system that accesses the server component generated on the server host through the stub object and the server-side adapter and executes the process when the server application is determined to execute.
[0036]
According to this, the execution position of the process can be dynamically changed, and the system configuration can be flexibly changed.
[0039]
(2) The distributed system according to the present invention has the above (1)And the load information of the server and the client, the information on the processing capacity of the server and the client, the transfer rate of the network connecting the server and the client, or the size information of the server component Or, further comprising a network monitor means for acquiring at least one or more of the calculation amount information of the server component and providing the information to the execution position determination means, wherein the execution position determination means is provided from the network monitor means. The execution position of the server component is determined based on the obtained information.
[0040]
According to this, the execution position of the server component can be switched so that the processing result from the client can be obtained quickly, leading to an improvement in throughput.
[0041]
(4) The distributed system according to the present invention is the distributed system described in (2) above, wherein the server issues processing of the application basic part based on the user information of the client or the identification information of the application basic part. An access control monitoring unit that determines whether to accept the request is provided, and the execution position determination unit also determines whether to execute the server component based on a determination result of the access control monitoring unit. is there.
[0042]
According to this, it is possible to control access to the server component based on the client user information and the client host information.
[0043]
(5) A distributed system according to the present invention is the distributed system described in (2) above, wherein the server component is a server component main body that implements required processing and a client that communicates with the server. And a server-side adapter that communicates with the client, and a common interface that defines a common interface between the server component body and the client-side adapter.
[0044]
According to this, since only one server component body is required, the server component developer only needs to implement the same program once. Furthermore, since the server component main body and the client-side adapter implement a common interface, the client can access both of them uniformly. When the server component is executed on the client host side, no adapter is used for communication between the client host application basic part and the server component, so there is no overhead in processing requests.
[0045]
(6) The distributed system according to the present invention is the distributed system according to (5), wherein the server component includes a client resource access unit that accesses a client resource, and a server resource access unit that accesses a server resource. And a server resource access client-side adapter and a server resource access server-side adapter for communicating with the server resource access unit when the server component body is executed on the client side.
[0046]
As a result, it is possible to develop a processing component which can move the processing body and which can access resources on the client host and resources on the server host.
[0047]
(7) The distributed system according to the present invention is the distributed system according to (5), wherein the server component includes a client resource access unit that accesses a client resource, and a server resource access unit that accesses a server resource. When the server component body is executed on the client side, the server resource access client side adapter and the server resource access server side adapter for communicating with the server resource access unit, and the server component body is executed on the server side. In this case, the system further includes a client adapter for client resource access and a server adapter for client resource access for communicating with the client resource access unit.
[0048]
As a result, it is possible to develop a processing component which can move the processing body and which can access resources on the client host and resources on the server host. Further, processing can be concentrated on the server component main body, and development of the server component becomes easy.
[0049]
(8) A server component generation device according to the present invention includes: a client having an application basic part that issues a processing request; a management unit that manages a server component that executes a processing requested by the application basic part; Execution position determination means for determining whether to execute the server component that executes the process on the client or the server, and manages the server component that executes the process requested by the application basic part. And a server having a server component delivery unit that delivers the acquired server component to the client or the server in accordance with the result determined by the execution position determination unit. A server component generating apparatus for generating a server component, comprising: a template providing unit for providing a plurality of templates of the server component; an information providing unit for providing information on the server component; And a program generating means for generating a server component by applying the information to the program.
[0050]
(9) In the distributed system of the present invention, an execution position of a process requested by a client is determined by an arbitrary computer before execution, and a server component that executes the process from a management unit that manages a server component that executes the process. And a main server that transfers the obtained server component to the determined computer, receives the processing result from the determined computer, and transfers the processing result to the client.
[0051]
(10) The distributed system according to the present invention is the distributed system according to (9), wherein the main server determines an execution position once, and determines an execution position of a server component executed by the determined computer. Change to another computer.
[0052]
(11) A computer-readable recording medium for recording a program for controlling a distributed system comprising a client and a server according to the present invention, comprising: a management unit for managing a server component of a process requested by an application basic part of the client; An execution position determining unit that receives a request from a basic part and determines whether to execute the server component on the client or the server, and obtains the server component from the management unit; A computer-readable recording medium on which is recorded a program for executing a server component delivery unit for delivering to the client or the server in accordance with a result determined by the execution position determination unit.
[0053]
(12) A program for controlling a distributed system comprising a client and a server according to the present invention and capable of dynamically changing whether a process required by an application basic part on the client is executed by the client or the server is recorded. A computer-readable recording medium that executes a process required by an application basic part on the client in either a client or a server; and a server that executes the server component. This is a computer-readable recording medium on which a program for executing communication processing means for securing communication with a basic part is recorded.
[0054]
BEST MODE FOR CARRYING OUT THE INVENTION
Hereinafter, an embodiment of a distributed system according to the present invention will be described with reference to the drawings.
[0055]
(1st Embodiment)
FIG. 1 is a block diagram illustrating a hardware configuration example of the distributed system according to the first embodiment of the present invention.
[0056]
This distributed system is configured by connecting a client host 1 and a server host 2 via a network 3. The client host 1 refers to a host machine that has a client application program and issues a request for processing, and the server host 2 refers to a host machine that receives a request from a client and executes the processing. When there are a plurality of host machines, all host machines other than the client host can be server hosts. As the client host 1, a personal computer, a workstation, a network computer (NC) or a mobile network computer (MNC) is used, and as the server host 2, a personal computer, a workstation, a large computer (mainframe), or the like is used. Can be
[0057]
As the network 3, a high-speed LAN, a low-speed public line, a wireless LAN, or the like is used. Therefore, this network system is configured as LAN, WAN, VPN (virtual private network), the Internet, or the like. In this system, the client host 1 and the server host 2 do not need to be always connected.
[0058]
The server host 2 is connected to a storage device 4 composed of a hard disk (HDD) or the like, and the storage device 4 stores a server component 5 which is a number of processing programs and forms a kind of database. This database is also referred to as a component repository. The storage device 4 may be directly connected to the server host 2 by SCSI or the like as shown in FIG. 1, or may be connected to the server host 2 via another host on which a storage device management server is mounted. Is also good.
[0059]
Although the server component 5 will be described later, it is simply a process or a process group that executes a process requested by the client host 1. The main purpose of this embodiment is to automatically determine whether to execute the request processing part in the server component 5 on the server side or on the client side, and to further create a state in which the processing can be actually executed according to the determination. And
[0060]
Next, a system logical configuration (software resources) in this distributed system will be described.
[0061]
FIG. 2 is a diagram showing a software logical configuration in the distributed system of the present embodiment.
[0062]
In the figure, the left side from the center broken line shows the client host 1 side, and the right side shows the server host 2 side. Since the server component 5 can be executed by any of the host machines of the client host 1 and the server host 2, the server component 5 is arranged on the broken line as shown in FIG.
[0063]
The client host 1 is provided with a client application basic part 11, a component loader 12, a component cache 13, and a server component 5 determined to be executed by the client host 1.
[0064]
On the other hand, the server host 2 is provided with a component server 14, an execution position determining unit 15, a component manager 16, an access control monitoring unit 17, a network monitor 18, and a server component 5 determined to be executed by the server host 2. . The network monitor 18 may be provided in another host on the network system. In this case, the server host 2 obtains necessary information from the network monitor 18 via the network 3. The storage device 4 is connected to the component manager 16.
[0065]
The client application basic part 11 requests the server component 5 which is a processing process to the component server 14 via the component loader 12. The component server 14 determines whether to operate the requested server component 5 on the server host 2 or the client host 1.
[0066]
Before specifically describing the above-described units, a process requested by the client host 1 and how the server component 5 is configured to realize the process will be described.
[0067]
The client host 1 implements various processes according to the request of the user. In many cases, an application program is not composed of only a single process, but is composed of a plurality of processes. Therefore, this can be divided into the most basic part and the other processing parts.
[0068]
FIG. 3 is a diagram illustrating a configuration example of the application program according to the present embodiment.
[0069]
In the system of the present embodiment, the application program is divided into a client application basic part 11 and a server component 5 as shown in FIG. Note that there may be a plurality of server components 5.
[0070]
Here, the client application basic part 11 is the most basic part of the application program, and performs activation of the application program and minimum functions, issuance of requests for the server component 5, display of processing results using the server component 5, and the like. . Therefore, this basic part 11 is located on the client host 1 as shown in FIG. On the other hand, the server component 5 is a substantive part of the application program.
[0071]
FIG. 3B shows, as a specific example, a configuration when the application program is image processing software. In this example, the client application basic part 11 is an image processing application basic part 11a, and a smoothing processing component 5a is provided as the server component 5.
[0072]
In this embodiment, in order to avoid developing a processing process that operates on the client side and a processing process that operates on the server side twice, the developer of the server component only needs to implement the same processing logic once. It is configured so that it is good (that is, it does not distribute similar implementations at multiple locations). Also, in order for the client to be able to execute processing without depending on the execution position of the server component, the interface of the server component as viewed from the client side can be used when operating on the server side and when operating on the client side. (The method of accessing the server component, more specifically, the method name, the type and number of arguments, the type of return value; called signature) are matched. Further, when processing is performed on the server side, it is necessary to perform communication between distributed objects using some communication means between the server component and the client. Further, a server component that displays a GUI (basically always displays it on the client side) or accesses a database management system on the server side, that is, a server component that accesses a unique host resource is also conceivable. Further, there is a possibility that the communication with the application program on the client side is performed asynchronously.
[0073]
In order to fulfill such a request, the movable server component of the present invention is divided into several components.
[0074]
FIG. 4 is a diagram illustrating a configuration example of the server component 5 according to the first embodiment.
[0075]
As shown in the figure, the server component 5 includes a server component main body 21, a client-side adapter 22, and a server-side adapter 24. The client-side adapter 22 and the server-side adapter 24 are connected by distributed inter-object communication 23. The common interface 25 is mounted on the server component main body 21 and the client-side adapter 22 among them. The server-side adapter 24 may be provided with an interface. The storage device 4 of the server host 2 stores, as the server component 5, files corresponding to the above-described parts except the inter-distributed-object communication 23.
[0076]
Here, the server component main body 21 is a part that executes processing originally requested by the client application basic part 11, and is a substantial processing part in the application. That is, the process provided by the server component 5 is mounted on the server component main body 21. When the processing is executed on the client side, the main body 21 is sent to the client side, and after being made executable, the processing from the client side is accepted. In this case, since the component body 21 is directly called from the client side, there is no overhead through the adapter 22 and the like. On the other hand, when the processing is executed on the server side, the main body 21 and the server-side adapter 24 connected thereto are made executable on the server side. The client-side adapter 22 is sent to the client host 1. This client-side adapter 22 is made executable on the client side, and connects to the server-side adapter 24 to prepare for communication. The client host 1 causes the component main body 21 to execute processing through the client adapter 22 and the server-side adapter 24. That is, the adapters 22 and 24 are components that only relay processing calls using distributed inter-object communication. For this reason, only one server component main body 21 is required, and it is possible to avoid a double development of a processing process that operates on the client side and a processing process that operates on the server side.
[0077]
The definition of the common interface 25 defines an access method (method (function) name, type and number of arguments, return value) for causing the server component to execute processing. The client-side adapter 22 (stub for remote connection) is a stub for making a remote connection to the server component body 21. Although not otherwise specified below, a common interface 25 is always implemented in the server component main body 21 and the client-side adapter 22. Thereby, according to the access method determined by the common interface definition, the client application basic unit 11 accesses the server component body 21 or the client-side adapter 22 uniformly regardless of the access destination. Will be able to do it. Therefore, the client host can execute the processing without depending on the execution position of the server component.
[0078]
Any technique may be used for the distributed inter-object communication 23. For example, CORBA, Java RMI, PDO, or the like can be used. These implementation differences are absorbed by the adapters on both hosts. Thus, the present system can be implemented without depending on a specific inter-object communication technology. In addition, it is easy to deal with the case where the implementation of communication is changed.
[0079]
Each of the components shown in FIG. 4 is not always used, and the combination thereof is dynamically changed depending on whether the server component main body 21 is executed on the client host 1 or the server host 2. It is.
[0080]
FIG. 5 is a diagram showing a configuration when the server component body 21 is executed on the client host 1 and a case where the server component main body 21 is executed on the server host 2.
[0081]
FIG. 2A shows a case where the server component main body 21 is executed on the client host 1. In this case, the common interface 25 and the server component main body 21 are provided in the client host 1, and the client application basic part 11, the common interface 25 and the server component main body 21 constitute the server component 5. The client application basic part 11 issues a request to the server component main body 21 via the common interface 25.
[0082]
FIG. 2B shows a case where the server component main body 21 is executed on the server host 2. In this case, the client-side adapter 22, the server-side adapter 24, on which the common interface 25 is mounted, and the server component main body 21, on which the common interface 25 is mounted, constitute the server component 5. The client-side adapter 22 and the server-side adapter 24 are connected by the distributed object communication 23. The client application basic part 11 issues a request to the server component main body 21 provided in the server host 2 via each of the units 25, 22, 23, 24, 25.
[0083]
The initial state of the server component 5 initially stored in the storage device 4 and managed by the component manager 16 is as shown in FIG. Each element of the server component 5 in this initial state is taken out of the storage device 4 and configured as a processing execution function on the client host 1 and the server host 2 as shown in FIGS. 5 (a) and 5 (b). These are server components 5 as a whole. However, the components and the arrangement of the components in the hosts 1 and 2 differ depending on the situation.
[0084]
Each of the units 12, 13, 14, 15, 16, 17, 18, and 4 shown in FIG. 2 is an execution position of the server component 5 which can be dynamically changed as shown in FIG. The position of the main body 21 is determined, and a process for creating one of the states shown in FIGS. 5A and 5B is performed. The component cache 13 is originally included in the component loader 12, and the execution position determining unit 15 and the access control monitoring unit 17 are originally included in the component server 14. However, for the sake of explanation of the operation later, these components are independent in FIG. It is shown as a means. Hereinafter, these configurations will be described.
[0085]
FIG. 6 is a diagram illustrating a configuration example of the component loader 12.
[0086]
The component loader 12 receives the server component main body 21 or the client-side adapter 22 (stub for remote connection) for connecting to the server component main body 21 in response to a request from the client application basic part 11 for the server component 5. Unless otherwise specified below, it is assumed that the common interface 25 is mounted on the server component main body 21 or the client-side adapter 22 or has already been mounted.
[0087]
The component loader 12 is provided with an instance generation unit 31, a component decryption unit 32, a component decompression unit 33, and a component cache 13 to realize the function. The component cache 13 is the same as that shown in FIG.
[0088]
The component cache 13 temporarily stores the server component 5 downloaded from the component server 14 to the client host 1, and is used for preventing double loading.
[0089]
FIG. 7 is a diagram illustrating a configuration example of the component server 14.
[0090]
The component server 14 determines the execution position of the server component 5 requested by the component loader 12 by the execution position determination unit 15, and prepares the server component main body 21 or the client-side adapter 22 or the like corresponding thereto, Return to the component loader 12. When executing the server component main body 21 on the server host 2 side, the server component main body 21 and the like required on the server host 2 are generated.
[0091]
The component server 14 includes an execution position determining unit 15, an instance generating unit 36, an access control monitoring unit 17, a component encrypting unit 37, and a component compressing unit 38 in order to realize the functions. The execution position determining unit 15 and the access control monitoring unit 17 are the same as those shown in FIG.
[0092]
The execution position determining unit 15 determines which host side of the client / server should operate the server component 5 based on both host information of the client / server, information on network connection, and information of the requested server component 5 Judge.
[0093]
The access control unit 17 is also referred to as a user authentication unit, and checks whether or not the current client host 1 (or its user) can use the server component 5 with respect to the requested server component 5.
[0094]
FIG. 8 is a diagram illustrating a configuration example of the component manager 16.
[0095]
The component manager 16 is configured to be accessible to the storage device 4 and manages the server component 5 and its information. More specifically, the registration / deletion and search of the server component 5 are performed.
[0096]
The component manager 16 is provided with a component extraction unit 41, a component information extraction unit 42, and a component registration management unit 43 in order to realize the function.
[0097]
The network monitor 18 calculates the load information of the server host 2 and the client host 1, the information on the processing capacity of the server host 2 and the client host 1, the transfer speed of the network, or the size information of the server component body 21, or the calculation of the server component body 21. The amount information is obtained and provided to the execution position determination unit 15.
[0098]
Next, an operation of the distributed system configured as described above according to the embodiment of the present invention will be described.
[0099]
(System start-up)
In this distributed system, there is no particular limitation on how to start the client application basic part 11 in the client host 1. For example, when the client host 1 is started, the client application basic part 11 may already exist on the client host 1, or may not exist at first, and may be downloaded from the server host 2 at the request of the user of the client host 1. It may be started as a program. Hereinafter, in the present embodiment, description will be made on the assumption that the client application basic part 11 already exists in the client host 1 and has been activated as an application program.
[0100]
Here, an image processing application program will be described as an example as shown in FIG. It is assumed that the image processing application program is divided into two parts, an image processing application basic part 11a and a smoothing processing component 5a as shown in FIG.
[0101]
The image processing application basic part 11a calls up / displays the image display and smoothing processing component 5a. The smoothing component 5a performs smoothing based on the given image data and parameters.
[0102]
Next, how the server component 5 is called in the software configuration of FIG. 2 will be described with reference to FIGS. 9, 10 and 11, and the flow of the processing will be described with reference to FIGS.
[0103]
FIG. 9 shows the processing from the processing request to the server component 5 to the determination of the execution position.
[0104]
FIG. 10 shows processing from execution position determination to execution when the server component 5 is executed on the client host 1 side.
[0105]
FIG. 11 shows processing from execution position determination to execution when the server component 5 is executed on the server host 2 side.
[0106]
FIG. 12 is a flowchart showing the entire processing from the processing request to the server component 5 to the execution of the processing.
[0107]
FIG. 13 is a flowchart showing a process for remotely using the server body 21 in FIG.
[0108]
FIG. 14 is a flowchart showing the process of receiving the component by the component loader 12 in FIG.
[0109]
FIG. 15 is a flowchart showing a process for using a component existing in the component cache 13 in FIG.
[0110]
(From server component request to execution position determination)
This processing will be described with reference to FIGS.
[0111]
(1) The user of the client application program orders execution of the processing provided by the desired server component 5 through the client application basic part 11 (signal a in FIG. 9).
[0112]
(2) The client application basic part 11 issues a request for the specified server component 5 to the component loader 12 (signal b in FIG. 9, step ST1 in FIG. 12).
[0113]
(3) The component loader 12 checks whether the requested server component 5 has already been loaded into the component cache 13 (signal c in FIG. 9, step ST2 in FIG. 12). It communicates with the component server 14 existing in the server host 2 of the server, and makes a request for the designated server component 5 (signal d in FIG. 9, step ST3 in FIG. 12). At this time, it generates information (client host information) such as the load average, the remaining memory capacity, and the possibility of swapping of the client host 1, and notifies the component server 14 (signal d 'in FIG. 9). The case where the server component 5 has already been loaded will be described later (step ST10 in FIG. 12, FIG. 15).
[0114]
(4) The component server 5 collects information on the server host 2 (server host information) and information on the connected network from the network monitor 18 (signal e in FIG. 9). The network monitor 18 collects information on the network by examining network information at that time based on, for example, the amount of use of the line, traffic, and the like, and device performance such as the line speed determined by the ID of the network card. The information may be set in advance by a system administrator.
[0115]
The component server 5 notifies the execution position determination unit 15 of the collected network information and inquires which host of the client / server should execute the specified server component 5 (signal f in FIG. 9). .
[0116]
(5) The execution position determination unit 15 first determines whether the client host 1 (or the user) who has requested the server component 5 specified by the access control monitoring unit 17 can use the server component 5 or not. It is checked whether there is a restriction or the like (signal g in FIG. 9). The access control monitoring unit 17 notifies the component server 14 when execution on the client side or the server side is forcibly restricted due to use restrictions. In this case, since the client host 1 (or its user) does not have the use qualification of the server component 5, the following processing is not performed.
[0117]
(6) Next, when the server component 5 is available, the execution position determination unit 15 adds the information on the server component 5 specified by the component manager 16 in addition to the information of both hosts and the network information passed from the component server 14 ( Server component information) is obtained, and based on these information, it is determined which host of the client / server the designated server component 5 should operate (signal h in FIG. 9, step ST4 in FIG. 12). Various algorithms can be considered as the determination algorithm, examples of which will be described later. Thereafter, the determined execution position is notified to the component server 14 (signal i in FIG. 9, step ST5 in FIG. 12).
[0118]
The above processing will be described below in conformity with the example of the image processing application program. First, the user instructs the image processing application basic part 11a to perform a smoothing process while the image processing application basic part 11a is displaying an image. Then, the image processing application basic part 11a requests the component loader 12 for the smoothing processing component 5a. After obtaining the client host information, the component loader 12 requests the component server 14 for the component 5a for smoothing processing. The component server 14 collects server host information and network information, and inquires of the execution position determination unit 15 about the execution position of the smoothing processing component 5a. After obtaining the component information of the smoothing processing component 5 a from the component manager 16, the execution position determination unit 15 determines an execution position based on each piece of information and notifies the component server 14.
[0119]
Next, an execution position determination algorithm in the execution position determination unit 15 will be described.
[0120]
When the purpose is to improve the throughput, the determination is made using information on both the client and server hosts, the transfer rate of the network, and information on the server components. That is, when the server component main body 21 is executed on the client host 1 and when the server component main body 21 is executed on the server host 2, the processing time considered necessary is calculated (estimated), and the processing time is reduced. It is determined that the server component body 21 is to be executed.
[0121]
In the example of the image processing application program, assuming that the data size (transfer amount) of the image data to be smoothed is passed from the user request, for example, the expected processing time is calculated by the following formula.
[0122]
T = hpt (hw, cp, cc) + hst (hm, cs, ds, hsc) + ntt (ds, ts) (1)
T is a predicted processing time, a function hpt is a function that returns a processing time obtained from the current load hw and calculation capacity cp of the host, and a calculation amount cc of the server component. A function ntt that returns the time required for the occurrence of a swap calculated from the size ds and the cost hsc required for the swap, the function ntt is the processing data size (when executed on the server host side; when the return value is also the same size) This function returns the time required for transfer calculated from ds and the transfer speed ts of the network (due to double the size) or the component size (when executed on the client side). The case where the above T is executed by both hosts is calculated, and the process is executed with the smaller value.
[0123]
Other determination methods include determining the execution position based on the amount of data transferred so as to minimize the charge in a pay-as-you-go network, and under certain conditions from the will of the component developer and the necessity of the client host environment. It is possible to make a determination such as executing at a fixed position. Of course, in order to improve the throughput, the calculation may be performed using other values.
[0124]
(Process when it is decided to execute on the client side)
Next, a series of processing when it is determined that the server component 5 is operated on the client host 1 side will be described with reference to FIGS. 10, 12, and 14.
[0125]
(1) The component server 14 that has received the determination notification (signal i in FIG. 9) from the execution position determination unit 15 stores the server component body 21 (executable object data) specified by the component manager 16 in the storage device 4. (Signal j in FIG. 10).
[0126]
(2) The component server 14 sends the server component body 21 as the server component 5 to the component loader 12 that has issued the request from the server host 2 (signal k in FIG. 10, step ST6 in FIG. 12).
[0127]
(3) The component loader 12 on the client host 1 generates an executable server component object from the obtained server component main body 21 (signal 1 in FIG. 10, step ST7 in FIG. 12, step ST12 in FIG. 14), The pointer is passed to the client application basic part 11 (signal m in FIG. 10, step ST7 in FIG. 12, step ST13 in FIG. 14). This allows the client application basic part 11 to cause the server component body 21 to execute the processing. The server component main body 21 has a common interface 25 mounted thereon. Further, in order to prevent double loading of the same server component, the component loader 12 stores the received server component 5 in the component cache 13 at the same time as receiving the same (signal n in FIG. 10, step ST7 in FIG. 12, FIG. 14 Step ST11).
[0128]
(4) The client application basic part 11 executes the process specified by the user using the passed server component body 21 (signal o in FIG. 10, step ST8 in FIG. 12).
[0129]
The above processing will be described below in conformity with the example of the image processing application program.
[0130]
First, the component server 14 receives the byte sequence of the main body of the smoothing component 5 a from the storage device 4 via the component manager 16 and sends it to the component loader 12. The component loader 12 generates an executable object (server component 21) based on the received byte sequence, and passes the pointer to the image processing application basic unit 11a. The image processing application basic unit 11a performs the smoothing process by calling the smoothing method of the received object of the smoothing component 5a.
[0131]
(Process when it is decided to execute on the server side)
Next, a series of processes when it is determined that the server component 5 is operated on the server host 2 side will be described with reference to FIGS. 11 and 12 and FIGS.
[0132]
(1) The component server 14 that has received the determination notification (signal i in FIG. 9) from the execution position determination unit 15 transmits the client-side adapter 22 (remote connection stub) of the server component 5 specified by the component manager 16 to the server. The component main body 21 and the like are received (signal p in FIG. 11).
[0133]
(2) The component server 14 generates an executable server component object from the server component main body 21 on the server host 2 (signal q in FIG. 11, step ST9 in FIG. 12, step ST21 in FIG. 13).
[0134]
(3) The component server 14 makes preparations according to the distributed inter-object communication technology (Java, CORVA, etc.) (signal r in FIG. 11, step ST9 in FIG. 12, step ST22 in FIG. 13). For this purpose, an object for the server-side adapter 24 is generated, and processing for enabling communication between distributed objects is performed.
[0135]
(4) Next, the component server 14 sends the client-side adapter 22 as the server component 5 to the component loader 12 that issued the request from the server host 2 (signal s in FIG. 11, step ST9 in FIG. 12, step in FIG. 13). ST23). Further, in order to prevent double loading, the component loader 12 of the client host 1 stores the server component 5 in the component cache 13 at the same time as receiving it (signal t in FIG. 11, step ST7 in FIG. 12, step ST11 in FIG. 14). .
[0136]
(5) The component loader 12 generates a stub object that can execute the received client-side adapter 22 (signal u in FIG. 11, step ST7 in FIG. 12, step ST12 in FIG. 14).
[0137]
(6) The component loader 12 transfers the generated stub object pointer to the client application basic part 11 (signal v in FIG. 11, step ST7 in FIG. 12, step ST13 in FIG. 14).
[0138]
(7) In this way, the client application basic part 11 accesses the remote server component main body 21 generated on the server host 2 through the stub object which is the client-side adapter 22, and executes the processing (signal in FIG. 11). w, step ST8 in FIG. 12).
[0139]
The above processing will be described below in conformity with the example of the image processing application program.
[0140]
First, the component server 14 receives the stub 22 of the component for smoothing processing and the byte string of the main body 21 from the component manager 16. Objects 21 and 25 are generated from the main body 21 that performs the smoothing process on the server host side, and are registered as server objects using existing distributed inter-object communication technology so that remote calls can be accepted. The stub 22 is sent to the component loader 12 as it is. The component loader 12 generates objects 22 and 25 from the received stub 22. The generated stub objects 22 and 25 connect with the main bodies 21 and 25 on the server host at the stage of their generation / initialization. The generated stubs 22 and 25 are passed to the image processing application basic part 11a. The image processing application basic part 11a accesses the remote object 5a (21, 25) for performing the smoothing processing via the stubs 22 and 25 and performs the processing.
[0141]
(Process when there is a server component in the component cache)
Once the server component main body 21 or the client-side adapter 22 is generated on the client host 1 side, the object is repeatedly executed until the client process ends or the object loaded from the server host 2 is discarded. It is possible to reuse. That is, this is the case where the process proceeds to step ST10 in step ST2 of FIG. In this case, it is not necessary to reload the server component 5 from the server host 2 every time the processing is performed.
[0142]
Specifically, the following procedure is performed.
[0143]
(1) The client application basic part 11 sends a request for the server component 5 to the component loader 12 (signal b in FIG. 9, step ST1 in FIG. 12).
[0144]
(2) The component loader 12 inquires of the component cache 13 whether the specified server component 5 has already been loaded (signal c in FIG. 9, steps ST2 and ST10 in FIG. 12, and step ST31 in FIG. 15).
[0145]
(3) If it has already been loaded, an object is generated based on the information (signal l in FIG. 10 or signal u in FIG. 11, step ST10 in FIG. 12, step ST32 in FIG. 15), and the client application basic part 11 (signal m in FIG. 10 or signal v in FIG. 11, step ST10 in FIG. 12, step ST33 in FIG. 15).
[0146]
(4) The client application basic part 11 performs a desired process using the returned object (signal o in FIG. 10 or signal w in FIG. 11, step ST8 in FIG. 12).
[0147]
As described above, the distributed system according to the first embodiment of the present invention includes a server component main body 21 that executes a process requested by the client application basic part 11, and a client side connected to each other through the distributed inter-object communication 23. A server component 5 comprising an adapter 22 and a server-side adapter 24 is provided, and in response to a request from the client application basic part 11, the execution position determining unit 15 determines which host of the client / server processes the server component body 21. Then, the processing by the server component main body 21 is executed on the host according to the determination result, so that the execution place of the processing can be dynamically switched, and the flexibility of the system can be improved. .
[0148]
Further, the execution position determination unit 15 determines the execution position based on information such as hardware and network status from the network monitor 18, so that the processing result can be obtained quickly in response to a processing request from the client host 1. The execution position of the component 5 can be switched. Thereby, throughput can be improved.
[0149]
Further, an access control monitoring unit 17 is provided, which can determine whether or not the client application basic part 11 that makes a request has a request authority based on the user information and the client host information of the client. Access can be controlled.
[0150]
Further, since the implementation of the required processing is performed only on the server component main body 21, that is, in one place, the server component developer does not need to duplicate the same implementation. That is, in constructing a dynamic change system for request processing, it is possible to eliminate the need to develop programs separately for server host side execution and client host side execution.
[0151]
In addition, since the server component main body 21 and the client-side adapter 24 have a common interface 25 mounted thereon, the client host 1 can uniformly access both of them. Therefore, the program (process) configuration can be simplified, and the speed can be increased accordingly.
[0152]
Furthermore, when the server component main body 21 is executed on the client host side, an adapter for communication between the client application basic part 11 and the server component main body 21 is not required, so that overhead in processing requests can be eliminated.
[0153]
In the present embodiment, the case where there is one client host 1 and one server host 2 has been described as an example. However, load distribution is performed in a cluster on the server side, that is, in a multi-server environment where a plurality of server hosts exist in a network. In practice, by using a virtual system or the like for performing centralized management or the like, a plurality of hosts can be actually targeted for execution positions.
[0154]
Here, what is called a server host indicates a host other than the client host. That is, in the case of the present embodiment, the host that issues the processing request and has the client application basic part 11 is the client host 1, and the host that executes the processing other than the client host is called the server host 2. Therefore, a client host generally called a terminal does not always correspond to the client host of the present embodiment.
[0155]
In the present embodiment, the case where the execution position is automatically determined has been described. However, by setting the execution position in advance, the execution position of the server component body 21 can be manually set in effect. it can. Further, both of them can be mixed.
[0156]
In addition, the above-mentioned respective effects are similarly exerted in the following embodiments or each embodiment with respect to a portion where the functional configuration is duplicated.
[0157]
(2nd Embodiment)
This embodiment is an improvement on the configuration of the server component 5 in the first embodiment, and the other parts are the same as those in the first embodiment. Therefore, the same parts as those in FIGS. 1 to 15 are denoted by the same reference numerals, and detailed description thereof will be omitted.
[0158]
That is, the server component 5 of the first embodiment shown in FIG. 4 is a basic configuration for realizing the invention. However, depending on such a basic component configuration, a function required by the server component main body 21 required in some cases may not be realized. What cannot be realized in the first embodiment are components that access host resources and components that communicate asynchronously with client-side application programs (communicate from components to client-side application programs).
[0159]
There are the following two server components 5 for accessing host resources. One is a server component that accesses resources (such as a screen display (GUI) or a local file system) of a client host, and the other is a server host 2 or a resource (a file system or a server side) existing in the back thereof. Database component).
[0160]
For example, if the server component 5 displays a GUI, the GUI must be displayed on the client host 1 regardless of whether the server component body 21 is on the server host 2 or the client host 1. In order to solve such a problem, the part for accessing the client resource must be moved to the client host 1 regardless of the position of the server component body 21.
[0161]
Further, for example, if the server component 5 is connected to the database management system on the server host 2 side, even if the server component main body 21 is sent to the client host 1, the part exchanged with the database management system is the server. It must remain in the host 2 and be able to interact with the database management system.
[0162]
Considering such conditions, the server component main body in the above case is composed of the original function execution part (the server component main body 21 of the first embodiment) and the part that accesses the client resources and / or the server (or subsequent). It must be divided into a part that accesses resources and a part that accesses resources. In consideration of this point, in the present embodiment, the server component 5 is configured as shown in FIG.
[0163]
FIG. 16 is a diagram illustrating a configuration example of the server component 5 according to the second embodiment of the present invention.
[0164]
This server component 5 has a client resource corresponding unit 51 and a server resource corresponding unit 52 in addition to the configuration shown in FIG.
[0165]
Here, the client resource corresponding unit 51 includes a client resource access unit 53. On the other hand, the server resource corresponding unit 52 includes a client adapter 54 for server resource access, a server adapter 56 for server resource access, and a server resource access unit 57, and the client adapter 54 for server resource access and the server resource access The server-side adapter 56 is connected via the distributed inter-object communication 55. Note that a server resource access unit common interface 58 is mounted on the server resource access client-side adapter 54 and the server resource access unit 57.
[0166]
The client resource access unit 53 performs a process for accessing resources of the client host 1. The server resource access unit 57 performs a process for accessing resources of the server host 2. The client adapter 54 for server resource access and the server adapter 56 for server resource access are adapters for performing the communication 55 between distributed objects.
[0167]
As described above, in the second embodiment, the server component body 5 is divided into three parts: a part that accesses client resources (including asynchronous communication to a client application); and a part that accesses server resources. ing.
[0168]
In the present embodiment, the server components 5 stored in the storage device 4 are as shown in FIG. 16, but the processes shown in FIG. 2 are the same as those in the first embodiment. Each unit shown in FIG. 2 executes the server component main body 21 on either the client host side or the server host side, and moves a portion newly added to the server component 5 in this embodiment and generates a corresponding object. Only in that it is required.
[0169]
Next, an operation of the distributed system configured as described above according to the embodiment of the present invention will be described.
[0170]
(When processing on the server side)
FIG. 17 is a diagram showing the configuration of the server component 5 when the server component body 21 is operated on the server host 2 side.
[0171]
When the server component body 21 is operated on the server host 2 side, the client side adapter 22 and the client resource access unit 57 are sent to the client host 1 side by the component server 14. After being instantiated by the component loader 12 on the client host 1 side, the client resource access unit 57 is passed by reference (passing of a pointer) from the component loader 12 to the server component body 21.
[0172]
On the server host 2 side, the server component main body 21 directly holds the server resource access unit 57 and performs exchange.
[0173]
Note that the client-side adapter 22 may directly exchange with the client resource access unit 53 in consideration of performance.
[0174]
(When processing on the client side)
FIG. 18 is a diagram showing a configuration of the server component when the server component main body is operated on the client host 1 side.
[0175]
Next, when the server component main body 21 is operated on the client host 1 side, the server component main body 21, the client resource access unit 53, and the server resource access client side adapter 54 are transmitted to the client host 1 side by the component server 14. Can be
[0176]
At this time, the server component main body 21 generated on the client host 1 side has the client resource directly. Further, the server resource access unit 57 needs to remain on the server host 2 side. Therefore, in order to perform the communication 55 between the distributed objects between the server component main body 21 and the server resource access unit 57, a structure similar to the configuration of the server component 5 in the case of FIG. 5B is provided. That is, as shown in FIG. 18, adapters 54 and 56 for server resource access are prepared and used in the host on the server side / client side.
[0177]
From the viewpoint of the server component main body 21, the client-side adapter 54 for server resource access and the server resource access unit 57 should be able to access in a uniform procedure, so that each implements a common interface 58 for server resource access. The server component 5 holds these elements as a type of a common interface for server resource access.
[0178]
Similarly, the client resource access unit 53 holds these as a common interface type so that the server component main body 21 and the client-side adapter 22 can be uniformly accessed.
[0179]
These ownership relationships are realized by initialization when each component is made executable by the component loader 12 and the server component 14. Thus, the server component 5 that can access the resources of the hosts 1 and 2 is realized by the configuration illustrated in FIG. 17 or FIG.
[0180]
As described above, in the distributed system according to the second embodiment of the present invention, in addition to the same configuration as the first embodiment, the server component 5 includes a client resource access unit 53, a server resource access client-side adapter 54, A communication 55 between distributed objects, a server-side adapter 56 for server resource access, and a server resource access unit 57 are provided so that the client / server resources can be accessed even when the server component body 21 is located on the host on either side of the client / server. As a result, the same effect as that of the first embodiment can be obtained. In addition to the processing in the form requested by the application basic part 11, execution cannot be performed unless client / server resources such as GUI and database access are accessed. Processing can also be realized by the server component 5.
[0181]
In the above-described configuration, various techniques can be applied to the communication between distributed objects. When Java and RMI are used, the object serving as a server for distributed inter-object communication is Java. rmi. It is necessary to inherit Remote.
[0182]
Further, the client resource corresponding unit 51 and the server resource corresponding unit 52 shown in the present embodiment may be added to the basic part only when necessary for the component. If these are unnecessary, they can be omitted.
[0183]
(Third embodiment)
This embodiment is an improvement on the configuration of the server component 5 in the second embodiment, and the other parts are the same as in the second embodiment. Therefore, the same portions as those in FIGS. 1 to 18 are denoted by the same reference numerals, and detailed description thereof will be omitted.
[0184]
According to the second embodiment, a server component that accesses the resources of the respective hosts 1 and 2 can be realized. However, in order to achieve this, it is necessary to be able to pass by reference (pass a pointer) from the client host 1 to the server host 2. In a distributed environment where reference passing is not possible, another means (component configuration) must be considered. Otherwise, in the case of FIG. 17, a message cannot be sent from the server component main body 21 to the client resource access unit 53, and the types of achievable processing are limited.
[0185]
In the present embodiment, the configuration of the server component 5 is improved in consideration of such circumstances.
[0186]
FIG. 19 is a diagram illustrating a configuration example of the server component 5 according to the third embodiment of the present invention.
[0187]
This server component 5 is configured similarly to the server component 5 of the second embodiment shown in FIG. 16 except that the configuration of the client resource corresponding unit 51 is changed.
[0188]
Here, the client resource corresponding unit 51 includes a client resource access unit 53 similar to the second embodiment, a client resource access client-side adapter 61, and a client resource access server-side adapter 63. The client-side adapter 61 and the server-side adapter 63 are connected by distributed inter-object communication 62. Note that a client resource access unit common interface 64 is implemented in the client resource access server-side adapter 63 and the client resource access unit 53.
[0189]
The client resource access unit 53 performs a process for accessing a resource of the client host 1 as in the second embodiment. The client adapter 61 for client resource access and the server adapter 63 for client resource access are adapters for performing the communication 62 between distributed objects.
[0190]
Next, the operation of the distributed system configured as described above according to the third embodiment of the present invention will be described.
[0191]
FIG. 20 is a diagram showing a configuration of a server component when the server component main body is operated on the server host 2 side.
[0192]
The procedure for generating such a server component configuration is the same as in the first and second embodiments. However, in the case of the present embodiment, reference passing from the client resource access unit 53 to the server component main body 21 is not performed.
[0193]
That is, the client resource access unit 53 is related only to the server component main body 21 via the distributed ring object communication 62 via the adapters 61 and 63. Therefore, even if the reference cannot be passed from the client resource access unit 53 to the server component main body 21, communication between them is realized.
[0194]
Further, when the server component body 21 is operated on the client host 1 side, the problem of reference passing between the hosts 1 and 2 does not occur. Therefore, the configuration of the server component 5 is the same as the case of FIG. 18 in the second embodiment.
[0195]
As described above, in the distributed system according to the third embodiment of the present invention, in addition to the configuration similar to that of the first embodiment, a client adapter 61 for client resource access, a communication between distributed objects 62, and a server for client resource access are provided. Since the side adapter 63 is provided, the same effect as that of the first embodiment can be obtained. In addition, when the server component main body 21 is on the server host 2 side, even if reference passing is not possible in the distributed object communication 62. The communication between the server component body 21 and the client access resource unit 53 can be performed, and the client resource can be accessed. Therefore, the application range of the system using the server component 5 is further improved.
[0196]
With such a configuration, the processing to be provided in the client resource access unit 53 when the reference cannot be passed can be concentrated on the server component main body 21, so that the server component 5 can be more easily developed. improves.
[0197]
(Fourth embodiment)
FIG. 21A shows an example in which the basic server component 5 shown in FIG. 4 is applied to an image processing application program as shown in FIG. In this example, a virtual language J is used as a programming language, and communication uses a virtual distributed object technology JRMI.
[0198]
(Fifth embodiment)
FIG. 21B shows an example in which the present invention is applied not only to an image processing application program but also to a general application program. Unlike the fourth embodiment, Java is used as a programming language, and communication is performed by a communication technology between distributed objects Java.
RMI is used.
[0199]
(Sixth embodiment)
FIG. 21C corresponds to the server component 5 (enabling resource access to the server / client) of the second embodiment shown in FIG. In this example, Java is used as a programming language, and communication uses a distributed inter-object communication technology Java RMI.
[0200]
(Seventh embodiment)
In the above embodiments, the distributed system capable of dynamically changing the execution position of the server component body 21 between the client host 1 and the server host 2 using the server component 5 and the configuration of the server component 5 used in the system I have explained. However, when a software developer creates the server component 5, it is necessary to develop many components (files).
[0201]
In the present embodiment, a technique for reducing the burden on the developer by automatically generating each file of the server component 5 will be described. Here, the server component 5 to be generated will be described taking the fifth embodiment shown in FIG. 21B as an example. In this embodiment, the same reference numerals are given to the same components as those in the respective drawings of the above embodiments, and the description will be omitted.
[0202]
In the case of FIG. 21B, five class files of the common interface 25, the client-side adapter 22, the server-side adapter 24, the server component body 21, and the RMI interface 24a are created as the components of the server component 5, and the storage device 4 must be registered.
[0203]
FIG. 22 is a block diagram illustrating a configuration example of a server component automatic generation system according to the seventh embodiment of the present invention.
[0204]
In this server component automatic generation system, an information providing unit 72, a template providing unit 73, a class file automatic generating unit 74, a class file unit 75, a main processing content creating unit 76, and a main processing content providing unit 77 are added to a development computer 71. It is provided and configured.
[0205]
The information providing unit 72 stores various pieces of information about the server component 5 such as a class name and a method name, and inputs the information to the class file automatic generation unit 24.
[0206]
The template providing unit 73 holds templates corresponding to, for example, five classes / interfaces of the common interface 25, the client-side adapter 22, the server-side adapter 24, the server component main body 21, and the RMI interface 24a shown in FIGS. The template is provided to the class file automatic generation unit 24. FIGS. 23 to 27 show examples of classes / interfaces created based on the template.
[0207]
FIG. 23 is a diagram illustrating an example of a common interface based on Java in the present embodiment.
[0208]
FIG. 24 is a diagram illustrating an example of the server component main body 21 based on Java in the present embodiment.
[0209]
FIG. 25 is a diagram illustrating an example of a server-side adapter class based on Java in the present embodiment.
[0210]
FIG. 26 is a diagram illustrating an example of an RMI interface of a server-side adapter class in Java according to the present embodiment.
[0211]
FIG. 27 is a diagram illustrating an example of a client-side adapter based on Java in the present embodiment.
[0212]
The class file automatic generation unit 74 generates each of the above five class files based on the information provided from the information providing unit 72 and the template providing unit 73 and outputs it to the class file unit 75. At this point, the substantive processing contents (processing logic) of the server component body 21 are not implemented in the class file output at this time.
[0213]
The main processing content creation unit 76 is a processing unit for generating the actual processing content, that is, the main processing content.
[0214]
The main processing content providing unit 77 implements the main processing content created by the main processing content creating unit 76 in the class file of the class file unit 75 corresponding to the server component main unit 21.
[0215]
Further, a registration unit (not shown) registers each class file thus created as a component of the server component 5 in the storage device 4.
[0216]
Next, an operation of the server component automatic generation system according to the embodiment of the present invention configured as described above will be described.
[0217]
First, the conceptual operation of the present embodiment will be described with reference to FIG. 22 and FIGS.
[0218]
Since the other classes / interfaces simply relay the method calls except for the main processing contents of the server component main body 21, the classes / interfaces other than the server component main body 21 are automatically set as follows. Can be generated.
[0219]
The class name can be automatically determined from the class name of the server component main body 21 according to a predetermined naming convention.
[0220]
Since the adapters 22 and 23 basically relay only the method, the client-side adapter 22 calls the method of the server-side adapter 23 and the server-side adapter 23 calls the method of the server component body 21. To do. The point to note here is about the return value. For methods declared other than void, it is necessary to define so that the result of the relay method is returned. It is not necessary to return anything for a method declared void.
[0221]
Note that one server component 5 can provide a plurality of methods.
[0222]
As described above, the information about the class name and the method of the server component main body 21 of the server component 5 is given from the information providing unit 72, and the information is added to each of the lists L-1 to L-5 shown in FIGS. By providing each corresponding template from the template providing unit 73, the class file automatic generation unit 74 can automatically generate all the five classes.
[0223]
FIG. 22 also illustrates this concept graphically. For example, in the examples shown in FIGS. 23 to 27, the class name is Foo, the method is one, the method name is fooMethod, the argument type is char, the argument name is c, and the return value type is int.
[0224]
However, the content of the main processing, which is the original processing logic, is naturally coded by the developer. For this reason, the development computer 71 is provided with a main processing content creation unit 76. Further, the main processing content created by the main processing content providing unit 77 is implemented in the class file of the server component main body 21.
[0225]
Finally, everything created above is registered in the component manager 16 (storage device 4 in terms of hardware). At this time, component information, information for access control, and the like are also registered as necessary.
[0226]
Next, the automatic generation of each element of the server component 5 when Java is used will be described more specifically with reference to a flowchart.
[0227]
The lists in FIGS. 23 to 27 are results obtained through the automatic generation device of the present invention, and the lists in FIGS. 28 and 29 are lists called templates. The lists of FIGS. 23 to 27 are generated by inputting conditions such as the class name Foo and the method name fooMethod to the automatic generation device of the present invention, and embedding them in the templates of FIGS. 28 and 29.
[0228]
FIG. 28 shows lists LC-1 (class definition of component body), LC-2 (method definition of component body), LC-3 (interface definition of common interface), and LC-4 corresponding to templates provided by the template providing unit. (Method definition of common interface), LC-5 (class definition of server-side adapter), LC-6 (method definition of server-side adapter when return type is non-void), LC-7 (return value type) FIG. 21 is a diagram illustrating a method definition of a server-side adapter when is void.
[0229]
FIG. 29 shows lists LC-8 (interface definition of the RMI interface of the server-side adapter), LC-9 (method definition of the RMI interface of the server-side adapter), and LC-10 (client side) corresponding to the template provided by the template providing unit. Adapter class definition), LC-11 (method definition of client-side adapter when return type is non-void), LC-12 (method definition of client-side adapter when return type is void) FIG.
[0230]
When the server component 5 is generated, first, the information providing unit 72 provides the following information to the class file automatic generation unit 74.
[0231]
-Server component name
・ Method name
・ Return value type
-Argument type and argument name
Further, the class file automatic generation unit 74 calls a template corresponding to a target file creation from templates (also referred to as skeletons) of each class / interface shown in FIGS. 28 and 29. Further, the information from the information providing unit 72 replaces the information in the portion enclosed by [] in the template, thereby automatically generating a class file of the server component body 21 and the like. By repeating this, all files are generated. Hereinafter, the processing by the class file automatic generation unit 74 will be specifically described with reference to the flowcharts of FIGS.
[0232]
FIG. 30 is a flowchart showing the entire processing flow of the class file automatic generation.
[0233]
FIG. 31 is a flowchart showing the skeleton generation of the server component main body 21.
[0234]
FIG. 32 is a flowchart showing automatic generation of a common interface.
[0235]
FIG. 33 is a flowchart showing automatic generation of a server-side adapter class.
[0236]
FIG. 34 is a flowchart showing the process of embedding the relay method into the definition of the adapter class.
[0237]
30. First, the server component name is checked by the information from the information providing unit 72 (step ST41), and then a skeleton file of the server component body 21 is created (step ST42). ). Next, a file for the common interface 25 is created (step ST43), and subsequently, a file for the server-side adapter interface 24a is created (step ST44). Then, a server-side adapter class file is created (step ST45), a client-side adapter class file is created (step ST46), and these files are output to the class file unit 75.
[0238]
Also, as shown in FIG. 31, in the skeleton generation of the server component main body 21, first, the list LC-1 (the class definition of the component main body) in FIG. The information is replaced for the template [] part by the information of (step ST51). Next, the list LC-2 (method definition of the component body) in FIG. 28 is called, and information replacement is similarly performed for all methods (steps ST52 and ST53). When the information replacement for all methods is completed, the skeleton generation of the server component main body 21 is completed (step ST53).
[0239]
Next, as shown in FIG. 32, in the automatic generation of the common interface, first, the list LC-3 (interface definition of the common interface) in FIG. 28 is called, and information replacement is performed (step ST61). Next, the list LC-4 (method definition of the common interface) in FIG. 28 is called, and information replacement is performed for all methods (steps ST62 and ST63). When information replacement of all methods is completed, automatic generation of the common interface is completed (step ST63).
[0240]
Next, as shown in FIG. 33, in the automatic generation of the server-side adapter class, first, the list LC-5 (the class definition of the server-side adapter) in FIG. 28 is called, and information replacement is performed (step ST71). . Next, a list of server-side adapter method definitions (list LC-6 in FIG. 28 (method definition of server-side adapter when return type is non-void) or LC-7 (when return type is void) Is called, and information replacement is performed for all methods (steps ST72 and ST73). When information replacement of all methods is completed, automatic generation of the server-side adapter class is completed (step ST73). Note that the processing in step ST72 is more specifically shown in FIG. That is, first, the type of the return value is checked based on the information from the information providing unit 72 (step ST81), and when the return value is other than void, the list LC-6 in FIG. 28 is called to replace the information ( In step ST82), in the case of void, the list LC-7 in FIG. 28 is called and information replacement is performed (step ST83).
[0241]
As described above, the file is generated by the class file automatic generation unit 74.
[0242]
The generation of the client-side adapter class is the same as that of the server-side adapter class shown in FIGS.
[0243]
In the above process, the server component name is in the capital letter format (words are capitalized and the rest are lowercase, if multiple words are connected, the words are capitalized and connected). And the argument names are written in capital letter format beginning with Kobunyu. [Server component name (lowercase)] is a name in which all server component names are written in small letters. [Default value of return value] Any default value of the type.
[0244]
As described above, in the server component automatic generation system according to the seventh embodiment of the present invention, the class file automatic generation unit 74 combines the template from the template providing unit 73 and applies the information from the information providing unit 72. Since the class file is generated, the components of the server component 5 can be automatically generated.
[0245]
Therefore, even if there are many components in the server component 5, most of the components are automatically generated by using the present invention, and the burden on the developer is reduced. Therefore, the developer has to actually program only the part relating to the implementation of the application program request processing (main processing contents).
[0246]
(Eighth embodiment)
In the seventh embodiment, the case of FIG. 21B, that is, the automatic generation of the class file in the case where the basic server component 5 shown in FIG. 4 is configured by Java RMI has been described. Next, as an eighth embodiment, automatic generation of each element of the server component 5 in the case of FIG. 21C, that is, when the server component 5 shown in FIG. 16 is configured by Java RMI will be described. The technology shown in the present embodiment and the seventh embodiment can be applied to the server component shown in FIG. 19 to automatically generate each component and class file.
[0247]
FIG. 35 is a block diagram showing a configuration example of a server component automatic generation system according to the eighth embodiment. The same parts as those in FIG. 22 are denoted by the same reference numerals and description thereof will be omitted.
[0248]
In this automatic generation system, a development computer 71A includes an information providing unit 72A, a template providing unit 73A, a class file automatic generating unit 74A, a class file unit 75, a main processing content creating unit 76, and a main processing content providing unit 77. It is configured.
[0249]
The information providing unit 72A has the same configuration as that of FIG. 22 except that the information to be provided increases with the expansion of the server component 5 function.
[0250]
The template providing unit 73A has the same configuration as that of FIG. 22 except that the number of templates to be provided increases with the expansion of the server component 5 function.
[0251]
The class file automatic generation unit 74A generates the twelve classes / interfaces shown in FIG. 21C based on the same concept as the class file automatic generation unit 74 of FIG. The specific processing is shown in FIGS.
[0252]
In addition, examples of the 12 classes / interfaces automatically generated in FIGS. 36 to 47 are lists LL-1 (an example of a common interface according to Java), LL-2 (an example of a server component body according to Java), and LL-3. (Example of server-side adapter class by Java), LL-4 (example of RMI interface of server-side adapter class), LL-5 (example of client-side adapter), LL-6 (example of server-side resource access unit common interface) ), LL-7 (example of server-side resource access unit), LL-8 (example of server-side resource access server-side adapter for RMI), LL-9 (example of server-side resource access server-side adapter) , LL-10 (Example of client-side adapter for server-side resource access) (Examples of RMI interface of the client-side resource accessing section) LL-11, shown as LL-12 (example of a client-side resource accessing section).
[0253]
48 to 56, a list C-1 (class definition of the component body) of each template (skeleton) provided by the template providing unit 73A, C-2 (an initialization method for execution on the client side for C-1) ), C-3 (C-2 client-side resource access unit generation unit), C-4 (C-2 server-side resource access unit generation unit), C-5 (for execution on the C-1 server side) Initialization method), C-6 (C-1 client resource section setting method), C-7 (C-1, C-60, C-b0 method definition), C-8 (C-1 client side) Resource access unit attribute), C-9 (C-1 server side resource access unit attribute), Ca (C-1 client application setting method), C-10 (common interface I Interface definition), C-11 (method definition for C-10, C-50), C-12 (client application setting method for C-10, C-a0), C-20 (for RMI of server side adapter) Interface definition), C-21 (relay method definition for C-20), C-22 (client resource access unit setting method for C-20), C-30 (class definition of server-side adapter), C-31 ( C-30 client-side resource access section setting method), C-32 (relay method definition for C-30, C-80 server-side adapter when return type is non-void), C-33 (return C-30, C-80 server-side adapter relay method definition when value type is void, C-34 (C-30 server initialization), C-40 ( Client-side adapter class definition), C-41 (C-40 client-side resource access part attribute), C-42 (C-40 client-side resource access part generation), C-43 (C-40 client C-44 (C-40 client application setting unit), C-45 (C-40, C-90 client-side adapter when return type is non-void) Relay method definition), C-46 (Relay method definition of C-40, C-90 client-side adapter when return type is void), C-50 (Server-side resource access unit common interface definition) , C-60 (class definition of server side resource access unit), C-70 (server side resource access server side adapter RMI interface) Interface definition), C-80 (class definition of server-side resource access client-side adapter), C-90 (server-side resource access client-side adapter class definition), C-a0 (client-side resource access module RMI) Interface definition), C-a1 (Client application setting method for C-a0), C-b0 (Class definition of client-side resource access unit), C-b1 (C-b0 client application attribute), C-b2 (C-b0 client application setting method) is shown. The list numbers shown in the flow charts of FIGS. 57 to 64 correspond to those of FIGS. 48 to 56.
[0254]
Next, a process of automatically generating these 12 classes / interfaces will be described.
[0255]
When the server component 5 is generated, the following information is given from the information providing unit 72A to the automatic class file generation unit 74A.
[0256]
1. Server component name
2. Accessing server-side resources?
3. Access client-side resources?
4. Does the component call the client application program?
5. Method name (assigned to each of the above 1, 2 and 3 as necessary)
・ Return type
-Argument types and argument names
Based on this information, each class and interface template (skeleton) shown below can be automatically generated by replacing the part enclosed by [] with the given information or adding an optional part. Is done. The server component name is described in a capital letter format, and the method name and the argument name are described in a capital letter format beginning with a lowercase letter. [Server component name (lowercase)] is the name of the server component in all lowercase letters. [Return value default value] is an arbitrary default value of the type.
[0257]
Specifically, it follows the flow charts of FIGS. 57 to 64 showing the processing of the class file automatic generation unit 74A.
[0258]
In these flowcharts, the RMI interface of the server-side adapter and the RMI interface of the client-side resource access unit are the common interface, and the RMI interface of the server-side resource access unit and the server-side resource access server-side adapter are the server side. The resource-access common interface, the server-side resource access server-side adapter and the client-side resource access part are similar to the server-side adapter, and the server-side resource access client-side adapter is similar to the client-side adapter. , And insertion points are as described above or below), and therefore, these flowcharts are omitted.
[0259]
Further, the client-side adapter class, each class / interface of the server-side resource access unit, and the class / interface of the client-side resource access unit are similar to the flowchart of the server-side adapter class, and will not be described. Q1, Q2, and Q3 in the branches in each flowchart mean the following, respectively.
[0260]
Q1: Do you access server side resources?
Q2: Do you access resources on the client side?
Q3: Does the component body call the client application program?
Hereinafter, generation of each component will be specifically described.
[0261]
First, in the source of the server component main body 21, first, a list C-1 (FIG. 48) is prepared. Next, when there is any option setting (2, 3, 4 above), the list C-2 (FIG. 48) is inserted into the corresponding location of the list C-1 (FIG. 48). The description of the insertion location is a location where "// << List C-n >>" is written. In this case, the list C-n is inserted at that location. Next, in the case of the above 3 (accessing the client-side resources) or 4 (the component body calls the client application program), the list C-3 (FIG. 48) is changed to the list C-2 (FIG. 48). -6 (FIG. 49) and list C-8 (FIG. 49) are inserted into list C-1 (FIG. 48). In the case of the above 2 (accessing the server side resources), the list C-4 (FIG. 48) is changed to the list C-2 (FIG. 48), and the list C-5 (FIG. 49) and the list C-9 (FIG. 49) are changed. Insert it into list C-1 (FIG. 48). Further, in case 4 above, the list Ca (FIG. 49) is inserted into the list C-1 (FIG. 48). After that, the list C-7 (FIG. 49) is inserted into the list C-1 (FIG. 48) as necessary (for the number of methods provided by the server component body 21).
[0262]
Next, as a source of the common interface 25, first, a list C-10 (FIG. 50) is prepared. Next, the list C-11 (FIG. 50) is inserted by a necessary amount. In the case of 4, the list C-1 (FIG. 48) 2 is inserted into the list C-10 (FIG. 50).
[0263]
Next, for the RMI interface 24a of the server-side adapter 24, a list C-20 (FIG. 50) is first prepared. Next, the required number of lists C-21 (FIG. 50) are inserted into the list C-20 (FIG. 50). In the case of the above 3 or 4, the list C-22 (FIG. 50) is inserted into the list C-20 (FIG. 50).
[0264]
Next, as the source of the server-side adapter 24, first, a list C-30 (FIG. 51) is prepared. Next, in the case of the above 3 and 4, the list C-31 (FIG. 51) and the list C-34 (FIG. 51) are inserted into the list C-30 (FIG. 51). Thereafter, the list C-32 (FIG. 51) or the list C-33 (FIG. 51) is inserted into the list C-30 (FIG. 51) as necessary.
[0265]
Next, the source of the client-side adapter 22 first prepares a list C-40 (FIG. 52). In the above cases 3 and 4, the list C-41 (FIG. 52), the list C-42 (FIG. 52), and the list C-43 (FIG. 53) are inserted into the list C-40 (FIG. 52). In the case of the above 4, the list C-44 (FIG. 53) is inserted into the list C-40 (FIG. 52). After that, as many lists C-45 (FIG. 53) or lists C-46 (FIG. 53) as necessary are inserted.
[0266]
Next, the source of the server-side resource access unit common interface 58 is created in the case of the above 2. First, a list C-50 (FIG. 54) is prepared. Next, the required number of lists C-11 (FIG. 50) are inserted into C-50 (FIG. 54).
[0267]
Next, the source of the server-side resource access unit 57 is created in the case of the above 2. First, a list C-60 (FIG. 54) is prepared. Next, the required number of lists C-7 (FIG. 49) are inserted into the list C-60 (FIG. 54).
[0268]
Next, the source of the RMI interface 56a of the server-side resource-accessing server-side adapter 56 is created in the case of the above 2. First, a list C-70 (FIG. 54) is prepared. Next, the required number of lists C-21 (FIG. 50) are inserted into the list C-70 (FIG. 54).
[0269]
Next, the source of the server-side resource-accessing server-side adapter 56 is created in case 2 above. Also, a list C-80 (FIG. 54) is prepared. Next, the required number of lists C-32 and C-33 (FIG. 51) are inserted into the list C-80 (FIG. 54).
[0270]
Next, the source of the client-side adapter 54 for server-side resource access is created in the case of the above 2. First, a list C-90 (FIG. 55) is prepared. Next, the required number of lists C-45 and C-46 (FIG. 53) are inserted into the list C-90 (FIG. 55).
[0271]
Next, the source of the RMI interface 53a of the client-side resource access unit 53 is created in the case of 3 or 4 above. First, a list C-a0 (FIG. 55) is prepared. Next, the required number of lists C-21 (FIG. 50) are inserted into the list C-a0 (FIG. 55). In case 4 above, the list C-a1 (FIG. 55) is inserted into the list C-a0 (FIG. 55).
[0272]
Next, the source of the client-side resource access unit 53 is created in the case of the above 3 or 4. First, a list C-b0 (FIG. 56) is prepared. Next, the required number of lists C-32 (FIG. 51) are inserted into the list C-b0 (FIG. 56). In the case of the above 4, the lists C-b1 and C-b2 (FIG. 56) are inserted into the list C-a0 (FIG. 55).
[0273]
As described above, in each of the generated classes / interfaces, the component developer can develop the server component 5 by implementing the part in which the list C-7 (FIG. 49) is inserted by the main body content providing unit 77.
[0274]
Further, the description in the present embodiment is directed to the Java language. However, even if CORBA is used for communication between distributed objects or C ++ is used as a language, it can be dealt with with few changes.
[0275]
(Ninth embodiment)
According to the above-described embodiment, the Java applet has a static system structure in which the processing execution position is always the client side, but the processing execution position is set to the server side or the client side at the time of execution. It is possible to construct a distributed system that can have a dynamic system structure that can determine this. However, in the above-described embodiment, there is one computer serving as a server that provides a server component, and another computer in a network other than the computer serving as a client and the computer serving as a server is used as a place (server) for executing processing. Cannot be used. Therefore, an embodiment in which the implementation of the server process can be operated by any computer in the network will be described below.
[0276]
In this embodiment, the server component is handled by one computer serving as a server host from the viewpoint of maintenance management of the server component and reduction of installation work.
[0277]
When executed on another computer (called a sub server host), server components are delivered from this server host and executed. For this reason, the sub server host receives the processing component sent from the server host, makes it executable, and performs other necessary preparations.
[0278]
The delivered server component is composed of a basic unit, a client-side resource access unit, and a server-side resource access unit so that the server component can be accessed even with a specific computer resource.
[0279]
Further, after determining the execution location, distributing the server component there, and performing the processing, the execution location can be changed from there, and an execution position indicating unit and a callback interface of the client side application program are provided.
[0280]
FIG. 65 shows the configuration (hardware configuration and software resources) of the distributed system according to the ninth embodiment based on such a principle.
[0281]
In this system, a client host 150, a main server host 120, and a sub server host 130 are connected via a network.
[0282]
The main server host 120 is connected to the server component 110. The server component 110 includes a basic portion 111 as shown in FIG. 4, a client-side resource access section 112, a server-side resource access section 113 and server component information 114 shown in FIGS.
[0283]
The client host 150 includes a client component loader 152 and a callback interface 151. The input device 180 and the display 190 are connected to the client host 150.
[0284]
The main server host 120 includes a component manager 121, a component server 122, and an execution position determining unit 123. The component server 122 is connected to a client component loader 152 and a callback interface 151.
[0285]
The sub server host 103 has a sub server component loader 131, and the sub server component loader 131 is connected to the component server 122.
[0286]
An execution position instruction unit 140 to which the input device 170 and the display 160 are connected is connected to the execution position determination unit 123.
[0287]
The application user operates the client host 150 via the input device 180 and the display 190. The client host 150 requests the main server host 120 for a server component 110 that performs processing according to a user's request. Specifically, the server component 110 makes a request to the component server 122 in the main server host 120 via the client component loader 152 in the client host 150. At that time, the callback interface 118 is passed to the component server 122.
[0288]
The component server 122 requests the specified server component 110 from the component manager 121 and receives it. The component server 122 determines a computer that executes the specified server component 110 by using the execution position determination unit 123.
[0289]
When the server component 110 is executed on the main server host 120, the basic unit 112 of the server component 110 is placed in an executable state (instance generation) by the component server 122, and preparations such as initialization are performed.
[0290]
When the server component 110 is executed on the sub server host 103, the component server 122 delivers the basic unit 112 of the server component 110 to the component loader 131 for the sub server. The sub server component loader 131 receives a necessary class from the component server 122, generates an instance of the class, and prepares for initialization and the like.
[0291]
When executing the server component 110 on the client host 150 side, the component server 122 delivers the basic part 112 of the server component 110 to the client component loader 152 of the client host 150. The client component loader 152 receives a necessary class from the component server 122, generates an instance of the class, and prepares for initialization and the like.
[0292]
The client host 150 connects to the base unit 112 of the server component 110 that has been instantiated in any one of the above cases via a network or in-process, and executes processing using the connection.
[0293]
When the server component 110 has the client-side resource access unit 112, the component server 122 delivers it to the client component loader 152 of the client host 150. The client component loader 152 generates an instance of the instance and sets the instance in the basic unit 112 of the server component 110. If the server component 110 has the server-side resource access unit 113, the server component information loader 131 of the sub-server host 103 on the “computer that executes the server-side resource access unit 113” described in the server component information 114 The side resource access unit 113 is delivered. The sub-server component loader 131 generates an instance of the instance and sets it in the basic unit 112 of the server component 110. When the server-side resource access unit 113 is operated by the main server host 120, the component server 122 generates an instance and sets the instance in the basic unit 112 of the server component 110.
[0294]
The system administrator instructs the execution position instructing unit 140 via the input device 170 and the display 160 to determine (instruct) the execution position. The execution position instructing unit 140 transmits an instruction of the system administrator to the execution position determining unit 123. The execution position determination unit 123 determines the execution position based on this information in the subsequent execution position determination. After determining the execution position requested by the component server 122, the execution position determination unit 123 also transmits the content to the execution position instruction unit 140. Based on this information, the execution position instructing unit 140 displays on the display 160 the currently executed server component 110 and its execution position.
[0295]
Based on this information, the system administrator can also specify the next execution position via the input device 170 for the component currently being executed. When the information of the “next execution place” designated by the system administrator is transmitted from the execution position designation unit 140 to the execution position decision unit 123, the execution position decision unit 123 further conveys the content to the component server 122, and A process for performing rearrangement is performed. Specifically, the currently executed server component 110 is temporarily terminated, the server component 110 is delivered to a newly designated location, and instance generation and the like are performed. Then, the component server 122 notifies the client host 150 using the callback interface 118 that the server component 110 has been relocated, and indicates a new location. The client host 150 performs initialization processing such as reconnection to a new server component 110 based on the information.
[0296]
According to such a ninth embodiment, in addition to the effects of the above-described embodiment, the implementation of the server processing can be operated by any computer in the network, and the specific implementation of the server processing is This has the effect of enabling operation on a computer.
[0297]
(Tenth embodiment)
FIG. 66 is a block diagram showing a physical configuration of a tenth embodiment of the distributed system of the present invention, and FIG. 67 is a block diagram showing a logical configuration of the tenth embodiment. Here, an application program that accesses a database and performs simple processing is shown as an example.
[0298]
As shown in FIG. 66, in the distributed system of the tenth embodiment, the main server host 120 is connected to the main server machine 330 connected to the network 310, the sub server host 230 is connected to the sub server machine (B) 350, and the sub server The sub server host 230 and the database 400 are installed on the machine (B) 350, the execution position instructing unit 240 is installed on the administrator machine 320, and the database access client host 250 is installed on the client machine 360. Here, the meaning of the installation means that the program is installed in a computer and is prepared for execution.
[0299]
As shown in FIG. 67, the distributed system includes a database access server component 210, a main server host 220, a sub server host 230, an execution position instructing unit 240, a database access client host 250, and a database 400. Further, the server component 210 includes a database (DB) access basic unit 211, a client-side resource access unit 212, a server-side resource access unit 213, and server component information 214. The client-side resource access unit 212 further includes a GUI 212a. Note that the client-side resource access unit 212 and the server-side resource access unit 213 do not necessarily need to be provided, and may be omitted in some cases.
[0300]
FIG. 68 shows an example of the server component information 214. Here, the server component information 214 includes the component name, the execution location of the server-side resource access unit, and the presence or absence of the client-side resource access unit.
[0301]
The main server host 220 includes a component manager 221, a component server 222, and an execution position determining unit 223.
[0302]
The sub server host 230 includes a sub server component loader 231.
[0303]
The execution position display unit 240 includes a GUI 241.
[0304]
The database access client host 250 includes a client component loader 252, a callback interface 253, and a GUI 250.
[0305]
As the operation of the distributed system of this embodiment configured as described above, the determination, arrangement, execution, and relocation after execution of the server component 210 are performed in accordance with the execution order of the database access application program shown in FIG. explain. The database access application program given here as an example is an application program that accesses a simple sales management database as shown in FIG. 69 and displays the total purchase price of a specific purchaser.
[0306]
FIG. 70 shows a GUI 253 of the client host 250 of this application program.
[0307]
FIG. 71 shows a series of flow of determination, arrangement, execution, and rearrangement of the execution position of the server component 210 in the present embodiment. The execution position is determined by requesting the server component 210 from the client host 250 to the main server host 220 so that the user of the application program accesses the database, and the execution position determination unit 223 determines the execution position. is there. The arrangement is from delivery, instance generation, and preparation of the server component 210 according to the determined execution position to connection processing with the client host 250. Execution is the actual database access process. The reallocation is a reallocation after the server component 210 is executed by the administrator. Note that this database access application program is merely for convenience of explanation, and the present invention is applicable to any application program.
[0308]
(1) [Execution position determination] Flow up to request of server component 210
First, the user of the database application program inputs the name of the purchaser to be searched into the purchaser name input section 610 (step ST102). Next, a search button 506 is pressed (step ST104). The client host 250 checks whether or not the server component 210 is ready for use (step ST106). If it can be used, a process such as a search is performed by using it (step ST114), and the result is displayed (step ST16).
[0309]
Otherwise, client host 250 makes a request for server component 210 to component server 222 (step ST108). The component server 222 requests the execution position determination unit 223 to determine the execution position of the server component 210 requested by the client host 250 to the component server 220 (step ST110).
[0310]
(2) [Arrangement] Flow from execution position determination to server component 210 becoming usable
A series of flows from the execution position determination to the server component 210 being usable will be described with reference to FIG. FIG. 73 shows an example of the server component information 214 of the server component 210 at the time of this processing. The server component information 214 stores the server component 210 as the component name, the sub-server machine (B) 350 as the execution location of the server-side resource access unit, and the presence or absence of the client-side resource access unit.
[0311]
In order to determine the execution position of the requested server component 210, the component server 222 first refers to the server component information 214 of the server component 210 via the component manager 221 and specifies a computer that operates the DB access basic unit 211. Investigate if it is. This information is optional and may not be present. No particular designation is made in the present embodiment.
[0312]
Next, the execution position determination unit 223 is asked about the execution position. In the present embodiment, it is assumed to be the sub server machine (A) 340. When the execution position of the server component basic unit (database access basic unit 211) is specified in the server component information 214, and the determination result of the execution position determination unit 223 differs from the specified location, which is the execution location Can be arbitrarily determined by the system. For example, it can be set so that the information of the server component information 214 is prioritized.
[0313]
In FIG. 72, since the result of the determination of the execution position of the server component 210 (step ST120), that is, the execution position of the DB access basic unit 211 is the sub server host 230, the component server 222 sends the DB access basic The sub-unit 211 is received and delivered to the sub-server component loader 231 of the sub-server machine (A) 340 (step ST128). The sub server component loader 231 generates an instance of the received DB access basic unit 211 and performs initialization (setting of initial values and preparation for receiving a connection from the client host 250) (step ST130). Then, the component server 222 notifies the client component loader 252 that the requested server component 210 has been operated on the sub server machine (A) 340. The client host 250 connects to the DB access basic unit 211 operating on the sub server machine (A) 340 based on the information.
[0314]
Since the server component 210 has the client-side resource access unit 212 from the server component information 214 (step ST132), the component server 222 sends the client-side resource access unit 212 to the client component loader 252 of the client host 250. Send (step ST134). The client component loader 252 generates an instance of the received client-side resource access unit 212 and performs initialization (step ST136). Then, it is set in the DB access basic unit 211 executed by the sub server machine (A) 340 (step ST138).
[0315]
Similarly, since “execution location of server-side resource access unit 213” is specified from server component information 214, it is known that server component 210 also has server-side resource access unit 213 (step ST140). The server 222 checks the computer on which the server-side resource access unit 213 is to be operated from the server component information 214 (step ST142). If “execution location of the server-side resource access unit 213” is not specified, it indicates that the server component 210 does not have the server-side resource access unit 213. In this example, since the component server 222 is operated by the sub server host 230, the component server 222 sends the server-side resource access unit 213 to the sub server component loader 231 of the sub server host 230 of the sub server host 230 (step ST146). The sub-server component loader 231 receiving the server-side resource access unit 213 generates an instance of the server-side resource access unit 213 and performs initialization (step ST148). Then, it is set in the DB access basic unit 211 executed by the sub server machine (A) 340.
[0316]
By the above-described series of flows, all the system configurations (relationship between the client and the server) necessary for accessing the database according to the present embodiment are established.
[0317]
(3) [Execution] Flow of actual database access processing
Although not directly related to the present invention, the database access according to the present embodiment will be described with reference to FIG.
[0318]
Client host 250 sends the purchaser name input to the purchaser name input section to DB access basic section 211 (step ST160). The DB access basic unit 211 passes the purchaser name to the server-side resource access unit 213, and instructs the server-side resource access unit 213 to access the database (step ST162). The server-side resource access unit 213 obtains the data including the passed purchaser name from the database, and returns the result to the DB access basic unit 211 (step ST164). The DB access basic unit 211 sums up the resulting price values. Then, the value is returned to the client host 250 (step ST166). The client host 250 that has received the result displays the result on the total purchase price display section of the GUI (step ST168).
[0319]
(4) [Relocation] After the administrator executes the server component 210, the relocation component server 222 instantiates the DB access basic unit 211 or distributes it to another component loader. The execution position determination unit 223 is notified of the basic unit 211) and the place where the execution was performed. The execution position determination unit 223 holds such information as a list, transmits the information to the execution position instruction unit 240 as necessary, and displays the information using a GUI. FIG. 75 shows a GUI in this embodiment.
[0320]
This operation will be described with reference to the flowchart shown in FIG.
[0321]
As shown in FIG. 75, the GUI displays the information about the currently executing server component 210 held by the execution position determination unit 223, and thus the server component name display unit, the current execution location display unit, and the relocation location designation unit. , A relocation execution button, and an end button. The server component name display section and the relocation location designation section are each like a pull-down menu, and when you press the button on the right side of each section, a list of selectable candidates is displayed, and the system administrator selects from this display Will be. When the server component 210 is specified in the server component name display section, the location where the selected server component 210 is operating is displayed in the current execution location display section (step ST170). This information is held by the execution position determination unit 223.
[0322]
Next, the system administrator specifies the main server host 220 machine as a relocation destination in the relocation location specifying section of the GUI (step ST172). Note that data relating to items that can be selected as relocation locations is stored in the execution position determination unit 223. In this embodiment, the main server machine 330, the sub server machine (A) 340, the sub server machine (B) 230, The client machine 360 becomes a selection target. These data are collected by the exchange between the main server host 220, the sub server host 230, and the client host 250 when the system is started. For example, when the main server host 220 is started, it searches for the sub server host 230 existing in the network and notifies the execution position determining unit 223 of the found one. When started, the sub server host 230 contacts the main server host 220 and notifies the execution position determination unit 223 via the component. When requesting the server component 210 from the main server host 220, the client host 250 notifies the execution position determination unit 223 via the component server 222.
[0323]
Then, when the system administrator presses the relocation button, information on the designated server component 210 and the relocation destination (main server host 220) is sent from the execution position specification unit to the execution position determination unit 223 (step ST174). The execution position determination unit 223 notifies the component server 222 of the content (step ST176), and starts the relocation processing (step ST178).
[0324]
FIG. 77 shows an example in which the system administrator relocates the server component 210 from the sub server machine (A) 340 to the main server machine 330. Basically, the processing is almost the same as the above (2) “from after the execution position is determined until the server component 210 becomes usable”, so that the processing will be briefly described here.
[0325]
Since the relocation destination is the main machine, the component server 222 generates an instance of the DB access basic unit 211 and performs initialization and the like (step ST204). The fact that the relocation has occurred is notified to the client host 250, and the server component 210 that has been operating so far is discarded (step ST212). If the target to be discarded is another sub server host 230 or client, the sub-server host 230 or the client is notified to discard it, and the transmitted side performs discarding.
[0326]
Since the server component 210 has the client-side resource access unit 212, it prepares it (steps ST214 to ST220). Since the server component 210 also has the server-side resource access unit 213, it prepares for it (steps ST222 to ST232).
[0327]
Thus, the rearrangement is completed.
[0328]
After the rearrangement is completed, the database access processing shown in the above (3) can be continued.
[0329]
According to the tenth embodiment, in addition to the effects of the above-described embodiment, the execution position of the server process after execution can be changed (rearranged).
[0330]
The present invention is not limited to the embodiments described above, and can be variously modified without departing from the gist thereof. For example, the method described in the embodiment can be executed by a computer as a program (software means) such as a magnetic disk (floppy disk, hard disk, etc.), an optical disk (CD-ROM, DVD, etc.), a semiconductor memory, etc. It can be stored in a recording medium or transmitted and distributed via a communication medium. The programs stored on the medium include a setting program for causing a computer to execute software means (including not only an execution program but also a table and a data structure) to be executed by the computer. A computer that realizes the present apparatus reads a program recorded on a recording medium, and in some cases, constructs software means using a setting program, and executes the above-described processing by controlling the operation of the software means.
[0331]
【Example】
Next, a specific example of the distributed system of the present invention will be described as an example.
[0332]
(First embodiment)
The distributed system of the present invention can be applied to an image processing application program.
[0333]
In an image processing application program, the data transfer amount (argument and return value) for performing a process is large, but the process itself is often simple repetition, so that the size of the server component body can often be reduced. Therefore, in the image processing application program, the execution position at which the processing result can be obtained more quickly changes depending on the calculation capability of both the client / server host and the state of the network. Therefore, when the present system is applied to an image processing application program, the throughput is improved.
[0334]
As a specific application example to the server component, there is an image smoothing process as described in the embodiment.
[0335]
(Second embodiment)
The distributed system of the present invention can be used for a component business in a mobile environment.
[0336]
The use of networks is considered to be one of the most effective means for distributing components. When this distributed system is used as infrastructure, an effective component sales system can be constructed.
[0337]
In such a usage form, it is considered that a mobile environment or an Internet connection of a general home through a public line is more likely to be targeted, rather than a constantly connected network environment such as a LAN.
[0338]
The user (the client host 1 side) connects to a component provider that provides a component and purchases a necessary component. At this time, the server component main body is operated only on the server host 2 side for a user who wants to consider purchasing after trial use. If necessary, the number of times of use and the time of use are limited. The restriction mechanism may be provided in the client-side adapter 22, for example. Then, the server component main body is downloaded to the client host 1 for the user who has decided to purchase it, and can be stored in a local disk of the client host 1.
[0339]
Since component developers can develop server components without being aware of the situation in which they are used, it is possible for component developers to use the above methods in combination with the automatic generation technology described above. The burden is no different from traditional component development.
[0340]
In such a case, the server component itself may be not only a processing process but also various data. For example, providing a new map component in a strategy simulation game, a news component (the headline is treated as the client, the body is treated as the component body), a released new song component (only some parts are sent to the client first, or Poor sound quality (rough sampling) can be considered.
[0341]
One example is the sale of news components. In the news component sales system, the client-side adapter 22 provides only simple information such as a headline and a summary. Then, the component main body 21 provides detailed contents of the news, photos, and the like. In this system, the server-side adapter 24 need hardly function. For example, information in the server component main body such as a part of voice information is also required when the client adapter 22 uses the information.
[0342]
From the client host 150, when trial-viewing the target news component, only the simple contents that can be referred to via the client-side adapter 22 can be viewed. When the user actually purchases and downloads the main body, To refer to detailed information.
[0343]
Other than this, a wider range of services can be provided by combining with software distribution such as PUSH technology (push technology).
[0344]
(Third embodiment)
This distributed system can be used for a distributed component development system.
[0345]
Even in the development of applications / components that are supposed to be used via a network, using this system as an infrastructure will enable efficient development.
[0346]
For example, the component developer registers the component in the system under the condition that the beta version is operated only on the server host 2 side. Since the β version can be executed only on the server host 2 side, error log collection is easy, and the client host 1 side is also relatively safe. Of course, it is possible to limit the client users who can perform the β test. The completed component can be distributed as a normal component thereafter by changing the conditions (conditions that can be executed only on the server host 2 side). Therefore, it is not necessary to create a special stub or the like at the stage of a test or the like, which is considered to be effective in terms of development efficiency.
[0347]
(Fourth embodiment)
This distributed system can be used for system-related issues that can absorb differences in execution environments.
[0348]
In a fast-paced language environment such as Java, APIs may be added or changed depending on the version, and a difference may occur between execution environments. This system is also considered to be effective in absorbing such differences in execution environments.
[0349]
For example, when a server host, a first client host, and a second client host are connected via a network, the first client host supports all Java APIs, but the second client host supports Java APIs. Assume that the extended API is not supported.
[0350]
Here, if a processing component requested by the client requires a certain extended API, a processing request from the first client can be executed by any client / server host. Process can be executed on the host. However, when a request is issued from the second client, the processing cannot be executed on the client host side, so that the operation is always performed on the server host side.
[0351]
Therefore, this makes it possible to flexibly execute processing even when there are differences in execution environments. If this is applied, it can be considered that it can be effectively used even in a restricted execution environment used in an embedded / microcomputer system, for example.
[0352]
(Fifth embodiment)
It is conceivable that this distributed system can reduce network traffic when applied to a normal DB system.
[0353]
When a normal business application program is considered, there are many server hosts and client hosts serving as databases, and the physical configuration of the network also takes various forms.
[0354]
For example, a LAN is composed of two segments, and a component server that provides a server component is on a second segment of the LAN, and the provided component is a processing component that accesses a specific DB, and a client uses the component. Think about it.
[0355]
In this case, for example, when the first client on the first segment requests a component for accessing the DB server on the first segment, it is executed on the component server on the second segment, When executed by the first client on one segment, the latter is considered to be better from the viewpoint of network traffic.
[0356]
Usually, when constructing such a distributed business system, it is conceivable to take such a physical configuration into account at the stage of designing the entire system. However, client hosts and DBs are frequently added and deleted. If it becomes necessary to change the network configuration or the like, it is difficult to respond. However, if a distributed business system is constructed based on this client system, it is possible to respond to changes in the network configuration only by changing the execution positions of the components, so that the optimal distributed system can be used continuously. It is thought to be.
[0357]
【The invention's effect】
As described above, according to the distributed system of the present invention, the following can be performed in a network environment in which two or more computers are connected.
[0358]
(1) Since the execution body of the process is managed by the server and the execution position is determined, the execution position of the processing process can be dynamically changed and the system configuration can be flexibly changed.
[0359]
(2) The server component developer only needs to implement the processing logic on the server side in one place (server host). Therefore, a processing process operating on the client side and a processing process operating on the server side are separately performed. There is no need for heavy development, and maintenance and installation of processing logic can be reduced.
[0360]
(3) Since the server component is composed of the basic unit, the client-side resource access unit, and the server-side resource access unit, the server component can be accessed even with a specific computer resource.
[0361]
(4) When there are a plurality of sub-servers other than the main server, and the sub-servers execute the sub-servers, the server components are delivered from the main server to the sub-servers, and the sub-servers receive the components and make them executable.
[0362]
(5) After determining the execution position, distributing the server component there, and performing the processing, the execution position can be further changed (relocated) therefrom.
[Brief description of the drawings]
FIG. 1 is a block diagram showing a hardware configuration example of a distributed system according to a first embodiment of the present invention.
FIG. 2 is a diagram illustrating a software logical configuration in the distributed system according to the first embodiment.
FIG. 3 is a diagram showing a configuration example of an application program according to the first embodiment.
FIG. 4 is a diagram showing a configuration example of a server component according to the first embodiment.
FIGS. 5A and 5B are diagrams illustrating configurations when a server component body is executed on a client host and when the server component body is executed on a server host.
FIG. 6 is a diagram showing a configuration example of a component loader.
FIG. 7 is a diagram showing a configuration example of a component server.
FIG. 8 is a diagram showing a configuration example of a component manager.
FIG. 9 is a diagram showing processing from a processing request to a server component to determination of an execution position.
FIG. 10 is a diagram showing from execution position determination to execution when a server component is executed on a client host side.
FIG. 11 is a diagram showing from execution position determination to execution when a server component is executed on the server host side.
FIG. 12 is a flowchart showing an entire process from a process request to a server component to a process execution.
FIG. 13 is a flowchart showing processing for remotely using the server body in FIG. 12;
FIG. 14 is a flowchart showing processing for receiving a component of the component loader in FIG. 12;
FIG. 15 is a flowchart showing a process for using a component present in the cache in FIG. 12;
FIG. 16 is a diagram showing a configuration example of a server component according to the second embodiment of the present invention.
FIG. 17 is a diagram showing a configuration of a server component when the server component main body is operated on the server host side.
FIG. 18 is a diagram showing a configuration of a server component when a server component main body is operated on a client host side.
FIG. 19 is a diagram illustrating a configuration example of a server component according to the third embodiment of the present invention.
FIG. 20 is a diagram showing a configuration of a server component when the server component main body is operated on the server host side.
FIG. 21 is a diagram showing a state when a server component is developed in a specific programming language.
FIG. 22 is a block diagram showing a configuration example of a server component automatic generation system according to a seventh embodiment of the present invention.
FIG. 23 is an exemplary view showing an example of a common interface based on Java in the embodiment.
FIG. 24 is an exemplary view showing an example of a server component main body based on Java in the embodiment.
FIG. 25 is an exemplary view showing an example of a server-side adapter class based on Java in the embodiment.
FIG. 26 is an exemplary view showing an example of an RMI interface of a server-side adapter class in Java according to the embodiment;
FIG. 27 is an exemplary view showing an example of a client-side adapter based on Java in the embodiment.
FIG. 28 is a diagram showing lists LC-1 to LC7 corresponding to templates provided by the template providing unit.
FIG. 29 is a view showing lists LC-8 to LC12 corresponding to templates provided by the template providing unit.
FIG. 30 is a flowchart showing an overall processing flow of class file automatic generation.
FIG. 31 is a flowchart showing skeleton generation of a server component main body.
FIG. 32 is a flowchart showing automatic generation of a common interface.
FIG. 33 is a flowchart showing automatic generation of a server-side adapter class.
FIG. 34 is a flowchart showing a process of embedding a relay method into the definition of an adapter class.
FIG. 35 is a block diagram showing a configuration example of a server component automatic generation system according to an eighth embodiment of the present invention.
FIG. 36 is an exemplary view showing an example of a common interface based on Java in the embodiment.
FIG. 37 is an exemplary view showing an example of a server component main body based on Java in the embodiment.
FIG. 38 is an exemplary view showing an example of a server adapter class based on Java in the embodiment.
FIG. 39 is an exemplary view showing an example of an RMI interface of a server adapter class based on Java in the embodiment.
FIG. 40 is an exemplary view showing an example of a client-side adapter based on Java in the embodiment.
FIG. 41 is an exemplary view showing an example of a server-side resource access unit common interface according to Java in the embodiment.
FIG. 42 is an exemplary view showing an example of a server-side resource access unit using Java in the embodiment.
FIG. 43 is an exemplary view showing an example of an RMI interface based on Java in the embodiment.
FIG. 44 is an exemplary view showing an example of a server-side resource-accessing server-side adapter in Java according to the embodiment.
FIG. 45 is a view showing an example of a client-side adapter for server-side resource access by Java in the embodiment.
FIG. 46 is a view showing an example of an RMI interface of a client-side resource access unit according to Java in the embodiment.
FIG. 47 is an exemplary view showing an example of a client-side resource access unit using Java in the embodiment.
FIG. 48 is a view showing lists C-1 to C-4 corresponding to templates provided by the template providing unit.
FIG. 49 is a view showing lists C-5 to C-9 and Ca corresponding to templates provided by the template providing unit.
FIG. 50 is a view showing lists C-10 to C-22 corresponding to templates provided by the template providing unit.
FIG. 51 is a view showing lists C-30 to C-34 corresponding to templates provided by the template providing unit.
FIG. 52 is a view showing lists C-40 to C-42 corresponding to templates provided by the template providing unit.
FIG. 53 is a view showing lists C-43 to C-46 corresponding to templates provided by the template providing unit.
FIG. 54 is a view showing lists C-50 to C-80 corresponding to templates provided by the template providing unit.
FIG. 55 is a view showing lists C-90, C-a0, and C-a1 corresponding to templates provided by the template providing unit.
FIG. 56 is a view showing lists C-b0 to C-b2 corresponding to templates provided by the template providing unit.
FIG. 57 is a flowchart showing the entire processing of automatic generation.
FIG. 58 is a flowchart showing a process of creating each file by a server-side resource access unit.
FIG. 59 is a flowchart showing a skeleton generation process of the server component main body.
FIG. 60 is a flowchart showing automatic generation processing of a common interface.
FIG. 61 is a flowchart showing automatic generation processing of a server-side adapter class.
FIG. 62 is a flowchart showing a process for creating a relay method definition.
FIG. 63 is a flowchart showing automatic generation processing of a client-side adapter file.
FIG. 64 is a flowchart showing automatic generation processing of a common interface file of a server-side resource access unit.
FIG. 65 is a block diagram showing a hardware configuration example of a distributed system according to a ninth embodiment of the present invention.
FIG. 66 is a block diagram showing a physical configuration example of a distributed system according to the tenth embodiment of the present invention.
FIG. 67 is a block diagram showing a logical configuration example of a distributed system according to the tenth embodiment.
FIG. 68 is a view showing an example of server component information.
FIG. 69 is a diagram showing an example of a database targeted by the database application program.
FIG. 70 is a view showing an example of a GUI of a client host of the database application program.
FIG. 71 is a flowchart showing the overall operation of the tenth embodiment;
FIG. 72 is a flowchart showing an operation when a server component is dynamically arranged.
FIG. 73 is a view showing an example of server component information when server components are dynamically arranged.
FIG. 74 is a flowchart showing an operation at the time of database access.
FIG. 75 is a view showing an example of a GUI of the component manager.
FIG. 76 is a flowchart showing the overall flow of relocation.
FIG. 77 is a detailed flowchart of the rearrangement processing of FIG. 76;
[Explanation of symbols]
1: Client host
2 ... Server host
3. Network
4. Storage device
5 ... Server component
11: Client host basic part
12 ... Component loader
13: Component cache
14. Component server
15 execution position determination unit
16 ... Component Manager
17 Access control monitoring unit
18 Network monitor
21 ... Server component body
22: Client-side adapter
23 Communication between distributed objects
24: Server-side adapter
25 ... Common interface
31 ... instance generation unit
32: Component decoding unit
33 ... Component decompression unit
36. Instance generation unit
37: Component encryption unit
38 Component compression unit
41: Component extraction unit
42 ... Component information extraction unit
43 ... Component registration management unit
51: Client resource support section
52: Server resource corresponding unit
53: Client resource access unit
54: Client adapter for server resource access
55: Communication between distributed objects
56: Server-side adapter for server resource access
57: Server resource access unit
58: Server resource access section common interface
61 ... Client-side adapter for client resource access
62 Communication between distributed objects
63: Server adapter for client resource access
64: Client resource access unit common interface
71 ... Computer for development
72… Information provider
73… Template provider
74 Class file automatic generation unit
75… Class file part
76: Body processing content creation section
77… Main unit processing content providing unit

Claims (9)

クライアントとサーバからなる分散システムにおいて、
前記クライアントは処理の要求を発するアプリケーション基本部分と、コンポーネントローダとを具備し、
前記サーバは前記アプリケーション基本部分が要求する処理を実行するサーバコンポーネントを管理する管理手段と、前記アプリケーション基本部分からの要求を受け取り、当該処理を実行するサーバコンポーネントを前記クライアント又は前記サーバのいずれで実行するかを決定する実行位置決定手段と、前記アプリケーション基本部分から要求された処理を実行するサーバコンポーネントを前記管理手段から取得し、取得した当該サーバコンポーネントを前記実行位置決定手段における決定結果に従って処理するサーバコンポーネント引渡手段とを具備し、前記サーバコンポーネントは、要求される処理を実装しているサーバコンポーネント本体と、前記サーバと通信を行うクライアント側アダプタ、前記クライアントと通信を行うサーバ側アダプタとを具備し、
前記サーバコンポーネント引渡手段は、
クライアントで実行すると決定した場合、サーバコンポーネント本体をクライアントのコンポーネントローダへ送り、コンポーネントローダにサーバコンポーネント本体から実行可能なサーバコンポーネントオブジェクトを生成させる手段と、
サーバで実行すると決定した場合、管理手段から指定されたサーバコンポーネントのクライアント側アダプタとサーバコンポーネント本体を受け取り、サーバコンポーネント本体から実行可能なサーバコンポーネントオブジェクトを生成し、サーバ側アダプタについてのオブジェクトを生成し、処理の要求を発したクライアントのコンポーネントローダへクライアント側アダプタを送り、コンポーネントローダにクライアント側アダプタを実行可能なスタブオブジェクトを生成させる手段とを具備し、
クライアントで実行すると決定した場合、クライアントアプリケーション基本部分にサーバコンポーネント本体を利用して処理を実行させ、
サーバで実行すると決定した場合、クライアントアプリーション基本部分にスタブオブジェクト、サーバ側アダプタを通してサーバホスト上に生成されたサーバコンポーネント本体にアクセスし処理を実行させる分散システム。 In a distributed system consisting of clients and servers,
The client includes an application basic part that issues a request for processing, and a component loader ,
The server manages a server component that executes a process requested by the application basic part, and receives a request from the application basic part, and executes the server component that executes the process on either the client or the server. An execution position determining unit for determining whether to perform the processing, and a server component that executes a process requested from the application basic part are obtained from the management unit, and the obtained server component is processed according to a result determined by the execution position determining unit. ; and a server component delivery means, wherein the server component, performing a server component body implementing the required processing, the client-side adapter that communicates with the server, the communication with the client service ; And a side adapter,
The server component delivery means,
Means for sending the server component body to the client component loader when it is determined to be executed on the client, and causing the component loader to generate an executable server component object from the server component body;
If it is determined to be executed on the server, it receives the client-side adapter and server component of the specified server component from the management means, generates an executable server component object from the server component, and generates an object for the server-side adapter. Means for sending a client-side adapter to the component loader of the client that issued the processing request, and causing the component loader to generate a stub object capable of executing the client-side adapter,
If it is determined to be executed on the client, make the client application basic part execute the process using the server component itself,
A distributed system that accesses the server component generated on the server host through the stub object and the server-side adapter and executes the process when the server application is determined to execute. 前記サーバ及び前記クライアントの負荷情報、前記サーバ及び前記クライアントの処理能力に関する情報、前記サーバ及び前記クライアントを接続するネットワークの転送速度、又は前記サーバコンポーネントのサイズ情報、又は前記サーバコンポーネントの計算量情報のうち、少なくとも１つ以上を取得し、前記実行位置決定手段に提供するネットワークモニタ手段をさらに具備し、
前記実行位置決定手段は、前記ネットワークモニタ手段から提供された情報に基づいて前記サーバコンポーネントの実行位置を決定する請求項１記載の分散システム。Load information of the server and the client, information on the processing capacity of the server and the client, transfer speed of a network connecting the server and the client, or size information of the server component, or calculation amount information of the server component Among them, further comprising a network monitor means for acquiring at least one or more and providing to the execution position determination means,
2. The distributed system according to claim 1, wherein the execution position determination unit determines an execution position of the server component based on information provided from the network monitor unit. 前記サーバは前記クライアントのユーザ情報又は前記アプリケーション基本部分の識別情報に基づき、当該アプリケーション基本部分の発する処理要求を受け付けるか否かを判定するアクセス制御監視手段を具備し、
前記実行位置決定手段は、前記アクセス制御監視手段の判定結果に基づき、前記サーバコンポーネントを実行させるか否かをも決定する請求項１記載の分散システム。The server includes an access control monitoring unit that determines whether to accept a processing request issued by the application basic part based on the user information of the client or identification information of the application basic part,
The distributed system according to claim 1, wherein the execution position determining unit also determines whether to execute the server component based on a determination result of the access control monitoring unit. 前記サーバコンポーネントは、前記サーバコンポーネント本体と前記クライアント側アダプタとの共通のインターフェースを定義する共通インターフェースをさらに具備する請求項１記載の分散システム。The distributed system according to claim 1, wherein the server component further includes a common interface that defines a common interface between the server component body and the client-side adapter. 前記サーバコンポーネントは、クライアントリソースへアクセスするクライアントリソースアクセス部と、
サーバリソースへアクセスするサーバリソースアクセス部と、
サーバコンポーネント本体がクライアント側で実行される場合に、サーバリソースアクセス部と通信するためのサーバリソースアクセス用クライアント側アダプタ及びサーバリソースアクセス用サーバ側アダプタとをさらに具備する請求項１記載の分散システム。The server component, a client resource access unit that accesses a client resource,
A server resource access unit for accessing server resources;
The distributed system according to claim 1, further comprising a server resource access client-side adapter and a server resource access server-side adapter for communicating with the server resource access unit when the server component body is executed on the client side. 前記サーバコンポーネントは、クライアントリソースへアクセスするクライアントリソースアクセス部と、サーバリソースへアクセスするサーバリソースアクセス部と、サーバコンポーネント本体がクライアント側で実行される場合に、サーバリソースアクセス部と通信するためのサーバリソースアクセス用クライアント側アダプタ及びサーバリソースアクセス用サーバ側アダプタと、サーバコンポーネント本体がサーバ側で実行される場合に、クライアントリソースアクセス部と通信するためのクライアントリソースアクセス用クライアント側アダプタ及びクライアントリソースアクセス用サーバ側アダプタとをさらに具備する請求項１記載の分散システム。The server component includes a client resource access unit for accessing a client resource, a server resource access unit for accessing a server resource, and a server for communicating with the server resource access unit when the server component body is executed on the client side. Resource access client-side adapter and server resource access server-side adapter, and client resource access client-side adapter and client resource access for communicating with the client resource access unit when the server component itself is executed on the server side The distributed system according to claim 1, further comprising a server-side adapter. 請求項１記載の分散システムに用いられるサーバコンポーネントを生成するサーバコンポーネント生成装置であって、
サーバコンポーネントの複数のテンプレートを提供するテンプレート提供手段と、
前記サーバコンポーネントに関する情報を提供する情報提供手段と、
前記テンプレートを組み合わせ、また、テンプレートに前記情報を当てはめることでサーバコンポーネントを生成するプログラム生成手段と、
を具備するサーバコンポーネント生成装置。A server component generation device that generates a server component used in the distributed system according to claim 1 ,
A template providing means for providing a plurality of templates of the server component;
Information providing means for providing information on the server component;
Combining the template, and a program generating means for generating a server component by applying the information to the template,
A server component generation device comprising: 処理の要求を発するアプリケーション基本部分と、コンポーネントローダとを具備するクライアントと、A client including an application basic part that issues a request for processing, and a component loader;
前記アプリケーション基本部分が要求する処理を実行するサーバコンポーネントを管理する管理手段と、前記アプリケーション基本部分からの要求を受け取り、当該処理を実行するサーバコンポーネントを前記クライアント又は前記サーバのいずれで実行するかを決定する実行位置決定手段と、前記アプリケーション基本部分から要求された処理を実行するサーバコンポーネントを前記管理手段から取得し、取得した当該サーバコンポーネントを前記実行位置決定手段における決定結果に従って処理するサーバコンポーネント引渡手段とを具備し、前記サーバコンポーネントは、要求される処理を実装しているサーバコンポーネント本体と、前記サーバと通信を行うクライアント側アダプタ、前記クライアントと通信を行うサーバ側アダプタとを具備するサーバとからなる分散システムの制御方法において、  A management unit that manages a server component that executes a process requested by the application basic unit; and a request that receives a request from the application basic unit and determines whether the server component that executes the process is executed by the client or the server. An execution position determining means for determining, and a server component for obtaining a server component for executing a process requested from the application basic part from the management means, and processing the obtained server component according to a result determined by the execution position determining means. Means, wherein the server component includes a server component main body that implements required processing, a client-side adapter that communicates with the server, and a server-side adapter that communicates with the client. A method of controlling a distributed system comprising a server having a,
クライアントで実行すると決定した場合、サーバコンポーネント本体をクライアントのコンポーネントローダへ送り、コンポーネントローダにサーバコンポーネント本体から実行可能なサーバコンポーネントオブジェクトを生成させるステップと、  Sending the server component body to the client component loader if it is determined to be executed on the client, causing the component loader to generate an executable server component object from the server component body;
サーバで実行すると決定した場合、管理手段から指定されたサーバコンポーネントのクライアント側アダプタとサーバコンポーネント本体を受け取り、サーバコンポーネント本体から実行可能なサーバコンポーネントオブジェクトを生成し、サーバ側アダプタについてのオブジェクトを生成し、処理の要求を発したクライアントのコンポーネントローダへクライアント側アダプタを送り、コンポーネントローダにクライアント側アダプタを実行可能なスタブオブジェクトを生成させるステップとを具備し、  If it is determined to be executed on the server, it receives the client-side adapter and server component of the specified server component from the management means, generates an executable server component object from the server component, and generates an object for the server-side adapter. Sending the client-side adapter to the component loader of the client that issued the processing request, and causing the component loader to generate a stub object that can execute the client-side adapter.
クライアントで実行すると決定した場合、クライアントアプリケーション基本部分にサーバコンポーネント本体を利用して処理を実行させ、  If it is determined to be executed on the client, make the client application basic part execute the process using the server component itself,
サーバで実行すると決定した場合、クライアントアプリーション基本部分にスタブオブジェクト、サーバ側アダプタを通してサーバホスト上に生成されたサーバコンポーネント本体にアクセスし処理を実行させる分散システムの制御方法。  A method of controlling a distributed system in which, when it is decided to execute on a server, a stub object is provided in a basic part of a client application and a server component generated on a server host is accessed and executed through a server-side adapter. コンピュータを動作させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体において、In a computer-readable recording medium recording a program for operating a computer,
前記プログラムは、処理の要求を発するアプリケーション基本部分とコンポーネントローダとを具備するクライアントと共に分散システムを構成するサーバコンピュータを  The program includes a server computer constituting a distributed system together with a client including an application basic part that issues a processing request and a component loader.
前記アプリケーション基本部分が要求する処理を実行するサーバコンポーネントを管理する管理手段と、  Management means for managing a server component that executes a process requested by the application basic part;
前記アプリケーション基本部分からの要求を受け取り、当該処理を実行するサーバコンポーネントを前記クライアント又は前記サーバのいずれで実行するかを決定する実行位置決定手段と、  An execution position determining unit that receives a request from the application basic part and determines whether to execute a server component that executes the process on the client or the server;
前記アプリケーション基本部分から要求された処理を実行するサーバコンポーネントを  A server component that executes a process requested from the application basic part; 前記管理手段から取得し、取得した当該サーバコンポーネントを前記実行位置決定手段における決定結果に従って処理するサーバコンポーネント引渡手段として機能させ、Acquired from the management means, and causes the server component to function as a server component delivery means that processes the acquired server component according to the determination result in the execution position determination means,
前記サーバコンポーネントは、要求される処理を実装しているサーバコンポーネント本体と、前記サーバと通信を行うクライアント側アダプタ、前記クライアントと通信を行うサーバ側アダプタとを具備し、  The server component includes a server component main body that implements required processing, a client-side adapter that communicates with the server, and a server-side adapter that communicates with the client.
前記サーバコンポーネント引渡手段は、  The server component delivery means,
クライアントで実行すると決定した場合、サーバコンポーネント本体をクライアントのコンポーネントローダへ送り、コンポーネントローダにサーバコンポーネント本体から実行可能なサーバコンポーネントオブジェクトを生成させ、  If it is determined to be executed on the client, the server component body is sent to the client component loader, and the component loader generates a server component object executable from the server component body,
サーバで実行すると決定した場合、管理手段から指定されたサーバコンポーネントのクライアント側アダプタとサーバコンポーネント本体を受け取り、サーバコンポーネント本体から実行可能なサーバコンポーネントオブジェクトを生成し、サーバ側アダプタについてのオブジェクトを生成し、処理の要求を発したクライアントのコンポーネントローダへクライアント側アダプタを送り、コンポーネントローダにクライアント側アダプタを実行可能なスタブオブジェクトを生成させ、クライアントアプリーション基本部分にスタブオブジェクト、サーバ側アダプタを通してサーバホスト上に生成されたサーバコンポーネント本体にアクセスし、処理を実行させることを特徴とする記録媒体。  If it is determined to be executed on the server, it receives the client-side adapter and server component of the specified server component from the management means, generates an executable server component object from the server component, and generates an object for the server-side adapter. Sends the client-side adapter to the component loader of the client that issued the processing request, and causes the component loader to generate a stub object that can execute the client-side adapter. A storage medium for accessing a server component main body generated in step (a) to execute processing.
JP24361498A 1998-08-28 1998-08-28 Distributed system, control method thereof, and storage medium Expired - Fee Related JP3558887B2 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP24361498A JP3558887B2 (en) 1998-08-28 1998-08-28 Distributed system, control method thereof, and storage medium
US09/383,963 US6678715B1 (en) 1998-08-28 1999-08-27 Systems and apparatus for switching execution of a process in a distributed system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP24361498A JP3558887B2 (en) 1998-08-28 1998-08-28 Distributed system, control method thereof, and storage medium

Publications (2)

Publication Number Publication Date
JP2000076172A JP2000076172A (en) 2000-03-14
JP3558887B2 true JP3558887B2 (en) 2004-08-25

Family

ID=17106449

Family Applications (1)

Application Number Title Priority Date Filing Date
JP24361498A Expired - Fee Related JP3558887B2 (en) 1998-08-28 1998-08-28 Distributed system, control method thereof, and storage medium

Country Status (2)

Country Link
US (1) US6678715B1 (en)
JP (1) JP3558887B2 (en)

Families Citing this family (45)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7299240B1 (en) 1992-04-10 2007-11-20 Intellisync Corporation Method for translating computer data from one record structure to another
US5684990A (en) * 1995-01-11 1997-11-04 Puma Technology, Inc. Synchronization of disparate databases
US6212529B1 (en) * 1996-11-13 2001-04-03 Puma Technology, Inc. Synchronization of databases using filters
US6044381A (en) * 1997-09-11 2000-03-28 Puma Technology, Inc. Using distributed history files in synchronizing databases
US5943676A (en) 1996-11-13 1999-08-24 Puma Technology, Inc. Synchronization of recurring records in incompatible databases
JP2000172657A (en) * 1998-12-08 2000-06-23 Fujitsu Ltd System and method for distributed processing, computer- readable recording medium with program for computer to execute the same method recorded therein, server device and client device
US7330815B1 (en) 1999-10-04 2008-02-12 Globalenglish Corporation Method and system for network-based speech recognition
US6810429B1 (en) * 2000-02-03 2004-10-26 Mitsubishi Electric Research Laboratories, Inc. Enterprise integration system
FR2810755B1 (en) * 2000-06-27 2003-01-17 Cit Alcatel JAVA INFORMATION MANAGEMENT PROCESS
US7302634B2 (en) * 2001-03-14 2007-11-27 Microsoft Corporation Schema-based services for identity-based data access
US7024662B2 (en) * 2001-03-14 2006-04-04 Microsoft Corporation Executing dynamically assigned functions while providing services
US7359920B1 (en) 2001-04-18 2008-04-15 Intellisync Corporation Communication protocol for synchronization of personal information management databases
US20030014478A1 (en) * 2001-06-29 2003-01-16 Noble Alan C. Dynamically distributed client-server web browser
GB2377775A (en) * 2001-07-18 2003-01-22 Ibm Distributing programs to processing units in a network using information on the capabilities of the units
EP1321853A3 (en) * 2001-12-10 2009-12-23 Sap Ag Dynamic component transfer based on resource negotiations between computer systems
US6782352B2 (en) * 2001-12-28 2004-08-24 Inventec Corporation System and method for monitoring server host operation
US8601096B2 (en) * 2002-05-14 2013-12-03 Motorola Mobility Llc Method and system for multi-modal communication
US9886309B2 (en) * 2002-06-28 2018-02-06 Microsoft Technology Licensing, Llc Identity-based distributed computing for device resources
US7065756B2 (en) * 2002-08-22 2006-06-20 International Business Machines Corporation Optimization of portable operations in a client-server environment
JP4124331B2 (en) * 2002-09-17 2008-07-23 株式会社日立製作所 Virtual volume creation and management method for DBMS
US8489742B2 (en) * 2002-10-10 2013-07-16 Convergys Information Management Group, Inc. System and method for work management
US7620737B2 (en) * 2002-12-12 2009-11-17 Xerox Corporation Methods, apparatus, and program products for abstract applications/components in a ubiquitous computing environment
JP4034312B2 (en) * 2003-03-24 2008-01-16 富士通株式会社 Distributed processing control device, distributed processing control method, and distributed processing control program
JP4769515B2 (en) * 2004-09-07 2011-09-07 株式会社リコー Application execution method, information processing apparatus, image forming apparatus, application execution program, recording medium, and information processing system
US7617503B2 (en) * 2004-09-15 2009-11-10 Verigy (Singapore) Pte. Ltd. Method and apparatus for determining which of two computer processes should perform a function X
JP2006178658A (en) * 2004-12-21 2006-07-06 Fujitsu Ltd Method and program for processing information
US8504999B2 (en) * 2006-10-05 2013-08-06 Palo Alto Research Center Incorporated System and method for transferring code to a data producer
JP5177628B2 (en) * 2007-07-31 2013-04-03 古野電気株式会社 Marine equipment network system terminal and marine equipment network system
US9454410B2 (en) * 2008-03-04 2016-09-27 Microsoft Technology Licensing, Llc Transparent integration of application components
JPWO2009119114A1 (en) * 2008-03-27 2011-07-21 日本電気株式会社 Thin client system and control method thereof
US8578056B1 (en) * 2008-03-31 2013-11-05 Symantec Corporation Optimized application streaming for just in time compiled components
JP2010191482A (en) * 2009-02-13 2010-09-02 Fujitsu Ltd Client server system, client device, and job processing distribution program
US20120102086A1 (en) * 2009-06-22 2012-04-26 Michitaro Miyata Processing node selection system, information processing node, processing execution method and program
JP2011070278A (en) * 2009-09-24 2011-04-07 Nec Personal Products Co Ltd Remote operation system, server device, client device, control method and control program
JP2011180816A (en) * 2010-03-01 2011-09-15 Nec Corp Information processing apparatus, information processing system, information processing method and information processing program
KR101222367B1 (en) * 2010-08-17 2013-01-15 홍운식 Personal computer system for mobile termial user and operating method thereof
JP5569269B2 (en) * 2010-09-06 2014-08-13 ソニー株式会社 Terminal device, information processing system, request destination selection method, and program
CN104684462B (en) * 2012-09-26 2016-08-24 富士胶片株式会社 Medical image management system and medical image management method
GB2508598A (en) * 2012-12-04 2014-06-11 Ibm Splitting the processing logic of a distributed application page between client and server
JP6244771B2 (en) * 2013-09-24 2017-12-13 日本電気株式会社 Information processing system, processing apparatus, distributed processing method, and program
US9986044B2 (en) * 2013-10-21 2018-05-29 Huawei Technologies Co., Ltd. Multi-screen interaction method, devices, and system
US10545749B2 (en) * 2014-08-20 2020-01-28 Samsung Electronics Co., Ltd. System for cloud computing using web components
US9606817B1 (en) * 2015-06-23 2017-03-28 Symantec Corporation Systems and methods for virtualizing internet of things (IoT) devices
US20190205937A1 (en) * 2016-09-27 2019-07-04 Mitsubishi Electric Corporation Information presentation system
JP7251247B2 (en) * 2018-03-29 2023-04-04 株式会社リコー Communication system and communication method

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06326856A (en) * 1993-05-17 1994-11-25 Hitachi Ltd Data recorder and its method
EP0746816B1 (en) 1993-08-03 2001-10-24 Sun Microsystems, Inc. Flexible multi-platform partitioning for computer applications
JP3737560B2 (en) * 1996-04-19 2006-01-18 松下電器産業株式会社 Distributed processing method and system in network
US5928323A (en) * 1996-05-30 1999-07-27 Sun Microsystems, Inc. Apparatus and method for dynamically generating information with server-side software objects
US6026425A (en) * 1996-07-30 2000-02-15 Nippon Telegraph And Telephone Corporation Non-uniform system load balance method and apparatus for updating threshold of tasks according to estimated load fluctuation
US5774660A (en) * 1996-08-05 1998-06-30 Resonate, Inc. World-wide-web server with delayed resource-binding for resource-based load balancing on a distributed resource multi-node network
JPH1153326A (en) * 1997-07-30 1999-02-26 Internatl Business Mach Corp <Ibm> Distribution processing system, client node, server node and distribution processing method
US6223205B1 (en) * 1997-10-20 2001-04-24 Mor Harchol-Balter Method and apparatus for assigning tasks in a distributed server system
US6209018B1 (en) * 1997-11-13 2001-03-27 Sun Microsystems, Inc. Service framework for a distributed object network system
US6324580B1 (en) * 1998-09-03 2001-11-27 Sun Microsystems, Inc. Load balancing for replicated services
US6314447B1 (en) * 1999-10-04 2001-11-06 Sony Corporation System uses local registry and load balancing procedure for identifying processing capabilities of a remote device to perform a processing task

Also Published As

Publication number Publication date
US6678715B1 (en) 2004-01-13
JP2000076172A (en) 2000-03-14

Similar Documents

Publication Publication Date Title
JP3558887B2 (en) Distributed system, control method thereof, and storage medium
JP4035872B2 (en) File format conversion method, file system, information system and electronic commerce system using the same
US20020082858A1 (en) Managing distribution and local execution of computing resources
JP5087456B2 (en) Service providing system and user accommodation device constituting the service providing system
US20030195924A1 (en) Methods and system using a local proxy server to process media data for local area users
US20030120704A1 (en) Method and device to assist in the execution of tasks of parallel jobs
US20080139201A1 (en) Method for Distributing Data, Adapted for Mobile Devices
US7440971B2 (en) Context based access of files by file system to a client based on detection of related files opened by the client
US7062527B1 (en) Management and scheduling of a distributed rendering method and system
KR20040082339A (en) Operating system deployment methods and systems
US20120016915A1 (en) System and method for file copy of cloud method and disk cloning over wide area network
US20100077396A1 (en) Portable storage device for supporting portable computing system and portable computing based system using the same
WO2001082224A2 (en) Distributed rendering
JP4336363B2 (en) Business process execution method, business process execution system, and program
JP2007041888A (en) Database restructuring device and database restructuring program
US7092983B1 (en) Method and system for secure remote distributed rendering
EP0709994A2 (en) Communications management between client and server processes
JPH11312154A (en) Cooperative work aiding system and recording medium thereof
CN102137122A (en) Method and device for downloading data
WO2006043322A1 (en) Server management program, server management method, and server management apparatus
CN115242817A (en) Data access processing method, device, equipment and storage medium
JP3350962B2 (en) Data distribution system and method
JP3907463B2 (en) Computer-readable recording medium and program storing program for managing CAD data
JP2019074954A (en) Information processing device, management server, information processing method, and program
JPH11149449A (en) Method and device for managing data base session and storage medium recording processing therefor

Legal Events

Date Code Title Description
TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20040511

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20040519

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

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

Free format text: PAYMENT UNTIL: 20090528

Year of fee payment: 5

LAPS Cancellation because of no payment of annual fees