JP5963682B2 - 要求をディスパッチするための方法、システム、およびコンピュータ・プログラム - Google Patents

Description

本発明は、ミドルウェアの分野に関し、詳細には、履歴メトリック（historicmetrics）を使用して要求ディスパッチに関する実行モードをプログラムによって決定することに関する。

アプリケーション・サーバがWebアプリケーション（たとえば、JAVAサーブレットまたはJAVA SERVER PAGE）などの実行可能コードを処理する場合、そのWebアプリケーション内に１つまたは複数の要求ディスパッチが存在する可能性がある。これらの要求ディスパッチは、典型的に、他のサーブレットまたはJAVA SERVER PAGE（JSP）など、実行すべきリソースを指定するinclude()関数呼び出しによって示される。指定されたリソースは、非同期または同期という２通りのモードの一方で実行することができる。同期実行の結果、しばしば、指定のリソース実行が完了するまで実行可能コードのブロッキング（たとえば、中断）が行われ、多くの場合、好ましくない状況になる。さらに、このリソースは追加の要求ディスパッチを含む可能性があり、それによりその他のリソースを実行する可能性があり、その結果、頻繁にWebアプリケーションに相当な待ち時間をもたらす実行チェーンを発生することになる。このため、この待ち時間の結果として、いくつかの不利益が発生する可能性があり、これは非応答アプリケーションあるいは過剰なサーバ負荷またはその両方を含む可能性がある。

このような不利益を克服するための解決策の１つは、指定のリソースに非同期実行モードを使用することである。しかし、非同期実行は、新しいスレッドの確立、出力内のマーカの配置、およびサーバまたはクライアント側の集約のためのマーカの置換などのオーバヘッドをもたらす。多くの場合、このオーバヘッドは待ち時間を倍加する可能性があり、それにより非同期実行によって提供されるパフォーマンス向上を大幅に低減する可能性がある。たとえば、あるリソースの同期実行の結果、１０ｍｓの待ち時間が発生する可能性があり、同じリソースを非同期的に実行すると、非同期実行によってもたらされるオーバヘッド（たとえば、スレッド・セットアップ・コスト）により２０ｍｓの待ち時間が発生する可能性がある。

さらに、動的サーバ環境では、同期および非同期リソース実行は、リソース可用性の変化により、様々な結果をもたらす可能性がある。Webアプリケーションは一般にこのような環境に配備されるので、Webアプリケーションはパフォーマンスの変動の影響を受ける。このような問題に対処するために、Web開発者は、しばしば、どの実行モードが最良のパフォーマンス結果をもたらすことができるかについて経験や知識に基づく推測を行う。往々にして、このような推測の結果、最も最適なアプリケーション・パフォーマンスが得られるわけではない。このため、Webアプリケーションを実行する多くのサーバ環境では、リソースの使用状況が非効率的になり、サーバの能力が低減され、それにより、情報技術（ＩＴ）インフラストラクチャに不当に負担をかける可能性がある。

本発明の一実施形態は、要求をディスパッチするための方法を含む。この方法では、実行時間中に第１の実行可能コード内で実行すべき要求ディスパッチを識別することができる。要求ディスパッチは固有識別値に関連付けることができる。要求ディスパッチの固有識別値は、実行すべき第２の実行可能コードを識別することができる。第１および第２の実行可能コードは、Webコンテナのコンポーネント内に常駐することができる。Webコンテナは、リソースの包含を可能にする様々な技術のいずれかを使用することができる。たとえば、Webコンテナは、J2EEランタイム環境などのランタイム環境に関連付けることができる。第２の実行可能コードの実行の前に、第２の実行可能コードに関する実行モードを決定することができる。この決定は、パフォーマンス・メトリックおよびしきい値のうちの少なくとも１つを評価することを伴うことができる。しきい値は、ユーザ確立値およびプログラム確立値のうちの少なくとも１つにすることができる。実行モードは、非同期実行モードまたは同期実行モードにすることができる。実行モードの決定に応答して、決定した実行モードの使用に基づいて要求ディスパッチを実行することができる。同期実行モードの結果、第２の実行可能コードの実行が始まる前に、第１の実行可能コードが実行され、実行を完了することができる。非同期実行モードの結果、第１および第２の実行可能コードを同時に実行することができる。

本発明の他の実施形態は、要求をディスパッチするためのシステムを含むことができる。このシステムは、第１の実行可能コードに関連する要求ディスパッチを識別し実行することができるディスパッチ・エンジンを含むことができる。ディスパッチ・エンジンは、ランタイム環境内のトランスポート・チャネル・チェーンのコンポーネントにすることができる。トランスポート・チャネル・チェーンは、オープン・システム間相互接続（ＯＳＩ）層モデルのトランスポート層に関連付けることができる。ランタイム環境は、リソースの包含をサポートする任意の環境にすることができる。たとえば、一実施形態では、ランタイム環境はJAVA 2 ENTERPRISE EDITION（J2EE）ランタイム環境にすることができる。また、このシステムは、第１の実行可能コードに関連する要求ディスパッチも含むことができる。要求ディスパッチは固有識別値に関連付けることができる。固有識別値は実行すべき固有リソースを識別することができる。要求ディスパッチは、固有リソースの実行をトリガすることができる。固有リソースは第２の実行可能コードを含むことができる。また、このシステムは、要求ディスパッチに関連する少なくとも１つのパフォーマンス・メトリックを含むこともできる。パフォーマンス・メトリックは、要求ディスパッチ実行中に自動的に収集することができる。パフォーマンス・メトリックは、要求ディスパッチの実行挙動を変更するために使用することができる。要求ディスパッチに関連するしきい値、実行モード、およびイベント・ハンドラのうちの少なくとも１つを確立するように構成されたルールセット（ruleset）が存在する可能性がある。しきい値はユーザ確立設定または自動決定値にすることができる。実行モードは同期実行モードまたは非同期実行モードにすることができる。同期実行モードの結果、第１の実行可能コードが第２の実行可能コードとともに順次実行することができ、第１の実行可能コードがその実行を完了するまで第２の実行可能コードは実行することができない。非同期実行モードの結果、第１および第２の実行可能コードが同時に実行することができる。

