JP3853593B2 - ウェブアプリケーションサーバにおいて拡張可能な認証機構を実現するための方法および装置 - Google Patents
ウェブアプリケーションサーバにおいて拡張可能な認証機構を実現するための方法および装置 Download PDFInfo
- Publication number
- JP3853593B2 JP3853593B2 JP2000519525A JP2000519525A JP3853593B2 JP 3853593 B2 JP3853593 B2 JP 3853593B2 JP 2000519525 A JP2000519525 A JP 2000519525A JP 2000519525 A JP2000519525 A JP 2000519525A JP 3853593 B2 JP3853593 B2 JP 3853593B2
- Authority
- JP
- Japan
- Prior art keywords
- authentication
- cartridge
- dispatcher
- message
- request
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/33—User authentication using certificates
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
Description
【０００１】
【発明の分野】
本発明は、ネットワーク接続されたコンピュータシステムにおけるクライアントのオペレーションの認証に関し、より特定的には、ステートレスなウェブ環境におけるブラウザのリクエストの認証に関する。
【０００２】
【発明の背景】
ワールド・ワイド・ウェブ（World Wide Web）はインターネット（Internet）上のサーバのネットワークを含み、その各々は１つ以上のＨＴＭＬ（Hypertext Markup Language：ハイパテキスト・マークアップ言語）ページに関連付けられている。サーバに関連付けられているＨＴＭＬページは、情報と、そのサーバおよび（通常は）他のサーバ上の他の文書へのハイパテキストリンクとを提供する。サーバはハイパテキスト・トランスファー・プロトコル（ＨＴＴＰ：Hypertext Transfer Protocol）を用いてクライアントと通信する。サーバはクライアントからのＨＴＭＬページに関するリクエストを聞くことから、多くの場合、「リスナ」と称される。
【０００３】
ワールド・ワイド・ウェブのユーザはブラウザと呼ばれるクライアントプログラムを用いてリスナから情報をリクエストし、デコードし、表示する。ブラウザのユーザがあるＨＴＭＬページ上のリンクを選択すると、そのページを表示しているブラウザはそのリンク内で特定されるユニバーサル・リソース・ロケータ（ＵＲＬ：Universal Resource Locator）と関連付けられるリスナにインターネットを通じてリクエストを送る。そのリクエストに応答して、リスナはそのリクエストを発行したブラウザにリクエストされた情報を送信する。ブラウザは情報を受取り、受取った情報をユーザに示し、次のユーザリクエストを待つ。
【０００４】
従来、リスナに蔵置される情報は静的ＨＴＭＬページの形態である。静的ＨＴＭＬページは、ウェブブラウザからのリクエストに先立ち作成されリスナに蔵置される。リクエストに応答して、静的ＨＴＭＬページが単に記憶から読出され、リクエストを行なっているブラウザに送信される。現在、ブラウザリクエストに応答して動的オペレーションを行なうリスナを開発しようとする趨勢にある。たとえば、リスナはリクエストに応答する際にデータベースにクエリーを発行し、そのクエリーの結果を含むウェブページを動的に構成し、動的に構成されたＨＴＭＬページをリクエストを行なっているブラウザに送信してもよい。動的オペレーションを行なうために、リスナの機能性を向上または増強させなければならない。動的オペレーションをサポートするようリスナを拡張するためにさまざまなアプローチが開発されてきた。
【０００５】
インターネット上のサーバには複数のクライアントがアクセスすることができるので、ある情報に対する無許可のアクセスに対して保護がなされるように、いくつかの保護方式が開発されてきている。ある情報に対する無許可のアクセスを阻止するのに使用される方法の１つは、クライアントが特定のサーバ上の情報に対してアクセスしようとする場合、アクセスを許可する前に、そのクライアントに対して何らかの許可情報を提供するように求める方法である。この許可情報は典型的に、ユーザ名およびパスワード、特定のＩＰアドレス、特定のドメイン名または、情報にアクセスを試みている特定のユーザおよび／またはマシンを識別することのできる他の情報、等の項目を含む。
【０００６】
許可機構を実現するための１つの方法として、認証プロセスを各サーバに関連付ける方法がある。許可のプロセスが、クライアントのリクエストを代行受信して、そのクライアントがそのサーバに関連付けられた情報に対してアクセスできるかどうかを判定する。したがって、クライアントが特定のサーバ上の情報に対してアクセスを試みるたびに、そのサーバに関連付けられた認証のプロセスがまず、そのクライアントがその情報へのアクセスを許可されていることを検証する。
【０００７】
このサーバ単位で認証プロセスを行なう方法は、サーバに関連付けられたＨＴＭＬページが保護されるべき項目である場合にはうまく機能する。しかし、サーバを使用して、そのサーバ以外のマシン上で実行されている可能性のあるコンピュータプログラムにアクセスしてそのプログラムを実行するようなシステムにおいては、この方法では必要とされる柔軟性を提供することができない場合がある。たとえば、バンキングアプリケーションとデータベースアプリケーションとの両方が特定のサーバを介してブラウザによってアクセス可能であるものとする。この場合、バンキングアプリケーションには、データベースアプリケーションとは全く異なる認証機構が必要であるかもしれないし、他のサーバの使用に対してはどのような認証も全く必要でないかもしれない。
【０００８】
以上のことから、ＨＴＴＰサーバを介して利用可能なリソースに対するアクセスを限定する、認証機構を提供することが明らかに望ましい。また、同じＨＴＴＰサーバを介してアクセスすることのできる複数のアプリケーションに対して、異なる認証プロトコルをサポートすることができるほど十分に柔軟性のある、認証機構を提供することが望ましい。
本発明の背景および本発明の実施例によって解決される問題のさらなる詳細は、 Nigel Edwards および Owen Rees による文献、「セキュリティに優れたウェブサーバおよびゲートウェイ（ "High security Web servers and gateways") 」、 COMPUTER NETWORKS AND ISDN SYSTEMS, 29, (1997) 927-938 、に記載されている。
【０００９】
【発明の概要】
本発明は、クライアントからのリクエストを認証するための、スケーラブルな、柔軟性のある、拡張可能な機構を提供する。好ましい実施例においては、本発明は、認証エンジン、認証ホスト、およびホストに連結された複数のプロバイダを含み、各プロバイダは選択された認証方式を実現する。好ましい実施例においては、プロバイダの各々は、ダイナミックリンクライブラリ（ＤＬＬ）等のような、ランタイムに動的にリンク・インすることのできる、モジュールの形をとる。
【００１０】
本発明は、好ましくは、種々の構成要素がマシンの境界を超えて互いに通信することができるようにする、マシンとは独立した通信機構をさらに含む。この通信機構によって、本発明の種々の構成要素は、各構成要素がどのマシン上に備えられているかにかかわらず、互いに通信することができる。好ましい実施例においては、通信機構はオブジェクトリクエストブローカの形をとる。種々の構成要素を異なるマシン上に設けることができるので、本発明は分散型であると言える。この分散型の性質により、本発明は非常にスケーラブルなものとなっている。
【００１１】
オブジェクトリクエストブローカは、通信機構として機能するのに加えて、好ましくは、負荷の最適配分機能もまた行なう。より特定的には、このブローカは、認証エンジンおよび認証ホストへのリクエストの送信を、ボトルネックの可能性を最小限にし、かつ利用可能なリソースの使用を最大限にするよう、調整する。この機能を行なうのに、ブローカは、各プロバイダがシステム内に導入されるときにそのプロバイダに対して登録される、メタデータを利用する。
【００１２】
動作中、認証エンジンは、プロテクトストリングと関連付けられているリクエストを受取る。プロテクトストリングは、とりわけ、そのリクエストに対して実現されるべき１以上の認証方式、および、その方式の結果に適用されるべき１以上の論理演算子（たとえばＡＮＤ、ＯＲ）を特定する。リクエストを受取ると、認証エンジンは、プロテクトストリングを解析して１または複数のプロバイダのリクエストとし、それらのリクエストをオブジェクトリクエストブローカを介して認証ホストに送信する。これに応じて、ホストは、それらのリクエストを適切なプロバイダへと送り、そこでリクエストの処理が行なわれる。プロバイダは処理を完了すると、その結果を認証ホストおよびオブジェクトリクエストブローカを介して認証エンジンへと戻す。その後、認証エンジンが、プロテクトストリングにおいて特定された論理演算子に従って結果を処理して、そのリクエストが認証されたかどうかを判定する。
【００１３】
本発明によれば、システムの実装を配置時に変更することができる。前述のように、各プロバイダは好ましくは、ランタイムにシステムにリンク・インすることのできるＤＬＬの形をとる。プロバイダがランタイムにリンク・インされるので、配置時に（１）あるプロバイダを別のプロバイダと置換したり（２）別のプロバイダをシステムに付加したりすることができる。本発明のアーキテクチャは、これらすべてを、他のどのモジュール（たとえば認証エンジンおよび認証ホスト）も変更したり再コンパイルしたりすることなく、行なうことができるようにしている。プロバイダの置換／付加に必要なのは、プロバイダのその置換／付加を反映するようメタデータを更新することのみである。さらに、特定のクエリーに関連付けられた認証方式を変更することも可能である。これは単に、そのクエリーに関連付けられたプロテクトストリングを変更することによって行なうことができる。やはり再コンパイルは不要である。これらの局面のおかげで、本発明においては、コンパイル時ではなく配置時に実装を変更することができる。これにより、本発明は非常に柔軟かつ拡張可能となっている。
【００１４】
これらおよび他の利点は、本発明がさらに詳細に説明されるにつれて明らかとなるであろう。
【００１５】
本発明は、限定のためではなく例示する目的で、添付の図面に示される。添付の図面において類似の参照番号は類似の要素を指す。
【００１６】
【好ましい実施例の詳細な説明】
ステートレスなウェブ環境においてブラウザのリクエストを認証するための方法および装置を説明する。以下において説明のため、この発明の完全な理解をもたらすように数多くの特定の詳細事項を挙げている。しかしながら、当業者にはこの発明がこれらの特定の詳細事項がなくても実施できることが明らかになるであろう。場合によっては不必要にこの発明を曖昧にすることを避けるため周知の構造および装置をブロック図の形態で示している。
【００１７】
ハードウェアの概観
図１は、この発明の実施例が実装され得るコンピュータシステム１００を示すブロック図である。コンピュータシステム１００は、バス１０２または情報を通信するための他の通信機構と、バス１０２に結合され情報を処理するためのプロセッサ１０４とを含む。コンピュータシステム１００はまた、バス１０２に結合され情報およびプロセッサ１０４が実行すべき命令を蔵置するための、ランダムアクセスメモリ（ＲＡＭ）または他の動的記憶装置などのメインメモリ１０６を含む。メインメモリ１０６はまた、プロセッサ１０４が実行すべき命令の実行の間に一時変数または他の中間情報を蔵置するのに用いられてもよい。コンピュータシステム１００はさらに、バス１０２に結合され静的情報およびプロセッサ１０４に対する命令を蔵置するための読取専用メモリ（ＲＯＭ）１０８または他の静的記憶装置を含む。磁気ディスクまたは光ディスクなどの記憶装置１１０が設けられ、バス１０２に結合されて情報および命令を蔵置する。
【００１８】
コンピュータシステム１００はバス１０２を介して、陰極線管（ＣＲＴ）などの表示装置１１２に結合されコンピュータユーザに対して情報を表示してもよい。英数字および他のキーを含む入力装置１１４がバス１０２に結合され、情報およびコマンド選択をプロセッサ１０４に伝える。別のタイプのユーザ入力装置は、プロセッサ１０４に方向情報およびコマンド選択を伝え、かつ表示装置１１２上のカーソル移動を制御するためのマウス、トラックボールまたはカーソル方向キーなどのカーソル制御装置１１６である。この入力装置は典型的に２つの軸、すなわち第１の軸（たとえばｘ）および第２の軸（たとえばｙ）において２つの自由度を有し、これは装置が平面上の位置を特定できるようにする。
【００１９】
この発明は、コンピュータシステム１００を用いて、ステートレスなウェブ環境においてブラウザの要求を認証することに関する。この発明の一実施例によれば、ブラウザの要求の認証は、プロセッサ１０４がメインメモリ１０６に含まれる１つ以上の命令の１つ以上のシーケンスを実行することに応答して、コンピュータシステム１００によって行なわれる。このような命令は、記憶装置１１０などの別のコンピュータ可読媒体からメインメモリ１０６に読込んでもよい。メインメモリ１０６に含まれる命令のシーケンスを実行することにより、プロセッサ１０４がここに説明するプロセスステップを実行することとなる。代替の実施例では、ソフトウェア命令の代わりに、またはソフトウェア命令と併せて結線回路を用いてこの発明を実現してもよい。すなわち、この発明の実施例はハードウェア回路およびソフトウェアの如何なる特定の組合せにも限定されない。
【００２０】
「コンピュータ可読媒体」という用語はここでは、実行のためにプロセッサ１０４に命令を提供するのにかかわるすべての媒体を指して用いる。このような媒体は、不揮発性媒体、揮発性媒体および伝送媒体を含むが、これらに限定されない数多くの形態を取り得る。不揮発性媒体には、たとえば、記憶装置１１０などの光ディスクまたは磁気ディスクが含まれる。揮発性媒体には、メインメモリ１０６などのダイナミックメモリが含まれる。伝送媒体には、バス１０２を構成するワイヤを含む、同軸ケーブル、導線および光ファイバが含まれる。伝送媒体はまた、電波および赤外線データ通信において生成されるもののような音波または光波の形態を取ることもある。
【００２１】
コンピュータ可読媒体の一般的な形態にはたとえば、フロッピーディスク、フレキシブルディスク、ハードディスク、磁気テープまたは何らかの他の磁気媒体、ＣＤ−ＲＯＭおよび何らかの他の光媒体、パンチカード、せん孔テープおよび孔のパターンを有する何らかの他の物理的媒体、ＲＡＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＦＬＡＳＨ−ＥＰＲＯＭおよび何らかの他のメモリチップまたはカートリッジ、以下に説明するような搬送波、またはコンピュータが読むことのできるものであればどのような他の媒体でも含まれる。
【００２２】
実行のために１つ以上の命令の１つ以上のシーケンスをプロセッサ１０４に与える上でさまざまな形態のコンピュータ可読媒体がかかわり得る。たとえば、命令は初めに遠隔コンピュータの磁気ディスク上に担持されてもよい。遠隔コンピュータは命令をそのダイナミックメモリにロードし、その命令をモデムを用いて電話回線を介して送ることができる。コンピュータシステム１００がローカルに有するモデムが電話回線上でデータを受取り、赤外線送信機を用いてそのデータを赤外線信号に変換できる。バス１０２に結合される赤外線検出器は赤外線信号で運ばれるデータを受取り、そのデータをバス１０２上に出力することができる。バス１０２はそのデータをメインメモリ１０６へ運び、そこからプロセッサ１０４は命令を取出して実行する。メインメモリ１０６が受取った命令は場合により、プロセッサ１０４による実行の前または後に記憶装置１１０に蔵置されてもよい。
【００２３】
コンピュータシステム１００はまた、バス１０２に結合される通信インターフェイス１１８を含む。通信インターフェイス１１８はローカルネットワーク１２２に接続されるネットワークリンク１２０への両方向データ通信結合を提供する。たとえば、通信インターフェイス１１８は、対応するタイプの電話回線に対してデータ通信接続を提供するサービス統合デジタル網（ＩＳＤＮ）カードまたはモデムであってもよい。別の例としては、通信インターフェイス１１８は、互換性のあるローカル・エリア・ネットワーク（ＬＡＮ）に対するデータ通信接続を提供するローカル・エリア・ネットワーク（ＬＡＮ）カードであってもよい。また、無線リンクを実現してもよい。このような実現例のいずれにおいても、通信インターフェイス１１８はさまざまなタイプの情報を表わすデジタルデータストリームを運ぶ電気信号、電磁気信号または光信号を送受信する。
【００２４】
ネットワークリンク１２０は典型的に１つ以上のネットワークを介して他のデータ装置へのデータ通信を提供する。たとえば、ネットワークリンク１２０はローカルネットワーク１２２を介してホストコンピュータ１２４または、インターネットサービスプロバイダ（ＩＳＰ：Internet Service Provider）１２６により運用されるデータ装置に対する接続を提供してもよい。ＩＳＰ１２６はこれを受けて、現在一般的に「インターネット」１２８と称される世界規模のパケットデータ通信網を介するデータ通信サービスを提供する。ローカルネットワーク１２２およびインターネット１２８はともに、デジタルデータストリームを運ぶ電気信号、電磁気信号または光信号を用いる。コンピュータシステム１００へまたはコンピュータシステム１００からデジタルデータを運ぶ、さまざまなネットワークを介する信号およびネットワークリンク１２０上の、通信インターネット１１８を介する信号は情報を運ぶ搬送波の典型的な形態である。
【００２５】
コンピュータシステム１００はネットワーク、ネットワークリンク１２０および通信インターネット１１８を介して、メッセージを送り、プログラムコードを含むデータを受取ることができる。インターネットの例では、サーバ１３０はインターネット１２８、ＩＳＰ１２６、ローカルネットワーク１２２および通信インターネット１１８を介してアプリケーションプログラムに対するリクエストされたコードを送信するかもしれない。
【００２６】
受取られたコードはそれが受取られると同時にプロセッサ１０４によって実行され、および／または後に実行するために記憶装置１１０または他の不揮発性記憶に蔵置されてもよい。このように、コンピュータシステム１００は搬送波の形態でアプリケーションコードを得ることもある。
【００２７】
アプリケーションサーバ機能の概要
図２は、この発明の一実施例に従って設計されたシステム２００のブロック図である。システム２００は、ＨＴＴＰプロトコルに従ってインターネット２０８にわたって複数のリスナ２１０、２１６および２２２と通信する複数のブラウザ２０２、２０４および２０６を含む。ブラウザからのリクエストに応答して、リスナはウェブアプリケーションサーバ２８０にここでカートリッジと称するソフトウェアモジュールを呼出させる。例示の実施例では、ウェブアプリケーションサーバ２８０は３つのカートリッジ２３０、２３４および２３８の実行を開始している。
【００２８】
ウェブアプリケーションサーバ２８０は、トランスポート・アダプタ２１２、２１８および２２４、ディスパッチャ２１４、２２０および２２６、認証サーバ２５２、仮想パスマネージャ２５０、リソースマネージャ２５４、コンフィギュレーションプロバイダ２５６および複数のカートリッジ実行エンジン２２８、２３２および２３６を含む、数多くの構成要素からなる。ウェブアプリケーションサーバ２８０のさまざまな構成要素について以下により詳しく説明する。
【００２９】
重要なことであるが、ウェブアプリケーションサーバ２８０の数多くの構成要素はオブジェクトリクエストブローカ（Object Request Broker）２８２などのマシン間通信機構を介して通信する。マシン間通信機構を用いることにより、ブラウザリクエストにおいて特定されるオペレーションを実行するカートリッジインスタンスは、リクエストを受取るリスナおよびリクエストを発行するブラウザとは異なるマシン上で実行することができる。カートリッジ・インスタンスがリスナとは異なるマシン上にあるため、リスナは障害のあるカートリッジ・インスタンスからよりよく隔離されることとなり、システムの信頼性および安全性が向上する。さらに、リスナが実行されるマシンと同じマシンでなく、数多くのマシン間でカートリッジインスタンスを実行する処理の負担を分散することによってシステムのスケーラビリティが大幅に増加する。複数のマシンにわたってカートリッジ・インスタンスの実行を分散できることから、いつどこで新しいカートリッジ・インスタンスを生じさせるかを決定するのに数多くのタイプの負荷の最適配分の技法を用いることができる。
【００３０】
システム２００内の典型的なオペレーションには一般的に以下の段階が含まれる。
ブラウザがインターネット２０８にわたってリクエストを送信する。
【００３１】
リスナがそのリクエストを受取ってトランスポートアダプタを介してディスパッチャに渡す。
【００３２】
ディスパッチャは、仮想パスマネージャ２５０と通信して、ブラウザのリクエストによって選択されたカートリッジを識別し、かつ、そのカートリッジが認証を必要としているかどうかを判定する。
【００３３】
カートリッジが認証を必要としていれば、ディスパッチャは認証サーバ２５２と通信して、そのブラウザがその選択されたカートリッジにアクセスすることを許可されているかどうかを判定する。
【００３４】
認証サーバ２５２が、そのブラウザがその選択されたカートリッジに対してアクセスすることを許可されていないと判定した場合には、そのブラウザにはアクセスが拒絶されたことが通知される。
【００３５】
しかし、アクセスが許可されているか、または、仮想パスマネージャ２５０が認証が不要であると判定した場合には、ディスパッチャは２つのうち一つを行なう。ディスパッチャがそのカートリッジに関する使用されていないインスタンスのことを知っている場合、ディスパッチャはそのインスタンスにリクエストを送る。そのカートリッジに関して使用されていないカートリッジインスタンスがない場合、ディスパッチャはリソースマネージャ２５４に新しいカートリッジインスタンスを作るよう依頼する。そのインスタンスがうまく起動した後に、カートリッジはその存在をリソースマネージャに知らせる。リソースマネージャ２５４はそこで、ディスパッチャに新しいインスタンスのことを知らせる。ディスパッチャはブラウザリクエストに基づいて変更されたリクエストを作り、その変更されたリクエストを新しいインスタンスに送る。
【００３６】
カートリッジインスタンスはその変更されたリクエストを処理して、ディスパッチャに応答を送る。
【００３７】
ディスパッチャはその応答をリスナを介してクライアントに戻す。
これらの段階について以下により詳しく説明する。
【００３８】
カートリッジ
カートリッジは特定のアプリケーションまたはシステム機能を行なうためのコードのモジュールである。カートリッジはシステム２００における分散の基本単位を形成する。この発明の一実施例によれば、カートリッジはユニバーサル・リソース・ロケータ（ＵＲＬ）を用いて名付けられる。すなわち、カートリッジ名（すなわちＵＲＬ）には２つの部分、すなわちカートリッジが存在するサーバのＩＰアドレスと、コンパイルされたカートリッジコードのサーバディレクトリ構造における仮想パスとがある。カートリッジはＵＲＬを用いて名付けられるため、カートリッジ名空間はグローバルであり、文書などの他のウェブリソースにアクセスするのに用いられるのと同じメッセージ通信技術を用いてカートリッジにアクセスすることができる。
【００３９】
この発明の一実施例によれば、各カートリッジはすべてのカートリッジに対して共通の全体構造をもたらす標準インターフェイスを有する。この標準インターフェイスは、特定の条件の下でウェブアプリケーションサーバ２８０により呼出されるルーチンのインターフェイスを規定する。この発明の一実施例によれば、抽象カートリッジインターフェイスは以下のとおりである。
【００４０】
【表１】
【００４１】
init()ルーチンはカートリッジインスタンスを初期化する役割を果たす。このことには、いくつかのサブオブジェクトのコンストラクタを呼出すことと、スレッドを予め分岐させることと、他のすべての必要となる共用リソースを獲得することとが含まれ得る。
【００４２】
shutdown()ルーチンはすべてのリソースを片付けカートリッジインスタンスをシャットダウンする役割を果たす。カートリッジインスタンスに対して一度shutdown()ルーチンが呼出されると、直ちにカートリッジインスタンスは後続のリクエストを処理するのに利用不可能となる。
【００４３】
authenticate()ルーチンではカートリッジのサービスをリクエストしているクライアントがそのサービスを用いることを許可されているかどうかを検証する。
【００４４】
exec()ルーチンはカートリッジに対してすべてのサービスリクエストをディスパッチする包括的なやり方である。
【００４５】
例示的カートリッジ
各カートリッジは、明確に定義された機能を行なうカートリッジとして構成されるか、またはあるアプリケーションのためのインタプリタまたはルーチン環境として作用するプログラム可能なカートリッジとして構成される。プログラム可能なカートリッジの一例はＰＬ／ＳＱＬランタイムであり、これは構造的問合せ言語（Structured Query Language）を用いるオラクルベースのプログラム言語（Oracle-based Programming Language）（ＰＬ／ＳＱＬ）に従ってデータベースクエリーを処理するよう構成される。ＰＬ／ＳＱＬランタイムはデータベースクエリーを有するブラウザリクエストを実行する。ＰＬ／ＳＱＬランタイムは、たとえば、データリンクを介してカートリッジインスタンスと通信しているデータベースサーバにアクセスすることによってリクエストを処理する。
【００４６】
プログラム可能なカートリッジの別の例はＪＡＶＡランタイムインタプリタである。ＪＡＶＡランタイムインタプリタカートリッジのおかげで、ウェブアプリケーション開発者らはブラウザリクエストを処理するためのサーバ側のＪＡＶＡアプリケーションを書くことができる。同様に、たとえば第三者のサーバによって実行されるプロセスにアクセスするなどの動的オペレーションをもたらすために、カスタムサーバをカートリッジとして構成してもよい。
【００４７】
ディスパッチャ
ディスパッチャは、リスナが受取ったリクエストを適当なカートリッジへ経路選択するよう構成されるソフトウェアモジュールである。この発明の一実施例によれば、ディスパッチャはサーバ側のプログラム拡張（すなわち、「プラグイン」）として実現される。そのため、ディスパッチャはそれらが属するリスナと同じアドレス空間にロードされそこで実行される。ディスパッチャはコンパイル時にリスナコードとリンクされてもよいし、実行時に動的にロードされてもよい。
【００４８】
例示される実施例では、ディスパッチャ２１４、２２０および２２６はそれぞれ、リスナ２１０、２１６および２２２に関連付けられる。ディスパッチャ２１４、２２０および２２６は、リスナ２１０、２１６および２２２が受取ったブラウザリクエストをカートリッジへ選択的に経路制御する。
【００４９】
たとえば、リスナ２１０がユニフォーム・リソース・ロケータ（ＵＲＬ：Uniform Resource Locator）の形態で運ばれるブラウザリクエストをインターネット２０８から受取ると仮定する。このブラウザリクエストは、たとえばＨＴＭＬページまたは実行すべきオペレーションであるウェブオブジェクトに対する識別子の役割を果たす。リスナ２１０はそのブラウザリクエストの解釈を全く試みることなくディスパッチャ２１４に受渡す。ブラウザリクエストを受取ると、ディスパッチャ２１４は、
（１） 仮想パスマネージャ２５０と通信してブラウザリクエストによって選択されるカートリッジを識別し、かつそのカートリッジが認証を要するかどうかを判定し、
（２） そのカートリッジが認証を必要とする場合、認証サーバ２５２と通信してブラウザがその選択されたカートリッジにアクセスすることが許されるかどうかを判定し、
（３） アクセスが許可された場合に、リソースマネージャと通信してブラウザリクエストを送るべき選択されたカートリッジの特定のインスタンスを定め、
（４） カートリッジの特定されたインスタンスによる実行のため、変更されたブラウザリクエストを作りかつディスパッチする。
【００５０】
変更されたブラウザリクエストは元のブラウザリクエストで受取った情報を再パッケージする。変更されたブラウザリクエストはたとえば、カートリッジの正しいオペレーションに必要なデータを含むコンテキストオブジェクトを含んでいてもよい。カートリッジの正しいオペレーションに必要なデータには、たとえば、そのブラウザリクエストが関連付けられるトランザクションを識別するトランザクションＩＤが含まれる。
【００５１】
カートリッジがリクエストに返答すると、そのカートリッジはディスパッチャにその返答を送り、ディスパッチャはこの返答をリスナに渡してそのリクエストを開始したブラウザへ送信されるようにする。
【００５２】
コンフィギュレーションプロバイダ
この発明の一実施例によれば、ウェブアプリケーションサーバ２８０とともに用いるべきカートリッジはまずウェブアプリケーションサーバ２８０に登録される。登録プロセスの間、そのカートリッジに関する情報がコンフィギュレーションプロバイダ２５６に供給される。コンフィギュレーションプロバイダ２５６はその情報をメタデータ２５８として蔵置してウェブアプリケーションサーバ２８０の構成要素が後からアクセスできるようにする。
【００５３】
メタデータ２５８はたとえば、
（１） カートリッジ名、
（２） 必要となるインスタンスの最小数、
（３） インスタンスの最大数、
（４） カートリッジを実装するコードの場所、
（５） コールバック機能（初期化、リクエストハンドラ、シャットダウン）を実行するためカートリッジ実行エンジンが用いるプログラムに依存した関数名、
（６） カートリッジを実行するためのマシンのリスト、
（７） カートリッジのためのアイドルタイム（カートリッジのインスタンスがシャットダウンされる前にアイドル状態でいることができる時間量）、
（８） オブジェクト識別子および
（９） もしあれば、カートリッジとともに用いるべき、認証サービスのタイプを示すデータ
を含んでいてもよい。
【００５４】
オブジェクト識別子は、対応するカートリッジによるオペレーションの実行をリクエストするためにブラウザリクエストが供給しなければならないデータを特定する。オブジェクトタイプは特定のワードまたはＵＲＬであってもよく、または「/java」などの仮想パスを含んでいてもよい。
【００５５】
一度コンフィギュレーションプロバイダ２５６が特定のカートリッジに対するコンフィギュレーション情報をメタデータ２５８内に蔵置すると、そのカートリッジはウェブアプリケーションサーバ２８０が起動される際に自動的に登録される。
【００５６】
カートリッジがウェブアプリケーションサーバ２８０に登録された後、リソースマネージャ２５４はカートリッジに対する最小インスタンスをイニシエートする。一度最小数のインスタンスがイニシエートされると、ウェブアプリケーションサーバ２８０はブラウザリクエストを処理する準備が整う。
【００５７】
仮想パスマネージャ
上に述べたように、ディスパッチャは仮想パスマネージャ２５０と通信して各々の変更されたブラウザリクエストをどこに経路選択するかを定める。特定的には、各ブラウザリクエストは典型的にＵＲＬを含む。ブラウザリクエストを受取ると、ディスパッチャはそのリクエスト内のＵＲＬを仮想パスマネージャ２５０に送る。仮想パスマネージャ２５０はこれに応答して、もしあれば、ＵＲＬに関連付けられるカートリッジを識別するデータをディスパッチャに送る。
【００５８】
必要とされる情報をディスパッチャに供給するため、仮想パスマネージャ２５０はＵＲＬをカートリッジにマッピングするメタデータ２５８を調べる。ブラウザリクエストを受取ったことに応答して、仮想パスマネージャ２５０はマッピングデータを用いて、もしあれば、ブラウザリクエストに含まれるＵＲＬに対応するカートリッジを判定する。
【００５９】
たとえば、ブラウザリクエストが仮想パス「/java」で始まるＵＲＬリクエストである場合、マッピングにより、ＪＡＶＡインタプリタカートリッジが仮想パス「/java」を有するリクエストを取扱うよう構成されていることが示されるかもしれない。
【００６０】
この発明の一実施例によれば、仮想パスマネージャ２５０はまた、ＵＲＬに関連付けられたカートリッジが認証を必要とするかどうかを判定する。カートリッジが認証を要する場合、仮想パスマネージャ２５０はディスパッチャに送る応答において、認証が必要であることを示す。認証が必要でない場合、ディスパッチャは認証サーバ２５２を呼出すことなく、カートリッジのインスタンスに対する変更されたブラウザリクエストを作って送る。認証が必要である場合、変更されたリクエストをカートリッジのインスタンスに送出してもよいことを認証サーバが示した後に初めてディスパッチャはそのカートリッジのインスタンスに変更されたリクエストを送る。
【００６１】
リソースマネージャ
ウェブアプリケーションサーバ２８０のリソースマネージャ２５４は、カートリッジに対して予め定められた最小数のインスタンスをイニシエートし、各カートリッジのインスタンスの間で負荷の最適配分を行ない、所与のカートリッジの予め定められた最大数のインスタンスまで必要に応じてカートリッジの新しいインスタンスをイニシエートすることによってカートリッジの各々の実行を管理する。
【００６２】
たとえば、ある特定のカートリッジ（Ｃ１）のためのメタデータが以下の情報を含んでいると仮定する：
名称＝Ｃ１
最小インスタンス＝１０
最大インスタンス＝５０
ホストマシン＝Ｍ１、Ｍ２、Ｍ３
アイドルタイム＝３０秒
このメタデータに基づいて、カートリッジＣ１が初めに登録される際に、リソースマネージャ２５４はＣ１の１０のインスタンスをイニシエートさせる。リソースマネージャ２５４はラベルＭ１、Ｍ２およびＭ３に関連付けられるマシン上の１０のインスタンスをイニシエートすることになる。
【００６３】
Ｃ１をアクセスするリクエストをディスパッチャから受取った際、リソースマネージャ２５４はＣ１のいずれかの既存のインスタンスが利用可能であるかどうかを判定する。リクエストを受取った際にＣ１のどのインスタンスも利用可能でない場合、リソースマネージャ２５４はＣ１の最大数のインスタンスが既に実行されているかどうかを判定する。Ｃ１の最大数のインスタンスが既に実行されていない場合、リソースマネージャ２５４は可能なホストマシンの１つの上でＣ１の新しいインスタンスをイニシエートし、リクエストを発行したディスパッチャにこの新しいインスタンスを識別するメッセージを送信する。Ｃ１の最大数のインスタンスが既に実行されている場合、リソースマネージャ２５４はリクエストを発行したディスパッチャに対し、その時点でそのリクエストを取扱うことができないことを示すメッセージを送る。
【００６４】
負荷の最適配分
この発明の一実施例によれば、リソースマネージャ２５４は１組の負荷の最適配分の規則を適用して、２つ以上の可能なホストマシンがある中、カートリッジのインスタンスをどこでイニシエートするかを定める。すなわち、上の例では、Ｍ１、Ｍ２およびＭ３はすべてカートリッジＣ１のインスタンスを実行することが可能である。Ｍ１、Ｍ２およびＭ３が同じ処理能力を有する場合、インスタンスを３つのマシンにわたって均等に分散するのが望ましいであろう。しかしながら、Ｍ１がＭ２およびＭ３の１０倍の処理力を有するなら、Ｃ１のインスタンスのすべてをある時点まではＭ１でイニシエートし、それからさらなるインスタンスをＭ１、Ｍ２およびＭ３の間で均等に分散させるのが望ましいであろう。
【００６５】
可能なマシンの間で負荷の最適配分を如何に行なうかを定める上でリソースマネージャ２５４を助けるため、各カートリッジに対して蔵置されるメタデータはさらなる詳細を含んでいてもよい。たとえば、メタデータは各マシンに対してインスタンスの別個の最小および最大数を特定してもよい。その場合リソースマネージャ２５４は、最大のインスタンスに対する現在実行されているインスタンスの比が最も低いマシンはどれかに基づいて、マシン間で新しいインスタンスを分散させることができる。
【００６６】
メタデータはまた、あるカートリッジを実行できるマシンのための順序を特定してもよい。その順序においてＮ＋１の位置にあるマシンは、その順序においてＮ番目の位置にあるマシンが既にその最大数のインスタンスを実行している場合にだけカートリッジのインスタンスを実行するのに用いられる。
【００６７】
カートリッジインスタンスステータスの管理
この発明の一実施例によれば、リソースマネージャ２５４は作られたカートリッジインスタンスを管理するためステート情報を維持する。ステート情報には、インスタンスを識別し、そのインスタンスを実行するマシンを識別し、そのインスタンスが割当てられたリスナを識別するデータが含まれる。
【００６８】
図５には、このステート情報を蔵置するためリソースマネージャ２５４が維持し得る表５００が示される。表５００には、インスタンス列５０２、カートリッジ列５０４、リスナ列５０６およびマシン列５０８が含まれる。表５００の各行は別個のカートリッジインスタンスに対応する。所与のカートリッジインスタンスに対する行内で、カートリッジ列５０４はカートリッジインスタンスに関連づけられるカートリッジを識別し、インスタンス列５０２はそのカートリッジインスタンスのインスタンス番号を示す。たとえば、行５１０はカートリッジＣ１のインスタンスに対応する。このため、行５１０のカートリッジ列５０４はカートリッジＣ１を示す。行５１０のインスタンス列５０２は行５１０に関連づけられるカートリッジインスタンスがカートリッジＣ１のインスタンス１であることを示す。
【００６９】
リスナ列５０６は、ある行に関連づけられるカートリッジインスタンスが割当てられたリスナを示す。マシン列５０８は、ある行に関連づけられるカートリッジインスタンスが実行されているマシンを示す。たとえば、行５１０に関連づけられるカートリッジインスタンスはリスナ２１０に割当てられており、マシンＭ１上で実行されている。
【００７０】
リソースマネージャ２５４と同様に、各ディスパッチャはそのディスパッチャが設けられているリスナに割当てられたカートリッジインスタンスに対するステート情報を維持する。このようなステート情報はたとえば、図４に示されるような表４００において維持されてもよい。表５００と同様に、表４００にはそれぞれインスタンス番号およびカートリッジ識別子を保持するインスタンス列４０２およびカートリッジ列４０４が含まれる。しかしながら、表５００ではリソースマネージャ２５４によって割当てられるすべてのカートリッジインスタンスに対して１つずつエントリが含まれるのに対し、表４００では特定のリスナに割当てられたカートリッジインスタンスに対するエントリしか含まれない。たとえば、表４００は、表５００に列挙されたカートリッジインスタンスのうちリスナ２００に割当てられたもののみに対するエントリを含む。
【００７１】
インスタンス列４０２およびカートリッジ列４０４に加えて、表４００にはステータス列４０６が含まれる。各行に対し、ステータス列４０６はその行に関連づけられるインスタンスのステータスを示す値を保持する。たとえば、行４０８のステータス列４０６はカートリッジＣ１にインスタンス１が現在ビジーであることを示している。例示される実施例では、ステータス列４０６はカートリッジインスタンスがＢＵＳＹまたはＦＲＥＥのいずれかであることを示すフラグを保持する。カートリッジステータスの重要性について、リソースマネージャ２５４とディスパッチャ２１４および２２０とのオペレーションに関連して以下に説明する。
【００７２】
ディスパッチャとリソースマネージャとの相互作用
上述のように、ディスパッチャは特定のカートリッジに変更されたブラウザリクエストを送る必要がある際にリソースマネージャ２５４と通信する。この発明の一実施例によれば、ディスパッチャはまず、適当なカートリッジのインスタンスが（１）これに既に割当てられているかどうか、また（２）新しい変更されたブラウザリクエストを処理するのに利用可能であるかどうかを判定する。適当なカートリッジインスタンスがディスパッチャに既に割当てられており新しい変更されたブラウザリクエストを処理するのに現在利用可能である場合、ディスパッチャはリソースマネージャ２５４とさらに通信することなく、変更されたブラウザリクエストをカートリッジインスタンスへ転送する。
【００７３】
たとえば、仮想パスマネージャ２５０によればカートリッジＣ１が処理しなければならないブラウザリクエストをリスナ２１０が受取ったと仮定する。また、表４００がリスナ２１０に割当てられたカートリッジインスタンスの現在のリストおよびステータスを反映すると仮定する。リスナ２１０からブラウザリクエストを受取ると、ディスパッチャ２１４は表４００を調べてカートリッジＣ１のＦＲＥＥインスタンスがあるか探す。例示される表４００では、行４１０がカートリッジＣ１のインスタンス３が現在ＦＲＥＥであることを示している。したがって、ディスパッチャ２１４はさらにリソースマネージャ２５４と通信することなく変更されたブラウザリクエストを直接カートリッジＣ１のインスタンス３に転送する。変更されたブラウザリクエストを送ることに応答してディスパッチャ２１４は行４１０のステータス列４０６のステータス値をＢＵＳＹに変える。
【００７４】
リスナに現在利用可能である適当なカートリッジインスタンスが既に割当てられていない場合、カートリッジに関連づけられるディスパッチャはリソースマネージャ２５４からのカートリッジインスタンスをリクエストする。必要とされるカートリッジのインスタンスが利用可能でなく、かつ必要とされるカートリッジの既存のインスタンスの数が最大数より下であることをリソースマネージャ２５４が判定した場合、リソースマネージャ２５４は新しいカートリッジをイニシエートする。新しいカートリッジをイニシエートする際に、リソースマネージャ２５４は表５００に新しいカートリッジインスタンスのためのエントリを挿入する。
【００７５】
たとえば、カートリッジＣ３が処理しなければならないブラウザリクエストをリスナ２１０が受取ったと仮定する。また、カートリッジＣ３のインスタンス３がまだイニシエートされていないものと仮定する。こうした条件の下では、ディスパッチャ２１４はリソースマネージャ２５４にカートリッジＣ３のインスタンスに対するハンドルを求めるリクエストを送る。このリクエストに応答して、リソースマネージャ２５４はマシンＭ３上でカートリッジＣ３のインスタンス３をイニシエートする。さらに、リソースマネージャ２５４は行５１２に見られるエントリを表５００に挿入する。
【００７６】
表５００にカートリッジＣ３のインスタンス３のための行５１２を挿入した後、リソースマネージャ２５４はディスパッチャ２１４に新しく作られたインスタンスに対するハンドルを送り返す。このハンドルを受取ったことに応答して、ディスパッチャ２１４はそのステータス表４００に新しいインスタンスのためのエントリ（行４１２）を挿入する。ディスパッチャ２１４はそこで、変更されたブラウザリクエストをカートリッジＣ３のインスタンス３に送信する。
【００７７】
カートリッジインスタンスの解放
この発明の一実施例によれば、リスナはカートリッジインスタンスが未処理のブラウザリクエストに応答し終わった際にカートリッジインスタンスの所有権を自動的に解放することはない。たとえば、カートリッジＣ３のインスタンス３が変更されたブラウザリクエストを受取り、その変更されたブラウザリクエストを処理して、ディスパッチャ２１４に応答を送り返すと想定する。ディスパッチャ２１４はその応答をリスナ２１０に渡し、これがブラウザリクエストを発行したブラウザに送り返されるようにする。
【００７８】
この時点で、リスナ２１０はカートリッジＣ３のインスタンス３の所有権をもはや必要としない。しかしながら、カートリッジＣ３のインスタンス３の所有権をリソースマネージャ２５４に戻す代わりに、ディスパッチャ２１４は単に行４１２のステータス列４０６をＢＵＳＹからＦＲＥＥに変える。
【００７９】
行４１２のステータス列４０６の値をＦＲＥＥに変えることによって、カートリッジＣ３のインスタンス３がもはやリクエストを処理しておらず、よって後続のリクエストを処理する準備ができていることが示される。しかしながら、カートリッジＣ３のインスタンス３が利用可能であることを示す表４００はディスパッチャ２１４によって局所的に維持されているため、カートリッジＣ３のインスタンス３はリスナ２１０に到達する後続のブラウザリクエストに対してだけ利用可能である。リソースマネージャ２５４が維持する表５００の行５１２はカートリッジＣ３のインスタンス３をリスナ２１０が所有していることを引続き示す。
【００８０】
リスナはリクエストが処理されるたびにカートリッジインスタンスを自動的に解放するわけではないため、リソースマネージャ２５４とさまざまなディスパッチャとの間での通信に関連するオーバーヘッドは大幅に減少される。たとえば、カートリッジＣ３に伝えなければならない１０の連続したリクエストをリスナ２１０が受取るものと仮定する。１０のリクエストの各々に対してリソースマネージャ２５４と通信するのではなく、ディスパッチャ２１４は最初のリクエストに応答してリソースマネージャ２５４と通信してもよい。ディスパッチャ２１４は後続の９つのリクエストをリソースマネージャ２５４と通信することなく処理することができるが、これはディスパッチャ２１４が最初のリクエストを処理するＣ３の同じインスタンスを用いて９つの後続のリクエストを処理するためである。
【００８１】
各リクエストを処理する際にカートリッジインスタンスのリスナ所有権を自動的に解放しないことでウェブアプリケーションサーバ２８０の効率が向上されるとはいえ、リスナは無期限にカートリッジインスタンスの所有権を維持することはできない。たとえば、長い期間にわたって用いられなかったインスタンスはリソースマネージャ２５４に戻され、リソースを空けるためにその割当ての解除ができるようにすべきである。さらに、他のリスナがそのカートリッジのインスタンスを必要としているところに、１つのリスナが比較的長い時間使っていなかったカートリッジのインスタンスの所有権を維持することは効率的ではない。
【００８２】
したがって、リソースマネージャ２５４は、リスナに渡される各カートリッジインスタンスのための最大アイドルタイムを各リスナに伝える。最大アイドルタイムとは、リスナがカートリッジインスタンスの所有権を解放しなければならなくなる前にそのカートリッジインスタンスが使用されない状態でいられる最大の時間を示すものである。たとえば、カートリッジＣ３のインスタンス３のための最大量のアイドルタイムが１０分であることをリソースマネージャ２５４がリスナ２１０に示すものと仮定する。この情報に基づいて、リスナ２１０は、カートリッジＣ３のインスタンス３が１０分より長い間アイドル状態またはＦＲＥＥとならない限りにおいてカートリッジＣ３のインスタンス３を続けて用いてカートリッジＣ３に対するブラウザリクエストを処理することができる。
【００８３】
カートリッジＣ３のインスタンス３が１０分より長い間アイドル状態である場合、ディスパッチャ２１４は表４００から行４１２を取除き、リスナ２１０がカートリッジＣ３のインスタンス３の所有権を解放することをリソースマネージャ２５４にメッセージを送って知らせる。このメッセージに応答して、リソースマネージャ２５４は行５１２を更新して、カートリッジＣ３のインスタンス３がいずれのリスナによっても所有されておらず、よって別のリスナに再割当てされるか終了され得ることを示す。
【００８４】
代替の実施例では、カートリッジインスタンスのためのアイドルタイムが満了した際にもディスパッチャはカートリッジインスタンスを自動的に解放しない。代わりに、ディスパッチャはリソースマネージャ２５４にメッセージを送り、満了となったインスタンスを解放することを申し出る。リソースマネージャ２５４はこの申し出に応答して、リスナがカートリッジインスタンスを解放するようリクエストするか、またはリスナがその満了となったカートリッジインスタンスの所有権を持ち続けることを許可してもよい。
【００８５】
この発明の一実施例によれば、リソースマネージャ２５４は直ちに処理することのできないリクエストのキューを維持する。キュー内のリクエストを処理することが可能となると、そのリクエストはキューから取除かれ処理される。
【００８６】
たとえば、カートリッジＣ１が処理しなければならないブラウザリクエストをリスナ２２２が受取り、そのリスナ２２２にカートリッジＣ１のいずれのインスタンスも割当てられていなかったと仮定する。ディスパッチャ２２６はリソースマネージャ２５４にＣ１のインスタンスに対するリクエストを送る。さらに、Ｃ１の最大５０のインスタンスが許容され、Ｃ１の５０のインスタンスがリスナ２１０に割当てられたと仮定する。こうした条件の下では、リソースマネージャ２５４はリスナ２２２からのリクエストを処理することができない。このため、リソースマネージャ２５４はそのリクエストをキューにおく。リスナ２１０がＣ１のインスタンスを解放すると、リソースマネージャ２５４はリスナ２２２にＣ１のインスタンスが利用可能であることを伝える。
【００８７】
ある特定の条件の下で、リソースマネージャ２５４は強制的にリスナにカートリッジインスタンスを解放させることがある。たとえば、リソースマネージャ２５４はシステムオーバロード状況を検出し、これに応答して１組のカートリッジインスタンスを終了することがあり、これはそのカートリッジインスタンスが終了されることになることをそのカートリッジインスタンスが現在割当てられているリスナに知らせる前または知らせた後に行なわれる。
【００８８】
また、リソースマネージャ２５４はリスナの間での公平性の方針を実現するために強制的にリスナにカートリッジインスタンスを解放させることがある。たとえば、別のリスナが予め定められたしきい値より長い時間にわたってカートリッジのインスタンスを待っている場合、リソースマネージャ２５４は所与のカートリッジの最も多い数のインスタンスを保持するリスナにそのカートリッジのあるインスタンスを解放させてもよい。たとえば、リスナ２１０にカートリッジＣ１の５０のインスタンスが割当てられ、Ｃ１は最大で５０のインスタンスを有する場合、リソースマネージャ２５４は別のリスナからＣ１のインスタンスに対するリクエストを受取ってから１０秒後にリスナ２１０にＣ１のあるインスタンスを解放させてもよい。
【００８９】
カートリッジ実行エンジン
この発明の一実施例によれば、各カートリッジインスタンスはカートリッジ実行エンジンおよびカートリッジから構成される。カートリッジ実行エンジンは、ウェブアプリケーションサーバ２８０およびマシン間通信機構の複雑さからカートリッジを隔離するコードモジュールである。カートリッジは、関数テーブルにカートリッジ関数に対するポインタを蔵置することによってカートリッジ実行エンジンに利用可能となる。一実施例によれば、すべてのカートリッジが、上述の例示のカートリッジインターフェイスにおいて特定された関数を提供する。すべてのカートリッジが同じインターフェイスをサポートするようにさせることにより、単一の標準カートリッジ実行エンジンをすべてのカートリッジに対して用いることができる。
【００９０】
この発明の一実施例によれば、カートリッジは共用ライブラリとして実装され、カートリッジ実行エンジンは標準カートリッジインターフェイスを用いて共用ライブラリ内のルーチンを呼出す実行可能なプログラムである。カートリッジ実行エンジンはカートリッジとディスパッチャとの間でインターフェイスをもたらし、カートリッジの制御のフローを指示し、カートリッジが用いるサービスを提供する。
【００９１】
リソースマネージャ２５４が新しいカートリッジインスタンスの生成を必要とする場合、リソースマネージャ２５４はカートリッジ実行エンジンのインスタンスを生成させる。これに対し、このようにして作られたカートリッジ実行エンジンのインスタンスは適当なカートリッジのインスタンスを生成させる。リソースマネージャ２５４はたとえば、カートリッジが実行されるマシン上にある「カートリッジ実行エンジンファクトリ」と呼出すことによってカートリッジ実行エンジンのインスタンスを生成させることができる。カートリッジ実行エンジンのインスタンスはたとえば、そのカートリッジを構成する共用ライブラリ内のルーチンのうちの１つに呼出を行なうことによってカートリッジのインスタンスを生成させることができる。
【００９２】
図２に示すように、ウェブアプリケーションサーバ２８０は、カートリッジ２３０、２３４および２３８のそれぞれに対して、カートリッジ実行エンジン２２８、２３２および２３６を含む。カートリッジ実行エンジンは、標準のカートリッジインターフェイスを通じてカートリッジへのコールを行なうことによって、対応するカートリッジのインスタンスの実行を制御する。カートリッジ実行エンジンとカートリッジとの間に基本的なコールバック機能を構築することによって、どのカートリッジも、ウェブアプリケーションサーバ２８０内に統合することができる。これは、そのカートリッジをコールバック機能に応答するよう構成し、その後、そのカートリッジをコンフィギュレーションプロバイダ２５６に登録することによって、行なわれる。これについては、以下に記載する。
【００９３】
したがって、ＰＬ／ＳＱＬランタイムカートリッジがリクエストを処理するのに適当なカートリッジであるとディスパッチャ２１４が判定すると、ディスパッチャ２１４はそのＰＬ／ＳＱＬランタイムカートリッジに関連づけられるカートリッジ実行エンジンを含むカートリッジインスタンスにそのリクエストをディスパッチする。新しいインスタンスをイニシエートする必要がある場合、リソースマネージャ２５４は別個のアドレス空間においてＰＬ／ＳＱＬランタイムカートリッジの新しいインスタンスを作り、その新しいインスタンスのカートリッジ実行エンジン２２８へそのリクエストをディスパッチする。プログラムのインスタンスを実行するのに用いられるアドレス空間は、ウェブアプリケーションサーバ２８０の構成要素の１つ以上が実行されているコンピュータシステムのメモリ内にあるか、または別のコンピュータシステム上にあってもよい。
【００９４】
ディスパッチャからのメッセージに応答して、カートリッジ実行エンジンはカートリッジにリクエストハンドラコールバック機能を発行し、カートリッジにそのリクエストを処理させる。そのリクエストを処理するカートリッジはその結果をカートリッジ実行エンジンに返し、カートリッジ実行エンジンはその結果をディスパッチャに転送する。ウェブアプリケーションサーバ２８０がオペレーションにおいて障害を検出した場合にはカートリッジ実行エンジンはカートリッジのシャットダウン関数を発行する。
【００９５】
このように、カートリッジ実行エンジンは、実行すべき予め定められたオペレーションを特定するウェブアプリケーションサーバ２８０へのアプリケーションプログラミングインターフェイスを提供する。標準のカートリッジインターフェイスを使用することにより、カートリッジのプログラマが、カートリッジがともに用いられることになる特定のウェブリスナが用いるプロトコルとは無関係に、各カートリッジをウェブアプリケーションサーバ２８０へ高レベルで統合化するよう構成することができる。
【００９６】
トランスポートアダプタ
リスナは、サーバ側のプラグインが使用するためのプログラミングインターフェイスおよびプロトコルを提供することによってそのようなプラグインの使用を可能にする。残念なことに、リスナが提供するプログラミングインターフェイスおよびプロトコルはリスナごとに異なる。たとえば、ネットスケープ・サーバ・アプリケーション・プログラミング・インターフェイス（ＮＳＡＰＩ：Netscape Server Application Programming Interface）、インターネット・サーバ・アプリケーション・プログラミング・インターフェイス（ＩＳＡＰＩ：Internet Server Application Programming Interface）およびアプリケーション開発インターフェイス（ＡＤＩ：Application Development Interface）は現在リスナによりもたらされる別個のプログラミングインターフェイスの３つの例である。
【００９７】
トランスポートアダプタはウェブリスナが用いる私的プロトコルおよびインターフェイスからディスパッチャを隔離する。特定的には、各トランスポートアダプタはさまざまなリスナのプロトコルを認識し、リスナから受取ったブラウザリクエストを変換してリスナのプロトコルとは無関係の標準ディスパッチャプロトコルを有する変換されたブラウザリクエストを生じるよう構成される。同様に、トランスポートアダプタはディスパッチャからの返答をリスナのトランスポートプロトコルに変換する。
【００９８】
このように、トランスポートアダプタにより、ウェブアプリケーションサーバ２８０を異なるベンダのリスナとともに用いることが可能となる。さらに、トランスポートアダプタは異なるサーバアーキテクチャおよびオペレーティングシステムに対応するよう構成されてもよい。
【００９９】
ウェブアプリケーションサーバのオペレーション
図３Ａおよび図３Ｂはこの発明の一実施例によるブラウザリクエストに応答する方法を示すフロー図である。ステップ３５０においてリスナがブラウザリクエストを受取る。説明のために、このブラウザリクエストはブラウザ２０２により発行されリスナ２１０により受取られるものと仮定する。
【０１００】
ブラウザリクエストを受取ると、リスナ２１０はステップ３５２においてウェブアプリケーションサーバ２８０にそのリクエストを転送する。特定的には、リスナ２１０はリスナ２１０の私的プログラミングインターフェイスを用いてそのリクエストをトランスポートアダプタ２１２に渡す。トランスポートアダプタ２１２は、必要に応じてそのリクエストを標準ディスパッチャプログラミングインターフェイスを用いて変換しそのリクエストをディスパッチャ２１４に渡す。
【０１０１】
ディスパッチャ２１４は、仮想パスマネージャ２５０と通信することによって、ブラウザリクエストにより特定される仮想パスに基づいて、ステップ３５４においてブラウザリクエストに対応するリクエストオブジェクトタイプを識別する。リクエストオブジェクトタイプがカートリッジに対応する場合には、仮想パスマネージャはまた、認証が必要であるかどうかをディスパッチャ２１４に知らせる。
【０１０２】
ディスパッチャ２１４はステップ３５６において、そのリクエストオブジェクトタイプが識別可能なカートリッジに対応するかどうかを判定する。そのリクエストオブジェクトタイプが識別可能なカートリッジに対応していない場合、そのリクエストはステップ３５８においてリスナ２１０に戻される（図３Ｂを参照）。ステップ３５８においてそのリクエストが静的ＨＴＭＬページに対するリクエストであることをリスナ２１０が認識すると、リスナはその静的ＨＴＭＬページにアクセスし、そのＨＴＭＬページをステップ３６０においてブラウザ２０２に送る。ブラウザリクエストがリスナ２１０によって認識されない場合、ステップ３６０において返答がブラウザ２０２に送られそのリクエストが認識不可能であったことを示す。
【０１０３】
ステップ３５６において、リクエストをカートリッジに送らなければならないとディスパッチャ２１４が判定すると、ディスパッチャは、認証サーバ２５２と通信することによって、必要な認証を行なう。この認証のプロセスについては、以下により詳細に説明する。さらに、ステップ３５６において、リスナ２１０にそのカートリッジの現在ＦＲＥＥであるインスタンスが１つも割当てられていないと判定すると、ディスパッチャ２１４は、そのブラウザリクエストを送ることのできるカートリッジ２３０のインスタンスが割当てられることになるリソースマネージャ２５４と通信する。
【０１０４】
図３Ｂに示されるステップ３６２では、リソースマネージャ２５４は、識別されたカートリッジのインスタンスが既存のインスタンスの数の中で利用可能である（所有されていない）かどうかを判定する。説明のため、このリクエストはカートリッジ２３０に関連づけられるものであり、カートリッジ２３０はＰＬ／ＳＱＬランタイムカートリッジであると仮定する。
【０１０５】
ステップ３６２においてリソースマネージャが利用可能なインスタンス、たとえばＰＬ／ＳＱＬランライム２３０のインスタンス２６０を識別すると、リソースマネージャ２５４はリクエストをインスタンス２６０に送るべきであることをディスパッチャ２１４に知らせる。ディスパッチャ２１４はそこで、変更されたブラウザリクエストを作りステップ３６８においてインスタンス２６０のカートリッジ実行エンジン２２８にその変更されたブラウザリクエストを送って、以下に説明するように利用可能なインスタンス２６０にそのリクエストを処理させる。
【０１０６】
しかしながら、ステップ３６２においてカートリッジ２３０のインスタンスが１つも利用可能でない場合、リソースマネージャ２５４はステップ３６４において、既存のインスタンスの数が最大所定数を超えるかどうかを判定する。ステップ３６４において既存のインスタンスの数が最大所定数を超える場合、リソースマネージャ２５４はその時点ではそのリクエストを処理できないことをディスパッチャ２１４に示す。これに応答して、ディスパッチャ２１４はステップ３５８においてそのリクエストをリスナ２１０に返し、その後に、ウェブリスナ２１０はステップ３６０においてネットワークを介してブラウザ２０２へ返答を送り、そのリクエストが処理されなかったことを示す。
【０１０７】
代わりに、カートリッジインスタンスがリクエストを処理するためにその現時点で利用可能でない場合、リスナ２１０はそのカートリッジインスタンスに対する待ちリストにそのリクエストを入れてもよい。カートリッジインスタンスが利用可能となると、変更されたブラウザリクエストが待ちリストから取除かれカートリッジインスタンスに転送される。変更されたブラウザリクエストが予め定められた時間より長い間待ちリストに残っている場合、リスナ２１０はそのリクエストを待ちリストから取除いてブラウザ２０２にメッセージを送りそのリクエストが処理できなかったことを示すようにしてもよい。
【０１０８】
ステップ３６４において既存のインスタンスの数が最大所定数を超えない場合、リソースマネージャ２５４は識別されたプログラムの新しいインスタンスをイニシエートし、ブラウザリクエストに基づく変更されたブラウザリクエストを新しいインスタンスに送るべきであることをディスパッチャ２１４に知らせる。そこでディスパッチャ２１４は変更されたブラウザリクエストをその新しいインスタンスのカートリッジ実行エンジンへディスパッチする。
【０１０９】
たとえば、リソースマネージャ２５４がブラウザリクエストに応答してインスタンス２６０をイニシエートしたと仮定する。その初期化の間、ＰＬ／ＳＱＬランタイムのための蔵置された命令シーケンスにアクセスが行なわれ、ディスパッチャ２１４が実行しているアドレス空間とは別個のアドレス空間においてカートリッジ２３０の新しいインスタンス２６０が作られる。一実施例によれば、初期化はカートリッジ実行エンジン２２８をロードし、そのカートリッジ実行エンジンにカートリッジ２３０内の初期化ルーチンを呼出させることによって行なわれる。
【０１１０】
一度新しいインスタンス２６０が実行されると、ディスパッチャ２１４はステップ３６８においてその新しいインスタンス２６０に関連づけられているカートリッジ実行エンジン２２８にリクエストをディスパッチする。カートリッジ実行エンジン２２８は新しいインスタンス２６０にコールバックメッセージを送りそのリクエストの実行を要求する。そのコールバックメッセージにおいて、カートリッジ実行エンジン２２８はそのリクエストを処理する上でインスタンス２６０が必要とする全てのパラメータを渡す。このようなパラメータにはたとえば、パスワード、データベース探索キー、またはインスタンス２６０が実行する動的オペレーションのための他のどんな引き数を含んでいてもよい。
【０１１１】
次にインスタンス２６０はリクエストを実行する。ステップ３６８におけるインスタンスによるリクエストの実行の間、ディスパッチャ２１４はステップ３７０においてインスタンスを監視して障害が発生するかどうかを判定する。ステップ３７０においてディスパッチャ２１４が障害を検出すると、ディスパッチャ２１４はステップ３７２において対応するカートリッジ実行エンジン２２８を呼出し、その障害を有するインスタンス２６０を打ち切る。これに対し対応するカートリッジ実行エンジン２２８はＡＰＩを通して障害のあるインスタンスに対してシャットダウンコマンドを発行する。そのインスタンスはカートリッジ実行エンジン２２８によるシャットダウンコマンドに応答して、他のどんなアドレス空間における他のどんなプロセスにも影響を与えることなくシャットダウンする。
【０１１２】
ステップ３７０において障害が検出されない場合、ディスパッチャ２１４はステップ３７４において実行の完了の際にインスタンス２６０から返答を受取る。ステップ３７６においてディスパッチャ２１４はその返答をリスナ２１０に転送し、リスナ２１０は実行されたインスタンス２６０からの返答をもってブラウザに応答する。インスタンス２６０を実行した後、ステップ３７８においてディスパッチャ２１４はステップ３７８に示されるようにメモリ内にインスタンスを維持し、後続のリクエストの実行を可能にする。
【０１１３】
ウェブサーバの分散アーキテクチャ
重要なことであるが、ウェブアプリケーションサーバ２８０のさまざまな構成要素は、それら構成要素が同じアドレス空間において実行される必要がなく同じマシン上で実行されることさえ必要としない通信機構を用いて互いに通信する。例示される実施例では、ウェブアプリケーションサーバ２８０の構成要素はオブジェクトリクエストブローカ（ＯＲＢ：Object Request Broker）２８２を介して通信するよう構成される。オブジェクトリクエストブローカは「共通オブジェクトリクエストブローカ：アーキテクチャおよび仕様（ＣＯＲＢＡ）」（"Common Object Request Broker: Architecture and Specification (CORBA)"）に詳しく記載されている。ＣＯＲＢＡに関連するこのおよび他の文献はワールド・ワイド・ウェブのhttp://www.omg.orgにおいて見つけることができる。
【０１１４】
この発明の実施例はＣＯＲＢＡに従ったＯＲＢを介する通信に関連して説明するが、他のクロスプラットフォーム通信機構を用いてもよい。たとえば、ウェブアプリケーションサーバ２８０の構成要素は代わりに、遠隔手続き呼出（ＲＰＣ：Remote Procedure Calls）、ＵＮＩＸパイプ、Microsoft COMを用いて互いに通信してもよい。
【０１１５】
ウェブアプリケーションサーバ２８０のさまざまな構成要素がマシンから独立した通信機構を用いて互いに通信するため、構成要素が互いに対してどこに存在するかということに関して固有の制約はない。たとえば、リスナ２１０、２１６および２２２は同じマシン上で実行していてもよく、またはそれぞれがこのようなオペレーティングシステムを有する３つの完全に異なったマシン上で実行してもよい。同様に、認証サーバ２５２、仮想パスマネージャ２５０、リソースマネージャ２５４およびコンフィギュレーションプロバイダ２５６は同じマシン上で実行していてもよく、または４つの異なるマシン上で実行していてもよい。さらに、これらの４つの異なるマシンはリスナ２１０、２１６および２２２を実行する３つのマシンと少しも重複していなくてもよい。
【０１１６】
カートリッジ実行エンジン２２８、２３２および２３６は、オブジェクトリクエストブローカ２８２を介してウェブアプリケーションサーバ２８０の他の構成要素と通信するのに必要な論理のすべてを組込んでいる。したがって、カートリッジインスタンス自体の場所は通信機構によって本質的に制約されるものではない。すなわち、インスタンス２６０はこれがリクエストを受取るディスパッチャとは全く異なるマシンおよびオペレーティングシステムにおいて実行されてもよい。同様に、インスタンス２６０は、リソースマネージャ２５４、または同じウェブアプリケーションサーバ２８０によって管理される他のカートリッジのインスタンスを含む、ウェブアプリケーションサーバ２８０の他の構成要素のいずれとも異なるマシンおよびオペレーティングシステム上にあってもよい。
【０１１７】
重要な事だが、ウェブアプリケーションサーバ２８０が用いるカートリッジが享受する場所の独立性は、カートリッジそのものにおける何らかのカスタムプログラミングを介してではなくカートリッジ実行エンジンの通信論理を介して達成される。したがって、分散アプリケーションサーバ環境における実行のために特別にカートリッジを設計する必要がない。このように、カートリッジ設計者らは分散システムの複雑さから隔離され、カートリッジが作られる目的であるタスクと関連する論理に労力を集中させることができる。
【０１１８】
認証機能の概要
前述のように、各ブラウザのメッセージはＵＲＬ情報と関連付けられて、ＵＲＬ情報はとりわけ、アクセスされるべき特定のカートリッジを識別する。ディスパッチャは、ブラウザのリクエストを受取ると、仮想パスマネージャと通信して、そのブラウザのメッセージに関連付けられたカートリッジが認証を必要としているかどうかを判定する。カートリッジが認証を必要としない場合には、ディスパッチャはブラウザのリクエストをカートリッジにディスパッチし、カートリッジがそれを実行する。しかし、カートリッジが認証を必要とする場合には、ディスパッチャは認証のリクエストを認証サーバに対して送信する。
【０１１９】
認証サーバは、認証のリクエストに含まれる情報を使用して、そのブラウザのリクエストがカートリッジにアクセスすることを許可されているかどうかを判定する。ブラウザのリクエストがカートリッジにアクセスすることを許可されている場合には、ディスパッチャはブラウザのリクエストをカートリッジにディスパッチし、カートリッジがそれを実行する。これに対し、ブラウザのリクエストがカートリッジにアクセスすることを許可されていない場合には、ディスパッチャはアクセスが拒絶されたことを示すメッセージをブラウザに送信する。このプロセスは、ブラウザの各リクエストに対して繰返される。
【０１２０】
図６は、本発明の一実施例に従った、ステートレスなウェブ環境において拡張可能な認証機構を提供する、システム６００のブロック図である。図６は図２と同様であるため、同じ構成要素には同じ参照番号が付されている。
【０１２１】
システム６００は、オブジェクトリクエストブローカ２８２を介して複数のディスパッチャ２１４、２２０および２２６に接続された認証サーバ２５２を含む。認証サーバ２５２は、認証エンジン６０２と、認証ホスト６０４と、複数の認証サービスプロバイダ（単にプロバイダと称する）６０６、６０８、６１０および６１２とを含む。
【０１２２】
認証エンジン６０２は、オブジェクトリクエストブローカ２８２を介してディスパッチャ２１４、２２０および２２６と通信して、認証のリクエストを受取る。認証のリクエストを受取ると、認証エンジン６０２はその認証のリクエストを解析して１または複数のプロバイダのリクエストとする。認証エンジン６０２はその後、それらプロバイダのリクエストを、オブジェクトリクエストブローカ２８２を介して認証ホスト６０４に送信する。各リクエストはそこから適切なプロバイダへと分配される。
【０１２３】
認証エンジン６０２からプロバイダのリクエストを受取ると、認証ホスト６０４はそのプロバイダのリクエストを適切なプロバイダに送る。プロバイダは、プロバイダのリクエストを受取ると、アクセスが許可されるべきかどうかを、そのプロバイダのリクエストに含まれる情報に基づいて判定する。プロバイダはその後、認証ホスト６０４およびオブジェクトリクエストブローカ２８２を介して、応答メッセージを認証エンジン６０２に戻す。この応答メッセージは、その特定のプロバイダのリクエストに含まれていた情報に基づいて、アクセスが許可されるべきかどうかを示している。
【０１２４】
認証エンジン６０２はその後、１または複数のプロバイダの応答メッセージを使用して、ディスパッチャから受取られた認証のリクエストに基づいて、カートリッジのアクセスが許可されるべきかどうかを判定する。認証エンジンはその後、ブラウザのリクエストを適切なカートリッジに送るか、それとも、送信側ブラウザにアクセスが拒絶されたことを知らせるか、をディスパッチャに通知する。
【０１２５】
プロテクトストリング
前述のように、ウェブアプリケーションサーバ２８０とともに使用されるべきカートリッジは、メタデータとして記憶されるべき情報をコンフィギュレーションプロバイダ２５６に提供することによって、まず登録される。この登録プロセス中、各カートリッジは、その特定のカートリッジに関連付けられるべきＵＲＬのリストを供給する。これらＵＲＬは、特定のブラウザのリクエストに関連付けられるカートリッジを識別するのに使用される。特定のカートリッジへのアクセスを制限するために、オプションとしてプロテクトストリングを各ＵＲＬエントリに関連付けてもよい。
【０１２６】
本発明の一実施例においては、各プロテクトストリングは、１または複数の方式名と領域名との対によって構成されており、方式名と領域名との対が複数あるときは、それらの間には論理関数（たとえばＡＮＤ、ＯＲ）が置かれている。方式名は、カートリッジのアクセスを認証するのに使用されるべきプロバイダの型を識別し、領域名は、方式名と関連付けられた、プロバイダによって必要とされる認証情報の型を示す。
【０１２７】
たとえば、カートリッジ２３８が登録する場合、これは、以下のようなＵＲＬおよびプロテクトストリングと関連付けられてもよい：
URL1 CARTRIDGE＿238 BASIC(GROUP1) AND IP(IP＿LIST)
この例においては、ＵＲＬ１がＵＲＬを表わし、方式名「ＢＡＳＩＣ」および「ＩＰ」がカートリッジのアクセスの認証に使用されるべきプロバイダを識別する。領域名「ＧＲＯＵＰ１」および「ＩＰ＿ＬＩＳＴ」は、それぞれ方式名「ＢＡＳＩＣ」および「ＩＰ」に関連付けられており、各プロバイダの型によって必要とされる認証情報の型を表わす。論理「ＡＮＤ」演算が、認証エンジンによって使用される。これはまた、そのブラウザのリクエストがＣＡＲＴＲＩＤＧＥ＿２３８にアクセスすることを許可されるかどうかを判定するために、「ＢＡＳＩＣ」および「ＩＰ」プロバイダから受取られた応答メッセージに対して論理「ＡＮＤ」演算が行なわれねばならないことを表わしている。
【０１２８】
プロバイダ
プロバイダは、特定の型の認証を行なうのに使用されるコードのモジュールである。本発明の一実施例に従えば、プロバイダは動的にリンクされるライブラリ（ＤＬＬ）として実装される。したがって、プロバイダは、それが属する認証ホストと同じアドレス空間内にロードされかつその中で実行される。プロバイダは、好ましくは、ランタイムに動的にロードされる。
【０１２９】
各プロバイダは、関数ポインタのテーブルおよびプロパティリストを含む。関数ポインタのテーブルは、認証ホスト６０４がアクセスすることのできる特定のプロバイダの機能に対するポインタを提供する。プロパティリストは、その特定のプロバイダにアクセスするのに必要とされる、（カートリッジに対してリクエストを開始するユーザのアイデンティティ等の）認証情報の型を記述する。一実施例に従えば、プロパティテーブルは、プロバイダの名前、ディスク上でそのＤＬＬが記憶されているロケーション、およびエントリポイントアドレスを含む。認証ホストは、エントリポイントを呼出して、特定のプロバイダのリクエストを認証するのに使用することのできる関数ポインタのリストを得ることができる。
【０１３０】
一実施例において、特定のプロバイダに関連する情報は、そのプロバイダが初期化されるときにウェブアプリケーションサーバ２８０内にメタデータとして格納される。プロバイダが初期化されるときにプロバイダ情報をメタデータとして格納することによって、プロバイダを認証サーバ２５２に対して動的に付加したりそれから分離したりすることのできる機構が提供される。
【０１３１】
図６に示すように、プロバイダ６０６、６０８、６１０および６１２は認証ホスト６０４に関連づけられている。各プロバイダは、特定のカートリッジへのアクセスを制限する、特定的な認証機構を提供する。たとえば、ＢＡＳＩＣプロバイダを認証ホストに関連づけ、このＢＡＳＩＣプロバイダを利用して、カートリッジのアクセスを、特定のユーザ名およびパスワードの対に関連づけられたブラウザのリクエストのみに制限することができる。したがって、このＢＡＳＩＣプロバイダは、認証ホストからプロバイダのリクエストを受取ると、所定のユーザ名／パスワードのアクセスリストをサーチして、アクセスが提供されるべきかどうかを判定する。ユーザ名／パスワードの一致を発見すると、ＢＡＳＩＣプロバイダは、供給されたユーザ名およびパスワードの対に基づいてアクセスが許可されるべきであることを示すメッセージを、認証ホストに送信する。しかし、一致を見つけることができなければ、そのＢＡＳＩＣプロバイダは、ユーザ名／パスワードの対に基づいてアクセスが許可されるべきではないことを示すメッセージを、認証ホストに送信する。
【０１３２】
認証ホストに関連づけることのできるプロバイダの型の別の例として、ＩＰアドレスプロバイダがある。このＩＰアドレスプロバイダは、カートリッジのアクセスを、特定のＩＰアドレスに関連づけられたブラウザのリクエストのみに制限するのに使用することができる。したがって、このＩＰアドレスプロバイダは、認証ホストからプロバイダのリクエストを受取ると、所定のＩＰアクセスリストをサーチして、アクセスが提供されるべきかどうかを判定する。もしＩＰアドレスの一致を発見すれば、ＩＰアドレスプロバイダはその供給されたＩＰアドレスに基づいてアクセスが許可されるべきであることを示すメッセージを、認証ホストに送信する。しかし、一致を発見できない場合には、ＩＰアドレスプロバイダは、ＩＰアドレスに基づいてアクセスが許可されるべきではないことを示すメッセージを、認証ホストに送信する。
【０１３３】
認証ホストに関連づけることのできるプロバイダの型のさらに別の例として、ＤＯＭＡＩＮ名プロバイダがある。ＤＯＭＡＩＮ名プロバイダは、カートリッジのアクセスを、特定の領域名に関連づけられたブラウザのリクエストのみに制限するのに使用することができる。したがって、このＤＯＭＡＩＮ名プロバイダは、認証ホストからプロバイダのリクエストを受取ると、所定のＤＯＭＡＩＮ名リストをサーチして、アクセスが提供されるべきかどうかを判定する。ＤＯＭＡＩＮ名の一致を発見した場合、ＤＯＭＡＩＮ名プロバイダは、供給されたＤＯＭＡＩＮ名に基づいてアクセスが許可されるべきであることを示すメッセージを、認証ホストに送信する。しかし、一致を発見できない場合には、ＤＯＭＡＩＮ名プロバイダは、ＤＯＭＡＩＮ名に基づいてアクセスが許可されるべきではないことを示すメッセージを、認証ホストに送信する。
【０１３４】
認証ホストに関連づけることのできるプロバイダの型のまた別の例として、ＤＡＴＡＢＡＳＥプロバイダがある。このＤＡＴＡＢＡＳＥプロバイダは、カートリッジのアクセスを、特定のデータベース内に含まれる特定のユーザ名およびパスワードの対に関連づけられたブラウザのリクエストのみに制限するのに使用することができる。したがって、このＤＡＴＡＢＡＳＥプロバイダは、認証ホストからプロバイダのリクエストを受取ると、データベースをサーチして、アクセスが提供されるべきかどうかを判定する。データベース内にユーザ名／パスワードの一致を発見すれば、ＤＡＴＡＢＡＳＥプロバイダは供給されたデータベースのユーザ名およびパスワードの対に基づいてアクセスが許可されるべきであることを示すメッセージを認証ホストに送信する。しかし、一致を発見することができなければ、ＤＡＴＡＢＡＳＥプロバイダは、データベースのユーザ名／パスワードの対に基づいてアクセスが許可されるべきではないことを示すメッセージを、認証ホストに送信する。
【０１３５】
認証ホストに関連づけることのできるプロバイダの型のさらに別の例に、ＤＩＧＥＳＴプロバイダがある。このＤＩＧＥＳＴプロバイダは、特定のユーザ名および暗号化されたパスワードの対に関連づけられたブラウザのリクエストのみにカートリッジのアクセスを制限するのに使用することができる。このＤＩＧＥＳＴプロバイダは、認証ホストからプロバイダのリクエストを受取ると、乱数を発生し、この乱数を、ディスパッチャを介してブラウザのリクエストに関連づけられたブラウザへと送り返す。
【０１３６】
ブラウザは、この乱数を受取ると、ＤＩＧＥＳＴプロバイダが発生したこの乱数に基づいてパスワードを暗号化し、それをディスパッチャおよびオブジェクトリクエストブローカを介して認証エンジンに送り返す。認証エンジンは、この暗号化されたパスワードを、オブジェクトリクエストブローカおよび認証ホストを介してＤＩＧＥＳＴプロバイダに戻す。ＤＩＧＥＳＴプロバイダは、ブラウザから送られてきた暗号化パスワードを受取ると、それをＤＩＧＥＳＴプロバイダによって生成された暗号化パスワードと比較する。その後、ＤＩＧＥＳＴプロバイダは、比較の結果を使用して、そのブラウザのリクエストがカートリッジに対してアクセスすることができるかどうかを判定する。
【０１３７】
認証エンジン
一実施例に従えば、認証エンジン６０２は、実行を開始するときに、自身を認証エンジンと識別するその名前および関連のＩＤをメタデータとしてウェブアプリケーションサーバ２８０に格納することによって、ウェブアプリケーションサーバ２８０に登録する。認証エンジンに関連づけられたメタデータは、オブジェクトリクエストブローカ２８２がシステムの負荷を最適配分するのに使用される。負荷の最適配分については、以下にさらに詳細に説明する。
【０１３８】
認証リクエストを受取ると、認証エンジン６０２はその認証リクエストを解析して１または複数のプロバイダのリクエストとする。その後、認証エンジン６０２はそれらプロバイダのリクエストを、オブジェクトリクエストブローカ２８２を介して認証ホスト６０４に送信し、各リクエストはそこから適切なプロバイダへと分配される。
【０１３９】
認証ホスト６０４は、認証エンジン６０２からプロバイダのリクエストを受取ると、各プロバイダのリクエストを適切なプロバイダに送る。プロバイダは、プロバイダのリクエストを受取ると、そのプロバイダのリクエストに含まれる情報に基づいてアクセスが許可されるべきかどうかを判定する。その後、プロバイダは、プロバイダのリクエスト内に含まれる情報に基づいてアクセスが許可されるべきかどうかを示す応答メッセージを、認証ホスト６０４およびオブジェクトリクエストブローカ２８２を介して認証エンジン６０２へと送り返す。
【０１４０】
認証のリクエストに関連づけられたプロバイダから応答メッセージを受けた後、認証エンジンは、そのブラウザのリクエストがカートリッジにアクセスするのを許可されるべきかどうかを判定するのに必要な論理演算を行なう。認証エンジンはその後、そのブラウザのリクエストがカートリッジにディスパッチされるべきか、それとも、カートリッジのアクセスが拒絶されたことをブラウザに知らせるべきかを、ディスパッチャに通知する。
【０１４１】
認識リクエストの処理
図７Ａおよび７Ｂは、本発明の一実施例に従った、ステートレスなウェブ環境においてブラウザのリクエストを認証するための方法を示すフロー図である。説明の目的で、ブラウザのリクエストはブラウザ２０２によって発行され、ディスパッチャ２１４がそれを受取るものとする。また、ブラウザのリクエストに関連するＵＲＬが、プロテクトストリング「ＢＡＳＩＣ（ＧＲＯＵＰ１） ＡＮＤ ＩＰ（ＩＰ＿ＬＩＳＴ）」に関連づけられ、また、ブラウザのリクエストが、ユーザ名「ＪＩＭ」、パスワード「ＭＡＮＡＧＥＲ」およびＩＰアドレス「１９２．６．２５．３」を含むものとする。さらに、プロバイダ６０６がＢＡＳＩＣ型のプロバイダであって、プロバイダ６０８がＩＰ型のプロバイダであるものとする。
【０１４２】
ステップ７０２において、ディスパッチャ２１４が上述のようなブラウザのリクエストを受取る。ステップ７０４において、ディスパッチャ２１４がオブジェクトリクエストブローカ２８２を介して仮想パスマネージャ２５０と通信して、そのブラウザのリクエストに関連づけられるＵＲＬが認証を必要とするか（たとえば、ＵＲＬがプロテクトストリングに関連づけられているか）を判定する。ＵＲＬがプロテクトストリングに関連づけられていない場合には、ステップ７０６において、ディスパッチャ２１４がそのブラウザのリクエストを適切なカートリッジにディスパッチする。その後、制御はステップ７０２に戻って、別のブラウザのリクエストを受取る。
【０１４３】
しかし、ＵＲＬが（この例のように）プロテクトストリングに関連づけられている場合には、ステップ７０８において、ディスパッチャ２１４はオブジェクトリクエストブローカ２８２を介して認証エンジン６０２へと、認証のリクエスト（たとえば、ＢＡＳＩＣ（Ｇｒｏｕｐ１）ＪＩＭ／ＭＡＮＡＧＥＲ ＡＮＤ ＩＰ（ＩＰ＿ＬＩＳＴ）１９２．６．２５．３）を送信する。ステップ７１０において、認証エンジン６０２は、その認証リクエストを解析して別々のプロバイダのリクエスト（たとえば、ＢＡＳＩＣ（Ｇｒｏｕｐ１）ＪＩＭ／ＭＡＮＡＧＥＲ、ＩＰ（ＩＰ＿ＬＩＳＴ）１９２．６．２５．３）とする。ステップ７１２において、認証エンジン６０２は、それらプロバイダのリクエストをオブジェクトリクエストブローカ２８２を介して認証ホスト６０４に送信し、これらはそこから適切なプロバイダへと分配される。
【０１４４】
ステップ７１４において、認証ホスト６０４は、プロバイダのリクエストを適切なプロバイダに送信する。この例においては、ＢＡＳＩＣ（ＧＲＯＵＰ１）ＪＩＭ／ＭＡＮＡＧＥＲというプロバイダのリクエストはプロバイダ６０６に送られ、ＩＰ（ＩＰ＿ＬＩＳＴ）１９２．６．２５．３というプロバイダのリクエストはプロバイダ６０８に送られる。ステップ７１６において、各プロバイダは、それらが受取ったプロバイダのリクエスト内に含まれる情報に基づいて、カートリッジへのアクセスが許可されるべきかどうかを判定する。ステップ７１８において、各プロバイダは、認証ホスト６０４およびオブジェクトリクエストブローカ２８２を介して認証エンジン６０２へと応答メッセージを送信する。この例においては、プロバイダ６０６および６０８が応答メッセージを認証エンジン６０２に送信する。
【０１４５】
ステップ７２０において、認証エンジン６０２は、認証のリクエストに関連づけられた論理演算を行なう。この例においては、認証エンジン６０２は、プロバイダ６０６およびプロバイダ６０８から受取った２つの応答メッセージに対して論理演算「ＡＮＤ」を行なう。ステップ７２２において、認証エンジン６０２は認証の結果を、オブジェクトリクエストブローカ２８２を介してディスパッチャ２１４に知らせる。
【０１４６】
ステップ７２４において、ディスパッチャ２１４は、この認証エンジン６０２から送られてきた認証の結果を使用して、ブラウザのリクエストが認証されたかどうかを判定する。ブラウザのリクエストが認証されなかった場合には、ディスパッチャ２１４はブラウザのリクエストが認証されずカートリッジのアクセスが拒絶されたことを、ブラウザ２０２に通知する。その後、制御はステップ７０２に戻って、別のブラウザのリクエストを受信する。
【０１４７】
これに対し、ブラウザのリクエストが認証された場合には、ディスパッチャ２１４はそのブラウザのリクエストを適切なカートリッジにディスパッチする。その後、制御はステップ７０２に戻って、別のブラウザのリクエストを受取る。
【０１４８】
負荷の最適配分
認証エンジンおよび認証ホストが実行を開始するとき、それらはまず、オブジェクトリクエストブローカ２８２が認証サーバの負荷の最適配分を行なうことができるようにする特定の情報をメタデータとしてウェブアプリケーションサーバ２８０に格納することによって、ウェブアプリケーションサーバ２８０に登録する。したがって、一実施例に従えば、認証エンジンは、実行を開始するときに、自身を認証エンジンと識別するその名前および関連のＩＤをメタデータとしてウェブアプリケーションサーバ２８０に格納することで、ウェブアプリケーションサーバ２８０に登録する。認証エンジンに関連づけられたメタデータは、オブジェクトリクエストブローカ２８２が、システムの負荷の最適配分を行なうのに使用する。
【０１４９】
認証エンジンに加えて、認証ホストも、実行を開始するときに、自身を認証ホストと識別するその名前および関連のＩＤをメタデータとしてウェブアプリケーションサーバ２８０に格納することで、ウェブアプリケーションサーバ２８０に登録する。さらに、認証ホストに関連づけられる１または複数のプロバイダを識別するメタデータも格納される。
【０１５０】
図８は、本発明の一実施例に従った、ステートレスなウェブ環境において拡張可能な認証機構の負荷の最適配分を行なうことのできる、システム８００のブロック図である。図８は図６と同様であるので、同じ構成要素には同じ参照番号が付されている。
【０１５１】
図８に示すように、認証サーバ８２８は、オブジェクトリクエストブローカ２８２に接続されてそれと通信する、複数の認証エンジン８０２、８０４および８０６を含む。認証サーバ８２８はまた、オブジェクトリクエストブローカ２８２にさらに接続されかつそれと通信する、複数の認証ホスト８０８、８１４および８２２を含む。図示されるように、認証ホスト８０８、８１４および８２２は各々、複数のプロバイダと関連づけられている。
【０１５２】
ディスパッチャは、認証エンジンと通信したいときには、オブジェクトリクエストブローカ２８２から認証エンジンを割当ててもらうよう要求する。特定の認証エンジンを識別する際に、オブジェクトリクエストブローカ２８２は、負荷の最適配分方式を使用して認証エンジンの作業量の最適配分を試みる。その後、オブジェクトリクエストブローカ２８２は、使用されるべき特定の認証エンジンを識別し、その特定の認証エンジンへと、オブジェクトリクエストブローカ２８２を介して認証のリクエストを送信する。
【０１５３】
認証エンジンは、認証のリクエストを受取ると、その認証リクエストを解析して１または複数のプロバイダのリクエストとする。その後、認証エンジンは、オブジェクトリクエストブローカ２８２に対して、それら１または複数のプロバイダのリクエストを処理することのできるプロバイダに関連する１または複数の認証ホストを識別するように要求する。この１または複数の認証ホストを識別する際にも、オブジェクトリクエストブローカ２８２はやはり負荷の最適配分方式を使用して、認証ホストの作業量の最適配分を試みる。オブジェクトリクエストブローカ２８２は、これら１または複数の認証ホストを識別した後に、１または複数のプロバイダのリクエストをオブジェクトリクエストブローカ２８２を介して１または複数の認証ホストへと送る。その後、これら１または複数の認証ホストが、それらプロバイダのリクエストを適切なプロバイダへと分配する。
【０１５４】
プロバイダは、プロバイダのリクエストの認証を完了すると、関連する認証ホストおよびオブジェクトリクエストブローカ２８２を介して認証エンジンへと応答メッセージを送り返す。１または複数のプロバイダから応答メッセージを受取ると、認証エンジンは、戻された応答メッセージに対して必要な論理演算を行なう。その後、認証エンジンは、ブラウザのリクエストが適切なカートリッジへと送られるべきか、それとも、送信側のブラウザに対してアクセスが拒絶されたことを知らせるべきかを、ディスパッチャに通知する。
【０１５５】
カートリッジの認証
ディスパッチャに加えて、カートリッジもまた、ブラウザのリクエストを認証する能力を有する。本発明の一実施例に従えば、ディスパッチャが認証が不要である（すなわち、ブラウザのリクエストＵＲＬに関連づけられたプロテクトストリングが存在しない）と判定すると、ディスパッチャはそのブラウザのリクエストを関連するカートリッジにディスパッチして、カートリッジ自身の認証ルーチンを起動する。カートリッジにおける認証ルーチンのロジックが、認証ルーチンの起動に対してカートリッジがどのように応答するのかを判定する。カートリッジの使用が制限されていなければ、カートリッジの認証メソッドは単に、「ＴＲＵＥ」を戻すであろう。
【０１５６】
これに対し、認証が必要とされる場合には、認証メソッドは、ブラウザのリクエストを認証するために認証サーバと通信することができる。たとえば、この認証メソッドは、上述のディスパッチャと同じ態様で、カートリッジが認証サーバ８２８と相互作用するようにすることもできる。一実施例においては、ブラウザのリクエスト自体を認証するために、各カートリッジは、ディスパッチャが使用したであろうのと同じ認証リクエストフォーマット（すなわち、プロテクトストリングフォーマット）を使用する。しかし、カートリッジには関連したプロテクトストリングが存在しないため、カートリッジ自身が、どの認証パラメータを使用すべきかを判定する。
【０１５７】
カートリッジが認証を行なうことを決めた場合、カートリッジはオブジェクトリクエストブローカ２８２から認証エンジンを割当ててもらうように要求する。特定の認証エンジンを識別するのに、オブジェクトリクエストブローカ２８２は負荷の最適配分方式を使用して、認証エンジンの作業量の最適配分を試みる。その後、オブジェクトリクエストブローカ２８２は使用すべき特定の認証エンジンを識別して、カートリッジに通知する。するとカートリッジは、認証リクエストをその特定の認証エンジンへと、オブジェクトリクエストブローカ２８２を介して送信する。
【０１５８】
認証エンジンは、認証リクエストを受取ると、その認証リクエストを解析して１または複数のプロバイダのリクエストとする。その後、認証エンジンはオブジェクトリクエストブローカ２８２に対して、それら１または複数のプロバイダのリクエストを処理することのできるプロバイダに関連づけられた１または複数の認証ホストを識別するように要求する。この１または複数の認証ホストを識別する際に、オブジェクトリクエストブローカ２８２はやはり負荷の最適配分方式を使用して、それら認証ホストの作業量の最適配分を試みる。オブジェクトリクエストブローカ２８２は、１または複数の認証ホストを識別して、認証エンジンに通知する。すると、認証エンジンは、１または複数のプロバイダのリクエストをオブジェクトリクエストブローカ２８２を介してそれら１または複数の認証ホストに送信する。１または複数の認証ホストはその後、それらプロバイダのリクエストを適切なプロバイダへと分配する。
【０１５９】
プロバイダは、プロバイダのリクエストの認証を完了すると、関連する認証ホストおよびオブジェクトリクエストブローカ２８２を介して認証エンジンへと応答メッセージを送り返す。１または複数のプロバイダから応答メッセージを受取ると、認証エンジンはそれら戻された応答メッセージに対して必要な論理演算を行なう。その後、認証エンジンはカートリッジに対して、ブラウザのリクエストがカートリッジにアクセスすることを許可されるべきかどうかを通知する。
【０１６０】
本発明は、クライアントのリクエストを認証するための、非常にスケーラブルで柔軟性がありかつ拡張可能な機構を提供する。多くの利点はこの開示から当業者には明らかであろうが、ここで、いくつかの特定の利点に注目されたい。
【０１６１】
第１に、認証サーバが分散型であることに留意されたい。基礎をなす通信機構としてオブジェクトリクエストブローカが使用されるので、また、このオブジェクトリクエストブローカがマシンとは独立した通信機構であるので、認証エンジンおよび認証ホスト等の種々の構成要素を異なるマシンのどのような組合せ上にも設けることができる（すなわち分散することができる）。それらマシンは、その構成にかかわらず、オブジェクトリクエストブローカを介して互いに通信することができるであろう。本発明のこの分散型という性質によって、能力の追加が最も必要とされる場所に、戦略的にマシンを追加することができる。たとえば、認証能力の増強が必要とされる場合には、追加の認証エンジンを実行するようマシンを追加することができる。マシンを追加することによってシステムを自由に拡張することができることで、本発明は非常にスケーラブルとなっている。
【０１６２】
第２に、本発明は負荷の最適配分によって効率を改善している。上述のように複数の認証エンジンおよび認証ホストの間で負荷を最適配分することによって、本発明はボトルネックの可能性を最小に抑え、かつ、利用可能なリソースを最大限に効率的に使用することができる。
【０１６３】
第３に、本発明は、配置時にシステムの実装を変更することができる。前述のように、各プロバイダは好ましくはＤＬＬの形をとり、ランタイムにシステムへとリンク・インすることができる。プロバイダのモジュールがランタイムにリンク・インされるので、配置時において（１）あるプロバイダを別のプロバイダに置換すること、および（２）システムに別のプロバイダを付加することができる。認証サーバのアーキテクチャによって、これらすべては他のモジュール（たとえば認証エンジンおよび認証ホスト）をいずれも変更または再コンパイルすることなく行なうことができる。プロバイダのその置換／付加を反映するようにメタデータを更新するだけでよい。この局面によって、本発明は非常に柔軟性がありかつ容易に拡張可能となっている。さらに、特定のクエリーに関連する認証方式を、配置時に容易に変更することができることにも留意されたい。このためには、そのクエリーに関連づけられたプロテクトストリングを変更するだけでよい。したがって、たとえば、現時点においてＢＡＳＩＣおよびＩＰ認証方式を要求しているクエリーを、プロテクトストリングを単に
URL1 CARTRIDGE＿238 BASIC(GROUP1) AND IP(IP＿LIST)
から
URL1 CARTRIDGE＿238 IP(IP＿LIST)
へと変更するだけで、ＩＰ方式のみを要求するように変更することができる。
【０１６４】
したがって、配置時におけるサーバの実装の変更は極めて容易である。
第４に、本発明が、カートリッジからのリクエストを認証する作業の、すべてではないにせよその大半を取除くことができることに留意されたい。各カートリッジに対する認証のプロセスを認証サーバが実現するようにしていることによって、カートリッジがリクエストを認証する必要が軽減される。
【０１６５】
以上のように、本発明は、クライアントのリクエストを認証するための非常に有効でありかつ有益な機構を提供する。
【０１６６】
以上、本明細書において、本発明を特定の実施例に関連して説明した。しかし、本発明のより広い範囲から離れることなく、それら実施例に対して種々の変形および変更を行なうことができることは明らかであろう。したがって、本明細書および添付の図面は、限定のためのものではなく例示のためのものであると理解されたい。
【図面の簡単な説明】
【図１】 本発明の一実施例が実装され得るコンピュータシステムのブロック図である。
【図２】 本発明の一実施例に従った、分散アプリケーションサーバのブロック図である。
【図３Ａ】 本発明の一実施例に従った、ブラウザリクエストを処理するためのステップを示すフローチャートの一部である。
【図３Ｂ】 本発明の一実施例に従った、ブラウザリクエストを処理するためのステップを示すフローチャートの別の部分である。
【図４】 本発明の一実施例に従った、ディスパッチャが維持する情報を含む表のブロック図である。
【図５】 本発明の一実施例に従った、リソースマネージャが維持する情報を含む表のブロック図である。
【図６】 本発明の一実施例に従った、ステートレスウェブ環境において拡張可能な認証機構を提供する分散型のアプリケーションサーバのブロック図である。
【図７Ａ】 本発明の一実施例に従った、ブラウザのリクエストを認証するためのステップを示すフローチャートの一部である。
【図７Ｂ】 本発明の一実施例に従った、ブラウザのリクエストを認証するためのステップを示すフローチャートの別の部分である。
【図８】 本発明の一実施例に従った、ステートレスウェブ環境において拡張可能な認証機構の負荷の最適配分を行なうことのできる分散型のアプリケーションサーバのブロック図である。
【発明の分野】
本発明は、ネットワーク接続されたコンピュータシステムにおけるクライアントのオペレーションの認証に関し、より特定的には、ステートレスなウェブ環境におけるブラウザのリクエストの認証に関する。
【０００２】
【発明の背景】
ワールド・ワイド・ウェブ（World Wide Web）はインターネット（Internet）上のサーバのネットワークを含み、その各々は１つ以上のＨＴＭＬ（Hypertext Markup Language：ハイパテキスト・マークアップ言語）ページに関連付けられている。サーバに関連付けられているＨＴＭＬページは、情報と、そのサーバおよび（通常は）他のサーバ上の他の文書へのハイパテキストリンクとを提供する。サーバはハイパテキスト・トランスファー・プロトコル（ＨＴＴＰ：Hypertext Transfer Protocol）を用いてクライアントと通信する。サーバはクライアントからのＨＴＭＬページに関するリクエストを聞くことから、多くの場合、「リスナ」と称される。
【０００３】
ワールド・ワイド・ウェブのユーザはブラウザと呼ばれるクライアントプログラムを用いてリスナから情報をリクエストし、デコードし、表示する。ブラウザのユーザがあるＨＴＭＬページ上のリンクを選択すると、そのページを表示しているブラウザはそのリンク内で特定されるユニバーサル・リソース・ロケータ（ＵＲＬ：Universal Resource Locator）と関連付けられるリスナにインターネットを通じてリクエストを送る。そのリクエストに応答して、リスナはそのリクエストを発行したブラウザにリクエストされた情報を送信する。ブラウザは情報を受取り、受取った情報をユーザに示し、次のユーザリクエストを待つ。
【０００４】
従来、リスナに蔵置される情報は静的ＨＴＭＬページの形態である。静的ＨＴＭＬページは、ウェブブラウザからのリクエストに先立ち作成されリスナに蔵置される。リクエストに応答して、静的ＨＴＭＬページが単に記憶から読出され、リクエストを行なっているブラウザに送信される。現在、ブラウザリクエストに応答して動的オペレーションを行なうリスナを開発しようとする趨勢にある。たとえば、リスナはリクエストに応答する際にデータベースにクエリーを発行し、そのクエリーの結果を含むウェブページを動的に構成し、動的に構成されたＨＴＭＬページをリクエストを行なっているブラウザに送信してもよい。動的オペレーションを行なうために、リスナの機能性を向上または増強させなければならない。動的オペレーションをサポートするようリスナを拡張するためにさまざまなアプローチが開発されてきた。
【０００５】
インターネット上のサーバには複数のクライアントがアクセスすることができるので、ある情報に対する無許可のアクセスに対して保護がなされるように、いくつかの保護方式が開発されてきている。ある情報に対する無許可のアクセスを阻止するのに使用される方法の１つは、クライアントが特定のサーバ上の情報に対してアクセスしようとする場合、アクセスを許可する前に、そのクライアントに対して何らかの許可情報を提供するように求める方法である。この許可情報は典型的に、ユーザ名およびパスワード、特定のＩＰアドレス、特定のドメイン名または、情報にアクセスを試みている特定のユーザおよび／またはマシンを識別することのできる他の情報、等の項目を含む。
【０００６】
許可機構を実現するための１つの方法として、認証プロセスを各サーバに関連付ける方法がある。許可のプロセスが、クライアントのリクエストを代行受信して、そのクライアントがそのサーバに関連付けられた情報に対してアクセスできるかどうかを判定する。したがって、クライアントが特定のサーバ上の情報に対してアクセスを試みるたびに、そのサーバに関連付けられた認証のプロセスがまず、そのクライアントがその情報へのアクセスを許可されていることを検証する。
【０００７】
このサーバ単位で認証プロセスを行なう方法は、サーバに関連付けられたＨＴＭＬページが保護されるべき項目である場合にはうまく機能する。しかし、サーバを使用して、そのサーバ以外のマシン上で実行されている可能性のあるコンピュータプログラムにアクセスしてそのプログラムを実行するようなシステムにおいては、この方法では必要とされる柔軟性を提供することができない場合がある。たとえば、バンキングアプリケーションとデータベースアプリケーションとの両方が特定のサーバを介してブラウザによってアクセス可能であるものとする。この場合、バンキングアプリケーションには、データベースアプリケーションとは全く異なる認証機構が必要であるかもしれないし、他のサーバの使用に対してはどのような認証も全く必要でないかもしれない。
【０００８】
以上のことから、ＨＴＴＰサーバを介して利用可能なリソースに対するアクセスを限定する、認証機構を提供することが明らかに望ましい。また、同じＨＴＴＰサーバを介してアクセスすることのできる複数のアプリケーションに対して、異なる認証プロトコルをサポートすることができるほど十分に柔軟性のある、認証機構を提供することが望ましい。
本発明の背景および本発明の実施例によって解決される問題のさらなる詳細は、 Nigel Edwards および Owen Rees による文献、「セキュリティに優れたウェブサーバおよびゲートウェイ（ "High security Web servers and gateways") 」、 COMPUTER NETWORKS AND ISDN SYSTEMS, 29, (1997) 927-938 、に記載されている。
【０００９】
【発明の概要】
本発明は、クライアントからのリクエストを認証するための、スケーラブルな、柔軟性のある、拡張可能な機構を提供する。好ましい実施例においては、本発明は、認証エンジン、認証ホスト、およびホストに連結された複数のプロバイダを含み、各プロバイダは選択された認証方式を実現する。好ましい実施例においては、プロバイダの各々は、ダイナミックリンクライブラリ（ＤＬＬ）等のような、ランタイムに動的にリンク・インすることのできる、モジュールの形をとる。
【００１０】
本発明は、好ましくは、種々の構成要素がマシンの境界を超えて互いに通信することができるようにする、マシンとは独立した通信機構をさらに含む。この通信機構によって、本発明の種々の構成要素は、各構成要素がどのマシン上に備えられているかにかかわらず、互いに通信することができる。好ましい実施例においては、通信機構はオブジェクトリクエストブローカの形をとる。種々の構成要素を異なるマシン上に設けることができるので、本発明は分散型であると言える。この分散型の性質により、本発明は非常にスケーラブルなものとなっている。
【００１１】
オブジェクトリクエストブローカは、通信機構として機能するのに加えて、好ましくは、負荷の最適配分機能もまた行なう。より特定的には、このブローカは、認証エンジンおよび認証ホストへのリクエストの送信を、ボトルネックの可能性を最小限にし、かつ利用可能なリソースの使用を最大限にするよう、調整する。この機能を行なうのに、ブローカは、各プロバイダがシステム内に導入されるときにそのプロバイダに対して登録される、メタデータを利用する。
【００１２】
動作中、認証エンジンは、プロテクトストリングと関連付けられているリクエストを受取る。プロテクトストリングは、とりわけ、そのリクエストに対して実現されるべき１以上の認証方式、および、その方式の結果に適用されるべき１以上の論理演算子（たとえばＡＮＤ、ＯＲ）を特定する。リクエストを受取ると、認証エンジンは、プロテクトストリングを解析して１または複数のプロバイダのリクエストとし、それらのリクエストをオブジェクトリクエストブローカを介して認証ホストに送信する。これに応じて、ホストは、それらのリクエストを適切なプロバイダへと送り、そこでリクエストの処理が行なわれる。プロバイダは処理を完了すると、その結果を認証ホストおよびオブジェクトリクエストブローカを介して認証エンジンへと戻す。その後、認証エンジンが、プロテクトストリングにおいて特定された論理演算子に従って結果を処理して、そのリクエストが認証されたかどうかを判定する。
【００１３】
本発明によれば、システムの実装を配置時に変更することができる。前述のように、各プロバイダは好ましくは、ランタイムにシステムにリンク・インすることのできるＤＬＬの形をとる。プロバイダがランタイムにリンク・インされるので、配置時に（１）あるプロバイダを別のプロバイダと置換したり（２）別のプロバイダをシステムに付加したりすることができる。本発明のアーキテクチャは、これらすべてを、他のどのモジュール（たとえば認証エンジンおよび認証ホスト）も変更したり再コンパイルしたりすることなく、行なうことができるようにしている。プロバイダの置換／付加に必要なのは、プロバイダのその置換／付加を反映するようメタデータを更新することのみである。さらに、特定のクエリーに関連付けられた認証方式を変更することも可能である。これは単に、そのクエリーに関連付けられたプロテクトストリングを変更することによって行なうことができる。やはり再コンパイルは不要である。これらの局面のおかげで、本発明においては、コンパイル時ではなく配置時に実装を変更することができる。これにより、本発明は非常に柔軟かつ拡張可能となっている。
【００１４】
これらおよび他の利点は、本発明がさらに詳細に説明されるにつれて明らかとなるであろう。
【００１５】
本発明は、限定のためではなく例示する目的で、添付の図面に示される。添付の図面において類似の参照番号は類似の要素を指す。
【００１６】
【好ましい実施例の詳細な説明】
ステートレスなウェブ環境においてブラウザのリクエストを認証するための方法および装置を説明する。以下において説明のため、この発明の完全な理解をもたらすように数多くの特定の詳細事項を挙げている。しかしながら、当業者にはこの発明がこれらの特定の詳細事項がなくても実施できることが明らかになるであろう。場合によっては不必要にこの発明を曖昧にすることを避けるため周知の構造および装置をブロック図の形態で示している。
【００１７】
ハードウェアの概観
図１は、この発明の実施例が実装され得るコンピュータシステム１００を示すブロック図である。コンピュータシステム１００は、バス１０２または情報を通信するための他の通信機構と、バス１０２に結合され情報を処理するためのプロセッサ１０４とを含む。コンピュータシステム１００はまた、バス１０２に結合され情報およびプロセッサ１０４が実行すべき命令を蔵置するための、ランダムアクセスメモリ（ＲＡＭ）または他の動的記憶装置などのメインメモリ１０６を含む。メインメモリ１０６はまた、プロセッサ１０４が実行すべき命令の実行の間に一時変数または他の中間情報を蔵置するのに用いられてもよい。コンピュータシステム１００はさらに、バス１０２に結合され静的情報およびプロセッサ１０４に対する命令を蔵置するための読取専用メモリ（ＲＯＭ）１０８または他の静的記憶装置を含む。磁気ディスクまたは光ディスクなどの記憶装置１１０が設けられ、バス１０２に結合されて情報および命令を蔵置する。
【００１８】
コンピュータシステム１００はバス１０２を介して、陰極線管（ＣＲＴ）などの表示装置１１２に結合されコンピュータユーザに対して情報を表示してもよい。英数字および他のキーを含む入力装置１１４がバス１０２に結合され、情報およびコマンド選択をプロセッサ１０４に伝える。別のタイプのユーザ入力装置は、プロセッサ１０４に方向情報およびコマンド選択を伝え、かつ表示装置１１２上のカーソル移動を制御するためのマウス、トラックボールまたはカーソル方向キーなどのカーソル制御装置１１６である。この入力装置は典型的に２つの軸、すなわち第１の軸（たとえばｘ）および第２の軸（たとえばｙ）において２つの自由度を有し、これは装置が平面上の位置を特定できるようにする。
【００１９】
この発明は、コンピュータシステム１００を用いて、ステートレスなウェブ環境においてブラウザの要求を認証することに関する。この発明の一実施例によれば、ブラウザの要求の認証は、プロセッサ１０４がメインメモリ１０６に含まれる１つ以上の命令の１つ以上のシーケンスを実行することに応答して、コンピュータシステム１００によって行なわれる。このような命令は、記憶装置１１０などの別のコンピュータ可読媒体からメインメモリ１０６に読込んでもよい。メインメモリ１０６に含まれる命令のシーケンスを実行することにより、プロセッサ１０４がここに説明するプロセスステップを実行することとなる。代替の実施例では、ソフトウェア命令の代わりに、またはソフトウェア命令と併せて結線回路を用いてこの発明を実現してもよい。すなわち、この発明の実施例はハードウェア回路およびソフトウェアの如何なる特定の組合せにも限定されない。
【００２０】
「コンピュータ可読媒体」という用語はここでは、実行のためにプロセッサ１０４に命令を提供するのにかかわるすべての媒体を指して用いる。このような媒体は、不揮発性媒体、揮発性媒体および伝送媒体を含むが、これらに限定されない数多くの形態を取り得る。不揮発性媒体には、たとえば、記憶装置１１０などの光ディスクまたは磁気ディスクが含まれる。揮発性媒体には、メインメモリ１０６などのダイナミックメモリが含まれる。伝送媒体には、バス１０２を構成するワイヤを含む、同軸ケーブル、導線および光ファイバが含まれる。伝送媒体はまた、電波および赤外線データ通信において生成されるもののような音波または光波の形態を取ることもある。
【００２１】
コンピュータ可読媒体の一般的な形態にはたとえば、フロッピーディスク、フレキシブルディスク、ハードディスク、磁気テープまたは何らかの他の磁気媒体、ＣＤ−ＲＯＭおよび何らかの他の光媒体、パンチカード、せん孔テープおよび孔のパターンを有する何らかの他の物理的媒体、ＲＡＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＦＬＡＳＨ−ＥＰＲＯＭおよび何らかの他のメモリチップまたはカートリッジ、以下に説明するような搬送波、またはコンピュータが読むことのできるものであればどのような他の媒体でも含まれる。
【００２２】
実行のために１つ以上の命令の１つ以上のシーケンスをプロセッサ１０４に与える上でさまざまな形態のコンピュータ可読媒体がかかわり得る。たとえば、命令は初めに遠隔コンピュータの磁気ディスク上に担持されてもよい。遠隔コンピュータは命令をそのダイナミックメモリにロードし、その命令をモデムを用いて電話回線を介して送ることができる。コンピュータシステム１００がローカルに有するモデムが電話回線上でデータを受取り、赤外線送信機を用いてそのデータを赤外線信号に変換できる。バス１０２に結合される赤外線検出器は赤外線信号で運ばれるデータを受取り、そのデータをバス１０２上に出力することができる。バス１０２はそのデータをメインメモリ１０６へ運び、そこからプロセッサ１０４は命令を取出して実行する。メインメモリ１０６が受取った命令は場合により、プロセッサ１０４による実行の前または後に記憶装置１１０に蔵置されてもよい。
【００２３】
コンピュータシステム１００はまた、バス１０２に結合される通信インターフェイス１１８を含む。通信インターフェイス１１８はローカルネットワーク１２２に接続されるネットワークリンク１２０への両方向データ通信結合を提供する。たとえば、通信インターフェイス１１８は、対応するタイプの電話回線に対してデータ通信接続を提供するサービス統合デジタル網（ＩＳＤＮ）カードまたはモデムであってもよい。別の例としては、通信インターフェイス１１８は、互換性のあるローカル・エリア・ネットワーク（ＬＡＮ）に対するデータ通信接続を提供するローカル・エリア・ネットワーク（ＬＡＮ）カードであってもよい。また、無線リンクを実現してもよい。このような実現例のいずれにおいても、通信インターフェイス１１８はさまざまなタイプの情報を表わすデジタルデータストリームを運ぶ電気信号、電磁気信号または光信号を送受信する。
【００２４】
ネットワークリンク１２０は典型的に１つ以上のネットワークを介して他のデータ装置へのデータ通信を提供する。たとえば、ネットワークリンク１２０はローカルネットワーク１２２を介してホストコンピュータ１２４または、インターネットサービスプロバイダ（ＩＳＰ：Internet Service Provider）１２６により運用されるデータ装置に対する接続を提供してもよい。ＩＳＰ１２６はこれを受けて、現在一般的に「インターネット」１２８と称される世界規模のパケットデータ通信網を介するデータ通信サービスを提供する。ローカルネットワーク１２２およびインターネット１２８はともに、デジタルデータストリームを運ぶ電気信号、電磁気信号または光信号を用いる。コンピュータシステム１００へまたはコンピュータシステム１００からデジタルデータを運ぶ、さまざまなネットワークを介する信号およびネットワークリンク１２０上の、通信インターネット１１８を介する信号は情報を運ぶ搬送波の典型的な形態である。
【００２５】
コンピュータシステム１００はネットワーク、ネットワークリンク１２０および通信インターネット１１８を介して、メッセージを送り、プログラムコードを含むデータを受取ることができる。インターネットの例では、サーバ１３０はインターネット１２８、ＩＳＰ１２６、ローカルネットワーク１２２および通信インターネット１１８を介してアプリケーションプログラムに対するリクエストされたコードを送信するかもしれない。
【００２６】
受取られたコードはそれが受取られると同時にプロセッサ１０４によって実行され、および／または後に実行するために記憶装置１１０または他の不揮発性記憶に蔵置されてもよい。このように、コンピュータシステム１００は搬送波の形態でアプリケーションコードを得ることもある。
【００２７】
アプリケーションサーバ機能の概要
図２は、この発明の一実施例に従って設計されたシステム２００のブロック図である。システム２００は、ＨＴＴＰプロトコルに従ってインターネット２０８にわたって複数のリスナ２１０、２１６および２２２と通信する複数のブラウザ２０２、２０４および２０６を含む。ブラウザからのリクエストに応答して、リスナはウェブアプリケーションサーバ２８０にここでカートリッジと称するソフトウェアモジュールを呼出させる。例示の実施例では、ウェブアプリケーションサーバ２８０は３つのカートリッジ２３０、２３４および２３８の実行を開始している。
【００２８】
ウェブアプリケーションサーバ２８０は、トランスポート・アダプタ２１２、２１８および２２４、ディスパッチャ２１４、２２０および２２６、認証サーバ２５２、仮想パスマネージャ２５０、リソースマネージャ２５４、コンフィギュレーションプロバイダ２５６および複数のカートリッジ実行エンジン２２８、２３２および２３６を含む、数多くの構成要素からなる。ウェブアプリケーションサーバ２８０のさまざまな構成要素について以下により詳しく説明する。
【００２９】
重要なことであるが、ウェブアプリケーションサーバ２８０の数多くの構成要素はオブジェクトリクエストブローカ（Object Request Broker）２８２などのマシン間通信機構を介して通信する。マシン間通信機構を用いることにより、ブラウザリクエストにおいて特定されるオペレーションを実行するカートリッジインスタンスは、リクエストを受取るリスナおよびリクエストを発行するブラウザとは異なるマシン上で実行することができる。カートリッジ・インスタンスがリスナとは異なるマシン上にあるため、リスナは障害のあるカートリッジ・インスタンスからよりよく隔離されることとなり、システムの信頼性および安全性が向上する。さらに、リスナが実行されるマシンと同じマシンでなく、数多くのマシン間でカートリッジインスタンスを実行する処理の負担を分散することによってシステムのスケーラビリティが大幅に増加する。複数のマシンにわたってカートリッジ・インスタンスの実行を分散できることから、いつどこで新しいカートリッジ・インスタンスを生じさせるかを決定するのに数多くのタイプの負荷の最適配分の技法を用いることができる。
【００３０】
システム２００内の典型的なオペレーションには一般的に以下の段階が含まれる。
ブラウザがインターネット２０８にわたってリクエストを送信する。
【００３１】
リスナがそのリクエストを受取ってトランスポートアダプタを介してディスパッチャに渡す。
【００３２】
ディスパッチャは、仮想パスマネージャ２５０と通信して、ブラウザのリクエストによって選択されたカートリッジを識別し、かつ、そのカートリッジが認証を必要としているかどうかを判定する。
【００３３】
カートリッジが認証を必要としていれば、ディスパッチャは認証サーバ２５２と通信して、そのブラウザがその選択されたカートリッジにアクセスすることを許可されているかどうかを判定する。
【００３４】
認証サーバ２５２が、そのブラウザがその選択されたカートリッジに対してアクセスすることを許可されていないと判定した場合には、そのブラウザにはアクセスが拒絶されたことが通知される。
【００３５】
しかし、アクセスが許可されているか、または、仮想パスマネージャ２５０が認証が不要であると判定した場合には、ディスパッチャは２つのうち一つを行なう。ディスパッチャがそのカートリッジに関する使用されていないインスタンスのことを知っている場合、ディスパッチャはそのインスタンスにリクエストを送る。そのカートリッジに関して使用されていないカートリッジインスタンスがない場合、ディスパッチャはリソースマネージャ２５４に新しいカートリッジインスタンスを作るよう依頼する。そのインスタンスがうまく起動した後に、カートリッジはその存在をリソースマネージャに知らせる。リソースマネージャ２５４はそこで、ディスパッチャに新しいインスタンスのことを知らせる。ディスパッチャはブラウザリクエストに基づいて変更されたリクエストを作り、その変更されたリクエストを新しいインスタンスに送る。
【００３６】
カートリッジインスタンスはその変更されたリクエストを処理して、ディスパッチャに応答を送る。
【００３７】
ディスパッチャはその応答をリスナを介してクライアントに戻す。
これらの段階について以下により詳しく説明する。
【００３８】
カートリッジ
カートリッジは特定のアプリケーションまたはシステム機能を行なうためのコードのモジュールである。カートリッジはシステム２００における分散の基本単位を形成する。この発明の一実施例によれば、カートリッジはユニバーサル・リソース・ロケータ（ＵＲＬ）を用いて名付けられる。すなわち、カートリッジ名（すなわちＵＲＬ）には２つの部分、すなわちカートリッジが存在するサーバのＩＰアドレスと、コンパイルされたカートリッジコードのサーバディレクトリ構造における仮想パスとがある。カートリッジはＵＲＬを用いて名付けられるため、カートリッジ名空間はグローバルであり、文書などの他のウェブリソースにアクセスするのに用いられるのと同じメッセージ通信技術を用いてカートリッジにアクセスすることができる。
【００３９】
この発明の一実施例によれば、各カートリッジはすべてのカートリッジに対して共通の全体構造をもたらす標準インターフェイスを有する。この標準インターフェイスは、特定の条件の下でウェブアプリケーションサーバ２８０により呼出されるルーチンのインターフェイスを規定する。この発明の一実施例によれば、抽象カートリッジインターフェイスは以下のとおりである。
【００４０】
【表１】
init()ルーチンはカートリッジインスタンスを初期化する役割を果たす。このことには、いくつかのサブオブジェクトのコンストラクタを呼出すことと、スレッドを予め分岐させることと、他のすべての必要となる共用リソースを獲得することとが含まれ得る。
【００４２】
shutdown()ルーチンはすべてのリソースを片付けカートリッジインスタンスをシャットダウンする役割を果たす。カートリッジインスタンスに対して一度shutdown()ルーチンが呼出されると、直ちにカートリッジインスタンスは後続のリクエストを処理するのに利用不可能となる。
【００４３】
authenticate()ルーチンではカートリッジのサービスをリクエストしているクライアントがそのサービスを用いることを許可されているかどうかを検証する。
【００４４】
exec()ルーチンはカートリッジに対してすべてのサービスリクエストをディスパッチする包括的なやり方である。
【００４５】
例示的カートリッジ
各カートリッジは、明確に定義された機能を行なうカートリッジとして構成されるか、またはあるアプリケーションのためのインタプリタまたはルーチン環境として作用するプログラム可能なカートリッジとして構成される。プログラム可能なカートリッジの一例はＰＬ／ＳＱＬランタイムであり、これは構造的問合せ言語（Structured Query Language）を用いるオラクルベースのプログラム言語（Oracle-based Programming Language）（ＰＬ／ＳＱＬ）に従ってデータベースクエリーを処理するよう構成される。ＰＬ／ＳＱＬランタイムはデータベースクエリーを有するブラウザリクエストを実行する。ＰＬ／ＳＱＬランタイムは、たとえば、データリンクを介してカートリッジインスタンスと通信しているデータベースサーバにアクセスすることによってリクエストを処理する。
【００４６】
プログラム可能なカートリッジの別の例はＪＡＶＡランタイムインタプリタである。ＪＡＶＡランタイムインタプリタカートリッジのおかげで、ウェブアプリケーション開発者らはブラウザリクエストを処理するためのサーバ側のＪＡＶＡアプリケーションを書くことができる。同様に、たとえば第三者のサーバによって実行されるプロセスにアクセスするなどの動的オペレーションをもたらすために、カスタムサーバをカートリッジとして構成してもよい。
【００４７】
ディスパッチャ
ディスパッチャは、リスナが受取ったリクエストを適当なカートリッジへ経路選択するよう構成されるソフトウェアモジュールである。この発明の一実施例によれば、ディスパッチャはサーバ側のプログラム拡張（すなわち、「プラグイン」）として実現される。そのため、ディスパッチャはそれらが属するリスナと同じアドレス空間にロードされそこで実行される。ディスパッチャはコンパイル時にリスナコードとリンクされてもよいし、実行時に動的にロードされてもよい。
【００４８】
例示される実施例では、ディスパッチャ２１４、２２０および２２６はそれぞれ、リスナ２１０、２１６および２２２に関連付けられる。ディスパッチャ２１４、２２０および２２６は、リスナ２１０、２１６および２２２が受取ったブラウザリクエストをカートリッジへ選択的に経路制御する。
【００４９】
たとえば、リスナ２１０がユニフォーム・リソース・ロケータ（ＵＲＬ：Uniform Resource Locator）の形態で運ばれるブラウザリクエストをインターネット２０８から受取ると仮定する。このブラウザリクエストは、たとえばＨＴＭＬページまたは実行すべきオペレーションであるウェブオブジェクトに対する識別子の役割を果たす。リスナ２１０はそのブラウザリクエストの解釈を全く試みることなくディスパッチャ２１４に受渡す。ブラウザリクエストを受取ると、ディスパッチャ２１４は、
（１） 仮想パスマネージャ２５０と通信してブラウザリクエストによって選択されるカートリッジを識別し、かつそのカートリッジが認証を要するかどうかを判定し、
（２） そのカートリッジが認証を必要とする場合、認証サーバ２５２と通信してブラウザがその選択されたカートリッジにアクセスすることが許されるかどうかを判定し、
（３） アクセスが許可された場合に、リソースマネージャと通信してブラウザリクエストを送るべき選択されたカートリッジの特定のインスタンスを定め、
（４） カートリッジの特定されたインスタンスによる実行のため、変更されたブラウザリクエストを作りかつディスパッチする。
【００５０】
変更されたブラウザリクエストは元のブラウザリクエストで受取った情報を再パッケージする。変更されたブラウザリクエストはたとえば、カートリッジの正しいオペレーションに必要なデータを含むコンテキストオブジェクトを含んでいてもよい。カートリッジの正しいオペレーションに必要なデータには、たとえば、そのブラウザリクエストが関連付けられるトランザクションを識別するトランザクションＩＤが含まれる。
【００５１】
カートリッジがリクエストに返答すると、そのカートリッジはディスパッチャにその返答を送り、ディスパッチャはこの返答をリスナに渡してそのリクエストを開始したブラウザへ送信されるようにする。
【００５２】
コンフィギュレーションプロバイダ
この発明の一実施例によれば、ウェブアプリケーションサーバ２８０とともに用いるべきカートリッジはまずウェブアプリケーションサーバ２８０に登録される。登録プロセスの間、そのカートリッジに関する情報がコンフィギュレーションプロバイダ２５６に供給される。コンフィギュレーションプロバイダ２５６はその情報をメタデータ２５８として蔵置してウェブアプリケーションサーバ２８０の構成要素が後からアクセスできるようにする。
【００５３】
メタデータ２５８はたとえば、
（１） カートリッジ名、
（２） 必要となるインスタンスの最小数、
（３） インスタンスの最大数、
（４） カートリッジを実装するコードの場所、
（５） コールバック機能（初期化、リクエストハンドラ、シャットダウン）を実行するためカートリッジ実行エンジンが用いるプログラムに依存した関数名、
（６） カートリッジを実行するためのマシンのリスト、
（７） カートリッジのためのアイドルタイム（カートリッジのインスタンスがシャットダウンされる前にアイドル状態でいることができる時間量）、
（８） オブジェクト識別子および
（９） もしあれば、カートリッジとともに用いるべき、認証サービスのタイプを示すデータ
を含んでいてもよい。
【００５４】
オブジェクト識別子は、対応するカートリッジによるオペレーションの実行をリクエストするためにブラウザリクエストが供給しなければならないデータを特定する。オブジェクトタイプは特定のワードまたはＵＲＬであってもよく、または「/java」などの仮想パスを含んでいてもよい。
【００５５】
一度コンフィギュレーションプロバイダ２５６が特定のカートリッジに対するコンフィギュレーション情報をメタデータ２５８内に蔵置すると、そのカートリッジはウェブアプリケーションサーバ２８０が起動される際に自動的に登録される。
【００５６】
カートリッジがウェブアプリケーションサーバ２８０に登録された後、リソースマネージャ２５４はカートリッジに対する最小インスタンスをイニシエートする。一度最小数のインスタンスがイニシエートされると、ウェブアプリケーションサーバ２８０はブラウザリクエストを処理する準備が整う。
【００５７】
仮想パスマネージャ
上に述べたように、ディスパッチャは仮想パスマネージャ２５０と通信して各々の変更されたブラウザリクエストをどこに経路選択するかを定める。特定的には、各ブラウザリクエストは典型的にＵＲＬを含む。ブラウザリクエストを受取ると、ディスパッチャはそのリクエスト内のＵＲＬを仮想パスマネージャ２５０に送る。仮想パスマネージャ２５０はこれに応答して、もしあれば、ＵＲＬに関連付けられるカートリッジを識別するデータをディスパッチャに送る。
【００５８】
必要とされる情報をディスパッチャに供給するため、仮想パスマネージャ２５０はＵＲＬをカートリッジにマッピングするメタデータ２５８を調べる。ブラウザリクエストを受取ったことに応答して、仮想パスマネージャ２５０はマッピングデータを用いて、もしあれば、ブラウザリクエストに含まれるＵＲＬに対応するカートリッジを判定する。
【００５９】
たとえば、ブラウザリクエストが仮想パス「/java」で始まるＵＲＬリクエストである場合、マッピングにより、ＪＡＶＡインタプリタカートリッジが仮想パス「/java」を有するリクエストを取扱うよう構成されていることが示されるかもしれない。
【００６０】
この発明の一実施例によれば、仮想パスマネージャ２５０はまた、ＵＲＬに関連付けられたカートリッジが認証を必要とするかどうかを判定する。カートリッジが認証を要する場合、仮想パスマネージャ２５０はディスパッチャに送る応答において、認証が必要であることを示す。認証が必要でない場合、ディスパッチャは認証サーバ２５２を呼出すことなく、カートリッジのインスタンスに対する変更されたブラウザリクエストを作って送る。認証が必要である場合、変更されたリクエストをカートリッジのインスタンスに送出してもよいことを認証サーバが示した後に初めてディスパッチャはそのカートリッジのインスタンスに変更されたリクエストを送る。
【００６１】
リソースマネージャ
ウェブアプリケーションサーバ２８０のリソースマネージャ２５４は、カートリッジに対して予め定められた最小数のインスタンスをイニシエートし、各カートリッジのインスタンスの間で負荷の最適配分を行ない、所与のカートリッジの予め定められた最大数のインスタンスまで必要に応じてカートリッジの新しいインスタンスをイニシエートすることによってカートリッジの各々の実行を管理する。
【００６２】
たとえば、ある特定のカートリッジ（Ｃ１）のためのメタデータが以下の情報を含んでいると仮定する：
名称＝Ｃ１
最小インスタンス＝１０
最大インスタンス＝５０
ホストマシン＝Ｍ１、Ｍ２、Ｍ３
アイドルタイム＝３０秒
このメタデータに基づいて、カートリッジＣ１が初めに登録される際に、リソースマネージャ２５４はＣ１の１０のインスタンスをイニシエートさせる。リソースマネージャ２５４はラベルＭ１、Ｍ２およびＭ３に関連付けられるマシン上の１０のインスタンスをイニシエートすることになる。
【００６３】
Ｃ１をアクセスするリクエストをディスパッチャから受取った際、リソースマネージャ２５４はＣ１のいずれかの既存のインスタンスが利用可能であるかどうかを判定する。リクエストを受取った際にＣ１のどのインスタンスも利用可能でない場合、リソースマネージャ２５４はＣ１の最大数のインスタンスが既に実行されているかどうかを判定する。Ｃ１の最大数のインスタンスが既に実行されていない場合、リソースマネージャ２５４は可能なホストマシンの１つの上でＣ１の新しいインスタンスをイニシエートし、リクエストを発行したディスパッチャにこの新しいインスタンスを識別するメッセージを送信する。Ｃ１の最大数のインスタンスが既に実行されている場合、リソースマネージャ２５４はリクエストを発行したディスパッチャに対し、その時点でそのリクエストを取扱うことができないことを示すメッセージを送る。
【００６４】
負荷の最適配分
この発明の一実施例によれば、リソースマネージャ２５４は１組の負荷の最適配分の規則を適用して、２つ以上の可能なホストマシンがある中、カートリッジのインスタンスをどこでイニシエートするかを定める。すなわち、上の例では、Ｍ１、Ｍ２およびＭ３はすべてカートリッジＣ１のインスタンスを実行することが可能である。Ｍ１、Ｍ２およびＭ３が同じ処理能力を有する場合、インスタンスを３つのマシンにわたって均等に分散するのが望ましいであろう。しかしながら、Ｍ１がＭ２およびＭ３の１０倍の処理力を有するなら、Ｃ１のインスタンスのすべてをある時点まではＭ１でイニシエートし、それからさらなるインスタンスをＭ１、Ｍ２およびＭ３の間で均等に分散させるのが望ましいであろう。
【００６５】
可能なマシンの間で負荷の最適配分を如何に行なうかを定める上でリソースマネージャ２５４を助けるため、各カートリッジに対して蔵置されるメタデータはさらなる詳細を含んでいてもよい。たとえば、メタデータは各マシンに対してインスタンスの別個の最小および最大数を特定してもよい。その場合リソースマネージャ２５４は、最大のインスタンスに対する現在実行されているインスタンスの比が最も低いマシンはどれかに基づいて、マシン間で新しいインスタンスを分散させることができる。
【００６６】
メタデータはまた、あるカートリッジを実行できるマシンのための順序を特定してもよい。その順序においてＮ＋１の位置にあるマシンは、その順序においてＮ番目の位置にあるマシンが既にその最大数のインスタンスを実行している場合にだけカートリッジのインスタンスを実行するのに用いられる。
【００６７】
カートリッジインスタンスステータスの管理
この発明の一実施例によれば、リソースマネージャ２５４は作られたカートリッジインスタンスを管理するためステート情報を維持する。ステート情報には、インスタンスを識別し、そのインスタンスを実行するマシンを識別し、そのインスタンスが割当てられたリスナを識別するデータが含まれる。
【００６８】
図５には、このステート情報を蔵置するためリソースマネージャ２５４が維持し得る表５００が示される。表５００には、インスタンス列５０２、カートリッジ列５０４、リスナ列５０６およびマシン列５０８が含まれる。表５００の各行は別個のカートリッジインスタンスに対応する。所与のカートリッジインスタンスに対する行内で、カートリッジ列５０４はカートリッジインスタンスに関連づけられるカートリッジを識別し、インスタンス列５０２はそのカートリッジインスタンスのインスタンス番号を示す。たとえば、行５１０はカートリッジＣ１のインスタンスに対応する。このため、行５１０のカートリッジ列５０４はカートリッジＣ１を示す。行５１０のインスタンス列５０２は行５１０に関連づけられるカートリッジインスタンスがカートリッジＣ１のインスタンス１であることを示す。
【００６９】
リスナ列５０６は、ある行に関連づけられるカートリッジインスタンスが割当てられたリスナを示す。マシン列５０８は、ある行に関連づけられるカートリッジインスタンスが実行されているマシンを示す。たとえば、行５１０に関連づけられるカートリッジインスタンスはリスナ２１０に割当てられており、マシンＭ１上で実行されている。
【００７０】
リソースマネージャ２５４と同様に、各ディスパッチャはそのディスパッチャが設けられているリスナに割当てられたカートリッジインスタンスに対するステート情報を維持する。このようなステート情報はたとえば、図４に示されるような表４００において維持されてもよい。表５００と同様に、表４００にはそれぞれインスタンス番号およびカートリッジ識別子を保持するインスタンス列４０２およびカートリッジ列４０４が含まれる。しかしながら、表５００ではリソースマネージャ２５４によって割当てられるすべてのカートリッジインスタンスに対して１つずつエントリが含まれるのに対し、表４００では特定のリスナに割当てられたカートリッジインスタンスに対するエントリしか含まれない。たとえば、表４００は、表５００に列挙されたカートリッジインスタンスのうちリスナ２００に割当てられたもののみに対するエントリを含む。
【００７１】
インスタンス列４０２およびカートリッジ列４０４に加えて、表４００にはステータス列４０６が含まれる。各行に対し、ステータス列４０６はその行に関連づけられるインスタンスのステータスを示す値を保持する。たとえば、行４０８のステータス列４０６はカートリッジＣ１にインスタンス１が現在ビジーであることを示している。例示される実施例では、ステータス列４０６はカートリッジインスタンスがＢＵＳＹまたはＦＲＥＥのいずれかであることを示すフラグを保持する。カートリッジステータスの重要性について、リソースマネージャ２５４とディスパッチャ２１４および２２０とのオペレーションに関連して以下に説明する。
【００７２】
ディスパッチャとリソースマネージャとの相互作用
上述のように、ディスパッチャは特定のカートリッジに変更されたブラウザリクエストを送る必要がある際にリソースマネージャ２５４と通信する。この発明の一実施例によれば、ディスパッチャはまず、適当なカートリッジのインスタンスが（１）これに既に割当てられているかどうか、また（２）新しい変更されたブラウザリクエストを処理するのに利用可能であるかどうかを判定する。適当なカートリッジインスタンスがディスパッチャに既に割当てられており新しい変更されたブラウザリクエストを処理するのに現在利用可能である場合、ディスパッチャはリソースマネージャ２５４とさらに通信することなく、変更されたブラウザリクエストをカートリッジインスタンスへ転送する。
【００７３】
たとえば、仮想パスマネージャ２５０によればカートリッジＣ１が処理しなければならないブラウザリクエストをリスナ２１０が受取ったと仮定する。また、表４００がリスナ２１０に割当てられたカートリッジインスタンスの現在のリストおよびステータスを反映すると仮定する。リスナ２１０からブラウザリクエストを受取ると、ディスパッチャ２１４は表４００を調べてカートリッジＣ１のＦＲＥＥインスタンスがあるか探す。例示される表４００では、行４１０がカートリッジＣ１のインスタンス３が現在ＦＲＥＥであることを示している。したがって、ディスパッチャ２１４はさらにリソースマネージャ２５４と通信することなく変更されたブラウザリクエストを直接カートリッジＣ１のインスタンス３に転送する。変更されたブラウザリクエストを送ることに応答してディスパッチャ２１４は行４１０のステータス列４０６のステータス値をＢＵＳＹに変える。
【００７４】
リスナに現在利用可能である適当なカートリッジインスタンスが既に割当てられていない場合、カートリッジに関連づけられるディスパッチャはリソースマネージャ２５４からのカートリッジインスタンスをリクエストする。必要とされるカートリッジのインスタンスが利用可能でなく、かつ必要とされるカートリッジの既存のインスタンスの数が最大数より下であることをリソースマネージャ２５４が判定した場合、リソースマネージャ２５４は新しいカートリッジをイニシエートする。新しいカートリッジをイニシエートする際に、リソースマネージャ２５４は表５００に新しいカートリッジインスタンスのためのエントリを挿入する。
【００７５】
たとえば、カートリッジＣ３が処理しなければならないブラウザリクエストをリスナ２１０が受取ったと仮定する。また、カートリッジＣ３のインスタンス３がまだイニシエートされていないものと仮定する。こうした条件の下では、ディスパッチャ２１４はリソースマネージャ２５４にカートリッジＣ３のインスタンスに対するハンドルを求めるリクエストを送る。このリクエストに応答して、リソースマネージャ２５４はマシンＭ３上でカートリッジＣ３のインスタンス３をイニシエートする。さらに、リソースマネージャ２５４は行５１２に見られるエントリを表５００に挿入する。
【００７６】
表５００にカートリッジＣ３のインスタンス３のための行５１２を挿入した後、リソースマネージャ２５４はディスパッチャ２１４に新しく作られたインスタンスに対するハンドルを送り返す。このハンドルを受取ったことに応答して、ディスパッチャ２１４はそのステータス表４００に新しいインスタンスのためのエントリ（行４１２）を挿入する。ディスパッチャ２１４はそこで、変更されたブラウザリクエストをカートリッジＣ３のインスタンス３に送信する。
【００７７】
カートリッジインスタンスの解放
この発明の一実施例によれば、リスナはカートリッジインスタンスが未処理のブラウザリクエストに応答し終わった際にカートリッジインスタンスの所有権を自動的に解放することはない。たとえば、カートリッジＣ３のインスタンス３が変更されたブラウザリクエストを受取り、その変更されたブラウザリクエストを処理して、ディスパッチャ２１４に応答を送り返すと想定する。ディスパッチャ２１４はその応答をリスナ２１０に渡し、これがブラウザリクエストを発行したブラウザに送り返されるようにする。
【００７８】
この時点で、リスナ２１０はカートリッジＣ３のインスタンス３の所有権をもはや必要としない。しかしながら、カートリッジＣ３のインスタンス３の所有権をリソースマネージャ２５４に戻す代わりに、ディスパッチャ２１４は単に行４１２のステータス列４０６をＢＵＳＹからＦＲＥＥに変える。
【００７９】
行４１２のステータス列４０６の値をＦＲＥＥに変えることによって、カートリッジＣ３のインスタンス３がもはやリクエストを処理しておらず、よって後続のリクエストを処理する準備ができていることが示される。しかしながら、カートリッジＣ３のインスタンス３が利用可能であることを示す表４００はディスパッチャ２１４によって局所的に維持されているため、カートリッジＣ３のインスタンス３はリスナ２１０に到達する後続のブラウザリクエストに対してだけ利用可能である。リソースマネージャ２５４が維持する表５００の行５１２はカートリッジＣ３のインスタンス３をリスナ２１０が所有していることを引続き示す。
【００８０】
リスナはリクエストが処理されるたびにカートリッジインスタンスを自動的に解放するわけではないため、リソースマネージャ２５４とさまざまなディスパッチャとの間での通信に関連するオーバーヘッドは大幅に減少される。たとえば、カートリッジＣ３に伝えなければならない１０の連続したリクエストをリスナ２１０が受取るものと仮定する。１０のリクエストの各々に対してリソースマネージャ２５４と通信するのではなく、ディスパッチャ２１４は最初のリクエストに応答してリソースマネージャ２５４と通信してもよい。ディスパッチャ２１４は後続の９つのリクエストをリソースマネージャ２５４と通信することなく処理することができるが、これはディスパッチャ２１４が最初のリクエストを処理するＣ３の同じインスタンスを用いて９つの後続のリクエストを処理するためである。
【００８１】
各リクエストを処理する際にカートリッジインスタンスのリスナ所有権を自動的に解放しないことでウェブアプリケーションサーバ２８０の効率が向上されるとはいえ、リスナは無期限にカートリッジインスタンスの所有権を維持することはできない。たとえば、長い期間にわたって用いられなかったインスタンスはリソースマネージャ２５４に戻され、リソースを空けるためにその割当ての解除ができるようにすべきである。さらに、他のリスナがそのカートリッジのインスタンスを必要としているところに、１つのリスナが比較的長い時間使っていなかったカートリッジのインスタンスの所有権を維持することは効率的ではない。
【００８２】
したがって、リソースマネージャ２５４は、リスナに渡される各カートリッジインスタンスのための最大アイドルタイムを各リスナに伝える。最大アイドルタイムとは、リスナがカートリッジインスタンスの所有権を解放しなければならなくなる前にそのカートリッジインスタンスが使用されない状態でいられる最大の時間を示すものである。たとえば、カートリッジＣ３のインスタンス３のための最大量のアイドルタイムが１０分であることをリソースマネージャ２５４がリスナ２１０に示すものと仮定する。この情報に基づいて、リスナ２１０は、カートリッジＣ３のインスタンス３が１０分より長い間アイドル状態またはＦＲＥＥとならない限りにおいてカートリッジＣ３のインスタンス３を続けて用いてカートリッジＣ３に対するブラウザリクエストを処理することができる。
【００８３】
カートリッジＣ３のインスタンス３が１０分より長い間アイドル状態である場合、ディスパッチャ２１４は表４００から行４１２を取除き、リスナ２１０がカートリッジＣ３のインスタンス３の所有権を解放することをリソースマネージャ２５４にメッセージを送って知らせる。このメッセージに応答して、リソースマネージャ２５４は行５１２を更新して、カートリッジＣ３のインスタンス３がいずれのリスナによっても所有されておらず、よって別のリスナに再割当てされるか終了され得ることを示す。
【００８４】
代替の実施例では、カートリッジインスタンスのためのアイドルタイムが満了した際にもディスパッチャはカートリッジインスタンスを自動的に解放しない。代わりに、ディスパッチャはリソースマネージャ２５４にメッセージを送り、満了となったインスタンスを解放することを申し出る。リソースマネージャ２５４はこの申し出に応答して、リスナがカートリッジインスタンスを解放するようリクエストするか、またはリスナがその満了となったカートリッジインスタンスの所有権を持ち続けることを許可してもよい。
【００８５】
この発明の一実施例によれば、リソースマネージャ２５４は直ちに処理することのできないリクエストのキューを維持する。キュー内のリクエストを処理することが可能となると、そのリクエストはキューから取除かれ処理される。
【００８６】
たとえば、カートリッジＣ１が処理しなければならないブラウザリクエストをリスナ２２２が受取り、そのリスナ２２２にカートリッジＣ１のいずれのインスタンスも割当てられていなかったと仮定する。ディスパッチャ２２６はリソースマネージャ２５４にＣ１のインスタンスに対するリクエストを送る。さらに、Ｃ１の最大５０のインスタンスが許容され、Ｃ１の５０のインスタンスがリスナ２１０に割当てられたと仮定する。こうした条件の下では、リソースマネージャ２５４はリスナ２２２からのリクエストを処理することができない。このため、リソースマネージャ２５４はそのリクエストをキューにおく。リスナ２１０がＣ１のインスタンスを解放すると、リソースマネージャ２５４はリスナ２２２にＣ１のインスタンスが利用可能であることを伝える。
【００８７】
ある特定の条件の下で、リソースマネージャ２５４は強制的にリスナにカートリッジインスタンスを解放させることがある。たとえば、リソースマネージャ２５４はシステムオーバロード状況を検出し、これに応答して１組のカートリッジインスタンスを終了することがあり、これはそのカートリッジインスタンスが終了されることになることをそのカートリッジインスタンスが現在割当てられているリスナに知らせる前または知らせた後に行なわれる。
【００８８】
また、リソースマネージャ２５４はリスナの間での公平性の方針を実現するために強制的にリスナにカートリッジインスタンスを解放させることがある。たとえば、別のリスナが予め定められたしきい値より長い時間にわたってカートリッジのインスタンスを待っている場合、リソースマネージャ２５４は所与のカートリッジの最も多い数のインスタンスを保持するリスナにそのカートリッジのあるインスタンスを解放させてもよい。たとえば、リスナ２１０にカートリッジＣ１の５０のインスタンスが割当てられ、Ｃ１は最大で５０のインスタンスを有する場合、リソースマネージャ２５４は別のリスナからＣ１のインスタンスに対するリクエストを受取ってから１０秒後にリスナ２１０にＣ１のあるインスタンスを解放させてもよい。
【００８９】
カートリッジ実行エンジン
この発明の一実施例によれば、各カートリッジインスタンスはカートリッジ実行エンジンおよびカートリッジから構成される。カートリッジ実行エンジンは、ウェブアプリケーションサーバ２８０およびマシン間通信機構の複雑さからカートリッジを隔離するコードモジュールである。カートリッジは、関数テーブルにカートリッジ関数に対するポインタを蔵置することによってカートリッジ実行エンジンに利用可能となる。一実施例によれば、すべてのカートリッジが、上述の例示のカートリッジインターフェイスにおいて特定された関数を提供する。すべてのカートリッジが同じインターフェイスをサポートするようにさせることにより、単一の標準カートリッジ実行エンジンをすべてのカートリッジに対して用いることができる。
【００９０】
この発明の一実施例によれば、カートリッジは共用ライブラリとして実装され、カートリッジ実行エンジンは標準カートリッジインターフェイスを用いて共用ライブラリ内のルーチンを呼出す実行可能なプログラムである。カートリッジ実行エンジンはカートリッジとディスパッチャとの間でインターフェイスをもたらし、カートリッジの制御のフローを指示し、カートリッジが用いるサービスを提供する。
【００９１】
リソースマネージャ２５４が新しいカートリッジインスタンスの生成を必要とする場合、リソースマネージャ２５４はカートリッジ実行エンジンのインスタンスを生成させる。これに対し、このようにして作られたカートリッジ実行エンジンのインスタンスは適当なカートリッジのインスタンスを生成させる。リソースマネージャ２５４はたとえば、カートリッジが実行されるマシン上にある「カートリッジ実行エンジンファクトリ」と呼出すことによってカートリッジ実行エンジンのインスタンスを生成させることができる。カートリッジ実行エンジンのインスタンスはたとえば、そのカートリッジを構成する共用ライブラリ内のルーチンのうちの１つに呼出を行なうことによってカートリッジのインスタンスを生成させることができる。
【００９２】
図２に示すように、ウェブアプリケーションサーバ２８０は、カートリッジ２３０、２３４および２３８のそれぞれに対して、カートリッジ実行エンジン２２８、２３２および２３６を含む。カートリッジ実行エンジンは、標準のカートリッジインターフェイスを通じてカートリッジへのコールを行なうことによって、対応するカートリッジのインスタンスの実行を制御する。カートリッジ実行エンジンとカートリッジとの間に基本的なコールバック機能を構築することによって、どのカートリッジも、ウェブアプリケーションサーバ２８０内に統合することができる。これは、そのカートリッジをコールバック機能に応答するよう構成し、その後、そのカートリッジをコンフィギュレーションプロバイダ２５６に登録することによって、行なわれる。これについては、以下に記載する。
【００９３】
したがって、ＰＬ／ＳＱＬランタイムカートリッジがリクエストを処理するのに適当なカートリッジであるとディスパッチャ２１４が判定すると、ディスパッチャ２１４はそのＰＬ／ＳＱＬランタイムカートリッジに関連づけられるカートリッジ実行エンジンを含むカートリッジインスタンスにそのリクエストをディスパッチする。新しいインスタンスをイニシエートする必要がある場合、リソースマネージャ２５４は別個のアドレス空間においてＰＬ／ＳＱＬランタイムカートリッジの新しいインスタンスを作り、その新しいインスタンスのカートリッジ実行エンジン２２８へそのリクエストをディスパッチする。プログラムのインスタンスを実行するのに用いられるアドレス空間は、ウェブアプリケーションサーバ２８０の構成要素の１つ以上が実行されているコンピュータシステムのメモリ内にあるか、または別のコンピュータシステム上にあってもよい。
【００９４】
ディスパッチャからのメッセージに応答して、カートリッジ実行エンジンはカートリッジにリクエストハンドラコールバック機能を発行し、カートリッジにそのリクエストを処理させる。そのリクエストを処理するカートリッジはその結果をカートリッジ実行エンジンに返し、カートリッジ実行エンジンはその結果をディスパッチャに転送する。ウェブアプリケーションサーバ２８０がオペレーションにおいて障害を検出した場合にはカートリッジ実行エンジンはカートリッジのシャットダウン関数を発行する。
【００９５】
このように、カートリッジ実行エンジンは、実行すべき予め定められたオペレーションを特定するウェブアプリケーションサーバ２８０へのアプリケーションプログラミングインターフェイスを提供する。標準のカートリッジインターフェイスを使用することにより、カートリッジのプログラマが、カートリッジがともに用いられることになる特定のウェブリスナが用いるプロトコルとは無関係に、各カートリッジをウェブアプリケーションサーバ２８０へ高レベルで統合化するよう構成することができる。
【００９６】
トランスポートアダプタ
リスナは、サーバ側のプラグインが使用するためのプログラミングインターフェイスおよびプロトコルを提供することによってそのようなプラグインの使用を可能にする。残念なことに、リスナが提供するプログラミングインターフェイスおよびプロトコルはリスナごとに異なる。たとえば、ネットスケープ・サーバ・アプリケーション・プログラミング・インターフェイス（ＮＳＡＰＩ：Netscape Server Application Programming Interface）、インターネット・サーバ・アプリケーション・プログラミング・インターフェイス（ＩＳＡＰＩ：Internet Server Application Programming Interface）およびアプリケーション開発インターフェイス（ＡＤＩ：Application Development Interface）は現在リスナによりもたらされる別個のプログラミングインターフェイスの３つの例である。
【００９７】
トランスポートアダプタはウェブリスナが用いる私的プロトコルおよびインターフェイスからディスパッチャを隔離する。特定的には、各トランスポートアダプタはさまざまなリスナのプロトコルを認識し、リスナから受取ったブラウザリクエストを変換してリスナのプロトコルとは無関係の標準ディスパッチャプロトコルを有する変換されたブラウザリクエストを生じるよう構成される。同様に、トランスポートアダプタはディスパッチャからの返答をリスナのトランスポートプロトコルに変換する。
【００９８】
このように、トランスポートアダプタにより、ウェブアプリケーションサーバ２８０を異なるベンダのリスナとともに用いることが可能となる。さらに、トランスポートアダプタは異なるサーバアーキテクチャおよびオペレーティングシステムに対応するよう構成されてもよい。
【００９９】
ウェブアプリケーションサーバのオペレーション
図３Ａおよび図３Ｂはこの発明の一実施例によるブラウザリクエストに応答する方法を示すフロー図である。ステップ３５０においてリスナがブラウザリクエストを受取る。説明のために、このブラウザリクエストはブラウザ２０２により発行されリスナ２１０により受取られるものと仮定する。
【０１００】
ブラウザリクエストを受取ると、リスナ２１０はステップ３５２においてウェブアプリケーションサーバ２８０にそのリクエストを転送する。特定的には、リスナ２１０はリスナ２１０の私的プログラミングインターフェイスを用いてそのリクエストをトランスポートアダプタ２１２に渡す。トランスポートアダプタ２１２は、必要に応じてそのリクエストを標準ディスパッチャプログラミングインターフェイスを用いて変換しそのリクエストをディスパッチャ２１４に渡す。
【０１０１】
ディスパッチャ２１４は、仮想パスマネージャ２５０と通信することによって、ブラウザリクエストにより特定される仮想パスに基づいて、ステップ３５４においてブラウザリクエストに対応するリクエストオブジェクトタイプを識別する。リクエストオブジェクトタイプがカートリッジに対応する場合には、仮想パスマネージャはまた、認証が必要であるかどうかをディスパッチャ２１４に知らせる。
【０１０２】
ディスパッチャ２１４はステップ３５６において、そのリクエストオブジェクトタイプが識別可能なカートリッジに対応するかどうかを判定する。そのリクエストオブジェクトタイプが識別可能なカートリッジに対応していない場合、そのリクエストはステップ３５８においてリスナ２１０に戻される（図３Ｂを参照）。ステップ３５８においてそのリクエストが静的ＨＴＭＬページに対するリクエストであることをリスナ２１０が認識すると、リスナはその静的ＨＴＭＬページにアクセスし、そのＨＴＭＬページをステップ３６０においてブラウザ２０２に送る。ブラウザリクエストがリスナ２１０によって認識されない場合、ステップ３６０において返答がブラウザ２０２に送られそのリクエストが認識不可能であったことを示す。
【０１０３】
ステップ３５６において、リクエストをカートリッジに送らなければならないとディスパッチャ２１４が判定すると、ディスパッチャは、認証サーバ２５２と通信することによって、必要な認証を行なう。この認証のプロセスについては、以下により詳細に説明する。さらに、ステップ３５６において、リスナ２１０にそのカートリッジの現在ＦＲＥＥであるインスタンスが１つも割当てられていないと判定すると、ディスパッチャ２１４は、そのブラウザリクエストを送ることのできるカートリッジ２３０のインスタンスが割当てられることになるリソースマネージャ２５４と通信する。
【０１０４】
図３Ｂに示されるステップ３６２では、リソースマネージャ２５４は、識別されたカートリッジのインスタンスが既存のインスタンスの数の中で利用可能である（所有されていない）かどうかを判定する。説明のため、このリクエストはカートリッジ２３０に関連づけられるものであり、カートリッジ２３０はＰＬ／ＳＱＬランタイムカートリッジであると仮定する。
【０１０５】
ステップ３６２においてリソースマネージャが利用可能なインスタンス、たとえばＰＬ／ＳＱＬランライム２３０のインスタンス２６０を識別すると、リソースマネージャ２５４はリクエストをインスタンス２６０に送るべきであることをディスパッチャ２１４に知らせる。ディスパッチャ２１４はそこで、変更されたブラウザリクエストを作りステップ３６８においてインスタンス２６０のカートリッジ実行エンジン２２８にその変更されたブラウザリクエストを送って、以下に説明するように利用可能なインスタンス２６０にそのリクエストを処理させる。
【０１０６】
しかしながら、ステップ３６２においてカートリッジ２３０のインスタンスが１つも利用可能でない場合、リソースマネージャ２５４はステップ３６４において、既存のインスタンスの数が最大所定数を超えるかどうかを判定する。ステップ３６４において既存のインスタンスの数が最大所定数を超える場合、リソースマネージャ２５４はその時点ではそのリクエストを処理できないことをディスパッチャ２１４に示す。これに応答して、ディスパッチャ２１４はステップ３５８においてそのリクエストをリスナ２１０に返し、その後に、ウェブリスナ２１０はステップ３６０においてネットワークを介してブラウザ２０２へ返答を送り、そのリクエストが処理されなかったことを示す。
【０１０７】
代わりに、カートリッジインスタンスがリクエストを処理するためにその現時点で利用可能でない場合、リスナ２１０はそのカートリッジインスタンスに対する待ちリストにそのリクエストを入れてもよい。カートリッジインスタンスが利用可能となると、変更されたブラウザリクエストが待ちリストから取除かれカートリッジインスタンスに転送される。変更されたブラウザリクエストが予め定められた時間より長い間待ちリストに残っている場合、リスナ２１０はそのリクエストを待ちリストから取除いてブラウザ２０２にメッセージを送りそのリクエストが処理できなかったことを示すようにしてもよい。
【０１０８】
ステップ３６４において既存のインスタンスの数が最大所定数を超えない場合、リソースマネージャ２５４は識別されたプログラムの新しいインスタンスをイニシエートし、ブラウザリクエストに基づく変更されたブラウザリクエストを新しいインスタンスに送るべきであることをディスパッチャ２１４に知らせる。そこでディスパッチャ２１４は変更されたブラウザリクエストをその新しいインスタンスのカートリッジ実行エンジンへディスパッチする。
【０１０９】
たとえば、リソースマネージャ２５４がブラウザリクエストに応答してインスタンス２６０をイニシエートしたと仮定する。その初期化の間、ＰＬ／ＳＱＬランタイムのための蔵置された命令シーケンスにアクセスが行なわれ、ディスパッチャ２１４が実行しているアドレス空間とは別個のアドレス空間においてカートリッジ２３０の新しいインスタンス２６０が作られる。一実施例によれば、初期化はカートリッジ実行エンジン２２８をロードし、そのカートリッジ実行エンジンにカートリッジ２３０内の初期化ルーチンを呼出させることによって行なわれる。
【０１１０】
一度新しいインスタンス２６０が実行されると、ディスパッチャ２１４はステップ３６８においてその新しいインスタンス２６０に関連づけられているカートリッジ実行エンジン２２８にリクエストをディスパッチする。カートリッジ実行エンジン２２８は新しいインスタンス２６０にコールバックメッセージを送りそのリクエストの実行を要求する。そのコールバックメッセージにおいて、カートリッジ実行エンジン２２８はそのリクエストを処理する上でインスタンス２６０が必要とする全てのパラメータを渡す。このようなパラメータにはたとえば、パスワード、データベース探索キー、またはインスタンス２６０が実行する動的オペレーションのための他のどんな引き数を含んでいてもよい。
【０１１１】
次にインスタンス２６０はリクエストを実行する。ステップ３６８におけるインスタンスによるリクエストの実行の間、ディスパッチャ２１４はステップ３７０においてインスタンスを監視して障害が発生するかどうかを判定する。ステップ３７０においてディスパッチャ２１４が障害を検出すると、ディスパッチャ２１４はステップ３７２において対応するカートリッジ実行エンジン２２８を呼出し、その障害を有するインスタンス２６０を打ち切る。これに対し対応するカートリッジ実行エンジン２２８はＡＰＩを通して障害のあるインスタンスに対してシャットダウンコマンドを発行する。そのインスタンスはカートリッジ実行エンジン２２８によるシャットダウンコマンドに応答して、他のどんなアドレス空間における他のどんなプロセスにも影響を与えることなくシャットダウンする。
【０１１２】
ステップ３７０において障害が検出されない場合、ディスパッチャ２１４はステップ３７４において実行の完了の際にインスタンス２６０から返答を受取る。ステップ３７６においてディスパッチャ２１４はその返答をリスナ２１０に転送し、リスナ２１０は実行されたインスタンス２６０からの返答をもってブラウザに応答する。インスタンス２６０を実行した後、ステップ３７８においてディスパッチャ２１４はステップ３７８に示されるようにメモリ内にインスタンスを維持し、後続のリクエストの実行を可能にする。
【０１１３】
ウェブサーバの分散アーキテクチャ
重要なことであるが、ウェブアプリケーションサーバ２８０のさまざまな構成要素は、それら構成要素が同じアドレス空間において実行される必要がなく同じマシン上で実行されることさえ必要としない通信機構を用いて互いに通信する。例示される実施例では、ウェブアプリケーションサーバ２８０の構成要素はオブジェクトリクエストブローカ（ＯＲＢ：Object Request Broker）２８２を介して通信するよう構成される。オブジェクトリクエストブローカは「共通オブジェクトリクエストブローカ：アーキテクチャおよび仕様（ＣＯＲＢＡ）」（"Common Object Request Broker: Architecture and Specification (CORBA)"）に詳しく記載されている。ＣＯＲＢＡに関連するこのおよび他の文献はワールド・ワイド・ウェブのhttp://www.omg.orgにおいて見つけることができる。
【０１１４】
この発明の実施例はＣＯＲＢＡに従ったＯＲＢを介する通信に関連して説明するが、他のクロスプラットフォーム通信機構を用いてもよい。たとえば、ウェブアプリケーションサーバ２８０の構成要素は代わりに、遠隔手続き呼出（ＲＰＣ：Remote Procedure Calls）、ＵＮＩＸパイプ、Microsoft COMを用いて互いに通信してもよい。
【０１１５】
ウェブアプリケーションサーバ２８０のさまざまな構成要素がマシンから独立した通信機構を用いて互いに通信するため、構成要素が互いに対してどこに存在するかということに関して固有の制約はない。たとえば、リスナ２１０、２１６および２２２は同じマシン上で実行していてもよく、またはそれぞれがこのようなオペレーティングシステムを有する３つの完全に異なったマシン上で実行してもよい。同様に、認証サーバ２５２、仮想パスマネージャ２５０、リソースマネージャ２５４およびコンフィギュレーションプロバイダ２５６は同じマシン上で実行していてもよく、または４つの異なるマシン上で実行していてもよい。さらに、これらの４つの異なるマシンはリスナ２１０、２１６および２２２を実行する３つのマシンと少しも重複していなくてもよい。
【０１１６】
カートリッジ実行エンジン２２８、２３２および２３６は、オブジェクトリクエストブローカ２８２を介してウェブアプリケーションサーバ２８０の他の構成要素と通信するのに必要な論理のすべてを組込んでいる。したがって、カートリッジインスタンス自体の場所は通信機構によって本質的に制約されるものではない。すなわち、インスタンス２６０はこれがリクエストを受取るディスパッチャとは全く異なるマシンおよびオペレーティングシステムにおいて実行されてもよい。同様に、インスタンス２６０は、リソースマネージャ２５４、または同じウェブアプリケーションサーバ２８０によって管理される他のカートリッジのインスタンスを含む、ウェブアプリケーションサーバ２８０の他の構成要素のいずれとも異なるマシンおよびオペレーティングシステム上にあってもよい。
【０１１７】
重要な事だが、ウェブアプリケーションサーバ２８０が用いるカートリッジが享受する場所の独立性は、カートリッジそのものにおける何らかのカスタムプログラミングを介してではなくカートリッジ実行エンジンの通信論理を介して達成される。したがって、分散アプリケーションサーバ環境における実行のために特別にカートリッジを設計する必要がない。このように、カートリッジ設計者らは分散システムの複雑さから隔離され、カートリッジが作られる目的であるタスクと関連する論理に労力を集中させることができる。
【０１１８】
認証機能の概要
前述のように、各ブラウザのメッセージはＵＲＬ情報と関連付けられて、ＵＲＬ情報はとりわけ、アクセスされるべき特定のカートリッジを識別する。ディスパッチャは、ブラウザのリクエストを受取ると、仮想パスマネージャと通信して、そのブラウザのメッセージに関連付けられたカートリッジが認証を必要としているかどうかを判定する。カートリッジが認証を必要としない場合には、ディスパッチャはブラウザのリクエストをカートリッジにディスパッチし、カートリッジがそれを実行する。しかし、カートリッジが認証を必要とする場合には、ディスパッチャは認証のリクエストを認証サーバに対して送信する。
【０１１９】
認証サーバは、認証のリクエストに含まれる情報を使用して、そのブラウザのリクエストがカートリッジにアクセスすることを許可されているかどうかを判定する。ブラウザのリクエストがカートリッジにアクセスすることを許可されている場合には、ディスパッチャはブラウザのリクエストをカートリッジにディスパッチし、カートリッジがそれを実行する。これに対し、ブラウザのリクエストがカートリッジにアクセスすることを許可されていない場合には、ディスパッチャはアクセスが拒絶されたことを示すメッセージをブラウザに送信する。このプロセスは、ブラウザの各リクエストに対して繰返される。
【０１２０】
図６は、本発明の一実施例に従った、ステートレスなウェブ環境において拡張可能な認証機構を提供する、システム６００のブロック図である。図６は図２と同様であるため、同じ構成要素には同じ参照番号が付されている。
【０１２１】
システム６００は、オブジェクトリクエストブローカ２８２を介して複数のディスパッチャ２１４、２２０および２２６に接続された認証サーバ２５２を含む。認証サーバ２５２は、認証エンジン６０２と、認証ホスト６０４と、複数の認証サービスプロバイダ（単にプロバイダと称する）６０６、６０８、６１０および６１２とを含む。
【０１２２】
認証エンジン６０２は、オブジェクトリクエストブローカ２８２を介してディスパッチャ２１４、２２０および２２６と通信して、認証のリクエストを受取る。認証のリクエストを受取ると、認証エンジン６０２はその認証のリクエストを解析して１または複数のプロバイダのリクエストとする。認証エンジン６０２はその後、それらプロバイダのリクエストを、オブジェクトリクエストブローカ２８２を介して認証ホスト６０４に送信する。各リクエストはそこから適切なプロバイダへと分配される。
【０１２３】
認証エンジン６０２からプロバイダのリクエストを受取ると、認証ホスト６０４はそのプロバイダのリクエストを適切なプロバイダに送る。プロバイダは、プロバイダのリクエストを受取ると、アクセスが許可されるべきかどうかを、そのプロバイダのリクエストに含まれる情報に基づいて判定する。プロバイダはその後、認証ホスト６０４およびオブジェクトリクエストブローカ２８２を介して、応答メッセージを認証エンジン６０２に戻す。この応答メッセージは、その特定のプロバイダのリクエストに含まれていた情報に基づいて、アクセスが許可されるべきかどうかを示している。
【０１２４】
認証エンジン６０２はその後、１または複数のプロバイダの応答メッセージを使用して、ディスパッチャから受取られた認証のリクエストに基づいて、カートリッジのアクセスが許可されるべきかどうかを判定する。認証エンジンはその後、ブラウザのリクエストを適切なカートリッジに送るか、それとも、送信側ブラウザにアクセスが拒絶されたことを知らせるか、をディスパッチャに通知する。
【０１２５】
プロテクトストリング
前述のように、ウェブアプリケーションサーバ２８０とともに使用されるべきカートリッジは、メタデータとして記憶されるべき情報をコンフィギュレーションプロバイダ２５６に提供することによって、まず登録される。この登録プロセス中、各カートリッジは、その特定のカートリッジに関連付けられるべきＵＲＬのリストを供給する。これらＵＲＬは、特定のブラウザのリクエストに関連付けられるカートリッジを識別するのに使用される。特定のカートリッジへのアクセスを制限するために、オプションとしてプロテクトストリングを各ＵＲＬエントリに関連付けてもよい。
【０１２６】
本発明の一実施例においては、各プロテクトストリングは、１または複数の方式名と領域名との対によって構成されており、方式名と領域名との対が複数あるときは、それらの間には論理関数（たとえばＡＮＤ、ＯＲ）が置かれている。方式名は、カートリッジのアクセスを認証するのに使用されるべきプロバイダの型を識別し、領域名は、方式名と関連付けられた、プロバイダによって必要とされる認証情報の型を示す。
【０１２７】
たとえば、カートリッジ２３８が登録する場合、これは、以下のようなＵＲＬおよびプロテクトストリングと関連付けられてもよい：
URL1 CARTRIDGE＿238 BASIC(GROUP1) AND IP(IP＿LIST)
この例においては、ＵＲＬ１がＵＲＬを表わし、方式名「ＢＡＳＩＣ」および「ＩＰ」がカートリッジのアクセスの認証に使用されるべきプロバイダを識別する。領域名「ＧＲＯＵＰ１」および「ＩＰ＿ＬＩＳＴ」は、それぞれ方式名「ＢＡＳＩＣ」および「ＩＰ」に関連付けられており、各プロバイダの型によって必要とされる認証情報の型を表わす。論理「ＡＮＤ」演算が、認証エンジンによって使用される。これはまた、そのブラウザのリクエストがＣＡＲＴＲＩＤＧＥ＿２３８にアクセスすることを許可されるかどうかを判定するために、「ＢＡＳＩＣ」および「ＩＰ」プロバイダから受取られた応答メッセージに対して論理「ＡＮＤ」演算が行なわれねばならないことを表わしている。
【０１２８】
プロバイダ
プロバイダは、特定の型の認証を行なうのに使用されるコードのモジュールである。本発明の一実施例に従えば、プロバイダは動的にリンクされるライブラリ（ＤＬＬ）として実装される。したがって、プロバイダは、それが属する認証ホストと同じアドレス空間内にロードされかつその中で実行される。プロバイダは、好ましくは、ランタイムに動的にロードされる。
【０１２９】
各プロバイダは、関数ポインタのテーブルおよびプロパティリストを含む。関数ポインタのテーブルは、認証ホスト６０４がアクセスすることのできる特定のプロバイダの機能に対するポインタを提供する。プロパティリストは、その特定のプロバイダにアクセスするのに必要とされる、（カートリッジに対してリクエストを開始するユーザのアイデンティティ等の）認証情報の型を記述する。一実施例に従えば、プロパティテーブルは、プロバイダの名前、ディスク上でそのＤＬＬが記憶されているロケーション、およびエントリポイントアドレスを含む。認証ホストは、エントリポイントを呼出して、特定のプロバイダのリクエストを認証するのに使用することのできる関数ポインタのリストを得ることができる。
【０１３０】
一実施例において、特定のプロバイダに関連する情報は、そのプロバイダが初期化されるときにウェブアプリケーションサーバ２８０内にメタデータとして格納される。プロバイダが初期化されるときにプロバイダ情報をメタデータとして格納することによって、プロバイダを認証サーバ２５２に対して動的に付加したりそれから分離したりすることのできる機構が提供される。
【０１３１】
図６に示すように、プロバイダ６０６、６０８、６１０および６１２は認証ホスト６０４に関連づけられている。各プロバイダは、特定のカートリッジへのアクセスを制限する、特定的な認証機構を提供する。たとえば、ＢＡＳＩＣプロバイダを認証ホストに関連づけ、このＢＡＳＩＣプロバイダを利用して、カートリッジのアクセスを、特定のユーザ名およびパスワードの対に関連づけられたブラウザのリクエストのみに制限することができる。したがって、このＢＡＳＩＣプロバイダは、認証ホストからプロバイダのリクエストを受取ると、所定のユーザ名／パスワードのアクセスリストをサーチして、アクセスが提供されるべきかどうかを判定する。ユーザ名／パスワードの一致を発見すると、ＢＡＳＩＣプロバイダは、供給されたユーザ名およびパスワードの対に基づいてアクセスが許可されるべきであることを示すメッセージを、認証ホストに送信する。しかし、一致を見つけることができなければ、そのＢＡＳＩＣプロバイダは、ユーザ名／パスワードの対に基づいてアクセスが許可されるべきではないことを示すメッセージを、認証ホストに送信する。
【０１３２】
認証ホストに関連づけることのできるプロバイダの型の別の例として、ＩＰアドレスプロバイダがある。このＩＰアドレスプロバイダは、カートリッジのアクセスを、特定のＩＰアドレスに関連づけられたブラウザのリクエストのみに制限するのに使用することができる。したがって、このＩＰアドレスプロバイダは、認証ホストからプロバイダのリクエストを受取ると、所定のＩＰアクセスリストをサーチして、アクセスが提供されるべきかどうかを判定する。もしＩＰアドレスの一致を発見すれば、ＩＰアドレスプロバイダはその供給されたＩＰアドレスに基づいてアクセスが許可されるべきであることを示すメッセージを、認証ホストに送信する。しかし、一致を発見できない場合には、ＩＰアドレスプロバイダは、ＩＰアドレスに基づいてアクセスが許可されるべきではないことを示すメッセージを、認証ホストに送信する。
【０１３３】
認証ホストに関連づけることのできるプロバイダの型のさらに別の例として、ＤＯＭＡＩＮ名プロバイダがある。ＤＯＭＡＩＮ名プロバイダは、カートリッジのアクセスを、特定の領域名に関連づけられたブラウザのリクエストのみに制限するのに使用することができる。したがって、このＤＯＭＡＩＮ名プロバイダは、認証ホストからプロバイダのリクエストを受取ると、所定のＤＯＭＡＩＮ名リストをサーチして、アクセスが提供されるべきかどうかを判定する。ＤＯＭＡＩＮ名の一致を発見した場合、ＤＯＭＡＩＮ名プロバイダは、供給されたＤＯＭＡＩＮ名に基づいてアクセスが許可されるべきであることを示すメッセージを、認証ホストに送信する。しかし、一致を発見できない場合には、ＤＯＭＡＩＮ名プロバイダは、ＤＯＭＡＩＮ名に基づいてアクセスが許可されるべきではないことを示すメッセージを、認証ホストに送信する。
【０１３４】
認証ホストに関連づけることのできるプロバイダの型のまた別の例として、ＤＡＴＡＢＡＳＥプロバイダがある。このＤＡＴＡＢＡＳＥプロバイダは、カートリッジのアクセスを、特定のデータベース内に含まれる特定のユーザ名およびパスワードの対に関連づけられたブラウザのリクエストのみに制限するのに使用することができる。したがって、このＤＡＴＡＢＡＳＥプロバイダは、認証ホストからプロバイダのリクエストを受取ると、データベースをサーチして、アクセスが提供されるべきかどうかを判定する。データベース内にユーザ名／パスワードの一致を発見すれば、ＤＡＴＡＢＡＳＥプロバイダは供給されたデータベースのユーザ名およびパスワードの対に基づいてアクセスが許可されるべきであることを示すメッセージを認証ホストに送信する。しかし、一致を発見することができなければ、ＤＡＴＡＢＡＳＥプロバイダは、データベースのユーザ名／パスワードの対に基づいてアクセスが許可されるべきではないことを示すメッセージを、認証ホストに送信する。
【０１３５】
認証ホストに関連づけることのできるプロバイダの型のさらに別の例に、ＤＩＧＥＳＴプロバイダがある。このＤＩＧＥＳＴプロバイダは、特定のユーザ名および暗号化されたパスワードの対に関連づけられたブラウザのリクエストのみにカートリッジのアクセスを制限するのに使用することができる。このＤＩＧＥＳＴプロバイダは、認証ホストからプロバイダのリクエストを受取ると、乱数を発生し、この乱数を、ディスパッチャを介してブラウザのリクエストに関連づけられたブラウザへと送り返す。
【０１３６】
ブラウザは、この乱数を受取ると、ＤＩＧＥＳＴプロバイダが発生したこの乱数に基づいてパスワードを暗号化し、それをディスパッチャおよびオブジェクトリクエストブローカを介して認証エンジンに送り返す。認証エンジンは、この暗号化されたパスワードを、オブジェクトリクエストブローカおよび認証ホストを介してＤＩＧＥＳＴプロバイダに戻す。ＤＩＧＥＳＴプロバイダは、ブラウザから送られてきた暗号化パスワードを受取ると、それをＤＩＧＥＳＴプロバイダによって生成された暗号化パスワードと比較する。その後、ＤＩＧＥＳＴプロバイダは、比較の結果を使用して、そのブラウザのリクエストがカートリッジに対してアクセスすることができるかどうかを判定する。
【０１３７】
認証エンジン
一実施例に従えば、認証エンジン６０２は、実行を開始するときに、自身を認証エンジンと識別するその名前および関連のＩＤをメタデータとしてウェブアプリケーションサーバ２８０に格納することによって、ウェブアプリケーションサーバ２８０に登録する。認証エンジンに関連づけられたメタデータは、オブジェクトリクエストブローカ２８２がシステムの負荷を最適配分するのに使用される。負荷の最適配分については、以下にさらに詳細に説明する。
【０１３８】
認証リクエストを受取ると、認証エンジン６０２はその認証リクエストを解析して１または複数のプロバイダのリクエストとする。その後、認証エンジン６０２はそれらプロバイダのリクエストを、オブジェクトリクエストブローカ２８２を介して認証ホスト６０４に送信し、各リクエストはそこから適切なプロバイダへと分配される。
【０１３９】
認証ホスト６０４は、認証エンジン６０２からプロバイダのリクエストを受取ると、各プロバイダのリクエストを適切なプロバイダに送る。プロバイダは、プロバイダのリクエストを受取ると、そのプロバイダのリクエストに含まれる情報に基づいてアクセスが許可されるべきかどうかを判定する。その後、プロバイダは、プロバイダのリクエスト内に含まれる情報に基づいてアクセスが許可されるべきかどうかを示す応答メッセージを、認証ホスト６０４およびオブジェクトリクエストブローカ２８２を介して認証エンジン６０２へと送り返す。
【０１４０】
認証のリクエストに関連づけられたプロバイダから応答メッセージを受けた後、認証エンジンは、そのブラウザのリクエストがカートリッジにアクセスするのを許可されるべきかどうかを判定するのに必要な論理演算を行なう。認証エンジンはその後、そのブラウザのリクエストがカートリッジにディスパッチされるべきか、それとも、カートリッジのアクセスが拒絶されたことをブラウザに知らせるべきかを、ディスパッチャに通知する。
【０１４１】
認識リクエストの処理
図７Ａおよび７Ｂは、本発明の一実施例に従った、ステートレスなウェブ環境においてブラウザのリクエストを認証するための方法を示すフロー図である。説明の目的で、ブラウザのリクエストはブラウザ２０２によって発行され、ディスパッチャ２１４がそれを受取るものとする。また、ブラウザのリクエストに関連するＵＲＬが、プロテクトストリング「ＢＡＳＩＣ（ＧＲＯＵＰ１） ＡＮＤ ＩＰ（ＩＰ＿ＬＩＳＴ）」に関連づけられ、また、ブラウザのリクエストが、ユーザ名「ＪＩＭ」、パスワード「ＭＡＮＡＧＥＲ」およびＩＰアドレス「１９２．６．２５．３」を含むものとする。さらに、プロバイダ６０６がＢＡＳＩＣ型のプロバイダであって、プロバイダ６０８がＩＰ型のプロバイダであるものとする。
【０１４２】
ステップ７０２において、ディスパッチャ２１４が上述のようなブラウザのリクエストを受取る。ステップ７０４において、ディスパッチャ２１４がオブジェクトリクエストブローカ２８２を介して仮想パスマネージャ２５０と通信して、そのブラウザのリクエストに関連づけられるＵＲＬが認証を必要とするか（たとえば、ＵＲＬがプロテクトストリングに関連づけられているか）を判定する。ＵＲＬがプロテクトストリングに関連づけられていない場合には、ステップ７０６において、ディスパッチャ２１４がそのブラウザのリクエストを適切なカートリッジにディスパッチする。その後、制御はステップ７０２に戻って、別のブラウザのリクエストを受取る。
【０１４３】
しかし、ＵＲＬが（この例のように）プロテクトストリングに関連づけられている場合には、ステップ７０８において、ディスパッチャ２１４はオブジェクトリクエストブローカ２８２を介して認証エンジン６０２へと、認証のリクエスト（たとえば、ＢＡＳＩＣ（Ｇｒｏｕｐ１）ＪＩＭ／ＭＡＮＡＧＥＲ ＡＮＤ ＩＰ（ＩＰ＿ＬＩＳＴ）１９２．６．２５．３）を送信する。ステップ７１０において、認証エンジン６０２は、その認証リクエストを解析して別々のプロバイダのリクエスト（たとえば、ＢＡＳＩＣ（Ｇｒｏｕｐ１）ＪＩＭ／ＭＡＮＡＧＥＲ、ＩＰ（ＩＰ＿ＬＩＳＴ）１９２．６．２５．３）とする。ステップ７１２において、認証エンジン６０２は、それらプロバイダのリクエストをオブジェクトリクエストブローカ２８２を介して認証ホスト６０４に送信し、これらはそこから適切なプロバイダへと分配される。
【０１４４】
ステップ７１４において、認証ホスト６０４は、プロバイダのリクエストを適切なプロバイダに送信する。この例においては、ＢＡＳＩＣ（ＧＲＯＵＰ１）ＪＩＭ／ＭＡＮＡＧＥＲというプロバイダのリクエストはプロバイダ６０６に送られ、ＩＰ（ＩＰ＿ＬＩＳＴ）１９２．６．２５．３というプロバイダのリクエストはプロバイダ６０８に送られる。ステップ７１６において、各プロバイダは、それらが受取ったプロバイダのリクエスト内に含まれる情報に基づいて、カートリッジへのアクセスが許可されるべきかどうかを判定する。ステップ７１８において、各プロバイダは、認証ホスト６０４およびオブジェクトリクエストブローカ２８２を介して認証エンジン６０２へと応答メッセージを送信する。この例においては、プロバイダ６０６および６０８が応答メッセージを認証エンジン６０２に送信する。
【０１４５】
ステップ７２０において、認証エンジン６０２は、認証のリクエストに関連づけられた論理演算を行なう。この例においては、認証エンジン６０２は、プロバイダ６０６およびプロバイダ６０８から受取った２つの応答メッセージに対して論理演算「ＡＮＤ」を行なう。ステップ７２２において、認証エンジン６０２は認証の結果を、オブジェクトリクエストブローカ２８２を介してディスパッチャ２１４に知らせる。
【０１４６】
ステップ７２４において、ディスパッチャ２１４は、この認証エンジン６０２から送られてきた認証の結果を使用して、ブラウザのリクエストが認証されたかどうかを判定する。ブラウザのリクエストが認証されなかった場合には、ディスパッチャ２１４はブラウザのリクエストが認証されずカートリッジのアクセスが拒絶されたことを、ブラウザ２０２に通知する。その後、制御はステップ７０２に戻って、別のブラウザのリクエストを受信する。
【０１４７】
これに対し、ブラウザのリクエストが認証された場合には、ディスパッチャ２１４はそのブラウザのリクエストを適切なカートリッジにディスパッチする。その後、制御はステップ７０２に戻って、別のブラウザのリクエストを受取る。
【０１４８】
負荷の最適配分
認証エンジンおよび認証ホストが実行を開始するとき、それらはまず、オブジェクトリクエストブローカ２８２が認証サーバの負荷の最適配分を行なうことができるようにする特定の情報をメタデータとしてウェブアプリケーションサーバ２８０に格納することによって、ウェブアプリケーションサーバ２８０に登録する。したがって、一実施例に従えば、認証エンジンは、実行を開始するときに、自身を認証エンジンと識別するその名前および関連のＩＤをメタデータとしてウェブアプリケーションサーバ２８０に格納することで、ウェブアプリケーションサーバ２８０に登録する。認証エンジンに関連づけられたメタデータは、オブジェクトリクエストブローカ２８２が、システムの負荷の最適配分を行なうのに使用する。
【０１４９】
認証エンジンに加えて、認証ホストも、実行を開始するときに、自身を認証ホストと識別するその名前および関連のＩＤをメタデータとしてウェブアプリケーションサーバ２８０に格納することで、ウェブアプリケーションサーバ２８０に登録する。さらに、認証ホストに関連づけられる１または複数のプロバイダを識別するメタデータも格納される。
【０１５０】
図８は、本発明の一実施例に従った、ステートレスなウェブ環境において拡張可能な認証機構の負荷の最適配分を行なうことのできる、システム８００のブロック図である。図８は図６と同様であるので、同じ構成要素には同じ参照番号が付されている。
【０１５１】
図８に示すように、認証サーバ８２８は、オブジェクトリクエストブローカ２８２に接続されてそれと通信する、複数の認証エンジン８０２、８０４および８０６を含む。認証サーバ８２８はまた、オブジェクトリクエストブローカ２８２にさらに接続されかつそれと通信する、複数の認証ホスト８０８、８１４および８２２を含む。図示されるように、認証ホスト８０８、８１４および８２２は各々、複数のプロバイダと関連づけられている。
【０１５２】
ディスパッチャは、認証エンジンと通信したいときには、オブジェクトリクエストブローカ２８２から認証エンジンを割当ててもらうよう要求する。特定の認証エンジンを識別する際に、オブジェクトリクエストブローカ２８２は、負荷の最適配分方式を使用して認証エンジンの作業量の最適配分を試みる。その後、オブジェクトリクエストブローカ２８２は、使用されるべき特定の認証エンジンを識別し、その特定の認証エンジンへと、オブジェクトリクエストブローカ２８２を介して認証のリクエストを送信する。
【０１５３】
認証エンジンは、認証のリクエストを受取ると、その認証リクエストを解析して１または複数のプロバイダのリクエストとする。その後、認証エンジンは、オブジェクトリクエストブローカ２８２に対して、それら１または複数のプロバイダのリクエストを処理することのできるプロバイダに関連する１または複数の認証ホストを識別するように要求する。この１または複数の認証ホストを識別する際にも、オブジェクトリクエストブローカ２８２はやはり負荷の最適配分方式を使用して、認証ホストの作業量の最適配分を試みる。オブジェクトリクエストブローカ２８２は、これら１または複数の認証ホストを識別した後に、１または複数のプロバイダのリクエストをオブジェクトリクエストブローカ２８２を介して１または複数の認証ホストへと送る。その後、これら１または複数の認証ホストが、それらプロバイダのリクエストを適切なプロバイダへと分配する。
【０１５４】
プロバイダは、プロバイダのリクエストの認証を完了すると、関連する認証ホストおよびオブジェクトリクエストブローカ２８２を介して認証エンジンへと応答メッセージを送り返す。１または複数のプロバイダから応答メッセージを受取ると、認証エンジンは、戻された応答メッセージに対して必要な論理演算を行なう。その後、認証エンジンは、ブラウザのリクエストが適切なカートリッジへと送られるべきか、それとも、送信側のブラウザに対してアクセスが拒絶されたことを知らせるべきかを、ディスパッチャに通知する。
【０１５５】
カートリッジの認証
ディスパッチャに加えて、カートリッジもまた、ブラウザのリクエストを認証する能力を有する。本発明の一実施例に従えば、ディスパッチャが認証が不要である（すなわち、ブラウザのリクエストＵＲＬに関連づけられたプロテクトストリングが存在しない）と判定すると、ディスパッチャはそのブラウザのリクエストを関連するカートリッジにディスパッチして、カートリッジ自身の認証ルーチンを起動する。カートリッジにおける認証ルーチンのロジックが、認証ルーチンの起動に対してカートリッジがどのように応答するのかを判定する。カートリッジの使用が制限されていなければ、カートリッジの認証メソッドは単に、「ＴＲＵＥ」を戻すであろう。
【０１５６】
これに対し、認証が必要とされる場合には、認証メソッドは、ブラウザのリクエストを認証するために認証サーバと通信することができる。たとえば、この認証メソッドは、上述のディスパッチャと同じ態様で、カートリッジが認証サーバ８２８と相互作用するようにすることもできる。一実施例においては、ブラウザのリクエスト自体を認証するために、各カートリッジは、ディスパッチャが使用したであろうのと同じ認証リクエストフォーマット（すなわち、プロテクトストリングフォーマット）を使用する。しかし、カートリッジには関連したプロテクトストリングが存在しないため、カートリッジ自身が、どの認証パラメータを使用すべきかを判定する。
【０１５７】
カートリッジが認証を行なうことを決めた場合、カートリッジはオブジェクトリクエストブローカ２８２から認証エンジンを割当ててもらうように要求する。特定の認証エンジンを識別するのに、オブジェクトリクエストブローカ２８２は負荷の最適配分方式を使用して、認証エンジンの作業量の最適配分を試みる。その後、オブジェクトリクエストブローカ２８２は使用すべき特定の認証エンジンを識別して、カートリッジに通知する。するとカートリッジは、認証リクエストをその特定の認証エンジンへと、オブジェクトリクエストブローカ２８２を介して送信する。
【０１５８】
認証エンジンは、認証リクエストを受取ると、その認証リクエストを解析して１または複数のプロバイダのリクエストとする。その後、認証エンジンはオブジェクトリクエストブローカ２８２に対して、それら１または複数のプロバイダのリクエストを処理することのできるプロバイダに関連づけられた１または複数の認証ホストを識別するように要求する。この１または複数の認証ホストを識別する際に、オブジェクトリクエストブローカ２８２はやはり負荷の最適配分方式を使用して、それら認証ホストの作業量の最適配分を試みる。オブジェクトリクエストブローカ２８２は、１または複数の認証ホストを識別して、認証エンジンに通知する。すると、認証エンジンは、１または複数のプロバイダのリクエストをオブジェクトリクエストブローカ２８２を介してそれら１または複数の認証ホストに送信する。１または複数の認証ホストはその後、それらプロバイダのリクエストを適切なプロバイダへと分配する。
【０１５９】
プロバイダは、プロバイダのリクエストの認証を完了すると、関連する認証ホストおよびオブジェクトリクエストブローカ２８２を介して認証エンジンへと応答メッセージを送り返す。１または複数のプロバイダから応答メッセージを受取ると、認証エンジンはそれら戻された応答メッセージに対して必要な論理演算を行なう。その後、認証エンジンはカートリッジに対して、ブラウザのリクエストがカートリッジにアクセスすることを許可されるべきかどうかを通知する。
【０１６０】
本発明は、クライアントのリクエストを認証するための、非常にスケーラブルで柔軟性がありかつ拡張可能な機構を提供する。多くの利点はこの開示から当業者には明らかであろうが、ここで、いくつかの特定の利点に注目されたい。
【０１６１】
第１に、認証サーバが分散型であることに留意されたい。基礎をなす通信機構としてオブジェクトリクエストブローカが使用されるので、また、このオブジェクトリクエストブローカがマシンとは独立した通信機構であるので、認証エンジンおよび認証ホスト等の種々の構成要素を異なるマシンのどのような組合せ上にも設けることができる（すなわち分散することができる）。それらマシンは、その構成にかかわらず、オブジェクトリクエストブローカを介して互いに通信することができるであろう。本発明のこの分散型という性質によって、能力の追加が最も必要とされる場所に、戦略的にマシンを追加することができる。たとえば、認証能力の増強が必要とされる場合には、追加の認証エンジンを実行するようマシンを追加することができる。マシンを追加することによってシステムを自由に拡張することができることで、本発明は非常にスケーラブルとなっている。
【０１６２】
第２に、本発明は負荷の最適配分によって効率を改善している。上述のように複数の認証エンジンおよび認証ホストの間で負荷を最適配分することによって、本発明はボトルネックの可能性を最小に抑え、かつ、利用可能なリソースを最大限に効率的に使用することができる。
【０１６３】
第３に、本発明は、配置時にシステムの実装を変更することができる。前述のように、各プロバイダは好ましくはＤＬＬの形をとり、ランタイムにシステムへとリンク・インすることができる。プロバイダのモジュールがランタイムにリンク・インされるので、配置時において（１）あるプロバイダを別のプロバイダに置換すること、および（２）システムに別のプロバイダを付加することができる。認証サーバのアーキテクチャによって、これらすべては他のモジュール（たとえば認証エンジンおよび認証ホスト）をいずれも変更または再コンパイルすることなく行なうことができる。プロバイダのその置換／付加を反映するようにメタデータを更新するだけでよい。この局面によって、本発明は非常に柔軟性がありかつ容易に拡張可能となっている。さらに、特定のクエリーに関連する認証方式を、配置時に容易に変更することができることにも留意されたい。このためには、そのクエリーに関連づけられたプロテクトストリングを変更するだけでよい。したがって、たとえば、現時点においてＢＡＳＩＣおよびＩＰ認証方式を要求しているクエリーを、プロテクトストリングを単に
URL1 CARTRIDGE＿238 BASIC(GROUP1) AND IP(IP＿LIST)
から
URL1 CARTRIDGE＿238 IP(IP＿LIST)
へと変更するだけで、ＩＰ方式のみを要求するように変更することができる。
【０１６４】
したがって、配置時におけるサーバの実装の変更は極めて容易である。
第４に、本発明が、カートリッジからのリクエストを認証する作業の、すべてではないにせよその大半を取除くことができることに留意されたい。各カートリッジに対する認証のプロセスを認証サーバが実現するようにしていることによって、カートリッジがリクエストを認証する必要が軽減される。
【０１６５】
以上のように、本発明は、クライアントのリクエストを認証するための非常に有効でありかつ有益な機構を提供する。
【０１６６】
以上、本明細書において、本発明を特定の実施例に関連して説明した。しかし、本発明のより広い範囲から離れることなく、それら実施例に対して種々の変形および変更を行なうことができることは明らかであろう。したがって、本明細書および添付の図面は、限定のためのものではなく例示のためのものであると理解されたい。
【図面の簡単な説明】
【図１】 本発明の一実施例が実装され得るコンピュータシステムのブロック図である。
【図２】 本発明の一実施例に従った、分散アプリケーションサーバのブロック図である。
【図３Ａ】 本発明の一実施例に従った、ブラウザリクエストを処理するためのステップを示すフローチャートの一部である。
【図３Ｂ】 本発明の一実施例に従った、ブラウザリクエストを処理するためのステップを示すフローチャートの別の部分である。
【図４】 本発明の一実施例に従った、ディスパッチャが維持する情報を含む表のブロック図である。
【図５】 本発明の一実施例に従った、リソースマネージャが維持する情報を含む表のブロック図である。
【図６】 本発明の一実施例に従った、ステートレスウェブ環境において拡張可能な認証機構を提供する分散型のアプリケーションサーバのブロック図である。
【図７Ａ】 本発明の一実施例に従った、ブラウザのリクエストを認証するためのステップを示すフローチャートの一部である。
【図７Ｂ】 本発明の一実施例に従った、ブラウザのリクエストを認証するためのステップを示すフローチャートの別の部分である。
【図８】 本発明の一実施例に従った、ステートレスウェブ環境において拡張可能な認証機構の負荷の最適配分を行なうことのできる分散型のアプリケーションサーバのブロック図である。
Claims (34)
- オペレーションを認証するかどうかを判定するための方法であって、該オペレーションは、第１のマシン上で実行するカートリッジ（２３０）によって行なわれるべきオペレーションであり、該方法は、第２のマシン上でディスパッチャ（２１４）を実行するステップと、第３のマシン上で認証サーバ（２５２）の少なくとも１つの構成要素を実行するステップとを含み、
前記方法は、
前記第２のマシンとは異なるマシン上で実行するクライアントから前記ディスパッチャ（２１４）にリクエストを受取るステップと、
第１のメッセージを、前記クライアントおよび前記カートリッジに対してトランスペアレントに、ディスパッチャ（２１４）から認証サーバ（２５２）に送信するステップとを含み、該第１のメッセージはカートリッジ（２３０）に関連付けられた許可情報を含み、さらに、
第２のメッセージを、前記クライアントおよび前記カートリッジに対してトランスペアレントに、認証サーバ（２５２）からディスパッチャ（２１４）に送信するステップを含み、該第２のメッセージはオペレーションがカートリッジ（２３０）によって行なわれるよう許可されるかどうかを示し、さらに、
オペレーションがカートリッジ（２３０）によって行なわれるよう許可された場合には、第３のメッセージをディスパッチャ（２１４）からカートリッジ（２３０）に送信して、該カートリッジ（２３０）に該オペレーションを行なわせるようにするステップを含み、
該第１のマシン、第２のマシンおよび第３のマシンのうち、少なくとも２つが別々のマシンであることによって特徴づけられ、
第１のメッセージを認証エンジン（６０２）に送信するステップと、
第１のメッセージを解析して１または複数の第４のメッセージとするステップと、
１または複数の第４のメッセージを認証ホスト（６０４）に送信するステップとをさらに含み、該認証ホスト（６０４）は１または複数のプロバイダ（６０６，６０８，６１０，６１２）に関連付けられ、さらに、
１または複数の第４のメッセージの各々を１または複数のプロバイダ（６０６，６０８，６１０，６１２）のうちの１つに送信するステップを含み、該１または複数のプロバイ
ダ（６０６，６０８，６１０，６１２）の各々は、それが受取る１または複数の第４のメッセージの各々に対して認証を行なう、方法。 - ブラウザ（２０２）がブラウザのリクエストをウェブリスナ（２１０）に送信するステップと、
ウェブリスナ（２１０）がブラウザのリクエストをディスパッチャ（２１４）に渡すステップとをさらに含み、
該ディスパッチャ（２１４）はウェブリスナ（２１０）からブラウザのリクエストを受信したのに応答して第１のメッセージを送信する、請求項１に記載の方法。 - 第１のマシンと第２のマシンとが別々のマシンであって、
第１のメッセージをディスパッチャ（２１４）から認証サーバ（２５２）に送信するステップは、第１のメッセージをオブジェクトリクエストブローカ（２８２）を介してディスパッチャ（２１４）から認証サーバ（２５２）に送信することによって行なわれ、
第２のメッセージを認証サーバ（２５２）からディスパッチャ（２１４）に送信するステップは、第２のメッセージをオブジェクトリクエストブローカ（２８２）を介して認証サーバ（２５２）からディスパッチャ（２１４）に送信することによって行なわれる、請求項１に記載の方法。 - 第１のメッセージをディスパッチャ（２１４）から認証サーバ（２５２）に送信するステップは、認証サーバ（２５２）が第１のメッセージに関連する情報に基づいて、オペレーションがカートリッジに（２３０）よって行なわれるよう許可されるべきであるかどうかを判定するステップを含む、請求項１に記載の方法。
- 第３のマシン上で認証サーバ（２５２）の少なくとも１つの構成要素を実行するステップは、
第３のマシン上で認証エンジン（６０２）を実行するステップと、
第４のマシン上で認証ホスト（６０４）を実行するステップとを含み、
第３のマシンと第４のマシンとは別々のマシンである、請求項１に記載の方法。 - １または複数の第４のメッセージに対して行なわれる認証に基づいて、１または複数の応答メッセージを認証エンジン（６０２）に送信するステップと、
１または複数の応答メッセージに基づいて、オペレーションがカートリッジ（２３０）によって行なわれるよう許可されるべきかどうかを判定するステップとをさらに含む、請求項１に記載の方法。 - 第１のメッセージをディスパッチャ（２１４）から認証エンジン（６０２）に送信するステップは、第１のメッセージをオブジェクトリクエストブローカ（２８２）を介してディスパッチャ（２１４）から認証エンジン（６０２）に送信するステップを含み、
１または複数の第４のメッセージを認証ホスト（６０４）に送信するステップは、１または複数の第４のメッセージをオブジェクトリクエストブローカ（２８２）を介して認証ホスト（６０４）に送信するステップを含む、請求項１に記載の方法。 - 複数の認証エンジンを実行するステップと、
複数の認証ホストを実行するステップと、
第１のメッセージをディスパッチャ（２１４）から受取るべき特定の認証エンジン（６０２）を選択するステップと、
１または複数の第４のメッセージを受取るべき１または複数の認証ホストを選択するステップとをさらに含む、請求項７に記載の方法。 - 第１のメッセージをディスパッチャ（２１４）から受取るべき特定の認証エンジン（６０２）を選択するステップは、オブジェクトリクエストブローカ（２８２）が第１のメッセージを受取る特定の認証エンジン（６０２）を選択するステップを含み、
１または複数の第４のメッセージを受取るべき１または複数の認証ホストを選択するステップは、オブジェクトリクエストブローカ（２８２）が１または複数の第４のメッセージを受取る１または複数の認証ホストを選択するステップを含む、請求項８に記載の方法
。 - 特定の認証エンジン（６０２）を選択するステップは、複数の認証エンジンの作業量に基づいて特定の認証エンジン（６０２）を選択するステップを含み、
１または複数の認証ホストを選択するステップは、複数の認証ホストの作業量に基づいて１または複数の認証ホストを選択するステップを含む、請求項８に記載の方法。 - プロバイダ（６０６，６０８，６１０，６１２）を認証ホスト（６０４）と動的に関連付けたり分離したりするステップをさらに含む、請求項１に記載の方法。
- 認証サーバ（２５２）が２つ以上のプロバイダから受取られた結果を組合せるための論理演算を行なうステップをさらに含む、請求項６に記載の方法。
- 第１のメッセージを送信するのに先立って、オペレーションを認証するのに複数のプロバイダ（６０６，６０８，６１０，６１２）のうちどのプロバイダが使用されるべきかをディスパッチャ（２１４）に判定させるステップをさらに含む、請求項１に記載の方法。
- 第１のメッセージをディスパッチャ（２１４）から認証サーバ（２５２）に送信するステップは、ディスパッチャ（２１４）がプロテクトストリングに基づいて、第１のメッセージを認証サーバ（２５２）に送信するべきかどうかを判定するステップを含む、請求項１に記載の方法。
- １または複数のプロバイダ（６０６，６０８，６１０，６１２）は、各々が明確な判断基準の組に基づいて認証を行なう複数のプロバイダを表わす、請求項１に記載の方法。
- オペレーションを認証するかどうかを判定するためのプログラムを記録したコンピュータ可読媒体であって、該オペレーションは、第１のコンピュータ上で実行するカートリッジ（２３０）によって行なわれるべきオペレーションであり、
前記プログラムは、第２のコンピュータにディスパッチャ（２１４）を実行させ、第３のコンピュータに認証サーバ（２５２）の少なくとも１つの構成要素を実行させ、
前記プログラムは、前記第２のコンピュータに、
前記第２のコンピュータとは異なるコンピュータ上で実行するクライアントから前記ディスパッチャ（２１４）にリクエストを受取るステップと、
第１のメッセージを、前記クライアントおよび前記カートリッジに対してトランスペアレントに、ディスパッチャ（２１４）から認証サーバ（２５２）に送信するステップとを実行させ、該第１のメッセージはカートリッジ（２３０）に関連づけられた許可情報を含み、さらに、
前記プログラムは、さらに前記第３のコンピュータに、
第２のメッセージを、前記クライアントおよび前記カートリッジに対してトランスペアレントに、認証サーバ（２５２）からディスパッチャ（２１４）に送信するステップを実行させ、該第２のメッセージはオペレーションがカートリッジ（２３０）によって行なわれるよう許可されるべきかどうかを示し、さらに、
前記プログラムは、さらに前記第２のコンピュータに、
オペレーションがカートリッジ（２３０）によって行なわれるよう許可された場合には、第３のメッセージをディスパッチャ（２１４）からカートリッジ（２３０）に送信して、カートリッジ（２３０）に該オペレーションを行なわせるようにするステップを実行させ、
該第１のコンピュータ、該第２のコンピュータおよび該第３のコンピュータのうち、少なくとも２つが別々のコンピュータであり、
前記プログラムは、さらに、１または複数のコンピュータに、
第１のメッセージを認証エンジン（６０２）に送信するステップと、
第１のメッセージを解析して１または複数の第４のメッセージとするステップと、
１または複数の第４のメッセージを認証ホスト（６０４）に送信するステップとを実行させ、該認証ホスト（６０４）は１または複数のプロバイダ（６０６，６０８，６１０，
６１２）に関連付けられ、さらに、
１または複数の第４のメッセージの各々を１または複数のプロバイダ（６０６，６０８，６１０，６１２）のうちの１つに送信するステップを実行させ、該１または複数のプロバイダ（６０６，６０８，６１０，６１２）はそれが受取る１または複数の第４のメッセージの各々に対して認証を行なうよう構成される、コンピュータ可読媒体。 - 前記プログラムは、さらに、１または複数のコンピュータに、
ブラウザ（２０２）がブラウザのリクエストをウェブリスナ（２１０）に送信するステップと、
ウェブリスナ（２１０）がブラウザのリクエストをディスパッチャ（２１４）に渡すステップとを実行させ、
該ディスパッチャ（２１４）は、ウェブリスナ（２１０）からブラウザのリクエストを受取ったのに応答して第１のメッセージを送信する、請求項１６に記載のコンピュータ可読媒体。 - 該第１のコンピュータと該第２のコンピュータとが別々のコンピュータであって、
第１のメッセージをディスパッチャ（２１４）から認証サーバ（２５２）に送信するステップは、第１のメッセージをオブジェクトリクエストブローカ（２８２）を介してディスパッチャ（２１４）から認証サーバ（２５２）に送信することによって行なわれ、
第２のメッセージを認証サーバ（２５２）からディスパッチャ（２１４）に送信するステップは、第２のメッセージをオブジェクトリクエストブローカ（２８２）を介して認証サーバ（２５２）からディスパッチャ（２１４）に送信することによって行なわれる、請求項１６に記載のコンピュータ可読媒体。 - 第１のメッセージをディスパッチャ（２１４）から認証サーバ（２５２）に送信するステップは、認証サーバ（２５２）が第１のメッセージに関連する情報に基づいて、オペレーションがカートリッジ（２３０）によって行なわれるように許可されるべきかどうかを判定するステップを含む、請求項１６に記載のコンピュータ可読媒体。
- 前記第３のコンピュータで実行される前記認証サーバ（２５２）の少なくとも１つの構成要素は、認証エンジン（６０２）であり、
前記プログラムは、さらに、第４のコンピュータに認証サーバ（２５２）の別の構成要素である認証ホスト（６０４）を実行させ、
該第３のコンピュータと該第４のコンピュータとは別々のコンピュータである、請求項１６に記載のコンピュータ可読媒体。 - 前記プログラムは、さらに、１または複数のコンピュータに、
１または複数の第４のメッセージに対して行なわれる認証に基づいて、１または複数の応答メッセージを認証エンジン（６０２）に送信するステップと、
１または複数の応答メッセージに基づいて、オペレーションがカートリッジ（２３０）によって行なわれるよう許可されるべきかどうかを判定するステップとを実行させる、請求項１６に記載のコンピュータ可読媒体。 - 第１のメッセージをディスパッチャ（２１４）から認証エンジン（６０２）に送信するステップは、第１のメッセージをオブジェクトリクエストブローカ（２８２）を介してディスパッチャ（２１４）から認証エンジン（６０２）に送信するステップを含み、
１または複数の第４のメッセージを認証ホスト（６０４）に送信するステップは、１または複数の第４のメッセージをオブジェクトリクエストブローカ（２８２）を介して認証ホスト（６０４）に送信するステップを含む、請求項１６に記載のコンピュータ可読媒体。 - 前記プログラムは、さらに、１または複数のコンピュータに、
複数の認証エンジンを実行するステップと、
複数の認証ホストを実行するステップと、
ディスパッチャ（２１４）から第１のメッセージを受取るべき特定の認証エンジン（６０２）を選択するステップと、
１または複数の第４のメッセージを受取るべき１または複数の認証ホストを選択するステップとを実行させる、請求項２２に記載のコンピュータ可読媒体。 - ディスパッチャ（２１４）から第１のメッセージを受取るための特定の認証エンジン（６０２）を選択するステップは、オブジェクトリクエストブローカ（２８２）が第１のメッセージを受取る特定の認証エンジン（６０２）を選択するステップを含み、
１または複数の第４のメッセージを受取るべき１または複数の認証ホストを選択するステップは、オブジェクトリクエストブローカ（２８２）が１または複数の第４のメッセージを受取る１または複数の認証ホストを選択するステップを含む、請求項２３に記載のコンピュータ可読媒体。 - 特定の認証エンジン（６０２）を選択するステップは、複数の認証エンジンの作業量に基づいて特定の認証エンジン（６０２）を選択するステップを含み、
１または複数の認証ホストを選択するステップは、複数の認証ホストの作業量に基づいて１または複数の認証ホストを選択するステップを含む、請求項２３に記載のコンピュータ可読媒体。 - 前記プログラムは、さらに、１または複数のコンピュータに、
プロバイダ（６０６，６０８，６１０，６１２）を認証ホスト（６０４）と動的に関連付けたり分離したりするステップを実行させる、請求項１６に記載のコンピュータ可読媒体。 - 前記プログラムは、さらに、１または複数のコンピュータに、
認証サーバ（２５２）が２つ以上のプロバイダから受取られた結果を組合せる論理演算を行なうステップ実行させる、請求項２１に記載のコンピュータ可読媒体。 - 前記プログラムは、さらに、１または複数のコンピュータに、
第１のメッセージの送信に先立って、オペレーションを認証するのに複数のプロバイダ（６０６，６０８，６１０，６１２）のうちどのプロバイダが使用されるべきかをディスパッチャ（２１４）に判定させるステップを実行させる、請求項１６に記載のコンピュータ可読媒体。 - 第１のメッセージをディスパッチャ（２１４）から認証サーバ（２５２）に送信するステップは、ディスパッチャ（２１４）がプロテクトストリングに基づいて、第１のメッセージを認証サーバ（２５２）に送るべきかどうかを判定するステップを含む、請求項１６に記載のコンピュータ可読媒体。
- １または複数のプロバイダ（６０６，６０８，６１０，６１２）は、各々が明確な判断基準の組に基づいて認証を行なう複数のプロバイダを表わす、請求項１６に記載のコンピュータ可読媒体。
- ブラウザのリクエストが第１のマシン上で実行するカートリッジ（２３０）上で実行するよう許可されるかどうかを判定するためのシステムであって、
前記システムは、
複数のウェブリスナ（２１０，２１６，２２２）に連結された複数のディスパッチャ（２１４，２２０，２２６）を含み、前記複数のディスパッチャ（２１４，２２０，２２６）の各ディスパッチャは、前記複数のウェブリスナ（２１０，２１６，２２２）のうち対応するウェブリスナから、前記対応のウェブリスナによって受取られたブラウザのリクエストを受取り、前記対応のウェブリスナによって受取られたブラウザのリクエストは、前記対応のウェブリスナとは異なるマシン上で実行するクライアントから受取られ、さらに、
マシン間通信機構を介して前記複数のディスパッチャ（２１４，２２０，２２６）に連結された仮想パスマネージャ（２５０）を含み、前記仮想パスマネージャ（２５０）は、特定のブラウザのリクエストが認証を必要とするかどうかを前記ディスパッチャ（２１４，２２０，２２６）に対して示し、
前記複数のディスパッチャ（２１４，２２０，２２６）は複数の認証サーバに連結され、前記複数のディスパッチャ（２１４，２２０，２２６）は複数のメッセージを、前記クライアントおよび前記カートリッジに対してトランスペアレントに、前記マシン間通信機構を介して複数の認証サーバに送信するよう構成され、
前記複数の認証サーバは前記複数のディスパッチャ（２１４，２２０，２２６）から送信された前記複数のメッセージを認証することができ、該複数の認証サーバは、該特定のブラウザのリクエストがカートリッジ（２３０）上で実行するよう許可されるべきかどうかを、前記クライアントおよび前記カートリッジに対してトランスペアレントに、該複数のディスパッチャ（２１４，２２０，２２６）に対して知らせる、システム。 - 該マシン間の通信機構は、オブジェクトリクエストブローカ（２８２）である、請求項３１に記載のシステム。
- 該複数の認証サーバは、複数の認証エンジン（８０２，８０４，８０６）および複数の認証ホスト（８０８，８１４，８２２）からなる、請求項３１に記載のシステム。
- 該複数の認証ホストは、複数のプロバイダ（６０６，６０８，６１０，６１２）に関連付けられている、請求項３３に記載のシステム。
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US08/961,796 | 1997-10-31 | ||
| US08/961,796 US6446204B1 (en) | 1997-10-31 | 1997-10-31 | Method and apparatus for implementing an extensible authentication mechanism in a web application server |
| PCT/US1998/022832 WO1999023786A2 (en) | 1997-10-31 | 1998-10-29 | Method and apparatus for implementing an extensible authentication mechanism in a web application server |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001522115A JP2001522115A (ja) | 2001-11-13 |
| JP3853593B2 true JP3853593B2 (ja) | 2006-12-06 |
Family
ID=25505024
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000519525A Expired - Lifetime JP3853593B2 (ja) | 1997-10-31 | 1998-10-29 | ウェブアプリケーションサーバにおいて拡張可能な認証機構を実現するための方法および装置 |
Country Status (8)
| Country | Link |
|---|---|
| US (1) | US6446204B1 (ja) |
| EP (1) | EP1027795B9 (ja) |
| JP (1) | JP3853593B2 (ja) |
| AU (1) | AU750435B2 (ja) |
| CA (1) | CA2308797C (ja) |
| DE (1) | DE69821020T2 (ja) |
| HK (1) | HK1028687A1 (ja) |
| WO (1) | WO1999023786A2 (ja) |
Families Citing this family (65)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6427238B1 (en) * | 1998-05-29 | 2002-07-30 | Opentv, Inc. | Module manager for interactive television system |
| DE19910345A1 (de) * | 1999-03-09 | 2000-09-21 | Siemens Ag | Verfahren zur Nachrichtenübertragung zwischen einer einem ersten Prozeß zugewiesenen Clientinstanz und wenigstens einer mindestens einem weiteren Prozeß zugewiesenen Serverinstanz innerhalb eines verteilten Systems |
| US7391865B2 (en) | 1999-09-20 | 2008-06-24 | Security First Corporation | Secure data parser method and system |
| EP1218813A1 (en) | 1999-09-20 | 2002-07-03 | Ethentica, Inc. | Context sensitive dynamic authentication in a cryptographic system |
| US7490065B1 (en) | 1999-10-18 | 2009-02-10 | Stamps.Com | Cryptographic module for secure processing of value-bearing items |
| AU1966601A (en) * | 1999-10-18 | 2001-04-30 | Stamps.Com | Method and apparatus for on-line value-bearing item system |
| US6970641B1 (en) * | 2000-09-15 | 2005-11-29 | Opentv, Inc. | Playback of interactive programs |
| US7363361B2 (en) * | 2000-08-18 | 2008-04-22 | Akamai Technologies, Inc. | Secure content delivery system |
| WO2001061652A2 (en) | 2000-02-16 | 2001-08-23 | Stamps.Com | Secure on-line ticketing |
| US7444368B1 (en) * | 2000-02-29 | 2008-10-28 | Microsoft Corporation | Methods and systems for selecting methodology for authenticating computer systems on a per computer system or per user basis |
| US20050044405A1 (en) * | 2000-05-11 | 2005-02-24 | Spraggs Lynn D. | System and method of securing a computer from unauthorized access |
| EP1311946B1 (en) * | 2000-07-27 | 2017-12-27 | Oracle International Corporation | System and method for concentration and load-balancing of requests |
| US7941669B2 (en) * | 2001-01-03 | 2011-05-10 | American Express Travel Related Services Company, Inc. | Method and apparatus for enabling a user to select an authentication method |
| FR2820533B1 (fr) | 2001-02-07 | 2003-04-18 | Sagem | Systeme d'identification ou d'authentification biometrique |
| US7437437B2 (en) * | 2001-04-25 | 2008-10-14 | Hewlett-Packard Development Company, L.P. | Access authentication for distributed networks |
| US7274659B2 (en) | 2001-07-27 | 2007-09-25 | Western Digital Ventures, Inc. | Providing streaming media data |
| US7320075B2 (en) * | 2001-11-20 | 2008-01-15 | Safenet, Inc. | Software protection method utilizing hidden application code in a protection dynamic link library object |
| US7107615B2 (en) * | 2002-01-30 | 2006-09-12 | Hewlett-Packard Development Company, L.P. | Parameter verification in an authentication system and method |
| US7219231B2 (en) * | 2002-01-30 | 2007-05-15 | Hewlett-Packard Development Company, L.P. | Extensible authentication system and method |
| US7444410B1 (en) | 2002-02-15 | 2008-10-28 | Oracle International Corporation | Application platform execution environment |
| US7194473B1 (en) | 2002-02-15 | 2007-03-20 | Oracle International Corporation | Application platform development environment |
| US7191467B1 (en) * | 2002-03-15 | 2007-03-13 | Microsoft Corporation | Method and system of integrating third party authentication into internet browser code |
| US7614077B2 (en) * | 2002-04-10 | 2009-11-03 | International Business Machines Corporation | Persistent access control of protected content |
| US20040024771A1 (en) * | 2002-08-01 | 2004-02-05 | Oracle International Corporation | Buffered message queue architecture for database management systems with transactional enqueue support |
| US7188359B2 (en) * | 2002-12-18 | 2007-03-06 | America Online, Inc. | Optimizing authentication service availability and responsiveness via client-side routing |
| US7860957B1 (en) * | 2002-12-20 | 2010-12-28 | Cisco Technology, Inc. | System and method for managing network services in a distributed system |
| US6888431B2 (en) * | 2003-01-30 | 2005-05-03 | Square D Company | Remotely operated circuit breaker for emergency lighting circuits |
| US7685300B2 (en) * | 2003-09-04 | 2010-03-23 | International Business Machines Corporation | Method for access by server-side components using unsupported communication protocols through passthrough mechanism |
| US9614772B1 (en) | 2003-10-20 | 2017-04-04 | F5 Networks, Inc. | System and method for directing network traffic in tunneling applications |
| US20050198643A1 (en) * | 2004-02-17 | 2005-09-08 | Lachelt David J. | Journaling proxy in activation solution |
| US7523145B2 (en) * | 2004-04-22 | 2009-04-21 | Opentv, Inc. | System for managing data in a distributed computing system |
| US7818563B1 (en) * | 2004-06-04 | 2010-10-19 | Advanced Micro Devices, Inc. | Method to maximize hardware utilization in flow-thru IPsec processing |
| US8499153B2 (en) * | 2004-06-24 | 2013-07-30 | Nokia Corporation | System and method of authenticating a user to a service provider |
| US7428754B2 (en) * | 2004-08-17 | 2008-09-23 | The Mitre Corporation | System for secure computing using defense-in-depth architecture |
| EP1825412A1 (en) | 2004-10-25 | 2007-08-29 | Rick L. Orsini | Secure data parser method and system |
| US7779418B2 (en) * | 2004-12-30 | 2010-08-17 | Oracle International Corporation | Publisher flow control and bounded guaranteed delivery for message queues |
| US7788490B2 (en) * | 2005-04-01 | 2010-08-31 | Lexmark International, Inc. | Methods for authenticating an identity of an article in electrical communication with a verifier system |
| US8196150B2 (en) * | 2005-10-07 | 2012-06-05 | Oracle International Corporation | Event locality using queue services |
| CN105978683A (zh) | 2005-11-18 | 2016-09-28 | 安全第公司 | 安全数据解析方法和系统 |
| US20070258459A1 (en) * | 2006-05-02 | 2007-11-08 | Harris Corporation | Method and system for QOS by proxy |
| US8516153B2 (en) | 2006-06-16 | 2013-08-20 | Harris Corporation | Method and system for network-independent QoS |
| US7990860B2 (en) | 2006-06-16 | 2011-08-02 | Harris Corporation | Method and system for rule-based sequencing for QoS |
| US20070291767A1 (en) * | 2006-06-16 | 2007-12-20 | Harris Corporation | Systems and methods for a protocol transformation gateway for quality of service |
| US8064464B2 (en) | 2006-06-16 | 2011-11-22 | Harris Corporation | Method and system for inbound content-based QoS |
| US20070291765A1 (en) * | 2006-06-20 | 2007-12-20 | Harris Corporation | Systems and methods for dynamic mode-driven link management |
| US8730981B2 (en) | 2006-06-20 | 2014-05-20 | Harris Corporation | Method and system for compression based quality of service |
| US20100238801A1 (en) * | 2006-07-31 | 2010-09-23 | Smith Donald L | Method and system for stale data detection based quality of service |
| US8300653B2 (en) | 2006-07-31 | 2012-10-30 | Harris Corporation | Systems and methods for assured communications with quality of service |
| US20080025318A1 (en) * | 2006-07-31 | 2008-01-31 | Harris Corporation | Systems and methods for dynamically customizable quality of service on the edge of a network |
| US8904080B2 (en) | 2006-12-05 | 2014-12-02 | Security First Corp. | Tape backup method |
| US9779556B1 (en) | 2006-12-27 | 2017-10-03 | Stamps.Com Inc. | System and method for identifying and preventing on-line fraud |
| US20080228922A1 (en) * | 2007-03-14 | 2008-09-18 | Taiwan Semiconductor Manufacturing Company, Ltd. | System and Method for Providing Client Awareness in High-Availability Application Architecture |
| CN102932136B (zh) | 2007-09-14 | 2017-05-17 | 安全第一公司 | 用于管理加密密钥的系统和方法 |
| EP2106642A4 (en) | 2008-01-07 | 2015-12-02 | Security First Corp | SYSTEMS AND METHODS FOR SECURING DATA USING A KEY OR MULTI-FACTOR DISPERSION |
| CN103281190B (zh) | 2008-02-22 | 2018-03-09 | 安全第一公司 | 安全工作组管理和通信的系统和方法 |
| US9832069B1 (en) | 2008-05-30 | 2017-11-28 | F5 Networks, Inc. | Persistence based on server response in an IP multimedia subsystem (IMS) |
| CN102428686A (zh) | 2009-05-19 | 2012-04-25 | 安全第一公司 | 用于安全保护云中的数据的系统和方法 |
| EP2504973B1 (en) | 2009-11-25 | 2016-11-16 | Security First Corp. | Systems and methods for securing data in motion |
| JP2013524352A (ja) | 2010-03-31 | 2013-06-17 | セキュリティー ファースト コーポレイション | 移動中のデータをセキュア化するためのシステムおよび方法 |
| US8824492B2 (en) | 2010-05-28 | 2014-09-02 | Drc Computer Corporation | Accelerator system for remote data storage |
| US8392452B2 (en) * | 2010-09-03 | 2013-03-05 | Hulu Llc | Method and apparatus for callback supplementation of media program metadata |
| CN102801714B (zh) * | 2012-07-26 | 2015-03-11 | 杭州电子科技大学 | 旁路式解析和还原tns协议中sql命令的方法 |
| US8925050B2 (en) * | 2012-10-29 | 2014-12-30 | Oracle International Corporation | Communication between authentication plug-ins of a single-point authentication manager and client systems |
| US20140122437A1 (en) * | 2012-10-31 | 2014-05-01 | Kaseya International Limited | Dynamically provisioned storage server operating on a data communications network |
| EP3206357A1 (de) | 2016-02-09 | 2017-08-16 | Secunet Security Networks Aktiengesellschaft | Einsatz eines nicht lokalen kryptographie-verfahrens nach authentifizierung |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE69329577T2 (de) * | 1992-07-01 | 2001-05-31 | Ericsson Telefon Ab L M | Verfahren und system für implementierung-unabhängige schnittstellenspezifikation |
| US5649099A (en) | 1993-06-04 | 1997-07-15 | Xerox Corporation | Method for delegating access rights through executable access control program without delegating access rights not in a specification to any intermediary nor comprising server security |
| CA2138302C (en) * | 1994-12-15 | 1999-05-25 | Michael S. Fortinsky | Provision of secure access to external resources from a distributed computing environment |
| US5907675A (en) | 1995-03-22 | 1999-05-25 | Sun Microsystems, Inc. | Methods and apparatus for managing deactivation and shutdown of a server |
| US5812776A (en) * | 1995-06-07 | 1998-09-22 | Open Market, Inc. | Method of providing internet pages by mapping telephone number provided by client to URL and returning the same in a redirect command by server |
| AR003524A1 (es) * | 1995-09-08 | 1998-08-05 | Cyber Sign Japan Inc | Un servidor de verificacion para ser utilizado en la autenticacion de redes de computadoras. |
| US5903732A (en) * | 1996-07-03 | 1999-05-11 | Hewlett-Packard Company | Trusted gateway agent for web server programs |
-
1997
- 1997-10-31 US US08/961,796 patent/US6446204B1/en not_active Expired - Lifetime
-
1998
- 1998-10-29 WO PCT/US1998/022832 patent/WO1999023786A2/en active IP Right Grant
- 1998-10-29 DE DE69821020T patent/DE69821020T2/de not_active Expired - Lifetime
- 1998-10-29 JP JP2000519525A patent/JP3853593B2/ja not_active Expired - Lifetime
- 1998-10-29 AU AU12035/99A patent/AU750435B2/en not_active Expired
- 1998-10-29 CA CA002308797A patent/CA2308797C/en not_active Expired - Lifetime
- 1998-10-29 EP EP98955165A patent/EP1027795B9/en not_active Expired - Lifetime
-
2000
- 2000-12-08 HK HK00107911A patent/HK1028687A1/xx not_active IP Right Cessation
Also Published As
| Publication number | Publication date |
|---|---|
| AU1203599A (en) | 1999-05-24 |
| DE69821020T2 (de) | 2004-10-21 |
| JP2001522115A (ja) | 2001-11-13 |
| EP1027795B1 (en) | 2004-01-07 |
| AU750435B2 (en) | 2002-07-18 |
| CA2308797C (en) | 2008-03-25 |
| CA2308797A1 (en) | 1999-05-14 |
| WO1999023786A2 (en) | 1999-05-14 |
| DE69821020D1 (de) | 2004-02-12 |
| US6446204B1 (en) | 2002-09-03 |
| WO1999023786A3 (en) | 1999-07-15 |
| HK1028687A1 (en) | 2001-02-23 |
| EP1027795B9 (en) | 2004-09-08 |
| EP1027795A2 (en) | 2000-08-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3853593B2 (ja) | ウェブアプリケーションサーバにおいて拡張可能な認証機構を実現するための方法および装置 | |
| JP3853592B2 (ja) | 分散ウェブアプリケーションサーバ | |
| US6026404A (en) | Method and system for executing and operation in a distributed environment | |
| JP4729172B2 (ja) | 宣言型パラダイムをサポートするステートレスなウェブ環境におけるトランザクションを実行するための方法および装置 | |
| KR100464839B1 (ko) | 서브릿을처리하기위한장치및방법 | |
| EP0956687B1 (en) | Web request broker controlling multiple processes | |
| US6038603A (en) | Processing customized uniform resource locators | |
| US6629154B1 (en) | Method and system for deterministic hashes to identify remote methods | |
| JP2003534588A (ja) | 分散コンピューティング環境でのプロセスのデータ表現言語表現を使用するプロセスの移植 | |
| US20020198895A1 (en) | Apparatus and method for dynamically verifying information in a distributed system | |
| Cisco | Updating the Mainframe Application Software | |
| Cisco | Updating the Mainframe Application Software | |
| Cisco | Updating the Mainframe Application Software | |
| Cisco | Updating the Mainframe Application Software | |
| Cisco | Updating the Mainframe Application Software | |
| Cisco | Updating the Mainframe Application Software | |
| WO1999044138A2 (en) | Stack-based security requirements | |
| Guide | Unicenter® SOLVE: CPT™ |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A711 | Notification of change in applicant |
Free format text: JAPANESE INTERMEDIATE CODE: A711 Effective date: 20050913 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20051122 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20060221 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20060228 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060501 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060829 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060906 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100915 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110915 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120915 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130915 Year of fee payment: 7 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| EXPY | Cancellation because of completion of term |