(57)【要約】      （修正有）【課題】分離されたアプリケーションプロセスに対する動的集中制御を提供する。【解決手段】本システム３０は、マネージドコードプラットフォームの制御下にオブジェクト指向プログラムコードとして提供される少なくとも１つのアプリケーション３３と、実行アプリケーションマネージャ３１と論理的に通信するハンドラ３６と、オブジェクト指向プログラムコードとして提供される通知可能オブジェクトに対応する１つ以上のコンストラクタ４３を識別するためのローカルリスト４６と、該マネージドアプリケーションプロセス３２に変更リクエストをブロードキャストするための少なくとも１つの制御スレッドと、各識別されたコンストラクタ４３によって追跡された該通知可能オブジェクト３５にわたって繰り返され、該マネージドアプリケーションプロセス３２中に挙動変更を生成するためのリスナ３４とを備える。【選択図】図２
2005209173.tif 000002
【特許請求の範囲】
【請求項１】
マネージドアプケーションプロセス中に非同期挙動変更を誘導するためのシステムであって、
マネージドアプリケーションプロセスは、
マネージドコードプラットフォームの制御下にオブジェクト指向プログラムコードとして提供される少なくとも１つのアプリケーションと、
実行アプリケーションマネージャと論理的に通信するハンドラと、
オブジェクト指向プログラムコードとして提供される通知可能オブジェクトに対応する１つ以上のコンストラクタを識別するためのローカルリストと、
該マネージドアプリケーションプロセスに変更リクエストをブロードキャストするための少なくとも１つの制御スレッドと、
各識別されたコンストラクタによって追跡された該通知可能オブジェクトにわたって繰り返され、該マネージドアプリケーションプロセス中に挙動変更を生成するためのリスナと
を備える、システム。
【請求項２】
前記リスナを特定するための制御スレッドであって、該制御スレッドが前記変更リクエストの受信に対してスリープ状態にされる、制御スレッドをさらに備える、請求項１に記載のシステム。
【請求項３】
前記制御スレッド上に定義されたシステム中の前記アプリケーションマネージャから情報が通信される、請求項２に記載のシステム。
【請求項４】
前記ハンドラはＴＣＰソケットを備え、かつそのストリームはＴＣＰストリームを備える、請求項３に記載のシステム。
【請求項５】
前記通知可能オブジェクトに対応し、かつガービッジコレクションに対して該通知可能オブジェクトの適格性を特定する１つ以上のコンストラクタをさらに備える、請求項１に記載のシステム。
【請求項６】
少なくとも１つの前記通知可能オブジェクトを介して変更された前記少なくとも１つのアプリケーションと関連づけられた少なくとも１つのプロパティをさらに備える、請求項１に記載のシステム。
【請求項７】
前記少なくとも１つのプロパティ変更を特定するための少なくとも１つのプロパティ変更リスナをさらに備える、請求項６に記載のシステム。
【請求項８】
前記変更リクエストの受信に対して通知される前記少なくとも１つのプロパティ変更リスナをさらに備える、請求項７に記載のシステム。
【請求項９】
前記少なくとも１つの通知可能オブジェクトを介して変更される前記少なくとも１つのアプリケーションと関連付けられた少なくとも１つの見た目および感じ特性を備える、請求項６に記載のシステム。
【請求項１０】
前記少なくとも１つの見た目および感じ特性変更を特定するための少なくとも１つの登録されたトップレベルユーザインタフェースコンポーネントをさらに備える、請求項９に記載のシステム。
【請求項１１】
前記変更リクエストの受信に対して少なくとも１つの登録されたトップレベルユーザインタフェースコンポーネントをさらに備える、請求項１０に記載のシステム。
【請求項１２】
前記少なくとも１つの見た目および感じ特性変更の完了し、
前記変更リクエストの受信に対して前記少なくとも１つの登録されたトップレベルユーザインタフェースコンポーネントを待ち行列にいれて一時的に実行を遅らせる行列、および
該変更リクエストの受信に対して該少なくとも１つの登録されたトップレベルユーザインタフェースコンポーネントを直ちに実行するプロセススレッド
のうちの少なくとも１つを備える、請求項１１に記載のシステム。
【請求項１３】
前記オブジェクト指向プログラムコードは、Ｊａｖａ（登録商標）プログラミング言語で書かれる、請求項１に記載のシステム。
【請求項１４】
前記マネージドコードプラットフォームは、Ｊａｖａ（登録商標）仮想マシンである、請求項１に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に非同期挙動変更に関する。より詳細には、本発明は、非同期挙動変更をマネージドアプリケーションプロセスに誘導するためのシステムおよび方法に関する。
【背景技術】
【０００２】
マイクロプロセッサ設計および構成要素の集積化における最近の発展によって、広範囲のデバイスがますます複雑な機能および「ソフト」特徴を提供できるようになってきた。ソフト特徴は、デバイスの動作を強化およびカスタマイズするソフトウェアアプリケーションを含む。これらのデバイスは、デスクトップおよびラップトップコンピュータなどの標準の計算デバイス、情報携帯端末などの携帯計算デバイス、および携帯電話、ポケットベル、ゲーム機およびセットトップボックスなどの一般消費者向けデバイスを含む。大半のデバイスは、現在、ソフト特徴および他の拡張機能に対応するためのオペレーティングシステムを備える。
【０００３】
また、ソフトウェアのアップグレードが可能なこれらのデバイスによって提供される能力が増大されることで、ユーザはある種の期待をもつようになってきた。ユーザは、技術をよく知らず、そして遅かったりまたは一貫しないアプリケーション性能などの構造的問題によって起こされる性能の妥協に我慢できないことが多い。同様に、ユーザは、マルチタスクを介してシステムレベルで実装された別々のアプリケーションのホストにアクセスできることを一般に期待する。ユーザにとっては、広範囲に入手可能なソフトウェアアプリケーションが複数のマルチプラットホームにわたって一貫し、かつより多く利用できることで満足が得られる。しかし、ソフトウェア開発者にとっては、異なるコンピューティングプラットフォーム対する技術ソフトウェアアプリケーションは、開発コストが増大し、ならびに各対応アーキテクチャに対する常時対応およびアップグレード確約が必要となる。
【０００４】
マネージドコードプラットフォームは、マシンに依存せず、かつアーキテクチャ中立の動作環境を与えることによって、複数のプラットフォームへの対応を求めるソフトウェア開発者に１つの解決手段を提供する。マネージドコードプラットフォームは、ユーザアプリケーションとしてオペレーティングシステムによって実行されるプログラミング言語コンパイラおよびインタプリタを含む。しかし、これらは、互換アプリケーションが動作し得る仮想ランタイム環境を提供する。例えば、Ｊａｖａ（登録商標）プログラミング言語によって書かれたアプリケーションは、Ｊａｖａ（登録商標）仮想マシン（ＪＶＭ）ランタイム環境と組み合わせられる場合に、マシン別環境およびコンフィグレーション設定に依存せず異種のコンピュータシステム上で動作し得る。Ｊａｖａ（登録商標）プログラミング言語の概説は、非特許文献１に記載され、その開示は参考として援用される。ＪＶＭは、Ｊａｖａ（登録商標）動作環境に対して重要な要素であり、メモリに制約のある一般消費者デバイスを含む計算デバイスの全範囲に移植され得る。
【０００５】
マネージドコードプラットフォームは、一般に１つのアプリケーションインスタンスの単調な実行のために設計される。マネージドコードプラットフォームおよびアプリケーションインスタンスの組み合わせは、アプリケーションプロセスを形成する。したがって、複数のアプリケーションプロセスは、複数の個々のアプリケーションに対してマルチタスク挙動をシミュレートするように実行され得る。各「マルチタスクされた」アプリケーションは、異なる仮想ランタイム環境を提供する別々のマネージドコードプラットフォームの下で実行する。次いで、各マネージドコードプラットフォームは、別々のプロセス空間において下層のオペレーティングシステムの制御下に実行する。マネージドコードプラットフォーム上の制限された制御は、プロセス間通信（ＩＰＣ）などのオペレーティングシステムによって提供される機能および信号ハンドラなどの関連機構を使用して達成され得るが、同様の機能は、マネージドコードプラットフォーム下に実行する制御アプリケーションに対しては一般に利用可能でない。
【０００６】
アプリケーション制御はいくつかの理由のために利用可能でない。第１に、各アプリケーションは異なるソースから生成され得、かつ異なるアプリケーションモデル、プログラミング言語および動作仮定を使用してプログラミングされ得る。同様に、各アプリケーションは、マネージドコードプラットフォームによって提供される仮想ランタイム環境内で分離されており、かつプロセス間制御は、ランタイム環境内で動作する拡張ライブラリ機能を使用してアプリケーションに明示的にプログラムされなければならない。そのようなプログラム拡張は遅いことが多く、かつ互換性および相互運用性問題を起こす可能性がある。さらに、分離されたアプリケーションの実行は、一般に単純性、頑強性および効率性のために協調アプリケーション実行よりも好ましい。
【０００７】
それにもかかわらず、アプリケーションマネージャをしばしば使用して、ユーザリクエストに基づいてデバイス（特に一般消費者デバイス）上で実行する複数のアプリケーションプロセスに対して最低限の集中制御を提供する。しかし、その制御は、一般にアプリケーションの起動および終了に対して提供されるおおざっぱな制御に制限される。アプリケーションレベルの挙動特性に対するきめ細かな制御は、アプリケーション制御機能が利用可能でないので対応されない。例えば、アプリケーションのプロパティまたはユーザインタフェースの見た目や感じは、ランタイム環境によって動的に変更されるか、または一貫した体裁およびユーザの体験を確実にする必要があり得る。しかし、アプリケーション間制御機能がないとそのようなランタイム変更が可能でない。
【０００８】
したがって、分離されたアプリケーションプロセスに対する動的集中制御を提供するアプローチが求められる。好ましくは、そのようなアプローチは異なるアプリケーション実行を生成することなく各アプリケーションプロセスに対して非同期変更を生成し得る。さらに、そのようなアプリケーションはさらに、各アプリケーションプロセスが明示的な協調なしに進行することが可能なようにしながら挙動変更を通信するフレキシブルな機構を提供し得る。
【非特許文献１】Ｐ．ｖａｎ  ｄｅｒ  Ｌｉｎｄｅｎ、「Ｊｕｓｔ  Ｊａｖａ（登録商標）」、第１章、Ｓｕｎ  Ｍｉｃｒｏｓｙｓｔｅｍｓ社（第２版、１９９７）
【発明の開示】
【課題を解決するための手段】
【０００９】
アプリケーションマネージャおよびマネージドコードプラットフォームは、複数かつ独立の分離ユーザアプリケーションの生成をサポートするアプリケーションフレームワークにおいて実行される。マネージドコードプラットフォームは、マシン移植可能コード定義互換アプリケーションをインタープリットするための仮想マシンなどのランタイムシステムプロセスを含む。各実行アプリケーションおよびランタイムシステムプロセス対は、マネージドアプリケーションプロセスを構成する。アプリケーションマネージャは、専用制御スレッドなどのプロセス間通信（ＩＰＣ）機構を実装するリスナを介してランタイムシステムプロセスに非同期にアクセスする。このリスナのインスタンスは、各マネージドアプリケーションプロセスにアドレス空間に存在する。リスナは、「ハンドル」を介してアプリケーションマネージャによってアクセス可能である。例えば、ＴＣＰ／ＩＰは、アプリケーションマネージャとマネージドアプリケーションプロセスとの間のＩＰＣ機構として使用され得、かつハンドルは、ＴＣＰポート番号として指定される。ランタイムシステムプロセスコンテクストは、１セットの通知オブジェクトを含む。これらは、ランタイムシステムプロセスにおいて実行するアプリケーションに挙動変更をトランスペアレントに課すために使用される。適切なマネージドコードプラットフォームおよびマネージドアプリケーションプロセスの一例は、サンマイクロシステムズ（Ｐａｌｏ  Ａｌｔｏ、ＣＡ）によってライセンスされるＪａｖａ（登録商標）オペレーティング環境およびＪａｖａ（登録商標）仮想マシン（ＪＶＭ）アーキテクチャである。
【００１０】
一つの実施形態は、マネージドアプリケーションプロセスに非同期挙動変更を誘導するためのシステムおよび方法を提供する。アプリケーションマネージャが実行される。マネージドアプリケーションプロセスが実行される。マネージドコードプラットフォームの制御下にオブジェクト指向プログラムコードとして提供される少なくとも１つのアプケーションが実行される。マネージドアプリケーションプロセスは、アプリケーションマネージャプロセスと論理的に通信する。通知オブジェクトのクラスに対応する１以上のコンストラクタが識別される。各そのようなコンストラクタは、実行時に、新しく構築した対象通知オブジェクトをリストに載せる。変更リクエストは、マネージドアプリケーションプロセスにブロードキャストされる。コンストラクタによってトランスペアレントにトラッキングされた通知オブジェクトは繰り返され、マネージドアプリケーションプロセスにおける挙動変更を生成する。
【００１１】
挙動変更は、マネージドアプリケーションプロセスの一部としてランタイムシステムプロセスにおいて実行する非協調アプリケーションに対してトランスペアレントに実行される。リスナおよびトランスペアレントにトラッキング通知オブジェクトを使用して、挙動変更は、個別の実行アプリケーションの表現協調（ｅｘｐｒｅｓｓ  ｃｏｏｐｅｒａｔｉｏｎ）に独立かつそれなしにマネージドアプリケーションプロセスを実行する際にアプリケーションマネージャによって生成され得る。
【００１２】
本発明のさらに別の実施形態は、以下の詳細な説明から当業者に容易に理解される。以下においては、本発明を実施するために最も好適な実施形態を例示する。本発明はそのすべてが、本発明の意図および範囲から逸脱せずに、他の異なる実施形態が可能であり、かつその詳細は種々の自明な点において変更可能であることが理解される。したがって、図面および詳細な説明は本質的に例示とみなされ、限定を意図しない。
【００１３】
したがって、本発明は以下を提供する。
【００１４】
１．マネージドアプケーションプロセス中に非同期挙動変更を誘導するためのシステムであって、マネージドアプリケーションプロセスは、マネージドコードプラットフォームの制御下にオブジェクト指向プログラムコードとして提供される少なくとも１つのアプリケーションと、実行アプリケーションマネージャと論理的に通信するハンドラと、オブジェクト指向プログラムコードとして提供される通知可能オブジェクトに対応する１つ以上のコンストラクタを識別するためのローカルリストと、該マネージドアプリケーションプロセスに変更リクエストをブロードキャストするための少なくとも１つの制御スレッドと、各識別されたコンストラクタによって追跡された該通知可能オブジェクトにわたって繰り返され、該マネージドアプリケーションプロセス中に挙動変更を生成するためのリスナとを備える、システム。
【００１５】
２．前記リスナを特定するための制御スレッドであって、該制御スレッドが前記変更リクエストの受信に対してスリープ状態にされる、制御スレッドをさらに備える、項目１に記載のシステム。
【００１６】
３．前記制御スレッド上に定義されたシステム中の前記アプリケーションマネージャから情報が通信される、項目２に記載のシステム。
【００１７】
４．前記ハンドラはＴＣＰソケットを備え、かつそのストリームはＴＣＰストリームを備える、項目３に記載のシステム。
【００１８】
５．前記通知可能オブジェクトに対応し、かつガービッジコレクションに対して該通知可能オブジェクトの適格性を特定する１つ以上のコンストラクタをさらに備える、項目１に記載のシステム。
【００１９】
６．少なくとも１つの前記通知可能オブジェクトを介して変更された前記少なくとも１つのアプリケーションと関連づけられた少なくとも１つのプロパティをさらに備える、項目１に記載のシステム。
【００２０】
７．前記少なくとも１つのプロパティ変更を特定するための少なくとも１つのプロパティ変更リスナをさらに備える、項目６に記載のシステム。
【００２１】
８．前記変更リクエストの受信に対して通知される前記少なくとも１つのプロパティ変更リスナをさらに備える、項目７に記載のシステム。
【００２２】
９．前記少なくとも１つの通知可能オブジェクトを介して変更される前記少なくとも１つのアプリケーションと関連付けられた少なくとも１つの見た目および感じ特性を備える、項目６に記載のシステム。
【００２３】
１０．前記少なくとも１つの見た目および感じ特性変更を特定するための少なくとも１つの登録されたトップレベルユーザインタフェースコンポーネントをさらに備える、項目９に記載のシステム。
【００２４】
１１．前記変更リクエストの受信に対して少なくとも１つの登録されたトップレベルユーザインタフェースコンポーネントをさらに備える、項目１０に記載のシステム。
【００２５】
１２．前記少なくとも１つの見た目および感じ特性変更の完了し、前記変更リクエストの受信に対して前記少なくとも１つの登録されたトップレベルユーザインタフェースコンポーネントを待ち行列にいれて一時的に実行を遅らせる行列、および該変更リクエストの受信に対して該少なくとも１つの登録されたトップレベルユーザインタフェースコンポーネントを直ちに実行するプロセススレッドのうちの少なくとも１つを備える、項目１１に記載のシステム。
【００２６】
１３．前記オブジェクト指向プログラムコードは、Ｊａｖａ（登録商標）プログラミング言語で書かれる、項目１に記載のシステム。
【００２７】
１４．前記マネージドコードプラットフォームは、Ｊａｖａ（登録商標）仮想マシンである、項目１に記載のシステム。
【発明を実施するための最良の形態】
【００２８】
マネージドアプリケーションプロセスにおいて非同期挙動変更を誘導するためのシステムおよび方法が提供される。アプリケーションマネージャプロセスが実行される。マネージドアプリケーションプロセスが実行される。マネージドコードプラットフォームの制御下にオブジェクト指向プログラムコードとして提供される少なくとも１つのアプリケーションが実行される。マネージドアプリケーションプロセスは、アプリケーションマネージャプロセスと論理的に通信する。オブジェクト指向プログラムコードとして提供される通知可能オブジェクトに対応する１つ以上のコンストラクタが識別される。各コンストラクタは、マネージドアプリケーションプロセスにおいてリスト中のインスタンス化された通知可能オブジェクトを追跡する。変更リクエストがマネージドアプリケーションプロセスにブロードキャストされる。各識別されたコンストラクタによって追跡された通知可能オブジェクトは繰り返されてマネージドアプリケーションプロセスにおける挙動変更を生成する。
【００２９】
（システム概要）
図１は、例として、複数の異種デバイス上に実施されるランタイム環境（ＲＴＥ）１４、２２、２４、２６を示す機能ブロック図１０である。各異種デバイス１１は、ランタイム環境１４、２２、２４、２６において実行するＪａｖａ（登録商標）動作環境などのマネージドコードプラットフォームを提供する。１つ以上のアプリケーション２７は、ランタイム環境１４、２２、２４、２６において実行し得、かつ各実行アプリケーション２７およびランタイム環境１４、２２、２４、２６の対はマネージドアプリケーションプロセス２８を構成する。これらは以下に図２を参照してさらに説明する。異種デバイス１１は、非排他的に、デスクトップまたはラップトップコンピュータシステムなどのクライアントコンピュータシステム１３を含む。各クライアント１３は、格納デバイス１５に動作可能に結合され、かつデータ構造およびデータ上で動作する数セットの方法を特定するコードモジュールをそれぞれ定義する１セットのクラス１６およびクラスライブラリ１７、およびシェア可能なモジュールの集まりを維持する。異種デバイス１１はまた、個人データアシスタント２１、および一般消費者デバイス（携帯電話２３およびセットトップボックス（ＳＴＢ）２５など）を含む携帯コンピューティングデバイスを含む。最後に、サーバ１８は、グローバルにシェア可能なクラスライブラリ２０が維持される格納デバイス１９に動作可能に結合される。異種デバイス１１のそれぞれは、従来のハードウェアに組み込まれたワイヤレスネットワークコンフィギュレーションを含むネットワーク１２を介してインタフェースをとり得る。他のタイプの異種デバイス１１および種々のネットワークコンフィギュレーション、構成、およびトポロジーが可能である。
【００３０】
各異種デバイス１１は、リソースを管理し、周辺デバイスへのアクセスを提供し、メモリリソースを割り当て、かつプログラムの実行および終了を制御するためのオペレーティングシステムを含む。１つの実施形態において、各オペレーティングシステムは、特定可能プロセスのメモリ空間をクローン化することによって複数かつ独立な個別ユーザアプリケーションを生成するプロセスクローン化機構に対応する。このことは、同一人に譲渡された米国特許出願シリアル番号１０／７４５，０２３、発明の名称「Ｓｙｓｔｅｍ  Ａｎｄ  Ｍｅｔｈｏｄ  Ｆｏｒ  Ｄｙｎａｍｉｃ  Ｐｒｅｌｏａｄｉｎｇ  Ｏｆ  Ｃｌａｓｓｅｓ  Ｔｈｒｏｕｇｈ  Ｍｅｍｏｒｙ  Ｓｐａｃｅ  Ｃｌｏｎｉｎｇ  Ｏｆ  Ａ  Ｍａｓｔｅｒ  Ｒｕｎｔｉｍｅ  Ｓｙｓｔｅｍ  Ｐｒｏｃｅｓｓ」（２００３年１２月２２日出願、係属中）、シリアル番号１０／７４５，０２０、発明の名称「Ｓｙｓｔｅｍ  Ａｎｄ  Ｍｅｔｈｏｄ  Ｆｏｒ  Ｐｒｏｖｉｄｉｎｇ  Ｐｒｅｃｏｍｐｉｌｅｄ  Ｃｏｄｅ  Ｔｈｒｏｕｇｈ  Ｍｅｍｏｒｙ  Ｓｐａｃｅ  Ｃｌｏｎｉｎｇ  Ｏｆ  Ａ  Ｍａｓｔｅｒ  Ｒｕｎｔｉｍｅ  Ｓｙｓｔｅｍ  Ｐｒｏｃｅｓｓ」（２００３年１２月２２日出願、係属中）、およびシリアル番号１０／７４５，０２１、発明の名称「Ｓｙｓｔｅｍ  Ａｎｄ  Ｍｅｔｈｏｄ  Ｆｏｒ  Ｅｌｉｍｉｎａｔｉｎｇ  Ｓｔａｔｉｃ  Ｉｎｉｔｉａｌｉｚａｔｉｏｎ  Ｏｖｅｒｈｅａｄ  Ｂｙ  Ｍｅｍｏｒｙ  Ｓｐａｃｅ  Ｃｌｏｎｉｎｇ  Ｏｆ  Ａ  Ｍａｓｔｅｒ  Ｒｕｎｔｉｍｅ  Ｓｙｓｔｅｍ  Ｐｒｏｃｅｓｓ」（２００３年１２月２２日出願、係属中）に記載される。これらの開示は本明細書中において参考として援用される。本発明の使用に適切なプロセスクローン化機構の例は、Ｕｎｉｘ（登録商標）またはＬｉｎｕｘオペレーティングシステムによって提供されるｆｏｒｋ（）システムコールである。これは、Ｍ．Ｊ．  Ｂａｃｈ，「Ｔｈｅ  Ｄｅｓｉｇｎ  Ｏｆ  Ｔｈｅ  Ｕｎｉｘ（登録商標）  Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ」  Ｃｈ．  ７，  Ｂｅｌｌ  Ｔｅｌｅ．  Ｌａｂｓ．，  Ｉｎｃ．  （１９８６）などに記載され、その開示は本明細書中において参考として援用される。ｆｏｒｋ（）を呼び出すプロセスは親プロセスとして知られ、かつ新たに生成されたプロセスは子プロセスと呼ばれる。オペレーティングシステムは、個別のプロセス識別子を子プロセスに割当てる。子プロセスは個別のプロセスとして実行する。オペレーティングシステムはまた、親プロセスのメモリ空間を子プロセスのメモリ空間にコピーすることによって親プロセスのコンテクストの論理コピーを生成する。ｆｏｒｋ（）システムコールのコピーオンライト変形例において、オペレーティングシステムは、メモリ空間への参照をコピーするだけであり、そして子プロセスが親プロセスコンテクストの参照されたデータの変更を試みるまで、および試みたならば、個々のメモリ空間セグメントの実際のコピーを遅らせる。コピーオンライトｆｏｒｋ（）システムコールは、非コピーオンライトｆｏｒｋ（）システムコールより速く、かつ親および子プロセスの間に書き込まれないいずれのデータも暗黙的に共有する。
【００３１】
（非同期挙動変更を誘導するためのシステム）
図２は、本発明による、マネージドアプリケーションプロセス３４において非同期挙動変更を誘導するためのシステム３０を示すブロック図である。システム３０は、アプリケーションマネージャ３１および１つ以上のマネージドアプリケーションプロセス３２を実行するランタイム環境を含む。マネージドアプリケーションプロセス３２は、マシン移植可能コード定義互換アプリケーションおよび１つ以上の実行アプリケーション３３をインタープリットするＪａｖａ（登録商標）仮想マシンなどのマネージドコードプラットフォームを含む。格納デバイス３０は、全コアマネージドコードプラットフォームを形成する個別のクラス４０およびクラスライブラリ４２を常に格納する。例として、Ｊａｖａ（登録商標）動作環境を参照してシステムを記載したが、Ｊａｖａ（登録商標）プログラミング言語などのオブジェクト指向プログラミング言語で好ましきくは書かれたアプリケーションを実行する他の形態のマネージドコードプラットフォームもまた使用され得る。
【００３２】
アプリケーションマネージャ３１は、ユーザインタフェースを提供し、それを介して個別のアプリケーションがユーザによって選択および実行され得る。ランタイム時に、アプリケーションマネージャ３１は、リスナ３４を介してマネージドアプリケーションプロセス３２に対して通信可能にインタフェースをとられる。アプリケーションマネージャ３１は、リスナ３４、およびマネージドアプリケーションプロセスコンテクストにおいてインスタンス化されかつそのコンストラクタによってリスト中をトランスペアレントに追跡された１つ以上の通知可能オブジェクト３５の組み合わせを介して間接的にアプリケーション３３において挙動変更を誘導する。
【００３３】
リスナ３４は、アプリケーションマネージャ３１から論理通信チャネルを提供する。論理通信チャネルを介して挙動変更はメッセージ（「Ｍｓｇ」）において１つ以上のマネージドアプリケーションプロセス３２に非同期的に「ブロードキャスト」され得る。アプリケーションマネージャ３１は、アプリケーション起動リスト４４において起動されたマネージドアプリケーションプロセス３２を記録する。挙動変更を開始する際、アプリケーションマネージャ３２は、アプリケーション起動リスト４４上で繰り返し、そしてすべての生成されたマネージドアプリケーションプロセス３２のリスナ３４に同じメッセージ３８を送信する。メッセージ３８は、アプリケーションの特性またはユーザインタフェースの見た目および感じの変更などの変更リクエストの性質を識別する。変更リクエストの他のタイプも可能である。
【００３４】
アプリケーションマネージャ３１は、リスナ３４上に定義されたハンドル３６を介して各マネージドアプリケーションプロセス３２にアクセスする。アプリケーションマネージャ３１は、リスナハンドルリスト４５中にリスナハンドル３６を記録する。リスナ３４は、マネージドアプリケーションのアドレス空間中に存在し、かつ変更がアプリケーションマネージャ３４によってリクエストされるまでイナクティブにとどまる専用コントロールスレッドを含む。このことは以下に図５を参照して説明する。上記の実施形態において、リスナ３４は、ＴＣＰなどのＩＰＣ機構を介して提供され、かつＴＣＰソケットなどのソケットとして定義されるハンドル３６を含む。ハンドル３６は、マネージドアプリケーションプロセス３２上の専用ポート番号として特定され得る。
【００３５】
通知可能オブジェクト３５は、マネージドアプリケーションプロセス３２のマネージドプラットフォームのコンテクストにおいてインスタンス化される。通知可能オブジェクト３５に対するコンストラクタ４１、４３は、クラス４０およびクラスライブラリ４２において定義されるクラスにおいて定義される。マネージドアプリケーションプロセス３２は、通知可能オブジェクト３５のタイプに対してコンストラクタ４１、４３を使用して各インスタンス化通知可能オブジェクト３５をマネージドアプリケーションプロセス３１中のローカルリスト４６に入れる。これらのコンストラクタ４１、４３は、クラス４０、４２中にアーキテクトされ、上記の追跡に対応するために必要な機能を含む。クラス４０、４２は、引き続きプログラミングモデル予想を満足するが、さらなる追跡および変更機能を補填される。例えば、ある周知のライブラリがしばしばアプリケーション３３によって使用され、かつライブラリを定義するために必要なソースコードの実装がアプリケーションクラスではなくシステムクラスとして一般に特定される。したがって、ライブラリは予想される機能を提供し、かつリスト４６中の通知オブジェクト３５を追跡するための機能をまた含むために書かれるので、挙動変更がアプリケーション実行に対してトランスペアレントに生じることが可能となる。さらなる実施形態において、各クラス４０、４２はまた、ガーベッジコレクションのために通知可能オブジェクトの適格性を検出し得るファイナライザを定義する。次いで、ファイナライザ方法は、通知可能オブジェクト３５がガーベッジコレクタによって取り戻されるところなので、それぞれの追跡リストから通知可能オブジェクト３５を除去し得る。
【００３６】
挙動変更を初期化するために、アプリケーションマネージャ３１は、挙動変更を生成するために必要な通知可能オブジェクト３５のタイプを識別するメッセージ３８を送信する。次いで、リスナ３４は、ローカルリスト４６において追跡されるように識別されたタイプの割り当てられた通知可能オブジェクト３５にわたって繰り返えされ、かつアプリケーションマネージャ３１に代わって挙動変更をトランスペアレントに生成する。
【００３７】
（非同期制御およびデータ交換）
図３Ａ〜Ｃは、例として、アプリケーションマネージャ６２と複数のマネージドアプリケーションプロセス６３、６５、６７との間の非同期制御およびデータ交換を示す機能ブロック図である。アプリケーションマネージャ６２およびマネージドアプリケーションプロセス６３、６５、６７はすべて、ランタイム環境６１において実行する。まず図３Ａを参照すると、各マネージドアプリケーションプロセス６３、６５、６７は、通知可能オブジェクトのタイプに対応するコンストラクタ６９を使用して、通知可能オブジェクトをローカルリスト中に追跡する。
【００３８】
次に図３Ｂを参照すると、アプリケーションマネージャ６２は、メッセージ３８をマネージドアプリケーションプロセス６３、６５、６７のそれぞれに非同期「ブロードキャスト」７１を介して転送することによって挙動変更を誘導することを開始する。非同期ブロードキャスト７１は、各マネージドアプリケーションプロセス６３、６５、６７中に実装されたリスナ（「Ｌ」）６４、６６、６８によって受信される。ブロードキャスト７１は２つの機能を提供する。１つ目は、ブロードキャスト７１が各マネージドアプリケーションプロセス６３、６５、６７にアプリケーションマネージャ６２が挙動変更をリクエストしていることを通知することである。２つ目は、ブロードキャスト７１がリクエストされた挙動変更のタイプを識別することである。例として、変更は各マネージドアプリケーションの性質または見た目や感じ特性を生成し得る。他のタイプの変更も可能である。
【００３９】
最後に図３Ｃを参照すると、個別のマネージドアプリケーションプロセス６３、６５、６７はリクエストされた挙動変更を実施する。各マネージドアプリケーションプロセス６３、６５、６７によるアクションのタイプは、各通知可能オブジェクト６９を定義するコードに左右される。リスナ６４、６６、６８は、各セットの追跡された通知可能オブジェクトを各マネージドアプリケーションプロセス６３、６５、６７の対応のアドレス空間において見出し、そして通知可能オブジェクトにわたって繰り返して挙動変更を生成する役割を果たす。他のタイプのアクションが可能である。
【００４０】
（非同期挙動変更を誘導するための方法）
図４は、本発明にしたがってマネージドアプリケーションプロセス中に非同期挙動変更を誘導するための方法９０を示す。方法１００は、例えば図２のランタイム環境３１および他のコンポーネントによって実行され得る一シーケンスのプロセス動作またはステップとして記載される。
【００４１】
まず、アプリケーションマネージャ３１がロードされる（ブロック９１）。誘導された挙動変更を開始する際、アプリケーションマネージャ３１は、挙動変更を生成するために必要な通知可能オブジェクト３５のタイプを識別する（ブロック９２）。次いで、アプリケーションマネージャ３１は、生成されたマネージドアプリケーションプロセス３２のすべてのリスナ３４を各マネージドアプリケーションプロセス３２上にそれぞれ定義されたハンドル３６を介して呼び出す（ブロック９６）。次いで、挙動変更を記載するメッセージ３８は、マネージドアプリケーションプロセス３２にブロードキャストされる（ブロック９４）。処理は、アプリケーションマネージャ３１が終了するまでいつまでも続く。
【００４２】
（マネージドアプリケーションプロセスを実行するためのルーチン）
図５は、図４の方法９０において使用するためのマネージドアプリケーションプロセス３２を実行するためのルーチン１００を示す。このルーチンの方法は、アプリケーションマネージャ３１から受信された変更リクエストに応答して非同期挙動変更を開始することである。
【００４３】
まず、アプリケーション３３は、マネージドアプリケーションプロセス３２のマネージドコードプラットフォームによって実行される（ブロック１０１）。ハンドル３６が生成され、そして専用制御スレッドがハンドル３１をリッスンするマネージドアプリケーションプロセス３２において開始される（ブロック１０２）。マネージドスレッドは、イナクティブスリープモードに入る（ブロック１０３）。アプリケーションマネージャ３２から変更リクエストを受信すると（ブロック１０４）、制御スレッドは起動し（ブロック１０５）、そして誘導された挙動変更を処理する（ブロック１０６）。このことは以下に図１６を参照して説明する。処理は、マネージドアプリケーションプロセス３２が終了するまでいつまでも続く。
【００４４】
（変更を処理するためのルーチン）
図６は、例として、図５のルーチン１００において使用するための誘導された非同期挙動変更を処理するためのルーチン１００を示すフロー図である。このルーチンの１つの目的は、通知可能オブジェクト１１０、１１１の実行を介してマネージドアプリケーションプロセス１０２上に挙動変更を生成することである。実行は、リスナ３４がアプリケーションマネージャ３１からブロードキャストされたメッセージ３８を受信した場合に、リスナ３４によって引き起こされる。次いで、リスナ３４は、各セットの通知可能オブジェクトをマネージドアプリケーションプロセス３２の対応のアドレス空間において見出し、そして通知可能オブジェクトにわたって繰り返して挙動変更を生成する役割を果たす。
【００４５】
まず、リクエストされた挙動変更のタイプが識別される（ブロック１０１）。一実施形態において、１つ以上の登録されたプロパティ変更リスナ（ブロック１１４）を識別（ブロック１１３）しそして通知することによってマネージドアプリケーションプロセス３２のプロパティへの変更が生成され得る（ブロック１１２）。
【００４６】
さらなる実施形態において、マネージドアプリケーションプロセス３２のユーザインタフェースの見た目および感じ特性への変更が生成され得る（ブロック１１６）。リクエストされた変更が有効な見た目および感じクラス（ブロック１１６）を識別し、かつそのクラスが現在の見た目および感じクラスと異なる（ブロック１１７）ならば、見た目および感じ挙動変更が必要である。マネージドアプリケーションプロセス３２は、各登録されたトップレベルユーザインタフェースコンポーネントにわたって繰り返され（ブロック１１８〜１２０）、そして見た目および感じ変更メッセージを送信する（ブロック１１９）。次いで、変更は、使用されるツールキットに適切なように生成される。例えば、変更は、実行を一時的に遅らせるために待ち行列に入れられるか、または直ちに実行される。変更の生成に続いて、次いでルーチンが戻る。
【００４７】
例として、アプリケーションマネージャ３２によって送信されたメッセージ３８が「ＰＲＯＰＥＲＴＹ＿ＣＨＡＮＧＥ  ｐｒｏｐｅｒｔｙＮａｍｅ＝値」を含むならば、リスナ３４は＜ｐｒｏｐｅｒｔｙＮａｍｅ＞に対して登録されたこれらの変更リスナを識別し、そしてｐｒｏｐｅｒｔｙＣｈａｎｇｅｄ（）コールを使用して各プロパティ変更リスナを通知する。
【００４８】
さらなる例として、アプリケーションマネージャ３２によって送信されたメッセージ３８が「ＬＡＮＤＦ＿ＣＨＡＮＧＥ  ｌｏｏｋＡｎｄＦｅｅｌＣｌａｓｓＮａｍｅ」を含むならば、リスナ３４は、＜ｌｏｏｋＡｎｄＦｅｅｌＣｌａｓｓＮａｍｅ＞が有効であり、かつ現在の見た目および感じと異なるかどうかを判断する。変更が必要ならば、リスナ３４は、すべての登録されたトップレベルユーザインタフェースコンポーネントにわたって繰り返えされ、そして見た目および感じ変更メッセージを送信する。他のタイプの挙動変更が可能である。
【００４９】
本発明を実施の形態を参照して詳細に記載したが、形態や詳細における前記およびその他の変更は本発明の意図および範囲を逸脱せずになされ得ることが当業者には理解される。
【図面の簡単な説明】
【００５０】
【図１】例として、複数の異種デバイス上に実装されたランタイム環境を示す機能ブロック図である。
【図２】本発明による、マネージドアプリケーションプロセスにおいて非同期挙動変更を誘導するためのシステムを示すブロック図である。
【図３Ａ】例として、アプリケーションマネージャと複数のマネージドアプリケーションプロセスとの間の非同期制御およびデータ交換を示す機能ブロック図である。
【図３Ｂ】例として、アプリケーションマネージャと複数のマネージドアプリケーションプロセスとの間の非同期制御およびデータ交換を示す機能ブロック図である。
【図３Ｃ】例として、アプリケーションマネージャと複数のマネージドアプリケーションプロセスとの間の非同期制御およびデータ交換を示す機能ブロック図である。
【図４】本発明にしたがってマネージドアプリケーションプロセス中に非同期挙動変更を誘導するための方法を示す。
【図５】図４の方法において使用するためのマネージドアプリケーションプロセスを実行するためのルーチンを示す。
【図６】例として、図５のルーチンにおいて使用するための誘導された非同期挙動変更を処理するためのルーチンを示すフロー図である。
【図１】
2005209173.tif 000003
【図２】
2005209173.tif 000004
【図３Ａ】
2005209173.tif 000005
【図３Ｂ】
2005209173.tif 000006
【図３Ｃ】
2005209173.tif 000007
【図４】
2005209173.tif 000008
【図５】
2005209173.tif 000009
【図６】
2005209173.tif 000010
【外国語明細書】
1. Title of Invention
System and Method for Inducing asynchronous behavioral changes in a managed application process
2. Detailed Description of Invention
FIELD OF THE INVENTION
The invention relates in general to asynchronous behavioral changes and, in particular, to a system and method for inducing asynchronous behavioral changes in a managed application process.
BACKGROUND OF THE INVENTION
Recent advances in microprocessor design and component integration have enabled a wide range of devices to offer increasingly complex functionality and “soft” features.  Soft features include software applications that enhance and customize the operation of a device.  These devices include standard computing devices, such as desktop and laptop computers, portable computing devices, such as personal data assistants, and consumer devices, such as cellular telephones, messaging pagers, gaming consoles, and set top boxes.  Most devices now include an operating system to support the soft features and other extensions.
The increased capabilities offered by these software-upgradeable devices have also created certain user expectations.  Often, users are not technically savvy and are intolerant of performance compromises occasioned by architectural challenges, such as slow or inconsistent application performance.  Similarly, users generally expect to be able to access a host of separate applications, which are implemented at the system level through multitasking.  For users, widely available software applications assure a positive experience through consistency and increased exposure across multiple platforms.  However, for software developers, engineering software applications for disparate computing platforms entails increased development costs and on-going support and upgrade commitments for each supported architecture.
Managed code platforms provide one solution to software developers seeking to support multiple platforms by presenting a machine-independent and architecture-neutral operating environment.  Managed code platforms include programming language compilers and interpreters executed by an operating system as user applications, but which provide virtual runtime environments within which compatible applications can operate.  For instance, applications written in the Java programming language, when combined with a Java virtual machine (JVM) runtime environment, can operate on heterogeneous computer systems independent of machine-specific environment and configuration settings.  An overview of the Java programming language is described in P. van der Linden, “Just Java,” Ch. 1, Sun Microsystems, Inc. (2d ed. 1997), the disclosure of which is incorporated by reference.  JVMsare a critical component to the overall Java operating environment, which can be ported to the full range of computational devices, including memory-constrained consumer devices.
Managed code platforms are generally designed for the monotonic execution of a single application instance.  The combination of a managed code platform and an application instance forms an application process.  Thus, multiple application processes can be executed to simulate multitasking behavior for a plurality of individual applications.  Each “multitasked” application executes under a separate managed code platform, which provides a discrete virtual runtime environment.  In turn, each managed code platform executes in a separate process space under the control of the underlying operating system.  Limited control over managed code platforms can be effected using facilities provided by the operating system, such as inter-process communication (IPC) and related mechanisms, such as signal handlers, but similar facilities are generally not available for controlling applications executing under managed code platforms.
Application control is unavailable for several reasons.  First, each application can originate from a different source and can be programmed using different application models, programming languages and operational assumptions.  As well, each application is isolated within the virtual runtime environment provided by the managed code platform and inter-process control must be explicitly programmed into an application using extended library functions operating within the runtime environment.  Such program extensions are often slow and can potentially introduce compatibility and interoperability issues.  Moreover, isolated application execution is generally preferred over cooperative application execution for simplicity, robustness and efficiency.
Nevertheless, an application manager is frequently used to provide a minimal degree of centralized control over multiple application processes executing on a device, especially consumer devices, based on user requests.  However, the control is generally limited to provided large grained control over application startup and termination.  Fine grained control over application-level behavioral characteristics is unsupported due to the unavailability of application control facilities.  For example, application properties or the look and feel of the user interface might need to be dynamically changed by the runtime environment or to ensure a consistence appearance and user experience.  However, the lack of inter-application control facilities precludes making such runtime changes.
Therefore, there is a need for an approach to providing dynamic centralized control over isolated application processes.  Preferably, such an approach would effect asynchronous changes over each application process without effecting discrete application execution.  Moreover, such an approach would further provide a flexible mechanism to communicate behavioral changes while allowing each application process to proceed without explicit cooperation.
SUMMARY OF THE INVENTION
An application manager and a managed code platform are executed in an application framework that supports the spawning of multiple and independent isolated user applications.  The managed code platform includes a runtime system process, such as a virtual machine, to interpret machine-portable code defining compatible applications.  Each executing application and runtime system process pairing constitutes a managed application process.  The application manager asynchronously accesses the runtime system process through a listener implementing an inter-process communication (IPC) mechanism, such as a dedicated control thread.  An instance of this listener resides in the address space of each managed application process. The listener is accessible by the application manager via a “handle.”  For example, TCP/IP can be used as the IPC mechanism between the application manager and managed application processes and the handle is specified as a TCP port number.  The runtime system process context includes a set of notifiable objects, which are used to transparently impose behavioral changes on applications executing in the runtime system process.  An example of a suitable managed code platform and managed application process are the Java operating environment and Java virtual machine (JVM) architecture, as licensed by Sun Microsystems, Inc., Palo Alto, CA.
One embodiment provides a system and method for inducing asynchronous behavioral changes in a managed application process.  An application manager process is executed.  A managed application process is executed.  At least one application provided as object-oriented program code under the control of a managed code platform is executed.  The managed application process logically communicates with the application manager process.  One or more constructors corresponding to classes of notifiable objects are identified.  Each such constructor, when executed, puts a newly constructed notifiable object of interest on a list. A change request is broadcast to the managed application process.  The notifiableobjects transparently tracked by the constructors are iterated over to effect a behavioral change in the managed application process.
Behavioral changes are performed transparently to non-cooperating applications executing in a runtime system process as part of a managed application process.  Using the listener and transparently tracked notifiableobjects, behavioral changes can be effected by an application manager on executing managed application processes independently of and without the express cooperation of the discrete executing application.
Still other embodiments of the invention will become readily apparent to those skilled in the art from the following detailed description, wherein are described embodiments of the invention by way of illustrating the best mode contemplated for carrying out the invention.  As will be realized, the invention is capable of other and different embodiments and its several details are capable of modifications in various obvious respects, all without departing from the spirit and the scope of the invention.  Accordingly, the drawings and detailed description are to be regarded as illustrative in nature and not as restrictive.
Accordingly, the present invention provides the following items:
1. A system for inducing asynchronous behavioral changes in a managed application process, comprising:
a managed application process, comprising:
at least one application being provided as object-oriented program code under the control of a managed code platform; and 
a handler to logically communicate with an executing application manager process;
a local list to identify one or more constructors corresponding to notifiable objects provided as object-oriented program code;
at least one control thread to broadcast a change request to the managed application process; and
a listener to iterate over the notifiableobjects tracked by each identified constructor to effect a behavioral change in the managed application process.
2. A system according to Item 1, further comprising:
a control thread to specify the listener, wherein the control thread is caused to sleep relative to receiving the change request.
3. A system according to Item 2, wherein information is communicated from the application manager in a stream defined on the control thread.
4. A system according to Item 3, wherein the handle comprises a TCP socket and the stream comprises a TCP stream.
5. A system according to Item 1, further comprising:
one or more constructors corresponding to the notifiableobjects and specifying eligibility of the notifiableobjects for garbage collection.
6. A system according to Item 1, further comprising:
at least one property associated with the at least one application changed through the at least one such notifiableobject.
7. A system according to Item 6, further comprising:
at least one property change listener to specify the at least one property change.
8. A system according to Item 7, further comprising:
the at least one property change listener to be notified relative to receiving the change request.
9. A system according to Item 6, further comprising:
at least one look and feel characteristic associated with the at least one application to be changed through the at least one such notifiableobject.
10. A system according to Item 9, further comprising:
at least one registered top-level user interface component to specify the at least one look and feel characteristic change.
11. A system according to Item 10, wherein the listener iterates over each at least one registered top-level user interface component relative to receiving the change request.
12. A system according to Item 11, wherein completion of the at least one look and feel characteristic change is effected, comprising at least one of:
a queue to enqueue the at least one registered top-level user interface component relative to receiving the change request to temporarily defer execution; and
a process thread to immediately execute the at least one registered top-level user interface component relative to receiving the change request.
13. A system according to Item 1, wherein the object-oriented program code is written in the Java programming language.
14. A system according to Item 1, wherein the managed code platform is a Java virtual machine.
DETAILDEDDESCRIPTION OF THE INVENTION
A system and method for inducing asynchronous behavioral changes in a managed application process is presented.  An application manager process is executed.  A managed application process is executed.  At least one application provided as object-oriented program code under the control of a managed code platform is executed.  The managed application process logically communicates with the application manager process.  One or more constructors corresponding to notifiable objects provided as object-oriented program code are identified.  Each constructor keeps track of instantiated notifiable objects in a list in the managed application process. A change request is broadcast to the managed application process.  The notifiable objects tracked by each identified constructor are iterated over to effect a behavioral change in the managed application process.
System Overview
FIGURE 1 is a functional block diagram 10 showing, by way of example, runtime environments (RTEs) 14, 22, 24, 26 implemented on a plurality of heterogeneous devices 11.  Each heterogeneous device 11 provides a managed code platform, such as the Java operating environment, executing in a runtime environment 14, 21, 24, 26.  One or more applications 27 can execute in the runtime environments 14, 21, 24, 26 and each executing application 27 and runtime environment 14, 21, 24, 26 pairing constitutes a managed application process 28, as further described below with reference to FIGURE 2.  The heterogeneous devices 11 include, nonexclusively, a client computer system 13, such as a desktop or laptop computer system.  Each client 13 is operatively coupled to a storage device 15 and maintains a set of classes 16 and class libraries 17, which respectively define code modules that specify data structures and sets of methods that operate on the data, and shareable collections of the modules.  The heterogeneous devices 11 also include portable computing devices, including personal data assistants 21, and consumer devices, such as cellular telephones 23 and set top boxes (STB) 25.  Finally, a server 18 is operatively coupled to a storage device 19 in which globally shareable class libraries 20 are maintained.  Each of the heterogeneous devices 11 can interface via a network 12, which includes conventional hardwired and wireless network configurations.  Other types of heterogeneous devices 11 and various network configurations, arrangements, and topologies are possible.
Each heterogeneous device 11 includes an operating system to manage resources, provide access to peripheral devices, allocate memory resources, and control program execution and termination.  In one embodiment, each operating system supports a process cloning mechanism that spawns multiple and independent isolated user applications by cloning the memory space of specifiable processes, such as described in commonly-assigned U.S. Patent application Serial No. 10/745,023, entitled “System And Method For Dynamic Preloading Of Classes Through Memory Space Cloning Of A Master Runtime System Process,” filed 22 December 2003, pending; Serial No. 10/745,020, entitled “System And Method For Providing Precompiled Code Through Memory Space Cloning Of A Master Runtime System Process,” filed 22 December 2003, pending; and Serial No. 10/745,021, entitled “System And Method For Eliminating Static Initialization Overhead By Memory Space Cloning Of A Master Runtime System Process,” filed 22 December 2003, pending; the disclosures of which are incorporated by reference.  An example of a process cloning mechanism suitable for use in the present invention is the fork() system call provided by the Unix or Linux operating systems, such as described in M.J. Bach, “The Design Of The Unix Operating System,” Ch. 7, Bell Tele. Labs., Inc. (1986), the disclosure of which is incorporated by reference.  The process invoking the fork()system call is known as the parent process and the newly created process is called the child process.  The operating system assigns a separate process identifier to the child process, which executes as a separate process.  The operating system also creates a logical copy of the context of the parent process by copying the memory space of the parent process into the memory space of the child process.  In a copy-on-write variant of the fork() system call, the operating system only copies references to the memory space and defers actually copying individual memory space segments until, and if, the child process attempts to modify the referenced data of the parent process context.  The copy-on-write fork() system call is faster than the non-copy-on-write fork() system call and implicitly shares any data not written into between the parent and child processes.
System for Inducing Asynchronous Behavioral Changes
FIGURE 2 is a block diagram showing a system 30 for inducing asynchronous behavioral changes in a managed application process 34, in accordance with the invention.  The system 30 includes a runtime environment executing an application manager 31 and one or more managed application processes 32.  The managed application process 32 includes a managed code platform, such as a Java virtual machine, that interprets machine-portable code defining compatible applications and one or more executing applications 33.  A storage device 39 persistently stores individual classes 40 and class libraries 42 that form the overall core managed code platform.  By way of example, the system is described with reference to the Java operating environment, although other forms of managed code platforms that execute applications preferably written in an object oriented programming language, such as the Java programming language, could also be used.
The application manager 31 presents a user interface through which individual applications can be selected and executed by a user.  At runtime, the application manager 31 is communicatively interfaced to the managed application process 32 through a listener 34.  The application manager 31 induces behavioral changes in the application 33 indirectly through a combination of the listener 34 and one or more notifiable objects 35 instantiated in the managed application process context and transparently tracked in lists by their constructors.
The listener 34 provides a logical communication channel from the application manager 31 through which behavioral changes can be asynchronously “broadcast” in a message (“Msg”) 38 to one or more managed application processes 32.  The application manager 31 records launched managed application processes 32 in an applications launched list 44.  Upon initiating a behavioral change, the application manager 32 iterates over the applications launched list 44 and sends the same message 38 to the listeners 34 of all spawned managed application processes 32.  The message 38 identifies the nature of the change request, such as changing application properties or the look and feel of the user interface.  Other types of change requests are possible.
The application manager 31 accesses each managed application process 32 through a handle 36 defined on the listener 34.  The application manager 31 records listener handles 36 in a listener handles list 45.  The listener 34 resides in the address space of the managed application process 31 and includes a dedicated control thread that remains inactive until a change is requested by the application manager 31, as further described below with reference to FIGURE 5.  In the described embodiment, the listener 34 is provided through an IPC mechanism, such as a TCP, and includes a handle 36 defined as a socket, such as a TCP socket, which can be specified as a dedicated port number on the managed application process 32.
The notifiableobjects 35 are instantiated in the context of the managed code platform of the managed application process 32.  Constructors 41, 43 for the notifiable objects 35 are defined in the classes 40 and classes defined in the class libraries 42.  The managed application process 32 uses the constructors 41, 43 for the types of notifiableobjects 35 to put each instantiated notifiable object 35  into a local list 46 in the managed application process 31.  These constructors 41, 43 are architected into the classes 40, 42 to include functionality necessary to accommodate such tracking.  The classes 40, 42 continue to meet programming model expectations, but are supplemented with the additional tracking and change functionality.  For example, certain well-known libraries are often used by applications 33 and the implementation of the source code required to define the libraries are generally specified as a system class, rather than an application class.  Accordingly, the libraries can be written to both provide the expected functionality and also include functionality to track notifiable objects 35 in lists 46, thereby allowing behavioral changes to occur transparently relative to application execution.  In a further embodiment, each class 40, 42 also defines a finalizerthat can detect the eligibility of notifiable objects 35 for garbage collection. The finalizer method can then remove the notifiable object 35 from the respective tracking list, since the notifiable object 35 is about to be reclaimed by the garbage collector.
To initiate a behavioral change, the application manager 31 sends a message 38 identifying the type of notifiable object 35 required to effect the behavioral change.  The listener 34 then iterates over allocated notifiable objects 35 of the identified type as tracked in the local list 46 and transparently effects the behavioral change on behalf of the application manager 31.
Asynchronous Control and Data Exchange
FIGURES 3A-C are functional block diagrams 60, 80, 90 showing, by way of example, an asynchronous control and data exchange between an application manager 62 and a plurality of managed application processes 63, 65, 67.  The application manager 62 and managed application processes 63, 65, 67 all execute within a runtime environment 61.  Referring first to FIGURE 3A, each managed application process 63, 65, 67 uses the constructors 69 corresponding to the type of notifiable objects to track notifiable objects into a local list.
Referring next to FIGURE 3B, the application manager 62 begins  inducing behavioral changes by transferring a message 38 to each of the managed application processes 63, 65 67 through an asynchronous “broadcast” 71, which is received by a listener (“L”) 64, 66, 68 implemented in each managed application process 63, 65, 67.  The broadcast 71 serves two functions.  First, the broadcast 71 notifies each managed application process 63, 65, 67 that the application manager 62 is requesting a behavioral change.  Second, the broadcast 71 identifies the type of behavioral change requested.  By way of example, the change could effect properties or look and feel characteristics of each managed application process 63, 65, 67.  Other types of changes are possible.
Referring last to FIGURE 3C, the individual managed application processes 63, 65, 67 implement the requested behavioral changes.  The type of actions taken by each managed application process 63, 65, 67 depend upon the code defining each notifiable object 69.  The listener 64, 66, 68 is responsible for finding each set of tracked notifiable objects in the corresponding address space of each managed application process 63, 65, 67 and iterating over the notifiable objects to effect the behavioral change.  Other types of actions are possible.
Method for Inducing Asynchronous Behavioral Changes
FIGURE 4 is a flow diagram, showing a method 90 for inducing asynchronous behavioral changes in a managed application process, in accordance with the invention.  The method 100 is described as a sequence of process operations or steps, which can be executed, for instance, by the runtime environment 31 of FIGURE 2 or other components. 
Initially, the application manager 31 is loaded (block 91).  When initiating an induced behavioral change, the application manager 31 identifies the type of notifiable objects 35 required to effect the behavioral change (block 92).  The application manager 31 then invokes the listeners 34 of all of the spawned managed application processes 32 through the handle 36 respectively defined on each managed application process 32 (block 93).  A message 38 describing the behavioral change is then broadcast to the managed application processes 32 (block 94).  Processing continues indefinitely until the application manager 31 is terminated.
Routine for Executing a Managed Application Process
FIGURE 5 is a flow diagram showing the routine 100 for executing a managed application process 32 for use in the method 90 of FIGURE 4.  One purpose of this routine is to initiate an asynchronous behavioral change in response to a change request received from an application manager 31.
Initially, an application 33 is executed by the managed code platform of the managed application process 32 (block 101).  A handle 36 is created and a dedicated control thread is started in the managed application process 32 listening to the handle 31 (block 102).  The control thread immediately enters an inactive sleep mode (block 103).  Upon receiving a change request from the application manager 32 (block 104), the control thread awakens (block 105) and processes an induced behavioral change (block 106), as further described below with reference to FIGURE 16.  Processing continues indefinitely until the managed application process 32 is terminated.
Routine for Processing a Change
FIGURE 6 is a flow diagram showing, by way of example, the routine 110 for processing an induced asynchronous behavioral change for use in the routine 100 of FIGURE 5.  One purpose of this routine is to effect a behavioral change on a managed application process 102 through execution of notifiable objects 110, 111.  The execution is triggered by the listener 34 when the listener 34 receives a message 38 broadcast from the application manager 31.  The listener 34 is then responsible for finding each set of notifiableobjects 35 in the corresponding address space of the managed application process 32 and iterating over the notifiable objects 35 to effect the behavioral change
Initially, the type of requested behavioral change is identified (block 111).  In one embodiment, a change to a property of the managed application process 32 can be effected (block 112) by identifying (block 113) and notifying one or more registered property change listeners (block 114).  
In a further embodiment, a change to a look and feel characteristic of a user interface of the managed application process 32 can be effected (block 116).  If the requested change identifies a valid look and feel class (block 116) and the class is different than the current look and feel class (block 117), a look and feel behavioral change is necessary.  The managed application process 32 iterates (blocks 118-120) over each registered top-level user interface component and sends a look and feel change message (block 119).  The change is then effected in a manner appropriate to the toolkit in use.  For example, the change could be enqueued to temporarily defer execution or could be executed immediately.  Following effecting changes, the routine then returns.
By way of example, if the message 38 sent by the application manager 32 includes “PROPERTY_CHANGE propertyName=value,” the listener 34 identifies those property change listeners registered for <propertyName> and notifies each property change listener using a propertyChanged() call.
By way of further example, if the message 38 sent by the application manager 32 includes “LANDF_CHANGE lookAndFeelClassName,” the listener 34 determines whether <lookAndFeelClassName> is valid and different from the current look and feel.  If a change is necessary, the listener 34 iterates over all registered top-level user interface components and sends a look and feel change message.  Other types of behavioral changes are possible.
While the invention has been particularly shown and described as referenced to the embodiments thereof, those skilled in the art will understand that the foregoing and other changes in form and detail may be made therein without departing from the spirit and scope of the invention.
3. Brief Description of Drawings
FIGURE 1 is a functional block diagram showing, by way of example, runtime environments implemented on a plurality of heterogeneous devices.
FIGURE 2 is a block diagram showing a system for inducing asynchronous behavioral changes in a managed application process, in accordance with the invention.
FIGURES 3A-C are functional block diagrams showing, by way of example, an asynchronous control and data exchange between an application manager and a plurality of managed application processes.
FIGURE 4 is a flow diagram showing a method for inducing asynchronous behavioral changes in a managed application process, in accordance with the invention.
FIGURE 5 is a flow diagram showing the routine for executing a managed application process for use in the method of FIGURE 4.
FIGURE 6 is a flow diagram showing, by way of example, the routine for processing an induced asynchronous behavioral change for use in the routines of FIGURE 5.
1. A system for inducing asynchronous behavioral changes in a managed application process, comprising:
a managed application process, comprising:
at least one application being provided as object-oriented program code under the control of a managed code platform; and 
a handler to logically communicate with an executing application manager process;
a local list to identify one or more constructors corresponding to notifiable objects provided as object-oriented program code;
at least one control thread to broadcast a change request to the managed application process; and
a listener to iterate over the notifiableobjects tracked by each identified constructor to effect a behavioral change in the managed application process.
2. A system according to Claim 1, further comprising:
a control thread to specify the listener, wherein the control thread is caused to sleep relative to receiving the change request.
3. A system according to Claim 2, wherein information is communicated from the application manager in a stream defined on the control thread.
4. A system according to Claim 3, wherein the handle comprises a TCP socket and the stream comprises a TCP stream.
5. A system according to Claim 1, further comprising:
one or more constructors corresponding to the notifiableobjects and specifying eligibility of the notifiableobjects for garbage collection.
6. A system according to Claim 1, further comprising:
at least one property associated with the at least one application changed through the at least one such notifiableobject.
7. A system according to Claim 6, further comprising:
at least one property change listener to specify the at least one property change.
8. A system according to Claim 7, further comprising:
the at least one property change listener to be notified relative to receiving the change request.
9. A system according to Claim 6, further comprising:
at least one look and feel characteristic associated with the at least one application to be changed through the at least one such notifiableobject.
10. A system according to Claim 9, further comprising:
at least one registered top-level user interface component to specify the at least one look and feel characteristic change.
11. A system according to Claim 10, wherein the listener iterates over each at least one registered top-level user interface component relative to receiving the change request.
12. A system according to Claim 11, wherein completion of the at least one look and feel characteristic change is effected, comprising at least one of:
a queue to enqueue the at least one registered top-level user interface component relative to receiving the change request to temporarily defer execution; and
a process thread to immediately execute the at least one registered top-level user interface component relative to receiving the change request.
13. A system according to Claim 1, wherein the object-oriented program code is written in the Java programming language.
14. A system according to Claim 1, wherein the managed code platform is a Java virtual machine.
1. Abstract 
A system for inducing asynchronous behavioral changes in a managed application process, comprising:
a managed application process, comprising:
at least one application being provided as object-oriented program code under the control of a managed code platform; and 
a handler to logically communicate with an executing application manager process;
a local list to identify one or more constructors corresponding to notifiable objects provided as object-oriented program code;
at least one control thread to broadcast a change request to the managed application process; and
a listener to iterate over the notifiableobjects tracked by each identified constructor to effect a behavioral change in the managed application process.
2. Representative Drawing 
none
2005209173.tif 000011
2005209173.tif 000012
2005209173.tif 000013
2005209173.tif 000014
2005209173.tif 000015
2005209173.tif 000016
2005209173.tif 000017
2005209173.tif 000018