次に、以下の図面に関連して、一例としてのみ、本発明の好ましい諸実施形態について説明する。

本明細書に開示されている発明的配置の一実施形態により、履歴メトリックを使用して要求ディスパッチに関する実行モードをプログラムによって決定する方法を示す流れ図である。 本明細書に開示されている発明的配置の一実施形態により、履歴メトリックを使用して要求ディスパッチに関する実行モードをプログラムによって決定するための実行可能コード・セグメントおよび通信モデルを示すブロック図である。 本明細書に開示されている発明的配置の一実施形態により、履歴メトリックを使用して要求ディスパッチ実行モードをプログラムによって決定するためのシステムを示すブロック図である。 本明細書に開示されている発明的配置の一実施形態により、履歴メトリックを使用して要求ディスパッチに関する実行モードをプログラムによって決定するための１組のインターフェースを示すブロック図である。

本発明は、履歴メトリックを使用してランタイム中に要求ディスパッチ実行モードをプログラムによって決定するための解決策を提供する。すなわち、要求ディスパッチャは、同期モードおよび非同期モードで要求ディスパッチ（たとえば、include()）の処理を自動的かつ知的に切り替えることができる。各要求ディスパッチは、プロセスＩＤまたはユニフォーム・リソースＩＤ（ＵＲＩ）などの固有識別値、履歴メトリック、およびルールセットに関連付けることができる。要求ディスパッチを実行するたびに、履歴メトリックを収集することができる。メトリックとしては、実行持続期間あるいは実行頻度またはその両方、プロセッサ負荷、メモリ使用率、ネットワーク入出力、従属要求ディスパッチの数などを含むことができるが、これらに限定されない。履歴メトリックを使用すると、要求ディスパッチのその後の実行をどちらのモードで実行すべきかを判断するためのルールを構築することができる。たとえば、要求ディスパッチの同期実行持続期間（たとえば、１００ｍｓ）がユーザ指定持続期間（たとえば、５０ｍｓ）を超える場合、要求ディスパッチのその後の実行は非同期モードで実行することができる。要求ディスパッチに関連するルールは、適切な実行モードを決定するための１つまたは複数の任意の複雑なルールにすることができる。このため、Webアプリケーションのランタイム最適化をさらに改善することができる。

当業者であれば分かるように、本発明は、システム、方法、またはコンピュータ・プログラム（computer program product）として実施することができる。したがって、本発明は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態（ファームウェア、常駐ソフトウェア、マイクロコードなどを含む）、またはソフトウェアとハードウェアの態様を組み合わせた実施形態の形を取ることができ、いずれも一般に本明細書では「回路」、「モジュール」、または「システム」と呼ぶことができる。さらに、本発明は、その媒体に実施されたコンピュータ使用可能プログラム・コードを有する１つまたは複数の任意の有形表現媒体に実施されたコンピュータ・プログラムの形を取ることができる。

１つまたは複数のコンピュータ使用可能またはコンピュータ可読媒体（複数も可）の任意の組み合わせを使用することができる。コンピュータ使用可能またはコンピュータ可読媒体は、たとえば、電子、磁気、光、電磁、赤外線、または半導体のシステム、装置、またはデバイスにすることができるが、これらに限定されない。コンピュータ可読媒体のより具体的な例（非網羅的リスト）は、１つまたは複数のワイヤを有する電気接続、ポータブル・コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、消去可能プログラム可能読み取り専用メモリ（ＥＰＲＯＭまたはフラッシュ・メモリ）、光ファイバ、ポータブル・コンパクト・ディスク読み取り専用メモリ（ＣＤＲＯＭ）、光学記憶装置、または磁気記憶装置を含むことになるであろう。

コンピュータ可読媒体は、データがデジタルでコード化された形で保持される非一時的記憶媒体にすることができる。コンピュータ可読媒体は、記憶媒体に保管されたデータ内容を入手するためにコンピューティング機器によって抽出可能な情報を保持することができる物理的な有形記憶媒体にすることができる。

本発明の動作を実行するためのコンピュータ・プログラム・コードは、Java、Smalltalk、C++などのオブジェクト指向プログラミング言語あるいは「Ｃ」プログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語を含む、１つまたは複数のプログラミング言語の任意の組み合わせで作成することができる。このプログラム・コードは、完全にユーザのコンピュータ上で、一部分はユーザのコンピュータ上で、スタンドアロン・ソフトウェア・パッケージとして、一部分はユーザのコンピュータ上でしかも一部分はリモート・コンピュータ上で、あるいは完全にリモート・コンピュータまたはサーバ上で実行することができる。後者のシナリオでは、ローカル・エリア・ネットワーク（ＬＡＮ）または広域ネットワーク（ＷＡＮ）を含む任意のタイプのネットワークを介してリモート・コンピュータがユーザのコンピュータに接続される場合もあれば、（たとえば、インターネット・サービス・プロバイダを使用してインターネットを介して）外部コンピュータに接続が行われる場合もある。

本発明は、本発明の諸実施形態による方法、装置（システム）、およびコンピュータ・プログラムの流れ図あるいはブロック図またはその両方に関連して以下に記載されている。流れ図あるいはブロック図またはその両方の各ブロックおよび流れ図あるいはブロック図またはその両方内の複数ブロックの組み合わせは、コンピュータ・プログラム命令によって実現可能であることが理解されるであろう。これらのコンピュータ・プログラム命令は、汎用コンピュータ、特殊目的コンピュータ、またはその他のプログラマブル・データ処理装置のプロセッサに提供し、コンピュータまたはその他のプログラマブル・データ処理装置のプロセッサにより実行された命令が流れ図あるいはブロック図またはその両方の１つまたは複数のブロックに指定された機能／行為を実現するための手段を作成するようなマシンを生産することができる。

