(57)【要約】【課題】プログラム製品のリリース、変更、供給停止等の変化に簡易に追従できる技術を提供する。【解決手段】アプリケーションプログラムからアプリケーションプログラム内に導入されるべき被組み込みオブジェクトを含むライブラリの指定を受け付ける手段と、アプリケーションプログラム内に導入される被組み込みオブジェクトを生成するためのライブラリごとに固有の情報を特定する固有情報特定手段と、ライブラリごとに固有の情報を用いて被組み込みオブジェクトを生成する手段と、生成された被組み込みオブジェクトをアプリケーションプログラムに導入する手段、とを備える。【選択図】図３
2007219612.tif 000002
【特許請求の範囲】
【請求項１】
データ構造と前記データ構造を処理する機能によって定義される複数のオブジェクトが階層的に関係付けられ、上位の階層に位置するオブジェクトの有するデータ構造と機能とが下位の階層に位置するオブジェクトにおいて利用可能な、そのような被組み込みオブジェクトをアプリケーションプログラムに導入するインターフェースプログラムであって、
前記アプリケーションプログラムから前記アプリケーションプログラム内に導入されるべき被組み込みオブジェクトを含むライブラリの指定を受け付ける手段と、
前記アプリケーションプログラム内に導入される前記被組み込みオブジェクトを生成するためのライブラリごとに固有の情報を特定する固有情報特定手段と、
前記ライブラリごとに固有の情報を用いて前記被組み込みオブジェクトを生成する手段と、
前記生成された被組み込みオブジェクトをアプリケーションプログラムに導入する手段、として機能するコンピュータ実行可能なインターフェースプログラム。
【請求項２】
前記固有の情報は、前記アプリケーションプログラム内に導入される前記被組み込みオブジェクトを生成する、ライブラリに固有の生成オブジェクトの定義を示す情報であり、
前記固有情報特定手段は、前記ライブラリにおいて、それぞれのオブジェクトの定義を示す情報を検索し、当該オブジェクトの上位の階層のオブジェクトの定義を示す情報において複数のライブラリに共通の生成オブジェクトを示す情報が含まれる場合に、当該オブジェクトの定義を示す情報を前記ライブラリに固有の生成オブジェクトの定義を示す情報として特定する請求項１に記載のコンピュータ実行可能なインターフェースプログラム。
【請求項３】
データ構造と前記データ構造を処理する機能によって定義される複数のオブジェクトが階層的に関係付けられ、上位の階層に位置するオブジェクトの有するデータ構造と機能とが下位の階層に位置するオブジェクトにおいて利用可能な、そのような被組み込みオブジェクトをアプリケーションプログラムに導入するインターフェースプログラムであって、
前記アプリケーションプログラムから前記アプリケーションプログラム内に導入されるべき被組み込みオブジェクトを含むライブラリの指定を受け付ける手段と、
前記アプリケーションプログラム内に導入される前記被組み込みオブジェクトを生成するためのライブラリごとに固有の情報を特定する固有情報特定手段と、
前記ライブラリごとに固有の情報を用いて前記被組み込みオブジェクトを生成する手段と、
前記生成された被組み込みオブジェクトをアプリケーションプログラムに導入する手段と、を備える情報処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、被組み込み部品をアプリケーションプログラムに導入するインターフェース技術に関する。
【背景技術】
【０００２】
異なるプログラム製品間での互換性保持を目的として共通の規格に則って構築され、共通のＡＰＩ（アプリケーションインターフェース）を有するプログラム製品群がある。そのようなプログラム製品群としては、「ファクトリ／ストラテジパターン」を適用しているプログラム製品群を例示できる（例えば、特許文献１参照）。
【０００３】
ここで、ストラテジは、オブジェクト指向プログラミングにおいて、アルゴリズムをオブジェクトとしてカプセル化することでプログラムの処理の一部を動的に変更する技術である。また、ファクトリはオブジェクトの生成に関する詳細をクライアントプログラム中にコーディングさせないための技術である。
【０００４】
このようなプログラム製品群を複数組み込み、その利用目的によって各製品を使い分ける既存技術は、従来から利用されている。しかし、そのようなプログラム製品（パッケージ）の構造、オブジェクトを定義するクラスの名称等が変更されバージョンアップされることがある。また、プログラム製品自体が提供されなくなる場合もある。
【０００５】
そのような場合には、利用者は製品の変更内容に合わせて既存プログラムを修正しなければならない。
【０００６】
ここでは、課題を明確にするため、ＪＡＸＰインターフェースを実装した「ＸＭＬプロセッサ製品群をファクトリ／ストラテジ・デザインパターンで使用する従来型の利用者プログラムを例に挙げて説明する。
【０００７】
ここで、ＸＭＬ（eXtensible Markup Language）プロセッサは、ＸＭＬ文書をアプリケーションソフトが利用しやすい形に変換するコンピュータプログラムをいう。また、ＪＡＸＰは、Ｊａｖａ  （登録商標）ＸＭＬ  Ｐａｃｋに含まれるパッケージの１つで、ＸＭＬ文書の生成や読み出し、編集などを行なう機能をまとめたＡＰＩをいう。
【０００８】
図１に従来型の情報システムの機能ブロック図を示す。従来の処理では、図の左側にある「利用者プログラム」が図の中央にある「ＪＡＸＰ  Ｉ／Ｆ」を介し、図の右側にある「各製品」のオブジェクトを明示的に生成して利用する形態を採る。この場合、オブジェクトの生成は、各製品に用意されたＪＡＸＰインターフェースの実装クラス（オブジェクトを生成するためのオブジェクトを定義するクラス）のオブジェクトによる。すなわち、アプリケーションプログラムは、その実装クラスからオブジェクトを生成するためオブジェクトを明示的に生成することで、各製品に実装されたオブジェクトの利用が可能となる。
【０００９】
したがって、利用者プログラムでは常に各製品に用意されたＪＡＸＰインターフェースの上記実装クラスを意識して操作しなければならない。また、次に示す事象などが発生すると、オブジェクトの生成に失敗するだけでなくシステムが異常終了するといった問題にもつながる。
（例１）ＸＭＬプロセッサの提供を中止するベンダが現れた場合である。
（例２）ＸＭＬプロセッサが他のパッケージに集約され、その実装クラスの名前等も変更
された場合である。
（例３）ＸＭＬプロセッサのクラス構成が変化した場合である。
【００１０】
この問題を解決するためには、利用者は、製品の変更に関する情報あるいは、適切なアプリケーションプログラムの修正方法が提供される説明書、または、プログラム製品が格納されたライブラリファイルなどから、その実装クラスを調査しなければならない。そして、利用者は、その結果を基に利用者プログラムを正しく修正しなければならない。具体的には、新たに定義された実装クラスを基に、各製品に実装されたオブジェクトを明示的に生成しなければならない。
【００１１】
この一連の作業は利用者に大きな負担をかけることになるため、この作業を簡易に、あるいは、概ね自動的に（ユーザの手を介在させないで）実施できる手段を提供し、利用者の負担を軽減することが今後の課題となる。
【特許文献１】特開２００４−２４６４３４号公報
【発明の開示】
【発明が解決しようとする課題】
【００１２】
本発明の目的は、プログラム製品群を複数組み込み、その利用目的によって各製品を使い分けるシステムにおいて、それぞれのプログラム製品のリリース、変更、供給停止等の変化に簡易に追従できる技術を提供することである。
【課題を解決するための手段】
【００１３】
本発明は前記課題を解決するために、以下の手段を採用した。すなわち、本発明は、データ構造と前記データ構造を処理する機能によって定義される複数のオブジェクトが階層的に関係付けられ、上位の階層に位置するオブジェクトの有するデータ構造と機能とが下位の階層に位置するオブジェクトにおいて利用可能な、そのような被組み込みオブジェクトをアプリケーションプログラムに導入するインターフェースプログラムであって、前記アプリケーションプログラムから前記アプリケーションプログラム内に導入されるべき被組み込みオブジェクトを含むライブラリの指定を受け付ける手段と、前記アプリケーションプログラム内に導入される前記被組み込みオブジェクトを生成するためのライブラリごとに固有の情報を特定する固有情報特定手段と、前記ライブラリごとに固有の情報を用いて前記被組み込みオブジェクトを生成する手段と、前記生成された被組み込みオブジェクトをアプリケーションプログラムに導入する手段、として機能するコンピュータ実行可能なインターフェースプログラムである。
【００１４】
本発明は、被組み込みオブジェクトを生成するためのライブラリごとに固有の情報を特定し、ライブラリごとに固有の情報を用いて前記被組み込みオブジェクトを生成し、アプリケーションプログラムに導入する手段として機能するので、アプリケーションプログラム自体は、ライブラリごとに固有の情報を用いて被組み込みオブジェクトを生成する必要がない。したがって、ライブラリ内の固有情報に変更があった場合にも、アプリケーションプログラムを変更する必要がない。
【００１５】
前記固有の情報は、前記アプリケーションプログラム内に導入される前記被組み込みオブジェクトを生成する、ライブラリに固有の生成オブジェクトの定義を示す情報であり、前記固有情報特定手段は、前記ライブラリにおいて、それぞれのオブジェクトの定義を示す情報を検索し、当該オブジェクトの上位の階層のオブジェクトの定義を示す情報において複数のライブラリに共通の生成オブジェクトを示す情報が含まれる場合に、当該オブジェクトの定義を示す情報を、前記ライブラリに固有の生成オブジェクトの定義を示す情報として特定するようにすればよい。
【００１６】
本発明によれば、オブジェクトの上位の階層のオブジェクトの定義を示す情報において複数のライブラリに共通の生成オブジェクトを示す情報が含まれる場合に、当該オブジェクトの定義を示す情報を、前記ライブラリに固有の生成オブジェクトの定義を示す情報として特定するので、上位の階層のオブジェクトの定義を継承する機能を有し、かつ、所定の規格にしたがって、上位のオブジェクトにおいて共通の生成オブジェクトが提供されている環境において、ライブラリの構造から固有の情報を決定できる。
【００１７】
本発明は、以上のような手段を備える情報処理装置であってもよい。
【発明の効果】
【００１８】
本発明によれば、プログラム製品群を複数組み込み、その利用目的によって各製品を使い分けるシステムにおいて、それぞれのプログラム製品のリリース、変更、供給停止等の変化に簡易に追従できる。
【発明を実施するための最良の形態】
【００１９】
以下、図面を参照して本発明を実施するための最良の形態（以下、実施形態という）に係る情報システムについて説明する。以下の実施形態の構成は例示であり、本発明は実施形態の構成に限定されない。
【００２０】
＜発明の骨子＞
製品固有オブジェクトの生成処理などの煩雑な手続き処理を代行し、利用者プログラムと各ベンダが提供する製品との間を仲介する「オブジェクト供給機構」を提供する。この仲介役となるオブジェクト供給機構は、次の２つの処理モジュールで構成される。
【００２１】
処理モジュール１：提供される製品ごとに固有の情報（パッケージ構成、クラス構成、固有情報格納ファイルなど）を自動で検出し、情報システムに登録されている製品ごとに固有のメタ情報を作成する。
【００２２】
処理モジュール２：処理モジュール２が生成したメタ情報を取り込んで製品固有のオブジェクト生成処理実装部を動的に変更し、登録された製品ごとのオブジェクトを製品固有の情報の変更の有無にかかわらず、生成・管理する。
【００２３】
製品固有のオブジェクト生成処理実装部を利用者プログラムの外部に排除し、オブジェクト供給機構に取り込んだことで、利用者プログラムは各ベンダが提供する製品の変更による影響を受けずに要求するＸＭＬプロセッサオブジェクトを利用できる。
【００２４】
なお、本発明は、ＸＭＬプロセッサのみに限らず、同様のファクトリ／ストラテジパターンを導入している製品についても、同様の処理モジュール１、２を作成することで適用することが可能となる。
【００２５】
＜システム構成＞
図２に、本実施形態に係る情報システムの機能ブロック図を示す。図２は、図１に示した従来の情報システムの構成に加えて、オブジェクト供給機構１が導入されている。すなわち、本情報システムは、それぞれのベンダから提供される製品５０−１から５０−４等と、その製品５０−１から５０−４等のいずれかを利用する利用者プログラム６０と、製品５０−１から５０−４等を利用者プログラム６０に組み込むために、製品５０−１から５０−４等と利用者プログラム６０との間に介在するオブジェクト供給機構１とを有している。
【００２６】
本情報システムは、パーソナルコンピュータ、携帯情報端末（ＰＤＡ）、あるいは、ネ
ットワーク上のサーバようなコンピュータ上に構築される。このようなコンピュータは、ＣＰＵ、メモリ、入出力インターフェース、入出力インターフェースを通じてＣＰＵに接続されるハードディスク駆動装置、着脱可能な記録媒体（ＤＶＤ、ＣＤ、フラッシュメモリカード等）の駆動装置（アクセス装置）、有線または無線の通信インターフェース、表示装置、および、ユーザ操作を検知する入力装置（キーボード、ポインティングデバイス等）を有している。このようなコンピュータの構成および作用は、広く知られているので、その説明を省略する。
【００２７】
ベンダの製品５０−１から５０−４等を総称して製品５０と呼ぶことにする。ベンダの製品５０は、例えば、ミドルウェアと呼ばれるもので、利用者プログラム６０に様々な機能を提供する。本実施形態では、製品５０として、オブジェクト指向の環境でＸＭＬプロセッサの機能を提供するものを想定する。また、製品５０は、ＪＡＸＰインターフェースを実装した「ファクトリ／ストラテジパターン」を適用しているプログラム製品群であり、ベンダが異なっても共通の規格にしたがって構成され、共通の規格にしたがったＡＰＩを提供する。
【００２８】
利用者プログラム６０は、ＡＰＩ利用部６１を通じて製品５０を利用する。従来のシステム（図１）では、利用者プログラム６０内に、製品固有実装部が直接組み込まれていた。すなわち、従来は、利用者プログラム６０が直接製品５０のオブジェクトを生成していた。一方、本実施形態（図２）の構成では、利用者プログラム６０のＡＰＩ利用部６１は、オブジェクト供給機構１によって規定されるＡＰＩを参照する。
【００２９】
オブジェクト供給機構１は、利用者プログラム６０に代わって、製品固有実装部１１を有しており、製品５０−１から５０−４等それぞれについて固有の情報を設定し、各製品５０−１から５０−４等を実装する（例えば、各製品５０−１から５０−４等のオブジェクトを生成する）。その場合に、オブジェクト供給機構１は、固定された情報によって各製品５０−１から５０−４等の製品ごとのオブジェクトを実装するのではなく、ライブラリとして提供される各製品５０−１から５０−４等のそれぞれから、固有情報抽出部１２が、製品固有の情報を抽出し、各製品５０−１から５０−４等の製品ごとのオブジェクトを実装するために必要な情報を動的に組み立てる。製品固有実装部１１は、組み立てられた情報を基に、各製品５０−１から５０−４等のそれぞれのオブジェクトを生成し、利用者プログラム６０からの要求時にオブジェクトを提供する。
【００３０】
一方、オブジェクト供給機構１のＡＰＩ定義部１３は、利用者プログラム６０に対してＡＰＩを提供する。
【００３１】
このように、図２の構成では、利用者プログラム６０側で製品５０のＡＰＩに関係する処理が一切不要になる。さらに、製品５０−１から５０−４等のそれぞれに固有の情報が動的に組み立てられるので、製品５０−１から５０−４等のアップデート等においても、安定したオブジェクト供給を受けられる。このため、利用者プログラム６０は、本来のアプリケーションに必要な処理の実装に専念できる。
【００３２】
図３に、オブジェクト供給機構１の構成を示す。図３のように、オブジェクト供給機構１は、２つの処理モジュール（処理モジュール１、処理モジュール２）を有している。
【００３３】
処理モジュール１は、利用者プログラム６０からの要求により、ベンダの製品５０−１から５０−４にアクセスして、製品構造を解析し、メタ情報１４を生成するメタ情報生成装置１２Ａの機能を提供する。メタ情報生成装置１２Ａは、図２の固有情報抽出部１２に該当する。図３に示したように、本実施形態では、製品５０−１から５０−４は、情報システムの資源１を構成する。
【００３４】
処理モジュール２は、オブジェクト供給装置１１Ａである。処理モジュール２は、生成されたメタ情報１４から製品オブジェクトを生成し、利用者プログラム６０に供給する。オブジェクト供給装置１１Ａは、図２の製品固有実装部１１に該当する。図３に示したように、本実施形態では、メタ情報１４は、情報システムの資源２を構成する。
【００３５】
（１）図３において、利用者は、不図示のコンピュータにおいて入力装置を操作し、資源１内に、製品５０−１から５０−４等を登録し、あるいは、削除する。さらに、利用者は、利用者プログラム６０の実行時に利用者プログラム６０が、資源１のいずれかの製品５０−１から５０−４等を利用するように指定する。この指定は、例えば、利用者プログラム６０の実行時に、逐一製品５０−１から５０−４等の製品名、バージョン等を指定するようにしてもよい。また、利用者プログラム６０が起動時に参照する初期設定ファイル、環境変数等に、製品５０−１から５０−４等の製品名、バージョン等を設定しておいて、利用者プログラム６０が参照するようにしてもよい。また、製品５０−１から５０−４等のインストール時に、どの製品を優先するかを設定しておき、利用者プログラム６０の実行時に、その優先順位にしたがって製品名、バージョン等を選択するようにしてもよい。
【００３６】
（２）すると、利用者プログラム６０は、オブジェクト供給機構１のメタ情報生成装置１２Ａにアクセスし、現在指定されている製品５０−１から５０−４等の製品名、バージョンに基づく、製品５０−１から５０−４等のファイルの解析を指示する。このようなファイルは、通常、ベンダからライブラリとして供給される。ここでは、このようなファイルは、すでに、資源１に登録されているものとする。そして、メタ情報生成装置１２Ａは、製品名、バージョンに基づいて決定される資源１の製品５０のファイルから情報を読み出し、製品構造を解析する。製品５０から情報を読み出す手段（関数、メソド等のＡＰＩ）は、ファクトリ／ストラテジ・デザインパターンの規格にしたがって、各ベンダから提供されるものとする。
【００３７】
（３）そして、メタ情報生成装置１２Ａは、解析した製品構造に基づき、メタ情報１４を生成する。ここで、メタ情報１４とは、製品５０−１から５０−４等のファイルから製品ごとのオブジェクトを生成するための必要な各ベンダ固有の情報をいう。
【００３８】
（４）次に、オブジェクト供給装置１１Ａは、メタ情報１４を基にオブジェクトを生成して製品オブジェクト記憶手段１５に格納する。
【００３９】
（５）利用者プログラム６０は、製品オブジェクト記憶手段１５に格納されたオブジェクトを利用者プログラム６０内に取り込んで利用する。すなわち、製品５０−１から５０−４等によって付与される機能を実行し、利用者プログラム６０としての機能を利用者に提供する。
【００４０】
＜処理フロー＞
図４から図７の図面に基づいて、本情報システムの処理フローを説明する。以下の処理では、ファクトリ／ストラテジ・デザインパターンを適用してオブジェクト指向プログラムによるＸＭＬプロセッサ製品群に関して実行されるオブジェクト供給機構１の処理例を説明する。
【００４１】
図４は、図３に示した処理モジュール１、すなわち、メタ情報生成装置１２Ａの処理を示すフローチャートである。メタ情報生成装置１２Ａは、メタ情報生成装置１２ＡからＸＭＬプロセッサの利用に必要な製品ごとに固有の情報であるファクトリクラス名を抽出して資源２へと格納する。
【００４２】
ここで、ファクトリクラスとは、製品５０−１から５０−４ごとに用意されている製品固有のオブジェクトを生成する機能を有するオブジェクトのクラスである。ファクトリクラスを抽出することにより、そのファクトリクラスのオブジェクト（ファクトリオブジェクトという）により、オブジェクト供給機構１は、各製品５０−１から５０−４等のオブジェクトを生成する。
【００４３】
この処理では、オブジェクト供給機構１は、利用者環境に存在する関連製品パッケージファイ群（資源１）から目的のファクトリクラスを検出して資源２を作成する。
【００４４】
すなわち、オブジェクト供給機構１は、資源１においてベンダの製品５０−１から５０−４等内の情報をそれぞれ検索する。ここで、本ファクトリ／ストラテジ・デザインパターンでは、製品ごとのファイルは、資源１内の所定の領域（フォルダ）に階層的に格納されており、そのような階層を構成するディレクトリ名およびファイル名は既知であると仮定する。例えば、ＡＰＩを通じて階層構造のツリー構造を示す情報を得ることができると仮定する。または、各ファイル内には、クラス名の一覧が記載されていると仮定する。さらに、各クラスについて、階層関係において上位のクラスを参照する手段が提供されていると仮定する。
【００４５】
さらに、各製品５０−１から５０−４等は、通常のオブジェクト指向の継承機能を有しているとする。すなわち、上位のクラスで規定されているデータ型およびメソドは、下位のクラスで利用可能であるとする。したがって、各クラスがファクトリクラスであるか否かを判定するために、各クラスの上位の階層に、ファクトリ／ストラテジ・デザインパターンの規格にしたがった共通のファクトリクラス（このような共通のファクトリクラスをインターフェースクラスという）が存在するか否かを判定すればよい。インターフェースクラスを継承した各製品固有のクラスは、オブジェクトを生成するファクトリオブジェクトを生成するクラスとなる。
【００４６】
以上のような環境において、オブジェクト供給機構１は、ライブラリの階層構造中に格納されたクラスの名称を１つ取得する。今、このクラスを対象クラスと呼ぶことにする。このようなクラスを取得する処理は、階層構造を辿りつつ、再帰的に実行されるので、図４では、再帰検索として示している（Ｓ３）。
【００４７】
そして、オブジェクト供給機構１は、対象クラスの上位のクラスの情報を取得する。上位のクラスの情報を取得する手段としては、通常のオブジェクト指向プログラミング環境では、スーパークラスを取得するメソド（例えば、Ｃｌａｓｓ．ｇｅｔＳｕｐｅｒｃｌａｓｓ（）という関数）が提供されている。
【００４８】
次に、オブジェクト供給機構１は、取得した上位のクラスが目的のクラス（規格にしたがった共通のファクトリクラス）であるか否かを判定する（Ｓ４）。取得した上位のクラスが共通のファクトリクラスであった場合、オブジェクト供給機構１は、現在の対象クラスの上位の階層に共通のファクトリクラスが存在するので、この対象クラスは、製品固有のファクトリクラスであると判断する。
【００４９】
そして、オブジェクト供給機構１は、注目クラスの名称を資源２に出力する（Ｓ５）。このようにして、オブジェクト供給機構１は、ある製品５０についてクラスを格納した階層構造（ディレクトリ構造）を辿りつつ、再帰的にＳ３−Ｓ５の処理を繰り返す。このようにして、各製品５０について、製品固有のファクトリクラスが取得される。
【００５０】
図５に、製品のファイル（製品パッケージともいう）から、再帰的にクラスを検索する
処理（図４のＳ３−Ｓ５の詳細）を示す。この処理では、オブジェクト供給機構１は、指定された製品５０のファイル内から目的のファクトリクラスを検出し、資源２の出力用情報保持領域へ検索結果を格納する。なお、製品パッケージからの情報取得はシステムに用意されたアクセスインターフェースを使用する。
【００５１】
例えば、ｊａｖａ（登録商標）によってライブラリ化されたＸＭＬプロセッサの場合、ｊａｖａ（登録商標）．ｕｔｉｌ．ｊａｒ．ＪａｒＦｉｌｅやｊａｖａ（登録商標）．ｌａｎｇ．Ｃｌａｓｓなどのｊａｖａ（登録商標）システムで用意されたアクセス用Ｉ／Ｆを使用して、ファイル内のクラスの階層情報を取得することができる。
【００５２】
実際の製品パッケージの内容は階層構造を形成しているため、最初に先頭の階層名を取得し、階層名をスタックに登録する（Ｓ１０）。
【００５３】
次に、その階層内に存在するクラスと対象のインターフェースクラスとをクラスの宣言部分を参照して検証する。このクラスの宣言部分は、例えば、プロトタイプ宣言と呼ばれる。すなわち、共通のファクトリクラスを継承している製品固有の実装クラス名を取得するために、階層化された各クラスのクラス情報（プロトタイプ宣言情報を含む）を再帰的に検索し（Ｓ１１）、Ｃｌａｓｓ．ｇｅｔＳｕｐｅｒｃｌａｓｓ（）メソッドを使ってｓｕｐｅｒクラスの情報を取得後、目的のファクトリクラス名と比較検証する（Ｓ１２）。
【００５４】
例えば、あるベンダから供給される製品のクラスは、以下のような階層構造（ディレクトリ構造）を有するライブラリに格納されている。
com/ベンダ名/xml/parser/dtd/FiDtdCommand.class
(中略)
com/ベンダ名/xml/parser/lex/XmlDocParser.class
(中略)
com/ベンダ名/xml/tree/DocumnetBuilderFactorylmpl.class
com/ベンダ名/xml/tree/DocumnetBuilderlmpl.class
com/ベンダ名/xml/serializer/OutputFormatter.class
オブジェクト供給機構１は、このような階層構造をcom => ベンダ名  => xml => parser => dtdのように、再帰的に辿りつつ、各階層に定義されているクラスを検索していく。例えば、階層「com」から階層「ベンダ名」に移動する場合には、階層「com」をスタックに積んで、現在の階層を「ベンダ名」とする。そして、階層「com/ベンダ名」においてクラスを検索する。その階層でクラスが見つかった場合に、オブジェクト供給機構１は、そのクラスのｓｕｐｅｒクラスの情報を取得して、目的のインターフェースクラスが存在するか否かを判定する。
【００５５】
ｓｕｐｅｒクラスにおいて、目的のインターフェースクラスを検出した場合には、本実施形態のオブジェクト供給機構１は、スタックに積まれた階層名とクラス名をピリオドで連結（補完）した名前を検出クラス名として記憶する領域に格納する（Ｓ１３）。本実施形態のファクトリ／ストラテジ・デザインパターンの規格では、階層名の区切りをピリオドで接続して、クラス名を付加した名称が正式の実装クラスの名称であると仮定している。
【００５６】
クラスが検出できなかった場合には、次の検証対象の階層が存在する場合にのみ再帰的な検証を実施する（Ｓ１４、Ｓ１５）。なお、本実施形態では、再帰処理から離脱する際には必ずスタックに積まれた階層名を１つずつ取り除く必要がある（Ｓ１６）。
【００５７】
全ての階層の再帰的検索（検証）を済ませて復帰した後、最後に対象クラスが検出できたかを、検出クラス名を記憶する領域の内容で判定する。このような検出クラス名は、例
えば、再帰呼び出しのリターン値で呼び出し側に返すようにすればよい。そのような目的クラス名を検出できた場合には資源２へとその内容を出力して処理を終了する。なお、何も検出できない場合には、再帰呼び出しのリターン値として、ＮＵＬＬが呼び出し側に返されることになる。
【００５８】
図６に、資源２の製品オブジェクト記憶手段１５（構造解析結果情報ファイルともいう）の構造を示す。構造解析結果情報ファイル（メタ情報）には、XMLプロセッサの「DocumentBuilder」クラスのオブジェクトを生成するために必要な製品ごとに固有の情報であるファクトリ実装クラス（共通のファクトリクラス継承したクラス）名が全て「定義名=実
装クラス名」の形式で出力される。
【００５９】
なお、本定義ファイルでは定義名に「dbf」を使っているが、この名前は自由に決めて
構わない。また、本定義ファイルに注釈行を含めてもよい。その場合は、行の先頭に「#
」記号などを明記すればよい。
【００６０】
本定義ファイルの内容はメタ情報生成装置１２Ａによって生成される。出力される内容については、利用者優先順位が高い順に先頭から出力される。この優先順位の基準は、例えば、オブジェクト指向プログラミングの環境で設定されたクラスの検索順位（クラスパスとも呼ばれる）に指定されているもの、指定されていないものといった順となる。ただし、本定義ファイルは後から手動で修正することもできる。
【００６１】
図７に、処理モジュール２、すなわち、オブジェクト供給装置１１Ａの処理フローを示す。オブジェクト供給装置１１Ａは資源２の内容を読み込んでＸＭＬプロセッサの利用に必要なファクトリクラスオブジェクトを生成する（Ｓ２０）。生成されたオブジェクトは生成順に配列に格納され（Ｓ２１）、管理される。生成されたオブジェクトについては、利用者プログラム６０が所定のＡＰＩを実行しオブジェクトを取得要求したときに、オブジェクトのアドレスが返されることになる。
【００６２】
利用者プログラム６０からのオブジェクト取得要求に対し、どの製品のオブジェクトを供給するかは、様々な方式が考えられる。デフォルトでは最初に生成されたオブジェクトが基本オブジェクトとして利用者プログラム６０に供給される（Ｓ２２）。ただし、製品５０−１から５０−４等の間で、利用者プログラム６０に提供されるべき優先順位を定めて所定の環境設定ファイル等に記録しておいても構わない。
【００６３】
また、それ以外のオブジェクトに関しても、利用者が必要に応じて製品、バージョン等を明示的に指定して取得することが可能である。なお、利用者に標準として供給されるオブジェクトは、資源２の先頭に定義されたクラスのオブジェクトであることから、資源２の内容を手動で編集した後に本装置を使うことで、簡単に基本のファクトリを変更することもできる。
【００６４】
以上述べたように、本実施形態の情報システムは、製品固有のオブジェクト生成処理実装部を利用者プログラム６０の外部に排除し、オブジェクト供給機構１に取り込んだ構成を採る。オブジェクト供給機構１は、製品５０のＡＰＩを通じて、製品５０ごとに固有の情報であるファクトリクラス名を抽出する。そして、抽出された製品５０ごとに固有のファクトリクラス名によりオブジェクトを動的に生成し、利用者プログラム６０に提供する。さらに、オブジェクト供給機構１は、固定された情報により製品５０のオブジェクトを生成するのではなく、製品５０の情報を解析することで得られる情報からオブジェクトを生成する。したがって、利用者プログラム６０は各ベンダが提供する製品５０の変更による影響を受けずに要求するＸＭＬプロセッサのオブジェクトを利用できる。
【００６５】
＜コンピュータ読み取り可能な記録媒体＞
コンピュータその他の機械、装置（以下、コンピュータ等）に上記いずれかの機能を実現させるプログラムをコンピュータ等が読み取り可能な記録媒体に記録することができる。そして、コンピュータ等に、この記録媒体のプログラムを読み込ませて実行させることにより、その機能を提供させることができる。
【００６６】
ここで、コンピュータ等が読み取り可能な記録媒体とは、データやプログラム等の情報を電気的、磁気的、光学的、機械的、または化学的作用によって蓄積し、コンピュータ等から読み取ることができる記録媒体をいう。このような記録媒体のうちコンピュータ等から取り外し可能なものとしては、例えばフレキシブルディスク、光磁気ディスク、CD-ROM、CD-R/W、DVD、DAT、８mmテープ、メモリカード等がある。
【００６７】
また、コンピュータ等に固定された記録媒体としてハードディスクやＲＯＭ（リードオンリーメモリ）等がある。
【図面の簡単な説明】
【００６８】
【図１】従来型の情報システムの機能ブロック図である。
【図２】本発明の一実施形態に係る情報システムの機能ブロック図である。
【図３】オブジェクト供給機構１の構成を示す図である。
【図４】メタ情報生成装置の処理を示すフローチャートである。
【図５】製品のファイル（製品パッケージともいう）から、再帰的にクラスを検索する処理を示すフローチャートである。
【図６】出力用情報保持領域の構造を示す図である。
【図７】オブジェクト供給装置１１Ａの処理フローを示すフローチャートである
【符号の説明】
【００６９】
１    オブジェクト供給機構
１１    製品固有実装部
１１Ａ  オブジェクト供給装置
１２    固有情報抽出部
１２Ａ  メタ情報生成部
１４    メタ情報
６０    利用者プログラム
【図１】
2007219612.tif 000003
【図２】
2007219612.tif 000004
【図３】
2007219612.tif 000005
【図４】
2007219612.tif 000006
【図５】
2007219612.tif 000007
【図６】
2007219612.tif 000008
【図７】
2007219612.tif 000009