JP2005505831A - Ｊａｖａサーブレットを非同期メッセージと統合するための方法 - Google Patents

Abstract

本発明は、応答を送る準備ができる前に、service()メソッドが戻ること、及びスレッドを開放することを可能にする、非同期スレッド化のためのシステム、及び方法を提供する。次に、非同期イベントが後に発生する時、応答を完成させ、送ることができる。この機構の使用例は、サーブレットを組み合わせたJMSの使用である。

Description

【技術分野】
【０００１】
本発明は、一般的に、アプリケーションサーバー及びトランザクションサーバーに関するものであり、特に多重実行キューを用いたメッセージキューイング及びスレッドをサポートするためのシステムに関するものである。
【０００２】
(著作権表示)
本特許文献の開示の一部は、著作権保護を条件とする題材を含むものである。特許商標庁の書類又は記録に掲載される限り、著作権者は、本特許文献又は本特許開示の何人による複写複製にも異議はないが、しかしもしそうでなければ一切の無断転載を禁ずる。
【０００３】
(優先権の主張)
本出願は、2001年10月5日に出願された「非同期キューを用いたアプリケーションサーバーメッセージングのためのシステム」という名称の米国特許仮出願60/327,530号に基づく優先権を主張するものであり、この出願は引用により本出願に組み入れられる。
【０００４】
(相互引用)
本出願は、2001年10月5日に出願された「多重発送プールを用いたアプリケーションサーバーメッセージングのためのシステム」という名称の米国特許仮出願60/327,543号、及び、2002年10月3日に出願され、発明者がAdamMessinger及びDonFergusonである「多重発送プールを用いたアプリケーションサーバーメッセージングのためのシステム」という名称の米国特許出願、に関連するものであり、双方の出願とも引用により本出願に組み入れられる。
【背景技術】
【０００５】
Java2プラットフォームエンタープライズエディション(J2EE)の仕様は、多層企業アプリケーションを開発するための現行標準の一つを定義するものである。J2EEは、企業アプリケーションの設計、開発、組み立て、及び導入のコンポーネントベースの手法を提供し、これはコストを減らし、かつ設計及び実装をしっかりしたものにすることを可能にする。J2EEプラットフォームは、開発者に、多層分散アプリケーションモデル、コンポーネントを再利用する能力、統一セキュリティモデル、及び柔軟なトランザクション制御を提供する。それらは、これまでになく早く市場に革新的なカスタマーソリューションを届けることができるだけでなく、その結果として生じた、プラットフォームに依存しないJ2EEコンポーネントベースのソリューションは、如何なるベンダーの製品及びアプリケーションプログラムインターフェース(API)とも結び付くものではない。
【０００６】
J2EE仕様は、以下の種類のコンポーネントを定義する。アプリケーションクライアントコンポーネント、企業Javaビーン(EJB)、サーブレット及びJavaサーバーページ(JSP)(ウェブコンポーネントとも言う)、及びアプレットである。多層分散アプリケーションモデルは、アプリケーションロジックが機能に応じてコンポーネントに分かれること、及び、異なるアプリケーションコンポーネントが同じサーバー上又は異なるサーバー上でJ2EEアプリケーションを作り上げることができることを、暗に示している。アプリケーションコンポーネントが実際にどこにインストールされるかは、そのアプリケーションコンポーネントが多層J2EE環境の中のどの層に属するかによって決まる。これらの層を図1に示す。そこ示すように、アプリケーションサーバー層104は、EJBコンテナ及び/又はサーブレット、JSP、及びhtmlページ114のような表示用コンテナを開発するのに使用される。これらは、クライアント108及びクライアントアプリケーションが配置されるクライアント層102と、企業リソース計画(ERP)システムのような企業アプリケーション又は従来アプリケーションのホストとして働くために使用される後端層106との間のインターフェースとして、交替で使用される。
【０００７】
クライアント層−会社のファイアウォールの内側でも外側でも、これらはブラウザ、Javaベースのプログラム、又はクライアント層内で動作する他のウェブイネーブルのプログラミング環境、とすることができる。
【０００８】
アプリケーションサーバー層−通常、この層は、クライアント要求をサポートするため、表示用ロジック及びビジネスロジックの組み合わせのホストとして働く。表示用ロジックは、HTMLページを表示するJSPページ及びサーブレットを介してサポートされるが、一方、ビジネスロジックは、遠隔メソッド呼び出し(RMI)オブジェクト及びEJB112を介してサポートされる。ビーンを実行する実行時環境を共に作り上げるトランザクション、ライフサイクル及び状態管理、リソースプーリング、セキュリティ等を、EJBはコンテナ環境に依存している。
【０００９】
後端層−これは一般的に、既存のアプリケーション及びデータ貯蔵の組み合わせである。これはまた、企業リソース計画(ERP)、汎用大型コンピュータのトランザクション処理、データベースシステム、及び他の従来の情報システムのようなシステムを含むことができるので、企業情報システム(EIS)層とも呼ばれる。
【００１０】
J2EEアプリケーションのコンポーネントは、別々に、かつしばしば異なるデバイス上で動作するので、クライアント層及びアプリケーションサーバー層のコードが、他のコード及びリソースを捜しかつ参照するための方法が必要である。クライアント層及びアプリケーションサーバー層のコードは、例えば、企業ビーンのようなユーザー定義オブジェクト、及び、後端層の中のリソースを捜すために交替で使用されるJavaデータベース接続(JDBC)データソースオブジェクトの場所のような環境登録、及びメッセージ接続を捜すために、Java命名とディレクトリインターフェース(JNDI)116を使用することができる。
【００１１】
セキュリティ及びトランザクション管理のようなアプリケーション動作は、ウェブ及び企業ビーンコンポーネント上で配置時に構成することができる。この配置時の特徴は、その組み立てと共に変化し得る構成設定からアプリケーションロジックを切り離すことである。J2EEセキュリティモデルにより、開発者は、システムリソースが承認されたユーザーによってのみアクセスできるように、ウェブ又は企業ビーンコンポーネントを構築することができる。例えば、ウェブコンポーネントを、ユーザー名及びパスワードの入力を要求するように構築することができる。企業ビーンコンポーネントを、特定のグループ人のみがある決まった種類のそのメソッドを呼び出すことができるように構築することができる。あるいはまた、そのメソッドの幾つかが全ての人にアクセス可能であるように、及び二、三のメソッドが組織内のある決まった特権のある人のみにアクセス可能であるように、サーブレットコンポーネントを構築することもできるであろう。その同じサーブレットコンポーネントを、他の環境では、全てのメソッドが全ての人に利用可能であるように、又は全てのメソッドが選ばれた二、三の人のみに利用可能であるように、構築することもできるであろう。
【００１２】
カリフォルニア州サンノゼにあるBEAシステムのウェブロジックサーバー製品のような幾つかのアプリケーションサーバーは、サーバー上で動作するコンポーネントの使用の細かい制御に備えたアクセス制御リスト(ACL)機構を使用する。ACLを使用して、開発者は、どのユーザー又はユーザーのグループにより何を実行できるのか又はできないのか、をJavaメソッドレベルで定義することができる。このACL機構は、自分自身のアクセス制御機構をEJB仕様の中で定義するEJBを除くアプリケーションサーバー上で動作する如何なるものをも扱う。セキュリティ領域は、管理者が既存の承認又は認証システムからの情報をACLに取り込むことを可能にする。
【００１３】
Javaサーブレット
サーブレットは、ウェブサーバーの機能を拡張するプログラムである。サーブレットは、クライアントから要求を受け取り、動的に応答を作成し(多分、要求を満たすためにデータベースに問い合わせて)、次にHTML又はXMLドキュメントを含む応答をクライアントに送る。サーブレットはCGIに似ているが、しかしJavaクラス及びストリームを使用するので典型的には、より書きやすい。サーブレットはJavaバイトコードにコンパイルされ、かつ実行時にはサーブレットインスタンスがメモリ内に保持されるので、それらはより高速に実行され、各クライアント要求は新たなスレッドを生む。サーブレットにより、動的なやり方でHTTP応答ストリームへのデータを生成することが容易となる。各クライアント要求は新たな接続として実行され、そのため当然、フロー制御は要求間には出現しない。このセッション管理に備えることは、要求間の特定のクライアントの状態を保持することとなる。幾つかのアプリケーションサーバーでは、サーブレットは、メソッド要求間のそれらの状態を格納するためにHTTPセッションオブジェクトを利用する。フェイルオーバーの目的のため、クラスタ化された環境の中でこのオブジェクトを複製することができる。
【００１４】
Javaサーバーページ
JSPページは、サーブレットを開発するための、テキストベースの表示専用の方法である。JSPページはサーブレットの全ての利点を提供し、かつJavaビーンクラスと組み合わされる時、内容と表示用ロジックをそれぞれ別々にわけておくための容易な方法を提供する。JSPページ及びサーブレットの双方とも、プラットフォームに依存せず、かつより少ないオーバーヘッドを使用するので、共通ゲートウェイインターフェース(CGI)よりも望ましい。JSPページは、似たような外観及び雰囲気を持つページから成るウェブサイトを構築するためのウェブテンプレートを定義するために、Javaビーンクラスと共に使用することができる。Javaビーンクラスがデータレンダリングを実行し、そのため、テンプレートは全くJavaコードを持たない。これは、HTMLエディタによってテンプレートを保持できることを意味する。JSPページを使用する単純なウェブベースのアプリケーションは、内容を、Javaビーンクラスではなくカスタムタグ又は小スクリプトを使用するアプリケーションロジックと結び付けるのに使用することができる。カスタムタグは、JSPページに取り込まれるタグライブラリにまとめて束ねられる。小スクリプトは、JSPページに直接埋め込まれる小さなJavaコードセグメントである。
【００１５】
Javaメッセ−ジングサービス(JMS)
JMSは、Javaプログラム間でのメッセージの交換をサポートするために使用されるJ2EE機構である。これはJavaが非同期通信をサポートする方法であり、ここでは送信者及び受信者が互いを意識する必要がなく、そのため独立して動作することができる。JMSは、二つのメッセ−ジングモデルをサポートする。
【００１６】
ポイントツーポイント(point to point)−これはメッセージキューに基づくものである。このモデルでは、メッセージ作成者がキューにメッセージを送る。メッセージ消費者は、メッセージを検出しようとするために、自分自身をキューに接続することができる。メッセージがキューに到着するとき、消費者はキューからそれを取り外し、かつそれに応答する。メッセージは、ただ一つのキューに送ることができ、かつただ一人の消費者により使用されるであろう。消費者は、自分達が必要とする厳密なメッセージ形式を指定するために、メッセージを選別するという選択肢をもつ。
【００１７】
発行及び購読(publish and subscribe)−これは、メッセージ作成者がある話題に対してメッセージを送ることを可能にし、かつその話題について登録されている全てのメッセージ消費者がそれらのメッセージを検索することを可能にする。この場合、多くの消費者が同じメッセージを受け取ることができる。
【００１８】
現行のサーブレットAPIに関する一つの問題は、完全同期プログラミングモデルである。要求が特定のスレッドに発送された後、適切なサーブレットのservice()メソッドが呼ばれる。そのservice()メソッドが戻ってきた時、応答が送られる。これは、作業の多くの形式に適する単純なプログラミングモデルであるが、しかし、サーブレットを実行するスレッドはイベントが起こるまでブロックしなければならないので、応答が送られ得る前に非同期イベントが起こらなければならない場合には最適ではない。
【００１９】
(要約)
本発明は、応答を送る準備ができる前に、service()メソッドが戻ってくることを可能にする(それゆえ、スレッドを開放することが可能となる)非同期スレッド化のためのシステム、及び方法を提供する。次に、非同期イベントが後に発生する時、応答を完成させ、送ることができる。この機構の使用例は、サーブレットを組み合わせたJMSの使用である。
【００２０】
本発明に従って、プロセスは、サーブレットが実行される時に開始する。サーブレットは、応答の一部分を構築するが、しかし典型的には、応答を完成させるためにより多くのデータを必要とする。それは、待っている間、データを要求するJMSメッセージをキューに入れ、必要なデータを含むJMSメッセージが到着した時に見つけることができる場所に、その応答オブジェクトを置いておく。この時点でサーブレットは戻ってくることができるが、しかしその応答はまだ送られないであろう。その後の時点で、例えばJMSを介してデータが到着した時、対応する応答オブジェクトを検索する。次いで、応答の残りの部分を作成することができる。応答が完成した時、それは明らかにクライアントに送ることができる。
【００２１】
この機能はまた、JSPタグライブラリの使用を通じて利用可能である。タグを使って、JSPページの作者は、非同期イベントの前に何の作業を行うべきか、及び非同期イベントの後にどの作業を行うべきかを指定する。非同期イベントの後にそれらが元通りになり、及びその処理が中断せずに続くことができることを確実にするために、この機能はJSP状況機構と一体化する。
【００２２】
(詳細な説明)
大雑把に説明すると、本発明は、非同期スレッド化を可能にするシステム、及び方法を提供する。本発明は、アプリケーションプログラミングインターフェース(API)を介してのサーブレットへのアクセスを可能にするアプリケーションサーバーシステムの中に組み込むことができる、又は非同期スレッド化の恩恵を受ける他のシステムの中に組み込むことができる。
【００２３】
典型的なサーブレットAPIは、完全に同期する。要求がスレッドに発送された後、適切なサーブレットのservice()メソッドが呼ばれる。service()メソッドが戻ってきた時、応答が送られる。この単純なプログラミングモデルは、作業の多くの形式に適しているが、しかし、サーブレットを実行するスレッドはイベントが発生するまでブロックしなければならないので、応答を送る前に非同期イベントが発生しなければならない場合には最適ではない。
【００２４】
一実施形態では、本発明は、応答を送る準備ができる前に、service()メソッドが戻ってくることを可能にする(それゆえ、スレッドを開放することが可能となる)サーブレットAPIへの拡張を提供する。次に、非同期イベントが後で発生する時、その応答を完成させ、かつ送ることができる。この機構の一使用例は、サーブレットを組み合わせたJMSの使用である。
【００２５】
この実施形態では、サーブレットが実行される時、それは応答の一部分を構築するが、しかし次いで、典型的にはその応答を完成させるためにより多くのデータを必要とする。それは、データを要求するJMSメッセージをキューに入れ、及び、必要なデータを含むJMSメッセージが到着した時に見つけることができる場所にその応答オブジェクトを置いておく。この時点でサーブレットは戻ってくることができるが、しかし応答はまだ送られていないであろう。後で、JMSを介して要求されたデータが到着した時、その応答オブジェクトを検索する。次に、応答の残りの部分を作成することができ、かつ、それが完成した時、明らかにそれをクライアントに送ることができる。
【００２６】
本発明は主に、BEAシステム社の製品のウェブロジックファミリーのようなアプリケーションサーバー、トランザクションサーバー、及びメッセ−ジングサーバーにおける使用のために設計されている。典型的なサーバー設計の中核において、スレッド化モデルは、作業要求を実行するためにスレッドを割り当てるポリシーである。サーブレット要求がサーバーに到着した時、それらはスレッドに発送される。このスレッドは、要求されたサーブレットの実行を担っている。サーバーは、非同期プール(しばしば読み取りスレッドと呼ばれる)及び同期プール(実行スレッドと呼ばれる)という二つのスレッドプールを使用するスレッド化モデルを採用する。このプールの併用は、ブロック化動作を実行するユーザーコードを容認する一方で、開発者又は管理が効果的に要求を優先順位付けすることを可能にする。
【００２７】
図2は、本発明の実施形態に従ってスレッド化ポリシー機構206を示している。非同期読み取り結果が利用可能となるように、非同期スレッド化プール208は非同期入力機構202(多重化装置)に応対する。結果が利用可能となると、プールのスレッドは、メッセージを見て、かつ適切なコールバックを作ることによりそれを発送する。発送コールバックは普通、同期スレッドプールによる後での処理のための要求をキューに入れる。しかしながら、特定のブロック化なしの優先要求は、コールバックの中で直接処理される。積極的に入力を受け入れることにより、優先度の低い要求212が実行している間、優先度の高い要求214は読み取られるのを待つことはない。これらのスレッドは決してブロックすべきでないので、おそらくプロセッサ(CPU)につき一つの、より少数のスレッドが普通存在する。
【００２８】
同期スレッドプール210は、要求のキュー204に応対する。要求が利用可能になると、プールプロセスのスレッドが、その要求をキューから取り出し、それを処理し、及び結果216を送出する。要求を処理する間、スレッドは、結果の送出のようなコードを実行することができ、これによりスレッドはブロックする。それゆえ、動作可能状態のCPUにつき一つのスレッドが常に存在するように、スレッド数を調整すべきである。発送ポリシーについては、2001年10月5日に出願された、発明者AdamMessingerの「多重発送プールを用いたアプリケーションサーバーメッセ−ジングのためのシステム」という名称の米国特許仮出願60/327,543号、及び、2002年10月3日に出願された、発明者AdamMessinger及びDonFergusonの「多重発送プールを用いたアプリケーションサーバーメッセ−ジングのためのシステム」という名称の審査中の米国特許出願の中で、より詳細に説明されている。
【００２９】
図3は、従来の同期メッセージ応答機構を示している。そこに示すように、例えばウェブブラウザアプリケーションのようなクライアントアプリケーション302からの要求は、サーブレット304を介してアプリケーションサーバーに伝達される。要求はハイパーテキスト転送プロトコル(HTTP)要求306型とすることができ、そのため、クライアントは典型的にハイパーテキストマークアップ言語(html)応答308を期待するであろう。同期モデルでは、スレッドはサーブレットを実行し、次にサーブレットの実行が完了した時、即座にクライアントに応答を送る。この手法に関する問題は、サーブレットの実行全体のために実行スレッドを使い果たしてしまうことである。サーブレットが、ブロックするタスクを実行し、おそらく他のデータを待っている場合には、これはサーバーリソースの消耗となり得る。
【００３０】
図4は、クライアントがサーバーのリソースにアクセスする場合の典型的なシステムライフサイクルを示している。図4に示すように、HTTPクライアント402は、典型的にリモートのウェブサーバー上で動作するサーブレット408にアクセスする。例示の目的のためにHTTPクライアントをここに示したが、本発明はそれに限定されず、他の形式のクライアントアプリケーションにおいて使用できることは、当業者には明らかであろう。図4のライフサイクルダイヤグラムに示すように、HTTPクライアントは、サーブレットコンテナ404を介してサーブレットにアクセスする。サーブレットコンテナは、HTTP要求410を受け取り、及び処理のためにそれをサーブレット408に渡す。このHTTP要求を処理する動作の大半は、サーブレット応答層406で起こる。図4に示すように、時間がページの鉛直下向きに進むにつれて、プロセスは、サーブレットへの初期化(init)コール412を続け、それは応答ハンドラ406により処理される。次に、サーブレットコンテナは、例えばデータを検索する又は更新するために、サーブレットへサービス(service)要求414を渡す。このようなシステムは電子商取引環境で典型的に使用され、そこでは飛行時間の探索の結果等のようなカタログリストを検索するようにクライアントアプリケーションが設計される。サーブレットは、典型的に、サーブレット応答ハンドラに出力416を書き出すことにより、要求に応答する。このステップは、しばしば、バッファリング及び最適化の目的のために必要である。次に、サーブレットコンテナが、クライアントに応答を返すことを要求する時、それは応答ハンドラに送信(send)要求418を送り、及び応答ハンドラは送信応答(send response)420をサーブレットコンテナに返す。次にこの応答は、HTTP応答422としてクライアントに送られる。
【００３１】
図5は、本発明の実施形態に従って使用することのできる同様なライフサイクルを示している。図5に示すように、リモートサーバー、サーバーリソース、又はサーブレット508にアクセスするために、再びHTTPクライアント502を使用する。HTTP要求510は、サーブレット応答ハンドラ506に初期化(init)要求512を発行するサーブレットコンテナ504により、処理される。しかしながら今回は、サービス(service)要求514が処理のためにサーブレットに伝達した時、サーブレットは即座に応答ハンドラに516を返す。それらの要求を処理するためにサーブレットが自発的にデータを返すのを待つ必要がないということから、この即座の返答は、次に続く要求を処理するために応答ハンドラを開放する。ある時間t520の後、その要求に返すための適切なデータをサーブレットが有するとき、サーブレットは送信(send)信号518を応答ハンドラに送り、次にそれは送信(send)応答522をサーブレットコンテナに送る。次に続くHTTP応答524は、前記のようにクライアントに伝達される。
【００３２】
上で説明したプロセスの一部として、サーブレットは、伝達すべき何か他のものを持つまで応答コードをセットし、効果的にコンテナ層から応答し、かつサーブレット層にそれを置く。実際に、サーブレットが送信(send)応答を発行するために待つ時間の総計は、ある任意の時間と定義することができる、又は、非同期メッセージの結果として、例えばその情報がクライアントに送信するのに利用可能であることを示すJMSメッセージを受け取った結果として実行されるものとすることができる。この形式の処理は、例えば、ユーザーが探索結果を待つときに典型的に遅延時間を経験する電子商取引のサイトで役立つものである。本発明により処理を実行するとき、ただ単に画面がフリーズするのではなく、ユーザーは、情報のうちの幾つかの項目を受け取ることができ、一方で他の項目は、サーブレットが適切なデータを見つけ及びそれを返す時に、一つずつ返される。同時に、サーブレット応答ハンドラは、他のクライアント要求を処理するために利用可能である。開発者は、即座に返されるデータの形式、及び後で返される形式を指定することができる。
【００３３】
図6及び図7は、多重要求を処理するために適用される時の、本発明の動作をより詳細に示している。図6に示すように、非同期メッセ−ジングを使用しない時、クライアントからの次に続く要求を逐次的手法で処理しなければならない。そのため、例えば図6では、クライアントAからの第一のHTTP要求410は、クライアントB403からの第二のHTTP要求430が対応される前に、サーブレットコンテナ404及びサーブレット応答ハンドラ406により対応され、かつ完全に処理される。全体的な結果は、二つのクライアントからのHTTP要求を処理するために二倍の時間がかかるというものとなる。要求をこの逐次的手法で処理しない場合には、おそらく、処理時にユーザーが遅延を経験するであろうように、一又はそれ以上の要求が他の要求に対して未処理の仕事を作成するであろう。
【００３４】
図7は、異なるスレッドで処理を実行できるような非同期手法で、単一クライアントからの多重要求及び/又は多重クライアントからの要求を処理するために非同期メッセ−ジングを使用する、本発明の実施形態に従った機構のライフサイクルを示している。図7に示すように、第一のHTTPクライアントA502及び第二のHTTPクライアントB503は、上で説明した機構を使ってサーブレットリソース508にアクセスする。この実施形態に従うと、第一のHTTP要求A510がサーブレットコンテナで受け取られる時、それは応答ハンドラにより初期化(init)Aコール512を使って処理され、次にサービス(service)要求514としてサーブレット508に渡される。サーブレットは、サーブレット応答ハンドラに即座に516を返し、次いでこれは、他の要求を処理するため応答ハンドラを開放する。図7に示すように、第二のHTTP要求Bは、初期化(init)Bコール532としてサーブレット応答ハンドラにより即座に対応され、処理のためのサービス(service)要求534としてサーブレットに渡される。再び、サーブレットは即座に536を返す。この手法におけるメッセージの差込みは、双方の要求を処理するための全体的な時間を減らし、かつ、情報が利用可能になった時及び場合にサーブレットがそれをクライアントに返すことを可能にする。例えば、図7に示すように、要求Aに応答するのに必要な情報をサーブレットが見つけた時、HTTP応答A524としてクライアントに回送するために、送信応答(send response)A信号522をサーブレットコンテナに返す。第二の送信応答(send response)B信号542及びHTTP応答B544は、同じ方法で同様に処理される。
【００３５】
実装
ファイルサーブレットは、ネットワーク上のファイルの非同期送信をサポートするプラットフォーム上の高速ファイルサーブレットに置き換えることができる。この形式のサーブレットの実装は、サーブレットのための非同期応答の付加を要求し、これについては下記で説明する。
【００３６】
同期及び非同期応答
リモートクライアントからのサーブレット要求が処理される時、しばしば応答が要求される。この応答は、要求を処理したのと同じスレッドにより送信するときには同期、又は異なるスレッドで後で送信するときには非同期、のいずれかとすることができる。この解析は、サーバー側の観点からのものである。クライアント側の観点からすれば、リモート要求がどのように作成されるかによって、どちらの形式の応答も、それを待つことを阻止できる又はできないとすることができる。
【００３７】
現在、ほとんどの要求は同期手法で処理される。サーブレット要求を処理する時、処理スレッドが他の要求に移り得る前に、すべての処理を完了しなければならない。この同期モデルは、RMI及びサーブレット仕様により指定されるものである。これに対する従来の理由は、非同期コードを書くことは非常に難しく、そのためエラーを起こしがちということにある。
【００３８】
非同期手法で要求に応答できる能力が、スレッドを保存するのに非常に役立つであろう特定の状況が存在する。これは、サーバーが一又はそれ以上の長く実行中の外部リソースの要求を作成する必要がある場合、又は要求を処理する間にサーバーがある状況に応対する必要がある場合に、典型的には真である。これの例は、現在空であるJMSキューからメッセージを取り出すというクライアント要求である。同期モデルでは、その要求を処理するスレッドは、クライアントに戻すべきメッセージがキューに存在するようになるまでブロックされる。非同期モデルでは、スレッドは要求を取っておくことができ、かつ他の要求を処理し続けることができる。メッセージがキュー内に置かれた時、その要求を発見し、かつ応答をクライアントに返すことができる。本発明は、サーバーがRMI及びサーブレット要求への非同期応答をサポートすることを可能にする。
【００３９】
サーブレット
特定のサーブレットは、自己の配置記述子の中で非同期と宣言することができる。非同期サーブレットのserviceメソッド(サービスメソッド)が戻ってきた時には、その要求に対して何の更なる措置も取られないであろう。サーブレットは、その要求を、何か他の動作が起こった後に、それを検索し及びその応答を送ることができるようなどこかの場所に格納する。この時点で、ストリームを押し流し、要求のログを取り、かつそれが生きたままの接続である場合にはより多くのデータを受け取るためにソケットを多重化装置に登録する要求について、特別なsendメソッド(送信メソッド)が呼ばれるはずである。長く実行中の要求をタイムアウトさせることにより、リソースを適度に開放することを確実にする実装を作成することは重要であり、これによりガーベッジコレクション及び他のクリーンアップためのリソースを開放する。
【００４０】
JSP
非同期モデルもまた、JSPタグライブラリの使用を通じて同様な手法でサポートすることができる。これらのタグライブラリは、非同期イベントよりも先にウェブページのどの部分を実行すべきか、及び非同期イベントの後にどの部分を実行すべきかを指定するために、http開発者/ページ作成者が使用する。タグライブラリは、非同期イベントが発生しかつJSPページ実行を再開すべき時が知らされるはずであるオブジェクトに作成者がアクセスすることを可能にする。
【００４１】
タグライブラリを使用している時、その非同期イベントについて登録する前に、ページの実行状況を自動的に格納することができる。このように、非同期プログラミングの詳細の多くを、JSP作成者から見えないようにすることが可能である。JSPは状態維持について心配する必要はない。標準の範囲(ページ、要求、セッション又はアプリケーション)のいずれかに格納された状態は、同期JSPを使用して行うであろうように動作しつづけるであろう。
【００４２】
本発明の上述の説明は、例証及び説明の目的のために提供されたものである。これは、網羅的なもの、又は本発明を開示した厳密な形態に限定することを意図するものではない。明らかに、多くの修正及び変形が当業者には明白であろう。本実施形態は、本発明の原理及びその実用例を最もよく説明するために選択され、かつ説明されたものであり、そのため他の当業者が、意図する特定の使用に適した様々な修正を伴った、様々な実施形態における本発明を理解することが可能となる。本発明の技術的範囲は、次の特許請求の範囲及びその均等技術により定められることを意図している。
【図面の簡単な説明】
【００４３】
【図１】本発明を利用することができるJ2EE互換アーキテクチャを示している。
【図２】本発明の実施形態に従った、非同期スレッドプールを用いたスレッド化ポリシーを示している。
【図３】同期スレッド化処理のダイヤグラムを示している。
【図４】従来のメソッドを使って処理される単一のHTTP要求のライフサイクルを示している。
【図５】非同期メッセ−ジングを使って処理される単一のHTTP要求のライフサイクルを示している。
【図６】従来のメソッドを使って処理される複数のHTTP要求のライフサイクルを示している。
【図７】非同期メッセ−ジングを使って処理される複数のHTTP要求のライフサイクルを示している。

