JP2005531061A - モバイルアプリケーションのための実行環境 - Google Patents

Abstract

本発明の一態様においては、少なくとも１つのアクセスネットワークの一部を形成するモバイルアプリケーション環境が提供される。アプリケーション環境は、動的ウェブページを形成するための命令のセットを含むＭｅｒｖｌｅｔアプリケーションを備えている。Ｍｅｒｖｌｅｔは、それぞれがアクセスネットワークに接続されるローカルノードまたはサーバノードで実行することができ、これにより、ローカルノードで実行しているクライアントアプリケーションからの要求に応じて、動的ウェブページを前記ローカルノードに表示する。また、アプリケーション環境は、Ｍｅｒｖｌｅｔに関連付けられた少なくとも１つのアプリケーション属性を備えている。アプリケーション属性は、Ｍｅｒｖｌｅｔのユーザ認識性能を特徴付けるための少なくとも１つの性能属性を含んでいる。アプリケーション環境は、Ｍｅｒｖｌｅｔに関連付けられたＭｅｒｖｌｅｔエンジンを更に備えている。Ｍｅｒｖｌｅｔエンジンは、アプリケーション属性に基づいてローカルノードとサーバノードとの間でＭｅｒｖｌｅｔの実行を与えるようになっている命令の第１のセットを有するポリシーモジュールを含んでいる。

Description

本発明は、一般に、モバイルアプリケーションのための実行環境に関する。特に、本発明は、複数の低レベルの転送プロトコルに適合するメッセージングシステムを使用して異種のモバイル通信ネットワークにわたって動的ウェブページを形成することができるモバイルアプリケーションをロードバランシングすることにより、アプリケーションのユーザに対する応答性能を最適化することができるモバイルアプリケーションのための実行環境に関する。

モバイル計算およびネットワーク接続の必要性は、今日、コンピュータデバイスの発展を後押しする主要な原動力のうちの１つである。デスクトップパーソナルコンピュータ（ＰＣ）は、携帯型のノートパソコンへと変化してきた。さらに最近、携帯デジタル端末（ＰＤＡ）、携帯電話、インテリジェントポケベルを含む様々な携帯型の手持ち式家庭用電化製品および内蔵デバイスが、十分な計算能力を獲得してきた。現在、ネットワーク接続性は、有線ＬＡＮまたは無線ＬＡＮ、携帯電話、Ｂｌｕｅｔｏｏｔｈ、８０２．１１ｂ（Ｗｉ−Ｆｉ）無線電信、汎用パケット無線サービス（ＧＰＲＳ）携帯電話ネットワーク、等の様々な通信ネットワークによって、上記のコンシューマー向けデバイスがデータ通信の形式で互いに交信し且つ従来のサーバコンピュータと交信し始めたことに伴って、急速に、当該コンシューマー向けデバイスの一体部分になってきている。

人々が情報を共有し且つ個人環境および職場環境を変化させている途中で、モバイルコンピュータデバイスの発展が重大な影響力を持ってきている。従来は、ＰＣが机上に固定されて簡単に移動できなかったため、適当なソフトウェアを有するＰＣが設置されている場所でだけデータを管理して処理することができた。しかしながら、今日、モバイルコンピュータデバイスのユーザは、これらのデバイスの移動性を十分に利用して、自分の都合に合わせて離れた場所から情報にアクセスして当該情報を共有することができる。コンピュータおよびモバイルデバイスのネットワークにわたって情報を共有する高い度合いで予期される有力な方法は、動的に形成されたコンテンツを表示するためのウェブインタフェースである。

しかしながら、モバイルデバイスは、アプリケーション開発者にとって幾つかの課題を提示する。例えば、モバイルデバイスは、一般に、従来のコンピュータよりもハードウェアリソースが限られている。また、モバイルデバイスは、計算能力、メモリサイズ、表示能力、データ入力手段等における違いを含む幅広く変化するハードウェアコンフィギュレーションを有する傾向がある。また、移動通信ネットワークは、ネットワーク帯域幅およびネットワーク利用可能性が限られている。その結果、モバイルデバイスは、ネットワークに接続され、断続的に接続され、あるいは、ネットワークから切断され得る。

第１世代のモバイルデバイスは、一般に、要求だけのデバイス、すなわち、処理能力が高く計算資源も豊富なサーバコンピュータに対してサービスおよび情報を要求するだけのデバイスであった。サーバは、Ｊａｖａ２エンタープライズエディション（Ｊ２ＥＥ）プラットフォーム等の標準的なソフトウェアアーキテクチャを使用していた。サーバプラットフォームは、サーバで実行する論理命令を小型軽量のクライアントアプリケーションが呼び出すことを許容するプログラミングモデルを規定し且つサポートすることができた。

今日、ＰｏｃｋｅｔＰＣおよびＪａｖａ２プラットフォームマイクロエディション（Ｊ２ＭＥ）等のモバイルコンピュータデバイス向けのより強力なコンピューティングプラットフォームの出現で、モバイルデバイスは、情報を受け入れて処理する能力、および、より複雑な双方向トランザクションに関与する能力を増した。モバイルアプリケーションを実行するためのポピュラーなプラットフォームは、Ｊａｖａプラットフォームである。このプラットフォームにより、同じＪａｖａアプリケーションは、オペレーティングシステムやハードウェアの互換性が無くても、様々な種類のコンピュータデバイスにて動作させることができる。Ｊａｖａはプログラミング言語であり、Ｊａｖａプログラムは、その後にＪａｖａバーチャルマシンにより動作（実行）のために解釈される機種に依存しないバイトコードにコンパイルされる。Ｊａｖａプログラムは、機種に依存しないため、当該プログラムを機種毎にポーティングする必要が無く、様々なハードウェアプラットフォームで動作（実行）する。

しかしながら、一般に、従来のモバイルアプリケーションプラットフォームは、依然として、モバイルデバイスおよびサーバに利用可能なリソースを知的に活用してモバイルコンピューティング環境の制限からモバイルアプリケーションを保護するということはできていない。例えば、既知のプラットフォームは、モバイルアプリケーションを十分にロードバランシングして、ネットワーク負荷およびネットワーク内のデバイスの負荷に伴って変化するそのユーザに対する応答性能を最適化することができない。また、これらのプラットフォームは、異種の移動通信ネットワークにわたっての適合性のための複数の低レベル転送プロトコルをサポートするために必要なサービスを提供しない。更に、これらのプラットフォームは、システムの一時的な故障に対して十分にフォールトトレラントなモバイルコンピューティング環境を作り且つデバイスがネットワークから切断されてもサービスを提供し続けるための十分なメカニズムを提供しない。

したがって、モバイルデバイスのためのモバイルアプリケーションのための実行環境の領域においては、向上されたサービスを提供してより強力な機能性をもって双方向モバイルアプリケーションをサポートするより強力なアプリケーション環境の必要性が存在し続けている。

本発明の一態様においては、少なくとも１つのアクセスネットワークの一部を形成するモバイルアプリケーションのための実行環境が提供される。当該環境は、動的ウェブページを形成するための命令のセットを含むＭｅｒｖｌｅｔアプリケーションを備えている。このＭｅｒｖｌｅｔは、それぞれが前記アクセスネットワークに接続されるローカルノードまたはサーバノードで実行することができ、これにより、前記ローカルノードで実行しているクライアントアプリケーションからの要求に応じて、前記動的ウェブページを当該ローカルノードに表示する。また、前記環境は、前記Ｍｅｒｖｌｅｔに関連付けられた少なくとも１つのアプリケーション属性を備えている。前記アプリケーション属性は、前記Ｍｅｒｖｌｅｔのユーザに対する応答性能を特徴付けるための少なくとも１つの性能属性を含んでいる。前記環境は、前記Ｍｅｒｖｌｅｔに関連付けられたＭｅｒｖｌｅｔエンジンを更に備えている。前記Ｍｅｒｖｌｅｔエンジンは、前記アプリケーション属性に基づいて前記ローカルノード及びサーバノードの間で前記Ｍｅｒｖｌｅｔの実行を与えるようになっている命令の第１のセットを有するポリシーモジュールを含んでいる。

本発明の他の態様においては、Ｍｅｒｖｌｅｔアプリケーションを実行するための方法が提供される。前記Ｍｅｒｖｌｅｔは、少なくとも１つのアクセスネットワークの一部を形成するモバイルアプリケーションのための実行環境において動的ウェブページを形成する命令のセットを含んでいる。前記方法は、前記アクセスネットワークに接続されるローカルノードで実行するクライアントアプリケーションから前記Ｍｅｒｖｌｅｔアプリケーションのための要求を発することを含む。また、前記方法は、前記アクセスネットワークに接続されたローカルノードまたはサーバノードに記憶された前記Ｍｅｒｖｌｅｔを見つけることを含む。更に、前記方法は、前記Ｍｅｒｖｌｅｔが前記ローカルノードで見つけられる時、当該ローカルノードで前記Ｍｅｒｖｌｅｔを実行して当該ローカルノード上に動的ウェブページを表示することを含む。また、前記方法は、前記Ｍｅｒｖｌｅｔが前記サーバノードで見つけられる時、前記アプリケーション属性に基づいて、前記ローカルノードまたはサーバノードのどちらかを選択し前記Ｍｅｒｖｌｅｔの実行を指示すること、を含む。また、前記方法は、前記ローカルノード上での前記Ｍｅｒｖｌｅｔの実行を選択した場合、前記Ｍｅｒｖｌｅｔおよび前記アプリケーション属性を、前記サーバノードから前記ローカルノードへと移動させることを含む。更に、前記方法は、前記サーバノード上での前記Ｍｅｒｖｌｅｔの実行を選択した場合、前記Ｍｅｒｖｌｅｔを前記サーバノード上で実行して、前記ローカルノード上に前記動的ウェブページを表示することを含む。

本発明の更なる他の態様においては、少なくとも１つのアクセスネットワークの一部を形成するモバイルアプリケーションのための実行環境が提供される。前記環境は、前記アクセスネットワークに接続されるローカルノードに存在するクライアントアプリケーションからＭｅｒｖｌｅｔアプリケーションのための要求を発する手段を備えている。前記Ｍｅｒｖｌｅｔアプリケーションは、動的ウェブページを形成するようになっている。また、前記環境は、前記アクセスネットワークに接続されたローカルノードまたはサーバノードに記憶された前記Ｍｅｒｖｌｅｔを見つける手段を備えている。前記環境は、前記Ｍｅｒｖｌｅｔが前記ローカルノードで見つけられる時、前記ローカルノードで前記Ｍｅｒｖｌｅｔを実行して当該ローカルノード上に前記動的ウェブページを表示する手段を更に備えている。前記環境は、前記Ｍｅｒｖｌｅｔが前記サーバノードで見つけられる時、少なくとも１つのアプリケーション属性に基づいて、前記ローカルノードまたはサーバノードのどちらかを選択し前記Ｍｅｒｖｌｅｔの実行を指示する手段を更に備えている。前記アプリケーション属性は、前記Ｍｅｒｖｌｅｔのユーザに対する応答性能を特徴付けるための少なくとも１つの性能属性を含んでいる。また、前記環境は、前記ローカルノード上で前記Ｍｅｒｖｌｅｔの実行を選択した場合、前記Ｍｅｒｖｌｅｔを前記サーバノードから前記ローカルノードへと移動させる手段を備えている。前記環境は、前記サーバノード上で前記Ｍｅｒｖｌｅｔの実行を選択した場合、前記Ｍｅｒｖｌｅｔを前記サーバノード上で実行して前記ローカルノード上に前記動的ウェブページを表示する手段を更に備えている。

本発明の更に他の態様においては、デバイス間で通信するための少なくとも１つのアクセスネットワークに接続された複数のコンピュータデバイス間でアプリケーションをロードバランシングする方法が提供される。前記方法は、前記アクセスネットワークに接続されたサーバデバイス上に前記アプリケーションを記憶することを含んでいる。また、前記方法は、前記アプリケーションのユーザに対する応答性能を特徴付けるための少なくとも１つの性能属性を含む、前記アプリケーションに関連付けられたアプリケーション属性のセットを測定することを含んでいる。更に、前記方法は、前記アクセスネットワークに接続されたクライアントデバイスから、前記アプリケーションのための要求を発することを含んでいる。また、前記方法は、前記アプリケーション属性のセットに基づき、前記要求に応じて、前記クライアントデバイスまたはサーバデバイスのどちらかを選択し、その上での前記アプリケーションの実行を指示することを含んでいる。更に、前記方法は、前記アプリケーションの実行が指示された場合、前記クライアントデバイスまたはサーバデバイスで前記アプリケーションを実行することを含んでいる。

本発明の更に他の態様においては、少なくとも１つのネットワークの一部を形成するアプリケーションをロードバランシングするためのシステムが提供される。前記システムは、前記ネットワークに接続され、前記アプリケーションのための様々な実行環境を与える、複数の実行モジュールを備えている。また、前記システムは、前記ネットワークに接続され、前記アプリケーションに関連付けられたアプリケーション属性のセットを測定する、少なくとも１つの収集モジュールを備えている。前記アプリケーション属性は、前記アプリケーションのユーザに対する応答性能を特徴付けるための少なくとも１つの性能属性を含んでいる。前記システムは、前記ネットワークに接続され、前記アプリケーション属性に基づいて前記アプリケーションの実行環境を決定するための少なくとも１つのポリシーを満たす第１の実行モジュールを決定する、少なくとも１つのポリシーモジュールを更に備えている。また、前記システムは、前記第１の実行モジュール上に前記アプリケーションを割り当てる少なくとも１つのプログラム割り当てモジュールを備えている。

本発明の更に他の態様においては、デバイス間で通信するための少なくとも１つのアクセスネットワークに接続された複数のコンピュータデバイス間でアプリケーションをロードバランシングするシステムが提供される。前記システムは、前記アクセスネットワークに接続されたサーバデバイス上に前記アプリケーションを記憶する手段を備えている。また、前記システムは、前記アプリケーションのユーザに対する応答性能を特徴付けるための少なくとも１つの性能属性を含むアプリケーション属性のセットを測定する手段を備えている。更に、前記システムは、前記アクセスネットワークに接続されたクライアントデバイスから前記アプリケーションのための要求を発する手段を有している。また、前記システムは、前記アプリケーション属性のセットに基づき、前記要求に応じて、前記サーバデバイスおよびクライアントデバイスの一方上での前記アプリケーションの実行を指示する手段を備えている。更に、前記システムは、前記アプリケーションの実行を指示することに応じて、クライアントデバイスおよびサーバデバイスの前記一方上で前記アプリケーションを実行する手段を有している。

本発明の更に他の態様においては、フォールトトレランスシステムが提供される。このフォールトトレランスシステムは、ネットワークに接続された複数のモジュール間で通信するための構成可能な信頼できるメッセージングシステムを備えている。前記信頼できるメッセージングシステムは、メッセージを生成し且つ前記ネットワークを介して前記メッセージに対する応答を受けるようになっているクライアントモジュールを含んでいる。更に、前記信頼できるメッセージングシステムは、前記ネットワークを介して前記メッセージを受け且つ前記応答を生成するようになっているサーバモジュールを含んでいる。また、前記信頼できるメッセージングシステムは、クライアントロギング信号に応じて、前記クライアントモジュール上で選択的に実行するクライアントロギングエージェントを有している。前記クライアントロギングエージェントは、前記メッセージおよび前記応答を記憶し、前記応答が受けられるまで前記メッセージを前記サーバモジュールに送信するようになっている。また、前記信頼できるメッセージングシステムは、サーバロギング信号に応じて、前記サーバモジュール上で選択的に実行するサーバロギングエージェントを有している。前記サーバロギングエージェントは、前記メッセージおよび前記応答を記憶し、前記応答を前記クライアントモジュールに送信するようになっている。更に、前記信頼できるメッセージングシステムは、前記クライアントモジュールおよびサーバモジュールのうちの少なくとも一方に関連付けられるコンフィギュレーションエージェントを有している。前記コンフィギュレーションエージェントは、前記クライアントロギング信号および前記サーバロギング信号を生成するようになっている。

本発明の更に他の態様においては、分散コンピュータシステムをフォールトトレラントにするための方法が提供される。この方法は、ネットワークに接続された複数のコンピュータデバイス間で複数のメッセージを送ることを含んでいる。前記複数のコンピュータデバイスは、要求メッセージを生成し且つ応答メッセージを受けるようになっている第１のコンピュータデバイスと、前記要求メッセージを受け且つ当該要求メッセージに応じて前記応答メッセージを生成するようになっている第２のコンピュータデバイスと、を含んでいる。また、前記方法は、前記第１のコンピュータデバイス上に前記要求メッセージを選択的に記憶することを含んでいる。また、前記方法は、前記第２のコンピュータデバイス上に前記要求メッセージを選択的に記憶することを更に含んでいる。また、前記方法は、前記第２のコンピュータデバイス上に前記応答メッセージを選択的に記憶することを含んでいる。また、前記方法は、前記第１のコンピュータデバイス上に前記応答メッセージを選択的に記憶することを含んでいる。

本発明の更に他の態様においては、フォールトトレラントな分散コンピュータシステムが提供される。前記システムは、ネットワークに接続された複数のコンピュータデバイス間で複数のメッセージを送る手段を備えている。前記複数のコンピュータデバイスは、要求メッセージを生成し且つ応答メッセージを受けるようになっている第１のコンピュータデバイスと、前記要求メッセージを受け且つ前記要求メッセージに応じて前記応答メッセージを生成するようになっている第２のコンピュータデバイスと、を含んでいる。また、前記システムは、前記第１のコンピュータデバイス上に前記要求メッセージを選択的に記憶する手段を備えている。また、前記システムは、前記第２のコンピュータデバイス上に前記要求メッセージを選択的に記憶する手段を更に備えている。また、前記システムは、前記第２のコンピュータデバイス上に前記応答メッセージを選択的に記憶する手段を備えている。また、前記システムは、前記第１のコンピュータデバイス上に前記応答メッセージを選択的に記憶する手段を備えている。

本発明の更に他の態様においては、分散コンピュータシステムをフォールトトレラントにするための方法が提供される。この方法は、ネットワークに接続されたクライアントモジュールからメッセージを生成し、当該クライアントモジュール上に前記メッセージを選択的に記憶し、前記ネットワークに接続されたサーバモジュールに前記メッセージを送ることを含んでいる。更に前記方法は、前記メッセージを受けるとともに、前記サーバモジュール上に前記メッセージを選択的に記憶することを含んでいる。また、前記方法は、前記サーバモジュールからの先の応答を解放することを含んでいる。また、前記方法は、前記サーバモジュールにより、前記メッセージに対する応答を生成し、当該サーバモジュール上に前記応答を選択的に記憶することを含んでいる。更に、前記方法は、前記応答を前記クライアントモジュールに送り、前記サーバモジュールから前記メッセージを除去することを含んでいる。また、前記方法は、前記応答を受けるとともに前記クライアントモジュール上に前記応答を選択的に記憶し、前記クライアントモジュールから前記メッセージを除去し、前記クライアントモジュールから前記応答を解放することを含んでいる。

この明細書中に組み込まれ且つこの明細書の一部を構成する添付図面は、本発明の実施形態を示すとともに、明細書本文と共に、本発明の利点および原理を説明するのに役立つ。

図１は、本発明に係るＭｅｒｖｌｅｔアプリケーション環境のシステムコンポーネントを示すブロック図である。

図２は、図１のＭｅｒｖｌｅｔアプリケーション環境の動作の詳細を示すフローチャートである。

図３は、図１のＭｅｒｖｌｅｔアプリケーション環境のためのモバイル通信ネットワークの高レベルビューを示すブロック図である。

図４は、図１のＭｅｒｖｌｅｔアプリケーション環境におけるＭｅｒｖｌｅｔアプリケーションの構造およびその属性を示すブロック図である。

図５は、図１のＭｅｒｖｌｅｔアプリケーション環境におけるＭｅｒｖｌｅｔアプリケーションのライフサイクルを示すブロック図である。

図６は、図１のＭｅｒｖｌｅｔアプリケーション環境におけるＭｅｒｖｌｅｔエンジンの全体構造およびステップを示すブロック図である。

図７は、図１のＭｅｒｖｌｅｔアプリケーション環境におけるユーザインタフェースイベントのためのタイムラインを示すブロック図である。

図８は、図１のＭｅｒｖｌｅｔアプリケーション環境における性能属性およびシステム属性を要約する表である。

図９は、図１のＭｅｒｖｌｅｔアプリケーション環境におけるＭｅｒｖｌｅｔをロードバランシングするためのアプリケーション提供最適化の詳細を示すフローチャートである。

図１０は、図１のＭｅｒｖｌｅｔアプリケーション環境におけるＭｅｒｖｌｅｔをロードバランシングするためのネットワーク切換え最適化の詳細を示すフローチャートである。

図１１は、図１のＭｅｒｖｌｅｔアプリケーション環境におけるＭｅｒｖｌｅｔエンジンと信頼できるメッセージシステムとの間のインタフェースを示すブロック図である。

図１２は、図１１の信頼できるメッセージングシステムにおけるメッセージの構造を示す図である。

図１３は、図１１の信頼できるメッセージングシステムの動作の詳細を示すチャートである。

