(57)【要約】【課題】パーベイシブコンピューティング環境において、文脈の変化に透明（transparent）にアプリケーションプログラムを再構成できるアプリケーションプログラムの再構成方法及びそのシステムを提供する。【解決手段】アプリケーションプログラムの再構成システムは、所定アプリケーションプログラムを構成するサービスコンポーネントに関する情報を格納するサービスコンテナ１１０と、サービスコンポーネントに対して、文脈の変化に対応するサービス情報を探索する代替方針判断部１２０と、サービスコンポーネントと対応するサービス情報との間のマッピング情報を格納するマッピングテーブル１３０と、サービス情報の探索のための情報を格納するタイプ格納部１５０と、マッピング情報に応じて、所定アプリケーションプログラムの実行要請を処理するイベント解析部１４０とを備える。【選択図】図１
2006228221.tif 000002
【特許請求の範囲】
【請求項１】
パーベイシブコンピューティング環境におけるアプリケーションプログラムの再構成方法において、
文脈の変化にともなう所定アプリケーションプログラムの再構成要請を受けるステップと、
前記所定アプリケーションプログラムを構成する少なくとも１つのサービスコンポーネント各々に対して、前記文脈の変化に対応するサービスを探索するステップと、
探索された前記サービスに基づいて、前記所定アプリケーションプログラムを再構成するステップと、
を含むことを特徴とするアプリケーションプログラムの再構成方法。
【請求項２】
前記サービスを探索するステップは、
前記サービスコンポーネントと同じ機能を提供するサービスを探索するステップと、
前記サービスコンポーネントと同じ機能を提供するサービスが存在しない場合に、代替可能なサービスを探索するステップと、
を含むことを特徴とする請求項１に記載のアプリケーションプログラムの再構成方法。
【請求項３】
前記代替可能なサービスは、ｂｅｈａｖｉｏｒ  ｓｕｂ‐ｔｙｐｉｎｇ概念に基づき、前記代替可能なサービスは、サブタイプへの代替、スーパータイプへの代替、及びスーパータイプへの型変換のうち、いずれかの方式で決定されることを特徴とする請求項２に記載のアプリケーションプログラムの再構成方法。
【請求項４】
前記文脈の変化は、ユーザが新しい環境へ移動した場合と、機器が動的に出現した場合と、サービスが動的に出現した場合とのうち、少なくとも１つにより発生することを特徴とする請求項１ないし請求項３のいずれか一項に記載のアプリケーションプログラムの再構成方法。
【請求項５】
パーベイシブコンピューティング環境において、文脈の変化に応じてアプリケーションプログラムを再構成するアプリケーションプログラムの再構成システムにおいて、
所定アプリケーションプログラムを構成する少なくとも１つのサービスコンポーネントに関する情報を格納するサービスコンテナと、
前記サービスコンポーネント各々に対して、文脈の変化に対応するサービス情報を探索する代替方針判断部と、
前記サービスコンポーネントと前記対応するサービス情報との間のマッピング情報を格納するマッピングテーブルと、
を備えることを特徴とするアプリケーションプログラムの再構成システム。
【請求項６】
前記サービス情報の探索のための情報を格納するタイプ格納部をさらに備えることを特徴とする請求項５に記載のアプリケーションプログラムの再構成システム。
【請求項７】
前記マッピングテーブルに格納された前記マッピング情報に応じて、前記所定アプリケーションプログラムの実行要請を処理するイベント解析部をさらに備えることを特徴とする請求項５または請求項６に記載のアプリケーションプログラムの再構成システム。
【請求項８】
前記代替方針判断部は、前記サービスコンポーネントと同じ機能を提供するサービスを探索し、前記サービスコンポーネントと同じ機能を提供するサービスが存在しない場合、代替可能なサービスを探索することを特徴とする請求項５ないし請求項７のいずれか一項に記載のアプリケーションプログラムの再構成システム。
【請求項９】
ユーザが移動した環境において、移動前環境でのサービスコンポーネントと同じサービスコンポーネントが存在するか否かを探索するサービスディスカバリをさらに備えることを特徴とする請求項５ないし請求項８のいずれか一項に記載のアプリケーションプログラムの再構成システム。
【請求項１０】
前記代替可能なサービスは、ｂｅｈａｖｉｏｒ  ｓｕｂ‐ｔｙｐｉｎｇ概念に基づき、前記代替可能なサービスは、サブタイプへの代替、スーパータイプへの代替、及びスーパータイプへの型変換のうち、いずれかの方式で決定されることを特徴とする請求項８に記載のアプリケーションプログラムの再構成システム。
【請求項１１】
前記文脈の変化は、ユーザが新しい環境へ移動した場合と、機器が動的に出現した場合と、サービスが動的に出現した場合とのうち、少なくとも１つにより発生することを特徴とする請求項５ないし請求項１０のいずれか一項に記載のアプリケーションプログラムの再構成システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アプリケーションプログラムの再構成方法及びそのシステムに関し、特に、パーベイシブコンピューティング環境（Pervasive Computing Environment）におけるアプリケーションプログラムの再構成方法及びそのシステムに関する。
【背景技術】
【０００２】
従来、ネットワーキングの拡散とコンピュータ機器の偏在性とにより、パーベイシブコンピューティング時代が早く到来すると予想されている。パーベイシブコンピューティングの目標の１つは、様々な理由によって変わる文脈（context）変化に応じて、最低のオーバーヘッド（overhead）でユーザに現在自分が行う作業を持続的に行うように、システムがユーザに透明（transparent）に支援することにある。このような透明性の支援のために、パーベイシブコンピューティングシステムは、ユーザの要求事項を予め予測して（context-awareness）、ユーザが新しい環境へ移動したときに使用可能なサービスで、アプリケーションプログラムを再構成する技術が要求される。
【０００３】
パーベイシブ環境において動的アプリケーションプログラムの再構成を支援するための従来の代表的な研究には、ＧａｉａシステムとＡｕｒａシステムがある。これらは、それぞれアプリケーションプログラム(application）とタスク(task)の移動にともなうアプリケーションプログラムの再構成を支援するためのものである。これらのシステムの主要な理念は、アプリケーションプログラムを抽象的かつ環境に独立的に記述して、アプリケーションプログラムがいかなる環境に移動するにせよ、各々の異なる環境に適応できるようにすることである。
【０００４】
Ｇａｉａシステムは、様々な異種の装置を含むactive space（物質的な境界の存在しない空間)間のアプリケーションプログラムの移動性（mobility）を取り扱っている。active spaceにおけるアプリケーションプログラムは、分散されたコンポーネントの集まりから構成されており、active spaceに独立的なＡＧＤ（Application Generic Description）で記述される。アプリケーションプログラムは、ＡＧＤを各環境で利用可能な資源で記述したＡＣＤ（Application Customized Description）によって初期化し実行される。Ｇａｉａシステムは、様々な環境における多様性（heterogeneity）に対する問題を解決しようとしたが、サービスの多様性よりは、機器の多様性に焦点を合せている。換言すれば、Ｇａｉａシステムは、すべてのactive spaceにおいて、アプリケーションプログラムのコンポーネントとして用いられるサービスがすべて使用可能であるということを前提としている。
【０００５】
しかし、このような仮定は、パーベイシブコンピューティング環境に適していない。すなわち、新しい環境で同様のサービスがないときにも、アプリケーションプログラムが動的に適応できるように支援することによって、サービスの多様性問題を解決する必要性があるが、Ｇａｉａシステムの場合、このようなサービスの多様性の問題を考慮していない。
【０００６】
また、Ａｕｒａシステムは、タスク移動性（task mobility）を支援するシステムである。ここで、タスクとは、色々な抽象化されたサービスの連合から構成される単位であり、環境に独立的に記述される。各環境において、サービスは、環境に具体化されてタスクを支援するが、例えば、「文編集」というタスクは、ウィンドウ環境では、ＭＳ  ＷｏｒｄやＮｏｔｅｐａｄで行われ、ユニックスやリナックス（登録商標）環境では、ＶｉやＥｍａｃｅで行われる。このように、Ａｕｒａシステムは、多様性を、サービスと運営体制の観点で解決しようとした。しかし、サービス間の機能的類似性あるいは一致（functional conformance）に対する点が看過されている。例えば、ＭＳ  Ｗｏｒｄが提供する機能は、Ｎｏｔｅｐａｄでは、同様には提供されていないということが挙げられる。また、ユーザが、２つのサービス間の機能的な不一致に対して、それぞれ適応して使用しなければならないという短所があり、代替可能なサービス間の機能的一致を保障できない。
【０００７】
したがって、ＧａｉａシステムとＡｕｒａシステムとで用いられるアプローチの問題点は、次の通りである。すなわち、ユーザが新しい環境へ移動したとき、それらは、単に既存のサービスと同様のもののみを探索しようとするか、それとも、類似のサービスのみを探索しようとする。もし、同様のサービスが存在しないにもかかわらず同様のサービスのみを探索しようとする場合、アプリケーションプログラムの再構成は失敗するはずである。これは、ユーザが直接アプリケーションプログラムの再構成のためにサービスを選択しなければならないということを意味する。また、既存のサービスが類似のサービスに交替されるとしても、そのサービスが、既存のサービスにおいてユーザが望む機能を同様に提供することが保障できない。
【０００８】
一方、ＣＢＳＥ（Component-based Software Engineering）領域では、既に他の環境における柔軟なサービス適応を支援するための多様な方法が提示されている。サービスが有する意味自体を解析、比較することによって、代替可能なサービスを探索する方法が、アプリケーションプログラムコンポーネントの再構成に用いられてきた。このような方法は、広範囲な領域に適しており、極めて柔軟な方法であるが、サービス提供者にサービスの機能に対する極めて詳細な記述を要求する。Ｓｕｂ‐ｔｙｐｉｎｇも、従来からコンポーネントを代替するために用いられた技術である。ｂｅｈａｖｉｏｒ  ｓｕｂ‐ｔｙｐｉｎｇの概念は、各機能（関数）に対する作用を記述することによって、サブタイプ（sub-type）とスーパータイプ（super-type）の機能間に意味論的な代替が可能なようにするものである。従来のｂｅｈａｖｉｏｒ  ｓｕｂ‐ｔｙｐｉｎｇを基にした方法は、代替可能なサービスを探索するとき、サービス間の階層関係のみに限定しなかった。すなわち、要求されるサービスのサブタイプが存在しない場合にも、類似の機能のサービスを探索してきた。
【０００９】
この方法もまた、サービス提供者にサービス機能に対する詳細な記述を要求する。また、依然として、代替されるサービスが既存のサービスと機能的に完全に一致するとは保障できない。
【発明の開示】
【発明が解決しようとする課題】
【００１０】
本発明は、前記の従来の問題を解決するためになされたものであって、その目的は、パーベイシブコンピューティング環境において、文脈の変化に透明（transparent）にアプリケーションプログラムの再構成が可能なアプリケーションプログラムの再構成方法及びそのシステムを提供することにある。
【課題を解決するための手段】
【００１１】
前記した目的を達成するために、本発明のアプリケーションプログラムの再構成方法は、パーベイシブコンピューティング環境におけるアプリケーションプログラムの再構成方法において、文脈の変化にともなう所定アプリケーションプログラムの再構成要請を受けるステップと、前記所定アプリケーションプログラムを構成する少なくとも１つのサービスコンポーネント各々に対して、前記文脈の変化に対応するサービスを探索するステップと、探索された前記サービスに基づいて、前記所定アプリケーションプログラムを再構成するステップとを含むことを特徴とする。
【００１２】
また、アプリケーションプログラムの再構成方法は、前記サービスを探索するステップが、前記サービスコンポーネントと同じ機能を提供するサービスを探索するステップと、前記サービスコンポーネントと同じ機能を提供するサービスが存在しない場合に、代替可能なサービスを探索するステップとを含むことが好ましい。
【００１３】
また、アプリケーションプログラムの再構成方法は、前記代替可能なサービスが、ｂｅｈａｖｉｏｒ  ｓｕｂ‐ｔｙｐｉｎｇ概念に基づいて探索されることが可能である。
また、前記代替可能なサービスは、サブタイプへの代替（substituion）、スーパータイプへの代替、及びスーパータイプへの型変換（coercion）のうち、いずれかの方式で決定されることが好ましい。
【００１４】
また、アプリケーションプログラムの再構成方法は、前記文脈の変化が、ユーザが新しい環境へ移動した場合と、機器が動的に出現した場合と、サービスが動的に出現した場合とのうち、少なくとも１つにより発生することが好ましい。
【００１５】
また、前記した目的を達成するために、本発明のアプリケーションプログラムの再構成システムは、パーベイシブコンピューティング環境において、文脈の変化に応じてアプリケーションプログラムを再構成するアプリケーションプログラムの再構成システムにおいて、所定アプリケーションプログラムを構成する少なくとも１つのサービスコンポーネントに関する情報を格納するサービスコンテナと、前記サービスコンポーネント各々に対して、文脈の変化に対応するサービス情報を探索する代替方針判断部と、前記サービスコンポーネントと前記対応するサービス情報との間のマッピング情報を格納するマッピングテーブルとを備えることを特徴とする。
【００１６】
また、アプリケーションプログラムの再構成システムは、好ましくは、前記サービス情報の探索のための情報を格納するタイプ格納部と、前記マッピングテーブルに格納された前記マッピング情報に応じて、前記所定アプリケーションプログラムの実行要請を処理するイベント解析部とをさらに備える。
【００１７】
また、アプリケーションプログラムの再構成システムは、前記代替方針判断部が、前記サービスコンポーネントと同じ機能を提供するサービスを探索し、前記サービスコンポーネントと同じ機能を提供するサービスが存在しない場合、代替可能なサービスを探索することが好ましい。
【００１８】
また、アプリケーションプログラムの再構成システムは、前記代替可能なサービスが、ｂｅｈａｖｉｏｒ  ｓｕｂ‐ｔｙｐｉｎｇ概念に基づいて探索されることが可能である。また、前記代替可能なサービスは、サブタイプへの代替、スーパータイプへの代替、及びスーパータイプへの型変換のうち、いずれかの方式で決定されることが好ましい。
【００１９】
また、アプリケーションプログラムの再構成システムは、前記文脈の変化が、ユーザが新しい環境へ移動した場合と、機器が動的に出現した場合と、サービスが動的に出現した場合とのうち、少なくとも１つにより発生することが好ましい。
【発明の効果】
【００２０】
本発明によれば、パーベイシブコンピューティングの主目的である動的に変化する環境に対して、ユーザに代わってシステムが適応することによって、ユーザは、自分の作業のみに集中できる。パーベイシブ環境のアプリケーションプログラムは、ユーザの移動、あるいは機器やサービスの動的な出現による文脈の変化に透明かつ動的に適応しなければならないが、本発明は、ユーザが新しい環境へ移動したときに、既存のサービスと同様のサービスが存在しない場合にも、ｓｕｂ‐ｔｙｐｉｎｇの概念を利用してサブタイプかスーパータイプに代替されて、アプリケーションプログラムの再構成が透明に行われるようにする。そして、ｂｅｈａｖｉｏｒ  ｓｕｂ‐ｔｙｐｉｎｇを適用することによって、本発明は、柔軟性と機能的一致を保障できるという長所が得られる。
【発明を実施するための最良の形態】
【００２１】
以下、添付の図面に基づいて本発明の好適な実施形態を詳述する。
【００２２】
従来のアプリケーションプログラムの再構成方法は、要求されるサービスと同様のサービスが新しい環境に存在しない場合、類似のサービスを探索するか、ユーザが直接アプリケーションプログラムのサービスを選択しなければならない方法であった。これに対して、本発明に係るアプリケーションプログラムの再構成方法は、代替されるサービスを選択するときに、機能的一致を保障するために、ｂｅｈａｖｉｏｒ  ｓｕｂ‐ｔｙｐｉｎｇの概念（置き換えの原理）を採用した弾力的なサービス再構成技法を使用する。ｂｅｈａｖｉｏｒ  ｓｕｂ‐ｔｙｐｉｎｇは、新しい文脈において、既存のサービスがない場合には、このサービスのサブタイプかスーパータイプへの代替を可能にする概念で説明できる。この方法により、アプリケーションプログラムは、柔軟に環境内で利用可能な同じタイプであるサービスと接続されるだけでなく、機能的一致（functional conformance）も保障されることになる。条件を緩和させるために、サービス提供者が新しいサービスを設計する場合、ｓｔｒｏｎｇあるいはｗｅａｋ概念のうち、いずれかの概念のｂｅｈａｖｉｏｒ  ｓｕｂ‐ｔｙｐｉｎｇを使用することを許諾することができる。これは、サブタイプで新しく追加される機能が、スーパータイプ機能の組み合わせに代替されることもできるし、あるいは、できないこともあり得るということを意味する。
【００２３】
要求されるサービスが新しい環境に存在しない場合、サービスを適応させる方法に、次のような３つのケースを考えることができる。
第１は、要求されるサービスのサブタイプに代替される場合である。サブタイプのサービスは、スーパータイプのすべての機能に対して対応する機能を提供するため、もし、サブタイプに代替される場合、サービスのすべての機能がそのまま提供される。すなわち、すべてのサブタイプは、スーパータイプと機能的一致をなしていると言える。以下、これを「サブタイプへの代替」という。
【００２４】
第２は、要求されるサービスがスーパータイプに変換される場合である。このような状況は、新しい環境において、要求されるサービスのサブタイプが１つも存在しない場合に生じることができる。その場合には、２つのケースがある。
【００２５】
まず、要求されるサービスが、スーパータイプのサービスに代替される場合である。サブタイプの追加的な機能が、スーパータイプの機能の組み合わせに代替される場合である。以下、これを「スーパータイプへの代替」という。
【００２６】
次に、サブタイプの追加的な機能に対して、スーパータイプのある機能に交替される場合である。このような場合は、サービス提供者がサブタイプに新しい機能を追加するときに、その機能がスーパータイプの機能の組み合わせに代替できない場合、すなわち機能的一致が保障できない場合、スーパータイプの他の機能に交替することを意味する。以下、これを「スーパータイプへの型変換」という。
【００２７】
このように、サブタイプの追加的な機能に対して、この機能がスーパータイプに代替されるか、あるいは、スーパータイプに型変換されるかに対する情報は、サービス提供者のサービス記述に依存する。
【００２８】
すなわち、サービス提供者は、この情報を新しいサービス設計時に記述しなければならない。本発明では、このような事項を記述できる方法を提供することによって、スーパータイプに変換することを可能にする。しかし、スーパータイプに変換することは、ユーザの意図とは異なって、機能が交替され得るので、アプリケーションプログラムの方針（policy）により決定される。また、他のサービスに変換されたとすれば、サブタイプに代替された機能、または、スーパータイプに代替（型変換）された機能に対するマッピング情報を提供しなければならない。これは、ユーザが要求するサービスの機能を代替したサブタイプの機能、または、スーパータイプの機能で実行する際に、透明に３つの形態、すなわちサブタイプへの代替、スーパータイプへの代替、スーパータイプへの型変換に変換するためである。
【００２９】
もし、新しいサービスを設計する場合に、既存のサービスを利用して設計するならば、サービスの適応を透明に支援するために、サービス提供者がサービス記述書中に追加的に提供しなければならない情報は、次の通りである。
【００３０】
第１に、タイプ間の連関関係、すなわちどんなサービスがスーパータイプであるかに対する情報を記述しなければならない。この情報は、タイプ階層ツリーを作るのに必要な情報である。
【００３１】
第２に、実行時に要求されるサービスの機能を代替するために代替されるサービスの機能に対する情報を記述しなければならない。この情報は、このサービスがスーパータイプに代替される場合、追加的な機能がスーパータイプの機能に代替されるか、あるいは、スーパータイプの機能に交替されるかに対する情報である。
【００３２】
最後に、サービスの各機能に対して前状態（pre-condition）と後状態（post-condition）とを記述する。これらは、サービス提供者が新しいサービスをデザインするとき、代替可能なサービスを記述することを手助けする役割を果たす。
【００３３】
このような３つの要求事項が、サービスの機能的な記述と共に、サービス記述書中に共に記述されなければならない。このような情報は、後記するタイプ格納部（Type Repository）に格納されることができる。
【００３４】
以下、アプリケーションプログラムの構成情報、すなわちどのような分散サービスコンポーネントからなっているか、それらの間にどのように相互作用するか（内部的に従属したコンポーネント情報をも含んで）は、ユーザが新しい環境へ移動したときに、その移動した環境に伝送されると仮定する。ここで、コンポーネント間の相互作用は、publish/subscribeのようなメッセージ基盤のシステムを仮定する。その理由は、このモデルがパーベイシブ環境に適した様々な長所を有しているためである。
【００３５】
図１は、本発明の一実施形態に係るアプリケーションプログラムの再構成システムのブロック図である。
【００３６】
図１に示すように、本アプリケーションプログラムの再構成システムは、サービス適応管理部（Service Adaptation Manager part）１００と、タイプ格納部１５０とを備える。サービス適応管理部１００は、サービスコンテナ（Service Container）１１０と、代替方針判断部（Substitution Policy Decision part）１２０と、マッピングテーブル（Mapping Table）１３０と、イベント解析部（Event Translation Module）１４０とを備え、アプリケーションフレームワーク（Application Framework）９０からアプリケーションプログラムの再構成要請を受けて、これを処理する。そして、代替方針判断部１２０は、探索部１２２を備える。
【００３７】
サービスコンテナ１１０は、アプリケーションプログラムに関する情報、すなわちどのようなサービスコンポーネントからなっているかに対する情報を、オブジェクトそれ自体の形態ではない、コンポーネントを表すことのできる情報の形態で格納する。サービスコンポーネントの唯一性のために、アプリケーションプログラムと各サービスとは、唯一のＩＤを有すると仮定する。また、サービスコンテナ１１０には、アプリケーションプログラムの再構成以後に代替されたサービスに関する識別情報を格納する。これは、実行時にユーザが要求するメッセージを透明に変えるためである。
【００３８】
代替方針判断部１２０は、ｂｅｈａｖｉｏｒ  ｓｕｂ‐ｔｙｐｉｎｇの概念を行う部分である。すなわち、サービスコンテナ１１０から渡されたアプリケーションプログラムの情報にて、ユーザが現在移動した環境内でアプリケーションプログラムのサービスコンポーネントを探索する役割を担当する。このために、探索部１２２は、タイプ格納部１５０から代替可能なサービスに関する情報を抽出する役割を果たす。このとき、各環境ごとに環境領域内のサービスが存在するか否かの識別が可能なサービスディスカバリ（Service Discovery）８０があるものと仮定する。
【００３９】
代替方針判断部１２０の動作は、次のような３つの過程からなる。
まず、サービスディスカバリ８０を利用して、ユーザが移動した環境内で同様のサービスが存在するか否かを識別する。もし、同様のサービスが存在しない場合、タイプ格納部１５０からサブタイプかスーパータイプの情報を抽出して、そのサービスがその環境に存在するか否かと、代替可能であるか否かを判別する。このとき、サブタイプへの代替を先に試みてから、スーパータイプへの代替を試みる。最後に、代替されるサービスへの情報をマッピングテーブル１３０に格納する。このとき、要求されるサービスの機能を正確にマッピングさせるために、operation overloading（関数の名前は同様で、媒介変数が異なる場合）の場合も考慮する。もし、代替が可能でない場合には、他のサブタイプへの代替を試みるか、スーパータイプへの代替を再び試みる。このような３つの過程を経ながら、代替可能なサービスを探索する。もし、満足するサービスが存在しない場合には、アプリケーションプログラム再構成は失敗することとなる。
【００４０】
マッピングテーブル１３０には、代替方針判断部１２０の実行結果として、既存のサービスと代替されたサービスとの間のマッピング情報を格納する。格納される情報は、どんなサービスに代替されるか、またどんな機能に代替あるいは型変換されるかに対するもの（スーパータイプに変換される場合）である。このとき、前者の場合を「サービスマッピング情報」と定義し、後者の場合を「機能マッピング情報」と定義する。もし、要求されるサービスがサブタイプに代替される場合には、サービスマッピング情報のみが格納される。その理由は、サブタイプは、スーパータイプから提供する機能をそのまますべて提供するためである。すなわち、サービスがサブタイプに代替された場合、要求されるサービスのある機能をユーザが要求したとき、サブタイプでも同様の機能をそのまま提供するため、単にメッセージの目的地のみを変えれば良いからである。しかし、スーパータイプに代替された場合、サービスマッピング情報のみでなく、機能マッピング情報も格納しなければならない。その理由は、サブタイプのサービスの追加的な機能をスーパータイプからは同様に提供しないためである。したがって、マッピングテーブル１３０は、スーパータイプに代替された場合、サブタイプから提供する追加的な機能が、スーパータイプのいかなる機能にマッピングされるかに関する情報を保管するように構成されている。
【００４１】
このように、サブタイプに変換される場合と、スーパータイプに変換される場合とは、格納しなければならない情報が互いに異なり、変えなければならない情報が異なるため、検索時間の効率性のためと、システムが次の過程を速く決定できるようにするために、２つの格納領域を備えて、それぞれ別に格納することとなる。このようなマッピング情報は、イベント解析部１４０で用いられるようになる。
【００４２】
イベント解析部１４０は、実行の際にメッセージ形態で現れる各コンポーネント間のサービス機能に対する要求を処理する。もし、サブタイプかスーパータイプサービスに代替されたサービスに対する機能を要求するメッセージが発生した場合、イベント解析部１４０では、一応、マッピングテーブル１３０に格納された情報を読み込んで透明に変換させるが、このとき、前記したように、各ケースに応じて、メッセージを異なるように変換させる。もし、要求するサービスの機能が代替されなかった場合には、単純に、そのメッセージを目的地に伝送する役割を果たす。すなわち、サービスが代替されたか否かに関係なく、ユーザの要求を透明に処理する役割を担当する。
【００４３】
タイプ格納部１５０は、サービスの情報を抽出するために用いられる。すなわち、要求されるサービスタイプはもちろん、サブタイプかスーパータイプに対する情報を抽出するために用いられる。サービスの情報は、そのサービスが提供するすべての機能的な（functional）側面と、各機能の作用（behavior）に対する情報を意味する。このような情報を表すために、サービス階層ツリー（service hierarchy tree）をタイプ格納部１５０に作っておく。このサービス階層ツリーは、システムにとって既存のサービスがサブタイプかスーパータイプに変換されるときに、マッピング（mapping）情報を作ることができるようにするためのものである。
【００４４】
タイプ格納部１５０で管理するサービス階層ツリーは、サービス間の連関関係はもちろん、サービスに対する情報を格納する所である。ここで、サービス階層ツリーは、機器（device）間の階層ツリーを意味するものではない。その理由は、１つの機器から複数のサービスの提供が可能であるためである。したがって、サービス階層ツリーは、各サービスの種類別に存在する。サービス階層ツリーは、タイプ格納部１５０に新しいサービスがサービス提供者から登録されるとき、そのサービスを解析することによって作られる。
【００４５】
本発明に係るアプリケーションプログラムの再構成方法を支援するために、さらに要求される事項は次の通りである。すなわち、どんなサービスがスーパータイプであるかを表すことのできるサービス連関関係に対することが表わされなければならず（第１）、スーパータイプにサービスが代替される場合に備えて、サービスの追加機能に対しては、どんなスーパータイプの機能が代替あるいは型変換するかに対する情報を表さなければならない（第２）。最後に、pre-conditionとpost-conditionとを記述する（第３）ことによって、サービス提供者が新しいサービスを設計するとき、追加的な機能の代替可能な機能を記述できるように助けることができる。第２と第３に要求される記述は、サービス記述書内の機能（operation）に対する記述内に従属的に記述される。
【００４６】
次の表１は、サービス階層ツリーで格納するサービスに対する情報を示す。このような情報は、アプリケーションプログラムの再構成の際に、代替方針判断部１２０から抽出されて、マッピングテーブル１３０を作成するために用いられる。
【００４７】
【表１】
2006228221.tif 000003
【００４８】
表１において、「substitutableOperation＊」フィールドは、選択フィールドであって、新しい環境において、既存サービスがスーパータイプに型変換される場合、この機能をどんな機能が代替あるいは型変換するかに対する情報を格納する所である。このフィールドは、サブタイプで新しく追加された機能に対してのみ記述すればよい。それは、他の機能は、スーパータイプでも同様に提供されるためである。前記したように、代替（substitution）と型変換（coercion）の２つの場合が可能なために、このフィールドの値によって、どんな場合であるのかを記述する。それは、各ケースに応じて、イベント解析部１４０で支援しなければならない過程が異なるためである。さらに、この情報だけでなく、代替される機能の名前と返還値（restore value）とを記述する。代替される機能に対する情報を記述するとしても、ユーザが自らの使用する機能の低下を望まない場合があるため、スーパータイプへの代替あるいは型変換の場合は、アプリケーションプログラムの方針（policy）にしたがう。表１に示す他のフィールドの情報は、フィールドの名前が意味する通りに、サービスの各機能に対する情報を示す。
【００４９】
図２は、本発明の一実施形態に係るアプリケーションプログラムの再構成システムにおけるアプリケーションプログラムの再構成方法の説明に提供されるメッセージ伝送フローチャートである。このような過程は、ユーザが新しい環境へ移動した場合、機器が動的に出現した場合、サービスが動的に出現した場合などのような場合に発生する。
【００５０】
まず、サブタイプへの代替過程は、次の通りである。
サービス適応管理部１００は、ユーザが新しい環境へ移動するなどの場合、アプリケーションフレームワーク９０からアプリケーションプログラムの再構成要請を受ける（Ｓ２００）。これにより、サービス適応管理部１００は、サービス適応管理部１００内のサービスコンテナ１１０からアプリケーションプログラムの情報、すなわちどのようなサービスコンポーネントからなっているかに対する情報であるサービスコンポーネントリストを代替方針判断部１２０に伝送する（Ｓ２０５）。
【００５１】
代替方針判断部１２０は、伝送されたサービスコンポーネントリストを参照して、各サービスコンポーネントが代替可能であるか否かをタイプ格納部１５０を介して探索し（Ｓ２１０）、タイプ格納部１５０から探索されたサービスコンポーネント情報を伝送する（Ｓ２１５）。探索されたサービスコンポーネント情報が、仮に、同じサービスタイプである場合、探索部１２２は、タイプ格納部１５０のサービス階層関係を解析して、サブタイプを探索する。このとき、サービス間の類似性を考慮して、既存サービスと最も近いサブタイプから順に探索する。
【００５２】
この代替方針判断部１２０は、サブタイプが現在の環境に存在するか否かをサービスディスカバリ８０を介して確認し、もし、存在しなければ、他のサブタイプへの代替を試みる。この過程は、現在の環境に存在するサブタイプを探索するまで続けられる。これにより、代替方針判断部１２０は、代替可能なサービスを決定する（Ｓ２２０）。
【００５３】
そして、代替方針判断部１２０は、代替結果、すなわち既存のサービスと代替されたサービス間のマッピング情報をマッピングテーブル１３０に格納する（Ｓ２２５）。ステップＳ２１５ないしステップＳ２２５の過程は、すべてのコンポーネントに対して行われ、このような過程が終われば、代替方針判断部１２０は、代替されたサービスリストをアプリケーションフレームワーク９０に格納する（Ｓ２３０）。
【００５４】
マッピングテーブル１３０には、単に、どんなサブタイプが代替されたかに関する情報のみ格納する。もし、いずれかのサブタイプも現在の環境に存在しない場合には、代替方針判断部１２０では、このサービスのスーパータイプへの代替／型変換を試みる。もちろん、スーパータイプも現在の環境に存在しない場合には、アプリケーションプログラムの再構成は失敗することとなる。前記したように、スーパータイプに代替されるか型変換されるかは、サービス提供者の方針にしたがい、型変換される過程は、以下に示すように、最初の過程は同一であるが、サービス階層ツリーの「substitutableOperation＊」フィールド（表１参照）の記述に応じて、スーパータイプへの代替であるか、または、型変換であるかが決定される過程が異なる。
【００５５】
次に、スーパータイプに「代替」される場合には、探索部１２２でサービス階層関係を解析して、要求するサービスのスーパータイプを探索する。サブタイプへの変換過程とは異なり、ここでは、単に直上位のスーパータイプのみを持ってくる。その理由は、サービス提供者がサービスを記述するとき、直上位のスーパータイプとのマッピング情報のみを記述するためである。そして、タイプ格納部１５０からスーパータイプのサービスを探索部１２２に渡せば、このサービスが現在の環境に存在しているか否かをサービスディスカバリ８０が確認することができる。
【００５６】
代替方針判断部１２０において、既存サービスの追加的な機能がスーパータイプに代替可能な場合、追加的な機能の「substitutableOperation＊」フィールドの記述が、スーパータイプ機能の組み合わせで記述される。このようなフィールドの記述内容は、マッピングテーブル１３０に格納される。
【００５７】
次に、スーパータイプに「型変換」される場合は、代替方針判断部１２０で既存サービスの追加的な機能がスーパータイプに代替不可能な場合である。これは、追加的な機能の「substitutableOperation＊」フィールドの記述が、スーパータイプの他の機能に記述された場合である。すなわち、他の機能に交替（型変換）されるということを意味する。この場合にも、フィールドの記述内容をマッピングテーブル１３０に格納する。
【００５８】
サービス階層ツリーで検索したサービスから代替可能な機能を探索するために、代替方針判断部１２０では、２つの検索方法を使用する。
第１に、名前基盤検索を行うものであって、これは、代替可能なサービスから同じ名前を有する機能を探索するものである。これは、文法マッチング（Syntactic matching）方法である。すなわち、関数（機能）の名前と媒介変数、そして返還値が同じである場合、同じ機能を行うサービスであるとみなすという方法である。名前基盤検索ですべてが探索できない場合（スーパータイプへの代替／型変換の場合）には、意味基盤検索を行う。これは、「substitutableOperation＊」フィールドの情報を検査して、追加的な機能がいかなる機能に変換されるかを探索する方法である。
【００５９】
一方、新しく移動した環境において、アプリケーションプログラムの再構成以後、実行時にユーザが要請したメッセージを変換する過程が必要である。これは、次のような過程によりなる。すなわち、ユーザが要求したメッセージを透明化可能に伝送するために、サービスコンテナ１１０は、一応、ユーザが要求するサービスが新しい環境で代替されたか否かを確認する。もし、このサービスが代替されなかった場合、ユーザの要求は、イベント解析部１４０に伝送された後、そのイベントを送る（publish）。しかし、要求するサービスが他のサービスに代替された場合には、ユーザが要求したサービスがどのように代替されたかの情報を確認するために、マッピングテーブル１３０に送り、そして、マッピングテーブル１３０は、その情報を再びイベント解析部１４０に送る。メッセージの目的地は、変更された目的地に送られる。また、必要な場合には、イベント解析部１４０から送られた情報に応じてメッセージそれ自体が変換される。
【００６０】
もちろん、ユーザによる、サービスのある機能に対する要求は、メッセージ中に表現される。イベント解析部１４０では、マッピングテーブル１３０に記述されている内容を基盤として、３つのケースを処理する。
サブタイプに代替された場合には、単純に、伝送されたイベントの目的地のみを変える。
スーパータイプに代替された場合には、スーパータイプと本来のサービスで同時に支援する機能に対しては、単純に目的地のみを変える。一方、既存サービスの追加的な機能を要求するときには、その機能が実行される前の状態と、実行された後の状態とを同様に維持するために、すなわち、サービスのpre-conditionとサービスのpost-conditionを維持するために、マッピングテーブル１３０に記述された通りに、スーパータイプの機能の組み合わせを順次処理する。
スーパータイプに型変換された場合は、単純に、マッピングテーブル１３０に記述された通りに、スーパータイプのいずれかの機能に変更する。
【００６１】
例えば、現在の環境で「Light」サービスを利用すると仮定する。「Light」サービスは、「Smart Light」というサービスのスーパータイプであり、「turn on」と「turn off」との２つの機能を果たす。「Smart Light」サービスは、「Light」サービスを拡張して、「dimming」という機能を提供する。これは、「turn on」機能に媒介変数（dim-level）を追加して具現されたものと仮定する。このとき、ユーザが移動した環境に「Light」サービスが存在せずに、「Smart Light」サービスのみが存在する場合、「Light」サービスは、「Smart Light」サービスに代替される。また、「Light」サービスの「turn on」／「turn off」機能をユーザが要求するとき、透明に「Smart Light」サービスの「turn on」／「turn off」機能に代替される。
【００６２】
反対に、ユーザが現在の環境で「Smart Light」サービスを利用すると仮定する。この場合には、新しい環境へ移動したユーザは、その環境で単に「Light」サービスのみが利用可能であって、「Light」サービスに代替されることとなる。この代替は、その環境に「Smart Light」サービスが存在せず、「Smart Light」サービスのいかなるサブタイプも存在しないという仮定下で行われる。このとき、「Smart Light」サービスの「dimming」の機能は、「Light」サービスの機能の組み合わせでは、代替され得ない。そのため、単純に、「Light」サービスの「turn on」機能に交替されると記述されていれば（スーパータイプに型変換していれば）、ユーザが実行時に「Smart Light」サービスの「dimming」機能を要求する場合、この「dimming」機能は、「Light」サービスの「turn on」機能に透明に変換されることとなる。
【００６３】
一方、本発明に係るアプリケーションプログラムの再構成システムは、Ｊａｖａ（登録商標）を利用して具現することができる。タイプ格納部１５０は、Ｊａｖａ（登録商標）とＸＭＬ（Extensible Markup Language）を利用して具現することができる。サービスを記述するために、本発明では、ＷＳＤＬ（Web Service Description Language）にタグを追加して、ＷＳＤＬと類似の形態で記述したが、これは、ＷＳＤＬでは、単に機能的な記述のみを支援するためである。拡張したＷＳＤＬ記述が有効なＷＳＤＬ形式であるとは言えないが、ＷＳＤＬを拡張することによって得られる長所は、既存のＷＳＤＬで記述したサービスが単にいくつかの追加的なタグのみを追加することによって、容易に本発明に係る方法を利用できるということにある。このサービス記述から、サービスの相関関係と情報とを格納するサービス階層ツリーが作られる。サービス記述を解析するために、われらは、ＪＷＳＤＬ（ＷＳＤＬパーサー）を拡張したが、これは、サービスをタイプ格納部１５０に登録するとき、サービスの情報を解析するために用いられる。サービス階層ツリーにおいて、サービス間の相関関係をよく表すために、ＤＯＭ（Document Object Model）を用いるが、その理由は、これが階層関係モデルをよく表すことができ、かつ、プラットホームと、言語に中立的なインターフェースとを提供するためである。
【００６４】
図３は、本発明の一実施形態に係るアプリケーションプログラムの再構成システムで用いられる全体クラス図である。なお、タイプ格納部１５０については、図６を参照して後記する。アプリケーションフレームワーク９０でサービス適応管理部１００のRECONFIGURATION関数を呼び出すことによって、アプリケーションプログラムの再構成を要請する。このとき、アプリケーションプログラムの情報を代替方針判断部１２０では、SEARCHING SERVICE関数を利用して、各サービスの情報をタイプ格納部１５０から読み込んで、代替されるサービスが現在の環境に存在するか否かを確認する。この過程をアプリケーションプログラムのコンポーネントの数だけ繰り返す。再構成が終われば、代替されたサービスのリストをSUBSTITUTED INFO関数を利用して、サービスコンテナ１１０に格納する。
【００６５】
マッピングテーブル１３０は、代替可能なケースに応じて、２つのハッシュテーブル（hash table）で具現することができる。これらのハッシュテーブルは、それぞれサブタイプに代替された場合の情報、スーパータイプに代替された場合の情報を格納する。
サブタイプのハッシュテーブルには、既存のサービスをキーとして代替されたサービスが値として格納される。
スーパータイプのハッシュテーブルには、代替する機能の媒介変数や返還値のような追加的なデータが格納されなければならない。したがって、既存のサービスをキーとして挿入され、値としては、代替されたサービスと機能とを格納する抽象化されたクラスが格納される。
【００６６】
図４は、図１に示したイベント解析部のクラス図である。図４に示すように、イベント解析部１４０は、プロキシモデルで具現できる。２つのクラスは、SUBSTITUTABLEインターフェースのPROCESS EVENTインターフェースを具現して、ユーザは、サービスが代替されたか否かに関係なく、このインターフェースを呼び出すことのみで、透明にアプリケーションプログラムを新しい環境で駆動することができる。
【００６７】
ユーザがPROCESS EVENTインターフェースを介して、イベントをイベント解析部１４０（EVENT TRANSLATION PROXY）に伝送すれば、イベント解析部１４０は、このイベントの内容を検査して、もし、要求するサービスが代替されていない場合には、直ちに送り、代替されている場合には、デフォルト リアル サブジェクトを生成した後、そのサブジェクトにイベントの処理を渡す。このとき、デフォルト リアル サブジェクトでは、マッピングテーブル１３０に記述された通りに、イベントの内容を変更して送ることになる。この２つのクラスは、マルチスレッド方式で具現した。それは、リアルタイムで多くの要請を同時に処理するためである。すなわち、１つのスレッドが１つのユーザ要請ごとに生成されて、そのイベントの処理を担当することができる。
【００６８】
図５は、実行の際のイベント伝送過程を示すものであり、図１に示したイベント解析部のメッセージ伝送フローチャートである。図５に示すように、まず、サービスコンテナ１１０では、代替が可能であるか否かをチェックする（Ｓ３００）。すなわち、ユーザが要求したメッセージを透明化可能に伝送するために、サービスコンテナ１１０では、ユーザが要求するサービスが新しい環境で代替されたか否かを確認する。
【００６９】
続いて、代替不可能な場合、サービスコンテナ１１０は、イベントをイベント解析部１４０に伝送する（Ｓ３０５）。すなわち、サービスコンテナ１１０は、ユーザが要求するサービスが新しい環境で代替不可能な場合であると確認された場合、ユーザの要求をイベント解析部１４０に伝送する。そして、イベント解析部１４０は、スレッドを生成し、受信されたイベントを目的地に単純に伝送する（Ｓ３１０）。すなわち、イベント解析部１４０は、受信されたイベントの内容を検査して、ユーザが要求するサービスが代替不可能な場合であれば、ユーザが要求したメッセージを直ちに目的地に伝送する。
【００７０】
次に、代替可能な場合、サービスコンテナ１１０では、イベントをマッピングテーブル１３０に伝送する（Ｓ３２０）。すなわち、サービスコンテナ１１０は、ユーザが要求したサービスがどのように代替されたかの情報を確認するために、マッピングテーブル１３０にイベントを伝送する。そして、マッピングテーブル１３０では、受信されたイベントの内容を検査して、ユーザが要求するサービスが代替されたサービスをチェックする（Ｓ３２５）。次に、マッピングテーブル１３０では、代替された機能情報をイベント解析部１４０に伝送する（Ｓ３３０）。そして、イベント解析部１４０は、デフォルト リアル サブジェクト１７０を生成し、イベント解析部１４０は、デフォルト リアル サブジェクト１７０にイベントを伝送する（Ｓ３４０）。次に、デフォルト リアル サブジェクト１７０では、代替ケースをチェックし、スレッドを生成した後、ケースに応じてイベントを伝送する（Ｓ３４５）。すなわち、デフォルト リアル サブジェクト１７０では、マッピングテーブル１３０で記述された通りに、イベントの内容を変更して、イベントを目的地に伝送する。
【００７１】
図６は、図１に示したタイプ格納部のクラス図である。タイプ格納部１５０では、２つのパーサー（parser）を有する。このうちの１つは、サービス階層ツリーを解析するためのものであり、他の１つは、拡張されたＷＳＤＬ（Web Service Description Language）を解析するパーサーであり、ＪＷＳＤＬを拡張して具現できる。タイプ格納部１５０内には、サービス階層ツリーでサービスの情報を解析する時間を減らすために、サービスの名前とサービスのインデックスとをツリー内で格納するハッシュテーブルがある。これは、サービスの種類が増加するとしても、検索時間を一定に維持させるためのものである。タイプ格納部１５０から提供するＡＰＩ（Application Program Interface）を示すと、図６のクラス図の通りである。
【００７２】
図７および図８は、本発明に係るアプリケーションプログラムの再構成方法を「Smart Light」サービスに適用した場合を示す図である。図７の場合、「Smart Light」サービスを使用するユーザが、環境Ａ（Environment A）から新しい環境Ｂ（Environment B）に移動するとき、アプリケーションプログラムが再構成される過程を示すものである。図８の場合には、「Smart Light」サービスを使用するユーザが、環境Ａ（Environment A）から新しい環境Ｂ（Environment B）に移動して、アプリケーションプログラムが再構成された後、相互作用することを示すものである。
【００７３】
具体的には、図７に示すように、ユーザが環境Ｂに移動し（７０１）、移動先でアプリケーションを選択し、サービス適応管理部１００に入力する。つまり、アプリケーションの構成情報がサービスコンテナ１１０に送られる（７０２）。そして、サービスコンテナ１１０は、代替方針判断部１２０にアプリケーションの再構成を要請する（７０３）。次に、代替方針判断部１２０は、サービスディスカバリ８０に、「Smart Light」サービスの探索を指示する（７０４）。また、代替方針判断部１２０は、タイプ格納部１５０からサブタイプを探索し、「Light」サービスのオブジェクトに関する情報を抽出する（７０５）。さらに、代替方針判断部１２０は、マッピングテーブル１３０に対して、マッピング情報の生成を指示する（７０６）。次いで、マッピングテーブル１３０は、生成したマッピング情報をイベント解析部１４０に送る（７０７）。これにより、イベント解析部１４０は、「Light」サービスオブジェクトに対して、サービス提供を指示する。
【００７４】
また、図８に示すように、まず、ユーザは、環境Ａでアプリケーションを選択し（８０１）、サービス適応管理部１００に入力する（８０２）。すると、サービス適応管理部１００は、環境Ａにおいて、「Smart Light」サービスオブジェクトにサービス提供を指示する（８０３）。一方、ユーザが環境Ｂに移動する（８０４）と、ユーザは、環境Ｂでアプリケーションを選択し（８０５）、サービス適応管理部１００に入力する（８０６）。そして、サービス適応管理部１００は、マッピングテーブル１３０に格納されたマッピング情報をイベント解析部１４０に送る（８０７）。これにより、イベント解析部１４０は、「Light」サービスオブジェクトに対して、サービス提供を指示する（８０８）。
【００７５】
前記の一実施形態から分かるように、本発明に係る方法は、效率的に代替されるサービスを探索するために、単にサービスタイプ間の階層関係のみを利用する。すなわち、代替可能なサービスを探索するときに、単にサービス間の連関関係のみを考慮するということを意味する。このような方式は、従来の方式に比べて柔軟性は落ちるが、サービスに対する詳細な記述が不要で、システムを效率的にプログラミングできるという長所がある。また、本発明と、従来のｓｕｂ‐ｔｙｐｉｎｇ概念を拡張した方法とを比較する場合、その差異点には、代替可能なサービスを探索するとき、各環境でサービス有効性に基づいて、サブタイプはもちろん、スーパータイプにも代替可能だという点が挙げられる。
【００７６】
なお、本発明は、前記の実施の形態に限定されるものではなく、本発明に係る技術的思想から逸脱しない範囲内で様々な変更が可能であり、それらも本発明の技術的範囲に属する。
【図面の簡単な説明】
【００７７】
【図１】本発明の一実施形態に係るアプリケーションプログラムの再構成システムのブロック図である。
【図２】本発明の一実施形態に係るアプリケーションプログラムの再構成システムにおけるアプリケーションプログラムの再構成過程を説明するためのメッセージ伝送フローチャートである。
【図３】本発明の一実施形態に係るアプリケーションプログラムの再構成システムで用いられる全体クラス図である。
【図４】図１に示したイベント解析部のクラス図である。
【図５】図１に示したイベント解析部のメッセージ伝送フローチャートである。
【図６】図１に示したタイプ格納部のクラス図である。
【図７】本発明に係るアプリケーションプログラムの再構成方法を「Smart Light」サービスに適用した場合の一例を示す図である。
【図８】本発明に係るアプリケーションプログラムの再構成方法を「Smart Light」サービスに適用した場合の他の一例を示す図である。
【符号の説明】
【００７８】
８０    サービスディスカバリ
９０    アプリケーションフレームワーク
１００  サービス適応管理部
１１０  サービスコンテナ
１２０  代替方針判断部
１２２  探索部
１３０  マッピングテーブル
１４０  イベント解析部
１５０  タイプ格納部
【図１】
2006228221.tif 000004
【図２】
2006228221.tif 000005
【図３】
2006228221.tif 000006
【図４】
2006228221.tif 000007
【図５】
2006228221.tif 000008
【図６】
2006228221.tif 000009
【図７】
2006228221.tif 000010
【図８】
2006228221.tif 000011