また、これらのコンピュータ・プログラム命令は、コンピュータ可読記憶媒体に保管された命令が流れ図あるいはブロック図またはその両方の１つまたは複数のブロックに指定された機能／行為を実現する命令を含む装置（article of manufacture）を生産するような特定の方法で機能するよう、コンピュータまたはその他のプログラマブル・データ処理装置に指示することができるコンピュータ可読記憶媒体に保管することもできる。

また、コンピュータ・プログラム命令は、コンピュータまたはその他のプログラマブル・データ処理装置上にロードし、コンピュータまたはその他のプログラマブル装置上で実行された命令が流れ図あるいはブロック図またはその両方の１つまたは複数のブロックに指定された機能／行為を実現するためのプロセスを提供するようなコンピュータで実行されるプロセスを生産するように、コンピュータまたはその他のプログラマブル装置上で一連の動作ステップを実行させることもできる。

図１は、本明細書に開示されている発明的配置の一実施形態により、履歴メトリックを使用して要求ディスパッチに関する実行モードをプログラムによって決定する方法１００を示す流れ図である。方法１００では、アプリケーション・サーバ（たとえば、JAVA 2 ENTERPRISE EDITIONアプリケーション・サーバ）内で実行される識別済み実行可能コード（たとえば、JAVAサーブレット）に関連する要求ディスパッチは、マシンが決定した方法で自動的に実行することができる。履歴メトリックを使用して、ランタイム中に要求ディスパッチ決定を実行し、非同期または同期の実行モードを識別することができる。実行可能コードは、サーブレット、JAVA server pages、JAVA beans、JAVAクラス、ポートレットなどを含むがこれらに限定されないWebアプリケーションの１つまたは複数のコンポーネントにすることができる。たとえば、実行可能コードは、動的Webコンテンツを提供するJava Webアプリケーションにすることができる。

方法１００は、システム３００などの任意の数の適切なシステムのコンテキスト内で実行することができる。本発明全体を通して、説明の明瞭性および利便性のために、JAVAベースの実現例が提供されている。本発明の範囲はこの点については限定されず、実現技術がリソースの包含をサポートする限り、本明細書に詳述されている発明的配置は様々な技術（非JAVA技術を含む）のいずれかを使用して実現することができる。たとえば、一実施形態では、本明細書に詳述されているように、履歴メトリックを使用して要求ディスパッチに関する実行モードを決定するときに、.ＮＥＴ技術を使用することができる。

本明細書で使用する要求ディスパッチは、開発者が指定したリソースの実行を可能にするプログラムのコマンドを含むことができる。一実施形態（たとえば、JAVAベースのもの）では、要求ディスパッチは、include()およびforward()など、JAVAアプリケーション・プログラミング・インターフェース（ＡＰＩ）のメソッドにすることができる。要求ディスパッチは、プロセスＩＤ、自動／手動コード注釈、タグ付け、ユニフォーム・リソース・ロケータ（ＵＲＬ）識別、固有パス識別、固有照会ストリングなどを含むがこれらに限定されない１つまたは複数の識別メカニズムを使用して明確に識別することができる。各要求ディスパッチは、アプリケーション・サーバ・パフォーマンスに基づいて最適化要求ディスパッチを可能にする１つまたは複数の履歴メトリックおよび実行モード設定に関連付けることができる。

ステップ１０５では、Webコンテナ内の実行可能コードを初期設定する。実行可能コードは、Webコンテナ内で実行されるWebアプリケーションにすることができる。Webコンテナは、JAVA仮想マシン（JVM）などのJAVA 2 ENTERPRISE EDITION（J2EE）アプリケーション・サーバ内で実行される１つまたは複数の構成体にすることができる。方法１００が実行されるターゲット実現環境および実現選択肢次第で、J2EEアプリケーション・サーバの代わりに.ＮＥＴサーバなどのその他のサーバを使用することができる。ステップ１１０では、初期設定された実行可能コードに関連する要求ディスパッチを識別する。識別済みディスパッチは、実行すべき１つまたは複数のリソースに関連付けることができる。このリソースは、サーブレット、１つまたは複数のJAVA SERVER PAGE（JSP）Webページなどの１つまたは複数の実行可能コード・オブジェクトにすることができる。ステップ１１５では、識別済みディスパッチについてメトリックが存在する場合、この方法はステップ１２０に進むことができ、さもなければステップ１５５に移行することができる。識別済みディスパッチに関連するメトリックは１つまたは複数の履歴メトリックにすることができる。メトリックとしては、実行持続期間あるいは実行頻度またはその両方、複雑さ、プロセッサ負荷、メモリ使用率、ネットワーク入出力、従属識別済みディスパッチの数などを含むことができるが、これらに限定されない。たとえば、メトリックは、決定された期間における識別済みディスパッチの平均実行持続期間を含むことができる。さらに、識別済みディスパッチの各実行モードに関するメトリックを追跡し、最適意思決定機能を可能にすることができる。すなわち、Webアプリケーションに関するデフォルト設定を確立するために、非同期実行モードおよび同期実行モードに関するメトリックの評価を実行することができる。

ステップ１２０では、識別済みディスパッチに関する履歴メトリックが前に確立したしきい値を超える場合、この方法はステップ１２５に進むことができ、さもなければステップ１４０に移行することができる。たとえば、しきい値は実行持続期間などのタイミング値にすることができる。一実施形態では、どちらのモードで識別済みディスパッチを実行すべきかを判断するために、履歴実行時間およびしきい値を数値的に比較することができる。しきい値が存在しない事例では、「最良推測」手法を使用して識別済みディスパッチを実行することができる。たとえば、同様のディスパッチを分析することにより、しきい値をプログラムによって導出し、識別済みディスパッチの知的実行を可能にすることができる。ステップ１２５では、ディスパッチ・イベントをイベント・ハンドラに登録する。ステップ１３０では、非ブロッキング・コード実行を含むことができる非同期モードで識別済みディスパッチを実行する。すなわち、Webアプリケーションは、識別済みディスパッチと同時に実行し続けることができる。ステップ１３５では、識別済みディスパッチに関するメトリックを収集することができる。パフォーマンス・モニター・エージェントなどの１つまたは複数のメトリック収集コンポーネントを使用して、メトリックを収集することができる。パフォーマンス・モニター・エージェントとしては、負荷モニター、実行可能コード最適化ツールなどを含むことができるが、これらに限定されない。