図１４は、図１１の信頼できるメッセージングシステムにおける様々なコンフィギュレーション及び対応する性能コストを示す表である。

添付図面を参照して、本発明の実施について詳細に説明する。以下、Ｊａｖａベースのソフトウェアシステムを使用して、本発明の好ましい実施形態を説明する。しかしながら、容易に分かるように、Ｊａｖａベースのソフトウェアシステムは、本発明を実施するための唯一の手段ではなく、本発明は、他のタイプのソフトウェアシステム下で実施されても良い。

（１．Ｍｅｒｖｌｅｔアプリケーション環境の概要）
図１に示される本発明に係るアプリケーション環境において、アプリケーション開発者は、「Ｍｅｒｖｌｅｔ（マーブレット）」として知られるモバイルアプリケーションを形成する。Ｍｅｒｖｌｅｔ１０は、モバイルコンピュータデバイスのための動的ウェブページを形成することができる実行可能アプリケーションプログラムである。Ｍｅｒｖｌｅｔ１０は、解釈されていないコードおよびローカルスタティックデータを含んでいる。Ｍｅｒｖｌｅｔの解釈されていないコードは、ウェブページを形成するためのユーザインタフェースロジック、および、ウェブページのためのダイナミックコンテンツを生成するアプリケーションロジックの両方を含んでいても良い。また、Ｍｅｒｖｌｅｔ１０は、ＡＳＣＩＩテキストファイル等の外部データファイルにアクセスすることもできる。更に、Ｍｅｒｖｌｅｔ１０は、従来のアプリケーションプログラムとは異なり、それに関連付けられるアプリケーション属性の固有のセットを有している。これらの属性により、通信ネットワークにわたってＭｅｒｖｌｅｔ１０を動的にロードバランシングすることができる。また、Ｍｅｒｖｌｅｔ１０はセキュリティ属性のセットを有しており、これらのセキュリティ属性により、Ｍｅｒｖｌｅｔ１０は、ネットワーク内の様々なデバイス上において、それ自身のセキュリティコンテキスト内で実行する（動作する）ことができる。したがって、Ｍｅｒｖｌｅｔ１０は、再配置可能なダイナミックウェブドキュメントの特徴を有している。

Ｍｅｒｖｌｅｔ１０は、Ｍｅｒｖｌｅｔランタイムエンジン１２の制御下で実行される。Ｍｅｒｖｌｅｔランタイムエンジン１２は、カスタマイズドタグライブラリ１４と、システムサービス１６のための一組のコンポーネントと、コアインタープリタ１８と、を有している。Ｍｅｒｖｌｅｔエンジン１２は、自己修復可能であるように構成され、システム故障時に実行していた一組のＭｅｒｖｌｅｔの実行を再起動できるようになっていても良い。

Ｍｅｒｖｌｅｔエンジン１２は、ネットワークにわたってコンテンツをＭｅｒｖｌｅｔから遠隔クライアントデバイスへと配信するため、メッセージに基づく通信システム２０を使用する。また、メッセージングシステム２０は、ロードバランシングのため、１つのネットワークにわたってＭｅｒｖｌｅｔ１０を送ることもできる。例えば、メッセージングシステム２０は、ポイント・ツー・ポイント非同期メッセージングを使用して作動し、要求メッセージおよび応答メッセージを通信しても良い。また、Ｍｅｒｖｌｅｔアプリケーション環境は、一時的なネットワークおよびデバイスの故障を修復することができるとともに、そのエンドポイントへのメッセージの配信を保証することができる、信頼できるメッセージングシステム２０をサポートする。この信頼できるメッセージングシステム２０は、アプリケーション開発者、システムアドミニストレータまたはユーザが様々な修復オプションのためのメッセージをバッファリングするデバイスを選択できるように、構成可能であっても良い。しかしながら、当業者であれば容易に分かるように、ＨＴＴＰ、ＳＭＴＰあるいは同様の転送プロトコルによって転送される遠隔手続呼び出しを使用するシステムを含む他のタイプの通信システムが、Ｍｅｒｖｌｅｔアプリケーション環境で使用されることができる。

また、Ｍｅｒｖｌｅｔエンジン１２は、ネットワーク切断を隠すために、デバイス上にＭｅｒｖｌｅｔをローカルにキャッシュするための構成可能キャッシュマネージャ２２とインタフェースをとる。デバイスキャッシュがプログラム化できる場合には、Ｍｅｒｖｌｅｔ固有のキャッシュ法が、デバイスに対してダウンロードされ得る。構成可能キャッシュマネージャ２２のキャッシュ機構により、キャッシュマネージャは、そのキャッシュ管理法を動的に変化させることができる。

次に、図２および図３を参照すると、作動時、通信ネットワークの一部を形成するモバイルデバイスまたはユーザクライアントデバイス（ＵＣＤ）３０は、ステップ１０で、Ｍｅｒｖｌｅｔ１０のための要求を生成する。ＵＣＤ３０は、Ｍｅｒｖｌｅｔエンジン１２、メッセージングシステム２０、キャッシュマネージャ２２を実行する。また、ＵＣＤ３０は、マイクロソフト社のポケットインターネットエクスプローラおよびインターネットエクスプローラや、ネットスケープ通信社のネットスケープナビゲータ等のウェブブラウザを使用して、Ｍｅｒｖｌｅｔ１０からの情報を表示することができる。Ｍｅｒｖｌｅｔ１０は遠隔的に実行しても良く、あるいは、要求しているＵＣＤ３０が要求されているＭｅｒｖｌｅｔ１０をローカルに実行することができても良い。ＵＣＤ３０は、ユニフォームリソース識別子（「ＵＲＩ」）を使用してＭｅｒｖｌｅｔ１０のための要求を生成する。ＵＲＩは、インターネットアクセスプロトコルを使用してＭｅｒｖｌｅｔにアクセスできるように、ネットワーク上の登録されたネーム空間内にＭｅｒｖｌｅｔ１０のネームおよびアドレスをエンコードする。

要求されたＭｅｒｖｌｅｔ１０は、要求しているＵＣＤ３０、または、他のＵＣＤ３４またはコンピュータサーバクラスのデバイス３６であっても良い、Ｍｅｒｖｌｅｔ（「プライマリサーバ」）３２を実行することができる十分なメモリおよび処理能力を有するネットワークの遠隔ノード上、にローカルに記憶され得る。ステップ１２において、要求しているＵＣＤ３０は、サンマイクロシステムズのＪＩＮＩ等の既存のリソースディスカバリ技術を使用して、プライマリサーバ３２を見つけることができる。プライマリサーバ３２は、Ｍｅｒｖｌｅｔ１０を実行できるか、あるいは、Ｍｅｒｖｌｅｔ１０を実行するためにネットワーク上で図示しない２次サーバを見つけることができなければならない。後者の場合、プライマリサーバ３２は、Ｍｅｒｖｌｅｔ１０を２次サーバに送るとともに、要求しているＵＣＤ３０からの要求を転送しなければならない。ＵＣＤ３０およびプライマリサーバ３２は、１または複数のアクセスネットワーク３８を介して、互いに通信を行なっても良い。

ステップ１４において、要求しているＵＣＤ３０は、最初に、デバイス上のローカルキャッシュ内にＭｅｒｖｌｅｔ１０が記憶されているかどうかを確かめるためにチェックする。Ｍｅｒｖｌｅｔ１０が記憶されている場合、そこでＭｅｒｖｌｅｔ１０が実行される。これがステップ１６である。一方、Ｍｅｒｖｌｅｔ１０が記憶されていない場合、ステップ１８において、要求しているＵＣＤ３０は、プライマリサーバ３２と通信を行なって、要求されたＭｅｒｖｌｅｔ１０への「アクセス」を得る。その後、ステップ２０において、プライマリサーバ３２は、Ｍｅｒｖｌｅｔ１０上でロードバランシングポリシーを呼び出し、Ｍｅｒｖｌｅｔ１０のユーザに対する応答性能を最適化する。例えば、プライマリサーバ３２は、Ｍｅｒｖｌｅｔ１０をローカルに実行することを決定しても良く（ステップ２２）、あるいは、要求しているＵＣＤ３０にＭｅｒｖｌｅｔ１０を再配置することを決定しても良い（ステップ２４）。場合によって、ＵＣＤ３０は、そのサイトでＭｅｒｖｌｅｔ１０を実行するための明示的な要求を行なっても良い。しかしながら、プライマリサーバ３２は、その要求を無視することができる。ステップ２２においてＭｅｒｖｌｅｔ１０がプライマリサーバ３２上で実行される場合、その結果は、Ｍｅｒｖｌｅｔアプリケーション環境のメッセージングシステム２０を介して、ＵＣＤ３０に対して送り戻される。

プライマリサーバ３２は、１）ＵＣＤおよびサーバノードにおけるメモリおよび処理能力、２）２つのノードの各々におけるロードと、ネットワークの帯域幅および待ち時間、及び、３）Ｍｅｒｖｌｅｔの性能に関する一組の属性、を含む幾つかの属性に基づいて、Ｍｅｒｖｌｅｔ１０をローカルに実行するか或いは要求しているＵＣＤ３０上で実行するかを決定することができる。例えば、Ｍｅｒｖｌｅｔがユーザインタラクティブ性が高い例えばゲームアプリケーションであり、ＵＣＤが当該Ｍｅｒｖｌｅｔを実行するための十分なハードウェアリソースを有している場合、サーバは、ＵＣＤ上でＭｅｒｖｌｅｔを実行することを決定しても良い。一方、Ｍｅｒｖｌｅｔがデータ処理であり、あるいは、インタラクティブではなくコンピュータを駆使した例えば個人的アプリケーションである場合、サーバは、それ自身でＭｅｒｖｌｅｔを実行することを決定しても良い。しかしながら、当業者であればはっきりと分かるように、システムが監視するパラメータに基づいて、他のロードバランシング決定も考えられる。例えば、プライマリサーバ３２およびＵＣＤ３０は、ネットワーク切換ポリシーを実行して、デバイス間でアクセスネットワーク３８を切換え、通信を向上させることができる。

ここで、前述した高レベル実行モデルをサポートするシステムの実現について説明する。特に、１）Ｍｅｒｖｌｅｔのためのアプリケーションモデル、２）Ｍｅｒｖｌｅｔランタイムエンジン、３）ネットワークにわたるＭｅｒｖｌｅｔのユーザに対する応答性能を最適化するためのロードバランシングスキーム、４）回復可能なＭｅｒｖｌｅｔエンジンおよび信頼できるメッセージングシステムのための構成可能フォールト・トレランス・スキーム、５）構成可能切断モード操作スキーム、を含むＭｅｒｖｌｅｔアプリケーション環境の幾つかの重要な特性について説明する。

（２．Ｍｅｒｖｌｅｔアプリケーション）
Ｍｅｒｖｌｅｔ１０は、ウェブページのためのユーザインタフェースを規定して、動的に生成されたコンテンツをモバイルデバイス上に表示する。Ｍｅｒｖｌｅｔ１０の構造が図４に示されている。特に、Ｍｅｒｖｌｅｔ１０は、マークアップ言語命令等のプラットフォームインディペンデントなユーザインタフェースロジック４０を使用して、フォーマッティングを制御するとともに、ウェブページを表示する。また、Ｍｅｒｖｌｅｔは、ウェブブラウザからの要求および応答を扱うこともできる。例えば、Ｍｅｒｖｌｅｔ１０は、静的なＨＴＭＬ、ＤＨＴＭＬ、ＸＨＴＭＬ、ＸＭＬおよびウェブブラウザによって解釈できる同様のフォーマットタグを使用して、ウェブページをサポートすることができる。

また、Ｍｅｒｖｌｅｔ１０は、ＸＭＬ状タグを使用して、ウェブページのための動的なコンテンツを生成するアプリケーションロジック４２をカプセル化する。アプリケーションロジック４２は、それ自体、ウェブページがこれらのＸＭＬ状タグを使用してアクセスするＪａｖａＢｅａｎｓまたはカスタマイズドＭｅｒｖｌｅｔタグライブラリ１４等のサーバベースのリソース内に存在することができる。Ｍｅｒｖｌｅｔタグライブラリ１４は、特定のデバイスのアプリケーション環境に最初からあっても良く、あるいは、ロードバランシング中にＭｅｒｖｌｅｔが再配置される時にＭｅｒｖｌｅｔ１０と共に移動しても良い。したがって、Ｍｅｒｖｌｅｔ１０は、動的なウェブページのユーザインタフェースを、プラットフォームインディペンデントである再利用可能なコンポーネントベースの設計のためのコンテンツ形成から分離する。

また、Ｍｅｒｖｌｅｔ１０は、メッセージングシステム２０を介してネットワーク接続を行なうことができるとともに、ローカルデータファイルにアクセスすることができる。したがって、Ｍｅｒｖｌｅｔのためのアプリケーションモデルは、ユーザインタフェースロジック４０と、アプリケーションロジック４２と、ファイルアクセス４６と、ネットワークアクセス４４と、を含んでいる。

また、性能属性５２およびシステム属性５４を含む新規なアプリケーション属性のセット５０は、Ｍｅｒｖｌｅｔをネットワーク内で動的にロードバランシングするためにＭｅｒｖｌｅｔ１０に関連付けられる。例えば、Ｍｅｒｖｌｅｔ１０は、後述するように、そのアプリケーション属性５０に基づき、モバイル通信ネットワークにわたって、ロードタイムおよびランタイムで動的に再配置されても良い。

また、Ｍｅｒｖｌｅｔ１０は、関連付けられたセキュリティ属性５６のセットに基づいて、それ自身のセキュリティコンテキスト内で実行することもできる。格納モデルは、何のリソースがユーザに利用可能であるかを決める。Ｊａｖａ２セキュリティモデルの変形を使用し、１９９７年のＩＥＥＥソフトウェアにおけるＩｓｌａｍらによる「インターネットコンテンツを使用するためのフレキシブルセキュリティモデル」に記載されているようなポリシーメカニズムを用いて、クラスローダーおよび関連クラスが変更される。なお、「インターネットコンテンツを使用するためのフレキシブルセキュリティモデル」の内容は、これを参照することにより、保護ドメインがＵＣＤによって設定されても良いという点を除き、本願に組み込まれる。クラスローダーは、Ｍｅｒｖｌｅｔを実行するためのセキュリティコンテンツを形成する。Ｍｅｒｖｌｅｔ１０は、それが実行される前に、サイン（署名）されるとともに、デバイスによって確認される。セキュリティ属性５６を使用して構成されたポリシーモジュールは、誰を信用し且つどの操作が許容されるかに関するポリシーを実行する。Ｍｅｒｖｌｅｔエンジン１２は、Ｍｅｒｖｌｅｔ１０による任意のアクセスをランタイムで監視するとともに、Ｍｅｒｖｌｅｔがそのセキュリティコンテキストから外れて実行しようとする場合には、当該Ｍｅｒｖｌｅｔを抹消する。Ｍｅｒｖｌｅｔ１０のためのセキュリティコンテキストは、Ｍｅｒｖｌｅｔ１０と共にセキュリティ属性５６を再配置することにより、移動させることができるとともに、ネットワーク内の様々なデバイス上で再現することができる。

前述した特徴は、Ｍｅｒｖｌｅｔアプリケーションモデルに固有のものであり、動的なウェブページを形成するための他のタイプの技術を逃れる。Ｍｅｒｖｌｅｔ１０は、ＵＲＬ ｈｔｔｐ：／／ｊａｖａ．ｓｕｎ．ｃｏｍ／ｐｒｏｄｕｃｔｓ／ｊｓｐ／ｗｈｉｔｅｐａｐｅｒ．ｈｔｍｌによって利用可能であり且つこれを参照することによってその内容が本願に組み込まれるサンマイクロシステムズの「Ｊａｖａサーバページ（登録商標）−ホワイトペーパ」に記載されたＪａｖａサーバページ（「ＪＳＰ」）モデルから得られるＪａｖａアプリケーションコンポーネントとして実行され得る。ＪａｖａベースのＭｅｒｖｌｅｔの実行により、ＪＮＤＩ、ＪＭＳ、ＪＴＡ、ＪＡＦ、Ｊａｖａメール、ＲＭＩ、ＪＤＢＣ及びＩＩＯＰクラスにはアクセスできないかもしれないが、Ｊａｖａクラスによって使用されるリソースファイルおよびＪ２ＭＥ ＣＤＣ環境にはアクセスすることができる。また、ＪＳＰから得られるＭｅｒｖｌｅｔは、ＡＷＴクラスまたはＳＷＩＮＧクラスへのアクセスを有しないかもしれない。また、Ｍｅｒｖｌｅｔ１０のＪ２ＭＥベースの実行は、Ｍｅｒｖｌｅｔにより処理されるウェブページ内でスクリプトを許可しない。これらの制約は、Ｍｅｒｖｌｅｔアプリケーション環境を実現して限られたハードウェアリソースを有する小型軽量クライアントデバイスにおけるＭｅｒｖｌｅｔの実行を最適化するネットワークの全てのノードにおいて存在するかもしれない。したがって、そのようなＭｅｒｖｌｅｔの実行は、プラットフォームインディペンデントであり、小型軽量クライアントの要求を満たしつつ、既存のＪａｖａプラットフォーム技術を利用することができる。

本発明に係るＭｅｒｖｌｅｔアプリケーション環境のＪ２ＭＥベースの実行は、ＪＳＰアプリケーションプログラミングインタフェース（「ＡＰＩｓ」）への変更に加えて、Ｍｅｒｖｌｅｔを実行する時期および場所を決定するなど、従来のＪＳＰおよびＳｅｒｖｌｅｔ実行のセマンティクスを変更する。以下、この実行について詳細に説明する。

（３．Ｍｅｒｖｌｅｔエンジン）
図１に示されるように、Ｍｅｒｖｌｅｔ１０は、Ｍｅｒｖｌｅｔエンジン１２でコンパイルされて実行される。エンジン１２は、ウェブブラウザ等のクライアントアプリケーションからＭｅｒｖｌｅｔ１０への要求を処理することができるとともに、Ｍｅｒｖｌｅｔ１０からクライアントブラウザへの応答を生成することができる。特に、Ｍｅｒｖｌｅｔエンジン１２は、アプリケーションロジック４２のためのＭｅｒｖｌｅｔタグを解釈する。その後、Ｍｅｒｖｌｅｔエンジンは、リソースまたはタグライブラリ１４にアクセスして、Ｍｅｒｖｌｅｔ１０のユーザインタフェースロジック４０によって規定されるウェブページのための動的なコンテンツを生成する。タグライブラリ１４は、デバイスに最初からあっても良く、あるいは、Ｍｅｒｖｌｅｔ１０と共に再配置可能であっても良い。その後、エンジン１２は、その結果を、ＨＴＭＬまたはＸＭＬの形態で、要求しているウェブブラウザに送り戻す。アプリケーションロジック４２のための任意の静的なフォーマットタグは、要求しているウェブブラウザに対して直接に送られる。

Ｍｅｒｖｌｅｔエンジン１２は、小型軽量クライアントデバイスにおけるＪ２ＭＥ ＣＤＣプラットフォーム上およびサーバクラスデバイスにおけるＪ２ＥＥプラットフォーム上で実行することができる。Ｊ２ＭＥプラットフォームは、従来、３２ビットＣＰＵおよび少なくとも２メガバイトのメモリを必要とする。Ｊ２ＥＥプラットフォームは、従来、少なくとも１つのインテルペンティアムＩＩＩクラスプロセッサと、１２８メガバイトのＲＡＭメモリと、３００メガバイトの固定記憶域とを必要とする。ランタイムで最大６メガバイトを費やすＭｅｒｖｌｅｔエンジン１２をサポートする、本発明に係るＭｅｒｖｌｅｔアプリケーション環境のための１つの考えられる構成は、少なくとも３２ビットＣＰＵと、１０メガバイトのＲＡＭメモリと、４０メガバイトの固定記憶域と、を含む。しかしながら、Ｍｅｒｖｌｅｔアプリケーション環境におけるこれらの値は、単なる一例であり、制限的なものでないことは言うまでもない。Ｊ２ＥＥのコンテクストにおいては、Ｍｅｒｖｌｅｔエンジン１２は、Ｊ２ＥＥにおけるＳｅｒｖｌｅｔエンジンモデルとウェブコンテナとを交換することができる。したがって、Ｍｅｒｖｌｅｔエンジン１２により、Ｍｅｒｖｌｅｔ１０は、Ｊａｖａバーチャルマシン（ＪＶＭ）、パーソナルＪａｖａバーチャルマシン（ＰＪＶＭ）、あるいは、他のタイプのバーチャルマシン（ＶＭ）にアクセスすることができる。デバイスのネイティブのオペレーティングシステムの上で実行するＶＭは、Ｊａｖａバイトコードを受け且つネイティブのオペレーティングシステムによって実行できる形式に当該Ｊａｖａバイトコードを動的に変換することにより当該Ｊａｖａバイトコードを解釈する抽象的な計算機のように、作用する。