Claims (12)

1. Javaサーブレットとサーブレットハンドラとの間の非同期メッセ−ジングのためのシステムであって、
   サーブレット及びサーブレット応答ハンドラを含むサーバーと、
   HTTPクライアントから要求を受け取り、HTTPクライアントへ応答を送るためのHTTPインターフェースと、
   を備え、クライアントからの要求は、サーブレットが即座にある特定の応答データを返すこと、及び次に続く応答で使用するための応答コードをセットすることを可能にするものである、
   ことを特徴とするシステム。
2. 前記サーブレットの次に続く応答が、更なる応答データを送る応答コマンドによりトリガされる、
   請求項1記載のシステム。
3. 前記応答コマンドがJMSメッセージである、請求項2記載のシステム。
4. 前記サーブレット及びサーブレット応答ハンドラの機能が、JSPタグライブラリを介してユーザーに公開される、
   請求項1記載のシステム。
5. 前記JSPタグライブラリが、どのHTTP応答データを即座に返すべきか、及びどの応答データを後で返すべきかを示すために使用される、
   請求項4記載のシステム。
6. JSP実行状況のサポートをさらに備える請求項4記載のシステム。
7. Javaサーブレットとサーブレットハンドラとの間の非同期メッセ−ジングのための方法であって、
   サーブレットリソースにアクセスするためのHTTPクライアントからの要求を受け取るステップと、
   前記要求に非同期的に応答するステップと、
   を含み、クライアントからの要求は、サーブレットが即座にある特定の応答データを返すこと、及び次に続く応答で使用するための応答コードをセットすることを可能にするものである、
   ことを特徴とする方法。
8. 前記サーブレットの次に続く応答が、更なる応答データを送る応答コマンドによりトリガされる、
   請求項7記載の方法。
9. 前記応答コマンドがJMSメッセージである、請求項8記載の方法。
10. 前記サーブレット及びサーブレット応答ハンドラの機能が、JSPタグライブラリを介してユーザーに公開される、
    請求項7記載の方法。
11. 前記JSPタグライブラリが、どのHTTP応答データを即座に返すべきか、及びどの応答データを後で返すべきかを示すために使用される、
    請求項10記載の方法。
12. JSP実行状況のサポートをさらに備える請求項10記載のシステム。

Images