(57)【特許請求の範囲】
【請求項１】
所定の形式でデータを格納する構造体を、前記所定の形式と異なるプログラミング言語で記述されたアプリケーションとのインタフェースとするミドルウェア基盤と、前記アプリケーションとの連携を支援する方法をコンピュータに実行させる開発支援プログラムであって、
記憶手段に記憶された前記アプリケーションに係るデータ形式を含むデータファイルに基づいて、前記ミドルウェア基盤から前記アプリケーションを呼び出すために必要となる情報である呼び出し定義情報を生成する呼び出し定義情報生成手順と、
前記アプリケーションが呼び出された場合に、前記ミドルウェア基盤と前記アプリケーションとを仲介するための仲介ソースファイルを、呼び出された前記アプリケーションに対応する前記データファイルと、前記呼び出し定義情報とに基づいて、読み出したデータファイルに示されるデータ形式と前記所定の形式との交換を行うコードを用いて生成する仲介ソースファイル生成手順と、
呼び出された前記アプリケーションに対応する前記仲介ソースファイルと、呼び出された前記アプリケーションのソースファイルとをコンパイルして呼び出された前記アプリケーションを生成するアプリケーション生成手順と、
をコンピュータに実行させることを特徴とする開発支援プログラム。
【請求項２】
前記アプリケーションに係る関数のインタフェース定義情報を示すアプリケーションインタフェース定義情報を生成するアプリケーションインタフェース定義情報生成手順をさらにコンピュータに実行させることを特徴とする請求項１に記載の開発支援プログラム。
【請求項３】
前記データファイルはさらに、前記アプリケーションの名称と、前記アプリケーションが存在するライブラリ名とを含むことを特徴とする請求項１または２に記載の開発支援プログラム。
【請求項４】
所定の形式でデータを格納する構造体を、前記所定の形式と異なるプログラミング言語で記述されたアプリケーションとのインタフェースとするミドルウェア基盤と、前記アプリケーションとの連携を支援する開発支援方法であって、
記憶手段に記憶された前記アプリケーションに係るデータ形式を含むデータファイルに基づいて、前記ミドルウェア基盤から前記アプリケーションを呼び出すために必要となる情報である呼び出し定義情報を生成する呼び出し定義情報生成工程と、
前記アプリケーションが呼び出された場合に、前記ミドルウェア基盤と前記アプリケーションとを仲介するための仲介ソースファイルを、呼び出された前記アプリケーションに対応する前記データファイルと、前記呼び出し定義情報とに基づいて、読み出したデータファイルに示されるデータ形式と前記所定の形式との交換を行うコードを用いて生成する仲介ソースファイル生成工程と、
呼び出された前記アプリケーションに対応する前記仲介ソースファイルと、呼び出された前記アプリケーションのソースファイルとをコンパイルして呼び出された前記アプリケーションを生成するアプリケーション生成工程と、
を含んだことを特徴とする開発支援方法。
【請求項５】
所定の形式でデータを格納する構造体を、前記所定の形式と異なるプログラミング言語で記述されたアプリケーションとのインタフェースとするミドルウェア基盤と、前記アプリケーションとの連携を支援する開発支援装置であって、
記憶手段に記憶された前記アプリケーションに係るデータ形式を含むデータファイルに基づいて、前記ミドルウェア基盤から前記アプリケーションを呼び出すために必要となる情報である呼び出し定義情報を生成する呼び出し定義情報生成手段と、
前記アプリケーションが呼び出された場合に、前記ミドルウェア基盤と前記アプリケーションとを仲介するための仲介ソースファイルを、呼び出された前記アプリケーションに対応する前記データファイルと、前記呼び出し定義情報とに基づいて、読み出したデータファイルに示されるデータ形式と前記所定の形式との交換を行うコードを用いて生成する仲介ソースファイル生成手段と、
呼び出された前記アプリケーションに対応する前記仲介ソースファイルと、呼び出された前記アプリケーションのソースファイルとをコンパイルして呼び出された前記アプリケーションを生成するアプリケーション生成手段と、
を備えたことを特徴とする開発支援装置。
【請求項６】
コンピュータに、
所定のデータ形式で記述されたデータを受け渡すプログラムであって、アプリケーションプログラム間の連携処理を行うプログラムの制御対象である少なくとも１つのアプリケーションプログラムの処理で前記所定のデータ形式で記述されたデータが用いられるときのデータ形式を示す情報と、当該アプリケーションの呼び出しに用いる呼び出し定義情報とを含むデータファイルを記憶した記憶部から前記少なくとも１つのアプリケーションプログラムに対応するデータファイルを読み出し、
読み出した前記データファイルに含まれる前記情報に示されるデータ形式と前記呼び出し定義情報とに基づいて、前記情報に示されるデータ形式と前記所定のデータ形式との間でデータの変換処理を行い、前記所定の形式で記述されたデータを前記情報に示されるデータ形式で用いるための仲介ソースファイルを生成し、
生成した該仲介ソースファイルと、前記少なくとも１つのアプリケーションプログラムに対応するソースファイルとをコンパイルしてアプリケーションを生成する、
ことを実行させることを特徴とする開発支援プログラム。
【請求項７】
前記コンピュータに
前記アプリケーションに係る関数のインタフェース定義情報を示すアプリケーションインタフェース定義情報を生成する、
ことをさらに実行させることを特徴とする請求項６に記載の開発支援プログラム。
【請求項８】
前記データファイルはさらに、前記アプリケーションの名称と、前記アプリケーションが存在するライブラリ名とを含むことを特徴とする請求項６または７に記載の開発支援プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、仲介プログラム開発支援プログラム、仲介プログラム開発支援方法および仲介プログラム開発支援装置に関する。
【背景技術】
【０００２】
従来より、各種プログラミング言語で記述された複数のアプリケーション間の連携実行を実現することを目的として、ミドルウェア基盤技術（例えば、ＣＯＲＢＡ(Common Object Request Broker Architecture)など）を利用し、このミドルウェア基盤上にアプリケーションを配備する方法が知られている。このＣＯＲＢＡの仕様には、サーバアプリケーションおよびクライアントアプリケーションを作成するための仕組みや、作成されたこれらのアプリケーションを動作させるための仕組みなどが規定されているので、サーバアプリケーションおよびクライアントアプリケーションは、この仕様に従って開発される必要がある。
【０００３】
具体的に説明すると、ＣＯＲＢＡの仕様に従ってアプリケーションが開発されるには、図２３に示すように、まず、開発者によって、サーバアプリケーションおよびクライアントアプリケーションの設計が行われる（図２３の(1)を参照）。次に、開発者によってサーバアプリケーションのインタフェース定義情報が記述され、ＩＤＬ（Interface Definition Language）ファイルが作成される（図２３の(2)を参照）。そして、開発者によって、サーバアプリケーションおよびクライアントアプリケーションのソースファイルが記述される（図２３の(3)を参照）。
【０００４】
ここで、図２３の(3)に示す「サーバアプリケーション、クライアントアプリケーションのソースファイルを記述」についてより具体的に説明すると、例えば、静的起動インタフェースを使用する方法（サーバアプリケーションの関数を直接クライアントアプリケーションの中から呼び出す方法）によるクライアントアプリケーションのソースファイルは、図２４に示すように、一般に、ＯＲＢ(Object Request Broker)の初期化、ネーミングサービスのオブジェクトリファレンスの獲得、サーバアプリケーションのオブジェクトリファレンスの獲得、サーバアプリケーションのオペレーション呼び出しの順で記述される（図２４の(1)〜(4)を参照）。そして、図２４においては、クライアントアプリケーションが開発者によってＣ言語で記述された場合のソースファイルが示されているが、随所に、ＣＯＲＢＡに依存した記述が存在している。なお、図示してはいないが、開発者によって記述されるサーバアプリケーションのソースファイルについても同様に、随所に、ＣＯＲＢＡに依存した記述が存在する。
【０００５】
続いて、図２３に戻ると、図２３の(2)で開発者によって作成されたＩＤＬファイルは、サーバアプリケーション側およびクライアントアプリケーション側のＩＤＬコンパイラでコンパイルされることで、スケルトン、スタブと呼ばれるアプリケーション間の連携を仲介するためのプログラムとなる（図２３の(4)を参照）。そして、生成されたスケルトンと、図２３の(3)で開発者によって記述されたサーバアプリケーションのソースファイルとをコンパイルおよびリンクすると、実行形式のサーバアプリケーションが生成される（図２３の(5)を参照）。また、生成されたスタブと、図２３の(3)で開発者によって記述されたクライアントアプリケーションのソースファイルとをコンパイルおよびリンクすると、実行形式のクライアントアプリケーションが生成される（図２３の(6)を参照）。
【０００６】
このように、ＣＯＲＢＡの仕様に従ってアプリケーションが開発されるには、開発者によって、サーバアプリケーションおよびクライアントアプリケーションのソースファイルが記述される段階（図２３の(3)を参照）で、ＣＯＲＢＡに依存した記述がなされなければならず（図２４を参照）、すなわち、開発者にＣＯＲＢＡに関する知識が必要とされる結果、開発者側の負担が大きくなる。
【０００７】
そこで、例えば、特許文献１では、開発者によって、サーバアプリケーションおよびクライアントアプリケーションのソースファイルが記述される段階で、ＣＯＲＢＡに依存した記述が不要な方法が提案されている。具体的には、ＣＯＲＢＡ独自の仕様による処理、設定、データの型変換などを、アプリケーションに係るインタフェース定義情報を示すＩＤＬファイルを用いて生成する連携用アダプタに代行させ、この連携用アダプタがＣＯＲＢＡオブジェクト（機能ごとに分割されたアプリケーション）にアクセスすることで、アプリケーション間の連携実行を実現する方法である。
【０００８】
この連携用アダプタは、特許文献１の段落番号[００４１]に記述されるように、複数のＣＯＲＢＡオブジェクトのクラス（ＩＤＬにおけるインタフェース）ごとに生成されて、任意のＣＯＲＢＡオブジェクトにアクセスする場合や、特許文献１の段落番号[００９３]に記述されるように、ひとつの連携用汎用アダプタによって任意のＣＯＲＢＡオブジェクトにアクセスする場合など、種々の実施形態において提案されている。
【０００９】
そして、いずれの場合においても、連携用アダプタは、複数存在するＣＯＲＢＡオブジェクトを識別しなければならないので、ネーミングサービス機能などを利用することによって、ＣＯＲＢＡオブジェクトを一意に識別している。例えば、図２５に示すように、ＣＯＲＢＡオブジェクトの識別子と、これに対応するオブジェクト情報とをネーミングサービス機能としてアプリケーションサーバ（アプリケーション間の連携実行を実現することを目的としたミドルウェアの一種）が保持し、連携用アダプタがこれらの情報を参照することによって、ＣＯＲＢＡプロキシを生成する。そして、連携アダプタは、ネーミングサービス機能を参照することによって生成されたＣＯＲＢＡプロキシを用いて、ＣＯＲＢＡオブジェクトにアクセスする。
【００１０】
【特許文献１】特開２００３−１５７２４２号公報
【発明の開示】
【発明が解決しようとする課題】
【００１１】
ところで、上記した従来の技術では、連携用アダプタは、ネーミングサービス機能などを利用することによって、ＣＯＲＢＡオブジェクトを一意に識別しなければならないので、ネーミングサービス機能を利用するための手段などを連携用アダプタ自身が備えなければならず、連携用アダプタの機構が大きくなり、処理における負荷が大きくなるおそれがある。また、ネーミングサービス機能などを利用すると、その処理自体に時間を要し、処理が遅くなるおそれがある。これらのことから、上記した従来の技術では、複数のアプリケーション間の連携実行環境の性能が低下するおそれがあるという課題があった。
【００１２】
このような課題を解決するため、ミドルウェア基盤自体をひとつのＣＯＲＢＡオブジェクトとみなす方法を提案する。具体的に説明すると、このミドルウェア基盤は、図２６に示すように、各種プログラミング言語で記述された複数のアプリケーション間の連携実行を実現するもので、ＣＯＲＢＡを吸収隠蔽し、バイナリ形式でデータを格納する構造体を当該ミドルウェア基盤に配備されるアプリケーションとのインタフェースとする。ミドルウェア基盤がこのような固有のインタフェースを提供することで、アプリケーションは、ミドルウェア基盤自体をひとつのＣＯＲＢＡオブジェクトとみなすことが可能になる。
【００１３】
したがって、この提案によれば、アプリケーション間の連携を仲介するための仲介プログラムが、ＣＯＲＢＡオブジェクトを識別するためのネーミングサービス機能などを利用しないので、ネーミングサービス機能を利用するための手段などを仲介プログラムが備える必要がなく、仲介プログラムの機構を小さくし、処理における負荷を小さくすることが可能になる。また、ネーミングサービス機能などを利用しないので、その処理自体にかかる時間を削減することが可能になる。これらのことから、上記の提案によれば、複数のアプリケーション間の連携実行環境の性能を向上させることが可能になる。
【００１４】
しかしながら、この提案によっても、ミドルウェア基盤上に配備される複数のアプリケーションは、当該ミドルウェア基盤によって提供される固有のインタフェースの仕様に従って、開発者によって記述されなければならない。すなわち、開発者に当該ミドルウェア基盤によって提供される固有のインタフェースの仕様に関する知識が必要とされる結果、結局、開発者側の負担が大きくなるという課題が生じる。
【００１５】
そこで、この発明は、上述した従来技術の課題を解決するためになされたものであり、開発者にミドルウェア基盤によって提供される固有のインタフェースの仕様に関する知識が必要とされる場合に比較して、複数のアプリケーション間の連携実行環境を、開発から運用に至るまで効率的に行わせることが可能な仲介プログラム開発支援プログラム、仲介プログラム開発支援方法および仲介プログラム開発支援装置を提供することを目的とする。
【課題を解決するための手段】
【００１６】
上述した課題を解決し、目的を達成するため、本発明は、各種プログラミング言語で記述された複数のアプリケーション間の連携実行を実現するミドルウェア基盤に配備され、前記アプリケーション間の連携を仲介する仲介プログラムの開発を支援する方法をコンピュータに実行させる仲介プログラム開発支援プログラムであって、ＣＯＲＢＡを吸収隠蔽した前記ミドルウェア基盤に配備され、バイナリ形式でデータを格納する構造体を当該ミドルウェア基盤とのインタフェースとして前記アプリケーション間の連携を仲介する仲介プログラムを、当該アプリケーションに係るインタフェース定義情報を示すＩＤＬファイルを用いて生成する仲介プログラム生成手順をコンピュータに実行させることを特徴とする。
【００１７】
また、本発明は、上記の発明において、前記ミドルウェア基盤から前記アプリケーションを呼び出すために必要となるアプリケーション呼び出し定義情報を生成するアプリケーション呼び出し定義情報生成手順と、前記アプリケーションに係る関数のインタフェース定義情報を示すアプリケーションインタフェース定義情報を生成するアプリケーションインタフェース定義情報生成手順と、をさらにコンピュータに実行させることを特徴とする。
【００１８】
また、本発明は、各種プログラミング言語で記述された複数のアプリケーション間の連携実行を実現するミドルウェア基盤に配備され、前記アプリケーション間の連携を仲介する仲介プログラムの開発を支援する仲介プログラム開発支援方法であって、ＣＯＲＢＡを吸収隠蔽した前記ミドルウェア基盤に配備され、バイナリ形式でデータを格納する構造体を当該ミドルウェア基盤とのインタフェースとして前記アプリケーション間の連携を仲介する仲介プログラムを、当該アプリケーションに係るインタフェース定義情報を示すＩＤＬファイルを用いて生成する仲介プログラム生成工程を含んだことを特徴とする。
【００１９】
また、本発明は、各種プログラミング言語で記述された複数のアプリケーション間の連携実行を実現するミドルウェア基盤に配備され、前記アプリケーション間の連携を仲介する仲介プログラムの開発を支援する仲介プログラム開発支援装置であって、ＣＯＲＢＡを吸収隠蔽した前記ミドルウェア基盤に配備され、バイナリ形式でデータを格納する構造体を当該ミドルウェア基盤とのインタフェースとして前記アプリケーション間の連携を仲介する仲介プログラムを、当該アプリケーションに係るインタフェース定義情報を示すＩＤＬファイルを用いて生成する仲介プログラム生成手段を備えたことを特徴とする。
【発明の効果】
【００２０】
本発明によれば、ＣＯＲＢＡを吸収隠蔽したミドルウェア基盤に配備され、バイナリ形式でデータを格納する構造体をミドルウェア基盤とのインタフェースとしてアプリケーション間の連携を仲介する仲介プログラムを、アプリケーションに係るインタフェース定義情報を示すＩＤＬファイルを用いて生成するので、開発者にミドルウェア基盤によって提供される固有のインタフェースの仕様に関する知識が必要とされる場合に比較して、ＩＤＬファイルなどの基本的な情報が用意されれば仲介プログラムが生成されることから、開発者側の負担が小さくなるとともに、複数のアプリケーション間の連携実行環境の性能も向上する結果、複数のアプリケーション間の連携実行環境を、開発から運用に至るまで効率的に行わせることが可能になる。
【００２１】
また、本発明によれば、ミドルウェア基盤からアプリケーションを呼び出すために必要となるアプリケーション呼び出し定義情報を生成し、アプリケーションに係る関数のインタフェース定義情報を示すアプリケーションインタフェース定義情報を生成するので、ミドルウェア基盤上に複数のアプリケーションが配備されている場合であっても、目的のアプリケーションおよびアプリケーションに係る関数を適切に選択し、実行することができる結果、複数のアプリケーション間の連携実行環境を、確実に実現することが可能になる。
【発明を実施するための最良の形態】
【００２２】
以下に添付図面を参照して、この発明に係る仲介プログラム開発支援プログラム、仲介プログラム開発支援方法および仲介プログラム開発支援装置の実施例を詳細に説明する。なお、以下では、本実施例で用いる主要な用語、本実施例に係る仲介プログラム開発支援装置の概要および特徴、仲介プログラム開発支援装置の構成および処理の流れ、本実施例の効果を順に説明し、最後に本実施例に対する種々の変形例を説明する。
【実施例１】
【００２３】
［用語の説明］
まず最初に、本実施例で用いる主要な用語を説明する。本実施例で用いる「サーバアプリケーション（特許請求の範囲に記載の「複数のアプリケーション」に対応する）」とは、ネットワークに接続されたコンピュータ上で動作し、サービス機能を提供するアプリケーションソフトウェアである。例えば、企業における人事システムや経理システムを運営する基幹系の業務アプリケーションサーバ、大量のデータを保有し各種問い合わせに応じて情報を提供するデータベースサーバ、またはインターネットやイントラネットに接続して各種情報を提供するＷＷＷサーバなどのアプリケーションソフトウェアである。このようなサーバアプリケーションは、各種プログラミング言語（例えば、Ｃ、Ｊａｖａ（登録商標）など）で記述されたプログラムとして、コンピュータ上にインストールされる。
【００２４】
また、「クライアントアプリケーション（特許請求の範囲に記載の「複数のアプリケーション」に対応する）」とは、ネットワークに接続されたコンピュータ上で動作し、上記したサーバアプリケーションから提供されるサービス機能を利用するアプリケーションである。例えば、基幹系業務アプリケーションサーバから提供される人事システムや経理システムを扱うアプリケーションソフトウェア、データベースサーバに問い合わせをして情報を検索するアプリケーションソフトウェア、またはＷＷＷサーバにアクセスして各種情報を取得するアプリケーションソフトウェアなどである。このようなクライアントアプリケーションは、各種プログラミング言語で記述されたプログラムとして、コンピュータ上にインストールされる。
【００２５】
また、上記した各種プログラミング言語のひとつである「Ｃ（特許請求の範囲に記載の「プログラミング言語」に対応する）」とは、豊富な HYPERLINK "http://e-words.jp/w/E6BC94E7AE97E5AD90.html" 演算子、データ型、および制御構造を持ち、構造化プログラミングに適したプログラミング言語のことである。また、「Ｊａｖａ（登録商標）（特許請求の範囲に記載の「プログラミング言語」に対応する）」とは、オブジェクト指向性を備えたプログラミング言語のことである。
【００２６】
次に、本実施例で用いる「ミドルウェア基盤（特許請求の範囲に記載の「ミドルウェア基盤」に対応する）とは、図２６に示すように、各種プログラミング言語で記述された複数のアプリケーション間の連携実行を実現する基盤型のソフトウェアである。すなわち、ＣやＪａｖａ（登録商標）などで記述されたサーバアプリケーションと、ＣやＪａｖａ（登録商標）などで記述されたクライアントアプリケーションとの間、もしくは、ＣやＪａｖａ（登録商標）などで記述されたサーバアプリケーション同士の間で複数のアプリケーション間の連携実行を実現するための仕組みを有するソフトウェアである。また、ミドルウェア基盤では配備される各種プログラミング言語で記述されたアプリケーションの言語に固有な処理（例えば、ＣＯＢＯＬ実行環境の開設・閉鎖など）を実行し、どの言語のアプリケーションを配備するかを配備時に意識させないことを特徴としている。
【００２７】
そして、本実施例で用いる「ＣＯＲＢＡ(Common Object Request Broker Architecture：特許請求の範囲に記載の「ＣＯＲＢＡ」に対応する)」とは、このようなミドルウェア基盤のひとつの仕様であり、サーバアプリケーションおよびクライアントアプリケーションを作成するための仕組みや、作成されたこれらのアプリケーションを動作させるための仕組みなどが規定されている。
【００２８】
そして、上記したミドルウェア基盤上にサーバアプリケーションやクライアントアプリケーションを配備するにあたっては、一般に、図２６に示すように、アプリケーション間の連携を仲介するための仲介プログラムが必要となる。本実施例で用いる「Ｃ固有処理ソースファイル（特許請求の範囲に記載の「仲介プログラム」に対応する）」とは、Ｃで記述されたアプリケーションと、他のプログラミング言語で記述されたアプリケーションとの連携を仲介する仲介プログラムであり、本実施例で用いる「Ｊａｖａ（登録商標）Ｂｅａｎソースファイル（特許請求の範囲に記載の「仲介プログラム」に対応する）」と「Ｊａｖａ（登録商標）構造体ソースファイル（特許請求の範囲に記載の「仲介プログラム」に対応する）」とは、Ｊａｖａ（登録商標）で記述されたアプリケーションと、他のプログラミング言語で記述されたアプリケーションとの連携を仲介する仲介プログラムである。
【００２９】
［仲介プログラム開発支援装置の概要および特徴］
続いて、図１を用いて、本実施例に係る仲介プログラム開発支援装置の概要および特徴を説明する。図１は、実施例１に係る仲介プログラム開発支援装置の概要および特徴を説明するための図である。なお、以下では、Ｃで記述されたサーバアプリケーションと、Ｊａｖａ（登録商標）で記述されたクライアントアプリケーションとの連携を仲介する仲介プログラム（Ｃ固有処理ソースファイル、Ｊａｖａ（登録商標）Ｂｅａｎソースファイル、およびＪａｖａ（登録商標）構造体ソースファイル）の開発を支援する場合を説明する。
【００３０】
実施例１に係る仲介プログラム開発支援装置は、各種プログラミング言語で記述された複数のアプリケーション間の連携実行を実現するミドルウェア基盤に配備され、前記アプリケーション間の連携を仲介する仲介プログラムの開発を支援することを概要とし、複数のアプリケーション間の連携実行環境を、開発から運用に至るまで効率的に行わせることを可能にしている点に主たる特徴がある。
【００３１】
この主たる特徴について簡単に説明すると、図１に示すように、実施例１に係る仲介プログラム開発支援装置では、サーバアプリケーションに係るインタフェース定義情報（例えば、サーバアプリケーションに係るパラメータのデータ型など）が、開発者によってＩＤＬ(Interface Definition Language)で記述されたＩＤＬファイルをＩＤＬファイル記憶部に記憶する（図１の(1)を参照）。また、仲介プログラム開発支援装置では、アプリケーションに係る情報（例えば、サーバアプリケーション名、ライブラリ名など）が開発者によって記述されたアプリケーション情報入力ファイルをアプリケーション情報入力ファイル記憶部に記憶する（図１の(1)を参照）。なお、ＩＤＬファイルとは、特許請求の範囲に記載の「ＩＤＬファイル」に対応する。
【００３２】
そして、実施例１に係る仲介プログラム開発支援装置は、仲介プログラム開発支援装置を動作させるための仲介プログラム生成指示を受け付ける（図１の(2)を参照）。次に、仲介プログラム開発支援装置は、ＩＤＬファイルを用いて、仲介プログラムであるＣ固有処理ソースファイルを生成し、Ｃ固有処理ソースファイル記憶部に記憶する（図１の(3)を参照）。具体的には、ＣＯＲＢＡを吸収隠蔽し、バイナリ形式でデータを格納する構造体をインタフェースとするミドルウェア基盤とサーバアプリケーションとを連携することを目的として、仲介プログラム開発支援装置は、Ｃ固有処理生成部においてＩＤＬファイルの解析を行い、サーバアプリケーションに係るパラメータをＣのデータ型に変換するための関数を記述するなどして、Ｃ固有処理ソースファイルを生成する。
【００３３】
例えば、ＩＤＬファイルに、サーバアプリケーションの関数名を示すＩＤＬのオペレーション名「op」が記述されている場合には、仲介プログラム開発支援装置のＣ固有処理生成部は、Ｃ固有処理ソースファイルに「apfwskel_op」という名前の関数を記述する。なお、複数のアプリケーション間の連携実行環境においては、この関数によってミドルウェア基盤からサーバアプリケーションの呼び出しが行われると、ミドルウェア基盤においてバイナリ形式で構造体に格納されていたデータは、Ｃのデータ型に変換されてサーバアプリケーションに渡される。
【００３４】
続いて、仲介プログラム開発支援装置は、ＩＤＬファイルおよびアプリケーション情報入力ファイルを用いて、ミドルウェア基盤からアプリケーションを呼び出すために必要となるアプリケーション呼び出し定義情報を生成し、アプリケーション呼び出し定義ファイルとしてアプリケーション呼び出し定義ファイル記憶部に記憶する（図１の(3)を参照）。具体的には、仲介プログラム開発支援装置は、Ｃ固有処理生成部においてＩＤＬファイルおよびアプリケーション情報入力ファイルの解析を行い、クライアントアプリケーションなどから呼び出されるサーバアプリケーションのサーバアプリケーション名の定義、サーバアプリケーションが存在するライブラリ名の定義、サーバアプリケーションの関数名の定義などを記述する。
【００３５】
例えば、ＩＤＬファイルに、サーバアプリケーションの関数名を示すＩＤＬのオペレーション名「op」が記述されている場合には、仲介プログラム開発支援装置のＣ固有処理生成部は、アプリケーション呼び出し定義情報として「<func name="op"/>」を記述する。なお、複数のアプリケーション間の連携実行環境においては、ミドルウェア基盤からサーバアプリケーションの関数の呼び出しが行われる時には、「apfwskel_op」という関数名で呼び出され、バイナリ形式で構造体に格納されたデータをＣのデータ型に変換した上で、「op」というアプリケーション呼び出し定義に記述された関数名で呼び出される。
【００３６】
一方、アプリケーション情報入力ファイルに、オペレーション名「op」に対してサーバアプリケーションのサーバアプリケーション名「apl」と、サーバアプリケーションが存在するライブラリ名「libserverapl.so」とが記述されている場合には、仲介プログラム開発支援装置のＣ固有処理生成部は、アプリケーション呼び出し定義情報として、「<target name="apl">」と、「<library name="libserverapl.so"/>」とを記述する。なお、複数のアプリケーション間の連携実行環境においては、ミドルウェア基盤からサーバアプリケーションの呼び出しが行われる時には、サーバアプリケーション名「apl」が指定された場合に「libserverapl.so」というライブラリに存在する「apfwskel_op」という関数名で呼び出される。
【００３７】
また、仲介プログラム開発支援装置は、ＩＤＬファイルおよびアプリケーション情報入力ファイルを用いて、アプリケーションに係る関数のインタフェース情報を示すアプリケーションインタフェース定義情報を生成し、アプリケーションインタフェース定義ファイルとしてアプリケーションインタフェース定義ファイル記憶部に記憶する（図１の(3)を参照）。具体的には、仲介プログラム開発支援装置は、Ｃ固有処理生成部においてＩＤＬファイルおよびアプリケーション情報入力ファイルの解析を行い、サーバアプリケーションの関数名、関数の戻り値、パラメータの方向、パラメータのデータ型、およびパラメータ名などを記述する。
【００３８】
例えば、ＩＤＬファイルに、「void  op(in long indata)」と記述されている場合には、仲介プログラム開発支援装置のＣ固有処理生成部は、アプリケーションインタフェース定義情報として、「<func name="op">」、「<return type="void"/>」、および「<param name="indata" type="long" direction="IN"/>」を記述する。なお、複数のアプリケーション間の連携実行環境においては、ミドルウェア基盤からサーバアプリケーションの関数の呼び出しが行われると、呼び出しは「op」という関数名、関数の戻り値は「void」、パラメータの方向は「in」、パラメータのデータ型は「long」、およびパラメータ名は「indata」となる。
【００３９】
次に、仲介プログラム開発支援装置は、ＩＤＬファイルを用いて、仲介プログラムであるＪａｖａ（登録商標）ＢｅａｎソースファイルおよびＪａｖａ（登録商標）構造体ソースファイルを生成し、Ｊａｖａ（登録商標）Ｂｅａｎソースファイル記憶部およびＪａｖａ（登録商標）構造体ソースファイル記憶部にそれぞれ記憶する（図１の(4)を参照）。具体的には、ＣＯＲＢＡを吸収隠蔽し、バイナリ形式でデータを格納する構造体をインタフェースとするミドルウェア基盤とクライアントアプリケーションとを連携することを目的として、仲介プログラム開発支援装置は、Ｊａｖａ（登録商標）Ｂｅａｎ生成部においてＩＤＬファイルの解析を行い、サーバアプリケーションに係るパラメータをＪａｖａ（登録商標）のデータ型に変換するための関数を記述するなどして、Ｊａｖａ（登録商標）ＢｅａｎソースファイルおよびＪａｖａ（登録商標）構造体ソースファイルを生成する。
【００４０】
なお、このようにして仲介プログラム開発支援装置が生成したＣ固有処理ソースファイルは、開発者が別途作成するＣサーバアプリケーションソースファイルとともにコンパイルおよびリンクされることで、ＣＯＲＢＡを吸収隠蔽し、バイナリ形式でデータを格納する構造体をインタフェースとするミドルウェア基盤に配備されるサーバアプリケーションとなる。また、同様に、仲介プログラム開発支援装置が生成したＪａｖａ（登録商標）ＢｅａｎソースファイルおよびＪａｖａ（登録商標）構造体ソースファイルは、開発者が別途作成するＪａｖａ（登録商標）クライアントアプリケーションソースファイルとともにコンパイルおよびリンクされることで、ＣＯＲＢＡを吸収隠蔽し、バイナリ形式でデータを格納する構造体をインタフェースとするミドルウェア基盤に配備されるクライアントアプリケーションとなる。
【００４１】
このようなことから、実施例１に係る仲介プログラム開発支援装置は、開発者にミドルウェア基盤によって提供される固有のインタフェースの仕様に関する知識が必要とされる場合に比較して、ＩＤＬファイルなどの基本的な情報が用意されれば仲介プログラムが生成されることから、開発者側の負担が小さくなるとともに、複数のアプリケーション間の連携実行環境の性能も向上する結果、複数のアプリケーション間の連携実行環境を、開発から運用に至るまで効率的に行わせることが可能になる。
【００４２】
［仲介プログラム開発支援装置の構成］
続いて、図２〜図１８用いて、実施例１に係る仲介プログラム開発支援装置の構成を説明する。図２は、実施例１に係る仲介プログラム開発支援装置の構成を示すブロック図であり、図３および図４は、ＩＤＬファイル記憶部を説明するための図であり、図５は、アプリケーション情報入力ファイル記憶部を説明するための図であり、図６〜図１１は、Ｃ固有処理ソースファイル記憶部を説明するための図であり、図１２は、アプリケーション呼び出し定義ファイル記憶部を説明するための図であり、図１３は、アプリケーションインタフェース定義ファイル記憶部を説明するための図であり、図１４および図１５は、Ｊａｖａ（登録商標）Ｂｅａｎソースファイル記憶部を説明するための図であり、図１６〜図１８は、Ｊａｖａ（登録商標）構造体ソースファイル記憶部を説明するための図であり、図１９は、実施例１に係るＣ固有処理生成部の構成を示すブロック図である。
【００４３】
図２に示すように、仲介プログラム開発支援装置１０は、入力部１１と、出力部１２と、入出力制御ＩＦ部１３と、記憶部２０と、制御部３０とから構成される。
【００４４】
入力部１１は、制御部３０による各種処理に用いるデータや、各種処理をするための操作指示などを、キーボード、記憶媒体、または通信などによって入力する入力手段である。具体的には、アプリケーションに係るインタフェース定義情報（例えば、アプリケーションに係るパラメータのデータ型など）が開発者によってＩＤＬで記述されたＩＤＬファイルと、アプリケーションに係る情報（例えば、サーバアプリケーション名、ライブラリ名など）が開発者によって記述されたアプリケーション情報入力ファイルと、仲介プログラム生成指示など各種操作指示とを入力する。なお、入力部１１によって入力されたＩＤＬファイルは、後述するＩＤＬファイル記憶部２１に記憶され、アプリケーション情報入力ファイルは、後述するアプリケーション情報入力ファイル記憶部２２に記憶される。
【００４５】
出力部１２は、制御部３０による各種処理の結果や、各種処理をするための操作指示などを、モニタ、プリンタ、またはスピーカーなどに出力する出力手段である。具体的には、各種処理の過程を示すログ情報、入力部１１から入力される各種操作指示、または生成されたファイルの一覧などを出力する。
【００４６】
入出力制御ＩＦ部１３は、入力部１１および出力部１２と、記憶部２０および制御部３０との間におけるデータ転送を制御する手段である。
【００４７】
記憶部２０は、制御部３０による各種処理に用いるデータを記憶する記憶手段であり、特に本発明に密接に関連するものとしては、図２に示すように、ＩＤＬファイル記憶部２１と、アプリケーション情報入力ファイル記憶部２２と、Ｃ固有処理ソースファイル記憶部２３と、アプリケーション呼び出し定義情報ファイル記憶部２４と、アプリケーションインタフェース定義ファイル記憶部２５と、Ｊａｖａ（登録商標）Ｂｅａｎソースファイル記憶部２６と、Ｊａｖａ（登録商標）構造体ソースファイル記憶部２７とを備える。
【００４８】
かかる記憶部２０のなかで、ＩＤＬファイル記憶部２１は、仲介プログラム開発支援装置１０が仲介プログラムを生成するために必要となる情報であって、入力部１１によって入力されたＩＤＬファイルを記憶する記憶手段である。具体的には、図３および図４に例示するように、アプリケーションに係るインタフェース定義情報が、開発者によってＩＤＬで記述されたＩＤＬファイルを記憶する。例えば、図３に示す「interface apfw_inf」という記述は、サーバアプリケーションのインタフェース名が「apfw_inf」であることがＩＤＬで記述されたものであり、また、「void op(in long indata)」という記述は、サーバアプリケーションの関数名が「op」、関数の戻り値が「void」、パラメータの方向が「in」、パラメータのデータ型が「long」、およびパラメータ名が「indata」であることがＩＤＬで記述されたものである。
【００４９】
同様に、図４においても、サーバアプリケーションのインタフェース名が「apfwinf」、サーバアプリケーションの関数名が「sampleop1」、関数の戻り値が「void」であること、パラメータ名「indata」のパラメータの方向が「in」で、データ型が「sample_struct1」であること、パラメータ名「outdata」のパラメータ方向が「out」で、データ型が「sample_struct1」であることなどの情報が、ＩＤＬで記述されている。
【００５０】
アプリケーション情報入力ファイル記憶部２２は、仲介プログラム開発支援装置１０が仲介プログラムを生成するために必要となる情報であって、入力部１１によって入力されたアプリケーション情報入力ファイルを記憶する記憶手段である。具体的には、図５に例示するように、アプリケーションに係る情報が開発者によって記述されたアプリケーション情報入力ファイルを記憶する。例えば、図５に示す「<target name="apl"/>」という記述は、サーバアプリケーション名が「apl」であることが記述されたものであり、「<library name="libserverapl.so"/>」という記述は、サーバアプリケーションが存在するライブラリ名が「libserverapl.so」であることが記述されたものである。なお、図５では、アプリケーション情報入力ファイルの記述言語として、ＸＭＬ(eXtensible Markup Language)を用いる場合を例示したが、本発明はこれに限定されるものではなく、ＳＧＭＬ(Standard Generalized Mark-up Language)を用いるなど、文書を記述する言語であれば、いずれでもよい。
【００５１】
Ｃ固有処理ソースファイル記憶部２３は、後述するＣ固有処理生成部３１によって生成されたＣ固有処理ソースファイルを記憶する記憶手段である。具体的には、図６〜図１１に例示するように、Ｃで記述された仲介プログラムのソースファイルを記憶する。例えば、「apfwskel_sampleop1」という記述は、サーバアプリケーションの関数名であり、複数のアプリケーション間の連携実行環境においては、この関数によってミドルウェア基盤からサーバアプリケーションの呼び出しが行われると、ミドルウェア基盤においてバイナリ形式で構造体に格納されていたデータは、Ｃのデータ型に変換されてサーバアプリケーションに渡される。なお、Ｃ固有処理ソースファイルは、開発者によって別途作成されるＣサーバアプリケーションソースファイルとともにコンパイルおよびリンクされることで、ミドルウェア基盤に配備されるアプリケーションとなる。
【００５２】
アプリケーション呼び出し定義ファイル記憶部２４は、後述するＣ固有処理生成部３１によって生成されたアプリケーション呼び出し定義情報を、アプリケーション呼び出し定義ファイルとして記憶する記憶手段である。具体的には、図１２に例示するように、ミドルウェア基盤からアプリケーションを呼び出すために必要となるアプリケーション呼び出し定義情報を主に記憶する。例えば、図１２に示す「<target name="apl">」という記述は、サーバアプリケーション名が「apl」であることが記述されたものであり、「<library name="libserverapl.so"/>」という記述は、サーバアプリケーションが存在するライブラリ名が「libserverapl.so」であることが記述されたものであり、「<func name="op">/」という記述は、サーバアプリケーションの関数名が「op」であることが記述されたものである。なお、図１２では、アプリケーション呼び出し定義ファイルの記述言語として、ＸＭＬ(eXtensible Markup Language)を用いる場合を例示したが、本発明はこれに限定されるものではなく、ＳＧＭＬ(Standard Generalized Mark-up Language)を用いるなど、文書を記述する言語であれば、いずれでもよい。
【００５３】
アプリケーションインタフェース定義ファイル記憶部２５は、後述するＣ固有処理生成部３１によって生成されたアプリケーションインタフェース定義情報を、アプリケーションインタフェース定義ファイルとして記憶する記憶手段である。具体的には、図１３に例示するように、アプリケーションに係る関数のインタフェース情報を示すアプリケーションインタフェース定義情報を主に記憶する。例えば、図１３に示す「<func name="op">」という記述は、サーバアプリケーションの関数名が「op」であることが記述されたものであり、「<return type="void"/>」という記述は、関数の戻り値が「void」であることが記述されたものであり、「<param name="indata" type="long" direction="in"/>」は、サーバアプリケーションに係るパラメータ名が「indata」であること、パラメータのデータ型が「long」であること、パラメータの方向が「in」であることが記述されたものである。なお、図１３では、アプリケーションインタフェース定義ファイルの記述言語として、ＸＭＬ(eXtensible Markup Language)を用いる手段を例示したが、本発明はこれに限定されるものではなく、ＳＧＭＬ(Standard Generalized Mark-up Language)を用いるなど、文書を記述する言語を用いる手段であれば、いずれの手段でもよい。
【００５４】
Ｊａｖａ（登録商標）Ｂｅａｎソースファイル記憶部２６は、後述するＪａｖａ（登録商標）Ｂｅａｎ生成部３２によって生成されたＪａｖａ（登録商標）Ｂｅａｎソースファイルを記憶する記憶手段である。具体的には、図１４および図１５に例示するように、Ｊａｖａ（登録商標）で記述された仲介プログラムのソースファイルを記憶する。例えば、「public class sampleop1Bean」という記述は、Ｊａｖａ（登録商標）のソースファイルを構成する単位であるクラスの定義を行うことを意味している。なお、Ｊａｖａ（登録商標）Ｂｅａｎソースファイルは、開発者によって別途作成されるＪａｖａ（登録商標）クライアントアプリケーションソースファイルとともにコンパイルおよびリンクされることで、ミドルウェア基盤に配備されるアプリケーションとなる。
【００５５】
Ｊａｖａ（登録商標）構造体ソースファイル記憶部２７は、後述するＪａｖａ（登録商標）Ｂｅａｎ生成部３２によって生成されたＪａｖａ（登録商標）構造体ソースファイルを記憶する記憶手段である。具体的には、図１６〜図１８に例示するように、Ｊａｖａ（登録商標）で記述された仲介プログラムのソースファイルを記憶する。例えば、「final public class sample_str1」という記述は、クラスの定義を行うことを意味し、「public Ｊａｖａ（登録商標）.lang.String sample_picx;」という記述は、データ型がstring型である「sample_picx」というパラメータ名のパラメータを定義している。なお、Ｊａｖａ（登録商標）構造体ソースファイルは、開発者によって別途作成されるＪａｖａ（登録商標）クライアントアプリケーションソースファイルとともにコンパイルおよびリンクされることで、ミドルウェア基盤に配備されるアプリケーションとなる。
【００５６】
制御部３０は、仲介プログラム開発支援装置１０を制御して各種処理を実行する制御手段であり、特に本発明に密接に関連するものとしては、図２に示すようにＣ固有処理生成部３１と、Ｊａｖａ（登録商標）Ｂｅａｎ生成部３２とを備える。
【００５７】
かかる制御部３０のなかで、Ｃ固有処理生成部３１は、Ｃ固有処理ソースファイルと、アプリケーション呼び出し定義ファイルと、アプリケーションインタフェース定義ファイルとを生成する処理部である。具体的には、ＩＤＬファイル記憶部２１に記憶されているＩＤＬファイルと、アプリケーション情報入力ファイル記憶部２２に記憶されているアプリケーション情報入力ファイルとを用いて、Ｃ固有処理ソースファイルと、アプリケーション呼び出し定義ファイルと、アプリケーションインタフェース定義ファイルとを生成し、Ｃ固有処理ソースファイル記憶部２３と、アプリケーション呼び出し定義ファイル記憶部２４と、アプリケーションインタフェース定義ファイル記憶部２５とに、それぞれ記憶させる。
【００５８】
ここで、Ｃ固有処理生成部３１の構成を、図１９を用いて具体的に説明する。Ｃ固有処理生成部３１は、図１９に示すように、Ｃ固有処理ソースファイル生成部３１ａと、アプリケーション呼び出し定義情報生成部３１ｂと、アプリケーションインタフェース定義情報生成部３１ｃとを備える。なお、Ｃ固有処理ソースファイル生成部３１ａは、特許請求の範囲に記載の「仲介プログラム生成手順」に対応し、アプリケーション呼び出し定義情報生成部３１ｂは、特許請求の範囲に記載の「アプリケーション呼び出し定義情報生成手順」に対応し、アプリケーションインタフェース定義情報生成部３１ｃは、特許請求の範囲に記載の「アプリケーションインタフェース定義情報生成手順」に対応する。
【００５９】
かかるＣ固有処理生成部３１を具体的に説明すると、Ｃ固有処理ソースファイル生成部３１ａは、ＣＯＲＢＡを吸収隠蔽したミドルウェア基盤に配備され、バイナリ形式でデータを格納する構造体をミドルウェア基盤とのインタフェースとしてアプリケーション間の連携を仲介する仲介プログラムを、アプリケーションに係るインタフェース定義情報を示すＩＤＬファイルを用いて生成する処理部である。具体的には、ＣＯＲＢＡを吸収隠蔽し、バイナリ形式でデータを格納する構造体をインタフェースとするミドルウェア基盤とサーバアプリケーションとを連携することを目的として、Ｃ固有処理ソースファイル生成部３１ａは、ＩＤＬファイルの解析を行い、サーバアプリケーションに係るパラメータをＣのデータ型に変換するための関数を記述するなどして、Ｃ固有処理ソースファイルを生成する。
【００６０】
例えば、図４に示すように、ＩＤＬファイルに、サーバアプリケーションの関数名を示すＩＤＬのオペレーション名「sampleop1」が記述されている場合、Ｃ固有処理ソースファイル生成部３１ａは、図６に示すように、Ｃ固有処理ソースファイルに「apfwskel_sampleop1」という名前の関数を記述する。なお、複数のアプリケーション間の連携実行環境においては、この関数によってミドルウェア基盤からサーバアプリケーションの呼び出しが行われると、ミドルウェア基盤においてバイナリ形式で構造体に格納されていたデータは、Ｃのデータ型に変換されてサーバアプリケーションに渡される。
【００６１】
アプリケーション呼び出し定義情報生成部３１ｂは、ミドルウェア基盤からアプリケーションを呼び出すために必要となるアプリケーション呼び出し定義情報を生成する処理部である。具体的には、アプリケーション呼び出し定義情報生成部３１ｂは、ＩＤＬファイルおよびアプリケーション情報入力ファイルの解析を行い、クライアントアプリケーションなどから呼び出されるサーバアプリケーションのサーバアプリケーション名の定義、サーバアプリケーションが存在するライブラリ名の定義、サーバアプリケーションの関数名などを記述する。
【００６２】
例えば、図３に示すように、ＩＤＬファイルに、サーバアプリケーションの関数名を示すＩＤＬのオペレーション名「op」が記述されている場合、アプリケーション呼び出し定義情報生成部３１ｂは、図１２に示すように、アプリケーション呼び出し定義情報として「<func name="op"/>」を記述する。なお、複数のアプリケーション間の連携実行環境においては、ミドルウェア基盤からサーバアプリケーションの関数の呼び出しが行われる時には、「apfwskel_op」という関数名で呼び出され、バイナリ形式で構造体に格納されたデータをＣのデータ型に変換した上で、「op」というアプリケーション呼び出し定義に記述された関数名で呼び出される。
【００６３】
一方、図５に示すように、アプリケーション情報入力ファイルに、オペレーション名「op」に対してサーバアプリケーションのサーバアプリケーション名「apl」と、サーバアプリケーションが存在するライブラリ名「libserverapl.so」とが記述されている場合、アプリケーション呼び出し定義情報生成部３１ｂは、図１２に示すように、アプリケーション呼び出し定義情報として、「<target name="apl">」と、「<library name="libserverapl.so"/>」とを記述する。なお、複数のアプリケーション間の連携実行環境においては、ミドルウェア基盤からサーバアプリケーションの呼び出しが行われる時には、サーバアプリケーション名「apl」が指定された場合に「libserverapl.so」というライブラリに存在する「apfwskel_op」という関数名で呼び出される。
【００６４】
アプリケーションインタフェース定義情報生成部３１ｃは、アプリケーションに係る関数のインタフェース定義情報を示すアプリケーションインタフェース定義情報を生成する処理部である。具体的には、アプリケーションインタフェース定義情報生成部３１ｃは、ＩＤＬファイルおよびアプリケーション情報入力ファイルの解析を行い、サーバアプリケーションの関数名、関数の戻り値、パラメータの方向、パラメータのデータ型、およびパラメータ名などを記述する。
【００６５】
例えば、図３に示すように、ＩＤＬファイルに、「void  op(in long indata)」と記述されている場合、アプリケーションインタフェース定義情報生成部３１ｃは、図１３に示すように、アプリケーションインタフェース定義情報として、「<func name="op">」、「<return type="void"/>」、および「<param name="indata"type="long"direction="IN"/>」を記述する。なお、複数のアプリケーション間の連携実行環境においては、ミドルウェア基盤からサーバアプリケーションの関数の呼び出しが行われると、呼び出しは「op」という関数名、関数の戻り値は「void」、パラメータの方向は「in」、パラメータのデータ型は「long」、およびパラメータ名は「indata」となる。
【００６６】
ここで、図２に戻ると、Ｊａｖａ（登録商標）Ｂｅａｎ生成部３２は、Ｊａｖａ（登録商標）Ｂｅａｎソースファイルと、Ｊａｖａ（登録商標）構造体ソースファイルとを生成する処理部である。具体的には、ＩＤＬファイル記憶部２１に記憶されているＩＤＬファイルを用いて、Ｊａｖａ（登録商標）Ｂｅａｎソースファイルと、Ｊａｖａ（登録商標）構造体ソースファイルとを生成し、Ｊａｖａ（登録商標）Ｂｅａｎソースファイル記憶部２６と、Ｊａｖａ（登録商標）構造体ソースファイル記憶部２７とに、それぞれ記憶させる。なお、Ｊａｖａ（登録商標）Ｂｅａｎ生成部３２は、特許請求の範囲に記載の「仲介プログラム生成手順」に対応する。
【００６７】
かかるＪａｖａ（登録商標）Ｂｅａｎ生成部３２は、ＣＯＲＢＡを吸収隠蔽し、バイナリ形式でデータを格納する構造体をインタフェースとするミドルウェア基盤とクライアントアプリケーションとを連携することを目的として、ＩＤＬファイルの解析を行い、サーバアプリケーションに係るパラメータをＪａｖａ（登録商標）のデータ型に変換するための関数を記述するなどして、Ｊａｖａ（登録商標）ＢｅａｎソースファイルおよびＪａｖａ（登録商標）構造体ソースファイルを生成する。例えば、図４に示すように、ＩＤＬファイルに、サーバアプリケーションの関数名を示すＩＤＬのオペレーション名「sampleop1」が記述されている場合、Ｊａｖａ（登録商標）Ｂｅａｎ生成部３２は、図１４に示すように、Ｊａｖａ（登録商標）Ｂｅａｎソースファイルに「public class sampleop1Bean」とクラスを定義する。なお、複数のアプリケーション間の連携実行環境においては、この関数によってミドルウェア基盤からサーバアプリケーションの呼び出しが行われると、ミドルウェア基盤においてバイナリ形式で構造体に格納されていたデータは、Ｊａｖａ（登録商標）のデータ型に変換されてクライアントアプリケーションに渡される。
【００６８】
［仲介プログラム開発支援装置による処理］
次に、図２０および図２１を用いて、実施例１における仲介プログラム開発支援装置による処理を説明する。図２０は、実施例１における仲介プログラム開発支援処理の手順を示すフローチャートであり、図２１は、実施例１におけるＣ固有処理生成処理の手順を示すフローチャートである。
【００６９】
図２０に示すように、仲介プログラム開発支援装置１０において、仲介プログラム開発支援装置を動作させるための仲介プログラム生成指示を入力部１１から受け付けた場合に（ステップＳ２００１肯定）、Ｃ固有処理生成部３１は、ＩＤＬファイル記憶部２１に記憶されたＩＤＬファイルと、アプリケーション情報入力ファイル記憶部２２に記憶されたアプリケーション情報入力ファイルとを用いて、Ｃ固有処理ソースファイルと、アプリケーション呼び出し定義ファイルと、アプリケーションインタフェース定義ファイルとを生成し、Ｃ固有処理ソースファイルをＣ固有処理ソースファイル記憶部２３に、アプリケーション呼び出し定義ファイルをアプリケーション呼び出し定義ファイル記憶部２４に、アプリケーションインタフェース定義ファイルをアプリケーションインタフェース定義ファイル記憶部２５に記憶させる（ステップＳ２００２）。
【００７０】
そして、Ｊａｖａ（登録商標）Ｂｅａｎ生成部３２は、ＩＤＬファイル記憶部２１に記憶されたＩＤＬファイルと、アプリケーション情報入力ファイル記憶部２２に記憶されたアプリケーション情報入力ファイルとを用いて、Ｊａｖａ（登録商標）Ｂｅａｎソースファイルと、Ｊａｖａ（登録商標）構造体ソースファイルとを生成し、Ｊａｖａ（登録商標）ＢｅａｎソースファイルをＪａｖａ（登録商標）Ｂｅａｎソースファイル記憶部２６に、Ｊａｖａ（登録商標）構造体ソースファイルをＪａｖａ（登録商標）構造体ソースファイル記憶部２７に記憶させる（ステップＳ２００３）。
【００７１】
ここで、Ｃ固有処理生成処理の手順を、図２１を用いて具体的に説明する。図２１に示すように、まず、Ｃ固有処理ソースファイル生成部３１ａは、ＩＤＬファイル記憶部２１に記憶されたＩＤＬファイルの解析を行い、サーバアプリケーションに係るパラメータをＣのデータ型に変換するための関数を記述するなどして、Ｃ固有処理ソースファイルを生成し、Ｃ固有処理ソースファイル記憶部２３に記憶させる（ステップＳ２１０１）。
【００７２】
そして、アプリケーション呼び出し定義情報生成部３１ｂは、ＩＤＬファイル記憶部２１に記憶されたＩＤＬファイルおよびアプリケーション情報入力ファイル記憶部２２に記憶されたアプリケーション情報入力ファイルの解析を行い、クライアントアプリケーションなどから呼び出されるサーバアプリケーションのサーバアプリケーション名の定義、サーバアプリケーションが存在するライブラリ名の定義、サーバアプリケーションの関数名などを記述して、アプリケーション呼び出し定義情報を生成し、アプリケーション呼び出し定義情報ファイルとしてアプリケーション呼び出し定義ファイル記憶部２４に記憶させる（ステップＳ２１０２）。
【００７３】
そして、アプリケーションインタフェース定義情報生成部３１ｃは、ＩＤＬファイル記憶部２１に記憶されたＩＤＬファイルおよびアプリケーション情報入力ファイル記憶部２２に記憶されたアプリケーション情報入力ファイルの解析を行い、サーバアプリケーションの関数名、関数の戻り値、パラメータの方向、パラメータのデータ型、およびパラメータ名などを記述して、アプリケーションインタフェース定義情報を生成し、アプリケーションインタフェース定義情報ファイルとして、アプリケーションインタフェース定義ファイル記憶部２５に記憶させる（ステップＳ２１０３）。
【００７４】
なお、上述した仲介プログラム開発支援装置による処理では、ＩＤＬファイルおよびアプリケーション情報入力ファイルを用いて、Ｃ固有処理ソースファイル、アプリケーションインタフェース定義ファイル、アプリケーション呼び出し定義ファイル、Ｊａｖａ（登録商標）Ｂｅａｎソースファイル、およびＪａｖａ（登録商標）構造体ソースファイルを生成する場合を説明したが、仲介プログラム開発支援装置１０としては、Ｃ固有処理ソースファイルのみを生成したり、アプリケーション呼び出し定義情報ファイルのみを生成するなど、生成するファイルが選択されることも、それに応じて、入力を受け付けるファイルを選択することも可能である。
【００７５】
［実施例１の効果］
上述してきたように、実施例１によれば、ＣＯＲＢＡを吸収隠蔽したミドルウェア基盤に配備され、バイナリ形式でデータを格納する構造体をミドルウェア基盤とのインタフェースとしてアプリケーション間の連携を仲介する仲介プログラムを、アプリケーションに係るインタフェース定義情報を示すＩＤＬファイルを用いて生成するので、開発者にミドルウェア基盤によって提供される固有のインタフェースの仕様に関する知識が必要とされる場合に比較して、ＩＤＬファイルなどの基本的な情報が用意されれば仲介プログラムが生成されることから、開発者側の負担が小さくなるとともに、複数のアプリケーション間の連携実行環境の性能も向上する結果、複数のアプリケーション間の連携実行環境を、開発から運用に至るまで効率的に行わせることが可能になる。
【００７６】
また、実施例１によれば、ミドルウェア基盤からアプリケーションを呼び出すために必要となるアプリケーション呼び出し定義情報を生成し、アプリケーションに係る関数のインタフェース定義情報を示すアプリケーションインタフェース定義情報を生成するので、ミドルウェア基盤上に複数のアプリケーションが配備されている場合であっても、目的のアプリケーションおよびアプリケーションに係る関数を適切に選択し、実行することができる結果、複数のアプリケーション間の連携実行環境を、確実に実現することが可能になる。
【実施例２】
【００７７】
ところで、これまで実施例１に係る仲介プログラム開発支援装置について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では、実施例２に係る仲介プログラム開発支援装置として、異なる実施例を説明する。
【００７８】
[他のプログラミング言語]
上記の実施例１では、サーバアプリケーションがＣで記述され、クライアントアプリケーションがＪａｖａ（登録商標）で記述された場合を説明したが、本発明はこれに限定されるものではなく、サーバアプリケーションがＣＯＢＯＬで記述され、クライアントアプリケーションがＪａｖａ（登録商標）で記述された場合や、サーバアプリケーションがＪａｖａ（登録商標）で記述され、クライアントアプリケーションがＣで記述された場合など、サーバアプリケーションとクライアントアプリケーションとが他のプログラミング言語で記述された場合にも、本発明を同様に適用することができる。
【００７９】
[他の処理方式]
上記の実施例１では、サーバアプリケーションとクライアントアプリケーションとの連携実行を実現する場合を説明したが、本発明はこれに限定されるものではなく、サーバアプリケーション同士の連携実行を実現する場合や、非同期方式のシステムとの連携を実現する場合など、複数のアプリケーションが他の処理方式で構築される場合にも、本発明を同様に適用することができる。
【００８０】
[コンピュータ]
ところで、上記の実施例１で説明した各種の処理は、あらかじめ用意されたプログラムやパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。そこで、以下では、図２２を用いて、上記の実施例１と同様の機能を有する仲介プログラム開発支援プログラムを実行するコンピュータの一例を説明する。図２２は、仲介プログラム開発支援プログラムを実行するコンピュータを示す図である。
【００８１】
図２２に示すように、仲介プログラム開発支援装置（コンピュータ）４０は、キャッシュ４１、ＲＡＭ４２、ＨＤＤ４３、ＲＯＭ４４、およびＣＰＵ４５をバス４６で接続して構成される。ここで、ＲＯＭ４４には、上記の実施例１と同様の機能を発揮する仲介プログラム開発支援プログラム、つまり、図２２に示すように、Ｃ固有処理生成プログラム４４ａと、Ｊａｖａ（登録商標）Ｂｅａｎ生成プログラム４４ｂとがあらかじめ記憶されている。
【００８２】
そして、ＣＰＵ４５は、これらのプログラム４４ａおよび４４ｂを読み出して実行することで、図２２に示すように、各プログラム４４ａおよび４４ｂは、Ｃ固有処理生成プロセス４５ａおよびＪａｖａ（登録商標）Ｂｅａｎ生成プロセス４５ｂとなる。なお、各プロセス４５ａおよび４５ｂは、図２に示した、Ｃ固有処理生成部３１およびＪａｖａ（登録商標）Ｂｅａｎ生成部３２にそれぞれ対応する。
【００８３】
また、図２２に戻ると、ＨＤＤ４３には、ＩＤＬファイルテーブル４３ａ、アプリケーション情報入力ファイルテーブル４３ｂ、Ｃ固有処理ソースファイルテーブル４３ｃ、アプリケーション呼び出し定義ファイルテーブル４３ｄ、アプリケーションインタフェース定義ファイルテーブル４３ｅ、Ｊａｖａ（登録商標）Ｂｅａｎソースファイルテーブル４３ｆ、およびＪａｖａ（登録商標）構造体ソースファイルテーブル４３ｇが設けられる。なお、各テーブル４３ａ、４３ｂ、４３ｃ、４３ｄ、４３ｅ、４３ｆ、および４３ｇは、図２に示したＩＤＬファイル記憶部２１、アプリケーション情報入力ファイル記憶部２２、Ｃ固有処理ソースファイル記憶部２３、アプリケーション呼び出し定義ファイル記憶部２４、アプリケーションインタフェース定義ファイル記憶部２５、Ｊａｖａ（登録商標）Ｂｅａｎソースファイル記憶部２６、およびＪａｖａ（登録商標）構造体ソースファイル記憶部２７にそれぞれ対応する。
【００８４】
ところで、上記した各プログラム４４ａおよび４４ｂについては、必ずしもＲＯＭ４４に記憶させておく必要はなく、例えば、コンピュータ４０に挿入されるフレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＭＯディスク、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」、または、コンピュータ４０の内外に備えられるハードディスクドライブ（ＨＤＤ）などの「固定用物理媒体」、さらには、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータ４０に接続される「他のコンピュータ（またはサーバ）」に記憶させておき、コンピュータ４０がこれらからプログラムを読み出して実行するようにしてもよい。
【００８５】
[システム構成等]
また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともでき、あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
【００８６】
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
【産業上の利用可能性】
【００８７】
以上のように、本発明に係る仲介プログラム開発支援プログラム、仲介プログラム開発支援方法および仲介プログラム開発支援装置は、各種プログラミング言語で記述された複数のアプリケーション間の連携実行を実現するミドルウェア基盤に配備され、前記アプリケーション間の連携を仲介する仲介プログラムの開発を支援することに有用であり、特に、複数のアプリケーション間の連携実行環境を、開発から運用に至るまで効率的に行わせることに適する。
【図面の簡単な説明】
【００８８】
【図１】実施例１に係る仲介プログラム開発支援装置の概要および特徴を説明するための図である。
【図２】実施例１に係る仲介プログラム開発支援装置の構成を示すブロック図である。
【図３】ＩＤＬファイル記憶部を説明するための図である。
【図４】ＩＤＬファイル記憶部を説明するための図である。
【図５】アプリケーション情報入力ファイル記憶部を説明するための図である。
【図６】Ｃ固有処理ソースファイル記憶部を説明するための図である。
【図７】Ｃ固有処理ソースファイル記憶部を説明するための図である。
【図８】Ｃ固有処理ソースファイル記憶部を説明するための図である。
【図９】Ｃ固有処理ソースファイル記憶部を説明するための図である。
【図１０】Ｃ固有処理ソースファイル記憶部を説明するための図である。
【図１１】Ｃ固有処理ソースファイル記憶部を説明するための図である。
【図１２】アプリケーション呼び出し定義ファイル記憶部を説明するための図である。
【図１３】アプリケーションインタフェース定義ファイル記憶部を説明するための図である。
【図１４】Ｊａｖａ（登録商標）Ｂｅａｎソースファイル記憶部を説明するための図である。
【図１５】Ｊａｖａ（登録商標）Ｂｅａｎソースファイル記憶部を説明するための図である。
【図１６】Ｊａｖａ（登録商標）構造体ソースファイル記憶部を説明するための図である。
【図１７】Ｊａｖａ（登録商標）構造体ソースファイル記憶部を説明するための図である。
【図１８】Ｊａｖａ（登録商標）構造体ソースファイル記憶部を説明するための図である。
【図１９】実施例１に係るＣ固有処理生成部の構成を示すブロック図である。
【図２０】実施例１における仲介プログラム開発支援処理の手順を示すフローチャートである。
【図２１】実施例１におけるＣ固有処理生成処理の手順を示すフローチャートである。
【図２２】仲介プログラム開発支援プログラムを実行するコンピュータを示す図である。
【図２３】ＣＯＲＢＡに従うアプリケーション開発の流れを説明するための図である。
【図２４】ＣＯＲＢＡに従うアプリケーションのソースファイルを説明するための図である。
【図２５】背景技術を説明するための図である。
【図２６】ミドルウェア基盤を説明するための図である。
【符号の説明】
【００８９】
１０  仲介プログラム開発支援装置
１１  入力部
１２  出力部
１３  入出力制御ＩＦ部
２０  記憶部
２１  ＩＤＬファイル記憶部
２２  アプリケーション情報入力ファイル記憶部
２３  Ｃ固有処理ソースファイル記憶部
２４  アプリケーション呼び出し定義ファイル記憶部
２５  アプリケーションインタフェース定義ファイル記憶部
２６  Ｊａｖａ（登録商標）Ｂｅａｎソースファイル記憶部
２７  Ｊａｖａ（登録商標）構造体ソースファイル記憶部
３０  制御部
３１  Ｃ固有処理生成部
３１ａ  Ｃ固有処理ソースファイル生成部
３１ｂ  アプリケーション呼び出し定義情報生成部
３１ｃ  アプリケーションインタフェース定義情報生成部
３２  Ｊａｖａ（登録商標）Ｂｅａｎ生成部
４０  仲介プログラム開発支援装置（コンピュータ）
４１  キャッシュ
４２  ＲＡＭ
４３  ＨＤＤ
４４  ＲＯＭ
４５  ＣＰＵ
４６  バス
【図１】
0005292670.tif 000002
【図２】
0005292670.tif 000003
【図３】
0005292670.tif 000004
【図４】
0005292670.tif 000005
【図５】
0005292670.tif 000006
【図６】
0005292670.tif 000007
【図７】
0005292670.tif 000008
【図８】
0005292670.tif 000009
【図９】
0005292670.tif 000010
【図１０】
0005292670.tif 000011
【図１１】
0005292670.tif 000012
【図１２】
0005292670.tif 000013
【図１３】
0005292670.tif 000014
【図１４】
0005292670.tif 000015
【図１５】
0005292670.tif 000016
【図１６】
0005292670.tif 000017
【図１７】
0005292670.tif 000018
【図１８】
0005292670.tif 000019
【図１９】
0005292670.tif 000020
【図２０】
0005292670.tif 000021
【図２１】
0005292670.tif 000022
【図２２】
0005292670.tif 000023
【図２３】
0005292670.tif 000024
【図２４】
0005292670.tif 000025
【図２５】
0005292670.tif 000026
【図２６】
0005292670.tif 000027