Ｍｅｒｖｌｅｔエンジン１２は、図５に示されるように、アプリケーションプログラミングインタフェース（ＡＰＩｓ）のセットにより、Ｍｅｒｖｌｅｔ１０のライフサイクルを管理する。Ｍｅｒｖｌｅｔエンジンが行なうこのアクションは、ステップ３０において、クライアントアプリケーションによって要求されるＭｅｒｖｌｅｔをネットワーク上に見つけることを含んでいる。要求されたＭｅｒｖｌｅｔは、要求しているクライアントまたはプライマリサーバのいずれかに記憶されても良い。Ｍｅｒｖｌｅｔが見つけられた後、Ｍｅｒｖｌｅｔエンジンは、Ｍｅｒｖｌｅｔのインスタンス（例）を形成するとともに、そのインスタンスをエンジンのメモリにロードして、ステップ３２においてそのインスタンスを初期化する。初期化すると直ちに、Ｍｅｒｖｌｅｔは情報を受け取れる状態になり、Ｍｅｒｖｌｅｔエンジン１２は、ステップ３４において、要求を送ることができるとともに、Ｍｅｒｖｌｅｔからの応答を処理することができる。Ｍｅｒｖｌｅｔがもはや不要になると、ステップ３６において、Ｍｅｒｖｌｅｔエンジンは、Ｍｅｒｖｌｅｔを破壊（デストロイ）するとともに、その存在をエンジンメモリから抹消し、Ｍｅｒｖｌｅｔに関連付けられた固定記憶域内のあらゆるデータを除去する。

ステップ３８において、Ｍｅｒｖｌｅｔエンジンは、クラッシュ後、Ｍｅｒｖｌｅｔを再起動することができる。また、Ｍｅｒｖｌｅｔエンジンは、ステップ４０において、その状態を保存する必要があることを常にＭｅｒｖｌｅｔに知らせても良い。以下、これらのアクションを使用してクラッシュから回復できるＭｅｒｖｌｅｔエンジンの能力について、Ｍｅｒｖｌｅｔアプリケーション環境におけるフォールト・トレランスと共に、詳細に説明する。

以下は、Ｊ２ＭＥプラットフォームに基づいてＭｅｒｖｌｅｔをＭｅｒｖｌｅｔエンジン上で実行するためのＡＰＩの典型的なセットである。ＭｅｒｖｌｅｔＡＰＩは、Ｊａｖａ Ｓｅｒｖｌｅｔのためのインタフェースにおける標準的なＪａｖａクラスから得られる。Ｍｅｒｖｌｅｔの実行によって、「ｊａｖａｘ．ｓｅｒｖｌｅｔ」クラスの「ｊａｖａｘ．ｍｅｒｖｌｅｔ」サブクラスが形成される。

ＭｅｒｖｌｅｔＡＰＩの「ｊａｖａｘ．ｍｅｒｖｌｅｔ」の実行を考えると、１０個のクラスがある。１０個のクラスのうち、Ｓｅｒｖｌｅｔの実行によって不変のまま維持される５個のクラスを以下に記載する。

・ＳｅｒｖｌｅｔＥｘｃｅｐｔｉｏｎと同じＭｅｒｖｌｅｔＥｘｃｅｐｔｉｏｎ
・ＳｅｒｖｌｅｔＩｎｐｕｔＳｔｒｅａｍと同じＭｅｒｖｌｅｔＩｎｐｕｔＳｔｒｅａｍ
・ＳｅｒｖｌｅｔＯｕｔｐｕｔＳｔｒｅａｍと同じＭｅｒｖｌｅｔＯｕｔｐｕｔＳｔｒｅａｍ
・不変を維持するＲｅｑｕｅｓｔＤｉｓｐａｔｃｈｅｒ
・ＳｅｒｖｌｅｔＣｏｎｆｉｇと同じＭｅｒｖｌｅｔＣｏｎｆｉｇ

以下のように、修正されたセマンティクスを要求する５個のクラスもある。

・Ｍｅｒｖｌｅｔ
・ＭｅｒｖｌｅｔＣｏｎｔｅｘｔ
・ＭｅｒｖｌｅｔＲｅｑｕｅｓｔ
・ＭｅｒｖｌｅｔＲｅｓｐｏｎｓｅ
・ＳｉｎｇｌｅＴｈｒｅａｄＭｏｄｅｌ

クラス「Ｍｅｒｖｌｅｔ」は、３つの重要なメソッドを有している。すなわち、

ｐｕｂｌｉｃ ｖｏｉｄ Ｉｎｉｔ（）は、「ＭｅｒｖｌｅｔＥｘｃｅｐｔｉｏｎ」を投入し；
ｐｕｂｌｉｃ ｖｏｉｄ Ｓｅｒｖｉｃｅ（）は、「ＭｅｒｖｌｅｔＥｘｃｅｐｔｉｏｎ」を投入し；
ｐｕｂｌｉｃ ｖｏｉｄ Ｄｅｓｔｒｏｙ（）は、「ＭｅｒｖｌｅｔＥｘｃｅｐｔｉｏｎ」を投入する。

メソッド「Ｉｎｉｔ（）」は、Ｍｅｒｖｌｅｔを初期化するために、Ｍｅｒｖｌｅｔエンジンによって呼び出される。メソッド「Ｉｎｉｔ（）」は、Ｍｅｒｖｌｅｔが見つけられ且つクラスローダーがＭｅｒｖｌｅｔ上で呼び出された後に、呼び出されなければならない。メソッド「Ｉｎｉｔ（）」は、メソッド「Ｓｅｒｖｉｃｅ（）」への任意の呼び出しが許容される前に呼び出されなければならない。メソッド「Ｓｅｒｖｉｃｅ（）」は、Ｍｅｒｖｌｅｔエンジンが要求を送ってＭｅｒｖｌｅｔからの応答を処理することができるように、Ｍｅｒｖｌｅｔ上で呼び出される。Ｍｅｒｖｌｅｔは、Ｍｅｒｖｌｅｔ上でメソッド「Ｄｅｓｔｒｏｙ（）」を呼び出すことによって破壊（デストロイ）される。

あるパラメータが要求される場合、ＭｅｒｖｌｅｔＣｏｎｔｅｘｔが構成されて前記メソッドに送られる。したがって、開発者は、クラス「Ｍｅｒｖｌｅｔ」を拡張して、例えば以下のようにメソッド「Ｉｎｉｔ（）」およびメソッド「Ｓｅｒｖｉｃｅ（）」を無効にすることができる。

ｐｕｂｌｉｃ ｖｏｉｄ Ｉｎｉｔ（ＭｅｒｖｌｅｔＣｏｎｆｉｇ）は、「ＭｅｒｖｌｅｔＥｘｃｅｐｔｉｏｎ」を投入し；
ｐｕｂｌｉｃ ｖｏｉｄ Ｓｅｒｖｉｃｅ（ＭｅｒｖｌｅｔＲｅｑｕｅｓｔ，ＭｅｒｖｌｅｔＲｅｓｐｏｎｓｅ）は、ＩＯＥｘｃｅｐｔｉｏｎ，ＭｅｒｖｌｅｔＥｘｃｅｐｔｉｏｎを投入する。

また、Ｍｅｒｖｌｅｔをロードバランシングするため、及び、システム故障から回復するために、クラス「Ｍｅｒｖｌｅｔ」の一部として、以下の２つの別個のメソッドを利用することができる。
Ｖｏｉｄ Ｒｅｓｔｏｒｅ（ＭｅｒｖｌｅｔＣｏｎｔｅｘｔ ｍ）
Ｖｏｉｄ Ｓａｖｅ（）

メソッドＲｅｓｔｏｒｅ（）は、クラッシュ後にＭｅｒｖｌｅｔを回復させようとする際にそれ自身の状態を戻すため、メソッドＩｎｉｔに先だって、Ｍｅｒｖｌｅｔエンジンにより呼び出される。メソッドＳａｖｅ（）は、Ｍｅｒｖｌｅｔに知らせてそのアプリケーション状態を保存するために、常にＭｅｒｖｌｅｔエンジンによって呼び出され得る。しかしながら、Ｍｅｒｖｌｅｔは、クラッシュの前にメソッドＳａｖｅ（）が呼び出されることを前提とすべきではない。

クラス「ＭｅｒｖｌｅｔＣｏｎｔｅｘｔ」は、Ｍｅｒｖｌｅｔに利用可能なリソースを特定する。それは、クラス「ＳｅｒｖｌｅｔＣｏｎｔｅｘｔ」の拡張子であり、以下の別個のリソース、すなわち、ｉ）Ｍｅｒｖｌｅｔと共に使用できるファイル、ｉｉ）後述するようなユーザインタフェースおよびＩ／Ｏ特性を含むＭｅｒｖｌｅｔの性能に関連する属性のセット、ｉｉｉ）Ｍｅｒｖｌｅｔのためのリソース権利、を含んでいる。また、クラス「ＭｅｒｖｌｅｔＣｏｎｔｅｘｔ」は、これらのリソースの各々を取得して設定するためのメソッドも含んでいる。

クラス「ＭｅｒｖｌｅｔＲｅｑｕｅｓｔ」およびクラス「ＭｅｒｖｌｅｔＲｅｓｐｏｎｓｅ」は、クラス「ＳｅｒｖｌｅｔＲｅｑｕｅｓｔ」およびクラス「ＳｅｒｖｌｅｔＲｅｓｐｏｎｃｅ」のそれぞれの拡張子である。Ｍｅｒｖｌｅｔエンジンは、以下の抽象的なメッセージングメソッドを使用して、要求および応答を生成する。

Ｖｏｉｄ Ｒｅｌｉａｂｌｅ＿ａｓｙｎｃ＿ｓｅｎｄ（Ｅｎｄｐｏｉｎｔ ｔｏ， Ｅｎｄｐｏｉｎｔ Ｆｒｏｍ， ＤａｔａＳｔｒｅａｍ Ｄａｔａ， Ｒｅｌｉａｂｉｌｉｔｙ Ｔｙｐｅ， ＣａｌｌｂａｃｋＭｅｔｈｏｄ ｃｍ）

このメソッドにおけるデータフォーマットは、ＨＴＴＰマイムエンコードインタフェースにおけるそれと同じである。様々な交換フォーマットを用いた他の実行も考えられる。

Ｍｅｒｖｌｅｔエンジンがマルチスレッドであるため、Ｓｅｒｖｌｅｔモデルからのクラス「ＳｉｎｇｌｅＴｈｒｅａｄＭｏｄｅｌ」は実行されない。

次に図６を参照して、ユーザクライアントデバイス３０上のクライアントアプリケーションまたはブラウザ６０からのＭｅｒｖｌｅｔ１０のための要求に応じたＭｅｒｖｌｅｔエンジン１２の動作を示す機能ブロック図について説明する。図６に示されるＭｅｒｖｌｅｔ１０は、ユーザクライアントデバイス３０上またはプライマリサーバデバイス３２上に記憶されても良い。ユーザクライアントデバイス３０およびプライマリサーバデバイス３２の両方は、コアインタープリタ１８を有するＭｅｒｖｌｅｔエンジン１２を実行する。

先ず最初に、要求しているクライアント３０上のＭｅｒｖｌｅｔエンジン１２は、Ｍｅｒｖｌｅｔ１０を見つけなければならない。エンジンそれ自体は、単純なＭｅｒｖｌｅｔコンポーネントから構成される。要求されたＭｅｒｖｌｅｔの所在を確認する或は見つけるため、Ｍｅｒｖｌｅｔファインダモジュール６２は、Ｍｅｒｖｌｅｔのロードを要求するクライアント３０における全ての呼び出しをインタセプトする。Ｍｅｒｖｌｅｔファインダモジュール６２は、キャッシュによってエクスポートされた既知のハッシュ機能を使用して要求されたＭｅｒｖｌｅｔ１０のためのクライアント３０上のローカルキャッシュを検索する。Ｍｅｒｖｌｅｔ１０が見つけられると、Ｍｅｒｖｌｅｔファインダモジュール６２は、Ｍｅｒｖｌｅｔのためのメモリを割り当てるとともに、当該ローカルキャッシュからＭｅｒｖｌｅｔを読み込む。その後、Ｍｅｒｖｌｅｔファインダモジュール６２は、Ｍｅｒｖｌｅｔ１０上でメソッド「Ｉｎｉｔ」を呼び出し、要求されたＭｅｒｖｌｅｔのためのコンフィギュレーションデータを送って、新たに形成されたＭｅｒｖｌｅｔのインスタンスを初期化する。Ｍｅｒｖｌｅｔ１０が終了すると、それ自体にメソッド「Ｄｅｓｔｒｏｙ（）」を呼び出す。Ｍｅｒｖｌｅｔエンジン１２がＭｅｒｖｌｅｔ１０の除去を望む場合、Ｍｅｒｖｌｅｔエンジン１２は、それ自体にメソッド「Ｄｅｓｔｒｏｙ（）」を呼び出すことができる。

Ｍｅｒｖｌｅｔファインダモジュール６２は、ローカルキャッシュにおいて適合するものがなかったために要求されたＭｅｒｖｌｅｔ１０がクライアント３０に存在しないと判断する場合には、Ｍｅｒｖｌｅｔ１０のためのプライマリサーバデバイス３２に問い合わせる。サーバ３２に対する問い合わせには、Ｍｅｒｖｌｅｔ１０の名前、クライアントデバイス３０におけるＣＰＵ稼動時間、クライアントデバイス３０のＭＩＰＳ等級、クライアントデバイス３０の利用可能なメモリおよび固定記憶域、利用可能な場合にはＭｅｒｖｌｅｔ１０の任意の性能属性が含まれる。この情報は、Ｍｅｒｖｌｅｔ１０をクライアント３０に再配置するか、あるいは、後述するロードバランシングスキームを使用してサーバ３２とクライアント３０との間で通信を行なうためにアクセスネットワーク３８を切換えるか、を決定するために、プライマリサーバ３２によって使用され得る。

また、Ｍｅｒｖｌｅｔエンジン１２は、プライマリサーバ３２に到達するＭｅｒｖｌｅｔ１０のための要求をインタセプトするインターセプティングＭｅｒｖｌｅｔモジュール６４を有している。Ｍｅｒｖｌｅｔ１０のために要求メッセージがネットワークから到達すると、インターセプティングＭｅｒｖｌｅｔモジュール６４は、サーバ３２上のＭｅｒｖｌｅｔ１０にメッセージを送る。また、インターセプティングＭｅｒｖｌｅｔモジュール６４は、Ｍｅｒｖｌｅｔ１０のための要求に応じて、ポリシーＭｅｒｖｌｅｔモジュール６６を呼び出すとともに、要求しているクライアント３０におけるシステム性能パラメータをポリシーＭｅｒｖｌｅｔモジュール６６に伝える。その後、ポリシーＭｅｒｖｌｅｔモジュール６６は、そのユーザに対する応答性能を最適化するためにＭｅｒｖｌｅｔ１０をどのようにロードバランシングするかを決定する。ポリシーＭｅｒｖｌｅｔモジュール６６は、システムアドミニストレータによって設定される。また、プライマリサーバ３２は、クライアントからの複数の要求を同時に受け入れても良く、したがって、ポリシーＭｅｒｖｌｅｔモジュール６６およびインターセプティングＭｅｒｖｌｅｔモジュール６４はマルチスレッドである。

特に、プライマリサーバ３２およびクライアント３０は、以下のようにＭｅｒｖｌｅｔ１０をロードバランシングすることができる。サーバ３２は、サーバマシン上でＭｅｒｖｌｅｔ１０を実行するとともに、要求しているクライアント３０にＭｅｒｖｌｅｔ１０と遠隔的にやりとりさせることを選ぶことができる。あるいは、サーバ３２は、クライアントデバイス上で実行するために、Ｍｅｒｖｌｅｔ１０をクライアント３０に送ることを決定することができる。ポリシーＭｅｒｖｌｅｔモジュール６６は、後述するアプリケーション提供スキームを使用して、Ｍｅｒｖｌｅｔ１０を再配置するか否かを決定する。また、サーバ３２あるいはクライアント３０は、後述するネットワーク切換えスキームを使用して、互いに通信するためにアクセスネットワーク３８を切換えることを選択しても良い。

要求されたＭｅｒｖｌｅｔ１０をサーバマシン上で実行することをサーバ３２が決定する場合、ポリシーＭｅｒｖｌｅｔモジュール６６は、サーバのキャッシュからＭｅｒｖｌｅｔ１０を検索するとともに、メソッド「ｎｅｗ（）」を使用してＭｅｒｖｌｅｔのためのメモリを割り当てる。その後、適当なＭｅｒｖｌｅｔのコンテクストを使用して、メソッド「Ｉｎｉｔ（）」がＭｅｒｖｌｅｔ１０上に呼び出される。初期化されたＭｅｒｖｌｅｔ１０のインスタンスは、セキュリティのセマンティックスがＪ２ＥＥのそれと同じである場合、要求しているクライアントの認定を前提とする。要求されたＭｅｒｖｌｅｔ１０のインスタンスは、初期化された後、サーバ上のローカルデータにアクセスすることができる。また、Ｍｅｒｖｌｅｔ１０は、後述するように、メッセージングシステム２０により、クライアント３０上のクライアントアプリケーションと通信することができる。したがって、Ｍｅｒｖｌｅｔエンジン１２は、Ｍｅｒｖｌｅｔ１０からの出力を、要求しているクライアント３０に対して直接に送る。最後に、Ｍｅｒｖｌｅｔ上でメソッド「Ｄｅｓｔｒｏｙ（）」を呼び出すことにより、Ｍｅｒｖｌｅｔ１０をデストロイすることができる。

要求されたＭｅｒｖｌｅｔ１０が要求しているクライアント３０上で動作するべきであることをポリシーＭｅｒｖｌｅｔモジュール６６が決定すると、Ｍｅｒｖｌｅｔは整理されてリモートマシンに送られる。Ｍｅｒｖｌｅｔ１０を再配置するため、エンジン１２は、ＭｅｒｖｌｅｔをＭｅｒｖｌｅｔアーカイブ（ＭＡＲ）ファイル６８中にパッケージングする。ＭＡＲファイル６８は、１）Ｍｅｒｖｌｅｔ１０および任意の関連するタグライブラリ１４と、２）Ｍｅｒｖｌｅｔのためのアプリケーション属性５０およびセキュリティコンテキスト属性５６と、３）Ｍｅｒｖｌｅｔ１０に関連付けられた任意のデータファイルと、４）ＭＡＲファイルのコンテンツを記載したＭＡＲファイルマニフェストと、を備えていることが好ましい。したがって、ＭＡＲファイル６８は、起動時にクライアント３０上でＭｅｒｖｌｅｔエンジン１２が適当なＭｅｒｖｌｅｔのコンテキストを形成してＭｅｒｖｌｅｔ１０のメソッド「Ｉｎｉｔ」に送るために必要な情報の全てを有している。ＭＡＲファイル６８は、圧縮されて、ハッシュされ、その後、サインされ得る。ダウンローダは、解凍して、コンテンツが改悪されなかったことを確認し、サインを確認し得る。

ここで、Ｍｅｒｖｌｅｔアプリケーション環境がＭｅｒｖｌｅｔアプリケーションをどのようにロードバランシングしてシステム故障から回復するか、について説明する。

（３．アプリケーションロードバランシングスキーム）
ここで詳細に説明するＭｅｒｖｌｅｔアプリケーション環境の１つの特徴により、Ｍｅｒｖｌｅｔエンジン１２は、Ｍｅｒｖｌｅｔ１０をロードバランシングして、Ｍｅｒｖｌｅｔの性能を最適化することができる。

本発明に係るロードバランシングスキームは、サーバ３２からＭｅｒｖｌｅｔ１０を要求しているユーザクライアントデバイス３０とのユーザのやりとりを基本としている。特に、Ｍｅｒｖｌｅｔエンジン１２のポリシーＭｅｒｖｌｅｔモジュール６６は、クライアントのユーザインタフェース（「ＵＩ」）におけるイベント待ち時間の測定を使用して、Ｍｅｒｖｌｅｔ１０の応答性能を最適化する。本発明に係るＭｅｒｖｌｅｔアプリケーション環境により、イベント待ち時間に基づくロードバランシングを、アプリケーション要求時間およびアプリケーションランタイムで行なうことができる。

モデルロードバランシングスキームは、２つのタイプの最適化、すなわち、アプリケーション提供およびネットワーク切換え、を可能にする。アプリケーション提供ポリシーにより、サーバは、ネットワークにおける何れのノードがＭｅｒｖｌｅｔを実行すべきかを決定することができる。ネットワーク切換えポリシーにより、要求しているクライアントまたはサーバは、サーバとクライアントとの間で通信するための新たなアクセスネットワークを選択することができる。このモデルにより、開発者は、ロードバランシングのための大きなクラスのアルゴリズムを形成することができる。

ロードバランシングスキームを使用して行なうことができる性能の最適化を説明するため、クライアントデバイスのユーザインタフェースイベントにおけるタイムラインが図７に示されている。ユーザは、Ｍｅｒｖｌｅｔとやりとりしている間、交互の考え時間および待ち時間を進む。各考え時間Ｔの最後に、ユーザは、Ｍｅｒｖｌｅｔに対して要求を送り、応答を待つ。Ｍｅｒｖｌｅｔは、一般に、ユーザからの要求を１つのループ内で待つ。Ｍｅｒｖｌｅｔは、要求を受けると、計算およびデータアクセスを行ない、ユーザの要求を満たすことができる。その後、Ｍｅｒｖｌｅｔは、応答を送り戻す。図７に示されるタイムラインは、そのような１つのやりとりの全てを示している。