ステップ１４０では、識別済みディスパッチを同期モードで実行することができる。ステップ１４７では、識別済みディスパッチについてメトリックを収集することができる。ステップ１４７では、識別済みディスパッチについてメトリック・データを収集することができる。一実施形態では、メトリック・データは、識別済みディスパッチのブロッキング持続期間を含むことができる。ステップ１５０では、識別済みディスパッチ実行が完了した場合、この方法はステップ１５７に進むことができ、さもなければこの方法はステップ１４０に戻ることができる。

ステップ１５５では、デフォルト設定を使用して識別済みディスパッチを実行し、このディスパッチに関連するメトリックを収集することができる。ステップ１５７では、履歴メトリックに基づいて、任意選択でしきい値を変更することができる。たとえば、変更としては、時間の経過につれてしきい値を増加／減少することを含むことができる。すなわち、履歴メトリックを収集するにつれて、ランタイム・パフォーマンスは継続的に改善することができる。ステップ１６０では、実行可能コードに関連するより多くのディスパッチが処理に使用可能である場合、この方法はステップ１１０に戻ることができ、さもなければステップ１６５に進むことができる。ステップ１６５では、実行可能コードの実行を終了することができる。

方法１００の開示された諸ステップはいずれの点でも本発明を限定するものと解釈してはならないことを認識されたい。方法１００は連続的にリアルタイムで実行することができ、アプリケーション・サーバ・リソースの可用性が変動するにつれて各実行可能コードを動的に最適化することができる。しかし、パフォーマンスを低減する可能性のあるディスパッチの過剰最適化を回避するために、方法１００によって各要求を任意選択で静的に決定することができる。一実施形態では、方法１００は、コンピューティング・リソースを最小限にすることができる間隔で実行することができる。

図２は、本明細書に開示されている発明的配置の一実施形態により、履歴メトリックを使用して要求ディスパッチに関する実行モードをプログラムによって決定するための実行可能コード・セグメント２１０および通信モデル２３０を示すブロック図である。ある事例では、実行可能コード・セグメント２１０はJAVAソース・コード・ファイルにすることができる。ここではその他の（非JAVA）技術に基づくその他のタイプのセグメント２１０を使用することができ、どの特定の実装言語とも無関係なものとして解釈すべき概念を表すために，本明細書ではJAVAベースの例が使用されている。実行可能コード・セグメント２１０では、要求ディスパッチ・アプリケーション・プログラミング・インターフェース（ＡＰＩ）２１２により、使用可能リソース、パフォーマンス履歴などを含むがこれらに限定されない１つまたは複数の条件に基づいて、最適化した方法で要求ディスパッチを自動的に実行することができる。一実施形態では、ＡＰＩ２１２は、既存の要求ディスパッチャをカプセル化するラッパ・クラスにすることができる。他の実施形態では、ＡＰＩ２１２は、伝統的な要求ディスパッチャへの「ドロップイン」置換にすることができる。すなわち、既存の実行可能コードは、ＡＰＩ２１２のパフォーマンス上の恩恵を獲得している間、未変更のままになる可能性がある。一実施形態では、要求ディスパッチャ２４４は、要求ディスパッチの透明な動的モード実行を可能にするトランスポート・チャネル・チェーン２４０のコンポーネントにすることができる。

ＡＰＩ２１２を使用すると、アプリケーション開発者は、使用可能コンピューティング・リソースに基づいて要求ディスパッチ２１４をランタイムにおいて最適実行モードで処理することができる。一実施形態では、ＡＰＩ２１２は、IBM WEBSPHEREというWebコンテナ・プラットフォームのコンポーネントにすることができる。たとえば、アプリケーション開発者は、１つまたは複数のインポート・ディレクティブ（たとえば、「import com.ibm.Websphere.Webcontainer.RequestDispatch」）を介して要求ディスパッチ機能にアクセスすることができる。要求ディスパッチ２１４は、実行のカスタマイズを可能にするために１つまたは複数のパラメータを含むことができる。一実施形態では、引数（たとえば、ａｕｔｏ、５００ｍｓ）により、アプリケーション開発者は要求ディスパッチ挙動の一部分を制御することができる。さらに、ＡＰＩ２１２は、要求ディスパッチをネイティブに管理しモニターするための機能を可能にし、開発者が実行コードおよびランタイム環境の制御を維持できるようにすることができる。

一実施形態では、要求ディスパッチャ２４４は、オープン・システム間相互接続モデル２３０のトランスポート層２３２内に常駐することができる。ディスパッチャ２４４は、適切なWebコンテナ２４２に対するＨＴＴＰ２４６の要求を透過的に受信しディスパッチすることができる。このため、ディスパッチャ２４４は、配備されたアプリケーションおよびアプリケーション制限とは無関係に機能することができる。

本明細書に提示されている図面は、例示のためのものであり、いずれの点でも本発明を限定するものと解釈してはならない。一実施形態では、要求ディスパッチ構文が伝統的な構文と同一になり得るように、ＡＰＩ２１２はアプリケーション開発者にとって透過的なものにすることができる。さらに、ＡＰＩ２１２は、Webアプリケーションに対して自動的に機能を提供する基本パッケージのコンポーネントにすることができる。すなわち、アプリケーション開発者は、ＡＰＩ２１２の機能を手動でインポートする必要はない。

