Ｗｅｂシステムおよびリクエスト処理方法
【課題】アプリケーションサーバによらず、ＡＰＩサーバを再利用することができるＷｅｂシステムを提供する。
【解決手段】Ｗｅｂシステムは、アプリケーションサーバ２とＡＰＩサーバ３とから構成されている。アプリケーションサーバ２は、クライアント１から受信したリクエストの認証処理またはセッション処理を行うとともに、リクエストがＡＰＩサーバ３へのアクセスを要求している場合には認証処理結果またはセッション処理結果をリクエストに付随させてＡＰＩサーバ３に送信する認証・セッション処理部２２を有している。ＡＰＩサーバ３は、アプリケーションサーバ２から受信したリクエストに付随されている認証処理結果またはセッション処理結果に基づいて、当該受信したリクエストを処理するリクエスト処理部３１を有している。
【解決手段】Ｗｅｂシステムは、アプリケーションサーバ２とＡＰＩサーバ３とから構成されている。アプリケーションサーバ２は、クライアント１から受信したリクエストの認証処理またはセッション処理を行うとともに、リクエストがＡＰＩサーバ３へのアクセスを要求している場合には認証処理結果またはセッション処理結果をリクエストに付随させてＡＰＩサーバ３に送信する認証・セッション処理部２２を有している。ＡＰＩサーバ３は、アプリケーションサーバ２から受信したリクエストに付随されている認証処理結果またはセッション処理結果に基づいて、当該受信したリクエストを処理するリクエスト処理部３１を有している。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、Ｗｅｂシステムおよびリクエスト処理方法に関する。
【背景技術】
【０００２】
一般に、アプリケーションサーバとＡＰＩサーバとにより構成されるＷｅｂシステムでは、両サーバに共通した認証・セッション機能が実装されている。ところで、アプリケーションサーバのロジックはサービスにより異なり、適したプログラム言語により実装される。たとえば、Ｗｅｂシステムの開発には、Ｓｔｒｕｔｓ、Ｒｕｂｙ ｏｎ Ｒａｉｌｓ、またはＣａｔａｌｙｓｔのような様々なフレームワークが用いられている（非特許文献１参照）。
【非特許文献１】Dave Thomas, David Heinemeier Hansson, "第2版 Rails によるアジャイル Webアプリケーション開発", 21.2節, オーム社, 2006年 2月
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら、認証・セッション機能に用いられるデータ構造はプログラム言語やフレームワークによって異なり、また複雑である。そのために、ＡＰＩサーバを再利用することは難しいという問題があった。
【０００４】
たとえば、上述したＳｔｒｕｔｓ、Ｒｕｂｙ ｏｎ Ｒａｉｌｓ、またはＣａｔａｌｙｓｔのようなフレームワークは認証・セッション機能を提供するが、用いられるデータ構造はフレームワークによって異なり、複雑である。また、たとえば、Ｒｕｂｙ ｏｎ Ｒａｉｌｓでは、セッション情報のデータ構造として、シリアライズされたＲｕｂｙデータオブジェクトを用いるために、他のプログラム言語から利用することは難しい。このような理由により、ＡＰＩサーバを再利用することは難しいという問題があった。
【０００５】
また、ＡＰＩサーバに要求される機能はサービスによらず似ているため、再利用されることが望ましいという要望がある。
【０００６】
本発明は、このような事情に鑑みてなされたもので、その目的は、アプリケーションサーバによらず、ＡＰＩサーバを再利用することができるＷｅｂシステムおよびリクエスト処理方法を提供することにある。
【課題を解決するための手段】
【０００７】
この発明は上述した課題を解決するためになされたもので、請求項１に記載の発明は、アプリケーションサーバとＡＰＩサーバとから構成されるＷｅｂシステムであって、前記アプリケーションサーバが、クライアントから受信したリクエストの認証処理またはセッション処理を行うとともに、前記リクエストが前記ＡＰＩサーバへのアクセスを要求している場合には前記認証処理結果または前記セッション処理結果を前記リクエストに付随させて前記ＡＰＩサーバに送信する認証・セッション処理部を有し、前記ＡＰＩサーバが、前記アプリケーションサーバから受信したリクエストに付随されている認証処理結果またはセッション処理結果に基づいて、当該受信したリクエストを処理するリクエスト処理部を有することを特徴とするＷｅｂシステムである。
【０００８】
請求項２に記載の発明は、前記認証・セッション処理部が、前記認証処理結果または前記セッション処理結果を前記リクエストに付随させて前記ＡＰＩサーバに送信する場合に、前記認証処理結果または前記セッション処理結果を前記リクエストに付随させて前記ＡＰＩサーバに標準化された通信方式で送信することを特徴とする請求項１に記載のＷｅｂシステムである。
【０００９】
請求項３に記載の発明は、前記Ｗｅｂシステムが、複数の前記ＡＰＩサーバ、を有しており、前記認証・セッション処理部が、前記認証処理結果または前記セッション処理結果を前記リクエストに付随させて前記ＡＰＩサーバに送信する場合に、前記複数のＡＰＩサーバの中から当該リクエストに対応するＡＰＩサーバに、前記認証処理結果または前記セッション処理結果を前記リクエストに付随させて送信することを特徴とする請求項１または請求項２に記載のＷｅｂシステムである。
【００１０】
請求項４に記載の発明は、アプリケーションサーバとＡＰＩサーバとから構成されるＷｅｂシステムにおいて用いられるリクエスト処理方法であって、前記アプリケーションサーバが、クライアントから受信したリクエストの認証処理またはセッション処理を行うとともに、前記リクエストが前記ＡＰＩサーバへのアクセスを要求している場合には前記認証処理結果または前記セッション処理結果を前記リクエストに付随させて前記ＡＰＩサーバに送信する認証・セッション処理手順を有し、前記ＡＰＩサーバが、前記アプリケーションサーバから受信したリクエストに付随されている認証処理結果またはセッション処理結果に基づいて、当該受信したリクエストを処理するリクエスト処理手順を有することを特徴とするリクエスト処理方法である。
【発明の効果】
【００１１】
この発明によれば、アプリケーションサーバの認証・セッション処理部が、クライアントから受信したリクエストの認証処理またはセッション処理を行うとともに、リクエストがＡＰＩサーバへのアクセスを要求している場合には認証処理結果またはセッション処理結果をリクエストに付随させてＡＰＩサーバに送信する。たとえば、認証・セッション処理部は、認証処理結果またはセッション処理結果をリクエストに付随させてＡＰＩサーバに送信する場合に、認証処理結果またはセッション処理結果をリクエストに付随させてＡＰＩサーバに標準化された通信方式で送信する。
【００１２】
これにより、ＡＰＩサーバのリクエスト処理部は、標準化された通信方式で認証処理結果またはセッション処理結果を受信することができる。よって、このＡＰＩサーバのリクエスト処理部は、アプリケーションサーバから受信したリクエストに付随されている認証処理結果またはセッション処理結果に基づいて、当該受信したリクエストを処理することができる。
【００１３】
従って、アプリケーションサーバとＡＰＩサーバとを有するＷｅｂシステムは、アプリケーションサーバによらずＡＰＩサーバを再利用することができるという効果を奏する。
【発明を実施するための最良の形態】
【００１４】
以下、図面を参照して、本発明の実施の形態について説明する。図１は、この発明の一実施形態によるＷｅｂシステムの構成を示す概略ブロック図である。
このＷｅｂシステムは、クライアント１と、アプリケーションサーバ２と、ＡＰＩ（Application Programming Interface）サーバ３とを有している。このＷｅｂシステムは、アプリケーションサーバ２およびＡＰＩサーバ３から構成されるサーバと、クライアント１とのクライアントサーバシステムとして構成されている。
【００１５】
このアプリケーションサーバ２とクライアント１とは、通信回線を介してＨＴＴＰ（HyperText Transfer Protocol）によって通信を行う。また、アプリケーションサーバ２とＡＰＩサーバ３とは、通信回線を介してＨＴＴＰによって通信を行う。この通信回線は、たとえばインターネット網である。すなわち、アプリケーションサーバ２とクライアント１との間の通信方式、および、アプリケーションサーバ２とＡＰＩサーバ３との間の通信方式は、標準化された通信方式である。
【００１６】
次に、アプリケーションサーバ２とＡＰＩサーバ３との一例としての構成について説明する。ここでは、アプリケーションサーバ２とＡＰＩサーバ３との構成のうち、本実施形態に関する構成のみについて説明する。
【００１７】
アプリケーションサーバ２は、ユーザ情報記憶部２１と、認証・セッション処理部２２と、アプリケーション処理部２３とを有している。ユーザ情報記憶部２１には、たとえばクライアント１のユーザ情報と当該クライアントのパスワード情報（または、パスワードのハッシュ情報）とが関連付けて予め記憶されている。
【００１８】
認証・セッション処理部２２は、クライアント１から受信したリクエストの認証処理またはセッション処理を行うとともに、リクエストがＡＰＩサーバ３へのアクセスを要求している場合には認証処理結果またはセッション処理結果をリクエストに付随させてＡＰＩサーバ３に送信する。また、認証・セッション処理部２２は、クライアント１から受信したリクエストの認証処理またはセッション処理を行うとともに、リクエストがＡＰＩサーバ３へのアクセスを要求していない場合にはリクエストをアプリケーション処理部２３に送信する。
【００１９】
たとえば、認証・セッション処理部２２は、クライアント１からリクエストとともにユーザ情報とパスワード情報とを受信する。そして、認証・セッション処理部２２は、クライアント１から受信したユーザ情報と関連付けられているパスワード情報をユーザ情報記憶部２１から読み出し、当該読み出したパスワード情報とクライアント１から受信したパスワード情報とが一致するか否かを判定することにより、リクエストを認証する。この判定した結果が、認証処理結果に相当する。
【００２０】
なお、この認証処理は、ＯｐｅｎＩＤなどの技術によって、アプリケーションサーバ２の外部で行われてもよい。このＯｐｅｎＩＤとは、サイトを越えて使用できる「認証システム」であり、個人が登録した情報を公開することで個人の同一性を保証する認証システムである。
【００２１】
また、認証・セッション処理部２２は、クライアント１を一旦認証した後は、クライアント１と接続している期間においては、クライアント１とのセッション情報によりクライアント１の認証を維持してもよい。このセッションにより維持される認証の結果が、セッション処理結果に相当する。
【００２２】
アプリケーション処理部２３は、受信したリクエストを処理し、処理結果をクライアント１に返信する。
【００２３】
ＡＰＩサーバ３は、リクエスト処理部３１を有している。このリクエスト処理部３１は、アプリケーションサーバ２から受信したリクエストに付随されている認証処理結果またはセッション処理結果に基づいて、当該受信したリクエストを処理する。そして、リクエスト処理部３１は、処理結果をクライアント１にアプリケーションサーバ２を介して返信する。
【００２４】
次に、図２を用いて、図１を用いて説明したＷｅｂシステムの動作について説明する。
まず、クライアント１からのリクエストがサーバに到着すると（ステップＳ１０１）、サーバが有するアプリケーションサーバ２の認証・セッション処理部２２へとリクエストは届けられる。次に、認証・セッション処理部２２は、ユーザ情報記憶部２１に記憶されているユーザ情報を参照してリクエストの認証処理を実行する（ステップＳ１０２）。
【００２５】
次に、認証・セッション処理部２２は認証に成功したか否かを判定し（ステップＳ１０３）、このステップＳ１０３で認証に失敗した場合には、認証・セッション処理部２２は、エラーコードとしてクライアントエラーではなくサーバーエラーをクライアント１に送信し（ステップＳ１０４）、以降の処理を終了する。
【００２６】
一方、ステップＳ１０３で認証に成功した場合には、認証・セッション処理部２２は、リクエストの内容によって後続の処理を決定する。たとえば認証・セッション処理部２２は、まずリクエストの内容がＡＰＩサーバ３に対するリクエストであるか否かを判定する（ステップＳ１０５）。このステップＳ１０５において、リクエストの内容がＡＰＩサーバ３に対するリクエストである場合には、認証・セッション処理部２２は、リクエストをＡＰＩサーバ３に転送し（ステップＳ１０６）、そうでない場合にはリクエストをアプリケーション処理部２３に転送する（ステップＳ１０９）。
【００２７】
このステップＳ１０９に続いて、アプリケーション処理部２３は、サービスに応じた処理を実行し（ステップＳ１１０）、その処理結果をクライアント１に返信する（ステップＳ１１１）。
【００２８】
なお、認証・セッション処理部２２は、上述したステップＳ１０６でリクエストをＡＰＩサーバ３に転送する場合に、ＡＰＩサーバ３に転送するリクエストに、ステップＳ１０２で得た認証結果を付随して転送する。一例としては、図３に示すように、ＨＴＴＰヘッダ（Ｘ−Ｕｓｅｒｎａｍｅ）に認証されたユーザ名を示す情報を追加する。なお、この認証結果は、ＨＴＴＰヘッダではなく、ＵＲＬの一部として追加してもよい。たとえば、ＵＲＬの末尾に、「？ｘ−ｕｓｅｒｎａｍｅ＝ｓｕｚｕｋｉ」のようにして追加してもよい。
【００２９】
図２の説明に戻り、上述したステップＳ１０６に続いて、ＡＰＩサーバ３に到着したリクエストは、ＡＰＩサーバ３のリクエスト処理部３１へと届けられる。リクエスト処理部３１は、リクエストに付随された認証結果に基づいて、リクエストの処理を実行する（ステップＳ１０７）。たとえば、リクエスト処理部３１は、リクエストに付随された認証結果に基づいて、リクエストに含まれているデータに対するアクセス制御を実行する。
【００３０】
次に、リクエスト処理部３１は、処理結果をクライアント１にアプリケーションサーバ２を介して返信する（ステップＳ１０８）。たとえば、リクエスト処理部３１は、処理結果をアプリケーションサーバ２へと返信する。次に、アプリケーションサーバ２は、ＡＰＩサーバ３からの処理結果をそのままクライアント１に返信する。この処理は、たとえば、アプリケーションサーバ２が処理結果転送部を有しており、この処理結果転送部が、ＡＰＩサーバ３から受信した処理結果をクライアント１に転送することにより実行される。
【００３１】
なお、ここではステップＳ１０６において、認証・セッション処理部２２が、ＡＰＩサーバ３に転送するリクエストに、ステップＳ１０２で得た認証結果を付随して転送する場合について説明したが、ＡＰＩサーバ３に転送するリクエストにセッション処理結果を付随して転送してもよい。
【００３２】
図２を用いて説明したＷｅｂシステムの動作において、アプリケーションサーバ２とＡＰＩサーバ３との間の通信方式は、標準化されたＨＴＴＰであり、特定のプログラム言語やフレームワークに依存しない。そのため、ＡＰＩサーバ３は、アプリケーションサーバ２に依存せずに、認証処理結果またはセッション処理結果をアプリケーションサーバ２の認証・セッション処理部２２から受信し、この受信した認証処理結果またはセッション処理結果に基づいてリクエストを処理することができる。この結果、アプリケーションサーバ２に依存せず、ＡＰＩサーバ３を再利用することが可能となり、システム開発における経済性が向上する。
【００３３】
また、クライアント１はリクエストをアプリケーションサーバ２に送信するのみで、リクエストの結果をアプリケーションサーバ２から受信することができるという効果を奏する。
【００３４】
また、以上説明したＷｅｂシステムによれば、ＡＰＩサーバ３は、複数のアプリケーションサーバ２で実行する認証処理およびセッション管理の結果に基づいて所要の処理を行うので、ＡＰＩサーバ３の機能を複数のアプリケーションサーバ２で再利用できるという効果を奏する。たとえば、図１を用いたＷｅｂシステムにおいては、Ｗｅｂシステムが１つのアプリケーションサーバ２を有している場合について説明したが、Ｗｅｂシステムは複数のアプリケーションサーバ２を有していてもよい。そして、この複数のアプリケーションサーバ２が、ＡＰＩサーバ３の機能を共有して再利用してもよい。
【００３５】
なお、図１を用いたＷｅｂシステムにおいては、Ｗｅｂシステムが１つのＡＰＩサーバ３を有している場合について説明したが、Ｗｅｂシステムは複数のＡＰＩサーバ３を有してもよい。そして、アプリケーションサーバ２の認証・セッション処理部２２は、認証処理結果またはセッション処理結果をリクエストに付随させてＡＰＩサーバ３に送信する場合に、複数のＡＰＩサーバ３の中から当該リクエストに対応するＡＰＩサーバ３に、認証処理結果またはセッション処理結果をリクエストに付随させて送信してもよい。
【００３６】
これにより、アプリケーションサーバ２がクライアント１からのリクエストを受け付けて、認証処理またはセッション処理を行った後、続く処理をリクエストに対応するＡＰＩサーバ３に振り分けるので、クライアント１側の処理が簡易となる効果を奏する。たとえば、クライアント１はリクエストをアプリケーションサーバ２に送信するのみで、リクエストの内容に依存せずに、任意のリクエストに対する結果をアプリケーションサーバ２から受信することができ、一度の手続きで、必要とする関連作業をすべて完了させられるようになるという効果を奏する。すなわち、本実施形態によるＷＥＢシステムは、クライアント１に対して、ワンストップサービスを提供することができる。
【００３７】
なお、ユーザ情報記憶部２１は、ハードディスク装置や光磁気ディスク装置、フラッシュメモリ等の不揮発性のメモリや、ＣＤ−ＲＯＭ等の読み出しのみが可能な記憶媒体、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）のような揮発性のメモリ、あるいはこれらの組み合わせにより構成されるものとする。
【００３８】
なお、図１におけるアプリケーションサーバ２が有する認証・セッション処理部２２とアプリケーション処理部２３、および、ＡＰＩサーバ３が有するリクエスト処理部３１の各構成は、専用のハードウェアにより実現されるものであってもよく、また、この各構成はメモリおよびＣＰＵ（中央演算装置）により構成され、当該各構成の機能を実現するためのプログラムをメモリにロードして実行することによりその機能を実現させるものであってもよい。
【００３９】
また、図１におけるアプリケーションサーバ２が有する認証・セッション処理部２２とアプリケーション処理部２３、および、ＡＰＩサーバ３が有するリクエスト処理部３１の各構成の機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより各構成の機能を実現してもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。
【００４０】
また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含むものとする。また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであっても良い。
【００４１】
以上、この発明の実施形態を図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。
【図面の簡単な説明】
【００４２】
【図１】この発明の一実施形態によるＷｅｂシステムの構成を示すブロック図である。
【図２】図１のＷｅｂシステムの動作を説明するフローチャートである。
【図３】一例としての認証結果を示す情報の通信形式（ＨＴＴＰヘッダ）を示す図である。
【符号の説明】
【００４３】
１…クライアント、２…アプリケーションサーバ、３…ＡＰＩサーバ、２１…ユーザ情報記憶部、２２…認証・セッション処理部、２３…アプリケーション処理部、３１…リクエスト処理部
【技術分野】
【０００１】
本発明は、Ｗｅｂシステムおよびリクエスト処理方法に関する。
【背景技術】
【０００２】
一般に、アプリケーションサーバとＡＰＩサーバとにより構成されるＷｅｂシステムでは、両サーバに共通した認証・セッション機能が実装されている。ところで、アプリケーションサーバのロジックはサービスにより異なり、適したプログラム言語により実装される。たとえば、Ｗｅｂシステムの開発には、Ｓｔｒｕｔｓ、Ｒｕｂｙ ｏｎ Ｒａｉｌｓ、またはＣａｔａｌｙｓｔのような様々なフレームワークが用いられている（非特許文献１参照）。
【非特許文献１】Dave Thomas, David Heinemeier Hansson, "第2版 Rails によるアジャイル Webアプリケーション開発", 21.2節, オーム社, 2006年 2月
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら、認証・セッション機能に用いられるデータ構造はプログラム言語やフレームワークによって異なり、また複雑である。そのために、ＡＰＩサーバを再利用することは難しいという問題があった。
【０００４】
たとえば、上述したＳｔｒｕｔｓ、Ｒｕｂｙ ｏｎ Ｒａｉｌｓ、またはＣａｔａｌｙｓｔのようなフレームワークは認証・セッション機能を提供するが、用いられるデータ構造はフレームワークによって異なり、複雑である。また、たとえば、Ｒｕｂｙ ｏｎ Ｒａｉｌｓでは、セッション情報のデータ構造として、シリアライズされたＲｕｂｙデータオブジェクトを用いるために、他のプログラム言語から利用することは難しい。このような理由により、ＡＰＩサーバを再利用することは難しいという問題があった。
【０００５】
また、ＡＰＩサーバに要求される機能はサービスによらず似ているため、再利用されることが望ましいという要望がある。
【０００６】
本発明は、このような事情に鑑みてなされたもので、その目的は、アプリケーションサーバによらず、ＡＰＩサーバを再利用することができるＷｅｂシステムおよびリクエスト処理方法を提供することにある。
【課題を解決するための手段】
【０００７】
この発明は上述した課題を解決するためになされたもので、請求項１に記載の発明は、アプリケーションサーバとＡＰＩサーバとから構成されるＷｅｂシステムであって、前記アプリケーションサーバが、クライアントから受信したリクエストの認証処理またはセッション処理を行うとともに、前記リクエストが前記ＡＰＩサーバへのアクセスを要求している場合には前記認証処理結果または前記セッション処理結果を前記リクエストに付随させて前記ＡＰＩサーバに送信する認証・セッション処理部を有し、前記ＡＰＩサーバが、前記アプリケーションサーバから受信したリクエストに付随されている認証処理結果またはセッション処理結果に基づいて、当該受信したリクエストを処理するリクエスト処理部を有することを特徴とするＷｅｂシステムである。
【０００８】
請求項２に記載の発明は、前記認証・セッション処理部が、前記認証処理結果または前記セッション処理結果を前記リクエストに付随させて前記ＡＰＩサーバに送信する場合に、前記認証処理結果または前記セッション処理結果を前記リクエストに付随させて前記ＡＰＩサーバに標準化された通信方式で送信することを特徴とする請求項１に記載のＷｅｂシステムである。
【０００９】
請求項３に記載の発明は、前記Ｗｅｂシステムが、複数の前記ＡＰＩサーバ、を有しており、前記認証・セッション処理部が、前記認証処理結果または前記セッション処理結果を前記リクエストに付随させて前記ＡＰＩサーバに送信する場合に、前記複数のＡＰＩサーバの中から当該リクエストに対応するＡＰＩサーバに、前記認証処理結果または前記セッション処理結果を前記リクエストに付随させて送信することを特徴とする請求項１または請求項２に記載のＷｅｂシステムである。
【００１０】
請求項４に記載の発明は、アプリケーションサーバとＡＰＩサーバとから構成されるＷｅｂシステムにおいて用いられるリクエスト処理方法であって、前記アプリケーションサーバが、クライアントから受信したリクエストの認証処理またはセッション処理を行うとともに、前記リクエストが前記ＡＰＩサーバへのアクセスを要求している場合には前記認証処理結果または前記セッション処理結果を前記リクエストに付随させて前記ＡＰＩサーバに送信する認証・セッション処理手順を有し、前記ＡＰＩサーバが、前記アプリケーションサーバから受信したリクエストに付随されている認証処理結果またはセッション処理結果に基づいて、当該受信したリクエストを処理するリクエスト処理手順を有することを特徴とするリクエスト処理方法である。
【発明の効果】
【００１１】
この発明によれば、アプリケーションサーバの認証・セッション処理部が、クライアントから受信したリクエストの認証処理またはセッション処理を行うとともに、リクエストがＡＰＩサーバへのアクセスを要求している場合には認証処理結果またはセッション処理結果をリクエストに付随させてＡＰＩサーバに送信する。たとえば、認証・セッション処理部は、認証処理結果またはセッション処理結果をリクエストに付随させてＡＰＩサーバに送信する場合に、認証処理結果またはセッション処理結果をリクエストに付随させてＡＰＩサーバに標準化された通信方式で送信する。
【００１２】
これにより、ＡＰＩサーバのリクエスト処理部は、標準化された通信方式で認証処理結果またはセッション処理結果を受信することができる。よって、このＡＰＩサーバのリクエスト処理部は、アプリケーションサーバから受信したリクエストに付随されている認証処理結果またはセッション処理結果に基づいて、当該受信したリクエストを処理することができる。
【００１３】
従って、アプリケーションサーバとＡＰＩサーバとを有するＷｅｂシステムは、アプリケーションサーバによらずＡＰＩサーバを再利用することができるという効果を奏する。
【発明を実施するための最良の形態】
【００１４】
以下、図面を参照して、本発明の実施の形態について説明する。図１は、この発明の一実施形態によるＷｅｂシステムの構成を示す概略ブロック図である。
このＷｅｂシステムは、クライアント１と、アプリケーションサーバ２と、ＡＰＩ（Application Programming Interface）サーバ３とを有している。このＷｅｂシステムは、アプリケーションサーバ２およびＡＰＩサーバ３から構成されるサーバと、クライアント１とのクライアントサーバシステムとして構成されている。
【００１５】
このアプリケーションサーバ２とクライアント１とは、通信回線を介してＨＴＴＰ（HyperText Transfer Protocol）によって通信を行う。また、アプリケーションサーバ２とＡＰＩサーバ３とは、通信回線を介してＨＴＴＰによって通信を行う。この通信回線は、たとえばインターネット網である。すなわち、アプリケーションサーバ２とクライアント１との間の通信方式、および、アプリケーションサーバ２とＡＰＩサーバ３との間の通信方式は、標準化された通信方式である。
【００１６】
次に、アプリケーションサーバ２とＡＰＩサーバ３との一例としての構成について説明する。ここでは、アプリケーションサーバ２とＡＰＩサーバ３との構成のうち、本実施形態に関する構成のみについて説明する。
【００１７】
アプリケーションサーバ２は、ユーザ情報記憶部２１と、認証・セッション処理部２２と、アプリケーション処理部２３とを有している。ユーザ情報記憶部２１には、たとえばクライアント１のユーザ情報と当該クライアントのパスワード情報（または、パスワードのハッシュ情報）とが関連付けて予め記憶されている。
【００１８】
認証・セッション処理部２２は、クライアント１から受信したリクエストの認証処理またはセッション処理を行うとともに、リクエストがＡＰＩサーバ３へのアクセスを要求している場合には認証処理結果またはセッション処理結果をリクエストに付随させてＡＰＩサーバ３に送信する。また、認証・セッション処理部２２は、クライアント１から受信したリクエストの認証処理またはセッション処理を行うとともに、リクエストがＡＰＩサーバ３へのアクセスを要求していない場合にはリクエストをアプリケーション処理部２３に送信する。
【００１９】
たとえば、認証・セッション処理部２２は、クライアント１からリクエストとともにユーザ情報とパスワード情報とを受信する。そして、認証・セッション処理部２２は、クライアント１から受信したユーザ情報と関連付けられているパスワード情報をユーザ情報記憶部２１から読み出し、当該読み出したパスワード情報とクライアント１から受信したパスワード情報とが一致するか否かを判定することにより、リクエストを認証する。この判定した結果が、認証処理結果に相当する。
【００２０】
なお、この認証処理は、ＯｐｅｎＩＤなどの技術によって、アプリケーションサーバ２の外部で行われてもよい。このＯｐｅｎＩＤとは、サイトを越えて使用できる「認証システム」であり、個人が登録した情報を公開することで個人の同一性を保証する認証システムである。
【００２１】
また、認証・セッション処理部２２は、クライアント１を一旦認証した後は、クライアント１と接続している期間においては、クライアント１とのセッション情報によりクライアント１の認証を維持してもよい。このセッションにより維持される認証の結果が、セッション処理結果に相当する。
【００２２】
アプリケーション処理部２３は、受信したリクエストを処理し、処理結果をクライアント１に返信する。
【００２３】
ＡＰＩサーバ３は、リクエスト処理部３１を有している。このリクエスト処理部３１は、アプリケーションサーバ２から受信したリクエストに付随されている認証処理結果またはセッション処理結果に基づいて、当該受信したリクエストを処理する。そして、リクエスト処理部３１は、処理結果をクライアント１にアプリケーションサーバ２を介して返信する。
【００２４】
次に、図２を用いて、図１を用いて説明したＷｅｂシステムの動作について説明する。
まず、クライアント１からのリクエストがサーバに到着すると（ステップＳ１０１）、サーバが有するアプリケーションサーバ２の認証・セッション処理部２２へとリクエストは届けられる。次に、認証・セッション処理部２２は、ユーザ情報記憶部２１に記憶されているユーザ情報を参照してリクエストの認証処理を実行する（ステップＳ１０２）。
【００２５】
次に、認証・セッション処理部２２は認証に成功したか否かを判定し（ステップＳ１０３）、このステップＳ１０３で認証に失敗した場合には、認証・セッション処理部２２は、エラーコードとしてクライアントエラーではなくサーバーエラーをクライアント１に送信し（ステップＳ１０４）、以降の処理を終了する。
【００２６】
一方、ステップＳ１０３で認証に成功した場合には、認証・セッション処理部２２は、リクエストの内容によって後続の処理を決定する。たとえば認証・セッション処理部２２は、まずリクエストの内容がＡＰＩサーバ３に対するリクエストであるか否かを判定する（ステップＳ１０５）。このステップＳ１０５において、リクエストの内容がＡＰＩサーバ３に対するリクエストである場合には、認証・セッション処理部２２は、リクエストをＡＰＩサーバ３に転送し（ステップＳ１０６）、そうでない場合にはリクエストをアプリケーション処理部２３に転送する（ステップＳ１０９）。
【００２７】
このステップＳ１０９に続いて、アプリケーション処理部２３は、サービスに応じた処理を実行し（ステップＳ１１０）、その処理結果をクライアント１に返信する（ステップＳ１１１）。
【００２８】
なお、認証・セッション処理部２２は、上述したステップＳ１０６でリクエストをＡＰＩサーバ３に転送する場合に、ＡＰＩサーバ３に転送するリクエストに、ステップＳ１０２で得た認証結果を付随して転送する。一例としては、図３に示すように、ＨＴＴＰヘッダ（Ｘ−Ｕｓｅｒｎａｍｅ）に認証されたユーザ名を示す情報を追加する。なお、この認証結果は、ＨＴＴＰヘッダではなく、ＵＲＬの一部として追加してもよい。たとえば、ＵＲＬの末尾に、「？ｘ−ｕｓｅｒｎａｍｅ＝ｓｕｚｕｋｉ」のようにして追加してもよい。
【００２９】
図２の説明に戻り、上述したステップＳ１０６に続いて、ＡＰＩサーバ３に到着したリクエストは、ＡＰＩサーバ３のリクエスト処理部３１へと届けられる。リクエスト処理部３１は、リクエストに付随された認証結果に基づいて、リクエストの処理を実行する（ステップＳ１０７）。たとえば、リクエスト処理部３１は、リクエストに付随された認証結果に基づいて、リクエストに含まれているデータに対するアクセス制御を実行する。
【００３０】
次に、リクエスト処理部３１は、処理結果をクライアント１にアプリケーションサーバ２を介して返信する（ステップＳ１０８）。たとえば、リクエスト処理部３１は、処理結果をアプリケーションサーバ２へと返信する。次に、アプリケーションサーバ２は、ＡＰＩサーバ３からの処理結果をそのままクライアント１に返信する。この処理は、たとえば、アプリケーションサーバ２が処理結果転送部を有しており、この処理結果転送部が、ＡＰＩサーバ３から受信した処理結果をクライアント１に転送することにより実行される。
【００３１】
なお、ここではステップＳ１０６において、認証・セッション処理部２２が、ＡＰＩサーバ３に転送するリクエストに、ステップＳ１０２で得た認証結果を付随して転送する場合について説明したが、ＡＰＩサーバ３に転送するリクエストにセッション処理結果を付随して転送してもよい。
【００３２】
図２を用いて説明したＷｅｂシステムの動作において、アプリケーションサーバ２とＡＰＩサーバ３との間の通信方式は、標準化されたＨＴＴＰであり、特定のプログラム言語やフレームワークに依存しない。そのため、ＡＰＩサーバ３は、アプリケーションサーバ２に依存せずに、認証処理結果またはセッション処理結果をアプリケーションサーバ２の認証・セッション処理部２２から受信し、この受信した認証処理結果またはセッション処理結果に基づいてリクエストを処理することができる。この結果、アプリケーションサーバ２に依存せず、ＡＰＩサーバ３を再利用することが可能となり、システム開発における経済性が向上する。
【００３３】
また、クライアント１はリクエストをアプリケーションサーバ２に送信するのみで、リクエストの結果をアプリケーションサーバ２から受信することができるという効果を奏する。
【００３４】
また、以上説明したＷｅｂシステムによれば、ＡＰＩサーバ３は、複数のアプリケーションサーバ２で実行する認証処理およびセッション管理の結果に基づいて所要の処理を行うので、ＡＰＩサーバ３の機能を複数のアプリケーションサーバ２で再利用できるという効果を奏する。たとえば、図１を用いたＷｅｂシステムにおいては、Ｗｅｂシステムが１つのアプリケーションサーバ２を有している場合について説明したが、Ｗｅｂシステムは複数のアプリケーションサーバ２を有していてもよい。そして、この複数のアプリケーションサーバ２が、ＡＰＩサーバ３の機能を共有して再利用してもよい。
【００３５】
なお、図１を用いたＷｅｂシステムにおいては、Ｗｅｂシステムが１つのＡＰＩサーバ３を有している場合について説明したが、Ｗｅｂシステムは複数のＡＰＩサーバ３を有してもよい。そして、アプリケーションサーバ２の認証・セッション処理部２２は、認証処理結果またはセッション処理結果をリクエストに付随させてＡＰＩサーバ３に送信する場合に、複数のＡＰＩサーバ３の中から当該リクエストに対応するＡＰＩサーバ３に、認証処理結果またはセッション処理結果をリクエストに付随させて送信してもよい。
【００３６】
これにより、アプリケーションサーバ２がクライアント１からのリクエストを受け付けて、認証処理またはセッション処理を行った後、続く処理をリクエストに対応するＡＰＩサーバ３に振り分けるので、クライアント１側の処理が簡易となる効果を奏する。たとえば、クライアント１はリクエストをアプリケーションサーバ２に送信するのみで、リクエストの内容に依存せずに、任意のリクエストに対する結果をアプリケーションサーバ２から受信することができ、一度の手続きで、必要とする関連作業をすべて完了させられるようになるという効果を奏する。すなわち、本実施形態によるＷＥＢシステムは、クライアント１に対して、ワンストップサービスを提供することができる。
【００３７】
なお、ユーザ情報記憶部２１は、ハードディスク装置や光磁気ディスク装置、フラッシュメモリ等の不揮発性のメモリや、ＣＤ−ＲＯＭ等の読み出しのみが可能な記憶媒体、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）のような揮発性のメモリ、あるいはこれらの組み合わせにより構成されるものとする。
【００３８】
なお、図１におけるアプリケーションサーバ２が有する認証・セッション処理部２２とアプリケーション処理部２３、および、ＡＰＩサーバ３が有するリクエスト処理部３１の各構成は、専用のハードウェアにより実現されるものであってもよく、また、この各構成はメモリおよびＣＰＵ（中央演算装置）により構成され、当該各構成の機能を実現するためのプログラムをメモリにロードして実行することによりその機能を実現させるものであってもよい。
【００３９】
また、図１におけるアプリケーションサーバ２が有する認証・セッション処理部２２とアプリケーション処理部２３、および、ＡＰＩサーバ３が有するリクエスト処理部３１の各構成の機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより各構成の機能を実現してもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。
【００４０】
また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含むものとする。また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであっても良い。
【００４１】
以上、この発明の実施形態を図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。
【図面の簡単な説明】
【００４２】
【図１】この発明の一実施形態によるＷｅｂシステムの構成を示すブロック図である。
【図２】図１のＷｅｂシステムの動作を説明するフローチャートである。
【図３】一例としての認証結果を示す情報の通信形式（ＨＴＴＰヘッダ）を示す図である。
【符号の説明】
【００４３】
１…クライアント、２…アプリケーションサーバ、３…ＡＰＩサーバ、２１…ユーザ情報記憶部、２２…認証・セッション処理部、２３…アプリケーション処理部、３１…リクエスト処理部
【特許請求の範囲】
【請求項１】
アプリケーションサーバとＡＰＩサーバとから構成されるＷｅｂシステムであって、
前記アプリケーションサーバが、
クライアントから受信したリクエストの認証処理またはセッション処理を行うとともに、前記リクエストが前記ＡＰＩサーバへのアクセスを要求している場合には前記認証処理結果または前記セッション処理結果を前記リクエストに付随させて前記ＡＰＩサーバに送信する認証・セッション処理部を有し、
前記ＡＰＩサーバが、
前記アプリケーションサーバから受信したリクエストに付随されている認証処理結果またはセッション処理結果に基づいて、当該受信したリクエストを処理するリクエスト処理部を有する
ことを特徴とするＷｅｂシステム。
【請求項２】
前記認証・セッション処理部が、
前記認証処理結果または前記セッション処理結果を前記リクエストに付随させて前記ＡＰＩサーバに送信する場合に、前記認証処理結果または前記セッション処理結果を前記リクエストに付随させて前記ＡＰＩサーバに標準化された通信方式で送信する
ことを特徴とする請求項１に記載のＷｅｂシステム。
【請求項３】
前記Ｗｅｂシステムが、
複数の前記ＡＰＩサーバ、
を有しており、
前記認証・セッション処理部が、
前記認証処理結果または前記セッション処理結果を前記リクエストに付随させて前記ＡＰＩサーバに送信する場合に、前記複数のＡＰＩサーバの中から当該リクエストに対応するＡＰＩサーバに、前記認証処理結果または前記セッション処理結果を前記リクエストに付随させて送信する
ことを特徴とする請求項１または請求項２に記載のＷｅｂシステム。
【請求項４】
アプリケーションサーバとＡＰＩサーバとから構成されるＷｅｂシステムにおいて用いられるリクエスト処理方法であって、
前記アプリケーションサーバが、
クライアントから受信したリクエストの認証処理またはセッション処理を行うとともに、前記リクエストが前記ＡＰＩサーバへのアクセスを要求している場合には前記認証処理結果または前記セッション処理結果を前記リクエストに付随させて前記ＡＰＩサーバに送信する認証・セッション処理手順を有し、
前記ＡＰＩサーバが、
前記アプリケーションサーバから受信したリクエストに付随されている認証処理結果またはセッション処理結果に基づいて、当該受信したリクエストを処理するリクエスト処理手順を有する
ことを特徴とするリクエスト処理方法。
【請求項１】
アプリケーションサーバとＡＰＩサーバとから構成されるＷｅｂシステムであって、
前記アプリケーションサーバが、
クライアントから受信したリクエストの認証処理またはセッション処理を行うとともに、前記リクエストが前記ＡＰＩサーバへのアクセスを要求している場合には前記認証処理結果または前記セッション処理結果を前記リクエストに付随させて前記ＡＰＩサーバに送信する認証・セッション処理部を有し、
前記ＡＰＩサーバが、
前記アプリケーションサーバから受信したリクエストに付随されている認証処理結果またはセッション処理結果に基づいて、当該受信したリクエストを処理するリクエスト処理部を有する
ことを特徴とするＷｅｂシステム。
【請求項２】
前記認証・セッション処理部が、
前記認証処理結果または前記セッション処理結果を前記リクエストに付随させて前記ＡＰＩサーバに送信する場合に、前記認証処理結果または前記セッション処理結果を前記リクエストに付随させて前記ＡＰＩサーバに標準化された通信方式で送信する
ことを特徴とする請求項１に記載のＷｅｂシステム。
【請求項３】
前記Ｗｅｂシステムが、
複数の前記ＡＰＩサーバ、
を有しており、
前記認証・セッション処理部が、
前記認証処理結果または前記セッション処理結果を前記リクエストに付随させて前記ＡＰＩサーバに送信する場合に、前記複数のＡＰＩサーバの中から当該リクエストに対応するＡＰＩサーバに、前記認証処理結果または前記セッション処理結果を前記リクエストに付随させて送信する
ことを特徴とする請求項１または請求項２に記載のＷｅｂシステム。
【請求項４】
アプリケーションサーバとＡＰＩサーバとから構成されるＷｅｂシステムにおいて用いられるリクエスト処理方法であって、
前記アプリケーションサーバが、
クライアントから受信したリクエストの認証処理またはセッション処理を行うとともに、前記リクエストが前記ＡＰＩサーバへのアクセスを要求している場合には前記認証処理結果または前記セッション処理結果を前記リクエストに付随させて前記ＡＰＩサーバに送信する認証・セッション処理手順を有し、
前記ＡＰＩサーバが、
前記アプリケーションサーバから受信したリクエストに付随されている認証処理結果またはセッション処理結果に基づいて、当該受信したリクエストを処理するリクエスト処理手順を有する
ことを特徴とするリクエスト処理方法。
【図１】
【図２】
【図３】
【図２】
【図３】
【公開番号】特開２０１０−１４６１６９（Ｐ２０１０−１４６１６９Ａ）
【公開日】平成２２年７月１日（２０１０．７．１）
【国際特許分類】
【出願番号】特願２００８−３２１０７３（Ｐ２００８−３２１０７３）
【出願日】平成２０年１２月１７日（２００８．１２．１７）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
【公開日】平成２２年７月１日（２０１０．７．１）
【国際特許分類】
【出願日】平成２０年１２月１７日（２００８．１２．１７）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
[ Back to top ]