待ち時間Ｗは、要求の処理に関連付けられた時間である。待ち時間Ｗは、通信時間Ｃとサーバ計算時間Ｓとに分けることができる。一般に、ユーザの経験は、アプリケーションとのやりとり時における待ち時間の平均および分散（変動）に基づいている。したがって、その待ち時間が一般に所定の閾値を下回る場合には、Ｍｅｒｖｌｅｔの性能を最適化することができる。本発明に係るロードバランシングスキームは、サーバからユーザにより近くＭｅｒｖｌｅｔを再配置することにより、あるいは、適切な場合には、クライアントとサーバとの間でアクセスネットワークを切換えることにより、Ｍｅｒｖｌｅｔのための待ち時間の平均および分散を最適化することができる。

Ｍｅｒｖｌｅｔ１０をロードバランシングするため、Ｍｅｒｖｌｅｔエンジン１２のポリシーＭｅｒｖｌｅｔモジュール６６は、図８に要約されて後述される性能属性５２およびシステム属性５４を含むアプリケーション属性５０のセットを使用する。

（３．１ Ｍｅｒｖｌｅｔ性能属性）
Ｍｅｒｖｌｅｔ１０をロードバランシングするために使用されるアプリケーション属性５０は、２つの基準、すなわち、１）アプリケーションがどのようにインタラクティブであるか、２）アプリケーションが、どの程度コンピュータを駆使し、どのくらいデータ量が多いか、に基づいてＭｅｒｖｌｅｔを特徴付ける性能属性５２のセットを含んでいる。開発者は、本能的に、インタラクティブなアプリケーションをユーザにより近付ける能力と、データ量の多いアプリケーションをデータのソースにより近付ける能力と、コンピュータを駆使するアプリケーションをサーバクラスマシン等のより強力なデバイス上で実行させる能力と、をシステムに与えたいと考えている。一般に、開発者は、例えばＪＳＰやＳｅｒｖｌｅｔ等のＪ２ＥＥ上のサーバアプリケーションとして、あるいは、クライアントのためのアプレットとして、Ｊａｖａアプリケーションを書き込む。例えば、ある開発者は、従来、ゲームをアプレットとして書き込み、また、銀行のアプリケーションをサーバベースのアプリケーションとして書き込む。一方、Ｍｅｒｖｌｅｔの開発者は、アプリケーションを１度書き込むだけで済み、その後、ポリシーＭｅｒｖｌｅｔ６６は、測定された性能属性５２を使用して、ユーザの近くにＭｅｒｖｌｅｔ１０を再配置することができ、あるいは、アクセスネットワークを切換えて、Ｍｅｒｖｌｅｔのための良好な待ち時間の平均および分散を提供することができる。

（３．１．１ Ｍｅｒｖｌｅｔやりとり（インタラクション）の特徴付け）
特に、ユーザは、クライアントデバイス３０とやりとりを行なってＭｅｒｖｌｅｔ１０から情報を要求する際、例えば、ウェブページ書式を送って情報のためのＵＲＬをクリックする際に、イベントを待つ。書式に必要事項を記入して応答を待つ行為およびリンクをクリックしてページを取得する（ｇｅｔ）行為を含むこれらの行動は、ユーザインタフェースイベントと称される。Ｍｅｒｖｌｅｔ１０がクライアントデバイス３０上で実行する場合、待ち時間Ｗの全てがアプリケーションで費やされる。Ｍｅｒｖｌｅｔ１０がサーバ３２上でクライアントデバイス３０から離れて実行している場合、待ち時間Ｗの一部Ｃは、要求しているクライアントとの通信に費やされ、待ち時間の残りＳが、クライアント要求の処理のため、Ｍｅｒｖｌｅｔ自体において費やされる。

Ｍｅｒｖｌｅｔ１０をロードバランシングするため、Ｍｅｒｖｌｅｔアプリケーション環境は、Ｍｅｒｖｌｅｔに要求を送る各書式および各ＵＲＬに関して、Ｍｅｒｖｌｅｔの以下の性能属性、すなわち、待ち時間Ｗ、サーバ計算時間Ｓ、通信時間Ｃの平均および分散を測定する。

例えば、ＨＴＭＬベースのクライアントは、クライアント上のブラウザからＭｅｒｖｌｅｔへの全ての「ｇｅｔ」および「ｐｏｓｔ」をインタセプトすることができる。これは、ＭｅｒｖｌｅｔエンジンのインターセプティングＭｅｒｖｌｅｔモジュールによって取り扱われる。「ｇｅｔ」または「ｐｏｓｔ」が実施されると、第１のタイムスタンプＴ１が取得される。「ｇｅｔ」または「ｐｏｓｔ」が戻って、Ｍｅｒｖｌｅｔによって生成された応答がブラウザ上に表示されると、第２のタイムスタンプＴ２が取得される。また、Ｍｅｒｖｌｅｔからの応答メッセージは、サーバＳでの計算に費やされた時間を示すパラメータ値を含んでいる。したがって、以下の計算を行なうことができる。
Ｗ＝Ｔ２−Ｔ１
Ｗ＝Ｓ＋Ｃ
ここで、
Ｓ＝サービス時間
Ｃ＝通信時間
Ｗ＝待ち時間
Ｔ１＝第１のタイムスタンプ
Ｔ２＝第２のタイムスタンプ

サーバ３２は、Ａ（Ｓ）、Ａ（Ｃ）、Ａ（Ｗ）、Ｖ（Ｓ）、Ｖ（Ｃ）、Ｖ（Ｗ）でそれぞれ示される、サーバ計算時間、待ち時間、通信時間の平均および分散の移動平均を維持する。また、ＷパラメータおよびＣパラメータの平均および分散の移動平均は、要求しているクライアントとサーバとの間の通信に使用される各アクセスネットワーク毎に計算される。

ＣパラメータおよびＳパラメータが連続するランダムな変数である場合、以下の関係を想定することができる。
Ａ（Ｗ）＝Ａ（Ｃ）＋Ａ（Ｓ）
Ｖ（Ｗ）＝Ｖ（Ｃ）＋Ｖ（Ｓ）＋Ｃｏｖ（Ｖ，Ｓ）

ここで、ＶおよびＳに関する統計的な共分散＝Ｃｏｖ（Ｖ，Ｓ）である。

更に、ＶおよびＳが統計学的に独立した変数である場合、以下の関係が成り立つ。
Ｖ（Ｗ）＝Ｖ（Ｃ）＋Ｖ（Ｓ）

したがって、Ｍｅｒｖｌｅｔ１０のためのロードバランシングポリシーは、Ａ（Ｃ）およびＶ（Ｃ）を減らすことにより、Ｍｅｒｖｌｅｔの性能のユーザの認識を向上することができる。

例えば、アプリケーション提供最適化を実施するアルゴリズムにおけるフレームワークは、Ａ（Ｗ）が所定の閾値よりも大きいかどうかを確認することにより、Ｍｅｒｖｌｅｔ１０のための待ち時間Ｗが許容されないかどうかを判断することができる。また、前記アルゴリズムにおけるフレームワークは、Ａ（Ｃ）がＡ（Ｓ）よりも大きいことを確認することにより、通信時間Ｃが待ち時間Ｗにかなりの影響を与えているかどうかを判断することができる。Ｗが許容されず且つＣがかなりの影響を与える場合、アルゴリズムは、Ｍｅｒｖｌｅｔを他のデバイスに再配置することを試みることができる。さもなければ、Ｍｅｒｖｌｅｔは、現在のデバイス上で実行し続ける。

同様に、ネットワーク切換え最適化を実施するために使用され得るアルゴリズムのフレームワークは、第１のアクセスネットワークを使用するＭｅｒｖｌｅｔ１０のための平均待ち時間Ａ（Ｗ−ネットワーク１）が第２のアクセスネットワークを使用する平均待ち時間Ａ（Ｗ−ネットワーク２）よりも長いかどうかを判断する。長い場合、アルゴリズムは、Ｍｅｒｖｌｅｔとの通信のため、第２のネットワークであるネットワーク２に切換える。

当業者であれば分かるように、性能属性５２を使用してＭｅｒｖｌｅｔ１０をロードバランシングするための他の最適化アルゴリズムも考えられる。ロードバランシングスキームは、ユーザの経験を向上させユーザインタフェースイベントにおける応答性能を最適化するための様々なアルゴリズムをアプリケーション設計者が形成する機会を与える。

（３．１．２ サーバ計算時間およびデータアクセスの特徴付け）
前述したように、クライアントアプリケーションからの１つの要求に対する応答をＭｅｒｖｌｅｔが生成するための全サービス時間は、サーバ計算時間Ｓによって測定される。Ｍｅｒｖｌｅｔは、内部計算を行なって、及び、外部データファイルにアクセスして、サーバ計算時間Ｓを費やしても良い。例えば、
Ｓ＝Ｄ＋Ｉ
ここで、
Ｓ＝サービス時間
Ｄ＝データＩ／Ｏのために費やされた時間
Ｉ＝内部計算のために費やされた時間

サーバ計算時間Ｓを示す値を得るため、クライアントアプリケーションからの要求に応じてサーバのＭｅｒｖｌｅｔエンジンがメソッド「Ｓｅｒｖｉｃｅ（）」をＭｅｒｖｌｅｔ上で呼び出すと、サーバのタイマーが始動する。Ｍｅｒｖｌｅｔが要求に対する応答を生成すると、タイマーが停止される。タイマーの持続時間は、サーバ計算時間Ｓを測定する。ＭｅｒｖｌｅｔエンジンのためのＩ／Ｏライブラリには、データＩ／Ｏで費やされる時間ＤおよびデータＩ／Ｏ率ＤＴＰを記録するために機器が設けられる。内部計算のために費やされる時間Ｉは、前記方程式から計算できる。

また、Ｍｅｒｖｌｅｔエンジンは、サーバのタイマーを使用して、Ｍｅｒｖｌｅｔが終了する平均総使用時間、トータル時間、を記録することもできる。これらのパラメータは、後述するロードバランシングアルゴリズムを改良するために、Ｍｅｒｖｌｅｔの開発者が利用できるようにされる。

（３．１．３ 性能属性計測）
以下は、Ｊ２ＭＥライブラリを使用してＭｅｒｖｌｅｔ１０のファイルＩ／ＯイベントおよびユーザインタフェースをインタセプトするためのＡＰＩの典型的なセットである。これらのＡＰＩは、ライブラリｊａｖａ．ｎｅｔ， ｊａｖａ．ｉｏ， ｊａｖａ．ｕｔｉｌに対して以下の変更を要求する。

待ち時間Ｗ、サーバ計算時間Ｓ、通信時間Ｃを含む、Ｍｅｒｖｌｅｔ１０のユーザインタフェースイベントを測定するための性能属性５２は、ｊａｖａ．ｎｅｔを変更して全てのｈｔｔｐ要求をインタセプトすることにより決定される。以下のメソッドは、前述のように、ＨＴＭＬベースの形式（書式）およびＵＲＬ処理に関する情報を収集するために使用される。

ｖｏｉｄ ｒｅｃｏｒｄＥｖｅｎｔ（ＥｖｅｎｔＴｙｐｅ ｅｔ，Ｅｖｅｎｔ ｅ，ＴｉｍｅＳｔａｍｐ ｔ）

所定の形式を有する各要求／応答の対が記録され、当該形式の全てのイベントがこのメソッドを使用してカウントされる。

また、データファイルを読み書きする以下のメソッドが与えられる。

ｖｏｉｄ＿ｒｅｃｏｒｄＦｉｌｅＩＯ（ＡｃｃｅｓｓＴｙｐｅ ｔｙｐｅ， ｉｎｔ ｄａｔａ，Ｔｉｍｅｓｔａｍｐ ｔｉｍｅ）

パラメータＡｃｃｅｓｓＴｙｐｅにおけるデータタイプは、読み込みタイプまたは書き込みタイプであっても良い。このメソッドは、測定された性能属性をファイルに書き込む。

（３．２ システム属性）
また、ポリシーＭｅｒｖｌｅｔ６６は、ロードバランシングおよびネットワーク切換えの決定のため、アプリケーション属性５４に加えて、システム属性５４を使用する。システム属性５４は、一般に、Ｍｅｒｖｌｅｔアプリケーション環境によって使用されるコンピュータデバイスの処理能力およびリソースに関連している。特に、図８に示されるように、以下の属性、すなわち、ＭＩＰＳ等級、ＣＰＵ稼動時間の平均および分散、メモリおよび固定記憶域の大きさ、ネットワーク待ち時間の平均および分散、当該デバイスで利用可能な各ネットワークタイプにおける帯域幅、が各クライアント３０およびサーバ３２毎に記録される。

（３．２．１ 計測によるシステム属性）
システム属性５４を測定するため、Ｊ２ＭＥプラットフォーム、ｊａｖａ．ｓｙｓ．ｐｅｒｆのための新たなライブラリは、以下のメソッドを利用できるようになる。

ｖｏｉｄ Ｓｙｓｔｅｍ＿ｃｐｕ＿ｕｔｉｌ（Ｕｔｉｌ Ｕ）

メソッドＳｙｓｔｅｍ＿ｃｐｕ＿ｕｔｉｌ（Ｕｔｉｌ Ｕ）は、ＵＮＩＸ上で／ｄｅｖ／ｋｅｍを読み取って、ＵＮＩＸシステムにおけるＣＰＵ稼動時間情報を得る。当業者であれば分かるように、同様の呼び出しが他のオペレーティングシステムに存在する。

ｖｏｉｄ Ｓｙｓｔｅｍ＿ｎｅｔｗｏｒｋ＿ｂａｎｄｗｉｄｔｈ（ｂａｎｄｗｉｄｔｈ ｂ，ａｃｃｅｓｓｎｅｔｗｏｒｋ ａ）

メソッドＳｙｓｔｅｍ＿ｎｅｔｗｏｒｋ＿ｂａｎｄｗｉｄｔｈ（ｂａｎｄｗｉｄｔｈ ｂ，ａｃｃｅｓｓｎｅｔｗｏｒｋ ａ）は、アクセスネットワーク「ａ」を使用して、クライアント３０とプライマリサーバ３２との間のネットワーク帯域幅を取得する。帯域幅は、既知のサイズＳを有するパケットをクライアント３０からプライマリサーバ３２に送り、同じサイズのパケットを戻し、その後、パケットを得るために費やした時間でパケットサイズＳを割ることにより、計算される。この計算は、オペレーティングシステムで精度良く行なわれることが好ましい。

Ｖｏｉｄ ｓｙｓ＿ｎｅｔｗｏｒｋ＿ｌｏａｄ＿ｌａｔｅｎｃｙ（ａｃｃｅｓｓｎｅｔｗｏｒｋ ａ，ｌａｔｅｎｃｙ ｌ）

メソッドｓｙｓ＿ｎｅｔｗｏｒｋ＿ｌｏａｄ＿ｌａｔｅｎｃｙ（ａｃｃｅｓｓｎｅｔｗｏｒｋ ａ，ｌａｔｅｎｃｙ ｌ）は、インターネット制御メッセージプロトコル（ＩＣＭＰ）を使用して、ネットワーク待ち時間を取得する。クライアントは、ＩＣＭＰパケットを定期的にサーバに送るとともに、戻された値を使用して、待ち時間の平均値を長い時間にわたって維持する。システムアドミニストレータは、この演算が行なわれる頻度を設定することができる。

Ｖｏｉｄ Ｎｅｔｗｏｒｋ＿ｕｐｔｉｍｅ（Ｎｅｔｕｐｔｉｍｅ ｎｕ，ａｃｃｅｓｓｌｉｎｋ ａ）

メソッドＮｅｔｗｏｒｋ＿ｕｐｔｉｍｅ（Ｎｅｔｕｐｔｉｍｅ ｎｕ，ａｃｃｅｓｓｌｉｎｋ ａ）は、クライアントとサーバとの間のネットワーク接続が保たれていて（ｕｐである）時間のパーセンテージを取得する。ＩＣＭＰパケットが戻ると、システムは、ネットワークが切れ、さもなければダウンされた、と見なす。

（３．３ アプリケーション属性の収集および普及）
ロードバランシング決定を行なうため、測定されたアプリケーション属性は、ロードバランシングアルゴリズムに利用可能とされなければならない。アプリケーション提供最適化がサーバによって実行される。サーバおよびクライアントによってネットワーク切換え最適化が実行され得る。クライアントおよびサーバが動的にアプリケーション属性をプロファイルできる様々な方法がある。

例えば、要求しているクライアントのシステム属性は、サーバでのロードバランシングアルゴリズムにより、クライアントからのメッセージで得られ得る。サーバは、それ自身のシステム属性を記憶することができる。

クライアントは、現在実行しているＭｅｒｖｌｅｔアプリケーションに基づいて、Ａ（Ｗ）、Ａ（Ｃ）、Ａ（Ｓ）、Ｖ（Ｗ）、Ｖ（Ｃ）、Ｖ（Ｓ）に関する情報をローカルに維持することができる。また、クライアントデバイスは、複数のネットワークインタフェースを有していても良い。考え時間中、クライアント上の別個のアプリケーションは、異なるネットワーク上でのＡ（Ｃ）に関する情報を収集しても良い。この作業は、クライアントのバッテリに負担をかけ過ぎないように、省エネルギー形態で注意深く行なわれることが好ましい。各ネットワークインタフェースにわたりＭｅｒｖｌｅｔのためのＡ（Ｓ）およびＶ（Ｃ）を加えることにより、各ネットワーク毎にＡ（Ｗ）を収集することができる。測定された各Ａ（Ｗ）値は、ベクトルで記憶され得て、アプリケーション提供およびネットワーク切換えの決定において使用される。

また、クライアントは、サーバとの通信のために同じ基地局またはアクセスポイントを使用している共通のネットワーク上の他のクライアントから、Ａ（Ｃ）に関する情報を収集しても良い。Ｗ、Ｃ、Ｓは、アプリケーション毎に或はアプリケーション毎のユーザ毎に測定され得て、クライアントのキャッシュ内に記憶され得る。クライアントのキャッシュは、例えばサーバを介して、他のクライアントと同期され得る。何れのクライアントが同じアクセスポイントまたは基地局を共有しているかに関してサーバが分かっていること、が前提である。サーバは、同じ基地局を共有する全てのクライアントにおける情報を収集する。その後、クライアントのキャッシュは、システムアドミニストレータによって設定される頻度で、サーバに対して定期的に送られる。その周期は、システムアドミニストレータによって設定される。サーバは、データを収集するとともに、クライアントが要求する場合には、この情報およびスムージングインターバルをクライアントに送る。スムージングインターバルは、一連のロードバランシング最適化の間で経過しなければならない時間を示す所定の値である。

また、クライアントのキャッシュは、クライアント間で直接に同期されることもできる。この場合、各クライアントは、Ｂｌｕｅｔｏｏｔｈ、ＩＲＤＡまたは８０２．１１ｂ等の特別のネットワークを介して、キャッシュされた情報を他のクライアントにブロードキャストする。そのようなブロードキャストメッセージは、クライアントとサーバとの間の通信のためのネットワークを通じて伝搬する必要がない。その代わり、クライアントは、個別に、データを収集する。スムージングインターバルは、システムアドミニストレータによって決定されても良く、あるいは、クライアントは、分配されたコンセンサスアルゴリズムを使用して、スムージングインターバルにおいて一致することができる。

サーバは、Ｍｅｒｖｌｅｔがサーバ上で実行される時にはいつでも、待ち時間、通信時間、サーバ時間の測定された平均および分散を含む、当該Ｍｅｒｖｌｅｔにおける測定された性能属性を得ることができる。システムアドミニストレータは、動的プロファイルを使用するのに十分な測定データが性能属性に関して存在する前に、Ｍｅｒｖｌｅｔが実行しなければならない回数、例えば１０回の繰り返し、を選択することができる。

（３．３．１ 収集モード）
Ｍｅｒｖｌｅｔにおける性能属性値は、ユーザ毎に、あるいは、アプリケーション毎のユーザ毎に、あるいは、デバイス毎のアプリケーション毎のユーザ毎に、収集されても良い。デバイスがアプリケーション毎に性能属性を測定して記憶する場合、ロードバランシングアルゴリズムは、ユーザに関係無く、この情報を使用しても良い。また、デバイスは、ロードバランシングアルゴリズムが様々なユーザのプロファイルへと問い合わせすることができるように、アプリケーション毎のユーザ毎に、性能属性を測定して記憶しても良い。

イベントを記録するための機構に関連付けられるオーバーヘッドを最小限に抑えることが望ましい場合がある。したがって、性能属性およびシステム属性の収集は、記憶および処理の観点から妨害的であってはならない。各アプリケーション属性毎にデータを保存するための記憶要件は比較的最小であるため、このデータをメモリに書き込むこと、並びに、システムクロックを読み取ることは、妨害的であってはならない。例えば、ユーザインタフェースイベントが約５００ミリ秒から約１秒で生じるとすると、約１ミリ秒の粒状度でシステムクロックをサポートするＭｅｒｖｌｅｔアプリケーション環境のＪａｖａの実行により、ほんの僅かなオーバーヘッドでユーザインタフェース関連のイベントを測定することができる。