図３は、本明細書に開示されている発明的配置の一実施形態により、履歴メトリックを使用して要求ディスパッチ実行モードをプログラムによって決定するためのシステム３００を示すブロック図である。システム３００では、要求ディスパッチャ３４０により、サーブレット３２４に関連するディスパッチ３２６を自動決定モードで実行することができる。このプログラム決定モードは、同期実行モードおよび非同期実行モードにすることができる。一実施形態では、自動決定実行モードは伝統的な方法で実行することができる。すなわち、ディスパッチャ３４０の機能を可能にするために、ディスパッチ挙動あるいはオーバヘッドまたはその両方の変更はまったく不要である。一実施形態では、エンジン３４２は、要求ディスパッチ３２６のその後の実行のための実行モードを自動的に決定することができる。このため、ディスパッチ３２６の各インスタンスは、サーバ３２０のリソース可用性に応答して、同期または非同期モードで実行することができる。

本明細書で使用する各サーブレット３２４は、要求ディスパッチ３２６を介して１つまたは複数の実行可能リソースに関連付けることができる。サーブレット３２４は、JAVA 2 ENTERPRISE EDITION（J2EE）アプリケーション・サーバ３２０（または、企図された他の諸実施形態ではその他のタイプのサーバ）のWebコンテナ３２３内で実行することができる。Webコンテナ３２３は、JAVA仮想マシン・ランタイム環境などの動的ランタイム環境にすることができる。たとえば、サーブレット３２４は、ブラウザ・インターフェース３１２内で要求側クライアント３１０に対してWebベースのコンテンツ（たとえば、Webページ）を提示可能なWebアプリケーションにすることができる。各要求ディスパッチ３２６は、プロセスＩＤもしくは固有キーあるいはリソースＩＤ（たとえば、ユニフォーム・リソース・ロケータ）またはその両方などの固有識別値に関連付けることができる。一実施形態では、固有キーは自動生成値（たとえば、ディスパッチ・エンジン３４２による）または手動決定値にすることができる。ある事例では、固有識別値は注釈（またはソース・コード・コメント）として保管することができ、これはコンパイル時に抽出することができる。

サーブレット３２４は、要求ディスパッチ３２６の実行をトリガすることができる要求３８０を受信することができる。要求ディスパッチ３２６がランタイム環境３２３によって検出されると、ディスパッチ３２６を分析して、ユーザ指定のリソースＩＤに基づいてどのリソースを実行すべきかを判断することができる。一実施形態では、ディスパッチャ３４０は、指定のリソースの実行について、異なるWebコンテナ内で実行されるサーブレットなどの他のランタイム環境と交渉することができる。

要求ディスパッチャ３４０は、１つまたは複数のルール３４６あるいは設定またはその両方に基づいて、ディスパッチ３２６を明確に識別し実行することができる。すなわち、ディスパッチャ３４０は、サーバ３２０のリソース可用性（たとえば、サーバ負荷）に適合するように構成することができる。要求ディスパッチャ３４０は、ディスパッチ・エンジン３４２と、メトリック・エンジン３４３と、パフォーマンス・モニター３４４と、ルール３４６と、インターフェース３５２とを含むことができる。一実施形態では、ディスパッチャ３４０は、Webコンテナ３２３に対するプラグ可能拡張部分にすることができる。設定３４８は、ユーザ確立設定または自動決定設定にすることができる。たとえば、ディスパッチに関するデフォルト・タイムアウト値は、サーブレット３２４のパフォーマンスに基づいて動的に決定することができる。

ディスパッチ・エンジン３４２は、ディスパッチ３２６を処理し、履歴メトリック３５０を使用して適切な実行モードをプログラムによって決定することができる。エンジン３４２は、ディスパッチ３２６に関連するローカルおよびリモート・リソースの識別あるいは実行またはその両方を担当することができる。リソース処理がリモートで実行される事例では、エンジン３４２は、その処理を実行できるリモート・プロセッサに要求を転送することができる。リソース処理がローカルで実行される事例では、エンジン３４２は要求ディスパッチ３２６を管理することができる。

メトリック・エンジン３４３は、サーブレット３２４あるいはディスパッチ３２６またはその両方に関連する履歴メトリックを収集することができる。たとえば、高レベル・メトリックを入手することができるサーブレット３２４レベルでメトリックを収集することができる。ある事例では、メトリック・エンジン３４３は、リアルタイムでまたはほぼリアルタイムでメトリックを収集することができる。たとえば、エンジン３４３は、最後のＹ秒にわたり最後のＸ個のディスパッチ３２６を追跡するように構成することができ、ＸおよびＹはユーザが構成可能である。さらに、メトリック・エンジン３４３は、インターフェース３５２を介して提示可能なWebコンテナ３２３のリアルタイム・パフォーマンスをモニターするために使用することができる。

履歴メトリック３５０は、待ち時間、実行モード、およびメモリ使用率などのリソース情報を含むことができる。履歴メトリック３５０は、各ディスパッチ３２６の実行に関連付けることができる。一実施形態では、各モード（たとえば、非同期および同期）に関するメトリックを計算して、各モードに関する集約メトリックの評価を可能にすることができる。このように、エンジン３４３は、実行の前にディスパッチ３２６に関する適切な実行モードを計算することができる。他の実施形態では、ディスパッチ３２６に関連するメトリック３５０は、まとめて集約し、ルールセット３６０内のしきい値（たとえば、ルール３６０）に対して評価することができる。たとえば、非同期実行に関連するメモリ・コストをメモリ割り当て値（たとえば、しきい値）と比較して、非同期実行のオーバヘッドが最適選択肢であるかどうかを判断することができる。他の事例では、非同期コンテキストをセットアップ／破壊するための時間のオーバヘッドを前に確立したしきい値と比較して、どちらのモード（非同期または同期）を使用すべきかを判断することができる。

ルールセット３４６は、ディスパッチ３２６の実行モードを決定するための１つまたは複数の任意に複雑なルールで構成することができる。ルールセット３４６は、ユーザが確立することができるか、あるいはヒューリスティックに決定することができるか、またはその両方を行うことができる。一実施形態では、複数のメトリックをまとめて評価して、実行モードを決定することができる。ルールセット３４６は、しきい値、実行モード、要求ディスパッチに関連するイベント・ハンドラなどを含むことができるが、これらに限定されない。たとえば、しきい値はユーザ確立設定または自動決定値にすることができる。ルールセット３４６は、応答３８２を準備するために使用することができる、使用すべき集約のタイプ（たとえば、サーバ側対クライアント側）をさらに指定することができる。ディスパッチ３２６の実行が完了すると、応答３８２を生成し、ネットワーク３７０を介してクライアント３１０に伝達することができる。

