JP2012084088A - 情報処理装置、情報処理方法、及び情報処理プログラム - Google Patents

Abstract

【課題】複数の機能モジュールの組み合わせを容易に管理できる情報処理装置、情報処理方法、及び情報処理プログラムを提供する。
【解決手段】情報処理装置は、複数の機能モジュール間において、機能利用側の機能モジュール１７ａと機能提供側の機能モジュール１７ｂとを連携して実行し、搭載アプリケーションの機能が実現されるソフトウェア環境を有する装置であって、機能利用側の機能モジュール１７ａから機能提供側の機能モジュール１７ｂに対して、機能提供側の機能モジュール１７ｂによる提供機能を利用可能か否かの問い合わせ要求を行う手段２２と、機能提供側の機能モジュール１７ｂから機能利用側の機能モジュール１７ａに対して、利用可否結果を応答する手段２１と、応答された利用可否結果に基づき、機能利用側の機能モジュール１７ａによる提供機能の実行を制御する手段２０と、を有する。
【選択図】図３

Description

本発明は、アプリケーション機能提供時に実行されるプログラムモジュールの組み合わせを管理する技術に関するものである。

現在、情報処理装置において、利用者に対し、機能を提供するアプリケーションは、小機能を実現する複数のプログラムモジュール（以下「機能モジュール」と言う）を有するソフトウェア環境となっている。つまり、アプリケーションで提供される機能は、これらの機能モジュールが連携して実行されることにより実現される。

このようなソフトウェア環境では、例えば、設計変更や仕様変更などを行う際に、変更の影響範囲によって、複数の機能モジュールを変更する必要がある。そのため、リリース済み（市場投入後）のソフトウェア環境に対して、修正後の機能モジュールを提供する場合には、バージョンに基づき、各機能モジュールの組み合わせを管理し、組み合わせ不一致による機能停止（障害発生）などを防がなければならない。

そこで、例えば、特許文献１には、機能モジュールに関するソフトウェア構成情報をデータベースに登録し、ソフトウェア構成情報に基づき、インストーラを生成し、インストールする機能モジュールの組み合わせを管理する技術が開示されている。

しかしながら、従来の方法では、特定の機能モジュールを変更する場合であっても、機能を実現する上で組み合わせが発生する他の機能モジュールにも、その変更を反映（変更した機能モジュールに対応）させる必要がある。また、ソフトウェア構成情報などを用いて、機能モジュールの組み合わせを管理する場合には、機能モジュールの組み合わせが多くなるほど、組み合わせの登録パターンが多くなる。そのため、ソフトウェア構成情報そのものの管理が煩雑化し、バージョンの整合性を取ることが困難になる。

このように、従来の方法では、ソフトウェアベンダ（機能モジュールの提供側）で行う作業が煩雑になり、これらの作業に起因した障害が発生する恐れがある。よって、ソフトウェアベンダにとって、リリース済みのソフトウェア環境に対する作業は、容易に行えることが望ましい。

本発明は上記従来技術の問題点を鑑み提案されたものであり、複数の機能モジュールの組み合わせを容易に管理できる情報処理装置、情報処理方法、及び情報処理プログラムを提供することにある。

上記目的を達成するため、本発明に係る情報処理装置は、複数の機能モジュール間において、機能利用側の機能モジュールと機能提供側の機能モジュールとを連携して実行し、搭載アプリケーションの機能が実現されるソフトウェア環境を有する情報処理装置であって、機能利用側の機能モジュールから機能提供側の機能モジュールに対して、機能提供側の機能モジュールによる提供機能を利用可能か否かの問い合わせ要求を行う機能利用可否問い合わせ手段と、機能提供側の機能モジュールから機能利用側の機能モジュールに対して、利用可否結果を応答する機能利用可否応答手段と、応答された利用可否結果に基づき、機能利用側の機能モジュールによる提供機能の実行を制御する機能実行制御手段と、を有している。

このような構成によって、本発明に係る情報処理装置は、機能利用側の機能モジュールが、機能提供側の機能モジュールに提供機能の利用可否を問い合わせ、機能提供側の機能モジュールからの応答結果に基づき、機能実行（変更前／変更後のどちらの機能を動作させるか）を制御する。

これによって、本発明に係る情報処理装置では、特定の機能モジュールを変更する場合、組み合わせが発生する他の機能モジュールに、その変更を反映（変更した機能モジュールに対応）させる必要がない。また、本発明に係る情報処理装置では、機能モジュールの組み合わせが多くなっても、ソフトウェアベンダが煩雑な作業を行わなくてよい。その結果、本発明に係る情報処理装置では、複数の機能モジュールの組み合わせを容易に管理できる。

上記目的を達成するため、本発明に係る情報処理方法は、複数の機能モジュール間において、機能利用側の機能モジュールと機能提供側の機能モジュールとを連携して実行し、搭載アプリケーションの機能が実現されるソフトウェア環境を有する情報処理装置における情報処理方法であって、機能利用側の機能モジュールから機能提供側の機能モジュールに対して、機能提供側の機能モジュールによる提供機能を利用可能か否かの問い合わせ要求を行う機能利用可否問い合わせ手順と、前記機能利用可否問い合わせ手順による要求に応じて、機能提供側の機能モジュールから機能利用側の機能モジュールに対して、利用可否結果を応答する機能利用可否応答手順と、前記機能利用可否応答手順により応答された利用可否結果に基づき、機能利用側の機能モジュールによる提供機能の実行を制御する機能実行制御手順と、を有している。

このような手順によって、本発明に係る情報処理方法は、機能利用側の機能モジュールが、機能提供側の機能モジュールに提供機能の利用可否を問い合わせ、機能提供側の機能モジュールからの応答結果に基づき、機能実行（変更前／変更後のどちらの機能を動作させるか）を制御すると言う機能モジュール間の連携動作を実現する。