（３．４ ロードバランシングアルゴリズム）
Ｍｅｒｖｌｅｔアプリケーション環境は、そのアプリケーション属性およびシステム属性に基づく２つの異なる最適化、すなわち、アプリケーション提供およびネットワーク切換え、を使用して、アプリケーションロードタイムおよひランタイムで、Ｍｅｒｖｌｅｔをロードバランシングすることができる。具体的には、ユーザがＭｅｒｖｌｅｔを要求すると、ＭｅｒｖｌｅｔエンジンのポリシーＭｅｒｖｌｅｔモジュールは、Ｍｅｒｖｌｅｔを実行すべき場所および通信のために使用すべきアクセスネットワークを決定する。同様に、ランタイム中、Ｍｅｒｖｌｅｔエンジンは、ユーザに対する応答性能を向上させるために、Ｍｅｒｖｌｅｔを再配置すること、あるいは、アクセスネットワークを切換えること、を決定しても良い。

しかしながら、当業者であれば容易に分かるように、後述するロードバランシング最適化は、他のモバイルアプリケーションのための実行環境で使用することができ、Ｍｅｒｖｌｅｔに限定されない。例えば、開発者は、遠く離れたブラウザにコンテンツを提供するＡｇｌｅｔと呼ばれるアプリケーションプログラム、または、一方のマシンから他方のマシンへとネットワークにわたって移動することができる他のアプリケーション、を形成しても良い。Ａｇｌｅｔは、当該Ａｇｌｅｔがそれ自身をＵＲＬにて指定された他のマシンへ送ることを許容するメソッド「ｄｉｓｐａｔｃｈ（ｕｒｌ）」を有していても良い。Ａｇｌｅｔシステムにおけるデバイスは、システムデータベースに記憶された待ち時間の平均および分散のリストを有していても良い。Ａｇｌｅｔは、システムライブラリを介してこの情報にアクセスしても良く、また、それ自身、実行すべきマシンを選択する任意のポリシーを書き込むことができる。例えば、Ａｇｌｅｔシステム上で以下の定型化されたコードシーケンスを実行してロードバランシングすることができる。

ＤｉｓｐａｔｃｈＰｏｌｉｃｙ（）
｛
Ｉｆ（Ａ（Ｗ）＞Ａｇｌｅｔ＿Ｔｈｒｅｓｈｏｌｄ）ｔｈｅｎ
Ｄｉｓｐａｔｃｈ（ＵＲＬ）；
｝

この場合、Ａ（Ｗ）は、Ａｇｌｅｔにおける平均的な平均待ち時間であり、ＵＲＬは、ブラウザマシンにおけるＡｇｌｅｔランタイムのＵＲＬである。この方法論を使用すると、Ａｇｌｅｔは、１）現在のマシン上に残ることができ、あるいは、２）それ自身をブラウザと同じマシンへと移動させることができる。

（３．４．１ アプリケーション提供最適化）
次に、図９を参照すると、アプリケーション提供最適化の実施例が決定ツリーを使用して示されている。このアプリケーション提供アルゴリズムは、サーバによって実行されるとともに、Ｍｅｒｖｌｅｔ等のアプリケーションのロードタイムおよびランタイムで同様に適用可能である。

アプリケーション提供アルゴリズムは、Ｍｅｒｖｌｅｔ１０または他の再配置可能アプリケーションの、平均通信時間Ｃおよびサーバ計算時間Ｓを含む平均待ち時間Ｗに基づいている。Ｍｅｒｖｌｅｔ１０を、サーバ３２から、要求しているクライアントデバイス３０へと移動させることにより、通信時間Ｃをほぼ０まで減らすことができる。最初に、ステップ５０において、アルゴリズムは、Ｍｅｒｖｌｅｔからコンテンツを要求しているクライアントがＭｅｒｖｌｅｔを実行できる十分なメモリを有しているか否かについて、当該要求から得られるクライアントに関する情報を使用して判断する。同様に、ステップ５２において、アルゴリズムは、アプリケーションを実行するのに十分な処理能力、クライアントのＭＩＰＳ等級によって測定される、をクライアントが有しているか否かを判断する。

次に、ステップ５４において、アルゴリズムは、サーバのＣＰＵ稼動時間によって測定されるようなサーバ上における計算負荷が所定のＬｏａｄ＿ｔｈｒｅｓｈｏｌｄ値（負荷閾値）よりも大きいか否かを判断する。また、ステップ５４において、アルゴリズムは、サーバからクライアントへのＭｅｒｖｌｅｔの移動に関連付けられた再配置オーバーヘッドが所定のＲＯ＿ｔｈｒｅｓｈｏｌｄ値（再配置オーバーヘッド閾値）よりも小さいか否かを判断する。再配置オーバーヘッドは、システムアドミニストレータによって設定される関係を使用して、Ｍｅｒｖｌｅｔの大きさに基づいて計算され得る。両方の条件が満たされると、ステップ５６において、アルゴリズムは、クライアント上でＭｅｒｖｌｅｔを実行させるべく、Ｍｅｒｖｌｅｔをクライアントへと移動させるようにサーバに指示する。このシーケンスは、サーバが非常にビジーであるためにＭｅｒｖｌｅｔをタイムリーに処理することができない場合に、Ｍｅｒｖｌｅｔをクライアント上に移動させることで、Ｍｅｒｖｌｅｔの応答性能を向上させるのに役立つ。

両方の条件が満たされない場合、ステップ５８において、アルゴリズムは、Ｍｅｒｖｌｅｔにおける平均待ち時間が所定のＡＷ＿ｔｈｒｅｓｈｏｌｄ値よりも長いか否かを判断する。ステップ５８において、この条件が満たされ、平均待ち時間と平均通信時間との間の差によって測定される平均サーバ計算時間が所定のＡＳ＿ｔｈｒｅｓｈｏｌｄ値よりも小さく、かつ、再配置オーバーヘッドが所定のＲＯ＿ｔｈｒｅｓｈｏｌｄ値よりも小さい場合、アルゴリズムは、ステップ６０において、クライアント上でＭｅｒｖｌｅｔを実行するべく、Ｍｅｒｖｌｅｔをクライアントへと移動させるようにサーバに指示する。このステップは、当該移動後のサーバ計算時間があまり長くない限りにおいて、Ｍｅｒｖｌｅｔのユーザインタフェースイベントにおける待ち時間が長すぎる場合に、Ｍｅｒｖｌｅｔをクライアントに再配置させることで、Ｍｅｒｖｌｅｔの応答性能を向上させるのに役立つ。

また、アルゴリズムは、平均待ち時間が所定の閾値よりも長く且つ平均通信時間が平均サーバ計算時間よりも長い場合に、Ｍｅｒｖｌｅｔを再配置することを決定しても良い。

同様に、ステップ６２において、アルゴリズムは、Ｍｅｒｖｌｅｔにおける待ち時間の分散が所定のＶＷ＿ｔｈｒｅｓｈｏｌｄ値よりも大きいか否かを判断する。ステップ６２において、この条件が満たされ、待ち時間の分散と通信時間の分散との間の差によって測定されるサーバ計算時間の分散が所定のＶＳ＿ｔｈｒｅｓｈｏｌｄ値よりも小さく、かつ、再配置オーバーヘッドが所定のＲＯ＿ｔｈｒｅｓｈｏｌｄ値よりも小さい場合、アルゴリズムは、ステップ６４において、クライアント上でＭｅｒｖｌｅｔを実行するべく、Ｍｅｒｖｌｅｔをクライアントへと移動させるようにサーバに指示する。このステップは、当該移動後のサーバ計算時間があまり長くない限りにおいて、Ｍｅｒｖｌｅｔのユーザインタフェースイベントにおける待ち時間が長すぎる場合に、Ｍｅｒｖｌｅｔをクライアントに再配置させることで、Ｍｅｒｖｌｅｔの応答性能を向上させるのに役立つ。さもなくば、ステップ６６において、Ｍｅｒｖｌｅｔは、サーバ上で実行される。

あるいは、アプリケーション提供アルゴリズムは、Ａ（Ｓ）がＡ（Ｃ）よりも十分に小さい場合に成すその決定において、Ａ（Ｓ）を無視することができる。さもなくば、ＳがＣとほぼ同じである場合、倍率ＳＦを使用してデバイス上のＡ（Ｓ）を評価することができる。ＳＦは、サーバ上のＳｐｅｃＩｎｔをデバイス上のＳｐｅｃＩｎｔで割った値である。ここで、ＳｐｅｃＩｎｔは、プロセッサ速度を比較するための既知の基準である。

当業者であれば分かるように、アプリケーションにおける待ち時間を使用するＭｅｒｖｌｅｔ提供アルゴリズムのための他の実施も考えられる。例えば、待ち時間の平均および分散を比較するステップを省略する他のアルゴリズムが考えられる。

（３．４．１．１ 要求時間でのアプリケーション提供）
クライアントデバイス３０からの要求がＭｅｒｖｌｅｔ１０のためのサーバ３２で受けられる場合、当該要求は、以下の構造を有している。

ＵＲＩ
クライアントにおけるＭＩＰＳ等級
クライアントにおけるＣＰＵ稼動時間の平均および分散
クライアントにおける利用可能なデバイスメモリおよび固定記憶域（所定の時間にわたって平坦化される）
｛性能属性、アプリケーションにおけるデータサイズ｝

Ｍｅｒｖｌｅｔ１０の性能属性は、クライアント３０上の１つのファイルで維持されるとともに、ＭｅｒｖｌｅｔＵＲＩにより、また、随意的にはユーザにより、インデックスが付される。

その後、サーバ３２上のポリシーＭｅｒｖｌｅｔモジュール６６は、サーバ自身の性能データベースを調査し、以下のデータを検索する。

サーバにおけるＣＰＵ稼動時間の平均および分散
各アクセスリンクにおける待ち時間並びにネットワーク帯域幅の平均および分散
サーバに付随する
｛性能属性、アプリケーションにおけるデータサイズ｝

アプリケーション提供アルゴリズムは、クライアント３０またはサーバ３２またはこれらの組み合わせから得られるアプリケーション属性を使用して、Ｍｅｒｖｌｅｔ１０が実行されるべきデバイスを選択することができる。

サーバ３２は、新たなＭｅｒｖｌｅｔまたはその性能属性が新しくないＭｅｒｖｌｅｔをロードバランシングしようとする場合、ネットワーク中の他のデバイス上におけるＭｅｒｖｌｅｔの最近の実行から、性能属性に関する値を得ることができる。あるいは、サーバ３２は、それが記憶された同様のデバイスおよびネットワーク上の同様のアプリケーションにおける性能属性のキャッシュされた値を使用することができる。新しさの基準は、システムアドミニストレータによって設定される。

（３．４．１．２ ランタイムでのアプリケーション提供）
現在実行しているＭｅｒｖｌｅｔをロードバランシングするため、要求しているクライアント３０は、その性能が特定の閾値を超えて低下したか否かを判断して、この情報をサーバ３２に送る。具体的には、Ｍｅｒｖｌｅｔ１０がサーバ３２上で実行し、クライアント３０がそれに遠隔的にアクセスしている間、クライアントは、クライアントからの全てのユーザインタフェースイベントに関する待ち時間の平均および分散を監視する。Ａ（Ｗ）またはＶ（Ｗ）が所定の閾値に達すると、クライアント３０は、以下の情報を含むメッセージをサーバ３２に送る。

クライアントにおけるＭＩＰＳ等級
クライアントにおけるＣＰＵ稼動時間の平均および分散
クライアントにおける利用可能なデバイスメモリおよび固定記憶域（所定の時間にわたって平坦化される）
｛性能属性｝

その後、サーバ３２は、Ｍｅｒｖｌｅｔ１０が代わりにクライアント３０上で実行するべきか否かを判断する。実行すべき場合には、Ｍｅｒｖｌｅｔおよびその性能属性がクライアントに移動される。サーバは、クライアントがその保存状態を使用してＭｅｒｖｌｅｔの実行を再開できるように、Ｍｅｒｖｌｅｔがシャットダウンされて再配置される前に、Ｍｅｒｖｌｅｔの状態を保存しても良い。

（３．４．２ ネットワーク切換え最適化）
図１０には、決定ツリーを使用して、ネットワーク切換えアルゴリズムの実施例が示されている。このネットワーク切換えアルゴリズムは、Ｍｅｒｖｌｅｔアプリケーション環境のクライアント３０およびサーバ３２によって実行することができる。クライアントおよびサーバが複数のアクセスネットワークを使用して通信できると仮定すると、ネットワーク切換えアルゴリズムは、待ち時間の平均および分散を下げるために、アクセスネットワークを切換えることができる。ユーザは、サーバ３２から、あるいは、他のデバイスから、クライアントデバイス３０上に様々なネットワーク切換えアルゴリズムをインストールすることができる。

最初に、ステップ７０において、ネットワーク切換えアルゴリズムは、現在のアクセスネットワークを使用して、Ｍｅｒｖｌｅｔにおける平均待ち時間が所定のＡＷ＿ｔｈｒｅｓｈｏｌｄ値よりも長いか否かを判断するとともに、Ｍｅｒｖｌｅｔにおける平均通信時間が所定のＡＣ＿ｔｈｒｅｓｈｏｌｄ値よりも長いか否かを判断する。これらの条件が満たされ且つネットワーク切換えオーバーヘッドが所定のＳＯ＿ｔｈｒｅｓｈｏｌｄ値よりも小さい場合、ネットワーク切換えアルゴリズムは、ステップ７４から８２において、アクセスネットワークを切換えることを試みる。システムアドミニストレータによって設定された関係を使用して、Ｍｅｒｖｌｅｔのサイズに基づいて、ネットワーク切換えオーバーヘッドが計算され得る。以上の条件が満たされない場合には、ステップ７２において、現在のアクセスネットワークが使用されたままとなる。

次に、ステップ７４において、アルゴリズムは、利用可能な全てのアクセスネットワークにわたるアプリケーションの待ち時間の平均および分散を計算する。その後、アルゴリズムは、一群の利用可能なアクセスネットワークにおける最小の平均待ち時間を特定する。ステップ７６において、最小平均待ち時間が所定のＡＷ＿ｔｈｒｅｓｈｏｌｄ値よりも短く且つ１つのアクセスネットワークＮＮだけがそれと一致している場合、ステップ７８において、アルゴリズムは、そのアクセスネットワークＮＮに切換えるようにデバイスに指示する。

ステップ８０において、最小平均待ち時間が所定の平均閾値よりも短く且つ２つ以上のアクセスネットワークがそれと一致する場合、ステップ８２において、アルゴリズムは、待ち時間の分散が最も小さい特定されたグループの中からアクセスネットワークを選択する。また、アクセスネットワークを切換えるためのこれらの条件が何れも満たされない場合、ステップ８４において、現在のアクセスネットワークが使用されたままとなる。

あるいは、アルゴリズムは、その平均待ち時間が現在使用されているアクセスネットワークにおける平均待ち時間よりも所定の閾値Ｔ−ｍｅａｎｗａｉｔだけ短いアクセスネットワークを見つけた場合、アクセスネットワークを切換えることができる。全てのアクセスネットワークにおける平均待ち時間は略同一であるが、待ち時間の分散が現在使用されているネットワークにおける待ち時間の変動よりも所定の閾値Ｔ−ｖａｒｉａｎｃｅＭｅａｎｗａｉｔだけ小さいアクセスネットワークが存在する場合、アルゴリズムは、このネットワークに切換えることができる。

（３．５ 稼動時間の平坦化）
稼動時間の平坦化（スムージング）は、ロードバランシング中においてスラッシングを防止できる技術である。特に、Ｍｅｒｖｌｅｔアプリケーション環境は、単に、期間Ｔ毎にＮ個のネットワーク切換えイベントを許容するだけである。これらのパラメータは、システムの個々の実施に伴って変化することができ、また、ネットワークのシステムアドミニストレータによって設定され得る。クライアントにおける以下のアルゴリズムを使用して、ネットワーク切換えアルゴリズムにおけるスムージングインターバルを決定することができる。

各クライアントは、そのピア（同等物）の各々によって期間Ｔに成される切換えのリストを有している。ピア群は、動的に形成され、あるいは、サーバから要求され得る。クライアントは、ネットワークを切換える度に、その情報を特別のネットワークを使用してその近隣のクライアントにブロードキャストする。期間Ｔにおける切換えイベントの数がＮ個を下回る場合にだけ、切換えアルゴリズムが実行される。しかしながら、リンクそれ自体が機能しなくなる時、アルゴリズムは、ネットワークを即座に切換えるように構成されても良い。あるいは、サーバは、最近成された切換えのリストを維持するとともに、その情報を、アプリケーション属性の更新を要求している各クライアントに対して送っても良い。

（４．フォールト・トレランス・スキーム）
Ｍｅｒｖｌｅｔアプリケーション環境により、システムアドミニストレータは、２つのコンポーネント、すなわち、クラッシュから回復できるＭｅｒｖｌｅｔエンジン１０と、トランジット中のメッセージが少なくとも１度のセマンティクスで供給されることを保証する信頼できるメッセージングシステム２０と、を使用して、システムが許容すべき故障のタイプを選択することができる。信頼できるメッセージングシステム２０は、以下のように、すなわち、フォールトトレランスが無い、クライアントおよびネットワークの故障から回復することができる、クライアント、ネットワーク及びサーバの故障から回復することができる、というように構成され得る。

例えば、複数のクライアントからの要求処理中、または、１つのサーバからの応答中に、サーバ及びＵＣＤ間へのネットワーク接続が損なわれるかもしれない。必要に応じて、再接続時、サーバは、Ｍｅｒｖｌｅｔを実行すべき場所を決定するための決定アルゴリズムを自動的に実行する。また、システムアドミニストレータは、システムコンポーネントをフォールトトレラントするか否かを選択することができる。交換条件は、必要とされる信頼性と比較検討されなければならない性能関係をフォールトトレランスが有しているということである。本発明に係るフォールトトレランス方法論は、コンポーネントの回復に関連付けられたコスト及びその対応するコストに基づいて、モバイルシステムにおける様々な故障を特徴付ける。それから、本発明に係るフォールトトレランス方法論により、システムアドミニストレータは、回復すべきコンポーネントを選択することができる。

当業者であれば容易に分かるように、本発明のフォールトトレランススキームは、後述する信頼できるメッセージングシステムおよび回復可能なアプリケーションエンジンを有する他のモバイルアプリケーションのための実行環境を使用して実施されても良く、Ｍｅｒｖｌｅｔに限定されない。

（４．１ 回復可能なＭｅｒｖｌｅｔエンジン）
Ｍｅｒｖｌｅｔエンジン１２は、現在実行している全てのＭｅｒｖｌｅｔ１０及びそれぞれにおける最近のＭｅｒｖｌｅｔのｃｏｎｔｅｘｔのリストを含むその状態を、固定記憶域に定期的に記憶する。また、リストには、各アプリケーションの優先順位が含まれていても良い。また、エンジン１２は、そのアプリケーション状態を固定記憶域に保存するために、Ｍｅｒｖｌｅｔ１０上でメソッドＳａｖｅ（）を任意のタイミングで呼び出すことができる。

Ｍｅｒｖｌｅｔエンジン１２は、それ自身の状態を元に戻して、クラッシュ時にデバイス上で実行していたＭｅｒｖｌｅｔのセットを再起動することができる。Ｍｅｒｖｌｅｔエンジン１２は、そのリスト上の各Ｍｅｒｖｌｅｔ１０を１つずつ再起動する。Ｍｅｒｖｌｅｔを再起動する順番は、それらの優先順位に依存し得る。デバイス故障後にＭｅｒｖｌｅｔが再起動されると、Ｍｅｒｖｌｅｔ１０は、ランタイムエンジン１２を用いて、メソッドＲｅｓｔｏｒｅ（Ａｐｐｌｉｃａｔｉｏｎ Ｃｏｎｔｅｘｔ）を実行することができる。データオブジェクトＡｐｐｌｉｃａｔｉｏｎ Ｃｏｎｔｅｘｔは、アプリケーション及びそのコンテキストを特定するランタイムエンジンのリストからのデータを含んでいる。メソッドＲｅｓｔｏｒｅ（Ａｐｐｌｉｃａｔｉｏｎ Ｃｏｎｔｅｘｔ）は、ローカル通信バッファの状態を読み取ってクライアント３０上のＭｅｒｖｌｅｔのための信頼できるメッセージングシステム２０の通信状態を特定することを含む、Ｍｅｒｖｌｅｔ固有の回復作業を実施することができる。また、メソッドＲｅｓｔｏｒｅ（Ａｐｐｌｉｃａｔｉｏｎ Ｃｏｎｔｅｘｔ）は、サーバ３２上のＭｅｒｖｌｅｔのための信頼できるメッセージングシステム２０の通信状態を問い合わせることもできる。当該メソッドは、Ｍｅｒｖｌｅｔ１０が元の状態に戻った後、制御をＭｅｒｖｌｅｔエンジン１２に戻すことができる。