本明細書に提示されている図面は、例示のためのものであり、いずれの点でも本発明を限定するものと解釈してはならない。システム３００は、分散コンピューティング環境、ネットワーク・コンピューティング環境、サービス指向アーキテクチャ（ＳＯＡ）などの１つまたは複数のコンポーネントにすることができる。一実施形態では、システム３００は、IBM WEBSPHEREアプリケーション・サーバの１つまたは複数のコンポーネントにすることができる。他の実施形態では、システム３００は、.ＮＥＴフレームワーク（または本明細書に記載されている目的のためにリソースを含むことができる任意の他のフレームワーク）の１つまたは複数のコンポーネントを含むことができる。

図４は、本明細書に開示されている発明的配置の一実施形態により、履歴メトリックを使用して要求ディスパッチに関する実行モードをプログラムによって決定するための１組のインターフェース４１０、４４０を示すブロック図である。インターフェース４１０、４４０は、システム３００のコンテキストで提示することができる。インターフェース４１０では、Webコンテナ内で実行される１つまたは複数のWebアプリケーションに関連する要求ディスパッチはセクション４１２に提示することができる。Webアプリケーションは、JAVAサーブレット、JAVA SERVER PAGES（JSP）などの１つまたは複数の実行可能コード・エンティティにすることができる。インターフェース４４０では、要求ディスパッチ４１４に関連するメトリックを提示することができる。

一実施形態では、要求ディスパッチおよびメトリック４４２の提示はリアルタイムで行うことができ、実行スナップショットを容易に入手できるようになる。

インターフェース４１０は、１つまたは複数の実行中の要求ディスパッチおよび従属要求ディスパッチの管理を可能にすることができる。インターフェース４１０は、セクション４１２、４２０と、対話式インターフェース・エレメント４２２、４３０、４３２とを含むことができる。インターフェース４１０では、要求ディスパッチ４１４に関連する情報をセクション４１２内に提示することができる。要求ディスパッチ情報は、プロセスＩＤ、実行持続期間、実行モードなどを含むことができるが、これらに限定されない。たとえば、セクション４１２は、サーブレットＡに関連する各要求ディスパッチと従属ディスパッチを提示することができる。一実施形態では、管理者は要求ディスパッチのグループを選択的に管理することができる。インターフェース４１０は、アクティブ・ルール、パフォーマンス・メトリックなどの追加情報を提示することができる。

選択された要求ディスパッチ４１４に関連する情報はセクション４２０に提示することができる。たとえば、インターフェース・エレメント４３０と対話することにより、ディスパッチ要求に関連する情報を提示することができる。ある事例では、セクション４２０は、タイムアウト値、実行モードなどの要求ディスパッチ値の変更を可能にすることができる。すなわち、自動最適化が不成功であると判明したときに、要求ディスパッチのリアルタイム手動最適化を達成することができる。一実施形態では、インターフェース４１０はスレッド管理機能を可能にすることができる。たとえば、インターフェース・エレメント４３２により、選択された要求ディスパッチを終了することができる。インターフェース・エレメント４２２との対話により、検査インターフェース４４０を提示することができる。

インターフェース４４０は、選択された要求ディスパッチ４１４に関連するメトリックを提示することができるセクション４４２を含むことができる。セクション４４２は、プロセッサ使用率、実行持続期間、およびメモリ使用率などの履歴メトリックを含むことができる。たとえば、セクション４４２は、収集した履歴メトリックを使用して、要求ディスパッチの平均リソース負荷を提示することができる。一実施形態では、履歴メトリックは複数レベルの細分性で提示することができる。たとえば、履歴メトリックは、日、週、月などの単位で提示することができる。

本明細書に提示されている図面は、例示のためのものであり、いずれの点でも本発明を限定するものと解釈してはならない。一実施形態では、インターフェース４１０、４４０は、JAVA 2 ENTERPRISE EDITION最適化ツールの１つまたは複数の画面にすることができる。他の実施形態では、インターフェース４１０、４４０は統合開発環境（ＩＤＥ）のコンポーネントにすることができる。インターフェース４１０、４４０は、グラフィカル・ユーザ・インターフェース（ＧＵＩ）、音声ユーザ・インターフェース（ＶＵＩ）、マルチモード・インターフェイスなどにすることができる。インターフェース４１０、４４０に関連するインターフェース・エレメントは、対話式ボタン、ドロップダウン・メニュー、無線選択エレメントなどを含むことができるが、これらに限定されない。

本明細書で使用する用語は、特定の諸実施形態を記述するためのものであり、本発明を限定するためのものではない。本明細書で使用する単数形「a」、「an」、および「the」は、文脈が明確に他の指示を示さない限り、複数形も含むものである。「comprises」あるいは「comprising」という用語またはその両方は、本明細書で使用する場合、明記された特徴、整数、ステップ、操作、要素、あるいはコンポーネント、またはこれらの組み合わせの存在を指定するものであるが、１つまたは複数のその他の特徴、整数、ステップ、操作、要素、コンポーネント、あるいはそのグループ、またはこれらの組み合わせの存在または追加を排除するものではないことがさらに理解されるであろう。

以下の特許請求の範囲に記載されたすべての手段またはステップならびに機能要素に対応する構造体、材料、行為、および同等のものは、具体的に請求されたその他の請求要素と組み合わせてその機能を実行するための任意の構造体、材料、または行為を含むためのものである。本発明の説明は、例示および解説のために提示されたものであり、網羅するためまたは開示された形式に本発明を限定するためのものではない。多くの変更および変形は、本発明の範囲を逸脱せずに当業者にとって明白になるであろう。この実施形態は、本発明の原理および実用的な適用例を最も良く説明するため、ならびにその他の当業者が企図された特定の用途に適した様々な変更を含む様々な実施形態について本発明を理解できるようにするために、選択され記載されたものである。