これによって、本発明に係る情報処理方法では、複数の機能モジュールの組み合わせを容易に管理可能な環境を提供できる。

本発明によれば、機能提供時に連携して実行される機能モジュール間で、機能のサポート状態（新機能対応済み／未対応などの状態）を確認し合うことで、複数の機能モジュールの組み合わせを容易に管理可能な情報処理装置、情報処理方法、及び情報処理プログラムを提供することができる。

本発明の第１の実施形態に係る情報処理装置のハードウェア構成例を示す図である。 本発明の第１の実施形態に係る情報処理装置のソフトウェア構成例を示す図である。 本発明の第１の実施形態に係る情報処理機能の構成例を示す図である。 本発明の第１の実施形態に係る機能提供の基本動作例（その１）を示すシーケンス図である。 本発明の第１の実施形態に係る機能提供の基本動作例（その２）を示すシーケンス図である。 本発明の第１の実施形態に係るソフトウェア環境における機能実行処理例（その１）を示すシーケンス図である。 本発明の第１の実施形態に係るソフトウェア環境における機能実行処理例（その２）を示すシーケンス図である。

以下、本発明の好適な実施の形態（以下「実施形態」と言う）について、図面を用いて詳細に説明する。

［第１の実施形態］
＜ハードウェア構成＞
図１は、本実施形態に係る情報処理装置１００のハードウェア構成例を示す図である。
図１に示すように、本実施形態に係る情報処理装置１００は、入力装置１０１、表示装置１０２、ドライブ装置１０３、ＲＡＭ（Random Access Memory）１０４、ＲＯＭ（Read Only Memory）１０５、ＣＰＵ（Central Processing Unit）１０６、インタフェース装置１０７、及びＨＤＤ（Hard Disk Drive）１０８などを備え、それぞれがバスＢで相互に接続されている。

入力装置１０１は、キーボードやマウスなどを含み、情報処理装置１００に各操作信号を入力するのに用いられる。表示装置１０２は、ディスプレイなどを含み、情報処理装置１００による処理結果を表示する。

インタフェース装置１０７は、情報処理装置１００をデータ伝送路Ｎに接続するインタフェースである。これにより、情報処理装置１００は、インタフェース装置１０７を介して、画像処理装置２００や他の情報処理装置１００とデータ通信を行うことができる。

ＨＤＤ１０８は、プログラムやデータを格納している不揮発性の記憶装置である。格納されるプログラムやデータには、情報処理装置全体を制御する情報処理システム（例えば「Ｗｉｎｄｏｗｓ（商標又は登録商標）」や「ＵＮＩＸ（商標又は登録商標）」などの基本ソフトウェアであるＯＳ（Operating System））、及びシステム上において各種機能（例えば「画面カスタマイズ機能」）を提供するアプリケーションなどがある。また、ＨＤＤ１０８は、格納しているプログラムやデータを、所定のファイルシステム及び／又はＤＢ（Data Base）により管理している。

ドライブ装置１０３は、着脱可能な記録媒体１０３ａとのインタフェースである。これにより、情報処理装置１００は、ドライブ装置１０３を介して、記録媒体１０３ａの読み取り及び／又は書き込みを行うことができる。記録媒体１０３ａには、例えば、フロッピー（商標又は登録商標）ディスク、ＣＤ（Compact Disk）、及びＤＶＤ（Digital Versatile Disk）、ならびに、ＳＤメモリカード（SD Memory Card）やＵＳＢ（Universal Serial Bus）メモリなどがある。

ＲＯＭ１０５は、電源を切っても内部データを保持することができる不揮発性の半導体メモリ（記憶装置）である。ＲＯＭ１０５には、情報処理装置１００の起動時に実行されるＢＩＯＳ（Basic Input/Output System）、情報処理システム設定、及びネットワーク設定などのプログラムやデータが格納されている。ＲＡＭ１０４は、プログラムやデータを一時保持する揮発性の半導体メモリ（記憶装置）である。ＣＰＵ１０６は、上記記憶装置（例えば「ＨＤＤ」や「ＲＯＭ」など）から、プログラムやデータをＲＡＭ上に読み出し、処理を実行することで、装置全体の制御や搭載機能を実現する処理装置である。

以上のように、本実施形態に係る情報処理装置１００は、上記ハードウェア構成により、各種情報処理サービスを提供することができる。

＜ソフトウェア構成＞
図２は、本実施形態に係る情報処理装置１００のソフトウェア構成例を示す図である。
図２に示すように、本実施形態に係る情報処理装置１００は、上述した基本ソフトウェアであるＯＳ１１上に、スレッド制御部１２、ＩＰＣ（Inter Process Communication）１３、サービス層１４、ＡＰＩ（Application Program Interface）１５、及びアプリケーション１６などを有するソフトウェア構成となっている。

スレッド制御部１２は、ソフトウェアの実行単位（又はＣＰＵの利用単位）であるスレッドを制御する。つまり、ＯＳ１１は、マルチスレッド対応の基本ソフトウェアである。

ＩＰＣ１３は、プロセス間通信を制御する。ＩＰＣ１３は、動作中のプログラム間のデータ交換を制御する。

サービス層１４は、アプリケーション１６に対して、機能実現のための小機能を提供する。つまり、アプリケーション１６は、これらの小機能を利用して、利用者に所定の機能を提供する。このとき、アプリケーション１６は、ソフトウェアインタフェースであるＡＰＩ１５を介して、サービス層１４の小機能を利用する。

