(57)【要約】本発明は、アプリケーションサーバーにおける使用のためのシステム又は機構を提供するが、これはサーバースレッド化モデル、すなわち作業要求を実行するためにスレッドを割り当てるポリシー、を高めるものである。本発明の実施形態を使用するように設計されたアプリケーションサーバー又は何らかのサーバーは、非同期プール及び同期プールを含む多重スレッドプールを使用するスレッド化モデルを採用するが、これは、システムが要求を優先順位付けすることを可能にする。この設計はまた、オペレーションのブロックを実行するユーザーコードをうまく許容するものである。本発明はまた、単一サーバー内で多重実行キューを提供できる能力もサポートする。多重キューの付加は、要求の優先順位付け、絞込みのサポート、及び減少したキュー競合、を含む従来システムを超えるいくつかの利点を提供する。キューは、優先度の高い要求及び優先度の低い要求に、独立に割り当てることができる。それゆえ、システム管理者は、作業の各クラスについて要求されるスループットが達成されるまで、これらのキューに割り当てられるスレッドの数を調整することができる。
2005505833.tif 000002
【特許請求の範囲】
【請求項１】
クライアントアプリケーションからサーバーリソースへの要求を受け取り、処理するためのシステムであって、
サーバーリソースにアクセスすることについてのクライアントからの要求を受け取るサーバー要求インターフェースと、
前記サーバーリソースにアクセスすることについての要求をキューに入れるように構築された、複数の実行キューと、
前記キューの中の選択された一つのキューに特定の要求を入れるように、リソース毎に構築された発送ポリシーと、
を備えることを特徴とするシステム。
【請求項２】
前記要求が、前記リソースにアクセスするときにクライアントアプリケーションに提供すべきサービスの品質を指定するようになった、
請求項１記載のシステム。
【請求項３】
前記キューの要求に応じるためにスレッドを使用する請求項１記載のシステム。
【請求項４】
構成ファイル内において、各リソースについて多重キューを構成することができる
請求項１記載のシステム。
【請求項５】
前記サーバーが、前記発送ポリシーにより、直接発送又はキュー待ち発送のいずれかを指定する、
請求項１記載のシステム。
【請求項６】
前記リソースがサーブレットである請求項１記載のシステム。
【請求項７】
前記リソースがJavaサーブレットページである請求項１記載のシステム。
【請求項８】
前記リソースが個々のキューの名前に対応付けられる請求項１記載のシステム。
【請求項９】
各キューが複数の関連スレッドを持ち、当該スレッドの数は、前記キューに関連する要求の優先順位付けを可能とするように構成することができる、
請求項１記載のシステム。
【請求項１０】
前記複数の実行キューが、非同期スレッドプール及び同期スレッドプールを使用する請求項１記載のシステム。
【請求項１１】
クライアントアプリケーションからサーバーリソースへの要求を受け取り、かつ処理するための方法であって、
サーバーリソースにアクセスすることについてのクライアントからの要求を受け取るステップと、
前記要求を複数の実行キューの中の一つのキューに入れるステップと、
を含み、前記キューに入れるステップが、前記キューの中の選択された一つのキューに特定の要求を入れるようリソース毎に構築することのできる発送ポリシーに従って、前記サーバーリソースへのアクセスの要求をキューに入れるように構成することができる、
ことを特徴とする方法。
【請求項１２】
前記要求が、前記リソースにアクセスするときに前記クライアントアプリケーションに提供すべきサービスの品質を指定するようになった、
請求項11記載の方法。
【請求項１３】
前記キューの要求に応じるためにスレッドを使用する請求項11記載の方法。
【請求項１４】
設定ファイルの中で、各リソースについて多重キューを構成することができる、
請求項11記載の方法。
【請求項１５】
前記クライアントアプリケーションが、直接発送又はキュー待ち発送のいずれかを指定する、
請求項11記載の方法。
【請求項１６】
前記リソースがサーブレットである請求項11記載の方法。
【請求項１７】
前記リソースがJavaサーブレットページである請求項11記載の方法。
【請求項１８】
前記リソースが個々のキューの名前に対応付けられる請求項11記載の方法。
【請求項１９】
各キューが複数の関連スレッドを持ち、当該スレッドの数が前記キューに関連する要求の優先順位付を可能とするように構成することができる、
請求項11記載の方法。
【請求項２０】
前記複数の実行キューが、非同期スレッドプール及び同期スレッドプールを使用する、
請求項11記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、一般的にアプリケーションサーバー及びトランザクションサーバーに関するものであり、特に多重発送プールを用いたメッセージキューイング及びスレッドをサポートするためのシステムに関するものである。
【０００２】
(著作権表示)
本特許文献の開示の一部は、著作権保護を条件とする題材を含むものである。本特許文献又は特許開示が特許商標庁の特許書類又は記録に掲載される限りでは、著作権者は何人によるその複製にも異議はないが、しかしもしそうでなければ、一切の無断転載を禁ずる。
【０００３】
(優先権の主張)
本出願は、2001年10月5日に出願され、かつ引用により本出願に組み入れられる「多重発送プールを用いたアプリケーションサーバーのメッセージングのためのシステム」という名称の米国特許仮出願60/327,543号、に基づく優先権を主張するものである。
【０００４】
(相互引用)
本出願は、2001年10月5日に出願され、発明者がAdamMessinger及びDonFergusonである「非同期キューを用いたアプリケーションサーバーのメッセージングのためのシステム」という名称の米国特許仮出願60/327,530号、及び、2002年10月3日に出願され、発明者がAdamMessinger、SamPullara及びDaveBrownである「Javaサーブレットを非同期メッセージと統合するためのシステム」という名称の米国特許出願と関連のあるものであり、双方の出願とも引用により本出願に組み入れられる。
【背景技術】
【０００５】
企業ソフトウェア界全体の中心的人物と共同で、サンマイクロシステムにより開発されたJava2プラットフォームエンタープライズエディション(J2EE)の仕様は、多層企業アプリケーションを開発するための現行標準の一つを定義する。J2EEは、企業アプリケーションの設計、開発、組み立て、及び導入へのコンポーネントベースの手法を提供し、これはコストを減らし、かつ設計及び実装をしっかりしたものにすることを可能にする。J2EEプラットフォームは、多層分散アプリケーションモデル、コンポーネントを再利用できる能力、一体化されたセキュリティモデル、及び柔軟なトランザクション制御、を開発者に与える。それらは、これまでになく早く市場に革新的なカスタマーソリューションを提供できるだけでなく、その結果として生じたプラットフォームに依存しないJ2EEのコンポーネントベースの解決策は、如何なるベンダーの製品及びアプリケーションプログラムインターフェース(APIs)とも結び付くものではない。
【０００６】
J2EEの仕様は、以下の種類のコンポーネント、すなわち、アプリケーションクライアントコンポーネント、EnterpriseJavaBeans(EJB)、サーブレット及びJavaServerPages(JSP)(ウェブコンポーネントとも言う)、及びアプレットを定義する。多層分散アプリケーションモデルは、機能に従ってアプリケーションロジックがコンポーネントに分割され、異なるアプリケーションコンポーネントが同じ又は異なるサーバー上でJ2EEアプリケーションを作り上げることができることを含む。アプリケーションコンポーネントが実際にどこにインストールされるかは、そのアプリケーションコンポーネントが多層J2EE環境の中のどの層に属するかに依る。図1にこれらの層を図示する。そこで示すように、アプリケーションサーバー層104は、EJBコンテナ及び/又はサーブレット、JSP、及びhtmlページ104のような表示用コンテナを開発するのに使用される。これらは、クライアント108及びクライアントアプリケーションが配置されるクライアント層102と、企業リソース計画(ERP)システムのような企業アプリケーション又は従来アプリケーションのホストとして働くために使用される後端層106との間のインターフェースとして、順番に使用される。
【０００７】
クライアント層：会社のファイアウォールの内側でも外側でも、これらはブラウザ、Javaベースのプログラム、又はクライアント層内で動作する他のウェブイネーブルのプログラミング環境、とすることができる。
【０００８】
アプリケーションサーバー層：通常この層は、クライアント要求をサポートするために、表示ロジック及びビジネスロジックの組み合わせのホストとして働く。表示ロジックはHTMLページを表示するJSPページ及びサーブレットを介してサポートされるが、一方、ビジネスロジックは遠隔メソッド呼び出し(RMI)オブジェクト及びEJBs112を介してサポートされる。EJBは、トランザクション、ライフサイクル及び状態の管理、リソースプーリング、セキュリティ等のためのコンテナ環境に依存するが、これらは共に、ビーンを実行する実行時環境を作り上げるものである。
【０００９】
後端層：これは一般的に、既存のアプリケーション及びデータ貯蔵の組み合わせである。それはまた、企業リソース計画(ERP)、汎用大型コンピュータのトランザクション処理、データベースシステム、及び他の従来の情報システムのようなシステムを含むことができるので、企業情報システム(EIS)層とも呼ばれる。
【００１０】
J2EEアプリケーションのコンポーネントは別々に、かつしばしば異なるデバイス上で動作するので、クライアント層及びアプリケーションサーバー層のコードが他のコード及びリソースを捜しかつ参照するための方法が必要である。例えば、クライアント及びアプリケーションのコードは、エンタープライズビーンのようなユーザー定義のオブジェクト、及び、後端層の中のリソース及びメッセージ接続を探索するために順番に使用されるJavaデータベース接続(JDBC)データソースオブジェクトの場所のような環境登録、を捜すためにJava名称及びディレクトリインターフェース(JNDI)116を使用することができる。
【００１１】
セキュリティ管理及びトランザクション管理のようなアプリケーション動作は、ウェブコンポーネント及びエンタープライズビーンコンポーネント上で配置時に、設定することができる。この配置時の特徴は、その組み立てと共に変化するであろう環境設定から、アプリケーションロジックを切り離すことである。J2EEセキュリティモデルにより、開発者は、システムリソースが承認されたユーザーによってのみアクセスできるように、ウェブコンポーネント又はエンタープライズビーンコンポーネントを構築できる。例えば、ウェブコンポーネントを、ユーザー名及びパスワードの入力を要求するように構築することができる。特定のグループ内の人だけがある決まった種類のそのメソッドを呼び出すことができるように、エンタープライズビーンコンポーネントを構築することができる。或いはその代わりに、サーブレットコンポーネントを、そのメソッドの幾つかは全ての人がアクセスできるように、かつ二、三のメソッドは組織内のある特権の与えられた人のみがアクセスできるように、構築することができるであろう。同じサーブレットコンポーネントを、他の環境においては、全てのメソッドが全ての人に利用可能であるように、又は全てのメソッドが二、三の選ばれた人のみに利用可能であるように、構築することができる。
【００１２】
カリフォルニア州サンノゼにあるBEAシステムのウェブロジックサーバー製品のような幾つかのアプリケーションサーバーは、そのサーバー上で動作するコンポーネントの使用の細かい制御を考慮するアクセス制御リスト(ACL)機構を使用する。ACLを使用すると、開発者は、どのユーザー又はユーザーのグループによって、何を実行できるか又はできないか、をJavaメソッドの階層で定義することができる。このACL機構は、自分自身のアクセス制御機構をそのEJB仕様の中で定義させる、EJBを除いたアプリケーションサーバー上で動作する如何なるものをも扱う。セキュリティ領域は、管理者が既存の承認又は認証システムからの情報をACLに読み込むことを可能にする。
【００１３】
Javaサーブレット
サーブレットとは、ウェブサーバーの機能を拡張するプログラムである。サーブレットは、クライアントから要求を受け取り、動的に応答を生成し(多分、その要求を満たすためにデータベースに問い合わせて)、次いでHTML又はXML文書を含む応答をクライアントに送る。サーブレットはJavaクラス及びストリームを使用するので、CGIに似ているが、しかし典型的に書くことがより容易である。サーブレットはJavaバイトコードにコンパイルされ、かつ実行時にはサーブレットインスタンスがメモリ内に保存されるため、それらはより高速に実行され、各クライアント要求は新たなスレッドを生む。サーブレットは、動的なやり方でHTTP応答ストリームに対するデータを生成することを容易にする。各クライアント要求は新たな接続として実行され、そのため通常、フロー制御は要求間では発生しない。このセッション管理を可能とすることは、要求間での特定のクライアントの状態を保持する。幾つかのアプリケーションサーバーでは、サーブレットは、メソッド要求間の自己の状態を保存するため、HTTPセッションオブジェクトを使用する。このオブジェクトは、フェイルオーバーの目的のため、クラスタ化された環境において複製することができる。
【００１４】
Javaサーバーページ
JSPページは、サーブレットを開発するための、テキストベースの表示専用の方法である。JSPページは、サーブレットの全ての利点を提供し、かつJavaBeansクラスと組み合わされる時、内容と表示用ロジックとを別々にしておくための容易な方法を提供する。JSPページ及びサーブレットの双方は、プラットフォームに依存せず、かつより少ないオーバーヘッドを使用するので、共通ゲートウェイインターフェース(CGI)よりも望ましい。似たような外観及び雰囲気を持つページから成るウェブサイトを構築するためのウェブテンプレートを定義するために、JavaBeansクラスと共に、JSPページを使用することができる。JavaBeansクラスがデータ翻訳を実行するため、テンプレートはJavaコードを持たない。これは、HTMLエディタによりそれらを保守することができることを意味する。JSPページを使用した単純なウェブベースのアプリケーションは、JavaBeansクラスではなく、特注タグ又は小スクリプトを使って、内容をアプリケーションロジックと結び付けるのに使用することができる。特注タグは、JSPページに読み込まれるタグライブラリにまとめて束ねられる。小スクリプトは、JSPページに直接埋め込まれる小さなJavaコードの部分(セグメント)である。
【００１５】
データベースアクセスサービス(JDBC)
JDBCはリレーショナルデータベースへの橋渡しの役割を果たし、かつODBC(開放型データベース接続性)の仕様でモデル化される。それはドライバの使用を通じて、データベースをプログラムコードから切り離す。JDBCの幾つかの実装は、詳細なデータ形式のサポートを提供し、またスクロール可能な結果集合及び一括更新の機能をサポートする。
【００１６】
Javaメッセージングサービス(JMS)
JMSは、Javaプログラム間でのメッセージの交換をサポートするために使用されるJ2EEの機構である。これはJavaが非同期通信をサポートする方法であり、そこでは送信者及び受信者は互いを意識する必要がなく、それゆえ独立して動作することができる。JMSは現在、次の二つのメッセージングモデルをサポートする。
【００１７】
ポイントツーポイント(point  to  point)−これはメッセージキューに基づくものである。このモデルでは、メッセージ作成者はキューにメッセージを送る。メッセージ消費者はメッセージを検出しようとするために、自分自身をキューに接続することができる。メッセージがキューに到着する時、消費者はそれをキューから取り外し、かつそれに応答する。メッセージはただ一つのキューに送られることができ、かつただ一人の消費者により使用されるであろう。消費者は、自分が必要とするまさにそのメッセージ形式を指定するために、メッセージを選別することを選択できる。
【００１８】
発行及び購読(publish  and  subscribe)−これは、作成者がある話題に対してメッセージを送ることを可能にし、かつその話題について登録されている全ての消費者がそれらのメッセージを検索することを可能にする。この場合、多くの消費者が同じメッセージを受け取ることができる。
【００１９】
JavaIDL及びマルチスレッドサーバー
CORBAの世界では、CORBAオブジェクトが、契約、すなわちCORBAオブジェクトが他のオブジェクトと相互作用しようとする方法を指定するために、インターフェース定義言語(IDL)を使用することを可能にしようとする試みがなされてきた。契約は、JavaIDLを用いて、Javaの世界とCORBAの世界との間で定義することができる。SunのJava開発キット(JDK)バージョン1.2から続けて、オブジェクト要求ブローカー(ORB)は、Javaアプリケーションがインターネット相互ORBプロトコル(IIOP)を介してリモートのCORBAオブジェクトを呼び出すことを可能にする。マルチスレッドCORBAサーバーでは、イベントキューは、スレッド化ポリシーをそのCORBAサーバー上で実装するための方法を提供する。実際には、イベントキューは、CORBA要求に望まれるスレッド化ポリシーをサポートし、かつそのスレッド化ポリシーの中で非CORBAイベントの処理を統合する。lonaソフトウェアのOrbixサーバーのようなマルチスレッドCORBAサーバーは、例えば、どのくらいの数のスレッドを作成するか、いつそれらのスレッドを作成するか、及びどの要求をどのスレッドにより処理するか、を定めるポリシーを実装することができる。特定のポリシーを実装することは典型的に、多数のキュー及び作業者スレッドを作成すること、及び各入力イベントに対してどのキューを使用すべきかを定めるロジックをプログラムすること、を含む。
【００２０】
このように、マルチスレッドCORBAサーバーは、いくつかのCORBA要求を同時に処理することができる。これの一つの主な利点は、全体のスループットを高めることである。要求を処理する作業をどのようにそれらの間で共有すべきかに依って、スレッド化ポリシーをそれぞれの要望に対してカスタマイズすることができる。これらの選択肢は、以下のものを含む。
【００２１】
各オペレーションにつき一つのスレッド：この場合、各入力要求を処理するために、新たなスレッドが作成される。この選択は、最大並行性を提供するが、しかし最高負荷時にサーバーが多数の同時要求を受け取る場合には、時々スレッドを多く作りすぎる。
【００２２】
スレッドプールの使用：この場合、要求はキューに入れられ、かつスレッドのプール内の第一の利用可能なスレッドにより処理される。スレッドの最大数、従ってサーバーの負荷は、プールのサイズを制限することにより、制限される。
【００２３】
各オブジェクトにつき一つのスレッド：この選択に従うと、各オブジェクトに対して、一又はそれ以上の要求キューが保持される。この選択は、オブジェクト間の完全な並行性を提供するが、しかしそれぞれの個々のオブジェクトへのアクセスを一列に並べる。
【００２４】
各クライアントにつき一つのスレッド：各クライアントに対して、要求キューが保持される。この選択は、各々にリソースが割り当てられるスレッドの数を管理することにより、クライアントの平等な扱いを保証する。
【００２５】
J2EEサーバーにおけるスレッド化
J2EEベースのトランザクションサーバー及びアプリケーションサーバーで使用するような現行のスレッド化ポリシーに関する一つの問題は、要求の概念又は優先順位付けである。スレッド化ポリシーは、要求管理の観点から最大スループットのために設計することはできるが、要求の優先順位付けの観点からの選択肢はほとんどない。多くの現行のサーバー製品は、ネットワーク上のクライアントからの要求を読み取るためにスレッドのプールを使用する。完全な要求がキューに読み込まれると、サーバーの中で、実行のためにそれを発送しなければならない。しかし、開発者が、発送するよりも前に、その完全な要求に優先順位を付けることが可能になることは、殆どない。
【００２６】
要求の優先順位付けは一般的に求められる機能であるが、しかし、基となるサーバーコードにそれを付加する複雑さに対する懸念のため、及びそれが作り出す可能性のある優先度の逆転のような新たな問題のため、実装することは難しい。多重キューの付加は、ソフトウェア管理者又は開発者に、本来の優先方式が行うであろうよりも、これらの問題をうまく扱う優先機構を提供するであろう。
【００２７】
要求の絞り込みは、アプリケーションサーバーの顧客が一般的に求めるもう一つの機能である。作業負荷の一部が大量のメモリ、CPU時間、又は他のリソースを必要とするところで、これは一般的に要求される。このシステムは、これらの要求の多くを並行に処理することができない。
【００２８】
多くのアプリケーションサーバーは、要求を、それを読み取るスレッドと同じスレッド内で実行すること、又は作業者スレッドのプールを供給するキューに入れることを可能にする、発送オプションを提供する。この構成を使用すると、要求のサービスパラメータの様々な特性を制御することができる。例えば、要求を、それを読み取るスレッドの中で直接実行することにより、キューを飛び越し、迅速化することができる。幾つかの要求を、限られた数のスレッドのみによって対処されるキューに割り当てることにより、それらをかわるがわる絞ることができる。
【００２９】
(要約)
これらの要求に対処するため、本発明の実施形態は、アプリケーションサーバーにおける使用のためのシステム又は機構を提供するが、これはサーバースレッド化モデル、すなわち作業要求を実行するためにスレッドを割り当てるポリシー、を高めるものである。本発明の実施形態は、例えばカリフォルニア州サンノゼにあるBEAシステムのウェブロジックサーバー製品を含む、いろいろなアプリケーションサーバーで使用することができる。本発明の実施形態を使用するように設計されたアプリケーションサーバー又は何らかのサーバーは、非同期プール(時々、読み取りスレッドと呼ばれる)及び同期プール(実行スレッドと呼ばれる)を含む多重スレッドプールを使用するスレッド化モデルを採用する。このプールの併用は、システムが要求を優先順位付けすることを可能にする。この設計はまた、オペレーションのブロックを実行するユーザーコードをうまく許容するものである。
【００３０】
本発明の一実施形態では、非同期スレッドプールは、非同期読み取り結果が利用可能となるように、非同期入力機構(ここでは、多重化装置と呼ばれる)に応対する。結果が利用可能になると、プールからのスレッドは、そのメッセージを見て、かつ適切なコールバックを作成することによりそれを発送する。この発送コールバックは通常、同期スレッドプールによる後での処理の要求をキューに入れる。しかしながら、ある特定のブロック化なしの優先要求は、コールバックの中で直接処理される。積極的に入力を受け入れることで、これらの優先度の高い要求は、優先度の低い要求が実行する間、読み取られるのを待つことはない。
【００３１】
同期スレッドプールは、要求のキューに応対する。要求が利用可能となると、同期プールからのスレッドは、その要求をキューから受け取り、それを処理し、かつその結果を送信する。要求を処理するのと同時に、スレッドは、結果の送信というようなコードを実行することができ、これはスレッドをブロックさせるものである。
【００３２】
非同期出力及び非同期応答の付加は、従来システムにおける一般的なタスクであるスレッド処理の調整の必要性の一部を軽減する。さらに本発明の実施形態は、異なる要求形式の処理のより細かい制御を提供するように、多重同期スレッドプールの構成を考慮するものである。
【００３３】
本発明の実施形態はまた、単一サーバー内で多重実行キューを提供できる能力もサポートする。これらのキューは、個々に、現行の実行キューと似ている。各実行キューは、キューからの作業の取り出しに割り当てられる作業者スレッドのプールを持つ。本発明の一実施形態によると、各サーバーは、一つのデフォルトの実行キュー、及び零又は一又はそれ以上のカスタムの実行キューを持つ。多重キューの付加は、要求の優先順位付け、絞込みのサポート、及び減少したキュー競合、を含む従来システムを超えるいくつかの利点を提供する。キューは、優先度の高い要求及び優先度の低い要求に、独立に割り当てることができる。それゆえ、システム管理者は、作業の各クラスについて要求されるスループットが達成されるまで、これらのキューに割り当てられるスレッドの数を調整することができる。
【発明の開示】
【００３４】
(発明の詳細な説明)
大雑把に説明すると、本発明の実施形態は、トランザクションサーバー、アプリケーションサーバー、及びメッセージングサーバーにおける使用、特にRMI(遠隔メソッド呼び出し)、EJB(エンタープライズJavaビーン)、及びサーブレットにおける使用のための、柔軟な発送ポリシーのシステムのための拡張機能を提供する。本発明の実施形態を取り入れるアプリケーションサーバー、トランザクションサーバー、又はメッセージングサーバー(全て共通して以下、単にアプリケーションサーバーという)は、ネットワーク上のクライアントからの要求を読み取るためのスレッドのプールを使用する。完全な要求が読み取られると、それをサーバー内での実行のために発送しなければならない。本発明の実施形態は、この発送ポリシーを構築できる能力を提供する。サーブレットでは、これは各URL(全域資源位置指示子)ごとに構築される。RMI及びEJBでは、各メソッドごとに発送ポリシーが構築される。
【００３５】
本発明の実施形態により提供される発送オプションは、要求を、それを読み取るのと同じスレッド内で実行することを可能にする、あるいはそのかわりに、作業者スレッドのプールを供給するキューに入れることを可能にする。この様々な発送の構成を使って、要求のサービスパラメータの様々な特性を制御することができる。例えば、要求を、それを読み取るスレッド内で直接要求を実行することにより、その結果キューを飛び越し、迅速化することができる。いくつかの要求を限られた数のスレッドのみにより対処されるキューに割り当てることにより、それらをかわるがわる絞り込むことができる。
【００３６】
本発明の実施形態は、アプリケーションサーバーメッセージングに関連する新しい機能を提供するが、これは、ある種のメッセージングを要求する如何なるサーバー形式においても使用することができる。各サーバーの設計の中核において、スレッド化モデルは、作業要求を実行するためにスレッドを割り当てるポリシーである。本発明の実施形態に従って、サーバーは、非同期プール(読み取りスレッド)及び同期プール(実行スレッド)の２つのスレッドプールを使用するスレッド化モデルを採用する。このプールの併用及び発送オプションの柔軟性は、オペレーションのブロック化を実行するユーザーコードを許容すると同時に、管理者が要求を効果的に優先順位付けすることを可能にする。
【００３７】
図２は、要求をサーバーリソース205に渡すのに使用される、本発明の実施形態により提供されるようなスレッドプール206を示している。サーバーは、個々のリソースにおいて使用されるべき発送ポリシー211を定める、各リソースのための構成情報を含む。一実施形態に従って、非同期読み取り結果が利用可能となるように、スレッドプール208は非同期入力機構202(時々、多重化装置と呼ばれる)に応対する。結果が利用可能となると、プールからのスレッドは、そのメッセージを見て、かつ適切なコールバックを作成することにより、それを発送する。発送コールバックは通常、同期スレッドプールによる後での処理の要求をキューに入れる。しかしながら、ある特定のブロック化なしの優先要求は、コールバックの中で直接処理される。非同期スレッドプールが積極的に入力を受け入れることを可能にすることにより、優先度の高い要求212は、優先度の低い要求216が実行する間、読み取られるのを待つことはない。これらのスレッドは決してブロックしないはずであるので、おそらく一つのCPUにつきたった一つの、少数のスレッドが通常存在する。本発明の実施形態は付加的に、非同期スレッドプールがネットワーク出力のオペレーションを実行できる能力を提供する。この特別な機能は、2001年10月5日に出願された、発明者がAdamMessinger及びDonFergusonである「非同期キューを用いたアプリケーションサーバーメッセージングのためのシステム」という名称の米国特許仮出願60/327,530号、及び、2002年10月3日に出願された、発明者がAdamMessinger、SamPullara及びDaveBrownである「Javaサーブレットを非同期メッセージと統合するためのシステム」という名称の米国特許出願の中で詳細に説明されており、双方の出願とも引用により本出願に組み入れられる。
【００３８】
図２に示すように、同期スレッドプール210は、要求のキュー204に応対する。要求が利用可能となると、プールからのスレッドは、その要求をキューから受け取り、それを処理し、かつその結果216をリソース205に送出する。要求を処理する一方で、スレッドは、結果を送出するというようなコードを実行することができ、これによりスレッドはブロックする。それゆえスレッド数は、動作可能な状態にあるCPU一つにつき一つのスレッドが常に存在するように、調整されるべきである。サーバーの適切な最適化は、性能の理由のため重要である。本発明の実施形態で使用されるような非同期出力、及び非同期応答の付加は、この最適化の必要性の一部を軽減する。本発明の実施形態はまた、異なる要求形式の処理のより細かい制御を提供するように、管理者に多重同期スレッドプールを構築できる能力を与える。
【００３９】
発送
発送とは、サーバー要求を受け取り、かつそれを処理するのに適切な場所にその要求を送る処理である。アプリケーションサーバー、又は本発明の実施形態を使用できるサーバーには典型的に、直接発送とキュー待ち発送、の二つの形式の発送が存在する。サーバー要求は、例えばネットワークから読み取られる入力の結果、時間トリガー、又は何か他の作業の続行を含む、サーバーからの如何なる信号ともすることができる。
【００４０】
直接発送では、入力メッセージを生成するスレッドがまた、そのメッセージを処理する。要求を処理している間、発送スレッドは他のスレッドに置き換えられることはなく、そのため実行されるべき作業が、大幅な時間の間全く、発送スレッドをブロックしないであろうことが重要である。例えば、要求を処理するとき、ソケット読み取りスレッドがブロックされる場合には、サーバーは如何なる新たな入力メッセージも対処できないであろう、かつ更なる入力に応答できないであろう。同様に、時間トリガーのスレッドがブロックされる場合には、サーバー内の重要なタイミングイベントが配信されないであろう。この理由のため、直接発送は、典型的には内部APIを通じて利用可能にされ、かつ優先度の高いシステムレベルのメッセージのためだけに使用される。
【００４１】
図３は、従来の実行キューの機構を示している。そこに示すように、全域資源位置指示子(URL)又はデータベースのような特定のリソースに送られるクライアントからの要求は、実行キュー304に入れられる。一又はそれ以上の作業者スレッドのセット306、308、又はスレッド処理は、キューからエントリ310を検索し、それらをリソースを背景に実行し、その結果をクライアントに返す。この機構における問題は、キューが最初の入力/最初の出力の方式で作動することであり、他のものの前にキューの中の一つのエントリを処理するような、特定のエントリを優先する方法がないことである。
【００４２】
キュー待ち発送では、発送スレッドは入力メッセージをキューに入れ、そこでそのメッセージは後で作業者スレッドによりキューから取り出され、かつ処理されるであろう。幾つかの実施形態では、たった一つの実行キュー、及びそのキューからの要求を取り出しかつ処理するために割り当てられた実行スレッドの一つのプールが存在する。他の実施形態は、多重実行キューを使用することができる。キューの長さは、制限される又は制限されないとすることができるが、但し、キューの長さが制限される時はメモリ使用に関する問題を防ぐよう注意を払わなければならない。典型的には、全てのユーザー要求は配信されるのではなく、キューに発送される。
【００４３】
多重キュー
図４は、本発明の実施形態により提供される多重キューが、発送ポリシーを構築するためにどのように使用されるかを示している。図４に示すように、クライアントからの要求は、複数のキューソケット402、404、406から選択されたキューソケットに渡される。ソケットは並列に作動し、一つのソケット上のエントリを同時に実行する、あるいはそれらを他のソケット内のエントリよりも先に実行することを可能にする。この別々かつ並列なオペレーションは、システムが要求を優先順位付けすることを可能にする。一又はそれ以上の非同期スレッドのセット412、414、416は、ソケット要求を処理する、及びリソースへのアクセスを提供するのに使用される。非同期スレッドの集合(例えば、412及び414)は、ソケットの集合(例えば、404及び406)間で共有することができる。あるいはそのかわりに、ソケット402が、そのソケット内での特定の要求の信頼できる、又は優先度の高い処理を可能とするため、専用のスレッド416を持つことができる。本発明の実施形態を具体化する、又は組み込むアプリケーションサーバーは、単一サーバーの中で多重実行キューを持つことができる能力をサポートする。典型的には、各実行キューは、キューから作業を取り出すことに割り当てられる作業者スレッドのプールを持つ。一実施形態では、各サーバーは、一つのデフォルトの実行キュー、及び零又は一又はそれ以上のカスタムの実行キューを持つ。多重キューの付加は、要求の優先順位付け、絞込みのサポート、及び減少したキュー競合を含む、幾つかの利点を提供する。
【００４４】
要求の優先順位付け
上で説明するように、要求の優先順位付けは一般に求められる機能である。基となるコードにそれを加える場合の複雑さについての懸念のため、及びそれが作り出す可能性のある、優先度の逆転のような付加的な問題のため、従来、これは対処するのが難しい領域であった。本発明の実施形態で使用するように、多重キューの付加は、「本来の」優先方式が行うであろうよりもうまくこれらの懸念を扱う優先機構を提供する。管理者がそのように望む場合には、優先度の高い要求及び優先度の低い要求に、独立してキューを割り当てることができる。次いで、管理者は、作業の各クラスにおいて要求されるスループットが達成されるまで、これらのキューに割り当てられるスレッド数を調整することができる。
【００４５】
要求の絞り込み
要求の絞り込みは、アプリケーションサーバーのユーザーにより一般に要求される機能である。絞り込みは、作業負荷の一部が大量のメモリ、CPU時間、又は他のリソースを要求する場合において重要である。典型的には、システムは、これらの要求の多くを同時に処理することができない。システムリソースを保全することを保証するため、適当な数のスレッドにより構成されるキューに、全てのこれらの形式の要求が送られる可能性があることから、本発明の実施形態は、要求の絞り込みのための機構を提供する。
【００４６】
キュー競合の減少
キュー競合は、多重短要求に応じる、重く負荷のかかったシステムのベンチマークにおける問題である。本発明の実施形態は、負荷を幾つかのキュー上に分散させることにより、この問題にうまく取り組むための機構を提供し、キュー競合を減らすことができる。スループットを最大にするような手法で、要求はキューをまたがって配信される。
【００４７】
図５は、本発明の実施形態に従った多重キュー発送ポリシーのフローチャートを示している。そこに示すように、ステップ502では、特定のリソースにアクセスする要求がサーバーで受け取られる。これは、例えば、特定のサービス、URL、又はデータベースにアクセスする要求とすることができる。ステップ504では、発送スレッドが、多重メッセージキュー又はソケットの中の一つに要求を置く。ステップ506では、デフォルトの実行キュー、及び多重カスタム実行キューの提供の組み合わせは、システム又はシステム管理者に、要求をどのソケット又はキューの中に置くべきかを指定することによりその要求を優先できる能力を与える。ステップ508では、作業者スレッドが適当なメッセージキューから要求を検索し、かつ、ステップ510では、要求をサーバーで処理し、かつその結果をクライアントに返す。
【００４８】
RMI及びHTTPの実装
本発明の一実施形態に従って、典型的な遠隔メソッド呼び出し(RMI)の実装を、多重キューを利用するのに適応させる。RMI記述子は、メソッド毎のキューイングポリシーを設けることを可能にするために一般化される。この機能は、直接発送又はキュー待ち発送、を指定するための機構を提供する。Java仮想マシン(JVM)における使用のための一実施形態では、要求発送者メッセージがRJVMレベルに発送される。次にRJVMは、その実行時記述子を調べ、かつその要求にどの発送ポリシーを適用すべきかを定める。
【００４９】
サーブレットの実装を多重キューを利用するのに適応させることは、同様に行うことができる。一実施形態では、発送ポリシーを説明するメタデータは、サーブレットの配置記述子の中に置くことができる。要求が通常キューに入れられる点は、サーブレットが呼び出されるべき点までに存在することが定められている。この点で、適切な発送ポリシーを定めることができ、かつ適切な措置をとることができる。HTTPトンネル機構もまた、この機構を使用するように修正することができる。いくつかの実装では、タイミングサービスを多重キューを利用するのに適応させることできる。如何なるAPIへの付加もまた、特定のタイマーのための発送ポリシーの仕様を受け入れるようにすることができる。これは、タイミングスレッドの中で直接トリガーを提供する、現行の直接発送機構と一体化することができる。
【００５０】
特定のアプリケーションサーバーでは、幾つかの内部実装は、現在処理されている要求に付随する作業を処理するために、キュー待ち発送を使用する。これは、必要以上に長くロックを持続するのを防ぐためにしばしば行われるが、しかしこれはまた、多重キューの付加を伴って、付随的な要求を異なるキューの中に入れることにより、作業の優先度を区別するために使用することもできる。
【００５１】
さらに、多くの顧客が、付随的な要求のこのキュー待ち発送を実行できる能力を要求している。一実施形態では、本発明は、ユーザーがjava.lang.Runnable関数を指定されたキューに入れることを可能にする。次いで、このRunnable関数は、実行要求(ExecuteRequest)内にラップされ、希望するキューに置かれる。
【００５２】
実行キュー及びスレッドプールの構築
実行キュー及びスレッドプールの構築を可能にするために、本発明の実施形態は、コマンド及び構文のセットを提供する。次の章では、本発明の一実施形態に従って、これらのプールを使用するためのサーブレット、jsp、ejb、及びrmiオブジェクトの構築の手引きを与える。本発明の実施形態が、例証の目的のために与えられた、下で説明する特定の実装に限定されるものではなく、しかしそのかわり、他の実装において、及び他のアプリケーションサーバー又はサーバーにおいて使用することができることは明らかであろう。
【００５３】
実行キューの構築
サーバー構築(例えば、config.xmlファイル)において、開発者は、サーバー構築における「実行キュー」タグを介して、実行キューのセットを定義することができる。
<サーバー
名前＝「私のサーバー」
固有入出力イネーブル＝「真」
リッスンポート(受信ポート)＝「7701」
実行キュー＝「テストキュー」
>
<実行キュー
名前＝「テストキュー」
スレッド数＝「4」
/>
【００５４】
上で示す例は、4つの実行スレッドの関連プールを持つ、テストキューという名の実行キューの作成という結果となるであろう。
【００５５】
実行キューを使用するためのサーブレットの構築
サーブレットを構築するために、開発者又は管理者は、例えば、構築のためにweb.xmlファイルを使用するシステム内の「wl発送ポリシー」というタグを介して、キューの名前を設定するのにサーブレット初期パラメータを使用することができる。web.xmlファイルは、以下に示す典型的な一つのように、init-param(初期パラメータ)部を含む。
2005505833.tif 000003
【００５６】
実行キューを使用するためのJSPの構築
JSPは、サーブレットのように記載することができる。以下のコード例は、「テストキュー」という名前のキューを使用するように記載されたJSPを示している。
2005505833.tif 000004
【００５７】
実行キューを使用するためのEJB及びRMIの構築
EJBC及びRMICは、発送ポリシーの構築又はコマンドラインを可能にするため、発送ポリシーフラグを受け入れるように修正することができる。すなわち、
java  weblogic.rmic  dispatchPolicy(発送ポリシー)  testqueue(テストキュー)
java  weblogic.ejbc  dispatchPolicy(発送ポリシー)  testqueue(テストキュー)
【００５８】
優先度及びサービスの品質
本発明の幾つかの実施形態は、特定のスレッドプール内でスレッドの優先度を設定することを可能とするものである。しかしながら、本発明の一実施形態に従うと、その構築がプール内のスレッドの優先度を設定することを可能にするために、何の機構も提供されない。スレッドスケジューリングの意味規則はプラットフォーム間で変化するため、これは意図的なものであり、かつ、全ての実行スレッドが同じ優先度を持つ場合には、システムは欠乏/優先度逆転という問題により衝突しにくい。しかしながらまだ、優先度の高いトラフィックを軽く使用されるキュー、又はより多数の実行スレッドを持つキューに発送することができ、かつスレッドの優先度を明らかに使用することなく優先度の高い要求をより早く処理するという目標を達成することができる。
【００５９】
優先順位付けに密接に関連のあるトピックは、サービスの品質(QOS)である。発送ポリシーを使用すると、ある特定の形式の要求がある一定数のスレッドを持つであろうことを保証することができる。マシン上の如何なる他の負荷に関係なく、ある一定の速度で処理され続けなければならない幾つかの形式の要求が存在する場合には、これは役立つものとなり得る。
【００６０】
デッドロックの回避
別々の実行キューを使用するもっともな理由は、デッドロック状態を回避するためである。要求の処理が、追加の実行要求が完了することを要求する時、その追加要求のために別個のキューを構築することができる。例えば、サーブレット「a」がJMSキュー「b」から読み取る状況を考えなさい。サーバーの実行スレッドの全てがサーブレット「a」を実行している場合には、キュー「b」からメッセージを運ぶための実行スレッドは全く残らないであろう、そのためどの作業も進むことができない。サーブレット「a」のために別個のキューを定義することにより、この状態を回避することができる。
【００６１】
絞り込み及びスループットの最適化
別々のキューを使用するもう一つのもっともな理由は、リソースのある決まったプールを使用する要求を絞り込むためである。例えば、特定のジョブが大量のメモリを使用する場合には、それを限られた数の関連スレッドを持つキューに発送することは、より最適なものとすることができる。このように、システムは、同時に実行しているこの形式のジョブの最大数を制限することができ、かつサーバーがメモリを使い切ってしまう如何なる危険性も最小化することができる。
【００６２】
関連のある使用は、一つの特定のプールからのリソースへのアクセスを要求するそれらの要求を、アクセスを要求しない他のプール内の要求から切り離すことである。例えば、サーバーが２つのEJBのサーバーとして働いている場合を考えなさい。EJB「a」がデータベースにアクセスするために接続プールを使用し、その一方でEJB「b」があるメモリ内の作業のみを実行する(又はおそらく異なるプールを使用する)。スレッド数がプール内の接続数よりも多い場合には、システムは、「a」への要求を処理する間にプールからの接続を得ようとして、幾つかのスレッドがブロックされるという状態に遭遇し得る。同時に、空いている実行スレッドが存在する場合のみ進行することができるであろうキューの中に置かれている、「b」への他の要求が存在し得る。「a」及び「b」への要求を異なるキューに発送することにより、この状況を回避することができる。
【００６３】
性能の考慮
多重実行キューを持つことは非常に強力なツールであるが、しかしこれは注意して使用、又は構築されるべきである。管理者が考慮すべき事柄の幾つかは、以下のことを含む。
リソースの無駄使い：各キューはある一定の数のスレッドが割り当てられるので、他のキュー上の要求が休止状態に置かれている間、何もしていない多くのスレッドを持つ可能性がある。スレッドは安価なリソースではないので、そのため必要以上のスレッドを割り当てることは避けるべきである。
ライブロック及び優先度逆転：上で説明したように、別々のキューの適切な使用はデッドロックの機会を減らすことができるのと同時にまた、デバッグするのがかなり難しい可能性のある、起こり得る問題の新たなクラスを持ち込む。ささいな例として、同じクライアントから同じサーバーに向けて作成され、しかし別々のキューに発送された２つのリモートコール(遠隔コール)は、予想とは異なる順で戻ってくる可能性がある。
【００６４】
本発明の上述の説明は、例証及び説明の目的のために提供されている。これは、網羅的なもの、又は本発明を開示した厳密な形態に限定すること、を意図するものではない。明らかに、多くの修正及び変形が当業者には明白であろう。本発明の原理、及びその実用例を最もよく説明するために、本実施形態は選択されかつ説明されたものであり、その結果、他の当業者が、意図した特定の使用に適した様々な修正を伴った、様々な実施形態における本発明を理解することが可能となる。本発明の技術的範囲は、以下の特許請求の範囲、及びその均等技術により定められることを意図したものである。
【図面の簡単な説明】
【００６５】
【図１】本発明の実施形態を利用することのできるJ2EE互換のサーバーアーキテクチャを示す。
【図２】本発明の実施形態による、スレッド化モデルを示す。
【図３】本発明の実施形態による、多重発送キューシステムを示す。
【図４】本発明の実施形態による、多重スレッド発送システムを示す。
【図５】本発明の実施形態による、多重発送処理のフローチャートを示す。
【図１】
2005505833.tif 000005
【図２】
2005505833.tif 000006
【図３】
2005505833.tif 000007
【図４】
2005505833.tif 000008
【図５】
2005505833.tif 000009
【国際公開パンフレット】
2005505833.tif 000010
2005505833.tif 000011
2005505833.tif 000012
2005505833.tif 000013
2005505833.tif 000014
2005505833.tif 000015
2005505833.tif 000016
2005505833.tif 000017
2005505833.tif 000018
2005505833.tif 000019
2005505833.tif 000020
2005505833.tif 000021
2005505833.tif 000022
2005505833.tif 000023
2005505833.tif 000024
2005505833.tif 000025
2005505833.tif 000026
2005505833.tif 000027
2005505833.tif 000028
2005505833.tif 000029
2005505833.tif 000030
2005505833.tif 000031
2005505833.tif 000032
2005505833.tif 000033
2005505833.tif 000034
2005505833.tif 000035
2005505833.tif 000036
2005505833.tif 000037
2005505833.tif 000038
2005505833.tif 000039
2005505833.tif 000040
2005505833.tif 000041
2005505833.tif 000042
2005505833.tif 000043
【国際調査報告】
2005505833.tif 000044