図１〜図４内の流れ図およびブロック図は、本発明の様々な諸実施形態によるシステム、方法、およびコンピュータ・プログラムについて可能な実現例のアーキテクチャ、機能、および動作を例示している。この点に関しては、流れ図またはブロック図内の各ブロックは、指定の論理機能（複数も可）を実現するための１つまたは複数の実行可能命令を含む、コードのモジュール、セグメント、または一部分を表すことができる。また、いくつかの代替実現例では、ブロック内に示された機能は図面内に示された順序から外れて行われる可能性があることにも留意されたい。たとえば、連続して示されている２つのブロックは、関係する機能に応じて、実際にはほぼ同時に実行される場合もあれば、ときには逆の順序で実行される場合もある。また、ブロック図あるいは流れ図またはその両方の各ブロックおよびブロック図あるいは流れ図またはその両方内の複数ブロックの組み合わせは、指定の機能または行為を実行する特殊目的ハードウェアベースのシステムあるいは特殊目的ハードウェアとコンピュータ命令との組み合わせによって実現可能であることも留意されるであろう。

Claims (19)

1. 要求をディスパッチするための方法であって、
   実行時間中に第１の実行可能コード内で実行すべき要求ディスパッチを識別することであって、前記要求ディスパッチが識別値に関連付けられ、前記要求ディスパッチの前記識別値が実行すべき第２の実行可能コードを識別することと、
   前記第２の実行可能コードの実行の前に、前記第２の実行可能コードを実行するための実行モードを決定することであって、前記決定アクションがパフォーマンス・メトリックおよびしきい値を評価することを含み、前記しきい値がユーザ確立値およびプログラム確立値のうちの少なくとも１つであり、前記実行モードが非同期実行モードまたは同期実行モードであり、前記パフォーマンス・メトリックが前記要求ディスパッチの過去の実行の度に収集されたものであることと、
   前記実行モードの前記決定に応答して、前記実行モードに基づいて前記要求ディスパッチを実行することであって、前記同期実行モードの結果、前記第１の実行可能コードが停止し、前記第２の実行可能コードが開始して完了し、その後、前記停止した第１の実行可能コードが実行を再開し、前記非同期実行モードの結果、前記第１および第２の実行可能コードが同時に実行されることと、
   前記要求ディスパッチの実行時にパフォーマンス・メトリックを収集すること
   を含み、
   前記要求ディスパッチは、前記パフォーマンス・メトリックが前記しきい値を超え損なったときに、同期的に実行され、前記パフォーマンス・メトリックが前記しきい値を超えたときに、非同期的に実行される、方法。
2. 前記第１および第２の実行可能コードがWebコンテナのコンポーネント内に常駐し、前記Webコンテナがランタイム環境に関連付けられる、請求項１記載の方法。
3. 前記要求ディスパッチに関連する前記固有識別値が、自動生成固有識別値、ユニフォーム・リソースＩＤ（ＵＲＩ）、固有パス値、および固有照会ストリングのうちの少なくとも１つである、請求項１記載の方法。
4. 前記第１および第２の実行可能コードの前記実行モードがその後の実行中に動的に調整することができ、前記第１および第２の実行可能コードが、JAVAサーブレット、JAVA SERVER PAGE（JSP）、JAVA BEAN、およびJAVA対応ポートレットのうちの少なくとも１つである、請求項１記載の方法。
5. 前記実行モードを決定することが、
   要求ディスパッチおよびその実行時間の履歴データを使用して前記パフォーマンス・メトリックを構築すること
   をさらに含む、請求項１記載の方法。
6. 前記要求ディスパッチを実行することが、
   前記要求ディスパッチの前記実行パフォーマンスに応答して、前記要求ディスパッチに関連するモード設定を第１の実行モードから第２の実行モードにトグル切り替えすることであって、前記モード設定が前記要求ディスパッチを実行すべき前記モードを示し、前記モードが非同期実行モードおよび同期実行モードのうちの少なくとも１つであり、前記トグル切り替えアクションの結果、前記要求ディスパッチの前記その後の実行が前記第２の実行モードで実行されること
   をさらに含む、請求項１記載の方法。
7. 前記パフォーマンス・メトリックが、前記要求ディスパッチの前記実行に関連するタイミング情報のうちの少なくとも１つである、請求項１記載の方法。
8. 前記要求ディスパッチの前記実行中に要求ディスパッチャに関連する少なくとも１つのパフォーマンス・メトリックをプログラムによって収集することであって、前記パフォーマンス・メトリックがリソース割り振り値であること
   をさらに含む、請求項１記載の方法。
9. 既存のディスパッチＡＰＩの機能を透過的にカプセル化することであって、前記既存のディスパッチＡＰＩが要求ディスパッチを同期実行モードで実行し、前記カプセル化により前記要求ディスパッチを非同期的または同期的に実行できること
   をさらに含む、請求項１記載の方法。
