(57)【要約】【課題】サービスモジュールの変更に伴う、クライアントモジュールを含むアプリケーションの更新作業を簡素化する。【解決手段】コントローラ20は、管理サーバ10に対し、クライアントモジュール24とその連携対象となるサービスモジュール28とを仲介するアダプタ26の生成を要求する。要求の際には、クライアントAPI定義22b及びこの定義22bに対応する意味情報として、上記サービスモジュール28を特定する機器ID22aを管理サーバ10へ送信する。管理サーバ10は、サービスモジュール28のAPIの仕様を定義するサービスAPI定義13cとこれに対応する機器ID13aとを持ち、コントローラ20から受信した機器ID22aに基づいてサービスAPI定義13cを選択し、選択したサービスAPI定義13cと受信したクライアントAPI定義22bとに基づいてアダプタ26を生成し、クライアント20へ送信する。【選択図】図１
2009238040.tif 000002
【特許請求の範囲】
【請求項１】
他のモジュールに対して自身の機能を提供するサービスモジュールと、該サービスモジュールの機能を利用するクライアントモジュールの仲介を支援するモジュール間連携支援方法であって、
サービスモジュールのAPIの仕様を定義するサービスAPI定義情報と、該サービスモジュールの意味情報とを対応づけて記憶するサービスAPI定義ステップと、
クライアントモジュールのAPIの仕様を定義するクライアントAPI定義情報と、該クライアントモジュールの意味情報とを対応づけて記憶するクライアントAPI定義ステップと、
クライアントモジュールを選択するステップと、
前記選択したクライアントモジュールに対応するクライアントモジュール意味情報を取得し、前記取得したクライアントモジュール意味情報に整合するサービスモジュール意味情報を決定し、前記決定したサービスモジュール意味情報に対応するサービスモジュールを、前記選択したクライアントモジュールの連携対象として選択するステップと、
前記選択したクライアントモジュールのクライアントAPI定義情報と、前記選択したサービスモジュールのサービスAPI定義情報とに基づいて、前記選択したクライアントモジュールと前記選択したサービスモジュールとを仲介するアダプタを生成するステップとを含むモジュール間連携支援方法。
【請求項２】
前記サービスAPI定義ステップは、サービスAPI定義情報として、サービスモジュールのAPIで用いられるサービスAPI関数と、該サービスAPI関数の意味情報とを対応づけて記憶するステップを含み、
前記クライアントAPI定義ステップは、クライアントAPI定義情報として、クライアントモジュールのAPIで用いられるクライアントAPI関数と、該クライアントAPI関数の意味情報とを対応づけて記憶するステップを含み、
前記アダプタを生成するステップは、
クライアント又はサービスの一方を「第１」と呼び、他方を「第２」と呼ぶものとした場合、
前記選択した第１モジュールのAPIで用いられる第１API関数を選択するステップと、
前記選択した第１API関数に対応する第１API関数意味情報を取得し、前記取得した第１API関数意味情報に整合する第２API関数意味情報を決定し、前記決定した第２API関数意味情報に対応する、前記選択した第２モジュールで用いられる第２API関数を、前記選択した第１API関数の連携対象として選択するステップと、
前記選択した第１API関数と、前記選択した第２API関数とに基づいて、前記選択した第１API関数と前記選択した第２API関数とを仲介するアダプタの部分を生成するステップとを含む、請求項１に記載のモジュール間連携支援方法。
【請求項３】
前記サービスAPI定義ステップは、サービスAPI定義情報として、サービスモジュールのAPIで用いられるサービスAPI関数のパラメタと、該パラメタの意味情報とを対応づけて記憶するステップを含み、
前記クライアントAPI定義ステップは、クライアントAPI定義情報として、クライアントモジュールのAPIで用いられるクライアントAPI関数のパラメタと、該パラメタの意味情報とを対応づけて記憶するステップを含み、
前記アダプタの部分を生成するステップは、
前記選択した第１API関数のパラメタを選択するステップと、
前記選択した第１API関数パラメタに対応する第１API関数パラメタ意味情報を取得し、前記取得した第１API関数パラメタ意味情報に整合する第２API関数パラメタ意味情報を決定し、前記決定した第２API関数パラメタ意味情報に対応する、前記選択した第２API関数のパラメタを、前記選択した第１API関数パラメタの連携対象として選択するステップと、
前記選択した第１API関数パラメタと、前記選択した第２API関数パラメタとを対応づけて、前記選択した第１API関数と前記選択した第２API関数とを仲介するアダプタの部分を生成するステップとを含む、請求項２に記載のモジュール間連携支援方法。
【請求項４】
前記クライアントAPI定義ステップは、クライアントAPI定義情報として、固定値と、該固定値の意味情報とを対応づけて記憶するステップを含み、
前記アダプタの部分を生成するステップは、
前記選択した第１API関数がサービスAPI関数である場合に、該関数のサービスAPI関数パラメタのうち、意味情報が固定値意味情報であるパラメタを特定するステップと、
前記固定値のうち、前記特定したサービスAPI関数パラメタの固定値意味情報に整合する意味情報に対応する固定値を、前記特定したサービスAPI関数パラメタの連携対象として選択するステップと、
前記選択したクライアントAPI関数パラメタと、前記選択したサービスAPI関数パラメタとを対応づけて、かつ、前記特定したサービスAPI関数パラメタに前記選択した固定値を代入して、前記選択したクライアントAPI関数と前記選択したサービスAPI関数とを仲介するアダプタの部分を生成するステップとを含む、請求項３に記載のモジュール間連携支援方法。
【請求項５】
さらに、前記選択したクライアントモジュールに前記生成したアダプタをリンクさせるステップを含む、請求項１乃至４のいずれか１項に記載のモジュール間連携支援方法。
【請求項６】
前記サービスモジュールは、外部ユニットを利用してデータ取得を行うモジュールであり、前記外部ユニットは、センサ等の電子機器、又はネットワーク上にある計算機内で動作するプログラムユニットを含む、請求項１乃至５のいずれか１項に記載のモジュール間連携支援方法。
【請求項７】
前記アダプタを生成するステップでは、アダプタの実行時に前記外部ユニットへアクセスするための情報を取得するように該アダプタを生成する請求項６に記載のモジュール間連携支援方法。
【請求項８】
請求項１乃至７のいずれか１項に記載の方法を計算機に実行させるためのモジュール間連携支援プログラム。
【請求項９】
他のモジュールに対して自身の機能を提供するサービスモジュールと、該サービスモジュールの機能を利用するクライアントモジュールの仲介を支援するモジュール間連携支援システムであって、
サービスモジュールのAPIの仕様を定義するサービスAPI定義情報と、該サービスモジュールの意味情報とを対応づけて記憶するサービスAPI定義格納部と、
クライアントモジュールのAPIの仕様を定義するクライアントAPI定義情報と、該クライアントモジュールの意味情報とを対応づけて記憶するクライアントAPI定義格納部と、
クライアントモジュールを選択するアダプタ生成要求部と、
前記選択したクライアントモジュールに対応するクライアントモジュール意味情報を取得し、前記取得したクライアントモジュール意味情報に整合するサービスモジュール意味情報を決定し、前記決定したサービスモジュール意味情報に対応するサービスモジュールを、前記選択したクライアントモジュールの連携対象として選択する連携対象選択部と、
前記選択したクライアントモジュールのクライアントAPI定義情報と、前記選択したサービスモジュールのサービスAPI定義情報とに基づいて、前記選択したクライアントモジュールと前記選択したサービスモジュールとを仲介するアダプタを生成するアダプタ生成部とを含むモジュール間連携支援システム。
【請求項１０】
前記サービスAPI定義格納部は、サービスAPI定義情報として、サービスモジュールのAPIで用いられるサービスAPI関数と、該サービスAPI関数の意味情報とを対応づけて記憶し、
前記クライアントAPI定義格納部は、クライアントAPI定義情報として、クライアントモジュールのAPIで用いられるクライアントAPI関数と、該クライアントAPI関数の意味情報とを対応づけて記憶し、
前記アダプタ生成部は、
クライアント又はサービスの一方を「第１」と呼び、他方を「第２」と呼ぶものとした場合、
前記選択した第１モジュールのAPIで用いられる第１API関数を選択し、前記選択した第１API関数に対応する第１API関数意味情報を取得し、前記取得した第１API関数意味情報に整合する第２API関数意味情報を決定し、前記決定した第２API関数意味情報に対応する、前記選択した第２モジュールで用いられる第２API関数を、前記選択した第１API関数の連携対象として選択し、前記選択した第１API関数と、前記選択した第２API関数とに基づいて、前記選択した第１API関数と前記選択した第２API関数とを仲介するアダプタの部分を生成する、請求項９に記載のモジュール間連携支援システム。
【請求項１１】
前記サービスAPI定義格納部は、サービスAPI定義情報として、サービスモジュールのAPIで用いられるサービスAPI関数のパラメタと、該パラメタの意味情報とを対応づけて記憶し、
前記クライアントAPI定義格納部は、クライアントAPI定義情報として、クライアントモジュールのAPIで用いられるクライアントAPI関数のパラメタと、該パラメタの意味情報とを対応づけて記憶し、
前記アダプタ生成部は、
前記選択した第１API関数のパラメタを選択し
前記選択した第１API関数パラメタに対応する第１API関数パラメタ意味情報を取得し、前記取得した第１API関数パラメタ意味情報に整合する第２API関数パラメタ意味情報を決定し、前記決定した第２API関数パラメタ意味情報に対応する、前記選択した第２API関数のパラメタを、前記選択した第１API関数パラメタの連携対象として選択し、
前記選択した第１API関数パラメタと、前記選択した第２API関数パラメタとを対応づけて、前記選択した第１API関数と前記選択した第２API関数とを仲介するアダプタの部分を生成する、請求項１０に記載のモジュール間連携支援システム。
【請求項１２】
前記クライアントAPI定義格納部は、クライアントAPI定義情報として、固定値と、該固定値の意味情報とを対応づけて記憶し、
前記アダプタ生成部は、
前記選択した第１API関数がサービスAPI関数である場合に、該関数のサービスAPI関数パラメタのうち、意味情報が固定値意味情報であるパラメタを特定し、
前記固定値のうち、前記特定したサービスAPI関数パラメタの固定値意味情報に整合する意味情報に対応する固定値を、前記特定したサービスAPI関数パラメタの連携対象として選択し、
前記選択したクライアントAPI関数パラメタと、前記選択したサービスAPI関数パラメタとを対応づけて、かつ、前記特定したサービスAPI関数パラメタに前記選択した固定値を代入して、前記選択したクライアントAPI関数と前記選択したサービスAPI関数とを仲介するアダプタの部分を生成する、請求項１１に記載のモジュール間連携支援システム。
【請求項１３】
前記アダプタ生成要求部は、前記選択したクライアントモジュールに前記生成したアダプタをリンクさせる請求項９乃至１２のいずれか１項に記載のモジュール間連携支援システム。
【請求項１４】
前記サービスモジュールは、外部ユニットを利用してデータ取得を行うモジュールであり、前記外部ユニットは、センサ等の電子機器、又はネットワーク上にある計算機内で動作するプログラムユニットを含む、請求項９乃至１３のいずれか１項に記載のモジュール間連携支援システム。
【請求項１５】
前記アダプタ生成部は、アダプタの実行時に前記外部ユニットへアクセスするための情報を取得するように該アダプタを生成する請求項１４に記載のモジュール間連携支援システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、計算機ソフトウェアにおけるモジュール間連携の柔軟性を向上する技術に関するものであって、特にインターフェイスの変換を自動化する技術に関する。
【背景技術】
【０００２】
ソフトウェアシステムの開発では、独立性を高めたソフトウェア部品群をモジュールとして開発し、開発したモジュール同士を連携させることで全体システムを構築する開発手法が主流である。一般的には、他のモジュールから利用されるモジュール（サービスモジュール）が自身の機能を利用させるためのインターフェイスを公開し、そのモジュールを利用するモジュール（クライアントモジュール）はサービスモジュールのインターフェイスを使用することで、モジュール間連携を実現する。各モジュールの開発前にサービスモジュールのインターフェイスを決定しておくことで、各モジュールの開発作業を独立して進めることができる。
【０００３】
サービスモジュールの機能が多岐にわたる場合には、サービスモジュールのインターフェイスを、複数の機能を包含する汎用インターフェイスとすることで対応する。また、クライアントモジュールが想定するサービスモジュールのインターフェイスと、実際にサービスモジュールが提供するインターフェイスが合致しない場合は、両者を仲介するアダプタを作成する手法が知られている。アダプタは、クライアントモジュールに対してはサービスモジュールとして動作し、サービスモジュールに対してはクライアントモジュールとして動作する。
【０００４】
一方、特許文献1では、実行環境が異なる複数のクライアントが同一のRMI（Remote Method Invocation）サービスを利用する場合に、サーバ側でクライアント毎のスタブを用意しておき、クライアントがアプリケーションの実行時に各クライアントの実行環境に適したスタブをサーバからクライントにダウンロードする技術が開示されている。これによってクライアント毎に異なるスタブをインストールする作業の手間を削減することができる。
【０００５】
また、特許文献２には、サーバ上に、クライアント装置で実行するドライバのコアモジュールとサブモジュールを用意しておき、サーバがクライアント装置からドライバのパッケージファイルのダウンロード要求を受信すると、そのクライアント装置に応じてサブモジュールを選択し、ドライバコアモジュール及び選択したサブモジュールから、ドライバのパッケージファイルを生成し、そのファイルをクライアント装置へ送信する技術が開示されている。上記コアモジュールはクライアント装置の環境に依存しないモジュールであり、サブモジュールはクライアント装置の環境に依存するモジュールである。これにより、クライアント装置ごとの環境が異なっていても、各クライアント装置に適合したドライバを供給することができる。
【０００６】
さらに、特許文献３には、サーバ上にクライアントで実行するモジュール群を用意しておき、クライアントからのダウンロード要求に付加されているプラットフォームの種別に従ってリンク情報テーブルを参照し、アプリケーションの実行オブジェクトを生成し、生成した実行オブジェクトをクライアントへ送信する技術が開示されている。これにより、クライアントのプラットホームごとにカスタマイズした実行オブジェクトを配布することが可能となる。  上記特許文献1におけるRMIサービスのインターフェイス、上記特許文献2におけるコアモジュールとサブモジュール間のインターフェイス、及び上記特許文献3におけるモジュール間のインターフェイスは、あらかじめ決められたものである。従って、これらの特許文献に開示された技術は、従来と同様の計算機ソフトウェア開発手法を採用しているといえる。
【特許文献１】特開２００２−１３２７３９号公報
【特許文献２】特開２００６−２４４００９号公報
【特許文献３】特開２００２−０１４８２１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
上記ソフトウェア開発手法では、サービスモジュールのインターフェイスを更新する度に、サービスモジュールを利用するクライアントモジュールやアダプタを更新する必要がある。サービスモジュールのインターフェイスを、機能拡張を踏まえて設計しておく、という対策が考えられるが、当初想定していない機能を追加する場合には、対応できない。
【０００８】
例えば、センサを活用したシステムを開発する場合、センサ制御を行うモジュール（センサ制御モジュール）をアプリケーションから利用する構成になるが、センサ制御モジュールは業界でインターフェイスの統一化がなされていないため、新しいセンサを導入するたびに、アプリケーションの更新が必要になる。特に、システムの開発段階においては、センサ等の機器の選定が試行錯誤されるため、利用する機器の変更が頻繁に発生する。このように機器が変更されると、変更後の機器にアクセスするためのインターフェイスが従前のものと変わるため、クライアントモジュールやアダプタの修正が必要になる。
【０００９】
また、複数のセンサ制御モジュールのインターフェイスを共通化するアダプタを作成したとしても、当初想定していない機能を備えたセンサに対応するときには、アダプタが提供するインターフェイスを変更する必要があり、これに伴いアプリケーションの更新が必要になる。
【００１０】
このように、サービスモジュールのインターフェイスが変更された場合、従来は、サービスモジュールのインターフェイスが変更されるたびに、技術者がセンサ等の機器の仕様書を熟読してサービスモジュールのインターフェイスの仕様を理解し、そのインターフェイスに対応するクライアントモジュールのインターフェイスを手作業で作成しなければならないため、極めて煩雑であった。
【００１１】
同様の課題は、SOA（Service-Oriented Architecture）でシステムを構築する場合にも存在する。SOAは、ビジネスプロセスの構成単位に合わせてソフトウェア部品を構築し、それらをネットワーク上に公開し、相互に連携させることにより、柔軟なエンタープライズシステムを構築するシステムアーキテクチャである。このアーキテクチャでは、あるビジネスプロセスに変更があると、そのビジネスプロセスの機能を提供するサービスモジュールのインターフェイスの更新に加えて、サービスモジュールを利用するすべてのクライアントモジュールの更新が必要になる。つまり、上記ビジネスプロセスの変更箇所に直接関係しないクライアントモジュールの更新までも必要となるため、システム開発者に多大な負担を掛けてしまう。
【００１２】
特許文献1に開示されている技術では、例えばRMIサービスの機能拡張のためにRMIのインターフェイスを変更すると、そのインターフェイスを利用するすべてのクライアントプログラムを更新する必要があり、前述と同様の問題が生ずる。
【００１３】
上記特許文献２に開示されている技術は、クライアント装置に適合するデバイスドライバを簡単に用意する点に着目しているが、クライアント装置に接続される機器の変更時における対処方法は考慮されていない。従って、クライアント装置に接続される機器が変更されると、変更後の機器に応じて、デバイスドライバの元となるドライバコアモジュールを作り直す必要があり、前述と同様の問題が生ずる。また、ドライバコアモジュールの数や規模が大きくなる程、モジュールの作成作業は困難になる。さらに、例えばコアモジュールとサブモジュール間のインターフェイスを変更すると、コアモジュールだけではなく、そのインターフェイスを利用するすべてのサブモジュールを更新する必要がある。
【００１４】
同様に、上記特許文献３に開示されている技術は、クライアントのプラットフォームに応じたアプリケーションの実行オブジェクトをサーバ側で生成する点に着目しているが、サーバが提供するアプリケーションが変更された場合の対処方法は考慮されていない。従って、提供するアプリケーションが変更されるたびに、そのアプリケーションを構成するモジュール群を作り直す必要があり、前述と同様の問題が生ずる。また、アプリケーションの数や規模が大きくなる程、モジュールの作成作業は困難になる。さらに、例えば、あるモジュールのインターフェイスを変更すると、そのモジュールに依存するすべてのモジュールを更新する必要がある。
【００１５】
以上の課題を踏まえ、本発明は、サービスモジュールの変更に伴う、クライアントモジュールを含むアプリケーションの更新作業を簡素化することを目的とする。
【課題を解決するための手段】
【００１６】
上記目的を達成すべく、本発明のモジュール間連携支援方法は、他のモジュールに対して自身の機能を提供するサービスモジュールと、該サービスモジュールの機能を利用するクライアントモジュールの仲介を支援するモジュール間連携支援方法であって、サービスモジュールのAPIの仕様を定義するサービスAPI定義情報と、該サービスモジュールの意味情報とを対応づけて記憶するサービスAPI定義ステップと、クライアントモジュールのAPIの仕様を定義するクライアントAPI定義情報と、該クライアントモジュールの意味情報とを対応づけて記憶するクライアントAPI定義ステップと、クライアントモジュールを選択するステップと、前記選択したクライアントモジュールに対応するクライアントモジュール意味情報を取得し、前記取得したクライアントモジュール意味情報に整合するサービスモジュール意味情報を決定し、前記決定したサービスモジュール意味情報に対応するサービスモジュールを、前記選択したクライアントモジュールの連携対象として選択するステップと、前記選択したクライアントモジュールのクライアントAPI定義情報と、前記選択したサービスモジュールのサービスAPI定義情報とに基づいて、前記選択したクライアントモジュールと前記選択したサービスモジュールとを仲介するアダプタを生成するステップとを特徴とする。
【００１７】
本発明の実施形態では、前記サービスAPI定義ステップは、サービスAPI定義情報として、サービスモジュールのAPIで用いられるサービスAPI関数と、該サービスAPI関数の意味情報とを対応づけて記憶するステップを含み、前記クライアントAPI定義ステップは、クライアントAPI定義情報として、クライアントモジュールのAPIで用いられるクライアントAPI関数と、該クライアントAPI関数の意味情報とを対応づけて記憶するステップを含み、前記アダプタを生成するステップは、クライアント又はサービスの一方を「第１」と呼び、他方を「第２」と呼ぶものとした場合、前記選択した第１モジュールのAPIで用いられる第１API関数を選択するステップと、前記選択した第１API関数に対応する第１API関数意味情報を取得し、前記取得した第１API関数意味情報に整合する第２API関数意味情報を決定し、前記決定した第２API関数意味情報に対応する、前記選択した第２モジュールで用いられる第２API関数を、前記選択した第１API関数の連携対象として選択するステップと、前記選択した第１API関数と、前記選択した第２API関数とに基づいて、前記選択した第１API関数と前記選択した第２API関数とを仲介するアダプタの部分を生成するステップとを含む。
【００１８】
本発明の別の実施形態では、前記サービスAPI定義ステップは、サービスAPI定義情報として、サービスモジュールのAPIで用いられるサービスAPI関数のパラメタと、該パラメタの意味情報とを対応づけて記憶するステップを含み、前記クライアントAPI定義ステップは、クライアントAPI定義情報として、クライアントモジュールのAPIで用いられるクライアントAPI関数のパラメタと、該パラメタの意味情報とを対応づけて記憶するステップを含み、前記アダプタの部分を生成するステップは、前記選択した第１API関数のパラメタを選択するステップと、前記選択した第１API関数パラメタに対応する第１API関数パラメタ意味情報を取得し、前記取得した第１API関数パラメタ意味情報に整合する第２API関数パラメタ意味情報を決定し、前記決定した第２API関数パラメタ意味情報に対応する、前記選択した第２API関数のパラメタを、前記選択した第１API関数パラメタの連携対象として選択するステップと、前記選択した第１API関数パラメタと、前記選択した第２API関数パラメタとを対応づけて、前記選択した第１API関数と前記選択した第２API関数とを仲介するアダプタの部分を生成するステップとを含む。
【００１９】
本発明のさらに別の実施形態では、前記クライアントAPI定義ステップは、クライアントAPI定義情報として、固定値と、該固定値の意味情報とを対応づけて記憶するステップを含み、前記アダプタの部分を生成するステップは、前記選択した第１API関数がサービスAPI関数である場合に、該関数のサービスAPI関数パラメタのうち、意味情報が固定値意味情報であるパラメタを特定するステップと、前記固定値のうち、前記特定したサービスAPI関数パラメタの固定値意味情報に整合する意味情報に対応する固定値を、前記特定したサービスAPI関数パラメタの連携対象として選択するステップと、前記選択したクライアントAPI関数パラメタと、前記選択したサービスAPI関数パラメタとを対応づけて、かつ、前記特定したサービスAPI関数パラメタに前記選択した固定値を代入して、前記選択したクライアントAPI関数と前記選択したサービスAPI関数とを仲介するアダプタの部分を生成するステップとを含む。
【００２０】
本発明のさらにまた別の実施形態では、さらに、前記選択したクライアントモジュールに前記生成したアダプタをリンクさせるステップを含む構成を採用することができる。
【００２１】
また、前記サービスモジュールは、外部ユニットを利用してデータ取得を行うモジュールであり、前記外部ユニットは、センサ等の電子機器、又はネットワーク上にある計算機内で動作するプログラムユニットを含む。
【００２２】
さらに、前記アダプタを生成するステップでは、アダプタの実行時に前記外部ユニットへアクセスするための情報を取得するように該アダプタを生成する。
【００２３】
本発明のモジュール間連携支援プログラムは、上記いずれかの方法を計算機に実行させることを特徴とする。
【００２４】
本発明のモジュール間連携支援システムは、他のモジュールに対して自身の機能を提供するサービスモジュールと、該サービスモジュールの機能を利用するクライアントモジュールの仲介を支援するモジュール間連携支援システムであって、サービスモジュールのAPIの仕様を定義するサービスAPI定義情報と、該サービスモジュールの意味情報とを対応づけて記憶するサービスAPI定義格納部と、クライアントモジュールのAPIの仕様を定義するクライアントAPI定義情報と、該クライアントモジュールの意味情報とを対応づけて記憶するクライアントAPI定義格納部と、クライアントモジュールを選択するアダプタ生成要求部と、前記選択したクライアントモジュールに対応するクライアントモジュール意味情報を取得し、前記取得したクライアントモジュール意味情報に整合するサービスモジュール意味情報を決定し、前記決定したサービスモジュール意味情報に対応するサービスモジュールを、前記選択したクライアントモジュールの連携対象として選択する連携対象選択部と、前記選択したクライアントモジュールのクライアントAPI定義情報と、前記選択したサービスモジュールのサービスAPI定義情報とに基づいて、前記選択したクライアントモジュールと前記選択したサービスモジュールとを仲介するアダプタを生成するアダプタ生成部とを含むことを特徴とする。
【００２５】
本発明の実施形態では、前記サービスAPI定義格納部は、サービスAPI定義情報として、サービスモジュールのAPIで用いられるサービスAPI関数と、該サービスAPI関数の意味情報とを対応づけて記憶し、前記クライアントAPI定義格納部は、クライアントAPI定義情報として、クライアントモジュールのAPIで用いられるクライアントAPI関数と、該クライアントAPI関数の意味情報とを対応づけて記憶し、前記アダプタ生成部は、クライアント又はサービスの一方を「第１」と呼び、他方を「第２」と呼ぶものとした場合、前記選択した第１モジュールのAPIで用いられる第１API関数を選択し、前記選択した第１API関数に対応する第１API関数意味情報を取得し、前記取得した第１API関数意味情報に整合する第２API関数意味情報を決定し、前記決定した第２API関数意味情報に対応する第２API関数を、前記選択した第１API関数の連携対象として選択し、前記選択した第１API関数と、前記選択した第２API関数とに基づいて、前記選択した第１API関数と前記選択した第２API関数とを仲介するアダプタの部分を生成する。
【００２６】
本発明の別の実施形態では、前記サービスAPI定義格納部は、サービスAPI定義情報として、サービスモジュールのAPIで用いられるサービスAPI関数のパラメタと、該パラメタの意味情報とを対応づけて記憶し、前記クライアントAPI定義格納部は、クライアントAPI定義情報として、クライアントモジュールのAPIで用いられるクライアントAPI関数のパラメタと、該パラメタの意味情報とを対応づけて記憶し、前記アダプタ生成部は、前記選択した第１API関数のパラメタを選択し前記選択した第１API関数パラメタに対応する第１API関数パラメタ意味情報を取得し、前記取得した第１API関数パラメタ意味情報に整合する第２API関数パラメタ意味情報を決定し、前記決定した第２API関数パラメタ意味情報に対応する第２API関数パラメタを、前記選択した第１API関数パラメタの連携対象として選択し、前記選択した第１API関数パラメタと、前記選択した第２API関数パラメタとを対応づけて、前記選択した第１API関数と前記選択した第２API関数とを仲介するアダプタの部分を生成する。
【００２７】
本発明のさらに別の実施形態では、前記クライアントAPI定義格納部は、クライアントAPI定義情報として、固定値と、該固定値の意味情報とを対応づけて記憶し、前記アダプタ生成部は、前記選択した第１API関数がサービスAPI関数である場合に、該関数のサービスAPI関数パラメタのうち、意味情報が固定値意味情報であるパラメタを特定し、前記固定値のうち、前記特定したサービスAPI関数パラメタの固定値意味情報に整合する意味情報に対応する固定値を、前記特定したサービスAPI関数パラメタの連携対象として選択し、前記選択したクライアントAPI関数パラメタと、前記選択したサービスAPI関数パラメタとを対応づけて、かつ、前記特定したサービスAPI関数パラメタに前記選択した固定値を代入して、前記選択したクライアントAPI関数と前記選択したサービスAPI関数とを仲介するアダプタの部分を生成する。
【００２８】
本発明のさらにまた別の実施形態では、前記アダプタ生成要求部は、前記選択したクライアントモジュールに前記生成したアダプタをリンクさせる。
【００２９】
また、前記サービスモジュールは、外部ユニットを利用してデータ取得を行うモジュールであり、前記外部ユニットは、センサ等の電子機器、又はネットワーク上にある計算機内で動作するプログラムユニットを含む。
【００３０】
さらに、前記アダプタ生成部は、アダプタの実行時に前記外部ユニットへアクセスするための情報を取得するように該アダプタを生成する。
【発明の効果】
【００３１】
本発明によれば、サービスAPI定義とクライアントAPI定義に基づいて、モジュール同士を連携するアダプタを自動生成することで、サービスモジュールのインターフェイスの変更に伴う、クライアントモジュールを含むアプリケーションの変更を不要となるため、柔軟なモジュール間の連携を実現することができる。
【００３２】
さらに、サービスAPI定義及びクライアントAPI定義に付加した意味情報に基づき、引数や戻り値のマッピングを行うことで、引数や戻り値の型情報や構造が異なる場合（値と配列の場合など）でも、適切にモジュール間の連携を行うことが可能となる。
【発明を実施するための最良の形態】
【００３３】
【実施例１】
【００３４】
本実施例におけるシステム構成図を図1に示す。本実施例では、他のモジュールに対して自身の機能を提供するサービスモジュールと、このサービスモジュールの機能を利用するクライアントモジュールの仲介を支援するモジュール間連携支援システムの例として、センサ制御システムについて説明する。
【００３５】
このシステムでは、管理サーバ10、コントローラ20、センサ30がネットワークで接続されており、相互に通信することができる。
【００３６】
説明を簡単にするために、図1ではセンサ30、コントローラ20、プログラム実行部50を1個ずつ図示しているが、実際のシステムでは、複数種類のセンサ30を複数のコントローラ20から制御し、同時に複数のプログラム実行部50が動作する構成になる。尚、このシステムの適用例としては、例えば、建物内で利用される空調管理システムなど、種々の態様を考えることができる。
【００３７】
センサ30は、ネットワークに接続されているが、センサ30とコントローラ20との通信手段はどのようなものでもよく、例えば、センサ30とコントローラ20がRS-232C等のケーブルにより直接接続されている構成や赤外線通信等の無線通信手段を用いる構成でもよい。また、センサ30としては、温度センサ、湿度センサ、人感センサ、RFID R/W等の様々なセンサを利用できる。どのようなセンサを利用するかは、プログラム実行部50によるセンサ30の利用目的に依存する事柄であり、本発明の目的には直接関係しない。
【００３８】
管理サーバ10及びコントローラ20としては、図2に示すような構成の一般的なコンピュータ100が採用され得る。すなわち、CPU101、RAM102、ROM103、HDD等の二次記憶装置104、ネットワークを経由して通信を行うための通信I/F105、ユーザとの間でデータの入出力を行うための入出力I/F106、CD-ROMやDVD等の外部メディアにアクセスするためのメディアI/F107がそれぞれ内部で接続され、これらの各構成要素が連携して稼動する。典型的には、コンピュータ100は、上記入出力I/F106にキーボード108、マウス109、ディスプレイ110等の入力装置及び出力装置が接続された状態で使用される。
【００３９】
コントローラ20は、各種のプログラムを格納するプログラム格納部49と、CPU101が上記各種のプログラムを実行することにより機能的に実現されるプログラム実行部50と、クライアントAPI定義格納部としての機器定義格納部51とを含んで構成される。
【００４０】
プログラム格納部49は、アダプタ生成要求プログラム23、クライアントモジュールとしてのアプリケーションロジック24、サービスモジュールとしてのセンサ制御モジュール28、及びアプリケーションロジック24とセンサ制御モジュール28とを仲介するアダプタ26とを格納する。また、アプリケーションロジック24は、APIとしてクライアントAPI25を持ち、センサ制御モジュール28は、APIとしてサービスAPI27を持つ。なお、プログラム格納部49は、RAM102やHDD104等の記憶手段を用いて実現される。
【００４１】
ここで、API（Application Program Interface）とは、あるプログラムの機能を他のプログラムから呼び出して利用できるように公開する際の規約のことである。一般的なAPIは、関数（複数の関数の集合を含む）の形式で提供されており、アプリケーションからAPIの関数を呼び出す際には、パラメータ（引数）を適宜指定して呼び出しが行われる。
【００４２】
アダプタ生成要求プログラム23は、アダプタ26の生成及び送信を管理サーバ10に対して要求し、受信したアダプタ26をアプリケーションロジック24及びセンサ制御モジュール28にリンク（動的リンク又は静的リンク）させるためのプログラムであ。コントローラ20のCPU101がアダプタ生成要求プログラム23を実行することにより実現されるプログラム実行部50は、センサ30を制御するためのアプリケーションロジック24を選択し、アプリケーションロジック24の意味情報（クライアントモジュール意味情報）としての機器ID22aとともに管理サーバ10に対してアダプタ26の生成を要求するアダプタ生成要求部としても機能する。
【００４３】
ここで、本実施例における意味情報は、例えば、アプリケーションロジック24の意味を表す情報、及びセンサ制御モジュール28の意味を表す情報であり、それぞれクライアントモジュール意味情報及びサービスモジュール意味情報という。詳細には、これらの意味情報には、外部ユニットとしてのセンサ30を特定するための機器ID、機器名称、測定項目、位置情報、及びメーカ名などが含まれる。なお、位置情報には、IPアドレス、ポート番号、部屋番号、フロア番号など、外部ユニットの設置場所を特定し得る情報が含まれる。
【００４４】
また、アプリケーションロジック24のAPIで用いられるクライアントAPI関数、及びセンサ制御モジュール28のAPIで用いられるサービスAPI関数についても、意味情報が付与され得る。これらの意味情報（クライアントAPI関数意味情報、サービスAPI関数意味情報）には、関数の意味を表す情報として、「デバイスを制御して非同期に読み出しを行う（devCntl/asyncRead）」のような関数の用途及び内容を表す情報、関数名を表す情報、及び関数の型を表す情報などが含まれる。
【００４５】
さらに、クライアントAPI関数のパラメタ及びサービスAPI関数のパラメタについても意味情報が付与され得る。これらの意味情報（クライアントAPI関数パラメタ意味情報、サービスAPI関数パラメタ意味情報）には、パラメタの意味を表す情報として、「デバイスを制御する時間間隔（devCntl/interval）」や「デバイスにアクセスするためのパスワード（devCntl/password）」のようなパラメタの用途及び内容を表す情報、変数名を表す情報、型情報、パラメタを特定するためのIDの情報、及び入力と出力のどちらに該当するかを表す情報などが含まれる。なお、本実施例では、パラメタには、予め値が決められているパラメタ（固定値）が含まれ、固定値の意味情報のことを固定値意味情報という。
【００４６】
アプリケーションロジック24は、センサ30の計測値の収集など、アプリケーションの具体的な内容を表すクライアントモジュールとしてのプログラムである。
【００４７】
アダプタ26は、アプリケーションロジック24とセンサ制御モジュール28を仲介するプログラムである。
【００４８】
センサ制御モジュール28は、外部ユニットを利用してデータ取得を行うサービスモジュールとしてのプログラムであり、例えばセンサ30を制御する機能をアプリケーションロジック24に対して提供する。
【００４９】
コントローラ20のCPU101がアプリケーションロジック24、アダプタ26、及びセンサ制御モジュール28を実行することにより機能的に実現されるプログラム実行部50は、センサ30を制御しセンサから収集したデータを利用し及び活用する。このプログラム実行部50による処理が実現されるには、アプリケーションロジック24とセンサ制御モジュール28が、関数のパラメタの引数及び戻り値を受け渡しできるように連携されている必要がある。
【００５０】
本発明では、アプリケーションロジック24からサービスAPI27を直接利用するのではなく、アプリケーションロジック24からアダプタ26を介してサービスAPI27を利用する構成としている。すなわち、アダプタ26が提供するセンサ制御用インターフェイスとしてのクライアントAPI25を呼び出し、さらにアダプタ26を介してセンサ制御モジュール28のサービスAPI27を呼び出すことで、センサ制御モジュール28を利用する。
【００５１】
機器定義格納部51は、アプリケーションロジック24のクライアントAPI25の仕様を定義するクライアントAPI定義22bと、アプリケーションロジック24の意味情報とを対応づけた情報としての機器定義情報22を記憶する。具体的には、本実施例では、アプリケーションロジック24の意味情報としては、プログラム実行部50が制御するセンサ30を特定するための機器ID22aが用いられる。なお、機器定義格納部51は、RAM102やHDD104等の記憶手段を用いて実現される。
【００５２】
さらに詳細には、機器定義格納部51は、クライアントAPI定義22bとして、クライアントAPI25で用いられるクライアントAPI関数と、各クライアントAPI関数の意味情報とを対応づけて記憶している。また、機器定義格納部51は、クライアントAPI定義22bとして、クライアントAPI25で用いられるクライアントAPI関数のパラメタと、各パラメタの意味情報とを対応づけて記憶している。さらに、機器定義格納部51は、クライアントAPI定義22bとして、固定値と、各固定値の意味情報とを対応づけて記憶している。これらの意味情報の内容や対応付けの方法については、図６、図８〜１３を参照して後述する。
【００５３】
管理サーバ10は、構成情報格納部52と、アダプタ生成手段としてのコード生成部11及び検索手段としての構成管理部12から構成される管理部15とを含んで構成される。
【００５４】
構成情報格納部52は、システム上に存在するすべてのセンサ30に関する構成情報13、及び各センサ30を制御するために用いられるセンサ制御モジュール13ｄを含む各種の情報を格納する。なお、機器定義格納部51は、RAM102やHDD104等の記憶手段を用いて実現される。
【００５５】
具体的には、構成情報格納部52は、センサ制御モジュール28のサービスAPI27の仕様を定義するサービスAPI定義13cと、各センサ制御モジュール28の意味情報とを対応づけて記憶している。また、構成情報格納部52は、サービスAPI定義13cとして、センサ制御モジュール28のサービスAPI27で用いられるサービスAPI関数と、各サービスAPI関数の意味情報とを対応づけて記憶している。さらに、構成情報格納部52は、サービスAPI定義22cとして、センサ制御モジュール28のサービスAPI27で用いられるサービスAPI関数のパラメタと、各パラメタの意味情報とを対応づけて記憶している。
【００５６】
また、本実施例では、構成情報格納部52には、センサ制御モジュール28の意味情報（サービスモジュール意味情報）として、制御対象となる外部ユニットを特定するための機器ID13a、及び機器名称や位置情報等から構成される属性情報としての機器属性13bが格納される。なお、サービスモジュール意味情報、サービスAPI関数意味情報、及びサービスAPI関数パラメタ意味情報の内容や上記対応付けの方法については、図７〜１３を参照して後述する。  管理サーバ10内の管理部15は、管理サーバ10のCPUが所定のプログラムを実行することにより機能的に実現される。
【００５７】
管理部15内の構成管理部12は、コントローラ20のプログラム実行部50から、サービスAPI定義13cを特定する機器ID22aとクライアントAPI定義22bを受信すると、構成情報13に格納されている機器ID13aのうち、受信した機器ID22aに整合する機器ID13aを決定し、決定した機器ID13aに対応するセンサ制御モジュール13dを、コントローラ20から受信したクライアントAPI定義22bに対応するアプリケーションロジック24の連携対象として選択する連携対象選択部として機能する。そして、構成管理部12は、選択したセンサ制御モジュール13dのサービスAPI定義13cと、コントローラ20から受信したクライアントAPI定義22bをコード生成部11へ渡す。
【００５８】
管理部15内のコード生成部11は、コントローラ20から受信したクライアントAPI定義22bと、構成管理部12が選択したサービスAPI定義13dとに基づいて、コントローラ20内でプログラム実行部50が選択したアプリケーションロジック24と構成管理部12が選択したセンサ制御モジュール13dとを仲介するアダプタを生成する。
【００５９】
そして、コード生成部11は、生成したアダプタ26をコントローラ20へ送り、このアダプタ26は、コントローラ20のプログラム実行部50によってプログラム格納部19内にインストールされ、アプリケーションロジック24とセンサ制御モジュール28にリンクされる。
【００６０】
本発明においては、上記アダプタ26が提供するクライアントAPI25の仕様は、アプリケーションロジック24の開発者が決定することができる。すなわち、アプリケーションロジック24の開発者がシステム上で利用したいセンサ30の機器ID22aと、プログラム実行部50によってアプリケーションロジック24から呼び出されるクライアントAPI25のクライアントAPI定義22bをあらかじめ機器定義情報22に記載しておくだけで、管理サーバ10内のコード生成部11が必要なアダプタ26を自動的に生成する。
【００６１】
図3を用いて、アダプタ26がアプリケーションロジック24とセンサ制御モジュール28にリンクされるまでの手順の概要を説明する。
【００６２】
まず、コントローラ20において、CPU101がプログラム格納部10内に格納されているクライアントAPI定義プログラム（図示省略）を実行することにより実現されるプログラム実行部50は、アプリケーションロジック27のクライアントAPI25の仕様を定義するクライアントAPI定義22bを作成し、作成されたクライアントAPI定義22bとアプリケーションロジック27の意味情報とを対応づけてなる機器定義情報22を機器定義格納部51に記憶する処理としてクライアントAPI定義ステップを実行する（S101）。なお、計算機を用いた機器定義情報22の作成方法の詳細については後述する。
【００６３】
クライアントAPI定義ステップ（S101）には、以下のS101a〜S101dの処理が含まれる。以下、各処理について順に説明する。
【００６４】
プログラム実行部50は、クライアントAPI定義22bの作成過程において、アプリケーションロジック24のクライアントAPI25で用いられるクライアントAPI関数と、各クライアントAPI関数の意味情報とを対応づける（S101a）。
【００６５】
プログラム実行部50は、クライアントAPI定義22bの作成過程において、アプリケーションロジック24のクライアントAPI25で用いられるクライアントAPI関数のパラメタと、各パラメタの意味情報とを対応づける（S102b）。
【００６６】
プログラム実行部50は、クライアントAPI定義22bの作成過程において、固定値と、各固定値の意味情報とを対応づける（S101c）。基本的には、以上の処理（S101a〜S101c）を通してクライアントAPI定義22bが作成される。
【００６７】
そして、プログラム実行部50は、作成したクライアントAPI定義22bと、このクライアントAPI定義22bに対応するアプリケーションロジック24の意味情報（機器ID22a）とを対応づけ、機器定義情報22として機器定義格納部51に格納する（S101d）。
【００６８】
管理サーバ10側では、管理部15は、センサ制御モジュール13dのAPIの仕様を定義するサービスAPI定義13cを作成し、作成されたサービスAPI定義13cとセンサ制御モジュール28の意味情報とを対応づけてなる構成情報13を構成情報格納部52に記憶する処理としてサービスAPI定義ステップを実行する（S102）。なお、計算機を用いた構成情報13の作成方法の詳細については後述する。
【００６９】
サービスAPI定義ステップ（S102）には、以下のS102a〜S102cの処理が含まれる。以下、各処理について順に説明する。
【００７０】
管理部15は、サービスAPI定義13cの作成過程において、センサ制御モジュール13dのAPIで用いられるサービスAPI関数と、サービスAPI関数の意味情報とを対応づける（S102a）。
【００７１】
管理部15は、サービスAPI定義13cの作成過程において、センサ制御モジュール13dのAPIで用いられるサービスAPI関数のパラメタと、各パラメタの意味情報とを対応づける（S102b）。基本的には、以上の処理（S102a、S102b）によってサービスAPI定義13dが作成される。
【００７２】
そして、管理部15は、作成したサービスAPI定義13cと、このサービスAPI定義13cに対応するセンサ制御モジュール13dの意味情報（ここでは機器ID13aと機器属性13b）とを対応づけ、構成情報13として構成情報格納部52に格納する（S102c）。
【００７３】
次に、コントローラ20において、CPU101がアダプタ生成要求プログラム23を実行することにより実現されるプログラム実行部50は、制御対象となる外部ユニットに対応するアプリケーションロジック24を選択する（S103）。例えば、コントローラ20のCPU101がアプリケーションロジック24の実行を開始した場合（例えば、ユーザが起動を指示した場合）、プログラム実行部50は、センサ30からデータ取得を行うためのクライアントモジュールとしてアプリケーションロジック24を選択する。
【００７４】
そして、CPU101がアダプタ生成要求プログラム23を実行することにより実現されるプログラム実行部50は、選択したアプリケーションロジック24に対応するクライアントAPI定義22bと、そのアプリケーションロジック27に対応する機器ID22aとを機器定義格納部51から取得し、これらを管理サーバ10に送信する（S104）。
【００７５】
管理サーバ10内では、CPU101が所定のプログラム（図示省略）を実行することにより機能的に実現される構成管理部12は、プログラム実行部50が選択したアプリケーションロジック24に対応する機器ID22aを取得し、取得した機器ID22aに整合する機器ID13aを決定し、決定した機器ID13aに対応するセンサ制御モジュール13dを、プログラム実行部50が選択したアプリケーションロジック24の連携対象として選択する（S105）。
【００７６】
そして、CPU101がコード生成プログラム（図示省略）を実行することにより機能的に実現されるコード生成部11は、プログラム実行部50が選択したアプリケーションロジック24のクライアントAPI定義22bと、S105で構成管理部12が選択したセンサ制御モジュール13dのサービスAPI定義13cとに基づいて、プログラム実行部50が選択したアプリケーションロジック24とS105で選択したセンサ制御モジュール13dとを仲介するアダプタのソースコードを生成し（S106）、生成したソースコードをコンパイルして実行ファイルを生成する（S107）。この例では、アダプタのソースコードは、管理サーバ10内のコード生成部11が生成しているが、別の計算機上で作成したうえで、管理サーバ10へアップロードする構成でもよい。アダプタコード生成処理（S106）の詳細については、図9〜17を参照して後述する。
【００７７】
なお、本実施例におけるアダプタコード生成処理（S106）には、以下の処理が含まれる。
【００７８】
（１）関数同士を対応付ける処理
この処理では、コード生成部11は、アプリケーションロジック24のAPIで用いられるクライアントAPI関数と、センサ制御モジュール13dのAPIで用いられるサービスAPI関数とを対応づける。
【００７９】
具体的には、コード生成部11は、この処理において、
S105で構成管理部12が選択したセンサ制御モジュール13dのAPIで用いられるサービスAPI関数を選択するステップと、
その選択したサービスAPI関数に対応するサービスAPI関数意味情報を取得し、取得したサービスAPI関数意味情報に整合するクライアントAPI関数意味情報を決定し、決定したクライアントAPI関数意味情報に対応する、S105でプログラム実行部50が選択したアプリケーションロジック24で用いられるクライアントAPI関数を、上記選択したサービスAPI関数の連携対象として選択するステップと、
上記選択したサービスAPI関数と、上記選択したクライアントAPI関数とに基づいて、これらのサービスAPI関数とクライアントAPI関数とを仲介するアダプタの部分を生成するステップと、
を実行する。
【００８０】
（２）パラメタ同士を対応付ける処理
この処理では、コード生成部11は、上記関数同士を対応付ける処理で対応付けた関数において、意味情報が共通するパラメタ同士を対応付ける。
【００８１】
具体的には、コード生成部11は、この処理において、
上記（１）の処理で選択したサービスAPI関数のパラメタを選択するステップと、
その選択したサービスAPI関数パラメタに対応するサービスAPI関数パラメタ意味情報を取得し、この取得したサービスAPI関数パラメタ意味情報に整合するクライアントAPI関数パラメタ意味情報を決定し、決定したクライアントAPI関数パラメタ意味情報に対応する、上記（１）の処理で選択したクライアントAPI関数のパラメタを、上記選択したサービスAPI関数パラメタの連携対象として選択するステップと、
上記選択したサービスAPI関数パラメタと、上記選択したクライアントAPI関数パラメタとを対応づけて、上記（１）の処理で選択したサービスAPI関数及びクライアントAPI関数を仲介するアダプタの部分を生成するステップと、
を実行する。
【００８２】
（３）パラメタと固定値とを対応付ける処理
この処理では、コード生成部11は、上記関数同士を対応付ける処理で対応付けた関数において、固定値意味情報が整合するサービスAPI関数パラメタとクライアントAPI定義22b内の固定値とを対応づける。
【００８３】
具体的には、コード生成部11は、この処理において、
上記（１）の処理で選択したサービスAPI関数のサービスAPI関数パラメタのうち、意味情報が固定値意味情報であるパラメタを特定するステップと、
コントローラ20のプログラム実行部50から受信したクライアントAPI定義22bに含まれる固定値のうち、上記特定したサービスAPI関数パラメタの固定値意味情報に整合する意味情報に対応する固定値を、上記特定したサービスAPI関数パラメタの連携対象として選択するステップと、
上記（２）の処理で選択したクライアントAPI関数パラメタとサービスAPI関数パラメタとを対応づけて、かつ、上記特定したサービスAPI関数パラメタに上記選択した固定値を代入して、上記（１）の処理で選択したクライアントAPI関数及びサービスAPI関数とを仲介するアダプタの部分を生成するステップと、
を実行する。なお、上記（１）〜（３）の処理の詳細については、図９〜１３を参照して後述する。
【００８４】
構成管理部12は、コード生成部11が作成したアダプタ26と、ステップS105で選択したセンサ制御モジュール13dをコントローラ20に送信する（S108）。
【００８５】
コントローラ20側では、CPU101がアプリケーションロジック24、アダプタ26、及びセンサ制御モジュール28を実行することにより機能的に実現されるプログラム実行部50は、受信したアダプタ26とセンサ制御モジュール13dをプログラム格納部49に組み込み（S109）、アダプタ26を用いてアプリケーションロジック24とセンサ制御モジュール28とを連携させる。その後、プログラム実行部50は、組み込まれたアダプタ26を介してセンサ制御モジュール28の機能を利用する（S110）。
【００８６】
上記の説明では、アプリケーション起動時にアダプタ26が組み込まれるが、プログラム実行部50がセンサ30にアクセスしようとしたときにアダプタ26がプログラム格納部49に組み込まれる方式（オンデマンドダウンロード方式）を用いることも可能である。具体的には、アダプタ26及びセンサ制御モジュール28を管理サーバ10からダウンロードして実行プログラム23へ組み込む機能を有するいわゆる"ブートストラップアダプタ"を、あらかじめプログラム格納部49へ組み込んでおけばよい。これにより、CPU101がアプリケーションロジック24を実行することにより機能的に実現されるプログラム実行部50がセンサ30にアクセスしようとするタイミングで、CPU101がブートストラップアダプタを実行することにより実現されるプログラム実行部50は、管理サーバ10に対してアダプタの生成を要求し、生成されたアダプタ26がプログラム格納部49に組み込まれる。尚、ブートストラップアダプタは、プログラム管理部49にアダプタ26が組み込まれていない場合にのみ使用される。また、上記ブートストラップアダプタに基づく処理手順は、アダプタ生成要求プログラム23に基づいて実行されるようにしてもよい。
【００８７】
以上説明したように、本発明では、センサ30を制御するためのサービスAPI27の仕様変更があった場合でも、アダプタ26が自動生成されるため、クライアントAPI25の仕様変更作業が不要となり、アプリケーションロジック24の修正を行う必要がないという効果が得られる。
【００８８】
また、本発明によれば、センサ30の種類を変更した場合には、構成情報13の機器属性13bとサービスAPI定義13cを書き換えるだけでよいため、アプリケーションロジック24の修正を行う必要がない。これにより、システムの開発環境において、運用環境とは異なる種類のセンサ30を用いて動作確認等の作業を行えるため、柔軟性の高いシステムを開発することが可能になる。
【００８９】
センサ30の変更を頻繁に行う場合には、機器ID13a、22aは、各センサに個別に割り当てた識別子ではなく、センサ30の役割や機能を表す識別子（例えば、温度の検出や湿度の検出など）とすることが望ましい。何故なら、機器ID13a、22aを各センサ30に個別に割り当てた識別子とすると、センサ30を取り替える毎に、構成情報13及び機器定義情報22内の機器ID13a、22aを変更する必要があるからである。機器ID13a、22aをセンサ30の役割を表す識別子とすることで、センサ30を同じ役割や機能を持つセンサ30に取り替え場合でも、機器ID13a、22aの変更は不要となる。
【００９０】
以下、具体例を用いてアダプタ26の自動生成処理の手順を詳細に説明する。なお、以下の説明においては、クライアントモジュール意味情報、クライアントAPI関数意味情報、クライアントAPI関数パラメタ意味情報、サービスモジュール意味情報、サービスAPI関数意味情報、サービスAPI関数パラメタ意味情報のうち、関数の用途及び内容を表す情報及びパラメタの用途及び内容を表す情報を意味情報と表記し、その他の意味情報については、機器ID、型情報、関数名、変数名、属性条件のように、個別の情報名をそのまま表記するものとする。
【００９１】
まず、サービスAPI27の例を図4に、クライアントAPI25の例を図5に示す。サービスAPI27を利用してセンサ30からデータを収集するには、図4の12行目に示した「read」関数を利用する。この例では、「read」関数は、処理が成功したかどうかをboolean型（処理が成功した場合にtrue）で返す。また、センサ30は、内部に複数種類のセンサ（内部センサ）を具備していることが想定されている。例えば、温度センサ、湿度センサ、光量センサを備えており、温度、湿度、光量を同時に測定することができるセンサが想定されている。
【００９２】
「read」関数の第1引数「addr」はセンサ30のアドレス、第2引数「type」は実際に測定を行う内部センサの種類、第3引数「period」はセンシング間隔、第4引数「count」は「type」及び「period」の要素数、第5引数「pass」はセンサ30を利用するためのパスワード、第6引数「l」はセンサから非同期にデータを受け取るためのコールバックオブジェクトである。
【００９３】
配列「type」及び「period」における同一インデックスの値は相互に対応する。つまり、配列のインデックスを「i」とすると、type[i]で指定される種類の内部センサのセンシング間隔は、period[i]で指定される。
【００９４】
「pass」が配列でない理由は、パスワードは内部センサではなくセンサ30本体が要求するものだからである。つまり、センサ30は、ユーザから入力されたパスワードが正しいものであることを確認すると、ユーザに内部センサへのアクセスを許可する。
【００９５】
センサ30からデータを収集するためのコールバックオブジェクトの仕様は、図4の15行目から23行目に記載されている。センサ30からデータを受信すると、「read」関数に指定したコールバックオブジェクトの「received」関数が呼び出される。「received」関数の第1引数「type」はセンシングした内部センサの種類、第2引数「value」は内部センサから受信したデータの値、第3引数「count」は「type」及び「value」の要素数である。配列「type」及び「value」における同一インデックスの値は相互に対応する。つまり、配列のインデックスを「i」とすると、type[i]で指定される種類の内部センサから受信した値は、value[i]で指定される。
【００９６】
一方、クライアントAPI25を利用してセンサ30からデータを収集するには、図5の11行目に示した「getData」関数を利用する。本関数では、サービスAPIの「read」関数と「received」関数の引数「type」、「period」、及び「value」の情報を、「DevInfo」クラスに纏めている。また、これらのサービスAPIの関数とクライアントAPIの「getData」関数との相違点としては、「getData」関数には、サービスAPIの「read」関数のパラメータである「pass」（パスワード）に対して渡すべき引数が指定されていない。さらに、サービスAPIの「read」関数では、「addr」（アドレス）によってセンサ30が指定されるが、クライアントAPIの「getData」関数では、「id」（機器ID）によってセンサ30が指定される。その他の仕様は、クライアントAPIとサービスAPI間で本質的な違いはない。
【００９７】
クライアントAPIにおいて、「getData」関数の第1引数「id」はセンサ30の機器ID、第2引数「info」は測定を行う内部センサの種類とセンシング間隔、第3引数「count」は「info」の要素数、第4引数「cb」は非同期にデータを受け取るためのコールバックオブジェクトを指定する。第2引数「info」はDevInfo型オブジェクトであるが、本関数ではクラスメンバのうち「type」と「period」のみを利用する。「type」は測定を行う内部センサの種類であり、「period」はセンシング間隔である。
【００９８】
クライアントAPIのコールバックオブジェクトの仕様は、図5の29行目から37行目に記載されている。センサ30からデータを受信すると、「gotData」関数が呼び出される。「gotData」関数の第1引数「info」には、センシングした内部センサの種類とその内部センサから受信したデータの値がDevInfo型オブジェクトの配列として渡される。また、第2引数「count」には、「info」の要素数が渡される。さらに、「gotData」関数には、DevInfo型オブジェクトが渡されるが、本関数ではクラスメンバのうち「type」と「value」のみを利用する。
【００９９】
図6に機器定義情報22の具体例を、図7に構成情報13の具体例を示す。機器定義情報22において、「devices」要素以下の情報が、図1に示した機器ID22aに対応し、この部分にプログラム実行部50が利用するセンサ30の一覧が記載される。「devices」要素のサブ要素である「device」要素が各センサ30に対応し、「device」要素の「id」属性にはセンサの機器IDが、「devType」属性にはセンサの種類が記載される。「id」属性に指定した機器IDは、クライアントAPI25の引数として使用される。「devType」属性は、クライアントAPI定義22bとの対応関係を表現するために指定するものであり、1つのアプリケーション内で統一されていれば良い。
【０１００】
一方、構成情報13（図7）において、「devices」要素以下の情報が、図1に示した機器ID13aと機器属性13bに対応し、この部分にシステム内に存在するセンサ30の一覧が記載される。具体的には、機器定義情報22と同様に、「devices」要素のサブ要素である「device」要素には各センサ30の情報が記載される。つまり、「device」要素の「id」属性にセンサの機器IDが記載され、「devType」属性にはセンサの種類が記載される。
【０１０１】
「devType」属性は、サービスAPI定義13cとの対応関係を表現するために指定するものであり、構成情報13内で統一されている必要がある。
【０１０２】
「device」要素のサブ要素である「param」要素には、機器属性13bの属性パラメタを指定する。属性パラメタは、そのセンサ30を利用するときに、対応するサービスAPIの引数として渡される。
【０１０３】
図6に示した機器定義情報22の「apis」要素のサブ要素である「apidef」要素以下にクライアントAPI定義22bが記載される。「apidef」要素は、1つのモジュールのAPI仕様を定義している。「apidef」要素の属性「devType」によって、「device」要素の「id」属性として記載した機器IDとの対応関係を指定する。
【０１０４】
構成情報13は、機器定義情報22の構造と同様に、「api」要素のサブ要素である「apidef」要素以下にサービスAPI定義13cが記載される。クライアントAPI定義22bとサービスAPI定義13cは、「apidef」要素以下の記載方法は同一であるので、以下ではクライアントAPI定義22bについてのみ「apidef」要素以下の記載方法を詳細に説明し、サービスAPI定義13cについての具体的な説明は省略する。
【０１０５】
「apidef」要素のサブ要素である「funcdef」要素が1つの関数に対するクライアントAPI定義となる。一般的に、1つのモジュールを利用するためのAPIは複数の関数から構成されるため、このように「apidef」要素以下に複数の「funcdef」要素を記載可能とし、複数の関数が定義され得る形式にしている。尚、図８は、本実施例において「funcdef」要素以下に記載されるXMLタグ、XML属性、属性型、及びそれらの意味を示す。以下、要点を説明する。
【０１０６】
「funcdef」要素の「type」属性には、その関数が定義されているオブジェクトの型情報が記載され、「funname」属性には、その関数の名前が記載される。例えば、図6では「DevCntl」型のオブジェクトのメンバ関数「getData」を定義するために、「type」属性に「DevCntl」を指定し、「funcname」属性に「getData」を指定している。
【０１０７】
「funcdef」要素のサブ要素である「params」要素には、関数の引数と戻り値（以後、引数と戻り値を纏めてパラメタと呼ぶ）の情報が記載され、「funcdef」要素のサブ要素である「fixparams」要素には固定値としての固定変数が記載される。固定変数は、クライアントAPIが引数に取らないパラメタをサービスAPIへ指定する必要がある場合に記載される。
【０１０８】
具体的には、図4に示したサービスAPIの「read」関数にはパスワードを指定する必要があるが、図5に示したクライアントAPIの「getData」関数ではパスワードが指定されない。従って、このままではクライアントAPIの「getData」関数からサービスAPIの「read」関数を呼び出すことができない。そこで、固定変数としてパスワードをクライアントAPI定義22b内に記載しておくことで、コード生成部11は、固定変数として記載されたパスワードをサービスAPIへ渡すように機能するアダプタ26を生成することができる。
【０１０９】
また、各「param」要素がパラメタに対応する。具体的には、パラメタの型情報が「type」属性として記載され、パラメタの入出力情報（その引数がデータ入力とデータ出力のどちらで利用されるのかを表す情報）が「inout」属性として記載される。また、引数がクラスオブジェクトのような構造体である場合は、入出力情報は個々のクラスメンバに対して決まるため、パラメタの入出力情報は記載しないものとする。
【０１１０】
引数がクラスオブジェクトのような構造体となる場合、その構造を表現するために、「param」要素を階層構造化して記載するのがよい。構造体であることを現すパラメタの「type」属性（型情報）としては、「struct:（オブジェクト型）」と記載することができる。例えば図6の例では、「getData」関数の第2引数がDevInfo型の配列であるため、対応する「param」要素の「type」属性には「struct:DevInfo[]」と記載されている。型情報が配列で表わされている場合は、「type」属性に「（型情報）[]」と指定すればよい。
【０１１１】
上記「struct:DevInfo[]」は、構造体と配列を組み合わせた型であるため、「[]」を含んだ記述になっている。関数が配列を引数として取る場合、「配列の要素数」を関数の引数として別途指定する場合があるため、パラメタが「配列の要素数」に対応する場合には、そのパラメタの「type」属性に、「arraycount:（型情報）」と記載するのがよい。
【０１１２】
「arraycount」で指定する型情報は、要素数を表現するパラメタの型情報であり、通常はshort, int, long等、整数を表現する型が用いられる。さらにパラメタが「配列の要素数」に対応する場合、そのパラメタが要素数を指定する配列パラメタの「id」属性の一覧を「arrayid」属性で指定する。従って、指定される配列パラメタには、「id」属性を指定しておく必要がある。例えば図6では、「getData」関数の第2引数が配列であり、その配列の要素数を第3引数として指定している。第3引数と第2引数との関係は、「id」属性及び「arrayid」属性を用いて指定している。
【０１１３】
尚、1つのパラメタが複数の配列の要素数を表現する場合は、「arrayid」属性として、配列パラメタの「id」属性の一覧をカンマ区切りで指定することができる。図7に示したサービスAPI定義13cがこのような例になっている。
【０１１４】
パラメタがコールバックオブジェクトの場合、「type」属性に「callback:（コールバックオブジェクト型）」と記載し、コールバックオブジェクト内で定義されるコールバック関数は、別途「funcdef」要素によって関数仕様を定義することができる。図6では、「DevCB」型のコールバックオブジェクトのメンバ関数「gotData」を定義している。
【０１１５】
図6では、各パラメタに「semantic」属性が設定されているが、これは各パラメタの意味情報を表現する。モジュール間のインターフェイス変換を行うためには、関数やパラメタ間の対応関係を決定する必要がある。上記対応関係を決定する方法としては、型情報や構造を比較してパターンマッチングを行う手法が考えられるが、各インターフェイスが取り扱うパラメタの型情報や構造が異なる場合があり、上記手法ではインターフェイス間の対応関係を作成できない場合がある。
【０１１６】
そこで、関数や各パラメタに意味情報を設定し、意味情報が合致する関数やパラメタ同士を対応させることで、確実に関数やパラメタ間の対応関係を作成できるようにしている。また、パラメタの型情報が異なる場合でも、意味情報が合致すればそのパラメタの型をキャストする等して変換し、対応関係を作成することも可能となる。
【０１１７】
例えば図6では、クライアントAPIの「getData」関数の定義に対応する「funcdef」要素の「semantic」属性に「devCntl/asyncRead」と記載されているが、これは「デバイスを制御して非同期読み出しする」という意味を表す意味情報である。これと同じ意味情報を持つサービスAPIの関数は「read」関数であるので、クライアントAPIの「getData」関数はサービスAPIの「read」関数に対応付けることができる。また、上記のように意味情報を「/」で区切った階層構造の文字列として表現することで、概念を階層的に表現することができる。
【０１１８】
意味情報には、本アダプタ自動生成フレームワークにおいてあらかじめ定義されているものがある。具体的には、図6に示した「getData」関数の第1引数である「＠devID」は、機器IDという意味を持つ意味情報としてあらかじめ定義されている。これにより、コード生成部11は、「＠devID」が指定されている引数を機器IDとして取り扱うソースコードを作成する。
【０１１９】
尚、機器定義情報22（図6）や構成情報13（図7）は人手で作成してもよいが、記述が煩雑になる場合がある。従って、図4の3行目〜10行目に示すように、開発者が、ソースコード内に関数やパラメタに関する各種情報を拡張メタ情報として記述し、計算機が、ソースコードの字句解析を行い、ソースコードに記述された関数、引数の型情報、及び上記拡張メタ情報に基づいて、機器定義情報22や構成情報13内のクライアントAPI定義22bやサービスAPI定義13cを自動生成する手法を用いるのがよい。機器定義情報22や構成情報13を直接記述するよりも、ソースコードに拡張メタ情報を記述する方が、直感的に分かりやすく、これによって開発者の作業負荷を低減することができる。
【０１２０】
以下、図4を用いて、ソースコード内に記述する拡張メタ情報について説明する。図4の3行目に「＠functype」という記述があるが、これは関数に対する拡張メタ情報であり、「＠funtype」の第1引数に意味情報が記述され、第2引数にその他の拡張情報が記述される。図4の3行目の例では、第2引数は省略されているが、図4の17行目の例では、第2引数に「callback」と記載されており、その関数がコールバック関数であることが分かる。
【０１２１】
図4の4行目から10行目には「＠argtype」という記述があるが、これは引数に対する拡張メタ情報である。「＠argtype」の第1引数には拡張メタ情報を指定する引数名、第2引数には入出力情報、第3引数には意味情報、及び第4引数にはその他拡張情報が記述される。図4の10行目では、「＠argtype」の第1引数に「＠ret」と記載されているが、「@ret」は「関数の戻り値」を意味する特別な引数名である。
【０１２２】
また、図5の16行目には「＠semantic」という記述があるが、これは意味情報である。構造体のメンバに追加される拡張メタ情報は意味情報だけであるため、図のように「＠semantic」だけがメンバとして記述されている。
【０１２３】
図3に示したアダプタコード生成処理（S106）において、コード生成部11は、クライアントAPI定義22b及びサービスAPI定義13cを読み込み、パラメタの型情報、意味情報、入出力情報に基づき、パラメタ間の対応関係を作成する。そしてコード生成部11は、上記対応関係に基づいて、パラメタ間の変換を行うアダプタ26のソースコードを作成する。この、アダプタコード生成処理（S106）の内部フローを図9に示す。以下、図9を参照してアダプタコード生成処理の手順を詳細に説明する。
【０１２４】
コード生成部11は、構成情報13内で検索したサービスAPI定義13cを読み込み、サービスAPIを構成する関数を1つ選択する（S201）。
【０１２５】
そして、コード生成部11は、コントローラ20から受信（図3のS104で受信）したクライアントAPI定義22bを読み込み、S201で選択したサービスAPIの関数の意味情報と同じ意味情報を持つクライアントAPIの関数を決定する（S202）。
【０１２６】
例えば、S201でサービスAPIの「read」関数（図7参照）を選択した場合、この関数の意味情報を表す「semantic」属性は「devCntl/asyncRead」であるので、同じ「semantic」属性を持つクライアントAPIの関数をクライアントAPI定義22bから検索する。その結果、「getData」関数（図6参照）が検索結果として取得される。尚、S201で選択したサービスAPIの関数の意味情報と同じ意味情報を持つクライアントAPIの関数が存在しない場合は、コード生成部11がS201へ移行するようにプログラムを設計しておくのがよい。
【０１２７】
次にコード生成部11は、S201で選択したサービスAPIとS203で選択したクライアントAPIのそれぞれの関数の引数情報（図6、図7の「params」要素以下の部分）に基づいて、図10、図11に示すパラメタツリー（PT）を作成する（S203）。
【０１２８】
例えば、S201でサービスAPIの「read」関数を選択し、S202でクライアントAPIの「getData」関数を取得した場合、サービスAPIの「read」関数に対応するパラメタツリー（PT3、図11(a)）と、クライアントAPIの「getData」関数に対応するパラメタツリー（PT1、図10(a)）を作成する。
【０１２９】
パラメタツリー作成処理（S203）において、コード生成部11は、パラメタツリーのルートノードである「params」ノード以下に、関数の引数に対応するノードを、引数の順序に従って追加していく。図10、図11では、親ノードを共有する子ノード（兄弟ノード）間の順序は、引数の順序が早いものを上に図示している。例えば、クライアントAPIの「getData」関数の第1引数は機器IDであるが、その関数に対応するパラメタツリー（PT1）では、「params」要素の最初の子ノード（ノードID=001）が機器IDに対応するノードとなっている。尚、計算機上で上記順序関係を表現するには、兄弟ノードを順序付きリスト等の形式で表現すればよい。
【０１３０】
パラメタツリー（PT）を構成する各ノードは、設定項目として、「型」、「意味情報」、「変数名」、「入出力」、及び「ノードID」を持つ。「型」は「param」要素（図6、図7のクライアントAPI定義及びサービスAPI定義を参照）の「type」属性に記載された値とし、「意味情報」は「param」要素の「semantic」属性に記載された値とし、「変数名」は「param」要素の「arg」属性に記載された値とし、「入出力」は「param」要素の「inout」属性に記載された値とする。また、ノードに設定する「ノードID」は、1つの関数内で重複しないように、コード生成部11によって自動採番される。尚、各パラメタツリー（PT）のルートノードである「params」ノードは、特別なノードであり、上記設定項目を持たない。
【０１３１】
配列パラメタと配列要素数パラメタ間の関係は、「param」要素の「id」属性と「arrayid」属性に基づいて設定される。例えば、クライアントAPIの「getData」関数の第2引数は配列であり、第3引数はその要素数であるが、図6において、その引数間の関係は「id」属性と「arrayid」属性によって関連付けられている。そしてパラメタツリー（PT1）では、上記第2引数に対応するノード（ノードID=002）は、第3引数に対応するノード（ノードID=005）の配列要素として関連付けられている。尚、配列に関する関連付けを計算機上で表現するには、各ノードを表現する構造体に関連先を表すメンバ変数を設け、そのメンバ変数に関連先ノードのIDもしくは、関連先ノードを表現する構造体のアドレスを設定すればよい。
【０１３２】
尚、図10及び図11では、図の閲覧性を向上させるため、ノードの設定項目に記載される値が存在しない場合は、設定項目自体を記載せず省略している。例えば、図10(a)のパラメタツリー（PT1）において、ノードIDが002のノードについては、設定すべき意味情報と入出力情報の値が存在しないので、設定項目から意味情報と入出力情報を省略して記載されている。
【０１３３】
続いて、コード生成部11は、S203で作成したパラメタツリー（PT）を参照し、サービスAPIのパラメタツリー（PT）を構成するノードのうち、入出力情報が設定されているノードに対して、クライアントAPIのパラメタツリー（PT）を構成するノードを対応付け、パラメタのマッピングを行い、パラメタマップテーブル（MT）を作成する（S204）。なお、パラメタのマッピング方法の詳細については、図13を参照して後述する。
【０１３４】
上記パラメタ間の対応関係は、各ノードに設定されている「型」、「意味情報」、及び「入出力情報」に基づいて決定される。そして、コード生成部11は、その対応関係を図12に示すパラメタマップテーブル（MT）に登録する。
【０１３５】
パラメタマップテーブル（MT）は、関数毎に1つずつ作成される。例えばパラメタマップテーブル（MT1、図12(a)）には、クライアントAPIの「getData」関数とサービスAPIの「read」関数の対応関係が登録され、パラメタマップテーブル（MT2、図12(b)）には、クライアントAPIの「gotData」関数とサービスAPIの「received」関数の対応関係が登録される。
【０１３６】
パラメタマップテーブル（MT）は、サービスAPIパラメタID、クライアントAPIパラメタID、及び固定変数から構成されており、対応するパラメタツリー（PT）におけるノードのノードIDが、パラメタマップテーブル（MT）の同一エントリ内のサービスAPIパラメタID及びクライアントAPIパラメタIDとして設定される。
【０１３７】
例えば、サービスAPIの「read」関数のパラメタツリー（PT3、図11(a)）における、ノードIDが002のノードは、センサ30の内部センサの種類を表現するパラメタであるが、これはクライアントAPIの「getData」関数のパラメタツリー（PT1、図10(a)）における、ノードIDが003のノードに対応する。従って、図12(a)に図示したパラメタマップテーブル（MT）では、サービスAPIパラメタIDが002であるエントリのクライアントAPIパラメタIDは003となる。
【０１３８】
また、サービスAPIのパラメタに対応するクライアントAPIのパラメタが存在しない場合において、そのサービスAPIのパラメタに値を渡す必要があるときは、本処理（S204）によって、クライアントAPI定義22b（図6）において固定変数（「fixparams」要素以下の部分を参照）として指定されたパラメタがパラメタマップテーブル（MT）の固定変数として登録されるように構成すればよい。これにより、後述のコード生成処理（S205）において、クライアントAPI定義22bに記載された固定変数をサービスAPIの関数のパラメタとして与えるためのアダプタコードが生成される。
【０１３９】
また、構成情報13内の機器属性13bに指定されている属性パラメタがサービスAPI27の関数のパラメタとして与えられるようにする場合は、そのサービスAPI27の関数のパラメタと当該属性パラメタを対応付け、両者が対応付けられていることを表すために、そのサービスAPI27の関数のパラメタに関するパラメタマップテーブル（MT）内のエントリに固定変数として「＠devAttr」が記載される。これにより、コード生成部11は、アダプタの実行時にセンサ30へアクセスするための情報（上記構成情報13内の属性パラメタ）をプログラム実行部50が取得するようにアダプタを生成する。
【０１４０】
例えば、アプリケーションロジック24がクライアントAPI25を介してサービスAPI27にアクセスするためには、サービスAPI27の関数のパラメタに対し、ネットワーク上に存在する制御対象のセンサ20を特定するための属性パラメタ（例えば、IPアドレスやポート番号など）を引数として渡す必要がある場合がある。この場合、クライアントAPI定義22bに上記属性パラメタを予め指定しておくことで対応することも可能であるが、センサ30が交換された場合などにおいてIPアドレス等の属性が変更すると、各クライアント装置（コントローラ20など）内に存在するクライアントAPI定義22bをそれぞれ書き換える必要が生じ、極めて煩雑となる。そこで、本実施例のように、機器の属性パラメタは、クライアントAPI定義22b内ではなく、管理サーバ10内で一元的に管理される構成にしておけば、センサ30の属性が変更しても、管理サーバ10内に存在する属性パラメタだけを更新すればよく、対応が容易である。
【０１４１】
本実施例では、パラメタマップテーブル（MT）のエントリ内に固定変数として「＠devAttr」が記載されることにより、コード生成処理（S205）において、センサ30の機器属性の値パラメタを取得するための「findDevAttr」関数を呼び出すコードが生成される。そして、コントローラ20のプログラム実行部50は、この「findDevAttr」関数を実行することにより、管理サーバ10から機器属性の値パラメタを取得し、サービスAPI27の関数のパラメタに対して引数として渡すことができる。
【０１４２】
例えば、サービスAPIの「read」関数とクライアントAPIの「getData」関数の各パラメタについて本処理（S204）を実行した場合、図12に示すパラメタマップテーブル（MT1）が作成される。
【０１４３】
続いてコード生成部11は、クライアントAPIのパラメタツリー（PT）を構成するノードの一覧をチェックし、入出力情報を持つクライアントAPIのパラメタのノードうち、パラメタマップテーブル（MT）にノードIDが登録されていないノードをチェックし、そのノードのノードIDをパラメタマップテーブル（MT）のクライアントAPIパラメタIDに登録する(S205)。例えば、パラメタツリー（PT1）の場合、この時点でノードIDが001のノードはパラメタマップテーブル（PT）に登録されていないので、コード生成部11は、パラメタマップテーブル（PT）に新規エントリを作成し、クライアントAPIパラメタIDに上記ノードID（001）を登録する。
【０１４４】
その登録の際に、コード生成部11は、パラメタツリー（PT）のノードに記載された意味情報を参照し、意味情報に「@devID」の記載があれば、対応するパラメタマップテーブル（MT）の固定変数として「@devID」と記載する。パラメタツリー（PT1、図10(a)）の例では、上記の登録したノード（ノードID=001）の意味情報が「@devID」であることから、パラメタマップテーブル（MT1、図12(a)）の対応するエントリの固定変数に「@devID」が登録されている。
【０１４５】
続いてコード生成部11は、S203で作成したパラメタツリー（PT）と、S204及びS205で作成したパラメタマップテーブル（MT）に基づき、アダプタ26のソースコードを生成する（S206）。ソースコードの具体的な生成方法については、図14〜17を参照して後述する。
【０１４６】
次に、コード生成部11は、サービスAPIのすべての関数に対してアダプタコードの生成が完了したかどうかをチェックし（S207）、アダプタコードが生成されていない関数がある場合は、上記処理（S201〜S207）を繰り返す。
【０１４７】
一方、コード生成部11は、サービスAPIのすべての関数について、アダプタ26のソースコードの生成処理（S206）が完了すると、クライアントAPIを構成する関数のうち、まだアダプタ26のソースコードを作成していない関数を1つ選択する（S208）。
【０１４８】
続いてコード生成部11は、パラメタツリー（PT）を参照し、関数の引数の型情報を確認し、これに基づきダミー関数のソースコードを生成する（S209）。ダミー関数とは、処理を一切行わない関数である。クライアントAPIの関数のうち対応するサービスAPIの関数が存在する関数、具体的にはサービスAPIの関数と同じ意味情報を持つクライアントAPIの関数については、S202〜S206の処理でアダプタ26のソースコードが作成されている。従って、ここで取り扱うクライアントAPIの関数には、対応するサービスAPIの関数が存在しないため、S209で生成されるクライアントAPIの関数に関するソースコードは、処理を一切行わないダミー関数となる。
【０１４９】
コード生成部11は、上記ダミー関数の生成を行うと、ダミー関数の生成対象となるクライアントAPIの関数のすべてについて、ダミー関数の生成（S209）が完了したかどうかをチェックし（S210）、完了していなければ完了するまで上記処理（S208，S209）を繰り返す。一方、ダミー関数の生成が完了すると、コード生成部11は、このアダプタコード生成処理（図3のS106）を終了する。
【０１５０】
以上がアダプタコード生成処理の手順である。上記説明した手順では、クライアントAPIの関数のうち対応するサービスAPIの関数が存在しない関数については、ダミー関数として扱い、アダプタ26のダミーコードを生成するように構成されているが、このようなクライアントAPIの関数が存在する場合は、処理を中断し、ユーザに対してエラーを通知し、処理の中止とダミーコードの生成をユーザに選択させる構成としてもよい。
【０１５１】
続いて、図9のS204におけるサービス-クライアントパラメタマッピング処理の詳細を、図13を参照しつつ詳細に説明する。サービスAPIとクライアントAPIのパラメタが合致する度合いを評価するため、コード生成部11は、パラメタの合致数を示す合致数カウンタと、パラメタの非合致数を示す非合致数カウンタを内部に保持している。以下の処理を開始する前に、コード生成部11は、上記合致数カウンタと非合致数カウンタを0に初期化しておく。
【０１５２】
コード生成部11は、サービスAPIの関数のパラメタツリー（PT）から入出力情報を持つノードを1つ選択し（S301）、以下で説明する手順でマッピング処理を行う。すべてのノードに対して処理が完了すると、S322の処理へ進む（S302）。
【０１５３】
コード生成部11は、「arraycount」型を持つパラメタのマッピング処理は後でまとめて行うため、S301で選択したノードの型が「arraycount」である場合、以下の処理は行わずにS301の処理に戻る（S303）。尚、以下では型が「arraycount」であるノードを配列要素数ノード、型が配列であるノードを配列ノードと呼ぶ。
【０１５４】
コード生成部11は、構成情報13内の機器属性13bを参照し、S104（図3）でコントローラ20から受信した機器ID22aに対応する機器属性13bを取得する。コード生成部11は、取得した機器属性13bの中から、S301で選択したノードの意味情報と合致する意味情報を持つ属性パラメタを検索する（S304）。
【０１５５】
図7の例では、機器属性13bとして、「（意味情報、型、属性値）＝（devAddr、String、192.168.0.3）」という属性パラメタが1つ設定されている（「device」要素以下の情報）。この例では、設定されている属性パラメタは1つであるが、複数の属性パラメタが設定されている場合もある。そして、S301でパラメタツリー（PT3）内のノードIDが001のノードを選択した場合、このノードの意味情報「devAddr」と上記属性パラメタに記載された意味情報が合致するため、「（意味情報、型、属性値）＝（devAddr、String、192.168.0.3）」という属性パラメタが検索結果として取得される。
【０１５６】
S304で意味情報が合致する属性パラメタが見つかった場合、コード生成部11は、合致数カウンタをインクリメントし（S311）、パラメタマップテーブル（MT）のサービスAPIパラメタIDへS301で選択したノードのノードID（ここでは、001）を登録し、パラメタマップテーブル（MT）の固定変数へ「@devAttr」を登録する（S312）。
【０１５７】
S304で所定の属性パラメタが見つからない場合、コード生成部11は、クライアントAPIのパラメタツリー（PT）を検索し、意味情報と入出力情報がS301で選択したノードと合致するノードを検索する（S306）。
【０１５８】
例えば、コード生成部11が、S301でパラメタツリー（PT3）内のノードIDが002のノードを選択した場合、パラメタツリー（PT1）から、ノードIDが003のノードを選択することになる。これらのノードは設定項目として「（意味情報、入出力情報）=（devCntl/devType、in）」を共通に持つ。
【０１５９】
S306で、意味情報と入出力情報が合致する、クライアントAPIのパラメタツリー上のノードが見つかった場合、コード生成部11は、合致数カウンタをインクリメントし（S311）、パラメタマップテーブル（MT）のサービスAPIパラメタIDへS301で選択したノードのノードIDを登録し、パラメタマップテーブル（MT）のクライアントAPIパラメタIDへS306で取得したクライアントAPIのパラメタツリーPT上のノードのノードIDを登録する（S312）。
【０１６０】
S306で所定のノードが見つからない場合、コード生成部11は、S104でコントローラ20から受信したクライアントAPI定義22bを参照し、クライアントAPI定義22bに記載された固定変数の中から、意味情報がS301で選択したノードと合致する固定変数を検索する（S308）。
【０１６１】
例えば、コード生成部11が、S301でパラメタツリー（PT3）内のノードIDが005のノードを選択した場合、意味情報「devCntl/password」を持つ固定変数を、クライアントAPI定義22bから検索する。結果として、「（意味情報、型、変数値）=（devCntl/password, String, hogehoge）」という属性パラメタを持つ固定変数が取得される。
【０１６２】
S308で、意味情報が合致する固定変数が見つかった場合、コード生成部11は、合致数カウンタをインクリメントし（S311）、パラメタマップテーブル（MT）のサービスAPIパラメタIDへS301で選択したノードのノードIDを登録し、パラメタマップテーブル（MT）の固定変数へS308で取得した固定変数の型と変数値を、「型：変数値」というフォーマットで登録する（S312）。例えば、「（型、変数値）=（String、hogehoge）」の場合は、「String：hogehoge」が登録される。
【０１６３】
S308で所定のノードが見つからない場合、対応するパラメタが見つからないため、コード生成部11は、非合致数カウンタをインクリメントし（S310）、S301の処理へ戻る。
【０１６４】
S312の処理が終了すると、コード生成部11は、S301で選択したノードからルートノード（params）方向に辿りながらノードを検査し、途中に配列ノードが存在するかどうかを確認する（S313）。そのようなノードが存在すれば、S314の処理に進み、そのノードに対応する配列要素数ノードに関するマッピング処理を行う。例えば、コード生成部11は、S301でパラメタツリー（PT3）内のノードIDが002のノードを選択した場合、選択したノードの型が「short[]」で表現されており、これは配列を表しているため、S314の処理へ進む。
【０１６５】
コード生成部11は、S313で配列ノードが見つかったら、S301で選択したノードとルートノード間に存在する配列ノードを列挙し、各配列ノードについて、パラメタツリー（PT）の「配列要素」の関係を逆に辿り、各配列ノードに関係付けられる配列要素数ノードのリストを作成する（S314）。コード生成部11は、配列要素数ノードのリスト内のノードの順序を、S301で選択したノードとルートノード間に存在する配列ノードの出現順序と合致させる。
【０１６６】
尚、機器属性13bとクライアントAPI定義22bの固定変数に記載するパラメタには配列が記載されることはないため、本処理（S314）の実行時には、必然的にS306の処理でサービスAPIのノードにマッピングすべきクライアントAPIのノードが見つかっていること（S307の判断がY）になる。
【０１６７】
また、コード生成部11は、S306で取得したノード（サービスAPIのノードにマッピングされるクライアントAPIのノード）に対しても上記と同様の処理を行い、ルートノードと上記ノード間に存在する配列ノードを列挙し、各ノードに関係付けられる配列要素数ノードのリストを作成する（S314）。この処理でも、コード生成部11は、作成する配列要素数のリスト内のノードの順序を、S306で取得したノードとルートノード間に存在する配列ノードの出現順序と合致させる。
【０１６８】
コード生成部11は、上記のようにして作成した、サービスAPIの配列要素数ノードのリストと、クライアントAPIの配列要素数ノードのリストの各要素を、リストの順序どおりに対応づけることで、配列要素数ノードのマッピングを行う。
【０１６９】
例えば、S301でパラメタツリー（PT3）内のノードIDが002のノードを選択した場合、そのノードとルートノードの間に存在する、型が配列のノードは上記ノード（ノードID=002）のみである。そのノードと配列要素の関係になっているノードは、ノードIDが004のノードであるので、作成されるサービスAPIの配列要素数ノードのリストは、「[ノードID]=[004]」となる。S301で選択したノードにマッピングされるクライアントAPIのノードは、パラメタツリー（PT1）内のノードIDが003のノードである。このノードとルートノードとの間に存在する配列ノードは、ノードIDが002のノードであるので、作成されるクライアントAPIの配列要素数ノードのリストは「[ノードID]=[005]」となる。
【０１７０】
次にコード生成部11は、S314で作成したサービスAPIの配列要素数ノードのリストの先頭と、クライアントAPIの配列要素数ノードのリストの先頭から、ノードIDを1つずつ取り出す（S315）。尚、コード生成部11は、取り出したノードIDを上記リストから削除する。
【０１７１】
コード生成部11は、S315で取り出したノードIDのいずれかが、既にパラメタマップテーブル（MT）に登録されているかどうか確認する。つまり、S315でサービスAPIの配列要素数ノードのリストから取り出したノードIDが、パラメタマップテーブル（MT）のサービスAPIパラメタIDに既に存在するかどうかの確認と、S315でクライアントAPIの配列要素数ノードのリストから取り出したノードIDが、パラメタマップテーブル（MT）のクライアントAPIパラメタIDに既に存在するかどうかの確認を行う（S316）。コード生成部11は、そのいずれかが確認できれば、パラメタマップテーブル（MT）の整合性チェックを行うため、S317へ進む。そうでなければ、パラメタマップテーブル（MT）への登録を行うためS319へ進む。
【０１７２】
S315で取り出した、2つのノードIDの少なくともいずれか一方がパラメタマップテーブル（MT）に含まれていれば、コード生成部11は、2つのノードIDがパラメタマップテーブル（MT）の同一エントリに登録されていることを確認する（S317）。コード生成部11は、この条件が満たされているかどうかを確認し（S318）、整合性が確認できれば、S321の処理へ進み、この条件以外の状態になっている場合、パラメタマップテーブル（MT）の整合性に矛盾が発生するため、エラー終了とする。
【０１７３】
コード生成部11は、S315で取り出した、2つのノードIDの両方がパラメタマップテーブル（MT）に含まれていなければ、合致数カウンタをインクリメントする（S319）。
【０１７４】
そして、コード生成部11は、パラメタマップテーブル（MT）において新規エントリを作成し、S315でサービスAPIの配列要素数ノードのリストから取り出したノードIDを、新規エントリのサービスAPIパラメタIDとして登録し、S315でクライアントAPIの配列要素数ノードのリストから取り出したノードIDを、新規エントリのクライアントAPIパラメタIDとして登録する（S320）。
【０１７５】
コード生成部11は、S314で作成した配列要素数ノードのリストに含まれるすべてのノードについて処理が完了すると、S301へ戻り、そうでなければ、S315へ戻りノードのマッピング処理（S315〜S320）を続ける（S321）。
【０１７６】
サービスAPIの関数のパラメタツリー（PT）を構成する入出力情報を持つノードすべてに対して、マッピング処理が完了すると、コード生成部11は、下記数式を用いて合致率を算出する。
【０１７７】
合致率=(合致数カウンタ）/((合致数カウンタ)＋(非合致数カウンタ)))
コード生成部11は、合致率が規定値未満であれば、クライアントAPIとサービスAPIのパラメタの類似度が低いため、パラメタマッピング処理をエラー終了とし、合致率が規定値以上であれば、正常に終了する（S322）。
【０１７８】
続いて、図9のS206におけるコード生成処理の詳細を、図14〜17を用いて説明する。S206の処理を開始する時点で、アダプタ生成対象であるサービスAPIの関数とクライアントAPIの関数の組が決定しており（S201、S202参照）、対応するパラメタツリー（PT。S203参照）と、対応するパラメタマップテーブル（MT。S204、S205参照）の作成が完了している。本処理では、これらの情報に基づいて、アダプタ26のソースコードを生成する。本処理のフローを図14及び図15に、作成されるアダプタ26のソースコードの例を図16、図17に示す。
【０１７９】
まず、コード生成部11は、S201で選択したサービスAPIの関数がコールバック関数であるかどうかを確認する（S401）。
【０１８０】
S401で確認した結果がコールバック関数でない場合、生成されるアダプタ26のソースコードは、クライアントAPIの関数を外部インターフェイスとして持ち、内部でサービスAPIの関数を呼び出すものになる。以下、アダプタ生成対象の関数が、サービスAPIの「read」関数とクライアントAPIの「getData」関数である場合を例に挙げて具体的に説明する。この例で生成されるアダプタのソースコードを図16に示す。
【０１８１】
コード生成部11は、関数を初期化するためのソースコードを生成する（S402）。
【０１８２】
まず、コード生成部11は、S202（図9）で決定したクライアントAPIのクラス名から、クライアントAPIの「getData」関数をメソッドとして持つクライアントAPIのクラス定義と、コンストラクタを作成（図16の1行目〜6行目）する。尚、クラス定義とコンストラクタを既に作成済みの場合は、コード生成部11は、それらの作成を省略することができる。
【０１８３】
そして、コード生成部11は、クライアントAPIのパラメタツリー（PT1）の第一階層を構成するノードに基づいて、関数の引数と戻り値の型情報を決定する。そして、その情報とS202（図9）で決定したクライアントAPIの関数名に基づき、関数の型定義（図16の7行目）を作成する。図16の例では、n番目の引数の変数名をpnとしている。また、コード生成部11は、上記戻り値を関数のローカル変数(r)として宣言するソースコード（図16の8行目）を作成する。
【０１８４】
続いてコード生成部11は、サービスAPIのパラメタツリー（PT3）の第一階層を構成するノードに基づいて、サービスAPIの引数と戻り値の型情報を決定し、これらをローカル変数として宣言するソースコード（図16の9行目〜15行目）を作成する。図16の例ではn番目の引数の変数名をqnとし、戻り値に対応するローカル変数の変数名のインデックス番号を最終番号（図ではq7）としている。
【０１８５】
次にコード生成部11は、機器属性値を取得するためのソースコードを生成する（S403）。
【０１８６】
まずコード生成部11は、パラメタマップテーブル（MT1）から、固定変数が「@devAttr」であるエントリを検索する。そのようなエントリが存在すれば、サービスAPIのパラメタツリー（PT3）から上記エントリのサービスAPIパラメタIDをノードIDに持つノードを検索し、そのノードの意味情報（意味情報1）を取得する。また、コード生成部11は、上記ノードに対応するローカル変数（ローカル変数1）を取得する。さらにコード生成部11は、クライアントAPIのパラメタツリー（PT1）を構成するノードから意味情報が「@devID」であるノードを検索し、そのノードに対応するローカル変数（ローカル変数2）を取得する。
【０１８７】
そしてコード生成部11は、アダプタ自動生成フレームワークの内部関数である「findDevAttr」を呼び出すためのコード（図16の17行目）を生成する。この「findDevAttr」関数は、機器IDと機器属性の意味情報パラメタに基づいて、これらに対応する機器の機器属性の値パラメタを求める処理を行う。「findDevAttr」関数の第1引数は機器ID、第2引数は機器属性の意味情報パラメタ、戻り値は機器属性の値パラメタである。従って、コード生成部11は、「findDevAttr」関数の第1引数に上の検索処理で取得したローカル変数2が代入され、第2引数に意味情報1が代入され、関数の戻り値がローカル変数1に代入されるソースコードを生成する。
【０１８８】
コントローラ20のプログラム実行部50は、「findDevAttr」関数が呼び出されると、指定された機器IDと意味情報を用いて、これらに対応する機器属性の値パラメタを管理サーバ10に問い合わる。管理サーバ10がその問い合わせを受信すると、構成管理部12は、受信した機器IDをキーとして構成情報13を検索し、その機器IDに対応する一又は複数の機器属性13bを取得する。そして構成管理部12は、受信した意味情報をキーとして上記機器属性13bを検索し、その意味情報に対応する機器属性パラメタの属性値を取得する。そして構成管理部12は、コントローラ20にその属性値を返信し、「findDevAttr」関数は、管理サーバ10から受信した属性値を戻り値として返す。
【０１８９】
「findDevAttr」関数は、本実施例で説明しているアダプタ自動生成フレームワーク自体が提供する関数であり、アダプタ26の実行時にアダプタ26と静的リンクもしくは動的リンクされる。別の実施形態として、「findDevAttr」関数は、S108（図3）で管理サーバ10からコントローラ20へ配信され、センサ制御モジュール13dもしくはアダプタ26と静的リンクされる形態や、あらかじめコントローラ20内にライブラリとして保存され、アダプタ26の実行時にアダプタ26と動的リンクされる形態などが採用可能である。
【０１９０】
このように、「findDevAttr」関数が、アダプタ26の実行時に呼び出され、機器の属性パラメタをチェックする構成とすることで、機器の各種設定（アドレス、ポート番号など）に変更があった場合においても、アプリケーションロジック24を変更する必要がない。
【０１９１】
図16に示した例では、機器IDはクライアントAPIの関数の引数となっており、機器属性の値パラメタはサービスAPIの関数の引数となっている。これとは異なり、関数の引数に機器IDや機器属性の値パラメタを直接代入するのではなく、機器IDや機器属性の値パラメタを代入した構造体のメンバを関数の引数とするAPI仕様であっても対応可能である。
【０１９２】
またサービスAPIのパラメタツリー（PT3）を構成するノード内に、意味情報が「@devAttr」であるノードが複数存在する場合にも対応可能である。この場合、意味情報が「@devAttr」である各ノードに対して、「findDevAttr」関数が実行されることになる。
【０１９３】
続いてコード生成部11は、入力変数を変換するためのソースコードの生成処理を行う（S404）。
【０１９４】
具体的には、コード生成部11は、S402においてサービスAPIの関数の引数として作成したローカル変数のうち、S403において値が代入されていないものに値が代入されるソースコード（図16の18行目〜27行目）を作成する。コード生成部11は、ノード情報としてサービスAPIのパラメタツリー（PT3）のルートノードを指定し、入出力情報として「in」を指定して、図15に示す変数変換用サブルーチンを呼び出すことで本処理を実現する。上記サブルーチンの内部処理の詳細は後述する。
【０１９５】
コード生成部11は、S403、S404においてサービスAPIの関数のすべての引数に値を設定した後、サービスAPIの関数を呼び出すためのソースコード（図16の28行目）を作成する（S405）。上記サービスAPIの関数が呼び出されると、その戻り値は、S402でサービスAPIの関数の戻り値として作成されたローカル変数に代入される。
【０１９６】
次にコード生成部11は、出力変数を変換するためのソースコードの生成処理を行う（S406）。具体的には、コード生成部11は、クライアントAPIの関数の引数及び戻り値を保持する変数に対して、サービスAPIの実行結果が代入されるソースコード（図16の29行目）を作成する。コード生成部11は、ノード情報としてクライアントAPIのパラメタツリー（PT1）のルートノードを指定し、入出力情報として「out」を指定して、図15に示す変数変換用サブルーチンを呼び出すことでこの処理を実現する。上記サブルーチンの内部処理の詳細は後述する。
【０１９７】
最後にコード生成部11は、戻り値を返し、関数を終了するためのソースコード（図16の30〜31行目）を作成する（S407）。以上で、クライアントAPIの「getData」関数のソースコードが完成する。
【０１９８】
一方、S401で確認した結果がコールバック関数の場合、生成されるアダプタ26のソースコードは、サービスAPIの関数を外部インターフェイスとして持ち、内部でクライアントAPIの関数を呼び出すものになる。このようにサービスAPIの関数がコールバック関数の場合は、生成されるアダプタ26のソースコードにおいて、サービスAPIとクライアントAPIの呼び出し関係が通常の関数の場合とは逆になるが、この点を除くと、アダプタ26のソースコード生成処理は上で説明したS402〜S407の処理と同様である。以下、S408〜S412の処理については、S402〜S407の処理との相違点に着目して説明する。
【０１９９】
以下、アダプタ生成対象の関数が、サービスAPIの「received」関数とクライアントAPIの「gotData」関数である場合を例に挙げて具体的に説明する。この例で生成されるアダプタ26のソースコードを図17に示す。
【０２００】
コード生成部11は、S402と同様の手順で、サービスAPIのクラス定義と、コンストラクタを作成し、関数を初期化するためのソースコードを生成する（S408）。
【０２０１】
作成されるコンストラクタは、クライアントAPIのコールバックオブジェクトを引数にとり、コールバックオブジェクトを内部に保持する処理（図17の3行目〜5行目）を行うものとする。
【０２０２】
さらにコード生成部11は、サービスAPIのパラメタツリー（PT4）に基づき、関数の引数と戻り値を決定し、関数の型定義（図17の7行目）を作成する。また、コード生成部11は、クライアントAPIのパラメタツリー（PT2）に基づき、クライアントAPIの「gotData」関数の引数と戻り値をローカル変数として宣言するためのソースコード（図17の8行目〜9行目）を作成する。
【０２０３】
続いてコード生成部11は、入力変数を変換するためのソースコードの生成処理を行う（S409）。具体的には、コード生成部11は、S408において、クライアントAPIの「gotData」関数の引数として作成したローカル変数に対して、値が代入されるソースコード（図17の10行目〜16行目）を作成する。この処理は、クライアントAPIとサービスAPIの役割が逆になる点を除けばS404の処理と同様である。
【０２０４】
次に、コード生成部11は、クライアントAPIの関数を呼び出すためのソースコード（図17の17行目）を作成する（S410）。その関数の戻り値は、S408でクライアントAPIの関数の戻り値として作成されたローカル変数に代入される。但し、クライアントAPIの「gotData」関数のように、クライアントAPIの関数が戻り値を返さない関数の場合は、戻り値の代入処理を行うためのソースコードは作成する必要がない。
【０２０５】
そして、コード生成部11は、出力変数を変換するためのソースコードの生成処理を行う（S411）。具体的には、コード生成部11は、サービスAPIの関数の引数及び戻り値を保持する変数に対して、クライアントAPIの実行結果を代入するためのソースコードを作成する。この処理は、クライアントAPIとサービスAPIの役割が逆になる点を除けばS404の処理と同様である。但し、サービスAPIのパラメタツリー（PT4）には、入出力型が「out」であるノードは存在しないので、図17の例では、そのようなノードに対応するソースコードが作成されていない。
【０２０６】
最後にコード生成部11は、戻り値を返し、関数を終了するためのソースコード（図17の18行目）を作成する（S412）。以上で、サービスAPIの「received」関数のソースコードが完成する。
【０２０７】
次に、図14のS404、S406、S409、S411において実行される変数変換用サブルーチンの処理手順の詳細を、図15を参照して説明する。なお、上記の各ステップ（S404、S406、S409、S411）における処理内容は同様であるため、以下ではS404において、クライアントAPIの「getData」関数を作成する場合を例に挙げて説明する。
【０２０８】
S404では、コード生成部11は、ルートノード情報としてサービスAPIのパラメタツリー（PT3）のルートノードを指定し、入出力情報として「in」を指定して、図15に示す変数変換用サブルーチンを呼び出す。
【０２０９】
まず、コード生成部11は、指定されたルートノードの下位ノードのうちで、入出力情報が「in」であるものを列挙し、その中から1つを選択する（S501）。この例では、パラメタツリー（PT3）から、「ノードID=｛001、002、003、004、005、006｝」の各ノードが選択対象となる。
【０２１０】
コード生成部11は、S501で選択したノードに対応する変数に対して、以下に説明する手順で値を代入するためのソースコードを作成していく。すべてのノードに対する処理が完了すると、本処理を終了する（S502）。
【０２１１】
コード生成部11は、S501で選択したノードの型をチェックし、型が「arraycount」であれば、以下の処理を行わずS501の処理へ戻る。また、コード生成部11は、そのノードに対応するパラメタへの値の代入処理が既に完了している場合も、以下の処理を行わずS501の処理へ戻る。具体的には、S403で機器属性に対応するパラメタへの値の代入は完了しているので、コード生成部11は、機器属性に対応するパラメタへの値の代入処理を規定するソースコードは作成しない（S503）。
【０２１２】
以下の説明では、S501でパラメタツリー（PT3）からノードIDが002のノードを選択したものとする。S501で選択したノードをルートノード方向へ辿り、途中に配列が存在するかどうかをチェックする。途中に配列ノードが存在すれば、S505〜S507で、その配列についてのループ処理を行う。そうでない場合は、S508へ進みパラメタへの値の代入処理を行う（S504）。
【０２１３】
コード生成部11は、S501で選択したノードをルートノード方向へ辿り、途中に存在する配列ノードを列挙する。そして、それら配列ノードに対応する配列要素数ノードをピックアップし、配列要素数ノードに対応するパラメタへの値の代入処理を行うためのソースコードを以下の手順で作成する。
【０２１４】
コード生成部11は、上記ピックアップしたパラメタの代入元のパラメタを、パラメタマップテーブル（MT）から決定する。各パラメタへのアクセス方法は、サービスAPI及びクライアントAPIのパラメタツリー（PT）から決定する。パラメタツリー（PT）とソースコード上の変数との対応関係は、クライアントAPIのn番目の引数名がpn、サービスAPIのn番目の引数名がqnと表現されていることを利用して決定される。これらの情報に基づき、コード生成部11は、配列要素数ノードに対応するパラメタへの値の代入処理を行うためのソースコードを作成する。
【０２１５】
例えば、S501でパラメタツリー（PT3）からノードIDが002のノードを選択した場合、途中に存在する配列ノードはノードIDが002のノードのみであり、それに対応する配列要素数ノードはノードIDが004のノードである。パラメタマップテーブル（MT1）を参照すると、サービスAPIパラメタのIDが004のエントリに対応するクライアントAPIパラメタIDは005であることが分かる。従って、コード生成部11は、クライアントAPIのパラメタツリー（PT1）のノードIDが005に対応するパラメタから、サービスAPIのパラメタツリー（PT3）のノードIDが004に対応するパラメタへ値を代入するためのソースコードを作成する。この例の場合、コード生成部11によって、図16の18行目に示したソースコードが作成されることになる（S505）。
【０２１６】
次にコード生成部11は、S505で列挙したサービスAPIの配列の初期化を行う。この例の場合は、サービスAPIのパラメタツリー（PT3）でノードIDが002のノードに対応する配列パラメタを初期化するためのソースコード（図16の19行目）が作成される（S506）。
【０２１７】
そしてコード生成部11は、配列パラメタにアクセスするためのインデックス変数についてループを作成する。ループ内ではS501で選択したパラメタへアクセスするためのソースコードが作成されるが、そのとき、コード生成部11が必ず上記インデックス変数を使用して配列パラメタにアクセスすることに留意する（S507）。
【０２１８】
コード生成部11は、変数を変換するためのソースコード、すなわちS501で選択したパラメタへの値の代入処理を行うためのソースコードの作成処理を行う（S508）。本処理においても、S505と同様に、パラメタマップテーブル（MT）から、S501で選択したパラメタにマッピングされるクライアントAPIのパラメタ（もしくはサービスAPIのパラメタ）を取得し、サービスAPI及びクライアントAPIのパラメタツリー（PT）から各変数へのアクセス方法を決定し、対応するソースコードが作成される。
【０２１９】
この例の場合、S501でサービスAPIのパラメタツリー（PT3）からノードIDが002のノードが選択されているので、パラメタマップテーブル（MT1）を参照すると、対応するクライアントAPIのパラメタは、ノードIDが003のノードに関するパラメタであることが分かる。従って、これらのパラメタ間で値を代入するためのソースコードが作成されることになり、その結果として図16の21行目に示したソースコードが作成される（ここまでがS508）。
【０２２０】
コード生成部11は、S505〜S507で配列にアクセスするためのループを作成した場合（S509の判断がYの場合）は、そのループを閉じる処理を行うためのソースコード（図16の22行目）を作成する（S510）。
【０２２１】
以上、S501でパラメタツリー（PT3）からノードIDが002のノードが選択された場合について具体例を挙げて説明したが、S501で別のノードIDのノードが選択された場合についても、上記と同様の手順でソースコード（図16の23行目〜27行目）が作成される。
【０２２２】
以上、本発明の実施例1を説明したが、本発明の実施形態の例はこれに限られない。以下、本発明の別の実施形態としての実施例2を説明する。
【実施例２】
【０２２３】
実施例2では、本発明を適用した、建物の各部屋の温度と湿度を監視するシステム（図18）において、各センサ30がセンサごとの識別子ではなく、各センサ30の属性によって指定される場合について説明する。例えば、建物の各部屋の温度と湿度を監視するシステムでは、センサ30の属性としての位置情報（フロア名、部屋番号など）と測定項目（温度、湿度など）に基づき、駆動すべきセンサを決定する機能が必要になる。
【０２２４】
そこで実施例2では、クライアントAPI25にセンサ30の属性情報が渡されることで、センサ30が指定される枠組みを提供する。このシステムでは、属性情報として位置情報と測定項目がクライアントAPI25に渡されることで、センサ30が指定されるようにすればよい。尚、本実施例3は実施例1と類似点が多いため、以下の説明では実施例1との相違点を中心に説明する。
【０２２５】
本実施例におけるシステム構成図を図18に示す。実施例1と比較すると、本実施例では、機器定義格納部51内の機器定義情報22に変更がある。すなわち実施例1における機器ID22aが属性ID22cに置き換わり、新しく属性条件22dが追加されている。
【０２２６】
プログラム実行部50が利用するセンサ30の属性が属性条件22dに記載され、各属性条件22dの識別子が属性ID22cに記載される。クライアントAPI25の引数には、属性ID22cが指定される。属性ID22cは、機器定義情報22に記載された属性条件22dを一意に識別するための識別子であるため、システムに存在する他のアプリケーションの機器定義情報に記載される属性IDと整合している必要は無く、コントローラ20内で統一されていれば良い。
【０２２７】
また、属性条件22dとして多数の項目が使用されることがあるため、クライアントAPI25の引数として属性条件22dが直接記載されると、アプリケーションロジック24のソースコードが肥大化するおそれがある。そこで、上記の説明のように、あらかじめ属性条件22dを特定する識別子としての属性ID22cを定義しておき、アプリケーションロジック24からは、属性ID22cが指定される形態としている。従って、クライアントAPI25には属性ID22cが渡される方式となるが、この方式は、クライアントAPI25に属性条件22dが直接渡される方式と本質的には同じである。尚、属性条件22dのバリエーションが少ない場合には、クライアントAPIに属性条件22dが直接渡される方式としてもよい。
【０２２８】
図19に、コントローラ20のプログラム実行部50が管理サーバ10からアダプタ26を取得し、プログラム格納部49に組み込み、アプリケーションロジック24とセンサ制御モジュール28にリンクさせる手順を示す。
【０２２９】
まず、所定のタイミング（CPUがアプリケーションロジック24を実行するタイミング）で、コントローラ20のCPUがアダプタ生成要求プログラム23を実行すると、コントローラ20のプログラム実行部50は、機器定義格納部51内の機器定義情報22から、属性条件22dとクライアントAPI定義22bを取得し、これらを管理サーバ10に送信する。コントローラ20のプログラム実行部50は、実施例1では、機器ID22aとクライアントAPI定義22bを送信（図3、S104）していたが、本手順では機器ID22aが属性条件22dに置き換えられている（S601）。
【０２３０】
管理サーバ10は、受信した属性条件22dに合致する一又は複数の機器属性13bを構成情報13内で検索し、最も合致率が高い機器属性13bに対応するセンサ制御モジュール13dを、プログラム実行部50が使用するセンサ制御用サービスモジュールとして、すなわちそのセンサ30を制御するためのアプリケーションロジック24の連携対象モジュールとして選択する。尚、管理サーバ10のコード生成部10は、所定の基準値以上の合致率を示す機器属性13bが見つからない場合は、プログラム実行部50が利用しようとしているセンサ30に関する情報が見つからないということであるため、処理をエラー終了してもよい（S602）。
【０２３１】
以降の処理（S603〜S607）の手順は、実施例1で説明した処理（図3のS106〜S110）の手順と同じあるため、説明を省略する。本実施例でも実施例1と同様に、あらかじめ「ブートストラップアダプタ」を実行プログラム23に組み込んでおくことで、センサ利用時にオンデマンドでアダプタ26が管理サーバからダウンロードされる構成とすることが可能である。
【０２３２】
また、コード生成部11が生成するアダプタ26のソースコードは、実施例1で説明したものとほぼ同一になるが、アダプタ自動生成フレームワークが提供する「findDevAttr」関数の処理手順は、実施例1と異なる部分がある。つまり、本実施例においては、「findDevAttr」関数の第1引数として、機器IDではなく、属性ID22cが指定される。「findDevAttr」関数は、第1引数として指定された属性ID22cをキーとして機器定義情報22内を検索し、対応する属性条件22dを取得し、その属性条件22dに合致するセンサの機器属性13bを管理サーバ10の構成情報13から取得するという処理を行う。
【０２３３】
属性条件22dとしては、位置情報、センサの種類など、様々な条件が指定され得る。また、属性条件22d（項目名と値の組み合わせ）の例としては、「位置情報=第1会議室」又は「センサの種類=湿度センサ」等のように、一つの項目に対して一つの値が指定される以外に、「位置情報=1階の全室」、「位置情報=192.168.0.3〜192.168.0.167」、又は「センサの種類=シリアルナンバーの頭文字が"B"又は"C"のセンサ」等のように、一つの項目に対して値の範囲が指定される例や、一つの項目に対して値のパターンが指定される例など、柔軟に条件が設定され得る。
【０２３４】
以上、本発明の実施例2を説明したが、次に、さらに別の実施形態としての実施例3を説明する。
【実施例３】
【０２３５】
本実施例では、SOA（Service Oriented Architecture）で構築した情報システムに本発明を適用する例を説明する。本実施例におけるシステム構成図を図20に示す。本実施例における情報システムは、実施例2のシステムにおけるコントローラ20がクライアント20bに置き換えられ、センサ30がサーバ40に置き換えられ、管理サーバ10がディレクトリサーバ10bに置き換えられた構成となっている。また、実施例2における機器定義格納部51がサービス定義格納部59に置き換えられ、機器定義情報22がサービス定義情報29に置き換えられている。尚、ディレクトリサーバ10b、クライアント20b、及びサーバ40としては、実施例1及び2と同様に、図2に示すような構成の一般的なコンピュータ100が採用され得る。
【０２３６】
本実施例では、プログラム格納部49内のアプリケーションロジック24がクライアントモジュールに相当し、サーバ40上で動作するサービスロジック42がサービスモジュールに相当する。この情報システムにおいては、アプリケーションロジック24とサービスロジック42の間で通信を行うソフトウェアとして、クライアント20b側のプログラム格納部49内にクライアントスタブ28が組み込まれ（リンクされ）、サーバ40側のプログラム格納部41内にはサーバスタブ44が組み込まれている。サーバ40のプログラム格納部41に格納されているサービスロジック42及びサーバスタブ44の機能は、サービス提供部60によって実現される。なお、サービス提供部60は、サーバ40のCPUがサービスロジック42及びサーバスタブ44を実行することにより機能的に実現される。
【０２３７】
クライアント20bのCPU101がクライアントスタブ28を実行すると、プログラム実行部50は、サービスAPI27の関数へ渡したパラメタを、ネットワーク上で送受する形式のメッセージに変換し、サーバ40へ届ける。サーバ40がクライアントスタブ28からメッセージを受信すると、サービス提供部60は、サービスロジック42が提供するサービスAPI43を呼び出す。クライアント20b内のクライアントスタブ28は、サーバ40内のサービスロジック42が提供するサービスAPI43と同一のサービスAPI27を外部インターフェイスとして提供するため、プログラム実行部50は、クライアントスタブ28をサービスロジック42であるかのように扱うことができる。
【０２３８】
本実施例では、実施例2（図18）におけるセンサ30がサーバ40に置き換られていることにより、ディレクトリサーバ10b上の構成情報13内に格納される情報が実施例2の場合と異なる。具体的には、機器ID13aがサービスID14aに、機器属性13bがサービス属性14bに、センサ制御モジュール13dがクライアントスタブ14dにそれぞれ置き換えられている。また、クライアント20b上のサービス定義格納部59においては、実施例2で用いた機器定義情報22がサービス定義情報29に置き換えられている。しかし、上記置き換えられた各構成のそれぞれの役割は実施例2と類似している。
【０２３９】
すなわち、サービス定義情報29内の属性条件29dに、利用したいサービス（例えば、サービスプログラム41が提供するサービス）の属性が記載されていれば、クライアント20bのプログラム実行部50は、所定のタイミングでアプリケーションロジック24を選択し、属性条件29d及び選択したアプリケーションロジック24に対応するクライアントAPI定義29bをディレクトリサーバ10bへ送信し、ディレクトリサーバ10bは、受信した属性条件29dに基づいて最適なサービス（ここでは、サービスプログラム41が提供するサービス）のサービスAPI定義14cとプログラム実行部50が選択したクライアントAPI定義29bとに基づいて、アダプタ26を自動生成する。アダプタ26の生成及び組み込みの手順は実施例1及び2で説明した手順と同様であるため、詳細な説明は省略する。
【０２４０】
以上、本発明の実施例形態を説明したが、本発明は上記3つの実施形態に限定されるわけではなく、発明の要旨の範囲内で数々の変形が可能である。
【０２４１】
例えば、コード生成部11は、必ずしも管理サーバ10やディレクトリサーバ10b上に構成される必要はなく、実施例1及び実施例2では、コントローラ20上に構成されても良い。また、実施例3では、コード生成部11がクライアント20bもしくはサーバ40上に構成されることも可能である。
【０２４２】
また、実施例1では、コード生成部11は、アダプタ26を生成する際に、サービスAPI定義13c及びクライアントAPI定義22bに記載されたパラメタの用途及び内容を表す意味情報に基づいて、APIのパラメタマッピングを行う（図9のS204、S205。詳細には図13のS304、S306、S308）が、サービスAPI定義13c及びクライアントAPI定義22bにそのような意味情報が付与されていないシステムにおいても、パラメタマッピングを行うことができる。この場合、コード生成部11は、パラメタの型情報に基づいて、パラメタマッピングを行うことができる。また別の例として、コード生成部11は、パラメタの用途及び内容を表す情報とパラメタの型情報とからなる二種類の意味情報の組み合わせに基づいて、パラメタマッピングを行うことができる。
【０２４３】
また本発明は、特定のプログラミング言語に適用されることは想定されておらず、任意のプログラミング言語に対して適用可能である。例えば、コード生成部11は、アダプタ26のソースコードを生成するが、そのソースコードのプログラミング言語は、アプリケーションロジック24（図1、図18）、センサ制御モジュール13d（図1、図18）及び、クライアントスタブ28（図20）の開発に使用されるプログラミング言語と異なっていてもよい。
【０２４４】
また、センサ制御モジュール13d（図1、図18）やクライアントスタブ28（図20）は、計算機上で実行可能なバイナリ形式で管理サーバ10及びディレクトリサーバ10bに保存されている必要は無く、その一部もしくはすべてがソースコードの状態であってもよい。この場合、コード生成部11がそのソースコードをコンパイルし、コントローラ20上で実行可能なセンサ制御モジュール28が生成される構成や、コントローラ20（図1、図18）若しくはクライアント20b（図20）上でコンパイルされて実行可能なクライアントスタブ28が生成される構成を採用すればよい。さらに、ソースコードのコンパイルは、コード生成部11からソースコードを受信したプログラム実行部50が行うように構成することもできる。
【０２４５】
さらに、前記実施例では、アダプタコード生成処理（図3のS106）において、関数同士の対応づけの際にはサービスAPI関数が先に選択され（図9のS201）、これに対応するクライアントAPI関数を決定する構成が採用され、パラメタ同士の対応づけの際にはサービスAPI関数パラメタが先に選択され（図13のS301）、これに対応するクライアントAPI関数パラメタを決定する構成が採用されていたが、選択する関数及びパラメタの順序を逆にしてもよい。
【０２４６】
すなわち、実施例1の構成を例にとり、関数の対応づけについて説明すると、アダプタを生成するステップ（図3のS106）では、コード生成部11は、
クライアント又はサービスの一方を「第１」と呼び、他方を「第２」と呼ぶものとした場合、
プログラム実行部50又は構成管理部12が選択した第１モジュールのAPIで用いられる第１API関数を選択するステップと、
上記選択した第１API関数に対応する第１API関数意味情報を取得し、この取得した第１API関数意味情報に整合する第２API関数意味情報を決定し、この決定した第２API関数意味情報に対応する、構成管理部12又はプログラム実行部50が選択した第２API関数を、上記選択した第１API関数の連携対象として選択するステップと、
プログラム実行部50及び構成管理部12がそれぞれ選択した第１API関数と第２API関数とに基づいて、上記選択した第１API関数と選択した第２API関数とを仲介するアダプタの部分を生成するステップと、
を実行する。
【０２４７】
上記の処理において、「第１」がサービスに相当し、「第１」がクライアントに相当する場合、アダプタコード生成処理（図3のS106）において、関数同士の対応づけの際にはクライアントAPI関数が先に選択され、これに対応するサービスAPI関数を決定する構成となる。
【０２４８】
また、関数の対応づけについて説明すると、アダプタを生成するステップ（図3のS106）では、コード生成部11は、
プログラム実行部50又は構成管理部12が選択した第１API関数のパラメタを選択するステップと、
上記選択した第１API関数パラメタに対応する第１API関数パラメタ意味情報を取得し、この取得した第１API関数パラメタ意味情報に整合する第２API関数パラメタ意味情報を決定し、この決定した第２API関数パラメタ意味情報に対応する、構成管理部12又はプログラム実行部50が選択した第２API関数のパラメタを、上記選択した第１API関数パラメタの連携対象として選択するステップと、
上記選択した第１API関数パラメタと、上記選択した第２API関数パラメタとを対応づけて、既に選択されている第１API関数と第２API関数とを仲介するアダプタの部分を生成するステップと、
を実行する。
【０２４９】
上記の処理において、「第１」がサービスに相当し、「第１」がクライアントに相当する場合、パラメタ同士の対応づけの際にはクライアントAPI関数パラメタが先に選択され、これに対応するサービスAPI関数パラメタを決定する構成となる。
【０２５０】
さらに、実施例では、外部ユニットの例として、センサ又はネットワーク上にある計算機内で動作するプログラムユニットについて説明したが、センサの他にも、他の装置（例えば、コントローラ20）からの要求に応じてデータを送信する機能を備えた任意の電子機器が採用され得る。
【図面の簡単な説明】
【０２５１】
【図１】実施例1のシステム構成図。
【図２】本発明における計算機の機能を実現するハードウェア構成図。
【図３】実施例1において、アダプタを生成し、コントローラに組み込む手順を示すフロー図。
【図４】実施例1における、サービスAPIのインターフェイスの一例を示す図。
【図５】実施例1における、クライアントAPIのインターフェイスの一例を示す図。
【図６】実施例1における、機器定義情報の一例を示す図。
【図７】実施例1における、構成情報の一例を示す図。
【図８】実施例1における、クライアントAPI定義及びサービスAPI定義の記述規則を示す図。
【図９】実施例1における、アダプタコード生成手順の詳細を示すフロー図。
【図１０】実施例1における、クライアントAPIのパラメタツリーの一例を示す図。
【図１１】実施例1における、サービスAPIのパラメタツリーの一例を示す図。
【図１２】実施例1における、パラメタマップテーブルの一例を示す図。
【図１３】実施例1における、パラメタマッピングの手順を示すフロー図。
【図１４】実施例1における、ソースコード生成手順の詳細を示すフロー図。
【図１５】実施例1における、変数変換ソースコード生成手順の詳細を示すフロー図。
【図１６】実施例1において、自動生成されたアダプタのソースコードの一例を示す図。
【図１７】実施例1において、自動生成されたアダプタのソースコードの一例を示す図。
【図１８】実施例2のシステム構成図。
【図１９】実施例2において、アダプタを生成し、コントローラに組み込む手順を示すフロー図。
【図２０】実施例3のシステム構成図。
【符号の説明】
【０２５２】
10 管理サーバ
11 コード生成部
12 構成管理部
13 構成情報
13a 機器ID
13b 機器属性
13c サービスAPI定義
13d センサ制御モジュール
20 コントローラ
22 機器定義情報
22a 機器ID
22b クライアントAPI定義
23アダプタ生成要求プログラム
24 アプリケーションロジック
25 クライアントAPI
26 アダプタ
27 サービスAPI
28 センサ制御モジュール
30 センサ
49 プログラム格納部
50 実行部
51 機器定義格納部
52 構成情報格納部
59 サービス定義格納部
60 サーバ
【図１】
2009238040.tif 000003
【図２】
2009238040.tif 000004
【図３】
2009238040.tif 000005
【図４】
2009238040.tif 000006
【図５】
2009238040.tif 000007
【図６】
2009238040.tif 000008
【図７】
2009238040.tif 000009
【図８】
2009238040.tif 000010
【図９】
2009238040.tif 000011
【図１０】
2009238040.tif 000012
【図１１】
2009238040.tif 000013
【図１２】
2009238040.tif 000014
【図１３】
2009238040.tif 000015
【図１４】
2009238040.tif 000016
【図１５】
2009238040.tif 000017
【図１６】
2009238040.tif 000018
【図１７】
2009238040.tif 000019
【図１８】
2009238040.tif 000020
【図１９】
2009238040.tif 000021
【図２０】
2009238040.tif 000022