JP3780507B2 - セッション情報の引継ぎ方法、アプリケーションサーバ、Ｗｅｂサイト、およびプログラム - Google Patents
セッション情報の引継ぎ方法、アプリケーションサーバ、Ｗｅｂサイト、およびプログラム Download PDFInfo
- Publication number
- JP3780507B2 JP3780507B2 JP2002070489A JP2002070489A JP3780507B2 JP 3780507 B2 JP3780507 B2 JP 3780507B2 JP 2002070489 A JP2002070489 A JP 2002070489A JP 2002070489 A JP2002070489 A JP 2002070489A JP 3780507 B2 JP3780507 B2 JP 3780507B2
- Authority
- JP
- Japan
- Prior art keywords
- redirect
- application
- cluster
- request
- information
- 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 - Fee Related
Links
Images
Classifications
-
- 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
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- 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/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/561—Adding application-functional data or data for application control, e.g. adding metadata
-
- 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
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
-
- 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/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/563—Data redirection of data network streams
-
- 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]
-
- 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
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1034—Reaction to server failures by a load balancer
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Library & Information Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer And Data Communications (AREA)
- Information Transfer Between Computers (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、Ｗｅｂに用いられるセッション情報の取り扱いに係り、より詳しくは、例えばサイトを移動した後にもとのサイトに戻る場合等におけるセッション情報の引継ぎ方法等に関する。
【０００２】
【従来の技術】
近年、Ｗｅｂ(World Wide Web)技術を使ったビジネスの発展に伴い、複数のＷｅｂサイトが協力してサービスを提供する形態のアプリケーションが開発されるようになっている。例えば、ユーザが保険会社のＷｅｂサイトから自分の保険を担保にして貸付を受けている銀行のサイトに移動して返済等の処理を行った後、再び保険会社のＷｅｂサイトに戻って作業を続ける、といったようなシナリオが存在する。
【０００３】
これらの多くのアプリケーションシナリオでは、ユーザがサイトＡからサイトＢに移動し、再びサイトＡ(Ａ'とする)に戻ってきたときに、ＡとＡ'との間でセッション情報が引き継がれている必要がある。通常、セッション情報は、サーバ側のメモリまたはデータベース上に格納されており、サーバ側アプリケーションは、ブラウザから送られてくるセッションＩＤをキーとして各ユーザ用のセッション情報にアクセスすることができる。セッションＩＤは、最初のセッション確立時にサーバからブラウザに送られ、以後クッキーとしてブラウザ側で保持されている。
【０００４】
しかし、実際に負荷分散サーバやシングルサインオン(Single-Sign On：一度のユーザ認証を受けるだけで、アクセス権を持つサーバやディレクトリなど、許可されている全ての機能を利用できるもの)用の認証サーバと組み合わせてＷｅｂアプリケーションシステムを構成した状態では、上記のようなセッション引継ぎの仕組みが機能しない場合が生じる。
【０００５】
図６は、このような問題が生じる可能性のある構成例を示した図である。図６に示す例では、自社サイト(サイトＡ)２０１、他社サイト(サイトＢ)２１１、およびブラウザ２２１がインターネット２３１を介して接続されている。この自社サイト２０１では、リバースプロキシ(セキュリティ確保のために全てのアクセスをプロキシサーバ経由で制御する)型の認証サーバ２０２と負荷分散サーバ２０３とを組み合わせて使用しており、ここでは、負荷分散サーバ２０３に振り分けられるアプリケーションサーバとして、第１Ｗｅｂアプリケーションサーバ２０４と第２Ｗｅｂアプリケーションサーバ２０５とが示されている。インターネット２３１を通じての要求の受け口となる認証サーバ２０２にはＩＰアドレス9.100.1.1が割り当てられているものとし、実際の処理を行う第１Ｗｅｂアプリケーションサーバ２０４と第２Ｗｅｂアプリケーションサーバ２０５には、夫々192.168.0.1と192.168.0.2のＩＰアドレスが割り当てられているものとする。負荷分散サーバ２０３は、３つのクラスタアドレス(負荷分散サーバ２０３が受け付ける仮想的なアドレス)192.168.1.0, 192.168.1.1, 192.168.1.2を所定のルールに従ってディスパッチしている。
【０００６】
図７は、各クラスタアドレスに対するディスパッチのルールを示した図である。ここでは、クラスタアドレス192.168.1.0は、ＨＴＴＰ要求ごとに192.168.0.1と192.168.0.2に均等にディスパッチすることをルールとしている。また、クラスタアドレス192.168.1.1は、原則として192.168.0.1にディスパッチし、192.168.0.1がダウンしていると判断された場合には192.168.0.2にディスパッチすることをルールとしている。更に、クラスタアドレス192.168.1.2は、原則として192.168.0.2にディスパッチし、192.168.0.2がダウンしていると判断された場合には192.168.0.1にディスパッチすることをルールとしている。
【０００７】
Ｗｅｂアプリケーションサーバへの最初の要求は、クラスタアドレス192.168.1.0経由で送られ、実アドレス192.168.0.1か192.168.0.2のどちらかにディスパッチされる。このとき、Ｗｅｂアプリケーションサーバ側のＨＴＴＰサーバの機能により、実アドレス192.168.0.1にディスパッチされた要求はクラスタアドレス192.168.1.1に、実アドレス192.168.0.2にディスパッチされた要求はクラスタアドレス192.168.1.2に、それぞれリダイレクト(一旦、ブラウザ側に応答を戻し再度自動的にサーバ側に要求を送ること)される。
【０００８】
認証サーバ２０２は、外部に対してただ一つのＩＰアドレス(9.100.1.1)しか見せていないことから、３つのクラスタアドレスで要求を受け付けるために、図８に示すような変換を行っている。この変換は、ブラウザ２２１からの要求ＵＲＬおよび応答のＨＴＭＬ中に記述されているＵＲＬ全般について行われる。例えば応答ＨＴＭＬ中のアンカータグに"/index.html"という記述があった場合には、"/cluster1/index.html"に変換されてブラウザ２２１に届く。このような処理を行うことにより、あるユーザからのＨＴＴＰ要求が最初は均等な確率で第１Ｗｅｂアプリケーションサーバ２０４および第２Ｗｅｂアプリケーションサーバ２０５の何れかにディスパッチされ、それ以降、そのユーザからの要求は、同じサーバにディスパッチされる(片寄せされる)ことが保証され、負荷分散を行いながらセッション情報を引き継いでいくことが可能になる。ブラウザ側のＩＰアドレスを用いてユーザを識別しディスパッチの片寄せを行う方法もあるが、図６に示す構成のようにフロントエンドに認証サーバ２０２が置かれる場合には機能しない。負荷分散サーバ２０３からは全ての要求が認証サーバ２０２から送られてくるように見えるため、ユーザの識別ができないことによる。
【０００９】
【発明が解決しようとする課題】
ここで、上述したような環境下において、ユーザを自社サイト２０１であるサイトＡから他社サイト２１１であるサイトＢに誘導し、再び自社サイト２０１であるサイトＡ'に誘導するという状況を考える。サイトＢからサイトＡ'にユーザを導くためには、サイトＢの応答ＨＴＭＬファイル中にサイトＡ'へリンクするためのＵＲＬ情報が記述されている必要があるが、提携関係にあるサイトＢに予め固定のＵＲＬ(9.100.1.1/cluster0)を伝えておき、ＨＴＭＬに埋め込んでもらうのが一般的である。
【００１０】
しかしながら、最初にサイトＡで片寄せが行われている場合、クッキーは"/cluster1"や"/cluster2"といったパス情報と結びついてブラウザ２２１側で管理され、パス情報が一致しないＵＲＬへの要求に関しては、セキュリティ上の理由によりセッションＩＤがサーバ側(自社サイト２０１)に送付されない。仮にサイトＡで9.100.1.1/cluster1に片寄せされて処理されていたセッションで、ユーザがサイトＢに移動後、9.100.1.1/cluster0でサイトＡ'に要求を出した場合、この要求がサイトＡで処理を行っていたのと同じＷｅｂアプリケーションサーバに送られたとしても、サーバ側アプリケーションでは以前のセッション情報にアクセスすることができない。ブラウザ２２１が9.100.1.1/cluster0と9.100.1.1/cluster1とは異なる送り先だと判断してしまい、9.100.1.1/cluster1とのやりとりで使っていたクッキー(セッションＩＤ)をサーバ側に対して送らないためである。
【００１１】
かかる問題は、
・認証サーバの方式やそこに設定するセキュリティポリシィ
・負荷分散の方式や構成
・自サイト→他サイト→自サイトと移動するアプリケーションシナリオ
等の組み合わせで発生する。技術的にはこのような問題が生じない認証や負荷分散の構成の仕方も存在するが、実際には認証や負荷分散の方式は、個々のアプリケーションシナリオとの適合性を検討する以前に他の多くの制約条件(会社全体のセキュリティポリシィ、パフォーマンス要求、他社製品の仕様等々)によって決定されてしまう。ユーザＩＤ等をキーとしてＷｅｂアプリケーションサーバ側でファイルやデータベースに格納したデータを引き継ぐ方式もあるが、個々のアプリケーション毎に個別の実装が必要となってしまう。
【００１２】
本発明は、以上のような技術的課題を解決するためになされたものであって、その目的とするところは、他サイトが間に入ったときのセッション引継ぎの問題をアプリケーションサーバ側で解決するための統一的な方法を提案することにある。
【００１３】
【課題を解決するための手段】
かかる目的のもと、本発明は、アプリケーションサーバ側に実際の処理を行うアプリケーション(実アプリケーション)とは別に、セッションの最初の要求を受け付ける第１のリダイレクトアプリケーションと、他サイトから戻ってくるときの要求を受け付ける第２のリダイレクトアプリケーションを用意する。この第１のリダイレクトアプリケーションと第２のリダイレクトアプリケーションは、一旦、ブラウザ側に応答を戻し、再度自動的にサーバ側に要求を送るリダイレクトの処理を行い、応答をブラウザ側に返す。ブラウザ側では、応答中の記述に従って自動的に、ユーザに意識させずに、改めてサーバ側の実アプリケーション宛に要求を送信する。本発明は、このリダイレクト処理によって、実アプリケーションを起動する際のクラスタアドレスを変更し、セッション引継ぎを可能としている。また、セッションの最初の片寄せ時(実アプリケーションのセッションが開始される前)に他サイトから戻ってきたときに必要なクラスタ情報(どちらのクラスタアドレスに片寄せされたか)を記録しておくことを特徴としている。
【００１４】
即ち、本発明は、負荷分散サーバを用いている自サイトから一旦、他サイトにブラウザ側が誘導され、再び自サイトへブラウザ側が誘導される際に有効なセッション情報の引継ぎ方法であって、この負荷分散サーバによるディスパッチの結果に基づくリダイレクトすべきクラスタアドレスをセットしてリダイレクト応答を生成するステップと、クラスタアドレスに片寄せされることを示すクラスタ情報をブラウザ側の識別情報ファイルにセットするステップと、リダイレクト応答を送信するステップと、クラスタアドレスに対する要求をブラウザ側から受信して実アプリケーションを実行するステップと、他サイトから自サイトに誘導されたブラウザ側から識別情報ファイルを含む要求を受信するステップと、受信した識別情報ファイルに含まれるクラスタ情報を取得するステップと、取得されたクラスタ情報に基づいて、先の自サイトに対する要求ではどのクラスタアドレスに片寄せされていたかを認識するステップと、認識されたクラスタアドレスをリダイレクト応答に記述するステップと、クラスタアドレスが記述されたリダイレクト応答をブラウザ側に送信するステップとを含んでいる。ここで、「識別情報ファイルにセットする」とは、メモリ上にセットする態様を含むものである。以下、同様である。
【００１５】
また、本発明が適用されるセッション情報の引継ぎ方法は、ＨＴＴＰ要求を受信するステップと、動作しているサーバの設定ファイルからリダイレクトすべきクラスタ情報を読み込むステップと、ＨＴＴＰ要求で受信したパラメータおよびクラスタ情報を用いて実アプリケーション起動用のリダイレクト応答を作成するステップと、クラスタ情報をクッキーとしてリダイレクト応答にセットするステップと、リダイレクト応答をブラウザ側に送信するステップと、他サイトから誘導されたブラウザ側からの新たなＨＴＴＰ要求を受信するステップと、新たなＨＴＴＰ要求にセットされているクラスタ情報を取得するステップと、新たなＨＴＴＰ要求で受信したパラメータおよび取得されたクラスタ情報を用いて新たなリダイレクト応答を作成するステップと、新たなリダイレクト応答をブラウザ側に送信するステップとを含むことを特徴としている。
【００１６】
更に、本発明が適用されるセッション情報の引継ぎ方法は、受信したＨＴＴＰ要求のクッキーにクラスタ情報が埋め込まれているか否かをチェックするステップと、クラスタ情報が埋め込まれている場合にはクラスタ情報を用いてリダイレクト応答を作成し、クラスタ情報が埋め込まれていない場合には設定ファイルから読み込んだ読み込みクラスタ情報を用いてリダイレクト応答を作成するステップと、クラスタ情報または読み込みクラスタ情報をクッキーとしてリダイレクト応答にセットするステップと、リダイレクト応答を送信するステップとを含むものである。上述した第１のリダイレクトアプリケーションと第２のリダイレクトアプリケーションとの機能を単一のリダイレクトアプリケーションにて機能させる場合に、上述のステップを実行することによりセッション情報の引継ぎが可能となる。
【００１７】
一方、本発明が適用されるアプリケーションサーバは、受信したＨＴＴＰ要求を処理し応答を返す実アプリケーションと、分配されたＨＴＴＰ要求により実アプリケーションの実行に先立って起動され、最初の分配に基づくクラスタ情報に基づいてリダイレクト応答を生成すると共に、クラスタ情報をブラウザのクッキーにセットしてリダイレクト応答を送信する第１のリダイレクトアプリケーションと、実アプリケーションの実行に先立って起動され、第１のリダイレクトアプリケーションがクッキーにセットしたクラスタ情報をブラウザから受信し、このクラスタ情報に基づいてリダイレクト応答を生成すると共に、生成されたリダイレクト応答を送信する第２のリダイレクトアプリケーションとを含むものである。
【００１８】
他の観点から捉えると、本発明が適用されるアプリケーションサーバは、ディスパッチされた要求に対して実際のアプリケーション処理を実行する実行手段と、この実行手段による実行に先立って、セッションの最初の要求を受け付けてリダイレクト処理を行い、リダイレクト応答をブラウザ側に返す第１のリダイレクト処理手段と、ブラウザ側が他サイトから戻ってくるときの要求に対して、実行手段による実行に先立ってリダイレクト処理を行い、リダイレクト応答をブラウザ側に返す第２のリダイレクト処理手段とを含んでいる。
【００１９】
また、本発明が適用されるアプリケーションサーバは、ディスパッチされた要求に対して実アプリケーションを実行する実行手段と、この実行手段による実行に先立って、サーバ側にてリダイレクト応答を実行することにより、実アプリケーションを起動する際のクラスタアドレスを変更してセッション引継ぎを可能にするリダイレクト処理手段と、実アプリケーションのセッションが開始される前であるセッションの最初の片寄せ時に、他サイトから戻ってきたときに必要なクラスタ情報(例えば、セッションの最初の片寄せ時にどのクラスタアドレスに片寄せされたかを示す情報)を記録する記録手段を含むことを特徴としている。
【００２０】
一方、本発明は、ブラウザからの要求に対して認証を行う認証サーバと、この認証サーバを経た要求をディスパッチする負荷分散サーバと、この負荷分散サーバによりディスパッチされた要求を処理するために設けられる複数のアプリケーションサーバとを含むＷｅｂサイトであって、このアプリケーションサーバは、実際にアプリケーションを実行する実アプリケーションと、ディスパッチされた最初の要求を受け付ける第１のリダイレクトアプリケーションと、ブラウザが他サイトから戻ってくるときの要求を受け付ける第２のリダイレクトアプリケーションとを含み、この第１のリダイレクトアプリケーションおよび第２のリダイレクトアプリケーションは、実アプリケーションを実行する前にリダイレクト処理を行い、要求に対するリダイレクト応答をブラウザに返すことを特徴としている。
【００２１】
尚、これらの各発明は、アプリケーションサーバとして機能するコンピュータに、各機能を実現させるためのプログラムとして把握することができる。これらのプログラムは、コンピュータに実行させるプログラムをコンピュータが読取可能に記憶した記憶媒体にて提供する形態が考えられる。この記憶媒体としては、例えばフロッピーディスクやＣＤ−ＲＯＭ媒体等が該当し、フロッピーディスクドライブやＣＤ−ＲＯＭ読取装置等によってプログラムが読み取られ、フラッシュＲＯＭ等にこのプログラムが格納されて実行される形態が考えられる。また、これらのプログラムは、例えば、プログラム伝送装置によってネットワークを介して提供される形態がある。このプログラム伝送装置としては、例えば、ホスト側のサーバに設けられ、プログラムを格納するメモリと、ネットワークを介してプログラムを提供するプログラム伝送手段とを備えている。更に、コンピュータ装置を顧客に対して提供する際に、装置の中にインストールされた状態にて提供される場合がある。
【００２２】
【発明の実施の形態】
以下、添付図面に示す実施の形態に基づいて本発明を詳細に説明する。
図１は、本実施の形態が適用されるネットワークシステムの全体構成を示した図である。図１に示すネットワークシステムでは、アプリケーションを実行する自サイト１０、このネットワークシステムのアプリケーションシナリオとして、ユーザを自サイト１０から誘導してアクセスされる他サイト１１、ネットワーク１３を介して自サイト１０や他サイト１１にアクセスするためのユーザ側のソフトウェアであるブラウザ１２、を備えている。本実施の形態におけるアプリケーションシナリオとしては、自サイト１０からユーザ(ブラウザ１２)を一旦、他サイト１１に誘導し、再び自サイト１０に誘導するという状況を考える。この自サイト１０に戻る間に、他サイト１１と同様な複数のサイトが間に入るアプリケーションシナリオも考えられる。
【００２３】
自サイト１０は、ネットワーク１３経由で自サイト１０にアクセスしてくるユーザの名前やパスワード等を一括管理して認証を行う認証サーバ２１、アプリケーションの負荷を均衡させるために、分配処理、即ち、実行可能状態のアプリケーションから優先順位の高いものを選択して処理を割り当てるディスパッチを行う負荷分散サーバ２２、個々のアプリケーションを実行するＷｅｂアプリケーションサーバ２３を備えている。自サイト１０には、複数のＷｅｂアプリケーションサーバ２３が設けられており、負荷分散サーバ２２によってディスパッチされる。
【００２４】
図１に示す例では、認証サーバ２１は外部に対してただ一つのＩＰアドレス(9.100.1.1)しか見せていない。負荷分散サーバ２２は、受け付ける仮想的なアドレスであるクラスタアドレスとして、例えば３つのクラスタアドレス(192.168.1.0、192.168.1.1、192.168.1.2)を備えている。Ｗｅｂアプリケーションサーバ２３の数が増加すれば、このクラスタアドレスの数も増加する。ブラウザ１２側から見えるクラスタアドレスは、図８に示したものと同様である。ブラウザ１２側から送られるクラスタアドレス9.100.1.1/cluster0、9.100.1.1/cluster1、9.100.1.1/cluster2は、内部的な３つのクラスタアドレス192.168.1.0、192.168.1.1、192.168.1.2に各々変換される。
【００２５】
図１に示す２つのＷｅｂアプリケーションサーバ２３は、実アドレスとして、例えば192.168.0.1および192.168.0.2が夫々割り当てられている。これらのＷｅｂアプリケーションサーバ２３は、実際の処理を行うアプリケーションである実アプリケーション３１、リダイレクトと呼ばれる処理を行い、一旦、応答をブラウザ１２側に返すためのアプリケーションであるリダイレクトアプリケーション３２を備えている。このリダイレクトアプリケーション３２は、セッションの最初の要求を受け付けるアプリケーションであるリダイレクトアプリケーションＡ(第１のリダイレクトアプリケーション)と、他サイト１１から戻ってくるときの要求を受け付けるアプリケーションであるリダイレクトアプリケーションＢ(第２のリダイレクトアプリケーション)が用意されている。リダイレクトアプリケーション３２によって応答が返されたブラウザ１２側では、応答中の記述に従って自動的に(ユーザに意識させずに)、改めてサーバ側の実アプリケーション３１宛に要求を送信する。
【００２６】
リダイレクトアプリケーションＡは、セッションにおける最初の要求のディスパッチ結果に基づくクラスタアドレスをリダイレクト応答の中にセットすることによりディスパッチ対象の片寄せを行う。同時にどちらのクラスタアドレスに片寄せされるのかを示す情報(クラスタ情報)をブラウザ１２側のクッキーにセットする。実アプリケーション３１は、片寄せされたクラスタアドレス経由で起動され、実アプリケーション３１用のセッションＩＤがブラウザ１２側のクッキーにセットされる。以後、このクラスタアドレス経由で要求が送られる限り、クッキー中のセッションＩＤがサーバ側に送信され、セッション情報の引き継ぎが可能になる。
【００２７】
他サイト１１に誘導され再び自サイト１０に戻ってくる場合には、他サイト１１は、返す応答ＨＴＭＬ中にリダイレクトアプリケーションＢを起動するためのリンクを記述しておく。リダイレクトアプリケーションＢはリダイレクトアプリケーションＡがクッキーにセットしたクラスタ情報をブラウザ１２から受信し、以前にどちらのクラスタアドレスに片寄せされたのかを知る。リダイレクト応答中にこのクラスタアドレスを記述することによって実アプリケーション３１をこのクラスタアドレス経由で起動することができる。
【００２８】
リダイレクトアプリケーションＡは、他サイト１１に移る前に片寄せされていたクラスタアドレスの情報を記録し、他サイト１１から戻るときには、リダイレクトアプリケーションＢが、この情報を利用してどちらに片寄せすべきかを決定し、クラスタアドレスを変更して実アプリケーション３１を起動する。これによって自サイト１０→他サイト１１→自サイト１０という遷移においてもセッション情報の引き継ぎが可能になる。
【００２９】
負荷分散の際に、クッキーを用いてクラスタアドレスの片寄せを行う手法は既に存在するが、本実施の形態では、
・リダイレクト処理によってアプリケーションを起動する際のクラスタアドレスを変更しセッション引継ぎを可能にする。
・セッションの最初の片寄せ時(実アプリケーション３１のセッションが開始される前)に他サイト１１から戻ってきたときに必要なクラスタ情報(どちらのクラスタアドレスに片寄せされたか)を記録しておく。
・負荷分散サーバ２２自体はＩＰレイヤでの処理を行う簡単な実装で実現できる。
という特徴を有している。
【００３０】
尚、クラスタアドレスは、例えば、192.168.0.1といった形式のＩＰアドレスを言う。また、クラスタ情報は、複数のクラスタアドレスにおける、その中のどの一つかを指定する情報である。例えば、３つのクラスタアドレス192.168.0.1、192.168.0.2、192.168.0.3のどれかを指定するためにクッキーに格納するクラスタ情報としては、例えば、値が“Ａ”か“Ｂ”か“Ｃ”をとる１文字等が使用される。
【００３１】
図２は、セッションの最初の要求に対するリダイレクトアプリケーション３２(リダイレクトアプリケーションＡ)の動作とそれに対するブラウザ１２の動作を説明するための図である。
まず、図中、▲１▼クラスタアドレス192.168.1.0への要求では、ユーザ認証後にブラウザ１２からＵＲＬ9.100.1.1/cluster0に送られたＨＴＴＰ(Hypertext Transfer Protocol：ＨＴＭＬ文書を送受信するためのプロトコル)要求は、認証サーバ２１によってクラスタアドレス192.168.1.0宛てに変換され、更に負荷分散サーバ２２によって実アドレス192.168.0.1または192.168.0.2に分配される。ＨＴＴＰ要求はリダイレクトアプリケーション３２(サーブレットまたはサーブレットから起動されるプログラム)の中のリダイレクトアプリケーションＡを起動するが、その引数として実アプリケーション３１(サーブレットまたはサーブレットから起動されるプログラム)を特定するための情報や実アプリケーション３１のロジックが必要とする引数の情報を含んでいる。
【００３２】
▲１▼のＨＴＴＰ要求は、その要求が実際にディスパッチされたＷｅｂアプリケーションサーバ２３上のリダイレクトアプリケーションＡによって処理され、▲２▼リダイレクト応答が作成される。リダイレクトアプリケーション３２によるリダイレクト処理は、ＨＴＴＰのLocationヘッダ、メタ(Meta)タグを記述したＨＴＭＬ応答、自動実行されるJavaScriptを含んだＨＴＭＬ応答などによって実現可能である。
【００３３】
このLocationヘッダによる応答では、リダイレクトアプリケーション３２が返す応答ヘッダ部にLocationヘッダという特別なヘッダをセットする。このヘッダの値として、リダイレクト先のＵＲＬを記述しておくと、応答を受信したブラウザ１２が自動的にリダイレクトを行う。メタ(Meta)タグによる応答では、リダイレクトアプリケーション３２が返す応答ボディ部(ＨＴＭＬ)にMETA HTTP-EQUIV="Refresh"を指定したメタタグを記述する。リダイレクト先ＵＲＬを例えば下記に示すようなＣＯＮＴＥＮＴ属性に記述しておく。
< META HTTP-EQUIV="Refresh"CONTENT="URL=http://xyz.com/">
また、JavaScriptによる応答では、リダイレクトアプリケーション３２が返す応答ボディ部(ＨＴＭＬ)に、ブラウザ画面表示後直ちに実行されるようなJavaScriptを記述する。JavaScriptの中にリダイレクト先ＵＲＬにジャンプするような記述を埋め込んでおく。このような方法によってリダイレクトを行うことが可能である。
【００３４】
図２に示す▲２▼の処理に際して、リダイレクトアプリケーションＡは、Ｗｅｂアプリケーションサーバ２３ごとに設定ファイルに記述してあるクラスタ情報(自身がどちらのクラスタアドレスで起動されるべきものか)を読み込み、リダイレクト応答中に実アプリケーション３１のクラスタアドレスを埋め込む。実アプリケーション３１のロジックに必要な引数もそのままリダイレクト応答の中に埋め込まれる。また、リダイレクトアプリケーションＡは、設定ファイルから読み込んだクラスタ情報をクッキーとしてリダイレクト応答のヘッダ内のSet-Cookieヘッダにセットする。リダイレクト応答が認証サーバ２１を経てブラウザ１２側に戻る過程でSet-Cookieに記述されているパス属性は変更され、"/cluster0"等の要求時クラスタを示す情報が追加される。パス属性は、ブラウザ１２側でのプライバシィ保護のために使われる情報であり、例えば"cluster0"のパス属性をもったクッキーは9.100.1.1/cluster0/...という形式の要求にのみ付加される。
【００３５】
図２に示す、▲３▼クラスタアドレス192.168.1.1または192.168.1.2への要求、では、リダイレクト応答を受信したブラウザ１２により、応答の内容に従って実アプリケーション３１へのＨＴＴＰ要求が自動的に送信される。リダイレクトアプリケーションＡによって片寄せが行われているので、要求の送信先は9.100.1.1/cluster1/...か9.100.1.1/cluster2/...となる。認証サーバ２１によって、これらの宛先アドレスはそれぞれクラスタアドレス192.168.1.1または192.168.1.2に変換された後、負荷分散サーバ２２によって実アドレス192.168.0.1または192.168.0.2にディスパッチされる。同時にブラウザ１２では、図中の▲２▼で送られてきたクッキーの内容(値や属性)がクライアント側のメモリまたはファイルに保存される。
【００３６】
図２に示す、▲４▼処理結果応答、に際し、実アプリケーション３１側に対しては何ら変更を行う必要はない。実アプリケーション３１は、従来どおり受信したＨＴＴＰ要求を処理して応答を返す。必要に応じてセッションオブジェクトを作成し、次のＨＴＴＰ要求処理に引き継ぐ情報をセットする。セッションオブジェクトを識別するためのセッションＩＤは、Ｗｅｂアプリケーションサーバ２３が作成し処理結果応答におけるヘッダのSet-Cookieヘッダにセットされる。このクッキーについても認証サーバ２１によりパス属性(実アプリケーション３１がどちらのクラスタアドレス経由で起動されたかによって"/cluster1"または"cluster2")が追加される。セッションＩＤのクッキーは、結果応答を受信したブラウザ１２側で保存される。以降、同一のクラスタアドレス(クッキーのパス属性が一致するアドレス)に対して送信された要求には、このセッションＩＤが付加されるので、サーバ側プログラムは引き続きセッション情報にアクセスすることができる。
【００３７】
図３は、他サイト１１に移動して戻ってくるときの要求に対するリダイレクトアプリケーション３２(リダイレクトアプリケーションＢ)の動作とそれに対するブラウザ１２の動作を説明するための図である。図２に示す▲４▼の動作の後、何回か自サイト１０とブラウザ１２との間で要求と応答とが繰り返される。その後、他サイト１１にＨＴＴＰ要求を送って他サイト１１との間で要求・応答を繰り返し、他サイト１１から受信したＨＴＭＬ中のリンクを用いて自サイト１０に送信した要求が図３に示す▲５▼に相当する。
【００３８】
この▲５▼クラスタアドレス192.168.1.0への要求、にて、他サイト１１から指定されたＵＲＬ9.100.1.1/cluster0に送られたＨＴＴＰ要求は、認証サーバ２１によってクラスタアドレス192.168.1.0宛てに変換され、更に、負荷分散サーバ２２によって実アドレス192.168.0.1または192.168.0.2に分配される。ＨＴＴＰ要求はリダイレクトアプリケーションＢを起動するが、その引数として、実アプリケーション３１を特定するための情報や実アプリケーション３１のロジックが必要とする引数の情報を含んでいる。
【００３９】
この要求は、パス部分が"/cluster0"であるため、図２に示す前述の▲４▼でクッキーにセットされたセッションＩＤの情報がブラウザ１２から送られることはない。つまり、リダイレクトアプリケーションＢから、以前に自サイト１０で作業していたときのセッション情報にアクセスすることはできない。しかながら、図２に示す前述▲２▼で送られたクラスタ情報のクッキーとはパス属性が一致するので、クラスタ情報は要求ヘッダにセットされてサーバ側に送られる。リダイレクトアプリケーションＢは、以前のセッション情報にアクセスできるようにするためにはどのようなクラスタアドレス経由で実アプリケーション３１を起動すればよいのか、を知ることができる。
【００４０】
▲５▼のＨＴＴＰ要求は、その要求が実際にディスパッチされたＷｅｂアプリケーションサーバ２３上のリダイレクトアプリケーションＢによって処理され、図３に示す、▲６▼リダイレクト応答、が作成される。リダイレクトアプリケーションＢは、受信した要求ヘッダから読み込んだクラスタ情報を用いて、リダイレクト応答中に実アプリケーション３１のクラスタアドレスを埋め込む。実アプリケーション３１のロジックに必要な引数もそのままリダイレクト応答の中に埋め込まれる。
【００４１】
リダイレクト応答を受信したブラウザ１２は、応答の内容に従って実アプリケーション３１へのＨＴＴＰ要求を自動的に送信する。要求の送信先クラスタアドレスは、前述の▲３▼の要求時と同様、▲７▼クラスタアドレス192.168.1.0または192.168.1.1への要求、となる。そのパス情報が、図２に示す▲４▼でセットされたクッキーのパス属性と一致することにより、セッションＩＤが要求ヘッダにセットされてサーバ側に送られる。図３中の、▲８▼処理結果応答、では、実アプリケーション３１は、受信したセッションＩＤをキーとしてセッションオブジェクトにアクセスし、業務ロジックを実行後、結果をブラウザ１２に返している。
【００４２】
次に、リダイレクトアプリケーション３２における処理について説明する。
図４(ａ),(ｂ)は、リダイレクトアプリケーション３２にて実行される処理を示したフローチャートであり、図４(ａ)はリダイレクトアプリケーションＡについての処理を、図４(ｂ)はリダイレクトアプリケーションＢについての処理を示している。
【００４３】
図４(ａ)に示すように、まず、ＨＴＴＰ要求を受信したリダイレクトアプリケーションＡは、付随するパラメータを取り出して保存する(ステップ１０１)。次に、リダイレクトアプリケーション３２が動作している各Ｗｅｂアプリケーションサーバ２３の設定ファイルから、リダイレクトすべきクラスタアドレスの情報を読み込む(ステップ１０２)。次に、リダイレクトアプリケーションＡは、ＨＴＴＰ要求で受信したパラメータおよびクラスタアドレスの情報を用いて実アプリケーション３１起動用のリダイレクト応答を作成する(ステップ１０３)。その後、Set-CookieヘッダをＨＴＴＰ応答のヘッダ部にセットして、クッキーへのクラスタ情報の埋め込みを行う(ステップ１０４)。そして、ＨＴＴＰ応答である用意したリダイレクト応答をブラウザ１２に送信して(ステップ１０５)、リダイレクトアプリケーションＡの処理が終了する。
【００４４】
リダイレクトアプリケーションＢの処理では、まず、ＨＴＴＰ要求を受信し、付随するパラメータを取り出して保存する(ステップ１１１)。次に、受信したＨＴＴＰ要求のヘッダ部にセットされているクッキーからクラスタアドレスの情報を取得する(ステップ１１２)。そして、ＨＴＴＰ要求で受信したパラメータおよびクラスタアドレスの情報を用いて実アプリケーション３１起動用のリダイレクト応答を作成する(ステップ１１３)。そして、ＨＴＴＰ応答である用意したリダイレクト応答をブラウザ１２に送信して(ステップ１１４)、リダイレクトアプリケーションＢの処理が終了する。
【００４５】
このように、本実施の形態では、サーバ側で、リダイレクト応答中に実アプリケーション３１のクラスタアドレスを埋め込むことで、応答を受信したブラウザ１２は、このクラスタアドレスに対して自動的に要求を送るリダイレクトを行うことができる。この「埋め込み」とは、具体的には、例えばJavaScriptやLocation等の特別なＨＴＴＰヘッダの中にクラスタアドレスを記述しておくことが挙げられる。
【００４６】
また、サーバ側で、クラスタ情報をクッキーとしてリダイレクト応答のヘッダ内のSet-Cookieヘッダにセットすることによって、応答を受信したブラウザ１２は、このクラスタ情報をクッキーとして、パーソナルコンピュータ(ＰＣ)内のメモリ/ディスクに格納する。以降、サーバに要求を送るときには、ブラウザ１２は格納していたクラスタ情報を要求データの一部として付加する。
【００４７】
図５は、リダイレクトアプリケーション３２にて、リダイレクトアプリケーションＡが動く場合とリダイレクトアプリケーションＢが動く場合との自動判定の処理を示したフローチャートである。まず、ＨＴＴＰ要求を受信し、付随するパラメータを取り出して保存する(ステップ１５１)。次に、受信したＨＴＴＰ要求のヘッダ部にクラスタ情報がクッキーとして埋め込まれているか否かをチェックし(ステップ１５２)、埋め込まれている場合には、ヘッダからのクラスタ情報を取得し、その情報をクラスタアドレスとして使用する(ステップ１５３)。クッキーとして埋め込まれていない場合には、サーバの設定ファイルからクラスタアドレスの情報を読み込む(ステップ１５４)。このようにして得られたクラスタアドレスの情報を用いて、実アプリケーション３１起動用のリダイレクト応答を作成する(ステップ１５５)。ここで、受信したＨＴＴＰ要求のヘッダ部にクラスタ情報を示すクッキーがセットされていたか否かを判断し(ステップ１５６)、セットされていない場合にはその情報をクッキーとして応答のヘッダ部にセットし(ステップ１５７)、ＨＴＴＰ応答をブラウザ１２に送信して(ステップ１５８)、処理が終了する。
【００４８】
このように、本実施の形態によれば、認証サーバ２１とＩＰレイヤベースの負荷分散サーバ２２とを組み合わせて使用するシステム構成において、自サイト１０→他サイト１１→自サイト１０という遷移にて、自サイト１０におけるセッションの引き継ぎが可能となる。リバースプロキシ型の認証サーバ２１を利用したシステム構成も、自サイト１０から他サイト１１に移動しまた自サイト１０に戻ってくるようなアプリケーションシナリオも、Ｗｅｂアプリケーションの高度化・複雑化に伴い、今後増加していくと予想される。また、企業のＷｅｂサイトにおいては、リライアビリティやスケーラビリティの観点から負荷分散サーバ２２の使用は必須である。従って、セッション引継ぎの問題は今後もしばしば発生すると考えられ、この問題を解決できる本実施の形態における価値は非常に高い。
【００４９】
尚、本実施の形態が適用されるＷｅｂサイト間(自サイト１０および他サイト１１)の連携シナリオについては、例えば、ユーザが保険会社のＷｅｂサイト(自サイト１０)から、自分の保険を担保にして貸付を受けている銀行サイト(他サイト１１)に移動して返済等の処理を行った後、再び保険会社のＷｅｂサイト(自サイト１０)に戻って作業を続ける、といったようなシナリオが考えられる。かかるシナリオに際して、一旦、銀行サイト(他サイト１１)に移行した後、保険会社のＷｅｂサイト(自サイト１０)に遷移した場合でも、保険契約作業等を継続させることができる。
【００５０】
また、例えば、ショッピングモールのサイト(自サイト１０)で買い物カゴに商品を入れた状態で、一旦、クレジット会社のサイト(他サイト１１)に移って引き落としの予定等を確認した後、ショッピングモールのサイト(自サイト１０)に戻って購入手続きを行う等のシナリオも考えられる。このとき、本実施の形態によれば、ショッピングモールのサイト(自サイト１０)が認証サーバ２１とＩＰレイヤベースの負荷分散サーバ２２とを組み合わせて使用するシステム構成にて、他サイト１１からショッピングモールのサイト(自サイト１０)に戻ってきたときのセッションの引き継ぎを可能とすることで、複数のサイトを遷移した後であっても円滑な作業継続が可能となる。
【００５１】
更には、旅行の予約をする際に、交通機関の予約をするサイト(自サイト１０)の手続き途中でホテルや宿関係のサイト(他サイト１１)に移動し、予約の確認を行ってから交通機関の予約をするサイト(自サイト１０)において交通機関の予約を最終的に決定する等のシナリオにも適用できる。このとき、本実施の形態によれば、交通機関の予約をするサイト(自サイト１０)にて、負荷分散機能をシステム構成とする場合に、旅行の予約に関連する他サイト１１に移行した後、自サイト１０に遷移した場合であってもセッションの引き継ぎが可能となり、交通機関の予約をするサイト(自サイト１０)にて予約作業を継続することができる。
【００５２】
【発明の効果】
以上説明したように、本発明によれば、他サイトが間に入ったときのセッション引継ぎの問題を解決することができる。
【図面の簡単な説明】
【図１】 本実施の形態が適用されるネットワークシステムの全体構成を示した図である。
【図２】 セッションの最初の要求に対するリダイレクトアプリケーション(リダイレクトアプリケーションＡ)の動作とそれに対するブラウザの動作を説明するための図である。
【図３】 他サイトに移動して戻ってくるときの要求に対するリダイレクトアプリケーション(リダイレクトアプリケーションＢ)の動作とそれに対するブラウザの動作を説明するための図である。
【図４】 (ａ),(ｂ)は、リダイレクトアプリケーションにて実行される処理を示したフローチャートである。
【図５】 リダイレクトアプリケーションにて、リダイレクトアプリケーションＡが動く場合とリダイレクトアプリケーションＢが動く場合との自動判定の処理を示したフローチャートである。
【図６】 セッション引継ぎの仕組みが機能しない場合が生じる可能性のある構成例を示した図である。
【図７】 各クラスタアドレスに対するディスパッチのルールを示した図である。
【図８】 内部的なクラスタアドレスとブラウザ側から見えるクラスタアドレスとの関係を示した図である。
【符号の説明】
１０…自サイト、１１…他サイト、１２…ブラウザ、１３…ネットワーク、２１…認証サーバ、２２…負荷分散サーバ、２３…Ｗｅｂアプリケーションサーバ、３１…実アプリケーション、３２…リダイレクトアプリケーション
【発明の属する技術分野】
本発明は、Ｗｅｂに用いられるセッション情報の取り扱いに係り、より詳しくは、例えばサイトを移動した後にもとのサイトに戻る場合等におけるセッション情報の引継ぎ方法等に関する。
【０００２】
【従来の技術】
近年、Ｗｅｂ(World Wide Web)技術を使ったビジネスの発展に伴い、複数のＷｅｂサイトが協力してサービスを提供する形態のアプリケーションが開発されるようになっている。例えば、ユーザが保険会社のＷｅｂサイトから自分の保険を担保にして貸付を受けている銀行のサイトに移動して返済等の処理を行った後、再び保険会社のＷｅｂサイトに戻って作業を続ける、といったようなシナリオが存在する。
【０００３】
これらの多くのアプリケーションシナリオでは、ユーザがサイトＡからサイトＢに移動し、再びサイトＡ(Ａ'とする)に戻ってきたときに、ＡとＡ'との間でセッション情報が引き継がれている必要がある。通常、セッション情報は、サーバ側のメモリまたはデータベース上に格納されており、サーバ側アプリケーションは、ブラウザから送られてくるセッションＩＤをキーとして各ユーザ用のセッション情報にアクセスすることができる。セッションＩＤは、最初のセッション確立時にサーバからブラウザに送られ、以後クッキーとしてブラウザ側で保持されている。
【０００４】
しかし、実際に負荷分散サーバやシングルサインオン(Single-Sign On：一度のユーザ認証を受けるだけで、アクセス権を持つサーバやディレクトリなど、許可されている全ての機能を利用できるもの)用の認証サーバと組み合わせてＷｅｂアプリケーションシステムを構成した状態では、上記のようなセッション引継ぎの仕組みが機能しない場合が生じる。
【０００５】
図６は、このような問題が生じる可能性のある構成例を示した図である。図６に示す例では、自社サイト(サイトＡ)２０１、他社サイト(サイトＢ)２１１、およびブラウザ２２１がインターネット２３１を介して接続されている。この自社サイト２０１では、リバースプロキシ(セキュリティ確保のために全てのアクセスをプロキシサーバ経由で制御する)型の認証サーバ２０２と負荷分散サーバ２０３とを組み合わせて使用しており、ここでは、負荷分散サーバ２０３に振り分けられるアプリケーションサーバとして、第１Ｗｅｂアプリケーションサーバ２０４と第２Ｗｅｂアプリケーションサーバ２０５とが示されている。インターネット２３１を通じての要求の受け口となる認証サーバ２０２にはＩＰアドレス9.100.1.1が割り当てられているものとし、実際の処理を行う第１Ｗｅｂアプリケーションサーバ２０４と第２Ｗｅｂアプリケーションサーバ２０５には、夫々192.168.0.1と192.168.0.2のＩＰアドレスが割り当てられているものとする。負荷分散サーバ２０３は、３つのクラスタアドレス(負荷分散サーバ２０３が受け付ける仮想的なアドレス)192.168.1.0, 192.168.1.1, 192.168.1.2を所定のルールに従ってディスパッチしている。
【０００６】
図７は、各クラスタアドレスに対するディスパッチのルールを示した図である。ここでは、クラスタアドレス192.168.1.0は、ＨＴＴＰ要求ごとに192.168.0.1と192.168.0.2に均等にディスパッチすることをルールとしている。また、クラスタアドレス192.168.1.1は、原則として192.168.0.1にディスパッチし、192.168.0.1がダウンしていると判断された場合には192.168.0.2にディスパッチすることをルールとしている。更に、クラスタアドレス192.168.1.2は、原則として192.168.0.2にディスパッチし、192.168.0.2がダウンしていると判断された場合には192.168.0.1にディスパッチすることをルールとしている。
【０００７】
Ｗｅｂアプリケーションサーバへの最初の要求は、クラスタアドレス192.168.1.0経由で送られ、実アドレス192.168.0.1か192.168.0.2のどちらかにディスパッチされる。このとき、Ｗｅｂアプリケーションサーバ側のＨＴＴＰサーバの機能により、実アドレス192.168.0.1にディスパッチされた要求はクラスタアドレス192.168.1.1に、実アドレス192.168.0.2にディスパッチされた要求はクラスタアドレス192.168.1.2に、それぞれリダイレクト(一旦、ブラウザ側に応答を戻し再度自動的にサーバ側に要求を送ること)される。
【０００８】
認証サーバ２０２は、外部に対してただ一つのＩＰアドレス(9.100.1.1)しか見せていないことから、３つのクラスタアドレスで要求を受け付けるために、図８に示すような変換を行っている。この変換は、ブラウザ２２１からの要求ＵＲＬおよび応答のＨＴＭＬ中に記述されているＵＲＬ全般について行われる。例えば応答ＨＴＭＬ中のアンカータグに"/index.html"という記述があった場合には、"/cluster1/index.html"に変換されてブラウザ２２１に届く。このような処理を行うことにより、あるユーザからのＨＴＴＰ要求が最初は均等な確率で第１Ｗｅｂアプリケーションサーバ２０４および第２Ｗｅｂアプリケーションサーバ２０５の何れかにディスパッチされ、それ以降、そのユーザからの要求は、同じサーバにディスパッチされる(片寄せされる)ことが保証され、負荷分散を行いながらセッション情報を引き継いでいくことが可能になる。ブラウザ側のＩＰアドレスを用いてユーザを識別しディスパッチの片寄せを行う方法もあるが、図６に示す構成のようにフロントエンドに認証サーバ２０２が置かれる場合には機能しない。負荷分散サーバ２０３からは全ての要求が認証サーバ２０２から送られてくるように見えるため、ユーザの識別ができないことによる。
【０００９】
【発明が解決しようとする課題】
ここで、上述したような環境下において、ユーザを自社サイト２０１であるサイトＡから他社サイト２１１であるサイトＢに誘導し、再び自社サイト２０１であるサイトＡ'に誘導するという状況を考える。サイトＢからサイトＡ'にユーザを導くためには、サイトＢの応答ＨＴＭＬファイル中にサイトＡ'へリンクするためのＵＲＬ情報が記述されている必要があるが、提携関係にあるサイトＢに予め固定のＵＲＬ(9.100.1.1/cluster0)を伝えておき、ＨＴＭＬに埋め込んでもらうのが一般的である。
【００１０】
しかしながら、最初にサイトＡで片寄せが行われている場合、クッキーは"/cluster1"や"/cluster2"といったパス情報と結びついてブラウザ２２１側で管理され、パス情報が一致しないＵＲＬへの要求に関しては、セキュリティ上の理由によりセッションＩＤがサーバ側(自社サイト２０１)に送付されない。仮にサイトＡで9.100.1.1/cluster1に片寄せされて処理されていたセッションで、ユーザがサイトＢに移動後、9.100.1.1/cluster0でサイトＡ'に要求を出した場合、この要求がサイトＡで処理を行っていたのと同じＷｅｂアプリケーションサーバに送られたとしても、サーバ側アプリケーションでは以前のセッション情報にアクセスすることができない。ブラウザ２２１が9.100.1.1/cluster0と9.100.1.1/cluster1とは異なる送り先だと判断してしまい、9.100.1.1/cluster1とのやりとりで使っていたクッキー(セッションＩＤ)をサーバ側に対して送らないためである。
【００１１】
かかる問題は、
・認証サーバの方式やそこに設定するセキュリティポリシィ
・負荷分散の方式や構成
・自サイト→他サイト→自サイトと移動するアプリケーションシナリオ
等の組み合わせで発生する。技術的にはこのような問題が生じない認証や負荷分散の構成の仕方も存在するが、実際には認証や負荷分散の方式は、個々のアプリケーションシナリオとの適合性を検討する以前に他の多くの制約条件(会社全体のセキュリティポリシィ、パフォーマンス要求、他社製品の仕様等々)によって決定されてしまう。ユーザＩＤ等をキーとしてＷｅｂアプリケーションサーバ側でファイルやデータベースに格納したデータを引き継ぐ方式もあるが、個々のアプリケーション毎に個別の実装が必要となってしまう。
【００１２】
本発明は、以上のような技術的課題を解決するためになされたものであって、その目的とするところは、他サイトが間に入ったときのセッション引継ぎの問題をアプリケーションサーバ側で解決するための統一的な方法を提案することにある。
【００１３】
【課題を解決するための手段】
かかる目的のもと、本発明は、アプリケーションサーバ側に実際の処理を行うアプリケーション(実アプリケーション)とは別に、セッションの最初の要求を受け付ける第１のリダイレクトアプリケーションと、他サイトから戻ってくるときの要求を受け付ける第２のリダイレクトアプリケーションを用意する。この第１のリダイレクトアプリケーションと第２のリダイレクトアプリケーションは、一旦、ブラウザ側に応答を戻し、再度自動的にサーバ側に要求を送るリダイレクトの処理を行い、応答をブラウザ側に返す。ブラウザ側では、応答中の記述に従って自動的に、ユーザに意識させずに、改めてサーバ側の実アプリケーション宛に要求を送信する。本発明は、このリダイレクト処理によって、実アプリケーションを起動する際のクラスタアドレスを変更し、セッション引継ぎを可能としている。また、セッションの最初の片寄せ時(実アプリケーションのセッションが開始される前)に他サイトから戻ってきたときに必要なクラスタ情報(どちらのクラスタアドレスに片寄せされたか)を記録しておくことを特徴としている。
【００１４】
即ち、本発明は、負荷分散サーバを用いている自サイトから一旦、他サイトにブラウザ側が誘導され、再び自サイトへブラウザ側が誘導される際に有効なセッション情報の引継ぎ方法であって、この負荷分散サーバによるディスパッチの結果に基づくリダイレクトすべきクラスタアドレスをセットしてリダイレクト応答を生成するステップと、クラスタアドレスに片寄せされることを示すクラスタ情報をブラウザ側の識別情報ファイルにセットするステップと、リダイレクト応答を送信するステップと、クラスタアドレスに対する要求をブラウザ側から受信して実アプリケーションを実行するステップと、他サイトから自サイトに誘導されたブラウザ側から識別情報ファイルを含む要求を受信するステップと、受信した識別情報ファイルに含まれるクラスタ情報を取得するステップと、取得されたクラスタ情報に基づいて、先の自サイトに対する要求ではどのクラスタアドレスに片寄せされていたかを認識するステップと、認識されたクラスタアドレスをリダイレクト応答に記述するステップと、クラスタアドレスが記述されたリダイレクト応答をブラウザ側に送信するステップとを含んでいる。ここで、「識別情報ファイルにセットする」とは、メモリ上にセットする態様を含むものである。以下、同様である。
【００１５】
また、本発明が適用されるセッション情報の引継ぎ方法は、ＨＴＴＰ要求を受信するステップと、動作しているサーバの設定ファイルからリダイレクトすべきクラスタ情報を読み込むステップと、ＨＴＴＰ要求で受信したパラメータおよびクラスタ情報を用いて実アプリケーション起動用のリダイレクト応答を作成するステップと、クラスタ情報をクッキーとしてリダイレクト応答にセットするステップと、リダイレクト応答をブラウザ側に送信するステップと、他サイトから誘導されたブラウザ側からの新たなＨＴＴＰ要求を受信するステップと、新たなＨＴＴＰ要求にセットされているクラスタ情報を取得するステップと、新たなＨＴＴＰ要求で受信したパラメータおよび取得されたクラスタ情報を用いて新たなリダイレクト応答を作成するステップと、新たなリダイレクト応答をブラウザ側に送信するステップとを含むことを特徴としている。
【００１６】
更に、本発明が適用されるセッション情報の引継ぎ方法は、受信したＨＴＴＰ要求のクッキーにクラスタ情報が埋め込まれているか否かをチェックするステップと、クラスタ情報が埋め込まれている場合にはクラスタ情報を用いてリダイレクト応答を作成し、クラスタ情報が埋め込まれていない場合には設定ファイルから読み込んだ読み込みクラスタ情報を用いてリダイレクト応答を作成するステップと、クラスタ情報または読み込みクラスタ情報をクッキーとしてリダイレクト応答にセットするステップと、リダイレクト応答を送信するステップとを含むものである。上述した第１のリダイレクトアプリケーションと第２のリダイレクトアプリケーションとの機能を単一のリダイレクトアプリケーションにて機能させる場合に、上述のステップを実行することによりセッション情報の引継ぎが可能となる。
【００１７】
一方、本発明が適用されるアプリケーションサーバは、受信したＨＴＴＰ要求を処理し応答を返す実アプリケーションと、分配されたＨＴＴＰ要求により実アプリケーションの実行に先立って起動され、最初の分配に基づくクラスタ情報に基づいてリダイレクト応答を生成すると共に、クラスタ情報をブラウザのクッキーにセットしてリダイレクト応答を送信する第１のリダイレクトアプリケーションと、実アプリケーションの実行に先立って起動され、第１のリダイレクトアプリケーションがクッキーにセットしたクラスタ情報をブラウザから受信し、このクラスタ情報に基づいてリダイレクト応答を生成すると共に、生成されたリダイレクト応答を送信する第２のリダイレクトアプリケーションとを含むものである。
【００１８】
他の観点から捉えると、本発明が適用されるアプリケーションサーバは、ディスパッチされた要求に対して実際のアプリケーション処理を実行する実行手段と、この実行手段による実行に先立って、セッションの最初の要求を受け付けてリダイレクト処理を行い、リダイレクト応答をブラウザ側に返す第１のリダイレクト処理手段と、ブラウザ側が他サイトから戻ってくるときの要求に対して、実行手段による実行に先立ってリダイレクト処理を行い、リダイレクト応答をブラウザ側に返す第２のリダイレクト処理手段とを含んでいる。
【００１９】
また、本発明が適用されるアプリケーションサーバは、ディスパッチされた要求に対して実アプリケーションを実行する実行手段と、この実行手段による実行に先立って、サーバ側にてリダイレクト応答を実行することにより、実アプリケーションを起動する際のクラスタアドレスを変更してセッション引継ぎを可能にするリダイレクト処理手段と、実アプリケーションのセッションが開始される前であるセッションの最初の片寄せ時に、他サイトから戻ってきたときに必要なクラスタ情報(例えば、セッションの最初の片寄せ時にどのクラスタアドレスに片寄せされたかを示す情報)を記録する記録手段を含むことを特徴としている。
【００２０】
一方、本発明は、ブラウザからの要求に対して認証を行う認証サーバと、この認証サーバを経た要求をディスパッチする負荷分散サーバと、この負荷分散サーバによりディスパッチされた要求を処理するために設けられる複数のアプリケーションサーバとを含むＷｅｂサイトであって、このアプリケーションサーバは、実際にアプリケーションを実行する実アプリケーションと、ディスパッチされた最初の要求を受け付ける第１のリダイレクトアプリケーションと、ブラウザが他サイトから戻ってくるときの要求を受け付ける第２のリダイレクトアプリケーションとを含み、この第１のリダイレクトアプリケーションおよび第２のリダイレクトアプリケーションは、実アプリケーションを実行する前にリダイレクト処理を行い、要求に対するリダイレクト応答をブラウザに返すことを特徴としている。
【００２１】
尚、これらの各発明は、アプリケーションサーバとして機能するコンピュータに、各機能を実現させるためのプログラムとして把握することができる。これらのプログラムは、コンピュータに実行させるプログラムをコンピュータが読取可能に記憶した記憶媒体にて提供する形態が考えられる。この記憶媒体としては、例えばフロッピーディスクやＣＤ−ＲＯＭ媒体等が該当し、フロッピーディスクドライブやＣＤ−ＲＯＭ読取装置等によってプログラムが読み取られ、フラッシュＲＯＭ等にこのプログラムが格納されて実行される形態が考えられる。また、これらのプログラムは、例えば、プログラム伝送装置によってネットワークを介して提供される形態がある。このプログラム伝送装置としては、例えば、ホスト側のサーバに設けられ、プログラムを格納するメモリと、ネットワークを介してプログラムを提供するプログラム伝送手段とを備えている。更に、コンピュータ装置を顧客に対して提供する際に、装置の中にインストールされた状態にて提供される場合がある。
【００２２】
【発明の実施の形態】
以下、添付図面に示す実施の形態に基づいて本発明を詳細に説明する。
図１は、本実施の形態が適用されるネットワークシステムの全体構成を示した図である。図１に示すネットワークシステムでは、アプリケーションを実行する自サイト１０、このネットワークシステムのアプリケーションシナリオとして、ユーザを自サイト１０から誘導してアクセスされる他サイト１１、ネットワーク１３を介して自サイト１０や他サイト１１にアクセスするためのユーザ側のソフトウェアであるブラウザ１２、を備えている。本実施の形態におけるアプリケーションシナリオとしては、自サイト１０からユーザ(ブラウザ１２)を一旦、他サイト１１に誘導し、再び自サイト１０に誘導するという状況を考える。この自サイト１０に戻る間に、他サイト１１と同様な複数のサイトが間に入るアプリケーションシナリオも考えられる。
【００２３】
自サイト１０は、ネットワーク１３経由で自サイト１０にアクセスしてくるユーザの名前やパスワード等を一括管理して認証を行う認証サーバ２１、アプリケーションの負荷を均衡させるために、分配処理、即ち、実行可能状態のアプリケーションから優先順位の高いものを選択して処理を割り当てるディスパッチを行う負荷分散サーバ２２、個々のアプリケーションを実行するＷｅｂアプリケーションサーバ２３を備えている。自サイト１０には、複数のＷｅｂアプリケーションサーバ２３が設けられており、負荷分散サーバ２２によってディスパッチされる。
【００２４】
図１に示す例では、認証サーバ２１は外部に対してただ一つのＩＰアドレス(9.100.1.1)しか見せていない。負荷分散サーバ２２は、受け付ける仮想的なアドレスであるクラスタアドレスとして、例えば３つのクラスタアドレス(192.168.1.0、192.168.1.1、192.168.1.2)を備えている。Ｗｅｂアプリケーションサーバ２３の数が増加すれば、このクラスタアドレスの数も増加する。ブラウザ１２側から見えるクラスタアドレスは、図８に示したものと同様である。ブラウザ１２側から送られるクラスタアドレス9.100.1.1/cluster0、9.100.1.1/cluster1、9.100.1.1/cluster2は、内部的な３つのクラスタアドレス192.168.1.0、192.168.1.1、192.168.1.2に各々変換される。
【００２５】
図１に示す２つのＷｅｂアプリケーションサーバ２３は、実アドレスとして、例えば192.168.0.1および192.168.0.2が夫々割り当てられている。これらのＷｅｂアプリケーションサーバ２３は、実際の処理を行うアプリケーションである実アプリケーション３１、リダイレクトと呼ばれる処理を行い、一旦、応答をブラウザ１２側に返すためのアプリケーションであるリダイレクトアプリケーション３２を備えている。このリダイレクトアプリケーション３２は、セッションの最初の要求を受け付けるアプリケーションであるリダイレクトアプリケーションＡ(第１のリダイレクトアプリケーション)と、他サイト１１から戻ってくるときの要求を受け付けるアプリケーションであるリダイレクトアプリケーションＢ(第２のリダイレクトアプリケーション)が用意されている。リダイレクトアプリケーション３２によって応答が返されたブラウザ１２側では、応答中の記述に従って自動的に(ユーザに意識させずに)、改めてサーバ側の実アプリケーション３１宛に要求を送信する。
【００２６】
リダイレクトアプリケーションＡは、セッションにおける最初の要求のディスパッチ結果に基づくクラスタアドレスをリダイレクト応答の中にセットすることによりディスパッチ対象の片寄せを行う。同時にどちらのクラスタアドレスに片寄せされるのかを示す情報(クラスタ情報)をブラウザ１２側のクッキーにセットする。実アプリケーション３１は、片寄せされたクラスタアドレス経由で起動され、実アプリケーション３１用のセッションＩＤがブラウザ１２側のクッキーにセットされる。以後、このクラスタアドレス経由で要求が送られる限り、クッキー中のセッションＩＤがサーバ側に送信され、セッション情報の引き継ぎが可能になる。
【００２７】
他サイト１１に誘導され再び自サイト１０に戻ってくる場合には、他サイト１１は、返す応答ＨＴＭＬ中にリダイレクトアプリケーションＢを起動するためのリンクを記述しておく。リダイレクトアプリケーションＢはリダイレクトアプリケーションＡがクッキーにセットしたクラスタ情報をブラウザ１２から受信し、以前にどちらのクラスタアドレスに片寄せされたのかを知る。リダイレクト応答中にこのクラスタアドレスを記述することによって実アプリケーション３１をこのクラスタアドレス経由で起動することができる。
【００２８】
リダイレクトアプリケーションＡは、他サイト１１に移る前に片寄せされていたクラスタアドレスの情報を記録し、他サイト１１から戻るときには、リダイレクトアプリケーションＢが、この情報を利用してどちらに片寄せすべきかを決定し、クラスタアドレスを変更して実アプリケーション３１を起動する。これによって自サイト１０→他サイト１１→自サイト１０という遷移においてもセッション情報の引き継ぎが可能になる。
【００２９】
負荷分散の際に、クッキーを用いてクラスタアドレスの片寄せを行う手法は既に存在するが、本実施の形態では、
・リダイレクト処理によってアプリケーションを起動する際のクラスタアドレスを変更しセッション引継ぎを可能にする。
・セッションの最初の片寄せ時(実アプリケーション３１のセッションが開始される前)に他サイト１１から戻ってきたときに必要なクラスタ情報(どちらのクラスタアドレスに片寄せされたか)を記録しておく。
・負荷分散サーバ２２自体はＩＰレイヤでの処理を行う簡単な実装で実現できる。
という特徴を有している。
【００３０】
尚、クラスタアドレスは、例えば、192.168.0.1といった形式のＩＰアドレスを言う。また、クラスタ情報は、複数のクラスタアドレスにおける、その中のどの一つかを指定する情報である。例えば、３つのクラスタアドレス192.168.0.1、192.168.0.2、192.168.0.3のどれかを指定するためにクッキーに格納するクラスタ情報としては、例えば、値が“Ａ”か“Ｂ”か“Ｃ”をとる１文字等が使用される。
【００３１】
図２は、セッションの最初の要求に対するリダイレクトアプリケーション３２(リダイレクトアプリケーションＡ)の動作とそれに対するブラウザ１２の動作を説明するための図である。
まず、図中、▲１▼クラスタアドレス192.168.1.0への要求では、ユーザ認証後にブラウザ１２からＵＲＬ9.100.1.1/cluster0に送られたＨＴＴＰ(Hypertext Transfer Protocol：ＨＴＭＬ文書を送受信するためのプロトコル)要求は、認証サーバ２１によってクラスタアドレス192.168.1.0宛てに変換され、更に負荷分散サーバ２２によって実アドレス192.168.0.1または192.168.0.2に分配される。ＨＴＴＰ要求はリダイレクトアプリケーション３２(サーブレットまたはサーブレットから起動されるプログラム)の中のリダイレクトアプリケーションＡを起動するが、その引数として実アプリケーション３１(サーブレットまたはサーブレットから起動されるプログラム)を特定するための情報や実アプリケーション３１のロジックが必要とする引数の情報を含んでいる。
【００３２】
▲１▼のＨＴＴＰ要求は、その要求が実際にディスパッチされたＷｅｂアプリケーションサーバ２３上のリダイレクトアプリケーションＡによって処理され、▲２▼リダイレクト応答が作成される。リダイレクトアプリケーション３２によるリダイレクト処理は、ＨＴＴＰのLocationヘッダ、メタ(Meta)タグを記述したＨＴＭＬ応答、自動実行されるJavaScriptを含んだＨＴＭＬ応答などによって実現可能である。
【００３３】
このLocationヘッダによる応答では、リダイレクトアプリケーション３２が返す応答ヘッダ部にLocationヘッダという特別なヘッダをセットする。このヘッダの値として、リダイレクト先のＵＲＬを記述しておくと、応答を受信したブラウザ１２が自動的にリダイレクトを行う。メタ(Meta)タグによる応答では、リダイレクトアプリケーション３２が返す応答ボディ部(ＨＴＭＬ)にMETA HTTP-EQUIV="Refresh"を指定したメタタグを記述する。リダイレクト先ＵＲＬを例えば下記に示すようなＣＯＮＴＥＮＴ属性に記述しておく。
< META HTTP-EQUIV="Refresh"CONTENT="URL=http://xyz.com/">
また、JavaScriptによる応答では、リダイレクトアプリケーション３２が返す応答ボディ部(ＨＴＭＬ)に、ブラウザ画面表示後直ちに実行されるようなJavaScriptを記述する。JavaScriptの中にリダイレクト先ＵＲＬにジャンプするような記述を埋め込んでおく。このような方法によってリダイレクトを行うことが可能である。
【００３４】
図２に示す▲２▼の処理に際して、リダイレクトアプリケーションＡは、Ｗｅｂアプリケーションサーバ２３ごとに設定ファイルに記述してあるクラスタ情報(自身がどちらのクラスタアドレスで起動されるべきものか)を読み込み、リダイレクト応答中に実アプリケーション３１のクラスタアドレスを埋め込む。実アプリケーション３１のロジックに必要な引数もそのままリダイレクト応答の中に埋め込まれる。また、リダイレクトアプリケーションＡは、設定ファイルから読み込んだクラスタ情報をクッキーとしてリダイレクト応答のヘッダ内のSet-Cookieヘッダにセットする。リダイレクト応答が認証サーバ２１を経てブラウザ１２側に戻る過程でSet-Cookieに記述されているパス属性は変更され、"/cluster0"等の要求時クラスタを示す情報が追加される。パス属性は、ブラウザ１２側でのプライバシィ保護のために使われる情報であり、例えば"cluster0"のパス属性をもったクッキーは9.100.1.1/cluster0/...という形式の要求にのみ付加される。
【００３５】
図２に示す、▲３▼クラスタアドレス192.168.1.1または192.168.1.2への要求、では、リダイレクト応答を受信したブラウザ１２により、応答の内容に従って実アプリケーション３１へのＨＴＴＰ要求が自動的に送信される。リダイレクトアプリケーションＡによって片寄せが行われているので、要求の送信先は9.100.1.1/cluster1/...か9.100.1.1/cluster2/...となる。認証サーバ２１によって、これらの宛先アドレスはそれぞれクラスタアドレス192.168.1.1または192.168.1.2に変換された後、負荷分散サーバ２２によって実アドレス192.168.0.1または192.168.0.2にディスパッチされる。同時にブラウザ１２では、図中の▲２▼で送られてきたクッキーの内容(値や属性)がクライアント側のメモリまたはファイルに保存される。
【００３６】
図２に示す、▲４▼処理結果応答、に際し、実アプリケーション３１側に対しては何ら変更を行う必要はない。実アプリケーション３１は、従来どおり受信したＨＴＴＰ要求を処理して応答を返す。必要に応じてセッションオブジェクトを作成し、次のＨＴＴＰ要求処理に引き継ぐ情報をセットする。セッションオブジェクトを識別するためのセッションＩＤは、Ｗｅｂアプリケーションサーバ２３が作成し処理結果応答におけるヘッダのSet-Cookieヘッダにセットされる。このクッキーについても認証サーバ２１によりパス属性(実アプリケーション３１がどちらのクラスタアドレス経由で起動されたかによって"/cluster1"または"cluster2")が追加される。セッションＩＤのクッキーは、結果応答を受信したブラウザ１２側で保存される。以降、同一のクラスタアドレス(クッキーのパス属性が一致するアドレス)に対して送信された要求には、このセッションＩＤが付加されるので、サーバ側プログラムは引き続きセッション情報にアクセスすることができる。
【００３７】
図３は、他サイト１１に移動して戻ってくるときの要求に対するリダイレクトアプリケーション３２(リダイレクトアプリケーションＢ)の動作とそれに対するブラウザ１２の動作を説明するための図である。図２に示す▲４▼の動作の後、何回か自サイト１０とブラウザ１２との間で要求と応答とが繰り返される。その後、他サイト１１にＨＴＴＰ要求を送って他サイト１１との間で要求・応答を繰り返し、他サイト１１から受信したＨＴＭＬ中のリンクを用いて自サイト１０に送信した要求が図３に示す▲５▼に相当する。
【００３８】
この▲５▼クラスタアドレス192.168.1.0への要求、にて、他サイト１１から指定されたＵＲＬ9.100.1.1/cluster0に送られたＨＴＴＰ要求は、認証サーバ２１によってクラスタアドレス192.168.1.0宛てに変換され、更に、負荷分散サーバ２２によって実アドレス192.168.0.1または192.168.0.2に分配される。ＨＴＴＰ要求はリダイレクトアプリケーションＢを起動するが、その引数として、実アプリケーション３１を特定するための情報や実アプリケーション３１のロジックが必要とする引数の情報を含んでいる。
【００３９】
この要求は、パス部分が"/cluster0"であるため、図２に示す前述の▲４▼でクッキーにセットされたセッションＩＤの情報がブラウザ１２から送られることはない。つまり、リダイレクトアプリケーションＢから、以前に自サイト１０で作業していたときのセッション情報にアクセスすることはできない。しかながら、図２に示す前述▲２▼で送られたクラスタ情報のクッキーとはパス属性が一致するので、クラスタ情報は要求ヘッダにセットされてサーバ側に送られる。リダイレクトアプリケーションＢは、以前のセッション情報にアクセスできるようにするためにはどのようなクラスタアドレス経由で実アプリケーション３１を起動すればよいのか、を知ることができる。
【００４０】
▲５▼のＨＴＴＰ要求は、その要求が実際にディスパッチされたＷｅｂアプリケーションサーバ２３上のリダイレクトアプリケーションＢによって処理され、図３に示す、▲６▼リダイレクト応答、が作成される。リダイレクトアプリケーションＢは、受信した要求ヘッダから読み込んだクラスタ情報を用いて、リダイレクト応答中に実アプリケーション３１のクラスタアドレスを埋め込む。実アプリケーション３１のロジックに必要な引数もそのままリダイレクト応答の中に埋め込まれる。
【００４１】
リダイレクト応答を受信したブラウザ１２は、応答の内容に従って実アプリケーション３１へのＨＴＴＰ要求を自動的に送信する。要求の送信先クラスタアドレスは、前述の▲３▼の要求時と同様、▲７▼クラスタアドレス192.168.1.0または192.168.1.1への要求、となる。そのパス情報が、図２に示す▲４▼でセットされたクッキーのパス属性と一致することにより、セッションＩＤが要求ヘッダにセットされてサーバ側に送られる。図３中の、▲８▼処理結果応答、では、実アプリケーション３１は、受信したセッションＩＤをキーとしてセッションオブジェクトにアクセスし、業務ロジックを実行後、結果をブラウザ１２に返している。
【００４２】
次に、リダイレクトアプリケーション３２における処理について説明する。
図４(ａ),(ｂ)は、リダイレクトアプリケーション３２にて実行される処理を示したフローチャートであり、図４(ａ)はリダイレクトアプリケーションＡについての処理を、図４(ｂ)はリダイレクトアプリケーションＢについての処理を示している。
【００４３】
図４(ａ)に示すように、まず、ＨＴＴＰ要求を受信したリダイレクトアプリケーションＡは、付随するパラメータを取り出して保存する(ステップ１０１)。次に、リダイレクトアプリケーション３２が動作している各Ｗｅｂアプリケーションサーバ２３の設定ファイルから、リダイレクトすべきクラスタアドレスの情報を読み込む(ステップ１０２)。次に、リダイレクトアプリケーションＡは、ＨＴＴＰ要求で受信したパラメータおよびクラスタアドレスの情報を用いて実アプリケーション３１起動用のリダイレクト応答を作成する(ステップ１０３)。その後、Set-CookieヘッダをＨＴＴＰ応答のヘッダ部にセットして、クッキーへのクラスタ情報の埋め込みを行う(ステップ１０４)。そして、ＨＴＴＰ応答である用意したリダイレクト応答をブラウザ１２に送信して(ステップ１０５)、リダイレクトアプリケーションＡの処理が終了する。
【００４４】
リダイレクトアプリケーションＢの処理では、まず、ＨＴＴＰ要求を受信し、付随するパラメータを取り出して保存する(ステップ１１１)。次に、受信したＨＴＴＰ要求のヘッダ部にセットされているクッキーからクラスタアドレスの情報を取得する(ステップ１１２)。そして、ＨＴＴＰ要求で受信したパラメータおよびクラスタアドレスの情報を用いて実アプリケーション３１起動用のリダイレクト応答を作成する(ステップ１１３)。そして、ＨＴＴＰ応答である用意したリダイレクト応答をブラウザ１２に送信して(ステップ１１４)、リダイレクトアプリケーションＢの処理が終了する。
【００４５】
このように、本実施の形態では、サーバ側で、リダイレクト応答中に実アプリケーション３１のクラスタアドレスを埋め込むことで、応答を受信したブラウザ１２は、このクラスタアドレスに対して自動的に要求を送るリダイレクトを行うことができる。この「埋め込み」とは、具体的には、例えばJavaScriptやLocation等の特別なＨＴＴＰヘッダの中にクラスタアドレスを記述しておくことが挙げられる。
【００４６】
また、サーバ側で、クラスタ情報をクッキーとしてリダイレクト応答のヘッダ内のSet-Cookieヘッダにセットすることによって、応答を受信したブラウザ１２は、このクラスタ情報をクッキーとして、パーソナルコンピュータ(ＰＣ)内のメモリ/ディスクに格納する。以降、サーバに要求を送るときには、ブラウザ１２は格納していたクラスタ情報を要求データの一部として付加する。
【００４７】
図５は、リダイレクトアプリケーション３２にて、リダイレクトアプリケーションＡが動く場合とリダイレクトアプリケーションＢが動く場合との自動判定の処理を示したフローチャートである。まず、ＨＴＴＰ要求を受信し、付随するパラメータを取り出して保存する(ステップ１５１)。次に、受信したＨＴＴＰ要求のヘッダ部にクラスタ情報がクッキーとして埋め込まれているか否かをチェックし(ステップ１５２)、埋め込まれている場合には、ヘッダからのクラスタ情報を取得し、その情報をクラスタアドレスとして使用する(ステップ１５３)。クッキーとして埋め込まれていない場合には、サーバの設定ファイルからクラスタアドレスの情報を読み込む(ステップ１５４)。このようにして得られたクラスタアドレスの情報を用いて、実アプリケーション３１起動用のリダイレクト応答を作成する(ステップ１５５)。ここで、受信したＨＴＴＰ要求のヘッダ部にクラスタ情報を示すクッキーがセットされていたか否かを判断し(ステップ１５６)、セットされていない場合にはその情報をクッキーとして応答のヘッダ部にセットし(ステップ１５７)、ＨＴＴＰ応答をブラウザ１２に送信して(ステップ１５８)、処理が終了する。
【００４８】
このように、本実施の形態によれば、認証サーバ２１とＩＰレイヤベースの負荷分散サーバ２２とを組み合わせて使用するシステム構成において、自サイト１０→他サイト１１→自サイト１０という遷移にて、自サイト１０におけるセッションの引き継ぎが可能となる。リバースプロキシ型の認証サーバ２１を利用したシステム構成も、自サイト１０から他サイト１１に移動しまた自サイト１０に戻ってくるようなアプリケーションシナリオも、Ｗｅｂアプリケーションの高度化・複雑化に伴い、今後増加していくと予想される。また、企業のＷｅｂサイトにおいては、リライアビリティやスケーラビリティの観点から負荷分散サーバ２２の使用は必須である。従って、セッション引継ぎの問題は今後もしばしば発生すると考えられ、この問題を解決できる本実施の形態における価値は非常に高い。
【００４９】
尚、本実施の形態が適用されるＷｅｂサイト間(自サイト１０および他サイト１１)の連携シナリオについては、例えば、ユーザが保険会社のＷｅｂサイト(自サイト１０)から、自分の保険を担保にして貸付を受けている銀行サイト(他サイト１１)に移動して返済等の処理を行った後、再び保険会社のＷｅｂサイト(自サイト１０)に戻って作業を続ける、といったようなシナリオが考えられる。かかるシナリオに際して、一旦、銀行サイト(他サイト１１)に移行した後、保険会社のＷｅｂサイト(自サイト１０)に遷移した場合でも、保険契約作業等を継続させることができる。
【００５０】
また、例えば、ショッピングモールのサイト(自サイト１０)で買い物カゴに商品を入れた状態で、一旦、クレジット会社のサイト(他サイト１１)に移って引き落としの予定等を確認した後、ショッピングモールのサイト(自サイト１０)に戻って購入手続きを行う等のシナリオも考えられる。このとき、本実施の形態によれば、ショッピングモールのサイト(自サイト１０)が認証サーバ２１とＩＰレイヤベースの負荷分散サーバ２２とを組み合わせて使用するシステム構成にて、他サイト１１からショッピングモールのサイト(自サイト１０)に戻ってきたときのセッションの引き継ぎを可能とすることで、複数のサイトを遷移した後であっても円滑な作業継続が可能となる。
【００５１】
更には、旅行の予約をする際に、交通機関の予約をするサイト(自サイト１０)の手続き途中でホテルや宿関係のサイト(他サイト１１)に移動し、予約の確認を行ってから交通機関の予約をするサイト(自サイト１０)において交通機関の予約を最終的に決定する等のシナリオにも適用できる。このとき、本実施の形態によれば、交通機関の予約をするサイト(自サイト１０)にて、負荷分散機能をシステム構成とする場合に、旅行の予約に関連する他サイト１１に移行した後、自サイト１０に遷移した場合であってもセッションの引き継ぎが可能となり、交通機関の予約をするサイト(自サイト１０)にて予約作業を継続することができる。
【００５２】
【発明の効果】
以上説明したように、本発明によれば、他サイトが間に入ったときのセッション引継ぎの問題を解決することができる。
【図面の簡単な説明】
【図１】 本実施の形態が適用されるネットワークシステムの全体構成を示した図である。
【図２】 セッションの最初の要求に対するリダイレクトアプリケーション(リダイレクトアプリケーションＡ)の動作とそれに対するブラウザの動作を説明するための図である。
【図３】 他サイトに移動して戻ってくるときの要求に対するリダイレクトアプリケーション(リダイレクトアプリケーションＢ)の動作とそれに対するブラウザの動作を説明するための図である。
【図４】 (ａ),(ｂ)は、リダイレクトアプリケーションにて実行される処理を示したフローチャートである。
【図５】 リダイレクトアプリケーションにて、リダイレクトアプリケーションＡが動く場合とリダイレクトアプリケーションＢが動く場合との自動判定の処理を示したフローチャートである。
【図６】 セッション引継ぎの仕組みが機能しない場合が生じる可能性のある構成例を示した図である。
【図７】 各クラスタアドレスに対するディスパッチのルールを示した図である。
【図８】 内部的なクラスタアドレスとブラウザ側から見えるクラスタアドレスとの関係を示した図である。
【符号の説明】
１０…自サイト、１１…他サイト、１２…ブラウザ、１３…ネットワーク、２１…認証サーバ、２２…負荷分散サーバ、２３…Ｗｅｂアプリケーションサーバ、３１…実アプリケーション、３２…リダイレクトアプリケーション
Claims (20)
- 負荷分散サーバを用いている自サイトから一旦、他サイトにブラウザ側が誘導され、再び当該自サイトへ当該ブラウザ側が誘導される際に有効なセッション情報の引継ぎ方法であって、
前記負荷分散サーバによるディスパッチの結果に基づくリダイレクトすべきクラスタアドレスをセットしてリダイレクト応答を生成するステップと、
前記クラスタアドレスに片寄せされることを示すクラスタ情報を前記ブラウザ側の識別情報ファイルにセットするステップと、
前記リダイレクト応答を送信するステップと、
前記クラスタアドレスに対する要求を前記ブラウザ側から受信して実アプリケーションを実行するステップと
を含むセッション情報の引継ぎ方法。 - 更に、
前記他サイトから前記自サイトに誘導された前記ブラウザ側から前記識別情報ファイルを含む要求を受信するステップと、
受信した前記識別情報ファイルに含まれるクラスタ情報を取得するステップと、
取得された前記クラスタ情報に基づいて、先の自サイトに対する要求ではどのクラスタアドレスに片寄せされていたかを認識するステップと
を含む請求項１記載のセッション情報の引継ぎ方法。 - 更に、
認識された前記クラスタアドレスをリダイレクト応答に記述するステップと、前記クラスタアドレスが記述された前記リダイレクト応答をブラウザ側に送信するステップと
を含む請求項２記載のセッション情報の引継ぎ方法。 - ＨＴＴＰ要求を受信するステップと、
動作しているサーバの設定ファイルからリダイレクトすべきクラスタ情報を読み込むステップと、
前記ＨＴＴＰ要求で受信したパラメータおよび前記クラスタ情報を用いて実アプリケーション起動用のリダイレクト応答を作成するステップと、
前記クラスタ情報をクッキーとして前記リダイレクト応答にセットするステップと、
前記リダイレクト応答をブラウザ側に送信するステップと
を含むセッション情報の引継ぎ方法。 - 更に、
他サイトから誘導された前記ブラウザ側からの新たなＨＴＴＰ要求を受信するステップと、
前記新たなＨＴＴＰ要求にセットされている前記クラスタ情報を取得するステップと、
前記新たなＨＴＴＰ要求で受信したパラメータおよび取得された前記クラスタ情報を用いて新たなリダイレクト応答を作成するステップと、
前記新たなリダイレクト応答を前記ブラウザ側に送信するステップと
を含むことを特徴とする請求項４記載のセッション情報の引継ぎ方法。 - ＨＴＴＰ要求を受信するステップと、
受信した前記ＨＴＴＰ要求のクッキーにクラスタ情報が埋め込まれているか否かをチェックするステップと、
前記クラスタ情報が埋め込まれている場合には当該クラスタ情報を用いてリダイレクト応答を作成し、当該クラスタ情報が埋め込まれていない場合には設定ファイルから読み込んだ読み込みクラスタ情報を用いてリダイレクト応答を作成するステップと、
前記クラスタ情報または前記読み込みクラスタ情報をクッキーとして前記リダイレクト応答にセットするステップと、
前記リダイレクト応答を送信するステップと
を含むセッション情報の引継ぎ方法。 - 受信したＨＴＴＰ要求を処理し応答を返す実アプリケーションと、
分配されたＨＴＴＰ要求により前記実アプリケーションの実行に先立って起動され、最初の分配に基づくクラスタ情報に基づいてリダイレクト応答を生成すると共に、当該クラスタ情報をブラウザのクッキーにセットして当該リダイレクト応答を送信する第１のリダイレクトアプリケーションと、
前記実アプリケーションの実行に先立って起動され、前記第１のリダイレクトアプリケーションが前記クッキーにセットした前記クラスタ情報を前記ブラウザから受信し、当該クラスタ情報に基づいてリダイレクト応答を生成すると共に、生成された当該リダイレクト応答を送信する第２のリダイレクトアプリケーションと
を含むアプリケーションサーバ。 - 前記実アプリケーションは、セッションオブジェクトを作成し、次のＨＴＴＰ要求処理に引き継ぐ情報をセットすることを特徴とする請求項７記載のアプリケーションサーバ。
- ディスパッチされた要求に対して実際のアプリケーション処理を実行する実行手段と、
前記実行手段による実行に先立って、セッションの最初の要求を受け付けてリダイレクト処理を行い、リダイレクト応答をブラウザ側に返す第１のリダイレクト処理手段と、
前記ブラウザ側が他サイトから戻ってくるときの要求に対して、前記実行手段による実行に先立ってリダイレクト処理を行い、リダイレクト応答を当該ブラウザ側に返す第２のリダイレクト処理手段と
を含むアプリケーションサーバ。 - 前記第１のリダイレクト処理手段は、セッションの最初の要求に対するディスパッチの結果のクラスタアドレスを前記リダイレクト応答の中にセットして片寄せを行うと共に、どのクラスタアドレスに片寄せされるのかを示すクラスタ情報を前記ブラウザ側のクッキーにセットすることを特徴とする請求項９記載のアプリケーションサーバ。
- 前記第２のリダイレクト処理手段は、前記第１のリダイレクト処理手段によりセットされた前記クラスタ情報を前記ブラウザ側から受信してどのクラスタアドレスに片寄せされたかを認識すると共に、前記リダイレクト応答に当該クラスタアドレスを記述することによって前記実行手段を当該クラスタアドレス経由で起動することを特徴とする請求項９記載のアプリケーションサーバ。
- ディスパッチされた要求に対して実アプリケーションを実行する実行手段と、
前記実行手段による実行に先立って、サーバ側にてリダイレクト応答を実行することにより、前記実アプリケーションを起動する際のクラスタアドレスを変更してセッション引継ぎを可能にするリダイレクト処理手段と
を含むアプリケーションサーバ。 - 更に、前記実アプリケーションのセッションが開始される前であるセッションの最初の片寄せ時に、他サイトから戻ってきたときに必要なクラスタ情報を記録する記録手段を含むことを特徴とする請求項１２記載のアプリケーションサーバ。
- 前記クラスタ情報は、セッションの最初の片寄せ時にどのクラスタアドレスに片寄せされたかを示す情報であることを特徴とする請求項１３記載のアプリケーションサーバ。
- ブラウザからの要求に対して認証を行う認証サーバと、
前記認証サーバを経た前記要求をディスパッチする負荷分散サーバと、
前記負荷分散サーバによりディスパッチされた要求を処理するために設けられる複数のアプリケーションサーバとを含むＷｅｂサイトであって、
前記アプリケーションサーバは、
実際にアプリケーションを実行する実アプリケーションと、
ディスパッチされた最初の要求を受け付ける第１のリダイレクトアプリケーションと、
前記ブラウザが他サイトから戻ってくるときの要求を受け付ける第２のリダイレクトアプリケーションとを含み、
前記第１のリダイレクトアプリケーションおよび前記第２のリダイレクトアプリケーションは、前記実アプリケーションを実行する前にリダイレクト処理を行い、前記要求に対するリダイレクト応答を前記ブラウザに返すことを特徴とするＷｅｂサイト。 - 前記認証サーバは、前記リダイレクト応答を前記ブラウザに戻す過程で、当該リダイレクト応答にセットされたパス属性に対して前記要求時のクラスタアドレスを示す情報を追加することを特徴とする請求項１５記載のＷｅｂサイト。
- アプリケーションサーバとして機能するコンピュータに、
ディスパッチされた要求に対して実アプリケーションを実行する機能と、
前記実アプリケーションによる実行に先立って、リダイレクト応答を実行することにより当該実アプリケーションを起動する際のクラスタアドレスを変更してセッション引継ぎを可能にする機能と
を実現させるためのプログラム。 - 更に、前記実アプリケーションのセッションが開始される前であるセッションの最初の片寄せ時に、他サイトから戻ってきたときに必要なクラスタ情報を記録する機能を前記コンピュータに実現させるための請求項１７記載のプログラム。
- アプリケーションサーバとして機能するコンピュータに、負荷分散サーバによるディスパッチの結果に基づくリダイレクトすべきクラスタアドレスをセットしてリダイレクト応答を生成する機能と、
前記クラスタアドレスに片寄せされることを示すクラスタ情報を前記ブラウザ側の識別情報ファイルにセットする機能と、
前記リダイレクト応答を送信する機能と、
前記クラスタ情報がセットされた前記識別情報ファイルを有する要求を前記ブラウザ側から受信して実アプリケーションを実行する機能と
を実現させるためのプログラム。 - 更に、一旦、他サイトに移動した後に誘導された前記ブラウザ側から前記識別情報ファイルを含む要求を受信する機能と、
受信した前記識別情報ファイルに含まれるクラスタ情報を取得する機能と、
取得された前記クラスタ情報を用いてリダイレクト応答を生成する機能とを前記コンピュータに実現させるための請求項１９記載のプログラム。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002070489A JP3780507B2 (ja) | 2002-03-14 | 2002-03-14 | セッション情報の引継ぎ方法、アプリケーションサーバ、Ｗｅｂサイト、およびプログラム |
| US10/389,507 US7953790B2 (en) | 2002-03-14 | 2003-03-14 | Session information inheriting method and apparatus |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002070489A JP3780507B2 (ja) | 2002-03-14 | 2002-03-14 | セッション情報の引継ぎ方法、アプリケーションサーバ、Ｗｅｂサイト、およびプログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003271477A JP2003271477A (ja) | 2003-09-26 |
| JP3780507B2 true JP3780507B2 (ja) | 2006-05-31 |
Family
ID=28449063
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002070489A Expired - Fee Related JP3780507B2 (ja) | 2002-03-14 | 2002-03-14 | セッション情報の引継ぎ方法、アプリケーションサーバ、Ｗｅｂサイト、およびプログラム |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US7953790B2 (ja) |
| JP (1) | JP3780507B2 (ja) |
Families Citing this family (41)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE60121176T2 (de) * | 2000-08-04 | 2007-06-06 | Avaya Technology Corp. | Verfahren und System zur anforderungsorientierten Wiedererkennung von verbindungsorientierten Transaktionen |
| US7308499B2 (en) * | 2003-04-30 | 2007-12-11 | Avaya Technology Corp. | Dynamic load balancing for enterprise IP traffic |
| US8484348B2 (en) * | 2004-03-05 | 2013-07-09 | Rockstar Consortium Us Lp | Method and apparatus for facilitating fulfillment of web-service requests on a communication network |
| FR2873882A1 (fr) * | 2004-07-29 | 2006-02-03 | France Telecom | Procede et dispositif de distinction de requetes http utilisateur |
| KR100623482B1 (ko) * | 2004-12-14 | 2006-09-14 | 한국전자통신연구원 | 세션 이동 방법 |
| WO2006072994A1 (ja) * | 2005-01-07 | 2006-07-13 | Systemk Corporation | ネットワークカメラへのログイン認証システム |
| JP4570986B2 (ja) * | 2005-02-25 | 2010-10-27 | 京セラ株式会社 | 基地局装置、基地局装置の制御方法および通信制御プログラム |
| US8909782B2 (en) | 2005-07-13 | 2014-12-09 | International Business Machines Corporation | Method and system for dynamically rebalancing client sessions within a cluster of servers connected to a network |
| JP5100004B2 (ja) * | 2005-12-14 | 2012-12-19 | キヤノン株式会社 | 情報処理システム、サーバ装置、情報処理装置及びそれらの制御方法 |
| EP1979839B1 (en) * | 2006-01-31 | 2014-01-08 | Speed-trap.com Ltd. | Website monitoring and cookie setting |
| GB0601939D0 (en) * | 2006-01-31 | 2006-03-15 | Speed Trap Com Ltd | Website monitoring and cookie setting |
| US8533808B2 (en) * | 2006-02-02 | 2013-09-10 | Check Point Software Technologies Ltd. | Network security smart load balancing using a multiple processor device |
| AU2008232558B9 (en) | 2007-03-30 | 2013-08-01 | Google Llc | Determining advertising conversion |
| US10304065B2 (en) | 2007-03-30 | 2019-05-28 | Google Llc | Determining advertising conversion |
| JP5052955B2 (ja) * | 2007-05-09 | 2012-10-17 | 株式会社日立製作所 | アプリケーションの高可用運用方法、オンラインバージョン変更方法及び計算機システム |
| JP4956276B2 (ja) * | 2007-05-21 | 2012-06-20 | 日本電信電話株式会社 | サーブレット起動プログラムおよびホームゲートウェイ装置 |
| WO2010046985A1 (ja) * | 2008-10-23 | 2010-04-29 | 富士通株式会社 | 認証システム、認証プログラム、認証サーバおよび副認証サーバ |
| US8918853B2 (en) | 2011-06-29 | 2014-12-23 | Sharp Laboratories Of America, Inc. | Method and system for automatic recovery from lost security token on embedded device |
| JP5850657B2 (ja) * | 2011-07-01 | 2016-02-03 | キヤノン株式会社 | 情報処理装置とその制御方法、プログラム、並びに情報処理システム |
| US10430894B2 (en) | 2013-03-21 | 2019-10-01 | Khoros, Llc | Gamification for online social communities |
| JP2016149107A (ja) * | 2015-02-10 | 2016-08-18 | 株式会社アドウェイズ | サ−バ |
| US11567742B2 (en) * | 2016-12-29 | 2023-01-31 | Atlassian Pty Ltd. | Method, apparatus, and computer program product for generating updated network application interfaces |
| US10902462B2 (en) | 2017-04-28 | 2021-01-26 | Khoros, Llc | System and method of providing a platform for managing data content campaign on social networks |
| US11553046B1 (en) * | 2017-09-27 | 2023-01-10 | Amazon Technologies, Inc. | Seamless scaling via proxy replay of session state |
| US11570128B2 (en) | 2017-10-12 | 2023-01-31 | Spredfast, Inc. | Optimizing effectiveness of content in electronic messages among a system of networked computing device |
| US10999278B2 (en) | 2018-10-11 | 2021-05-04 | Spredfast, Inc. | Proxied multi-factor authentication using credential and authentication management in scalable data networks |
| US11470161B2 (en) * | 2018-10-11 | 2022-10-11 | Spredfast, Inc. | Native activity tracking using credential and authentication management in scalable data networks |
| US10346449B2 (en) | 2017-10-12 | 2019-07-09 | Spredfast, Inc. | Predicting performance of content and electronic messages among a system of networked computing devices |
| US11050704B2 (en) | 2017-10-12 | 2021-06-29 | Spredfast, Inc. | Computerized tools to enhance speed and propagation of content in electronic messages among a system of networked computing devices |
| US10785222B2 (en) | 2018-10-11 | 2020-09-22 | Spredfast, Inc. | Credential and authentication management in scalable data networks |
| US10601937B2 (en) | 2017-11-22 | 2020-03-24 | Spredfast, Inc. | Responsive action prediction based on electronic messages among a system of networked computing devices |
| US11061900B2 (en) | 2018-01-22 | 2021-07-13 | Spredfast, Inc. | Temporal optimization of data operations using distributed search and server management |
| US10594773B2 (en) | 2018-01-22 | 2020-03-17 | Spredfast, Inc. | Temporal optimization of data operations using distributed search and server management |
| US10855657B2 (en) | 2018-10-11 | 2020-12-01 | Spredfast, Inc. | Multiplexed data exchange portal interface in scalable data networks |
| US10931540B2 (en) | 2019-05-15 | 2021-02-23 | Khoros, Llc | Continuous data sensing of functional states of networked computing devices to determine efficiency metrics for servicing electronic messages asynchronously |
| US11438289B2 (en) | 2020-09-18 | 2022-09-06 | Khoros, Llc | Gesture-based community moderation |
| US11128589B1 (en) | 2020-09-18 | 2021-09-21 | Khoros, Llc | Gesture-based community moderation |
| US11627100B1 (en) | 2021-10-27 | 2023-04-11 | Khoros, Llc | Automated response engine implementing a universal data space based on communication interactions via an omnichannel electronic data channel |
| US11438282B2 (en) | 2020-11-06 | 2022-09-06 | Khoros, Llc | Synchronicity of electronic messages via a transferred secure messaging channel among a system of various networked computing devices |
| US11924375B2 (en) | 2021-10-27 | 2024-03-05 | Khoros, Llc | Automated response engine and flow configured to exchange responsive communication data via an omnichannel electronic communication channel independent of data source |
| US11714629B2 (en) | 2020-11-19 | 2023-08-01 | Khoros, Llc | Software dependency management |
Family Cites Families (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5991878A (en) * | 1997-09-08 | 1999-11-23 | Fmr Corp. | Controlling access to information |
| US6098093A (en) * | 1998-03-19 | 2000-08-01 | International Business Machines Corp. | Maintaining sessions in a clustered server environment |
| US6369840B1 (en) * | 1999-03-10 | 2002-04-09 | America Online, Inc. | Multi-layered online calendaring and purchasing |
| US6801949B1 (en) * | 1999-04-12 | 2004-10-05 | Rainfinity, Inc. | Distributed server cluster with graphical user interface |
| US7082532B1 (en) * | 1999-12-30 | 2006-07-25 | Intel Corporation | Method and system for providing distributed web server authentication |
| US6799214B1 (en) * | 2000-03-03 | 2004-09-28 | Nec Corporation | System and method for efficient content delivery using redirection pages received from the content provider original site and the mirror sites |
| US7340532B2 (en) * | 2000-03-10 | 2008-03-04 | Akamai Technologies, Inc. | Load balancing array packet routing system |
| US7099915B1 (en) * | 2000-06-30 | 2006-08-29 | Cisco Technology, Inc. | Server load balancing method and system |
| DE60121176T2 (de) * | 2000-08-04 | 2007-06-06 | Avaya Technology Corp. | Verfahren und System zur anforderungsorientierten Wiedererkennung von verbindungsorientierten Transaktionen |
| US7421505B2 (en) * | 2000-12-21 | 2008-09-02 | Noatak Software Llc | Method and system for executing protocol stack instructions to form a packet for causing a computing device to perform an operation |
| US20020194262A1 (en) * | 2001-04-27 | 2002-12-19 | Jorgenson D. Scott | System and method for controlling the interruption and resumption of access to WWW pages requiring certain prerequisites |
| US7702791B2 (en) * | 2001-07-16 | 2010-04-20 | Bea Systems, Inc. | Hardware load-balancing apparatus for session replication |
| US6944785B2 (en) * | 2001-07-23 | 2005-09-13 | Network Appliance, Inc. | High-availability cluster virtual server system |
-
2002
- 2002-03-14 JP JP2002070489A patent/JP3780507B2/ja not_active Expired - Fee Related
-
2003
- 2003-03-14 US US10/389,507 patent/US7953790B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US20030187871A1 (en) | 2003-10-02 |
| JP2003271477A (ja) | 2003-09-26 |
| US7953790B2 (en) | 2011-05-31 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3780507B2 (ja) | セッション情報の引継ぎ方法、アプリケーションサーバ、Ｗｅｂサイト、およびプログラム | |
| US6587880B1 (en) | Session management system and management method | |
| KR100528653B1 (ko) | 공용 및 사설 데이터를 통합하기 위한 시스템 및 방법 | |
| US6633915B1 (en) | Personal information management apparatus and customizing apparatus | |
| US6209038B1 (en) | Technique for aggregate transaction scope across multiple independent web requests | |
| US7657595B2 (en) | Method and system for generating auxiliary-server cache identifiers | |
| AU756650B2 (en) | An internet interface system | |
| EP3229188A1 (en) | Service request broking system | |
| JP2004029939A (ja) | 通信プロキシ装置、および、通信プロキシ装置を用いたサービス提供方法 | |
| US20080196096A1 (en) | Methods for Extending a Security Token Based Identity System | |
| US20060129816A1 (en) | Method and system for secure binding register name identifier profile | |
| US20070022199A1 (en) | Method, Apparatus, and Program Product For Providing Web Service | |
| US20070033658A1 (en) | Connected support entitlement system method of operation | |
| CN100421376C (zh) | 用于服务资源定位符的请求的方法 | |
| CN101326491A (zh) | 用于在应用程序的预定数量的执行方法之间选择的方法 | |
| JP2001515669A (ja) | 分散コンピュータシステムにおける情報へのアクセス権を付与するシステムおよび方法 | |
| CA2293566A1 (en) | Apparatus and method for identifying clients accessing network sites | |
| CN102984159A (zh) | 基于终端访问行为的安全接入逻辑控制方法及平台服务器 | |
| CN103197936A (zh) | 用于在应用程序的预定数量的执行方法之间选择的方法 | |
| JP5347429B2 (ja) | ユニフォームリソースロケータ書換方法及び装置 | |
| EP1360816B1 (en) | Network conduit for providing access to data services | |
| JP2003242117A (ja) | アクセス管理方法及びシステム | |
| US20030065789A1 (en) | Seamless and authenticated transfer of a user from an e-business website to an affiliated e-business website | |
| JP3437680B2 (ja) | 対話管理型情報提供方法及び装置 | |
| Weiss | Patterns for web applications |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| 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: 20060207 |
|
| RD14 | Notification of resignation of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7434 Effective date: 20060209 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060224 |
|
| 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: 20100317 Year of fee payment: 4 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100317 Year of fee payment: 4 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110317 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110317 Year of fee payment: 5 |
|
| LAPS | Cancellation because of no payment of annual fees |