(57)【要約】      （修正有）【課題】分散型コマンド処理システム・アプリケーションソフトウェアをより容易に開発する。【解決手段】プログラム生成装置１１は、通信プログラム生成部３１が、クライアント・サーバ間の通信インタフェースの仕様が記述される通信インタフェース記述情報２１に基づいて、クライアントとサーバのそれぞれにおいて実行される、インタフェースの仕様に基づく処理を実行するための通信プログラム２３を生成するとともに、リソース管理データ生成部３２が、クライアントとサーバの各プログラムに通信プログラムを関連付けるための仕様が記述されるリソース記述情報２２に基づいて、クライアントとサーバのそれぞれにおいて参照される、プログラムの関連付けの仕様がプログラム形式のデータとして表現されるリソース管理データ２４を生成する。【選択図】図１
2007164410.tif 000002
【特許請求の範囲】
【請求項１】
コマンドを送信するクライアント、および、前記クライアントからのコマンドを受信して処理するサーバからなる分散型コマンド処理システムにおいて利用されるプログラムの開発を支援する情報処理装置であって、
前記クライアントと前記サーバとの間の通信インタフェースの仕様が記述される通信インタフェース記述情報に基づいて、前記クライアントおよび前記サーバのそれぞれにおいて実行される、前記通信インタフェースの仕様に基づく処理を実行するための通信プログラムを生成する通信プログラム生成手段と、
前記クライアントと前記サーバのそれぞれのアプリケーションプログラムに、前記通信プログラム生成手段により生成された前記通信プログラムを関連付けるための仕様が記述されるリソース記述情報に基づいて、前記クライアントと前記サーバのそれぞれにおいて参照される、前記通信プログラムを関連付けるための仕様がプログラム形式のデータとして表現されるリソース管理データを生成するリソース管理データ生成手段と
を備える情報処理装置。
【請求項２】
前記リソース管理データは、前記通信プログラムと同一のプログラム言語により記述される
請求項１に記載の情報処理装置。
【請求項３】
前記通信インタフェース記述情報は、インタフェース名の定義と、リモート関数の定義の集合を有しており、
前記通信プログラム生成手段は、
前記通信インタフェース記述情報の前記インタフェース名を解析するインタフェース名解析手段と、
前記リモート関数の定義の集合に含まれる各リモート関数の定義を順に処理対象の定義として選択する関数定義選択手段と、
前記クライアント用の前記通信プログラムであるクライアント通信プログラムの、前記関数定義選択手段により選択された前記リモート関数の定義に対応する部分を生成するクライアント通信プログラム生成手段と、
前記サーバ用の前記通信プログラムであるサーバ通信プログラムの、前記関数定義選択手段により選択された前記リモート関数の定義に対応する部分を生成するサーバ通信プログラム生成手段と、
前記クライアント通信プログラムと前記サーバ通信プログラム間で転送されるデータの形式を定義するデータ構造定義の集合である通信プロトコル定義の、前記関数定義選択手段により選択された前記リモート関数の定義に対応する部分を生成する通信プロトコル定義生成手段と
を備え、
前記クライアント通信プログラム生成手段、前記サーバ通信プログラム生成手段、および、前記通信プロトコル定義生成手段は、前記関数定義選択手段が順に選択する各リモート関数の定義のそれぞれについて、前記クライアント通信プログラム、前記サーバ通信プログラム、および前記通信プロトコル定義を生成する
請求項１に記載の情報処理装置。
【請求項４】
前記リソース記述情報は、前記通信プログラムを関連付ける前記アプリケーションプログラムのプログラム名の定義と、前記通信プログラムが使用する通信路の定義の集合を有しており、
前記リソース管理データ生成手段は、
前記リソース記述情報の前記プログラム名を解析するプログラム名解析手段と、
前記通信路の定義の要素の構造を定義するリソース管理データ構造定義を生成するリソース管理データ構造定義生成手段と、
前記通信路の定義の集合に含まれる各通信路の定義を順に処理対象の定義として選択する通信路定義選択手段と、
前記クライアント用の前記リソース管理データであるクライアント・リソース管理データの、前記通信路定義選択手段により選択された前記通信路の定義に対応する部分を生成するクライアント・リソース管理データ生成手段と、
前記サーバ用の前記リソース管理データであるサーバ・リソース管理データの、前記通信路定義選択手段により選択された前記通信路の定義に対応する部分を生成するサーバ・リソース管理データ生成手段と
を備え、
前記クライアント・リソース管理データ生成手段、および前記サーバ・リソース管理データ生成手段は、前記通信路定義選択手段が順に選択する各通信路の定義のそれぞれについて、前記クライアント・リソース管理データ、および前記サーバ・リソース管理データを生成する
請求項１に記載の情報処理装置。
【請求項５】
コマンドを送信するクライアント、および、前記クライアントからのコマンドを受信して処理するサーバからなる分散型コマンド処理システムにおいて利用されるプログラムの開発を支援する情報処理装置の情報処理方法であって、
前記クライアントと前記サーバとの間の通信インタフェースの仕様が記述される通信インタフェース記述情報に基づいて、前記クライアントおよび前記サーバのそれぞれにおいて実行される、前記通信インタフェースの仕様に基づく処理を実行するための通信プログラムを生成し、
前記クライアントと前記サーバのそれぞれのアプリケーションプログラムに、前記通信プログラムを関連付けるための仕様が記述されるリソース記述情報に基づいて、前記クライアントと前記サーバのそれぞれにおいて参照される、前記通信プログラムを関連付けるための仕様がプログラム形式のデータとして表現されるリソース管理データを生成する
ステップを含む情報処理方法。
【請求項６】
コマンドを送信するクライアント、および、前記クライアントからのコマンドを受信して処理するサーバからなる分散型コマンド処理システムにおいて利用されるプログラムの開発を支援する処理をコンピュータに行わせるプログラムであって、
前記クライアントと前記サーバとの間の通信インタフェースの仕様が記述される通信インタフェース記述情報に基づいて、前記クライアントおよび前記サーバのそれぞれにおいて実行される、前記通信インタフェースの仕様に基づく処理を実行するための通信プログラムを生成し、
前記クライアントと前記サーバのそれぞれのアプリケーションプログラムに、前記通信プログラムを関連付けるための仕様が記述されるリソース記述情報に基づいて、前記クライアントと前記サーバのそれぞれにおいて参照される、前記通信プログラムを関連付けるための仕様がプログラム形式のデータとして表現されるリソース管理データを生成する
ステップを含むプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置および方法、並びにプログラムに関し、特に、分散型コマンド処理システムにおける、コマンドを送信するクライアント、および、コマンドを受信して処理するサーバとを実現するためのプログラムの開発を支援し、開発者が、より容易に分散型コマンド処理システムのためのプログラムを生成することができるようにした情報処理装置および方法、並びにプログラムに関する。
【背景技術】
【０００２】
従来、制御プログラムを自動的に更新する方法として様々なものが考えられてきた（例えば、特許文献１乃至特許文献５参照）。例えば、特許文献１には、操作者の入力などのような実行時の定数をもとに最適化されたマシンコードが更に生成され、その最適化されたマシンコードを実行する装置が記載されている。また、特許文献２には、オブジェクト指向言語によって記述されたクラス及びインタフェースの継承メカニズムを利用することにより、データ構造が経時的に変化する（データベース・スキーマ・エボリューション）ような場合であっても、アプリケーションに対して構造化データへのアクセスを許容することができるデータ処理システムが記載されている。さらに、特許文献３には、接続が検知された複数の被制御機器５〜７の固有の情報に基づいて、オブジェクト指向のプログラムを用いた制御情報となる代理オブジェクトの自動生成削除を行うためのオブジェクトを自動生成する機器制御装置が記載されている。また、特許文献４には、サーバコンピュータからクライアントコンピュータにプログラムをインストールする際に、事前にソフトウェアのインストールの許否を判断する方法が記載されている。さらに、特許文献５には、テスト用インタプリタ・プログラムを解析し、ユーザが記述した制御記述ファイルを第２メモリ１４に展開して解釈し、この解釈した結果によりLSIを制御する方法が記載されている。
【０００３】
しかしながら、これらの方法では、プログラムの開発を支援し、開発作業にかかる負荷を軽減させることはできない。特に、分散型コマンド処理システム等における制御プログラムを開発する場合、互いに関連するサーバ用プログラムとクライアント用プログラムの両方を作成しなければならず、開発作業の負荷が大きい。なお、上述したような方法では、このような分散型コマンド処理システムに対する制御プログラムへの適用も考慮されていない。
【０００４】
これらの方法に対して、分散型コマンド処理システムに対するプログラム生成の手法として、遠隔手続き呼び出しRPC(Remote Procedure Call)のプログラムをインタフェース定義から自動生成するrpcgenソフトウェアなどが知られている。
【０００５】
RPCは、サーバが提供するリモートコマンド機能を関数インタフェースに抽象化して見せる技術である。RPCでは、サーバ側のコマンド処理関数に対して、クライアント側にその関数を呼び出すためのスタブ関数を備える。このクライアントのスタブ関数は、関数の識別子やパラメータ等をコマンドパケットのデータに変換してサーバに送信する。サーバは、送信されたコマンドパケットを受信して解析し、該当するコマンド処理関数を実行し、その結果をクライアントに返送する。RPCは、以上のような一連の流れにより、クライアントプログラムが通常のローカルな関数を呼び出す時と同じ手順で、サーバのリモート関数を呼び出すことを可能にする手法である。
【０００６】
rpcgenソフトウェアは、前記リモートコマンドに対する名前、パラメータなどの仕様を示す、特定用途のためのインタフェース記述情報から、スタブ関数、サーバ側処理関数のスケルトンなどのＲＰＣを実現するための通信プログラム一式を生成するものである。このようなrpcgenを利用することにより、コマンドパケット変換、ネットワーク転送などの処理をする通信プログラムが自動作成されるため、プログラム開発者は、その自動生成のためのインタフェース記述情報を作成するだけでよく、クライアントおよびサーバのプログラム開発負荷を軽減することができる。
【特許文献１】特開平１１−１５４０９４号公報
【特許文献２】特開２００１−３３１３１５号公報
【特許文献３】特開２００２−１０３７４号公報
【特許文献４】特開２００２−３１８６９２号公報
【特許文献５】特開２００４−１３３６１４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかしながら、このように自動作成された通信プログラムを、クライアントまたはサーバのアプリケーションプログラムから使用するには、その通信プログラムの制御のためのリソース生成や初期化といった、通信プログラムをアプリケーションプログラムに結合するための付加プログラムを個別に作成する必要があるが、この付加プログラムについては、上述のrpcgenでは作成することができないので、プログラム開発者が手作業で開発を行わなければならず、この付加プログラムの開発により全体の開発作業の負荷が増大してしまう恐れがあった。
【０００８】
本発明は、このような状況に鑑みてなされたものであり、プログラム自動生成の対象範囲を拡大することにより、分散型コマンド処理システム・アプリケーションソフトウェアの開発負荷を軽減させ、生産性を向上させることができるようにするものである。
【課題を解決するための手段】
【０００９】
本発明の一側面は、コマンドを送信するクライアント、および、前記クライアントからのコマンドを受信して処理するサーバからなる分散型コマンド処理システムにおいて利用されるプログラムの開発を支援する情報処理装置であって、前記クライアントと前記サーバとの間の通信インタフェースの仕様が記述される通信インタフェース記述情報に基づいて、前記クライアントおよび前記サーバのそれぞれにおいて実行される、前記通信インタフェースの仕様に基づく処理を実行するための通信プログラムを生成する通信プログラム生成手段と、前記クライアントと前記サーバのそれぞれのアプリケーションプログラムに、前記通信プログラム生成手段により生成された前記通信プログラムを関連付けるための仕様が記述されるリソース記述情報に基づいて、前記クライアントと前記サーバのそれぞれにおいて参照される、前記通信プログラムを関連付けるための仕様がプログラム形式のデータとして表現されるリソース管理データを生成するリソース管理データ生成手段とを備える。
【００１０】
前記リソース管理データは、前記通信プログラムと同一のプログラム言語により記述されるようにすることができる。
【００１１】
前記通信インタフェース記述情報は、インタフェース名の定義と、リモート関数の定義の集合を有しており、前記通信プログラム生成手段は、前記通信インタフェース記述情報の前記インタフェース名を解析するインタフェース名解析手段と、前記リモート関数の定義の集合に含まれる各リモート関数の定義を順に処理対象の定義として選択する関数定義選択手段と、前記クライアント用の前記通信プログラムであるクライアント通信プログラムの、前記関数定義選択手段により選択された前記リモート関数の定義に対応する部分を生成するクライアント通信プログラム生成手段と、前記サーバ用の前記通信プログラムであるサーバ通信プログラムの、前記関数定義選択手段により選択された前記リモート関数の定義に対応する部分を生成するサーバ通信プログラム生成手段と、前記クライアント通信プログラムと前記サーバ通信プログラム間で転送されるデータの形式を定義するデータ構造定義の集合である通信プロトコル定義の、前記関数定義選択手段により選択された前記リモート関数の定義に対応する部分を生成する通信プロトコル定義生成手段とを備え、前記クライアント通信プログラム生成手段、前記サーバ通信プログラム生成手段、および、前記通信プロトコル定義生成手段は、前記関数定義選択手段が順に選択する各リモート関数の定義のそれぞれについて、前記クライアント通信プログラム、前記サーバ通信プログラム、および前記通信プロトコル定義を生成するようにすることができる。
【００１２】
前記リソース記述情報は、前記通信プログラムを関連付ける前記アプリケーションプログラムのプログラム名の定義と、前記通信プログラムが使用する通信路の定義の集合を有しており、前記リソース管理データ生成手段は、前記リソース記述情報の前記プログラム名を解析するプログラム名解析手段と、前記通信路の定義の要素の構造を定義するリソース管理データ構造定義を生成するリソース管理データ構造定義生成手段と、前記通信路の定義の集合に含まれる各通信路の定義を順に処理対象の定義として選択する通信路定義選択手段と、前記クライアント用の前記リソース管理データであるクライアント・リソース管理データの、前記通信路定義選択手段により選択された前記通信路の定義に対応する部分を生成するクライアント・リソース管理データ生成手段と、前記サーバ用の前記リソース管理データであるサーバ・リソース管理データの、前記通信路定義選択手段により選択された前記通信路の定義に対応する部分を生成するサーバ・リソース管理データ生成手段とを備え、前記クライアント・リソース管理データ生成手段、および前記サーバ・リソース管理データ生成手段は、前記通信路定義選択手段が順に選択する各通信路の定義のそれぞれについて、前記クライアント・リソース管理データ、および前記サーバ・リソース管理データを生成するようにすることができる。
【００１３】
本発明の一側面は、コマンドを送信するクライアント、および、前記クライアントからのコマンドを受信して処理するサーバからなる分散型コマンド処理システムにおいて利用されるプログラムの開発を支援する情報処理装置の情報処理方法であって、前記クライアントと前記サーバとの間の通信インタフェースの仕様が記述される通信インタフェース記述情報に基づいて、前記クライアントおよび前記サーバのそれぞれにおいて実行される、前記通信インタフェースの仕様に基づく処理を実行するための通信プログラムを生成し、前記クライアントと前記サーバのそれぞれのアプリケーションプログラムに、前記通信プログラムを関連付けるための仕様が記述されるリソース記述情報に基づいて、前記クライアントと前記サーバのそれぞれにおいて参照される、前記通信プログラムを関連付けるための仕様がプログラム形式のデータとして表現されるリソース管理データを生成するステップを含む。
【００１４】
本発明の一側面は、コマンドを送信するクライアント、および、前記クライアントからのコマンドを受信して処理するサーバからなる分散型コマンド処理システムにおいて利用されるプログラムの開発を支援する処理をコンピュータに行わせるプログラムであって、前記クライアントと前記サーバとの間の通信インタフェースの仕様が記述される通信インタフェース記述情報に基づいて、前記クライアントおよび前記サーバのそれぞれにおいて実行される、前記通信インタフェースの仕様に基づく処理を実行するための通信プログラムを生成し、前記クライアントと前記サーバのそれぞれのアプリケーションプログラムに、前記通信プログラムを関連付けるための仕様が記述されるリソース記述情報に基づいて、前記クライアントと前記サーバのそれぞれにおいて参照される、前記通信プログラムを関連付けるための仕様がプログラム形式のデータとして表現されるリソース管理データを生成するステップを含む。
【００１５】
本発明の一側面においては、クライアントとサーバとの間の通信インタフェースの仕様が記述される通信インタフェース記述情報に基づいて、クライアントおよびサーバのそれぞれにおいて実行される、通信インタフェースの仕様に基づく処理を実行するための通信プログラムが生成され、クライアントとサーバのそれぞれのアプリケーションプログラムに、その生成された通信プログラムを関連付けるための仕様が記述されるリソース記述情報に基づいて、クライアントとサーバのそれぞれにおいて参照される、通信プログラムを関連付けるための仕様がプログラム形式のデータとして表現されるリソース管理データが生成される。
【発明の効果】
【００１６】
本発明の側面によれば、情報を処理することができる。特に、開発者が、分散型コマンド処理システム・アプリケーションソフトウェアをより容易に開発することができる。
【発明を実施するための最良の形態】
【００１７】
以下に本発明の実施の形態を説明するが、本発明の構成要件と、発明の詳細な説明に記載の実施の形態との対応関係を例示すると、次のようになる。この記載は、本発明をサポートする実施の形態が、発明の詳細な説明に記載されていることを確認するためのものである。従って、発明の詳細な説明中には記載されているが、本発明の構成要件に対応する実施の形態として、ここには記載されていない実施の形態があったとしても、そのことは、その実施の形態が、その構成要件に対応するものではないことを意味するものではない。逆に、実施の形態が構成要件に対応するものとしてここに記載されていたとしても、そのことは、その実施の形態が、その構成要件以外の構成要件には対応しないものであることを意味するものでもない。
【００１８】
さらに、この記載は、本明細書に記載されている発明の全てを意味するものではない。換言すれば、この記載は、本明細書に記載されている発明であって、この出願では請求されていない発明の存在、すなわち、将来、分割出願されたり、補正により追加されたりする発明の存在を否定するものではない。
【００１９】
本発明の一側面は、コマンドを送信するクライアント（例えば、図２１のクライアントノード）、および、前記クライアントからのコマンドを受信して処理するサーバ（例えば、図２１のサーバノード）からなる分散型コマンド処理システム（例えば、図２１の分散型コマンド処理システム）において利用されるプログラムの開発を支援する情報処理装置（例えば、図１のプログラム生成装置）であって、前記クライアントと前記サーバとの間の通信インタフェースの仕様が記述される通信インタフェース記述情報（例えば、図１の通信インタフェース記述情報）に基づいて、前記クライアントおよび前記サーバのそれぞれにおいて実行される、前記通信インタフェースの仕様に基づく処理を実行するための通信プログラム（例えば、図１の通信プログラム）を生成する通信プログラム生成手段（例えば、図１の通信プログラム生成部）と、前記クライアントと前記サーバのそれぞれのアプリケーションプログラム（例えば、図１７のアプリケーション・ソースプログラム）に、前記通信プログラム生成手段により生成された前記通信プログラムを関連付けるための仕様が記述されるリソース記述情報（例えば、図１のリソース記述情報）に基づいて、前記クライアントと前記サーバのそれぞれにおいて参照される、前記通信プログラムを関連付けるための仕様がプログラム形式のデータとして表現されるリソース管理データ（例えば、図１のリソース管理データ）を生成するリソース管理データ生成手段（例えば、図１のリソース管理データ生成部）とを備える。
【００２０】
前記リソース管理データは、前記通信プログラムと同一のプログラム言語により記述される（例えば、図７乃至図９の記述例と図１３の記述例）ようにすることができる。
【００２１】
前記通信インタフェース記述情報は、インタフェース名の定義（例えば、図４の通信インタフェース属性情報）と、リモート関数の定義の集合（例えば、図４のリモート関数インタフェース定義情報）を有しており、前記通信プログラム生成手段は、前記通信インタフェース記述情報の前記インタフェース名を解析するインタフェース名解析手段（例えば、図２のインタフェース名解析部）と、前記リモート関数の定義の集合に含まれる各リモート関数の定義を順に処理対象の定義として選択する関数定義選択手段（例えば、図２の関数定義選択部）と、前記クライアント用の前記通信プログラムであるクライアント通信プログラムの、前記関数定義選択手段により選択された前記リモート関数の定義に対応する部分を生成するクライアント通信プログラム生成手段（例えば、図２のクライアント通信プログラム生成部）と、前記サーバ用の前記通信プログラムであるサーバ通信プログラムの、前記関数定義選択手段により選択された前記リモート関数の定義に対応する部分を生成するサーバ通信プログラム生成手段（例えば、図２のサーバ通信プログラム生成部）と、前記クライアント通信プログラムと前記サーバ通信プログラム間で転送されるデータの形式を定義するデータ構造定義の集合である通信プロトコル定義の、前記関数定義選択手段により選択された前記リモート関数の定義に対応する部分を生成する通信プロトコル定義生成手段（例えば、図２の通信プロトコル定義生成部）とを備え、前記クライアント通信プログラム生成手段、前記サーバ通信プログラム生成手段、および、前記通信プロトコル定義生成手段は、前記関数定義選択手段が順に選択する各リモート関数の定義のそれぞれについて、前記クライアント通信プログラム、前記サーバ通信プログラム、および前記通信プロトコル定義を生成するようにすることができる。
【００２２】
前記リソース記述情報は、前記通信プログラムを関連付ける前記アプリケーションプログラムのプログラム名の定義（例えば、図１０のリソース属性情報）と、前記通信プログラムが使用する通信路の定義の集合（例えば、図１０の通信リソース定義情報）を有しており、前記リソース管理データ生成手段は、前記リソース記述情報の前記プログラム名を解析するプログラム名解析手段（例えば、図３のプログラム名解析部）と、前記通信路の定義の要素の構造を定義するリソース管理データ構造定義を生成するリソース管理データ構造定義生成手段（例えば、図３のリソース管理データ構造定義生成部）と、前記通信路の定義の集合に含まれる各通信路の定義を順に処理対象の定義として選択する通信路定義選択手段（例えば、図３の通信ポート定義選択部）と、前記クライアント用の前記リソース管理データであるクライアント・リソース管理データの、前記通信路定義選択手段により選択された前記通信路の定義に対応する部分を生成するクライアント・リソース管理データ生成手段（例えば、図３のクライアント・リソース管理データ生成部）と、前記サーバ用の前記リソース管理データであるサーバ・リソース管理データの、前記通信路定義選択手段により選択された前記通信路の定義に対応する部分を生成するサーバ・リソース管理データ生成手段（例えば、図３のサーバ・リソース管理データ生成部）とを備え、前記クライアント・リソース管理データ生成手段、および前記サーバ・リソース管理データ生成手段は、前記通信路定義選択手段が順に選択する各通信路の定義のそれぞれについて、前記クライアント・リソース管理データ、および前記サーバ・リソース管理データを生成するようにすることができる。
【００２３】
本発明の一側面は、コマンドを送信するクライアント（例えば、図２１のクライアントノード）、および、前記クライアントからのコマンドを受信して処理するサーバ（例えば、図２１のサーバノード）からなる分散型コマンド処理システム（例えば、図２１の分散型コマンド処理システム）において利用されるプログラムの開発を支援する情報処理装置（例えば、図１のプログラム生成装置）の情報処理方法またはプログラムであって、前記クライアントと前記サーバとの間の通信インタフェースの仕様が記述される通信インタフェース記述情報（例えば、図１の通信インタフェース記述情報）に基づいて、前記クライアントおよび前記サーバのそれぞれにおいて実行される、前記通信インタフェースの仕様に基づく処理を実行するための通信プログラム（例えば、図１の通信プログラム）を生成し（例えば、図１４のステップＳ１）、前記クライアントと前記サーバのそれぞれのアプリケーションプログラム（例えば、図１７のアプリケーション・ソースプログラム）に、前記通信プログラムを関連付けるための仕様が記述されるリソース記述情報（例えば、図１のリソース記述情報）に基づいて、前記クライアントと前記サーバのそれぞれにおいて参照される、前記通信プログラムを関連付けるための仕様がプログラム形式のデータとして表現されるリソース管理データ（例えば、図１のリソース管理データ）を生成する（例えば、図１４のステップＳ２）ステップを含む。
【００２４】
次に、本発明を適用した実施の形態について、図面を参照して説明する。
【００２５】
図１は、本発明を適用したプログラム生成装置の構成例を示すブロック図である。
【００２６】
図１において、プログラム生成装置１１は、クライアント・サーバ間の通信インタフェースの仕様が記述される通信インタフェース記述情報２１、および、クライアントとサーバの各プログラムに通信プログラムを関連付けるための仕様が記述されるリソース記述情報２２を入力し、その通信インタフェースの仕様に基づく処理を実行するための通信プログラム２３、および、プログラム間の関連付けの仕様が、通信プログラム２３と同じプログラム言語で記述されたプログラム形式のデータとして表現されるリソース管理データ２４を生成して出力する装置であり、通信プログラム生成部３１およびリソース管理データ生成部３２を有している。
【００２７】
つまり、プログラム生成装置１１は、通信プログラム生成部３１が通信インタフェース記述情報２１に基づいて、クライアントとサーバのそれぞれにおいて実行される通信プログラム２３を生成するとともに、リソース管理データ生成部３２がリソース記述情報２２に基づいて、クライアントとサーバのそれぞれにおいて参照されるリソース管理データ２４を生成する。
【００２８】
このように、プログラム生成装置１１が、クライアントおよびサーバの両方において参照されるリソース管理データ２４を生成することにより、開発者は、通信プログラム２３を各アプリケーションプログラムに結合するための付加プログラムを個別に作成する必要がなくなり、分散型コマンド処理システム・アプリケーションソフトウェアをより容易に開発することができる。つまり、プログラム生成装置１１は、分散型コマンド処理システム・アプリケーションソフトウェアの開発における、開発者の負荷を軽減し、生産性を向上させることができる。
【００２９】
図２は、図１の通信プログラム生成部３１の詳細な構成例を示すブロック図である。
【００３０】
図２において、通信プログラム生成部３１は、インタフェース名解析部４１、関数定義選択部４２、クライアント通信プログラム生成部４３、サーバ通信プログラム生成部４４、通信プロトコル定義生成部４５、およびバージョン情報埋込部４６を有している。
【００３１】
インタフェース名解析部４１は、プログラム生成装置１１に入力された通信インタフェース記述情報２１を解析することにより、そこに含まれるインタフェース名を取得する。関数定義選択部４２は、通信インタフェース記述情報２１の記述の中から、処理対象とする関数定義の記述を、所定の単位毎に（例えば１つずつ）、順に選択する。
【００３２】
クライアント通信プログラム生成部４３は、関数定義選択部４２により選択された関数定義の記述を解析し、クライアント用の通信プログラムの、その関数定義に対応する部分を生成する。サーバ通信プログラム生成部４４は、関数定義選択部４２により選択された関数定義の記述を解析し、サーバ用の通信プログラムの、その関数定義に対応する部分を生成する。通信プロトコル定義生成部４５は、関数定義選択部４２により選択された関数定義の記述を解析し、通信プロトコル定義の、その関数定義に対応する部分を生成する。このとき、関数識別番号を、本繰り返し処理における繰り返しカウント数とすることにより、関数リスト中の複数の関数に対して異なる番号を割り当てることが可能になる。
【００３３】
バージョン情報埋込部４６は、通信プログラム２３に、通信インタフェース記述情報２１に含まれるバージョン情報を埋め込む（付加する）。これにより、後述するように、通信プログラム実行時に、サーバとクライアントが、互いの通信プログラムのバージョンを確認し、互換性を確認してから安全に通信を確立させるようにすることができる。
【００３４】
図３は、図１のリソース管理データ生成部３２の詳細な構成例を示すブロック図である。
【００３５】
図３において、リソース管理データ生成部３２は、プログラム名解析部５１、リソース管理データ構造定義生成部５２、通信ポート定義選択部５３、クライアント・リソース管理データ生成部５４、およびサーバ・リソース管理データ生成部５５を有している。
【００３６】
プログラム名解析部５１は、プログラム生成装置１１に入力されたリソース記述情報２２を解析して、通信プログラムを関連付けるアプリケーションプログラムのプログラム名を取得する。リソース管理データ構造定義生成部５２は、リソース記述情報２２に基づいてリソース管理データ構造定義を生成する。
【００３７】
通信ポート定義選択部５３は、リソース記述情報２２に含まれる、通信プログラムが使用する通信路である通信ポートを定義する通信ポート定義群の中から、処理対象とする通信ポート定義を、所定の単位毎に（例えば１つずつ）、順に選択する。クライアント・リソース管理データ生成部５４は、通信ポート定義選択部５３により選択された通信ポート定義を解析して、クライアント用のリソース管理データの、その通信ポート定義に対応する部分を生成する。サーバ・リソース管理データ生成部５５は、通信ポート定義選択部５３により選択された通信ポート定義を解析して、サーバ用のリソース管理データの、その通信ポート定義に対応する部分を生成する。
【００３８】
図４は、図１の通信インタフェース記述情報２１の構成例を示す模式図である。
【００３９】
図４において、通信インタフェース記述情報２１は、この通信インタフェース記述に関する共通パラメータを定義する通信インタフェース属性情報１０１と、サーバが提供する（クライアントにより実行されるサーバのコマンドである）リモートコマンドを関数形式で表現する関数定義情報の集合であるリモート関数インタフェース定義情報１０２を含む。リモート関数インタフェース定義情報１０２は、例えば、関数１の定義情報１１１、関数２の定義情報１１２、・・・のように、それぞれが互いに異なるリモート関数について定義する関数定義情報群を含む。各関数定義情報は、図４に示されるように、リモート関数の名前を定義する関数名１２１、要求に関するパラメータを定義するリクエストパラメータ定義１２２、および要求に対する応答に関するパラメータを定義するリプライパラメータ定義１２３の各情報により構成される。
【００４０】
図５は、この通信インタフェース記述情報２１の具体的な記述例を示す図である。なお、図５において、各行の左端の数字は、各行の行番号を示しており、説明のために設けたものである。つまり、実際の記述においては不要である。
【００４１】
図５において、通信インタフェース記述情報２１は、例えば、XML（eXtensible Markup Language）等のタグによる構造化データで表現した例であり、この記述は、１行目の通信インタフェース開始タグ「<通信インタフェース>」と、Ｎ行目（Ｎは整数。Ｎ≧２０）の通信インタフェース終了タグ「</通信インタフェース>」により挟み込まれている。この通信インタフェース記述情報２１の場合、２行目乃至６行目に通信インタフェース属性情報１０１が記述され、７行目乃至（Ｎ−１）行目にリモート関数インタフェース定義情報１０２が記述されている。
【００４２】
通信インタフェース属性情報１０１として、２行目には、インタフェース名開始タグ「<インタフェース名>」とインタフェース名終了タグ「</インタフェース名>」に挟まれて、インタフェース名「remoteHello」が記述されている。３行目のバージョン番号開始タグ「<バージョン番号>」と、６行目のバージョン番号終了タグ「</バージョン番号>」とに挟まれて、４行目および５行目には、２段階のバージョン番号が記述されている。つまり、４行目には、メジャーバージョン開始タグ「<Major Version>」と、メジャーバージョン終了タグ「</Major Version>」に挟まれて、メジャーバージョン番号「１．００」が記述され、５行目には、マイナーバージョン開始タグ「<Minor Version>」と、マイナーバージョン終了タグ「</Minor Version>」に挟まれて、マイナーバージョン番号「０．０１」が記述されている。
【００４３】
バージョン番号は、この通信インタフェース記述情報２１（および通信プログラム２３）の更新状況（またはリリース回数）を示す番号であり、主に開発者により付される番号である。その値は、通常の場合、更新の度に所定単位ずつインクリメントされる。マイナーバージョン番号は、例えばバグの修正やライブラリの追加等、改変内容が比較的小さい更新を示し、メジャーバージョン番号は、例えば、機能の追加やインタフェースの変更等、改変内容が比較的大きな更新を示す。例えば、上位互換性を持った更新の場合、マイナーバージョンが更新され、上位互換を維持できない更新の場合メジャーバージョンが更新されるようにする。
【００４４】
なお、このバージョン番号は何段階で示されるようにしてもよく、１つのバージョン番号で表すようにしてもよいし、３段階以上で表すようにしてもよい。また、各バージョン番号の値は、どのような値であってもよく、また、１回のインクリメントの単位もいくつであってもよい。以下においては、説明の便宜上、メジャーバージョン番号は整数値（自然数）で示され、マイナーバージョン番号は２桁の少数値（０より大きく１より小さい値）で示されるものとする。
【００４５】
図５の例の場合、通信インタフェース記述情報２１のメジャーバージョン番号は「１」であり、マイナーバージョン番号は、「０．０１」である。すなわち、通信インタフェース記述情報２１のバージョン番号は、「１．０１」である。
【００４６】
このようなバージョン番号は、後述するように通信プログラム２３に埋め込まれ、プログラム実行時の相互互換性確認に利用される。
【００４７】
また、図５の例の場合、リモート関数インタフェース定義情報１０２として、それぞれ関数を定義する関数定義のリストが、７行目のリモート関数リスト開始タグ「<リモート関数リスト>」と、（Ｎ−１）行目のリモート関数リスト終了タグ「</リモート関数リスト>」に挟まれて記述されている。リモート関数リストに含まれる各関数定義は、８行目乃至１８行目に示されるように、関数定義開始タグ「<関数>」（８行目）と関数定義終了タグ「</関数>」（１８行目）に挟まれて記述されている。
【００４８】
この８行目乃至１８行目の関数定義においては、９行目に関数名「hello」が、関数名開始タグ「<関数名>」と関数名終了タグ「</関数名>」に挟まれて記述されており、この関数において要求に用いられるリクエストパラメータについての情報が１０行目のリクエストパラメータリスト開始タグ「<リクエストパラメータリスト>」と１３行目のリクエストパラメータリスト終了タグ「</リクエストパラメータリスト>」に挟まれて、１１行目および１２行目に記述されている。
【００４９】
また、この関数において応答に用いられるリプライパラメータについての情報が１４行目のリプライパラメータリスト開始タグ「<リプライパラメータリスト>」と１７行目のリプライパラメータリスト終了タグ「</リプライパラメータリスト>」に挟まれて、１５行目および１６行目に記述されている。
【００５０】
つまり、図５に示される記述例においては、インタフェース名「remoteHello」の通信インタフェースが、リモートコマンド「hello」を備えており、この「hello」コマンド(関数)は、リクエストパラメータとして「int」型の「foo」と、「string」型の「bar」を受け取り、リプライパラメータとして「int」型の「ret1」と、「string」型の「ret2」を返す仕様であることが定義されている。
【００５１】
なお、関数定義が複数記述される場合、その他の関数定義は、１９行目乃至（Ｎ−２）行目に、上述の「hello」の場合と同様に記述される。
【００５２】
図６は、図１の通信プログラム２３の構成例を示す模式図である。
【００５３】
図６において、通信プログラム２３は、クライアントにおいて実行されるクライアント通信プログラム１５１、サーバにおいて実行されるサーバ通信プログラム１５２、および、クライアント・サーバ間の通信プロトコルを定義する通信プロトコル定義１５３を含む。クライアント通信プログラム１５１は、リモート関数１を呼び出すスタブ関数１６１、リモート関数２を呼び出すスタブ関数１６２、・・・のように、サーバの各リモートコマンドに対するスタブ関数の集合である。サーバ通信プログラム１５２は、リモート関数１のスケルトン関数１７１、リモート関数２のスケルトン関数１７２、・・・のように、基本的に関数インタフェースを定義するための基底の役割を果たすスケルトン関数の集合である。通信プロトコル定義１５３は、リモート関数１のプロトコル定義１８１、リモート関数２のプロトコル定義１８２、・・・のように、クライアント通信プログラムとサーバ通信プログラム間で転送されるデータの形式を定義するデータ構造定義の集合である。
【００５４】
プログラム生成装置１１は、各リモートコマンドに対して、スタブ関数、スケルトン関数、およびプロトコル定義を１つの組み合わせとして生成する。
【００５５】
図７は、通信プログラム２３のクライアント通信プログラム１５１の記述例を示す図である。図７の記述例は、図５に記述例が示される通信インタフェース記述情報２１より、プログラム生成装置１１の通信プログラム生成部３１が生成する通信プログラム２３に含まれるクライアント通信プログラム１５１を、Ｃ言語風の擬似的なプログラミング言語によって表現した例である。なお、図７において、各行の左端の数字は、各行の行番号を示しており、説明のために設けたものである。つまり、実際の記述においては不要である。
【００５６】
図７において、クライアント通信プログラム１５１の１行目乃至１１行目には、インタフェース名「remoteHello」のリモート関数「hello」を呼び出すスタブ関数が記述されている。１行目の記述は、スタブ関数のインタフェース定義文である。この１行目においては、インタフェース名「remoteHello」と、リモート関数名「hello」を”_（アンダーバー）”によって連結した文字列が関数名となり、リクエストパラメータとしては、通信ポートを示すための識別子であるcid_t型のresid、図５においてリモート関数インタフェース定義情報１０２のリクエストパラメータリストに記述された「int」型の「foo」と「string」型の「bar」を受け取ることが定義されている。
【００５７】
２行目と１１行目に記述された中括弧（”｛”および”｝”）に挟まれた記述の内、３行目および４行目の記述は、関数内ローカル変数の宣言文であり、サーバに対するリモート関数呼び出し情報の格納領域を「remoteHello_hello_request_rec」型の「req」、サーバからのリプライ情報格納領域を「remoteHello_hello_reply_rec」型の「reply」として定義している。５行目乃至７行目の記述は、リモート関数「hello」の呼び出し情報を設定する文であり、リモート関数「hello」の関数識別番号、並びに、本スタブ関数のパラメータ「foo」および「bar」が設定されている。８行目の記述は、「req」をサーバへ送信する文である。ここでは、「resid」と「req」をパラメータとして、「サーバへリクエスト送信」という補助関数を呼び出すようになされている。９行目の記述は、サーバからのリプライを「reply」に受信する文である。ここでは、「resid」と「reply」をパラメータとして、「サーバからリプライ受信」という補助関数を呼び出すようになされている。１０行目の記述は、受信したリプライデータを呼び出し元にリターンすることを示す文である。
【００５８】
他の関数に対するスタブ関数が続く場合、上述したリモート関数「hello」の場合と同様の方法により、１２行目乃至Ｎ−４行目に記述される。
【００５９】
なお、Ｎ−３乃至Ｎ行目には、バージョン情報埋込部４６により、図５の３行目乃至６行目に記述例が示されるバージョン情報が解析された、通信インタフェース記述情報２１（通信プログラム２３）のバージョン情報が埋め込まれている。つまり、このクライアント通信プログラム１５１のバージョン番号は、「１．０１」である。
【００６０】
図８は、通信プログラム２３のサーバ通信プログラム１５２の記述例を示す図である。図８の記述例は、図５に記述例が示される通信インタフェース記述情報２１より、プログラム生成装置１１の通信プログラム生成部３１が生成する通信プログラム２３に含まれるサーバ通信プログラム１５２を、Ｃ言語風の擬似的なプログラミング言語によって表現した例である。なお、図８において、各行の左端の数字は、各行の行番号を示しており、説明のために設けたものである。つまり、実際の記述においては不要である。
【００６１】
図８において、サーバ通信プログラム１５２の１行目乃至１１行目には、インタフェース名「remoteHello」のリモート関数「hello」のスケルトン関数が記述されている。１行目の記述は、スケルトン関数のインタフェース定義文である。この１行目においては、インタフェース名「remoteHello」と、リモート関数名「hello」を”_（アンダーバー）”によって連結した文字列が関数名となり、リクエストパラメータとしては、通信ポートを示すための識別子であるsid_t型のresid、図５においてリモート関数インタフェース定義情報１０２のリクエストパラメータリストに記述された「int」型の「foo」と「string」型の「bar」を受け取ることが定義されている。
【００６２】
２行目と８行目に記述された中括弧（”｛”および”｝”）に挟まれた記述の内、３行目の記述は、関数内ローカル変数の宣言文であり、クライアントに対するリプライ情報格納領域を「remoteHello_hello_reply_rec」型の「reply」として定義している。４行目および５行目の記述は、アプリケーション固有の処理を記述する部分であり、「reply」への値を設定するものである。具体的には、通信インタフェース記述情報２１のリプライパラメータリスト（図５の記述例の場合、１４行目乃至１７行目）に記述された、「int」型の「ret1」と「string」型の「ret2」に対してリプライデータが設定されている。６行目の記述は、「reply」の種別を示すために、このリモート関数の関数識別番号を設定する文である。７行目の記述は、「reply」をクライアントへ返信する文であり、「resid」と「reply」をパラメータとして、”クライアントへ返信”という補助関数を呼び出すことにより実現している。
【００６３】
他の関数に対するスケルトン関数が続く場合、上述したリモート関数「hello」の場合と同様の方法により、９行目乃至Ｎ−４行目に記述される。
【００６４】
なお、Ｎ−３乃至Ｎ行目には、バージョン情報埋込部４６により、図５の３行目乃至６行目に記述例が示されるバージョン情報が解析された、通信インタフェース記述情報２１（通信プログラム２３）のバージョン情報が埋め込まれている。つまり、このサーバ通信プログラム１５２のバージョン番号は、「１．０１」である。
【００６５】
図９は、通信プログラム２３の通信プロトコル定義１５３の記述例を示す図である。図９の記述例は、図５に記述例が示される通信インタフェース記述情報２１より、プログラム生成装置１１の通信プログラム生成部３１が生成する通信プログラム２３に含まれる通信プロトコル定義１５３を、Ｃ言語風の擬似的なプログラミング言語によって表現した例である。なお、図９において、各行の左端の数字は、各行の行番号を示しており、説明のために設けたものである。つまり、実際の記述においては不要である。
【００６６】
図９において、通信プロトコル定義１５３の１行目の記述は、リモート関数「hello」の関数識別番号を定義する文であり、インタフェース名「remoteHello」、リモート関数名「hello」、およびパラメータ修飾子「cmd」を”_（アンダーバー）”によって連結した文字列を関数識別番号の名前としている。
【００６７】
２行目乃至６行目の記述は、クライアントからサーバに送信されるリモート関数呼び出し情報の構造を定義する文であり、２行目の記述において、インタフェース名「remoteHello」、リモート関数名「hello」、およびパラメータ修飾子「request_rec」を”_（アンダーバー）”によって連結した文字列を構造名としている。２行目と６行目に記述された中括弧（”｛”および”｝”）に挟まれた３行目乃至５行目の記述は、クライアントがサーバのリモート関数を呼び出す際に設定されるパラメータを定義する部分である。図９の例の場合、関数識別番号「cmd」に続いて、通信インタフェース記述情報２１のリクエストパラメータリスト（図５の記述例の場合、１０行目乃至１３行目）に記述された、「int」型の「foo」と「string」型の「bar」が定義されている。
【００６８】
７行目乃至１１行目の記述は、サーバからクライアントに返信されるリプライ情報の構造を定義する文であり、３行目の記述において、インタフェース名「remoteHello」、リモート関数名「hello」、およびパラメータ修飾子「reply_rec」を”_（アンダーバー）”によって連結した文字列を構造名としている。７行目と１１行目に記述された中括弧（”｛”および”｝”）に挟まれた８行目乃至１０行目の記述は、サーバのリモート関数が処理結果をクライアントに返信する際に設定されるパラメータを定義する部分である。図９の例の場合、関数識別番号「cmd」に続いて、通信インタフェース記述情報２１のリプライパラメータリスト（図５の記述例の場合、１４行目乃至１７行目）に記述された、「int」型の「ret1」と「string」型の「ret2」が定義されている。
【００６９】
他の関数に対する通信プロトコル定義が続く場合、上述したリモート関数「hello」の場合と同様の方法により、１２行目以降に記述される。
【００７０】
図１０は、図１のリソース記述情報２２の構成例を示す模式図である。
【００７１】
図１０において、リソース記述情報２２は、このリソース記述に関する共通パラメータを定義するリソース属性情報２０１、および、クライアント用のアプリケーションプログラムまたはサーバ用のアプリケーションプログラムと、通信プログラム２３との関連付けを示す定義情報である通信リソース定義情報２０２を含む。
【００７２】
通信リソース定義情報２０２は、例えば、クライアント通信ポート１の定義情報２１１、クライアント通信ポート２の定義情報２１２、・・・のように、それぞれがクライアントの互いに異なる通信ポートについて定義するクライアント通信ポート定義情報群と、サーバ通信ポート１の定義情報２２１、サーバ通信ポート２の定義情報２２２、・・・のように、それぞれがサーバの互いに異なる通信ポートについて定義するサーバ通信ポート定義情報群とを含む。各通信ポート定義情報は、図１０に示されるように、通信ポート名２３１、通信インタフェース名２３２、通信ポートタイプ２３３、および接続先アドレス２３４により構成される。通常、クライアント通信ポート定義情報はクライアント用のアプリケーションプログラムに対する定義において指定し、サーバ通信ポート定義情報はサーバ用のアプリケーションプログラムに対する定義において指定する。
【００７３】
図１１は、このリソース記述情報２２の記述例を示す図である。なお、図１１において、各行の左端の数字は、各行の行番号を示しており、説明のために設けたものである。つまり、実際の記述においては不要である。
【００７４】
図１１において、リソース記述情報２２は、例えば、XML等のタグによる構造化データで表現した例であり、この記述は、１行目のプログラムリソース開始タグ「<プログラムリソース>」と、Ｎ行目（Ｎは整数。Ｎ≧１７）のプログラムリソース終了タグ「</プログラムリソース>」により挟み込まれている。このリソース記述情報２２の場合、２行目にリソース属性情報２０１が記述され、３行目乃至（Ｎ−１）行目に通信リソース定義情報２０２が記述されている。
【００７５】
リソース属性情報２０１として、２行目には、プログラム名開始タグ「<プログラム名>」とプログラム名終了タグ「</プログラム名>」に挟まれて、プログラム名「client」が記述されている。つまり、このリソース記述情報２２がプログラム名「client」のプログラムに通信プログラム２３を関連付けるための記述であることが示されている。
【００７６】
通信リソース定義情報２０２として、通信ポートを定義する通信ポートのリストが、３行目の通信ポートリスト開始タグ「<通信ポートリスト>」と、（Ｎ−１）行目の通信ポートリスト終了タグ「</通信ポートリスト>」に挟まれて記述されている。通信ポートリストに含まれる各通信ポート定義は、それぞれ、通信ポート定義開始タグ「<通信ポート>」と通信ポート定義終了タグ「</通信ポート>」に挟まれて記述されている。図１１の記述例の場合、４行目乃至１５行目に２つの通信ポート定義（４行目乃至９行目、および１０行目乃至１５行目）が記述されている。
【００７７】
４行目の通信ポート定義開始タグ「<通信ポート>」と９行目の通信ポート定義終了タグ「</通信ポート>」に挟まれた通信ポート定義においては、５行目において、通信ポート名２３１として、通信ポート名「helloClient1」が、通信ポート名開始タグ「<ポート名>」と通信ポート名終了タグ「</ポート名>」に挟まれて記述されており、６行目において、通信インタフェース名２３２として、通信インタフェース名「remoteHello」が、通信インタフェース名開始タグ「<通信インタフェース名>」と通信インタフェース名終了タグ「</通信インタフェース名>」に挟まれて記述されており、７行目において、通信ポートタイプ２３３として、通信ポートタイプ「クライアント」が、通信ポートタイプ開始タグ「<ポートタイプ>」と通信ポートタイプ終了タグ「</ポートタイプ>」に挟まれて記述されており、８行目において、接続アドレス２３４として、接続アドレス「相手ノード名：サーバ側ポート名」が、接続アドレス開始タグ「<接続アドレス>」と接続アドレス終了タグ「</接続アドレス>」に挟まれて記述されている。
【００７８】
また、１０行目の通信ポート定義開始タグ「<通信ポート>」と１５行目の通信ポート定義終了タグ「</通信ポート>」に挟まれた通信ポート定義においては、１１行目において、通信ポート名２３１として、通信ポート名「holaServer1」が、通信ポート名開始タグ「<ポート名>」と通信ポート名終了タグ「</ポート名>」に挟まれて記述されており、１２行目において、通信インタフェース名２３２として、通信インタフェース名「remoteHola」が、通信インタフェース名開始タグ「<通信インタフェース名>」と通信インタフェース名終了タグ「</通信インタフェース名>」に挟まれて記述されており、１３行目において、通信ポートタイプ２３３として、通信ポートタイプ「サーバ」が、通信ポートタイプ開始タグ「<ポートタイプ>」と通信ポートタイプ終了タグ「</ポートタイプ>」に挟まれて記述されており、１４行目において、接続アドレス２３４として、接続アドレス「相手ノード名：クライアント側ポート名」が、接続アドレス開始タグ「<接続アドレス>」と接続アドレス終了タグ「</接続アドレス>」に挟まれて記述されている。
【００７９】
つまり、プログラム（client）において使用される、クライアントタイプの通信ポート「helloClient1」と、サーバタイプの通信ポート「holaServer1」が定義されている。そして、クライアント通信ポート「helloClient1」が、通信インタフェース「remoteHello」を介して接続アドレス（タグ）で示されるサーバ通信ポートに接続することと、サーバ通信ポート「holaServer1」が、通信インタフェース「remoteHola」を介して接続アドレス（タグ）で示されるクライアント通信ポートから接続されることが定義されている。
【００８０】
なお、さらに、他の通信ポート定義が記述される場合、それらは、１６行目乃至（Ｎ−２）行目に、上述の場合と同様に記述される。また、このとき、図１０を参照して説明したように、クライアント通信ポートの定義情報を先にまとめて記述し、その後からサーバ通信ポートの定義情報をまとめて記述するようにしてもよい。つまり、通信ポートリスト開始タグと通信ポートリスト終了タグの間であれば、各通信ポート定義の記述は、どのような順番で記述されるようにしてもよい。
【００８１】
以上の様に、各アプリケーション・プログラムに対して１つのリソース記述情報２２を割り当てることにより、リソース管理データ生成部３２によって、プログラム単位にリソース管理データ２４が生成される。
【００８２】
図１２は、図１のリソース管理データ２４の構成例を示す模式図である。
【００８３】
図１２において、リソース管理データ２４は、リソース管理データ構造定義２５１、クライアント・リソース管理データ２５２、およびサーバ・リソース管理データ２５３を含む。リソース管理データ構造定義２５１は、クライアント・リソース管理データ２５２およびサーバ・リソース管理データ２５３の構造を定義するための記述情報である。クライアント・リソース管理データ２５２は、クライアント通信ポート１のデータ２６１、クライアント通信ポート２のデータ２６２、・・・のように、アプリケーションプログラムにおいて使用するクライアント通信ポートに関するデータの集合である。サーバ・リソース管理データ２５３は、サーバ通信ポート１のデータ２７１、サーバ通信ポート２のデータ２７２、・・・のように、アプリケーションプログラムにおいて使用するサーバ通信ポートに関するデータの集合である。
【００８４】
図１３は、リソース管理データ２４の記述例を示す図である。図１３の記述例は、図１１に記述例が示されるリソース記述情報２２より、プログラム生成装置１１のリソース管理データ生成部３２が生成するリソース管理データ２４を、Ｃ言語風の擬似的なプログラミング言語によって表現した例である。なお、図１３において、各行の左端の数字は、各行の行番号を示しており、説明のために設けたものである。つまり、実際の記述においては不要である。
【００８５】
１行目乃至６行目の記述は、図１２のリソース管理データ構造定義２５１に対応する記述であり、リソース管理データ２４の構造を定義する部分である。１行目の「struct reousrce_manage_rec」の記述により、１行目乃至６行目の記述において定義される構造の名前が、「reousrce_manage_rec」であることが定義されている。図１３の例の場合、１行目と６行目に記述された中括弧（”｛”および”｝”）に挟まれた２行目乃至５行目の記述は、図１２に示される通信ポートリストの各通信ポート定義の要素の構造に対応しており、通信ポート名に対する「port_name」、通信インタフェース名に対する「interface_name」、ポートタイプに対する「type」、接続アドレスに対する「address」が、構造内の要素として定義されている。
【００８６】
７行目乃至１２行目の記述は、図１２のクライアント・リソース管理データ２５２に対応する記述であり、クライアント通信ポートに関するリソース管理データを記述する部分である。７行目において、データ修飾子「res」、プログラム名「client」、ポート名「helloClient1」を”_（アンダーバー）”によって連結した文字列がデータ名として定義されている。図１３の例の場合、７行目と１２行目に記述された中括弧（”｛”および”｝”）に挟まれた８行目乃至１１行目の記述は、リソース管理データの値を定義する記述である。図１３の例の場合、通信リソース定義情報２０２の図１１の記述例（４行目乃至９行目）に対応しており、ポート名の「helloClient1」、通信インタフェース名の「remoteHello」、ポートタイプの「クライアント」、接続アドレスの「相手ノード：サーバ側ポート名」が、本構造の該当する要素の値として、設定されている。
【００８７】
１３行目乃至１８行目の記述は、図１２のサーバ・リソース管理データ２５３に対応する記述であり、サーバ通信ポートに関するリソース管理データを記述する部分である。１３行目において、データ修飾子「res」、プログラム名「client」、ポート名「holaServer1」を”_（アンダーバー）”によって連結した文字列がデータ名として定義されている。図１３の例の場合、１３行目と１８行目に記述された中括弧（”｛”および”｝”）に挟まれた１４行目乃至１７行目の記述は、リソース管理データの値を定義する記述である。図１３の例の場合、通信リソース定義情報２０２の図１１の記述例（１０行目乃至１５行目）に対応しており、ポート名の「holaServer1」、通信インタフェース名の「remoteHola」、ポートタイプの「サーバ」、接続アドレスの「相手ノード：クライアント側ポート名」が、本構造の該当する要素の値として、設定されている。
【００８８】
さらに、他の通信ポート定義が続く場合は、それらは、１９行目以降に、上述の場合と同様に記述される。また、このとき、図１２を参照して説明したように、クライアント通信ポートの定義情報を先にまとめて記述し、その後からサーバ通信ポートの定義情報をまとめて記述するようにしてもよい。つまり、各通信ポートのデータの記述は、どのような順番で記述されるようにしてもよい。
【００８９】
次に、各処理の具体的な流れについて説明する。
【００９０】
図１４は、図１のプログラム生成装置１１によるプログラム生成処理の流れの例を説明するフローチャートである。
【００９１】
例えばユーザが、通信インタフェース記述情報２１およびリソース記述情報２２を入力し、プログラム生成処理の実行を指示すると、プログラム生成装置１１は、プログラム生成処理を開始する。
【００９２】
プログラム生成処理が開始されると、通信プログラム生成部３１は、図１４のステップＳ１において、通信プログラム生成処理を実行し、通信プログラム２３を生成する。通信プログラム生成処理の詳細は後述する。また、図１４のステップＳ２において、リソース管理データ生成部３２は、リソース管理データ生成処理を実行し、リソース管理データ２４を生成する。リソース管理データ生成処理の詳細は後述する。通信プログラム生成処理およびリソース管理データ生成処理が終了すると、プログラム生成装置１１は、生成された通信プログラム２３およびリソース管理データ２４を出力し、プログラム生成処理を終了する。
【００９３】
このように、プログラム生成装置１１が、通信プログラム２３とともにリソース管理データ２４を生成することにより、開発者は、通信プログラムを各アプリケーションプログラムに結合するための付加プログラムを個別に作成する必要がなくなり、分散型コマンド処理システム・アプリケーションソフトウェアをより容易に開発することができる。
【００９４】
次に、通信プログラム生成処理の詳細な流れの例を、図１５のフローチャートを参照して説明する。
【００９５】
通信プログラム生成処理が開始されると、通信プログラム生成部３１のインタフェース名解析部４１（図２）は、ステップＳ２１において、通信インタフェース属性情報１０１を解析することにより、インタフェース名を解析して取得する。例えば、インタフェース名解析部４１は、取得したインタフェース名をif_nameとしている。
【００９６】
ステップＳ２２において、関数定義選択部４２は、未処理の関数定義が存在するか否かを判定し、存在すると判定した場合、処理をステップＳ２３に進め、検出した未処理の関数定義の中から、処理対象とする関数定義を選択する。
【００９７】
処理対象の関数定義が選択されると、クライアント通信プログラム生成部４３は、ステップＳ２４において、処理対象の関数について、スタブ関数を生成することにより、クライアント通信プログラム１５１（関数定義が複数存在する場合は、クライアント通信プログラム１５１の一部）を生成する。ステップＳ２４の処理が終了すると、サーバ通信プログラム生成部４４は、ステップＳ２５において、処理対象の関数について、スケルトン関数を生成することにより、サーバ通信プログラム１５２（関数定義が複数存在する場合は、サーバ通信プログラム１５２の一部）を生成する。ステップＳ２５の処理が終了すると、通信プロトコル定義生成部４５は、ステップＳ２６において、処理対象の関数について、通信プロトコル定義１５３（関数定義が複数存在する場合は、通信プロトコル定義１５３の一部）を生成する。ステップＳ２６の処理が終了すると、通信プロトコル定義生成部４５は、処理をステップＳ２２に戻す。
【００９８】
つまり、ステップＳ２２の処理は、リモート関数リスト内の各関数定義に対する処理を繰り返すための制御処理であり、関数定義選択部４２は、ステップＳ２２において、未処理の関数定義が存在しないと判定するまで、ステップＳ２２乃至ステップＳ２６の処理を繰り返すように制御する。そして、ステップＳ２２において、未処理の関数定義が存在しないと判定した場合、関数定義選択部４２は、処理をステップＳ２７に進める。
【００９９】
ステップＳ２７において、バージョン情報埋込部４６は、通信インタフェース属性情報１０１を解析することにより、バージョン情報を取得し、それを通信プログラムに埋め込む（挿入する）。ステップＳ２７の処理を終了すると、バージョン情報埋込部４６は、生成された通信プログラム２３を通信プログラム生成部３１より出力し、通信プログラム生成処理を終了し、処理を図１４のステップＳ１に戻し、それ以降の処理を実行させる。
【０１００】
以上のように、通信プログラム生成部３１は、ステップＳ２４乃至ステップＳ２６の処理を各リモート関数定義に対して実行し、スタブ関数、スケルトン関数、および通信プロトコル定義を生成する。なお、このように繰返し処理を行うことにより、ステップＳ２６において、図９の１行目に記述例が示される関数識別番号を、ステップＳ２２乃至ステップＳ２６の繰り返し処理における繰り返しカウント数とすることにより、関数リスト中の複数の関数に対して互いに異なる番号を割り当てることができる。
【０１０１】
次に、リソース管理データ生成処理の詳細な流れの例を、図１６のフローチャートを参照して説明する。
【０１０２】
リソース管理データ生成処理が開始されると、リソース管理データ生成部３２のプログラム名解析部５１（図３）は、ステップＳ４１において、リソース記述情報２２のリソース属性情報２０１を解析することにより、プログラム名を解析して取得する。例えば、プログラム名解析部５１は、取得したプログラム名をprog_nameとしている。
【０１０３】
ステップＳ４２において、リソース管理データ構造定義生成部５２は、リソース記述情報２２の通信リソース定義情報２０２の通信ポートリストを解析することにより、リソース管理データ構造定義２５１を生成する。
【０１０４】
ステップＳ４３において、通信ポート定義選択部５３は、未処理の通信ポート定義が存在するか否かを判定し、存在すると判定した場合、処理をステップＳ４４に進め、処理対象とする通信ポート定義を選択する。
【０１０５】
処理対象の通信ポート定義が選択されると、クライアント・リソース管理データ生成部５４は、ステップＳ４５において、処理対象の関数について、クライアント・リソース管理データ２５２（関数定義が複数存在する場合は、クライアント・リソース管理データ２５２の一部）を生成する。ステップＳ４５の処理が終了すると、サーバ・リソース管理データ生成部５５は、ステップＳ４６において、処理対象の関数について、サーバ・リソース管理データ２５３（関数定義が複数存在する場合は、サーバ・リソース管理データ２５３の一部）を生成する。ステップＳ４６の処理が終了すると、サーバ・リソース管理データ生成部５５は、処理をステップＳ４３に戻す。
【０１０６】
つまり、ステップＳ４３の処理は、通信リソース定義情報２０２内の各通信ポート定義に対する処理を繰り返すための制御処理であり、通信ポート定義選択部５３は、ステップＳ４３において、未処理の通信ポート定義が存在しないと判定するまで、ステップＳ４３乃至ステップＳ４６の処理を繰り返すように制御する。そして、ステップＳ４３において、未処理の通信ポート定義が存在しないと判定した場合、通信ポート定義選択部５３は、生成されたリソース管理データ２４をリソース管理データ生成部３２より出力し、リソース管理データ生成処理を終了し、処理を図１４のステップＳ２に戻し、それ以降の処理を実行させる。
【０１０７】
以上のように処理を行うことにより、リソース管理データ生成部３２は、クライアント用のリソース管理データおよびサーバ用のリソース管理データの両方を生成する。なお、このように繰返し処理を行うことにより、リソース管理データ生成部３２は、全ての通信ポートのそれぞれについて、リソース管理データを生成することができる。これにより、開発者は、通信プログラムを各アプリケーションプログラムに結合するための付加プログラムを個別に作成する必要がなくなり、分散型コマンド処理システム・アプリケーションソフトウェアをより容易に開発することができる。
【０１０８】
次に、アプリケーション開発のより具体的な例について説明する。
【０１０９】
図１７は、本発明を適用したアプリケーション開発システムの構成例を示すブロック図である。
【０１１０】
アプリケーション開発システム３００は、開発者が分散型コマンド処理システム・アプリケーションソフトウェアの開発を支援するシステムであり、プロセッサや主記憶装置等を含む装置である情報処理装置３０１と、情報処理装置３０１において動作するプログラムやデータが格納される補助記憶装置３０２を有している。情報処理装置３０１と補助記憶装置３０２は、互いに所定のバス３０３により接続されている。
【０１１１】
情報処理装置３０１は、プログラムが実行されることにより、プログラム生成部３１１、コンパイラ３１２、およびオペレーティングシステム３１３の機能ブロックを有する。つまり、情報処理装置３０１においては、オペレーティングシステム３１３の管理下で、プログラム生成部３１１やコンパイラ３１２等の機能ブロックが動作する。
【０１１２】
プログラム生成部３１１は、図１に示されるプログラム生成装置１１を機能ブロック化したものである。すなわち、プログラム生成部３１１は、プログラム生成装置１１と同様の機能を有し、同様に動作するので、その詳細な説明を省略する。
【０１１３】
コンパイラ３１２は、アプリケーションのソースプログラムをコンパイルし、実行形式に変換したロードモジュールを生成する機能ブロックである。
【０１１４】
補助記憶装置３０２は、所定の記憶領域を有しており、その記憶領域に、情報処理装置３０１に入力されるデータやプログラム、並びに、情報処理装置３０１より出力されるデータやプログラムが格納される（記憶する）。例えば、補助記憶装置３０２は、通信インタフェース記述情報３２１、リソース記述情報３２２、通信プログラム３２３、リソース管理データ３２４、共通ライブラリ３２５、クライアントにおいて実行されるクライアント・プログラム、および、サーバにおいて実行されるサーバ・プログラムの各々のソースであるアプリケーション・ソースプログラム３２６、および、クライアント・プログラムまたはサーバ・プログラムの各々の実行形式となるアプリケーション・ロードモジュール（実行形式）３２７等を記憶する。
【０１１５】
情報処理装置３０１のプログラム生成部３１１は、オペレーティングシステム３１３の管理の下、矢印３３１に示されるように、通信インタフェース記述情報３２１およびリソース記述情報３２２を、バス３０３を介して補助記憶装置３０２より取得し、上述したプログラム生成装置１１（図１）の場合と同様に、通信プログラム３２３およびリソース管理データ３２４を生成する。プログラム生成部３１１は、矢印３３２に示されるように、その生成した通信プログラム３２３およびリソース管理データ３２４を、バス３０３を介して補助記憶装置３０２に供給し、記憶させる。
【０１１６】
コンパイラ３１２は、オペレーティングシステム３１３の管理の下、矢印３３３乃至矢印３３５に示されるように、通信プログラム３２３、リソース管理データ３２４、共通ライブラリ３２５、およびアプリケーション・ソースプログラム３２６を、バス３０３を介して補助記憶装置３０２より取得し、実行形式であるアプリケーション・ロードモジュール３２７を生成する。コンパイラ３１２は、矢印３３６に示されるように、その生成したアプリケーション・ロードモジュール３２７を、バス３０３を介して補助記憶装置３０２に供給し、記憶させる。
【０１１７】
この補助記憶装置３０２に記憶されるアプリケーション・ロードモジュール３２７（クライアント・プログラムおよびサーバ・プログラム）が開発結果とされる。
【０１１８】
図１８は、図１７の情報処理装置３０１の構成例を示すブロック図である。
【０１１９】
図１８において、情報処理装置３０１のCPU（Central Processing Unit）４０１は、ROM（Read Only Memory）４０２に記憶されているプログラム、または記憶部４１３からRAM（Random Access Memory）４０３にロードされたプログラムに従って各種の処理を実行する。RAM４０３にはまた、CPU４０１が各種の処理を実行する上において必要なデータなども適宜記憶される。
【０１２０】
CPU４０１、ROM４０２、およびRAM４０３は、バス４０４を介して相互に接続されている。このバス４０４にはまた、入出力インタフェース４１０も接続されている。
【０１２１】
入出力インタフェース４１０には、キーボード、マウスなどよりなる入力部４１１、CRT（Cathode Ray Tube）、LCD（Liquid Crystal Display）などよりなるディスプレイ、並びにスピーカなどよりなる出力部４１２、ハードディスクなどより構成される記憶部４１３、モデムなどより構成される通信部４１４が接続されている。通信部４１４は、インターネットを含むネットワークを介しての通信処理を行う。
【０１２２】
入出力インタフェース４１０にはまた、必要に応じてドライブ４１５が接続され、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア４２１が適宜装着され、それらから読み出されたコンピュータプログラムが、必要に応じて記憶部４１３にインストールされる。
【０１２３】
このような構成の情報処理装置３０１において、記憶部４１３には、アプリケーションの開発に関する機能を実現するアプリケーション開発プログラム４３１やオペレーティングシステム４３２が記憶されている。アプリケーション開発プログラム４３１には、プログラム生成制御プログラム４４１とコンパイラ４４２が含まれる。
【０１２４】
CPU４０１は、例えばROM４０２に記憶されている情報処理装置３０１の起動プログラム等を実行することにより、記憶部４１３よりオペレーティングシステム４３２を読み出してRAM４０３上に展開させ、実行する。CPU４０１は、そのオペレーティングシステム４３２の管理の下、記憶部４１３よりアプリケーション開発プログラム４３１を読み出してRAM４０３上に展開させ、プログラム生成制御プログラム４４１を実行することにより、図１７のプログラム生成部３１１の機能ブロックを実現し、コンパイラ４４２を実行することにより、図１７のコンパイラ３１２の機能ブロックを実現する。
【０１２５】
図１９は、図１７の補助記憶装置３０２の構成例を示すブロック図である。
【０１２６】
図１９において、補助記憶装置３０２は、制御部５０１、記憶部５０２、および通信部５０３を有する。制御部５０１は、CPU、ROM、およびRAM等を有し、補助記憶装置３０２の各部の制御に関する処理を行う。記憶部５０２は、例えばハードディスクや半導体メモリ等の記憶媒体により構成される記憶領域を有し、制御部５０１に制御されて、その記憶領域に、図１７の通信インタフェース記述情報３２１乃至アプリケーション・ロードモジュール（実行形式）３２７等の各種のデータやプログラムを必要に応じて記憶する。通信部５０３は、制御部５０１に制御され、情報処理装置３０１とのバス３０３を介した通信を行い、データやプログラムの授受を行う。例えば、通信部５０３は、制御部５０１により、記憶部５０２より読み出されたデータやプログラムを情報処理装置３０１に供給したり、情報処理装置３０１より供給されるデータやプログラムを取得して、制御部５０１に供給し、記憶部５０２に記憶させたりする。
【０１２７】
次に、アプリケーション開発処理の具体的な処理の流れについて図２０のフローチャートを参照して説明する。
【０１２８】
アプリケーション開発処理が開始されると、情報処理装置３０１のプログラム生成部３１１は、ステップＳ６１において、通信インタフェース記述情報３２１およびリソース記述情報３２２を補助記憶装置３０２より取得し、ステップＳ６２において、図１４のフローチャートを参照して説明した場合と同様のプログラム生成処理を実行して通信プログラム３２３およびリソース管理データ３２４を生成し、ステップＳ６３において、それらを補助記憶装置３０２に供給して記憶させる。補助記憶装置３０２は、その供給された通信プログラム３２３およびリソース管理データ３２４を記憶部５０２に記憶する。
【０１２９】
情報処理装置３０１のコンパイラ３１２は、ステップＳ６４において、通信プログラム３２３、リソース管理データ３２４、共通ライブラリ３２５、アプリケーション・ソースプログラム３２６を補助記憶装置３０２より取得し、ステップＳ６５において、コンパイルを行い、アプリケーション・ロードモジュール３２７を生成する。コンパイラ３１２は、ステップＳ６６において、そのアプリケーション・ロードモジュール３２７を補助記憶装置３０２に供給して記憶させる。補助記憶装置３０２は、その供給されたアプリケーション・ロードモジュール３２７を記憶部５０２に記憶し、アプリケーション開発処理を終了する。
【０１３０】
以上のようにすることにより、開発者は、分散型コマンド処理システム・アプリケーションソフトウェアをより容易に開発し、そのロードモジュール（実行形式）を得ることができる。つまり、アプリケーション開発システム３００は、分散型コマンド処理システム・アプリケーションソフトウェアの開発における、開発者の負荷を軽減し、生産性を向上させることができる。
【０１３１】
次に、以上のように開発された分散型コマンド処理システム・アプリケーションソフトウェアを運用するシステムについて説明する。
【０１３２】
図２１は、例えば開発者が上述したアプリケーション開発システム３００を用いて開発したアプリケーションプログラムを適用して実現した分散型コマンド処理システムの構成例を示すブロック図である。
【０１３３】
図２１において、分散型コマンド処理システム６００は、ネットワーク６０２を介して互いに接続されるサーバノード６０１とクライアントノード６０３を有している。サーバノード６０１は、サーバ・プログラムのロードモジュールを実行する情報処理装置であり、分散型コマンド処理システム６００において、ネットワーク６０２を介して接続されるクライアントノード６０３に対してサーバとして機能する。クライアントノード６０３は、クライアント・プログラムのロードモジュールを実行する情報処理装置であり、分散型コマンド処理システム６００において、ネットワーク６０２を介して接続されるサーバノード６０１に対してクライアントとして機能する。
【０１３４】
ネットワーク６０２は、例えば、インターネットやLAN（Local Area Network）等に代表される所定のネットワークにより構成される。ネットワーク６０２は、１つのネットワークにより構成されるようにしてもよいし、複数のネットワークにより構成されるようにしてもよい。また、そのネットワークは、有線により構成されるものであってもよいし、無線により構成されるものであってもよい。
【０１３５】
サーバノード６０１およびクライアントノード６０３は、このネットワーク６０２を介して情報を送受信するために、互いのオペレーティングシステムを用いて論理的な通信路を構築し、その通信路を介して、リモートコマンド実行のための情報の授受を行う。
【０１３６】
図２２は、図２１のサーバノード６０１の構成例を示す機能ブロック図である。
【０１３７】
サーバノード６０１においては、サーバ・オペレーティングシステム６１２の管理の下でサーバ６１１が動作している。サーバ６１１は、上述したサーバ・プログラムのロードモジュールが実行されて実現された機能ブロックであり、サーバ用のアプリケーションプログラムを実行するサーバ・アプリケーションプログラム実行部６２１、サーバ用の通信プログラムを実行するサーバ通信プログラム実行部６２２、サーバ用のリソース管理データを管理するサーバ・リソース管理データ管理部６２３、およびサーバ用の共通ライブラリに関する処理を行うサーバ共通ライブラリ処理部６２４を有している。
【０１３８】
サーバ共通ライブラリ処理部６２４は、サーバおよびクライアントの通信プログラムのバージョンチェックに関する処理を行うバージョンチェック処理部６３１を有している。
【０１３９】
図２３は、図２１のクライアントノード６０３の構成例を示す機能ブロック図である。
【０１４０】
サーバノード６０１においては、クライアント・オペレーティングシステム６４２の管理の下でクライアント６４１が動作している。クライアント６４１は、上述したクライアント・プログラムのロードモジュールが実行されて実現された機能ブロックであり、クライアント用のアプリケーションプログラムを実行するクライアント・アプリケーションプログラム実行部６５１、クライアント用の通信プログラムを実行するクライアント通信プログラム実行部６５２、クライアント用のリソース管理データを管理するクライアント・リソース管理データ管理部６５３、およびクライアント用の共通ライブラリに関する処理を行うクライアント共通ライブラリ処理部６５４を有している。
【０１４１】
クライアント共通ライブラリ処理部６５４は、サーバおよびクライアントの通信プログラムのバージョンチェックに関する処理を行うバージョンチェック処理部６６１を有している。
【０１４２】
図２４は、図２１のサーバノード６０１の構成例を示すブロック図である。
【０１４３】
図２４において、サーバノード６０１のCPU７０１は、ROM７０２に記憶されているプログラム、または記憶部７１３からRAM７０３にロードされたプログラムに従って各種の処理を実行する。RAM７０３にはまた、CPU７０１が各種の処理を実行する上において必要なデータなども適宜記憶される。
【０１４４】
CPU７０１、ROM７０２、およびRAM７０３は、バス７０４を介して相互に接続されている。このバス７０４にはまた、入出力インタフェース７１０も接続されている。
【０１４５】
入出力インタフェース７１０には、キーボード、マウスなどよりなる入力部７１１、CRTやLCDなどよりなるディスプレイ、並びにスピーカなどよりなる出力部７１２、ハードディスクなどより構成される記憶部７１３、モデムなどより構成される通信部７１４が接続されている。通信部７１４は、インターネットを含むネットワークを介しての通信処理を行う。
【０１４６】
入出力インタフェース７１０にはまた、必要に応じてドライブ７１５が接続され、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア７２１が適宜装着され、それらから読み出されたコンピュータプログラムが、必要に応じて記憶部７１３にインストールされる。
【０１４７】
このような構成のサーバノード６０１において、記憶部７１３には、例えばアプリケーション開発システム３００を用いて開発されたサーバ用アプリケーション・ロードモジュール７３１やサーバ用のオペレーティングシステム７３２が記憶されている。
【０１４８】
CPU７０１は、例えばROM７０２に記憶されているサーバノード６０１の起動プログラム等を実行することにより、記憶部７１３よりサーバ用のオペレーティングシステム７３２を読み出してRAM７０３上に展開させ、実行することにより、図２２のサーバ・オペレーティングシステム６１２の機能ブロックを実現する。CPU７０１は、そのサーバ・オペレーティングシステム６１２の管理の下、記憶部７１３よりサーバ用アプリケーション・ロードモジュール７３１を読み出してRAM７０３上に展開させて実行することにより、図２２の、サーバ６１１の各機能である、サーバ・アプリケーションプログラム実行部６２１、サーバ通信プログラム実行部６２２、サーバ・リソース管理データ管理部６２３、サーバ共通ライブラリ処理部６２４、およびバージョンチェック処理部６３１の機能ブロックを実現する。
【０１４９】
図２５は、図２１のクライアントノード６０３の構成例を示すブロック図である。
【０１５０】
図２５において、クライアントノード６０３のCPU８０１は、ROM８０２に記憶されているプログラム、または記憶部８１３からRAM８０３にロードされたプログラムに従って各種の処理を実行する。RAM８０３にはまた、CPU８０１が各種の処理を実行する上において必要なデータなども適宜記憶される。
【０１５１】
CPU８０１、ROM８０２、およびRAM８０３は、バス８０４を介して相互に接続されている。このバス８０４にはまた、入出力インタフェース８１０も接続されている。
【０１５２】
入出力インタフェース８１０には、キーボード、マウスなどよりなる入力部８１１、CRTやLCDなどよりなるディスプレイ、並びにスピーカなどよりなる出力部８１２、ハードディスクなどより構成される記憶部８１３、モデムなどより構成される通信部８１４が接続されている。通信部８１４は、インターネットを含むネットワークを介しての通信処理を行う。
【０１５３】
入出力インタフェース８１０にはまた、必要に応じてドライブ８１５が接続され、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア８２１が適宜装着され、それらから読み出されたコンピュータプログラムが、必要に応じて記憶部８１３にインストールされる。
【０１５４】
このような構成のクライアントノード６０３において、記憶部８１３には、例えばアプリケーション開発システム３００を用いて開発されたクライアント用アプリケーション・ロードモジュール８３１やクライアント用のオペレーティングシステム８３２が記憶されている。
【０１５５】
CPU８０１は、例えばROM８０２に記憶されているクライアントノード６０３の起動プログラム等を実行することにより、記憶部８１３よりクライアント用のオペレーティングシステム８３２を読み出してRAM８０３上に展開させ、実行することにより、図２３のクライアント・オペレーティングシステム６４２の機能ブロックを実現する。CPU８０１は、そのクライアント・オペレーティングシステム６４２の管理の下、記憶部８１３よりクライアント用アプリケーション・ロードモジュール８３１を読み出してRAM８０３上に展開させて実行することにより、図２３の、クライアント６４１の各機能である、クライアント・アプリケーションプログラム実行部６５１、クライアント通信プログラム実行部６５２、クライアント・リソース管理データ管理部６５３、クライアント共通ライブラリ処理部６５４、およびバージョンチェック処理部６６１の機能ブロックを実現する。
【０１５６】
次に、各ノードにおいて実行される各処理の具体的な流れについて説明する。最初に、サーバノード６０１のサーバ６１１およびクライアントノード６０３のクライアント６４１は、それぞれのオペレーティングシステムの管理の下、各通信ポートを初期化して互いに通信を確立し、論理的な通信路を構築する。
【０１５７】
このサーバ６１１のサーバ共通ライブラリ処理部６２４が各通信ポートに対して実行する通信ポート初期化処理の流れの例を図２６のフローチャートを参照して説明する。
【０１５８】
通信ポート初期化処理が開始されると、サーバ共通ライブラリ処理部６２４は、ステップＳ８１において、サーバ・リソース管理データ管理部６２３が管理するサーバ・リソース管理データを参照し、その通信ポートについて、クライアント・サーバ間の通信処理をするためのサーバ通信ポートリソースを生成する。サーバ通信ポートリソースを生成すると、サーバ共通ライブラリ処理部６２４は、ステップＳ８２において、クライアント６４１からの要求を受信するための処理を行う。クライアント６４１より要求を受信すると、サーバ共通ライブラリ処理部６２４は、ステップＳ８３において、接続要求を取得したか否かを判定し、取得したと判定した場合、処理をステップＳ８４に進める。
【０１５９】
ステップＳ８４において、サーバ共通ライブラリ処理部６２４のバージョンチェック処理部６３１は、バージョン検査処理を実行し、サーバ６１１とクライアント６４１の通信プログラムのバージョンの検査を行い、正しく通信を行うことができるか否かを判定する。バージョン検査処理の詳細については後述する。
【０１６０】
バージョン検査処理が終了すると、サーバ共通ライブラリ処理部６２４は、ステップＳ８５において、その検査結果を応答としてクライアント６４１に送信する。例えば、検査結果として、クライアント６４１がサーバ６１１に対して妥当なクライアントであると判定された場合、サーバ共通ライブラリ処理部６２４は、接続要求受理の応答をクライアント６４１に返信する。逆に、クライアント６４１がサーバ６１１に対して不正なクライアントであると判定された場合、サーバ共通ライブラリ処理部６２４は、接続要求拒否の応答をクライアント６４１に返信する。応答処理を行うと、サーバ共通ライブラリ処理部６２４は、通信ポート初期化処理を終了する。
【０１６１】
また、ステップＳ８３において、取得した要求が接続要求でないと判定した場合、サーバ共通ライブラリ処理部６２４は、処理をステップＳ８６に進め、その取得した要求に応じた処理を実行し、通信ポート初期化処理を終了する。
【０１６２】
以上の一連の処理が、１つのサーバ通信ポートに対する初期化処理であり、サーバ共通ライブラリ処理部６２４は、上述した通信ポート初期化処理をサーバ・プログラムの初期化時に、全ての通信ポートについて実行する。また、サーバ共通ライブラリ処理部６２４が、クライアント６４１より要求を取得する際に、その通信ポートについての通信ポート初期化処理を、非同期に実行するようにしてもよい。このように通信ポート初期化処理を実行することにより、サーバ共通ライブラリ処理部６２４は、サーバ・リソース管理データの全ポートを初期化することができる。
【０１６３】
次に、図２６のステップＳ８４において実行されるバージョン検査処理の詳細な流れの例について、図２７のフローチャートを参照して説明する。
【０１６４】
バージョン検査処理が開始されると、バージョンチェック処理部６３１は、ステップＳ１０１において、例えば通信プログラムの内容等に基づいて、通信プログラムに割り当てられた全てのバージョン（例えばメジャーバージョンとマイナーバージョン）が所定の条件（例えば、サーバ通信プログラムが、クライアント通信プログラムより新しい）を満たす必要があるか否かを判定する。
【０１６５】
通信プログラムに割り当てられた全てのバージョンが所定の条件を満たす必要があると判定した場合、バージョンチェック処理部６３１は、処理をステップＳ１０２に進め、サーバ通信プログラム実行部６２２を制御して、サーバ通信プログラムに埋め込まれているバージョン情報を取得し、接続要求に含まれるクライアントのバージョン情報と、サーバの通信プログラムのバージョン情報を比較する。
【０１６６】
ステップＳ１０３において、バージョンチェック処理部６３１は、ステップＳ１０２における比較の結果、全てのバージョンが所定の条件を満たすか否かを判定する。全てのバージョンが所定の条件を満たすと判定した場合、バージョンチェック処理部６３１は、処理をステップＳ１０６に進め、接続を許可する。接続を許可すると、バージョンチェック処理部６３１は、それを検査結果として出力した後、バージョン検査処理を終了し、処理を図２６のステップＳ８４に戻し、それ以降の処理を実行させる。また、ステップＳ１０３において、いずれかまたは全てのバージョンが所定の条件を満たしていないと判定した場合、バージョンチェック処理部６３１は、処理をステップＳ１０７に進め、接続を拒否する。接続を拒否すると、バージョンチェック処理部６３１は、それを検査結果として出力した後、バージョン検査処理を終了し、処理を図２６のステップＳ８４に戻し、それ以降の処理を実行させる。
【０１６７】
また、ステップＳ１０１において、通信プログラムに割り当てられたバージョンのうち、一部または全部が所定の条件を満たす必要がなく、例えば、メジャーバージョンのみ等、一部のバージョンが条件を満たせばよいと判定した場合、バージョンチェック処理部６３１は、処理をステップＳ１０４に進める。なお、ここでは、この一部のバージョンとして、メジャーバージョンが条件を満たせばよいものとして説明する。
【０１６８】
ステップＳ１０４において、バージョンチェック処理部６３１は、サーバ通信プログラム実行部６２２を制御して、サーバ通信プログラムに埋め込まれているメジャーバージョンを取得し、接続要求に含まれるクライアントのメジャーバージョンと、サーバの通信プログラムのメジャーバージョンを比較する。
【０１６９】
ステップＳ１０５において、バージョンチェック処理部６３１は、ステップＳ１０４における比較の結果、メジャーバージョンが所定の条件を満たすか否かを判定する。メジャーバージョンが所定の条件を満たすと判定した場合、バージョンチェック処理部６３１は、処理をステップＳ１０６に進め、接続を許可する。接続を許可すると、バージョンチェック処理部６３１は、それを検査結果として出力した後、バージョン検査処理を終了し、処理を図２６のステップＳ８４に戻し、それ以降の処理を実行させる。また、ステップＳ１０５において、メジャーバージョンが所定の条件を満たしていないと判定した場合、バージョンチェック処理部６３１は、処理をステップＳ１０７に進め、接続を拒否する。接続を拒否すると、バージョンチェック処理部６３１は、それを検査結果として出力した後、バージョン検査処理を終了し、処理を図２６のステップＳ８４に戻し、それ以降の処理を実行させる。
【０１７０】
つまり、クライアント６４１からの接続要求には、クライアント通信プログラムのバージョン情報の一部または全部（すなわち、検査すべき項目）が含まれており、バージョンチェック処理部６３１は、そのバージョン情報に対応するサーバ通信プログラムのバージョン情報を、サーバ通信プログラムより取得し、互いに比較する。その比較の結果、必要な条件が満たされていると判定した場合、バージョンチェック処理部６３１は、接続を許可する。逆に、バージョン情報の比較の結果、必要な条件が満たされていないと判定した場合、バージョンチェック処理部６３１は、接続を拒否する。
【０１７１】
なお、例えば、バージョン情報の内、どのバージョンがどのような条件を満たすか等（必要な条件）については、予め定められているようにしてもよいし、その都度、各通信プログラム等の内容に基づいて決定されるようにしてもよい。
【０１７２】
次に、図２８のフローチャートを参照して、クライアント６４１のクライアント共通ライブラリ処理部６５４により実行される通信ポート初期化処理の流れの例を説明する。
【０１７３】
ステップＳ１２１において、クライアント共通ライブラリ処理部６５４は、クライアント・リソース管理データ管理部６５３が管理するクライアント・リソース管理データを参照し、処理対象の通信ポートについて、クライアント通信ポートリソースを生成する。ステップＳ１２２において、クライアント共通ライブラリ処理部６５４は、例えばユーザ指示等に基づいて、接続要求をサーバ６１１に送信するか否かを判定し、接続要求を送信すると判定した場合、処理をステップＳ１２３に進める。
【０１７４】
ステップＳ１２３において、クライアント共通ライブラリ処理部６５４のバージョンチェック処理部６６１は、クライアント通信プログラムに埋め込まれたバージョン情報を取得し、そのバージョン情報を用いて接続要求を生成する。クライアント共通ライブラリ処理部６５４は、ステップＳ１２４において、クライアント・リソース管理データ管理部６５３が管理するクライアント・リソース管理データを参照し、接続先サーバの通信ポートに対して接続要求を送信する。ステップＳ１２５において、クライアント共通ライブラリ処理部６５４は、その接続要求に対する応答を受信する。ステップＳ１２６において、クライアント共通ライブラリ処理部６５４は、その応答を参照してサーバ６１１に接続を許可されたか否かを判定し、許可されたと判定した場合、処理をステップＳ１２７に進める。ステップＳ１２７において、クライアント共通ライブラリ処理部６５４は、サーバ６１１との通信を確立して活性化させ、通信ポート初期化処理を終了する。このように初期化されると、この通信路を介してリモート関数の使用が可能になるので、クライアント６４１のクライアント・アプリケーションプログラム実行部６５１は、クライアント・アプリケーションを実行することができるようになる。
【０１７５】
また、ステップＳ１２６において、接続を拒否されたと判定した場合、クライアント共通ライブラリ処理部６５４は、処理をステップＳ１２８に進め、接続エラーとし、サーバ６１１との通信を活性化させずに、通信ポート初期化処理を終了する。このように初期化された場合、この通信路を使用することができないので、クライアント６４１のクライアント・アプリケーションプログラム実行部６５１は、クライアント・アプリケーションを実行することができなくなる。
【０１７６】
さらに、ステップＳ１２２において、接続要求以外の要求を送信すると判定した場合、クライアント共通ライブラリ処理部６５４は、通信ポート初期化処理を終了する。
【０１７７】
以上の一連の処理が、１つのクライアント通信ポートに対する初期化処理であり、クライアント共通ライブラリ処理部６５４は、上述した通信ポート初期化処理をクライアント・プログラムの初期化時に、全ての通信ポートについて実行する。また、クライアント共通ライブラリ処理部６５４が、サーバ６１１に要求を送信する際に、その通信ポートについての通信ポート初期化処理を、非同期に実行するようにしてもよい。このように通信ポート初期化処理を実行することにより、クライアント共通ライブラリ処理部６５４は、クライアント・リソース管理データの全ポートを初期化することができる。
【０１７８】
以上のように、開発時において、サーバ通信プログラムおよびクライアント通信プログラムの両方にバージョン情報を埋め込み、それらを用いて、通信ポートの初期化時に、場ジョンチェックを行うようにしたので、開発者の作業による非互換性の可能性やバージョン変更によるバグの発生率が減り、デバッグ時間の節約や開発プロセスの効率化を図ることができる。
【０１７９】
また、サーバ６１１とクライアント６４１間のバージョンチェックの仕組みにより両側の通信インタフェースの互換性が検証されるため、転送データの一意的な解釈が保証される。また、バージョンチェック結果によりポートの使用許可が判定されるので、両側の通信インタフェースの違いで発生する不正なデータ転送がブロックされ、不適切なデータ転送による情報の漏れ、不要なパケット転送によるネットワークの負荷発生を避けることが出来る。
【０１８０】
さらに、サーバ６１１とクライアント６４１の通信インタフェースの互換性は、バージョンチェック機能によりポート接続の前に行われる為、バージョン違いの問題はアプリケーション起動の直後、相当に早い段階で検証される。これにより、システム・リソースの効率的な使用、不要なネット・トラヒック量の削減、メインテナンス時間の短縮、またはセキュリティの強化等を図ることができる。
【０１８１】
また、上述したように、ポート毎に使用許可が判定されるので、サーバ６１１とクライアント６４１との間の通信路の一部は許可、他方は拒否されることもある。つまり、通信接続が最適化され、無駄な通信接続が排除され、データ転送の目的やセキュリティ要求に対応する通信のみが提供される。
【０１８２】
さらに、バージョン情報を「major_version」および「minor_version」などのように段階的に記述するようにすることにより、各レベルについてバージョンチェックを設けることができる。これにより、サーバ６１１とクライアント６４１は、通信インタフェースのバージョン一致の範囲内での通信が可能になるので、転送データの種類、送受信の環境によりその範囲を定めることにより、通信の制御を柔軟に行うことができる。
【０１８３】
次に、図２９のフローチャートを参照して、クライアント６４１によるリモート関数呼び出し処理の流れの例を説明する。
【０１８４】
リモート関数呼び出し処理が開始されると、クライアント６４１は、ステップ１２０１において、リモート関数に対応するスタブ関数を呼び出し、ステップＳ１２０２において、リモート関数に関連する通信プロトコル定義のデータを生成してサーバに送信し、ステップＳ１２０３において、サーバからのリプライを受信し、リモート関数からの結果（リプライ）を呼び出し元に返し、リモート関数呼び出し処理を終了する。なお、ステップＳ１２０２およびステップＳ１２０３は、スタブ関数が実行されることにより実現される処理である。
【０１８５】
次に、このようなリモート関数呼び出し処理に対応して、サーバ６１１により実行されるリモート関数実体の起動処理の流れの例を、図３０のフローチャートを参照して説明する。
【０１８６】
リモート関数実体の起動処理が開始されると、サーバ６１１は、ステップ１３０１において、クライアント６４１から送信された通信プロトコル定義のデータを解析して、サーバ通信プログラム内の該当するリモート関数実体を呼び出す。ステップＳ１３０２において、サーバ６１１は、通信プロトコル定義内のリクエストパラメータを解析し、所定のリモートコマンドの処理を実行する。ステップＳ１３０３において、サーバ６１１は、通信プロトコル定義に従い、リプライデータを生成し、それをクライアント６４１に返信し、リモート関数実体の起動処理を終了する。ステップ１３０３の処理により、図２９のステップ１２０３の処理が活性化される。
【０１８７】
以上のように、アプリケーション開発時において、通信プログラムとともに、クライアントおよびサーバのプログラムに、その通信プログラムを関連付けるためのリソース管理データを生成するようにしたので、開発者は、分散型コマンド処理システム・アプリケーションソフトウェアをより容易に開発することができる。
【０１８８】
また、クライアントにおいては、クライアント共通ライブラリがクライアント・リソース管理データ内の通信ポートのデータを参照して、初期化処理を実行し、一方のサーバにおいては、サーバ共通ライブラリがサーバ・リソース管理データ内の通信ポートのデータを参照して、初期化処理を実行するので、クライアント・プログラムおよびサーバ・プログラムは、自動生成された通信プログラムをアプリケーションプログラムに結合するための付加プログラムを個別に作成する必要がなくなる。従って、分散型コマンド処理システム・アプリケーションソフトウェアの生産性を向上させることが可能になる。
【０１８９】
なお、以上において、通信インタフェース記述情報２１、リソース記述情報２２、通信プログラム２３、およびリソース管理データ２４の各データの構成は、上述した記述例や構成例以外のものであってももちろんよい。また、アプリケーション開発システム３００も、図１７に示される構成例以外の構成であってもよく、例えば、情報処理装置３０１、補助記憶装置３０２、およびバス３０３を１つの装置として構成するようにしてもよい。さらに、分散型コマンド処理システム６００も、図２１に示される構成例以外の構成であってもよく、例えば、サーバノードおよびクライアントノードを複数有するようにしてもよい。
【０１９０】
上述した一連の処理は、ハードウェアにより実行させることもできるし、ソフトウェアにより実行させることもできる。上述した一連の処理をソフトウェアにより実行させる場合には、そのソフウェアを構成するプログラムが、ネットワークや記録媒体からインストールされる。
【０１９１】
この記録媒体は、例えば、図１８、図２４、または図２５に示されるように、装置本体とは別に、ユーザにプログラムを配信するために配布される、プログラムが記録されている磁気ディスク（フレキシブルディスクを含む）、光ディスク（CD-ROM(Compact Disk-Read Only Memory),DVD(Digital Versatile Disk)を含む）、光磁気ディスク（ＭＤ（Mini-Disk）（登録商標）を含む）、もしくは半導体メモリなどよりなるリムーバブルメディアにより構成されるだけでなく、装置本体に予め組み込まれた状態でユーザに配信される、プログラムが記録されているROMや、記憶部に含まれるハードディスクなどで構成される。
【０１９２】
なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
【０１９３】
また、本明細書において、システムとは、複数の装置により構成される装置全体を表すものである。
【０１９４】
なお、以上において、一つの装置として説明した構成を分割し、複数の装置として構成するようにしてもよい。逆に、以上において複数の装置として説明した構成をまとめて一つの装置として構成されるようにしてもよい。また、各装置の構成に上述した以外の構成を付加するようにしてももちろんよい。さらに、システム全体としての構成や動作が実質的に同じであれば、ある装置の構成の一部を他の装置の構成に含めるようにしてもよい。つまり、本発明の実施の形態は、上述した実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲において種々の変更が可能である。
【産業上の利用可能性】
【０１９５】
本発明は、情報処理装置に適用することが可能である。
【図面の簡単な説明】
【０１９６】
【図１】本発明を適用したプログラム生成装置の構成例を示すブロック図である。
【図２】図１の通信プログラム生成部の詳細な構成例を示すブロック図である。
【図３】図１のリソース管理データ生成部の詳細な構成例を示すブロック図である。
【図４】図１の通信インタフェース記述情報の構成例を示す模式図である。
【図５】図４の通信インタフェース記述情報の具体的な記述例を示す図である。
【図６】図１の通信プログラムの構成例を示す模式図である。
【図７】図６の通信プログラムのクライアント通信プログラムの記述例を示す図である。
【図８】図６の通信プログラムのサーバ通信プログラムの記述例を示す図である。
【図９】図６の通信プログラムの通信プロトコル定義の記述例を示す図である。
【図１０】図１のリソース記述情報の構成例を示す模式図である。
【図１１】図１０のリソース記述情報の記述例を示す図である。
【図１２】図１のリソース管理データの構成例を示す模式図である。
【図１３】図１２のリソース管理データの記述例を示す図である。
【図１４】図１のプログラム生成装置１１によるプログラム生成処理の流れの例を説明するフローチャートである。
【図１５】通信プログラム生成処理の詳細な流れの例を説明するフローチャートである。
【図１６】リソース管理データ生成処理の流れの例を説明するフローチャートである。
【図１７】本発明を適用したアプリケーション開発システムの構成例を示すブロック図である。
【図１８】図１７の情報処理装置の構成例を示すブロック図である。
【図１９】図１７の補助記憶装置の構成例を示すブロック図である。
【図２０】アプリケーション開発処理の流れの例を説明するフローチャートである。
【図２１】本発明を適用した分散型コマンド処理システムの構成例を示すブロック図である。
【図２２】図２１のサーバノードの構成例を示す機能ブロック図である。
【図２３】図２１のクライアントノードの構成例を示す機能ブロック図である。
【図２４】図２１のサーバノードの構成例を示すブロック図である。
【図２５】図２１のクライアントノードの構成例を示すブロック図である。
【図２６】サーバによる通信ポート初期化処理の流れの例を説明するフローチャートである。
【図２７】サーバによるバージョン検査処理の流れの例を説明するフローチャートである。
【図２８】クライアントによる通信ポート初期化処理の流れの例を説明するフローチャートである。
【図２９】クライアントによるリモート関数呼び出しの流れの例を説明するフローチャートである。
【図３０】サーバによるリモート関数実体の起動処理の流れの例を説明するフローチャートである。
【符号の説明】
【０１９７】
１１  プログラム生成装置，  ２１  通信インタフェース記述情報，  ２２  リソース記述情報，  ２３  通信プログラム，  ２４  リソース管理データ，  ４１  インタフェース名解析部，  ４２  関数定義選択部，  ４３  クライアント通信プログラム生成部，  ４４  サーバ通信プログラム生成部，  ４５  通信プロトコル定義生成部，  ４６  バージョン情報埋込部，  ５１  プログラム名解析部，  ５２  リソース管理データ構造定義生成部，  ５３  通信ポート定義選択部，  ５４  クライアント・リソース管理データ生成部，  ５５  サーバ・リソース管理データ生成部，  ３００  アプリケーション開発システム，  ３０１  情報処理装置，  ３０２  補助記憶装置，  ６００  分散型コマンド処理システム，  ６０１  サーバノード，  ６０２  ネットワーク，  ６０３  クライアントノード，  ６１１  サーバ，  ６２１  サーバ・アプリケーションプログラム実行部，  ６２２  サーバ通信プログラム実行部，  ６２３  サーバ・リソース管理データ管理部，  ６２４  サーバ共通ライブラリ処理部，  ６３１  バージョンチェック処理部，  ６４１  クライアント，  ６５１  クライアント・アプリケーションプログラム実行部，  ６５２  クライアント通信プログラム実行部，  ６５３  クライアント・リソース管理データ管理部，  ６５４  クライアント共通ライブラリ処理部，  ６６１  バージョンチェック処理部
【図１】
2007164410.tif 000003
【図２】
2007164410.tif 000004
【図３】
2007164410.tif 000005
【図４】
2007164410.tif 000006
【図５】
2007164410.tif 000007
【図６】
2007164410.tif 000008
【図７】
2007164410.tif 000009
【図８】
2007164410.tif 000010
【図９】
2007164410.tif 000011
【図１０】
2007164410.tif 000012
【図１１】
2007164410.tif 000013
【図１２】
2007164410.tif 000014
【図１３】
2007164410.tif 000015
【図１４】
2007164410.tif 000016
【図１５】
2007164410.tif 000017
【図１６】
2007164410.tif 000018
【図１７】
2007164410.tif 000019
【図１８】
2007164410.tif 000020
【図１９】
2007164410.tif 000021
【図２０】
2007164410.tif 000022
【図２１】
2007164410.tif 000023
【図２２】
2007164410.tif 000024
【図２３】
2007164410.tif 000025
【図２４】
2007164410.tif 000026
【図２５】
2007164410.tif 000027
【図２６】
2007164410.tif 000028
【図２７】
2007164410.tif 000029
【図２８】
2007164410.tif 000030
【図２９】
2007164410.tif 000031
【図３０】
2007164410.tif 000032