例えば、図２に示すサービス層１４は、Ｗｅｂｓｙｓ１７_１、ＤＥＳＳ１７_２（Data Encryption Security Service）、ＮＣＳ（Network Control Service）１７_３などの複数の機能モジュール１７_ｎ（以下総称する場合「機能モジュール１７」と言う）を有している。Ｗｅｂｓｙｓ１７_１は、情報処理装置１００が有する各種項目の設定や情報を提供する小機能を実現するモジュールである。また、ＤＥＳＳ１７_２は、通信の暗号化やデータの暗号化などを行う小機能を実現するモジュールである。また、ＮＣＳ１７_３は、ネットワーク制御を行う小機能を実現するモジュールである。

これらの機能モジュール１７_１〜１７_３を利用することで、アプリケーション１６は、次のような機能を利用者に提供することができる。アプリケーション１６であるブラウザは、ＡＰＩ１５をコールし、Ｗｅｂｓｙｓ１７_１に対して、ブラウザ上のＧＵＩ（Graphical User Interface）を介して受け付けた暗号化通信に係る入力情報の設定を要求する。その結果、Ｗｅｂｓｙｓ１７_１は、受け付けた要求をＤＥＳＳ１７_２に伝達する。ＤＥＳＳ１７_２は、ＮＣＳ１７_３に対して、暗号化通信に係る設定を要求する。これにより、ＮＣＳ１７_３は、暗号化通信に係る情報項目の記憶領域にアクセスし、項目値を指示された値（入力情報）に更新する。このように、アプリケーション１６で提供される機能は、サービス層１４の機能モジュール１７が連携して実行されることにより実現される。

以上のように、本実施形態に係る情報処理装置１００は、上記ソフトウェア構成により、各種アプリケーション機能を提供することができる。

＜情報処理機能＞
本実施形態に係る情報処理機能について説明する。
本実施形態に係る情報処理装置１００では、機能提供時に連携して実行される機能モジュール間で、次のような処理を行う。機能利用側の機能モジュール１７は、機能提供側の機能モジュール１７に対して、提供機能の利用可否の問い合わせを要求する。その結果、機能提供側の機能モジュール１７は、要求に応じて、利用可否の結果を応答する。これにより、機能利用側の機能モジュール１７は、応答結果に基づき、機能実行（変更前／変更後のどちらの機能を動作させるか）を制御する。本実施形態に係る情報処理装置１００は、このような情報処理機能を有している。

従来の機能モジュールの組み合わせを管理する方法では、ソフトウェアベンダで行う作業（リリース済みのソフトウェア環境に対する作業）が煩雑になり、これらの作業に起因した障害が発生する恐れがあった。

そこで、本実施形態に係る情報処理装置１００では、機能提供時に連携して実行される機能モジュール間で、機能のサポート状態（新機能対応済み／未対応などの状態）を確認し合う仕組みとした。

これにより、本実施形態に係る情報処理装置１００では、複数の機能モジュール１７の組み合わせを容易に管理できる。なぜなら、本実施形態に係る情報処理装置１００では、特定の機能モジュール１７を変更する場合、組み合わせが発生する他の機能モジュール１７に、その変更を反映（変更した機能モジュールに対応）させる必要がない。また、本実施形態に係る情報処理装置１００では、機能モジュール１７の組み合わせが多くなっても、ソフトウェアベンダが煩雑な作業を行わなくてよい。

以下に、本実施形態に係る情報処理機能の構成とその動作について説明する。
図３は、本実施形態に係る情報処理機能の構成例を示す図である。
図３に示すように、本実施形態に係る情報処理機能は、機能モジュール１７が有している。機能モジュール１７は、主に、機能実行制御部２０及び機能実行部３０などを有している。

機能実行制御部２０は、機能モジュール１７の実行を制御する機能部である。また、機能実行部３０は、機能モジュール１７の実行により、小機能を実現する機能部である。よって、小機能は、機能実行制御部２０が、機能実行部３０に対して、機能モジュール１７の実行を指示することで実現される。

また、機能実行制御部２０は、機能利用可否応答部２１、機能利用可否問い合わせ部２２、実行判定部２３、利用可能段階問い合わせ部２４、及び対応段階応答部２５などを有している。

なお、以下の説明では、機能モジュール間における上記機能部の連携動作を分かりやすく説明するため、機能利用側（小機能の実行を要求する側）と機能提供側（要求された小機能を実行する側）とに分けて説明する。よって、機能利用側を機能モジュール１７ａとし、機能提供側を機能モジュール１７ｂとする。

機能利用可否応答部２１は、機能利用側に対して、小機能の利用が可能か否かを応答する機能部である。一方、機能利用可否問い合わせ部２２は、機能提供側に対して、小機能の利用が可能か否かの問い合わせ要求を行う機能部である。よって、機能利用側の機能モジュール１７ａは、機能利用可否問い合わせ部２２により、機能提供側の機能モジュール１７ｂに対して、小機能の利用が可能か否かの問い合わせ要求を行う。その結果、機能提供側の機能モジュール１７ｂからは、機能利用可否応答部２１により、利用可否の結果が応答される。

なお、機能利用可否応答部２１は、小機能の利用可否（新機能対応済み／未対応などサポート状態）の問い合わせを受け付けるためのソフトウェアインタフェースを有している。よって、機能利用可否問い合わせ部２２は、上記ソフトウェアインタフェースを介して、機能利用可否応答部２１への利用可否の問い合わせ要求や、機能利用可否応答部２１からの利用可否結果の応答を受け付ける。

実行判定部２３は、機能利用可否問い合わせ部２２が受け付けた応答結果に基づき、同機能部２３を有する機能モジュール１７において、変更前の小機能（新機能未対応：従来機能）又は変更後の小機能（新機能）のどちらの機能を動作させるかを判定する機能部である。例えば、機能利用側の機能モジュール１７ａが有する実行判定部２３は、機能提供側の機能モジュール１７ｂからの応答結果が「エラー」であった場合、機能提供側が新機能未対応（新機能が未サポート状態）であり、機能モジュール１７ｂの小機能が利用不可能であると判定する。一方、応答結果が「利用可」であった場合には、機能提供側が新機能対応済み（新機能がサポート済み状態）であり、機能モジュール１７ｂの小機能が利用可能であると判定する。

