JP4083233B2

JP4083233B2 - 多数のプロセスを制御するウェブ要求ブローカ

Info

Publication number: JP4083233B2
Application number: JP53303898A
Authority: JP
Inventors: アドゥヌスーラ，セシュ; アナンド，マラ; チョウ，ツン−ジェン; ナホダ，シュザード; ウー，レイモンド; パン，ロバート; シャルマ，アンクル; ブックマン，マシュー
Original assignee: オラクル・インターナショナル・コーポレイション
Priority date: 1997-02-03
Filing date: 1998-01-29
Publication date: 2008-04-30
Anticipated expiration: 2018-01-29
Also published as: AU740827B2; US6845505B1; ATE236480T1; JP2001511269A; DE69812899D1; EP0956687B1; AU6047898A; EP0956687A1; CA2279382A1; CA2279382C; DE69812899T2; WO1998034386A1

Description

発明の分野
この発明は、ネットワークされたコンピュータシステムにおけるサーバアーキテクチャに関し、特に、ウェブユーザの動的動作をサポートするサーバアプリケーションを実行するウェブサーバに関する。
発明の背景
ワールドワイドウェブはインターネット上のサーバのネットワーク（「ウェブサーバ」）を含み、その各々は１または２以上のＨＴＭＬ（ハイパーテキストマークアップ言語）ページを有する。ウェブサーバ上のＨＴＭＬページはそのサーバおよび（通常は）他のウェブサーバ上の他の文書の情報とそこへのハイパーテキストリンクを提供する。ウェブサーバはハイパーテキスト転送プロトコル（ＨＴＴＰ）を用いてクライアントと通信する。
ワールドワイドウェブのユーザはブラウザと呼ばれるクライアントプログラムを使用して、選択されたウェブサーバからの情報を要求し、デコードし、表示する。ブラウザのユーザがリンクを選択すると、要求がインターネット上をそのリンクで特定された情報をストアしているウェブサーバへと送られる。この要求に応答して、ウェブサーバは特定された情報をその要求を発行したブラウザに送信する。ブラウザは情報を受信し、受信した情報をユーザに呈示し、次のユーザ要求を待つ。
伝統的には、ウェブサーバ上に記憶された情報は静的ＨＴＭＬページの形である。静的ＨＴＭＬページはウェブブラウザからの要求に先立ってウェブサーバで生成され記憶される。要求に応答して、静的ＨＴＭＬページは単に記憶装置から読出され、要求したブラウザへと送信される。現在、動的動作を行なうことによってブラウザの要求に応答するウェブサーバアプリケーションを開発しようとする動きがある。たとえば、ウェブサーバは要求に応答してデータベースへの問合せを発行し、問合せの結果を含むウェブページを動的に構築し、この動的に構築されたＨＴＭＬページを要求を出したブラウザに送信してもよい。動的動作を行なうために、ウェブサーバの機能性を高めるかまたは増加させなければならない。動的動作をサポートするためにウェブサーバを拡張するためのさまざまな方策が開発されてきている。
ウェブブラウザからの要求に応答して動的動作を提供するための１つの方策では、共通ゲートウェイインターフェイス（ＣＧＩ）を用いる。ＣＧＩはウェブサバとＣＧＩプログラムとの間で情報を転送するための仕様である。ＣＧＩプログラムはＣＧＩ仕様に合致するデータを受けかつ返送するように設計された何らかのプログラムである。このプログラムはＣ、Perl、またはビジュアルベーシックを含むどのプログラム言語で書くこともできる。
ＣＧＩの方策は、特定された要求がサーバで受信されるたびに別個のプロセス（ＣＧＩプログラムの別個のインスタンス）がイニシエート（initiate）されるという欠点がある。このような要求が異なるユーザから何千と受信された場合、何千というプロセスがイニシエートされることとなり、サーバの利用可能な資源を使い果たしてしまう。
要求に対する動的応答を提供するための別の方策は、「プラグ−イン」拡張を用いることを含む。プラグ−イン拡張はさまざまな段階でサーバに送られるメモリセルを代行受信（intercept）して特定のユーザ要求に対する応用指向処理を実行する。ウェブサーバプラグ−インはウェブサーバおよびすべての他のウェブサーバプラグ−インと同じアドレス空間で実行する。したがって、プラグ−インを設計するアプリケーション開発者はウェブサーバの下層の動作詳細を熟知していなければならない。さらに、ウェブサーバと同じアドレス空間でプラグ−インを実行することはウェブサーバを安全上および安定性上危険にさらすこととなり、この場合欠陥のあるプラグ−インは他のプラグインまたはウェブサーバ自身をクラッシュさせたり、予測できない様態で動作させたりするおそれがある。
発明の概要
ウェブサーバが動的サーバ動作をサポートすることを可能として、多数の外部プロセスが制御可能、スケーラブルかつ効率的な様態でイニシエートされ、管理されかつ終了できる構成が必要とされる。
ある要求を処理するために構成されたプログラムの多数のインスタンスを実行中のウェブサーバに対し発行されたそのクライアント要求に応答するための構成であって、クライアントからの要求が利用可能なインスタンスに選択的にディスパッチされる構成もまた必要とされる。
さらに、クライアント要求に応答する構成であって、その要求を処理するよう構成されたプログラムのあるインスタンスが既存のインスタンスの利用可能性と予め定められたインスタンスの最大数とに基づいて選択的にイニシエートされる構成もまた必要とされる。
これらおよび他の必要性は、ウェブ要求ブローカが要求の処理を、その要求に対応するプログラムを特定し、そのプログラムのインスタンスを選択的にイニシエートさせ、要求をそのインスタンスにディスパッチしてその要求を処理させることによって要求の処理を制御する、この発明によって満たされる。
この発明の１つの局面によれば、ネットワークシステム上でクライアントからサーバに発行された要求は、ネットワーク上で要求を獲得し、その要求に対応するプログラムを特定することによって処理される。プログラムのあるインスタンスは、そのプログラムの所与のインスタンス数に基づいて選択的にイニシエートされる。要求はそのプログラムのイニシエートされたインスタンスへとディスパッチされ、そのインスタンスが対応のプログラムを実行して要求を処理する。その後インスタンスの実行に基づいて要求に対する応答がなされる。ここで、複数のプログラム、たとえばサーバ拡張が、制御可能な様態でサーバプロセスに付加されてもよい。さらに、特定されたプログラムのあるインスタンスを選択的にイニシエートすることで、サーバが多数のインスタンスの制御を維持することが確実になり、サーバ動作の安定性が保たれる。所定数のインスタンスはまたインスタンスの最小数と最大数とをともに特定してもよく、これによってメモリ内の少なくとも最小数のインスタンスを後続の要求のために維持することで処理の遅延を最小化することが可能になり、一方でインスタンスの最大数を制限することでサーバ資源の制御を維持する。
この発明の別の局面によれば、動作の実行の要求に応答するための、サーバによる実行の方法が構成される。この方法は、ネットワーク上で要求を獲得するステップと、要求をサーバによって実行されるディスパッチャプラグ−インに送るステップとを含む。要求は、ディスパッチャプラグ−インが、その要求を扱うように構成されたプログラムの利用可能なインスタンスがプログラムインスタンスの既存の数から利用可能であるか否かを判断させることで処理される。もしあるインスタンスが利用可能であれば、要求はその利用可能なインスタンスによる実行のためにディスパッチされる。もし利用可能なインスタンスがない場合には、既存のインスタンス数が所与の最大数を超えていなければ、新たなインスタンスがイニシエートされる。もし利用可能なインスタンスがなく、かつ既存のインスタンス数が所与の最大数を超えている場合には、要求が処理されなかったことを示す返答がネットワーク上に送られる。したがって、ディスパッチャプラグ−インは要求を処理するにあたって、その要求を実行のために選択的にディスパッチするか、またはインスタンスの所与の最大数に関連するインスタンスの利用可能性に基づいて要求を否認することで、サーバの資源を管理する。
したがって、この発明は制御可能な様態でサーバプロセスに複数の拡張プログラムを付加することを可能にする。ディスパッチャプラグ−インは別個の独立したインスタンスで実行される異なった拡張プログラムの実行を制御し、要求を利用可能なインスタンスに選択的に経路付けし、サーバプロセスとサーバ拡張プログラムとがオーバロードしないようにする。
この発明のさらなる目的、利点および新規な特徴は以下の説明で述べられ、当業者にはその一部が以下を検討することによって明らかとなり、またはこの発明を実施することによってこれを学ぶことができるであろう。発明の目的と利点は添付のクレームで特に指摘する手段および組合せによって実現され達成されるであろう。
【図面の簡単な説明】
この発明は添付の図面に、限定ではなく例示の目的で示され、図面を通して同じ参照番号が同様の要素を示す。
図１はこの発明の一実施例に従ったネットワークシステムにおいてクライアントから受信した要求に応答するウェブサーバのブロック図である。
図２はこの発明の第１の実施例に従ったウェブサーバのブロック図である。
図３Ａおよび３Ｂはこの発明のある実施例に従った、クライアント要求に応答するための方法をまとめたフロー図である。
図４はこの発明のある実施例に従った、サーバプロセスをイニシエートする方法を例示するフロー図である。
図５はこの発明の第２の実施例に従ったウェブ要求ブローカを例示するブロック図である。
好ましい実施例の詳細な説明
ネットワークシステムでクライアントからサーバに発行された要求に応答するための方法と装置が説明される。以下の記載では、説明の目的で、この発明を完全に理解するために多くの具体的な詳細が述べられる。しかしながら、この発明はその具体的な詳細なしでも実施できることは当業者には明らかである。この発明を不要に曖昧にすることを避けるために、別の例では周知の構造と装置がブロック図の形で示されている。
ウェブサーバアーキテクチャの概観
図１はこの発明のある実施例に従った、ネットワークシステムでクライアントから受信した要求に応答するウェブサーバの図である。ウェブサーバ１０はネットワークシステム１４、たとえばワールドワイドウェブ上でクライアント１２からの要求を送信制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）を用いて受信する。ウェブサーバ１０はウェブリスナ１６、ウェブ要求ブローカ１８および複数のサーバ拡張プログラム２０を含む。ネットワーク１４のユーザはクライアントプログラム１２を用いてウェブサーバ１０からの情報を要求し、デコードし、表示する。クライアントプログラム１２はネットワーク１４を介してウェブリスナ１６に要求を送るウェブブラウザ２２を含む。クライアントプログラムはまたウェブブラウザ２２に付加的な処理能力を与えるブラウザ拡張プログラム２４（たとえば「プラグ−イン」拡張）を含む。ウェブブラウザ２２とウェブリスナ１６との通信は標準化されたプロトコル、たとえばハイパーテキスト転送プロトコル（ＨＴＴＰ）、バージョン１．０、を用いて実行される。ＨＴＴＰ１．０プロトコルは安全ソケット層（secure sockets、ＳＳＬ）ベースのデータ暗号化とともに用いてウェブブラウザ２２とウェブリスナ１６との短期接続を確立してもよい。
以下で述べられるように、ウェブリスナ１６はネットワーク１４上でクライアント要求を受信し、その要求をウェブ要求ブローカ１８に送る。ウェブ要求ブローカ１８はその要求をサーバ拡張プログラム２０のうち１つの実行可能インスタンスに選択的にディスパッチして処理させる。ウェブリスナ１６はウェブ要求ブローカ１８からの返答を受信すると、ネットワーク１４を介してクライアント要求に対する返答を出力する。返答を受信すると、ウェブブラウザ２２は受信された要求の型を判断し、その応答をどのように扱うべきかを決定する。たとえば、応答はウェブブラウザ２２そのもので（natively）処理され得るかもしれず、またはウェブブラウザ２２がブラウザ拡張プログラム２４のうち１つを使用して更なる処理を行なうかもしれない。ブラウザ拡張プログラム２４は典型的には返答の特定の処理を行なうクライアント側プラグ−インとして実現されるであろう。処理を完了すると、クライアント１２は典型的にはその結果をウェブブラウザの主表示域に、ハイパーテキストマークアップ言語（ＨＴＭＬ）ページとして表示する。
ウェブ要求ブローカ
この発明によれば、ウェブ要求ブローカ１８は、別個のプロセスで実行されるサーバ拡張にクライアント要求を選択的に経路付けすることによって、クライアント要求の処理を管理するように構成される。
図２はこの発明の第１の実施例に従ったサーバ１０のブロック図である。ウェブリスナ１６はＨＴＴＰプロトコルに従ってネットワークトンラスポートをサポートするＨＴＴＰデイモン（daemon）１６ａを含む。ウェブリスナ１６は典型的にはユニフォームリソースロケータ（ＵＲＬ）の形で送られるクライアント要求をネットワーク１４から受信する。クライアント要求はたとえばＨＴＭＬページまたは実行されるべき動作等のウェブオブジェクトの識別子として働く。ウェブリスナ１６はクライアント要求を通訳しようとする試みをすることなく、クライアント要求をウェブ要求ブローカ１８に手渡す。
ウェブ要求ブローカ１８はディスパッチャプラグ−イン３０と複数の実行エンジン３２とを含む。ウェブ要求ブローカ１８はクライアント要求の処理を、そのクライアント要求を処理するように構成された拡張プログラム２０を特定し、クライアント要求を実行のためにその拡張プログラムの利用可能なインスタンスにディスパッチすることによって制御する。ディスパッチャプラグ−イン３０は以下で詳細に説明されるように、異なる要求を取扱うための利用可能なプログラムを特定する構成ライブラリ３４を含む。ディスパッチャプラグ−イン３０がその要求を処理するように構成されたプログラム拡張２０を特定すると、ディスパッチャプラグ−イン３０は、その要求を取扱うように構成されたプログラムの利用可能なインスタンスが利用できるか否かを判断し、以下で説明されるように、その利用可能なインスタンスによる実行のために、要求をディスパッチする。
ウェブサーバ１０はまた複数のサーバ拡張プログラム２０ａ、２０ｂおよび２０ｃを含む。各サーバ拡張プログラムはまたシステムカートリッジとも呼ばれ、それぞれ異なる動作のために構成されている。特に、サーバ拡張プログラムは能く定義された機能を実行するカートリッジとして、またはインタープリタとして作用するプログラム可能カートリッジとして、またはアプリケーションのためのルーチン環境として構成される。プログラム可能カートリッジの一例はＰＬ／ＳＱＬエージェント２０ａであって、これは構造問合せ言語を用いたオラクルベースプログラミング言語（Oracle-based Programming Language Using Structured Query Language,ＰＬ／ＳＱＬ）に従ったデータベース問合せを処理するよう構成されたものである。ＰＬ−ＳＱＬエージェント２０ａはデータベース問合せを有するクライアント要求を、個別のプロセス３６（すなわちＰＬ−ＳＱＬエージェント２０ａの別個のインスタンス）を実行することによって実行する。インスタンス３０ａを実行することで、このインスタンスが、たとえばデータリンク４２を介してインスタンス３６と通信するデータベースサーバ４０にアクセスする等の、要求を処理することとなる。
プログラム可能なカートリッジ型サーバ拡張プログラムの別の例はＪＡＶＡインタープリタ２０ｂであって、これはウェブアプリケーション開発者がサーバ側ＪＡＶＡアプリケーションを書いてクライアント要求を処理することを可能にする。同様に、カスタマサーバ２０ｃが拡張プログラムとして構成されて、たとえば第三者のサーバ４６によって実行されるプロセスにアクセスする等の動的な動作を提供することもできる。
実行可能なコードとして記憶される拡張プログラム２０ａ、２０ｂおよび２０ｃはまず対応の拡張プログラム２０のインスタンス３６をサーバメモリに対しイニシエートし、そのインスタンスを実行することで実行される。あるインスタンスとはＵＮＩＸ環境におけるプロセスと均等である。ウェブ要求ブローカ１８は拡張プログラム２０ａ、２０ｂ、２０ｃについてそれぞれインスタンス３６ａ、３６ｂ、３６ｃの予め定められた最小数をイニシエートすることによって、拡張プログラム２０の各々の実行を管理する。もしウェブ要求ブローカ１８がクライアント要求を受信し、適切な拡張プログラムのインスタンス３６がどれも利用可能でないと判断した場合には、ウェブ要求ブローカ１８は、もし既存のインスタンス数が所与の最大数を超えていない場合には、プログラムの新たなインスタンスをイニシエートして要求を実行させる。
たとえば、もしクライアント要求がデータベース４０へのアクセス要求を特定するものであれば、ウェブ要求ブローカ１８はＰＬ／ＳＱＬエージェント２０ａを、その要求を取扱うために構成されたプログラムとして特定する。ウェブ要求ブローカ１８はプログラム２０ａの既存のインスタンス３６ａがその要求を取扱うために利用可能であるか否かを判断する。もし利用可能なインスタンスがない場合、たとえば既存のインスタンス３６ａ₁−３６ａ_nのすべてが他のクライアント要求を処理中であるような場合には、ウェブ要求ブローカ１８は、もし既存のインスタンス３６ａの数が所与の最大数を超えていない場合には、新たなインスタンス３６ａ_n+1をイニシエートする。
図２に示されるように、ウェブ要求ブローカ１８は各拡張プログラム２０のためのウェブ要求ブローカ実行エンジン（ＷＲＢＸ）３２を含む。実行エンジン３２は対応のプログラムのインスタンスによって実行されるべき予め定められた動作を特定する、アプリケーションプログラミングインターフェイス（ＷＲＢＡＰＩ）を提供することによって、対応するプログラムのインスタンスの実行を制御する。実行エンジン３２と拡張プログラムとの間の基本的なコールバック機能を確立することによって、どのような拡張プログラムも、拡張プログラムがコールバック機能（たとえば初期化機能、要求ハンドラおよび遮断機能）に応答するように構成し、その後その拡張プログラムを以下で説明される構成ライブラリ３４に登録することによって、サーバ１０に統合することができる。
したがって、もしディスパッチャプラグ−イン３０が、ＰＬ／ＳＱＬエージェント２０ａが要求を処理するための適切な拡張であると判断すれば、ディスパッチャプラグ−イン３０はその要求を実行エンジン３２ａにディスパッチする。プログラム２０の新たなインスタンスをイニシエートする必要がある場合には、ディスパッチャプラグ−イン３０はそのプログラムの新たなインスタンスを別のアドレス空間に生成し、要求を新たなインスタンスの実行エンジン３２ａにディスパッチする。プログラムのインスタンスを実行するのに使用されるアドレス空間はウェブ要求ブローカが動作を行なっているコンピュータシステムのメモリ内にあってもよく、または別のコンピュータシステムにあってもよい。実行エンジン３２ａはその後要求ハンドラコールバック機能を特定されたインスタンス３６ａ_iに発行して、インスタンス３６ａ_iにその要求、たとえばデータベース４０へのアクセス、を実行させる。要求を実行したインスタンス３６ａ_iは結果を実行エンジン３２ａに返送し、これはその結果をディスパッチャプラグ−イン３０に送る。ウェブ要求ブローカ１８が動作の失敗を検出すると、実行エンジン３２ａはシャットダウン機能を発行してメモリからインスタンスをアボート（abort）する。
こうして、実行エンジン３２ａは実行されるべき予め定められた動作を特定する、ウェブ要求ブローカ１８へのアプリケーションプログラミングインターフェイス（ＷＲＢＡＰＩ）を提供する。ＷＲＢＡＰＩを使用することで、拡張プログラム２０のプログラマーはその拡張プログラムを使用するであろう特定のウェブリスナによって使用されるプロトコルとは独立して、サーバ１０への高次の統合のために各拡張プログラムを構成することができるようになる。
図３Ａおよび３Ｂはこの発明の実施例に従ったクライアント要求に応答する方法を例示したフロー図をまとめたものである。クライアント要求はステップ５０でウェブリスナ１６によって受信される。クライアント要求を受信すると、ウェブリスナ１６はその要求をステップ５２でウェブ要求ブローカ１８に送る。ディスパッチャプラグ−イン３０はステップ５４で、構成ライブラリ３４にアクセスすることによってそのクライアント要求に対応するプログラムを特定する。構成ライブラリ３４は各プログラムについて対応のプログラムによって処理される要求に対応するオブジェクトタイプを含む。たとえば、もしクライアント要求が「／ｊａｖａ」という仮想経路で始まるＵＲＬ要求である場合、構成ライブラリ３４は対応のオブジェクトを、「／ｊａｖａ」という仮想経路を有する要求を取扱うように構成されたのはＪＡＶＡインタープリタ３６ｂであることを特定して、記憶する。構成ライブラリ３４はまた、プログラム２０のインスタンスをイニシエートするのに用いられる記憶されたプログラムのためのアドレス位置を特定する仮想経路をも含む。
ディスパッチャプラグ−イン３０はステップ５６で、要求のオブジェクトタイプ（たとえばクライアント要求で特定された仮想経路）が、要求オブジェクトタイプが構成ライブラリ３４に記憶されたオブジェクトタイプに対応する、特定可能なプログラムに対応するか否かを判断する。要求オブジェクトタイプが特定可能なプログラムに対応していない場合、要求はステップ５８でウェブリスナ１６に返送される（図３Ｂを参照）。ステップ５８で、ＨＴＴＰデイモン１６ａが要求を静的ＨＴＭＬページへの要求であると認識すると、ＨＴＴＰデイモンはページメモリ１６ｂから静的ＨＴＭＬページにアクセスし、ステップ６０で返答をクライアントに送る。クライアント要求がＨＴＴＰデイモンによって認識されない場合、ステップ６０で、要求が認識不能であることを示す返答がクライアントに送られる。
ステップ５６で、ディスパッチャプラグ−イン３０は構成ライブラリ３４から、その要求を取扱うように構成された拡張プログラムを特定し、ディスパッチャプラグ−イン３０は図３Ｂに示されるステップ６２で、特定されたプログラムの利用可能なインスタンスが既存の数のインスタンス３６の中で利用可能であるか否かを判断する。ステップ６２において、もしディスパッチャプラグ−イン３０が利用可能なインスタンス、たとえばＰＬ−ＳＱＬエージェント２０ａのインスタンス３６ａ₂を特定すると、、対応の実行エンジン３２がステップ６８で呼出されて、以下で説明するように、その利用可能なインスタンスを実行して要求を処理する。しかしながら、ステップ６２で、もし特定されたプログラム２０のどのインスタンスも利用可能でない場合には、ディスパッチャプラグ−イン３０はステップ６４において、既存のインスタンス数が構成ライブラリ３４に記憶された所与の最大数を超えたか否かを判断する。ステップ６４において、もし既存のインスタンス数が所与の最大数を超えている場合いは、ディスパッチャプラグ−イン３０はステップ５８で要求をウェブリスナ１６に返送し、その後ステップ６０で、ウェブリスナは要求が処理されなかったことを示す返答をクライアントにネットワークを介して送る。
もしステップ６４において既存のインスタンス数が所与の最大数を超えていない場合には、ディスパッチャプラグ−イン３０は特定されたプログラムの新たなインスタンスをイニシエートし、その要求を新たなインスタンスの実行エンジン３２ａにディスパッチする。たとえば、ディスパッチャプラグ−イン３０はＰＬ／ＳＱＬエージェント２０ａの新たなインスタンスをイニシエートする。このステップの間、ＰＬ／ＳＱＬエージェント２０ａのための記憶された一連の命令がアクセスされて、ディスパッチャプラグ−イン３０が動作を実行しているアドレス空間とは別個のアドレス空間にプログラム２０ａの新たなインスタンス３６ａを生成する。
新しいインスタンス３６ａ_iが実行されると、ステップ６８においてディスパッチャプラグ−イン３０は新しいインスタンス３６ａ_iに関連する実行エンジン３２ａに要求をディスパッチする。実行エンジン３２ａは新しいインスタンス３６ａ_iにコールバックメッセージを送り、要求の実行を求める。実行エンジン２０はインスタンス３６ａ_iが要求を処理するのに必要なパラメータ、たとえば、パスワード、データベース検索キー、またはインスタンス３６ａ_iによって実行される動的動作のための他の引数を、コールバックメッセージで渡す。次にインスタンス３６ａ_iは要求を実行する。ステップ６８におけるインスタンスによる要求の実行の間、ディスパッチャプラグ−イン３０はステップ７０において不良が起こるかどうかを判断するためにインスタンスをモニタする。ディスパッチャプラグ−イン３０がステップ７０で不良を検出すると、ディスパッチャプラグ−イン３０はステップ７２において対応する実行エンジン３２を呼出し、不良を有するインスタンス３６をアボートさせる。対応する実行エンジン３２は、不良インスタンスに対して遮断コマンドをＡＰＩで発行する。インスタンスは実行エンジン３２による遮断コマンドに応答して他のアドレス空間における他のプロセスに影響することなく遮断される。
ステップ７０において不良が検出されなければ、ディスパッチャプラグ−イン３０はステップ７４の実行が完了するとインスタンス３６からの返答を受取る。ステップ７６においてディスパッチャプラグ−イン３０はウェブリスナ１６に返答を送り、クライアントに対して実行されたインスタンス３６からの返答を返す。インスタンス実行後、ステップ７８においてディスパッチャプラグ−イン３０はステップ７８に示されているように後続の要求を実行可能とするようインスタンスをメモリに維持する。
こうして、開示された構成は多様なユーザ要求を処理するための異なる拡張プログラムの複数のインスタンスを管理する。プログラム２０の各インスタンス３６は別のメモリ空間で実行され、プログラム２０の不良インスタンス３６がプログラムの他のインスタンスに影響することなくアボートされることを可能にする。ウェブ要求ブローカ１８は各所与の拡張プログラム２０に対するインスタンスの数をも制御する。こうして、サーバ資源は多数の要求が制御不能なインスタンスの発生によりサーバ１０を圧倒しないように制御される。実行スループットは実行可能なインスタンスの数を最小限に保つことにより向上している。さらに、１回の実行の後にインスタンスを終了せて後続の要求を実行するためにインスタンスを再作成するために拡張プログラムをメモリに再ロードするのではなく、さらなるインスタンスをイニシエートしてメモリに維持して後続の要求を実行することができる。
図４は本発明の実施例に係るサーバ１０の初期化を示す図である。サーバ１０はステップ９０のサーバプロセスを開始させることにより初期化され、ウェブリスナおよび支持プロセスはメモリ空間にロードされる。ステップ９２においてサーバ１０はディスパッチャプラグ−イン３０を開始させ、それによりウェブ要求ブローカ１８を実行するための命令のシーケンスがメモリにストアされる。拡張プログラム２０はステップ９４においてディスパッチャプラグ−イン３０で登録される。すなわち、各拡張プログラム２０に対して、（１）カートリッジ名；（２）要求されるインスタンス３６の最小の数；（３）インスタンスの最大数；（４）拡張プログラムをアクセスするためのバーチャルパス、すなわちプログラムの新しいインスタンスをイニシエートするためにアクセスするべきアドレス空間；（５）コールバック機能を実行するために実行エンジンが用いるプログラム依存機能名（初期化、要求ハンドラ、遮断）；および（６）対応する拡張プログラム２０によって動作の実行を要求するために、クライアント要求によって与えられるたとえばオブジェクトタイプのようなオブジェクト識別子が構成ライブラリ３４にストアされる。オブジェクトタイプは特定のワード、またはたとえば／ｊａｖａのようなバーチャルパスを含み得る。ステップ９４において拡張プログラム２０はサーバマネージャ、すなわちリアルタイムのユーザ対話型環境において構成ライブラリへのアクセスを有するウェブマスタによって登録できる。サーバマネージャが一旦構成ライブラリを確立すると、たとえばディスクのような不揮発性メモリをアクセスすることにより、拡張プログラムはステップ９４において自動的に登録できる。
拡張プログラムをディスパッチャプラグ−イン３０で登録した後、ステップ９６においてディスパッチャプラグ−イン３０は別のアドレス空間における各プログラムに対する最小の数のインスタンスをイニシエートする。最小の数のインスタンスがイニシエートされると、サーバ１０はクライアントの要求を処理する準備が整えられている。各実行エンジン３２はメモリの場所および対応するプログラム２０の各インスタンス３６の状態を追跡する。
図５は本発明の第２の実施例に係るサーバ１０のブロック図である。図２の第１の実施例は、ディスパッチャプラグ−イン３０はウェブリスナ１６およびＨＴＴＰデイモン１６ａの下位レベルのプロセスと互換性を有すると仮定している。図５の実施例は図２の第１の実施例の変形であり、サーバはトランスポートアダプタ１７を含む。トランスポートアダプタ１７はウェブ要求ブローカ１８と異なるプロトコルに従って動作するＨＴＴＰデイモン１６′からクライアント要求を受取る。
トランスポートアダプタ１７は異なるＨＴＴＰデイモンのプロトコルを認識するよう構成されており、ＨＴＴＰデイモン１６′から受取ったクライアント要求を、ＨＴＴＰデイモン１６′のプロトコルと独立した第２のプロトコルを有し、かつウェブ要求ブローカ１８のプロトコルと一致するクライアント要求に変換できる。こうして、トランスポートアダプタ１７はウェブ要求ブローカ１８が異なるベンダからのＨＴＴＰデイモンで使用できることを可能にする。さらに、トランスポートアダプタ１７は異なるサーバアーキテクチャおよびＯＳに対応できるよう構成できる。したがって、トランスポートアダプタ１７はＨＴＴＰデイモン１６′からのクライアント要求を第１のプロトコルからウェブ要求ブローカ１８と互換性を有する第２のプロトコルに変換する。同様に、ウェブ要求ブローカからの返答はＨＴＴＰデイモン１６′のトランスポートプロトコルに変換され、ＨＴＴＰデイモン１６′が返答をネットワークを介してユーザに送ることを可能にする。
明細書において、本発明はその具体的実施例を参照して記載されている。しかし、本発明の精神および範囲から逸脱することなく種々の変形や変更が可能であることは明らかである。したがって、明細書および図面は限定するものではなく、例示的なものであると考えられるべきである。