（４．２ 信頼できるメッセージングシステム）
Ｍｅｒｖｌｅｔアプリケーション環境のメッセージングシステム２０は、様々なメッセージングプロトコルを使用して、Ｍｅｒｖｌｅｔ間の通信およびネットワーク内でのＭｅｒｖｌｅｔ自身の転送を容易にする。例えば、役に立つと見なされたメッセージングプロトコルのタイプには、同期可能または非同期可能な、一方向プロトコルおよび要求−応答プロトコルが含まれている。進行中のトランザクションが保存されることを保証するように、メッセージングシステム２０がフォールトトレラントであっても良い。しかしながら、信頼できるメッセージングシステムは、デバイス故障後にＭｅｒｖｌｅｔ自身を回復させることの責任は負わない。

特に、図１１に示される信頼できるメッセージングシステム７０は、クライアント側にキュー（待ちライン）７２を有しており、これにより、クライアント３０から発信する全ての通信がバッファに蓄えられる。バッファは、ユーザが構成可能な大きさを有している。また、各メッセージが固有の連続番号でタグ付けされるとともに、各要素毎に応答が求められる。応答が受けられない場合、メッセージは、応答が受けられるまで再送信される。応答が受けられると、バッファに記憶された適当なメッセージがシステムから解放される。

デバイスに内在するオペレーティングソフトウェアまたはＭｅｒｖｌｅｔ１０内の高レベルイベントに対して応答が関連付けられるように、信頼できるメッセージングシステム７０が実行されても良い。一般的なアプリケーション通信においては、内在するソフトウェアに対して応答が関連付けられるような一般的な形式が使用される。システムレベルの信頼できる通信の場合、バッファリング機構は、より低いオーバーヘッドのためにＭｅｒｖｌｅｔエンジンによって受けられる要求に対して関連付けられる。

信頼できるメッセージングシステム７０を実行するため、以下のＡＰＩが与えられる

ｖｏｉｄ Ｒｅｌｉａｂｌｅ＿ａｓｙｎｃ＿ｓｅｎｄ（Ｅｎｄｐｏｉｎｔ ｔｏ， Ｅｎｄｐｏｉｎｔ Ｆｒｏｍ， ＭｅｓｓａｇｅＤａｔａ Ｄａｔａ， Ｒｅｌｉａｂｉｌｉｔｙ Ｔｙｐｅ， ＣａｌｌｂａｃｋＭｅｔｈｏｄ ｃｍ）

「ｔｏ」フィールドは受信側を特定する。「ｆｒｏｍ」フィールドは送信元を特定する。「ｄａｔａ」フィールドは、順番に並べられた送信されるデータである。「ｔｙｐｅ」は、アプリケーションレベルまたはシステムレベルである。コールバックメソッドは、承認が得られた時に呼び出される。このＡＰＩを使用すると、システムは、少なくとも１つのメッセージ送出を保証することができる。

信頼できるメッセージングシステム７０のためのメッセージフォーマットが図１２に示されている。メッセージフォーマットは、６つのフィールドの全てを有している。この場合、最初の４つのフィールドはサイズが固定されており、データセグメントはサイズが可変であり、チェックサムは、可変であるとともに、全てのフィールドにわたって計算される。個々のメッセージのデータペイロード内にＭｅｒｖｌｅｔ自体を含めることにより、信頼できるメッセージングシステム７０を使用して、ネットワーク内でＭｅｒｖｌｅｔを再配置することができる。

図１３に示される動作時、メソッドＲｅｌｉａｂｌｅ＿ａｓｙｎｃ＿ｓｅｎｄを呼び出すことによりステップ１０２においてクライアントアプリケーションがサーバ上のＭｅｒｖｌｅｔに対してメッセージを送信する度に、クライアント３０上の信頼できるメッセージングシステム７０は、ステップ１０４において、フラッシュメモリやマイクロドライブ等のクライアントの固定記憶域に使用可能なバッファ空間が存在するか否かを確認する。最大のバッファ空間は、システムアドミニストレータにより、所定の値ＭＡＸ＿ＢＵＦに設定される。利用可能な十分なバッファ空間が存在する場合、ステップ１０６において、メッセージがバッファに蓄えられ、信頼できるメッセージングシステム７０のバッファマネージャは、当該メッセージに連続番号を付ける。固有の連続番号を用いて２対のマシン間で全てのメッセージが送信される。メッセージがバッファに蓄えられると、呼び出しはクライアントアプリケーションに戻ることができる。呼び出しは、メッセージが固定記憶域にバッファリングされるまで、クライアントアプリケーションに戻らない。呼び出しが戻ると、クライアントアプリケーションは、たとえクライアントデバイスまたはネットワークが機能しなくなる場合であっても、メッセージが適切なＭｅｒｖｌｅｔに送られることが保証される。

バッファマネージメントスレッドが定期的に起動し、ステップ１０８において、バッファリングされたメッセージをサーバ３２に送信するとともに、先に送られたメッセージへの応答を待つ。各メッセージは、当該メッセージに関連付けられた所定のタイムアウト値を有している。メッセージ応答がタイムアウト期間内に受けられないと、メッセージが再送信される。このプロセスは、応答が受けられるまで続く。バッファマネージメントスレッドは、アクセスネットワーク３８が作動し且つプライマリサーバ３２への経路が確立された時にのみトリガされる。

ステップ１１０において、サーバ上で要求メッセージを受け取ると、システムアドミニストレータは、信頼できるメッセージングシステム７０が当該メッセージをいかに処理してサーバ上のＭｅｒｖｌｅｔへと供給すべきか、を選択することができる。例えば、システムは、ステップ１１２において、メッセージをＭｅｒｖｌｅｔに即座に供給することができ、その後、ステップ１１４において、ハードディスク等の固定記憶域にメッセージを記憶することができる。これは、メッセージが「安全な」状態でない時間を増大させるが、Ｍｅｒｖｌｅｔにメッセージへの迅速なアクセスを与える。あるいは、ステップ１１６において、サーバ３２上の信頼できるメッセージングシステム７０は、メッセージを受け取った時に、そのメッセージを固定記憶域に記録することができ、その後、ステップ１１８において、当該メッセージをＭｅｒｖｌｅｔに対して配信する。その後、Ｍｅｒｖｌｅｔは、メッセージを処理して（ステップ１２２）、応答を生成する（ステップ１２４）。また、Ｍｅｒｖｌｅｔは、信頼できるメッセージングシステム７０に対して生成した応答を送信する。システムは、ステップ１２６で応答を記録し、その後その応答を、ステップ１２８で、対応する要求を発したクライアントに送ろうとする。この時点で、要求メッセージは、ステップ１３０において、サーバ上の固定記憶域バッファから除去される。

クライアントは、応答を受ける（ステップ１３２）と、固定記憶域のバッファ内に当該応答を即座に記憶する（ステップ１３４）。その後、クライアントは、サーバに送られた適合する要求メッセージを見つけ、ステップ１３６において、その要求メッセージをバッファから除去する。次に、ステップ１３８において、クライアントは、クライアントアプリケーションからの適当なコールバックメソッドへの応答を供給しようとする。コールバックメソッドが呼び出されると、ステップ１４０において、応答が解放される。より高い連続番号を有する同じクライアントからの次のメッセージが受けられると、ステップ１２０において、応答のためのバッファがサーバ上で解放される。二重メッセージがサーバによって受けられると、この二重メッセージは処分される。承認バッファのサイズは、システムアドミニストレータによりＡＣＫ＿ＢＵＦに設定される。

（４．２．１ プライマリサーバへの接続の検索）
信頼できるメッセージングシステム７０は、クライアントデバイス３０とサーバ３２との間の接続を管理する。システムは、定期的に起動して、以下のタスクを行なう。システムは、Ｂｌｕｅｔｏｏｔｈ、８０２．１１ｂ（Ｗｉ−Ｆｉ）無線、ＩＲＤＡ、汎用パケットラジオサービス（ＧＰＲＳ）携帯電話ネットワーク８０２．１１ｂ等の任意のクライアントアクセスネットワークによってプライマリサーバ３２が到達できるか否かを確認する。システムは、ＩＣＭＰ Ｐｉｎｇをプライマリサーバ３２に送ることにより、前記確認を行なう。クライアント３０とサーバ３２との間の更なる通信のため、最も適切と思われる第１のアクセスネットワークが使用される。また、信頼できるメッセージングシステム７０は、そのバッファマネージメントスレッドを起動し、サーバ３２と通信するために使用するべきプロトコルを前記スレッドに知らせる。

（４．２．２ 構成可能性）
フォールトトレランスは、全てがディスクコストタイムおよびディスクスペースに書き込むため、コストがかかる。次に、図１４を参照すると、信頼できるメッセージングシステム７０を実行するための幾つかのコンフィギュレーションが示されている。第１列は、メッセージがサーバ３２およびクライアント３０に記録される技術を示しており、第２列は、メッセージがクライアント３０だけに記憶されることを示しており、第３列は、メッセージが記録されない技術を示している。最初の２つの選択肢は、フォールトトレランスにおける以下の選択を与える。ユーザがランタイムコストを下げることを望み、アプリケーションの回復において時間を惜しみなく費やす場合には、第２の選択肢が考慮されても良い。第１の選択肢は、メッセージがクライアントおよびサーバに記録されるため、高いランタイムコストを有している。しかし、ユーザにとっての利点は、信頼できるメッセージングシステムを使用するアプリケーションの回復がより強力に成されるという点である。

（４．３ 故障の対処）
サーバ３２は、故障から回復すると、図１３に示されるステップ１０６で記憶されたその固定記憶域にあるバッファリストを見る。信頼できるメッセージングシステム７０は、デバイスの固定記憶域上のデータがデストロイされていない一方でデバイスのメインメモリ内のデータがデストロイされていると見なす。前記リストがクライアント３０からのメッセージを含んでいる場合、信頼できるメッセージングシステム７０は、要求が処理されなかったと見なし、メッセージをサーバ上の適当なＭｅｒｖｌｅｔに供給することを試みる。同様に、クラッシュからの回復後に、サーバ３２がバッファリングされた応答を見つけると、システムは、それを、適切な送信先のクライアント３０に送る。

Ｍｅｒｖｌｅｔアプリケーション環境全体をクラッシュからうまく回復させるため、以下の一連の回復作業が使用される。

１）信頼できるメッセージングシステム７０を、一致した状態にする。
２）後述するキャッシング・インフラストラクチャを、一致した状態にする。
３）Ｍｅｒｖｌｅｔエンジン１２を、一致した状態にする。
４）個々のＭｅｒｖｌｅｔ１０を、順次に一致した状態にする。

（５．切断モード計算）
クライアントデバイス３０は、例えばネットワーク帯域幅の利用を減らすため、２つの契機、すなわち、ネットワーク故障またはシステムアドミニストレータ或はユーザによる自発的な移動、により、サーバ３２または他のデバイスから「切断され」ても良い。Ｍｅｒｖｌｅｔアプリケーション環境は、ネットワークから切断された状態での作業をサポートするために、２つの特徴、すなわち、信頼できる非同期のメッセージングおよびＭｅｒｖｌｅｔキャッシングを提供する。

ネットワーク接続がクライアントとサーバとの間に存在しない場合、信頼できる非同期メッセージングにより、クライアント３０またはサーバ３２でメッセージがキューに入れられ得る。アプリケーションがメッセージを送ると、メッセージは、前述したように、ローカルに、バッファに記憶され、あるいは、キューに入れられる。ネットワーク接続が確立された時にだけ、メッセージが送られる。ネットワーク接続が回復されると、信頼できる非同期メッセージングシステムは、バッファキュー内で待っているメッセージを再送信する。また、信頼できるメッセージングシステム７０は、固定記憶域内にメッセージキューを保存することができ、これにより、前述したように、デバイスおよびサーバ故障を許容することができる。

切断モード計算のための第２の機構は、クライアントデバイス３０上のローカルキャッシュ内にＭｅｒｖｌｅｔを記憶することを要求する。キャッシュメモリは、図１に示されるキャッシュマネージャ２２によって管理される。キャッシュは、ネットワーク接続が無くても、ブラウザまたは他のクライアントアプリケーションからアクセス可能である。クライアント３０がネットワークから切断されても、キャッシュ上のＭｅｒｖｌｅｔは、依然として、ローカルブラウザから利用することができる。また、ローカルブラウザは、依然として、ローカルキャッシュからＭｅｒｖｌｅｔを呼び出すことができる。

キャッシュは、様々な方法で管理することができるが、キャッシュは、ホアーディング（ｈｏａｒｄｉｎｇ）等の技術を使用したインテリジェント・プレフェッチングを許容することが好ましい。将来のＭｅｒｖｌｅｔアクセスに関する多くの知識をサーバが有している状態で、例えば、協調的な設定で、あるいは、情報が積極的にクライアントデバイス３０へと押し出される設定で、Ｍｅｒｖｌｅｔキャッシング機構により、クライアント３０は、様々なキャッシュ管理決定をサーバ３２に委託することができる。したがって、クライアント３０によって、サーバ３２によって、あるいは、両者の組み合わせによって、キャッシュ管理ポリシーを設定することができる。ランタイムで、サーバ３２は、キャッシュ交換を更新して、クライアントデバイス３０のキャッシュに記憶された各Ｍｅｒｖｌｅｔ１０毎にポリシーを書き込むことができる。

更に、当業者であれば分かるように、必要に応じて、キャッシュマネージャ２２は、コードおよびデータを別個に処理するキャッシングアルゴリズムを実行することができる。また、キャッシュは、キャッシュ管理アルゴリズムにデバイス特性および個々のユーザの利用プロファイルを考慮しても良い。

一実施例に係るキャッシュマネージャ２２は、ｐｒｅ＿ｆｅｔｃｈ ｃｌａｓｓのメソッドを呼び出して、プレフェッチングを実行し、ｃａｃｈｅ＿ｍｉｓｓ ｃｌａｓｓを呼び出して、キャッシュミスの対処を行ない、ｃａｃｈｅ＿ｗｒｉｔｅ ｃｌａｓｓを呼び出して、キャッシュへのデータ書き込みを行なう。

プレフェッチ作業は、サーバで開始され、あるいは、クライアントで開始される。プレフェッチがサーバで開始される場合、サーバ３２は、プレフェッチ通知をクライアント３０に送る。クライアント３０は、キャッシュ状態ベクトルを送り戻す。その後、サーバは、ドキュメントの新たなセットをクライアントに送り、また、随意的に、新たな交換ポリシーをクライアントに送る。また、サーバ３２は、クライアントデバイス３０上でＭｅｒｖｌｅｔ１０を実行するための要求を行なう。Ｍｅｒｖｌｅｔ１０がクライアント３０上で実行されると、クライアントは、キャッシュ状態ベクトルをサーバ３２に送り戻す。その後、サーバ３２は、キャッシュオブジェクトのセットをＭｅｒｖｌｅｔ１０に送るとともに、交換ポリシーを送る。次に、Ｍｅｒｖｌｅｔ１０は、サーバ３２に呼び返して、新たな交換ポリシーのためのクラスをロードする。

キャッシュミスに対処するため、クライアント３０上のキャッシュマネージャ２２は、ドキュメントが見当たらないことを示す要求をプライマリサーバ３２に送るとともに、ミスが起きた時のローカルキャッシュ状態のベクトルを送る。ベクトルは、キャッシュのサイズと、サーバへの最後の更新以後におけるキャッシュのためのハッシュテーブルへの任意の変更と、を含んでいる。プライマリサーバ３２は、要求されたドキュメントを送り戻す。また、プライマリサーバは、他のプレフェッチされたドキュメントおよび交換ポリシーを送り戻しても良い。クライアント３０は、この新たな交換ポリシーをそのキャッシュ上で使用する。以下は、このメソッドを示す擬似コードである。

Ｖｏｉｄ ｈａｎｄｌｅ＿ｃａｓｈｅ＿ｍｉｓｓ（）
Ｓｅｎｄ（ｐｒｉｍａｒｙ＿ｓｅｒｖｅｒ， ｈａｓｈ＿ｖｅｃｔｏｒ＿ｄｉｆｆ， ｕｒｉ）
Ｒｅｃｅｉｖｅ（ｃａｃｈｅ＿ｏｂｊｓ， ｎｅｗ＿ｐｏｌｉｃｙ）
ｉｆ（ｎｅｗ＿ｐｏｌｉｃｙ） ｌｏａｄ＿ｃｌａｓｓ（ｎｅｗ＿ｐｏｌｉｃｙ）；
ｒｅｔｕｒｎ；

クライアント３０がそのキャッシュのための新たなＭｅｒｖｌｅｔ１０のリストを要求すると、サーバ３２は、それらを送り戻すとともに、随意的に、交換ポリシーを送り戻す。再度、クライアントは、積極的に、交換を実行する新たなクラスをダウンロードする。

クライアント３０のローカルキャッシュのための書き込みポリシーは、サーバ３２からダウンロードされる新たなクラスを使用して、キャッシュマネージャ２２により変更されても良い。キャッシュ内の各要素毎に、サーバ３２は、オブジェクトがキャッシュから出される時にダーティーオブジェクトまたは書き込まれたオブジェクトをどのように扱うかに関するポリシーを添付することができる。したがって、キャッシングシステムは、システムがキャッシングを行なうか否かを選択するように構成することができる。これは、動的選択またはランタイム選択である。また、キャッシングシステムそれ自体は、３つの領域、すなわち、交換ポリシー、プレフェッチポリシー、修正データ管理ポリシー、で動的に拡張可能である。

特定の例示的な実施形態を参照しながら本発明を説明してきたが、本発明がこれらの例示的な実施形態に限定されることを意図するものではない。当業者であれば分かるように、以下の請求の範囲によって規定された本発明の真の範囲および思想から逸脱することなく、変形および変更を行なうことができる。したがって、添付の請求の範囲およびその等価物に入るそのような全ての変形および変更が本発明に含まれることを意図している。

本発明に係るＭｅｒｖｌｅｔアプリケーション環境のシステムコンポーネントを示すブロック図である。 図１のＭｅｒｖｌｅｔアプリケーション環境の動作の詳細を示すフローチャートである。 図１のＭｅｒｖｌｅｔアプリケーション環境のためのモバイル通信ネットワークの高レベルビューを示すブロック図である。 図１のＭｅｒｖｌｅｔアプリケーション環境におけるＭｅｒｖｌｅｔアプリケーションの構造およびその属性を示すブロック図である。 図１のＭｅｒｖｌｅｔアプリケーション環境におけるＭｅｒｖｌｅｔアプリケーションのライフサイクルを示すブロック図である。 図１のＭｅｒｖｌｅｔアプリケーション環境におけるＭｅｒｖｌｅｔエンジンの全体構造およびステップを示すブロック図である。 図１のＭｅｒｖｌｅｔアプリケーション環境におけるユーザインタフェースイベントのためのタイムラインを示すブロック図である。 図１のＭｅｒｖｌｅｔアプリケーション環境における性能属性およびシステム属性を要約する表である。 図１のＭｅｒｖｌｅｔアプリケーション環境におけるＭｅｒｖｌｅｔをロードバランシングするためのアプリケーション提供最適化の詳細を示すフローチャートである。 図１のＭｅｒｖｌｅｔアプリケーション環境におけるＭｅｒｖｌｅｔをロードバランシングするためのネットワーク切換え最適化の詳細を示すフローチャートである。 図１のＭｅｒｖｌｅｔアプリケーション環境におけるＭｅｒｖｌｅｔエンジンと信頼できるメッセージシステムとの間のインタフェースを示すブロック図である。 図１１の信頼できるメッセージングシステムにおけるメッセージの構造を示す図である。 図１１の信頼できるメッセージングシステムの動作の詳細を示すチャートである。 図１１の信頼できるメッセージングシステムにおける様々なコンフィギュレーション及び対応する性能コストを示す表である。

Claims (125)

1. 少なくとも１つのアクセスネットワークの一部を形成するモバイルアプリケーション環境であって、
   動的ウェブページを形成するための命令のセットを含むＭｅｒｖｌｅｔアプリケーションであって、前記Ｍｅｒｖｌｅｔは、それぞれが前記少なくとも１つのアクセスネットワークに接続されるローカルノードおよびサーバノードのうちの少なくとも一方で実行することができ、これにより、前記ローカルノードで実行しているクライアントアプリケーションからの要求に応じて、前記動的ウェブページを前記ローカルノードに表示する、Ｍｅｒｖｌｅｔアプリケーションと、
   前記Ｍｅｒｖｌｅｔのユーザ認識性能を特徴付けるための少なくとも１つの性能属性を含む、前記Ｍｅｒｖｌｅｔに関連付けられた少なくとも１つのアプリケーション属性と、
   前記Ｍｅｒｖｌｅｔに関連付けられるとともに、前記少なくとも１つのアプリケーション属性に基づいて前記ローカルノードと前記サーバノードとの間で前記Ｍｅｒｖｌｅｔの実行を与えるようになっている命令の第１のセットを有するポリシーモジュールを含む、Ｍｅｒｖｌｅｔエンジンと、
   を備えたことを特徴とするモバイルアプリケーション環境。