これを受けて、機能実行制御部２０は、上記判定結果に基づき、次のような機能実行制御を行う。例えば、機能利用側の機能モジュール１７ａが有する機能実行制御部２０は、判定結果が「利用不可能」であった場合、同モジュール１７ａが有する機能実行部３０に対して、変更前の小機能（従来機能）が動作するように実行を指示する。一方、判定結果が「利用可能」であった場合には、同モジュール１７ａが有する機能実行部２０に対して、変更後の小機能（新機能）が動作するように実行を指示する。

このように、機能利用側の機能モジュール１７ａでは、機能提供側の機能モジュール１７ｂが提供する小機能の利用可能状態に応じて、同モジュール１７ａの機能動作が制御される。

利用可能段階問い合わせ部２４は、機能提供側に対して、新機能の利用可能な機能段階（機能利用側がどの新機能まで利用可能か）の問い合わせ要求を行う機能部である。一方、対応段階応答部２５は、機能利用側に対して、利用可能な新機能の対応段階（どの段階の新機能までサポート済みであるか）を応答する機能部である。

上述したように、機能利用側の機能モジュール１７ａでは、機能提供側の機能モジュール１７ｂからの応答結果から、機能提供側の小機能が新機能対応済みで利用可能であることを確認できる。しかし、機能利用側の機能モジュール１７ａでは、設計変更や仕様変更の履歴を考慮し、機能提供側が、どの段階の新機能まで対応済みであるかを確認しなければ、組み合わせ不一致により、機能モジュール間の連携動作に不具合が生じる恐れがある。

そこで、本実施形態に係る機能モジュール１７は、各機能モジュール１７に共通した定義値を用いて、対応済みの新機能を表す情報が定義された定義情報（対応済み新機能の定義値）４０Ｄを有している。例えば、図３には、機能利用側の機能モジュール１７ａが、対応済みである新機能Ａ，Ｂ，Ｃを表す定義値"１"（段階１），"２"（段階２），"３"（段階３）が定義された定義データ４０Ｄを有し、一方、機能提供側の機能モジュール１７ｂが、対応済みである新機能Ａ，Ｂを表す定義値"１"（段階１），"２"（段階２）が定義された定義データ４０Ｄを有する例が示されている。この場合、機能モジュール間では、機能利用側と機能提供側とで共通して対応済みとなっている新機能Ａ又は新機能Ｂで連携動作するように機能実行を制御しなければならない。そのため、機能利用側の機能モジュール１７ａでは、機能提供側の機能モジュール１７ｂとの連携動作を行う上で、機能利用側が利用可能な新機能の対応段階を確認する必要がある。

よって、機能利用側の機能モジュール１７ａは、利用可能段階問い合わせ部２４により、機能提供側の機能モジュール１７ｂに対して、新機能の利用可能な機能段階の問い合わせ要求を行う。その結果、機能提供側の機能モジュール１７ｂからは、対応段階応答部２５により、同モジュール１７ｂが有する定義情報４０Ｄが参照され、対応済みの新機能に対応する定義値が、利用可能な新機能の対応段階として応答される。これにより、機能利用側の機能モジュール１７ａは、機能提供側における新機能の対応段階を確認する。

なお、対応段階応答部２５は、新機能の利用可能な機能段階（新機能のサポート状態）の問い合わせを受け付けるためのソフトウェアインタフェースを有している。よって、利用可能段階問い合わせ部２４は、上記ソフトウェアインタフェースを介して、対応段階応答部２５への利用可能段階の問い合わせ要求や、対応段階応答部２５からの新機能対応段階の応答を受け付ける。なお、利用可能段階問い合わせ部２４は、機能利用可否問い合わせ部２２が受け付けた機能利用可否応答部２１からの応答結果が「利用可能」であった場合に機能する。

実行判定部２３は、利用可能段階問い合わせ部２４が受け付けた応答結果に基づき、同機能部２３を有する機能モジュール１７において、変更後の小機能（新機能）のうち、実行可能な機能（組み合わせ一致で実行可能な新機能）を判定する。このとき、実行判定部２３は、同機能部２３を有する機能モジュール１７の定義情報４０Ｄ及び応答結果に基づき、実行可能な機能を判定する。例えば、機能利用側の機能モジュール１７ａが有する実行判定部２３は、同モジュール１７ａが有する定義情報４０Ｄに新機能Ｃ（段階３）までが定義されており、機能提供側の機能モジュール１７ｂからの応答結果が「定義値"１"，"２"」であった場合、機能提供側が新機能Ｂまで対応済み（段階２までの新機能Ａ，Ｂがサポート済み状態）であることから、新機能Ｂまでを実行可能な機能と判定する。また、同モジュール１７ａが有する定義情報４０Ｄに新機能Ｂ（段階２）までが定義されており、機能提供側の機能モジュール１７ｂからの応答結果が「定義値"１"，"２"，"３"」であった場合も同様である。

このように、実行判定部２３では、機能利用側に定義される対応済み新機能の定義値と、機能提供側に定義される対応済み新機能の定義値（応答結果）との比較を行い、一致する最大の定義値（図中に示す例では定義値"２"）を特定し、特定した定義値に基づき、実行可能な機能（図中に示す例では新機能Ｂ（段階２））を判定する。