Claims

ネットワークシステムを介してクライアントからサーバに発行された要求に応答するための方法であって、前記方法は
ネットワークを介して前記サーバが要求を獲得するステップと、
前記サーバが、前記サーバが利用可能な複数のプログラムタイプから、要求に対応するプログラムタイプを前記サーバが決定するステップとを含み、前記複数のプログラムタイプの各プログラムタイプは、前記複数のプログラムタイプの他のプログラムタイプとは異なる機能を実現し、
要求に対応するプログラムタイプの現在実行中のインスタンスが利用可能でない場合は、前記プログラムタイプのインスタンスが現在いくつ実行されているかと、前記プログラムタイプの所定の最小および最大の数のインスタンスとの比較に基づいてプログラムタイプのインスタンスをサーバが選択的にイニシエートするステップと、
要求を前記プログラムタイプの前記インスタンスに前記サーバがディスパッチするステップと、
前記プログラムタイプの前記インスタンスが前記要求を処理するよう前記プログラムタイプの前記インスタンスを実行するステップと、
前記プログラムタイプの前記インスタンスの実行に基づいて要求に応答するステップとを含み、
前記プログラムタイプの各インスタンスは前記プログラムタイプの他のインスタンスによって用いられるアドレス空間と別のアドレス空間内で実行される、方法。
ネットワークを介して要求を獲得する前記ステップは、第１のアドレス空間で実行されるサーバプロセスによって行なわれ、
プログラムタイプのインスタンスを前記サーバが選択的にイニシエートする前記ステップは、第１のアドレス空間と別の第２のアドレス空間で前記プログラムタイプの前記インスタンスをイニシエートすることを含む、請求項１に記載の方法。
前記プログラムタイプの前記インスタンスの実行の後、後続の要求を実行するために前記プログラムタイプの前記インスタンスをメモリに維持するステップをさらに含む、請求項１に記載の方法。
実行の際に前記プログラムタイプのインスタンスにおける不良を検出するステップと、
前記不良検出に応答して前記プログラムタイプのインスタンスをアボートするステップとをさらに含む、請求項１に記載の方法。
プログラムタイプのインスタンスを前記サーバが選択的にイニシエートする前記ステップは、ネットワークを介して要求を獲得する前に、前記プログラムタイプの指定された最小の数のインスタンスをイニシエートするステップを含み、さらに
前記方法は、ネットワークを介して要求を獲得した後で、前記プログラムタイプの最小の数のインスタンスのうちの１つが前記要求を処理するために利用可能であるかを決定するステップをさらに含む、請求項１に記載の方法。
ネットワークを介して要求を獲得した後、前記プログラムタイプの最小の数のインスタンスのいずれもが前記要求を処理するのに利用可能でなく、かつ前記プログラムタイプのインスタンスの数が最大数のインスタンスより小さいのなら、プログラムタイプの新しいインスタンスをイニシエートするステップをさらに含む、請求項５に記載の方法。
前記プログラムタイプの前記インスタンスを実行する前記ステップは、前記プログラムタイプの前記最小数のインスタンスから前記プログラムタイプの利用可能なインスタンスを実行することを含む、請求項５に記載の方法。
プログラムタイプのインスタンスを前記サーバが選択的にイニシエートする前記ステップは前記プログラムタイプのインスタンスの現在の数が前記プログラムタイプに関連付けられた最大値を超えた場合、前記要求を処理せずに要求をネットワークに返却するステップを含む、請求項１に記載の方法。
複数個のプログラムタイプをサーバで登録するステップをさらに含み、前記プログラムタイプの各々の登録は、各プログラムタイプの最大数のインスタンスおよび前記プログラムタイプのバーチャルパスを指定することを含む、請求項１に記載の方法。
要求はバーチャルパスを特定し、さらに
要求に対応するプログラムタイプを決定する前記ステップは、要求で特定されたバーチャルパスに基づいてプログラムタイプを決定するステップを含む、請求項９に記載の方法。
ネットワークを介して前記サーバが要求を獲得する前記ステップは、第１のプロトコルに従って動作するトランスポートプロトコルプロセスから前記サーバが要求を受取ることを含み、さらに
前記方法は要求を第１のプロトコルと独立した第２のプロトコルに変換するステップをさらに含む、請求項１に記載の方法。
サーバによって実行するための、動作を行なう要求に応答するための方法であって、前記方法は
ネットワークを介して前記サーバが要求を獲得するステップと、
サーバによって実行されるディスパッチャに前記サーバが要求を送るステップと、
Ａ）前記サーバが利用可能な複数のプログラムタイプから、要求を扱うよう構成されたプログラムタイプを決定するステップを、ディスパッチャに行なわせ、前記複数のプログラムタイプの各プログラムタイプは、前記複数のプログラムタイプの他のプログラムタイプとは異なる機能を実現し、
Ｂ）要求を扱うよう構成された特定のプログラムタイプの利用可能なインスタンスが前記特定のプログラムタイプの既存の数のインスタンスのうちで利用可能であるかどうかを決定するステップ、
Ｃ）前記特定のプログラムタイプの利用可能なインスタンスがあるのなら、実行のための要求を利用可能なインスタンスによってディスパッチするステップ、
Ｄ）前記特定のプログラムタイプの利用可能なインスタンスがないなら、既存の数のインスタンスが前記特定のプログラムタイプに対する最大の所定数を超えなければ要求の実行のために前記特定のプログラムの新しいインスタンスをイニシエートするステップ、さらに
Ｅ）前記特定のプログラムタイプの利用可能なインスタンスがなくかつ前記特定のプログラムタイプの既存の数のインスタンスが前記特定のプログラムタイプに対する最大の所定数を超えるのなら、要求が処理されなかったことを示して前記返答をネットワークを介して送るステップを、ディスパッチャに行なわせることにより要求を処理するステップとを含み、
前記特定のプログラムタイプの各インスタンスは前記特定のプログラムタイプの他のインスタンスによって使用されるアドレス空間と別のアドレス空間内で実行される、方法。
ディスパッチャによって、前記特定のプログラムタイプの要求を実行するインスタンスから返答を受取るステップと、
返答に含まれる情報をディスパッチャからネットワークを介して要求を発行したクライアントに送るステップとをさらに含む、請求項１２に記載の方法。
前記特定のプログラムタイプの要求を実行しているインスタンスの不良をディスパッチャによって検出するステップと、
前記特定のプログラムタイプの検出された不良に応答して要求を実行しているインスタンスをディスパッチャによって終了させるステップをさらに含む、請求項１２に記載の方法。
要求が処理されていないことを示す返答をネットワークを介して送るステップをさらに含む、請求項１４に記載の方法。
それぞれの種類の要求を扱うよう構成された前記複数個のプログラムタイプをディスパッチャで登録するステップをさらに含み、前記複数個のプログラムタイプをディスパッチャで登録する前記ステップは、前記プログラムタイプの各々に対して、最大数のインスタンスおよび対応するプログラムタイプに関連するアドレス場所を指定するバーチャルパスをディスパッチャにストアするステップを含む、請求項１２に記載の方法。
前記特定のプログラムタイプの新しいインスタンスをイニシエートする前記ステップは、前記特定のプログラムタイプの他のインスタンスによって使用されるアドレス空間と別のアドレス空間内で前記特定のプログラムタイプの新しいインスタンスをイニシエートするステップを含む、請求項１２に記載の方法。
後続の要求を処理するために、要求を処理した後前記新しいインスタンスの割当解除を少なくとも所定の期間遅らせるステップと、前記所定の期間の後に到着した連続する要求がない場合、自動的に、前記新しいインスタンスを割当解除するステップとをさらに含む、請求項１７に記載の方法。
ネットワークを介して要求を獲得する前記ステップは、第１のプロトコルに従って動作するトランスポートプロトコルプロセスから要求を受取ることを含み、前記第１のプロトコルは、複数のプロトコルのうちの一つであり、
前記方法は、複数の前記第１のプロトコルのうちのいずれかに従って受け取られた要求を第２のプロトコルに変換するように構成されたトランスポートアダプタにより、要求を第１のプロトコルと独立した第２のプロトコルに変換するステップをさらに含む、請求項１２に記載の方法。
前記特定のプログラムタイプの前記インスタンスの既存数は少なくとも前記特定のプログラムタイプの前記インスタンスの所定の最小数である、請求項１２に記載の方法。
要求に指定された動作に基づきプログラムタイプが要求を扱うよう構成されているかをディスパッチャに決定させるステップと、
要求を取扱うよう構成されているプログラムタイプがなければ、要求が処理されなかったことを示す返答をネットワークを介して送るステップをさらに含む、請求項１２に記載の方法。
ネットワークを介して要求を前記サーバが獲得する前記ステップは、サーバによってサーバプロセスを実行するステップを含み、さらに
ディスパッチャに前記ステップを行なわせることにより要求を処理する前記ステップは、サーバプロセスに追加されるプラグ−インルーチンをサーバによって実行させて、ディスパッチャに前記ステップを行なわせるステップを含む、請求項１２に記載の方法。
サーバによって受取られた動作を行なう要求に応答するために命令のシーケンスがストアされているコンピュータ読取可能媒体であって、命令のシーケンスは、
ネットワークを介して要求を獲得するステップ、
複数のプログラムタイプから、要求に対応するプログラムタイプを決定するステップを行なうための命令を含み、前記複数のプログラムタイプの各プログラムタイプは、前記複数のプログラムタイプの他のプログラムタイプとは異なる機能を実現し、
プログラムタイプの現在実行中のインスタンスがない場合は、前記プログラムタイプのインスタンスが現在いくつ実行されているかと、所定の最小および最大の数のインスタンスとの比較に基づいて、プログラムタイプのインスタンスを前記サーバが選択的にイニシエートするステップ、
要求を前記プログラムタイプの前記インスタンスにディスパッチするステップと、
前記プログラムタイプの前記インスタンスに前記要求を処理させるために前記プログラムタイプの前記インスタンスを実行するステップと、
前記プログラムタイプの前記インスタンスの実行に基づいて要求に応答するステップとを行なうための命令を含み、
前記プログラムタイプの各インスタンスは前記プログラムタイプの他のインスタンスによって使用されるアドレス空間と別のアドレス空間内で実行される、コンピュータ読取可能媒体。
実行の際に前記プログラムタイプのインスタンスの不良を検出するステップと、
前記不良検出に応答して前記プログラムタイプのインスタンスをアボートさせるステップとを行なうための命令シーケンスをさらに含む、請求項２３に記載のコンピュータ読取可能媒体。
動作を行なう要求に応答するよう構成されているコンピュータサーバであって、
ネットワークを介して要求を受取りかつ要求の応答をネットワークを介して送るよう構成されたネットワークリスナを含み、要求は行なうべき動作を指定する所定のオブジェクトタイプを有し、
複数個のプログラムタイプを含み、各プログラムタイプはプログラムタイプによって行なわれる動作を指定する対応するオブジェクトタイプを有する要求の受取に応答して出力を生成する動作を行なうよう構成されており、各プログラムタイプはそれぞれの別のアドレス空間で実行される所定数のインスタンスを有し、さらに
所定のオブジェクトタイプに基づいて、要求に応答するために、プログラムタイプの１つを決定するよう構成されているディスパッチャプラグ−インを含み、ディスパッチャプラグ−インは対応する所定数のインスタンスに基づいて要求を特定された１つのプログラムタイプの利用可能なインスタンスに選択的にディスパッチし、ディスパッチャプラグ−インは利用可能なインスタンスによる要求の実行に基づいて前記応答をネットワークリスナへ送る、サーバ。
ネットワークリスナはハイパーテキストトランスファープロトコル（ＨＴＴＰ）に基づいて要求および応答を受取りおよび送る、請求項２５に記載のサーバ。
ネットワークリスナは、静的ハイパーテキストマークアップ言語（ＨＴＭＬ）ページの発送を指定する所定のオブジェクトタイプに応答して前記静的ＨＴＭＬページを出力するよう構成されているＨＴＴＰデイモンを含む、請求項２５に記載のサーバ。
ネットワークリスナから受取られた要求を第１のプロトコルから第１のプロトコルと独立した第２のプロトコルに変換するよう構成されているトランスポートアダプタをさらに含む、請求項２５に記載のサーバ。
複数個の実行エンジンをさらに含み、各実行エンジンは対応するプログラムタイプのインスタンスの実行を制御しかつ対応するプログラムタイプのインスタンスによって行なわれるべき所定の動作を指定するアプリケーションプログラミングインターフェイス（ＡＰＩ）を与えるよう構成されており、実行エンジンはディスパッチャプラグ−インから要求を受取る特定された１つのプログラムに対応し、要求を処理する利用可能なインスタンスの実行を制御する、請求項２５に記載のサーバ。
ＡＰＩによって指定された所定の動作は、対応するプログラムの少なくとも１つのインスタンスによる、初期化、要求の実行、および遮断の少なくとも１つを含む、請求項２９に記載のサーバ。
各実行エンジンは、対応するプログラムタイプの所定の最小数の前記インスタンスをイニシエートする、請求項２５に記載のサーバ。
ディスパッチャプラグ−インは、各プログラムタイプに対して対応するオブジェクトタイプおよび所定の数のインスタンスを決定する構成ライブラリを含む、請求項２５に記載のサーバ。
要求のオブジェクトタイプは特定された１つのプログラムタイプを指定するバーチャルパスを含む、請求項２５に記載のサーバ。