2. 前記Ｍｅｒｖｌｅｔを実行するためのセキュリティコンテキストを規定するために前記Ｍｅｒｖｌｅｔに関連付けられた少なくとも１つのセキュリティ属性を更に備え、
   前記Ｍｅｒｖｌｅｔエンジンは、前記セキュリティコンテキスト内で前記Ｍｅｒｖｌｅｔを実行するようになっているコアインタープリタモジュールを更に有している
   ことを特徴とする請求項１に記載のアプリケーション環境。
3. 動的ウェブページを形成するための前記命令のセットは、前記ウェブページのための動的なコンテンツを生成するアプリケーション命令のセット、および、前記ウェブページ上での表示のために前記動的なコンテンツをフォーマットするユーザインタフェース命令のセットのうちの少なくとも一方を含んでいる
   ことを特徴とする請求項１に記載のアプリケーション環境。
4. 前記アプリケーション命令のセットは、前記Ｍｅｒｖｌｅｔに関連付けられた少なくとも１つのＭｅｒｖｌｅｔタグライブラリ内に存在するアプリケーションロジックをカプセル化する解釈されないプログラムコードを含んでいる
   ことを特徴とする請求項３に記載のアプリケーション環境。
5. 前記ユーザインタフェース命令のセットは、ウェブブラウザによって解釈可能な静的なフォーマットタグを含んでいる
   ことを特徴とする請求項３に記載のアプリケーション環境。
6. 前記Ｍｅｒｖｌｅｔエンジンは、前記ローカルノードおよびサーバノードのうちの少なくとも一方に記憶された前記Ｍｅｒｖｌｅｔを見つけ且つ前記Ｍｅｒｖｌｅｔが前記ローカルノードに記憶される時に前記クライアントアプリケーションから前記Ｍｅｒｖｌｅｔへの要求を処理するようになっているファインダモジュールを更に有している
   ことを特徴とする請求項１に記載のアプリケーション環境。
7. 前記Ｍｅｒｖｌｅｔエンジンは、前記Ｍｅｒｖｌｅｔが前記サーバノードに記憶される時に前記クライアントアプリケーションから前記Ｍｅｒｖｌｅｔへの要求を処理するようになっているインターセプティングモジュールを更に有している
   ことを特徴とする請求項１に記載のアプリケーション環境。
8. 前記少なくとも１つの性能属性は、前記アプリケーションにおけるユーザインタフェースイベントのための待ち時間に関する少なくとも１つのパラメータを含み、
   前記待ち時間は、サーバ計算時間および通信時間を含んでいる
   ことを特徴とする請求項１に記載のアプリケーション環境。
9. 待ち時間に関する少なくとも１つの前記パラメータは、前記待ち時間、前記サーバ計算時間及び前記通信時間の平均と、前記待ち時間、前記サーバ計算時間及び前記通信時間の分散と、のうちの少なくとも一つを含んでいる
   ことを特徴とする請求項８に記載のアプリケーション環境。
10. 前記サーバ計算時間は、内部計算時間およびデータＩ／Ｏ時間を含んでいる
    ことを特徴とする請求項９に記載のアプリケーション環境。
11. 前記少なくとも１つの性能属性は、前記アプリケーションが終了まで実行する総使用時間を更に含んでいる
    ことを特徴とする請求項９に記載のアプリケーション環境。
12. 前記少なくとも１つの性能属性は、アプリケーション毎に測定される
    ことを特徴とする請求項１に記載のアプリケーション環境。
13. 前記少なくとも１つの性能属性は、デバイス毎のアプリケーション毎に測定される
    ことを特徴とする請求項１に記載のアプリケーション環境。
14. 前記少なくとも１つの性能属性は、ユーザ毎のデバイス毎のアプリケーション毎に測定される
    ことを特徴とする請求項１に記載のアプリケーション環境。
15. 前記少なくとも１つの性能属性は、アクセスネットワーク毎のユーザ毎のデバイス毎のアプリケーション毎に測定される
    ことを特徴とする請求項１に記載のアプリケーション環境。
16. 前記少なくとも１つのアプリケーション属性は、前記ローカルノード、前記サーバノード及び前記少なくとも１つのアクセスネットワーク、のうちの少なくとも１つの計算能力を特徴付けるための、少なくとも１つのシステム属性を更に含んでいる
    ことを特徴とする請求項１に記載のアプリケーション環境。
17. 前記ローカルノードの能力を特徴付けるためのシステム属性は、前記ローカルノードのプロセッサの稼動時間の測定に関するパラメータ、前記プロセッサのＭＩＰＳ等級、前記ローカルノードにおける固定記憶域のメモリサイズおよび大きさ、のうちの少なくとも１つを含んでいる
    ことを特徴とする請求項１６に記載のアプリケーション環境。
18. 前記サーバノードの能力を特徴付けるためのシステム属性は、前記サーバノードのプロセッサの稼動時間の測定に関するパラメータ、前記プロセッサのＭＩＰＳ等級、前記サーバノードにおける固定記憶域のメモリサイズおよび大きさ、のうちの少なくとも１つを含んでいる
    ことを特徴とする請求項１６に記載のアプリケーション環境。
19. 前記少なくとも１つのアクセスネットワークの能力を特徴付けるためのシステム属性は、ネットワーク帯域幅、ネットワーク待ち時間及びネットワーク状態、のうちの少なくとも１つを含んでいる
    ことを特徴とする請求項１６に記載のアプリケーション環境。
20. 前記ポリシーモジュールは、前記少なくとも１つのアプリケーション属性に基づいて、前記ローカルノードと前記サーバノードとの間で通信するためのアクセスネットワークを選択するようになっている命令の第２のセットを更に有している
    ことを特徴とする請求項１に記載のアプリケーション環境。
21. 前記Ｍｅｒｖｌｅｔエンジンは、実行しているＭｅｒｖｌｅｔアプリケーションのリストと前記実行している各Ｍｅｒｖｌｅｔ毎のアプリケーションコンテキストとを含む前記エンジンの実行状態を保存して元の状態に戻すようになっている回復モジュールを有している
    ことを特徴とする請求項１に記載のアプリケーション環境。
22. 前記Ｍｅｒｖｌｅｔと前記クライアントアプリケーションとの間でメッセージを送信するとともに、前記Ｍｅｒｖｌｅｔ、前記少なくとも１つのアプリケーション属性、前記少なくとも１つのセキュリティ属性及び前記少なくとも１つのＭｅｒｖｌｅｔタグライブラリをアクセスネットワークを介して前記ローカルノードと前記サーバノードとの間で移動させるようになっているメッセージングシステムを更に備えている
    ことを特徴とする請求項１に記載のアプリケーション環境。
23. 前記メッセージングシステムは、一方向同期メッセージングプロトコル、一方向非同期メッセージングプロトコル、要求−応答同期メッセージングプロトコル及び要求−応答非同期メッセージングプロトコル、のうちの少なくとも１つを含んでいる
    ことを特徴とする請求項２２に記載のアプリケーション環境。
24. 前記メッセージングシステムは、前記ローカルノードのローカルメッセージバッファと前記サーバノードのサーバメッセージバッファとの間でメッセージを供給するための非同期メッセージングプロトコルを含んでいる
    ことを特徴とする請求項２２に記載のアプリケーション環境。
25. 前記ローカルメッセージバッファおよび前記サーバメッセージバッファは、対応する前記ローカルノードおよび前記サーバノード上の固定記憶域および揮発性メモリのうちの一方に選択的に記憶される
    ことを特徴とする請求項２４に記載のアプリケーション環境。
26. 前記メッセージングシステムは、ネットワーク故障、ローカルノード故障及びサーバノード故障のうちの少なくとも１つの存在下で、メッセージングトランザクションを完了するように選択的に構成可能である
    ことを特徴とする請求項２２に記載のアプリケーション環境。
27. 前記ローカルノードおよび前記サーバノードのうちの少なくとも一方のキャッシュメモリを管理するようになっているキャッシュマネージャエージェントを更に備えている
    ことを特徴とする請求項１に記載のアプリケーション環境。
28. 前記キャッシュマネージャエージェントは、前記クライアントノードおよび前記サーバノードのうちの少なくとも一方によって設定されるキャッシュ管理ポリシーを含んでいる
    ことを特徴とする請求項２７に記載のアプリケーション環境。
29. 前記キャッシュマネージャエージェントは、前記キャッシュ管理ポリシーに従って前記キャッシュメモリから前記Ｍｅｒｖｌｅｔをプレフェッチする命令のセットを含んでいることを特徴とする請求項２８に記載のアプリケーション環境。
30. 前記キャッシュマネージャエージェントは、前記キャッシュ管理ポリシーに従い、前記クライアントノードにおけるキャッシュミスに応じて、前記サーバノードから前記Ｍｅｒｖｌｅｔを検索する命令のセットを含んでいる
    ことを特徴とする請求項２８に記載のアプリケーション環境。
31. 前記キャッシュマネージャエージェントは、前記キャッシュ管理ポリシーに従って前記Ｍｅｒｖｌｅｔを含むデータを前記キャッシュメモリに書き込む命令のセットを含んでいる
    ことを特徴とする請求項２８に記載のアプリケーション環境。
32. 少なくとも１つのアクセスネットワークの一部を形成するモバイルアプリケーション環境において動的ウェブページを形成する命令のセットを含むＭｅｒｖｌｅｔアプリケーションを実行するための方法であって、
    前記少なくとも１つのアクセスネットワークに接続されるローカルノードで実行するクライアントアプリケーションから、前記Ｍｅｒｖｌｅｔアプリケーションのための要求を発する工程と、
    前記少なくとも１つのアクセスネットワークに接続されたサーバノードおよび前記ローカルノードのうちの少なくとも一方に記憶された前記Ｍｅｒｖｌｅｔを見つける工程と、
    前記Ｍｅｒｖｌｅｔが前記ローカルノードで見つけられると、前記ローカルノードで前記Ｍｅｒｖｌｅｔを実行して、前記ローカルノード上に前記動的ウェブページを表示する工程と、
    前記Ｍｅｒｖｌｅｔが前記サーバノードで見つけられると、少なくとも１つのアプリケーション属性に基づいて、前記ローカルノードと前記サーバノードとの間で前記Ｍｅｒｖｌｅｔの実行を与える工程と、
    前記ローカルノード上で前記Ｍｅｒｖｌｅｔの実行を与えることに応じて、前記Ｍｅｒｖｌｅｔおよび前記少なくとも１つのアプリケーション属性を、前記サーバノードから前記ローカルノードへと移動させる工程と、
    前記サーバノード上で前記Ｍｅｒｖｌｅｔの実行を与えることに応じて、前記Ｍｅｒｖｌｅｔを前記サーバノード上で実行して、前記ローカルノード上に前記動的ウェブページを表示する工程と、
    を備えたことを特徴とする方法。
33. 前記少なくとも１つのアプリケーション属性に基づいて、アクセスネットワークを選択する工程
    を更に含むことを特徴とする請求項３２に記載の方法。
34. 前記Ｍｅｒｖｌｅｔは、少なくとも１つのセキュリティ属性によって規定されるセキュリティコンテキスト内で、前記ローカルノードおよび前記サーバノードを実行する
    ことを特徴とする請求項３２に記載の方法。
35. 前記ローカルノード上での前記Ｍｅｒｖｌｅｔの実行を割り当てる前記決定に応じて、前記少なくとも１つのセキュリティ属性を前記サーバノードから前記ローカルノードに移動させる工程
    を更に含むことを特徴とする請求項３４に記載の方法。
36. 前記Ｍｅｒｖｌｅｔの命令は、前記ウェブページのための動的なコンテンツを生成するアプリケーション命令のセット、および、前記ウェブページ上での表示のために前記動的なコンテンツをフォーマットするユーザインタフェース命令のセットのうちの少なくとも一方を含んでいる
    ことを特徴とする請求項３２に記載の方法。
37. 前記ユーザインタフェース命令は、ウェブブラウザによって解釈可能な少なくとも１つの静的なフォーマットタグを含んでいる
    ことを特徴とする請求項３６に記載の方法。
38. 前記アプリケーション命令は、少なくとも１つのＭｅｒｖｌｅｔタグライブラリ内に存在するアプリケーションロジックをカプセル化する解釈されないプログラムコードを含んでいる
    ことを特徴とする請求項３６に記載の方法。
39. 前記ローカルノード上での前記Ｍｅｒｖｌｅｔの実行を割り当てる前記決定に応じて、前記少なくとも１つのＭｅｒｖｌｅｔタグライブラリを前記サーバノードから前記ローカルノードに移動させる工程
    を更に含むことを特徴とする請求項３８に記載の方法。
40. 前記少なくとも１つのアプリケーション属性は、前記Ｍｅｒｖｌｅｔのユーザ認識性能を特徴付けるための少なくとも１つの性能属性と、前記ローカルノード、前記サーバノード及び前記少なくとも１つのアクセスネットワークのうちの少なくとも１つの計算能力を特徴付けるための少なくとも１つのシステム属性と、を含んでいる
    ことを特徴とする請求項３２に記載の方法。
41. 前記少なくとも１つの性能属性は、前記アプリケーションにおけるユーザインタフェースイベントのための待ち時間に関する少なくとも１つの値を含み、
    前記待ち時間は、サーバ計算時間および通信時間を含んでいる
    ことを特徴とする請求項４０に記載の方法。
42. 前記少なくとも１つの性能属性は、前記待ち時間、前記サーバ計算時間及び前記通信時間の平均と、前記待ち時間、前記サーバ計算時間及び前記通信時間の変動と、のうちの少なくとも一つを含んでいる
    ことを特徴とする請求項４１に記載の方法。
43. 前記サーバ計算時間は、内部計算時間およびデータＩ／Ｏ時間を含んでいる
    ことを特徴とする請求項４２に記載の方法。
44. 前記少なくとも１つの性能属性は、前記Ｍｅｒｖｌｅｔが終了まで実行する総使用時間を更に含んでいる
    ことを特徴とする請求項４２に記載の方法。
45. 前記少なくとも１つの性能属性は、アプリケーション毎に測定される
    ことを特徴とする請求項４０に記載の方法。
46. 前記少なくとも１つの性能属性は、デバイス毎のアプリケーション毎に測定される
    ことを特徴とする請求項４０に記載の方法。
47. 前記少なくとも１つの性能属性は、ユーザ毎のデバイス毎のアプリケーション毎に測定される
    ことを特徴とする請求項４０に記載の方法。
48. 前記少なくとも１つの性能属性は、アクセスネットワーク毎のユーザ毎のデバイス毎のアプリケーション毎に測定される
    ことを特徴とする請求項４０に記載の方法。
49. 前記ローカルノードの能力を特徴付けるためのシステム属性は、前記ローカルノードのプロセッサの稼動時間の測定に関するパラメータ、前記プロセッサのＭＩＰＳ等級、前記ローカルノードにおける固定記憶域のメモリサイズおよび大きさ、のうちの少なくとも１つを含んでいる
    ことを特徴とする請求項４０に記載の方法。
50. 前記サーバノードの能力を特徴付けるためのシステム属性は、前記サーバノードのプロセッサの稼動時間の測定に関するパラメータ、前記プロセッサのＭＩＰＳ等級、前記サーバノードにおける固定記憶域のメモリサイズおよび大きさ、のうちの少なくとも１つを含んでいる
    ことを特徴とする請求項４０に記載の方法。
51. 前記少なくとも１つのアクセスネットワークの能力を特徴付けるためのシステム属性は、ネットワーク帯域幅、ネットワーク待ち時間及びネットワーク状態、のうちの少なくとも１つを含んでいる
    ことを特徴とする請求項４０に記載の方法。
52. 前記Ｍｅｒｖｌｅｔを実行するＭｅｒｖｌｅｔエンジンの実行状態を保存して、前記実行状態を元の状態に戻す工程
    を更に含むことを特徴とする請求項３２に記載の方法。
53. 前記Ｍｅｒｖｌｅｔエンジンの実行状態を保存する工程は、実行しているＭｅｒｖｌｅｔアプリケーションのリストと前記実行している各Ｍｅｒｖｌｅｔ毎のアプリケーションコンテキストとを記憶する工程を含む
    ことを特徴とする請求項５２に記載の方法。
54. 一方向同期メッセージングプロトコル、一方向非同期メッセージングプロトコル、要求−応答同期メッセージングプロトコル及び要求−応答非同期メッセージングプロトコル、のうちの少なくとも１つを使用して、前記少なくとも１つのアクセスネットワークを介して、前記Ｍｅｒｖｌｅｔと前記クライアントアプリケーションとの間でメッセージを送信する工程
    を更に含むことを特徴とする請求項３２に記載の方法。
55. 前記ローカルノードのローカルメッセージバッファおよび前記サーバノードのサーバメッセージバッファのうちの少なくとも一方に前記メッセージを記録する工程
    を更に含むことを特徴とする請求項５４に記載の方法。
56. 前記第１および第２のメッセージバッファの各々は、対応する前記ローカルノードおよび前記サーバノード上に固定記憶域を有している
    ことを特徴とする請求項５５に記載の方法。
57. ネットワーク故障、ローカルノード故障及びサーバノード故障のうちの少なくとも１つの存在下で完了するようにメッセージングトランザクションを選択的に構成する工程
    を更に含むことを特徴とする請求項５４に記載の方法。
58. 前記Ｍｅｒｖｌｅｔを記憶して検索するために、前記ローカルノードおよび前記サーバノードのうちの少なくとも一方のキャッシュメモリを管理する工程
    を更に含むことを特徴とする請求項３２に記載の方法。
59. 前記クライアントノードおよび前記サーバノードのうちの少なくとも一方によって設定されるキャッシュ管理ポリシーを使用して、前記Ｍｅｒｖｌｅｔを記憶して検索するために前記ローカルノードおよび前記サーバノードのうちの少なくとも一方のキャッシュメモリを管理する工程
    を更に含むことを特徴とする請求項５８に記載の方法。
60. 少なくとも１つのアクセスネットワークの一部を形成するモバイルアプリケーション環境であって、
    前記少なくとも１つのアクセスネットワークに接続されるローカルノードに存在するクライアントアプリケーションから、Ｍｅｒｖｌｅｔアプリケーションのための要求を発する手段であって、前記Ｍｅｒｖｌｅｔは動的ウェブページを形成するようになっている、という手段と、
    前記少なくとも１つのアクセスネットワークに接続されたサーバノードおよび前記ローカルノードのうちの少なくとも一方に記憶された前記Ｍｅｒｖｌｅｔを見つける手段と、
    前記Ｍｅｒｖｌｅｔが前記ローカルノードで見つけられると、前記ローカルノードで前記Ｍｅｒｖｌｅｔを実行して、前記ローカルノード上に前記動的ウェブページを表示する手段と、
    前記Ｍｅｒｖｌｅｔが前記サーバノードで見つけられると、少なくとも１つのアプリケーション属性に基づいて、前記ローカルノードと前記サーバノードとの間で前記Ｍｅｒｖｌｅｔの実行を与える手段であって、前記少なくとも１つのアプリケーション属性は前記Ｍｅｒｖｌｅｔのユーザ認識性能を特徴付けるための少なくとも１つの性能属性を含んでいる、という手段と、
    前記ローカルノード上で前記Ｍｅｒｖｌｅｔの実行を与えることに応じて、前記Ｍｅｒｖｌｅｔを前記サーバノードから前記ローカルノードへと移動させる手段と、
    前記サーバノード上で前記Ｍｅｒｖｌｅｔの実行を与えることに応じて、前記Ｍｅｒｖｌｅｔを前記サーバノード上で実行して、前記ローカルノード上に前記動的ウェブページを表示する手段と、
    を備えたことを特徴とするアプリケーション環境。
61. 前記ローカルノードと前記サーバノードとの間で通信を行なうために前記少なくとも１つのアプリケーション属性に基づいて第１のアクセスネットワークを選択する手段
    を更に備えたことを特徴とする請求項６０に記載のアプリケーション環境。
62. 前記少なくとも１つのアプリケーション属性を測定する手段
    を更に備えたことを特徴とする請求項６０に記載のアプリケーション環境。
63. 前記ローカルノードの故障、前記サーバノードの故障及び前記少なくとも１つのアクセスネットワークの故障のうちの少なくとも１つの後、前記Ｍｅｒｖｌｅｔの実行を回復する手段
    を更に備えたことを特徴とする請求項６０に記載のアプリケーション環境。
64. 前記ローカルノードが前記サーバノードから切断される時に前記Ｍｅｒｖｌｅｔを実行する手段
    を更に備えたことを特徴とする請求項６０に記載のアプリケーション環境。
65. デバイス間での通信のための少なくとも１つのアクセスネットワークに接続された複数のコンピュータデバイス間でアプリケーションをロードバランシングする方法であって、
    前記少なくとも１つのアクセスネットワークに接続されたサーバデバイス上に前記アプリケーションを記憶する工程と、
    前記アプリケーションのユーザ認識性能を特徴付けるための少なくとも１つの性能属性を含む、前記アプリケーションに関連付けられたアプリケーション属性のセットを測定する工程と、
    前記少なくとも１つのアクセスネットワークに接続されたクライアントデバイスから、前記アプリケーションのための要求を発する工程と、
    前記アプリケーション属性のセットに基づき、前記要求に応じて、前記クライアントデバイスおよび前記サーバデバイスの一方上で前記アプリケーションの実行を与える工程と、
    前記実行を与える工程に応じて、前記クライアントデバイスおよび前記サーバデバイスの前記一方で前記アプリケーションを実行する工程と、
    を備えたことを特徴とする方法。