これを受けて、機能実行制御部２０は、上記判定結果に基づき、同機能部２３を有する機能モジュール１７において、機能の実行段階（変更後の機能をどの段階で動作させるか）を制御する。具体的には、次のような機能実行制御を行う。例えば、機能利用側の機能モジュール１７ａが有する機能実行制御部２０は、判定結果が「新機能Ｂ（段階２）まで」であった場合、同モジュール１７ａが有する機能実行部３０に対して、変更後の小機能（新機能）において、新機能Ａ，Ｂ（段階１，２）までの機能が動作するように実行を指示する。

このように、機能利用側の機能モジュール１７ａでは、機能提供側の機能モジュール１７ｂが提供する小機能の新機能対応状態に応じて、同モジュール１７ａの機能動作が制御される。

ここで、機能利用側と機能提供側との機能モジュール間で行われる機能提供時の動作例（上記各機能部の基本動作例）について、シーケンス図を用いて説明する。

《基本動作：その１》
図４は、本実施形態に係る機能提供の基本動作例（その１）を示すシーケンス図である。なお、図４には、機能利用側が新機能対応済みで、機能提供側が新機能未対応である場合の動作例が示されている。

図４に示すように、機能利用側の機能モジュール１７ａは、機能利用可否問い合わせ部２２が、機能提供側の機能モジュール１７ｂに対して、小機能の利用可否の問い合わせ要求を行う（ステップＳ１０１）。

機能提供側の機能モジュール１７ｂでは、新機能未対応のため、機能利用側からの問い合わせ要求がエラーとなる。よって、機能提供側の機能モジュール１７ｂからは、機能利用可否応答部２１により、機能利用側の機能モジュール１７ａに対して、その旨（エラー）が応答される（ステップＳ１０２）。

これを受けて、機能利用側の機能モジュール１７ａでは、実行判定部２３が、応答結果「エラー応答」から、機能提供側が新機能に対応していないと判断する（ステップＳ１０３）。

これにより、機能利用側の機能モジュール１７ａは、機能実行制御部２０が、機能実行部３０に対して、新機能対応前の機能で動作させる指示を出す。その結果、機能利用側の機能モジュール１７ａでは、機能実行部３０が、同モジュール１７ａを新機能対応前の機能で動作させる（ステップＳ１０４）。

《基本動作：その２》
図５は、本実施形態に係る機能提供の基本動作例（その２）を示すシーケンス図である。なお、図５には、機能利用側及び機能提供側が新機能対応済みである場合の動作例が示されている。

図５に示すように、機能利用側の機能モジュール１７ａは、機能利用可否問い合わせ部２２が、機能提供側の機能モジュール１７ｂに対して、小機能の利用可否の問い合わせ要求を行う（ステップＳ２０１）。

機能提供側の機能モジュール１７ｂでは、新機能対応済みのため、機能利用側からの問い合わせ要求への正常応答が可能である。よって、機能提供側の機能モジュール１７ｂからは、機能利用可否応答部２１により、機能利用側の機能モジュール１７ａに対して、利用可能の旨が応答される（ステップＳ２０２）。

これを受けて、機能利用側の機能モジュール１７ａでは、実行判定部２３が、応答結果「利用可能」から、機能提供側が新機能に対応していると判断する（ステップＳ２０３）。

次に、機能利用側の機能モジュール１７ａは、利用可能段階問い合わせ部２４が、機能提供側の機能モジュール１７ｂに対して、新機能の利用可能な機能段階の問い合わせ要求を行う（ステップＳ２０４）。

機能提供側の機能モジュール１７ｂでは、対応段階応答部２５が、同モジュール１７ｂが有する定義情報４０Ｄを参照し、対応済みの新機能Ａ，Ｂ（段階１，２）を表す定義値"１"，"２"を取得する（ステップＳ２０５）。よって、機能提供側の機能モジュール１７ｂからは、対応段階応答部２５により、機能利用側の機能モジュール１７ａに対して、利用可能な新機能の対応段階（対応済みの新機能Ａ，Ｂに対応する定義値"１"，"２"）が応答される。（ステップＳ２０６）。

これを受けて、機能利用側の機能モジュール１７ａでは、実行判定部２３が、同モジュール１７ａが有する定義情報４０Ｄを参照し、定義情報４０Ｄの定義値"１"（段階１），"２"（段階２），"３"（段階３）と応答結果「定義値"１"，"２"」とから、実行可能機能が新機能Ｂ（実行段階が段階２）までと判断する（ステップＳ２０７）。このとき、実行判定部２３は、定義値の比較を行い、一致する最大の定義値（定義値"２"）を特定し、特定した定義値に基づき、実行可能な機能（新機能Ｂ（段階２））を判定する。よって、機能利用側の機能モジュール１７ａからは、機能提供側の機能モジュール１７ｂに対して、判断した実行段階（段階２）が通知される（ステップＳ２０８）。

これにより、機能提供側の機能モジュール１７ｂでは、機能利用側の機能モジュール１７ａに対して、通知の旨の了解応答を行い（ステップＳ２０９）、機能実行制御部２０が、機能実行部３０に対して、通知された段階の機能で動作する指示を出す。その結果、機能提供側の機能モジュール１７ｂでは、機能実行部３０が、同モジュール１７ｂを新機能Ｂで動作させる（ステップＳ２１０）。

また、機能利用側の機能モジュール１７ａは、機能提供側の機能モジュール１７ｂから了解応答を受け付けると、機能実行制御部２０が、機能実行部３０に対して、実行可能機能で動作させる指示を出す。その結果、機能利用側の機能モジュール１７ａでは、機能実行部３０が、同モジュール１７ａを新機能Ｂで動作させる（ステップＳ２１１）。

このように、本実施形態に係る情報処理機能では、機能提供時に、機能モジュール間で、機能のサポート状態（新機能対応済み／未対応などの状態）を確認し合い、組み合わせを一致させた上で、連携して実行される。