10. 要求をディスパッチするためのシステムであって、
    第１の実行可能コードに関連する要求ディスパッチを識別し実行することができるディスパッチ・エンジンであって、前記ディスパッチ・エンジンがランタイム環境内のトランスポート・チャネル・チェーンのコンポーネントであり、前記トランスポート・チャネル・チェーンがオープン・システム間相互接続（ＯＳＩ）層モデルのトランスポート層に関連付けられる、ディスパッチ・エンジンと、
    前記第１の実行可能コードに関連する要求ディスパッチであって、前記要求ディスパッチが固有識別値に関連付けられ、前記固有識別値が実行すべき固有リソースを識別し、前記要求ディスパッチが前記固有リソースの前記実行をトリガし、前記固有リソースが第２の実行可能コードである、要求ディスパッチと、
    前記要求ディスパッチに関連するパフォーマンス・メトリックであって、前記パフォーマンス・メトリックが前記要求ディスパッチの過去の実行の度に自動的に収集されたものであり、前記パフォーマンス・メトリックが前記要求ディスパッチの実行挙動を変更するために使用される、パフォーマンス・メトリックと、
    前記要求ディスパッチに関連するしきい値、実行モード、およびイベント・ハンドラのうちの少なくとも１つを確立するように構成されたルールセットであって、前記しきい値がユーザ確立設定および自動決定値のうちの少なくとも１つであり、前記実行モードが同期実行モードおよび非同期実行モードのうちの少なくとも１つであり、前記同期実行モードの結果、前記第１の実行可能コードが停止し、前記第２の実行可能コードが開始して完了し、その後、前記停止した第１の実行可能コードが実行を再開し、前記非同期実行モードの結果、前記第１および第２の実行可能コードが同時に実行される、ルールセットと
    を含み、
    前記要求ディスパッチは、前記パフォーマンス・メトリックが前記しきい値を超え損なったときに、同期的に実行され、前記パフォーマンス・メトリックが前記しきい値を超えたときに、非同期的に実行される、システム。
11. 前記要求ディスパッチに関連する前記固有識別値が、自動生成固有識別値、ユニフォーム・リソースＩＤ（ＵＲＩ）、固有パス値、および固有照会ストリングのうちの少なくとも１つである、請求項１０記載のシステム。
12. 固有要求ディスパッチを識別し、前記識別済み要求ディスパッチ・パフォーマンスをモニターするように構成されたパフォーマンス・モニターであって、前記識別およびモニターがリアルタイムで実行される、パフォーマンス・モニター
    をさらに含む、請求項１０記載のシステム。
13. 前記システムのユーザ・カスタマイズを可能にするユーザ・インターフェースであって、カスタマイズがユーザ確立しきい値、ユーザ確立パフォーマンス・メトリック、およびユーザ確立実行モードのうちの少なくとも１つである、ユーザ・インターフェース
    をさらに含む、請求項１０記載のシステム。
14. 前記ディスパッチ・エンジンが、少なくとも１つのパフォーマンス・メトリックに応答して、前記しきい値を変更することができる、請求項１０記載のシステム。
15. コンピュータ使用可能プログラム・コードがそれにより実施されたコンピュータ可読記憶媒体を含むコンピュータ・プログラムであって、前記コンピュータ使用可能プログラム・コードが、
    実行時間中に第１の実行可能コード内で実行すべき要求ディスパッチを識別するように動作可能な有形記憶媒体に保管されたコンピュータ使用可能プログラム・コードであって、前記要求ディスパッチが固有識別値に関連付けられ、前記要求ディスパッチの前記固有識別値が実行すべき第２の実行可能コードを識別する、コンピュータ使用可能プログラム・コードと、
    前記第２の実行可能コードの実行の前に、前記第２の実行可能コードを実行するための実行モードを決定するように動作可能な有形記憶媒体に保管されたコンピュータ使用可能プログラム・コードであって、前記決定アクションがパフォーマンス・メトリックおよびしきい値を評価することを含み、前記しきい値がユーザ確立値およびプログラム確立値のうちの少なくとも１つであり、前記実行モードが非同期実行モードまたは同期実行モードであり、前記パフォーマンス・メトリックが前記要求ディスパッチの過去の実行の度に収集されたものである、コンピュータ使用可能プログラム・コードと、
    前記決定アクションに応答して、前記実行モードに基づいて前記要求ディスパッチを実行するように動作可能な有形記憶媒体に保管されたコンピュータ使用可能プログラム・コードであって、前記同期実行モードの結果、前記第１の実行可能コードが停止し、前記第２の実行可能コードが開始して完了し、その後、前記停止した第１の実行可能コードが実行を再開し、前記非同期実行モードの結果、前記第１および第２の実行可能コードが同時に実行される、コンピュータ使用可能プログラム・コードと、
    前記要求ディスパッチの実行時にパフォーマンス・メトリックを収集する、コンピュータ使用可能プログラム・コードと
    を含み、
    前記要求ディスパッチは、前記パフォーマンス・メトリックが前記しきい値を超え損なったときに、同期的に実行され、前記パフォーマンス・メトリックが前記しきい値を超えたときに、非同期的に実行される、コンピュータ・プログラム。
16. 前記第１および第２の実行可能コードがWebコンテナのコンポーネント内に常駐し、前記Webコンテナがランタイム環境に関連付けられる、請求項１５記載のコンピュータ・プログラム。
17. 前記要求ディスパッチに関連する少なくとも１つのパフォーマンス・メトリックを識別するように動作可能な有形記憶媒体に保管されたコンピュータ使用可能プログラム・コードであって、前記パフォーマンス・メトリックが履歴メトリックであり、前記履歴メトリックが前記要求ディスパッチの履歴実行の少なくとも１つのプロパティを示す統計値である、コンピュータ使用可能プログラム・コード
    をさらに含む、請求項１５記載のコンピュータ・プログラム。
18. 前記要求ディスパッチの前記実行パフォーマンスに応答して、前記要求ディスパッチに関連するモード設定を第１の実行モードから第２の実行モードにトグル切り替えするように動作可能な有形記憶媒体に保管されたコンピュータ使用可能プログラム・コードであって、前記モード設定が前記要求ディスパッチを実行すべき前記モードを示し、前記モードが非同期実行モードおよび同期実行モードのうちの少なくとも１つであり、前記トグル切り替えアクションの結果、前記要求ディスパッチの前記その後の実行が前記第２の実行モードで実行される、コンピュータ使用可能プログラム・コード
    をさらに含む、請求項１５記載のコンピュータ・プログラム。
19. 前記要求ディスパッチの前記実行中に要求ディスパッチャに関連する少なくとも１つのパフォーマンス・メトリックを収集するように動作可能な有形記憶媒体に保管されたコンピュータ使用可能プログラム・コードであって、前記パフォーマンス・メトリックがリソース割り振り値である、コンピュータ使用可能プログラム・コードをさらに含む、請求項１５記載のコンピュータ・プログラム。

Images