66. 前記アプリケーションを実行している間、前記アプリケーション属性のセットを監視する工程と、
    前記アプリケーションを実行している間における前記監視されたアプリケーション属性のセットに基づいて、前記サーバデバイスから前記クライアントデバイスへ前記アプリケーションを再配置するか否かを決定する工程と、
    を更に備えたことを特徴とする請求項６５に記載の方法。
67. アプリケーション属性の前記セットに基づいて、前記サーバデバイスと前記クライアントデバイスとの間で通信するための第１のアクセスネットワークを選択する工程
    を更に備えたことを特徴とする請求項６５に記載の方法。
68. 前記アプリケーションを実行している間、前記アプリケーション属性のセットを監視する工程と、
    前記アプリケーションを実行している間における前記監視されたアプリケーション属性のセットに基づいて、前記サーバデバイスと前記クライアントデバイスとの間で通信するための第２のアクセスネットワークに切換えるか否かを決定する工程と、
    ことを更に備えたことを特徴とする請求項６７に記載の方法。
69. 前記少なくとも１つの性能属性は、前記アプリケーションにおけるユーザインタフェースイベントのための待ち時間に関する少なくとも１つのパラメータを含み、
    前記待ち時間は、サーバ計算時間および通信時間を含んでいる
    ことを特徴とする請求項６５に記載の方法。
70. 待ち時間に関する少なくとも１つの前記パラメータは、前記待ち時間、前記サーバ計算時間及び前記通信時間の平均と、前記待ち時間、前記サーバ計算時間及び前記通信時間の分散と、のうちの少なくとも一つを含んでいる
    ことを特徴とする請求項６９に記載の方法。
71. 前記サーバ計算時間は、内部計算時間およびデータＩ／Ｏ時間を含んでいる
    ことを特徴とする請求項７０に記載の方法。
72. 前記少なくとも１つの性能属性は、前記アプリケーションが終了まで実行する総使用時間を更に含んでいる
    ことを特徴とする請求項７０に記載の方法。
73. 前記少なくとも１つの性能属性は、アプリケーション毎に測定される
    ことを特徴とする請求項６５に記載の方法。
74. 前記少なくとも１つの性能属性は、デバイス毎のアプリケーション毎に測定される
    ことを特徴とする請求項６５に記載の方法。
75. 前記少なくとも１つの性能属性は、ユーザ毎のデバイス毎のアプリケーション毎に測定される
    ことを特徴とする請求項６５に記載の方法。
76. 前記少なくとも１つの性能属性は、アクセスネットワーク毎のユーザ毎のデバイス毎のアプリケーション毎に測定される
    ことを特徴とする請求項６５に記載の方法。
77. アプリケーション属性の前記セットは、前記クライアントデバイス、前記サーバデバイス及び前記少なくとも１つのアクセスネットワークのうちの少なくとも１つの性能を特徴付けるための、少なくとも１つのシステム属性を更に含んでいる
    ことを特徴とする請求項６５に記載の方法。
78. 前記クライアントデバイスの性能を特徴付けるためのシステム属性は、前記クライアントデバイスのプロセッサの稼動時間の測定に関するパラメータ、前記プロセッサのＭＩＰＳ等級、前記クライアントデバイスにおける固定記憶域のメモリサイズおよび大きさ、のうちの少なくとも１つを含んでいる
    ことを特徴とする請求項７７に記載の方法。
79. 前記サーバデバイスの性能を特徴付けるためのシステム属性は、前記サーバデバイスのプロセッサの稼動時間の測定に関するパラメータ、前記プロセッサのＭＩＰＳ等級、前記サーバデバイスにおける固定記憶域のメモリサイズおよび大きさ、のうちの少なくとも１つを含んでいる
    ことを特徴とする請求項７７に記載の方法。
80. 前記少なくとも１つのアクセスネットワークの性能を特徴付けるためのシステム属性は、ネットワーク帯域幅、ネットワーク待ち時間及びネットワーク状態、のうちの少なくとも１つを含んでいる
    ことを特徴とする請求項７７に記載の方法。
81. 少なくとも１つのネットワークの一部を形成するアプリケーションをロードバランシングするためのシステムであって、
    前記少なくとも１つのネットワークに接続され、前記アプリケーションのための様々な実行環境を与える複数の実行モジュールと、
    前記少なくとも１つのネットワークに接続され、前記アプリケーションのユーザ認識性能を特徴付けるための少なくとも１つの性能属性を含む前記アプリケーションに関連付けられたアプリケーション属性のセットを測定する少なくとも１つの収集モジュールと、
    前記少なくとも１つのネットワークに接続され、前記アプリケーション属性に基づいて前記アプリケーションの実行環境を決定するための少なくとも１つのポリシーを満たす第１の実行モジュールを決定する少なくとも１つのポリシーモジュールと、
    前記第１の実行モジュール上に前記アプリケーションを割り当てる少なくとも１つのプログラム割り当てモジュールと、
    を備えたことを特徴とするシステム。
82. アプリケーション属性の前記セットに基づいて前記アプリケーションの通信環境を決定するための少なくとも１つのポリシーを満たすアクセスネットワークを選択する少なくとも１つのネットワーク割り当てモジュール
    を更に備えたことを特徴とする請求項８１に記載のシステム。
83. 前記少なくとも１つの性能属性は、前記アプリケーションにおけるユーザインタフェースイベントのための待ち時間に関する少なくとも１つのパラメータを含み、
    前記待ち時間は、サーバ計算時間および通信時間を含んでいる
    ことを特徴とする請求項８２に記載のシステム。
84. 待ち時間に関する少なくとも１つの前記パラメータは、前記待ち時間、前記サーバ計算時間及び前記通信時間の平均と、前記待ち時間、前記サーバ計算時間及び前記通信時間の分散と、のうちの少なくとも一つを含んでいる
    ことを特徴とする請求項８３に記載のシステム。
85. 前記サーバ計算時間は、内部計算時間およびデータＩ／Ｏ時間を含んでいる
    ことを特徴とする請求項８４に記載のシステム。
86. 前記少なくとも１つの性能属性は、前記アプリケーションが終了まで実行する総使用時間を更に含んでいる
    ことを特徴とする請求項８５に記載のシステム。
87. 前記少なくとも１つの性能属性は、アプリケーション毎に測定される
    ことを特徴とする請求項８１に記載のシステム。
88. 前記少なくとも１つの性能属性は、デバイス毎のアプリケーション毎に測定される
    ことを特徴とする請求項８１に記載のシステム。
89. 前記少なくとも１つの性能属性は、ユーザ毎のデバイス毎のアプリケーション毎に測定される
    ことを特徴とする請求項８１に記載のシステム。
90. 前記少なくとも１つの性能属性は、アクセスネットワーク毎のユーザ毎のデバイス毎のアプリケーション毎に測定される
    ことを特徴とする請求項８１に記載のシステム。
91. アプリケーション属性の前記セットは、前記クライアントデバイス、前記サーバデバイス及び前記少なくとも１つのアクセスネットワークのうちの少なくとも１つの性能を特徴付けるための、少なくとも１つのシステム属性を更に含んでいる
    ことを特徴とする請求項８１に記載のシステム。
92. 前記クライアントデバイスの性能を特徴付けるためのシステム属性は、前記クライアントデバイスのプロセッサの稼動時間の測定に関するパラメータ、前記プロセッサのＭＩＰＳ等級、前記クライアントデバイスにおける固定記憶域のメモリサイズおよび大きさ、のうちの少なくとも１つを含んでいる
    ことを特徴とする請求項９１に記載のシステム。
93. 前記サーバデバイスの性能を特徴付けるためのシステム属性は、前記サーバデバイスのプロセッサの稼動時間の測定に関するパラメータ、前記プロセッサのＭＩＰＳ等級、前記サーバデバイスにおける固定記憶域のメモリサイズおよび大きさ、のうちの少なくとも１つを含んでいる
    ことを特徴とする請求項９１に記載のシステム。
94. 前記少なくとも１つのアクセスネットワークの性能を特徴付けるためのシステム属性は、ネットワーク帯域幅、ネットワーク待ち時間及びネットワーク状態、のうちの少なくとも１つを含んでいる
    ことを特徴とする請求項９１に記載のシステム。
95. デバイス間での通信のための少なくとも１つのアクセスネットワークに接続された複数のコンピュータデバイス間でアプリケーションをロードバランシングするシステムであって、
    前記少なくとも１つのアクセスネットワークに接続されたサーバデバイス上に前記アプリケーションを記憶する手段と、
    前記アプリケーションのユーザ認識性能を特徴付けるための少なくとも１つの性能属性を含むアプリケーション属性のセットを測定する手段と、
    前記少なくとも１つのアクセスネットワークに接続されたクライアントデバイスから、前記アプリケーションのための要求を発する手段と、
    前記アプリケーション属性のセットに基づき、前記要求に応じて、前記クライアントデバイスおよび前記サーバデバイスの一方上で前記アプリケーションの実行を与える手段と、
    前記実行を与えることに応じて、前記クライアントデバイスおよび前記サーバデバイスの前記一方で前記アプリケーションを実行する手段と、
    を備えたことを特徴とするシステム。
96. 前記アプリケーションを実行している間、前記アプリケーション属性のセットを監視する手段と、
    前記監視されたアプリケーション属性のセットに基づいて、前記サーバデバイス上での実行中、前記サーバデバイスから前記クライアントデバイスへ前記アプリケーションを再配置するか否かを決定する手段と、
    を更に備えたことを特徴とする請求項９５に記載のシステム。
97. 前記サーバデバイスと前記クライアントデバイスとの間で通信するために、アプリケーション属性の前記セットに基づいて、第１のアクセスネットワークを選択する手段
    を更に備えたことを特徴とする請求項９５に記載のシステム。
98. 前記アプリケーションの実行中、前記アプリケーション属性のセットを監視する手段と、
    前記サーバデバイスと前記クライアントデバイスとの間で通信するため、前記監視されたアプリケーション属性のセットに基づいて、前記アプリケーションの実行中、第２のアクセスネットワークに切換えるか否かを決定する手段と、
    を更に備えたことを特徴とする請求項９７に記載のシステム。
99. ネットワークに接続された複数のモジュール間で通信するための構成可能な信頼できるメッセージングシステムを備え、
    当該メッセージングシステムは、
    メッセージを生成し、且つ、前記ネットワークを介して前記メッセージに対する応答を受けるようになっているクライアントモジュールと、
    前記ネットワークを介して、前記メッセージを受け、且つ、前記応答を生成するようになっているサーバモジュールと、
    クライアントロギング信号に応じて前記クライアントモジュール上で選択的に実行するとともに、前記メッセージおよび前記応答を記憶するように且つ前記応答が受けられるまで前記メッセージを前記サーバモジュールに送信するようになっているクライアントロギングエージェントと、
    サーバロギング信号に応じて前記サーバモジュール上で選択的に実行するとともに、前記メッセージおよび前記応答を記憶するように且つ前記応答を前記クライアントモジュールに送信するようになっているサーバロギングエージェントと、
    前記クライアントモジュールおよび前記サーバモジュールのうちの少なくとも一方に関連付けられ、前記クライアントロギング信号および前記サーバロギング信号を生成するようになっているコンフィギュレーションエージェントと、
    を含んでいる
    ことを特徴とするフォールトトレランスシステム。
100. アプリケーションを処理するために前記クライアントモジュールおよび前記サーバモジュールのうちの少なくとも一方で実行するとともに、実行状態を取得して、前記クライアントモジュールおよび前記サーバモジュールのうちの前記少なくとも一方に関連付けられた固定記憶域に当該実行状態を記憶するようになっている、回復可能なランタイムエンジンを更に備え、
     前記ランタイムエンジンは、当該ランタイムエンジンを実行している前記クライアントモジュールおよび前記サーバモジュールのうちの前記少なくとも一方の一時的な故障後、前記実行状態に基づいて、実行を再開することができる
     ことを特徴とする請求項９９に記載のフォールトトレランスシステム。
101. 前記クライアントモジュールは、前記メッセージを記憶するための第１の固定記憶域バッファを有している
     ことを特徴とする請求項９９に記載のフォールトトレランスシステム。
102. 前記第１の固定記憶域バッファは、ユーザ構成可能なサイズを有している
     ことを特徴とする請求項１００に記載のフォールトトレランスシステム。
103. 前記サーバモジュールは、前記応答を記憶するための第２の固定記憶域バッファを有している
     ことを特徴とする請求項９９に記載のフォールトトレランスシステム。
104. 前記第２の固定記憶域バッファは、ユーザ構成可能なサイズを有している
     ことを特徴とする請求項１０２に記載のフォールトトレランスシステム。
105. 前記実行状態は、実行しているアプリケーションのリストおよび前記実行している各アプリケーションに関連付けられたアプリケーションコンテキストを含んでいる
     ことを特徴とする請求項１００に記載のフォールトトレランスシステム。
106. 前記実行状態は、前記実行している各アプリケーションにおける優先順位の値を更に含んでいる
     ことを特徴とする請求項１０５に記載のフォールトトレランスシステム。
107. 前記アプリケーションコンテキストは、ハードウェアリソースに関連するパラメータ、外部ファイルに関連するパラメータ、性能属性に関連するパラメータ、及び、実行しているアプリケーションに関連付けられたリソース権利に関連するパラメータ、のうちの少なくとも１つを含んでいる
     ことを特徴とする請求項１０５に記載のフォールトトレランスシステム。
108. 前記性能属性は、前記実行しているアプリケーションのユーザインタフェースイベントにおける待ち時間の平均および待ち時間の分散のうちの少なくとも一方を含んでいる
     ことを特徴とする請求項１０７に記載のフォールトトレランスシステム。
109. 前記実行しているアプリケーションは、アプリケーション状態を保存するとともに、当該アプリケーション状態を使用して実行を再開するようになっている
     ことを特徴とする請求項１００に記載のフォールトトレランスシステム。
110. 分散コンピュータシステムをフォールトトレラントにするための方法であって、
     要求メッセージを生成し且つ応答メッセージを受けるようになっている第１のコンピュータデバイスと、前記要求メッセージを受け且つ前記要求メッセージに応じて前記応答メッセージを生成するようになっている第２のコンピュータデバイスと、を含むネットワークに接続された複数のコンピュータデバイス間で複数のメッセージを送る工程と、
     前記第１のコンピュータデバイス上に前記要求メッセージを選択的に記憶する工程と、
     前記第２のコンピュータデバイス上に前記要求メッセージを選択的に記憶する工程と、
     前記第２のコンピュータデバイス上に前記応答メッセージを選択的に記憶する工程と、
     前記第１のコンピュータデバイス上に前記応答メッセージを選択的に記憶する工程と、
     を備えたことを特徴とする方法。
111. 少なくとも１つのアプリケーションを処理するため、前記第１のコンピュータデバイスおよび前記第２のコンピュータデバイスのうちの少なくとも一方でランタイムエンジンを実行する工程と、
     前記ランタイムエンジンの実行状態を取得して保存する工程と、
     前記第１のコンピュータデバイスおよび前記第２のコンピュータデバイスのうちの前記少なくとも一方の一時的な故障の後、前記実行状態に基づいて、前記ランタイムエンジンの実行を再開する工程と、
     を更に備えたことを特徴とする請求項１１０に記載の方法。
112. 前記第２のコンピュータデバイスから前記応答メッセージを除去する工程と、
     前記第２のコンピュータデバイスから前記要求メッセージを除去する工程と、
     前記第１のコンピュータデバイスから前記要求メッセージを除去する工程と、
     前記第１のコンピュータデバイスから前記応答メッセージを除去する工程と、
     を更に備えたことを特徴とする請求項１１０に記載の方法。
113. 前記第１のコンピュータデバイス上に前記要求メッセージを選択的に記憶する前記工程は、前記第１のコンピュータデバイスに関連付けられた第１の固定記憶域バッファに前記要求メッセージを選択的に記憶する工程を含んでいる
     ことを特徴とする請求項１１０に記載の方法。
114. 前記第１の固定記憶域バッファは、ユーザ構成可能なサイズを有している
     ことを特徴とする請求項１１３に記載の方法。
115. 前記第２のコンピュータデバイス上に前記応答メッセージを選択的に記憶する前記工程は、前記第２のコンピュータデバイスに関連付けられた第２の固定記憶域バッファに前記応答メッセージを選択的に記憶する工程を含んでいる
     ことを特徴とする請求項１１０に記載の方法。
116. 前記第２の固定記憶域バッファは、ユーザ構成可能なサイズを有している
     ことを特徴とする請求項１１５に記載の方法。
117. 前記ランタイムエンジンの実行状態を保存する工程は、実行しているアプリケーションのリストおよび当該実行している各アプリケーションに関連付けられたアプリケーションコンテキストを記憶する工程を含んでいる
     ことを特徴とする請求項１１１に記載の方法。
118. 前記ランタイムエンジンの実行状態を保存する工程は、前記少なくとも１つのアプリケーションにおける優先順位の値を記憶する工程を更に含んでいる
     ことを特徴とする請求項１１７に記載の方法。
119. 前記アプリケーションコンテキストは、ハードウェアリソースに関連するパラメータ、外部ファイルに関連するパラメータ、性能属性に関連するパラメータ、及び、実行しているアプリケーションに関連付けられたリソース権利に関連するパラメータ、のうちの少なくとも１つを含んでいる
     ことを特徴とする請求項１１７に記載の方法。
120. 性能属性に関連する前記パラメータは、前記少なくとも１つのアプリケーションのユーザインタフェースイベントにおける待ち時間の平均および待ち時間の分散のうちの少なくとも一方を含んでいる
     ことを特徴とする請求項１１９に記載の方法。
121. 前記少なくとも１つのアプリケーションに関連付けられたアプリケーション状態を取得して保存する工程と、
     前記アプリケーション状態に基づいて、前記少なくとも１つのアプリケーションの実行を再開する工程と、
     を更に備えたことを特徴とする請求項１１１に記載の方法。
122. 要求メッセージを生成し且つ応答メッセージを受けるようになっている第１のコンピュータデバイスと、前記要求メッセージを受け且つ前記要求メッセージに応じて前記応答メッセージを生成するようになっている第２のコンピュータデバイスと、を含むネットワークに接続された複数のコンピュータデバイス間で複数のメッセージを送る手段と、
     前記第１のコンピュータデバイス上に前記要求メッセージを選択的に記憶する手段と、
     前記第２のコンピュータデバイス上に前記要求メッセージを選択的に記憶する手段と、
     前記第２のコンピュータデバイス上に前記応答メッセージを選択的に記憶する手段と、
     前記第１のコンピュータデバイス上に前記応答メッセージを選択的に記憶する手段と、
     を備えたことを特徴とするフォールトトレラントな分散コンピュータシステム。
123. アプリケーションを処理するため、前記第１のコンピュータデバイスおよび前記第２のコンピュータデバイスのうちの少なくとも一方でランタイムエンジンを実行する手段と、
     前記ランタイムエンジンの実行状態を取得して保存する手段と、
     前記第１のコンピュータデバイスおよび前記第２のコンピュータデバイスのうちの前記少なくとも一方の一時的な故障の後、前記実行状態に基づいて、前記ランタイムエンジンの実行を再開する手段と、
     を更に備えたことを特徴とする請求項１２２に記載のシステム。
124. 分散コンピュータシステムをフォールトトレラントにするための方法であって、
     ネットワークに接続されたクライアントモジュールによりメッセージを生成する工程と、
     前記クライアントモジュール上に前記メッセージを選択的に記憶する工程と、
     前記ネットワークに接続されたサーバモジュールに前記メッセージを送る工程と、
     前記サーバモジュール上に前記メッセージを受けて選択的に記憶する工程と、
     前記サーバモジュールから先の応答を解放する工程と、
     前記サーバモジュールにより、前記メッセージに対する応答を生成する工程と、
     前記サーバモジュール上に前記応答を選択的に記憶する工程と、
     前記応答を前記クライアントモジュールに送る工程と、
     前記サーバモジュールから前記メッセージを除去する工程と、
     前記クライアントモジュール上に前記応答を受けて選択的に記憶する工程と、
     前記クライアントモジュールから前記メッセージを除去する工程と、
     前記クライアントモジュールから前記応答を解放する工程と、
     を備えたことを特徴とする方法。
125. 少なくとも１つのアプリケーションを処理するために、前記クライアントモジュールおよび前記サーバモジュールのうちの少なくとも一方でランタイムエンジンを実行する工程と、
     前記ランタイムエンジンの実行状態を取得して保存する工程と、
     前記クライアントモジュールおよび前記サーバモジュールのうちの前記少なくとも一方の一時的な故障の後、前記実行状態に基づいて、前記ランタイムエンジンの実行を再開する工程と、
     を更に備えたことを特徴とする請求項１２４に記載の方法。

Images