以上のように、本実施形態に係る情報処理機能は、上記各機能部が連携動作することにより実現される。なお、本実施形態に係る情報処理機能は、情報処理装置１００に搭載（インストール）されるプログラム（情報処理機能を実現するソフトウェア）が、処理装置（例えば「ＣＰＵ」）により、記憶装置（例えば「ＨＤＤ」など）からメモリ（ＲＡＭ）上に読み出され、以下の処理が実行されることで実現される。

本実施形態に係る情報処理機能の詳細な動作（機能部群の連携動作）について、具体的なソフトウェア環境を例に、処理手順を示すシーケンス図を用いて説明する。

《新機能対応済みと新機能未対応とが混在するソフトウェア環境における機能実行処理》
図６は、本実施形態に係るソフトウェア環境における機能実行処理例（その１）を示すシーケンス図である。図６には、図２に示したサービス層１４が有するＷｅｂｓｙｓ１７_１、ＤＥＳＳ１７_２、及びＮＣＳ１７_３の連携により、アプリケーション１６が提供するＳＳＬ（Secure Sockets Layer）暗号強度設定機能（新機能）の実行処理例が示されている。その中で、新機能対応済みの機能モジュール１７は、Ｗｅｂｓｙｓ１７_１及びＤＥＳＳ１７_２である。また、Ｗｅｂｓｙｓ１７_１は、機能利用側の機能モジュール１７ａであり、ＮＣＳ１７_３は、機能提供側の機能モジュール１７ｂである。ＤＥＳＳ１７_２は、Ｗｅｂｓｙｓ１７_１及びＮＣＳ１７_３の両方の機能モジュール１７と連携するため、機能利用側と機能提供側の両方にあたる。

図６に示すように、Ｗｅｂｓｙｓ１７_１は、アプリケーション１６からの要求に従って、機能利用可否問い合わせ部２２により、ＤＥＳＳ１７_２に対して、ＳＳＬ暗号強度設定機能が利用可能か否かを問い合わせる（ステップＳ３０１）。

ＤＥＳＳ１７_２は、新機能対応済みであることから、Ｗｅｂｓｙｓ１７_１からの要求に従って、機能利用可否問い合わせ部２２により、ＮＣＳ１７_３に対して、ＳＳＬ暗号強度設定値を保持する記憶領域に参照可能か否かを問い合わせる（ステップＳ３０２）。

ＮＣＳ１７_３は、新機能未対応のため、ＤＥＳＳ１７_２からの問い合わせ要求がエラーとなる。よって、ＮＣＳ１７_３からは、機能利用可否応答部２１により、ＤＥＳＳ１７_２に対して、その旨（エラー）が応答される（ステップＳ３０３）。

これを受けて、ＤＥＳＳ１７_２では、実行判定部２３が、応答結果「エラー応答」から、ＮＣＳ１７_３が新機能に対応していないと判断する（ステップＳ３０４）。よって、ＤＥＳＳ１７_２からは、機能利用可否応答部２１により、Ｗｅｂｓｙｓ１７_１に対して、利用不可能の旨が応答される（ステップＳ３０５）。

このとき、ＤＥＳＳ１７_２は、機能実行制御部２０が、機能実行部３０に対して、新機能対応前の機能で動作する指示を出す。その結果、ＤＥＳＳ１７_２では、機能実行部３０が、同モジュール１７_２を新機能対応前（ＳＳＬ暗号強度設定未対応）の機能で動作させる（ステップＳ３０６）。

一方、Ｗｅｂｓｙｓ１７_１では、実行判定部２３が、応答結果「利用不可能」から、ＤＥＳＳ１７_２又はＮＣＳ１７_３が新機能に対応していないと判断する（ステップＳ３０７）。

これにより、Ｗｅｂｓｙｓ１７_１は、機能実行制御部２０が、機能実行部３０に対して、新機能対応前の機能で動作させる指示を出す。その結果、Ｗｅｂｓｙｓ１７_１では、機能実行部３０が、同モジュール１７_１を新機能対応前（ＳＳＬ暗号強度設定未対応）の機能で動作させる（ステップＳ３０８）。

《新機能対応済みのソフトウェア環境における機能実行処理》
図７は、本実施形態に係るソフトウェア環境における機能実行処理例（その２）を示すシーケンス図である。図７には、図６と同様にＷｅｂｓｙｓ１７_１、ＤＥＳＳ１７_２、及びＮＣＳ１７_３の連携によるＳＳＬ暗号強度設定機能（新機能）の実行処理例が示されている。図６との違いは、Ｗｅｂｓｙｓ１７_１、ＤＥＳＳ１７_２、及びＮＣＳ１７_３全てが、新機能対応済みの機能モジュール１７にあたる点である。

図７に示すように、Ｗｅｂｓｙｓ１７_１は、アプリケーション１６からの要求に従って、機能利用可否問い合わせ部２２により、ＤＥＳＳ１７_２に対して、ＳＳＬ暗号強度設定機能が利用可能か否かを問い合わせる（ステップＳ４０１）。

ＤＥＳＳ１７_２は、新機能対応済みであることから、Ｗｅｂｓｙｓ１７_１からの要求に従って、機能利用可否問い合わせ部２２により、ＮＣＳ１７_３に対して、ＳＳＬ暗号強度設定値を保持する記憶領域に参照可能か否かを問い合わせる（ステップＳ４０２）。

ＮＣＳ１７_３は、新機能対応済みであることから、ＤＥＳＳ１７_２からの問い合わせ要求への正常応答が可能である。よって、ＮＣＳ１７_３からは、機能利用可否応答部２１により、ＤＥＳＳ１７_２に対して、利用可能の旨が応答される（ステップＳ４０３）。

これを受けて、ＤＥＳＳ１７_２では、実行判定部２３が、応答結果「利用可能」から、ＮＣＳ１７_３が新機能に対応していると判断する（ステップＳ４０４）。よって、ＤＥＳＳ１７_２からは、機能利用可否応答部２１により、Ｗｅｂｓｙｓ１７_１に対して、利用可能の旨が応答される（ステップＳ４０５）。

