(57)【要約】      （修正有）【課題】ユーザが共通プラットフォームを使用して、異種技術の様々なアプリケーションとインターフェースする組込みサービス指向ユーザインターフェース統合バスを提供する。【解決手段】第１プラットフォームに関連するアプリケーションモジュール１１２からユーザインターフェースサービス要求を受信するためのコンピュータ実行可能命令を実行するように適合させることができる。また、アプリケーションモジュール１１２からのユーザインターフェースサービス要求をホストプラットフォーム用のユーザインターフェースサービス要求に変換する様に適合することができ、変換後ユーザインターフェースサービス要求をホストプラットフォーム上のプラットフォームサービス１１０と突き合わせ、ホストプラットフォーム用のプラットフォームサービス１１０をクライアント用のプラットフォームサービスに変換する様に適合することもできる。【選択図】図４
2011081789.tif 000002
【特許請求の範囲】
【請求項１】
データおよびコンピュータ実行可能命令を格納する少なくとも１つのメモリと、
少なくとも１つのコンピュータインターフェースと、
前記少なくとも１つのコンピュータインターフェースと通信し、前記少なくとも１つのメモリにアクセスするように構成された少なくとも１つのプロセッサであって、
第１プラットフォームと関連付けられる少なくとも１つのアプリケーションモジュール（１１２）から１つまたは複数のユーザインターフェースサービス要求を受信すること（５０５）、
前記少なくとも１つのアプリケーションモジュール（１１２）からの前記１つまたは複数のユーザインターフェースサービス要求をホストプラットフォーム用の１つまたは複数のユーザインターフェースサービス要求に変換すること（５１０）、
前記少なくとも１つのアプリケーションモジュール（１１２）からの１つまたは複数の変換後ユーザインターフェースサービス要求を前記ホストプラットフォーム用の１つまたは複数のプラットフォームサービス（１１０）と突き合わせること（５１５）、および
前記ホストプラットフォーム用の１つまたは複数のプラットフォームサービス（１１０）をクライアント用の１つまたは複数のプラットフォームサービス（４１５、４２０）に変換し、前記クライアントの既存のユーザインターフェースを介して前記少なくとも１つのアプリケーションモジュールにユーザインターフェースを提供すること（５２０）
を行うように前記コンピュータ実行可能命令を実行するようにさらに構成されたプロセッサと
を備えるシステム（４００）。
【請求項２】
前記第１プラットフォームおよび前記ホストプラットフォームが、共通アプリケーションフレームワークと共に動作するように適合される請求項１記載のシステム（４００）。
【請求項３】
前記第１プラットフォームが、Ｊａｖａ（登録商標）アプリケーションフレームワークと共に動作するように適合されたプラットフォームと関連付けられる請求項１記載のシステム（４００）。
【請求項４】
前記第１プラットフォームが、Ｍｉｃｒｏｓｏｆｔ．ＮＥＴ（登録商標）アプリケーションフレームワークと共に動作するように適合されたプラットフォームと関連付けられる請求項１記載のシステム（４００）。
【請求項５】
前記第１プラットフォームが、ウェブベースのアプリケーションフレームワークと共に動作するように適合されたプラットフォームと関連付けられる請求項１記載のシステム（４００）。
【請求項６】
少なくとも１つのアプリケーションモジュールが宣言型アプリケーションモジュール（１１２）を備え、前記少なくとも１つのプロセッサが、
前記宣言型アプリケーションモジュール（１１２）から１つまたは複数のユーザインターフェースサービス要求を受信し（５０５）、
前記宣言型アプリケーションモジュール（１１２）からの前記１つまたは複数のユーザインターフェースサービス要求を前記ホストプラットフォーム用の１つまたは複数のユーザインターフェースサービス要求に変換し（５１０）、
前記宣言型アプリケーションモジュール（１１２）からの１つまたは複数の変換後ユーザインターフェースサービス要求を前記ホストプラットフォーム用の前記１つまたは複数のプラットフォームサービスと突き合わせ（５１５）、
前記ホストプラットフォームに関する１つまたは複数のプラットフォームサービスをクライアント用の１つまたは複数のプラットフォームサービスに変換し、前記クライアントの既存のユーザインターフェースを介して前記宣言型アプリケーションモジュールにユーザインターフェースを提供する（５２０）
ようにコンピュータ実行可能命令を実行するように構成される請求項１記載のシステム（４００）。
【請求項７】
前記宣言型アプリケーションモジュール（１１２）が、前記ウェブサービス記述言語で前記１つまたは複数のユーザインターフェースサービス要求を定義するように構成される請求項６記載のシステム（４００）。
【請求項８】
前記ユーザインターフェースがグラフィカルユーザインターフェースである請求項１記載のシステム（４００）。
【請求項９】
前記第１プラットフォームに関連する前記少なくとも１つのアプリケーションモジュール（１１２）が、Ｊａｖａ（登録商標）アプリケーションフレームワーク、Ｍｉｃｒｏｓｏｆｔ．ＮＥＴ（登録商標）アプリケーションフレームワーク、およびウェブベースのアプリケーションフレームワークのうちの少なくとも１つに関連付けられる請求項１記載のシステム（４００）。
【請求項１０】
クライアント（４０５）内の組込み可能サービス指向ユーザインターフェース統合バスを提供するコンピュータ可読媒体上で実施されるコンピュータプログラムであって、
第１プラットフォームと関連付けられる少なくとも１つのアプリケーションモジュール（１１２）から１つまたは複数のユーザインターフェースサービス要求を受信すること（５０５）、
前記少なくとも１つのアプリケーションモジュール（１１２）からの前記１つまたは複数のユーザインターフェースサービス要求をホストプラットフォーム用の１つまたは複数のユーザインターフェースサービス要求に変換すること（５１０）、
前記少なくとも１つのアプリケーションモジュール（１１２）からの１つまたは複数の変換後ユーザインターフェースサービス要求を前記ホストプラットフォーム用の１つまたは複数のプラットフォームサービス（１１０）と突き合わせること（５１５）、および
前記ホストプラットフォーム用の１つまたは複数のプラットフォームサービスをクライアント用の１つまたは複数のプラットフォームサービス（４１５、４２０）に変換し、前記クライアントの既存のユーザインターフェースを介して前記少なくとも１つのアプリケーションモジュール（１１２）にユーザインターフェースを提供すること（５２０）
を行うための命令を含むコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般にはユーザインターフェースに関し、より詳細には、組込みサービス指向ユーザインターフェース統合バスを提供するシステムおよび方法に関する。
【背景技術】
【０００２】
従来型ユーザインターフェース（「ＵＩ」）統合技術は、ユーザが１つまたは複数のコンピュータアプリケーションと共同作業および対話することを可能にする。従来型ＵＩ統合技術の例は、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）と共に使用されるＡｃｔｉｖｅＸ（商標）、Ｅｃｌｉｐｓｅ（商標）アプリケーションフレームワークなどのプラットフォームと共に使用されるＯｐｅｎ  Ｓｅｒｖｉｃｅｓ  Ｇａｔｅｗａｙ  Ｉｎｉｔｉａｔｉｖｅ（「ＯＳＧｉ」）（登録商標）を含む。こうした従来型ＵＩ統合技術は、ユーザが特定の構成要素とインターフェースすることを可能にするという所期の目的を果たすが、こうした従来型ＵＩ統合技術は技術依存である。例えば、ＯＳＧｉ（登録商標）は言語依存であり、Ｊａｖａ（登録商標）コードで書かれる。一方、ＡｃｔｉｖｅＸ（商標）は、Ｍｉｃｒｏｓｏｆｔ（登録商標）ベースのプラットフォームに限定される。したがって、従来型ＵＩ統合技術は技術中立ではないので、従来型ＵＩ統合技術は相互運用性が限定され、技術間で移転できるようになるまでにかなりの再設計を必要とすることがある。
【０００３】
さらに、従来型ＵＩ統合技術は、アプリケーション統合ではなく、構成要素統合を対象としている。効率を向上させるために異種システムを統合する計画が浮上するにつれて、ユーザが共通プラットフォームを使用してこうしたシステムのアプリケーションとインターフェースすることが可能となるように、従来型ＵＩ統合技術が再設計されなければならなくなりつつある。そのような計画の一例がＳｍａｒｔ  Ｇｒｉｄである。Ｓｍａｒｔ  Ｇｒｉｄは、共通プラットフォームを介してリアルタイム監視し、制御するために、新しい１組のアプリケーションをレガシーパワーグリッドシステムと統合することを目指している。よりローカルなレベルでの複数の意思決定者の代わりに共通プラットフォームがエネルギー割振り決定を行うことを可能にすることにより、Ｓｍａｒｔ  Ｇｒｉｄは、ユーティリティパワーグリッドに関連する効率を向上させることを目指している。しかし、こうした効率の向上により、共通プラットフォームのユーザが、レガシーシステムによって提供される様々なアプリケーションと対話することが必要となり、したがって共通プラットフォームを介して異種アプリケーションを統合することが必要となる。従来型ＵＩ統合技術は、アプリケーション統合に適合されず、したがって、共通プラットフォームのユーザによる対話が可能ではない。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
したがって、ユーザが、技術的に中立的な方式で、共通プラットフォームを使用して異種技術の様々なアプリケーションとインターフェースすることを可能にすることが求められている。より具体的には、組込みサービス指向ユーザインターフェース統合バスを提供するシステムおよび方法が求められている。
【課題を解決するための手段】
【０００５】
本発明の実施形態は、上述の必要性の一部またはすべてに対処することができる。本発明のある実施形態は一般に、組込みサービス指向ユーザインターフェース統合バスを提供するシステムおよび方法を対象とする。一実施形態によれば、クライアント内の組込みサービス指向ユーザインターフェース統合バスを提供する方法を提供することができる。この方法は、アプリケーションモジュールからユーザインターフェースサービス要求を受信することを含むことができる。この方法はまた、アプリケーションモジュールからのユーザインターフェースサービス要求をホストプラットフォーム用のユーザインターフェースサービス要求に変換することをも含むことができる。この方法は、変換後ユーザインターフェースサービス要求をホストプラットフォーム用の１つまたは複数のプラットフォームサービスと突き合わせることをさらに含むことができる。この方法はまた、ホストプラットフォーム用の１つまたは複数のプラットフォームサービスをクライアント用の１つまたは複数のプラットフォームサービスに変換し、アプリケーションモジュールとのユーザインターフェースをクライアント上のユーザに提供することをも含むことができる。
【０００６】
別の実施形態によれば、組込みサービス指向ユーザインターフェース統合バスを提供するシステムを提供することができる。このシステムは、コンピュータ実行可能命令を格納するメモリと、コンピュータインターフェースを介してメモリと通信するプロセッサとを含むことができる。プロセッサは、第１プラットフォームに関連するアプリケーションモジュールからユーザインターフェースサービス要求を受信するためのコンピュータ実行可能命令を実行するように適合させることができる。プロセッサはまた、アプリケーションモジュールからのユーザインターフェースサービス要求をホストプラットフォーム用のユーザインターフェースサービス要求に変換するように適合させることもできる。プロセッサはまた、変換後ユーザインターフェースサービス要求をホストプラットフォーム上のプラットフォームサービスと突き合わせ、ホストプラットフォーム用のプラットフォームサービスをクライアント用のプラットフォームサービスに変換し、アプリケーションモジュールとのインターフェースをクライアント上のユーザに提供するように適合させることもできる。
【０００７】
本発明のさらに別の実施形態によれば、クライアント内の組込みサービス指向ユーザインターフェース統合バスを提供するコンピュータ可読媒体上で実施されるコンピュータプログラムを提供することができる。コンピュータプログラムは、アプリケーションモジュールからユーザインターフェースサービス要求を受信するようにプロセッサを適合させる命令を含むことができる。コンピュータプログラムはまた、アプリケーションモジュールからのユーザインターフェースサービス要求をホストプラットフォーム用のユーザインターフェースサービス要求に変換するようにプロセッサを適合させる命令をも含むことができる。コンピュータプログラムは、変換後ユーザインターフェースサービス要求をホストプラットフォーム用の１つまたは複数のプラットフォームサービスと突き合わせるようにプロセッサを適合させる命令をさらに含むことができる。コンピュータプログラムは、ホストプラットフォーム用の１つまたは複数のプラットフォームサービスをクライアント用の１つまたは複数のプラットフォームサービスに変換し、アプリケーションモジュールとのユーザインターフェースをクライアント上のユーザに提供するようにプロセッサを適合させる命令をさらに含むことができる。
【０００８】
以下の図面と共に行われる以下の説明から、本発明の他の実施形態および態様が明らかとなるであろう。
【０００９】
このように本発明を一般的な用語で説明したので、次に、必ずしも原寸に比例しない添付の図面への参照を行う。
【図面の簡単な説明】
【００１０】
【図１】本発明の一実施形態によるサービス指向ユーザインターフェース統合バスを提供する例示的システムを示す図である。
【図２】本発明の一実施形態によるサービス指向ユーザインターフェース統合バスの一部としての例示的アプリケーションモジュールを示す図である。
【図３】本発明の一実施形態によるサービス指向ユーザインターフェース統合バスを提供する例示的システムおよび方法を示す図である。
【図４】本発明の一実施形態による組込みサービス指向ユーザインターフェース統合バスを提供する例示的システムを示す図である。
【図５】本発明の一実施形態によるサービス指向ユーザインターフェース統合バスを提供する例示的方法を示す図である。
【発明を実施するための形態】
【００１１】
これから、本発明の例示的実施形態が示される添付の図面を参照しながら、本発明をより完全に説明する。しかし、本発明は、多数の異なる形態で実施することができ、本発明が本明細書に記載の例示的実施形態に限定されると解釈すべきではない。むしろ、こうした実施形態は、本開示が当業者に本発明の範囲を伝えるように与えられる。全体を通して、同様の番号は同様の要素を指す。
【００１２】
本発明のある実施形態は、異種技術のユーザインターフェース（「ＵＩ」）アプリケーションを単一のサービス指向ＵＩに統合することができる。そのように行う際に、本発明のある実施形態は、システム開発者が既存のアプリケーションを活用し、または既存または開発中の技術および／またはシステムの範囲のための新しいアプリケーションを提供するための共通プラットフォームを提供することができる。言い換えれば、本発明のある実施形態は、異種技術が異なるチームによって設計されたかどうか、または異なる目的で取得されたかどうかに関わらず、そのような技術に対する相互運用性を提供することができ、それによって単一の明確な統合実行環境からそのような技術を操作することができる。例えば、本発明のある実施形態は、ユーザが広範な異種システムをしばしば使用する配電網全体を１つの統合グラフィカルユーザインターフェースから制御および監視することを可能にするシステムを活用する、Ｓｍａｒｔ  Ｇｒｉｄのためのイネーブリング技術でよい。したがって、相互運用性は、本発明のある実施形態の少なくとも１つの技術的効果である。
【００１３】
さらに、本発明のある実施形態は、再設計を削減し、システム統合に関連する効率を向上させることができる。ある実施形態では、レガシーシステム内のアプリケーションへのアクセスを実現することができ、したがって現代の設計でレガシーアプリケーションを再実装する必要が削減される。別の実施形態では、こうしたレガシーシステムを活用することのできるより先進のＵＩアプリケーションの実装を可能にすることにより、レガシーアプリケーションの能力を拡張することができる。したがって、レガシーアプリケーションへの相互運用可能インターフェースを提供する際に、既存の機能を再実装する必要が削減される。コストの観点からは、既存のアプリケーションを新しいシステム用の新しいアプリケーションとして再実装するのではなく、既存のアプリケーションへのアクセスを可能にすることにより、本発明のある実施形態は、レガシーシステム統合に関連するコスト削減を実現することができる。したがって、低コストでのシステム統合は、本発明のある実施形態の少なくとも１つの別の技術的効果である。
【００１４】
図１は、本発明の一実施形態によるサービス指向ユーザインターフェース統合バスを提供する例示的システム１００を示す。図１にシステム１００を示し、図１に関してシステム１００を説明するが、システム１００は、例として与えるものに過ぎないということが理解されよう。他の多数のシステム動作環境、アーキテクチャ、および／または構成が可能である。したがって、本発明の実施形態が、図１に示し、図１に関して説明する特定の動作環境、アーキテクチャ、または構成に限定されると解釈すべきではない。
【００１５】
一般には、システム１００は、可視化プラットフォーム１００として説明することができる。可視化プラットフォームは、データの可視化、データの操作、およびデータとの対話のための利用環境をユーザに提供するのに使用することができる。しかし、従来技術と比べたとき、可視化プラットフォーム１００は、異種アプリケーションフレームワーク上で実装されることのある既存のレガシーＵＩアプリケーションモジュールと、ホストプラットフォームのアプリケーションフレームワーク上で実装されることがあり、または実装されないことのある新しいＵＩアプリケーションモジュールとが、ホストプラットフォーム上の１つまたは複数のＵＩ実行時環境で動作および通信することを可能にすることのできる新規な特徴を含む。例示的実施形態では、この機能は、図示される例示的高レベルアーキテクチャを介して提供することができる。
【００１６】
この高レベルアーキテクチャの一部として、サービス指向ユーザインターフェース統合バスを設けることができる。例示的実施形態では、可視化プラットフォーム１００は、モジュールマネージャ１０８とインターフェースするように適合された１つまたは複数のＵＩアプリケーションモジュールを含むことができる。一実施形態では、可視化プラットフォーム１００は、新しいアプリケーションモジュール１０２を含むことができ、新しいアプリケーションモジュール１０２は、ホストプラットフォームまたは第１プラットフォーム内で動作するように適合させることのできる１つまたは複数のＵＩアプリケーションモジュールに対応することができる。別の実施形態では、可視化プラットフォーム１００は、既存のアプリケーションモジュール１０４を含むことができ、既存のアプリケーションモジュール１０４は、第１プラットフォーム内で動作するようにやはり適合された１つまたは複数のＵＩアプリケーションモジュールに対応することができる。一実施形態では、第１プラットフォームは、ホストプラットフォームと共通アプリケーションフレームワークを共有することができる。別の実施形態では、第１プラットフォームとホストプラットフォームは、異種アプリケーションフレームワークを収容することができる。
【００１７】
例示的実施形態では、新しいアプリケーションモジュール１０２および既存のアプリケーションモジュール１０４のようなＵＩアプリケーションモジュールは、それが提供することのできるＵＩサービスと、それが消費することのできるＵＩサービスとをモジュールマネージャ１０８に対して記述することができる。ＵＩサービスは、１つまたは複数の表示をユーザに提供することができるように、ＵＩアプリケーションモジュールで使用されるサービスを記述する。一実施形態では、ＵＩアプリケーションモジュールとホストプラットフォームが共通アプリケーションフレームワークを共有するときなどに、モジュールマネージャ１０８は、１つまたは複数のＵＩアプリケーションモジュールからＵＩサービス要求を受信した後に、ホストプラットフォームから利用可能な１つまたは複数のＵＩサービスを１つまたは複数のＵＩアプリケーションモジュールと突き合わせることができる。別の実施形態では、ＵＩアプリケーションモジュールとホストプラットフォームが共通アプリケーションフレームワークを共有しないときなどに、モジュールマネージャ１０８は、ＵＩアプリケーションモジュールからのＵＩサービス要求をホストプラットフォーム用のＵＩサービス要求に変換することができる。ホストプラットフォーム用のＵＩサービス要求を決定すると、モジュールマネージャ１０８は、変換後ＵＩサービス要求をホストプラットフォームから利用可能なＵＩサービスと突き合わせることができる。
【００１８】
ＵＩ統合バスを提供する際に、モジュールマネージャ１０８は、プラットフォームサービス１１０などのホストプラットフォームから利用可能なＵＩサービスで、既存のＵＩアプリケーションモジュール１０４と新しいＵＩアプリケーションモジュール１０２との間の通信を容易にすることができる。ＵＩサービスを１つまたは複数のアプリケーションモジュールと突き合わせた後に、モジュールマネージャ１０８は、プラットフォームサービス１１０とインターフェースして、ホストプラットフォーム上のユーザに視覚インターフェースを提供することができる。少なくともこのようにして、ホストプラットフォームから利用可能なＵＩサービスを、こうした異種アプリケーションモジュールによって要求されたＵＩサービスと突き合わせ、ユーザに共通インターフェースを提供することにより、可視化プラットフォーム１００をサービス指向にすることができる。
【００１９】
図２は、ネイティブ可視化プラットフォームアプリケーションモジュール１１２のような新しいアプリケーションモジュール１０２の一実施形態を表すことのできるＵＩアプリケーションモジュール２００と、ＵＩアプリケーションモジュール１１４のような既存のアプリケーションモジュール１０４の一実施形態を表すことのできるＵＩアプリケーションモジュール２５０とを示す。一実施形態では、ＵＩアプリケーションモジュール２００は宣言型でよく、または宣言型特徴を示すことができ、ＵＩアプリケーションモジュール２００が技術的に独立の特徴を含むことができることを意味する。別の実施形態では、ＵＩアプリケーションモジュール２００は技術依存でよく、１つまたは複数のアプリケーションフレームワークと関連付けることができる。
【００２０】
ＵＩアプリケーションモジュール２００は、（１）拡張マークアップ言語（「ＸＭＬ」）ベースのスキーマライブラリ２０５、（２）モジュール定義ライブラリ２１０、（３）サービスモジュール２１５、および（４）プラットフォーム実装モジュール２２０という４つの構成要素を含むことができる。ＸＭＬスキーマライブラリ２０５は、ＵＩアプリケーションモジュール２００用の１つまたは複数のオブジェクトを定義することができる。モジュール定義ライブラリ２１０は、ホストプラットフォーム上のＵＩアプリケーションモジュール２００のモジュール名、モジュールバージョン情報、モジュール依存関係、および／または実装に関連する情報などのＵＩアプリケーションモジュール２００の１つまたは複数の定義特徴を含むことができる。サービスモジュール２１５は、ホストプラットフォーム上のＵＩアプリケーションモジュール２００のＸＭＬスキーマ２０５の１つまたは複数のＸＭＬオブジェクトを実装するローカルサービスを定義することができる。
【００２１】
プラットフォーム実装モジュール２２０は、ホストプラットフォームのアプリケーションフレームワークに従って、サービスモジュール２１５によって要求されたＵＩサービスを提供することができる。すなわち、例示的実施形態では、プラットフォーム実装モジュール２２０は、ホストプラットフォーム上のＵＩアプリケーションモジュール２００のローカルサービス２１５に従ってＸＭＬスキーマ２０５を実装することができる。例示のために、ＸＭＬスキーマ２０５で定義される１つまたは複数のデータオブジェクトが、ＵＩで実装される１つまたは複数のサービス２１５を要求することができる。この目的で、プラットフォーム実装モジュール２２０は、ＸＭＬスキーマ２０５で定義される１つまたは複数のデータオブジェクトについてホストプラットフォーム上でサービス２１５を実装することができる。
【００２２】
例示的実施形態では、ホストプラットフォーム上に存在するアプリケーションフレームワーク上で動作するように新しいアプリケーションモジュール１０２および２００を統合および／または設計できるが、他のプラットフォームに関して存在することのできるアプリケーションフレームワークと新しいアプリケーションモジュール１０２および２００を関連付けることもできることを理解されよう。すなわち、いくつかの実施形態では、ホストプラットフォームとは異なるアプリケーションフレームワークとプラットフォーム実装モジュール２２０を関連付けることができる。そのような実施形態では、プラットフォーム実装モジュール２２０がホストプラットフォームとは異なるアプリケーションフレームワークと関連付けられるとき、ＵＩアプリケーションモジュール２００と組み合わせて１つまたは複数のアダプタをさらに使用して、技術的中立性および／または独立性を実現することができる。以下では、既存のアプリケーションモジュール２５０に関して例示的アダプタが説明される。
【００２３】
ある実施形態では、新しいアプリケーションモジュール１０２および２００が技術的に独立の特徴を示すことができるので、こうした特徴を上述のモジュールまたはライブラリのうちの任意の１つまたは複数と関連付けることができることも理解されよう。すなわち、ＵＩアプリケーションモジュール１０２およびＵＩアプリケーションモジュール２００が宣言型でよい実施形態では、ＸＭＬスキーマ２０５、モジュール定義ライブラリ２１０、およびサービスモジュール２１５のうちの１つまたは複数が、１つまたは複数のプログラミング言語を介してなど、技術的に独立の特徴を示すことができる。例示的実施形態では、ウェブサービスを定義するのではなく、ＵＩアプリケーションモジュール１０２およびＵＩアプリケーションモジュール２００がプラットフォーム実装モジュール２２０を介してモジュールマネージャ１０８にＵＩローカルサービスを要求し、ホストプラットフォームを介して共通ＵＩを提供することができることを除いて、ＵＩアプリケーションモジュール１０２およびＵＩアプリケーションモジュール２００は、ウェブサービス記述言語（「ＷＳＤＬ」）の変形を使用してＵＩサービスを定義することができる。より具体的には、宣言型モジュールとして、サービスモジュール２１５は、ＵＩローカルサービスを表現的に要求することができ、サービスモジュール２１５が、ホストプラットフォーム上の実装とは無関係に１つまたは複数のＸＭＬオブジェクト２０５の必要なサービスを記述できることを意味する。次いで、サービス定義ライブラリ２１５に従って定義されるサービスを求める表現的呼出しを受信した後、プラットフォーム実装２２０をホストプラットフォーム上でこうしたサービスを実装することと関連付けることができる。
【００２４】
引き続き図１および図２を参照すると、既存のアプリケーションモジュール２５０は、ＵＩアプリケーションモジュール１１４のような既存のアプリケーションモジュール１０４に対応することができ、例示的実施形態のような、Ｍｉｃｒｏｓｏｆｔ．ＮＥＴ（登録商標）アプリケーションフレームワークなどの、ホストプラットフォームとは異なるアプリケーションフレームワーク上で動作するように既存のアプリケーションモジュール１０４を適合させることができる。例示的実施形態では、既存のＵＩアプリケーションモジュール２５０が、ＸＭＬスキーマ２５５、モジュール定義ライブラリ２６０、およびサービス定義ライブラリ２６５を含む、宣言型でよい１つまたは複数の構成要素を含むものとして示される。例示的実施形態は既存のアプリケーションモジュール２５０が宣言型の側面を有するものとして提示するが、より少ない宣言型の側面を有し、より多くの宣言型の側面を有し、または宣言型の側面を有さない既存のアプリケーションモジュールと本発明の別の実施形態を関連付けることができることを理解されよう。
【００２５】
宣言型モジュールに加えて、既存のアプリケーションモジュール２５０は、ホストプラットフォームとは異なるものでよいプラットフォーム上で既存のアプリケーションモジュール２５０を実装するための実装モジュールを含むことができる。例示的実施形態では、Ｍｉｃｒｏｓｏｆｔ．ＮＥＴ（登録商標）アプリケーションフレームワークで既存のアプリケーションモジュール２５０を実装するＭｉｃｒｏｓｏｆｔ．ＮＥＴ（登録商標）実装モジュール２７０として実装モジュールが提示される。Ｍｉｃｒｏｓｏｆｔ．ＮＥＴ（登録商標）実装モジュール２７０のような実装モジュールは、１つまたは複数のホストプラットフォーム用の既存のアプリケーションフレームワークに従って、サービスモジュール２６０によって要求されるＵＩサービスを提供することができる。既存のアプリケーションモジュール２５０は、単一のアプリケーションフレームワーク上で動作するように構成されるので、既存のアプリケーションモジュール２５０は技術中立ではない。言い換えれば、従来型システムでは、ユーザは、実装モジュール２７０によって提供されるアプリケーションフレームワークとは異なるアプリケーションフレームワークを有するプラットフォームからの既存のアプリケーションモジュール２５０と対話することができない。しかし、本発明のある実施形態は、図２に示される１つまたは複数のプラットフォームアダプタ２７５や、図１に示されるプラットフォームアダプタ１２６、１２８、および１３０などを介して技術的中立性を実現することができる。
【００２６】
既存のアプリケーションモジュール２５０がホストプラットフォームとは異なるアプリケーションフレームワークと関連するとき、プラットフォームアダプタ２７５は、ホストプラットフォーム上の既存のアプリケーションモジュール２５０を実装するアダプタの例示的実施形態を提示する。プラットフォームアダプタ２７５は、モジュールマネージャ１０８を介して、既存のアプリケーションモジュール２５０の実装モジュール２７０と、ホストプラットフォーム上で実装されるアプリケーションフレームワークとのブリッジを提供する。
【００２７】
例えば、プラットフォームアダプタ１２６および１２８は、モジュールマネージャ１０８が、例示的実施形態で示されるようにＭｉｃｒｏｓｏｆｔ．ＮＥＴ（登録商標）アプリケーションフレームワークやＪａｖａ（登録商標）アプリケーションフレームワークなどの複数のアプリケーションフレームワークに関連する言語で書かれたアプリケーションモジュールをホストすることを可能にすることができる。ウェブアプリケーションアダプタ１３０のようなアダプタは、モジュールマネージャ１０８が、ブラウザアプリケーションモジュールやシッククライアントなどの追加のアプリケーションフレームワークおよび／またはプラットフォームからのアプリケーションモジュールを統合することを可能にすることができる。どちらの場合も、モジュールマネージャ１０８は、技術的中立性を提供する可視化プラットフォーム１００の一部として単一のユーザインターフェースを提供することができる。
【００２８】
可視化プラットフォーム１００を参照しながら例示するために、ブロック１０４で、１つまたは複数のプラットフォームアダプタ内に包含される既存のアプリケーションモジュールが設けられる。モジュールマネージャ１０８を介して既存のアプリケーションモジュール１０４の実装特徴をホストプラットフォームの実装特徴とブリッジすることにより、アダプタ１２６、１２８、および１３０は、既存のアプリケーションモジュール１０４に対する修正を必要とすることなく、可視化プラットフォーム１００が既存のアプリケーションモジュール１０４を活用すると共に、新しいアプリケーションモジュール１０２をも活用することを可能にすることができる。そのような活用を相互運用性の改善と関連付けることができる。例示的実施形態では、既存のアプリケーションモジュール１０４は、以下のプラットフォームアダプタのうちの任意の１つまたは複数を含むことができる。（１）可視化プラットフォーム１００と統合するようにＭｉｃｒｏｓｏｆｔ．ＮＥＴ（登録商標）アプリケーションモジュールを適合させることとプラットフォームアダプタ１２６を関連付けることができ、（２）可視化プラットフォーム１００と統合するようにＪａｖａ（登録商標）アプリケーションモジュールを適合させることとプラットフォームアダプタ１２８を関連付けることができ、（３）可視化プラットフォーム１００と統合するようにウェブベースのアプリケーションモジュールおよび／またはインターネットブラウザアプリケーションモジュールを適合させることとプラットフォームアダプタ１３０を関連付けることができる。
【００２９】
複数のプラットフォームに関連する複数のアプリケーションフレームワーク上で動作するようにこれらのアプリケーションモジュールを設計および構成することができるとしても、プラットフォームアダプタ１２６、１２８、および１３０は、既存のアプリケーション１０４の機能を修正することなく、既存のアプリケーションモジュール１０４を可視化プラットフォーム１００と統合することができる。この目的を実現するために、プラットフォームアダプタ１２６、１２８、および１３０は、モジュールマネージャ１０８を介して、既存のアプリケーションモジュール１０４によって要求されるＵＩサービスを、可視化プラットフォーム１００を介して提供される１つまたは複数のＵＩサービスとブリッジすることができる。例えば、一実施形態では、モジュールマネージャ１０８は、可視化プラットフォーム１００によって提供されるユーザインターフェース用の１つまたは複数のプラットフォームサービス１１０を、１つまたは複数のプラットフォームアダプタ１２６、１２８、および１３０を介してモジュールマネージャ１０８に提供される、１つまたは複数のアプリケーションモジュール１１４、１１６、および１１８からの１つまたは複数のＵＩサービス要求と突き合わせることができる。
【００３０】
例えば、既存のアプリケーション１１４が明確なウィンドウ操作システムを有する場合、Ｍｉｃｒｏｓｏｆｔ．ＮＥＴ（登録商標）アダプタ１２６などのアプリケーションアダプタは、既存のアプリケーションモジュール１１４からのＵＩサービス要求を、１つまたは複数のウィンドウ操作システムアプリケーションプログラミングインターフェース（「ＡＰＩ」）に対応するＵＩサービス要求に変換することができる。モジュールマネージャ１０８はまた、Ｍｉｃｒｏｓｏｆｔ．ＮＥＴ（登録商標）プラットフォームアダプタ１２６によって提供される変換後ＵＩサービス要求を、以下でより完全に説明する可視化プラットフォーム１００によって提供される１つまたは複数のホストプラットフォームサービス１１０にマッピングすることもできる。このようにして、アプリケーションモジュール１１４のコア機能を妨げることなく、既存のアプリケーション１１４を可視化プラットフォーム１００と統合することができる。
【００３１】
ホストプラットフォームから利用可能な１つまたは複数のＵＩサービスを既存のアプリケーションモジュール１０４に提供することに加えて、モジュールマネージャ１０８は、Ｊａｖａ（登録商標）アプリケーションフレームワーク用に構成することのできるアプリケーションモジュール１１６と、Ｍｉｃｒｏｓｏｆｔ．ＮＥＴ（登録商標）アプリケーションフレームワーク用に構成することのできるアプリケーションモジュール１１４との間などの、１つまたは複数の既存のアプリケーションモジュール１０４間の相互運用性を実現することができる。
【００３２】
図３を参照して例示すると、既存のアプリケーションモジュール１１６は、レガシーＪａｖａ（登録商標）アプリケーションフレームワークにＵＩサービスを要求することができる。プラットフォームアダプタ１２８は、アプリケーションモジュール１１６からのＵＩサービス要求をホストプラットフォーム用のＵＩサービス要求に変換することができ、例示的実施形態では、ホストプラットフォーム用のＵＩサービス要求がＸＭＬベースのＵＩサービス要求として示される。ＸＭＬベースのＵＩサービス要求をモジュールマネージャ１０８に提供することができる。モジュールマネージャ１０８は、ＸＭＬベースのサービス要求をホストプラットフォームの１つまたは複数のＵＩサービスと突き合わせることができ、次いで、プラットフォームアダプタ１２６を介してアプリケーションモジュール１１４内のＵＩサービス要求を起動することができる。プラットフォームアダプタ１２６は、一実施形態ではＪａｖａ（登録商標）  Ｎａｔｉｖｅ  Ｉｎｔｅｒｆａｃｅを使用することなどにより、ホストプラットフォームのＵＩサービスに対応する、モジュールマネージャ１０８からのＵＩサービス要求を、Ｍｉｃｒｏｓｏｆｔ．ＮＥＴ（登録商標）アプリケーションフレームワーク用に構成される既存のモジュール１１４用のＵＩサービス要求に変換するように構成することができる。既存のアプリケーションモジュール１０４がウェブベースのアプリケーションモジュールおよび／またはインターネットブラウザアプリケーションモジュールに対応するとき、Ｊａｖａ（登録商標）  Ｎａｔｉｖｅ  Ｉｎｔｅｒｆａｃｅは、ウェブアプリケーションモジュール１１８からのＵＩサービス要求を、モジュールマネージャ１０８を介して利用可能なＵＩサービスに変換およびマッピングするように使用することもできる。少なくともこのようにして、可視化プラットフォーム１００は、１つまたは複数の既存のアプリケーションモジュール１０４間の相互運用性を実現することができる。
【００３３】
例示的実施形態では、モジュールマネージャ１０８が、１つまたは複数のアプリケーションモジュール１０２および１０４間の相互運用性を実現すること、およびホストプラットフォーム上でアプリケーションモジュール１０２および１０４を実装することと関連付けられる。アプリケーションモジュールの実装は、新しいアプリケーションモジュール１０２の実装モジュールなどを介して直接的に行うことができ、またはプラットフォームアダプタ１２６、１２８、および１３０などを介して間接的に行うことができる。アプリケーションモジュールを直接的に実装するとき（アプリケーションモジュール１０２がホストプラットフォームのアプリケーションフレームワークに対応する実装モジュールを含むときに行うことができる）、モジュールマネージャ１０８は、アプリケーションモジュールからのＵＩサービス要求をホストプラットフォームのプラットフォームサービスモジュール１１０に渡すことができる。アプリケーションモジュールを間接的に実装するとき（既存のアプリケーションモジュール１０４がホストプラットフォームのアプリケーションフレームワークに対応しない実装モジュールを含むときに行うことができる）、モジュールマネージャ１０８は、適切なアダプタを識別し、既存のアプリケーションモジュール１０４を参照して適切なアダプタをロードする。
【００３４】
１つまたは複数の適切なプラットフォームアダプタと対話し、上述の機能を提供するために、任意の適切なプログラミング言語でモジュールマネージャ１０８を実装し、適切に構成できることを理解されよう。例えば、一実施形態では、モジュールマネージャ１０８をＪａｖａ（登録商標）で実装することができる。Ｍｉｃｒｏｓｏｆｔ．ＮＥＴ（登録商標）プラットフォーム用に構成されるものとして示される可視化プラットフォーム１００で既存のアプリケーションモジュール１１４と対話するために、Ｍｉｃｒｏｓｏｆｔ．ＮＥＴ（登録商標）アダプタ１２６を設けて、モジュールマネージャ１０８を既存のアプリケーションモジュール１１４にブリッジすることができる。一実施形態では、Ｍｉｃｒｏｓｏｆｔ．ＮＥＴ（登録商標）アダプタ１２６は、アプリケーションモジュール１１４がＪａｖａ（登録商標）符号化モジュールマネージャ１０８と対話することを可能にするＪａｖａ（登録商標）  Ｎａｔｉｖｅ  Ｉｎｔｅｒｆａｃｅベースのアダプタに対応することができる。Ｊａｖａ（登録商標）  Ｎａｔｉｖｅ  Ｉｎｔｅｒｆａｃｅベースのアダプタはまた、プラットフォームアダプタ１３０にも対応することができる。このようにして、プラットフォームアダプタ１３０は、ウェブアプリケーションモジュール１１８からのＵＩサービス要求をモジュールマネージャ１０８用のＪａｖａ（登録商標）ＡＰＩに変換することができる。
【００３５】
再び図１を参照すると、ブロック１１０で、プラットフォームサポートのための１つまたは複数のプラットフォームサービスを設けることができる。構成要素統合を対象としていた従来型ＵＩ技術とは異なり、可視化プラットフォーム１００は、ＵＩアプリケーション統合に関する問題を解決することを対象とすることのできる１組のプラットフォームサービスを含むことができる。すなわち、可視化プラットフォーム１００は、モジュールマネージャ１０８とのＵＩ統合をサポートするために１つまたは複数のサービスを提供することができる。
【００３６】
こうしたサービスは、例えば、ウィンドウマネージャ１２０によって提供されるウィンドウ操作サービスを含むことができる。ウィンドウマネージャ１２０は、上述のプラットフォームアダプタなどを介して、ホストプラットフォーム上でユーザに対して表示されるウィンドウを管理することができ、ユーザに１つまたは複数のアプリケーションモジュールの操作を修正する能力を提供することを管理することができる。ウィンドウマネージャ１２０はまた、モジュールマネージャ１０８を介して、ユーザがウィンドウオブジェクトを作成し、１つまたは複数のアプリケーションモジュール間でデータを送ることを可能にすることもできる。ウィンドウ操作サービスを提供する際に、ウィンドウマネージャ１２０は、可視化プラットフォーム１００と、ウィンドウベースの動作環境、または当技術分野で周知の他の動作環境との統合を管理することができる。
【００３７】
プラットフォームサービス１１０はまた、セッション管理モジュール１２２によって提供されるセッション管理サービスをも含むことができる。セッション管理モジュール１２２は、ホストプラットフォームのシステムリソースを管理して、上述の様々なアプリケーションモジュールからのＵＩサービス要求に対処し、ホストプラットフォームの信頼性の高い動作を実現することができる。セッション管理モジュール１２２はまた、１つまたは複数のアプリケーションモジュールが、セッション情報を共有すること、ならびにログイン、ログオフ、およびユーザメッセージに関連するようなユーザサービスを提供することをも可能にすることができる。
【００３８】
プラットフォームサービス１１０は、モジュールマネージャ１０８を介して１つまたは複数のアプリケーションモジュール間のメッセージを管理するローカルバスマネージャ１２４をさらに含むことができる。上述のサービスに関してプラットフォームサービス１１０が説明されるが、記載の特定のサービスは例示のために提示されるに過ぎず、モジュールマネージャ１０８とのＵＩ統合をサポートするための潜在的なサービスのセットを伝えることが意図されることを理解されよう。したがって、本発明の実施形態が記載の特定のプラットフォームサービス１１０に限定されると解釈すべきではない。
【００３９】
図１に関して説明した高レベルアーキテクチャは、技術的に中立な方式でＵＩサービスを提供する１つまたは複数のアダプタおよび方法を含むが、本発明の別の実施形態に従って追加のアーキテクチャを利用できることも理解されよう。例えば、記載のアダプタのうちの１つまたは複数を介してではなく、異種技術を手動で、ポイントツーポイント式に統合することができる。したがって、図１に示し、図１に関して説明した高レベルアーキテクチャに加えて、本発明の別の実施形態が存在できることを理解されよう。
【００４０】
例えば、本発明の別の実施形態を新しいホストプラットフォーム上に実装するのではなく、レガシープラットフォーム内に組み込むことができる。すなわち、ある実施形態では、可視化プラットフォーム１００をレガシーシステム内に組み込むことができ、それにより、図１のサービス指向ユーザ統合バス用に設計されたアプリケーションモジュールがレガシーシステム上で動作することを可能することができ、それによってレガシーシステムでこうしたアプリケーションモジュールを再設計および再実装することなく、レガシーシステムの機能およびユーティリティが拡張される。
【００４１】
そのような実施形態が図４のシステム４００で示されている。システム４００は、組込み可能可視化プラットフォームマイクロカーネル４０２を有するレガシーアプリケーションモジュールまたはコンピュータシステムクライアント４０５の一部でよい。マイクロカーネル４０２は、クライアント４０５内の既存のレガシーアプリケーションモジュール４１０と一緒に動作することができ、それによってレガシーアプリケーションモジュール４１０が、レガシーシステムと相互運用可能ではないホストプラットフォーム用のサービス指向ユーザ統合バスの一部として設計および実装することのできる新しいアプリケーションモジュール１０２と対話することが可能となる。言い換えれば、言語およびプラットフォーム中立構成要素を含むことを望むことのあるレガシーアプリケーションモジュール４１０およびクライアント４０５のようなレガシーシステムが、組込みマイクロカーネル４０２を使用することによってそのように行うことができる。
【００４２】
レガシーシステムまたはアプリケーションモジュールに関連する技術に応じて、いくつかのプラットフォーム機構を介してマイクロカーネル４０２をクライアント４０５に統合することができる。例えば、一実施形態では、Ｊａｖａ（登録商標）クライアントが、Ｊａｖａ（登録商標）  Ｎａｔｉｖｅ  Ｉｎｔｅｒｆａｃｅを介して、サービス指向ユーザ統合バス用のアプリケーションモジュールを組み込むことができる。別の実施形態では、Ｍｉｃｒｏｓｏｆｔ（登録商標）クライアントが、コンポーネントオブジェクトモデル（「ＣＯＭ」）やＡｃｔｉｖｅＸ（商標）のような１つまたは複数のＭｉｃｒｏｓｏｆｔ（登録商標）ベースの技術を介して、サービス指向ユーザ統合バス用のアプリケーションモジュールを組み込むことができる。
【００４３】
一実施形態では、可視化プラットフォームマイクロカーネル４０２をクライアント４０５に組み込み、１つまたは複数のアダプタ４１５および４２０を介してレガシーアプリケーションモジュール４１０とインターフェースするように適合させることができる。アダプタ４１５および４２０は、ウィンドウ操作、セッション管理、アプリケーション間通信などの、レガシーシステム用の基本サービスを提供することができる。アダプタ４１５および４２０をマイクロカーネル４０２の一部として構成し、新しいアプリケーションモジュール１０２の機能または実装を修正することなく、マイクロカーネル４０２内に含まれるネイティブ機能をアプリケーションモジュール１１２に提供することができる。一実施形態では、アダプタ４１５および４２０は、ホストプラットフォーム用の１つまたは複数のプラットフォームサービスを既存のアプリケーションモジュール４１０用の１つまたは複数のプラットフォームサービスに変換し、相互運用性を実現することができる。別の実施形態では、アダプタ４１５および４２０は、ホストプラットフォーム用の１つまたは複数のプラットフォームサービスをクライアント４０５用の１つまたは複数のプラットフォームサービスに変換することができる。
【００４４】
例えば、可視化プラットフォーム１００用のネイティブアプリケーションモジュール１１２をクライアント４０５で使用されるウィンドウ操作システム内でホストすることが可能となるように、アダプタ４１５を介してウィンドウマネージャモジュール１２０を適合させることができる。例えば、一実施形態では、組込みマイクロカーネル４０２がＪａｖａ（登録商標）クライアントであるとき、クライアント４０５はＭｉｃｒｏｓｏｆｔ．ＮＥＴ（登録商標）クライアントでよい。この状況では、アダプタ４１５をウィンドウマネージャ１２０からのＪａｖａ（登録商標）ベースのウィンドウサービス要求をクライアント４０５用のＭｉｃｒｏｓｏｆｔ．ＮＥＴ（登録商標）ウィンドウサービス要求に変換することと関連付けることができる。クライアント４０５にウィンドウ操作システムが欠けているような別の実施形態では、アダプタ４１５および／または４２０は任意選択でよい。
【００４５】
図５は、本発明の一実施形態によるサービス指向ユーザインターフェース統合バスを提供する例示的方法５００を示す。図５に示されるように、方法５００はブロック５０５で始まり、ＵＩサービス要求がアプリケーションモジュールから受信される。第１プラットフォームに関連するアプリケーションモジュールからＵＩサービス要求を受信することができる。一実施形態では、第１プラットフォームは、ホストプラットフォームと共通アプリケーションフレームワークを共有することができる。例えば、図１を参照すると、ネイティブ可視化プラットフォームアプリケーションモジュール１１２などの新しいアプリケーションモジュール１０２からＵＩサービス要求を受信することができ、新しいアプリケーションモジュール１０２は、可視化プラットフォーム１００をホストするプラットフォーム上で動作するように統合および／または設計することができる。新しいアプリケーションモジュール１０２からのＵＩサービス要求をモジュールマネージャ１０８で受信することができ、別の実施形態では、１つまたは複数のプラットフォームサービス１１０で直接受信することができる。
【００４６】
別の実施形態では、ホストプラットフォームとは異なるアプリケーションフレームワークを有する第１プラットフォームに関連するアプリケーションモジュールからＵＩサービス要求を受信することができる。例えば、一実施形態では、可視化プラットフォーム１００内のアプリケーションモジュール１１４などの、Ｍｉｃｒｏｓｏｆｔ．ＮＥＴ（登録商標）アプリケーションフレームワークと共に動作するように適合されたプラットフォームに関連するアプリケーションモジュールからＵＩサービス要求を受信することができる。別の実施形態では、可視化プラットフォーム１００内のアプリケーションモジュール１１６などのＪａｖａ（登録商標）アプリケーションフレームワークと共に動作するように適合されたプラットフォームとアプリケーションモジュールを関連付けることができる。別の実施形態では、可視化プラットフォーム１００内のアプリケーションモジュール１１８などのウェブベースのプラットフォームおよび／またはインターネットブラウザプラットフォームとアプリケーションモジュールを関連付けることができる。さらに別の実施形態では、上記の実施形態のうちの任意の１つまたは複数を使用することができる。
【００４７】
ホストプラットフォームとは異なるプラットフォームとアプリケーションモジュールを関連付けることができるので、アプリケーションモジュールは宣言型でもよく、または宣言型特徴を有することもできることを理解されよう。言い換えれば、ある実施形態では、アプリケーションモジュールの１つまたは複数の側面を何らかの特定のプラットフォームまたはアプリケーションフレームワークと関連付ける必要はなく、そのようなアプリケーションモジュールは技術的に独立の特徴を有することができることを意味する。さらに別の実施形態では、アプリケーションモジュールをホストプラットフォームのアプリケーションフレームワークと関連付けることができる。
【００４８】
方法５００はブロック５１０に進み、アプリケーションモジュールからのＵＩサービス要求をホストプラットフォーム用のＵＩサービス要求に変換することができる。例えば、可視化プラットフォーム１００を参照すると、アプリケーションモジュール１１４からのＵＩサービス要求をプラットフォームアダプタ１２６で受信することができ、可視化プラットフォーム１００をホストするプラットフォーム用のＵＩサービス要求に変換することができる。一実施形態では、アプリケーションモジュールおよびプラットフォームアダプタをプラットフォームアダプタ１２６およびアプリケーションモジュール１１４としてＭｉｃｒｏｓｏｆｔ．ＮＥＴ（登録商標）アプリケーションフレームワークと関連付けることができる。別の実施形態では、アプリケーションモジュールおよびプラットフォームアダプタを、プラットフォームアダプタ１２８およびアプリケーションモジュール１１６のようなＪａｖａ（登録商標）アプリケーションフレームワークと関連付けることができる。別の実施形態では、アプリケーションモジュールおよびプラットフォームアダプタを、プラットフォームアダプタ１３０およびアプリケーションモジュール１１８のようなウェブベースのアプリケーションフレームワークと関連付けることができる。別の実施形態では、上記の任意の組合せを使用することができ、かつ／または追加のアプリケーションフレームワークと組み合わせることができる。
【００４９】
ブロック５１５で、方法５００は続行することができ、アプリケーションモジュールからの変換後ＵＩサービス要求を１つまたは複数のプラットフォームサービスと突き合わせることができる。一実施形態では、プラットフォームサービスをホストプラットフォームと関連付けることができ、サービスの突合せにより、ホストプラットフォームを介して、グラフィカルユーザインターフェースなどの視覚インターフェースをユーザに提供することができる。例えば、可視化プラットフォーム１００を参照すると、変換後ＵＩサービス要求をモジュールマネージャ１０８で受信し、プラットフォームサービス１１０を介して利用可能な１つまたは複数のＵＩサービスに対してモジュールマネージャ１０８で突き合わせることができる。別の実施形態では、プラットフォームサービスを他のアプリケーションモジュールと関連付けることができ、サービスの突合せを、図１の可視化プラットフォーム１００の一部として示されるアプリケーションモジュール１１２、１１４、１１６、および１１８などの１つまたは複数のＵＩアプリケーションモジュール間の通信を容易にすることと関連付けることができる。別の実施形態では、上記の任意の組合せを実現することができる。
【００５０】
ホストプラットフォーム上で実装されるのではなく、レガシープラットフォーム、アプリケーションモジュール、および／またはシンクライアントもしくはシッククライアントに組み込むことのできる実施形態などのいくつかの実施形態では、方法５００はブロック５２０に進むことができ、ホストプラットフォーム用の１つまたは複数のプラットフォームサービスを、レガシープラットフォーム、アプリケーションモジュール、および／またはクライアント用の１つまたは複数のプラットフォームサービスにさらに変換することができる。例えば、図４を参照すると、ホストプラットフォーム用の１つまたは複数のプラットフォームサービスを既存のアプリケーションモジュール４１０用の１つまたは複数のプラットフォームサービスに変換して相互運用性を実現するように、アダプタ４１５および４２０を適合させることができる。別の実施形態では、アダプタ４１５および４２０は、ホストプラットフォーム用の１つまたは複数のプラットフォームサービスをクライアント４０５用の１つまたは複数のプラットフォームサービスに変換することができる。別の実施形態では、上記の任意の組合せを使用することができる。
【００５１】
本発明の実施形態が技術独立でよく、異なるタイプのＵＩアプリケーションモジュールを統合した形で実行することを可能にできることを理解されよう。例えば、シッククライアント用に実装および設計されアプリケーションモジュールが、上述のアプリケーションモジュールおよび／または構成要素のうちの１つまたは複数を使用して、同一のＵＩ環境でウェブシンクライアントとタンデムに動作することができる。したがって、システム、方法、装置、および／またはコンピュータプログラム製品のブロックおよび流れ図を参照しながら本発明を上記で説明したが、こうした参照は本発明の例示的実施形態として提供されるに過ぎない。
【００５２】
さらに、ブロック図および流れ図のブロックは、指定の機能を実施する手段の組合せ、指定の機能を実施する要素またはステップの組合せ、および指定の機能を実施するプログラム命令手段をサポートする。本発明のある実施形態によれば、ブロック図および流れ図のあるブロックは、必ずしも提示される順序で実施する必要はないことがあり、またはすべてを実施する必要がないことがある。
【００５３】
ブロック図および流れ図の各ブロック、ならびにブロック図および流れ図の中のブロックの組合せは、指定の機能または要素を実施する専用ハードウェアベースのコンピュータシステム、または専用ハードウェアとコンピュータ命令の組合せで実装できることを理解されよう。こうした実施形態はまた、ハンドヘルド装置、マルチプロセッサシステム、マイクロプロセッサベースの、またはプログラム可能なコンシューマエレクトロニクス、ミニコンピュータ、メインフレームコンピュータなどを含む他のコンピュータシステム構成でも実施することができる。
【００５４】
本発明のある実施形態は、コンピュータのオペレーティングシステム上で動作するアプリケーションプログラムを介して実装することもできる。さらに、または別法として、通信ネットワークを介してリンクされたリモート処理装置でタスクが実施される本発明のある実施形態の実施が可能となるように、アプリケーションプログラム（全部または一部）をリモートメモリまたはストレージ内に配置することができる。
【００５５】
ブロック図および流れ図の１つまたは複数のブロック、ブロック図および流れ図の中のブロックの組合せをそれぞれ、コンピュータ実行可能プログラム命令で実装できることも理解されよう。コンピュータ実行可能命令で本発明の実施形態を実装するとき、コンピュータプログラム命令を汎用コンピュータ、専用コンピュータ、または他のプログラム可能データ処理装置上にロードしてマシンを生成することができ、その結果、コンピュータまたは他のプログラマブルデータ処理装置上で実行される命令が、本明細書で論じられるブロック図の各ブロック、またはブロック図中のブロックの組合せの機能を実装する手段を生成する。こうしたコンピュータプログラム命令をコンピュータ可読メモリ内に格納することもでき、コンピュータ可読メモリは、ブロック（複数可）で指定される機能を実装することを含む、特定の方式で機能するようにコンピュータまたは他のプログラム可能データ処理装置に指令することができ、それによってコンピュータ可読メモリ内に格納された命令が製品を生成する。この製品は、流れ図ブロックまたはブロック（複数可）で指定される１つまたは複数の機能を実装する命令手段を含むことができる。
【００５６】
本明細書で説明した本発明の多数の修正形態および他の実施形態が上記の説明および関連する図面で提示した教示の恩恵を有することが明らかとなるであろう。したがって、本発明が開示された特定の実施形態に限定されるべきではないこと、および修正形態および他の実施形態が添付の特許請求の範囲内に含まれるものとすることを理解されたい。本明細書で特定の用語を使用したが、こうした用語は、限定のためではなく、一般的かつ説明的な意味で使用されるに過ぎない。
【符号の説明】
【００５７】
１００  システム
１０２  新しいアプリケーションモジュール
１０４  既存のアプリケーションモジュール
１０８  モジュールマネージャ
１１０  プラットフォームサービス
１１２  ネイティブ可視化プラットフォームアプリケーションモジュール
１１４  ．ＮＥＴ（登録商標）アプリケーションフレームワーク用の既存のアプリケーションモジュール
１１６  Ｊａｖａ（登録商標）アプリケーションフレームワーク用の既存のアプリケーションモジュール
１１８  ブラウザ型プリケーションフレームワーク用の既存のアプリケーションモジュール
１２０  ウィンドウマネージャ
１２２  セッション管理
１２４  ローカルメッセージバス
１２６  ．ＮＥＴ（登録商標）プラットフォームアダプタ
１２８  Ｊａｖａ（登録商標）プラットフォームアダプタ
１３０  ブラウザ型プラットフォームアダプタ
２００  新しいアプリケーションモジュール
２０５  ＸＭＬスキーマ
２１０  モジュール定義ライブラリ
２１５  サービスモジュール
２２０  プラットフォーム実装モジュール
２５０  既存のアプリケーションモジュール
２５５  ＸＭＬスキーマ
２６０  モジュール定義ライブラリ
２６５  サービスモジュール
２７０  ．ＮＥＴ（登録商標）プラットフォーム実装モジュール
２７５  プラットフォームアダプタ
４００  システム
４０２  組込み可能可視化プラットフォームマイクロカーネル
４０５  クライアント
４１０  レガシーアプリケーションモジュール
４１５  ウィンドウマネージャアダプタ
４２０  セッション管理アダプタ
５００  方法
５０５  ブロック
５１０  ブロック
５１５  ブロック
５２０  ブロック
【図１】
2011081789.tif 000003
【図２】
2011081789.tif 000004
【図３】
2011081789.tif 000005
【図４】
2011081789.tif 000006
【図５】
2011081789.tif 000007
【外国語明細書】
2011081789000001.pdf