(57)【特許請求の範囲】
【請求項１】
コンピュータを、
ホストアプリケーションでクライアントアプリケーションから受け取ったハイパーテキスト転送プロトコル（ＨＴＴＰ）要求を論理的に表す手段であって、前記受け取ったＨＴＴＰ要求に関連する少なくとも１つのプロパティをカプセル化する手段、並びに、
該手段に対応する手段であって、各要求イベントは対応するイベントを有し、及び、前記要求イベントに対応する前記イベントが生じたときに前記要求イベントに関連付けてアプリケーションとモジュールが登録されていればコールバックを生成し、各コールバックが、前記要求イベントに関連付けて登録される各アプリケーションと各モジュールを開始して前記表す手段を処理する手段
として機能させるプログラム。
【請求項２】
前記複数の要求イベントは決定論的な順番（deterministic order)を有することを特徴とする請求項１に記載のプログラム。
【請求項３】
前記複数の要求イベントのうち少なくとも１つは同期式要求イベントであることを特徴とする請求項２に記載のプログラム。
【請求項４】
前記複数の要求イベントのうち少なくとも１つは非同期式要求イベントであることを特徴とする請求項２に記載のプログラム。
【請求項５】
前記複数の要求イベントは非決定論的な順番（non-deterministic order）を有する少なくとも１つの要求イベントをさらに含むことを特徴とする請求項２に記載のプログラム。
【請求項６】
前記複数の要求イベントは非決定論的な順番を有することを特徴とする請求項１に記載のプログラム。
【請求項７】
前記複数の非決定論的な順番の要求イベントはエラーイベントを含むことを特徴とする請求項６に記載のプログラム。
【請求項８】
モジュールが複数の要求イベントに関連付けられて登録されることを特徴とする請求項１に記載のプログラム。
【請求項９】
前記複数の要求イベントを有する手段は、前記ホストアプリケーションでクライアントアプリケーションから受け取った各ＨＴＴＰ要求について該手段の別個のインスタンスであることを特徴とする請求項１に記載のプログラム。
【請求項１０】
前記カプセル化する手段は、前記受け取ったＨＴＴＰ要求を解析して、前記ＨＴＴＰ要求を論理的に表すことを特徴とする請求項１に記載のプログラム。
【請求項１１】
ハイパーテキスト転送プロトコル（ＨＴＴＰ）要求を処理する方法であって、
ホストアプリケーションでクライアントアプリケーションから受け取ったＨＴＴＰ要求を論理的に表し、前記受け取った要求に関連する少なくとも１つのプロパティをカプセル化するコンテキストオブジェクトを形成するステップと、
前記コンテキストオブジェクトに対応し、それぞれが対応するイベントを有する複数の要求イベントを有するイベントパイプラインを形成するステップと、
要求イベントに対応するイベントが生じ且つ前記要求イベントに関連してアプリケーションとモジュールが登録されたときにコールバックを生成するステップと、
前記コンテキストオブジェクトを処理するための前記コールバックに応答して、前記要求イベントに関連付けて登録される各アプリケーションと各モジュールを開始するステップと
を含むことを特徴とする方法。
【請求項１２】
少なくとも１つの選択された要求イベントに関連付けてモジュールを登録するステップをさらに含むことを特徴とする請求項１１に記載の方法。
【請求項１３】
選択された要求イベントに関連付けて複数のモジュールを登録するステップをさらに含むことを特徴とする請求項１１に記載の方法。
【請求項１４】
前記複数の要求イベントは決定論的な順番を有することを特徴とする請求項１１に記載の方法。
【請求項１５】
前記複数の要求イベントのうち少なくとも１つは同期式要求イベントであることを特徴とする請求項１４に記載の方法。
【請求項１６】
前記複数の要求イベントのうち少なくとも１つは非同期式要求イベントであることを特徴とする請求項１４に記載の方法。
【請求項１７】
前記複数の要求イベントは非決定論的な順番を有する少なくとも１つの要求イベントをさらに含むことを特徴とする請求項１６に記載の方法。
【請求項１８】
前記複数の要求イベントは非決定論的な順番を有することを特徴とする請求項１１に記載の方法。
【請求項１９】
前記複数の非決定論的な順番の要求イベントはエラーイベントを含むことを特徴とする請求項１８に記載の方法。
【請求項２０】
前記コンテキストオブジェクトに対応する前記イベントパイプラインを形成する前記ステップでは、前記ホストアプリケーションでクライアントアプリケーションから受け取った各ＨＴＴＰ要求について別個のインスタンスとして前記イベントパイプラインを形成することを特徴とする請求項１１に記載の方法。
【請求項２１】
前記コンテキストオブジェクトを形成する前記ステップは、前記受け取ったＨＴＴＰ要求を解析して前記コンテキストオブジェクトを形成するステップを含むことを特徴とする請求項１１に記載の方法。
【請求項２２】
コンピュータを、
ホストアプリケーションでクライアントアプリケーションから受け取ったハイパーテキスト転送プロトコル（ＨＴＴＰ）要求を論理的に表し、前記受け取った要求に関連する少なくとも１つのプロパティをカプセル化するコンテキストオブジェクトを形成する手段、
前記コンテキストオブジェクトに対応し、それぞれが対応するイベントを有する複数の要求イベントを有するイベントパイプラインを形成する手段、
要求イベントに対応するイベントが生じ且つ前記要求イベントに関連してアプリケーションとモジュールが登録されたときにコールバックを生成する手段、並びに、
前記コンテキストオブジェクトを処理するための前記コールバックに応答して、前記要求イベントに関連付けて登録される各アプリケーションと各モジュールを開始する手段
として機能させるプログラムを含むコンピュータ可読媒体。
【請求項２３】
前記プログラムは前記コンピュータを、少なくとも１つの選択された要求イベントに関連付けてモジュールを登録する手段としてさらに機能させることを特徴とする請求項２２に記載のコンピュータ可読媒体。
【請求項２４】
前記プログラムは前記コンピュータを、選択された要求イベントに関連付けて複数のモジュールを登録する手段としてさらに機能させることを特徴とする請求項２２に記載のコンピュータ可読媒体。
【請求項２５】
前記複数の要求イベントは決定論的な順番を有することを特徴とする請求項２２に記載のコンピュータ可読媒体。
【請求項２６】
前記複数の要求イベントのうち少なくとも１つは同期式要求イベントであることを特徴とする請求項２２に記載のコンピュータ可読媒体。
【請求項２７】
前記複数の要求イベントのうち少なくとも１つは非同期式要求イベントであることを特徴とする請求項２２に記載のコンピュータ可読媒体。
【請求項２８】
前記複数の要求イベントは非決定論的な順番を有する少なくとも１つの要求イベントをさらに含むことを特徴とする請求項２５に記載のコンピュータ可読媒体。
【請求項２９】
前記複数の要求イベントは非決定論的な順番を有することを特徴とする請求項２２に記載のコンピュータ可読媒体。
【請求項３０】
前記複数の非決定論的な順番の要求イベントはエラーイベントを含むことを特徴とする請求項２９に記載のコンピュータ可読媒体。
【請求項３１】
前記イベントパイプラインを形成する前記手段は、ホストアプリケーションでクライアントアプリケーションから受け取った各ＨＴＴＰ要求について別個のインスタンスとして前記イベントパイプラインを形成することを特徴とする請求項２２に記載のコンピュータ可読媒体。
【請求項３２】
前記コンテキストオブジェクトを形成する前記手段は、前記受け取ったＨＴＴＰ要求を解析して、前記コンテキストオブジェクトを形成することを特徴とする請求項２２に記載のコンピュータ可読媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
この特許文書の開示の一部には、著作権保護の対象となる材料が含まれる。著作権所有者は、特許商標庁の特許ファイルまたは記録に現れる特許文書または特許開示の何人による複製にも異議はないが、それ以外では、すべての著作権を留保する。
【０００２】
本発明はハイパーテキスト転送プロトコル（ＨＴＴＰ）要求の処理に関する。より詳細には、本発明はＨＴＴＰ要求を処理するシステムおよび方法に関する。
【０００３】
【従来の技術】
図２は、従来技術でＨＴＴＰ要求を処理するウェブサイトアプリケーションの機能ブロック図を示す。クライアントコンピュータ２０２に置かれたウェブブラウザ２０１は、よく知られた方法で、インターネットなどのコンピュータネットワーク２０３を介して、選択されたＵＲＬ２０５に対するホストサーバコンピュータ２０４にＨＴＴＰ要求を送信する。ホストサーバコンピュータ２０４に特有のアプリケーション２０６を実行するホストサーバコンピュータ２０４は、ＨＴＴＰ要求を受信し、その要求の内容およびアプリケーション２０６の処理に基づいて、要求されたウェブページ２０５のコンテンツにアクセスする。そのＨＴＴＰ要求への応答がウェブサーバ２０７によってウェブブラウザ２０１に送られる前に、アプリケーション２０６は、ホストサーバコンピュータ２０４上で実行中のソフトウェアを使用して要求されたウェブページ２０５を作成し、また、そのウェブページ２０５のコンテンツに基づいてウェブサービスプロキシなどのウェブサービス２０８を作成する。
【０００４】
ホストサーバコンピュータ２０４上で実行中のソフトウェアが、例えば要求しているユーザを認証する機能モジュール２０９、要求しているユーザに要求されたウェブページにアクセスする権限が付与されているかどうかを判定する機能モジュール２０９、応答を暗号化するための機能モジュール２０９などを使用して、要求されたページを作成する前および／または後に、アプリケーション２０６は、選択された方法で要求を処理することもできる。ＪＡＶＡ（登録商標）サーブレットなどの機能モジュール２０９は、ＨＴＴＰ要求を連続した方法で処理する。すなわち、機能モジュール２０９ａは、機能モジュール２０９ｂが要求を処理する前にその要求を処理するために選択され、機能モジュール２０９ｃは、機能モジュール２０９ｂの後に要求を処理するために選択される。例えば、機能モジュール２０９ａは、アプリケーション２０６に対してユーザ認証を提供することができる。一旦、ユーザが認証されると、機能モジュール２０９ｂはユーザ認証を提供することができる。これに続いて、機能モジュール２０９ｃは、要求しているユーザの認証された識別（ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）に基づく広告機能を提供することができる。
【０００５】
ＨＴＴＰアプリケーション開発者が、カスタムロギング、インターネット規模のセキュリティ、またはデータのキャッシングなどのカスタマイズされた機能を含めるためにモジュール２０９の機能を変更することによってアプリケーション２０６の機能を変更する必要がある場合、開発者は、機能モジュールをカスタム生成すること、および／またはサードパーティによって開発された適切な機能モジュールを使用することが必要になる場合がある。
【０００６】
【発明が解決しようとする課題】
この従来の手法に伴う問題は、新しい機能モジュールが既にその場にある別の機能モジュールと矛盾するように、アプリケーション開発者は他のすべての機能モジュールの処理を完全に理解する必要があるということである。さらに、アプリケーション開発者が処理シーケンスのどこに新しい機能モジュールまたは更新された機能モジュールを挿入するかを正確に知ることは困難である。また、ウェブサイトがユーザに対して比較的高速なウェブサイトとしてみえるように、ホストサーバコンピュータ２０４上で実行中のソフトウェアが要求されたウェブページを作成する前に、要求しているユーザに対して機能モジュールがコンテンツおよび／またはヘッダーを提示する状況では、そのコンテンツおよび／またはヘッダーは処理に対して最早使用可能ではないので、従来型の処理シーケンスで後に機能モジュールによって実行されるいかなる要求処理も最早実行することはできない。
【０００７】
ＨＴＴＰアプリケーション開発者がＨＴＴＰアプリケーションに容易に機能を追加する方法が求められている。さらに、異なるモジュール開発者によって開発されたＨＴＴＰモジュールが多くのＨＴＴＰアプリケーションと共存することができるような、アプリケーション間で再利用可能な機能を作成する方法も求められている。さらに、別の機能モジュールと矛盾する可能性のある機能モジュールの連続した配置を避ける、ＨＴＴＰ要求の処理を提供する方法も求められている。
【０００８】
【課題を解決するための手段】
本発明は、ＨＴＴＰアプリケーション開発者がＨＴＴＰアプリケーションに容易に機能を追加する方法を提供する。さらに、本発明は、異なるモジュール開発者によって開発されたＨＴＴＰモジュールが多くのＨＴＴＰアプリケーションと共存することができるような、アプリケーション間で再使用可能な機能を作成する方法も提供する。本発明は、また、別の機能モジュールと矛盾する可能性のある機能モジュールの連続した配置を避ける、ＨＴＴＰ要求の処理を提供する方法も提供する。
【０００９】
これらの利点を達成するために、本発明は、ＨＴＴＰアプリケーションおよびＨＴＴＰモジュールが要求／応答サイクルの異なる段階で加わえるように、オブジェクト指向型でイベント駆動型のインフラストラクチャを公開することによって、ＨＴＴＰ要求に応答するためのアプリケーションランタイムを提供する。すなわち、ＨＴＴＰ要求の存続期間中に同期式要求イベントまたは非同期式要求イベントが発生されるとき、コールバックに対してメソッドが登録される。
【００１０】
本発明によれば、ＨＴＴＰ要求処理ランタイムは、コンテキストオブジェクトおよびイベントパイプラインを含む。コンテキストオブジェクトは、ホストアプリケーションでクライアントアプリケーションから受け取ったＨＴＴＰ要求を解析することによって作成され、そのＨＴＴＰ要求を論理的に表す。コンテキストオブジェクトは、受け取ったＨＴＴＰ要求に関連するプロパティ（ｐｒｏｐｅｒｔｉｅｓ）を好適にカプセル化する。コンテキストオブジェクトは、複数の要求イベントを含むイベントパイプラインによって処理される。このパイプラインは、１つのＨＴＴＰ要求を一度に処理し、そのパイプラインが１つのＨＴＴＰ要求の処理を完了すると、別のＨＴＴＰ要求が処理される。各要求イベントは対応するイベントを有しており、要求イベントに対応するイベントが生じたとき、および少なくとも１つのアプリケーションまたはモジュールが要求イベントに関連付けて登録されるときに、その要求イベントはコールバックを生成する。各コールバックは、コンテキストオブジェクトを処理するための要求イベントに関連付けて登録される各モジュールをインスタンス生成（ｉｎｓｔａｎｔｉａｔｅｓ）する。複数の要求イベントは、決定論的な順番（ｄｅｔｅｒｍｉｎｉｓｔｉｃ  ｏｒｄｅｒ）で同期および／または非同期であるイベントを含むことが好ましい。さらに、複数の要求イベントは、エラーイベントなどの非決定論的な順番を有する少なくとも１つの要求を含むことができる。本発明によれば、モジュールには複数の要求イベントを登録することができる。
【００１１】
【発明の実施の形態】
本発明は、同様の参照番号が同様の要素を示す添付の図面で例示として示されているものであって、この図面で限定されるものではない。
【００１２】
本発明は、図１および３を参照してより容易に説明することができる。図１は、本発明の様々な態様を実施するために使用することができる従来型汎用デジタルコンピューティング環境の概略図である。図１では、コンピュータ１００は、処理装置１１０、システムメモリ１２０、およびこのシステムメモリを含めて様々なシステム構成要素を処理装置１１０に結合するシステムバス１３０を含む。システムバス１３０は、メモリバスまたはメモリコントローラ、周辺バス、および様々なバスアーキテクチャを使用するローカルバスを含めて複数タイプのバス構造のいずれかであってよい。システムメモリ１２０は、読み出し専用メモリ（ＲＯＭ）１４０およびランダムアクセスメモリ（ＲＡＭ）１５０を含む。
【００１３】
コンピュータ１００の要素間で、情報を例えば起動時中に転送するために役立つ基本ルーチンを含んでいる基本入出力システム１６０（ＢＩＯＳ）は、ＲＯＭ１４０に記憶されている。コンピュータ１００は、ハードディスク（図示せず）に対して読み出しおよび書き込みを行うためのハードディスクドライブ１７０、取り外し可能磁気ディスク１９０に対して読み出しおよび書き込みを行うための磁気ディスクドライブ１８０、およびＣＤ−ＲＯＭまたは他の光学媒体などの取り外し可能光学ディスク１９２に対して読み出しおよび書き込みを行うための光学ディスクドライブ１９１も含む。ハードディスクドライブ１７０、磁気ディスクドライブ１８０、および光学ディスクドライブ１９１は、それぞれハードディスクドライブインターフェース１９２、磁気ディスクドライブインターフェース１９３、および光学ディスクドライブインターフェース１９４によってシステムバス１３０に接続されている。これらのドライブおよびそれらに関連するコンピュータ可読媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、およびパーソナルコンピュータ１００のための他のデータの不揮発性記憶装置を提供する。コンピュータによってアクセス可能なデータを記憶することができる別のタイプのコンピュータ可読媒体、例えば磁気カセット、フラッシュメモリカード、デジタルビデオディスク、Ｂｅｍｏｕｌｌｉのカートリッジ、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）なども例示的動作環境内で使用することができることが、当業者には明らかになろう。
【００１４】
オペレーティングシステム１９５、１つまたは複数のアプリケーションプログラム１９６、他のプログラムモジュール１９７およびプログラムデータ１９８を含めていくつかのプログラムモジュールを、ハードディスクドライブ１７０、磁気ディスク１９０、光学ディスク１９２、ＲＯＭ１４０またはＲＡＭ１５０に記憶することができる。ユーザは、キーボード１０１およびポインティングデバイス１０２などの入力装置を介してコンピュータ１００にコマンドおよび情報を入力することができる。その他の入力装置（図示せず）は、マイクロフォン、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナなどを含むことができる。これらおよび他の入力装置は、システムバスに結合されているシリアルポートインターフェース１０６を介して処理装置１１０に接続されることが多いが、他のインターフェース、例えばパラレル・ポート、ゲーム・ポート、またはユニバーサルシリアルバス（ＵＳＢ）などによって接続することもできる。さらに、これらの装置は、適切なインターフェース（図示せず）を介してシステムバス１３０に直接的に結合することができる。モニタ１０７または他のタイプの表示装置を、ビデオアダプタ１０８などのインターフェースを介してシステムバス１３０に接続することもできる。パーソナルコンピュータは、通常、モニタに加えてスピーカーおよびプリンタなどの他の周辺出力装置（図示せず）を含む。
【００１５】
コンピュータ１００は、遠隔コンピュータ１０９などの１つまたは複数の遠隔コンピュータへの論理接続によってネットワーク接続された環境で動作することができる。遠隔コンピュータ１０９は、サーバ、ルータ、ネットワークＰＣ、ピアデバイスまたは他の共通ネットワークノードであってよく、通常は、コンピュータ１００に関して述べた上記要素の多くのものまたはその全てを含む。但し、図１には記憶装置１１１しか示していない。図１に示す論理接続には、ローカルエリアネットワーク（ＬＡＮ）１１２およびワイドエリアネットワーク（ＷＡＮ）１１３が含まれる。このようなネットワーク接続された環境は、事務所、企業内コンピュータネットワーク、イントラネットおよびインターネットでは一般的なものである。
【００１６】
ＬＡＮネットワーク接続環境で使用されるとき、コンピュータ１００は、ネットワークインターフェースまたはアダプタ１１４を介してローカルエリアネットワーク１１２に接続される。ＷＡＮネットワーク接続環境で使用されるとき、パーソナルコンピュータ１００は、通常、モデム１１５、またはインターネットなどのワイドエリアネットワーク１１３を介して通信を確立する他の装置を含む。モデム１１５は内部モデムであっても外部モデムであってもよく、シリアルポートインターフェース１０６を介してシステムバス１３０に接続される。ネットワーク接続された環境では、パーソナルコンピュータ１００に関して述べたプログラムモジュール、またはその一部は遠隔記憶装置に記憶することができる。
【００１７】
図示したネットワーク接続は例示的なものであって、コンピュータ間に通信リンクを確立する他の技術を使用することができることも理解されよう。ＴＣＰ／ＩＰ、Ｅｔｈｅｒｎｅｔ（登録商標）、ＦＴＰ、ＨＴＴＰなどの様々な周知のプロトコルのいずれかの存在が想定され、システムは、ユーザに対してウェブベースのサーバからウェブページを取り出すことを可能にするためにクライアント・サーバ構成で動作することができる。ウェブページ上にデータを表示し、かつ操作するために、様々な従来型ウェブブラウザのどれでも使用することができる。
【００１８】
本発明の主要な態様は、ＨＴＴＰ要求に応答するイベントベースのアプリケーションランタイムを提供する。より具体的には、本発明のＡＳＰ．ＮＥＴ  ＨＴＴＰランタイムは、要求／応答サイクルの異なる段階で加わる高機能のアプリケーションを作成するために、アプリケーション開発者に対してオブジェクト指向型でイベント駆動型のインフラストラクチャを公開する。例えば、本発明のＡＳＰ．ＮＥＴ  ＨＴＴＰランタイムによって、アプリケーション開発者はＨＴＴＰアプリケーションを開発することができ、および／またはモジュール開発者は、任意の．ＮＥＴ言語で書かれたアプリケーションを使用して個々のＨＴＴＰ要求をインターセプトし、それによって加わり、および／またはそれを変更するための再使用可能なＨＴＴＰモジュールを開発することができる。これを達成するために、本発明は、ＨＴＴＰアプリケーション開発者および／またはＨＴＴＰモジュール開発者が、ＨＴＴＰ要求の存続期間中の特定の段階で呼び出されるメソッドをアプリケーションに登録することを可能にする。メソッドが登録されるこのインフラストラクチャは、従来型ウェブサーバのアプリケーションプログラムインターフェース（ＡＰＩ）フィルタに対する論理．ＮＥＴの代替品である。さらに、本発明は、ＡＳＰ．ＮＥＴの機能を変更することを可能にする。例えば、ＡＳＰ．ＮＥＴが特定のエリア内で十分な機能を提供しない場合、開発者は、基礎となるインフラストラクチャに関してより多くの知識を有する開発者の一部に対して準備されたレベルで、基礎となるアプリケーションインフラストラクチャを変更することができる。
【００１９】
図３は、本発明によるＡＳＰ．ＮＥＴ  ＨＴＴＰランタイムを使用したＨＴＴＰ要求を処理するウェブサイトアプリケーションの機能ブロック図である。ＡＳＰ．ＮＥＴ  ＨＴＴＰ要求処理ランタイムのアーキテクチャは、ＨＴＴＰ要求からＨＴＴＰＣｏｎｔｅｘｔオブジェクトを作成するアプリケーションと、ＨＴＴＰＣｏｎｔｅｘｔオブジェクトの存続期間中（すなわち、ＨＴＴＰ要求の存続期間中）にコールバックを生成するイベントパイプラインとを提供する。ＨＴＴＰＣｏｎｔｅｘｔオブジェクトは、受け取ったＨＴＴＰ要求に関連付けられており、その要求を処理するために必要なすべてのプロパティをカプセル化することによってその受け取ったＨＴＴＰ要求を論理的に表す。コールバックは、ＨＴＴＰアプリケーションによって、また、ＨＴＴＰモジュールが初期化されたときにイベントに登録するＨＴＴＰモジュールによって使用される。ＧＬＯＢＡＬ．ＡＳＡＸは進行中にコンパイルされたものであり、いかなるパイプラインイベントに対するイベントハンドラをも含むことができるアプリケーションコードを含んでいるので、このＧＬＯＢＡＬ．ＡＳＡＸはイベントの登録には必要ではない。このイベントハンドラは、命名規則によって自動的にフックされる。例えば、アプリケーションコード（ＧＬＯＢＡＬ．ＡＳＡＸ内にあるか、または事前コンパイルされている）がＡｐｐｌｉｃａｔｉｏｎ＿ＢｅｇｉｎＲｅｑｕｅｓｔと命名されたメソッドを含んでいるとき、そのアプリケーションコードは、ＢｅｇｉｎＲｅｑｕｅｓｔイベントに自動的にフックアップされることになる。したがって、イベントは、モジュールでもアプリケーションコードでも処理することができる。モジュールは複数のアプリケーション間で再使用可能なので、モジュールを使用することが好ましい。本発明は、受け取った複数のＨＴＴＰ要求を処理するためのイベントパイプラインのインスタンシエーションを生成する。
【００２０】
イベントパイプラインは、要求イベントが発生されるときにコールバックを生成するための複数の要求イベントを含むイベントベースのアーキテクチャを提供する。１つまたは複数の要求イベントが登録される各ＨＴＴＰモジュールは、パイプラインがインスタンス生成される（ｉｎｓｔａｎｔｉａｔｅｄ）ときにインスタンス生成される。したがって、アプリケーション開発者は、要求の存続期間中に選択されたイベントで要求をインターセプトし、それによって加わり、またはそれを変更するアプリケーションを開発することができる。同様に、ＨＴＴＰモジュール開発者は、要求の存続期間中に選択されたイベントで要求をインターセプトし、これによって加わり、またはこれを変更するＨＴＴＰモジュールを開発することができる。さらに、アプリケーションは、発生される要求イベントに基づいてＲｅｓｐｏｎｓｅ．Ｅｎｄ（）メソッドを呼び出すことによって要求のさらなる処理を終了することができる。実行される最後のイベントは、モジュールがクリーンアップ操作を実行することができるように、常にＥｎｄＲｅｑｕｅｓｔイベントである。
【００２１】
再度図３を参照すると、実行中のホスト、例えばＩＩＳ（インターネット情報サーバ）５またはＩＩＳ６はＨＴＴＰ要求を受け取る（図３には示さず）。受け取られた要求は本発明のＡＳＰ．ＮＥＴランタイムに渡され、そこでこの要求は周知の方法で解析され、要求を処理するために必要となる受け取られたＨＴＴＰ要求に関連するすべてのプロパティをカプセル化するＨＴＴＰＣｏｎｔｅｘｔオブジェクトを作成する。アプリケーションがインスタンス生成され、要求の処理がＨＴＴＰハンドラ「方向に」イベントパイプラインを通って（要求イベント３０１および３０２によって示す）進む。要求の存続期間はイベントパイプラインを通って進むので、決定論的な要求イベント（ｄｅｔｅｒｍｉｎｉｓｔｉｃ  ｒｅｑｕｅｓｔ  ｅｖｅｎｔ）のそれぞれが発生される。特定の要求イベントが登録されるＨＴＴＰモジュール、またはＧｌｏｂａｌ．ａｓａｘに含まれているイベントシンクを有するＨＴＴＰモジュールは、特定の要求イベントが発生されるときに呼び出される。要求されたウェブページをＨＴＴＰハンドラが生成した後、処理はイベントパイプラインを通して続行する。すべての要求イベントの発生が完了し、すべてのＨＴＴＰモジュールが要求を処理し終わると、ホストは、要求された（かつ処理された）ウェブページを送ることによって要求に応答する。
【００２２】
図３には３つの要求イベント３０１、３０２および３０３と、３つのＨＴＴＰモジュール３０４、３０５および３０６しか示していないが、使用される要求イベントおよびＨＴＴＰモジュールの数はこれ以上であってもこれ以下であってもよいことを理解されたい。複数のＨＴＴＰモジュールに特定の要求イベントを登録できることを理解されたい。図３は、ＨＴＴＰモジュール３０４〜３０６への要求イベント３０１〜３０３の例示的登録を示す。ＨＴＴＰモジュールと要求イベントとの間に延びた線は登録を示している。図３では、３つの例示的ＨＴＴＰモジュール３０４、３０５および３０６には要求イベント３０２が登録されており、したがって３つのモジュール３０４〜３０６はすべて、要求イベント３０２によって発生される同じコールバックに基づいて１つのＨＴＴＰ要求を処理する。ＨＴＴＰモジュール３０５には、１つの要求イベントだけが登録されているように示されている。ＨＴＴＰモジュールは、そのＨＴＴＰモジュールがそのモジュールに登録されたモジュールと同じ数だけコールバックを受け取るように、複数の要求イベントを登録することも可能である。例えば、図３は、ＨＴＴＰモジュール３０４に要求イベント３０１および３０２が登録されていることを示している。同様に、ＨＴＴＰモジュール３０６には要求イベント３０２および３０３が登録されている。
【００２３】
本発明によれば、イベントパイプラインは、１０個の決定論的な要求イベントと、３個の非決定論的な要求イベント（ｎｏｎ−ｄｅｔｅｒｍｉｎｉｓｔｉｃ  ｒｅｑｕｅｓｔ  ｅｖｅｎｔ）とを含むことが好ましい。さらに、決定論的な要求イベントは同期式要求イベントであっても非同期式要求イベントであってもよい。（同期式）決定論的なイベントには、好ましい順番で以下のものが含まれる。
BeginRequest
AuthenticateRequest
AuthorizeRequest
ResolveRequestCache
AcquireRequestState
PreRequestHandlerExecute
PostRequestHandlerExecute
ReleaseRequestState
UpdateRequestCacheEndRequest
EndRequest
【００２４】
当然ながら、決定論的な要求イベントの順番は、アプリケーションの要件に応じて再構成することができる。非決定論的な要求イベントには、以下のものが含まれる。
Error
PreSendRequestContent
PreSendRequesrHeaders
コールバックを生成するために、イベントパイプラインはこれ以上またはこれ以下の要求を含むことができ、および／またはその他の決定論的な要求イベントおよび非決定論的な要求イベントを含むことができることも理解されたい。
【００２５】
ＨＴＴＰ要求の処理の開始時にＢｅｇｉｎＲｅｑｕｅｓｔイベントが発生される。ＡｕｔｈｅｎｔｉｃａｔｅＲｅｑｕｅｓｔイベントは、アプリケーションがユーザの認証を必要とするＨＴＴＰ要求の存続期間中のある時点で発生される。ＡｕｔｈｏｒｉｚｅＲｅｑｕｅｓｔイベントは、ユーザに特定の要求に対する応答を受け取る権限が付与されているかどうかをアプリケーションが判定する必要があるときに発生される。ＲｅｓｏｌｖｅＲｅｑｕｅｓｔＣａｃｈｅイベントは、要求への応答のすべてがキャッシュ済みであるかどうかを判定することがアプリケーションに要求されているときに発生される。これによって、要求されたページを作成し、また、要求しているユーザに応答を戻すために必要となる時間が短縮される場合がある。この時点で、ＨＴＴＰハンドラが作成される。ＡｃｑｕｉｒｅＲｅｑｕｅｓｔＳｔａｔｅイベントは、クライアント接続に関連付けられた付加的状態を取得するためと、ＡＳＰ．ＮＥＴセッション状態を列挙（ｌｉｓｔ）するために発生される。個別設定モジュールは、例えばＡｃｑｕｉｒｅＲｅｑｕｅｓｔＳｔａｔｅイベントを使用することができる。ＡｃｑｕｉｒｅＲｅｑｕｅｓｔＳｔａｔｅイベントはＨＴＴＰハンドラが作成された後に発生され、したがってモジュールはＨＴＴＰハンドラを検査し、どの種類の状態が必要とされているかを判断することができる。ＰｒｅＲｅｑｕｅｓｔＨａｎｄｌｅｒＥｘｅｃｕｔｅイベントは、要求ハンドラが要求されたウェブページを作成する前に発生される。同様にして、ＰｏｓｔＲｅｑｕｅｓｔＨａｎｄｌｅｒＥｘｅｃｕｔｅイベントは、要求されたウェブページを要求ハンドラが作成し終わったときに発生される。ＲｅｌｅａｓｅＲｅｑｕｅｓｔＳｔａｔｅイベントは、ＡｃｑｕｉｒｅＲｅｑｕｅｓｔＳｔａｔｅで取得されたいかなる状態の変化をも保存する機会をモジュールに与えるために発生される。例えば、セッション状態モジュールはＲｅｌｅａｓｅＲｅｑｕｅｓｔＳｔａｔｅイベントを使用してセッションデータを保存することができる。ＵｐｄａｔｅＲｅｑｕｅｓｔＣａｃｈｅイベントは、応答がキャッシュ可能な場合、（同じページに対する後続のＨＴＴＰ要求に対して）後でその応答をＲｅｓｏｌｖｅＲｅｑｕｅｓｔＣａｃｈｅ内で発見できるように、その要求の処理中の、応答を保存するためにキャッシュが更新されるべきときに発生される。最後に、要求の処理が完了したときにＥｎｄＲｅｑｕｅｓｔイベントが発生される。
【００２６】
例えばアプリケーションコードによってキャッチされない例外条件が生成されるなどのエラー状態が発生したときは、非決定論的なＥｒｒｏｒイベントが発生される。ＰｒｅＳｅｎｄＲｅｑｕｅｓｔＣｏｎｔｅｎｔイベントは、ＨＴＴＰハンドラが要求を処理する前に、要求しているクライアントにコンテンツが送られ始めると発生される。同様に、ＰｒｅＳｅｎｄＲｅｑｕｅｓｔＨｅａｄｅｒｓイベントは、ＨＴＴＰハンドラが要求を処理する前に、要求しているクライアントにヘッダが送られ始めると発生される。ＰｒｅＳｅｎｄＲｅｑｕｅｓｔＣｏｎｔｅｎｔ要求イベントおよびＰｒｅＳｅｎｄＲｅｑｕｅｓｔＨｅａｄｅｒ要求イベントの目的は、要求しているクライアントアプリケーションにコンテンツおよび／またはヘッダが送られる前に、そのコンテンツおよび／またはヘッダを別のメソッドが処理できるようにすることである。上記で指摘した通り、要求されたウェブページをＨＴＴＰハンドラが作成する前に機能モジュールがコンテンツおよび／またはヘッダを提示するという状況においては、そのコンテンツおよび／またはヘッダは処理のためには最早使用可能ではないので、従来型の処理シーケンスでは後で行われるような機能モジュールによって実行されるいかなる処理も実行されない。
【００２７】
Ｉｎｔｅｒｃｅｐｔｉｏｎイベントは、インテリジェントエラー処理コードと共にアプリケーションをラッピングするために有効に使用することができる。アプリケーションで何らかの予期せぬことが発生し、Ｅｒｒｏｒイベントが発生される状況において、本発明は、その予期せぬ状況をどのように処理するかを決定するためのフレキシビリティを開発者に提供する。例えば、現行でログオンしているユーザ全員の現行の状態は、エラーをログしてシステム管理者に通知することに加えて、ＸＭＬファイルにログすることもできる。エラー状態が訂正され、アプリケーションが正常に実行され始めるとき、アプリケーションは、ＸＭＬファイルを使用したエラー状態が原因でドロップしたエンドユーザにコンタクトするように設計することができる。
【００２８】
Ｉｎｔｅｒｃｅｐｔｉｏｎイベントは、Ｇｌｏｂａｌ．ａｓａｘアプリケーションファイルを使用して開発することができるが、ＩＨｔｔｐＭｏｄｕｌｅインターフェースを実施する事前コンパイルされた構成要素であってもよい。Ｍｉｃｒｏｓｏｆｔ（登録商標）のＶＩＳＵＡＬＢＡＳＩＣブランドのプログラミング言語に準拠した以下の疑似コードは例示的なＧｌｏｂａｌ．ａｓａｘを示している。
0004302942.tif 000002
【００２９】
ＨＴＴＰモジュールは、Ｓｙｓｔｅｍ．Ｗｅｂ．ＩＨｔｔｐＭｏｄｕｌｅインターフェースを実施するクラスとして作成されており、任意のＨＴＴＰアプリケーションイベントに同期するためのＩｎｉｔ（）メソッドを使用する。以下の疑似コードはＨＴＴＰモジュールの一例である。
0004302942.tif 000003
ＨＴＴＰモジュールはコンパイルされ、．Ｎｅｔ  Ｌｉｂｒａｒｙ  ＤＬＬが「ｂｉｎ」ディレクトリにあるアプリケーションのｖｒｏｏｔの下に置かれる。ＨＴＴＰモジュールは以下の例示的疑似コードを使用してｃｏｎｆｉｇ．ｗｅｂに登録される。
0004302942.tif 000004
【００３０】
ＡＳＰ．ＮＥＴプロセスを実行するプロセス中では、コードを実行するためにスレッドが使用される。スレッドはリソースであり、ＡＳＰ．ＮＥＴが使用することができるスレッドは無数にある。
【００３１】
本発明によれば、ＡＳＰ．ＮＥＴは、アプリケーション開発者の制御下でアプリケーションの存続期間を通してスレッドの数を拡張、短縮するスレッドプールを作成して管理する。
【００３２】
場合によっては、ネットワークＩ／Ｏなどのアプリケーションコードはプロセスでスレッドをストールする可能性がある。これは、そのスレッドが、この比較的遅いネットワークＩ／Ｏの動作が完了するまで待機する（すなわち、スレッドがブロックされる）必要があるからである。スレッドがブロックされると、そのスレッドは要求に応えるために使用することはできず、したがって、その要求は要求のキューに入れられ、アプリケーションのパフォーマンスを低下させることになる。これは、すべてのスレッドが、待機中に作業を行うのではなく、ブロックされるからである。このような状況を回避するため、本発明は、非同期式イベントに対するサポートと同期式イベントに対するサポートを提供する。したがって、本発明は、非同期式ＩＯを容易にするために、ウェブサービスプロキシなどの、ネットワーククラスがＩ／Ｏ完了ポートをサポートするネットワークを介して操作を実行するアプリケーションをサポートする。
【００３３】
本発明は、それぞれが同期式決定論的な要求イベントに対応する１０個の非同期式要求イベントもサポートする。非同期式要求イベントは以下の順番で発生される。
AddOnBeginRequestAsync
AddOnAuthenticateRequsetAsync
AddOnAuthorizeRequestAsync
AddOnResolveRequestCacheAsync
AddOnAcquireRequesrStateAsync
AddOnPreRequestHandlerExecuteAsync
AddOnPostRequestHandlerExecuteAsync
AddOnReleaseRequestStateAsync
AddOnUpdateRequestCacheAsync
AddOnEndRequestAsync
【００３４】
ｇｌｏｂａｌ．ａｓａｘ内の非同期式イベントを使用するために、イベントのプロトタイプは、ＨＴＴＰアプリケーション内に仮想（ｖｉｒｔｕａｌ）としてマーク付けされているＩｎｉｔ（）メソッドを専用コードで置き換えることによって、イベントパイプライン内に手動で作成またはワイヤアップしなければならない。例えばＯｎＢｅｇｉｎＲｅｑｕｅｓｔイベントの非同期式バージョンであるＡｄｄＯｎＢｅｇｉｎＲｅｑｕｅｓｔＡｓｙｎｃイベントをワイヤアップするには、ＡｐｐｌｉｃａｔｉｏｎＩｎｓｔａｎｃｅのＡｄｄＯｎＢｅｇｉｎＲｅｑｕｅｓｔＡｓｙｎｃメソッドが呼び出されて２つのイベントハンドラ内に渡される場合がある。以下の例示的疑似コードはこれを示している。
0004302942.tif 000005
【００３５】
上記の例示的疑似コードでは、イベントの実行中に呼び出される２つのメンバメソッド（ＢｅｇｉｎおよびＥｎｄ）内に渡すことによって新しいＢｅｇｉｎＥｖｅｎｔＨａｎｄｌｅｒおよび新しいＥｎｄＥｖｅｎｔＨａｎｄｌｅｒが作成される。アプリケーション開発者は、両方のイベントハンドラを実施することが必要となる場合もある。例えば、Ｂｅｇｉｎ（）ハンドラは、別のスレッドで行われる以下の例示的疑似コードで示すように、ＳｉｍｐｌｅＡｓｙｎｃＲｅｓｕｌｔと定義されるカスタムクラスのインスタンスを使用する。
0004302942.tif 000006
【００３６】
ＩＡｓｙｎｃＲｅｓｕｌｔインターフェースを実施するクラスの例示的実施態様を以下の疑似コードで示す。
0004302942.tif 000007
【００３７】
以下の例示的疑似コードによって示すように、必要に応じていかなるオープンリソースをもクリーンアップするためにＥｎｄイベントを使用することができる。
0004302942.tif 000008
【００３８】
ＡＳＰ．ＮＥＴは同期式アプリケーションイベントおよび非同期式アプリケーションイベントの両方をサポートするので、アプリケーション開発者はアプリケーションを構築するためにより多くの選択肢を有する。イベントを非同期式になるように符号化することによって、ＡＳＰ．ＮＥＴのワーカースレッドを、非同期式スレッド上で実行されるコードが完了するまで他の要求に応えるように解放する。これによって、要求に応えるために使用されるＡＳＰ．ＮＥＴスレッドはブロックされないので、より優れた拡張性が得られる。
【００３９】
本発明は、本発明の実行に現時点で好適なモードを含めて特定の例示に関して説明したが、当業者ならば、上記のシステムおよび技術には、頭記の特許請求の範囲に記載の本発明の趣旨および範囲に含まれる無数の変形形態および並べ替えがあることが理解されよう。
【図面の簡単な説明】
【図１】本発明の様々な態様を実施するために使用することができる従来型汎用デジタルコンピューティング環境の概略図である。
【図２】従来の方法でＨＴＴＰ要求を処理するウェブサイトアプリケーションの機能ブロック図である。
【図３】本発明によるＡＳＰ．ＮＥＴ  ＨＴＴＰランタイムを使用してＨＴＴＰ要求を処理するウェブサイトアプリケーションの機能ブロック図である。
【符号の説明】
１００  コンピュータ
１２０  システムメモリ
１３０  システムバス
２０２  クライアントコンピュータ
２０４  ホストサーバコンピュータ
２０６  アプリケーション
３０１  要求イベント
３０２  要求イベント
３０３  要求イベント
３０４  ＨＴＴＰモジュール
３０５  ＨＴＴＰモジュール
３０６  ＨＴＴＰモジュール
【図１】
0004302942.tif 000009
【図２】
0004302942.tif 000010
【図３】
0004302942.tif 000011