これを受けて、Ｗｅｂｓｙｓ１７_１では、実行判定部２３が、応答結果「利用可能」から、ＤＥＳＳ１７_２及びＮＣＳ１７_３が新機能に対応していると判断する（ステップＳ４０６）。

次に、Ｗｅｂｓｙｓ１７_１は、利用可能段階問い合わせ部２４が、ＤＥＳＳ１７_２に対して、対応済み新機能のうち、どこまで（どの段階）の新機能が利用可能かを問い合わせる（ステップＳ４０７）。

ＤＥＳＳ１７_２では、対応段階応答部２５が、同モジュール１７_２が有する定義情報４０Ｄを参照し、「ＳＳＬプロトコルを設定可能」（段階１）と「暗号化種別を設定可能」（段階２）とを表す定義値"１"，"２"を取得する（ステップＳ４０８）。よって、ＤＥＳＳ１７_２からは、対応段階応答部２５により、Ｗｅｂｓｙｓ１７_１に対して、利用可能な新機能の対応段階（対応済みの新機能Ａ，Ｂ対応する定義値"１"，"２"）が応答される。（ステップＳ４０９）。

これを受けて、Ｗｅｂｓｙｓ１７_１では、実行判定部２３が、同モジュール１７_１が有する定義情報４０Ｄを参照し、定義情報４０Ｄの定義値"１"（段階１），"２"（段階２），"３"（段階３）と応答結果「定義値"１"，"２"」とから、実行可能機能が「暗号化種別を設定可能」（実行段階が段階２）までと判断する（ステップＳ４１０）。このとき、実行判定部２３は、定義値の比較を行い、一致する最大の定義値（定義値"２"）を特定し、特定した定義値に基づき、実行可能な機能が、「暗号化種別を設定可能」（段階２）までと判断する。よって、Ｗｅｂｓｙｓ１７_１からは、ＤＥＳＳ１７_２に対して、判断した実行段階（段階２）が通知される（ステップＳ４１１）。

これにより、ＤＥＳＳ１７_２では、Ｗｅｂｓｙｓ１７_１に対して、通知の旨の了解応答を行い（ステップＳ４１２）、機能実行制御部２０が、機能実行部３０に対して、通知された段階の機能で動作させる指示を出す。その結果、ＤＥＳＳ１７_２では、機能実行部３０が、同モジュール１７_２を「暗号化種別を設定可能」な機能で動作させる（ステップＳ４１３）。

また、Ｗｅｂｓｙｓ１７_１は、ＤＥＳＳ１７_２から了解応答を受け付けると、機能実行制御部２０が、機能実行部３０に対して、実行可能機能で動作させる指示を出す。その結果、Ｗｅｂｓｙｓ１７_１では、機能実行部３０が、同モジュール１７ａを「暗号化種別を設定可能」な機能で動作させる（ステップＳ４１４）。

このように、本実施形態に係る情報処理機能は、機能モジュール１７が階層的に連携して実行される場合であっても、機能モジュール間で、機能のサポート状態（新機能対応済み／未対応などの状態）を順次確認し合い、組み合わせを一致させた上で、連携して実行される。

＜まとめ＞
以上のように、本実施形態に係る情報処理装置１００によれば、機能提供時に連携して実行される機能モジュール間で、次のような処理を行う。

機能利用側の機能モジュール１７ａは、機能利用可否問い合わせ部２２が、機能提供側の機能モジュール１７ｂに対して、提供機能の利用可否の問い合わせを要求する。その結果、機能提供側の機能モジュール１７ｂは、機能利用可否応答部２１が、要求に応じて、利用可否の結果を応答する。

これにより、機能利用側の機能モジュール１７ａは、機能実行制御部２０が、応答結果に基づき、機能実行（変更前／変更後のどちらの機能を動作させるか）を制御する。

これによって、本実施形態に係る情報処理装置１００では、特定の機能モジュール１７を変更する場合、組み合わせが発生する他の機能モジュール１７に、その変更を反映（変更した機能モジュールに対応）させる必要がない。また、本実施形態に係る情報処理装置１００では、機能モジュール１７の組み合わせが多くなっても、ソフトウェアベンダが煩雑な作業を行わなくてよい。その結果、本実施形態に係る情報処理装置１００では、複数の機能モジュール１７の組み合わせを容易に管理できる。

ここまで、上記実施形態の説明を行ってきたが、上記実施形態に係る「情報処理機能」は、図を用いて説明を行った各処理手順を、動作環境（プラットフォーム）にあったプログラミング言語でコード化したプログラムが、情報処理装置１００が備える処理装置（例えば「ＣＰＵ」）により実行されることで実現される。

上記プログラムは、コンピュータが読み取り可能な記録媒体１０３ａに格納することができる。これにより、例えば、上記プログラムは、ドライブ装置１０３を介して、情報処理装置１００にインストールすることができる。また、情報処理装置１００は、インタフェース装置１０７を備えていることから、電気通信回線を用いて上記プログラムをダウンロードし、インストールすることもできる。

また、上記実施形態では、機能モジュール１７が定義情報４０Ｄを有する例を示した。定義情報４０Ｄは、例えば、予めヘッダファイルなどにプログラムコードとして記述しておいた定義値（例えば「Ｄｅｆｉｎｅ値」）を、機能モジュール１７の作成時（コンパイル時）に参照することで、モジュール内に保有できる。

最後に、上記実施形態に挙げた形状や構成に、その他の要素との組み合わせなど、ここで示した要件に、本発明が限定されるものではない。これらの点に関しては、本発明の主旨をそこなわない範囲で変更することが可能であり、その応用形態に応じて適切に定めることができる。

