(57)【要約】【課題】使用言語や環境が異なる場合でも煩雑な処理を行うことなくソフトウエアモジュールを連携する。【解決手段】サービス・コンポーネント１１は、当該サービス・コンポーネント１１にアクセスする情報であるインタフェース定義１２からサービス・スタブ１３を生成する。クライアント・コンポーネント２１は、インタフェース定義１２からクライアント・スタブ２２及びメモリハンドラ２３を生成する。クライアント・コンポーネント２１は共有メモリ３０にデータを書き込み、共有メモリ識別子をサービス・スタブ１３、クライアント・スタブ２２を介して、メモリハンドラ２３に供給する。メモリハンドラ２３は、共有メモリ識別子を利用して、共有メモリ３０を自プロセス内にアタッチする。【選択図】図４
2008040722.tif 000002
【特許請求の範囲】
【請求項１】
所定の処理を行う第１のソフトウエアモジュールと、
前記第１のソフトウエアモジュールにアクセスするための情報を定義したインタフェース定義部と、
第１のソフトウエアモジュールと異なる規格の第２のソフトウエアモジュールと、を備え、
前記第１のソフトウエアモジュールは、前記インタフェース定義に基づいて、前記第２のソフトウエアモジュールと連携するためのコードを生成し、
前記第２のソフトウエアモジュールは、前記インタフェース定義に基づいて、前記第１のソフトウエアモジュールと連携するためのコードを生成し、
前記第１及び第２のソフトウエアモジュールは、それぞれ生成したコードを用いて互いに連携処理を行うこと
を特徴とするソフトウエアモジュール連携システム。
【請求項２】
所定の処理を行う第１のソフトウエアモジュールが、前記第１のソフトウエアモジュールにアクセスするための情報を定義したインタフェース定義に基づいて、当該第１のソフトウエアモジュールと異なる規格の第２のソフトウエアモジュールと連携するためのコードを生成し、
前記第２のソフトウエアモジュールは、前記インタフェース定義に基づいて、前記第１のソフトウエアモジュールと連携するためのコードを生成し、
前記第１及び第２のソフトウエアモジュールは、それぞれ生成したコードを用いて互いに連携処理を行うこと
を特徴とするソフトウエアモジュール連携方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、異なる規格のソフトウエアモジュールを連携させるソフトウエアモジュール連携システム及び方法に関する。
【背景技術】
【０００２】
分散処理システムの構築のためのプラットフォームとして、アプリケーションサーバと呼ばれるミドルウェアの利用が多くなっている。アプリケーションサーバ上で動作するソフトウエアモジュールは、Ｊａｖａ（登録商標）等の所定の言語により開発されている。しかし、実際のシステムでは、様々な言語で開発したコンポーネントを利用することが必要であるため、１つの言語のみでシステムを構築するのは困難である。そこで、異なる言語、規格で開発されたソフトウエアモジュールを連携させるための技術が提案されている。
【０００３】
具体的には、アプリケーションサーバとＣＯＲＢＡサーバとの間における連携を容易に行う連携用アダプタが開示されている（特許文献１参照。）。特許文献１では、Ｊ２ＥＥ準拠アプリケーションサーバとＣＯＲＢＡサーバとの間に、連携用アダプタが介在している。Ｊ２ＥＥ準拠アプリケーションサーバは、連携用アダプタにアクセスすることにより、ＣＯＲＢＡサーバへの連携に必要とする処理、設定及びデータの型変換を行うことができる。すなわち、Ｊ２ＥＥ準拠アプリケーションサーバとＣＯＲＢＡサーバ間のように、アーキテクチャの異なるコンポーネント間においては、連携用アダプタを作成することにより、容易に連携することができる。
【０００４】
また、コンポーネント間の連携で複雑なインタフェースを隠蔽するコンポーネントをアダプタとして作成して利用することが開示されている（特許文献２参照。）。また、通信に用いるアプリケーションモジュールの通信部分の定型処理を生成し、開発効率を向上させると共に、トランザクション形式や画面プログラム情報の保守やデバッグ作業において作業が容易に行える技術が開示されている（特許文献３参照。）。特許文献３では、画面設計を行うことによって、トランザクション処理に必要な通信用コードを自動的に生成している。
【特許文献１】特開２００３−１５７２４２号公報
【特許文献２】特開２００３−２０２９８４号公報
【特許文献３】特開平９−２８２１５２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかし、ＣＯＲＢＡやＷＳＤＬ（Ｗｅｂ  Ｓｅｒｖｉｃｅ）のような多機種間の連携フレームワークにおいて、ツールによって自動的に生成されるソースコードは、データのバインディングのみである。そのデータをハンドルするために共通の処理があっても、それぞれのクライアントは似た処理を個々にする必要があり、煩雑であるばかりでなく、誤った処理によって予期せぬ動作を引き起こす可能性がある。
【０００６】
また、Ｊａｖａ（登録商標）  ＲＭＩのような単一言語間の連携フレームワークでは、サーバは、データをハンドルするコード自身をクライアントに送ることができるが、送信のオーバーヘッドが避けられないという問題がある。また、他の言語や環境のソフトウエアモジュールと連携することができない問題もある。
【０００７】
本発明は、上述した課題を解決するために提案されたものであり、使用言語や環境が異なる場合でも煩雑な処理を行うことなくソフトウエアモジュールを連携することができるソフトウエアモジュール連携システム及び方法を提供することを目的とする。
【課題を解決するための手段】
【０００８】
本発明のソフトウエアモジュール連携システムは、所定の処理を行う第１のソフトウエアモジュールと、前記第１のソフトウエアモジュールにアクセスするための情報を定義したインタフェース定義部と、第１のソフトウエアモジュールと異なる規格の第２のソフトウエアモジュールと、を備え、前記第１のソフトウエアモジュールは、前記インタフェース定義に基づいて、前記第２のソフトウエアモジュールと連携するためのコードを生成し、前記第２のソフトウエアモジュールは、前記インタフェース定義に基づいて、前記第１のソフトウエアモジュールと連携するためのコードを生成し、前記第１及び第２のソフトウエアモジュールは、それぞれ生成したコードを用いて互いに連携処理を行うことを特徴とする。
【０００９】
また、本発明のソフトウエアモジュール連携方法は、所定の処理を行う第１のソフトウエアモジュールが、前記第１のソフトウエアモジュールにアクセスするための情報を定義したインタフェース定義に基づいて、当該第１のソフトウエアモジュールと異なる規格の第２のソフトウエアモジュールと連携するためのコードを生成し、前記第２のソフトウエアモジュールは、前記インタフェース定義に基づいて、前記第１のソフトウエアモジュールと連携するためのコードを生成し、前記第１及び第２のソフトウエアモジュールは、それぞれ生成したコードを用いて互いに連携処理を行うことを特徴とする。
【００１０】
第１及び第２のソフトウエアモジュールは、それぞれ所定のサービス（データ処理）を行うものであれば、同一のハードウェアにあっても、ネットワークを介して異なるハードウェアにあってもよい。インタフェース定義部は第１のソフトウエアモジュールにアクセスするための情報を定義したものであり、これに基づいて第１及び第２のソフトウエアモジュールと連携するためのコードがそれぞれ生成される。そして、前記第１及び第２のソフトウエアモジュールは、それぞれ生成したコードを用いて互いに連携処理を行う。
【００１１】
したがって、上記発明は、使用言語や環境が異なる場合でも、インタフェース定義部に基づいて第１及び第２のソフトウエアモジュールと連携するためのコードをそれぞれ生成することにより、煩雑な処理を行うことなく第１及び第２のソフトウエアモジュールを連携することができる。
【発明の効果】
【００１２】
本発明は、使用言語や環境が異なる場合でも煩雑な処理を行うことなくソフトウエアモジュールを連携することができる。
【発明を実施するための最良の形態】
【００１３】
以下、本発明の好ましい実施の形態について図面を参照しながら詳細に説明する。
【００１４】
図１は、本発明の実施の形態に係る連携システムの構成を示す図である。
【００１５】
連携システムは、所定のサービスを提供するサーバ１０と、サーバ１０に対してサービスを依頼するクライアント２０と、サーバ１０とクライアント２０の間で使用される共有メモリ３０と、を備えている。サーバ１０は、クライアント２０、共有メモリ３０はネットワークを介して相互に接続されている。
【００１６】
サーバ１０及びクライアント２０は、例えばコンピュータで構成され、ネットワークを介してデータの入出力を行う入出力ポートと、データ、ソフトウエアコンポーネント等を記憶する記憶装置と、データの生成・配信、ソフトウエアコンポーネントの制御等に関する演算処理を行う演算回路と、を有している。これにより、サーバ１０及びクライアント２０は、機能的には次のような構成を有する。
【００１７】
サーバ１０は、所定のサービスを行うサービス・コンポーネント１１と、サービス・コンポーネント１１にアクセスする情報であるインタフェース定義１２と、を有している。クライアント２０は、クライアント・コンポーネント２１を有している。
【００１８】
図２は、インタフェース定義１２を示す図である。インタフェース定義１２は、ＸＭＬ文書によって構成されている。インタフェース定義１２は、１つのアクセスポイント情報（ネットワーク上で一意に識別可能なアクセス先に関する情報）を定義するアクセスポイント情報定義部（２〜６行目）と、それに対応する１つ以上のメソッド（サービスの実体を示す情報）を定義するメソッド定義部（７〜１９行目）と、仮想コードを定義する仮想コード定義部（２０〜３９行目）を含んでいる。なお、インタフェース定義１２が示すサービス（サービス・コンポーネント１１）は、画像の名前を受け取り、その名前で示される画像のデータを返すサービスである。この仮想コードは、共有メモリ３０を自プロセスにアタッチする機種依存の仮想コードである。
【００１９】
アクセスポイント情報定義部は、<endPoint>...</endPoint>で定義された情報であり、ネットワークアドレスの表現方法とそのアドレス（<address type=“...”>...</adress>）、ポート番号（<port>...</port>）、インタフェース利用上の注意点（<restriction>...</restriction>）を有する。通信方法は “名前つきパイプ”であり（３行目）、ポート番号はデフォルトを用いる。インタフェース利用上の注意点（制約）は、ネットワーク上に送受されるデータのうち直接伝達が困難な情報が含まれているか否かを示している。図２では、「sharedMemory」（５行目）が挙げられている。これは、制約条件として共有メモリの使用が可能であることを示す。他には「fileDescriptor」や「localFile」などがある。
【００２０】
メソッド定義部は、<method name=”…”>から</method>で定義された情報であり、上記のアクセスポイントに対して、一つ以上存在し、実際のサービスの実体に対応する。具体的には、個々のメソッド定義部は、サービスへの入力情報（<input>…</input>）と、サービスからの出力情報（<output>…</output>）、仮想コード及びその実行場所（<wrapper type=”…”>…</wrapper>）を含んでいる。
【００２１】
よって、メソッド定義部は、サービス・コンポーネント１１のサービスの名称（GetImagePage）と、サービス・コンポーネント１１とクライアント・コンポーネント２１の間の通信路でのデータの形式（入力情報及び出力情報）を示している。クライアント・コンポーネント２１からサービス・コンポーネント１１への入力は、画像の名前であり、種別は文字列である（図２の９行目）。一方、出力は、画像の大きさ（整数）、幅（整数）、高さ（整数）、深さ（整数）、識別子（整数）、種別（整数）である（図２の１２〜１７行目）。ここまでは、ＣＯＲＢＡやＷＳＤＬといった、既存のインタフェース定義とほぼ同様の内容である。
【００２２】
仮想コード定義部は、<wrapper type=”cliant”>から</wrapper>で定義された情報であり、関数の実体を定義する。
【００２３】
具体的には、仮想コード定義部は、関数の名称（<method name=”…”>）、関数の定義（<transform>）、サービスの情報や入出力情報と関数内の変数の対応(マッピング)（<source>…</source>）、関数の種別(コンパイル言語、スクリプト言語)と異常時の処理、実行する関数の仮想コード（<pseudo type=”…” exception=”…” />）を含んでいる。
【００２４】
なお、図２の２０行目は、仮想コードはクライアントサイドで動作することを示している。２１行目は、対象とするサービス（GetImagePage）を示している。
【００２５】
「サービスの情報や入出力情報と関数内の変数の対応」は、どこの場所(category)から、どの要素(element)の値を、どんな形式(type)で仮想コード内に移すか(参照可能か)を示す。また、最後に示す属性(wrapped)で、参照した変数を、関数の利用者に対して開示するかどうかを示し、開示しない場合には、関数の戻り値として定義されることはない。すなわち、データの変換を行うための入力するデータとして、サービスのアドレス、サービスの出力情報のうち、画像の大きさ、識別子、種別を利用することを宣言している。このうち、アドレスと識別子は隠蔽されて、クライアントの関数から見えないようになっていることも示されている。
【００２６】
なお、仮想コードの文法は、一般的な手続き言語であるＣ言語を簡易化した仕様を用い、Ｕｎｉｘ（登録商標）やＷｉｎｄｏｗｓ（登録商標）などが提供するシステムコールとは異なるシステムコールを持つ。そして、連携システムでは、次のようにしてスタブ、メモリハンドラが生成される。
【００２７】
最初に、サービス・コンポーネント１１は、上記のインタフェース定義１２に基づいて、サービス側のスタブコードであるサービス・スタブ１３を生成する。このとき、インタフェース定義１２はサービス側のコードを含んでいないため、サービス・コンポーネント１１は、インタフェース定義１２に記述されたサービス名とデータの形式に基づいてサービス・スタブ１３を生成する。そして、サービス・コンポーネント１１は、この生成されたコードと実装したコードをリンクすることによって、実際のサービスを開始する。
【００２８】
つぎに、クライアント・コンポーネント２１は、サービス・コンポーネント１１のサービスを利用するため、サービス・コンポーネント１１が発行したインタフェース定義１２を用いて、クライアント側のスタブコードであるクライアント・スタブ２２及び実行可能なメモリハンドラ２３を生成する。
【００２９】
インタフェース定義１２は、クライアント側のコードを含んでいるため、共有メモリ３０をハンドするためのコードを含んでいる。ここでは、クライアント２０は、ＮｅｔＢＳＤ  ＯＳ上で動作するＣ言語で作成されるものとし、そこで生成されるコードは、以下のようになる。
【００３０】
図３は、クライアント・スタブ２２及びメモリハンドラ２３のコードを示す図である。
【００３１】
インタフェース定義１２（図２）の２３行目によると、グローバルな変数であるサービスのアドレスを利用することがわかる。図３の９行目は、サービスのアドレス利用の宣言を示している。そして、このクライアント・スタブ２２は、サービス・コンポーネント１１の提供するサービスGetImagePageの上位にくるインタフェースであり、そのインタフェース宣言から１１行目の関数の型が決定される。
【００３２】
この結果、図４に示すように、サーバ１０は、サービス・コンポーネント１１、インタフェース定義１２、サービス・スタブ１３を備えている。また、クライアント２０は、クライアント・コンポーネント２１、クライアント・スタブ２２、メモリハンドラ２３を備えている。
【００３３】
以上のように構成された連携システムでは、次のようにしてソフトウエアモジュール間の連携が行われる。
【００３４】
サービス・コンポーネント１１は、共有メモリ３０を自身のコードにより、共有メモリ３０を自プロセス内にアタッチして（ステップＳ１）、サービスを開始する。
【００３５】
クライアント２０において、クライアント・コンポーネント２１は、サービス・コンポーネント１１にサービスを要求するために、クライアント・スタブ２２にアクセスする（ステップＳ２）。クライアント・スタブ２２は、図３の１９行目に基づいてクライアント・コンポーネント２１を呼び出すべく、クライアント・コンポーネント２１の要求をサーバ１０に転送する（ステップＳ３）。
【００３６】
サーバ１０では、サービス・スタブ１３は、メモリハンドラ２３から送られた要求をサービス・コンポーネント１１に転送する（ステップＳ４）。サービス・コンポーネント１１は、データを共有メモリ３０にデータを書き込んで、共有メモリ識別子を付けて、サービス・スタブ１３に応答する（ステップＳ５）。サービス・スタブ１３は、その応答をクライアント２０に転送する（ステップＳ６）。
【００３７】
クライアント２０では、クライアント・スタブ２２は、サービス・スタブ１３から送られた共有メモリ識別子をメモリハンドラ２３に転送する（ステップＳ７）。
【００３８】
メモリハンドラ２３は、クライアント・スタブ２２から受け取った共有メモリ識別子を、インタフェース定義１２（図２）の２６行目から３６行目までの仮想コードから定義されたアルゴリズムに基づくコードを用いて、次のように処理を行う。
【００３９】
メモリハンドラ２３は、共有メモリ識別子を利用して、共有メモリ３０を自プロセス内にアタッチする（ステップＳ８）。さらに、メモリハンドラ２３は、アタッチした共有メモリ３０のアドレスを付けて、クライアント・コンポーネント２１に応答する（ステップＳ９）。
【００４０】
具体的には、メモリハンドラ２３は、最初に共有メモリ識別子をローカルの識別子に変換し（図４の２２行目）、フラグをクリアして（２３行目）、共有メモリ３０を自アドレスにアタッチ（２４行目）する。そして、メモリハンドラ２３は、共有メモリ３０上の後端のアドレスを参照して、マジックナンバーと比較を行い、ページデータであることを確認（２５行目）する。このとき、マジックナンバーが正しくなければ、メモリハンドラ２３は、アタッチした共有メモリ３０をデタッチして、例外処理に移行（２６、２７行目）する。正常であれば、メモリハンドラ２３は、共有メモリ３０の大きさからマジックナンバー分の大きさを引いて（２９行目）、アタッチした共有メモリ３０のアドレスをクライアント・コンポーネント２１に供給する（３０行目）。
【００４１】
クライアント・コンポーネント２１は、受け取ったメモリアドレスに基づいて共有メモリ３０にアクセスすることによって、クライアント・コンポーネント２１が共有メモリ３０に書き込んだデータを読み出すことができる。
【００４２】
ここで、従来は、上記のクライアント側のコードは、すべてのクライアントで設計し、実装しなければならない。この実施の形態であれば、共有メモリ３０を自プロセスにアタッチするための方法や、マジックナンバーについての知識がなければ、利用することはできない。共有メモリ３０の利用方法であれば、一般書籍などによって知識を得ることでコードを作成することが可能となるかもしれないが、マジックナンバーのような、ある意味ローカルルールのようなものは、文章や図などで記述された仕様書を元にして、すべてのクライアントが独自に実装しなければならず、大変効率が悪い。特に、仕様が変更された場合には、それを周知徹底し、全クライアントが実装したコードを変更する必要が生じてしまう。
【００４３】
これに対して、本発明の実施の形態に係る連携システムは、サービス・コンポーネント１１にアクセスするためのインタフェース定義１２を用意し、インタフェース定義１２に基づいてサービス・スタブ１３、クライアント・スタブ２２及びメモリハンドラ２３を生成する。そして、連携システムは、サービス・スタブ１３、クライアント・スタブ２２、メモリハンドラ２３を介して、サービス・コンポーネント１１とクライアント・コンポーネント２１の間でデータの送受信を行う。
【００４４】
これにより、連携システムは、サービス・コンポーネント１１とクライアント・コンポーネント２１との規格、環境が異なる場合であっても、インタフェース定義１２に基づいてスタブ１３、２３やメモリハンドラ２３を生成するので、連携させるための重複処理を省くことができる。また、上記連携システムで生成されたコードは、スタブのコードと同様に、それぞれのコンポーネントのアーキテクチャに合致した実行コードとなるため、転送の必要もなく、処理の効率がよい。
【００４５】
なお、本発明は、上述した実施の形態に限定されるものではなく、特許請求の範囲に記載された範囲内で設計上の変更をされたものにも適用可能であるのは勿論である。
【００４６】
例えば、上述した実施の形態では、サーバ１０とクライアント２０がメモリを共有しているという前提でコードを生成したが、本発明はこれに限定されるものではない。すなわち、メモリを共有しない場合には、メモリの利用形態を元に、メモリ内容を転送などのコードを生成することもまったく問題がない。
【００４７】
さらに、上述した実施の形態では、静的にコードを生成して、クライアントに結合するケースを説明したが、これを実行時に動的に結合すれば、仕様変更にも柔軟に対応が可能である。例えば上記実施形態では、マジックナンバーが「０ｘａ５ａ５」であったが、動的リンクであればサービス・コンポーネント１１とクライアント・コンポーネント２１間のインタフェースに齟齬が生じる恐れがないので、マジックナンバーを「０ｘｆｅｆｅ」に変更することも可能である。
【図面の簡単な説明】
【００４８】
【図１】本発明の実施の形態に係る連携システムの構成を示す図である。
【図２】インタフェース定義を示す図である。
【図３】クライアント・スタブ２２及びメモリハンドラ２３のコードを示す図である。
【図４】サービス・スタブ、クライアント・コンポーネント、クライアント・スタブが生成された状態の連携システムの構成を示す図である。
【符号の説明】
【００４９】
１０  サーバ
１１  サービス・コンポーネント
１２  インタフェース定義
１３  サービス・スタブ
２０  クライアント
２１  クライアント・コンポーネント
２２  クライアント・スタブ
２３  メモリハンドラ
【図１】
2008040722.tif 000003
【図２】
2008040722.tif 000004
【図３】
2008040722.tif 000005
【図４】
2008040722.tif 000006