(57)【要約】      （修正有）【課題】共通のプラットフォームを使用してユーザが異種技術の様々なアプリケーションとのインターフェースをとることを可能にする。【解決手段】サービス指向ユーザインターフェースサービス統合バスを提供するためのシステム１００は、第１プラットフォームに関連付けられたアプリケーションモジュール１１２，１１４，１１６，１１８からユーザインターフェースサービス要求をホストプラットフォームへのユーザインターフェースサービス要求に変換し、変換したユーザインターフェースサービス要求を、アプリケーションモジュール１１２，１１４，１１６，１１８とのビジュアルインターフェースをホストプラットフォーム上でユーザに提供するためのプラットフォームサービス１１０とマッチングさせる。【選択図】図１
2011081791.tif 000002
【特許請求の範囲】
【請求項１】
データ及びコンピュータ実行可能命令を格納するための少なくとも１つのメモリと、
少なくとも１つのコンピュータインターフェースと、
前記少なくとも１つのコンピュータインターフェースに接続しており、前記少なくとも１つのメモリにアクセスするように構成された、少なくとも１つのプロセッサと
を含むシステム（１００）であって、前記少なくとも１つのプロセッサが、前記コンピュータ実行可能命令を実行し、
第１のプラットフォームに関連付けられた少なくとも１つのアプリケーションモジュール（１１２、１１４、１１６、１１８）から１つ又は複数のユーザインターフェースサービス要求を受け取り（５０５）、
前記少なくとも１つのアプリケーションモジュールからの前記１つ又は複数のユーザインターフェースサービス要求を、ホストプラットフォームへの１つ又は複数のユーザインターフェースサービス要求に変換し（５１０）、
前記少なくとも１つのアプリケーションモジュール（１２６、１２８、１３０）からの前記１つ又は複数の変換したユーザインターフェースサービス要求を、前記少なくとも１つのアプリケーションモジュール（１１２、１１４、１１６、１１８）とのビジュアルインターフェースを前記ホストプラットフォーム上でユーザに提供するための１つ又は複数のプラットフォームサービス（１１０）とマッチングさせる（５１５）ようにさらに構成された、システム（１００）。
【請求項２】
前記第１のプラットフォームと前記ホストプラットフォームとが、共通のアプリケーションフレームワークで動作するように構成された請求項１記載のシステム（１００）。
【請求項３】
前記第１のプラットフォームが、Ｊａｖａアプリケーションフレームワークで動作するように構成されたプラットフォームに関連付けられた請求項１記載のシステム（１００）。
【請求項４】
前記第１のプラットフォームが、Ｍｉｃｒｏｓｏｆｔ．ＮＥＴアプリケーションフレームワークで動作するように構成されたプラットフォームに関連付けられた請求項１記載のシステム（１００）。
【請求項５】
前記第１のプラットフォームが、Ｗｅｂベースのアプリケーションフレームワークで動作するように構成されたプラットフォームに関連付けられた請求項１記載のシステム（１００）。
【請求項６】
少なくとも１つのアプリケーションモジュール（１１２、１１４、１１６、１１８）が宣言型アプリケーションモジュールを含み、前記少なくとも１つのプロセッサが、コンピュータ実行可能命令を実行し、
前記宣言型アプリケーションモジュールから１つ又は複数のユーザインターフェースサービス要求を受け取り（５０５）、
前記宣言型アプリケーションモジュールからの前記１つ又は複数のユーザインターフェースサービス要求を、前記ホストプラットフォームへの１つ又は複数のユーザインターフェースサービス要求に変換し（５１０）、
前記宣言型アプリケーションモジュールからの前記１つ又は複数の変換されたユーザインターフェースサービス要求を、前記宣言型アプリケーションモジュールとのビジュアルインターフェースを前記ホストプラットフォーム上でユーザに提供するための１つ又は複数のプラットフォームサービスとマッチングさせる（５１５）
ように構成された請求項１記載のシステム（１００）。
【請求項７】
前記宣言型アプリケーションモジュールが、ウェブサービス記述言語で前記１つ又は複数のユーザインターフェースサービス要求を定義するように構成された請求項６記載のシステム（１００）。
【請求項８】
前記ビジュアルインターフェースが、グラフィカルユーザインターフェースである請求項１記載のシステム（１００）。
【請求項９】
前記第１のプラットフォームに関連付けられた前記少なくとも１つのアプリケーションモジュールが、Ｊａｖａアプリケーションフレームワーク、Ｍｉｃｒｏｓｏｆｔ．ＮＥＴアプリケーションフレームワーク、Ｗｅｂベースのアプリケーションフレームワークのうちの少なくとも１つに関連付けられた請求項１記載のシステム（１００）。
【請求項１０】
サービス指向ユーザインターフェース統合バスをホストプラットフォーム上で提供するための、コンピュータ可読媒体に格納されたコンピュータプログラムであって、
第１のプラットフォームに関連付けられた少なくとも１つのアプリケーションモジュール（１１２、１１４、１１６、１１８）から１つ又は複数のユーザインターフェースサービス要求を受け取り（５０５）、
前記少なくとも１つのアプリケーションモジュール（１１２、１１４、１１６、１１８）からの前記１つ又は複数のユーザインターフェースサービス要求を、ホストプラットフォームへの１つ又は複数のユーザインターフェースサービス要求に変換し（５１０）、
前記少なくとも１つのアプリケーションモジュール（１２６、１２８、１３０）からの前記１つ又は複数の変換したユーザインターフェースサービス要求を、前記少なくとも１つのアプリケーションモジュール（１１２、１１４、１１６、１１８）とのビジュアルインターフェースを前記ホストプラットフォーム上でユーザに提供するための１つ又は複数のプラットフォームサービス（１１０）とマッチングさせる（５１５）、
命令を含むコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、ユーザインターフェースに関し、より詳細には、サービス指向ユーザインターフェース統合バスを提供するためのシステム及び方法に関する。
【背景技術】
【０００２】
従来のユーザインターフェース（ＵＩ）統合技術では、ユーザは１つ又は複数のコンピュータアプリケーションと共同し、対話することができる。従来のＵＩ統合技術の例には、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（商標）と併用するＡｃｔｉｖｅＸや、Ｅｃｌｉｐｓｅアプリケーションフレームワークのようなプラットフォームと併用する、Ｏｐｅｎ  Ｓｅｒｖｉｃｅｓ  Ｇａｔｅｗａｙ  Ｉｎｉｔｉａｔｉｖｅ（ＯＳＧｉ）がある。これら従来のＵＩ統合技術は、ユーザが特定のコンポーネントとのインターフェースをとるために役立つが、技術に左右されるものである。たとえば、ＯＳＧｉは、Ｊａｖａ（商標）コードで書かれ、言語に依存している。一方、ＡｃｔｉｖｅＸは、Ｍｉｃｒｏｓｏｆｔベースのプラットフォームに限定される。したがって、従来のＵＩ統合技術は技術的中立でないため、相互運用性が限定されており、技術間で転用することができるようになるまでに、かなりの再設計が必要とされる場合がある。
【０００３】
さらに、従来のＵＩ統合技術は、アプリケーションの統合よりも、むしろコンポーネントの統合を目的としたものである。効率を高めるために異種のシステムを統合しようとする活動が顕在化してくるにつれて、ユーザが共通のプラットフォームを使用して異種システムのアプリケーションとのインターフェースをとることができるように従来のＵＩ統合技術を再設計しなければならなくなっている。このような活動の例がスマートグリッドである。スマートグリッドは、共通プラットフォームを介してリアルタイムで監視と制御を行うために、新規のアプリケーション群とレガシー電力網システムとを統合することを目的としている。より局所的なレベルにある複数の意志決定機関に代わり、共通のプラットフォームで電力配分を決定できるようにすることにより、スマートグリッドは、公共電力網に関する効率化を目指している。しかしこのように効率化が進むことにより、ユーザは共通プラットフォームでレガシーシステムが提供する様々なアプリケーションとの対話が求められるので、共通プラットフォームを介して異種のアプリケーションを統合することが必要となる。従来のＵＩ統合技術は、アプリケーションを統合するようには構成されておらず、共通プラットフォームでのユーザによる対話を可能にするものではない。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
したがって、技術的に中立な方法により、共通のプラットフォームを使用してユーザが異種技術の様々なアプリケーションとのインターフェースをとることを可能にすることが求められている。より具体的には、サービス指向ユーザインターフェース統合バスを提供するためのシステム及び方法が求められている。
【課題を解決するための手段】
【０００５】
本発明の実施例は、上記要件の一部又は全てに対処することができる。本発明のある実施例は、概して、サービス指向ユーザインターフェース統合バスを提供するためのシステム及び方法を提供することを目的としている。一実施例によれば、ホストプラットフォーム上でサービス指向ユーザインターフェース統合バスを提供するための方法を提供することができる。この方法は、アプリケーションモジュールからユーザインターフェースサービス要求を受け取ることを含むことができる。アプリケーションモジュールは、ホストプラットフォームと共通の、又は異なる第１のプラットフォームと関連付けることができる。この方法は、アプリケーションモジュールからのユーザインターフェースサービス要求を、ホストプラットフォームへのユーザインターフェースサービス要求に変換することも含むことができる。さらに、この方法は、変換したユーザインターフェースサービス要求を、アプリケーションモジュールとのビジュアルインターフェースをユーザにホストプラットフォームを介して提供するための１つ又は複数のプラットフォームサービスとマッチングさせることを含むことができる。
【０００６】
別の実施例によれば、サービス指向ユーザインターフェース統合バスを提供するシステムを提供することができる。このシステムは、コンピュータ実行可能命令を格納するためのメモリと、メモリにコンピュータインターフェースを介して接続されたプロセッサとを含むことができる。このプロセッサは、コンピュータ実行可能命令により、第１のプラットフォームに関連付けられたアプリケーションモジュールからユーザインターフェースサービス要求を受け取るように構成することができる。このプロセッサはまた、アプリケーションモジュールからのユーザインターフェースサービス要求を、ホストプラットフォームへのユーザインターフェースサービス要求に変換するようにも構成することができる。さらにこのプロセッサは、変換したユーザインターフェースサービス要求を、アプリケーションモジュールとのビジュアルインターフェースをホストプラットフォーム上でユーザに提供するためのプラットフォームサービスとマッチングさせるようにも構成することができる。
【０００７】
本発明のさらに別の実施例によれば、ホストプラットフォーム上でサービス指向ユーザインターフェース統合バスを提供するための、コンピュータ可読媒体に格納されたコンピュータプログラムを提供することができる。このコンピュータプログラムは、アプリケーションモジュールからユーザインターフェースサービス要求を受け取るようにプロセッサを構成するための命令を含むことができる。このコンピュータプログラムはまた、アプリケーションモジュールからのユーザインターフェースサービス要求を、ホストプラットフォームへのユーザインターフェースサービス要求に変換するようにプロセッサを構成するための命令を含むこともできる。コンピュータプログラムはまた、変換したユーザインターフェースサービス要求を、アプリケーションモジュールとのビジュアルインターフェースをユーザにホストプラットフォームを介して提供する１つ又は複数のプラットフォームサービスとマッチングさせるようにプロセッサを構成する命令を含むことができる。
【０００８】
本発明の他の実施形態及び態様は、以下に示す図面を参照し以下の説明を読むことにより明らかになろう。
【０００９】
以上で本発明の概要の説明を終え、以降、添付の図面を参照するが、これらの図面は必ずしも一定の比例により描かれているものではない。
【図面の簡単な説明】
【００１０】
【図１】図１は、本発明の一実施例によるサービス指向ユーザインターフェース統合バスを提供するためのシステム例を示す図である。
【図２】図２は、本発明の一実施例によるサービス指向ユーザインターフェース統合バスの一部をなすアプリケーションモジュール例を示す図である。
【図３】図３は、本発明の一実施例によるサービス指向ユーザインターフェース統合バスを提供するためのシステム及び方法の一例を示す図である。
【図４】図４は、本発明の一実施例による埋め込まれたサービス指向ユーザインターフェース統合バスを提供するためのシステム例を示す図である。
【図５】図５は、本発明の一実施例によるサービス指向ユーザインターフェース統合バスを提供するための方法例を示す図である。
【発明を実施するための形態】
【００１１】
以下では、本発明を、その実施例を示す添付の図面を参照しながら、より詳細に説明する。しかし本発明は多くの異なる形態で実施することができるものであって、本明細書に示す実施例に限定されるものと解釈されるべきではなく、むしろ、これらの実施例は、本開示により本発明の範囲が当業者に伝わるように提供するものである。本明細書を通して、同様の要素は同様の参照番号で示される。
【００１２】
本発明のある実施例は、異種の技術によるユーザインターフェース（ＵＩ）アプリケーションを、単一のサービス指向ＵＩに統合することができる。そうすることにより、本発明のそれらの実施例は、システム開発者に、既存のアプリケーションを強化するため、又はある範囲の既存もしくは開発中の技術及び／又はシステムに新規アプリケーションを提供するための共通プラットフォームを提供することができる。すなわち、本発明のそれらの実施例は、異種の技術がそれぞれ異なる人員により設計されたものであるか、異なる目的のために調達されたものであるかにかかわらず、単一の、明確に定義され、統合された実行時環境から操作可能になるように、それら異種の技術に相互運用性を提供することができる。たとえば、本発明のある実施例は、ユーザに対して、広範囲に亘る同類でない複数のシステムが採用されることの多い配電網全体の制御、監視を、１つの統合されたグラフィカルユーザインターフェースから可能にするシステムを強化する、スマートグリッドの実現技術になりうるものである。したがって、相互運用性は、本発明のそれら実施例の少なくとも１つの技術的効果である。
【００１３】
さらに、本発明のある実施例は、再設計を低減し、システム統合に関する効率化を実現することができる。ある実施例では、レガシーシステムのアプリケーションへのアクセスが可能であり、したがって、最新設計でレガシーアプリケーションを再実装する必要性を低減することができる。他の実施例では、それらのレガシーシステムを強化することのできる、より高性能なＵＩアプリケーションの実施を可能にすることにより、レガシーアプリケーションの性能を向上させることができる。したがって、レガシーアプリケーションに相互運用可能なインターフェースを提供する際に、既存の機能を再実装する必要性が低減される。コストの点からすると、新しいシステムに対して既存のアプリケーションを新規アプリケーションとして再実装するのではなく、既存のアプリケーションへのアクセスを可能にすることにより、本発明のある実施例は、レガシーシステムの統合に伴うコスト削減を実現することができる。したがって、低いコストでのシステムの統合は、本発明のある実施例の、少なくとももう１つの技術的効果である。
【００１４】
図１は、本発明の一実施例によるサービス指向ユーザインターフェース統合バスを提供するためのシステム例１００を示している。システム１００が図１に示されているが、システム１００は一例として提供されているにすぎないことが理解されよう。多くの他のシステム運用環境、アーキテクチャ、及び／又は構成が可能である。したがって、本発明の実施例は、図１に示し、説明するいかなる特定の動作環境、アーキテクチャ、又は構成にも限定されるものと解釈されるべきではない。
【００１５】
概して、システム１００は、可視化プラットフォーム１００として説明することができる。データを可視化し、操作し、データと対話するためのデータ探索環境をユーザに提供するために、可視化プラットフォームを使用することができる。しかし従来技術と比較すると、可視化プラットフォーム１００は、異種のアプリケーションフレームワークで実施することのできる既存のレガシーＵＩアプリケーションモジュールと、ホストプラットフォームのアプリケーションフレームワークで実施することのできる場合とできない場合のある新規のＵＩアプリケーションモジュールとに対して、ホストプラットフォームの１つ又は複数のＵＩ実行時環境での実行及び接続を可能にすることができる新規の特徴を含む。本実施例において、この機能は、図示する高度なアーキテクチャ例により提供することができる。
【００１６】
この高度なアーキテクチャの一部として、サービス指向ユーザインターフェース統合バスを提供することができる。本実施例において、可視化プラットフォーム１００は、モジュールマネージャ１０８とインターフェースをとるように構成された１つ又は複数のＵＩアプリケーションモジュールを含むことができる。一実施例では、可視化プラットフォーム１００は、ホストプラットフォーム又は第１のプラットフォーム内で動作するように構成することのできる、１つ又は複数のＵＩアプリケーションモジュールに相当させることのできる新規のアプリケーションモジュール１０２を含むことができる。別の実施例では、可視化プラットフォーム１００は、これも同様に第１のプラットフォーム内で動作するように構成することのできる１つ又は複数のＵＩアプリケーションモジュールに相当させることのできる、既存のアプリケーションモジュール１０４を含むことができる。一実施例では、第１のプラットフォームはホストプラットフォームと共通のアプリケーションフレームワークを共有することができる。別の実施例では、第１のプラットフォームとホストプラットフォームは、別種のアプリケーションフレームワークを収容することができる。
【００１７】
本実施例では、新アプリケーションモジュール１０２及び既存のアプリケーションモジュール１０４のようなＵＩアプリケーションモジュールは、それらが提供することのできるＵＩサービス及びモジュールマネージャ１０８に使用することのできるＵＩサービスを記述することができる。ＵＩサービスは、１つ又は複数の表示をユーザに提供することができるように、ＵＩアプリケーションモジュールが使用するサービスを記述する。一実施例では、ＵＩアプリケーションモジュールとホストプラットフォームが共通アプリケーションフレームワークを共有する場合などに、モジュールマネージャ１０８は、１つ又は複数のＵＩアプリケーションモジュールからＵＩサービス要求を受け取った後で、ホストプラットフォームから使用可能な１つ又は複数のＵＩサービスを、１つ又は複数のＵＩアプリケーションモジュールとマッチングさせることができる。別の実施例では、ＵＩアプリケーションモジュールとホストプラットフォームが共通アプリケーションフレームワークを共有しない場合などに、モジュールマネージャ１０８は、ＵＩアプリケーションモジュールからのＵＩサービス要求を、ホストプラットフォームへのＵＩサービス要求に変換することができる。ホストプラットフォームへのＵＩサービス要求を決めると、モジュールマネージャ１０８は、変換したＵＩサービス要求を、ホストプラットフォームから使用可能なＵＩサービスとマッチングさせることができる。
【００１８】
ＵＩ統合バスを提供する際、モジュールマネージャ１０８は、既存のＵＩアプリケーションモジュール１０４と新ＵＩアプリケーションモジュール１０２の間の接続を、プラットフォームサービス１１０のような、ホストプラットフォームから使用可能なＵＩサービスにより円滑化することができる。ＵＩサービスを１つ又は複数のアプリケーションモジュールとマッチングさせると、モジュールマネージャ１０８は、ホストプラットフォーム上のユーザにビジュアルインターフェースを提供するためのプラットフォームサービス１１０とインターフェースをとることができるようになる。少なくともこの方法で、ホストプラットフォームから使用可能なＵＩサービスを、ユーザに共通インターフェースを提供するためのこれらの別種のアプリケーションモジュールにより要求されたＵＩサービスとマッチングさせることにより、可視化プラットフォーム１００はサービス指向となることができる。
【００１９】
図２に、ＵＩアプリケーションモジュール２００（ネイティブ可視化プラットフォームアプリケーションモジュール１１２のような新アプリケーションモジュール１０２の一実施例）とＵＩアプリケーションモジュール２５０（ＵＩアプリケーションモジュール１１４のような既存のアプリケーションモジュール１０４の一実施例）を示す。一実施例において、ＵＩアプリケーションモジュール２００は、宣言型であることができる、もしくは宣言型の機能を示すことができるが、これはすなわち、ＵＩアプリケーションモジュール２００が技術的に独立した機能を持つことができるということである。別の実施例では、ＵＩアプリケーションモジュール２００は、技術依存的であり、１つ又は複数のアプリケーションフレームワークに関連付けることができる。
【００２０】
ＵＩアプリケーションモジュール２００は、（１）拡張可能マークアップ言語（ＸＭＬ）ベースのスキーマライブラリ２０５、（２）モジュール定義ライブラリ２１０、（３）サービスモジュール２１５、及び（４）プラットフォーム実施モジュール２２０の４つのコンポーネントを含むことができる。ＸＭＬスキーマライブラリ２０５は、ＵＩアプリケーションモジュール２００のために１つ又は複数のオブジェクトを定義することができる。モジュール定義ライブラリ２１０は、モジュール名、モジュールバージョン情報、モジュールの従属関係、及び／又はホストプラットフォームでＵＩアプリケーションモジュール２００を実施することに伴う情報など、ＵＩアプリケーションモジュール２００の１つ又は複数の特徴を含むことができる。サービスモジュール２１５は、ホストプラットフォームでＵＩアプリケーションモジュール２００のＸＭＬスキーマ２０５の１つ又は複数のＸＭＬオブジェクトを実施するためのローカルサービスを定義することができる。
【００２１】
プラットフォーム実施モジュール２２０は、サービスモジュール２１５により要求されたＵＩサービスを、ホストプラットフォームのアプリケーションフレームワークに従い提供することができる。すなわち、本実施例では、プラットフォーム実施モジュール２２０は、ホストプラットフォームのＵＩアプリケーションモジュール２００のローカルサービス２１５に従い、ＸＭＬスキーマ２０５を実施することができる。説明上、ＸＭＬスキーマ２０５で定義された１つ又は複数のデータオブジェクトは、ＵＩで実施するために１つ又は複数のサービス２１５を必要とするものとする。この目的のために、プラットフォーム実施モジュール２２０は、ＸＭＬスキーマ２０５で定義された１つ又は複数のデータオブジェクトについて、ホストプラットフォームでサービス２１５を実施することができる。
【００２２】
本実施例では、既存のホストプラットフォーム上に存在するアプリケーションフレームワークで動作するよう新アプリケーションモジュール１０２及び２００を統合し、かつ／又は設計することができるが、新アプリケーションモジュール１０２及び２００は、他のプラットフォームのためのアプリケーションフレームワークと関連付けることもできることが理解されよう。すなわち、実施例によっては、プラットフォーム実施モジュール２２０は、ホストプラットフォームと異なるアプリケーションフレームワークに関連付けることができる。そのような実施例では、プラットフォーム実施モジュール２２０がホストプラットフォームと異なるアプリケーションフレームワークに関連付けられる場合、技術的中立性及び／又は独立性を得るために、さらに１つ又は複数のアダプタをＵＩアプリケーションモジュール２００と組み合わせて採用してもよい。アダプタの一例を、既存のアプリケーションモジュール２５０に関連して以下に示す。
【００２３】
実施例によっては、新アプリケーションモジュール１０２及び２００が技術的に独立した特徴を示すことができるので、それらの特徴は、上記１つ又は複数のモジュール又はライブラリと関連付けることができることも理解されよう。すなわち、ＵＩアプリケーションモジュール１０２及びＵＩアプリケーションモジュール２００が宣言型であることのできる実施例では、ＸＭＬスキーマ２０５、モジュール定義ライブラリ２１０、サービスモジュール２１５のうちの１つ又は複数が、１つ又は複数のプログラミング言語を介するなどの技術的に独立した特徴を示すことができる。本実施例では、ＵＩアプリケーションモジュール１０２及びＵＩアプリケーションモジュール２００は、様々な「ＷＳＤＬ」（Ｗｅｂ  Ｓｅｒｖｉｃｅｓ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｌａｎｇｕａｇｅ）を使用してＵＩサービスを定義することができるが、但し、ＵＩアプリケーションモジュール１０２及びＵＩアプリケーションモジュール２００は、ウェブサービスを定義するのではなく、ホストプラットフォームにより共通ＵＩを提供するために、プラットフォーム実施モジュール２２０を介してモジュールマネージャ１０８に対しＵＩローカルサービスを要求することができる。より具体的には、サービスモジュール２１５は、宣言型モジュールとしてＵＩローカルサービスを明示的に要求することができる、すなわちサービスモジュール２１５は１つ又は複数のＸＭＬオブジェクト２０５に要求されたサービスを、ホストプラットフォーム上での実施態様にかかわらず記述することができるということである。プラットフォーム実施モジュール２２０は、サービス定義ライブラリ２１５に従って定義されたサービスに対する明示的読み出しを受け取ると、ホストプラットフォーム上のそれらサービスの実施と関連付けることができる。
【００２４】
引き続き図１及び図２を参照すると、既存のアプリケーションモジュール２５０は、本実施例のＭｉｃｒｏｓｏｆｔ．ＮＥＴアプリケーションフレームワークのようなホストプラットフォームと異なるアプリケーションフレームワーク上で動作するように構成することのできるＵＩアプリケーションモジュール１１４のように、既存のアプリケーションモジュール１０４に対応付けることができる。本実施例では、既存のＵＩアプリケーションモジュール２５０は、ＸＭＬスキーマ２５５、モジュール定義ライブラリ２６０、サービス定義ライブラリ２６５など、宣言型であってよい１つ又は複数のコンポーネントを含むように示される。本実施例では既存のアプリケーションモジュール２５０を複数の宣言型の態様を有するように示しているが、本発明の他の実施例は、より少ない宣言型の態様を有する既存のアプリケーションモジュール、より多く有する既存のアプリケーションモジュール、又は全く持たない既存のアプリケーションモジュールと関連付けることができることが理解されよう。
【００２５】
宣言型モジュールに加え、既存のアプリケーションモジュール２５０は、ホストプラットフォームと異なる場合のあるプラットフォーム上で既存のアプリケーションモジュール２５０を実施するための実施モジュールを含むことができる。本実施例では、実施モジュールは、Ｍｉｃｒｏｓｏｆｔ．ＮＥＴアプリケーションフレームワークで既存のアプリケーションモジュール２５０を実施するためのＭｉｃｒｏｓｏｆｔ．ＮＥＴ実施モジュール２７０として示される。Ｍｉｃｒｏｓｏｆｔ．ＮＥＴ実施モジュール２７０のような実施モジュールは、サービスモジュール２６０により要求されたＵＩサービスを、既存のアプリケーションフレームワークに従い１つ又は複数のホストプラットフォームに提供することができる。既存のアプリケーションモジュール２５０は単一のアプリケーションフレームワーク上で動作するように構成されているので、既存のアプリケーションモジュール２５０は技術的に中立ではない。すなわち、従来のシステムでは、ユーザは、実施モジュール２７０が提供するアプリケーションフレームワークと異なるアプリケーションフレームワークを有するプラットフォームからは、既存のアプリケーションモジュール２５０と対話することができない。しかし本発明のある実施例は、図２に示す１つ又は複数のプラットフォームアダプタ２７５及び図１に示すプラットフォームアダプタ１２６、１２８、１３０のように、技術的中立性を提供することができる。
【００２６】
プラットフォームアダプタ２７５は、既存のアプリケーションモジュール２５０がホストプラットフォームと異なるアプリケーションフレームワークに関連付けられている場合に、ホストプラットフォーム上で既存のアプリケーションモジュール２５０を実施するためのアダプタの一実施例である。プラットフォームアダプタ２７５は、既存のアプリケーションモジュール２５０の実施モジュール２７０とホストプラットフォーム上で実施されるアプリケーションフレームワークとの間に、モジュールマネージャ１０８を介してブリッジを提供する。
【００２７】
たとえば、プラットフォームアダプタ１２６及び１２８は、本実施例で示すＭｉｃｒｏｓｏｆｔ．ＮＥＴやＪａｖａ（商標）などのアプリケーションフレームワークのような複数のアプリケーションフレームワークに関連付けられた言語で書かれた複数のアプリケーションモジュールを、モジュールマネージャ１０８がホストすることを可能にする。ウェブアプリケーションアダプタ１３０などのアダプタは、モジュールマネージャ１０８が、ブラウザアプリケーションモジュールやシッククライアントのような、追加アプリケーションフレームワーク及び／又はプラットフォームからの複数のアプリケーションモジュールを統合することを可能にすることができる。いずれの場合も、モジュールマネージャ１０８は、技術的に中立な可視化プラットフォーム１００の一部として単一のユーザインターフェースを提供することができる。
【００２８】
可視化プラットフォーム１００を参照して説明するために、ブロック１０４には、１つ又は複数のプラットフォームアダプタ内に含まれる複数の既存のアプリケーションモジュールが示されている。アダプタ１２６、１２８、１３０は、モジュールマネージャ１０８を介して、既存のアプリケーションモジュール１０４の実施態様の特徴をホストプラットフォームの実施特徴とブリッジすることにより、既存のアプリケーションモジュール１０４に変更を加える必要なく、可視化プラットフォーム１００が新アプリケーションモジュール１０２を強化しながら、同時に既存のアプリケーションモジュール１０４をも強化することを可能にすることができる。このような強化は、相互運用性の向上と関連付けることができる。本実施例では、既存のアプリケーションモジュール１０４は、（１）Ｍｉｃｒｏｓｏｆｔ．ＮＥＴアプリケーションモジュールを可視化プラットフォーム１００と統合するように構成することに関連付けることのできる、プラットフォームアダプタ１２６、（２）Ｊａｖａ（商標）アプリケーションモジュールを可視化プラットフォーム１００と統合するように構成することに関連付けることのできる、プラットフォームアダプタ１２８、（３）Ｗｅｂベースの、かつ／又はインターネットブラウザのアプリケーションモジュールを可視化プラットフォーム１００と統合するように構成することに関連付けることのできる、プラットフォームアダプタ１３０のいずれか１つ又は複数を含むことができる。
【００２９】
プラットフォームアダプタ１２６、１２８、１３０は、既存のアプリケーションモジュール１０４が、複数のプラットフォームに関連付けられた複数のアプリケーションフレームワーク上で実行されるよう設計され構成される可能性のある場合であっても、既存のアプリケーション１０４の機能に変更を加えずに既存のアプリケーションモジュール１０４を可視化プラットフォーム１００と統合することができる。この目的を達成するために、プラットフォームアダプタ１２６、１２８、１３０は、既存のアプリケーションモジュール１０４によって要求されたＵＩサービスを、可視化プラットフォーム１００を介して提供される１つ又は複数のＵＩサービスと、モジュールマネージャ１０８によりブリッジすることができる。たとえば、一実施例では、モジュールマネージャ１０８は、可視化プラットフォーム１００により提供されるユーザインターフェースへの１つ又は複数のプラットフォームサービス１１０を、１つ又は複数のプラットフォームアダプタ１２６、１２８、１３０によりモジュールマネージャ１０８に提供される、１つ又は複数のアプリケーションモジュール１１４、１１６、１１８からの１つ又は複数のＵＩサービス要求とマッチングさせることができる。
【００３０】
たとえば、既存のアプリケーション１１４が明確に定義付けられたウィンドウイングシステムを有する場合、Ｍｉｃｒｏｓｏｆｔ．ＮＥＴアダプタ１２６のようなアプリケーションアダプタは、既存のアプリケーションモジュール１１４からのＵＩサービス要求を、１つ又は複数のウィンドウイングシステムアプリケーションプログラミングインターフェース（ＡＰＩ）に相当するＵＩサービス要求に変換することができる。また、モジュールマネージャ１０８は、Ｍｉｃｒｏｓｏｆｔ．ＮＥＴプラットフォームアダプタ１２６により提供される変換されたＵＩサービス要求を、可視化プラットフォーム１００により提供される１つ又は複数のホストプラットフォームサービス１１０にマッピングすることができるが、これは以下で詳細に説明する。このようにして、既存のアプリケーション１１４は、アプリケーションモジュール１１４の中核機能を分散せずに、可視化プラットフォーム１００と統合することができる。
【００３１】
モジュールマネージャ１０８は、ホストプラットフォームから使用可能な１つ又は複数のＵＩサービスを既存のアプリケーションモジュール１０４に提供する他、アプリケーションモジュール１１６（Ｊａｖａ（商標）アプリケーションフレームワーク用に構成可能）とアプリケーションモジュール１１４（Ｍｉｃｒｏｓｏｆｔ．ＮＥＴアプリケーションフレームワーク用に構成可能）のような、１つ又は複数の既存のアプリケーションモジュール１０４間に相互運用性を提供することができる。
【００３２】
図３を参照して説明するために、既存のアプリケーション１１６は、レガシーＪａｖａ（商標）アプリケーションフレームワークからＵＩサービスを要求することができる。プラットフォームアダプタ１２８は、アプリケーションモジュール１１６からのＵＩサービス要求を、ホストプラットフォームへのＵＩサービス要求（本実施例ではＸＭＬベースのＵＩサービス要求として示す）に変換することができる。ＸＭＬベースのＵＩサービス要求は、モジュールマネージャ１０８に提供することができる。モジュールマネージャ１０８は、ＸＭＬベースのサービス要求を、ホストプラットフォームの１つ又は複数のＵＩサービスとマッチングさせ、次いでプラットフォームアダプタ１２６によりアプリケーションモジュール１１４内のＵＩサービス要求を呼び出すことができる。一実施例では、プラットフォームアダプタ１２６は、ホストプラットフォームのＵＩサービスに対応付けられるモジュールマネージャ１０８からのＵＩサービス要求を、Ｍｉｃｒｏｓｏｆｔ．ＮＥＴアプリケーションフレームワーク用に構成された既存のモジュール１１４へのＵＩサービス要求に、Ｊａｖａ（商標）ネイティブインターフェースを使用するなどして変換するように構成することができる。既存のアプリケーションモジュール１０４がＷｅｂベースの、かつ／又はインターネットブラウザのアプリケーションモジュールに相当する場合、Ｊａｖａ（商標）ネイティブインターフェースは、Ｗｅｂアプリケーションモジュール１１８からのＵＩサービス要求を、モジュールマネージャ１０８を介して使用可能なＵＩサービスに変換し、マッピングするために使用することもできる。少なくともこれらの方法で、可視化プラットフォーム１００は、１つ又は複数の既存のアプリケーションモジュール１０４間に相互運用性を提供することができる。
【００３３】
本実施例において、モジュールマネージャ１０８は、１つ又は複数のアプリケーションモジュール１０２及び１０４間に相互運用性を提供し、かつ、ホストプラットフォーム上のアプリケーションモジュール１０２及び１０４を実施することに関連付けられる。アプリケーションモジュールは、新アプリケーションモジュール１０２の実施モジュールを介するなど直接的に実施するか、又はプラットフォームアダプタ１２６、１２８、１３０を介するなど間接的に実施することができる。アプリケーションモジュール１０２がホストプラットフォームのアプリケーションフレームワークに相当する実施モジュールを含んでいる場合に生じうる例として、アプリケーションモジュールを直接的に実施する場合、モジュールマネージャ１０８は、アプリケーションモジュールからのＵＩサービス要求を、ホストプラットフォームのプラットフォームサービスモジュール１１０に渡すことができる。既存のアプリケーションモジュール１０４がホストプラットフォームのアプリケーションフレームワークに相当しない実施モジュールを含んでいる場合に生じうる例として、アプリケーションモジュールを間接的に実施する場合、モジュールマネージャ１０８は、既存のアプリケーションモジュール１０４を参照して適切なアダプタを識別し、ロードすることができる。
【００３４】
１つ又は複数の適切なプラットフォームアダプタと対話し、上記の機能を提供するために、モジュールマネージャ１０８は、いかなる適切なプログラミング言語でも実施し、適切に構成することができることが理解されよう。たとえば、一実施例では、モジュールマネージャ１０８をＪａｖａ（商標）で実施することができる。Ｍｉｃｒｏｓｏｆｔ．ＮＥＴプラットフォーム用に構成されているように示される可視化プラットフォーム１００における既存のアプリケーションモジュール１１４と対話するために、モジュールマネージャ１０８を既存のアプリケーションモジュール１１４にブリッジするために、Ｍｉｃｒｏｓｏｆｔ．ＮＥＴアダプタ１２６を提供することができる。一実施例では、Ｍｉｃｒｏｓｏｆｔ．ＮＥＴアダプタ１２６を、アプリケーションモジュール１１４がＪａｖａ（商標）でエンコードされたモジュールマネージャ１０８と対話できるようにするためのＪａｖａ（商標）ネイティブインターフェースベースのアダプタに対応付けることができる。Ｊａｖａ（商標）ネイティブインターフェースベースのアダプタは、プラットフォームアダプタ１３０に対応付けることもできる。この方法で、プラットフォームアダプタ１３０は、Ｗｅｂアプリケーションモジュール１１８からのＵＩサービス要求を、モジュールマネージャ１０８用のＪａｖａ（商標）  ＡＰＩに変換することができる。
【００３５】
再度、図１を参照すると、ブロック１１０には、プラットフォームサポートのための１つ又は複数のプラットフォームサービスが提供される。コンポーネントの統合を目的とした従来のＵＩ技術と異なり、可視化プラットフォーム１００は、ＵＩアプリケーションの統合にかかわる問題を解決することを目的とすることのできる一組のプラットフォームサービスを含むことができる。すなわち、可視化プラットフォーム１００は、ＵＩとモジュールマネージャ１０８との統合をサポートするために、１つ又は複数のサービスを提供することができる。
【００３６】
このサービスには、たとえばウィンドウマネージャ１２０が提供するウィンドウイングサービスが挙げられる。ウィンドウマネージャ１２０は、ホストプラットフォーム上のユーザに表示されるウィンドウを管理することができ、また、上記プラットフォームアダプタによるなどして、１つ又は複数のアプリケーションモジュールの動作を変更する機能をそのユーザに提供することができる。さらに、ウィンドウマネージャ１２０は、ユーザが、ウィンドウオブジェクトを作成し、また、モジュールマネージャ１０８により１つ又は複数のアプリケーションモジュール間でデータを方向付けることを可能にすることもできる。ウィンドイングサービスを提供する際、ウィンドウマネージャ１２０は、可視化プラットフォーム１００の統合を、ウィンドウズ（商標）ベースの動作環境で、又は当業者に周知の他の動作環境で管理することができる。
【００３７】
プラットフォームサービス１１０は、セッション管理モジュール１２２により提供されるセッション管理サービスも含むことができる。セッション管理モジュール１２２は、ホストプラットフォームの信頼できる動作を提供するために、上記の様々なアプリケーションモジュールからＵＩサービス要求を受け入れるようホストプラットフォームのシステム資源を管理することができる。また、セッション管理モジュール１２２は、１つ又は複数のアプリケーションモジュールが、セッション情報を共有し、かつログイン、ログオフ、ユーザメッセージに関連するようなユーザサービスを提供することも可能にする。
【００３８】
プラットフォームサービス１１０はさらに、モジュールマネージャ１０８により、１つ又は複数のアプリケーションモジュール間におけるメッセージを管理するためのローカルバスマネージャ１２４を含むことができる。プラットフォームサービス１１０は、上記サービスに関連して説明しているが、本明細書記載の特定のサービスは一例として提示しているにすぎず、ＵＩとモジュールマネージャ１０８との統合をサポートするための潜在的な一組のサービスを説明することを目的としていることが理解されよう。したがって、本発明の実施例は、本明細書記載の特定のプラットフォームサービス１１０に限定されるものと理解されるべきではない。
【００３９】
図１を参照して説明した高度なアーキテクチャは、技術的に中立な方法でＵＩサービスを提供するための１つ又は複数のアダプタ及び方法を含むが、本発明の他の実施例により、さらなるアーキテクチャが使用可能であることも理解されよう。たとえば、別種の技術を、本明細書記載の１つ又は複数のアダプタを使用するのではなく、手動及びポイントツーポイントの方法で統合することができる。したがって、図１に示し、説明した高度なアーキテクチャに加えて、本発明の他の実施例が可能であることが理解されよう。
【００４０】
たとえば本発明の他の実施例は、新規のホストプラットフォームで実施するのではなく、レガシープラットフォームに埋め込むことができる。すなわち、一部の実施例では可視化プラットフォーム１００をレガシーシステムに埋め込むことができるが、それは、図１のサービス指向ユーザ統合バス用に設計されたアプリケーションモジュールをレガシーシステムで動作可能にすることができ、したがって、それらアプリケーションモジュールをレガシーシステムで再設計、再実装することなく、レガシーシステムの機能及び有用性が拡張される。
【００４１】
そのような実施例を、図４のシステム４００に示す。システム４００は、レガシーアプリケーションモジュール、又は埋め込み可能な可視化プラットフォームマイクロカーネル４０２を有するコンピュータシステムクライアント４０５の一部であってよい。マイクロカーネル４０２は、クライアント４０５で既存のレガシーアプリケーションモジュール４１０と共に実行することができるが、それにより、レガシーアプリケーションモジュール４１０は、レガシーシステムと相互運用性のないホストプラットフォームへのサービス指向ユーザ統合バスの一部として設計し、実施することのできる新アプリケーションモジュール１０２と対話することが可能になる。すなわち、言語及びプラットフォームの点で中立なコンポーネントを含むことを所望する場合のあるレガシーアプリケーションモジュール４１０及びクライアント４０５のようなレガシーシステムは、埋め込まれたマイクロカーネル４０２を使用することにより、その所望を実現することができる。
【００４２】
マイクロカーネル４０２は、レガシーシステム又はアプリケーションモジュールに関連付けられた技術に依存するいくつかのプラットフォーム機構により、クライアント４０５で統合することができる。たとえば、一実施例では、Ｊａｖａ（商標）クライアントは、Ｊａｖａ（商標）ネイティブインターフェースを介して、サービス指向ユーザ統合バス用のアプリケーションモジュールを埋め込むことができる。別の実施例では、Ｍｉｃｒｏｓｏｆｔのクライアントは、「ＣＯＭ」（Ｃｏｍｐｏｎｅｎｔ  Ｏｂｊｅｃｔ  Ｍｏｄｅｌ）及びＡｃｔｉｖｅＸのような、１つ又は複数のＭｉｃｒｏｓｏｆｔベースの技術を介して、サービス指向ユーザ統合バス用のアプリケーションモジュールを埋め込むことができる。
【００４３】
一実施例では、可視化プラットフォームマイクロカーネル４０２は、クライアント４０５に埋め込むことができ、かつ、１つ又は複数のアダプタ４１５及び４２０により、レガシーアプリケーションモジュール４１０とインターフェースをとるように構成することができる。アダプタ４１５及び４２０は、ウィンドウイング、セッション管理、及びアプリケーション通信などのレガシーシステムのための基本的なサービスを提供することができる。アダプタ４１５及び４２０は、新アプリケーションモジュール１０２の機能又は実施態様を変更せずに、マイクロカーネル４０２に含まれるアプリケーションモジュール１１２にネイティブ機能を提供するために、マイクロカーネル４０２の一部を構成することができる。一実施例では、アダプタ４１５及び４２０は、相互運用性を提供するために、ホストプラットフォーム用の１つ又は複数のプラットフォームサービスを、既存のアプリケーションモジュール４１０用の１つ又は複数のプラットフォームサービスに変換することができる。別の実施例では、アダプタ４１５及び４２０は、ホストプラットフォーム用の１つ又は複数のプラットフォームサービスを、クライアント４０５用の１つ又は複数のプラットフォームサービスに変換することができる。
【００４４】
たとえば、可視化プラットフォーム１００用のネイティブアプリケーションモジュール１１２を、クライアント４０５の使用するウィンドウイングシステム内でホストすることができるように、アダプタ４１５を介してウィンドウマネージャモジュール１２０を構成することができる。たとえば、一実施例では、埋め込まれたマイクロカーネル４０２がＪａｖａ（商標）クライアントの場合に、クライアント４０５はＭｉｃｒｏｓｏｆｔ．ＮＥＴクライアントであってよい。この状況で、アダプタ４１５を、ウィンドウマネージャ１２０からのＪａｖａ（商標）ベースのウィンドウサービス要求を、クライアント４０５へのＭｉｃｒｏｓｏｆｔ．ＮＥＴウィンドウサービス要求に変換することに関連付けることができる。クライアント４０５にウィンドウイングシステムがないような別の実施例では、アダプタ４１５及び／又は４２０は任意選択とすることができる。
【００４５】
図５は、本発明の一実施例によるサービス指向ユーザインターフェース統合バスを提供するための方法例５００を示す図である。図５に示すように、方法５００は、ＵＩサービス要求をアプリケーションモジュールから受け取るブロック５０５から始まる。このＵＩサービス要求は、第１のプラットフォームに関連付けられたアプリケーションモジュールから受け取ることができる。一実施例では、第１のプラットフォームは、ホストプラットフォームと共通アプリケーションフレームワークを共有することができる。たとえば図１を参照すると、可視化プラットフォーム１００をホストするプラットフォームで動作するように統合し、かつ／又は設計することのできる、ネイティブ可視化プラットフォームアプリケーションモジュール１１２などの新アプリケーションモジュール１０２から、ＵＩサービス要求を受け取ることができる。新アプリケーションモジュール１０２からのＵＩサービス要求は、モジュールマネージャ１０８により受け取ることができるが、他の実施例では、１つ又は複数のプラットフォームサービス１１０により直接的に受け取られる。
【００４６】
別の実施例では、ホストプラットフォームと異なるアプリケーションフレームワークを有する第１のプラットフォームに関連付けられたアプリケーションモジュールから、ＵＩサービス要求を受け取ることができる。たとえば、一実施例では、可視化プラットフォーム１００のアプリケーションモジュール１１４のような、Ｍｉｃｒｏｓｏｆｔ．ＮＥＴアプリケーションフレームワークで動作するように構成されたプラットフォームと関連付けられたアプリケーションモジュールから、ＵＩサービス要求を受け取ることができる。別の実施例では、アプリケーションモジュールは、可視化プラットフォーム１００のアプリケーションモジュール１１６のような、Ｊａｖａ（商標）アプリケーションフレームワークで動作するように構成されたプラットフォームに関連付けることができる。別の実施例では、アプリケーションモジュールは、可視化プラットフォーム１００のアプリケーションモジュール１１８のような、Ｗｅｂベースの、かつ／又はインターネットブラウザのプラットフォームに関連付けることができる。さらに別の実施例では、上記実施例の１つ又は複数のどれでも使用することができる。
【００４７】
アプリケーションモジュールは、ホストプラットフォームと異なるプラットフォームに関連付けることができるので、アプリケーションモジュールは宣言型であるか、又は宣言型の特徴を有することができることが理解されよう。すなわち、一部の実施例では、アプリケーションモジュールの１つ又は複数の態様は、いかなる特定のプラットフォーム又はアプリケーションフレームワークとも関連付ける必要はないが、これはすなわち、そのようなアプリケーションモジュールが、技術的に独立した特徴を有することができることを示している。さらに別の実施例では、アプリケーションモジュールは、ホストプラットフォームのアプリケーションフレームワークと関連付けることができる。
【００４８】
方法５００はブロック５１０に進み、アプリケーションモジュールからのＵＩサービス要求は、ホストプラットフォーム用のＵＩサービス要求に変換することができる。たとえば、可視化プラットフォーム１００を参照すると、アプリケーションモジュール１１４からのＵＩサービス要求を、プラットフォームアダプタ１２６によって受け取ることができ、可視化プラットフォーム１００をホストするプラットフォーム用のＵＩサービス要求に変換することができる。一実施例では、アプリケーションモジュール及びプラットフォームアダプタを、プラットフォームアダプタ１２６及びアプリケーションモジュール１１４としてＭｉｃｒｏｓｏｆｔ．ＮＥＴアプリケーションフレームワークに関連付けることができる。別の実施例では、アプリケーションモジュール及びプラットフォームアダプタを、プラットフォームアダプタ１２８及びアプリケーションモジュール１１６のように、Ｊａｖａ（商標）アプリケーションフレームワークに関連付けることができる。別の実施例では、アプリケーションモジュール及びプラットフォームアダプタを、プラットフォームアダプタ１３０及びアプリケーションモジュール１１８のようなＷｅｂベースのアプリケーションフレームワークに関連付けることができる。他の実施例では、上記のいかなる組み合わせでも使用することができ、かつ／又は追加のアプリケーションフレームワークと組み合わせることができる。
【００４９】
ブロック５１５で、方法５００は、アプリケーションモジュールからの変換したＵＩサービス要求を、１つ又は複数のプラットフォームサービスとマッチングさせることができる。一実施例では、プラットフォームサービスをホストプラットフォームに関連付けることができ、サービスのマッチングにより、ホストプラットフォームを介して、グラフィカルユーザインターフェースのように、ユーザにビジュアルインターフェースを提供することができる。たとえば可視化プラットフォーム１００を参照すると、変換したＵＩサービス要求をモジュールマネージャ１０８により受け取ることができ、それを、プラットフォームサービス１１０を介して使用可能な１つ又は複数のＵＩサービスと、モジュールマネージャ１０８によりマッチングすることができる。他の実施例では、プラットフォームサービスを他のアプリケーションモジュールに関連付けることができ、サービスのマッチングを、図１の可視化プラットフォーム１００の一部として示されるアプリケーションモジュール１１２、１１４、１１６、１１８のような１つ又は複数のＵＩアプリケーションモジュール間の接続を円滑化することに関連付けることができる。他の実施例では、上記のいかなる組み合わせでも提供することができる。
【００５０】
ホストプラットフォームで実施するのではなく、レガシープラットフォーム、アプリケーションモジュール、及び／又はシンクライアント又はシッククライアントに埋め込むことのできるような一部の実施例では、方法５００は、ブロック５２０に進むことができ、そこでホストプラットフォーム用の１つ又は複数のプラットフォームサービスを、さらに、レガシープラットフォーム、アプリケーションモジュール、及び／又はクライアント用の１つ又は複数のプラットフォームサービスに変換することができる。たとえば図４を参照すると、アダプタ４１５及び４２０は、相互運用性を提供するために、ホストプラットフォーム用の１つ又は複数のプラットフォームサービスを、既存のアプリケーションモジュール４１０用の１つ又は複数のプラットフォームサービスに変換するように構成することができる。別の実施例では、アダプタ４１５及び４２０は、ホストプラットフォーム用の１つ又は複数のプラットフォームサービスを、クライアント４０５用の１つ又は複数のプラットフォームサービスに変換することができる。他の実施例では、上記のいかなる組み合わせでも使用することができる。
【００５１】
本発明の実施例は技術的に独立性を保つことができ、また、異種のＵＩアプリケーションモジュールを統合された方法で実行することを可能にすることが理解されよう。たとえば、シッククライアント用に実施され、設計されたアプリケーションモジュールは、上記のアプリケーションモジュール及び／又はコンポーネントの１つ又は複数を使用し、同一のＵＩ環境でＷｅｂシンクライアントと共同で動作することができる。したがって、本発明を、システム、方法、装置、及び／又はコンピュータプログラム製品の構成図及び流れ図を参照して説明したが、それらの参照事項は、本発明の一例として提供されたにすぎない。
【００５２】
さらに、構成図及び流れ図のブロックは、特定の機能を実行するための手段の組み合わせ、特定の機能を実行するための要素又はステップと、特定の機能を実行するためのプログラム命令手段との組み合わせをサポートする。本発明の一部の実施例によれば、構成図及び流れ図の一部のブロックは、必ずしも提示した順番で実行する必要はない場合があり、又は全く実行する必要がない場合がある。
【００５３】
構成図及び流れ図の各ブロック、及び構成図及び流れ図のブロックの組み合わせは、指定した機能又は要素を実行する特定用途向けハードウェアベースのコンピュータシステム、又は特定用途向けハードウェア及びコンピュータ命令の組み合わせにより実施することができることが理解されよう。これらの実施例は、ハンドヘルド機器、マイクロプロセッサシステム、マイクロプロセッサベースの、又はプログラム可能な大衆消費電子製品、ミニコンピュータ、メインフレームコンピュータなどの他のコンピュータシステム構成によって実施することもできる。
【００５４】
本発明のある実施例は、コンピュータのオペレーティングシステムで実行中のアプリケーションプログラムにより実施することもできる。さらに別法として、通信網を介してリンクされる遠隔処理装置によりタスクが実行される、本発明のある実施例の実行を可能にするために、アプリケーションプログラム（全体又は一部）を遠隔メモリ又は記憶装置に配置してもよい。
【００５５】
構成図及び流れ図の１つ又は複数のブロック、及び構成図及び流れ図のブロックの組み合わせは、それぞれコンピュータ実行可能プログラム命令により実施することができることも、理解されよう。コンピュータ実行可能命令により本発明の実施例を実施する際に、コンピュータ又は他のプログラム可能なデータ処理装置で実行される命令が、本明細書に記載の構成図の各ブロック又はそれらブロックの組み合わせの機能を実施する手段を作成するように、コンピュータプログラム命令を、汎用コンピュータ、専用コンピュータ、又は機械を製造するための他のプログラム可能データ処理装置にロードすることができる。コンピュータ可読メモリに格納した命令が製品を製造するように、これらのコンピュータプログラム命令を、コンピュータ又は他のプログラム可能なデータ処理装置に特定の方法で機能するよう命令することのできる（１つ又は複数のブロックに指定した機能を実施することを含む）コンピュータ可読メモリに格納することもできる。この製品は、流れ図の１つ又は複数のブロックで指定した１つ又は複数の機能を実施するための命令手段を含むことができる。
【００５６】
本明細書に記載の本発明の多くの変形形態及び他の実施例は、上記の説明及び添付の図面に提示した教示により、明らかになろう。したがって、本発明は、開示された特定の実施例に限定されることなく、また変形形態及び他の実施例が添付の特許請求の範囲に含まれることを理解されよう。本明細書では特定の用語を用いたが、それらは一般的な意味及び説明のために使用されたものであり、限定する目的で使用されたものではない。
【符号の説明】
【００５７】
１００  システム
１０２  新アプリケーションモジュール
１０４  既存のアプリケーションモジュール
１０８  モジュールマネージャ
１１０  プラットフォームサービス
１１２  ネイティブ可視化プラットフォームアプリケーションモジュール
１１４  ．ＮＥＴアプリケーションフレームワーク用の既存のアプリケーションモジュール
１１６  Ｊａｖａ（商標）アプリケーションフレームワーク用の既存のアプリケーションモジュール
１１８  ブラウザタイプのアプリケーションフレームワーク用の既存のアプリケーションモジュール
１２０  ウィンドウマネージャ
１２２  セッション管理
１２４  ローカルメッセージバス
１２６  ．ＮＥＴプラットフォームアダプタ
１２８  Ｊａｖａ（商標）プラットフォームアダプタ
１３０  ブラウザタイプのプラットフォームアダプタ
２００  新アプリケーションモジュール
２０５  ＸＭＬスキーマ
２１０  モジュール定義ライブラリ
２１５  サービスモジュール
２２０  プラットフォーム実施モジュール
２５０  既存のアプリケーションモジュール
２５５  ＸＭＬスキーマ
２６０  モジュール定義ライブラリ
２６５  サービスモジュール
２７０  ．ＮＥＴプラットフォーム実施モジュール
２７５  プラットフォームアダプタ
４００  システム
４０２  埋め込み可能な可視化プラットフォームマイクロカーネル
４０５  クライアント
４１０  レガシーアプリケーションモジュール
４１５  ウィンドウマネージャアダプタ
４２０  セッション管理アダプタ
５００  方法
５０５  ブロック
５１０  ブロック
５１５  ブロック
５２０  ブロック
【図１】
2011081791.tif 000003
【図２】
2011081791.tif 000004
【図３】
2011081791.tif 000005
【図４】
2011081791.tif 000006
【図５】
2011081791.tif 000007
【外国語明細書】
2011081791000001.pdf