１１ ＯＳ（基本ソフトウェア）
１２ スレッド制御部
１３ ＩＰＣ（プロセス間通信制御部）
１４ サービス層
１５ ＡＰＩ（ソフトウェアインタフェース部）
１６ アプリケーション
１７ 機能モジュール
２０ 機能実行制御部
２１ 機能利用可否応答部
２２ 機能利用可否問い合わせ部
２３ 実行判定部
２４ 利用可能段階問い合わせ部
２５ 対応段階応答部
３０ 機能実行部
４０Ｄ 定義情報（対応済み新機能の定義値）
１００ 情報処理装置
１０１ 入力装置
１０２ 表示装置
１０３ ドライブ装置（ａ：記録媒体）
１０４ ＲＡＭ（揮発性の半導体メモリ）
１０５ ＲＯＭ（不揮発性の半導体メモリ）
１０６ ＣＰＵ（処理装置）
１０７ インタフェース装置（ＮＩＣ：Network I/F Card）
１０８ ＨＤＤ（不揮発性の記憶装置）
Ｂ バス

特開２００７−３０４６３９号公報

Claims (8)

1. 複数の機能モジュール間において、機能利用側の機能モジュールと機能提供側の機能モジュールとを連携して実行し、搭載アプリケーションの機能が実現されるソフトウェア環境を有する情報処理装置であって、
   機能利用側の機能モジュールから機能提供側の機能モジュールに対して、機能提供側の機能モジュールによる提供機能を機能利用側が利用可能か否かの問い合わせ要求を行う機能利用可否問い合わせ手段と、
   機能提供側の機能モジュールから機能利用側の機能モジュールに対して、利用可否結果を応答する機能利用可否応答手段と、
   応答された利用可否結果に基づき、機能利用側の機能モジュールによる提供機能の実行を制御する機能実行制御手段と、を有することを特徴とする情報処理装置。
2. 前記機能実行制御手段は、
   前記機能利用可否応答手段から、機能利用側が利用不可能の結果が応答された場合、
   新機能対応前の従来機能が動作するように、機能利用側の機能モジュールの実行を制御し、
   一方、前記機能利用可否応答手段から、機能利用側が利用可能の結果が応答された場合、
   新機能対応後の機能が動作するように、機能利用側の機能モジュールの実行を制御することを特徴とする請求項１に記載の情報処理装置。
3. 機能利用側の機能モジュールから機能提供側の機能モジュールに対して、機能提供側の機能モジュールによる提供機能のうち、機能利用側が利用可能な機能段階の問い合わせ要求を行う利用可能段階問い合わせ手段と、
   機能提供側の機能モジュールから機能利用側の機能モジュールに対して、機能利用側が利用可能な新機能の対応段階を応答する対応段階応答手段と、を有し、
   前記機能実行制御手段は、
   応答された利用可能な新機能の対応段階に基づき、機能利用側の機能モジュールによる提供機能の実行を制御することを特徴とする請求項１又は２に記載の情報処理装置。
4. 前記利用可能段階問い合わせ手段は、
   前記機能利用可否応答手段から、機能利用側が利用可能の結果が応答された場合、
   機能利用側が利用可能な機能段階の問い合わせ要求を行うことを特徴とする請求項３に記載の情報処理装置。
5. 前記機能モジュールが、
   他の機能モジュールと共通する定義値を用いて、当該モジュールで対応済みの新機能を表す情報が定義された定義情報を有し、
   前記対応段階応答手段は、
   機能提供側の機能モジュールが有する定義情報を、機能利用側が利用可能な新機能の対応段階を表す情報として応答することを特徴とする請求項３又は４に記載の情報処理装置。
6. 前記機能実行制御手段は、
   機能利用側の機能モジュールが有する定義情報の定義値と、前記対応段階応答手段から応答された定義情報の定義値とを比較し、一致する最も値の大きい定義値を特定し、特定した定義値に対応する新機能が動作するように、機能利用側の機能モジュールの実行を制御することを特徴とする請求項５に記載の情報処理装置。
7. 複数の機能モジュール間において、機能利用側の機能モジュールと機能提供側の機能モジュールとを連携して実行し、搭載アプリケーションの機能が実現されるソフトウェア環境を有する情報処理装置における情報処理方法であって、
   機能利用側の機能モジュールから機能提供側の機能モジュールに対して、機能提供側の機能モジュールによる提供機能を機能利用側が利用可能か否かの問い合わせ要求を行う機能利用可否問い合わせ手順と、
   前記機能利用可否問い合わせ手順による要求に応じて、機能提供側の機能モジュールから機能利用側の機能モジュールに対して、利用可否結果を応答する機能利用可否応答手順と、
   前記機能利用可否応答手順により応答された利用可否結果に基づき、機能利用側の機能モジュールによる提供機能の実行を制御する機能実行制御手順と、を有することを特徴とする情報処理方法。
8. 複数の機能モジュール間において、機能利用側の機能モジュールと機能提供側の機能モジュールとを連携して実行し、搭載アプリケーションの機能が実現されるソフトウェア環境を有する情報処理装置における情報処理プログラムであって、
   コンピュータを、
   機能利用側の機能モジュールから機能提供側の機能モジュールに対して、機能提供側の機能モジュールによる提供機能を機能利用側が利用可能か否かの問い合わせ要求を行う機能利用可否問い合わせ手段と、
   前記機能利用可否問い合わせ手段による要求に応じて、機能提供側の機能モジュールから機能利用側の機能モジュールに対して、利用可否結果を応答する機能利用可否応答手段と、
   前記機能利用可否応答手段により応答された利用可否結果に基づき、機能利用側の機能モジュールによる提供機能の実行を制御する機能実行制御手段として機能させる情報処理プログラム。

Images