(57)【要約】【課題】  オブジェクトの仕様変更を効率的に行うことができる情報処理装置、オブジェクト生成方法、オブジェクト変換方法、オブジェクト生成プログラム、オブジェクト変換プログラム及び記録媒体の提供を目的とする。【解決手段】  所定のオブジェクトを生成するオブジェクト生成手段と、前記所定のオブジェクトの型に応じてオブジェクトの属性情報が定義された第一の定義情報とを有する情報処理装置であって、前記所定のオブジェクトは、属性名と属性値とを対応づけて前記属性情報を管理する属性情報管理手段と、前記属性情報の設定及び取得の要求を受け付ける、複数の前記属性情報について共通のインタフェースとを有し、前記オブジェクト生成手段は、生成した前記所定のオブジェクトの型に対応した前記属性情報を前記第一の定義情報に基づいて該所定のオブジェクトに設定することにより上記課題を解決する。【選択図】  図３
2005301985.tif 000002
【特許請求の範囲】
【請求項１】
所定のオブジェクトを生成するオブジェクト生成手段と、前記所定のオブジェクトの型に応じてオブジェクトの属性情報が定義された第一の定義情報とを有する情報処理装置であって、
前記所定のオブジェクトは、属性名と属性値とを対応づけて前記属性情報を管理する属性情報管理手段と、前記属性情報の設定及び取得の要求を受け付ける、複数の前記属性情報について共通のインタフェースとを有し、
前記オブジェクト生成手段は、生成した前記所定のオブジェクトの型に対応した前記属性情報を前記第一の定義情報に基づいて該所定のオブジェクトに設定することを特徴とする情報処理装置。
【請求項２】
前記オブジェクト生成手段は、前記所定のオブジェクトの生成要求を受け付けるインタフェースを有し、前記生成要求に伴って指定された型に応じた前記属性情報を、生成した前記所定のオブジェクトに設定することを特徴とする請求項１記載の情報処理装置。
【請求項３】
前記属性情報管理手段は、前記属性名をキーとして前記属性値を格納するコンテナであることを特徴とする請求項１又は２記載の情報処理装置。
【請求項４】
前記属性情報の設定の要求を受け付けるインタフェースは、属性名と属性値とを入力情報とし、該入力情報として指定された属性値を属性名に対応づけて前記属性情報管理手段に登録することを特徴とする請求項１乃至３いずれか一項記載の情報処理装置。
【請求項５】
前記属性情報の取得の要求を受け付けるインタフェースは、属性名を入力情報とし、該入力情報として指定された属性名に対応づけられて前記属性情報管理手段に管理されている属性値を出力することを特徴とする請求項１乃至４いずれか一項記載の情報処理装置。
【請求項６】
前記第一の定義情報には、前記所定のオブジェクトの型に応じて他のオブジェクトとの関連情報が更に定義されており、
前記所定のオブジェクトは、前記関連情報を識別する関連名と前記他のオブジェクト又は該他のオブジェクトへの参照情報とを対応づけて前記関連情報を管理する関連情報管理手段と、前記関連情報の設定及び取得の要求を受け付ける、複数の前記関連情報について共通のインタフェースとを更に有し、
前記オブジェクト生成手段は、生成した前記所定のオブジェクトの型に対応した前記関連情報を前記第一の定義情報に基づいて該所定のオブジェクトに設定することを特徴とする請求項１乃至４いずれか一項記載の情報処理装置。
【請求項７】
前記オブジェクト生成手段は、前記生成要求に伴って指定された型に応じた前記関連情報を、生成した前記所定のオブジェクトに設定することを特徴とする請求項６記載の情報処理装置。
【請求項８】
前記関連情報管理手段は、それぞれの前記関連名をキーとして前記他のオブジェクト又は該他のオブジェクトへの参照情報を格納するコンテナであることを特徴とする請求項６又は７記載の情報処理装置。
【請求項９】
前記関連情報の設定の要求を受け付けるインタフェースは、前記関連名と前記他のオブジェクト又は該他のオブジェクトへの参照情報とを入力情報とし、該入力情報として指定された前記他のオブジェクト又は該他のオブジェクトへの参照情報を前記関連名に対応づけて前記関連情報管理手段に登録することを特徴とする請求項６乃至８いずれか一項記載の情報処理装置。
【請求項１０】
前記関連情報の取得の要求を受け付けるインタフェースは、前記関連名を入力情報とし、該入力情報として指定された関連名に対応づけられて前記関連情報管理手段に管理されている前記他のオブジェクト又は該他のオブジェクトへの参照情報を出力することを特徴とする請求項６乃至９いずれか一項記載の情報処理装置。
【請求項１１】
前記所定のオブジェクトの属性情報と属性値の設定先との対応関係が定義された第二の定義情報を管理する第二の定義情報管理手段と、
該第二の定義情報管理手段に管理されている前記第二の定義情報に基づき、前記所定のオブジェクトが有する属性値を、前記複数の属性情報について共通のインタフェースを介して取得し、取得した前記属性値を用いて前記所定のオブジェクトを前記設定先に対応した形式に変換する変換手段とを有することを特徴とする請求項１乃至１０いずれか一項記載の情報処理装置。
【請求項１２】
前記第二の定義情報には、前記所定のオブジェクトの型に応じて前記対応関係が定義されていることを特徴とする請求項１１記載の情報処理装置。
【請求項１３】
前記対応関係は、前記所定のオブジェクトの属性情報の種別に応じて定義されていることを特徴とする請求項１１又は１２記載の情報処理装置。
【請求項１４】
前記対応関係には、当該対応関係に係る属性値の前記設定先におけるデータ型が定義されていることを特徴とする請求項１１乃至１３いずれか一項記載の情報処理装置。
【請求項１５】
前記変換手段は、前記所定のオブジェクトを所定のデータベースのレコードに変換することを特徴とする請求項１１乃至１４いずれか一項記載の情報処理装置。
【請求項１６】
前記変換手段は、前記第二の定義情報に基づいて、前記所定のオブジェクトの属性情報を、前記レコードを構成する項目に変換することを特徴とする請求項１５記載の情報処理装置。
【請求項１７】
前記対応関係には、前記所定のデータベースにおいて前記レコードが登録されるテーブルを識別するための情報が定義されていることを特徴とする請求項１５又は１６記載の情報処理装置。
【請求項１８】
前記対応関係には、前記項目を識別するための情報が定義されていることを特徴とする請求項１６又は１７記載の情報処理装置。
【請求項１９】
前記変換手段は、前記所定のオブジェクトを所定のファイルに対応した形式に変換することを特徴とする請求項１１乃至１８いずれか一項記載の情報処理装置。
【請求項２０】
前記変換手段は、前記所定のオブジェクトを前記所定のファイルにおけるＸＭＬ形式の構造体を構成する要素に変換することを特徴とする請求項１９記載の情報処理装置。
【請求項２１】
前記変換手段は、前記第二の定義情報に基づいて、前記所定のオブジェクトの属性情報を前記所定のオブジェクトが変換された要素の子要素に変換することを特徴とする請求項２０記載の情報処理装置。
【請求項２２】
前記変換手段は、前記所定のオブジェクトを所定の機器に対応した形式に変換することを特徴とする請求項１１乃至２１いずれか一項記載の情報処理装置。
【請求項２３】
前記変換手段は、前記第二の定義情報に基づいて、前記所定のオブジェクトの属性情報を前記機器のパラメータに変換することを特徴とする請求項２２記載の情報処理装置。
【請求項２４】
前記変換手段は、前記設定先より取得した情報を、前記第二の定義情報に基づいて、前記複数の属性情報について共通のインタフェースを介して前記所定のオブジェクトに設定することにより、前記設定先に対応した形式の情報を前記所定のオブジェクトに変換することを特徴とする請求項１１乃至２３いずれか一項記載の情報処理装置。
【請求項２５】
コンピュータを用いたオブジェクト生成方法であって、
所定のオブジェクトの型に応じてオブジェクトの属性情報が定義された第一の定義情報を取得する第一の定義情報取得手順と、
属性名と属性値とを対応づけて前記属性情報を管理する属性情報管理手段と、前記属性情報の設定及び取得の要求を受け付ける、複数の前記属性情報について共通のインタフェースとを有する前記所定のオブジェクトを生成するオブジェクト生成手順と、
生成された前記所定のオブジェクトの型に対応した前記属性情報を前記第一の定義情報に基づいて該所定のオブジェクトに設定する属性情報設定手順とを有することを特徴とするオブジェクト生成方法。
【請求項２６】
前記第一の定義情報には、前記所定のオブジェクトの型に応じて他のオブジェクトとの関連情報が更に定義されており、
前記オブジェクト生成手順は、前記関連情報を識別する関連名と前記他のオブジェクト又は該他のオブジェクトへの参照情報とを対応づけて前記関連情報を管理する関連情報管理手段と、前記関連情報の設定及び取得の要求を受け付ける、複数の前記関連情報について共通のインタフェースとを更に有する前記所定のオブジェクトを生成し、
生成された前記所定のオブジェクトの型に対応した前記関連情報を前記第一の定義情報に基づいて該所定のオブジェクトに設定する関連情報設定手順を更に有することを特徴とする請求項２５記載のオブジェクト生成方法。
【請求項２７】
請求項２５又は２６記載のオブジェクト生成方法により生成された所定のオブジェクトの形式をコンピュータを用いて変換するオブジェクト変換方法であって、
前記所定のオブジェクトの属性情報と属性値の設定先との対応関係が定義された第二の定義情報に基づき、前記所定のオブジェクトが有する前記属性値を、前記複数の属性情報について共通のインタフェースを介して取得する属性取得手順と、
前記属性取得手順において取得された前記属性値を用いて前記所定のオブジェクトを前記設定先に対応した形式に変換する変換手順とを有することを特徴とするオブジェクト変換方法。
【請求項２８】
前記設定先より所定の情報を取得する情報取得手順と、
前記第二の定義情報に基づいて、前記情報取得手順において取得された前記所定の情報を、前記複数の属性情報について共通のインタフェースを介して前記所定のオブジェクトに設定することにより、前記設定先に対応した形式の情報を前記所定のオブジェクトに変換する逆変換手順とを更に有することを特徴とする請求項２７記載のオブジェクト変換方法。
【請求項２９】
コンピュータに、
所定のオブジェクトの型に応じてオブジェクトの属性情報が定義された第一の定義情報を取得する第一の定義情報取得手順と、
属性名と属性値とを対応づけて前記属性情報を管理する属性情報管理手段と、前記属性情報の設定及び取得の要求を受け付ける、複数の前記属性情報について共通のインタフェースとを有する前記所定のオブジェクトを生成するオブジェクト生成手順と、
生成された前記所定のオブジェクトの型に対応した前記属性情報を前記第一の定義情報に基づいて該所定のオブジェクトに設定する属性情報設定手順とを実行させるためのオブジェクト生成プログラム。
【請求項３０】
請求項２９記載のオブジェクト生成プログラムによって生成された所定のオブジェクトの形式をコンピュータに変換させるオブジェクト変換プログラムであって、
前記所定のオブジェクトの属性情報と属性値の設定先との対応関係が定義された第二の定義情報に基づき、前記所定のオブジェクトが有する前記属性値を、前記複数の属性情報について共通のインタフェースを介して取得する属性取得手順と、
前記属性取得手順において取得された前記属性値を用いて前記所定のオブジェクトを前記設定先に対応した形式に変換する変換手順とを有することを特徴とするオブジェクト変換プログラム。
【請求項３１】
請求項２９記載のオブジェクト生成プログラムを記録したコンピュータ読み取り可能な記録媒体。
【請求項３２】
請求項３０記載のオブジェクト変換プログラムを記録したコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、オブジェクト生成方法、オブジェクト変換方法、オブジェクト生成プログラム、オブジェクト変換プログラム及び記録媒体に関し、特に、所定の資源をオブジェクトとして管理する情報処理装置、オブジェクト生成方法、オブジェクト変換方法、オブジェクト生成プログラム、オブジェクト変換プログラム及び記録媒体に関する。
【背景技術】
【０００２】
近年においては、オブジェクト指向プログラミングが広く普及している。オブジェクト指向プログラミングとは、プログラムにおいて処理対象となる概念をクラスとしてモデル化することにより、当該概念を構成する情報（データ）と、当該概念に対する操作（処理手続）とを一まとまりの単位（オブジェクト）として管理し、プログラムの論理的な構造化を図るプログラミング技法の一つである（例えば、特許文献１）。
【０００３】
処理手続とデータとを一まとまりとすることにより、プログラムのモジュール化と、モジュールの再利用性を高めることができる。また、「継承」という概念を利用することにより、既存の機能との差分のみの実装によって、新たな機能を追加することが可能であり（差分プログラミング）、機能拡張等における開発効率を高めることができる。
【０００４】
例えば、データベースにおける一レコードを一つのオブジェクトにマッピングさせることにより、アプリケーションプログラムにおけるデータベースの取り扱いを容易かつ直感的にすることができる。ＲＤＢ（Relational DataBase）を例にとると、一つのテーブルを一つのクラスに対応させれば、当該クラスの一つのインスタンス（オブジェクト）は、当該テーブルの一つレコードにマッピングされる。
【０００５】
なお、機能拡張を容易に行うための技術という観点から、特許文献２には、制御プロセッサのデバイス・ドライバの特定のセグメントに相当する、ポータブルで個別化された複数の機能コンポーネントを含むシステムに関する発明が記載されている。当該機能コンポーネントは、低水準ＡＰＩと外部ＡＰＩを含み、ネットワーク上でのパケットの受信と転送や、ネットワーク・プロセッサと通信しそれに指示するために制御プロセッサが必要とする他の機能など様々なネットワーク・プロセッサ機能を実行する。更に、これらの機能コンポーネントは、利用可能な様々なタイプのプロセッサ・アーキテクチャおよびオペレーティング・システムに適応できるように、また利用可能なネットワーク・サービスを顧客や開発者がカスタマイズおよび拡張できるように設計されているため、プロセッサおよびオペレーティング・システムに依存しない拡張容易なネットワーク・プロセッサ・サービス・アーキテクチャを提供することができる。
【０００６】
また、特許文献３には、サービスソフトウェアを各サービス（コピー、ＦＡＸ、プリント等）に対応して設けることにより、デバイスの増加や変更等に柔軟に対応できるサービス提供装置に関する発明が記載されている。
【０００７】
更に、開発作業の効率化という観点から、特許文献４には、端末表示（標準出力に対する出力）を行うアプリケーション（端末表示アプリケーション）の標準出力から拡張制御コードを含む受信データを受信し、受信した拡張制御コードが指定する表示を行うための関数を呼び出し、呼び出した関数に基づいて表示部に表示を行うことにより、受信データに含まれる拡張制御コードが指定する種々の表示を表示部に表示することができるようにした画像形成装置の発明が記載されている。かかる画像形成装置には、ワークステーションやＰＣ上で動作する端末アプリケーションを効率的に移植することができる。
【特許文献１】特開平０９−０３４７１０号公報
【特許文献２】特開２００１−３２５２０３号公報
【特許文献３】特開２００３−２７４０６８号公報
【特許文献４】特開２００３−２８３７１７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
しかしながら、データベースのスキーマが変更された場合は、オブジェクトとレコードとの対応関係を維持するため、スキーマの変更に伴ってクラス仕様を変更する必要がある。すなわち、テーブルの項目を追加した場合は、当該項目に対応する属性を追加すると共に、当該属性の値が当該項目の値に反映されるよう新たな実装が必要となる。
【０００９】
また、新たなテーブルを追加した場合は、当該テーブルに対応した新たなクラスを定義すると共に、当該新たなクラスに対する実装を行う必要がある。更に、クラス仕様の変更は、当該クラスのオブジェクトを扱う上位アプリケーションにも影響するため、当該クラスのコンパイル及びリンクのみならず、既存の上位アプリケーションについても（例え当該上位アプリケーションが、拡張された属性を利用する必要がなくても）改めてコンパイル及びリンク等の煩雑な作業が要求されるといった問題がある。
【００１０】
本発明は、上記の点に鑑みてなされたものであって、オブジェクトの仕様変更を効率的に行うことができる情報処理装置、オブジェクト生成方法、オブジェクト変換方法、オブジェクト生成プログラム、オブジェクト変換プログラム及び記録媒体の提供を目的とする。
【課題を解決するための手段】
【００１１】
そこで上記課題を解決するため、本発明は、請求項１に記載されるように、所定のオブジェクトを生成するオブジェクト生成手段と、前記所定のオブジェクトの型に応じてオブジェクトの属性情報が定義された第一の定義情報とを有する情報処理装置であって、前記所定のオブジェクトは、属性名と属性値とを対応づけて前記属性情報を管理する属性情報管理手段と、前記属性情報の設定及び取得の要求を受け付ける、複数の前記属性情報について共通のインタフェースとを有し、前記オブジェクト生成手段は、生成した前記所定のオブジェクトの型に対応した前記属性情報を前記第一の定義情報に基づいて該所定のオブジェクトに設定することを特徴とする。
【００１２】
このような情報処理装置では、第一の定義情報に従った属性情報を有するオブジェクトを生成することができる。したがって、オブジェクトの属性情報を変更する際には当該第一の定義情報を修正すればよく、ソースコードの修正やコンパイル及びリンク等の作業は必要とされない。
【００１３】
また、上記課題を解決するため、本発明は、上記情報処理装置におけるオブジェクト生成方法、オブジェクト変換方法、前記オブジェクト生成方法をコンピュータに実行させるためのオブジェクト生成プログラム、前記オブジェクト変換方法をコンピュータに実行させるためのオブジェクト変換プログラム、又は前記オブジェクト生成プログラム若しくは前記オブジェクト変換プログラムを記録した記録媒体としてもよい。
【発明の効果】
【００１４】
本発明によれば、オブジェクトの仕様変更を効率的に行うことができる情報処理装置、オブジェクト生成方法、オブジェクト変換方法、オブジェクト生成プログラム、オブジェクト変換プログラム及び記録媒体を提供することができる。
【発明を実施するための最良の形態】
【００１５】
以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態における機器管理システムの構成例を示す図である。図１に示されるように本実施の形態における機器管理システム１は、データ管理装置１０と、ファイルサーバ２０と、一台以上の機器３０と、一台以上の端末４０とがＬＡＮ等のネットワーク５０を介して接続されることにより構成されている。
【００１６】
データ管理装置１０は、機器３０に対する管理機能を提供するコンピュータである。機器３０に対する管理機能とは、例えば、機器３０に関する各種の情報の提供や、機器３０に対する各種のパラメータの設定、及び機器３０に対するファームウェアのアップロード等が相当する。データ管理装置１０は、Ｗｅｂサーバとしての機能を有している。従って、端末４０のユーザは、データ管理装置１０の提供するＷｅｂページを介してデータ管理装置１０の機能を利用することができる。
【００１７】
ファイルサーバ２０は、データ管理装置１０が機器３０に対してアップロードするファームウェアを管理しているコンピュータである。すなわち、データ管理装置１０は、機器３０に対するファームウェアのアップロードを実行する前に、予め当該ファームウェアをファイルサーバ２０からダウンロードして管理しておく。なお、データ管理装置１０によるファイルサーバ２０からのファームウェアのダウンロードは、端末４０からの指示（
ＨＴＴＰリクエスト）に応じて実行される。
【００１８】
機器３０は、データ管理装置１０によって管理されているネットワーク機器であり、例えば、一般的なプリンタや、又は、プリンタ、コピー、若しくはファクシミリ等の複合サービスを実現するための複数のアプリケーションを有する複合機等が該当する。
【００１９】
端末４０は、データ管理装置１０から提供されるＷｅｂページを表示するためのＷｅｂブラウザを備えたＰＣ（Personal Computer）、ＰＤＡ（Personal Digital(Data) Assistants）、又は携帯電話等の端末であり、機器管理システム１のユーザが、機器管理システム１を利用する際に使用する。
【００２０】
次に、データ管理装置１０の詳細について説明する。図２は、本発明の実施の形態におけるデータ管理装置のハードウェア構成例を示す図である。図２のデータ管理装置１０は、それぞれバスBで相互に接続されているドライブ装置１００と、補助記憶装置１０２と、メモリ装置１０３と、演算処理装置１０４と、インタフェース装置１０５とを有するように構成される。
【００２１】
データ管理装置１０での処理を実現する機器管理プログラムは、CD―ROM等の記録媒体１０１によって提供される。機器管理プログラムを記録した記録媒体１０１がドライブ装置１００にセットされると、機器管理プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。補助記憶装置１０２は、インストールされた機器管理プログラムを格納すると共に、必要なファイルやデータ等を格納する。
【００２２】
メモリ装置１０３は、機器管理プログラムの起動指示があった場合に、補助記憶装置１０２から機器管理プログラムを読み出して格納する。演算処理装置１０４は、メモリ装置１０３に格納された機器管理プログラムに従ってデータ管理装置１０に係る機能を実行する。インタフェース装置１０５は例えばモデム、ルータ等で構成され、図１のネットワーク５０に接続するために用いられる。
【００２３】
図３は、本発明の実施の形態におけるデータ管理装置の機能構成例を示す図である。図３に示されるように、データ管理装置１０は、ｈｔｔｐｄ１１と、Ｗｅｂアプリケーション１２と、ソフト管理サービス１３ａ及び機器管理サービス１３ｂ等のＷｅｂサービス１３と、共通モジュール１４と、ネットワークレイヤ１５と、永続化ＤＢ（Ｄａｔａ  Ｂａｓｅ）１６と、永続化ファイル１７とから構成されている。
【００２４】
ｈｔｔｐｄ１１は、端末４０より受信したＨＴＴＰリクエストに基づいて、当該ＨＴＴＰリクエストにおいて要求されている情報（Ｗｅｂページ）の提供をＷｅｂアプリケーション１２に要求するデーモンプログラムである。ｈｔｔｐｄ１１は、また、Ｗｅｂアプリケーション１２が生成したＷｅｂページをＨＴＴＰレスポンスに含めて端末４０に対して送信する。Ｗｅｂアプリケーション１２は、端末４０より要求された処理を実行し、その処理結果を表示するＷｅｂページを生成するいわゆるＷｅｂアプリケーションである。
【００２５】
ソフト管理サービス１３ａは、機器３０にアップロードするためのファームウェアの管理機能（以下、「ファームウェア管理機能」という。）をＷｅｂサービスとして上位アプリケーション（Ｗｅｂアプリケーション１２）に提供するモジュール群である。ここで、ファームウェア管理機能には、ファイルサーバ２０からのファームウェアのダウンロード、当該ファームウェアの保存、当該ファームウェアに関する情報の提供、及び当該ファームウェアに対する機器３０へのアップロードスケジュールの設定等が相当する。
【００２６】
機器管理サービス１３ｂは、データ管理装置１０の管理下にある機器３０の管理機能（以下、「機器管理機能」という。）をＷｅｂサービスとして上位アプリケーションに提供するモジュール群である。ここで、機器管理機能には、機器３０に関する情報の提供、機器３０へのファームウェアのアップロード、及び機器３０に対する各種パラメータの設定等が相当する。
【００２７】
その他、符号１３ｃ及び符号１３ｄ等によって示されるモジュールは、機器管理に付随する各種サービスを提供するＷｅｂサービスの例示である。なお、Ｗｅｂアプリケーション１２とＷｅｂサービス１３との通信は、例えば、ＳＯＡＰ（Simple Object Access Protocol）によって行ってもよい。
【００２８】
永続化ＤＢ１６及び永続化ファイル１７は、各Ｗｅｂサービス１３の管理対象がモデル化されたオブジェクト（以下、「管理オブジェクト」という。）を永続化（保存）するための手段である。ここで、管理対象とは、例えば、ソフトウェア管理サービス１３ａであればファームウェアが相当し、機器管理サービス１３ｂであれば機器３０が相当する。したがって、ソフト管理サービス１３ａは、一つのファームウェアパッケージを一つの管理オブジェクトとして扱い、機器管理サービス１３ｂは、一台の機器３０を一つの管理オブジェクトとして扱う。なお、本実施の形態において、永続化ファイル１７は、ＸＭＬ（eXtensible Markup Language）形式によって管理オブジェクトを永続化する。
【００２９】
共通モジュール１４は、各種Ｗｅｂサービス１３に対して管理オブジェクトの生成手段を提供すると共に、Ｗｅｂサービス１３が、永続化ＤＢ１６に対するインタフェース（ＳＱＬ）や、永続化ファイル１７に対するインタフェース（ＤＯＭ（Document Object Model））や、機器３０に対する通信プロトコルを意識することなく、永続化ＤＢ１６、永続化ファイル１７及び機器３０等にアクセスするための手段（ＡＰＩ（Application Program Interface））を提供するモジュール群である。
【００３０】
共通モジュール１４について更に詳しく説明する。図４は、共通モジュールの機能構成例を示す図である。図４に示されるように、共通モジュール１４は、永続化ＡＰＩモジュール１４１、接続ＡＰＩモジュール１４２、オブジェクト生成モジュール１４３、雛型クラスモジュール１４４、及びオブジェクト定義ファイル１４５等より構成されている。
【００３１】
永続化ＡＰＩモジュール１４１は、管理オブジェクトの永続化手段（永続化ＤＢ１６及び永続化ファイル１７）に対するＡＰＩ（永続化ＡＰＩ）をＷｅｂサービス１３に対して提供するモジュールである。例えば、永続化ＡＰＩモジュール１４１は、管理オブジェクトの永続化機能、トランザクションの管理機能、管理オブジェクトに関する情報の検索、追加、削除、及び更新等の機能等を永続化ＡＰＩを介して提供する。したがって、例えば、ソフトウェア管理サービス１３ａは、永続化ＡＰＩモジュール１４１を利用することにより、ＳＱＬやファイル入出力インタフェース（ＤＯＭ等）を意識することなく、永続化ＤＢ１６及び永続化ファイル１７を操作することができる。
【００３２】
接続ＡＰＩモジュール１４２は、機器３０等のネットワーク資源に対するＡＰＩ（接続ＡＰＩ）をＷｅｂサービス１３に対して提供するモジュールである。例えば、接続ＡＰＩモジュールは、機器３０を検出する機能、機器３０から情報を取得する機能、機器３０に情報を設定する機能、及び機器３０を遠隔操作する機能等を接続ＡＰＩを介して提供する。しがって、例えば、機器管理サービス１３ｂは、接続ＡＰＩモジュール１４２を利用することにより、機器３０との通信プロトコルを意識することなく、機器３０を操作することができる。
【００３３】
オブジェクト定義ファイル１４５は、各Ｗｅｂサービス１３の管理オブジェクトの仕様が、管理オブジェクトの「型」ごとに定義されているファイルである。一般にオブジェクトの型は「クラス」という用語を用いるが、ここで「型」という用語を用いるのは、実際にソースコードとして実装されているクラスとの混同を避けるためである。すなわち、後述より明らかなように、本実施の形態においてはオブジェクト定義ファイル１４５において定義された全ての「型」のオブジェクトは、同一の実装クラス（雛型クラス）のインスタンスとして生成される。したがって、用語上両者を明確に区別する趣旨である。なお、管理オブジェクトの型は、管理対象の種別ごとに定義される。したがって、ファームウェアに対するｆｉｒｍｗａｒｅ型や、機器３０に対するｄｅｖｉｃｅ型等がそれぞれ型として定義される。
【００３４】
雛型クラスモジュール１４４は、オブジェクト定義ファイル１４５によって定義されている管理オブジェクトの全ての型について共通の雛形となる一つのクラス（雛形クラス）についての実装がされているモジュールである。オブジェクト生成モジュール１４３は、Ｗｅｂサービス１３から要求された管理オブジェクトを、オブジェクト定義ファイル１４５と雛型クラスモジュール１４４とを利用することによりインスタンス化し、当該管理オブジェクトをＷｅｂサービス１３に提供する機能が実装されたモジュールである。
【００３５】
オブジェクト定義ファイル１４５について更に詳しく説明する。図５は、オブジェクト定義ファイルの定義例を示す図である。図５に示されるように、本実施の形態におけるオブジェクト定義ファイル１４５の内容は、ＸＭＬ（eXtensible Markup Language）によって定義されている。オブジェクト定義ファイル１４５において、＜ｏｂｊｅｃｔ＞タグで囲まれたｏｂｊｅｃｔ要素は、各管理オブジェクトの型を定義する要素である。本実施の形態においては、ｏｂｊｅｃｔ要素１４５１とｏｂｊｅｃｔ要素１４５２とによって二つの型が定義されている。各ｏｂｊｅｃｔ要素には、ｔｙｐｅ属性が定義されており、ｔｙｐｅ属性によってそれぞれの型の名前（型名）を識別することができる。すなわち、ｏｂｊｅｃｔ要素１４５１及び１４５２において管理オブジェクトの型名は、ｍｏｄｕｌｅ又はｆｉｒｍｗａｒｅとして定義されている。なお、参考までに、ｆｉｒｍｗａｒｅは、ファームウェアのパッケージを表現した型であり、ｍｏｄｕｌｅは、当該パッケージに含まれている各モジュールを表現した型である。
【００３６】
ｏｂｊｅｃｔ要素には、子要素として、＜ｆｉｅｌｄ＞タグで囲まれたｆｉｅｌｄ要素が定義され得る。一つのｆｉｅｌｄ要素は管理オブジェクトにおける一つの属性に対する定義に相当し、その属性名を示すｎａｍｅ属性と、属性のデータ型を示す「ｔｙｐｅ属性」とを有する。例えば、ｏｂｊｅｃｔ要素１４５２には、ｆｉｅｌｄ要素１４５２ａ、１４５２ｂ、１４５２ｃ、１４５２ｄ、１４５２ｅ及び１４５２ｆの６つのｆｉｅｌｄ要素が含まれているところから、ｆｉｒｍｗａｒｅ型の管理オブジェクトは、６つの属性を有することが分かる。
【００３７】
ｏｂｊｅｃｔ要素には、更に、子要素として、＜ｒｅｌａｔｉｏｎ＞タグで囲まれたｒｅｌａｔｉｏｎ要素が定義され得る。一つのｒｅｌａｔｉｏｎ要素は、当該管理オブジェクトと他の管理オブジェクトとの関連（集約関係）に対する定義に相当し、各関連を識別するための関連名を示すｎａｍｅ属性と、関連先の管理オブジェクトの型を識別するためのｔｙｐｅ属性とを有する。例えば、ｏｂｊｅｃｔ要素１４５２には、ｒｅｌａｔｉｏｎ要素１４５２ｇが含まれている。ｒｅｌａｔｉｏｎ要素１４５２ｇのｔｙｐｅ属性の値が「ｍｏｄｕｌｅ」であるところから、ｆｉｒｍｗａｒｅ型の管理オブジェクトは、ｍｏｄｕｌｅ型の管理オブジェクトを集約することが分かる。
【００３８】
ｒｅｌａｔｉｏｎ要素には子要素として、詳細情報が定義されている。図６は、一つの関連についての詳細情報の例を示す図である。図６には、ｒｅｌａｔｉｏｎ要素１４５２ｇが図５より抜き出されている。ｒｅｌａｔｉｏｎ要素１４５２ｇにおいて、符号１４５２ｇ−１０で示される部分が詳細情報である。詳細情報１４５２ｇ−１０は、一つ以上のｃａｐａｂｉｌｉｔｙ要素（＜ｃａｐａｂｉｌｉｔｙ＞タグで囲まれた要素）によって構成されている。一つのｃａｐａｂｉｌｉｔｙ要素は、詳細情報を構成するパラメータの一つに対応しており、ｎａｍｅ属性、ｔｙｐｅ属性及びｖａｌｕｅ属性を有している。ｎａｍｅ属性は、各パラメータを識別するためにそれぞれのパラメータに付された名前を示す。ｔｙｐｅ属性は、パラメータのデータ型を示す。ｖａｌｕｅ属性は、パラメータの値を示す。
【００３９】
例えば、ｃａｐａｂｉｌｉｔｙ要素１４５２ｇ−１１は、ｎａｍｅ属性の値が「ｍｕｌｔｉｐｌｅ」であり、ｖａｌｕｅ属性の値が「ｔｒｕｅ」であることから、ｍｏｄｕｌｅｓ関連は、多重関連（複数の子オブジェクトが属しうる関連）であることを示している。ｃａｐａｂｉｌｉｔｙ要素１４５２ｇ−１２は、ｎａｍｅ属性の値が「ｒｅｌａｔｉｏｎＴｙｐｅ」であり、ｖａｌｕｅ属性の値が「ｃｏｍｐｏｓｉｔｅ」であることから、ｍｏｄｕｌｅｓ関連は、集約関係であることを示している。ｃａｐａｂｉｌｉｔｙ要素１４５２ｇ−１３及びｃａｐａｂｉｌｉｔｙ要素１４５２ｇ−１４については、それぞれのｎａｍｅ属性が、「ｌｏｃａｌ」、「ｆｏｒｅｉｇｎ」であるところから、親オブジェクトと子オブジェクトとの関連の保持の仕方についての定義であることを示している。すなわち、当該定義は、ｌｏｃａｌパラメータの値が「ｉｄ」であり、ｆｏｒｅｉｇｎパラメータの値が「ｐｉｄ」であるところから、子オブジェクトにおけるｐｉｄ属性の値に、親オブジェクトのｉｄ属性の値を設定することにより、親子関係を保持することを示している。すなわち、ｆｉｒｍｗａｒｅオブジェクトの子オブジェクトとして定義されているｍｏｄｕｌｅオブジェクトは、ｐｉｄ属性を有しており（図５のｆｉｅｌｄ要素１４５１ａ参照）、当該ｐｉｄ属性の値に、親オブジェクトであるｆｉｒｍｗａｒｅオブジェクトのｉｄ属性の値が設定されるというわけである。
【００４０】
このように、オブジェクト定義ファイル１４５（図５）には、管理オブジェクトの型に応じて属性情報及び関連情報が定義されている。なお、ｆｉｅｌｄ要素及びｒｅｌａｔｉｏｎ要素には、子要素として、＜ｄｅｓｃｒｉｐｔｉｏｎ＞タグで囲まれたｄｅｓｃｒｉｐｔｉｏｎ要素が含まれている。ｄｅｓｃｒｉｐｔｉｏｎ要素は、ユーザが認識可能な表現で属性又は関連の意味を示したものである。更に、ｆｉｅｌｄ要素には、マッピング情報が子要素として含まれている。マッピング情報は、管理オブジェクトを永続化等する際に、当該ｆｉｅｌｄ要素に対応する属性又は関連を永続化先等にどのようにマッピングさせるかについての定義を含む情報であるが、詳細については後述する。
【００４１】
図５に示されるオブジェクト定義ファイル１４５の定義内容をクラス図に示すと図７のようになる。図７は、オブジェクト定義ファイルの定義内容を示すクラス図である。図７においては、ｆｉｒｍｗａｒｅ型の管理オブジェクト（以下、単に「ｆｉｒｍｗａｒｅオブジェクト」という。）は、６つの属性（ｉｄ、ｎａｍｅ、ｖｅｒｓｉｏｎ、ｐａｃｋＳｉｚｅ、ｐａｃｋＵＲＬ及びｄｏｗｎＬｏａｄＤａｔｅ）を有しており、更に、ｍｏｄｕｌｅ型の管理オブジェクト（以下、単に「ｍｏｄｕｌｅオブジェクト」という。）を集約していることが示されている。
【００４２】
次に、雛型クラスモジュール１４４に実装されている雛型クラスについて説明する。既に説明したように、雛型クラスは、オブジェクト定義ファイル１４５によって定義されている全ての型の管理オブジェクトについて共通の雛形となるクラスである。図８は、雛型クラスのクラス仕様を示す図である。
【００４３】
雛型クラスには、表１２１に示されるような属性（メンバ変数）が定義されている。ｔｙｐｅは、管理オブジェクトの型名を格納するための文字列型の変数である。ｐｒｏｐｅｒｔｉｅｓは、管理オブジェクトの属性値をその属性名をキーとして格納するためのマップ（ｍａｐ）型の変数である。ここで、マップとは、一つ以上の値をそれぞれに対応する「キー」に対応づけて管理するコンテナの一つである。コンテナとは、任意の型を格納することができる汎用データ構造をいい、例えばＳＴＬ（Standard Template Library）においては、マップ（map）以外に、vector、list、deque（double ended queue）、及びset等が用意されている。
【００４４】
なお、各属性値は様々なデータ型を取り得るため、マップにおける「値」については、あらゆるデータ型を扱うことができるデータ型（例えば、Ｊａｖａ（登録商標）言語ではＯｂｊｅｃｔ型等）として定義すればよい。なお、以下において、「あらゆるデータ型を扱うことができるデータ型」を「Ｏｂｊｅｃｔ型」と表現することとする。ｃｈｉｌｄｒｅｎは、集約する管理オブジェクト（子オブジェクト）又は当該管理オブジェクトへのポインタ等の参照情報をその管理オブジェクトの名前をキーとして格納するマップ型の変数である。なお、以下においては、管理オブジェクト自体とその参照情報とは特に区別しないで全て管理オブジェクトとして記載する。
【００４５】
雛型クラスには、更に、表１２２に示されるようなメソッドが定義されている。ｓｅｔＴｙｐｅメソッドは、型名を設定させるためのメソッドであり、引数（ｔｙｐｅ）に指定された値をメンバ変数ｔｙｐｅに代入する。ｓｅｔＦｉｅｌｄメソッドは、第一引数（ｋｅｙ）に指定された属性名をキーとして、第二引数（ｖａｌｕｅ）に指定された属性値をメンバ変数ｐｒｏｐｅｒｔｉｅｓに登録する。
【００４６】
ｓｅｔＣｈｉｌｄｒｅｎメソッドは、子オブジェクトを設定させるためのメソッドであり、第一引数（ｃｈｉｌｄＮａｍｅ）に指定された子オブジェクトの名前をキーとして、第二引数（ｃｈｉｌｄｒｅｎ［］）に指定された子オブジェクトの配列をメンバ変数ｃｈｉｌｄｒｅｎに登録する。なお、ｓｅｔＦｉｅｌｄメソッド及びｓｅｔＣｈｉｌｄｒｅｎメソッドが、引数として属性名又は子オブジェクトの名前を要求しているところからも明らかなように、両メソッドは、属性又は関連の種別にかかわらず共通に利用されるものである。
【００４７】
図９は、雛型クラスにおける属性情報の管理イメージを示す図である。図９においては、雛型クラス１２３が、Ｗｅｂサービス１３からのｓｅｔＦｉｅｌｄメソッドの呼び出しに基づいて、マップ型のメンバ変数ｐｒｏｐｅｒｔｉｅｓ１２４に属性値を設定（ｐｕｔ）する様子と共に、ｇｅｔＦｉｅｌｄメソッドの呼び出しに基づいて、ｐｒｏｐｅｒｔｉｅｓ２４より属性値を取得（ｇｅｔ）する様子を示している。ｐｒｏｐｅｒｔｉｅｓ１２４においては、属性名をキーとして、当該属性に対する値が管理されている。
【００４８】
ｇｅｔＴｙｐｅメソッド（図８）は、型名を取得させるためのメソッドであり、メンバ変数ｔｙｐｅに格納されている型名を返却する。ｇｅｔＦｉｅｌｄメソッドは、属性値を取得させるためのメソッドであり、引数（ｋｅｙ）に指定された属性名をキーとして、メンバ変数ｐｒｏｐｅｒｔｉｅｓより属性値を取得し、その属性値を返却する。ｇｅｔＣｈｉｌｄｒｅｎメソッドは、子オブジェクトを取得させるためのメソッドであり、引数（ｃｈｉｌｅｄＮａｍｅ）に指定された子オブジェクトの名前をキーとして、メンバ変数ｃｈｉｌｄｒｅｎより子オブジェクトを取得し、その子オブジェクトの配列を返却する。なお、ｇｅｔＦｉｅｌｄメソッド及びｇｅｔＣｈｉｌｄｒｅｎメソッドが、引数として属性名又は子オブジェクトの名前を要求しているところからも明らかなように、両メソッドは、属性又は関連の種別にかかわらず共通に利用されるものである。
【００４９】
その他、雛型クラスには、コンストラクタやデストラクタについても定義されているが、図８においては便宜上省略している。
【００５０】
次に、オブジェクト生成モジュール１４３による管理オブジェクトの生成処理、すなわち、管理オブジェクトをメモリ装置１０３におけるメモリ領域に割り当てる処理について説明する。図１０は、管理オブジェクトの生成処理を説明するためのフローチャートである。図１０においては、ソフト管理サービス１３ａがｆｉｒｍｗａｒｅオブジェクトの生成（インスタンス化）をオブジェクト生成モジュール１４３に要求した場合を例として説明する。
【００５１】
ステップＳ１０１において、ソフト管理サービス１３ａは、オブジェクト生成モジュール１４３に対してｆｉｒｍｗａｒｅ型の管理オブジェクトの生成を要求する。具体的には、ソフト管理サービス１３ａは、オブジェクト生成モジュール１４３に実装されたオブジェクト生成メソッド（ｃｒｅａｔｅＩｎｓｔａｎｃｅ）を、その引数にｆｉｒｍｗａｒｅオブジェクトの型名（"ｆｉｒｍｗａｒｅ"）を指定して呼び出す。
【００５２】
ステップＳ１０１に続いてステップＳ１０２に進み、オブジェクト生成メソッドを呼び出されたオブジェクト生成モジュール１４３は、オブジェクト定義ファイル１４５の定義内容（以下、単に「定義内容」という。）をメモリ装置１０３に読み込む。ステップＳ１０２に続いてステップＳ１０３に進み、オブジェクト生成モジュール１４３は、定義内容の中からｏｂｊｅｃｔ要素を一つ取得する。
【００５３】
ステップＳ１０３に続いてステップＳ１０４に進み、オブジェクト生成モジュール１４３は、取得したｏｂｊｅｃｔ要素（以下、「カレントｏｂｊｅｃｔ要素」という。）のｔｙｐｅ属性の値が、オブジェクト生成メソッドの引数に指定された型名（"ｆｉｒｍｗａｒｅ"）と同一であるか否かを判断する。同一で無い場合は、同一のｏｂｊｅｃｔ要素が取得されるまで、ｏｂｊｅｃｔ要素の取得を繰り返す（Ｓ１０３、Ｓ１０４）。その結果、目的とするｏｂｊｅｃｔ要素が無かった場合（ステップＳ１０３で「失敗」の場合）は、オブジェクト生成モジュール１４３は、オブジェクト生成メソッドの戻り値としてエラーを返却する。
【００５４】
目的とするｏｂｊｅｃｔ要素が取得できた場合は、ステップＳ１０４に続いてステップＳ１０５に進み、オブジェクト生成モジュール１４３は、雛型クラスモジュール１４４に実装されている雛型クラスのコンストラクタを呼び出すことにより、雛型オブジェクトをインスタンス化する。更に、オブジェクト生成モジュール１４３は、カレントｏｂｊｅｃｔ要素のｔｙｐｅ属性の値（"ｆｉｒｍｗａｒｅ"）を引数として雛型オブジェクトのｓｅｔＴｙｐｅメソッドを呼び出すことにより、雛型オブジェクトに対して、型名を設定する。
【００５５】
ステップＳ１０５に続いてステップＳ１０６に進み、オブジェクト生成モジュール１４３は、カレントｏｂｊｅｃｔ要素の中からｆｉｅｌｄ要素を一つ取得する。ｆｉｅｌｄ要素を取得できた場合は、ステップＳ１０６に続いてステップＳ１０７に進み、オブジェクト生成モジュール１４３は、取得したｆｉｅｌｄ要素のｎａｍｅ属性の値を第一引数として指定し、雛型オブジェクトのｓｅｔＦｉｅｌｄメソッドを呼び出すことにより、雛型オブジェクトに対して属性を追加する。
【００５６】
例えば、ｆｉｅｌｄ要素１４５２ａ（図５）が取得された場合は、第一引数には、"ｉｄ"が指定される。なお、ｓｅｔＦｉｅｌｄメソッドの第二引数（属性の値）には、当該属性の初期値（例えば、「０」等）を指定すればよい。初期値については、オブジェクト定義ファイル１４５において、ｆｉｅｌｄ要素の属性として指定できるようにし、その値をｓｅｔＦｉｌｅｄメソッドの第二引数に指定するようにしてもよい。
【００５７】
オブジェクト生成モジュール１４３は、更に、その他のｆｉｅｌｄ要素についても同様の処理を繰り返すことにより、カレントｏｂｊｅｃｔ要素の子要素として定義された全てのｆｉｅｌｄ要素に対応する属性を雛型オブジェクトに設定する（Ｓ１０６、Ｓ１０７）。全てのｆｉｅｌｄ要素に対する処理が完了すると（ステップＳ１０６で「失敗」の場合）、ステップＳ１０６に続いてステップＳ１０８に進み、オブジェクト生成モジュール１４３は、カレントｏｂｊｅｃｔ要素の中からｒｅｌａｔｉｏｎ要素を一つ取得する。ｒｅｌａｔｉｏｎ要素を取得できた場合は、ステップＳ１０８に続いてステップＳ１０９に進み、オブジェクト生成モジュール１４３は、取得したｒｅｌａｔｉｏｎ要素のｎａｍｅ属性の値を第一引数として指定し、雛型オブジェクトのｓｅｔＣｈｉｌｄｒｅｎメソッドを呼び出すことにより、雛型オブジェクトに対して子オブジェクトとの関連を追加する。
【００５８】
例えば、ｒｅｌａｔｉｏｎ要素１１２ｆ（図５）が取得された場合は、第一引数には、"ｍｏｄｕｌｅｓ"が指定される。なお、ｓｅｔＦｉｅｌｄメソッドの第二引数（子オブジェクト）には、既に子オブジェクトがインスタンス化されているのであれば、当該管理オブジェクトを指定してもよいし、まだインスタンス化されていないのであれば、例えばＮＵＬＬ値を指定するようにしてもよい。
【００５９】
オブジェクト生成モジュール１４３は、更に、その他のｒｅｌａｔｉｏｎ要素についても同様の処理を繰り返すことにより、カレントｏｂｊｅｃｔ要素の子要素として定義された全てのｒｅｌａｔｉｏｎ要素に対応する関連を雛型オブジェクトに設定する（Ｓ１０８、Ｓ１０９）。全てのｒｅｌａｔｉｏｎ要素に対する処理が完了すると（ステップＳ１０８で「失敗」の場合）、オブジェクト生成モジュール１４３は、属性及び関連を設定した雛型オブジェクトをオブジェクト生成メソッドの戻り値としてソフト管理サービス１３ａに対して返却し、オブジェクト生成メソッドの処理を終了する。
【００６０】
以上によって、ソフト管理サービス１３ａは、'擬似的な'ｆｉｒｍｗａｒｅ型の管理オブジェクト（ｆｉｒｍｗａｒｅオブジェクト）を取得したことになる。ここで、'擬似的な'とは、厳密にはｆｉｒｍｗａｒｅオブジェクトは全ての型に対して共通な雛型クラスのインスタンスであるが、その中身、すなわち、マップ型のメンバ変数であるｐｒｏｐｅｒｔｉｅｓには、ｆｉｒｍｗａｒｅ型に対応した属性情報がセットされていることにより、ｆｉｒｍｗａｒｅ型としての特性が付加された状態を表現したものである。
【００６１】
したがって、ソフト管理サービス１３ａは、ｆｉｒｍｗａｒｅオブジェクトのｓｅｔＦｉｅｌｄメソッドやｇｅｔＦｉｅｌｄメソッドを呼び出すことにより、ｆｉｒｍｗａｒｅ型に定義された属性の設定や属性値の取得をしたり、ｓｅｔＣｈｉｌｄｒｅｎメソッドやｇｅｔＣｈｉｌｄｒｅｎメソッドを呼び出すことにより、子オブジェクトの設定や取得をしたりと、雛型オブジェクトをｆｉｒｍｗａｒｅ型の管理オブジェクト（ｆｉｒｍｗａｒｅオブジェクト）として扱うことができる。
【００６２】
このように、データ管理装置１０によれば、属性情報や関連情報を動的に設定可能な雛型クラスに基づいてそれぞれの型のオブジェクトを生成するため、オブジェクト定義ファイル１４５の定義に従った属性情報及び関連情報を有するオブジェクトを生成することができる。ここで、本実施の形態において「型」として表現した概念は、実質的には「クラス」と同義である。したがって、新たなクラスを追加したい場合や、既存のクラスの仕様（属性情報、関連情報）を変更したい場合には、オブジェクト定義ファイル１４５を修正するだけでよく、ソースコードの修正、コンパイル及びリンク等の煩雑な作業をする必要はない。また、拡張された属性情報や関連情報に無関係な既存のアプリケーションのソースコードについても改めてコンパイル及びリンク等を実行する必要はなく、オブジェクトの仕様変更に伴う開発作業を効率的なものとすることができる。
【００６３】
次に、管理オブジェクトを入手したソフト管理サービス１３ａからの要求に基づいて、永続化ＡＰＩモジュール１４１が、ｆｉｒｍｗａｒｅオブジェクトを永続化ＤＢ１６へ永続化する際の処理について説明する。
【００６４】
図１１は、永続化ＡＰＩモジュールのクラス図の例である。図１１に示されるように、永続化ＡＰＩモジュール１４１は、主に、永続化ＡＰＩクラス１４１ａ、ＸＭＬ永続化クラス１４１ｂ、ＤＢ永続化クラス１４１ｃ、メモリ永続化クラス１４１ｄ、ＸＭＬ操作クラス１４１ｅ、ＤＢ操作クラス１４１ｆ、メモリ操作クラス１４１ｇ、及びトランザクションハンドルクラス１４１ｈ等から構成されている。
【００６５】
永続化ＡＰＩクラス１４１ａは、各種の永続化手段にアクセスするためのインタフェースのみが定義された、いわゆる抽象クラスである。ＸＭＬ永続化クラス１４１ｂ、ＤＢ永続化クラス１４１ｃ、及びメモリ永続化クラス１４１ｄは、永続化ＡＰＩクラス１４１ａのサブクラスであり、永続化ＡＰＩクラス１４１ａにおいて定義されたインタフェースについて、それぞれが対応する特定の永続化手段に応じた実装がなされている、いわゆる具象クラスである。ＸＭＬ永続化クラス１４１ｂは、永続化ファイル１７に対応したクラスである。ＤＢ永続化クラス１４１ｃは、永続化ＤＢ１６に対応したクラスである。また、メモリ永続化クラス１４１ｄは、メモリ装置１０３に対応したクラスである。
【００６６】
ＸＭＬ永続化クラス１４１ｂ等の具象クラスが、一つの永続化ＡＰＩクラス１４１ａによって抽象化されていることによって、Ｗｅｂサービス１３のソースコードにおいては、永続化ＡＰＩクラス１４１ａのみを意識した実装を行うことができ、新たな永続化手段が追加された場合、すなわち、当該新たな永続化手段に対する具象クラスが永続化ＡＰＩクラス１４１ａのサブクラスとして追加された場合であっても、Ｗｅｂサービス１３のソースコードは修正する必要はない。
【００６７】
各具象クラスは、それぞれ、ＸＭＬ操作クラス１４１ｅ、ＤＢ操作クラス１４１ｆ、又はメモリ操作クラス１４１ｇ（以下、総称する場合「操作クラス」という。）を集約している。操作クラスは、各具象クラスが対応する永続化手段に依存したインタフェース（ＳＱＬやＤＯＭ等）を隠蔽したインタフェースを各具象クラスに提供するクラスである。トランザクションハンドルクラス１４１ｈは、各トランザクションを識別するために、それぞれのトランザクションに関する情報を管理するためのクラスである。
【００６８】
以下、シーケンス図に基づいて、ｆｉｒｍｗａｒｅオブジェクトの永続化処理について説明する。図１２は、ｆｉｒｍｗａｒｅオブジェクトの永続化ＤＢへの永続化処理を説明するためのシーケンス図である。
【００６９】
ステップＳ２０１においてソフト管理サービス１３ａは、引数にｆｉｒｍｗａｒｅオブジェクト（以下、「カレントオブジェクト」という。）を指定してＤＢ永続化オブジェクト１４１ｃの登録メソッドを呼び出すことにより、ＤＢ永続化オブジェクト１４１ｃに対してカレントオブジェクトの永続化を要求する。なお、図１１のクラス図からも明らかなように、ＤＢ永続化オブジェクト１４１ｃは、ソフト管理サービス１３ａからは、永続化ＡＰＩクラス１４１ａのインスタンスとして認識されている。
【００７０】
ステップＳ２０１に続いてステップＳ２０２に進み、ＤＢ永続化オブジェクト１４１ｃは、ＤＢ操作オブジェクト１４１ｆのトランザクション開始メソッドを呼び出すことにより、ＤＢ操作オブジェクト１４１ｆに対してトランザクションの開始を要求する。ステップＳ２０２に続いてステップＳ２０３に進み、ＤＢ操作オブジェクト１４１ｆは、永続化ＤＢ１６との接続を確立し、トランザクションを制御するためのトランザクションハンドルオブジェクト１４１ｈをＤＢ永続化オブジェクト１４１ｃに返却する（Ｓ２０４）。
【００７１】
ステップＳ２０４に続いてステップＳ２０５に進み、ＤＢ永続化オブジェクト１４１ｃは、引数にカレントオブジェクトを指定してＤＢ操作オブジェクト１４１ｆの登録メソッドを呼び出すことにより、ＤＢ操作オブジェクト１４１ｆに対してカレントオブジェクトのデータベースへの登録を要求する。ステップＳ２０５に続いてステップＳ２０６に進み、ＤＢ操作オブジェクト１４１ｆは、登録を要求されたカレントオブジェクトのｇｅｔＴｙｐｅメソッドを呼び出すことにより、カレントオブジェクトの型名（ｆｉｒｍｗａｒｅ）を取得する。
【００７２】
ステップＳ２０６に続いてステップＳ２０７に進み、ＤＢ操作オブジェクト１４１ｆは、カレントオブジェクトの型名に基づいて、カレントオブジェクトに対応する定義をオブジェクト定義ファイル１４５より取得する。ここでは、カレントオブジェクトはｆｉｒｍｗａｒｅオブジェクトであるため、ｏｂｊｅｃｔ要素１４５２（図５）が取得される。ステップＳ２０７に続いてステップＳ２０８に進み、ＤＢ操作オブジェクト１４１ｆは、ｏｂｊｅｃｔ要素１４５２の定義内容に基づいて、カレントオブジェクトの属性値を取得する。すなわち、ＤＢ操作オブジェクト１４１ｆは、ｏｂｊｅｃｔ要素１４５２に含まれている各ｆｉｅｌｄ要素に基づいて各属性の属性名を特定する。更に、ＤＢ操作オブジェクト１４１ｆは、各属性名を引数としてカレントオブジェクトのｇｅｔＦｉｅｌｄメソッドを呼び出すことにより各属性の属性値を取得する。
【００７３】
ステップＳ２０８に続いてステップＳ２０９に進み、ＤＢ操作オブジェクト１４１ｆは、ｏｂｊｅｃｔ要素１４５２に含まれている各ｆｉｅｌｄ要素のマッピング情報に基づいて、カレントオブジェクトの各属性について永続化ＤＢ１６における項目との対応関係を特定する。
【００７４】
図１３は、一つの属性についてのマッピング情報の例を示す図である。図１３には、ｄｏｗｎｌｏａｄＤａｔｅ属性に対応するｆｉｅｌｄ要素１４５２ｆが図５より抜き出されている。ｆｉｅｌｄ要素１４５２ｆにおいて、符号１４５２ｆ−１０で示されている部分がマッピング情報である。マッピング情報１４５２ｆ−１０は、一つ以上のｃａｐａｂｉｌｉｔｙ要素（＜ｃａｐａｂｉｌｉｔｙ＞タグで囲まれた要素）によって構成されている。
【００７５】
例えば、ｃａｐａｂｉｌｉｔｙ要素１４５２ｆ−１１は、ｎａｍｅ属性の値が「ｐｅｒｓｉｓｔｅｒ」であり、ｖａｌｕｅ属性の値が「ｄａｔａｂａｓｅ」であることから、ｄｏｗｎｌｏａｄＤａｔｅ属性の永続化先は、データベース（永続化ＤＢ１６）であることを示している。ｃａｐａｂｉｌｉｔｙ要素１４５２ｆ−１２は、ｎａｍｅ属性の値が「ｐｒｉｍａｒｙＫｅｙ」であり、ｖａｌｕｅ属性の値が「ｆａｌｓｅ」であることから、ｄｏｗｎｌｏａｄＤａｔｅ属性はプライマリキーではないことを示している。ｃａｐａｂｉｌｉｔｙ要素１４５２ｆ−１３は、ｎａｍｅ属性の値が「ｔａｂｌｅ」であり、ｖａｌｕｅ属性の値が「ｆｉｒｍｗａｒｅ」であることから、ｄｏｗｎｌｏａｄＤａｔｅ属性はデータベースにおけるｆｉｒｍｗａｒｅテーブルに登録されるものであることを示している。ｃａｐａｂｉｌｉｔｙ要素１４５２ｆ−１４は、ｎａｍｅ属性の値が「ｃｏｌｕｍｎ」であり、ｖａｌｕｅ属性の値が「ｄｏｗｏｎｌｏａｄｄａｔｅ」であることから、ｄｏｗｎｌｏａｄＤａｔｅ属性はｆｉｒｍｗａｒｅテーブルにおけるｄｏｗｎｌｏａｄｄａｔｅ項目に対応することを示している。ｃａｐａｂｉｌｉｔｙ要素１４５２ｆ−１５は、ｎａｍｅ属性の値が「ｃｏｌｕｍｎＴｙｐｅ」であり、ｖａｌｕｅ属性の値が「ｎｖａｒｃｈａｒ」であることから、ｄｏｗｎｌｏａｄＤａｔｅ属性が対応するｆｉｒｍｗａｒｅテーブルにおけるｄｏｗｎｌｏａｄｄａｔｅ項目のデータ型はｎｖａｒｃｈａｒ型であることを示している。
【００７６】
したがって、ＤＢ操作オブジェクト１４１ｆは、各属性についての永続化ＤＢ１６における項目との対応関係をそれぞれの属性に対するマッピング情報に基づいて特定する。なお、マッピング情報は、オブジェクト定義ファイル１４５と別のファイルにおいて管理してもよい。この場合、オブジェクト定義ファイル１４５内には、マッピング情報そのものの代わりに当該別のファイルに対するリンク情報（例えば、当該別のファイルのファイル名）を記述しておけばよい。
【００７７】
ステップＳ２０９に続いてステップＳ２１０に進み、ＤＢ操作オブジェクト１４１ｆは、ＳＱＬのＩＮＳＥＲＴ文によって永続化ＤＢ１６のテーブル（ｆｉｒｍｗａｒｅテーブル）にカレントオブジェクトに対応するレコードを追加する。この際、ＤＢ操作オブジェクト１４１ｆは、ステップＳ２０９において特定した対応関係に基づいて、ステップＳ２０８において取得した属性値を永続化ＤＢ１６における各項目にマッピングさせ、当該レコードにおける各項目の値を設定する。
【００７８】
上記によって、カレントオブジェクトは、永続化ＤＢ１６上の一つのレコードに変換されたことになる。
【００７９】
ステップＳ２１０に続いてステップＳ２１１に進み、ＤＢ操作オブジェクト１４１ｆが、永続化ＤＢ１６に対してｆｉｒｍｗａｒｅテーブル内にけるＩＤ項目の最大値（以下、「最大ＩＤ値」という。）の検索を要求すると、永続化ＤＢ１６より最大ＩＤ値が返却される（Ｓ２１２）。ステップＳ２１２に続いてステップＳ２１３に進み、ＤＢ操作１４１ｆが、永続化ＤＢ１６に対して、ＩＤ項目の値が最大ＩＤ値であるレコードを検索する。本実施の形態においては、ＩＤ項目の値は、昇順に設定されるものとする。したがって、ここで検索されるレコードは、ステップＳ２１０において登録されたレコード（以下、「カレントレコード」という。）ということになる。
【００８０】
ステップＳ２１４に続いてステップＳ２１５に進み、ＤＢ操作オブジェクト１４１ｆは、カレントレコードを管理オブジェクト（ｆｉｒｍｗａｒｅオブジェクト）に変換する。
【００８１】
図１４は、ＤＢレコードから管理オブジェクトへの変換処理を説明するためのシーケンス図である。まず、ＤＢ操作オブジェクト１４１ｆは、オブジェクト定義ファイル１４５の定義内容に基づいて、カレントレコードの一の項目（カレント項目）に対応する、カレントオブジェクトにおける属性（カレント属性）を特定し（Ｓ２１５ａ）、カレント属性の属性名とカレント項目の値とを引数としてカレントオブジェクトのｓｅｔＦｉｅｌｄメソッドを呼び出す（Ｓ２１５ｂ）。カレントオブジェクトは、ｓｅｔＦｉｅｌｄメソッドの引数に指定された属性名をキーとしてカレント項目の値をマップ型のメンバ変数ｐｒｏｐｅｒｔｉｅｓに設定（ｐｕｔ）する（Ｓ２１５ｃ）。ステップＳ２１５ａ〜Ｓ２１５ｃまでの処理がカレントレコードの全ての項目について行われることにより、カレントレコードの全ての項目の値がカレントオブジェクトの属性の属性値として設定されカレントレコードがオブジェクトに変換されたことになる。
【００８２】
なお、登録要求に係る処理であるにもかかわらず、登録したレコードを検索し、検索結果を改めてカレントオブジェクト、すなわち、永続化が要求されたオブジェクトに設定するのは、永続化ＤＢ１６に対する項目の値の設定が正常に行われなかった場合等を考慮して、永続化ＤＢ１６の内容とカレントオブジェクトの内容とを正確に同期させるためである。
【００８３】
ステップＳ２１５に続いてステップＳ２１６に進み（図１２）、カレントオブジェクトがＤＢ永続化オブジェクト１４１ｃに返却される。以降、カレントオブジェクトの子オブジェクトや孫オブジェクト等についても再帰的にステップＳ２０４からステップＳ２１６までの処理が実行され、子オブジェクト等についても永続化ＤＢ１６内のそれぞれのテーブルのレコードとして永続化される（Ｓ２１７）。
【００８４】
全ての子オブジェクト等についての永続化が完了すると、ステップＳ２１８に進み、ＤＢ永続化オブジェクト１４１ｃが、ＤＢ操作オブジェクト１４１ｆに対してコミットを要求すると、ＤＢ操作１４１ｆにより永続化ＤＢ１６に対してコミットが要求される（Ｓ２１９）。処理の制御が復帰すると（Ｓ２２０）、ＤＢ永続化オブジェクト１４１ｃは、カレントオブジェクトをソフト管理サービス１３ａに対して返却する（Ｓ２２１）。
【００８５】
上述したように、本実施の形態におけるデータ管理装置１０によれば、管理オブジェクトの内容（属性等）をその永続化先に登録する際に、オブジェクト定義ファイル１４５に定義されたマッピング情報に基づいてオブジェクトの内容と永続化先との対応関係を動的に（処理の実行時に）判断することができる。また、全ての型の管理オブジェクトは、一つの実装クラス（雛型クラス）によって実現されており、上位モジュールは、全ての型について同一のインタフェースによって取り扱うことができる。したがって、永続化先のスキーマ等に変更があった場合でも、オブジェクト定義ファイル１４５の定義内容さえ修正すればよく、管理オブジェクトを永続化先に対応した形式に変換するための処理に係るソースコードや、管理オブジェクトのクラス定義を修正する必要はない。よって、永続化先のスキーマの変更等に対して効率的に対応することができる。
【００８６】
次に、永続化先が永続化ファイル１７である場合の例について説明する。図１５は、ｆｉｒｍｗａｒｅオブジェクトの永続化ファイルへの永続化処理を説明するためのシーケンス図である。図１５における処理は、図１２における処理と共通する部分があるため、当該部分については適宜簡略化して説明する。なお、図１５においては、図１２におけるＤＢ永続化オブジェクト１４１ｃ、ＤＢ操作オブジェクト１４１ｆの役割は、それぞれＸＭＬ永続化オブジェクト１４１ｂ、ＸＭＬ操作オブジェクト１４１ｅが担っている点に注意を要する。
【００８７】
ソフト管理サービス１３ａが、ｆｉｒｍｗａｒｅオブジェクトの永続化をＸＭＬ永続化オブジェクト１４１ｂに対して要求すると（Ｓ３０１）、ＸＭＬ永続化オブジェクト１４１ｂは、ＸＭＬ操作オブジェクト１４１ｅに対してトランザクションの開始を要求する（Ｓ３０２）。ＸＭＬ操作オブジェクト１４１ｅは、トランザクションを制御するためのトランザクションハンドルオブジェクト１４１ｈをＸＭＬ永続化オブジェクト１４１ｂに返却する（Ｓ３０３）。
【００８８】
ステップＳ３０３に続いてステップＳ３０４に進み、ＸＭＬ永続化オブジェクト１４１ｂは、ＸＭＬ操作オブジェクト１４１ｅに対してｆｉｒｍｗａｒｅオブジェクトの永続化ファイル１７への登録を要求する。ステップＳ３０４に続いてステップＳ３０５に進み、ＸＭＬ操作オブジェクト１４１ｅは、登録を要求されたｆｉｒｍｗａｒｅオブジェクト（以下、「カレントオブジェクト」という。）のｇｅｔＴｙｐｅメソッドを呼び出すことにより、カレントオブジェクトの型名（ｆｉｒｍｗａｒｅ）を取得する。
【００８９】
ステップＳ３０５に続いてステップＳ３０６に進み、ＸＭＬ操作オブジェクト１４１ｅは、カレントオブジェクトの型名に基づいて、カレントオブジェクトに対応する定義（ｏｂｊｅｃｔ要素１４５２（図５））をオブジェクト定義ファイル１４５より取得する。ステップＳ３０６に続いてステップＳ３０７に進み、ＸＭＬ操作オブジェクト１４１ｅは、カレントオブジェクトに対するＩＤを採番する。永続化先が永続化ＤＢ１６である場合は、データベースによってＩＤが採番されるが、永続化先が永続化ファイル１７である場合はＩＤを採番するような仕組みは無いため、ＸＭＬ操作オブジェクト１４１ｅが採番するというわけである。採番されたＩＤは、カレントオブジェクトにｓｅｔＦｉｅｌｄメソッドを介して設定される。
【００９０】
ステップＳ３０７に続いてステップＳ３０８に進み、ＸＭＬ操作オブジェクト１４１ｅは、カレントオブジェクト一つに対応する要素ノード（以下、「オブジェクトノード」という。）の生成をＤＯＭ１７１に対して要求する。オブジェクトノードの要素名は、例えば、「ｏｂｊｅｃｔ」等、オブジェクトに対応する要素ノードであることが容易に識別できるものにすると取り扱いに便宜である。ステップＳ３０８に続いてステップＳ３０９に進み、ＸＭＬ操作オブジェクト１４１ｅは、ｏｂｊｅｃｔ要素１４５２におけるｆｉｅｌｄ要素に基づいて一の属性（カレント属性）の属性名を特定し、当該属性名を引数としてカレントオブジェクトのｇｅｔＦｉｅｌｄメソッドを呼び出すことによりカレント属性の属性値を取得する。
【００９１】
ステップＳ３０９に続いてステップＳ３１０に進み、ＸＭＬ操作オブジェクト１４１ｅは、カレント属性の属性名及び属性値等の情報を含む要素ノード（以下、「属性ノード」という。）をオブジェクトノードの子ノードとして生成するようＤＯＭ１７１に対して要求する。属性ノードの要素名は、例えば、「ｆｉｅｌｄ」等、属性に対応する要素ノードであることが容易に識別できるものにすると取り扱いに便宜である。なお、カレント属性の属性値は、カレント属性に対するｆｉｅｌｄ属性のマッピング情報に基づいてデータ型の変換が行われる。
【００９２】
図１６は、永続化先が永続化ファイルである場合のマッピング情報の例を示す図である。図１６には、図１３に対応させて、ｄｏｗｎｌｏａｄＤａｔｅ属性に対応するｆｉｅｌｄ要素１４５２ｆが図５より抜き出されている。ｆｉｅｌｄ要素１４５２ｆにおいて、符号１４５２ｆ−２０で示されている部分がマッピング情報である。ｃａｐａｂｉｌｉｔｙ要素１４５２ｆ−２１は、ｎａｍｅ属性の値が「ｐｅｒｓｉｓｔｅｒ」であり、ｖａｌｕｅ属性の値が「ｘｍｌ」であることから、ｄｏｗｎｌｏａｄＤａｔｅ属性の永続化先は、ＸＭＬ形式のファイル（永続化ファイル１７）であることを示している。また、ｃａｐａｂｉｌｉｔｙ要素１４５２ｆ−２２は、ｎａｍｅ属性の値が「ｃｏｎｖｅｒｔｅｒ」であり、ｖａｌｕｅ属性の値が「ＸＭＬＤａｔｅＴｉｍｅ」であることから、ｄｏｗｎｌｏａｄＤａｔｅ属性の永続化先におけるデータ型がＸＭＬＤａｔｅＴｉｍｅ型であることを示している。したがって、ＸＭＬ操作オブジェクト１４１ｅは、ｃａｐａｂｉｌｉｔｙ要素１４５２ｆ−２２に基づいて、カレント属性の属性値のデータ型を変換する。
【００９３】
カレントオブジェクトの全ての属性についてステップＳ３０９及びＳ３１０の処理、すなわち、ＤＯＭ１７１に対する属性ノードの生成処理が繰り返された後（Ｓ３１１）、ステップＳ３１２に進み、ＸＭＬ操作オブジェクト１４１ｅは、カレントオブジェクトをＸＭＬ永続化オブジェクト１４１ｂに対して返却する。以降、カレントオブジェクトの子オブジェクトや孫オブジェクト等についても再帰的にステップＳ３０４からステップＳ３１２までの処理が実行され、子オブジェクト等についてもＤＯＭ１７１に対してオブジェクト要素ノードの生成が行われる（Ｓ３１３）。
【００９４】
全ての子オブジェクト等についてのオブジェクト要素ノードの生成が完了すると、ステップＳ３１４に進み、ＸＭＬ永続化オブジェクト１４１ｂは、ＸＭＬ操作オブジェクト１４１ｅに対してトランザクションの終了を要求する。ＸＭＬ操作オブジェクト１４１ｅが、ＤＯＭ１７１に対して永続化ファイル１７の生成を要求すると、当該要求に基づいて、ＤＯＭ１７１は設定された情報を永続化ファイル１７に出力する（Ｓ３１５）。処理の制御が復帰すると（Ｓ３１６）、ＸＭＬ永続化オブジェクト１４１ｂは、カレントオブジェクトをソフト管理サービス１３ａに対して返却する（Ｓ３１７）。
【００９５】
このように、永続化先が永続化ファイル１７である場合も、永続化先が永続化ＤＢ１６である場合と同様に、オブジェクト定義ファイル１４５に基づいて管理オブジェクトを永続化先に対応した形式に動的に変換することができる。なお、永続化先がメモリである場合であっても、同様の処理によって管理オブジェクトをメモリに永続化することができる。
【００９６】
なお、上記においては、管理オブジェクトを永続化ＤＢ１６又は永続化ファイル１７に永続化する場合の例について説明したが、管理オブジェクトの属性値の設定先を機器３０としてもよい。すなわち、管理オブジェクト（例えば、ｄｅｖｉｃｅ型のオブジェクト）の属性を機器３０のパラメータに対応させることで、上位アプリケーション（Ｗｅｂサービス１３）から見た場合、データベースやファイル等に管理オブジェクトの属性値を設定する場合と同様に、管理オブジェクトの属性値を機器３０のパラメータに反映させることができる。管理オブジェクトの属性と機器３０のパラメータとの対応付けは、上記同様オブジェクト定義ファイル１４５において行えばよい。対応付けをオブジェクト定義ファイル１４５によって行うことで、管理対象とする機器３０の機種が変わったことにより、管理対象とする機器３０のパラメータに変化があった場合でも、オブジェクト定義ファイル１４５において変化のあったパラメータに対するｆｉｅｌｄ要素の追加、削除又は変更のみおこなえばよく、ソースコードの修正、コンパイル及びリンク等については必要ない。
【００９７】
管理オブジェクトの属性値を機器３０のパラメータに設定する場合、機器３０との通信が発生するため、上記において永続化ＡＰＩモジュール１４１が行っていた処理は、接続ＡＰＩモジュール１４２が担当することになる。図１７は、接続ＡＰＩモジュールのクラス図の例である。図１７に示されるように、接続先ＡＰＩモジュール１４２は、主に、接続ＡＰＩクラス１４２ａ、機器接続クラス１４２ｂ、接続操作クラス１４２ｃ、及び接続ハンドルクラス１４２ｄ等から構成されている。
【００９８】
接続ＡＰＩクラス１４２ａは、各種の接続対象（例えば、機器３０等）にアクセスするためのインタフェースのみが定義された、いわゆる抽象クラスである。機器接続クラス１４２ｂは、接続ＡＰＩクラス１４２ａのサブクラスであり、接続ＡＰＩクラス１４２ａにおいて定義されたインタフェースについて、それぞれが対応する特定の接続対象に応じた実装がなされている、いわゆる具象クラスである。機器接続クラス１４２ｂは、機器３０に対応したクラスである。図１７においては、具象クラスとして機器接続クラス１４２ｂのみが表示されているが、接続対象のバリエーションに応じて、それぞれの接続対象に対応した具象クラスを定義すればよい。機器接続クラス１４２ｂ等の具象クラスが、一つの接続ＡＰＩクラス１４２ａによって抽象化されていることによって、Ｗｅｂサービス１３のソースコードにおいては、接続ＡＰＩクラス１４２ａのみを意識した実装を行うことができ、新たな接続対象が追加された場合、すなわち、当該新たな接続対象に対する具象クラスが接続ＡＰＩクラス１４２ａのサブクラスとして追加された場合であっても、Ｗｅｂサービス１３のソースコードは修正する必要はない。
【００９９】
機器接続クラス１４２ｂは、それぞれ、接続操作クラス１４２ｃを集約している。接続操作クラスは、各具象クラスが対応する接続対象とのプロトコルを隠蔽したインタフェースを各具象クラスに提供するクラスである。接続ハンドルクラス１４２ｄは、接続対象とのセッション情報を管理するためのクラスである。
【０１００】
なお、図１７を図１１と対比させると、接続ＡＰＩクラス１４２ａは、永続化ＡＰＩクラス１４１ａに、機器接続クラス１４２ｂは、ＸＭＬ永続化クラス１４１ｂ、ＤＢ永続化クラス１４１ｃ又はメモリ永続化クラス１４１ｄに、接続操作クラス１４２ｃは、ＸＭＬ操作クラス１４１ｅ、ＤＢ操作クラス１４１ｆ又はメモリ操作クラス１４１ｇに、接続ハンドルクラス１４２ｄは、トランザクションハンドルクラス１４１ｈにその役割が対応している。したがって、機器３０に対するパラメータの設定処理、すなわち、ｄｅｖｉｃｅオブジェクトの機器パラメータへの変換処理は、図１２において説明したものと同様の処理手順によって実現することができる。
【０１０１】
ところで、近年においては、ある特定の機能に特化した組み込み機器についても一般的なコンピュータと同等の情報処理を実行することができるものが提供されている。例えば、融合機、又は複合機と呼ばれる、プリンタ、コピー、又はファクシミリ等の複合サービスに固有の処理を行う複数のアプリケーションを有する画像形成装置もかかる機器に該当する。したがって、汎用的なコンピュータだけでなく、かかる機器に対して図３に示される機能を実装することにより、本実施の形態におけるデータ管理装置１０の役割を当該機器に担わせてもよい。この場合、ｈｔｔｐｄ１１は、必ずしもＨＴＴＰによって通信するモジュールである必要はなく、当該機器がサポートしているプロトコルによってクライアントからの要求を受け付けるデーモンプログラムであればよい。また、Ｗｅｂアプリケーション１２についても、Ｗｅｂアプリケーションである必要はなく、クライアントからの要求に応じて呼び出されるアプリケーションであればよい。
【０１０２】
以上、本発明の好ましい実施例について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【図面の簡単な説明】
【０１０３】
【図１】本発明の実施の形態における機器管理システムの構成例を示す図である。
【図２】本発明の実施の形態におけるデータ管理装置のハードウェア構成例を示す図である。
【図３】本発明の実施の形態におけるデータ管理装置の機能構成例を示す図である。
【図４】共通モジュールの機能構成例を示す図である。
【図５】オブジェクト定義ファイルの定義例を示す図である。
【図６】一つの関連についての詳細情報の例を示す図である。
【図７】オブジェクト定義ファイルの定義内容を示すクラス図である。
【図８】雛型クラスのクラス仕様を示す図である。
【図９】雛型クラスにおける属性情報の管理イメージを示す図である。
【図１０】管理オブジェクトの生成処理を説明するためのフローチャートである。
【図１１】永続化ＡＰＩモジュールのクラス図の例である。
【図１２】ｆｉｒｍｗａｒｅオブジェクトの永続化ＤＢへの永続化処理を説明するためのシーケンス図である。
【図１３】一つの属性についてのマッピング情報の例を示す図である。
【図１４】ＤＢレコードから管理オブジェクトへの変換処理を説明するためのシーケンス図である。
【図１５】ｆｉｒｍｗａｒｅオブジェクトの永続化ファイルへの永続化処理を説明するためのシーケンス図である。
【図１６】永続化先が永続化ファイルである場合のマッピング情報の例を示す図である。
【図１７】接続ＡＰＩモジュールのクラス図の例である。
【符号の説明】
【０１０４】
１            機器管理システム
１０          データ管理装置
１１          ｈｔｔｐｄ
１２          Ｗｅｂアプリケーション
１３、１３ｃ、１３ｄ      Ｗｅｂサービス
１３ａ        ソフト管理サービス
１３ｂ        機器管理サービス
１４          共通モジュール
１５          ネットワークレイヤ
１６          永続化ＤＢ
１７          永続化ファイル
２０          ファイルサーバ
３０          機器
４０          端末
５０          ネットワーク
１００        ドライブ装置
１０１        記録媒体
１０２        補助記憶装置
１０３        メモリ装置
１０４        演算処理装置
１０５        インタフェース装置
１２３        雛型クラス
１４１        永続化ＡＰＩモジュール
１４１ａ      永続化ＡＰＩクラス（オブジェクト）
１４１ｂ      ＸＭＬ永続化クラス（オブジェクト）
１４１ｃ      ＤＢ永続化クラス（オブジェクト）
１４１ｄ      メモリ永続化クラス
１４１ｅ      ＸＭＬ操作クラス（オブジェクト）
１４１ｆ      ＤＢ操作クラス（オブジェクト）
１４１ｇ      メモリ操作クラス
１４１ｈ      トランザクションハンドル
１４２        接続ＡＰＩモジュール
１４２ａ      接続ＡＰＩ
１４２ｂ      機器接続
１４２ｃ      接続操作
１４２ｄ      接続ハンドル
１４３        オブジェクト生成モジュール
１４４        雛型クラスモジュール
１４５        オブジェクト定義ファイル
Ｂ            バス
【図１】
2005301985.tif 000003
【図２】
2005301985.tif 000004
【図３】
2005301985.tif 000005
【図４】
2005301985.tif 000006
【図５】
2005301985.tif 000007
【図６】
2005301985.tif 000008
【図７】
2005301985.tif 000009
【図８】
2005301985.tif 000010
【図９】
2005301985.tif 000011
【図１０】
2005301985.tif 000012
【図１１】
2005301985.tif 000013
【図１２】
2005301985.tif 000014
【図１３】
2005301985.tif 000015
【図１４】
2005301985.tif 000016
【図１５】
2005301985.tif 000017
【図１６】
2005301985.tif 000018
【図１７】
2005301985.tif 000019