(57)【要約】【課題】ＡＰＩを変更することに起因する生産性の低下を回避し、ＡＰＩを変更せずに実質的な機能拡張を実現する。【解決手段】プログラム言語処理実行系に備わるリフレクション機能を用いて、旧ＡＰＩを実装するメソッドの呼び出しに際して、メタレベルの処理（処理系レベル、クラスやメソッドなどメタオブジェクトの振る舞いを実行するレベル）に制御を移し、メタレベルにおいて旧メソッドの実行を横取りし、旧メソッドオブジェクトに対応する新メソッドを検索し、メタレベル処理内部で当該旧メソッドに代わって実行する。これにより、クライアントは、旧ＡＰＩを呼び出すコードを変更することなく、そのまま実行するだけで、メタレベルにおいて新しいＡＰＩに対応する処理が代替実行される。【選択図】  図１
2004246789.tif 000002
【特許請求の範囲】
【請求項１】
ＡＰＩを介して協調動作する複数プログラムの連携を管理し、プログラム間の規約であるＡＰＩの変更に際し、ＡＰＩ互換性を維持しながら旧ＡＰＩ機能を新ＡＰＩ機能へ拡張するプログラム機能拡張システムであって、
旧ＡＰＩ機能を介して協調動作する複数のプログラムの実行中に、旧ＡＰＩ機能を実装するメソッドオブジェクトに対応した代替処理オブジェクトを動的に登録・変更・削除する代替処理管理手段と、
旧ＡＰＩ機能の起動・実行を制御するメタレベル処理において前記代替処理管理手段を用いて旧ＡＰＩ機能のメソッドオブジェクトをキーに、代替処理オブジェクトを検索・取得する代替処理オブジェクト取得手段と、
ＡＰＩ拡張に伴う追加情報とＡＰＩからの返却情報との整合性を維持しながら旧ＡＰＩ機能の実行に代わって、前記代替処理オブジェクト取得手段で取得した代替処理オブジェクトを実行する代替処理オブジェクト実行手段と、
前記代替処理オブジェクト実行手段の代替処理オブジェクト実行に際し、代替機能と旧ＡＰＩ機能と融合した処理を実行する融合処理実行手段と
を具備することを特徴とするプログラム機能拡張システム。
【請求項２】
代替処理管理手段は、キーとして旧ＡＰＩ処理オブジェクトと、新ＡＰＩ処理オブジェクトとを対応付けて格納するハッシュテーブルで実現されることを特徴とする請求項１記載のプログラム機能拡張システム。
【請求項３】
前記代替処理管理手段は、旧ＡＰＩ処理オブジェクトをキーに新ＡＰＩ処理オブジェクトを検索した結果、キーに対応する値が空であれば、旧ＡＰＩ処理をそのまま実行して結果を返す一方、キーに対応する値が空でなく新ＡＰＩ処理オブジェクトが割り当てられている場合は、新ＡＰＩ処理オブジェクトを取り出し、代替処理を実行するためのメッセージを発行することを特徴とする請求項２記載のプログラム機能拡張システム。
【請求項４】
前記代替処理管理手段は、Ｓｉｎｇｌｅｔｏｎデザインパターンに基づいて構成されていることを特徴とする請求項２記載のプログラム機能拡張システム。
【請求項５】
ＡＰＩを介して協調動作する複数プログラムの連携を管理し、プログラム間の規約であるＡＰＩの変更に際し、ＡＰＩ互換性を維持しながら旧ＡＰＩ機能を新ＡＰＩ機能へ拡張するプログラム機能拡張方法であって、
旧ＡＰＩ機能を介して協調動作する複数のプログラムの実行中に、旧ＡＰＩ機能を実装するメソッドオブジェクトに対応した代替処理オブジェクトを動的に登録・変更・削除し、
旧ＡＰＩ機能の起動・実行を制御するメタレベル処理において旧ＡＰＩ機能のメソッドオブジェクトをキーに、代替処理オブジェクトを検索・取得し、
ＡＰＩ拡張に伴う追加情報とＡＰＩからの返却情報との整合性を維持しながら旧ＡＰＩ機能の実行に代わって、前記取得された代替処理オブジェクトを実行し、
前記代替処理オブジェクト実行において、代替機能と旧ＡＰＩ機能と融合した処理を実行することを特徴とするプログラム機能拡張方法。
【請求項６】
ＡＰＩを介して協調動作する複数プログラムの連携を管理し、プログラム間の規約であるＡＰＩの変更に際し、ＡＰＩ互換性を維持しながら旧ＡＰＩ機能を新ＡＰＩ機能へ拡張するプログラム機能拡張方法であって、
プログラム言語処理実行系に備わるリフレクション機能を用いて、旧ＡＰＩ機能を実装するメソッドの呼び出しに際して、メタレベルの処理に制御を移し、メタレベルにおいて旧メソッドの実行を横取りし、旧メソッドオブジェクトに対応する新メソッドを検索し、メタレベル処理内部で当該旧メソッドに代わって新メソッドを実行することを特徴とするプログラム機能拡張方法。
【請求項７】
旧ＡＰＩに対応する機能を実現する旧ＡＰＩ処理オブジェクトと、新ＡＰＩに対応する機能を実現する新ＡＰＩ処理オブジェクトとを対応づけて管理することを特徴とする請求項６記載のプログラム機能拡張方法。
【請求項８】
旧ＡＰＩ機能を介して協調動作する複数のプログラムの実行中に、旧ＡＰＩ機能を実装するメソッドオブジェクトに対応した代替処理オブジェクトを動的に登録・変更・削除するステップと、
旧ＡＰＩ機能の起動・実行を制御するメタレベル処理において旧ＡＰＩ機能のメソッドオブジェクトをキーに、代替処理オブジェクトを検索・取得するステップと、
ＡＰＩ拡張に伴う追加情報とＡＰＩからの返却情報との整合性を維持しながら旧ＡＰＩ機能の実行に代わって、前記取得された代替処理オブジェクトを実行するステップと、
前記代替処理オブジェクト実行において、代替機能と旧ＡＰＩ機能と融合した処理を実行するステップと
をコンピュータに実行させることを特徴とするプログラム機能拡張プログラム。
【請求項９】
旧ＡＰＩ機能を介して協調動作する複数のプログラムの実行中に、旧ＡＰＩ機能を実装するメソッドオブジェクトに対応した代替処理オブジェクトを動的に登録・変更・削除するステップと、
旧ＡＰＩ機能の起動・実行を制御するメタレベル処理において旧ＡＰＩ機能のメソッドオブジェクトをキーに、代替処理オブジェクトを検索・取得するステップと、
ＡＰＩ拡張に伴う追加情報とＡＰＩからの返却情報との整合性を維持しながら旧ＡＰＩ機能の実行に代わって、前記取得された代替処理オブジェクトを実行するステップと、
前記代替処理オブジェクト実行において、代替機能と旧ＡＰＩ機能と融合した処理を実行するステップと
をコンピュータに実行させるプログラム機能拡張プログラムを記録したことを特徴とする記録媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ＡＰＩを介して協調動作するプログラムを連携・管理する機構に係り、特に互換性を維持しながら機能拡張するプログラム機能拡張システム、プログラム機能拡張方法、プログラム機能拡張プログラムおよび記録媒体に関する。
【０００２】
【従来の技術】
インターネット上のサービス開発において生産性を向上し開発時間を短縮するための方法として、サービス連携、Ｗｅｂサービスといった技術領域がある。また、ＥＡＩ（Ｅｎｔｅｒｐｒｉｓｅ  Ａｐｐｌｉｃａｔｉｏｎ  Ｉｎｔｅｇｒａｔｉｏｎ）技術等も既存システムを連携させてサービスを構築する方法である（例えば、非特許文献１、２参照）。
【０００３】
連携サービス機構上では、複数のサービスが協調動作する。このような状況において、機能を提供するプログラムとそれを利用するプログラムとの間のインタフェースがＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）である。
【０００４】
ＡＰＩ提供プログラム（サーバ：Ｓｅｒｖｅｒ）は、当該機能を実装し、ＡＰＩとして公開する一方で、ＡＰＩ利用側プログラム（クライアント：Ｃｌｉｅｎｔ）は、自らのアプリケーションロジックを実装する中で当該ＡＰＩに基づいて機能を呼び出すため、ＡＰＩは、両者が遵守すべき規約（プロトコル）と見なすことができる。
【０００５】
従来、ＣＯＲＢＡ技術やＪ２ＥＥ（Ｊａｖａ（登録商標）２  Ｅｎｔｅｒｐｒｉｓｅ  Ｅｄｉｔｉｏｎ）におけるＥＪＢ（Ｅｎｔｅｒｐｒｉｓｅ  ＪＡＶＡ（登録商標）Ｂｅａｎｓ）技術では、ネーミングおよびディレクトリ機能を提供する機能を用いて、名前で間接的にインタフェースを参照する手法がとられていた（例えば、非特許文献３、４参照）。しかしながら、ＡＰＩ利用側プログラム（クライアント）側は、新しい機能を呼び出す部分では、新しいインタフェースを意識する必要があった。すなわち、クライアント側の呼び出し部分でプログラムの修正が必須であった。また、インタフェース単位での機能の差し替えは可能であるが、オブジェクト・メソッド単位での機能の交換は想定していない。
【０００６】
【非特許文献１】
日野隆一  外１名、「プラットフォーム連携によるＡＰ開発手法の提案」，電子情報通信学会，２００２年３月２２日発行、電子情報通信学会技術研究報告ＫＢＳＥ２００１−７２，ｐｐ．５７−６４
【非特許文献２】
堀用桂太郎  外１名、「システム間の連携Ｉ／Ｆとその拡張による影響の考察」，電子情報通信学会，２００２年１２月１２日発行、電子情報通信学会技術研究報告ｖｏ１．１０２、Ｎ０．５０３，ｐｐ．７−１２
【非特許文献３】
オーファリ、ロバート他、「ＪＡＶＡ（登録商標）＆ＣＯＲＢＡ  Ｃ／Ｓ  プログラミング」，日経ＢＰ社出版，１９９９年１月発行，ｐｐ．１１、６２，３３５３，３５９
【非特許文献４】
マイケルガードレー他、「Ｊ２ＥＥ＆ＢＥＡ  ＷｅｂＬｏｇｉｃ  Ｓｅｒｖｅｒ  開発者ガイド」、ピアソンエデスケーション、２００１年１１月発行、ｐｐ．２６，１７３−２０８，２３６
【０００７】
【発明が解決しようとする課題】
ところで、プログラムの開発プロセスでは、一般に、大小さまざまなレベルで仕様変更や機能拡張が発生する。既存システムを連携する開発環境においても同様に、構成要素である個々のシステムが独自に機能拡張する、全体として不足する機能を補う要求が発生するなどの理由から、ＡＰＩ変更が避けられないケースが少なからず存在する。
【０００８】
単純なバグの修正など、インタフェースを変えない範囲での修正については、影響範囲がインタフェースの外部に及ばないため、修正・テストのコストを抑えることが可能であるが、上述した通り、ＡＰＩは、それを介して協調動作するプログラム間の規約であるため、当該ＡＰＩの変更によってそれを遵守しているすべてのプログラムに影響が及ぶ。これは本質的に不可避な問題である。
【０００９】
したがって、ＡＰＩの変更に伴い、ＡＰＩを提供するサーバおよびそれを利用する全てのクライアントにおける追加機能の実装および試験作業が必須となり、結果として開発コストが増加する。
【００１０】
また、変更前のＡＰＩで動作試験が済んだ定常状態の品質に対し、新たな機能追加を行うことは品質を低下する要因になりかねず、品質面でのリスクを高めることになる。
【００１１】
さらに、ＡＰＩ拡張によってインタフェースが変わることに対し、互換性を保証するための機能追加および試験コストも含めると、開発全体のコストをより一層増加させる問題が生じている。
【００１２】
この発明は上述した事情に鑑みてなされたもので、ＡＰＩを変更することに起因する生産性の低下を回避し、ＡＰＩを変更せずに実質的な機能拡張を実現することができるプログラム機能拡張システム、プログラム機能拡張方法、プログラム機能拡張プログラムおよび記録媒体を提供することを目的とする。
【００１３】
【課題を解決するための手段】
上述した問題点を解決するために、請求項１記載の発明では、ＡＰＩを介して協調動作する複数プログラムの連携を管理し、プログラム間の規約であるＡＰＩの変更に際し、ＡＰＩ互換性を維持しながら旧ＡＰＩ機能を新ＡＰＩ機能へ拡張するプログラム機能拡張システムであって、旧ＡＰＩ機能を介して協調動作する複数のプログラムの実行中に、旧ＡＰＩ機能を実装するメソッドオブジェクトに対応した代替処理オブジェクトを動的に登録・変更・削除する代替処理管理手段と、旧ＡＰＩ機能の起動・実行を制御するメタレベル処理において前記代替処理管理手段を用いて旧ＡＰＩ機能のメソッドオブジェクトをキーに、代替処理オブジェクトを検索・取得する代替処理オブジェクト取得手段と、ＡＰＩ拡張に伴う追加情報とＡＰＩからの返却情報との整合性を維持しながら旧ＡＰＩ機能の実行に代わって、前記代替処理オブジェクト取得手段で取得した代替処理オブジェクトを実行する代替処理オブジェクト実行手段と、前記代替処理オブジェクト実行手段の代替処理オブジェクト実行に際し、代替機能と旧ＡＰＩ機能と融合した処理を実行する融合処理実行手段とを具備することを特徴とする。
【００１４】
また、請求項２記載の発明では、請求項１記載のプログラム機能拡張システムにおいて、代替処理管理手段は、キーとして旧ＡＰＩ処理オブジェクトと、新ＡＰＩ処理オブジェクトとを対応付けて格納するハッシュテーブルで実現されることを特徴とする。
【００１５】
また、請求項３記載の発明では、請求項２記載のプログラム機能拡張システムにおいて、前記代替処理管理手段は、旧ＡＰＩ処理オブジェクトをキーに新ＡＰＩ処理オブジェクトを検索した結果、キーに対応する値が空であれば、旧ＡＰＩ処理をそのまま実行して結果を返す一方、キーに対応する値が空でなく新ＡＰＩ処理オブジェクトが割り当てられている場合は、新ＡＰＩ処理オブジェクトを取り出し、代替処理を実行するためのメッセージを発行することを特徴とする。
【００１６】
また、請求項４記載の発明では、請求項２記載のプログラム機能拡張システムにおいて、前記代替処理管理手段は、Ｓｉｎｇｌｅｔｏｎデザインパターンに基づいて構成されていることを特徴とする。
【００１７】
また、上述した問題点を解決するために、請求項５記載の発明では、ＡＰＩを介して協調動作する複数プログラムの連携を管理し、プログラム間の規約であるＡＰＩの変更に際し、ＡＰＩ互換性を維持しながら旧ＡＰＩ機能を新ＡＰＩ機能へ拡張するプログラム機能拡張方法であって、旧ＡＰＩ機能を介して協調動作する複数のプログラムの実行中に、旧ＡＰＩ機能を実装するメソッドオブジェクトに対応した代替処理オブジェクトを動的に登録・変更・削除し、旧ＡＰＩ機能の起動・実行を制御するメタレベル処理において旧ＡＰＩ機能のメソッドオブジェクトをキーに、代替処理オブジェクトを検索・取得し、ＡＰＩ拡張に伴う追加情報とＡＰＩからの返却情報との整合性を維持しながら旧ＡＰＩ機能の実行に代わって、前記取得された代替処理オブジェクトを実行し、前記代替処理オブジェクト実行において、代替機能と旧ＡＰＩ機能と融合した処理を実行することを特徴とする。
【００１８】
また、上述した問題点を解決するために、請求項６記載の発明では、ＡＰＩを介して協調動作する複数プログラムの連携を管理し、プログラム間の規約であるＡＰＩの変更に際し、ＡＰＩ互換性を維持しながら旧ＡＰＩ機能を新ＡＰＩ機能へ拡張するプログラム機能拡張方法であって、プログラム言語処理実行系に備わるリフレクション機能を用いて、旧ＡＰＩ機能を実装するメソッドの呼び出しに際して、メタレベルの処理に制御を移し、メタレベルにおいて旧メソッドの実行を横取りし、旧メソッドオブジェクトに対応する新メソッドを検索し、メタレベル処理内部で当該旧メソッドに代わって新メソッドを実行することを特徴とする。
【００１９】
また、請求項７記載の発明では、請求項６記載のプログラム機能拡張方法において、旧ＡＰＩに対応する機能を実現する旧ＡＰＩ処理オブジェクトと、新ＡＰＩに対応する機能を実現する新ＡＰＩ処理オブジェクトとを対応づけて管理することを特徴とする。
【００２０】
また、上述した問題点を解決するために、請求項８記載の発明では、旧ＡＰＩ機能を介して協調動作する複数のプログラムの実行中に、旧ＡＰＩ機能を実装するメソッドオブジェクトに対応した代替処理オブジェクトを動的に登録・変更・削除するステップと、旧ＡＰＩ機能の起動・実行を制御するメタレベル処理において旧ＡＰＩ機能のメソッドオブジェクトをキーに、代替処理オブジェクトを検索・取得するステップと、ＡＰＩ拡張に伴う追加情報とＡＰＩからの返却情報との整合性を維持しながら旧ＡＰＩ機能の実行に代わって、前記取得された代替処理オブジェクトを実行するステップと、前記代替処理オブジェクト実行において、代替機能と旧ＡＰＩ機能と融合した処理を実行するステップとをコンピュータに実行させることを特徴とする。
【００２１】
また、上述した問題点を解決するために、請求項９記載の発明では、旧ＡＰＩ機能を介して協調動作する複数のプログラムの実行中に、旧ＡＰＩ機能を実装するメソッドオブジェクトに対応した代替処理オブジェクトを動的に登録・変更・削除するステップと、旧ＡＰＩ機能の起動・実行を制御するメタレベル処理において旧ＡＰＩ機能のメソッドオブジェクトをキーに、代替処理オブジェクトを検索・取得するステップと、ＡＰＩ拡張に伴う追加情報とＡＰＩからの返却情報との整合性を維持しながら旧ＡＰＩ機能の実行に代わって、前記取得された代替処理オブジェクトを実行するステップと、前記代替処理オブジェクト実行において、代替機能と旧ＡＰＩ機能と融合した処理を実行するステップとをコンピュータに実行させるプログラム機能拡張プログラムを記録したことを特徴とする。
【００２２】
この発明では、プログラム言語処理実行系に備わるリフレクション機能を用いて、旧ＡＰＩを実装するメソッドの呼び出しに際して、メタレベルの処理（処理系レベル、クラスやメソッドなどメタオブジェクトの振る舞いを実行するレベル）に制御を移し、メタレベルにおいて旧メソッドの実行を横取りし、旧メソッドオブジェクトに対応する新メソッドを検索し、メタレベル処理内部で当該旧メソッドに代わって実行する。したがって、ＡＰＩ利用側は、旧ＡＰＩを呼び出すコードを変更することなくそのまま実行するだけで、メタレベルにおいて新しいＡＰＩに対応する処理が代替実行され、結果として、ＡＰＩの互換性を保ったまま機能拡張が可能になる。
【００２３】
【発明の実施の形態】
以下、図面を用いて本発明の実施の形態を説明する。
【００２４】
図１は、本発明の実施形態によるプログラム機能拡張方法の作用および効果を示す概念図である。なお、本実施形態によるプログラム機能拡張方法は、ＪＡＶＡ（登録商標）言語、Ｐｙｔｈｏｎ言語などリフレクション機能を有する言語処理系を利用する。図では、旧ＡＰＩ機能を新ＡＰＩ機能に拡張する状況で、新ＡＰＩでは新たに１つ追加パラメタが必要になる事例を示している。サーバプログラム１０において、ＡＰＩを実装・公開しているオプジェクトをｒｅｃｅｉｖｅｒとする。また、クライアントプログラム２０において、サーバのＡＰＩを呼び出すオブジェクトをｓｅｎｄｅｒとする。サーバプログラム１０とクライアントプログラム２０とは、同一の言語処理実行系（ＪＡＶＡ（登録商標）のＶＭ相当）に含まれていてもよく、また、ＪＡＶＡ（登録商標）  ＲＭＩなどの分散オブジェクト機構を介して連携していてもよい。
【００２５】
旧ＡＰＩ機能４０は、入力として２つのオブジェクト（ｘ，ｙ）を与え，結果として「ｖ」を出力する機能で、ｒｅｃｅｉｖｅｒオプジェクトのｍｅｔｈｏｄメソッドで実現されているものとする。一方、新ＡＰＩ機能５０は、入力として３つのオブジェクト（ｘ，ｙ，ｚ）を与え、結果として「φ（Ｖ）」を出力する機能であるが、予めｒｅｃｅｉｖｅｒオブジェクトのｍｅｔｈｏｄメソッドで実現されていなくてもよい。
【００２６】
クライアントプログラム２０がサーバプログラム１０に対して旧ＡＰＩを呼び出すプロトコル３０は、ｓｅｎｄｅｒオブジェクトの実行スレッドにおいて、ｒｅｃｅｉｖｅｒオブジェクトに対して、「ｖ＝ｒｅｃｅｉｖｅｒ．ｍｅｔｈｏｄ（ｘ，ｙ）」というメソッドリクエストを発行する。
【００２７】
ここで、本発明の特徴は、サーバプログラム１０におけるｒｅｃｅｉｖｅｒオブジェクトの実装、クライアントプログラム２０におけるｓｅｎｄｅｒオブジェクトの実装、およびメソッドリクエスト呼び出しプロトコル３０：  ｖ＝ｒｅｃｅｉｖｅｒ．ｍｅｔｈｏｄ（ｘ，ｙ）のいずれも変えることなく、旧ＡＰＩ機能４０を新ＡＰＩ機能５０に改変することである。
【００２８】
新ＡＰＩ機能５０の実装は、Ｅｘｅｃｕｔａｂｌｅインタフェースを実装するオブジェクトとして定義する。Ｅｘｅｃｕｔａｂｌｅインタフェースは、必須メソッドとして、「ｐｕｂｌｉｃ  Ｏｂｊｅｃｔ  Ｅｘｅｃｕｔａｂｌｅ＃ｅｘｅｃｕｔｅ（Ｏｂｊｅｃｔ［］  ａｒｇｓ）」なるメソッドを求める。
【００２９】
Ｃｏｍｍａｎｄデザインパターンを適用し、Ｅｘｅｃｕｔａｂｌｅインタフェースを実装するオブジェクトを定義するか、「ｎｅｗ  Ｅｘｅｃｕｔａｂｌｅ（）｛  ｐｕｂｌｉｃ  Ｏｂｊｅｃｔ  ｅｘｅｃｕｔｅ（Ｏｂｊｅｃｔ［］  ａｒｇｓ）｛／＊新ＡＰＩ機能のロジック＊／｝｝」として無名クラスのオブジェクトとして実現する。
【００３０】
新ＡＰＩ機能の実装は、クライアントプログラム内でも、サーバプログラム内でも、第三者プログラム内でもいずれにおいて定義してよい。
【００３１】
ｅｘｅｃｕｔｅ（）メソッドの本体に、新ＡＰＩ機能：入力として３つのオブジェクト（ｘ，ｙ，ｚ）を与え、結果として「φ（Ｖ）」を出力する機能を定義する。この時、新ＡＰＩ機能の実現のための情報として、ｒｅｃｅｉｖｅｒオブジェクト、ｓｅｎｄｅｒオブジェクト、ｒｅｃｅｉｖｅｒ＃ｍｅｔｈｏｄ（）メソッドオブジェクト、実パラメタｘ，ｙ、追加の実パラメタｚおよび該ｚを取得するメソッドｇｅｔＺ（）などが必要となる場合には、これらの取得のための処理をｅｘｅｃｕｔｅ（）メソッド内に定義する。
【００３２】
例えば、ｅｘｅｃｕｔｅ（）に対するパラメタ：Ｏｂｊｅｃｔ［］  ａｒｇｓに実体を格納して渡すこと、Ｅｘｅｃｕｔａｂｌｅインタフェースを実装するオブジェクトの生成時のパラメタとして渡すこと、ｓｅｎｄｅｒ，ｒｅｃｅｉｖｅｒオブジェクトヘのメソッドコールバックによって実行時に取得すること、外部ファイルやネットワークを通じて通信すること、などの手段によって任意の方法で必要な情報を取得できるため、ｅｘｅｃｕｔｅ（）の定義に特に制約はない。
【００３３】
また、状況に応じて多種類の異なる処理を実行したい場合には、Ｅｘｅｃｕｔａｂｌｅを実装するクラスを１つ設け、そのクラス内で、異なる処理毎に１つの内部クラスとして定義することで多様な処理を１つのクラス内に束ねて定義する。これにより、処理の追加削除は、内部クラスの追加・削除で実現できるため、多くの小さなクラスをバラバラに定義・作成することなく、整理された形で一連の処理集合を管理できる。
【００３４】
Ｃｏｍｍａｎｄデザインパターンを適用することで、Ｅｘｅｃｕｔａｂｌｅを実装したオブジェクトは、統一的に外部からｅｘｅｃｕｔｅ（）メソッドコールにて起動し、所望の処理を実施する。
【００３５】
次に、図２は、本発明の実施形態によるプログラム機能拡張の実現手段を具体例とともに示す概念図である。図２において、代替処理管理部１００は、新ＡＰＩ機能を実現したＥｘｅｃｕｔａｂｌｅ実装オブジェクト（新ＡＰＩ処理オブジェクト）２００を、代替したい旧ＡＰＩ機能を実装したＭｅｔｈｏｄオブジェクト（旧ＡＰＩ処理オブジェクト）Ｒ＃ｍｅｔｈｏｄ（ｘ，ｙ）と対応付けて管理する。代替処理管理部１００は、ハッシュテーブルを持つか、ハッシュテーブル機能を継承して実現する。
【００３６】
旧ＡＰＩ機能を実装したｒｅｃｅｉｖｅｒオブジェクトのＭｅｔｈｏｄオブジェクトは、「ｒｅｃｅｉｖｅｒ．ｇｅｔＣｌａｓｓ（）．ｇｅｔＤｅｃｌａｒｅｄＭｅｔｈｏｄ（“ｍｅｔｈｏｄ”，ｎｅｗ  Ｃｌａｓｓ［］｛ｘ．ｃｌａｓｓ，ｙ．ｃｌａｓｓ｝）」により取得し、これをハッシュテーブルのキーに、対応する値として新ＡＰＩ機能を実装したＥｘｅｃｕｔａｂｌｅ実装オブジェクトを管理に加える。
【００３７】
当該ハッシュテーブルにキー・値のペアが登録されているＭｅｔｈｏｄオブジェクトは、その代替処理が定義されていることを意味し、キーもしくは値が登録されていないものは代替処理がない、つまり元の処理を実行することを意味する。
【００３８】
したがって、キーとなるＭｅｔｈｏｄに対して、値となるＥｘｅｃｕｔａｂｌｅ実装オブジェクトを割り当てる（ｒｅｇｉｓｔｅｒ）ことで代替処理の付与、削除する（ｒｅｍｏｖｅ）ことで代替処理の削除＝元の処理に戻す、別のＥｘｅｃｕｔａｂｌｅ実装オブジェクトを割り当てる（ｕｐｄａｔｅ）ことで代替処理の変更、という３種類の操作が可能となる。
【００３９】
Ｍｅｔｈｏｄ起動ハンドラ部５００は、旧ＡＰＩを提供するオブジェクトに対して旧ＡＰＩメソッド呼び出し時にフックされ、代理オブジェクト、当該メソッドオブジェクト、呼び出し時の実パラメタをオブジェクトとして取得できる機構である。
【００４０】
ｊａｖａ．ｌａｎｇ．ｒｅｎｅｅｔ．ＩｎｖｏｃａｔｉｏｎＨａｎｄｌｅｒインタフェースの「ｐｕｂｌｉｃ  Ｏｂｊｅｃｔ  ｉｎｖｏｋｅ（Ｏｂｊｅｃｔ  ｐｒｏｘｙ，Ｍｅｔｈｏｄ  ｍ，Ｏｂｊｅｃｔ［］  ａｒｇｓ）」を実装定義したメソッドの中で、代理処理管理部１００の機能を呼び出し、当該メソッドオブジェクトに対応する代替処理オブジェクトを検索・実行する。
【００４１】
以下に、詳細に説明する。本実施形態では、ＡＰＩの拡張に際し、ＡＰＩ提供側（サーバ）もＡＰＩ利用側（クライアント）もプログラムコードを修正することなく、ＡＰＩおよび当該機能を拡張する。
【００４２】
具体的には、プログラム言語処理実行系に備わるリフレクション機能を用いて、旧ＡＰＩを実装するメソッドの呼び出しに際して、メタレベルの処理（処理系レベル、クラスやメソッドなどメタオブジェクトの振る舞いを実行するレベル）に制御を移し、メタレベルにおいて旧メソッドの実行を横取りし、旧メソッドオブジェクトに対応する新メソッドを検索し、メタレベル処理内部で当該旧メソッドに代わって実行することを実現する。
【００４３】
これにより、クライアントは、旧ＡＰＩを呼び出すコードを変更することなくそのまま実行するだけで、メタレベルにおいて新しいＡＰＩに対応する処理が代替実行され、結果として、ＡＰＩの互換性を保ったまま機能拡張が可能になる。
【００４４】
旧ＡＰＩ処理オブジェクトは、Ｍｅｔｈｏｄオブジェクト（ＪＡＶＡ（登録商標）  ＡＰＩではｊａｖａ．ｌａｎｇ．ｒｅｆｌｅｃｔ．Ｍｅｔｈｏｄクラスのインスタンス）で取得でき、新ＡＰＩ処理オブジェクトは代替となるＭｅｔｈｏｄオブジェクトもしくはＣｏｍｍａｎｄデザインパターンにより処理を具現化したオブジェクトで与える。
【００４５】
Ｃｏｍｍａｎｄデザインパターンで処理を具現化したオブジェクトとは、Ｉｎｔｅｒｆａｃｅで規定した必須メソッド（例えば，Ｅｘｅｃｕｔａｂｌｅ＃ｅｘｅｃｕｔｅ（Ｏｂｊｅｃｔ［］ａｒｇｓ）など）を１つ以上伴うオブジェクトであり、処理に必要な０個以上のオブジェクトの参照を束ねてインスタンス化し、ｉｎｔｅｒｆａｃｅで規定したメソッドを呼び出すことで任意の処理を定義するものである。
【００４６】
代替処理管理部１００は、ハッシュテーブル（ＪＡＶＡ（登録商標）  ＡＰＩでは、ｊａｖａ．ｕｔｉｌ．Ｈａｓｈｔａｂｌｅクラスのインスタンス）で実現し、キーとして旧ＡＰＩ処理オブジェクト、対応する値として新ＡＰＩ処理オブジェクトを格納する。
【００４７】
当該代替処理管理部１００に対して旧ＡＰＩ処理オブジェクトをキーに新ＡＰＩ処理オブジェクトを検索した結果、キーに対応する値が空（ｎｕｌｌ）であれば、旧ＡＰＩ処理をそのまま実行して結果を返す。一方、キーに対応する値が空でなく、新ＡＰＩ処理オブジェクトが割り当てられている場合には、新ＡＰＩ処理オブジェクトを取り出し、代替処理を実行するためにｅｘｅｃｕｔｅ（）メッセージを発行する。
【００４８】
その際、旧ＡＰＩの処理結果を利用する必要があれば、旧ＡＰＩ処理オブジェクトを新ＡＰＩ処理オブジェクトに渡して、処理を融合できる。例えば、旧ＡＰＩのメソッド呼び出し直後・復帰直前でデバッグログを出力する、あるいは、メソッド本体の処理に要する時間を計時し性能測定に利用する処理も、代替処理オブジェクトの中で、旧ＡＰＩメソッドと付加機能の融合を行えばよく、本方法によって統一的に実現できる。
【００４９】
代替処理管理部１００は、Ｓｉｎｇｌｅｔｏｎデザインパターンに基づき設計・実装する。これにより、同一の処理系（Ｊａｖａ（登録商標）であればＪＡＶＡ（登録商標）  ＶＭ）中には唯一の存在であることを保証するとともに、特定のオブジェクトが代替処理管理クラスを参照するために（インスタンス変数で保有するなど）密結合することなく、（代替処理管理クラス＃ｇｅｔＩｎｓｔａｎｃｅ（）により）任意のメソッド中から適切に参照できるようにする。
【００５０】
したがって、旧ＡＰＩ処理の起動時に、メソッド起動を実行するメタレベル処理のメソッド内でも当該代替処理管理クラスを参照することが可能となり、旧ＡＰＩメソッドの実行契機に、対応する新ＡＰＩ処理オブジェクトを検索し実行できる。
【００５１】
サーバ開発者、クライアント開発者、あるいはその両者以外の第三者により、新ＡＰＩ処理オブジェクトが用意され、旧ＡＰＩとの対応関係を動的に結びつけることができる。つまり、旧ＡＰＩを介して協調動作する複数プログラムの実行中に、旧ＡＰＩに対応した代替処理を追加・変更・削除することが可能となり、機能拡張・旧機能への回帰以外にも、実行時に動的に振る舞いを変更することができる。
【００５２】
旧ＡＰＩのメソッド起動処理のメタレベル処理にアクセスするために、旧ＡＰＩメソッド実行時のコンテキスト、すなわち実行しようとする｛インスタンス、メソッド、実パラメタ｝のすべてを取得し、メタレベルにおいてユーザが定義した処理と動的に結びつける。例えば、利用言語がＪａｖａ（登録商標）であれば、Ｊａｖａ（登録商標）リフレクション機能のダイナミックプロキシを利用する。すなわち、ｊａｖａ．ｌａｎｇ．ＰｒｏｘｙクラスとＡＰＩ呼び出しハンドラｊａｖａ．ｌａｎｇ．ＩｎｖｏｃａｔｉｏｎＨａｎｄｌｅｒ＃ｉｎｖｏｋｅ（）を用いることで上記動作を行うことができる。
【００５３】
前出の動的に処理を結びつける中で、代替処理管理クラスにアクセスし、旧ＡＰＩメソッドオブジェクトに対応する代替処理を実行する。これにより、ＡＰＩ呼び出しインクフェースを変更せず、実質的なＡＰＩの機能拡張が実現でき、サーバとクライアント双方のプログラムに修正が加わらないため、互換性を維持しながら機能拡張を行うことが容易に実現される。また、試験プログラムも変更する必要がないため試験作業も簡易になる。
【００５４】
図３は、本発明の実施形態によるプログラム機能拡張を実現するための機能構成を示すブロック図である。代替処理管理部１００は、代替処理検索部１１０、代替処理登録部１１１、代替処理更新部１１２、代替処理削除部１１３、代替処理検索・実行部１１４、代替処理合成・実行部１１５から構成される。代替処理検索部１１０は、旧ＡＰＩのメソッドをキーに代替処理を検索する機能を有するもので、前述したようにハッシュテーブルの検索機構を用いて実現できる。代替処理登録部１１１は、旧ＡＰＩのメソッドをキーに代替処理を登録する機能を有するもので、前述したようにハッシュテーブルへの追加機能を用いて実現できる。
【００５５】
代替処理更新部１１２は、旧ＡＰＩのメソッドをキーに代替処理を更新する機能を有するもので、前述したようにハッシュテーブルへの追加機能を用いて実現できる。代替処理削除部１１３は、旧ＡＰＩのメソッドをキーの代替処理を削除し、本来の機能に戻すもので、前述したようにハッシュテーブルからの値の削除機能を用いて実現できる。代替処理検索・実行部１１４は、旧ＡＰＩのメソッドをキーに代替処理を検索すると同時に、自動的に代替処理を実行する機能を有するもので、代替処理検索機能とＥｘｅｃｕｔａｂｌｅオブジェクトヘのｅｘｅｃｕｔｅ（）メッセージの発行で実現できる。代替処理合成・実行部１１５は、旧ＡＰＩのメソッドをキーに代替処理を検索すると同時に、自動的に旧ＡＰＩメソッドの実行と、代替処理を実行する機能を有するもので、代替処理検索機能と、旧ＡＰＩメソッドの起動と、Ｅｘｅｃｕｔａｂｌｅオブジェクトヘのｅｘｅｃｕｔｅ（）メッセージの発行で実現できる。
【００５６】
代替処理オブジェクト定義部２０１は、代替処理管理部１００へ登録するためのＥｘｅｃｕｔａｂｌｅ実装オブジェクトを定義する機能を有する。通常、ＪＡＶＡ（登録商標）のソースコードを編集・コンパイルし、生成されたｃｌａｓｓファイルを外部からＪＡＶＡ（登録商標）  ＶＭに見える位置に配置することで実現できる。
【００５７】
Ｍｅｔｈｏｄ起動ハンドラ部５０１は、代替処理管理部１００に代替処理の登録有無を問合せ、代替処理の実行を依頼する機能を有する。旧ＡＰＩメソッドの実行要否や、代替処理の前後で付加的な処理（ログ出力、プロファイル情報の出力、パフォーマンス情報の出力など）の追加要否、代替処理自体の登録・変更・削除など、代替処理の実行時の振る舞いに応じて、複数種類のＭｅｔｈｏｄ起動ハンドラ部が存在することが可能である。ＪＡＶＡ（登録商標）リフレクション機能のダイナミックプロキシクラスを用いて、メソッドの起動をフックした後に、代替処理管理部１００を呼び出すことで実現できる。
【００５８】
クライアントプログラム部３０１は、旧ＡＰＩを呼び出し、結果を利用して高次のビジネスロジックを実行制御する部分である。ビジネスロジックの種類に応じて複数のクライアントプログラムが存在し得る。サーバプログラム部４０１は、旧ＡＰＩを実現する機能を具備し、旧ＡＰＩを公開し、ＡＰＩへのリクエストを実行し結果を返すプログラムを実行制御する部分である。ＡＰＩの種類や提供プログラムに応じて、複数のサーバプログラムが存在し得る。
【００５９】
言語処理実行系１０００は、代替処理管理部１００、代替処理オブジェクト定義部２０１、クライアントプログラム部３０１、サーバプログラム部４０１，Ｍｅｔｈｏｄ起動ハンドラ部５０１をそれぞれ実行制御する言語処理実行系である。ＪＡＶＡ（登録商標）言語の場合、ＪＡＶＡ（登録商標）  ＶＭに相当する。必ずしも唯一の存在である必要はなく、ＪＡＶＡ（登録商標）  ＲＭＩ技術を利用することでオブジェクトの一意性を保証する範囲で、分散したＪＡＶＡ（登録商標）  ＶＭ構成でも構わない。
【００６０】
次に、本発明の実施形態によるプログラム機能拡張を実現するための具体例について説明する。ここで、図４ないし図８は、具体的なプログラム例を示す概念図である。図４は、サーバプログラム中のｒｅｃｅｉｖｅｒオブジェクトの一実装例を示したものである。Ｒｅｃｅｉｖｅｒインタフェースは、ｏｌｄＡＰＩ（Ｓｔｒｉｎｇ，Ｓｔｒｉｎｇ）とｎｅｗＡＰＩ（Ｓｔｒｉｎｇ，Ｓｔｒｉｎｇ，Ｓｔｒｉｎｇ）の２つのＡＰＩを公開している。前者は旧ＡＰＩを、後者は新ＡＰＩを表すとする。後者は必ずしも予めサーバプログラム中に定義してある必要はない。これは、説明を簡明にするためにＲｅｃｅｉｖｅｒインタフェースに敢えて予め用意したものである。ＲｅｃｅｉｖｅｒＩｍｐｌクラスは、上記Ｒｅｃｅｉｖｅｒインタフェースを実装した具象クラスである。ｏｌｄＡＰＩ（），ｎｅｗＡＰＩ（）ともにパラメタで与えられた文字列を合成して返す機能を実現している。
【００６１】
本発明を適用することにより、旧ＡＰＩを利用しているクライアント側プログラムは、２つの文字列を伴ってｏｌｄＡＰＩ（Ｓｔｒｉｎｇ，Ｓｔｒｉｎｇ）を呼び出すロジックを変えることなく（つまり互換性を保ちながら）、ＡＰＩ拡張の後に、拡張ＡＰＩ機能の実装であるｎｅｗＡＰＩ（Ｓｔｒｉｎｇ，Ｓｔｒｉｎｇ，Ｓｔｒｉｎｇ）を自動的に呼び出す。
【００６２】
次に、図５は、クライアントプログラム中のＳｅｎｄｅｒオブジェクトの一実装例を示したものである。Ｓｅｎｄｅｒインクフェースは、ｃａｌｌＯｌｄＡＰＩ（Ｓｔｒｉｎｇ，Ｓｔｒｉｎｇ）とｃａｌｌＮｅｗＡＰＩ（Ｓｔｒｉｎｇ，Ｓｔｒｉｎｇ，Ｓｔｒｉｎｇ）の２つのＡＰＩを公開している。前者は旧ＡＰＩを、後者は新ＡＰＩを表す。後者は必ずしも予めクライアントプログラム中に定義してある必要はない。これは、説明を簡明にするためにＳｅｎｄｅｒインタフェースに敢えて用意したものである。
【００６３】
ＳｅｎｄｅｒＩｍｐｌクラスは、上記Ｓｅｎｄｅｒインタフェースを実装した具象クラスである。インスタンス変数としてＲｅｃｅｉｖｅｒインタフェースを実装したオブジェクトｒｅｃｅｉｖｅｒを有し、これに対しＡＰＩ呼び出しを発行する。ｃａｌｌＯｌｄＡＰＩ（），ｃａｌｌＮｅｗＡＰＩ（）ともにパラメタで与えられた文字列をそれぞれ、ｒｅｃｅｉｖｅｒ＃ｏｌｄＡＰＩ（），ｒｅｃｅｉｖｅｒ＃ｎｅｗＡＰＩ（）に渡してＡＰＩを呼び出し、結果として返ってくる合成された文字列を標準出力する。
【００６４】
本発明を用いると、ｃａｌｌＯｌｄＡＰＩ（）を利用しているクライアント側プログラムは、２つの文字列を伴ってｒｅｃｅｉｖｅｒ．ｏｌｄＡＰＩ（Ｓｔｒｉｎｇ，Ｓｔｒｉｎｇ）を呼び出すロジックを変えることなく（つまり互換性を保ちながら）、ＡＰＩ拡張の後に、ｒｅｃｅｉｖｅｒ，ｎｅｗＡＰＩ（Ｓｔｒｉｎｇ，Ｓｔｒｉｎｇ，Ｓｔｒｉｎｇ）を呼び出すように自動的に機能拡張に対応する。
【００６５】
ＳｅｎｄｅｒＩｍｐｌクラスのｃｈａｎｇｅＡＰＩ（）メソッドは、旧ＡＰＩに対して代替処理を定義して登録する機能を持っている。このメソッドは、必ずしもクライアントプログラム中に定義してある必要はない。ここでは、説明を簡単にするためにＳｅｎｄｅｒＩｍｐｌ中に定義しているが、Ｅｘｅｃｕｔａｂｌｅ実装オブジェクトの定義方法を変えれば、第三者のプログラム中に実装することも可能である。
【００６６】
この例では、“Ｓｅｎｄｅｒ”クラスの“ｃａｌｌＯｌｄＡＰＩ”というメソッドに対して、「代替処理管理部に対して、Ｒｅｃｅｉｖｅｒ＃ｏｌｄＡＰＩ（）の代替処理Ｘを登録する」という代替処理を定義し登録している。それと同時に前述の“Ｒｅｃｅｉｖｅｒ”クラスの“ｏｌｄＡＰＩ”メソッドに対する代替処理Ｘとして、「ｃａｌｌＮｅｗＡＰＩ（Ｓｔｒｉｎｇ，Ｓｔｒｉｎｇ，Ｓｔｒｉｎｇ）メソッドを呼び出す」という代替処理を定義し登録している。
【００６７】
ＳｅｎｄｅｒＩｍｐｌクラスのｍａｉｎ（）メソッドが、本発明の利用方法を示す例である。まずメソッド呼び出しをフックするために代理クラスとしてオブジェクトを生成する。次に、旧ＡＰＩを変更する前の処理としてｓｅｎｄｅｒ．ｃａｌｌＯｌｄＡＰＩ（）とｓｅｎｄｅｒ．ｃａｌｌＮｅｗＡＰＩ（）を呼び出す。それぞれ与えられたパラメタの文字列を連結して出力する。その後、上述したＳｅｎｄｅｒＩｍｐｌ＃ｃｈａｎｇｅＡＰＩ（）を呼び出すことで、ｓｅｎｄｅｒ．ｃａｌｌＯｌｄＡＰＩ（）と、その中で呼ばれているｒｅｃｅｉｖｅｒ．ｏｌｄＡＰＩ（）の２つの旧ＡＰＩの代替処理を作成・登録する。
【００６８】
このＡＰＩ変更後に、全く同じ呼び出し形式でｓｅｎｄｅｒ．ｃａｌｌＯｌｄＡＰＩ（）とｓｅｎｄｅｒ．ｃａｌｌＮｅｗＡＰＩ（）を呼び出す。その動作は、次のようなシーケンスとなる。
【００６９】
ｓｅｎｄｅｒ．ｃａｌｌＯｌｄＡＰＩ（）の実行は、メソッド起動ハンドラにフックされ、代替処理に置き換わって実行されるため、前述した「代替処理管理部に対して、Ｒｅｃｅｉｖｅｒ＃ｏｌｄＡＰＩ（）の代替処理Ｘを登録する」が実行される。
【００７０】
それとともに、ｓｅｎｄｅｒ．ｃａｌｌＯｌｄＡＰＩ（）の本来の処理であるｒｅｃｅｉｖｅｒ．ｏｌｄＡＰＩ（）処理が実行されるが、この処理も前述した代替処理Ｘ：「ｃａｌｌＮｅｗＡＰＩ（Ｓｔｒｉｎｇ，Ｓｔｒｉｎｇ，Ｓｔｒｉｎｇ）メソッドを呼び出す」に置き換わって実行されるため、結果としてｓｅｎｄｅｒ．ｃａｌｌＮｅｗＡＰＩ（）を実行したことになる。
【００７１】
この時、ｓｅｎｄｅｒ．ｃａｌｌＯｌｄＡＰＩ（）では２つのパラメタを渡しているが、代替処理として呼ばれるｓｅｎｄｅｒ．ｃａｌｌＮｅｗＡＰＩ（）の第３番目のパラメタは、ＳｅｒｖｅｒＩｍｐｌ．ｔｈｉｓ．ｇｅｔＺ（）という処理で捕完される。これは、ＳｅｒｖｅｒＩｍｐｌ＃ｃｈａｎｇｅＡＰＩ（）中で定義したＥｘｅｃｕｔａｂｌｅ実装オブジェクトの定義で与えた動作である。
【００７２】
最終的に、旧ＡＰＩの変更後に呼ばれるｓｅｎｄｅｒ．ｃａｌｌＯｌｄＡＰＩ（）の処理は、その呼出形式を全く変えることなく、ｓｅｎｄｅｒ．ｃａｌｌＮｅｗＡＰＩ（）に置き換わって実行されるため、３つの文字列の合成という効果を得る。それとともに、元々のｓｅｎｄｅｒ．ｃａｌｌＯｌｄＡＰＩ（）自体の処理結果と合成された文字列出力が得られることとなる。
【００７３】
一方、ｓｅｎｄｅｒ．ｃａｌｌＮｅｗＡＰＩ（）とｒｅｃｅｉｖｅｒ．ｎｅｗＡＰＩ（）とには、代替処理を定義しないため、これらの起動はそのまま実行される。
【００７４】
次に、図６は、Ｅｘｅｃｕｔａｂｌｅインタフェースの一定義例を示す概念図である。唯一必須のメソッドとして、ｐｕｂｌｉｃ  Ｏｂｊｅｃｔ  ｅｘｅｃｕｔｅ（Ｏｂｊｅｃｔ［］  ａｒｇｓ）ｔｈｒｏｗｓ  Ｅｘｃｅｐｔｉｏｎ；の実装を必須とするもので、代替処理の定義に利用する。後述の代替処理管理クラスの中で検索され、ｅｘｅｃｕｔｅ（）メソッドの発行により起動される。
【００７５】
Ｃｏｍｍａｎｄデザインパターンを適用し、Ｅｘｅｃｕｔａｂｌｅインタフェースを実装するオブジェクトを定義するか、ｎｅｗ  Ｅｘｅｃｕｔａｂｌｅ（）｛  ｐｕｂｌｉｃ  Ｏｂｊｅｃｔ  ｅｘｅｃｕｔｅ（Ｏｂｊｅｃｔ［］ａｒｇｓ）｛／＊新ＡＰＩ機能のロジック＊／｝｝として無名クラスのオブジェクトとして代替処理を実現する。
【００７６】
次に、図７は、代替処理管理クラスの一実装例を示したものである。また、図８は、メソッド起動ハンドラの一実装例を示したものである。
【００７７】
上述した実施形態によれば、クライアントは、旧ＡＰＩを呼び出すコードを変更することなくそのまま実行するだけで、メタレベルにおいて新しいＡＰＩに対応する処理が代替実行され、結果として、ＡＰＩの互換性を保ったまま機能拡張が可能になる。
【００７８】
また、サーバ１０の機能、あるいはクライアント２０の機能は、図示しない記憶部に記憶されたプログラムを実行することで実現するようになっている。記憶部は、ハードディスク装置や光磁気ディスク装置、フラッシュメモリ等の不揮発性メモリやＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）のような揮発性のメモリ、あるいはこれらの組み合わせにより構成されるものとする。また、上記記憶部とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（ＲＡＭ）のように、一定時間プログラムを保持しているものも含む。
【００７９】
また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワークや電話回線等の通信回線のように情報を伝送する機能を有する媒体のことをいう。また、上記プログラムは、上述した処理の一部を実現するためのものであってもよい。さらに、上述した処理をサーバ１０あるいはクライアント２０に既に記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよい。
【００８０】
以上、この発明の実施形態を、図面を参照して詳述してきたが、具体的な構成は、上記実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。
【００８１】
【発明の効果】
以上説明したように、本発明によれば、旧ＡＰＩを利用するサーバとクライアント双方のプログラムに修正が加わらないため、互換性を維持しながら機能拡張を行うことが容易かつ柔軟に実現することができるという利点が得られる。また、試験プログラムも変更しないため試験作業も簡易になる。また、旧ＡＰＩを介して協調動作する複数プログラムの実行中に、旧ＡＰＩに対応した代替処理を追加・変更・削除することが可能となり、機能拡張・旧機能への回帰以外にも、実行時に動的に振る舞いを変更することができる。その結果として、協調動作するプログラム自体への修正を最小限にとどめ、機能拡張の実施・試験が容易になるため、プログラムの開発効率および生産性を向上することに寄与することができるという利点が得られる。
【図面の簡単な説明】
【図１】本発明の実施形態によるプログラム機能拡張の作用および効果を示す概念図である。
【図２】本実施形態によるプログラム機能拡張の実現手段を具体例とともに示す概念図である。
【図３】本実施形態によるプログラム機能拡張を実現するための機能構成を示すブロック図である。
【図４】サーバプログラム中のｒｅｃｅｉｖｅｒオブジェクトの一実装例を示したものである。
【図５】クライアントプログラム中のＳｅｎｄｅｒオブジェクトの一実装例を示す概念図である。
【図６】クライアントプログラム中のＳｅｎｄｅｒオブジェクトの一実装例を示す概念図である。
【図７】Ｅｘｅｃｕｔａｂｌｅインタフェースの一定義例を示す概念図である。
【図８】代替処理管理部の一実装例を示す概念図である。
【図９】メソッド起動ハンドラの一実装例を示す概念図である。
【符号の説明】
１０  サーバプログラム
２０  クライアントプログラム
３０  旧ＡＰＩ呼び出しプロトコル
４０  旧ＡＰＩ機能
５０  新ＡＰＩ機能
１００  代替処理管理部
１１０  代替処理検索部
１１１  代替処理登録部
１１２  代替処理更新部
１１３  代替処理削除部
１１４  代替処理検索・実行部
１１５  代替処理合成・実行部
２００  代替処理オブジェクト定義部
３００  クライアントプログラム
４００  サーバプログラム
５００  Ｍｅｔｈｏｄ起動ハンドラ部
２０１  代替処理オブジェクト定義部
３０１  クライアントプログラム部
４０１  サーバプログラム部
５０１  Ｍｅｔｈｏｄ起動ハンドラ部
１０００  言語処理実行系
【図１】
2004246789.tif 000003
【図２】
2004246789.tif 000004
【図３】
2004246789.tif 000005
【図４】
2004246789.tif 000006
【図５】
2004246789.tif 000007
【図６】
2004246789.tif 000008
【図７】
2004246789.tif 000009
【図８】
2004246789.tif 000010
【図９】
2004246789.tif 000011