JP5617709B2 - プログラム、制御装置および方法 - Google Patents

プログラム、制御装置および方法 Download PDF

Info

Publication number
JP5617709B2
JP5617709B2 JP2011058539A JP2011058539A JP5617709B2 JP 5617709 B2 JP5617709 B2 JP 5617709B2 JP 2011058539 A JP2011058539 A JP 2011058539A JP 2011058539 A JP2011058539 A JP 2011058539A JP 5617709 B2 JP5617709 B2 JP 5617709B2
Authority
JP
Japan
Prior art keywords
access
computer
request
database
access 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 - Fee Related
Application number
JP2011058539A
Other languages
English (en)
Other versions
JP2012194809A (ja
Inventor
智裕 大嶽
智裕 大嶽
昭彦 松尾
昭彦 松尾
小高　敏裕
敏裕 小高
憲二 大木
憲二 大木
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2011058539A priority Critical patent/JP5617709B2/ja
Priority to US13/329,837 priority patent/US8825703B2/en
Publication of JP2012194809A publication Critical patent/JP2012194809A/ja
Application granted granted Critical
Publication of JP5617709B2 publication Critical patent/JP5617709B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

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]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25—Integrating or interfacing systems involving database management systems
    • 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/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0209—Architectural arrangements, e.g. perimeter networks or demilitarized zones
    • 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/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Transfer Between Computers (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

本発明はデータベース（ＤＢ）へのアクセスを制御する技術に関する。
近年ではＷｅｂアプリケーションが広く利用されており、Ｗｅｂアプリケーションに関連する様々な技術が提案されている。
ところで、多くのＷｅｂアプリケーションはＤＢを利用する。その際、クライアントマシンが属するイントラネットとはファイアウォールによって隔てられた外部ネットワークにＤＢが存在することがある。
しかし、ＤＢが外部ネットワークに存在することは、ユーザにＷｅｂアプリケーションの利用を躊躇させる一因である。なぜなら、ユーザはある種のデータを秘密にしたいことがあるからである。ユーザは、秘密にしたいデータが外部ネットワーク上のＤＢに保存されることを嫌って、Ｗｅｂアプリケーションを利用しないことに決めるかもしれない。
これに対し、Ｗｅｂアプリケーションが利用するＤＢがイントラネット内にあれば、ユーザが秘密にしたいデータが外部ネットワーク上のＤＢに不揮発的に保存されるのを防ぐことができる。したがって、Ｗｅｂアプリケーションの利用促進のためには、ＤＢをイントラネット内に設けられるようにすることが有効な場合がある。
特表２０１０−５１４０７３号公報 特開２０１０−５５５６０号公報 特表２０００−５０５２７０号公報
Google Secure Data Connector, http://code.google.com/intl/ja/securedataconnector/docs/1.3/overview.html（２０１１年２月２日閲覧）
ところが、外部ネットワーク上のサーバで動作するＷｅｂアプリケーションが、イントラネット内のＤＢのデータを利用した処理を行うことを可能にするための技術は、まだ発展途上である。すなわち、外部ネットワークなどに配置された第１のコンピュータに搭載されたＷｅｂアプリケーションなどのアプリケーションがＤＢへのアクセス要求を発行したとしても、Ｗｅｂアプリケーションと連携して動作可能なブラウザなどを搭載するイントラネット内の第２のコンピュータの当該ブラウザは、ＤＢへのアクセス処理に対応しておらず、アクセス要求に従ってＤＢにアクセスすることができない。
そこで１つの側面では、本発明は、第２のコンピュータが第１のコンピュータに代わって、データベースにアクセスできるようにすることを目的とする。
また、他の側面では、本発明は、外部ネットワーク上のサーバで動作するＷｅｂアプリケーションがイントラネット内のＤＢのデータを利用した処理を行うことを可能にする技術を提供することを目的とする。
一態様により提供されるプログラムは、第１のコンピュータに以下の制御処理を実行させる。
前記制御処理は、第２のコンピュータから、特定のパスへのアクセスを求める特定要求を受け付けることを含む。また、前記制御処理は、前記第２のコンピュータと前記第１のコンピュータとの間のコネクションを、前記特定要求の受付を契機として確立することを含む。
さらに、前記制御処理は、前記第２のコンピュータのアクセス先であるアプリケーションがデータベースへのアクセスを求めるデータベースアクセス要求を、前記アプリケーションから受け付けることを含む。
また、前記データベースアクセス要求にしたがって前記データベースにアクセスし、データベースアクセス結果を前記データベースから取得し、前記第１のコンピュータに前記データベースアクセス結果を送信する代行処理を、前記第２のコンピュータに実行させるための実行命令スクリプトを、前記第２のコンピュータに送信することを、前記制御処理は含む。
そして、前記制御処理は、前記データベースアクセス要求を、前記実行命令スクリプトに含めて、または前記実行命令スクリプトとは別に、前記コネクションを介して前記第２のコンピュータに送信することで、前記代行処理を前記第２のコンピュータに実行させることを含む。また、前記制御処理は、前記第２のコンピュータから前記データベースアクセス結果を受信することと、前記データベースアクセス結果を前記アプリケーションに出力することを含む。
上記プログラムは、例えば、第２のコンピュータとデータベースが同じイントラネット内にあり、かつ、第１のコンピュータがイントラネットの外部のネットワーク上にあるような環境において利用されてもよい。つまり、第１のコンピュータからデータベースへのアクセスが許可されない環境において、上記プログラムが利用されてもよい。
上記プログラムによれば、第２のコンピュータがデータベースにアクセスしデータベースアクセス結果は、第２のコンピュータから第１のコンピュータに送信され、最終的にはアプリケーションに出力される。
また、たとえ第１のコンピュータからデータベースへのアクセスが許可されない環境であったとしても、上記プログラムによれば、上記アプリケーションは上記データベースアクセス結果を用いた処理を行うこともできる。
システム構成図である。 対応表と設定ファイルの例を示す図である。 比較例のシステム構成図である。 コンピュータのハードウェア構成図である。 ＤＢアクセス代行スクリプトにしたがってブラウザが実行する処理のフローチャートである。 ＤＢインタフェイス部の動作を示すフローチャートである。 スクリプト生成部の動作を示すフローチャートである。 第１実施形態の一動作例に関するシーケンス図である。 第１実施形態でブラウザに送信されるソースコードの例を示す図である。 第１実施形態において振り分け部がＤＢインタフェイス部からのＤＢアクセス要求の受付を契機として行う処理のフローチャートである。 第１実施形態において振り分け部がブラウザからの要求の受信を契機として行う処理のフローチャートである。 第２実施形態のＷｅｂサーバの動作を説明するアクティビティ図である。 第２実施形態の一動作例に関するシーケンス図である。 第２実施形態でブラウザに送信されるソースコードの例を示す図である。 第２実施形態において振り分け部がＤＢインタフェイス部からのＤＢアクセス要求の受付を契機として行う処理のフローチャートである。 第２実施形態において振り分け部がブラウザからの要求の受信を契機として行う処理のフローチャートである。 設定ファイルの他の例を示す図である。 変形例のシステム構成図である。 変形例のＤＢインタフェイス部の動作を説明するフローチャートである。
以下、実施形態について、図面を参照しながら詳細に説明する。まず、図１〜７を参照して、第１実施形態と第２実施形態の共通点について説明する。次に、「ｉｆｒａｍｅストリーミング」または「ＨＴＴＰ（Hypertext Transfer Protocol）ストリーミング」と呼ばれる技術を利用する第１実施形態について、図８〜１１を参照して説明する。続いて、「ロングポーリング（long polling）」と呼ばれる技術を利用する第２実施形態について、図１２〜１６を参照して説明する。その後、その他の変形例について、図１７〜１９を参照して説明する。
図１は、第１実施形態と第２実施形態に共通のシステム構成図である。図１のシステムは、Ｗｅｂサーバ１００とクライアントマシン１１０とＤＢサーバ１２０を含む。Ｗｅｂサーバ１００は、換言すれば、アプリケーションサーバである。
また、ファイアウォール１３０が、クライアントマシン１１０とＤＢサーバ１２０の属するイントラネット１４０を、外部からの不正なアクセスから保護する。なお、図面では紙幅の都合上、「ファイアウォール」を“Ｆ／Ｗ”と表記する。
以下では、ファイアウォール１３０によってイントラネット１４０と隔てられたネットワークを、「外部ネットワーク１５０」という。換言すれば、外部ネットワーク１５０は、イントラネット１４０の外部のネットワークであり、クライアントマシン１１０やＤＢサーバ１２０にとっては、インターネット側のネットワークである。
具体的には、外部ネットワーク１５０は、例えば、インターネットを介してイントラネット１４０と接続された他のイントラネットであってもよい。Ｗｅｂサーバ１００は外部ネットワーク１５０に属する。
例えば、イントラネット１４０は、ある企業のイントラネットでもよい。また、外部ネットワーク１５０は、Ｗｅｂサービスを提供するＳａａＳ（Software as a Service）ベンダあるいはＡＳＰ（Application Service Provider）のイントラネットでもよい。
Ｗｅｂサーバ１００は、ＨＴＴＰサーバソフトウェアがインストールされたサーバマシンであり、Ｗｅｂアプリケーション１０１を実行する。他方、クライアントマシン１１０はブラウザ１１１を実行する。また、ＤＢサーバ１２０は、Ｗｅｂアプリケーション１０１が処理に用いる各種のデータを格納するＤＢ１２１を有する。
Ｗｅｂサーバ１００は、ＤＢインタフェイス部１０２と振り分け部１０３を含み、振り分け部１０３はスクリプト生成部１０４を含む。そして、Ｗｅｂサーバ１００は、対応表１０５と設定ファイル１０６を記憶している。対応表１０５と設定ファイル１０６の具体例は、図２とともに後述する。
Ｗｅｂサーバ１００は、Ｗｅｂアプリケーション１０１を実行するだけでなく、ＤＢアクセスの流れを制御するサーバサイドの制御装置としても動作する。換言すれば、ＤＢインタフェイス部１０２と振り分け部１０３（スクリプト生成部１０４を含む）は、対応表１０５と設定ファイル１０６を用いて、制御装置の少なくとも一部として動作する。
ＤＢインタフェイス部１０２は、Ｗｅｂアプリケーション１０１に対してＤＢアクセスのためのインタフェイスを提供する。振り分け部１０３は、Ｗｅｂアプリケーション１０１からＤＢ１２１へのアクセスを中継するために、ブラウザ１１１からの要求に応じた処理と、ＤＢインタフェイス部１０２からの要求に応じた処理を行う。振り分け部１０３の具体的な動作は実施形態に応じて様々に異なるので、振り分け部１０３についての詳細は、図８〜１６とともに後述する。
ブラウザ１１１が表示するページは、Ｗｅｂアプリケーション１０１のページを表示するためのインラインフレーム１１２と、ブラウザ１１１とＷｅｂサーバ１００との間のＣｏｍｅｔコネクションを維持するためのインラインフレーム１１３を含む。なお、以下では表記の簡略化のため、ＨＴＭＬ（HyperText Markup Language）のタグ名を用いて、「インラインフレーム」を単に“ｉｆｒａｍｅ”と表記する。
具体的には、ｉｆｒａｍｅ１１３には、ＤＢアクセス代行スクリプト１１４を含むソースコードが読み込まれる。ＤＢアクセス代行スクリプト１１４は、Ｗｅｂサーバ１００がクライアントマシン１１０にＤＢ１２１へのアクセスを代行させるためのスクリプトである。ＤＢアクセス代行スクリプト１１４は、スクリプト生成部１０４により生成され、振り分け部１０３からブラウザ１１１に送られる。
ＤＢアクセス代行スクリプト１１４は、例えばＪａｖａＳｃｒｉｐｔ（登録商標）などのスクリプト言語で書かれたスクリプトである。ＤＢアクセス代行スクリプト１１４は、１つの＜ｓｃｒｉｐｔ＞ブロックに含まれていてもよいし、ｉｆｒａｍｅ１１３に読み込まれるソースコード内の複数の＜ｓｃｒｉｐｔ＞ブロックに分散していてもよい。
上記のとおり、振り分け部１０３の具体的な動作は実施形態に応じて様々に異なるが、振り分け部１０３の動作の概要を説明すれば以下のとおりである。
振り分け部１０３は、クライアントマシン１１０から（より具体的にはブラウザ１１１から）、Ｗｅｂサーバ１００上の特定のパスへのアクセスを求める要求（以下「特定要求」という）を受け付ける。そして、振り分け部１０３は、クライアントマシン１１０（より具体的にはクライアントマシン１１０上のブラウザ１１１）とＷｅｂサーバ１００との間のコネクションを、特定要求の受付を契機として確立する。
確立されるコネクションは、具体的にはＨＴＴＰコネクションであり、より詳細にはＴＣＰ（Transmission Control Protocol）コネクション上のＨＴＴＰコネクションである。また、確立されたコネクションは、擬似的なサーバプッシュの実現のために使われるので、用途の観点からは「Ｃｏｍｅｔコネクション」とも呼ばれる。
上記の特定のパスは、「Ｗｅｂアプリケーション１０１によっては使用されない」と予め決められて、予約されている、特殊なパスである。
例えば、Ｗｅｂアプリケーション１０１が、“ｈｔｔｐ：／／ｗｗｗ．ｆｏｏ．ｃｏｍ／”配下のパスで提供されるとする。また、「Ｗｅｂサーバ１００のドキュメントルートのディレクトリ内で、アンダスコアから始まるパスは、Ｗｅｂアプリケーション１０１によっては使用されない」と予め決められているとする。
すると、例えば“／＿ｒｅｓｅｒｖｅｄＦｏｒＣｏｍｅｔ”というパスが、上記の特定のパスとして利用可能である。この場合、特定要求は、“ｈｔｔｐ：／／ｗｗｗ．ｆｏｏ．ｃｏｍ／＿ｒｅｓｅｒｖｅｄＦｏｒＣｏｍｅｔ”というＵＲＩ（Uniform Resource Identifier）がリクエストＵＲＩとして指定されたＨＴＴＰ要求であってもよい。つまり、特定要求は、ブラウザ１１１が、特定のパスにより指定されるページをｉｆｒａｍｅ１１３に読み込もうとする要求であってもよい。
あるいは、ブラウザ１１１がｉｆｒａｍｅ１１３内に読み込んだＤＢアクセス代行スクリプト１１４が、ＸＨＲ（XMLHttpRequest）オブジェクトを用いて特定のパスを含むＵＲＩに対してＨＴＴＰ要求を送信するためのコードを含んでいてもよい。この場合、特定要求は、具体的には、ＸＨＲオブジェクトを用いた、特定のパスを含むＵＲＩに対するＨＴＴＰ要求である。もちろん、特定要求は、ＸＨＲオブジェクト以外の実装による非同期通信によって実現されてもよい。
詳しくは後述するが、特定要求が上記２通りのいずれであっても、振り分け部１０３が特定要求の受付を契機として確立したコネクションは、ｉｆｒａｍｅ１１３を用いてブラウザ１１１とＷｅｂサーバ１００の間で維持される。維持されるコネクションを介して擬似的なサーバプッシュを実現することが可能である。
このように擬似的なサーバプッシュを実現するために維持されるコネクションは「Ｃｏｍｅｔコネクション」とも呼ばれる。“Ｃｏｍｅｔ”は、擬似的なサーバプッシュを実現する技法の総称である。
さて、振り分け部１０３は、ブラウザ１１１からの要求を受け付けるだけでなく、ＤＢインタフェイス部１０２からの要求も受け付ける。
具体的には、ＤＢインタフェイス部１０２は、Ｗｅｂアプリケーション１０１がＤＢ１２１へのアクセスを求める要求（以下「ＤＢアクセス要求」という）をＷｅｂアプリケーション１０１から受け付ける。そして、ＤＢインタフェイス部１０２は、受け付けたＤＢアクセス要求を振り分け部１０３に出力する。つまり、Ｗｅｂアプリケーション１０１からのＤＢアクセス要求は、ＤＢインタフェイス部１０２を介して振り分け部１０３に中継され、振り分け部１０３において受け付けられる。
振り分け部１０３は、以上のようにしてＤＢインタフェイス部１０２から受け付けたＤＢアクセス要求にしたがったＤＢ１２１へのアクセスを、クライアントマシン１１０のブラウザ１１１に代行させるため、スクリプトを送信する。ここで送信されるスクリプトを、以下では説明の便宜上「実行命令スクリプト」ともいう。
実行命令スクリプトは、具体的には、ＤＢアクセス代行スクリプト１１４の少なくとも一部である。また、実行命令スクリプトは、振り分け部１０３の指示にしたがってスクリプト生成部１０４により生成され、振り分け部１０３からブラウザ１１１に送信される。
具体的には、実行命令スクリプトは、次のような処理（説明の便宜上「代行処理」ともいう）をクライアントマシン１１０（具体的にはブラウザ１１１）に実行させるためのスクリプトである。すなわち、代行処理は、上記のＤＢアクセス要求にしたがってＤＢ１２１にアクセスし、ＤＢアクセス結果をＤＢ１２１から取得し、Ｗｅｂサーバ１００にＤＢアクセス結果を送信する処理である。
なお、振り分け部１０３は、ＤＢアクセス要求を含む実行命令スクリプトをスクリプト生成部１０４に生成させてもよい。そして、振り分け部１０３は、ＤＢアクセス要求を含む実行命令スクリプトを、上記のとおり維持されているコネクションを介して、ブラウザ１１１に送信してもよい。あるいは、振り分け部１０３は、上記のとおり維持されているコネクションを介して、ＤＢアクセス要求を、実行命令スクリプトとは別に、ブラウザ１１１に送信してもよい。
いずれにしろ、維持されているコネクションを介して、ＤＢアクセス要求が、Ｗｅｂサーバ１００からクライアントマシン１１０に擬似的にプッシュされる。そして、振り分け部１０３は、ＤＢアクセス要求をクライアントマシン１１０（具体的にはブラウザ１１１）に送信することで、クライアントマシン１１０（具体的にはブラウザ１１１）に代行処理を実行させる。換言すれば、クライアントマシン１１０のブラウザ１１１は、振り分け部１０３からのＤＢアクセス要求の受信を契機として、代行処理を実行する。
そして、ＤＢアクセス要求の受信を契機としてブラウザ１１１が代行処理を実行すると、ＤＢアクセス結果がＷｅｂサーバ１００に送信される。すると、振り分け部１０３が、ＤＢアクセス結果を受信する。
振り分け部１０３は、受信したＤＢアクセス結果をＤＢインタフェイス部１０２に出力する。すると、ＤＢインタフェイス部１０２は、振り分け部１０３から取得したＤＢアクセス結果をＷｅｂアプリケーション１０１に出力する。その結果、Ｗｅｂアプリケーション１０１は、ＤＢアクセス結果を利用した処理（例えば、動的なＨＴＭＬページの生成）を行うことができる。
以上のとおり、図１のシステムによれば、インタフェイス・サーバ、中間システム、中継サーバなどの付加的な装置は不要である。それにもかかわらず、図１のシステムによれば、ファイアウォール１３０によってＷｅｂサーバ１００とは隔てられたイントラネット１４０内に保持されるＤＢ１２１を用いた処理を、Ｗｅｂアプリケーション１０１が行うことができる。
したがって、図１のシステムによれば、ユーザは、外部ネットワーク１５０にＤＢ１２１を保存することによる情報漏洩などを懸念することなく、Ｗｅｂアプリケーション１０１を利用することができる。
もちろん、Ｗｅｂアプリケーション１０１は、一時的にＤＢ１２１のデータの一部を記憶する。例えば、Ｗｅｂアプリケーション１０１は、ＤＢ１２１に追加するための新たなデータをブラウザ１１１から受け取り、受け取ったデータをメモリに記憶するかもしれない。あるいは、Ｗｅｂアプリケーション１０１は、動的にページを生成するために、ＤＢ１２１の既存のデータをＤＢインタフェイス部１０２から受け取り、受け取ったデータをメモリに記憶するかもしれない。
しかしながら、Ｗｅｂアプリケーション１０１は、一時的に利用したデータを外部ネットワーク１５０内に恒久的に蓄積することはない。換言すれば、Ｗｅｂアプリケーション１０１によるデータの利用は、部分的かつ揮発的であり、不揮発的にＤＢ１２１全体の内容が外部ネットワーク１５０に保存されることはない。よって、外部ネットワーク１５０からの情報漏洩のリスクは非常に低く、ほとんどゼロと見なしてさしつかえない。したがって、図１のシステムは、ユーザが「外部には秘密にしたい」と考えるデータがＤＢ１２１に含まれる場合にも、好適である。
さて、図２は、対応表１０５と設定ファイル１０６の例を示す図である。対応表１０５は、コネクションの管理のために使われ、動的に書き換えられる。また、設定ファイル１０６は、スクリプト生成部１０４がＤＢアクセス代行スクリプト１１４に埋め込む値が予め設定された、静的なファイルである。
図２の対応表１０５ａは、図１の対応表１０５の具体例である。対応表１０５ａは、１つまたは複数のエントリを含む。各エントリは、セッションを識別するセッションＩＤ（identification）と、Ｃｏｍｅｔコネクションを識別するコネクションＩＤを対応づける。
図２の対応表１０５ａでは、セッションＩＤ「Ａ１」とコネクションＩＤ「Ｂ１」が対応づけられている。同様に、対応表１０５ａでは、セッションＩＤ「Ａ２」とコネクションＩＤ「Ｂ２」が対応づけられており、セッションＩＤ「Ａ３」とコネクションＩＤ「Ｂ３」が対応づけられている。
セッションＩＤは、Ｗｅｂサーバ１００（より具体的には振り分け部１０３）が、新規セッションを生成するときに発行するＩＤである。セッションＩＤは、十分な長さを持つランダムな値であることが望ましい。
コネクションＩＤは、Ｃｏｍｅｔコネクションを識別することの可能な情報であれば何でもよい。例えば、コネクションＩＤは、ファイルディスクリプタのＩＤでもよいし、ハンドルを指すポインタであってもよい。コネクションＩＤの形式は、Ｗｅｂサーバ１００のＯＳ（Operating System）に依存し得る。
なお、振り分け部１０３が、後述のフローチャートにしたがって対応表１０５へのエントリの追加と削除を行う。振り分け部１０３はさらに、セッションタイムアウトが生じると、タイムアウトしたセッションのセッションＩＤを含むエントリを対応表１０５から削除してもよい。
また、図２の設定ファイル１０６ａは、図１の設定ファイル１０６の具体例である。設定ファイル１０６の他の例については、図１７とともに後述する。設定ファイル１０６ａは、ブラウザ１１１からＤＢサーバ１２０にアクセスするためのアドレスを示す「ＤＢアドレス」という項目を含む。
図１に示すとおり、ブラウザ１１１を実行するクライアントマシン１１０とＤＢサーバ１２０は、同じイントラネット１４０に属する。したがって、ブラウザ１１１は、“１９２．１６８．１２３．４５”というプライベートＩＰ（Internet Protocol）アドレスを用いてＤＢサーバ１２０にアクセスすることができる。
なお、ＤＢサーバ１２０は、イントラネット１４０内の他のコンピュータからのＤＢ１２１へのアクセス要求を、具体的にはＨＴＴＰを介して受け付ける。よって、設定ファイル１０６ａには、ＤＢアドレスとして“ｈｔｔｐ：／／１９２．１６８．１２３．４５／”という、イントラネット１４０内のプライベートＩＰアドレスを含むＵＲＩが設定されている。
なお、ＤＢサーバ１２０のインタフェイスに応じて、設定ファイル１０６に設定されるＤＢサーバ１２０のアドレスの形式は任意に変更可能である。例えば、プライベートＩＰアドレスの代わりにＦＱＤＮ（Fully-Qualified Domain Name）を用いたＵＲＩが使われてもよい。また、ＤＢサーバ１２０のＵＲＩがポート番号を含んでもよい。
次に、図１のシステムの利点を明らかにするため、図３を参照して比較例について説明する。図３は、比較例のシステム構成図である。
図３のクライアントマシン１１０は、図１と同様に、ブラウザ１１１を実行する。また、クライアントマシン１１０は、図１と同様に、ファイアウォール１３０によって外部ネットワーク１５０と隔てられたイントラネット１４０に属する。
また、図３の比較例では、外部ネットワーク１５０内にＷｅｂサーバ１６０とＤＢサーバ１７０がある。Ｗｅｂサーバ１６０は、Ｗｅｂアプリケーション１０１を実行する点では図１のＷｅｂサーバ１００と同様である。また、ＤＢサーバ１７０は、図１のＤＢサーバ１２０が保持するのと同様のＤＢ１２１を保持する。なお、図３において、ＤＢサーバ１７０がＷｅｂサーバ１６０と同じ外部ネットワーク１５０内にある理由は、Ｗｅｂサーバ１６０がファイアウォール１３０越しにイントラネット１４０内のコンピュータにアクセスすることはできないためである。
図３の比較例において、Ｗｅｂアプリケーション１０１は、ＤＢライブラリ１６１を介してＤＢサーバ１７０上のＤＢ１２１にアクセスする。換言すれば、ＤＢライブラリ１６１は、Ｗｅｂアプリケーション１０１に対して、ＤＢアクセス用のＡＰＩ（Application Programming Interface）を提供する。
以上のようなシステム構成の図３の比較例における、ブラウザ１１１とＷｅｂアプリケーション１０１の動作は、次のとおりである。
ブラウザ１１１が、ＤＢ１２１のデータを用いた動的なページを要求した場合、または、ＤＢ１２１に対するデータの追加、削除、もしくは更新を要求した場合、Ｗｅｂアプリケーション１０１は、ＤＢライブラリ１６１を介してＤＢ１２１にアクセスする。そして、Ｗｅｂアプリケーション１０１は、ＤＢライブラリ１６１を介して、データの参照、追加、削除、または更新を行う。
Ｗｅｂアプリケーション１０１は、ＤＢ１２１へのアクセス結果に応じて、適宜のページを動的に生成してブラウザ１１１に返すか、または静的に記憶されたページをブラウザ１１１に返す。すると、ブラウザ１１１は、Ｗｅｂアプリケーション１０１から返されたページをディスプレイ上に表示する。
ここで、仮にＤＢ１２１に格納されるデータが、ユーザにとって秘密にしたいデータ（以下「機密情報」ともいう）であるとする。例えば、企業ユーザにとっての機密情報の例は、顧客情報などである。
ユーザは、「イントラネット１４０の外部に機密情報を保存したくない」と考えるかもしれない。また、ユーザは、「外部ネットワーク１５０から機密情報が漏洩するかもしれない」と心配するかもしれない。その結果、ユーザは、Ｗｅｂアプリケーション１０１を利用しないことに決定するかもしれない。
すなわち、図３の比較例のようなシステムでは、「ＤＢ１２１がイントラネット１４０の外部に保存されている」という事実が、Ｗｅｂアプリケーション１０１の利用促進を阻害する要因として働く。他方、図１の実施形態によれば、ＤＢ１２１はイントラネット１４０の内部にある。つまり、図１の実施形態では、図３の比較例と比べて、機密情報を扱うＷｅｂアプリケーション１０１の利用をユーザが躊躇する要因が、１つ解消されている。したがって、図１の実施形態は、Ｗｅｂアプリケーション１０１の利用促進のために効果的である。
しかも、図１の実施形態は、Ｗｅｂサーバ１００とクライアントマシン１１０とＤＢサーバ１２０のほかの付加的な装置を必要としない。
例えば、図３の比較例を変形して、ＤＢサーバ１７０を外部ネットワーク１５０からイントラネット１４０に移そうとすると、１つの解決策として、一種の「トンネル」機構が考えられる。
具体的には、イントラネット１４０と外部ネットワーク１５０にそれぞれ中継サーバが設けられてもよい。２台の中継サーバが、ファイアウォール１３０を超えた中継サーバ間のコネクションを維持することにより、当該コネクションを介しての、Ｗｅｂアプリケーション１０１からイントラネット１４０内のＤＢ１２１へのアクセスが可能となる。
他方、図１の実施形態は、例えば上記の２台の中継サーバのような付加的な装置を必要としない。そして、付加的な装置を必要としないことは、Ｗｅｂアプリケーション１０１の導入と運用における手間と金銭的コストを下げる効果がある。つまり、付加的な装置が不要な図１の実施形態は、保守性（serviceability）の観点においても、金銭的コストの観点においても、優れている。
さらに、付加的な装置が必要なシステムにおいては、付加的な装置がシステム全体のＳＰｏＦ（Single Point of Failure）になるおそれがある。つまり、たとえＷｅｂサーバ１６０とクライアントマシン１１０が正常でも、付加的な装置が故障することにより、Ｗｅｂアプリケーション１０１が利用不能になるおそれがある。したがって、付加的な装置が不要な図１の実施形態は、可用性の観点においても優れている。
また、図１の実施形態は、上記のような２台の中継サーバを含むシステムと比べて、セキュリティの面でも優れている。なぜなら、図１のシステムでは、特定要求の受付を契機として確立されたコネクションは、ユーザがブラウザ１１１を終了すると、切れるからである。
それに対して、２台の中継サーバを用いるシステムにおいては、ブラウザ１１１の終了後も、２台の中継サーバ間のコネクションが残る。すると、実際にはブラウザ１１１がＷｅｂアプリケーション１０１を利用していない状況下においても、中継サーバ間のコネクションを介して、Ｗｅｂサーバ１６０からイントラネット１４０内のＤＢ１２１へのアクセスが可能となる。
そして、必要以上のアクセスを許容することは、セキュリティ上、好ましくない。例えば、まれに、Ｗｅｂアプリケーション１０１とは別のマルウェアがＷｅｂサーバ１６０にインストールされるおそれがある。すると、ブラウザ１１１の終了後も残っている２台の中継サーバ間のコネクションを介して、マルウェアがイントラネット１４０内のＤＢ１２１にアクセスするおそれがある。
したがって、ブラウザ１１１の終了にともなってコネクションが切れる図１の実施形態は、２台の中継サーバを含むシステムと比べて、セキュリティの面でも優れている。
さらに、図１のシステムは、２台の中継サーバを含む上記システムと比べて、リソースの利用効率の面でも優れている。なぜなら、２台の中継サーバを用いるシステムにおいては、ブラウザ１１１の終了後も、２台の中継サーバ間のコネクションが残り、結果として、必要以上にネットワークリソースおよびＷｅｂサーバのリソースが消費されてしまうからである。
なお、図１のＤＢインタフェイス部１０２がＷｅｂアプリケーション１０１に対して提供するインタフェイスは、図３のＤＢライブラリ１６１がＷｅｂアプリケーション１０１に対して提供するインタフェイスと同じであってもよい。換言すれば、ＤＢインタフェイス部１０２は、Ｗｅｂアプリケーション１０１から利用可能なライブラリの形で実装されてもよい。
すると、図３のようなシステムで使われているＷｅｂアプリケーション１０１のソースコードを変更しなくても、図３のシステムを図１のシステムのように変更することが可能となる。つまり、既存のＷｅｂアプリケーション１０１のソースコードが有効に活用される。
ところで、図１のＷｅｂサーバ１００とクライアントマシン１１０とＤＢサーバ１２０は、いずれも、例えば図４に例示するようなコンピュータであってもよい。図４は、コンピュータのハードウェア構成図である。
図４のコンピュータ２００は、ＣＰＵ２０１（Central Processing Unit）とメモリ２０２とネットワーク接続装置２０３と入力装置２０４と出力装置２０５と記憶装置２０６と駆動装置２０７を有する。また、コンピュータ２００内の各部は、バス２０８を介して互いに接続されている。
ＣＰＵ２０１は、プログラムをメモリ２０２にロードし、メモリ２０２をワークエリアとして用いながら、プログラムを実行する。メモリ２０２は、例えばＤＲＡＭ（Dynamic Random Access Memory）である。
プログラムは、記憶装置２０６に予め格納されていてもよい。あるいは、プログラムは、ネットワーク接続装置２０３を介してネットワーク２２０からダウンロードされ、記憶装置２０６にコピーされてもよい。
または、プログラムは、可搬型記憶媒体２１０に格納されて提供され、駆動装置２０７により読み取られてもよい。駆動装置２０７により可搬型記憶媒体２１０から読み取られたプログラムは、直接メモリ２０２にロードされてもよいし、一旦記憶装置２０６にコピーされ、記憶装置２０６からメモリ２０２にロードされてもよい。可搬型記憶媒体２１０としては、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disc）などの光ディスク、光磁気ディスク、磁気ディスク、不揮発性の半導体メモリカードなどが利用可能である。
また、ネットワーク接続装置２０３は、ネットワーク２２０を介した通信を行うための通信インタフェイス装置である。ネットワーク接続装置２０３は、例えば、有線ＬＡＮ（Local Area Network）インタフェイス装置、無線ＬＡＮインタフェイス装置、またはその組み合わせである。
入力装置２０４は、例えば、キーボード、マウスやタッチスクリーンなどのポインティングデバイス、マイク、またはそれらの組み合わせである。出力装置２０５は、例えば、ディスプレイ、スピーカ、またはそれらの組み合わせである。ディスプレイは、タッチスクリーンであってもよい。
記憶装置２０６は、不揮発性の記憶装置であり、例えば、ＲＯＭ（Read Only Memory）やフラッシュメモリなどの半導体メモリ、ハードディスク装置、またはそれらの組み合わせである。なお、メモリ２０２、記憶装置２０６、および可搬型記憶媒体２１０は、いずれも、コンピュータ読み取り可能な記憶媒体の例である。これらのコンピュータ読み取り可能な記憶媒体は、有形の（tangible）記憶媒体であり、信号搬送波のような一時的な（transitory）媒体ではない。
ところで、図１のＷｅｂサーバ１００が図４のコンピュータ２００である場合、Ｗｅｂアプリケーション１０１は、ＣＰＵ２０１が実行するプログラムのうちの１つである。また、ＤＢインタフェイス部１０２、振り分け部１０３、およびスクリプト生成部１０４は、ＣＰＵ２０１がプログラムを実行することにより実現される。
また、Ｗｅｂアプリケーション１０１は、ネットワーク接続装置２０３による通信機能を利用する。そして、振り分け部１０３の通信機能は、ネットワーク接続装置２０３によって実現される。
また、Ｗｅｂサーバ１００がコンピュータ２００である場合、ネットワーク２２０は、具体的には、Ｗｅｂサーバ１００が属する外部ネットワーク１５０を含む。さらに、ネットワーク２２０は、外部ネットワーク１５０と直接的または間接的に接続された他のネットワーク（例えば、インターネットやイントラネット１４０）も含む。
対応表１０５は、メモリ２０２に格納されるが、対応表１０５の一部が記憶装置２０６に格納されてもよい。設定ファイル１０６は、不揮発性の記憶装置２０６に格納される。
また、図１のクライアントマシン１１０が図４のコンピュータ２００である場合、ブラウザ１１１は、ＣＰＵ２０１が実行するプログラムのうちの１つである。そして、ブラウザ１１１上で実行されるＤＢアクセス代行スクリプト１１４も、ＣＰＵ２０１が実行するプログラムのうちの１つである。
また、ｉｆｒａｍｅ１１２内に読み込まれたコンテンツは、ブラウザ１１１のレンダリング機能によってディスプレイ（すなわち出力装置２０５）上に表示される。ｉｆｒａｍｅ１１３内に読み込まれたコンテンツも、同様にして出力装置２０５上に表示されてもよい。しかし、後述のとおりｉｆｒａｍｅ１１３は不可視であってもよく、その場合、ｉｆｒａｍｅ１１３内に読み込まれたコンテンツは、出力装置２０５上に表示されない。
なお、ブラウザ１１１の通信機能は、ネットワーク接続装置２０３により実現される。ＤＢアクセス代行スクリプト１１４にしたがって行われる、クライアントマシン１１０とＤＢサーバ１２０の間の通信およびクライアントマシン１１０とＷｅｂサーバ１００の間の通信も、具体的には、ネットワーク接続装置２０３により実現される。
また、クライアントマシン１１０がコンピュータ２００である場合、ネットワーク２２０は、具体的には、クライアントマシン１１０が属するイントラネット１４０を含む。さらに、ネットワーク２２０は、イントラネット１４０に直接的または間接的に接続された他のネットワーク（例えば、インターネットや外部ネットワーク１５０）も含む。
また、図１のＤＢサーバ１２０が図４のコンピュータ２００である場合、ＤＢ１２１は、記憶装置２０６に格納される。そして、ＤＢサーバ１２０とクライアントマシン１１０の間の通信は、ネットワーク接続装置２０３により実現される。ＤＢサーバ１２０がコンピュータ２００である場合、ネットワーク２２０は、具体的には、ＤＢサーバ１２０が属するイントラネット１４０を少なくとも含む。
続いて、図５を参照して、ブラウザ１１１によるＤＢアクセスの代行について説明する。図５は、ＤＢアクセス代行スクリプト１１４にしたがってブラウザ１１１が実行する処理のフローチャートである。
ステップＳ１０１でブラウザ１１１は、Ｗｅｂサーバ１００からＤＢアクセス要求を受信するまで待つ。ＤＢアクセス要求は、具体的には、＜ｓｃｒｉｐｔ＞ブロック内のステートメントの形で、Ｗｅｂサーバ１００の振り分け部１０３から送信されることもある。あるいは、ＤＢアクセス要求は、ブラウザ１１１が過去にＸＨＲオブジェクトを使って送信したＨＴＴＰ要求に対するＨＴＴＰ応答の形で、振り分け部１０３から送信されることもある。
ブラウザ１１１が振り分け部１０３からＤＢアクセス要求を受信すると、処理はステップＳ１０２に移行する。なお、参照の便宜のため、図５には「ＤＢアクセス要求到着」というガード条件も記載されている。他のフローチャートでも同様に、参照の便宜のため、適宜ガード条件が記載されている。
ステップＳ１０２でブラウザ１１１は、ＤＢアクセス代行スクリプト１１４にしたがって、イントラネット１４０内のＤＢサーバ１２０にＤＢアクセス要求を送信する。
例えば、ＤＢサーバ１２０は、イントラネット１４０内のクライアントマシン１１０がＨＴＴＰを介してＤＢ１２１にアクセスするためのインタフェイスを提供してもよい。この場合、ＤＢアクセス代行スクリプト１１４は、ＸＨＲオブジェクトを用いてＨＴＴＰを介してＤＢサーバ１２０にＤＢアクセス要求を送信する処理を、ブラウザ１１１に実行させるためのコードを含んでもよい。
なお、ＤＢアクセス代行スクリプト１１４は、外部ネットワーク１５０のＷｅｂサーバ１００で生成されたスクリプトである。そして、外部ネットワーク１５０とイントラネット１４０のドメインは異なる。
よって、同一生成元ポリシ（same origin policy）によりクロスドメインの要求が許されない場合、ブラウザ１１１がＤＢアクセス代行スクリプト１１４を実行することによりイントラネット１４０内のＤＢサーバ１２０に要求を送信することは、許されない。しかし、ＸＨＲのレベル２の仕様では、ＤＢサーバ１２０が許可すればクロスドメインの要求が可能になっている。よって、レベル２のＸＨＲを用いることにより、ブラウザ１１１は、ＤＢアクセス代行スクリプト１１４を実行することでＤＢサーバ１２０にＤＢアクセス要求を送信することが可能である。
さて、ステップＳ１０２でＤＢアクセス要求を送信した後、ブラウザ１１１は、ステップＳ１０３で、イントラネット１４０内のＤＢサーバ１２０からＤＢアクセス結果を受信するまで待つ。そして、ブラウザ１１１がＤＢサーバ１２０からＤＢアクセス結果を受信すると、処理はステップＳ１０４に移行する。
例えば、ＤＢアクセス要求が、データの追加、更新、または削除を求める要求である場合、ＤＢアクセス結果は、具体的には、「成功」または「エラー」を示す制御情報であってもよい。逆に、ＤＢアクセス要求がデータの参照を求める要求である場合、ＤＢアクセス結果は、要求されたデータ自体であるか、または「エラー」を示す制御情報である。
また、ＤＢアクセス結果の具体的なデータフォーマットは、実施形態に応じて任意である。ＤＢアクセス結果は、例えば、ＪＳＯＮ（JavaScript Object Notation）、ＣＳＶ（Comma Separated Values）、ＸＭＬ（Extensible Markup Language）などによって適宜に表現されていてよい。
さて、ステップＳ１０４でブラウザ１１１は、Ｗｅｂサーバ１００に、ＤＢサーバ１２０から受信したＤＢアクセス結果を送信する。ステップＳ１０４での送信も、例えば、ＸＨＲオブジェクトにより実現可能である。また、ＤＢアクセス結果の具体的な送信先のＵＲＩは、ＤＢアクセス代行スクリプト１１４内に指定されている。
ステップＳ１０４での送信後、処理はステップＳ１０１に戻る。したがって、Ｗｅｂアプリケーション１０１があるページを動的に生成するために複数のＤＢアクセス要求を発行する場合であっても、Ｗｅｂアプリケーション１０１は、各ＤＢアクセス要求に対するＤＢアクセス結果を得ることができる。また、Ｗｅｂアプリケーション１０１の複数のページが次々に呼び出される場合であっても、Ｗｅｂアプリケーション１０１は、各ページの各ＤＢアクセス要求に対するＤＢアクセス結果を得ることができる。
続いて、図６のフローチャートを参照して、ＤＢインタフェイス部１０２の動作を説明する。
ステップＳ２０１でＤＢインタフェイス部１０２は、Ｗｅｂアプリケーション１０１からＤＢアクセス要求を受け取るまで待つ。例えば、ＤＢ１２１がリレーショナルＤＢの場合、ＤＢアクセス要求は、ＳＱＬ文（Structured Query Language statement）として表される。よって、ＤＢインタフェイス部１０２は、Ｗｅｂアプリケーション１０１からＳＱＬ文を受け取るまで待つ。
ＤＢインタフェイス部１０２がＷｅｂアプリケーション１０１からＤＢアクセス要求を受信すると、処理はステップＳ２０２に移行する。そして、ステップＳ２０２でＤＢインタフェイス部１０２は、Ｗｅｂアプリケーション１０１から受け取ったＤＢアクセス要求を振り分け部１０３に出力する。
そして、次のステップＳ２０３でＤＢインタフェイス部１０２は、振り分け部１０３からＤＢアクセス結果を受け取るまで待つ。そして、ＤＢインタフェイス部１０２が振り分け部１０３からＤＢアクセス結果を受け取ると、処理はステップＳ２０４に移行する。
ステップＳ２０４でＤＢインタフェイス部１０２は、振り分け部１０３から受け取ったＤＢアクセス結果をＷｅｂアプリケーション１０１に返す。そして、処理はステップＳ２０１に戻る。
以上のようにＤＢインタフェイス部１０２がステップＳ２０１〜Ｓ２０４の処理を繰り返すことにより、Ｗｅｂアプリケーション１０１は、複数のＤＢアクセス要求を発行する場合であっても、各ＤＢアクセス要求に対するＤＢアクセス結果を得ることができる。
続いて、図７のフローチャートを参照して、スクリプト生成部１０４の動作を説明する。
まず、ステップＳ３０１でスクリプト生成部１０４は設定ファイル１０６からＤＢサーバ１２０のアドレスを読み取る。なお、ＤＢサーバ１２０に実際にアクセスするのは、ＤＢサーバ１２０と同じイントラネット１４０内にあるクライアントマシン１１０上のブラウザ１１１である。したがって、スクリプト生成部１０４自体は、ステップＳ３０１で読み取ったアドレスへのアクセスが禁止されていても、全く問題ない。
ステップＳ３０１の読み取りの後、処理はステップＳ３０２に移行する。そして、ステップＳ３０２でスクリプト生成部１０４は、振り分け部１０３からスクリプトの生成指示を受け取るまで待つ。
スクリプト生成部１０４がスクリプトの生成指示を振り分け部１０３から受け取ると、処理はステップＳ３０３に移行する。そして、ステップＳ３０３でスクリプト生成部１０４は、生成指示にしたがって適宜スクリプトを生成する。ステップＳ３０３で生成されるスクリプトは、ＤＢアクセス代行スクリプト１１４の一部または全部である。
また、生成指示の内容に応じて、ＤＢアクセス代行スクリプト１１４は、ステップＳ３０１で読み取ったＤＢサーバ１２０のアドレスを、ステップＳ３０３でスクリプトの中に埋め込むこともある。逆に、生成指示の内容によっては、スクリプト生成部１０４は、ステップＳ３０３ではＤＢサーバ１２０のアドレスを使わないこともある。
そして、次のステップＳ３０４でスクリプト生成部１０４は、ステップＳ３０３で生成したスクリプトを振り分け部１０３に返す。その後、処理はステップＳ３０２に戻る。
以上、図１〜７を参照して第１実施形態と第２実施形態の共通点について説明した。続いて、第１実施形態と第２実施形態それぞれの詳細を説明する。
第１実施形態では、「ｉｆｒａｍｅストリーミング」または「ＨＴＴＰストリーミング」と呼ばれる技術がＣｏｍｅｔコネクションの維持のために使われる。具体的には、ｉｆｒａｍｅ１１３内には、チャンク（chunked）形式のデータが読み込まれる。
つまり、ｉｆｒａｍｅ１１３へのページ読み込みのためのブラウザ１１１からのＨＴＴＰ要求に対して、振り分け部１０３は、Ｔｒａｎｓｆｅｒ−Ｅｎｃｏｄｉｎｇヘッダフィールドに“ｃｈｕｎｋｅｄ”と指定して、ＨＴＴＰ応答を返す。チャンク形式のＨＴＴＰ応答のメッセージボディは、任意の個数のチャンクに分けて送信される。チャンクサイズがゼロと指定されるまで、メッセージボディは完了しないので、コネクションは維持される。
第１実施形態では、上記のようにして維持されるＣｏｍｅｔコネクション（換言すればＨＴＴＰコネクション）上で、振り分け部１０３がＤＢアクセス要求をブラウザ１１１に送信する。以下ではより具体的に第１実施形態について説明する。
図８は、ＵＭＬ（Unified Modeling Language）で表した、第１実施形態の一動作例に関するシーケンス図である。また、図９は、第１実施形態でブラウザ１１１に送信されるソースコードの例を示す図である。
図８のステップＳ４０１でブラウザ１１１は、Ｗｅｂサーバ１００に対する初回の要求を送信する。
以下では説明の便宜上、Ｗｅｂアプリケーション１０１のトップページのＵＲＩが、“ｈｔｔｐ：／／ｗｗｗ．ｆｏｏ．ｃｏｍ／”であるとする。ユーザは、Ｗｅｂアプリケーション１０１を利用するために、“ｈｔｔｐ：／／ｗｗｗ．ｆｏｏ．ｃｏｍ／”というＵＲＩにアクセスするよう、クライアントマシン１１０の入力装置を操作する。この例では、ステップＳ４０１でブラウザ１１１から送信される要求は、ＵＲＩとして“ｈｔｔｐ：／／ｗｗｗ．ｆｏｏ．ｃｏｍ／”が指定されたＨＴＴＰ要求である。
Ｗｅｂサーバ１００においては、振り分け部１０３が、ステップＳ４０１の要求を受信する。そして、ステップＳ４０２で振り分け部１０３は、新たなセッションを生成し、ｉｆｒａｍｅ１１２とｉｆｒａｍｅ１１３を要素として指定するページを返す。
なお、以下では説明の便宜上、ｉｆｒａｍｅ１１２とｉｆｒａｍｅ１１３を要素として含むページを「親ページ」ともいう。また、ｉｆｒａｍｅ１１２とｉｆｒａｍｅ１１３内にそれぞれ読み込まれるページを「子ページ」ともいう。
図９には、親ページと子ページのソースコードの具体例が示されている。上記のステップＳ４０２で返される親ページは、例えば図９の親ページ３００である。親ページ３００は、＜ｉｆｒａｍｅ＞ブロック３０１と＜ｉｆｒａｍｅ＞ブロック３０２を含む。
図９の＜ｉｆｒａｍｅ＞ブロック３０１は、ブラウザ１１１に、ｉｆｒａｍｅ１１２の中にＷｅｂアプリケーション１０１のページを表示させるためのＨＴＭＬソースコードの例である。また、＜ｉｆｒａｍｅ＞ブロック３０１は、ｉｆｒａｍｅ１１２の幅と高さがそれぞれ４００ピクセルと６００ピクセルであること、および、ｉｆｒａｍｅ１１２に読み込む対象のソースの相対ＵＲＩが“／”であることを示している。
他方、＜ｉｆｒａｍｅ＞ブロック３０２は、図１に関して説明した「特定のパス」をｉｆｒａｍｅ１１３のソースとして指定するＨＴＭＬソースコードである。換言すれば、＜ｉｆｒａｍｅ＞ブロック３０２は、図１に関して説明した「特定要求」をブラウザ１１１に行わせるためのＨＴＭＬソースコードである。
なお、図９の例では、＜ｉｆｒａｍｅ＞ブロック３０２において“ｓｒｃ”属性の値が相対パス形式で“／＿ｒｅｓｅｒｖｅｄＦｏｒＣｏｍｅｔ”と指定されている。よって、Ｗｅｂアプリケーション１０１のトップページのＵＲＩが“ｈｔｔｐ：／／ｗｗｗ．ｆｏｏ．ｃｏｍ／”だとすると、特定のパスへアクセスするためのＵＲＩは、“ｈｔｔｐ：／／ｗｗｗ．ｆｏｏ．ｃｏｍ／＿ｒｅｓｅｒｖｅｄＦｏｒＣｏｍｅｔ”である。
また、＜ｉｆｒａｍｅ＞ブロック３０２は、ｉｆｒａｍｅ１１３の幅と高さがいずれも１ピクセルであることを示している。したがって、ブラウザ１１１のユーザは、ブラウザ１１１の画面を見ても、ｉｆｒａｍｅ１１３の存在を視認することができない。ユーザは、単にＷｅｂアプリケーション１０１のページだけがブラウザ１１１に表示されているかのように認識するであろう。
このように、ｉｆｒａｍｅ１１３を実質的に不可視に設定することにより、ユーザの利便性を損なうことなく、イントラネット１４０内のＤＢ１２１の利用が可能となる。つまり、ｉｆｒａｍｅ１１３を実質的に不可視に設定することにより、ユーザに「Ｗｅｂアプリケーション１０１がどこのＤＢのデータを使うのか」ということを意識させない、透過的なサービスが実現される。
なお、ｉｆｒａｍｅ１１３を実質的に不可視にするためには、＜ｉｆｒａｍｅ＞ブロック３０２に例示されるように、幅と高さを微小な値（例えば１ピクセルなど）に設定してもよく、“ｔｙｐｅ”属性の値を“ｈｉｄｄｅｎ”と指定してもよい。
ここで、図８の説明に戻る。ステップＳ４０２で親ページ３００を受信したブラウザ１１１は、親ページ３００のソースコードから、「親ページ３００が２つのｉｆｒａｍｅを含む」ということを認識する。
なお、図９の親ページ３００のようなＨＴＭＬソースコードを読み込んだブラウザ１１１が、ｉｆｒａｍｅ１１２とｉｆｒａｍｅ１１３にページを読み込む順序は任意であり、決まっていない。しかし、ここでは説明の便宜上、先にｉｆｒａｍｅ１１３へのページ読み込みが発生するものと仮定する。
図９には、説明の簡単化のため、親ページ３００のような単純なＨＴＭＬソースコードを例示したが、より複雑なコードを利用することにより、ｉｆｒａｍｅ１１２とｉｆｒａｍｅ１１３へのページ読み込みの順序を制御することが可能である。したがって、「先にｉｆｒａｍｅ１１３の読み込みが発生する」という上記の仮定を設けても、第１実施形態は限定されない。
例えば、ｉｆｒａｍｅ１１２のソースとして制御用のダミーページのＵＲＩを指定するように、＜ｉｆｒａｍｅ＞ブロック３０１が変形されてもよい。そして、ｉｆｒａｍｅ１１３の読み込みが完了したときにｉｆｒａｍｅ１１２内のダミーページから“ｈｔｔｐ：／／ｗｗｗ．ｆｏｏ．ｃｏｍ／”へのリダイレクションを行うための、“ｏｎＬｏａｄ”属性を用いたスクリプトが、ダミーページに含まれていてもよい。すると、上記の仮定が成立する。
また、ｉｆｒａｍｅ１１２のソースとしてダミーページのＵＲＩを指定するように上記のごとく変形された＜ｉｆｒａｍｅ＞ブロックも、図９に示した単純な＜ｉｆｒａｍｅ＞ブロック３０１も、以下の点では同じである。すなわち、どちらの＜ｉｆｒａｍｅ＞ブロックも、最終的にはブラウザ１１１に、ｉｆｒａｍｅ１１２内にＷｅｂアプリケーション１０１のページを表示させるためのコードである点では共通である。
いずれにしろ、図８のステップＳ４０３ではｉｆｒａｍｅ１１３が生成される。そして、ステップＳ４０４でブラウザ１１１は、＜ｉｆｒａｍｅ＞ブロック３０２に指定されたＵＲＩに対するＨＴＴＰ要求を、Ｗｅｂサーバ１００に送信する。すなわち、ブラウザ１１１は、Ｃｏｍｅｔコネクションを維持するためのページをステップＳ４０４で要求する。ステップＳ４０４におけるＨＴＴＰ要求は、上記「特定要求」の具体例である。
振り分け部１０３は、特定要求の受信にともない、ブラウザ１１１とＷｅｂサーバ１００との間のコネクションを確立する。そして、振り分け部１０３はステップＳ４０５で、ステップＳ４０２で生成したセッションと、確立したコネクションとを対応づける。具体的には、振り分け部１０３は、ステップＳ４０２で生成したセッションのセッションＩＤと、ステップＳ４０４での要求の受信にともなって確立したコネクションを識別するコネクションＩＤとを対応づけるエントリを、対応表１０５に追加する。
そして、ステップＳ４０６で振り分け部１０３は、スクリプト生成部１０４にスクリプトの生成を指示する。すると、スクリプト生成部１０４は、スクリプトを生成し、生成したスクリプトをステップＳ４０７で振り分け部１０３に出力する。
そして、ステップＳ４０８で振り分け部１０３は、スクリプト生成部１０４から取得したスクリプトを含むページをブラウザ１１１に返す。なお、上記のとおり、ステップＳ４０８のＨＴＴＰ応答のメッセージボディはチャンク形式である。そのため、ステップＳ４０８の送信後も、コネクションは維持される。
ここで、再び図９を参照し、ｉｆｒａｍｅ１１３に読み込まれる子ページの例について説明する。
図９の子ページ４００は、ステップＳ４０８で返されるチャンク４０１を含む。図９の例では、チャンク４０１は、＜ｈｔｍｌ＞要素の開始タグ、＜ｈｅａｄ＞要素、および＜ｂｏｄｙ＞要素の開始タグを含む。そして、＜ｈｅａｄ＞要素は＜ｓｃｒｉｐｔ＞ブロックを含み、＜ｓｃｒｉｐｔ＞ブロックは、アドレス代入文４０２と関数定義４０３を含む。ステップＳ４０６の生成指示にしたがってスクリプト生成部１０４が生成するスクリプトとは、具体的には、例えばチャンク４０１内の＜ｓｃｒｉｐｔ＞ブロックである。
また、アドレス代入文４０２は、具体的には、変数ｄｂＡｄｄｒに、図２の設定ファイル１０６ａに設定されているＤＢサーバ１２０のアドレスを代入する文（ステートメント）である。そして、関数定義４０３は、図１に関して説明した「代行処理」をブラウザ１１１に行わせるための関数ｅｘｅｃｕｔｅ１（）の定義である。
なお、図９ではアドレス代入文４０２が代行処理の関数定義４０３の外にあり、変数ｄｂＡｄｄｒがグローバル変数として定義されている。しかし、変数ｄｂＡｄｄｒは、関数ｅｘｅｃｕｔｅ１（）のローカル変数として、関数定義４０３の中で定義されてもよい。
また、以下では説明の便宜上、ＤＢ１２１がリレーショナルＤＢであるとする。したがって、ＤＢアクセス要求はＳＱＬ文により表される。そのため、関数ｅｘｅｃｕｔｅ１（）は、ＤＢアクセス要求を示すＳＱＬ文を引数ｓｑｌとしてとる。
図９の例から理解されるように、図８のステップＳ４０８でブラウザ１１１が子ページ４００のチャンク４０１をｉｆｒａｍｅ１１３内に読み込んだ時点では、副作用は生じない。つまり、ブラウザ１１１は、まだＤＢサーバ１２０にアクセスしない。
さて、続いてステップＳ４０９でｉｆｒａｍｅ１１２が生成される。そして、ステップＳ４１０ではｉｆｒａｍｅ１１２へのページ読み込みが発生する。すなわち、ブラウザ１１１は、図９の＜ｉｆｒａｍｅ＞ブロック３０１に指定されたＵＲＩに対するＨＴＴＰ要求を、Ｗｅｂサーバ１００に送信する。
なお、図８の例は、Ｗｅｂアプリケーション１０１のトップページが静的ページの場合の例である。したがって、ステップＳ４１０の要求は静的ページの要求である。
ステップＳ４１１では、ブラウザ１１１からの要求を受信した振り分け部１０３が、「受信した要求は、Ｗｅｂアプリケーション１０１の静的なページへのアクセス要求である」と判断する。そして、振り分け部１０３は、ステップＳ４１２で、受信した要求をＷｅｂアプリケーション１０１に出力する。すなわち、振り分け部１０３はＷｅｂアプリケーション１０１に、ブラウザ１１１からの要求に対する処理を委譲する。
すると、次のステップＳ４１３でＷｅｂアプリケーション１０１は、要求された静的なページをブラウザ１１１に返す。そして、ブラウザ１１１は返された静的なページをｉｆｒａｍｅ１１２の中に表示する。
また、以上のようにして表示された静的なページは、Ｗｅｂアプリケーション１０１がＤＢ１２１のデータを用いて動的に生成するページへのリンクを含んでもよい。あるいは、静的なページは、次に動的なページを表示するための入力フォームを含んでもよい。
図９の例は、表示された静的なページに対してユーザが何らかの操作（例えば、リンクのクリック、あるいは入力フォームへの入力など）を行うことで、次に動的なページが要求される場合の例である。
具体的には、ユーザの操作にともなって、ステップＳ４１４でブラウザ１１１は、ｉｆｒａｍｅ１１２に読み込む対象の動的なページに対するＨＴＴＰ要求を、Ｗｅｂサーバ１００に送信する。
すると、ステップＳ４１５では、ブラウザ１１１からの要求を受信した振り分け部１０３が、「受信した要求は、Ｗｅｂアプリケーション１０１の動的なページへのアクセス要求である」と判断する。そして、振り分け部１０３は、ステップＳ４１６で、受信した要求をＷｅｂアプリケーション１０１に出力する。すなわち、振り分け部１０３はＷｅｂアプリケーション１０１に、ブラウザ１１１からの要求に対する処理を委譲する。
すると、Ｗｅｂアプリケーション１０１は、要求された動的なページを生成する処理を行う。具体的には、Ｗｅｂアプリケーション１０１は、ページを生成するために用いるデータをＤＢ１２１から取得するため、ステップＳ４１７でＤＢインタフェイス部１０２に対してＤＢアクセス要求を出力する。
すると、ステップＳ４１８でＤＢインタフェイス部１０２は、Ｗｅｂアプリケーション１０１から受け取ったＤＢアクセス要求を振り分け部１０３に出力する。
そして、ステップＳ４１９で振り分け部１０３は、ＤＢインタフェイス部１０２から受け取ったＤＢアクセス要求に対応するコネクションを照会する。ステップＳ４１９の詳細は図１０とともに後述するが、振り分け部１０３は、対応表１０５を参照することで、ステップＳ４１８のＤＢアクセス要求に対応するＣｏｍｅｔコネクションを特定することができる。なお、図８の例では、ステップＳ４０８でのチャンク形式でのＨＴＴＰ応答により維持され続けているＣｏｍｅｔコネクションが、ステップＳ４１９で特定される。
また、振り分け部１０３はステップＳ４２０で、ステップＳ４１８で受け取ったＤＢアクセス要求に応じたスクリプトを生成するようにスクリプト生成部１０４に指示する。すると、スクリプト生成部１０４は、指示にしたがって、ＤＢアクセス要求を含むスクリプトを生成する。そして、スクリプト生成部１０４は、ステップＳ４２１で、生成したスクリプトを振り分け部１０３に返す。
すると、振り分け部１０３は、次のステップＳ４２２において、ステップＳ４１９で特定したＣｏｍｅｔコネクション上で、ＤＢアクセス要求を含むスクリプトをブラウザ１１１に送信する。
上記のとおり、ｉｆｒａｍｅ１１３に読み込まれる対象のページは、チャンク形式で送信される。そして、ステップＳ４０８で最初のチャンクが送られた後も、まだＨＴＴＰ応答が完了していないので、コネクションは維持されている。したがって、ステップＳ４２２では、維持されているコネクション上で、次のチャンクが送られる。そして、送信される当該チャンクの中には、ＤＢアクセス要求が埋め込まれる。
ここで再び図９を参照すると、ステップＳ４２２で送信されるチャンクは、具体的には例えば、子ページ４００における＜ｓｃｒｉｐｔ＞ブロック４０４である。＜ｓｃｒｉｐｔ＞ブロック４０４は、具体的には、ステップＳ４２０での指示にしたがってスクリプト生成部１０４により生成され、ステップＳ４２２で送信され、ｉｆｒａｍｅ１１３に読み込まれる。
図９の＜ｓｃｒｉｐｔ＞ブロック４０４は、ステップＳ４０８で送信されたチャンク４０１内で定義された関数ｅｘｅｃｕｔｅ１（）の呼び出しステートメントを含む。そして、＜ｓｃｒｉｐｔ＞ブロック４０４では、関数ｅｘｅｃｕｔｅ１（）に引数として、“ＳＥＬＥＣＴ ＊ ＦＲＯＭ ｐｕｒｃｈａｓｅＴｂｌ ＷＨＥＲＥ ｐｕｒｃｈａｓｅＮｏ＝１２３４５；”というＳＱＬ文が指定されている。
図８のステップＳ４２２で送信されるＤＢアクセス要求は、具体的には、上記のように関数呼び出しステートメントの引数として与えられるＳＱＬ文により表される。また、＜ｓｃｒｉｐｔ＞ブロック４０４の関数呼び出しステートメントは、ｉｆｒａｍｅ１１３に読み込まれ次第、ブラウザ１１１により実行される。すなわち、＜ｓｃｒｉｐｔ＞ブロック４０４は、図１に関して説明した「ＤＢアクセス要求を含む実行命令スクリプト」の具体例である。
そして、ステップＳ４２３でブラウザ１１１は、関数ｅｘｅｃｕｔｅ１（）の定義にしたがって、ＤＢサーバ１２０にＤＢアクセス要求を送信する。具体的には、ブラウザ１１１は、レベル２のＸＨＲオブジェクト（図８では簡略化のため単に「ＸＨＲ２」と表記）を新たに生成し、生成したＸＨＲオブジェクトを用いてＤＢサーバ１２０にＤＢアクセス要求を送信する。
なお、ＸＨＲオブジェクトを用いたブラウザ１１１からＤＢサーバ１２０へのＨＴＴＰ要求は、ＤＢサーバ１２０のインタフェイスに応じて、ＧＥＴメソッドでもよいしＰＯＳＴメソッドでもよい。ＧＥＴメソッドが使われる場合は、ＤＢアクセス要求を表すＳＱＬ文をクエリ・ストリングとして含むＵＲＩが、ＸＨＲオブジェクトに対するｏｐｅｎ（）メソッドの引数として与えられる。また、ＰＯＳＴメソッドが使われる場合は、ＤＢアクセス要求を表すＳＱＬ文が、ＸＨＲオブジェクトに対するｓｅｎｄ（）メソッドの引数として与えられる。
いずれにしろ、ＤＢアクセス要求を受信したＤＢサーバ１２０は、ＤＢアクセス要求にしたがってＤＢ１２１にアクセスする。
例えば、図９の＜ｓｃｒｉｐｔ＞ブロック４０４がステップＳ４２２で送信された場合のＤＢアクセス要求は、具体的にはＤＢ１２１内の“ｐｕｒｃｈａｓｅＴｂｌ”という名前のテーブルに対する参照要求である。よって、この場合、ＤＢサーバ１２０は、要求されたデータをＤＢ１２１から抽出する。
そして、ステップＳ４２４でＤＢサーバ１２０は、ＤＢアクセス要求に応じたＤＢアクセス結果を、ＸＨＲオブジェクトによるＨＴＴＰ要求に対するＨＴＴＰ応答として、ブラウザ１１１に返す。
すると、ＤＢアクセス結果を受信したブラウザ１１１は、ステップＳ４２５で、ＤＢアクセス結果をＷｅｂサーバ１００に送信する。ステップＳ４２５でのＤＢアクセス結果の送信は、例えば、以下の（Ａ１）〜（Ａ３）のような一連のステップにより実現されてもよい。換言すれば、関数定義４０３は（Ａ１）〜（Ａ３）のステップの定義を含んでもよい。
（Ａ１）新規ＸＨＲオブジェクトを生成するステップ。
（Ａ２）ＨＴＴＰのＰＯＳＴメソッドを引数として指定するとともに、Ｗｅｂサーバ１００の特定のパスを含むＵＲＩも引数として指定したｏｐｅｎ（）メソッドを、（Ａ１）で生成した新規ＸＨＲオブジェクトに対して適用するステップ。
（Ａ３）ＪＳＯＮ、ＣＳＶ、ＸＭＬなどの適宜の形式でフォーマットされたＤＢアクセス結果を引数として指定したｓｅｎｄ（）メソッドを、（Ａ１）で生成した新規ＸＨＲオブジェクトに適用するステップ。
さて、以上のようにしてステップＳ４２５で送信されたＤＢアクセス結果を受信した振り分け部１０３は、次のステップＳ４２６において、受信したＤＢアクセス結果をＤＢインタフェイス部１０２に出力する。
すると、ステップＳ４２７でＤＢインタフェイス部１０２は、振り分け部１０３から取得したＤＢアクセス結果をＷｅｂアプリケーション１０１に出力する。そして、ステップＳ４２８でＷｅｂアプリケーション１０１は、ＤＢインタフェイス部１０２から取得したＤＢアクセス結果を用いて動的にページを生成し、生成した動的なページを、ステップＳ４１４のＨＴＴＰ要求に対するＨＴＴＰ応答としてブラウザ１１１に返す。すると、ブラウザ１１１は、動的ページをｉｆｒａｍｅ１１２の中に表示する。
なお、図８の例は様々な動作例のうちの一つに過ぎない。例えば、ステップＳ４２８で動的ページがブラウザ１１１に返された後、再び別の動的なページが要求されてもよい。複数の動的なページが次々に要求される場合は、ステップＳ４１４〜Ｓ４２８の一連の処理が繰り返され、ｉｆｒａｍｅ１１２の中の画面が遷移する。例えば、図９の＜ｓｃｒｉｐｔ＞ブロック４０５が、２回目の動的なページの要求に応じて、ステップＳ４２２と同様にしてブラウザ１１１に送信され、ｉｆｒａｍｅ１１３に読み込まれてもよい。
あるいは、１つのページの生成が、複数のＤＢアクセス要求をともなっていてもよい。その場合、ステップＳ４１４〜Ｓ４１６と同様の一連の処理が１回行われた後、ステップＳ４１７〜Ｓ４２７の一連の処理がＤＢアクセス要求の数だけ繰り返し行われる。その後、ステップＳ４２８と同様にしてＷｅｂアプリケーション１０１がブラウザ１１１にページを返す。
また、Ｗｅｂアプリケーション１０１のトップページは、必ずしも静的なページでなくてもよい。トップページが動的なページの場合であっても、ｉｆｒａｍｅ１１２内へのページ読み込みよりも先に、ｉｆｒａｍｅ１１３へのステップＳ４０８でのチャンク４０１の読み込みが行われていれば、問題は生じない。そして、上記のとおり、＜ｉｆｒａｍｅ＞ブロック３０１を適宜修正するとともにダミーページを用いることにより、「ｉｆｒａｍｅ１１３へのステップＳ４０８でのチャンク４０１の読み込みが先に行われる」ということを保証することができる。
また、図８〜９では説明の便宜上、ＤＢアクセス要求の具体例として、ＤＢ１２１への参照要求（すなわちＳＥＬＥＣＴ文で表される要求）を例示した。しかしながら、ＤＢアクセス要求が、ＤＢ１２１へのデータの追加、ＤＢ１２１内の既存のデータの更新、またはＤＢ１２１からのデータの削除を求める要求であってもよい。また、ＤＢアクセス要求の種類に応じて、ブラウザ１１１がステップＳ４１４でＷｅｂサーバ１００に送信するＨＴＴＰ要求のメソッドも、必ずしもＧＥＴメソッドでなくてもよい。ＤＢアクセス要求の種類が何であれ、ステップＳ４１４〜Ｓ４２８と同様にして、ＤＢアクセスはブラウザ１１１によって代行される。
ところで、図５〜７を参照して前述した処理を、図８および図９と対応づけてより詳細に説明すれば、以下のとおりである。
図５に示すように、ブラウザ１１１は、ｉｆｒａｍｅ１１３に読み込んだＤＢアクセス代行スクリプト１１４にしたがって動作する。ＤＢアクセス代行スクリプト１１４は、図９の例では、具体的には、アドレス代入文４０２、代行処理の関数定義４０３、＜ｓｃｒｉｐｔ＞ブロック４０４、および＜ｓｃｒｉｐｔ＞ブロック４０５を含む。
ブラウザ１１１は、図５のステップＳ１０１に示すように、Ｗｅｂサーバ１００からＤＢアクセス要求を受信するまで待つ。図８の例では、ブラウザ１１１は、ステップＳ４０８でチャンク４０１をｉｆｒａｍｅ１１３に読み込んだ後、ステップＳ４２２でのＤＢアクセス要求の受信まで待つ。
そして、図５のステップＳ１０２は、図８のステップＳ４２３に対応する。また、図５のステップＳ１０３に示すように、ブラウザ１１１は、ＤＢサーバ１２０からのＤＢアクセス結果を受信するまで待つ。図８の例では、ブラウザ１１１は、ステップＳ４２４でのＤＢアクセス結果の受信まで待つ。
そして、図５のステップＳ１０４は、図８のステップＳ４２５に対応する。また、図５ではステップＳ１０４からステップＳ１０１へと制御が戻る。この図５のループにより、複数の動的なページが要求される場合、または１つのページが複数のＤＢアクセス要求をともなう場合において、それぞれのＤＢアクセスがブラウザ１１１により代行される。
以上から明らかなとおり、図９の関数定義４０３は、図５のステップＳ１０２〜Ｓ１０４の動作を定義している。また、定義された関数ｅｘｅｃｕｔｅ１（）の中では、図５のステップＳ１０２の処理のために、アドレス代入文４０２により変数ｄｂＡｄｄｒに設定されたＤＢサーバ１２０のアドレスが参照される。そして、図５のステップＳ１０１は、具体的には、＜ｓｃｒｉｐｔ＞ブロック４０４または４０５のような、関数呼び出しステートメントを含むチャンクの受信に対応する。
また、図６のステップＳ２０１に示すように、ＤＢインタフェイス部１０２は、Ｗｅｂアプリケーション１０１からＤＢアクセス要求を受け取るまで待つ。図８の例では、ＤＢインタフェイス部１０２は、ステップＳ４１７まで待つ。
そして、図６のステップＳ２０２は図８のステップＳ４１８に対応する。また、図６のステップＳ２０３に示すように、ＤＢインタフェイス部１０２は、振り分け部１０３からＤＢアクセス結果を受け取るまで待つ。図８の例では、ＤＢインタフェイス部１０２は、ステップＳ４２６まで待つ。
そして、図６のステップＳ２０４は、図８のステップＳ４２７に対応する。また、図６ではステップＳ２０４からステップＳ２０１へと制御が戻る。この図６のループにより、複数の動的なページが要求される場合、または１つのページが複数のＤＢアクセス要求をともなう場合において、それぞれのＤＢアクセスが、ＤＢインタフェイス部１０２と振り分け部１０３を介して、ブラウザ１１１により代行される。
なお、図７のステップＳ３０１は図８には明示されていない。スクリプト生成部１０４は、ステップＳ３０１の実行後、ステップＳ３０２で振り分け部１０３からスクリプトの生成指示を受け取るまで待つ。図８の例では、スクリプト生成部１０４は、ステップＳ４０６まで待つ。
そして、図７のステップＳ３０３でスクリプト生成部１０４が生成するスクリプトの内容は、生成指示に応じて異なる。例えば、図８のステップＳ４０６の生成指示を受け取った場合、スクリプト生成部１０４は、ステップＳ３０１で読み取ったＤＢサーバ１２０のアドレスに基づいてアドレス代入文４０２を生成するとともに、関数定義４０３も生成する。
また、図８のステップＳ４０７は、図７のステップＳ３０４に対応する。そして、図７に示すように、処理はステップＳ３０４からステップＳ３０２に戻る。すると、図８に示すように、スクリプト生成部１０４は、次のスクリプト生成指示を振り分け部１０３からステップＳ４２０で受け取るまで待つ。
ステップＳ４２０での生成指示は、具体的には、関数呼び出しステートメントの生成指示であり、ＤＢアクセス要求を示すＳＱＬ文を関数の引数として指定する指示である。したがって、次に図７のステップＳ３０３でスクリプト生成部１０４が生成するスクリプトは、具体的には図９の＜ｓｃｒｉｐｔ＞ブロック４０４である。そして、次のステップＳ３０４は図８のステップＳ４２１に対応する。
また、図７の処理はステップＳ３０４からステップＳ３０２へと再び戻る。したがって、この図７のループにより、複数の動的なページが要求される場合、または１つのページが複数のＤＢアクセス要求をともなう場合において、それぞれのＤＢアクセス要求に対応する＜ｓｃｒｉｐｔ＞ブロックがスクリプト生成部１０４により生成される。また、この図７のループにより、複数のブラウザからの要求に対応するそれぞれのスクリプトがスクリプト生成部１０４により生成される。
続いて、第１実施形態における振り分け部１０３の動作について、図１０〜１１を参照して詳しく説明する。
図１０は、第１実施形態において振り分け部１０３がＤＢインタフェイス部１０２からのＤＢアクセス要求の受付を契機として行う処理のフローチャートである。例えば、図８のステップＳ４１８でのＤＢアクセス要求の受付を契機として、振り分け部１０３は図１０の処理を開始する。
そして、ステップＳ５０１で振り分け部１０３は、スレッドローカルな変数からセッションＩＤを取得する。詳しくは図１１とともに説明するが、振り分け部１０３は、ブラウザ１１１からのアクセス要求（具体的にはＨＴＴＰ要求）をＷｅｂアプリケーション１０１に委譲する場合、スレッドローカルな変数にセッションＩＤを代入する。そして、ＤＢインタフェイス部１０２から振り分け部１０３がＤＢアクセス要求を受け取るタイミングは、Ｗｅｂアプリケーション１０１への処理の委譲が起きた後である。したがって、振り分け部１０３は、ステップＳ５０１でスレッドローカルな変数からセッションＩＤを取得することができる。
そして、次のステップＳ５０２で振り分け部１０３は、取得したセッションＩＤを検索キーとして用いて対応表１０５を検索し、取得したセッションＩＤに対応するコネクションを特定する。ステップＳ５０２の例は、図８のステップＳ４１９である。
さらに、次のステップＳ５０３で振り分け部１０３は、図１０の処理を開始する契機となったＤＢアクセス要求を含むスクリプトを、スクリプト生成部１０４に生成させる。ステップＳ５０３の例は、図８のステップＳ４２０〜Ｓ４２１である。
例えば、図８のステップＳ４１８で振り分け部１０３が受け取ったＤＢアクセス要求が、図９の＜ｓｃｒｉｐｔ＞ブロック４０４において関数の引数として与えられているＳＱＬ文により表されるとする。この場合、ステップＳ５０３において振り分け部１０３は、ＳＱＬ文をスクリプト生成部１０４に対して指定し、スクリプト生成部１０４に＜ｓｃｒｉｐｔ＞ブロック４０４を生成させる。
なお、ステップＳ５０３の処理はステップＳ５０１〜Ｓ５０２の処理とは独立しているので、ステップＳ５０１〜Ｓ５０２の処理と並行にステップＳ５０３の処理が行われてもよい。あるいは、ステップＳ５０３の処理がステップＳ５０１〜Ｓ５０２の処理よりも先に行われてもよい。
そして、ステップＳ５０１〜Ｓ５０３の実行後、ステップＳ５０４で振り分け部１０３は、ステップＳ５０２で特定したコネクションを介して、ステップＳ５０３で生成されたスクリプトをブラウザ１１１に送信する。ステップＳ５０４の例は、図８においては、ステップＳ４２２である。また、図９の＜ｓｃｒｉｐｔ＞ブロック４０４は、ステップＳ５０４で送信されるスクリプトの一つの例であり、＜ｓｃｒｉｐｔ＞ブロック４０５は、ステップＳ５０４で送信されるスクリプトの他の例である。
スクリプトの送信後、振り分け部１０３は、ステップＳ５０５で、ブラウザ１１１からＤＢアクセス結果を受信するまで待つ。ステップＳ５０５の例は、図８においては、ステップＳ４２２の送信後、ステップＳ４２５の受信までの待機である。
そして、振り分け部１０３がＤＢアクセス結果をブラウザ１１１から受信すると、処理はステップＳ５０６に移行する。すると、ステップＳ５０６で振り分け部１０３は、ブラウザ１１１から受信したＤＢアクセス結果をＤＢインタフェイス部１０２に返す。ステップＳ５０６の具体例は、図８のステップＳ４２６である。
ステップＳ５０６の実行後、図１０の処理も終了する。なお、ブラウザ１１１がＸＨＲを用いてＤＢアクセス結果を振り分け部１０３に通知する場合は、振り分け部１０３は、さらに、ＸＨＲによるＨＴＴＰ要求に対するＨＴＴＰ応答をブラウザ１１１に返してもよい。例えば、振り分け部１０３は、ステータスコードが２００（ＯＫ）でメッセージボディが空のＨＴＴＰ応答を、ブラウザ１１１に返してもよい。
さて、図１１は、第１実施形態において振り分け部１０３がブラウザ１１１からの要求の受信を契機として行う処理のフローチャートである。例えば、図８のステップＳ４０１、Ｓ４０４、Ｓ４１０、Ｓ４１４、Ｓ４２５では、振り分け部１０３がブラウザ１１１からのＨＴＴＰ要求を受信する。そして、振り分け部１０３は、ＨＴＴＰ要求の受信を契機として、図１１の処理を開始する。
なお、ＨＴＴＰ要求を振り分け部１０３が受信すると、ブラウザ１１１とＷｅｂサーバ１００の間のＨＴＴＰコネクションが確立する。したがって、図１１の処理が開始された時点で何らかのコネクションが存在する。
ステップＳ６０１で振り分け部１０３は、セッションがあるか否かを判断する。具体的には、振り分け部１０３は、受信したＨＴＴＰ要求のＣｏｏｋｉｅヘッダを参照することで、セッションがあるか否かを判断してもよい。そして、セッションがなければ処理はステップＳ６０２に移行する。逆に、セッションが既に存在していれば、振り分け部１０３は例えばＣｏｏｋｉｅヘッダからセッションＩＤを認識し、処理はステップＳ６０４に移行する。
ステップＳ６０２で振り分け部１０３は、セッションを新規に作成する。具体的には、振り分け部１０３は、新たなセッションＩＤを発行する。ステップＳ６０２が実行されるのは、例えば、図８のステップＳ４０１の要求の受信を契機として図１１の処理が開始された場合である。
そして、次のステップＳ６０３で振り分け部１０３は、ＨＴＴＰ応答のＳｅｔ−ＣｏｏｋｉｅヘッダにステップＳ６０２で発行したセッションＩＤを設定して、親ページ３００をブラウザ１１１に返す。親ページ３００の＜ｉｆｒａｍｅ＞要素３０１に付けられているｓｒｃ属性を”／”の代わりにＨＴＴＰ要求のリクエストラインにあったパスとしておくことも可能である。ステップＳ６０３の具体例は、図８のステップＳ４０２である。また、ステップＳ６０３の実行後、図１１の処理は終了する。
他方、セッションが既に存在する場合、ステップＳ６０４で振り分け部１０３は、ブラウザ１１１から要求されたＵＲＩが、ＤＢアクセス用の特定のパスを含むＵＲＩであるか否かを判断する。例えば、特定のパスは、先に例示した“／＿ｒｅｓｅｒｖｅｄＦｏｒＣｏｍｅｔ”であってもよい。
そして、ブラウザ１１１から要求されたＵＲＩが、ＤＢアクセス用の特定のパスを含むＵＲＩの場合、処理はステップＳ６０５に移行する。逆に、ブラウザ１１１から要求されたＵＲＩが、ＤＢアクセス用の特定のパスを含まないＵＲＩ（すなわち、Ｗｅｂアプリケーション１０１が使用するＵＲＩ）の場合、処理はステップＳ６０９に移行する。
なお、振り分け部１０３は、図８のステップＳ４０４で要求を受信したときにステップＳ６０４の判断を行う。また、図８のステップＳ４１１とＳ４１５でも、ステップＳ６０４の判断が行われる。さらに、振り分け部１０３は、図８のステップＳ４２５でＤＢアクセス結果をＨＴＴＰ要求の形で受信したときも、ステップＳ６０４の判断を行う。
そして、ブラウザ１１１から要求されたＵＲＩが、ＤＢアクセス用の特定のパスを含むＵＲＩの場合、ステップＳ６０５で振り分け部１０３は、ブラウザ１１１からのＨＴＴＰ要求のメソッドがＧＥＴメソッドであるか、それともＰＯＳＴメソッドであるかを判断する。振り分け部１０３は、受信したＨＴＴＰ要求のリクエストラインを参照することでメソッドを認識することができる。
リクエストラインにＧＥＴメソッドが指定されていた場合、処理はステップＳ６０６に移行する。逆に、リクエストラインにＰＯＳＴメソッドが指定されていた場合、処理はステップＳ６１１に移行する。
例えば、図８のステップＳ４０４の要求は、ＧＥＴメソッドによって特定のパスへのアクセスを求める要求である。よって、ステップＳ４０４の受信を契機として図１１の処理が開始された場合、処理はステップＳ６０６へと進む。
逆に、図８のステップＳ４２５のＤＢアクセス結果の通知のためのＨＴＴＰ要求は、ＰＯＳＴメソッドによって特定のパスへのアクセスを求める要求である。よって、ステップＳ４２５の受信を契機として図１１の処理が開始された場合、処理はステップＳ６１１へと進む。
さて、ステップＳ６０６で振り分け部１０３は、対応表１０５に新規エントリを追加する。そして、振り分け部１０３は、新規エントリのセッションＩＤフィールドに、ステップＳ６０１で認識したセッションＩＤを設定する。
また、ステップＳ６０６が実行されるのは、例えば図８のステップＳ４０４のように、Ｃｏｍｅｔコネクション用にｉｆｒａｍｅ１１３に読み込むための子ページ４００がブラウザ１１１から要求された場合である。そして、ブラウザ１１１からのＨＴＴＰ要求の受信を契機として、図１１の処理の開始時点でＨＴＴＰコネクションは確立済みである。したがって、ステップＳ６０６で振り分け部１０３は、新規エントリのコネクションＩＤフィールドに、確立したコネクションを識別するコネクションＩＤを設定する。
以上のようにしてステップＳ６０６では、セッションＩＤとコネクションＩＤの新たなペアが対応表１０５に登録される。ステップＳ６０６の具体例は図８のステップＳ４０５である。
そして、次のステップＳ６０７で振り分け部１０３は、スクリプト生成部１０４にスクリプトを生成させる。ステップＳ６０７の具体例は、図８のステップＳ４０６〜Ｓ４０７である。つまり、ステップＳ６０７で振り分け部１０３は、アドレス代入文４０２と関数定義４０３を含むスクリプトをスクリプト生成部１０４に生成させる。
そして、次のステップＳ６０８で振り分け部１０３は、生成されたスクリプトを含むページをチャンク形式でブラウザ１１１に返す。ステップＳ６０８の具体例は、図８のステップＳ４０８である。振り分け部１０３がチャンク形式でページを返す（すなわちＨＴＴＰ応答を返す）ことにより、ブラウザ１１１のｉｆｒａｍｅ１１３とＷｅｂサーバ１００との間でコネクションは維持され続ける。ステップＳ６０８の実行後、図１１の処理は終了する。
さて、ブラウザ１１１から要求されたＵＲＩが特定のパスを含まない場合、ステップＳ６０９で振り分け部１０３は、スレッドローカルな変数に、ステップＳ６０１で認識したセッションＩＤを保存する。ここで保存されたセッションＩＤは、前述のとおり、図１０のステップＳ５０１で参照される。
そして、次のステップＳ６１０で振り分け部１０３は、Ｗｅｂアプリケーション１０１に処理を委譲する。具体的には、振り分け部１０３は、ブラウザ１１１から受信したＨＴＴＰ要求をＷｅｂアプリケーション１０１に出力する。そして、振り分け部１０３による図１１の処理は終了する。なお、ステップＳ６０９〜Ｓ６１０の処理は、例えば、図８においては、ステップＳ４１２においても行われ、ステップＳ４１６においても行われる。
他方、ブラウザ１１１から特定のパスへのＰＯＳＴメソッドによるアクセスが要求された場合、振り分け部１０３はステップＳ６１１の処理を行う。なお、ステップＳ６１１の処理が行われるのは、上記のとおり、例えば図８のステップＳ４２５のようにＤＢアクセス結果の通知のためのＨＴＴＰ要求を振り分け部１０３が受信した場合である。よって、ステップＳ６１１で振り分け部１０３は、具体的には、ＤＢアクセス結果の受信を認識する。
すると、図１１の処理フローは終了するが、他方で、振り分け部１０３は、図１０のステップＳ５０５でＤＢアクセス結果の受信を待ってもいるので、図１０において処理がステップＳ５０５からステップＳ５０６へと進む。その結果、振り分け部１０３は、ブラウザ１１１から受信したＤＢアクセス結果をＤＢインタフェイス部１０２へと出力する。
なお、より詳しく説明すると、第１実施形態では、振り分け部１０３のスレッドは、ステップＳ６１０でＷｅｂアプリケーション１０１へ処理を委譲した後、図１１の処理を一旦終了するが、消滅はしない。スレッドが消滅せずに存在を続けることは、図８においては、振り分け部１０３の列に示したアクティベーションの矩形が、ステップＳ４１５からステップＳ４２６まで続いていることにより表現されている。
そして、ステップＳ６１０に相当するステップＳ４１６での委譲を行ったスレッドは、ステップＳ４１８でのＤＢインタフェイス部１０２からのＤＢアクセス要求の受付を契機に図１０の処理を開始し、図１０のステップＳ５０５でＤＢアクセス結果の受信を待つ。また、ステップＳ４２５でのＤＢアクセス結果の受信を契機に、当該スレッドは図１１の処理を開始する。
以上のようにして、ＤＢインタフェイス部１０２からのＤＢアクセス要求を受け付けたスレッド自体が、対応するＤＢアクセス結果をブラウザ１１１から受信する。したがって、振り分け部１０３は、ブラウザ１１１から受信したＤＢアクセス結果がＤＢインタフェイス部１０２からのどのＤＢアクセス要求に対応するのかを認識して、ＤＢインタフェイス部１０２に正しくＤＢアクセス結果を出力することができる。
もちろん、実施形態によっては、ＤＢアクセス要求を識別する要求ＩＤが、ＤＢアクセス要求とＤＢアクセス結果の対応関係の管理のために使われてもよい。つまり、要求ＩＤがＤＢアクセス要求とともにＤＢインタフェイス部１０２から振り分け部１０３に出力されてもよい。そして、関数定義４０３は、引数として、ＳＱＬ文とともに要求ＩＤをとるように変形されてもよい。また、ＤＢアクセス結果は、要求ＩＤとともにブラウザ１１１から振り分け部１０３へ、振り分け部１０３からＤＢインタフェイス部１０２へ、と返されてもよい。
以上のとおり、第１実施形態によれば、ｉｆｒａｍｅ１１３に読み込まれる子ページ６００がチャンク形式で送られる（つまり、ストリーミングのように少しずつ送られる）ことにより、ブラウザ１１１とＷｅｂサーバ１００の間のコネクションが維持され続ける。また、Ｗｅｂアプリケーション１０１によるＤＢアクセス要求がいつ生じても、コネクションが維持され続けているので、振り分け部１０３はすぐにＤＢアクセス要求をブラウザ１１１に中継することができる。
そして、ブラウザ１１１がＤＢアクセス代行スクリプト１１４にしたがってＤＢアクセスを代行し、ＤＢアクセス結果は振り分け部１０３とＤＢインタフェイス部１０２を介して最終的にＷｅｂアプリケーション１０１に出力される。したがって、Ｗｅｂアプリケーション１０１は、直接ＤＢサーバ１２０にアクセスすることが許されなくても、ＤＢアクセス結果を得ることができる。
このように、第１実施形態によれば、インタフェイス・サーバまたは中継サーバなどの付加的な装置がなくても、Ｗｅｂアプリケーション１０１が、ファイアウォール１３０で隔てられたイントラネット１４０内のＤＢ１２１のデータを使って処理を行うことができる。また、Ｗｅｂアプリケーション１０１は、ＤＢ１２１のデータを一時的かつ部分的に使うだけであり、ＤＢ１２１のデータがＷｅｂサーバ１００に不揮発的に長期にわたって保存されるわけではない。したがって、第１実施形態は、ＤＢ１２１に機密情報が含まれる場合にも好適である。
続いて、図１２〜１６を参照して第２実施形態について説明する。第２実施形態では、Ｃｏｍｅｔコネクションの維持のために「ロングポーリング」と呼ばれる技術が使われる。具体的には、ＤＢアクセス代行スクリプト１１４にしたがってブラウザ１１１がＸＨＲオブジェクトを用いて送信するＨＴＴＰ要求に対する応答を、Ｗｅｂサーバ１００が延期することで、応答が返るまでの間、コネクションが維持され続ける。
第２実施形態では、上記のようにして維持されるＣｏｍｅｔコネクション（換言すればＨＴＴＰコネクション）を利用して、振り分け部１０３がＤＢアクセス要求をブラウザ１１１に送信する。以下ではより具体的に第２実施形態について説明する。
図１２は、第２実施形態のＷｅｂサーバ１００の動作を説明する、ＵＭＬで表現されたアクティビティ図である。詳しくは後述するが、第２実施形態では、ｉｆｒａｍｅ１１３内に読み込む対象のデータが、チャンク形式で複数回に分けられて送信されるのではなく、一度に送信される。図１２は、少なくとも親ページがＷｅｂサーバ１００からブラウザ１１１に送信された後のＷｅｂサーバ１００の動作を説明する図である。また、ｉｆｒａｍｅ１１３への子ページの読み込みのための処理は、図１２では省略されている。
初期ノードＳ７０１からのフローは、ブラウザ１１１がｉｆｒａｍｅ１１２内にページを読み込むためにＨＴＴＰ要求を送信し、振り分け部１０３が当該ＨＴＴＰ要求を受信することを契機として始まる。具体的には、ＨＴＴＰ要求を受信した振り分け部１０３は、ステップＳ７０２においてスレッドローカルな変数にセッションＩＤを保存する。
そして、次の決定ノードＳ７０３に示すように、その後の動作には、ＤＢアクセス以外の処理が発生する場合と、ＤＢアクセスの処理が発生する場合と、Ｗｅｂアプリケーション１０１の処理が終了する場合がある。それぞれの場合に対応して、制御は、ステップＳ７０４、Ｓ７０９、Ｓ７１５へと移行する。
もしＤＢアクセス以外の処理が発生すると、ステップＳ７０４で、振り分け部１０３はＷｅｂアプリケーション１０１に処理を委譲し、Ｗｅｂアプリケーション１０１が適宜の処理を行う。例えば、静的または動的なページがブラウザ１１１から要求された場合、ステップＳ７０４でＷｅｂアプリケーション１０１による処理が行われる。そして、制御は、マージノードＳ７０５を経て決定ノードＳ７０３に戻る。
他方で、初期ノードＳ７０６からのフローは、ブラウザ１１１がＤＢアクセス代行スクリプト１１４にしたがって、ＸＨＲオブジェクトを用いてロングポーリング用のＨＴＴＰ要求を送信し、振り分け部１０３が当該ＨＴＴＰ要求を受信することを契機として始まる。ロングポーリング用のＨＴＴＰ要求は、具体的には、メッセージボディにＤＢアクセス要求を含むＨＴＴＰ応答を受信するための要求であり、ｉｆｒａｍｅ１１２へのページ読み込みのためのＨＴＴＰ要求とは非同期に送信される。また、ロングポーリング用のＨＴＴＰ要求に対する応答は、コネクションの維持のために適宜延期される。
具体的には、振り分け部１０３は、ロングポーリング用のＨＴＴＰ要求を受信すると、ステップＳ７０７で、対応表１０５に新規エントリを挿入する。また、振り分け部１０３は、新規エントリのセッションＩＤフィールドに、ブラウザ１１１とＷｅｂサーバ１００の間で確立済みのセッションのセッションＩＤを設定する。そして、振り分け部１０３は、ロングポーリング用のＨＴＴＰ要求の受信によってブラウザ１１１とＷｅｂサーバ１００との間に確立したＨＴＴＰコネクションを識別するコネクションＩＤを、新規エントリのコネクションＩＤフィールドに設定する。
なお、上記のようにロングポーリング用のＨＴＴＰ要求は、ｉｆｒａｍｅ１１２へのページ読み込みのためのＨＴＴＰ要求とは非同期に送信される。また、ｉｆｒａｍｅ１１２に読み込む対象のＷｅｂアプリケーション１０１のページが常にＤＢアクセスをともなうとも限らない。逆に、振り分け部１０３がＤＢインタフェイス部１０２からＤＢアクセス要求を受け取った時点で、「ロングポーリング用のＨＴＴＰ要求が既に受信されており、かつ、まだＨＴＴＰ応答は返されていない」という条件が成立するとも限らない。
そこで、ステップＳ７０７の処理の後は、ジョインノードＳ７０８に示すように、待ち合わせが生じる。待ち合わせの対象は、ステップＳ７０９〜Ｓ７１０のフローである。
具体的には、ステップＳ７０４でのＷｅｂアプリケーション１０１への処理の委譲の結果として、ＤＢアクセスの処理が発生することもある。すると、ステップＳ７０９で、振り分け部１０３は、スレッドローカルな変数からセッションＩＤを取得する。そして、次のステップＳ７１０で振り分け部１０３は、取得したセッションＩＤに対応するコネクションを対応表１０５から探す。
ステップＳ７１０での検索の結果、コネクションが見つかれば、続いてステップＳ７１１の処理が行われる。
しかし、ステップＳ７１０での検索の結果、コネクションが見つからない場合もある。対応するコネクションが見つからない場合は、スレッドローカルな変数に保存されているセッションＩＤを持つエントリがステップＳ７０７で対応表１０５に追加されるまで、ステップＳ７１１の処理は行われない。つまり、待ち合わせが生じる。
そして、ステップＳ７１１では、振り分け部１０３が、ステップＳ７０９で取得したセッションＩＤと、当該セッションＩＤに対応づけられたコネクションＩＤとのペアを、対応表１０５から削除する。より具体的には、振り分け部１０３は、当該コネクションＩＤを記憶してから、セッションＩＤとコネクションＩＤのペアを削除する。
さらに、次のステップＳ７１２では、ＸＨＲオブジェクトを用いたＨＴＴＰ要求に対するＨＴＴＰ応答を経由してのＤＢアクセスが行われる。
具体的には、振り分け部１０３が、ステップＳ７１１で記憶したコネクションＩＤで特定されるコネクションを利用して、ＤＢアクセス要求をブラウザ１１１に送信する。つまり、振り分け部１０３は、ＸＨＲオブジェクトを用いてロングポーリング用にブラウザ１１１から以前送信されたＨＴＴＰ要求に対するＨＴＴＰ応答として、ＤＢインタフェイス部１０２から受け取ったＤＢアクセス要求を、ブラウザ１１１に送信する。
そして、ブラウザ１１１は、ＤＢアクセス要求を受信すると、ＤＢアクセス代行スクリプト１１４にしたがって、ＤＢアクセスを代行し、ＤＢアクセス結果をＷｅｂサーバ１００に返信する。ＤＢアクセス結果は、具体的には、ＸＨＲオブジェクトを用いたＨＴＴＰ要求（具体的にはＰＯＳＴメソッドのＨＴＴＰ要求）のメッセージボディに含められて、Ｗｅｂサーバ１００に送信される。
すると、振り分け部１０３が、以上のようにしてブラウザ１１１からＸＨＲオブジェクトを用いて送信されたＤＢアクセス結果を受信し、ＤＢインタフェイス部１０２にＤＢアクセス結果を出力する。また、ＤＢインタフェイス部１０２は、ＤＢアクセス結果をＷｅｂアプリケーション１０１に出力する。
また、ＤＢアクセス結果の受信によりステップＳ７１２のガード条件が満たされるので、ジョインノードＳ７０８で合流した二つのフローは、フォークノードＳ７１３に示すように再び分かれる。すなわち、初期ノードＳ７０６からのフローは最終ノードＳ７１４に至り、ステップＳ７０９〜Ｓ７１０からのフローは、マージノードＳ７０５を経て決定ノードＳ７０３に戻る。
なお、ブラウザ１１１は、ＤＢアクセス代行スクリプト１１４にしたがって、再びロングポーリング用の新たなＨＴＴＰ要求をＷｅｂサーバ１００に送信する。よって、Ｗｅｂサーバ１００では再び初期ノードＳ７０６からのフローが始まる。
他方で、上記のようにしてステップＳ７１２でＤＢインタフェイス部１０２からＤＢアクセス結果を受け取ったＷｅｂアプリケーション１０１は、必要に応じてＤＢアクセス結果を用いて動的にページを生成する。そして、Ｗｅｂアプリケーション１０１によるページ生成の処理が終了すると、ステップＳ７１５のとおり、Ｗｅｂサーバ１００からブラウザ１１１にＨＴＴＰ応答が返されて、フローは最終ノードＳ７１６に至る。
続いて、第２実施形態の一動作例を、図１３のシーケンス図を参照して説明する。
ステップＳ８０１でブラウザ１１１は、Ｗｅｂサーバ１００に対する初回の要求を送信する。すると、振り分け部１０３がステップＳ８０１の要求を受信する。そして、ステップＳ８０２で振り分け部１０３は、新たなセッションを生成し、ｉｆｒａｍｅ１１２とｉｆｒａｍｅ１１３を要素として指定する親ページを返す。
ステップＳ８０１〜Ｓ８０２は、図８のステップＳ４０１〜Ｓ４０２とほぼ同じである。ただし、第１実施形態では、Ｗｅｂサーバ１００がブラウザ１１１にＤＢアクセスを代行させるために予約される特殊なパスが１つのみだが、第２実施形態では次の（Ｂ１）〜（Ｂ３）の３つのパスが予約される。
（Ｂ１）ｉｆｒａｍｅ１１３用のパス（以下では説明の便宜上、“／＿ｒｅｓｅｒｖｅｄＦｏｒＩｆｒａｍｅ”とする）。
（Ｂ２）ＸＨＲオブジェクトを用いたロングポーリング用のＨＴＴＰ要求を受け付けるためのパス（以下では説明の便宜上、“／＿ｒｅｓｅｒｖｅｄＦｏｒＬＰ”とする）。
（Ｂ３）ブラウザ１１１からＤＢアクセス結果の通知を受信するためのパス（以下では説明の便宜上、“／＿ｒｅｓｅｒｖｅｄＦｏｒＤＢ”とする）。
なお、以上の３つのパスのうち、ロングポーリング用のＨＴＴＰ要求を受け付けるための（Ｂ２）のパスが、図１に関して説明した「特定要求」により要求される「特定のパス」である。
ここで、図１４を参照してステップＳ８０２で送信される親ページの例について説明する。図１４は、第２実施形態でブラウザ１１１に送信されるソースコードの例を示す図である。
ステップＳ８０２では、例えば図１４の親ページ５００が返される。親ページ５００は、＜ｉｆｒａｍｅ＞ブロック５０１と＜ｉｆｒａｍｅ＞ブロック５０２を含む。
図１４の＜ｉｆｒａｍｅ＞ブロック５０１は、ブラウザ１１１に、ｉｆｒａｍｅ１１２の中にＷｅｂアプリケーション１０１のページを表示させるためのＨＴＭＬソースコードの例である。また、＜ｉｆｒａｍｅ＞ブロック５０１は、ｉｆｒａｍｅ１１２の幅と高さがそれぞれ４００ピクセルと６００ピクセルであること、および、ｉｆｒａｍｅ１１２に読み込む対象のソースの相対ＵＲＩが“／”であることを示している。
他方、＜ｉｆｒａｍｅ＞ブロック５０２は、（Ｂ１）のｉｆｒａｍｅ１１３用のパスをソースとして指定するＨＴＭＬソースコードである。換言すれば、＜ｉｆｒａｍｅ＞ブロック５０２は、ブラウザ１１１を（Ｂ２）の「特定のパス」にアクセスさせるためのコードを、クライアントマシン１１０（具体的にはブラウザ１１１）に取得させるためのコードである。なお、「ブラウザ１１１を（Ｂ２）の『特定のパス』にアクセスさせるためのコード」とは、具体的には、ｉｆｒａｍｅ１１３に読み込まれる子ページ６００のコードである。子ページ６００の詳細については後述する。
なお、＜ｉｆｒａｍｅ＞ブロック５０２によれば、第１実施形態と同様に、ユーザの利便性の観点から、ｉｆｒａｍｅ１１３が実質的に不可視に設定される。
ここで、図１３の説明に戻る。ステップＳ８０２で親ページ５００を受信したブラウザ１１１は、親ページ５００が２つのｉｆｒａｍｅ１１２とｉｆｒａｍｅ１１３を含むことを認識する。
なお、第１実施形態と同様に、ｉｆｒａｍｅ１１２とｉｆｒａｍｅ１１３の読み込み順を制御するために＜ｉｆｒａｍｅ＞ブロック５０１が変形されてもよい。しかし、第２実施形態では、図１２のジョインノードＳ７０８に示すような待ち合わせが行われるので、読み込み順の制御は不要である。
図１４の動作例は、たまたまｉｆｒａｍｅ１１３へのページ読み込みが先に生じた場合の例である。この場合、ステップＳ８０３でｉｆｒａｍｅ１１３が生成され、ステップＳ８０４でブラウザ１１１は、＜ｉｆｒａｍｅ＞ブロック５０２に指定されたＵＲＩに対するＨＴＴＰ要求を、Ｗｅｂサーバ１００に送信する。
すなわち、ステップＳ８０４でブラウザ１１１は、Ｃｏｍｅｔ用のページを要求する。ただし、ステップＳ８０４の要求自体は、Ｃｏｍｅｔコネクションを維持するための「特定要求」ではなく、特定要求の送信をブラウザ１１１に指示するＤＢアクセス代行スクリプト１１４を含むページに対する要求である。ＤＢアクセス代行スクリプト１１４にしたがってブラウザ１１１が特定要求を送信することでＣｏｍｅｔコネクションが維持されるので、図１４のステップＳ８０４には「Ｃｏｍｅｔ用ページ要求」と表記してある。
さて、ステップＳ８０４で要求を受信した振り分け部１０３は、ステップＳ８０５でスクリプト生成部１０４にスクリプトの生成を指示する。すると、スクリプト生成部１０４は、スクリプトを生成し、生成したスクリプトをステップＳ８０６で振り分け部１０３に出力する。
そして、ステップＳ８０７で振り分け部１０３は、スクリプト生成部１０４から取得したスクリプトを含むＣｏｍｅｔ用のページをブラウザ１１１に返す。なお、ステップＳ８０７では、ｉｆｒａｍｅ１１３内に読み込むためのページ全体が返される。つまり、チャンク形式は使われない。
ここで、再び図１４を参照し、ｉｆｒａｍｅ１１３に読み込まれる子ページの例について説明する。
図１４の子ページ６００は、＜ｈｅａｄ＞要素と＜ｂｏｄｙ＞要素を含む。そして、＜ｈｅａｄ＞要素は＜ｓｃｒｉｐｔ＞ブロックを含み、＜ｓｃｒｉｐｔ＞ブロックは、アドレス代入文６０１と、図１に関して説明した「代行処理」の関数定義６０２と、メインルーチンの関数定義６０３を含む。
また、＜ｂｏｄｙ＞要素も＜ｓｃｒｉｐｔ＞ブロック６０４を含む。そして、＜ｓｃｒｉｐｔ＞ブロック６０４は、具体的には、関数定義６０３で定義された関数の呼び出しステートメントを含む。
なお、関数ｍａｉｎ（）の呼び出しステートメントは、＜ｈｅａｄ＞要素内の＜ｓｃｒｉｐｔ＞ブロックにあってもよい。または、アドレス代入文６０１、関数定義６０２、および関数定義６０３が、＜ｂｏｄｙ＞要素内の＜ｓｃｒｉｐｔ＞ブロック６０４の中の、関数ｍａｉｎ（）の呼び出しステートメントの前にあってもよい。
アドレス代入文６０１は、図９のアドレス代入文４０２と同様である。アドレス代入文４０２が関数定義４０３の中にあってもよいのと同様に、アドレス代入文６０１も、関数定義６０２の中にあってもよい。
また、関数定義６０２で定義される関数ｅｘｅｃｕｔｅ２（）は、ＤＢアクセス要求を示すＳＱＬ文を引数ｓｑｌとしてとる。関数ｅｘｅｃｕｔｅ２（）は、第１実施形態の関数ｅｘｅｃｕｔｅ１（）とほぼ同様だが、関数定義の中に埋め込まれるＤＢアクセス結果の通知先のＵＲＩが異なる。
第１実施形態では、ＧＥＴメソッドによる特定要求を受け付けるための特定のパスが、ＰＯＳＴメソッドによるＤＢアクセス結果の通知を受け付けるのにも使われる。よって、第１実施形態のｅｘｅｃｕｔｅ１（）の中には、“ｈｔｔｐ：／／ｗｗｗ．ｆｏｏ．ｃｏｍ／＿ｒｅｓｅｒｖｅｄＦｏｒＣｏｍｅｔ”という、特定のパスを含むＵＲＩが、ＤＢアクセス結果の通知先のＵＲＩとして埋め込まれる。
それに対して、第２実施形態では、特定要求を受け付けるための上記（Ｂ２）の特定のパスとは別の、上記（Ｂ３）のパスが、ＤＢアクセス結果の通知を受け付けるのに使われる。よって、代行処理の関数定義６０２の中には、“ｈｔｔｐ：／／ｗｗｗ．ｆｏｏ．ｃｏｍ／＿ｒｅｓｅｒｖｅｄＦｏｒＤＢ”というＵＲＩが埋め込まれる。
また、関数ｅｘｅｃｕｔｅ２（）は、ＸＨＲオブジェクトを用いてＨＴＴＰ要求の形でＤＢアクセス結果をＷｅｂサーバ１００に送信した後、対応するＨＴＴＰ応答の受信またはタイムアウトを待ってから終了するよう、定義される。ＤＢアクセス結果を送信するためのＨＴＴＰ要求に対応するＨＴＴＰ応答は、具体的には、例えば、ステータスコードが２００（ＯＫ）で、メッセージボディが空のＨＴＴＰ応答である。
また、関数定義６０３で定義されるメインルーチンは、具体的には、下記（Ｃ１）〜（Ｃ３）のステップを繰り返すルーチンである。
（Ｃ１）新規ＸＨＲオブジェクトを生成し、新規ＸＨＲオブジェクトによるロングポーリング用のＨＴＴＰ要求（すなわち、（Ｂ２）の特定のパスに対する特定要求）を送信するステップ。
（Ｃ２）上記（Ｃ１）の要求に対する応答を待ち、応答を受信したら、受信した応答からＤＢアクセス要求（すなわちＳＱＬ文）を抽出するステップ。
（Ｃ３）抽出したＳＱＬ文を引数として指定して関数ｅｘｅｃｕｔｅ２（）を呼び出すステップ。
ブラウザ１１１は、メインルーチンの関数呼び出しステートメントを含む＜ｓｃｒｉｐｔ＞ブロック６０４をｉｆｒａｍｅ１１３に読み込むと、関数ｍａｉｎ（）の実行を開始する。その結果、上記（Ｃ１）のステップが実行される。すなわち、図１３のステップＳ８０８に示すように、ＸＨＲオブジェクトによるロングポーリング用のＨＴＴＰ要求がブラウザ１１１からＷｅｂサーバ１００へと送信され、振り分け部１０３において受信される。
すると、要求を受信した振り分け部１０３は、次のステップＳ８０９において、図１２のステップＳ７０７に示すようにセッションとコネクションの対応づけを行う。そして、図１２のジョインノードＳ７０８に示すように、振り分け部１０３は、ＤＢインタフェイス部１０２からのＤＢアクセス要求を待つ。
他方、ステップＳ８１０ではｉｆｒａｍｅ１１２が生成され、ステップＳ８１１ではｉｆｒａｍｅ１１２へのページ読み込みが発生する。すなわち、ブラウザ１１１は、図１４の＜ｉｆｒａｍｅ＞ブロック５０１に指定されたＵＲＩに対するＨＴＴＰ要求を、Ｗｅｂサーバ１００に送信する。
なお、図１４の例も、図８と同様に、Ｗｅｂアプリケーション１０１のトップページが静的ページの場合の例である。したがって、図８のステップＳ４１０〜Ｓ４１３と同様の一連の処理が、ステップＳ８１１〜Ｓ８１４で行われる。その結果、ブラウザ１１１は静的なページをｉｆｒａｍｅ１１２の中に表示する。
続いて、ステップＳ８１５では、図８のステップＳ４１４と同様に、ブラウザ１１１が、ｉｆｒａｍｅ１１２に読み込む対象の動的なページに対するＨＴＴＰ要求を、Ｗｅｂサーバ１００に送信する。すると、図８のステップＳ４１５〜Ｓ４１８と同様の一連の処理が、ステップＳ８１６〜Ｓ８１９で行われる。
そして、次のステップＳ８２０で振り分け部１０３は、図１２のステップＳ７０９〜Ｓ７１０に示すように、対応表１０５を参照してコネクションの照会を行う。図１３の例では、ステップＳ８０８の要求に対してまだ応答が返されていないので、ステップＳ８２０での照会の結果、コネクションが見つかる。すると、図１２のステップＳ７１１に関して説明したように、振り分け部１０３はコネクションＩＤを記憶してから、見つけたエントリを対応表１０５から削除する。
そして、ステップＳ８２１で振り分け部１０３は、図１２のステップＳ７１２に関して説明したように、受信済みのＨＴＴＰ要求（図１３の例ではステップＳ８０８の要求）に対する応答として、ＤＢアクセス要求をブラウザ１１１に送信する。すると、ブラウザ１１１はＤＢアクセス代行スクリプト１１４にしたがって上記（Ｃ２）〜（Ｃ３）の処理を行う。
その結果、関数ｅｘｅｃｕｔｅ２（）の呼び出しにより、ステップＳ８２２では、ＸＨＲオブジェクトを用いたブラウザ１１１からＤＢサーバ１２０へのＨＴＴＰ要求が送信される。ステップＳ８２２のＨＴＴＰ要求のメッセージボディには、ＤＢアクセス要求が含まれる。そして、ＤＢアクセス要求を受信したＤＢサーバ１２０は、ＤＢアクセス要求にしたがってＤＢ１２１にアクセスし、ＤＢアクセス結果を取得する。
また、ステップＳ８２３でＤＢサーバ１２０は、取得したＤＢアクセス結果を、ステップＳ８２２のＨＴＴＰ要求に対するＨＴＴＰ応答として、ブラウザ１１１に返す。
すると、ＤＢアクセス結果を受信したブラウザ１１１は、ステップＳ８２４で、ＤＢアクセス結果をＷｅｂサーバ１００に送信する。ステップＳ８２２〜Ｓ８２４の詳細は図８のステップＳ４２３〜Ｓ４２５と同様である。
そして、以上のようにして送信されたＤＢアクセス結果は、振り分け部１０３により受信される。すると、振り分け部１０３は、ステップＳ８２５でＤＢインタフェイス部１０２にＤＢアクセス結果を出力する。そして、ステップＳ８２６でＤＢインタフェイス部１０２は、ＤＢアクセス結果をＷｅｂアプリケーション１０１に出力する。ステップＳ８２５〜Ｓ８２６は、図１２のステップＳ７１２に対応し、図８のステップＳ４２６〜Ｓ４２７と同様である。
また、ＤＢインタフェイス部１０２からＤＢアクセス結果を取得したＷｅｂアプリケーション１０１は、ステップＳ８２７において、取得したＤＢアクセス結果を用いて動的にページを生成する。また、Ｗｅｂアプリケーション１０１は、生成した動的なページを、ステップＳ８１５のＨＴＴＰ要求に対するＨＴＴＰ応答として、ステップ８２７でブラウザ１１１に返す。ステップＳ８２７は、図８のステップＳ４２８と同様である。また、ステップＳ８２７でのＨＴＴＰ応答の送信は、図１２のステップＳ７１５に対応する。
また、図１３では紙幅の都合上省略されているが、振り分け部１０３は、ステップＳ８２４でＤＢアクセス結果を受信すると、上記のとおりメッセージボディが空のＨＴＴＰ応答をブラウザ１１１に返す。その結果、ブラウザ１１１では、上記（Ｃ３）における関数ｅｘｅｃｕｔｅ２（）の実行が完了する。
すると、ブラウザ１１１は、メインルーチンの関数定義６０３にしたがって再度（Ｃ１）のステップを実行する。すなわち、ブラウザ１１１は、ステップＳ８２８でステップＳ８０８と同様にして、再びＸＨＲオブジェクトによるロングポーリング用のＨＴＴＰ要求を送信する。すると、要求を受信した振り分け部１０３は、次のステップＳ８２９において、ステップＳ８０９と同様の処理を行う。
なお、以上説明した図１３の例は様々な動作例のうちの一つに過ぎない。図８に関して説明したのと同様に、図１３に関しても様々なバリエーションがあり得る。
例えば、ステップＳ８２７で動的ページがブラウザ１１１に返された後、再び別の動的なページが要求されてもよい。あるいは、１つのページの生成が、複数のＤＢアクセス要求をともなっていてもよい。また、Ｗｅｂアプリケーション１０１のトップページは、必ずしも静的なページでなくてもよい。そして、ＤＢアクセス要求の種類は、参照、追加、更新、削除のいずれであってもよい。ＤＢアクセス要求の種類が何であれ、ＤＢアクセスはブラウザ１１１によって代行される。
ところで、図５〜７を参照して前述した処理を、図１２〜１４と対応づけてより詳細に説明すれば、以下のとおりである。
図５に示すように、ブラウザ１１１は、ｉｆｒａｍｅ１１３に読み込んだＤＢアクセス代行スクリプト１１４にしたがって動作する。ＤＢアクセス代行スクリプト１１４は、図１４の例では、具体的には、アドレス代入文６０１、代行処理の関数定義６０２、メインルーチンの関数定義６０３、および＜ｓｃｒｉｐｔ＞ブロック６０４内のメインルーチンの関数呼び出しステートメントを含む。
ブラウザ１１１は、図５のステップＳ１０１に示すように、Ｗｅｂサーバ１００からＤＢアクセス要求を受信するまで待つ。第２実施形態では、ステップＳ１０１は、図１３におけるステップＳ８０８のロングポーリング用のＨＴＴＰ要求の送信を含む。さらに、ステップＳ１０１での待機は、図１３の例では、ステップＳ８０８の送信後、ステップＳ８２１でのＨＴＴＰ応答の形でのＤＢアクセス要求の受信まで待つことに対応する。
そして、図５のステップＳ１０２は図１３のステップＳ８２２に対応する。また、図５のステップＳ１０３に示すように、ブラウザ１１１は、ＤＢサーバ１２０からＤＢアクセス結果を受信するまで待つ。図１３の例では、ブラウザ１１１は、ステップＳ８２３でのＤＢアクセス結果の受信まで待つ。
そして、図５のステップＳ１０４は、図１３のステップＳ８２４に対応する。また、図５ではステップＳ１０４からステップＳ１０１へと制御が戻る。この図５のループにより、上記のように複数の動的なページが要求される場合、または１つのページが複数のＤＢアクセス要求をともなう場合において、それぞれのＤＢアクセスがブラウザ１１１により代行される。そして、この図５のループは、第２実施形態では、関数ｍａｉｎ（）内のループにより実現される。
すなわち、図１４のメインルーチンの関数定義６０３は、図５の全体のフローを定義している。また、代行処理の関数定義６０２は、図５のステップＳ１０２〜Ｓ１０４の動作を定義している。そして、＜ｓｃｒｉｐｔ＞ブロック６０４は、図５の処理の開始をブラウザ１１１に指示するコードである。
また、図６に動作を示したＤＢインタフェイス部１０２は、第１実施形態と同様である。
また、図７のステップＳ３０１は図１３には明示されていない。スクリプト生成部１０４は、ステップＳ３０１の実行後、ステップＳ３０２で振り分け部１０３からスクリプトの生成指示を受け取るまで待つ。図１３の例では、スクリプト生成部１０４は、ステップＳ８０５まで待つ。
そして、図７のステップＳ３０３でスクリプト生成部１０４が生成するスクリプトの内容は、具体的には、図１４の子ページ６００に含まれる＜ｈｅａｄ＞要素内の＜ｓｃｒｉｔｐ＞ブロックおよび＜ｂｏｄｙ＞要素内の＜ｓｃｒｉｐｔ＞ブロック６０４である。
また、図７の処理はステップＳ３０４からステップＳ３０２へと再び戻る。したがって、この図７のループにより、複数のブラウザからの要求に対応するそれぞれのスクリプトがスクリプト生成部１０４により生成される。
続いて、第２実施形態における振り分け部１０３の動作について、図１５〜１６を参照して詳しく説明する。
図１５は、第２実施形態において振り分け部１０３がＤＢインタフェイス部１０２からのＤＢアクセス要求の受付を契機として行う処理のフローチャートである。例えば、図１３のステップＳ８１９でのＤＢアクセス要求の受付を契機として、振り分け部１０３は図１５の処理を開始する。
そして、ステップＳ９０１で振り分け部１０３は、スレッドローカルな変数からセッションＩＤを取得する。ステップＳ９０１は、図１０のステップＳ５０１と同様であり、また、図１２のステップＳ７０９に対応する。
次に、ステップＳ９０２で振り分け部１０３は、ステップＳ９０１で取得したセッションＩＤに対応するコネクションを対応表１０５から探す。なお、ステップＳ９０２は図１０のステップＳ５０２と似ているが、違いもある。すなわち、ステップＳ５０２では予期せぬエラーでもない限りコネクションが１つ見つかるのに対し、ステップＳ９０２ではコネクションが見つかる保証はない。図１２のジョインノードＳ７０８に関して説明したとおり、例えば、図１３のステップＳ８０８のＨＴＴＰ要求の受信の前に、振り分け部１０３がステップＳ８１９のＤＢアクセス要求を受け付けた場合などは、コネクションが見つからない。
そこで、次のステップＳ９０３で振り分け部１０３は、ステップＳ９０２の検索の結果コネクションが見つかったか否かを判断する。コネクションが見つかった場合、処理はステップＳ９０４に移行する。逆に、コネクションが見つからなかった場合、処理はステップＳ９０６に移行する。
ステップＳ９０４で振り分け部１０３は、ステップＳ９０２の検索の結果として見つかったエントリのコネクションＩＤを記憶し、見つかったエントリ（すなわちセッションＩＤとコネクションＩＤのペア）を対応表１０５から削除する。
なお、ステップＳ９０４は、図１２のステップＳ７１１に対応する。また、ステップＳ９０４で記憶されるコネクションＩＤは、具体的には、ブラウザ１１１が過去にＸＨＲオブジェクトを用いて送信したＨＴＴＰ要求を振り分け部１０３が受信してから維持され続けているコネクションのコネクションＩＤである。
そして、次のステップＳ９０５で振り分け部１０３は、ステップＳ９０４で記憶したコネクションＩＤにより特定されるコネクションを介して、ＤＢアクセス要求をブラウザ１１１に送信する。つまり、コネクションの維持のために応答を延期していた、ＸＨＲオブジェクトを用いたＨＴＴＰ要求に対するＨＴＴＰ応答として、振り分け部１０３は、ＤＢアクセス要求をメッセージボディに含むＨＴＴＰ応答を返す。
ステップＳ９０５は、図１２のステップＳ７１２の一部である。また、ステップＳ９０５の具体例は、図１３のステップＳ８２１である。
そして、ステップＳ９０５の実行後、図１５の処理フローは終了するが、振り分け部１０３のスレッド自体は消滅しない。振り分け部１０３のスレッドでは、その後のブラウザ１１１からのＤＢアクセス結果の受信を契機に、図１６の処理が始まる。
他方、ステップＳ９０２の検索の結果、コネクションが見つからなかった場合、振り分け部１０３はステップＳ９０６の処理を行う。ステップＳ９０６の処理は、図１２においてジョインノードＳ７０８で表される待ち合わせのための処理である。
具体的には、振り分け部１０３は、待ち合わせのために、セッションＩＤごとにＤＢアクセス要求のキューをメモリ上に保持している。よって、ステップＳ９０６で振り分け部１０３は、図１５の処理の開始の契機となったＤＢインタフェイス部１０２からのＤＢアクセス要求を、ステップＳ９０１で取得したセッションＩＤに対応するキューに追加する。
そして、図１５の処理フローは終了するが、振り分け部１０３のスレッド自体は消滅しない。振り分け部１０３のスレッドでは、ＸＨＲオブジェクトを用いたロングポーリング用の新たなＨＴＴＰ要求のブラウザ１１１からの受信を契機に、図１６の処理が始まる。
さて、図１６は、第２実施形態において振り分け部１０３がブラウザ１１１からの要求の受信を契機として行う処理のフローチャートである。例えば、図１３のステップＳ８０１、Ｓ８０４、Ｓ８０８、Ｓ８１１、Ｓ８１５、Ｓ８２４、Ｓ８２８では、振り分け部１０３がブラウザ１１１からのＨＴＴＰ要求を受信する。そして、振り分け部１０３は、ＨＴＴＰ要求の受信を契機として、図１６の処理を開始する。
なお、ＨＴＴＰ要求を振り分け部１０３が受信すると、ブラウザ１１１とＷｅｂサーバ１００の間のＨＴＴＰコネクションが確立する。したがって、図１６の処理が開始された時点で何らかのコネクションが存在する。
ステップＳ１００１で振り分け部１０３は、図１１のステップＳ６０１と同様に、セッションがあるか否かを判断する。セッションがなければ処理はステップＳ１００２に移行する。逆に、セッションが既に存在していれば、振り分け部１０３はセッションＩＤを認識し、処理はステップＳ１００４に移行する。
ステップＳ１００２で振り分け部１０３は、セッションを新規に作成する。具体的には、振り分け部１０３は、新たなセッションＩＤを発行する。ステップＳ１００２が実行されるのは、例えば、図１３のステップＳ８０１の要求の受信を契機として図１６の処理が開始された場合である。
そして、次のステップＳ１００３で振り分け部１０３は、ＨＴＴＰ応答のＳｅｔ−ＣｏｏｋｉｅヘッダにステップＳ１００２で発行したセッションＩＤを設定して、親ページ５００をブラウザ１１１に返す。親ページ５００の＜ｉｆｒａｍｅ＞要素５０１に付けられているｓｒｃ属性を”／”の代わりにＨＴＴＰ要求のリクエストラインにあったパスとしておくことも可能である。ステップＳ１００３の具体例は、図１３のステップＳ８０２である。また、ステップＳ１００３の実行後、図１６の処理は終了する。
他方、セッションが既に存在する場合、ステップＳ１００４で振り分け部１０３は、ブラウザ１１１から要求されたＵＲＩの種類を判定する。
要求されたＵＲＩが、上記（Ｂ１）のｉｆｒａｍｅ１１３用のパスを含む場合、処理はステップＳ１００５に移行する。例えば、図１３のステップＳ８０４の要求の受信を契機として図１６の処理が開始された場合、処理はステップＳ１００５へと移行する。
また、要求されたＵＲＩが、上記（Ｂ２）のロングポーリング用のＨＴＴＰ要求（つまり特定要求）を受け付けるためのパスを含む場合、処理はステップＳ１００８に移行する。例えば、図１３のステップＳ８０８またはＳ８２８の要求の受信を契機として図１６の処理が開始された場合、処理はステップＳ１００８へと移行する。
また、要求されたＵＲＩが、上記（Ｂ３）のＤＢアクセス結果の通知用のパスを含む場合、処理はステップＳ１０１３に移行する。例えば、図１３のステップＳ８２４のＨＴＴＰ要求の形でのＤＢアクセス結果の通知を振り分け部１０３が受信したことを契機として図１６の処理が開始された場合、処理はステップＳ１０１３に移行する。
そして、要求されたＵＲＩが、上記（Ｂ１）〜（Ｂ３）のいずれのパスも含まない場合（すなわち、要求されたＵＲＩが、Ｗｅｂアプリケーション１０１が使うための通常のパスを示す場合）、処理はステップＳ１００６に移行する。例えば、図１３のステップＳ８１１またはＳ８１５の要求の受信を契機として図１６の処理が開始された場合、処理はステップＳ１００６へと移行する。
さて、（Ｂ１）のｉｆｒａｍｅ１１３用のパスを含むＵＲＩへの要求をブラウザ１１１から受信した場合、振り分け部１０３は、ステップＳ１００５において、設定ファイル１０６に基づくスクリプトをスクリプト生成部１０４に生成させる。そして、振り分け部１０３は、スクリプト生成部１０４に生成させたスクリプトを含むページを生成し、生成したページをブラウザ１１１に送付する。ステップＳ１００５の実行後、図１６の処理は終了する。
なお、ステップＳ１００５の具体例は、図１３のステップＳ８０５〜Ｓ８０７である。また、ステップＳ１００５でスクリプト生成部１０４が生成するスクリプトの具体例は、図１４の子ページ６００の＜ｈｅａｄ＞要素内の＜ｓｃｒｉｐｔ＞ブロックと＜ｂｏｄｙ＞要素内の＜ｓｃｒｉｐｔ＞ブロック６０４である。つまり、ステップＳ１００５で振り分け部１０３が生成するページの例は、図１４の子ページ６００である。
さて、ブラウザ１１１から要求されたＵＲＩが、上記（Ｂ１）〜（Ｂ３）のいずれのパスも含まない場合、振り分け部１０３は、ステップＳ１００６で、スレッドローカルな変数に、ステップＳ１００１で認識したセッションＩＤを保存する。ここで保存されたセッションＩＤは、前述のとおり、図１５のステップＳ９０１で参照される。
そして、次のステップＳ１００７で振り分け部１０３は、Ｗｅｂアプリケーション１０１に処理を委譲する。具体的には、振り分け部１０３は、ブラウザ１１１から受信したＨＴＴＰ要求をＷｅｂアプリケーション１０１に出力する。そして、振り分け部１０３による図１６の処理は終了する。
なお、ステップＳ１００６は図１２のステップＳ７０２に対応し、ステップＳ１００７は図１２のステップＳ７０４の一部である。また、ステップＳ１００６〜Ｓ１００７の処理は、例えば、図１３のステップＳ８１３においても行われ、ステップＳ８１７においても行われる。
また、（Ｂ２）のロングポーリング用のＨＴＴＰ要求（つまり特定要求）を受け付けるためのパスを含むＵＲＩへの要求をブラウザ１１１から受信した場合、振り分け部１０３は、ステップＳ１００８以降の処理を行う。
具体的には、ステップＳ１００８で振り分け部１０３は、対応表１０５に新規エントリを挿入する。また、振り分け部１０３は、新規エントリのセッションＩＤフィールドに、ステップＳ１００１で認識したセッションＩＤを設定する。そして、振り分け部１０３は、ロングポーリング用のＨＴＴＰ要求の受信によってブラウザ１１１とＷｅｂサーバ１００との間に確立したＨＴＴＰコネクションを識別するコネクションＩＤを、新規エントリのコネクションＩＤフィールドに設定する。ステップＳ１００８は図１２のステップＳ７０７に相当する。
そして、次のステップＳ１００９で振り分け部１０３は、図１５に関して説明したキューが空であるか否かを判断する。具体的には、振り分け部１０３は、ステップＳ１００１で認識したセッションＩＤに対応するキューが空か否かを判断する。
キューが空の場合とは、振り分け部１０３が、ＤＢインタフェイス部１０２からＤＢアクセス要求を受け取る前に、ロングポーリング用のＨＴＴＰ要求を受信した場合である。よって、振り分け部１０３が次にＤＢインタフェイス部１０２からＤＢアクセス要求を受け取るまで、ロングポーリング用のＨＴＴＰ要求に対するＨＴＴＰ応答は延期される。つまり、振り分け部１０３が、今回受信したロングポーリング用のＨＴＴＰ要求に対して現時点で行う処理はない。したがって、図１６の処理は終了する。
逆に、キューが非空の場合とは、振り分け部１０３が、ロングポーリング用のＨＴＴＰ要求を受信する前に、既にＤＢインタフェイス部１０２からＤＢアクセス要求を受け取っている場合である。よって、振り分け部１０３は、今回受信したロングポーリング用のＨＴＴＰ要求に対するＨＴＴＰ応答を延期せず、キューに蓄積されているＤＢアクセス要求をＨＴＴＰ応答の形でブラウザ１１１に送信する。
つまり、ステップＳ１００９でキューが非空の場合とは、図１２のステップＳ７１０のガード条件が今まで満たされていなかったのが、ロングポーリング用のＨＴＴＰ要求の受信によりガード条件が満たされた場合に相当する。そこで、キューが非空の場合、処理はステップＳ１０１０に移行する。
すると、ステップＳ１０１０で振り分け部１０３は、ステップＳ１００８で対応表１０５に追加したエントリのコネクションＩＤを記憶し、ステップＳ１００８で対応表１０５に追加したエントリを対応表１０５から削除する。ステップＳ１０１０は、図１２のステップＳ７１１に対応する。
そして、次のステップＳ１０１１で振り分け部１０３は、キューから先頭のＤＢアクセス要求を取り出す。
また、次のステップＳ１０１２で振り分け部１０３は、ステップＳ１０１１で取り出したＤＢアクセス要求をブラウザ１１１に送信する。具体的には、振り分け部１０３は、キューから取り出したＤＢアクセス要求を、今回受信したＨＴＴＰ要求（すなわちＸＨＲオブジェクトによるロングポーリング用のＨＴＴＰ要求）に対するＨＴＴＰ応答に含めて、ブラウザ１１１に返す。そして、図１６の処理は終了する。なお、ステップＳ１０１１〜Ｓ１０１２は図１２のステップＳ７１２の一部である。
ところで、振り分け部１０３は、（Ｂ３）のＤＢアクセス結果の通知用のパスを含むＵＲＩへの要求をブラウザ１１１から受信した場合、ステップＳ１０１３〜Ｓ１０１４の処理を行う。ステップＳ１０１３〜Ｓ１０１４の処理は、図１２のステップＳ７１２のガード条件が満たされたときに行われる処理だが、図１２には明示されていない。
具体的には、振り分け部１０３はステップＳ１０１３において、ブラウザ１１１から受信したＤＢアクセス結果に対応する、ＤＢインタフェイス部１０２からのＤＢアクセス要求に対して、ＤＢアクセス結果を返す。ステップＳ１０１３の具体例は、図１３のステップＳ８２５である。
なお、第１実施形態と同様に第２実施形態でも、振り分け部１０３は、ＤＢインタフェイス部１０２からのＤＢアクセス要求を受け取ったのと同じスレッドでブラウザ１１１からＤＢアクセス要求を受信する。よって、振り分け部１０３は、ブラウザ１１１から受信したＤＢアクセス結果がどのＤＢアクセス要求に対応するのかを認識することができる。もちろん、実施形態によっては、ＤＢアクセス要求を識別する要求ＩＤが、ＤＢアクセス要求とＤＢアクセス結果の対応関係の管理のために使われてもよい。
また、次のステップＳ１０１４で振り分け部１０３は、ＤＢアクセス結果の通知のためにブラウザ１１１からＸＨＲオブジェクトを用いて送られたＨＴＴＰ要求に対して、メッセージボディが空のＨＴＴＰ応答を返す。そして、図１６の処理は終了する。
以上のとおり、第２実施形態によれば、ブラウザ１１１がＤＢアクセス代行スクリプト１１４にしたがって送信するＨＴＴＰ要求に対する応答を、振り分け部１０３が延期することにより、ブラウザ１１１とＷｅｂサーバ１００の間のコネクションが維持される。また、応答が返されて、その結果としてコネクションが切れると、ブラウザ１１１はＤＢアクセス代行スクリプト１１４にしたがって新たなＨＴＴＰ要求を送信する。したがって、新たなＨＴＴＰ要求に対する応答が延期されている間は、新たなコネクションが維持される。
つまり、第２実施形態では、第１実施形態のように１つのコネクションが維持され続けるわけではなく、コネクションが順次切り換わる。しかし、第２実施形態によれば、１つのコネクションが切れるとすぐに新たなコネクションが確立される。したがって、第２実施形態は、ブラウザ１１１とＷｅｂサーバ１００の間に常にコネクションが維持されている状態とほとんど変わらない状態を実現することができる。
つまり、第２実施形態によれば、ＤＢアクセス要求がエンキューされている間の短い待ち時間が生じることはあり得る。しかし、そのような短い待ち時間を除けば、Ｗｅｂアプリケーション１０１によるＤＢアクセス要求がいつ生じても、振り分け部１０３はすぐにＤＢアクセス要求をブラウザ１１１に中継することができる。
そして、ブラウザ１１１がＤＢアクセス代行スクリプト１１４にしたがってＤＢアクセスを代行し、ＤＢアクセス結果は振り分け部１０３とＤＢインタフェイス部１０２を介して最終的にＷｅｂアプリケーション１０１に出力される。したがって、Ｗｅｂアプリケーション１０１は、直接ＤＢサーバ１２０にアクセスすることが許されなくても、ＤＢアクセス結果を得ることができる。
このように、第２実施形態によれば、インタフェイス・サーバまたは中継サーバなどの付加的な装置がなくても、Ｗｅｂアプリケーション１０１が、ファイアウォール１３０で隔てられたイントラネット１４０内のＤＢ１２１のデータを使って処理を行うことができる。また、Ｗｅｂアプリケーション１０１は、ＤＢ１２１のデータを一時的かつ部分的に使うだけであり、ＤＢ１２１のデータがＷｅｂサーバ１００に不揮発的に長期にわたって保存されるわけではない。したがって、第２実施形態は、ＤＢ１２１に機密情報が含まれる場合にも好適である。
ところで、以上説明した第２実施形態は、同じ１つのＸＨＲオブジェクトによる１つのＨＴＴＰ要求が、図１３のステップＳ８２４のＤＢアクセス結果の通知と、ステップＳ８２８のロングポーリング用の要求を兼ねるように変形されてもよい。具体的には、例えば以下のような変形が可能である。
まず、図１４の関数ｅｘｅｃｕｔｅ２（）は、ＸＨＲオブジェクトを用いてＨＴＴＰ要求の形でＤＢアクセス結果をＷｅｂサーバ１００に送信した後、対応するＨＴＴＰ応答を受信したら、受信した応答のメッセージボディを返り値として返すように変形される。つまり、変形された関数ｅｘｅｃｕｔｅ２（）は、あるＤＢアクセス要求を代行してＤＢアクセス結果をＷｅｂサーバ１００に返すとともに、次のＤＢアクセス要求を受け取るための関数である。
また、図１４の関数ｍａｉｎ（）は、以下の（Ｄ１）〜（Ｄ３）のステップを実行した後、（Ｄ４）のステップを繰り返すように変形される。
（Ｄ１）新規ＸＨＲオブジェクトを生成し、新規ＸＨＲオブジェクトによるロングポーリング用のＨＴＴＰ要求（すなわち、（Ｂ２）の特定のパスに対する特定要求）を送信するステップ。
（Ｄ２）上記（Ｄ１）の要求に対する応答を待ち、応答を受信したら、受信した応答からＤＢアクセス要求（すなわち最初のＤＢアクセス要求を表すＳＱＬ文）を抽出するステップ。
（Ｄ３）関数ｅｘｅｃｕｔｅ２（）に引数として与えるための変数（説明の便宜上“ｑ”とする）に、上記（Ｄ２）で抽出したＳＱＬ文の文字列を代入するステップ。
（Ｄ４）変数ｑを引数として与えて関数ｅｘｅｃｕｔｅ２（）を呼び出し、返り値（すなわち次のＤＢアクセス要求を表すＳＱＬ文）を取得し、取得した返り値を変数ｑに代入するステップ（つまり、“ｑ＝ｅｘｅｃｕｔｅ２（ｑ）；”というステップ）。
また、上記（Ｂ３）のＤＢアクセス結果の受信用のパスは、本変形例では不要である。そして、振り分け部１０３による図１６の処理は、次のように変形される。
すなわち、ステップＳ１００４で判定されたパスが、ロングポーリング用のＨＴＴＰ要求を受け付けるための上記（Ｂ２）のパスだった場合、振り分け部１０３は、受信したＨＴＴＰ要求のメッセージボディが空か否かを判断する。そして、メッセージボディが空の場合は、ＤＢアクセス結果の通知は行われていないので、振り分け部１０３は、ステップＳ１００８以降の処理を行う。逆に、メッセージボディが非空の場合は、振り分け部１０３はステップＳ１０１３の処理を行い、次のステップＳ１０１４の処理は省略し、その代わりに続けてステップＳ１００８以降の処理を行う。
例えば以上のような変形により、図１３のステップＳ８２４とＳ８２８を同じ１つのＨＴＴＰ要求で実現することが可能となる。その結果、Ｗｅｂサーバ１００とクライアントマシン１１０の間のトラフィックを削減することができる。
続いて、上記の第１実施形態と第２実施形態のいずれに対しても適用可能な変形の例とを説明する。具体的には、設定ファイル１０６の変形およびそれにともなう処理の変形について、図１７〜１９を参照して説明する。
図１７は、設定ファイル１０６の他の例を示す図である。図２の設定ファイル１０６ａは、ブラウザ１１１がＤＢサーバ１２０にアクセスするための「ＤＢアドレス」という項目のみを含む。しかしながら、他の項目をさらに含む設定ファイル１０６が使われてもよい。
例えば、図１７の設定ファイル１０６ｂは、設定ファイル１０６ａと同様のＤＢアドレスに加えて、「プライベートキー」という項目を含む。図１７では説明の便宜上、プライベートキーの値の例として“ａｂｃｄｅｆ０１２３４５６７８９”という値が例示されているが、もちろん、プライベートキーの値は任意である。
設定ファイル１０６ｂに記憶されるプライベートキーは、Ｗｅｂサーバ１００のプライベートキー（換言すれば、Ｗｅｂアプリケーション１０１を提供するＳａａＳベンダあるいはＡＳＰのプライベートキー）である。また、対応するパブリックキーが、ＤＢサーバ１２０に予め記憶される。
そして、設定ファイル１０６ｂが使われる変形例においては、ＤＢアクセス要求がブラウザ１１１に送信されるとき、署名が付けられる。具体的には第１実施形態と第２実施形態はそれぞれ以下のように変形されてもよい。
第１実施形態がプライベートキーを使うように変形される場合の変更点は次のとおりである。
まず、図９の関数ｅｘｅｃｕｔｅ１（）は、もう１つの引数として署名をとるように変形される。さらに、関数ｅｘｅｃｕｔｅ１（）は、ＸＨＲオブジェクトを用いてＤＢアクセス要求（すなわち引数ｓｑｌで表されるＳＱＬ文）をＤＢサーバ１２０に送信するときに、署名も一緒に同じＨＴＴＰ要求のメッセージボディに含めて送信するように変形される。
また、本変形例の振り分け部１０３は、図１０のステップＳ５０３において、署名を生成する。そして、振り分け部１０３は、スクリプト生成部１０４に対して、ＤＢアクセス要求を表すＳＱＬ文だけでなく、署名も、スクリプトの生成に用いるための情報として指定する。すると、スクリプト生成部１０４は、振り分け部１０３から指定されたＳＱＬ文と署名を引数とする関数ｅｘｅｃｕｔｅ１（）の呼び出しステートメントを含む＜ｓｃｒｉｐｔ＞ブロックを生成する。以上のようにして生成された＜ｓｃｒｉｐｔ＞ブロックを含むチャンクが、図１０のステップＳ５０４で送信される。
なお、振り分け部１０３による署名の生成方法と、ＤＢサーバ１２０による認証処理の内容は、実施形態に応じて様々であってよい。
例えば、振り分け部１０３は、ステップＳ５０３の実行時に、タイムスタンプを取得する。また、振り分け部１０３は、ＳＨＡ（Secure Hash Algorithm）−１などの暗号学的ハッシュ関数を用いてＳＱＬ文からハッシュ値を計算する。そして、振り分け部１０３は、タイムスタンプとハッシュ値を連結した文字列をプライベートキーで暗号化することにより、署名を生成する。
すると、ＳＱＬ文と署名を引数とする関数ｅｘｅｃｕｔｅ１（）をブラウザ１１１が実行すると、ＳＱＬ文とともに署名がＤＢサーバ１２０に送信される。ＤＢサーバ１２０は、署名をパブリックキーで復号することによりタイムスタンプとハッシュ値を得る。また、ＤＢサーバ１２０は、ブラウザ１１１から送信されたＳＱＬ文から、振り分け部１０３が使ったのと同じハッシュ関数を用いてハッシュ値を計算する。
ＤＢサーバ１２０は、復号と計算によりそれぞれ得られた２つのハッシュ値を比較する。そして、２つのハッシュ値が異なれば、ＤＢサーバ１２０は、「不正なＤＢアクセス要求を受信した」と判断して適宜のエラー処理を行ってもよい。
また、ＤＢサーバ１２０は、リプレイ攻撃への対策として、復号により得たタイムスタンプとハッシュ値のペアを、所定時間の間メモリ上のテーブルに記憶してもよい。そして、ＤＢサーバ１２０は、復号と計算によりそれぞれ得られた２つのハッシュ値が同じ場合、復号により得たタイムスタンプとハッシュ値のペアとまったく同じペアがテーブルに記憶されているか否かをチェックする。もし同じペアがテーブルに記憶されている場合は、ＤＢサーバ１２０は「リプレイ攻撃を受けた」と判断して適宜のエラー処理を行ってもよい。
また、ＤＢアクセス要求の種類によっては、同じ要求の繰り返しが許容されない場合があり得る。例えば、同じデータに対する参照要求の繰り返しは許容されるが、同じデータに対する削除要求の繰り返しは許容されないかもしれない。
そこで、ＤＢサーバ１２０は、上記のテーブルの検索によって同じペアが見つからなかった場合、さらに、次のようなチェック処理を行ってもよい。すなわち、繰り返しが許容されない種類のＤＢアクセス要求を受けた場合、ＤＢサーバ１２０は、復号により得たハッシュ値と同じハッシュ値がテーブルに記憶されているか否かをチェックしてもよい。そして、もし同じハッシュ値が見つかれば、ＤＢサーバ１２０はエラー処理を行ってもよい。
また、ＤＢサーバ１２０とＷｅｂサーバ１００は、例えばＮＴＰ（Network Time Protocol）などによって正しい時刻に同期されていてもよい。ＤＢサーバ１２０は、復号により得たタイムスタンプと、現在時刻との差に応じて、適宜のエラー処理を行ってもよい。例えば、ＤＢサーバ１２０は、時間差が閾値以上の場合はエラー処理を行ってもよい。
そして、以上例示したようなエラー処理の対象にならないＤＢアクセス要求に対してのみ、ＤＢサーバ１２０は、ＤＢ１２１への実際のアクセスを行ってもよい。
また、第２実施形態がプライベートキーを使うように変形される場合の変更点は次のとおりである。
まず、図１４の関数ｅｘｅｃｕｔｅ２（）は、もう１つの引数として署名をとるように変形される。さらに、関数ｅｘｅｃｕｔｅ２（）は、ＸＨＲオブジェクトを用いてＤＢアクセス要求（すなわち引数ｓｑｌで表されるＳＱＬ文）をＤＢサーバ１２０に送信するときに、署名も一緒に同じＨＴＴＰ要求のメッセージボディに含めて送信するように変形される。そして、図１４の関数ｍａｉｎ（）は、上記（Ｃ２）のステップにおいて、振り分け部１０３より受信したＨＴＴＰ応答から、ＳＱＬ文だけでなく署名も抽出するように、変形される。
また、振り分け部１０３は、図１５のステップＳ９０５または図１６のステップＳ１０１２において、署名を生成する。そして、振り分け部１０３は、ステップＳ９０５またはＳ１０１２で送信するＨＴＴＰ応答のメッセージボディに、ＤＢアクセス要求を表すＳＱＬ文だけでなく、生成した署名も含める。
なお、振り分け部１０３による署名の生成方法と、ＤＢサーバ１２０による署名を用いた認証処理の内容は特に限定されない。第１実施形態の変形に関して例示したような、タイムスタンプとハッシュ関数を用いた署名が使われてもよいし、そのような署名を用いた認証がＤＢサーバ１２０により行われてもよい。
ここで、図１７の説明に戻る。図２の設定ファイル１０６ａの代わりに、例えば図１７の設定ファイル１０６ｃが用いられてもよい。設定ファイル１０６ｃは、設定ファイル１０６ａと同様のＤＢアドレスに加えて、「イントラネット上のテーブル名」と「インターネット上のテーブル名」という２つの項目を含む。以下ではこれら２つの項目により表される情報を「所在情報」ともいう。
設定ファイル１０６ｃの例では、具体的には、「イントラネット上のテーブル名」として、「顧客」および「注文」という２つのテーブル名が記憶されており、「インターネット上のテーブル名」として「商品」および「カート」という２つのテーブル名が記憶されている。つまり、所在情報１０７は、「顧客」テーブルと「注文」テーブルがイントラネット１４０内にあることと、「商品」テーブルと「カート」テーブルがイントラネット１４０外にあることを示す。
より一般化して言えば、所在情報１０７は、ＤＢ１２１が含む各テーブルの識別情報をＤＢ１２１と対応づけるとともに、ＤＢ１８１が含む各テーブルの識別情報をＤＢ１８１と対応づける情報である。そして、図１７では、各テーブルの識別情報として、テーブル名が使われている。
所在情報１０７を含む設定ファイル１０６ｃは、ＤＢがイントラネット１４０と外部ネットワーク１５０に分散している図１８のような場合に使われる。また、設定ファイル１０６ｃが使われる場合、ＤＢインタフェイス部１０２の動作が図１９のように変更される。
図１８は、変形例のシステム構成図である。図１と図１８の違いは以下のとおりである。
図１８の変形例においては、図６のフローチャートにしたがって動作する図１のＤＢインタフェイス部１０２の代わりに、図１９のフローチャートにしたがって動作するＤＢインタフェイス部１０２ａが設けられる。なお、ＤＢインタフェイス部１０２ａがＷｅｂアプリケーション１０１に対して提供するインタフェイスは、ＤＢインタフェイス部１０２がＷｅｂアプリケーション１０１に対して提供するインタフェイスと同じである。
また、外部ネットワーク１５０内に、Ｗｅｂサーバ１００のＤＢインタフェイス部１０２ａからアクセス可能なＤＢサーバ１８０がさらに設けられる。また、ＤＢサーバ１８０はＤＢ１８１を記憶する。
なお、ＤＢインタフェイス部１０２ａも、例えば図４のＣＰＵ２０１がプログラムを実行することにより、実現される。また、ＤＢインタフェイス部１０２ａはＤＢサーバ１８０と通信するが、ＤＢインタフェイス部１０２ａの通信機能は、例えば図４のネットワーク接続装置２０３により実現される。
図１７の設定ファイル１０６ｃの例によれば、イントラネット１４０内のＤＢ１２１に含まれるテーブルは、「顧客」および「注文」という２つのテーブルである。また、設定ファイル１０６ｃの例によれば、外部ネットワーク１５０内のＤＢ１８１に含まれるテーブルは、「商品」および「カート」という２つのテーブルである。
ＤＢインタフェイス部１０２ａは、設定ファイル１０６ｃを参照し、アクセス対象のテーブルに応じて、ブラウザ１１１にＤＢアクセスを代行させるか、ＤＢインタフェイス部１０２ａ自身がＤＢアクセスを行うかを決定する。そして、ＤＢ１２１へのＤＢアクセス要求が生じた場合は、ＤＢインタフェイス部１０２ａは、ブラウザ１１１にＤＢアクセスを代行させるために、振り分け部１０３にＤＢアクセス要求を出力する。逆に、ＤＢ１８１へのＤＢアクセス要求が生じた場合は、ＤＢインタフェイス部１０２ａ自身がＤＢサーバ１８０にＤＢアクセス要求を送信する。
ところで、ＤＢ１８１へのＤＢアクセスには、Ｗｅｂサーバ１００とＤＢサーバ１８０の間のＲＴＴ（Round Trip Time）以上の時間がかかる。また、ＤＢ１２１へのＤＢアクセスには、Ｗｅｂサーバ１００とクライアントマシン１１０の間のＲＴＴと、クライアントマシン１１０とＤＢサーバ１２０の間のＲＴＴの和以上の時間がかかる。
そして、外部ネットワーク１５０は、より具体的には、ＳａａＳベンダあるいはＡＳＰのＬＡＮである。したがって、Ｗｅｂサーバ１００とＤＢサーバ１８０の間のＲＴＴは、Ｗｅｂサーバ１００とクライアントマシン１１０の間のＲＴＴと比較すると、大幅に短い。つまり、ＤＢ１８１へのＤＢアクセスにかかる時間は、ＤＢ１２１へのＤＢアクセスにかかる時間よりも大幅に短い。
詳しくは後述するが、あるデータをＤＢ１２１とＤＢ１８１のいずれに格納するのが好ましいかは、ＤＢアクセスにかかる時間の違いも考慮に入れたうえで決められることが好ましい。
なお、図１８の例ではＷｅｂサーバ１００とＤＢサーバ１８０が別のサーバだが、実施形態によっては、物理的には１台のサーバがＷｅｂサーバ１００とＤＢサーバ１８０を兼ねていてもよい。逆に、負荷分散のためにＤＢサーバ１８０が物理的には複数のサーバであってもよい。
さて、図１９は、変形例のＤＢインタフェイス部１０２ａの動作を説明するフローチャートである。
ステップＳ１１０１でＤＢインタフェイス部１０２ａは、Ｗｅｂアプリケーション１０１からＤＢアクセス要求を受け取るまで待つ。ステップＳ１１０１は、図６のステップＳ２０１と同様である。
そして、ＤＢインタフェイス部１０２ａがＷｅｂアプリケーション１０１からＤＢアクセス要求を受信すると、処理はステップＳ１１０２に移行する。ステップＳ１１０２でＤＢインタフェイス部１０２ａは、設定ファイル１０６ｃの所在情報１０７を参照する。
そして、次のステップＳ１１０３でＤＢインタフェイス部１０２ａは、ＤＢアクセス要求により要求されたテーブルがＤＢ１２１とＤＢ１８１のどちらに含まれるのかを確認する。ＤＢアクセス要求により要求されたテーブルが、クライアントマシン１１０から見てインターネット側のＤＢ１８１に含まれる場合、処理はステップＳ１１０４に移行する。逆に、ＤＢアクセス要求により要求されたテーブルが、イントラネット１４０内のＤＢ１２１に含まれる場合、処理はステップＳ１１０５に移行する。
例えば、「商品」テーブルまたは「カート」テーブルに対するＤＢアクセス要求をＤＢインタフェイス部１０２ａがＷｅｂアプリケーション１０１から受け取った場合、処理はステップＳ１１０４に移行する。逆に、「顧客」テーブルまたは「注文」テーブルに対するＤＢアクセス要求をＤＢインタフェイス部１０２ａがＷｅｂアプリケーション１０１から受け取った場合、処理はステップＳ１１０５に移行する。
ステップＳ１１０４でＤＢインタフェイス部１０２ａは、ＤＢサーバ１８０に直接アクセスしてＤＢアクセス結果を取得する。そして、処理はステップＳ１１０７に移行する。
他方、ステップＳ１１０５でＤＢインタフェイス部１０２ａは、図６のステップＳ２０２と同様に、Ｗｅｂアプリケーション１０１から受け取ったＤＢアクセス要求を振り分け部１０３に出力する。
そして、次のステップＳ１１０６でＤＢインタフェイス部１０２ａは、図６のステップＳ２０３と同様に、振り分け部１０３からＤＢアクセス結果を受け取るまで待つ。ＤＢインタフェイス部１０２ａが振り分け部１０３からＤＢアクセス結果を受け取ると、処理はステップＳ１１０７に移行する。
ステップＳ１１０７でＤＢインタフェイス部１０２ａは、図６のステップＳ２０４と同様に、ＤＢアクセス結果をＷｅｂアプリケーション１０１に返す。そして、処理はステップＳ１１０１に戻る。
続いて、図１８〜１９の変形例の利点について説明する。図１８〜１９の変形例の利点は、データの特性に応じてＤＢ１２１とＤＢ１８１の両方が利用可能な点である。
Ｗｅｂアプリケーション１０１の種類は様々であり、Ｗｅｂアプリケーション１０１が利用するデータの種類も様々である。そして、ある種のデータは、イントラネット１４０内のＤＢ１２１に格納されることが好ましく、別の種類のデータは、Ｗｅｂサーバ１００から直接アクセス可能なＤＢサーバ１８０内のＤＢ１８１に格納されることが好ましい。
例えば顧客の個人情報や注文履歴などの機密性の高いデータは、ＤＢ１２１に格納されることが好ましい。なぜなら、企業ユーザは、外部ネットワーク１５０からの情報漏洩のリスクをおそれて、イントラネット１４０の外部に機密性の高いデータが保存されることを嫌うからである。図１７の所在情報１０７の例でも、顧客の個人情報を含む「顧客」テーブルと、顧客の注文履歴を含む「注文」テーブルは、「イントラネット上のテーブル名」の項目に登録されている。
逆に、ＤＢ１８１に格納するのに適したデータの例は、たとえ漏洩しても被害が限定的な機密性の低いデータや、そもそも公開されていて機密性のないデータである。例えば、Ｗｅｂアプリケーション１０１がオンラインショッピングのアプリケーションの場合、商品は公開されているので、商品に関するデータは機密性がない。
また、「カート」テーブルのデータは、例えば、一時的に顧客のＩＤと商品のＩＤを対応づけるだけのデータかもしれない。すると、たとえ「カート」テーブルのデータが漏洩しても、顧客の住所や氏名などの個人情報そのものが漏洩するわけではないので、被害は限定的である。そして、限定的な被害ならば許容される場合もあり得る。よって、図１７の所在情報１０７の例では、「商品」テーブルと「カート」テーブルが「インターネット上のテーブル名」の項目に登録されている。
また、あるデータがＤＢ１２１とＤＢ１８１のどちらに格納される方が好ましいか、ということに関しては、データの機密性以外の観点もある。
例えば、頻繁にアクセスされるデータ（すなわち、読み書きが多く発生するデータ）は、ＤＢ１８１に格納するのに適している。なぜなら、ＤＢ１２１に格納されたデータをＷｅｂアプリケーション１０１が利用するためには、以下の（Ｅ１）〜（Ｅ４）の通信が生じるからである。
（Ｅ１）Ｗｅｂサーバ１００の振り分け部１０３から、クライアントマシン１１０のブラウザ１１１への、ＤＢアクセス要求の送信
（Ｅ２）ブラウザ１１１からＤＢサーバ１２０へのＤＢアクセス要求の送信
（Ｅ３）ＤＢサーバ１２０からブラウザ１１１へのＤＢアクセス結果の送信
（Ｅ４）ブラウザ１１１から振り分け部１０３へのＤＢアクセス結果の送信
つまり、頻繁にアクセスされるデータがＤＢ１２１に格納されている場合、頻繁に生じるアクセスのたびに（Ｅ１）〜（Ｅ４）の通信が生じる。その結果、Ｗｅｂサーバ１００とクライアントマシン１１０の間、およびイントラネット１４０内における通信トラフィックが増大する。通信トラフィックの増大は、例えば他のネットワークアプリケーションに悪影響を及ぼすおそれもある。
そして、もちろん通信には遅延がともなう。また、上記のとおり、Ｗｅｂサーバ１００とＤＢサーバ１８０の間のＲＴＴよりも、Ｗｅｂサーバ１００とクライアントマシン１１０の間のＲＴＴの方が大幅に長い。
よって、ＤＢ１８１内のデータが使われる場合よりも、ＤＢ１２１内のデータが使われる場合の方が、ユーザにとっての応答時間も長い。なお「ユーザにとっての応答時間」とは、ユーザがｉｆｒａｍｅ１１２内のページに対して、クリックや入力などの操作を行ってから、Ｗｅｂアプリケーション１０１から返された応答内容がｉｆｒａｍｅ１１２内に表示されるまでの時間のことである。
以上のとおりなので、頻繁にアクセスされるデータは、たとえデータサイズそのものが小さいとしても、通信トラフィックの抑制およびユーザにとっての利便性の観点からは、ＤＢ１８１に格納されることが好ましい。
逆に言えば、あまりアクセスされないデータは、ＤＢ１２１に格納されていても、ユーザにとっての利便性をあまり損なわない。また、あまりアクセスされないデータへのアクセスによって生じる通信トラフィックは、たとえデータサイズそのものが比較的大きいとしても、単位時間あたりでは少ない。
そして、ＳａａＳベンダ（あるいはＡＳＰ）によっては、ＤＢ１８１に格納されるデータの量に応じてユーザに課金する。すると、データサイズが大きいデータは、金銭コストの観点からは、ＤＢ１２１に格納されることが好ましい。
例えば、ある種のデータは、新しいエントリが次々と作成されて量が増えていく一方で、めったに参照されないかもしれない。例えば、ある種のログデータは、大量に蓄積されるが、めったに参照されないかもしれない。このようにデータサイズが大きく、かつ参照頻度の少ないデータは、金銭コストの観点からＤＢ１２１に格納されることが好ましい場合がある。そして、参照頻度の少ないデータは、たとえデータサイズが大きくても、ＤＢ１２１に格納されたことによって通信トラフィックやユーザの利便性にそれほど悪影響を与えない。
以上のように、各種のデータは、様々な観点から、「ＤＢ１２１とＤＢ１８１のどちらに格納する方が好ましいか」ということが異なる。そして、図１８〜１９に示した変形例によれば、データの特性に応じてＤＢ１２１またはＤＢ１８１の適切な方に各データが格納された環境において、Ｗｅｂアプリケーション１０１は、ＤＢ１２１とＤＢ１８１のいずれに格納されたデータも利用可能である。
また、Ｗｅｂアプリケーション１０１は、データがＤＢ１２１とＤＢ１８１のどちらに格納されているかを判断する必要がない。つまり、データの所在はＷｅｂアプリケーション１０１に対して隠蔽されている。よって、Ｗｅｂアプリケーション１０１は、ＤＢ１２１のデータに対しても、ＤＢ１８１のデータに対しても、同じロジックでＤＢアクセス要求を発行することができる。したがって、既存のＷｅｂアプリケーション１０１も、図１８のシステムにおいて利用可能である。
なお、図１９に関する上記の説明では簡単のため、「１つのＤＢアクセス要求では、ＤＢ１２１内のテーブルのみに対してアクセスが要求されるか、またはＤＢ１８１内のテーブルのみに対してアクセスが要求される」と仮定している。しかし、１つのＤＢアクセス要求が、ＤＢ１２１内の「注文」テーブルとＤＢ１８１内の「商品」テーブルの両方へのアクセスを要求する場合もあり得る。例えば、ＳＱＬのＳＥＬＥＣＴ文のＦＲＯＭ句に「注文」テーブルと「商品」テーブルの双方が指定されている場合、当該ＳＥＬＥＣＴ文は、ＤＢ１２１とＤＢ１８１の両方へのアクセスを要求するＤＢアクセス要求である。
１つのＤＢアクセス要求が、ＤＢ１２１内のテーブルとＤＢ１８１のテーブルの両方へのアクセスを要求する場合、ＤＢインタフェイス部１０２ａは、例えば以下の（Ｆ１）〜（Ｆ３）の処理を行ってもよい。
（Ｆ１）Ｗｅｂアプリケーション１０１から受け取ったＤＢアクセス要求から、ＤＢ１２１内のテーブルのみに対するＤＢアクセス要求を生成し、生成したＤＢアクセス要求を使ってステップＳ１１０５〜Ｓ１１０６の処理を行う処理。
（Ｆ２）Ｗｅｂアプリケーション１０１から受け取ったＤＢアクセス要求から、ＤＢ１８１内のテーブルのみに対するＤＢアクセス要求を生成し、生成したＤＢアクセス要求を使ってステップＳ１１０４の処理を行う処理。
（Ｆ３）Ｗｅｂアプリケーション１０１から受け取ったＤＢアクセス要求におけるテーブル結合の種類や結合条件に応じて、（Ｆ１）と（Ｆ２）でそれぞれ得られたＤＢアクセス結果から、最終的なＤＢアクセス結果を生成する処理。
なお、Ｗｅｂアプリケーション１０１から出力されたＤＢアクセス要求に指定されている結合条件（例えばＳＱＬ文のＷＨＥＲＥ句などに指定されている条件）に応じて、（Ｆ１）の処理が先に実行されてもよく、（Ｆ２）の処理が先に実行されてもよい。あるいは、結合条件によっては、（Ｆ１）と（Ｆ２）が並列に実行されてもよい。
また、（Ｆ３）の処理は、具体的には、直積演算や、Ｗｅｂアプリケーション１０１から出力されたＤＢアクセス要求に指定されている条件による絞り込み演算（すなわち選択演算）などを含む。
ところで、本発明は上記実施形態に限られるものではない。上記の説明においてもいくつかの変形について説明したが、上記実施形態は、さらに例えば下記の観点から様々に変形することもできる。そして、上記および下記の変形は、相互に矛盾しない限り、任意に組み合わせることが可能である。
変形の第１の観点は、データ構造に関する。例えば、図２には、対応表１０５の具体例として、対応表１０５ａがテーブル形式で図示されている。しかし、対応表１０５のデータ構造は実施形態に応じて任意であり、連想配列、線形リスト、その他の任意のデータ構造が利用可能である。
また、図２と図１７には設定ファイル１０６の具体例として設定ファイル１０６ａ〜１０６ｃがテーブル形式で図示されている。しかし、設定ファイル１０６のフォーマットも実施形態に応じて任意である。また、設定ファイル１０６がプライベートキーと所在情報１０７の双方を含んでいてもよい。
変形の第２の観点は、「複数のＤＢアクセス要求がどのように処理されるか」という観点である。１つのページの生成が複数のＤＢアクセス要求をともなう場合、図８のステップＳ４１７〜Ｓ４２７の一連の処理または図１３のステップＳ８１８〜Ｓ８２６の一連の処理が、ＤＢアクセス要求の数だけ繰り返されてもよい。しかし、Ｗｅｂアプリケーション１０１は、複数のＤＢアクセス要求をまとめて一度にＤＢインタフェイス部１０２に出力してもよい。
例えば、あるページの生成が５つのＳＱＬ文の実行をともなう場合、ステップＳ４１７〜Ｓ４２７の一連の処理またはステップＳ８１８〜Ｓ８２６の一連の処理が５回繰り返されてもよい。しかし、Ｗｅｂアプリケーション１０１は、５つのＳＱＬ文をデリミタ文字“；”で区切って１つに連結した文字列を、ステップＳ４１７またはステップＳ８１８でＤＢインタフェイス部１０２に出力してもよい。
すると、ＤＢインタフェイス部１０２から振り分け部１０３へ、振り分け部１０３からブラウザ１１１へ、そしてブラウザ１１１からＤＢサーバ１２０へ、と送られるＤＢアクセス要求は、５つのＳＱＬ文が連結された文字列により表される。そこで、ＤＢサーバ１２０は、５つのＳＱＬ文をそれぞれ実行し、５つのＳＱＬ文それぞれに対するＤＢアクセス結果を得る。そして、ＤＢサーバ１２０は、５つのＤＢアクセス結果を適宜のフォーマットにしたがって連結し、連結した５つのＤＢアクセス結果を、１つのＨＴＴＰ応答によりブラウザ１１１に返す。
すると、連結された５つのＤＢアクセス結果は、ブラウザ１１１から振り分け部１０３へ、振り分け部１０３からＤＢインタフェイス部１０２へ、ＤＢインタフェイス部１０２からＷｅｂアプリケーション１０１へと送られる。Ｗｅｂアプリケーション１０１は、５つのＤＢアクセス結果をそれぞれ抽出し、抽出したＤＢアクセス結果に基づいてページを生成し、生成したページをブラウザ１１１に返す。
以上のように、複数のＤＢアクセス要求がまとめて一緒に送信され、対応する複数のＤＢアクセス結果がまとめて一緒に返信されてもよい。すると、Ｗｅｂサーバ１００とクライアントマシン１１０の間およびクライアントマシン１１０とＤＢサーバ１２０の間の通信トラフィックの削減という効果が得られるし、ユーザにとっての応答時間の短縮という効果も得られる。
変形の第３の観点は、ＤＢの種類に関する。ＤＢ１２１とＤＢ１８１は、リレーショナルＤＢでもよいが、他の種類のＤＢでもよい。例えば、ＸＭＬＤＢ（Extensible Markup Language Database）またはＫＶＳ（Key-Value Store）が使われてもよい。ＤＢの種類に応じて、ＤＢアクセス要求を表す問い合わせ言語も異なる。
変形の第４の観点は、クロスドメイン非同期通信の具体的実装に関する。上記の説明では、具体的な実装例として、ＸＨＲオブジェクトによるＨＴＴＰ通信を利用する実施形態について詳しく説明した。しかし、具体的実装は実施形態に応じて様々であってよい。
例えば、クロスドメイン非同期通信のためには、上述のとおりレベル２のＸＨＲオブジェクトを用いる実装が採用されてもよい。しかし、実施形態によっては、ＪＳＯＮＰ（JavaScript Object Notation with Padding）またはＸＤＲ（XDomainRequest）オブジェクトを用いる実装が採用されてもよい。
変形の第５の観点は、タイムアウトに関する。Ｃｏｍｅｔコネクションの維持に関して、上記では説明を省略したが、タイムアウトによりコネクションが切れる場合もあり得る。そこで、タイムアウトを防ぐための適宜の変形、または、タイムアウトに応じて再びＨＴＴＰ要求をブラウザ１１１に送信させるための適宜の変形が、上記実施形態に適用されてもよい。
例えば、第１実施形態の振り分け部１０３は、ＤＢインタフェイス部１０２から一定時間以上ＤＢアクセス要求を受け取らない場合、子ページ４００の新たなチャンクとして、適宜のダミーデータを含むチャンクを送信してもよい。また、第２実施形態におけるメインルーチンの関数定義６０３は、ロングポーリング用のＨＴＴＰ要求がタイムアウトしたら、ロングポーリング用のＨＴＴＰ要求を送信しなおすためのコードを含んでいてもよい。
変形の第６の観点は、振り分け部１０３やＤＢインタフェイス部１０２の具体的実装に関する。具体的実装は実施形態に応じて様々に異なっていてよい。
例えば、振り分け部１０３がスレッドローカルな変数を使ってセッションＩＤを記憶する例について上記で説明したが、振り分け部１０３がセッションＩＤの認識するために他の実装が採用されてもよい。例えば、実施形態によっては、セッションＩＤはコールスタックに格納されていてもよい。
変形の第７の観点は、ＤＢアクセス代行スクリプト１１４に関する。第１実施形態に関して図９に例示した子ページ４００の送信においては、最初にアドレス代入文４０２と関数定義４０３を含むチャンク４０１が送信される。そして、その後は、ＤＢアクセス要求の発生のたびに、関数呼び出しステートメントのみを含む短い＜ｓｃｒｉｐｔ＞ブロックが送信される。このように関数定義４０３を利用することで、第１実施形態では、Ｗｅｂサーバ１００とクライアントマシン１１０の間の通信トラフィックが抑制される。
しかし、通信トラフィックが増えてもかまわないならば、次のような変形も可能である。すなわち、最初のチャンク４０１は＜ｓｃｒｉｐｔ＞ブロックを含まなくてもよい。その代わり、ＤＢアクセス要求の発生のたびに、（Ｇ１）〜（Ｇ３）をすべて含む＜ｓｃｒｉｐｔ＞ブロックがスクリプト生成部１０４により生成され、振り分け部１０３によりブラウザ１１１へと送信されてもよい。
（Ｇ１）アドレス代入文４０２
（Ｇ２）ＤＢアクセス要求を表すＳＱＬ文の文字列を変数ｓｑｌに代入する代入文
（Ｇ３）関数定義４０３の内容と同様の内容のスクリプト
また、図９では関数定義４０３の外にアドレス代入文４０２があり、図１４では関数定義６０２の外にアドレス代入文６０１がある。しかし、実施形態によっては、関数ｅｘｅｃｕｔｅ１（）またはｅｘｅｃｕｔｅ２（）が、引数としてイントラネット１４０内のＤＢサーバのアドレスを受け取るように変形されてもよい。
図１には１台のＤＢサーバ１２０のみが図示されているが、イントラネット１４０内に複数のＤＢサーバがあってもよい。そして、設定ファイル１０６には、テーブル名ごとにイントラネット１４０内のＤＢサーバのアドレス（つまりＵＲＩ）が記憶されていてもよい。
すると、第１実施形態のスクリプト生成部１０４は、次のように変形されてもよい。
すなわち、ＤＢアクセス要求を表すＳＱＬ文を振り分け部１０３から指定されたとき、スクリプト生成部１０４は、設定ファイル１０６を参照して、アクセス先のＤＢサーバのアドレスを特定する。そして、スクリプト生成部１０４は、特定したアドレスを引数として含む、関数ｅｘｅｃｕｔｅ１（）の呼び出しステートメントを生成する。
あるいは、第２実施形態の振り分け部１０３とスクリプト生成部１０４は、次のように変形されてもよい。
振り分け部１０３は、ＤＢアクセス要求をブラウザ１１１に送信するときに、ＤＢアクセス要求に応じたアクセス先のＤＢサーバのアドレスもブラウザ１１１に送信する。なお、振り分け部１０３は、設定ファイル１０６を参照することで、アクセス先のＤＢサーバのアドレスを特定することができる。
また、スクリプト生成部１０４は、次のように変形されたメインルーチンの関数定義６０３を生成する。すなわち、本変形例の関数ｍａｉｎ（）は、ＨＴＴＰ応答から、ＤＢアクセス要求を表すＳＱＬ文とともにＤＢサーバのアドレスを抽出し、抽出したＳＱＬ文とアドレスを引数として関数ｅｘｅｃｕｔｅ２（）を呼び出すように、定義される。
なお、もちろん関数名や変数名は実施形態に応じて任意に変更してよい。
変形の第８の観点は、予約されるパスに関する。
第１実施形態では、図１１のステップＳ６０５に示すように、子ページ４００の読み込み要求とＤＢアクセス結果の通知がメソッドにより区別される。しかし、子ページ４００の読み込み要求とＤＢアクセス結果の通知が、第２実施形態のようにパスによって区別されてもよい。
つまり、第１実施形態は、２つの予約されたパスを使うように変形されてもよい。そして、振り分け部１０３は、受信したＨＴＴＰ要求に指定されたＵＲＩに含まれるパスのみから、受信したＨＴＴＰ要求が、子ページ４００の読み込み要求か、ＤＢアクセス結果の通知か、Ｗｅｂアプリケーション１０１に対する要求か、を判断してもよい。
逆に、第２実施形態では、上記（Ｂ１）〜（Ｂ３）の３つのパスが予約され、使われているが、予約されるパスは２つでもよい。
例えば、（Ｂ１）のｉｆｒａｍｅ１１３用のパスと、（Ｂ３）のＤＢアクセス結果の通知用のパスが同じであってもよい。その場合、ｉｆｒａｍｅ１１３への子ページ６００の読み込み要求ではＧＥＴメソッドが指定され、ＤＢアクセス結果の通知ではＰＯＳＴメソッドが指定されるので、振り分け部１０３は、メソッドに基づいて、子ページ６００の読み込み要求とＤＢアクセス結果の通知を区別することができる。
あるいは、（Ｂ１）のｉｆｒａｍｅ１１３用のパスと、（Ｂ２）のロングポーリング用のＨＴＴＰ要求を受け付けるためのパスが同じであってもよい。ロングポーリング用のＨＴＴＰ要求のメソッドとしては、第２実施形態ではＧＥＴメソッドが使われるが、ＰＯＳＴメソッドが使われる場合でもロングポーリングは可能である。
そこで、（Ｂ１）と（Ｂ２）のパスが同じ場合、ｉｆｒａｍｅ１１３への子ページ６００の読み込み要求ではＧＥＴメソッドが指定され、ロングポーリング用のＨＴＴＰ要求ではＰＯＳＴメソッドが指定されてもよい。振り分け部１０３は、ロングポーリング用のＨＴＴＰ要求のメッセージボディを無視して、単にＨＴＴＰ応答を返すときにＨＴＴＰ応答のメッセージボディにＤＢアクセス要求を示す文字列（例えばＳＱＬ文）を設定すればよい。振り分け部１０３は、メソッドに基づいて、子ページ６００の読み込み要求とロングポーリング用のＨＴＴＰ要求を区別することができる。
なお、本明細書および図面におけるパスの具体例は単なる例示である。実施形態に応じて任意に決められたパスが「特定要求」のための「特定のパス」として使われてよい。また、第２実施形態のように（Ｂ１）〜（Ｂ３）の３つのパスが予約される場合、３つのパスは任意に決められてよい。
例えば、上記に例示した“／＿ｒｅｓｅｒｖｅｄＦｏｒＣｏｍｅｔ”などのパスは、Ｗｅｂサーバ１００のドキュメントルートの直下のパスだが、ドキュメントルートの直下ではないパスも利用可能である。また、上記に例示したパスは拡張子を含まないが、もちろん拡張子を含むパスが利用されてもよい。
また、上記ではブラウザ１１１から振り分け部１０３が受信したＨＴＴＰ要求の種類を区別するために、パスとメソッドが使われる。しかし、ＵＲＩに含まれるパスとクエリ・ストリングの組み合わせによりＨＴＴＰ要求の種類が区別される実施形態も可能である。
変形の第９の観点はマルチテナンシ（multi-tenancy）に関する。上記の説明においては、Ｗｅｂアプリケーション１０１がマルチテナント環境に対応しているか否かについて特に言及しなかった。しかし、次のような変形により、マルチテナント型のＷｅｂアプリケーション１０１にも上記実施形態は適用可能である。
すなわち、テナントごとに予め用意された複数の設定ファイル１０６がＷｅｂサーバ１００に記憶される。また、上記のとおり、実施形態に応じて１つ、２つ、または３つの予約されたパスが使われるが、各テナントごとに異なるパスが予約される。さらに、Ｗｅｂサーバ１００には、各テナントについて、当該テナントのＩＤと、当該テナント用に予約されたパスと、当該テナント用の設定ファイル１０６とを対応づける情報が予め格納される。
すると、振り分け部１０３は、ＨＴＴＰ要求を受信したとき、受信したＨＴＴＰ要求がどのテナント用に予約されたパスへの要求であるかに応じて、どのテナントのブラウザ１１１からＨＴＴＰ要求を受信したのかを認識することができる。したがって、振り分け部１０３は、スクリプト生成部１０４にスクリプトの生成を指示する場合に、どの設定ファイル１０６からＤＢアドレスを読み出せばよいかを正しく指示することができる。
また、図２のように設定ファイル１０６においてプライベートＩＰアドレスを含むＵＲＩが使われることは、マルチテナント環境におけるセキュリティ保持にも有益である。なぜなら、たとえ第１のテナントのブラウザが第２のテナント用に予約されたパスにアクセスしたとしても、第１のテナントのブラウザがプライベートＩＰアドレスを使ってアクセス可能なのは、第１のテナントにとってのイントラネット内部のみだからである。つまり、たとえ第１のテナントのブラウザが第２のテナント用に予約されたパスにアクセスしたとしても、第１のテナントのブラウザから第２のテナントのＤＢサーバがアクセスされることはない。
さらに、マルチテナント環境においては、振り分け部１０３は、ブラウザ１１１がどのテナントに属するかを判断し、テナントに応じた処理を行ってもよい。ＨＴＴＰ要求はＩＰパケットの中にカプセル化されているので、振り分け部１０３は、ブラウザ１１１から受け取ったＨＴＴＰ要求の送信元ＩＰアドレスから、ブラウザ１１１がどのテナントに属するかを判断することもできる。
変形の第１０の観点はブラウザ１１１に関する。図１のブラウザ１１１は、汎用的なＷｅｂブラウザであってもよい。しかし、汎用的なＷｅｂブラウザ以外の、例えば「リッチクライアント」と呼ばれるタイプのクライアントが、ブラウザ１１１の代わりに使われてもよい。そして、リッチクライアントに対応するサーバサイド・アプリケーションがＷｅｂアプリケーション１０１の代わりに使われてもよい。
ブラウザ１１１の代わりにリッチクライアントが使われる場合であっても、リッチクライアントが特定要求をＷｅｂサーバに送信することを契機にコネクションが確立される。そして、確立されたコネクションを介して、ＷｅｂサーバがＤＢアクセス要求をリッチクライアントに送信する。すると、リッチクライアントがＤＢアクセス代行スクリプトにしたがってＤＢアクセスを代行してＤＢアクセス結果をＷｅｂサーバに送信する。
なお、以上説明した第１０の観点について補足すれば、以下のとおりである。
Ｗｅｂサーバ１００は、ＤＢアクセスを制御するサーバサイドの制御装置の一例である。また、クライアントマシン１１０あるいはブラウザ１１１は、クライアントの一例である。
そして、振り分け部１０３は、クライアントから、特定のパスへのアクセスを求める特定要求を受け付ける第１の受付手段の一例である。また、振り分け部１０３は、クライアントと制御装置との間のコネクションを、第１の受付手段による特定要求の受付を契機として確立する確立手段の一例でもある。
そして、ＤＢインタフェイス部１０２と振り分け部１０３は協働して、クライアントのアクセス先であるアプリケーションがＤＢへのアクセスを求めるＤＢアクセス要求をアプリケーションから受け付ける第２の受付手段として動作する。
さらに、スクリプト生成部１０４を含む振り分け部１０３は、次のような送信手段としても動作する。すなわち、送信手段はスクリプトをクライアントに送信する。当該スクリプトは、ＤＢアクセス要求にしたがってＤＢにアクセスし、ＤＢアクセス結果をＤＢから取得し、制御装置にＤＢアクセス結果を送信する処理を、クライアントに実行させるためのものである。また、送信手段は、ＤＢアクセス要求を、スクリプトに含めて、またはスクリプトとは別に、確立手段により確立された上記コネクションを介してクライアントに送信する。
さらに、ＤＢインタフェイス部１０２と振り分け部１０３は協働して、クライアントからＤＢアクセス結果を受信して、ＤＢアクセス結果をアプリケーションに出力する出力手段としても動作する。
以上、変形例も含めて様々な実施形態について説明したが、いずれの実施形態においても、以下のような利点がある。
第１に、イントラネット１４０内のＤＢ１２１のデータを使ってＷｅｂアプリケーション１０１が処理を行うことが可能だが、ＤＢ１２１のデータは外部ネットワーク１５０上に不揮発的に蓄積されることはない。したがって、外部ネットワーク１５０からの情報漏洩のリスクはほとんどない。
第２に、Ｗｅｂサーバ１００とクライアントマシン１１０以外の、中継サーバ等の付加的な装置が不要である。したがって、上述の各種実施形態は、コスト、保守性、可用性などが優れている。
第３に、ファイアウォール１３０の設定を変更する必要がない。ファイアウォール１３０の設定の変更は、うっかり間違えるとセキュリティホールを作ってしまうことになりかねないので、設定変更が不要なことは利点である。
そして、以上例示した利点は、Ｗｅｂアプリケーション１０１の利用促進を図るうえで有益である。その理由は以下のとおりである。
近年では、企業が社内のイントラネットにＷｅｂアプリケーションをデプロイして利用する代わりに、インターネットを介してＳａａＳベンダなどが提供するＷｅｂアプリケーションを利用する事例も増えつつある。一方で、企業は、社外のネットワークに機密情報が保存されることを嫌う。
しかし、上述の各種実施形態によれば、ＤＢ１２１は企業のイントラネット１４０内にあり、かつ、外部ネットワーク１５０のＷｅｂアプリケーション１０１が利用可能である。したがって、上述の各種実施形態は、企業ユーザにおけるＷｅｂアプリケーション１０１の利用促進を図るうえで有益である。
最後に、上記の種々の実施形態に関して、さらに下記の付記を開示する。
（付記１）
第１のコンピュータに、
第２のコンピュータから、特定のパスへのアクセスを求める特定要求を受け付け、
前記第２のコンピュータと前記第１のコンピュータとの間のコネクションを、前記特定要求の受付を契機として確立し、
前記第２のコンピュータのアクセス先であるアプリケーションが第１のデータベースへのアクセスを求める第１のデータベースアクセス要求を、前記アプリケーションから受け付け、
前記第１のデータベースアクセス要求にしたがって前記第１のデータベースにアクセスし、第１のデータベースアクセス結果を前記第１のデータベースから取得し、前記第１のコンピュータに前記第１のデータベースアクセス結果を送信する代行処理を、前記第２のコンピュータに実行させるための実行命令スクリプトを、前記第２のコンピュータに送信し、
前記第１のデータベースアクセス要求を、前記実行命令スクリプトに含めて、または前記実行命令スクリプトとは別に、前記コネクションを介して前記第２のコンピュータに送信することで、前記代行処理を前記第２のコンピュータに実行させ、
前記第２のコンピュータから前記第１のデータベースアクセス結果を受信し、
前記第１のデータベースアクセス結果を前記アプリケーションに出力する
ことを含む制御処理を実行させるプログラム。
（付記２）
前記第２のコンピュータから、前記第１のコンピュータへのアクセスを求めるアクセス要求を受け付け、
前記アクセス要求に対応するセッションが存在するか否かを判断し、
前記セッションが存在しない場合、
新規セッションを生成し、
前記第２のコンピュータを前記特定のパスにアクセスさせるための第１のコードと、前記アプリケーションのページを第２のコンピュータに表示させるための第２のコードを、前記第２のコンピュータに送信し、
前記セッションが存在する場合、
前記アクセス要求が前記特定要求ならば、確立した前記コネクションを前記セッションと対応づけて記憶手段に記憶し、
前記アクセス要求が前記アプリケーションに対する要求ならば、前記アクセス要求を前記アプリケーションに出力する
ことを前記制御処理がさらに含むことを特徴とする付記１に記載のプログラム。
（付記３）
前記第１のコードは、前記特定のパスを第１のフレームのソースとして指定するコードであり、
前記第２のコードは、前記第２のコンピュータに、第２のフレームの中に前記アプリケーションの前記ページを表示させるためのコードである
ことを特徴とする付記２に記載のプログラム。
（付記４）
前記第１のデータベースアクセス要求を前記アプリケーションから受け付けると、前記セッションを識別するセッション識別情報を認識し、
前記記憶手段を検索することにより、前記セッション識別情報で識別される前記セッションと対応づけられた前記コネクションを特定する
ことを前記制御処理がさらに含み、
前記第１のデータベースアクセス要求を含む前記実行命令スクリプトが、特定された前記コネクションを介して前記第２のコンピュータに送信される
ことを特徴とする付記２または３に記載のプログラム。
（付記５）
前記第１のデータベースアクセス要求を受け付ける前に予め、前記代行処理のための関数の定義を含む定義スクリプトを、前記コネクションを介して前記第２のコンピュータに送信することを前記制御処理がさらに含み、
前記実行命令スクリプトは、前記第１のデータベースアクセス要求を表す引数を指定して前記関数の実行を命令するステートメントを含む
ことを特徴とする付記１から４のいずれか１項に記載のプログラム。
（付記６）
前記第２のコンピュータから、前記第１のコンピュータへのアクセスを求めるアクセス要求を受け付け、
前記アクセス要求に対応するセッションが存在するか否かを判断し、
前記セッションが存在しない場合、
新規セッションを生成し、
前記第２のコンピュータを前記特定のパスにアクセスさせるための第１のコードを前記第２のコンピュータに取得させるためのコードと、前記アプリケーションのページを第２のコンピュータに表示させるための第２のコードを、前記第２のコンピュータに送信し、
前記セッションが存在する場合、
前記アクセス要求が前記特定要求ならば、確立した前記コネクションを前記セッションと対応づけて記憶手段に記憶し、
前記アクセス要求が前記第１のコードを取得するための要求ならば、前記第１のコードを生成して前記第２のコンピュータに送信し、
前記アクセス要求が前記アプリケーションに対する要求ならば、前記アクセス要求を前記アプリケーションに出力する
ことを前記制御処理がさらに含むことを特徴とする付記１に記載のプログラム。
（付記７）
前記第１のコードは、前記第２のコンピュータに、前記特定要求を前記第１のコンピュータに繰り返し送信させるためのスクリプトを含む
ことを特徴とする付記６に記載のプログラム。
（付記８）
前記第１のデータベースアクセス要求を前記アプリケーションから受け付けると、前記セッションを識別するセッション識別情報を認識し、
前記セッション識別情報で識別される前記セッションと対応づけられた前記コネクションを特定する
ことを前記制御処理がさらに含み、
前記第１のデータベースアクセス要求は、前記実行命令スクリプトとは別に、特定された前記コネクションを介して前記第２のコンピュータに送信される
ことを特徴とする付記６または７に記載のプログラム。
（付記９）
前記制御処理は、
前記特定要求を受け付けた後、前記第１のデータベースアクセス要求を受け付けるまでは、前記特定要求への応答である特定応答の送信を延期し、
前記特定応答に、前記第１のデータベースアクセス要求を含め、
前記特定応答を前記第２のコンピュータに送信する
ことをさらに含み、
前記実行命令スクリプトは、前記第２のコンピュータに、
前記特定応答の受信を待ち、
前記特定応答を受信したら、前記特定応答から、前記第１のデータベースアクセス要求を抽出し、
抽出した前記第１のデータベースアクセス要求にしたがって前記代行処理を実行する
ことを含む処理を実行させる
ことを特徴とする付記１、６、７または８に記載のプログラム。
（付記１０）
第２のデータベースへのアクセスを求める第２のデータベースアクセス要求を前記アプリケーションから受け付け、
前記第２のデータベースアクセス要求にしたがって前記第２のデータベースにアクセスし、
第２のデータベースアクセス結果を前記第２のデータベースから取得し、
前記第２のデータベースアクセス結果を前記アプリケーションに出力する
ことを前記制御処理がさらに含む
ことを特徴とする付記１から９のいずれか１項に記載のプログラム。
（付記１１）
前記アプリケーションから受け付ける各データベースアクセス要求について、
前記第１のデータベースが含む各テーブルの識別情報を前記第１のデータベースと対応づけるとともに、前記第２のデータベースが含む各テーブルの識別情報を前記第２のデータベースと対応づける所在情報を参照し、
当該データベースアクセス要求が、前記第１のデータベースへのアクセスを求める要求なのか、それとも前記第２のデータベースへのアクセスを求める要求なのかを、前記所在情報を用いて判断する
ことを前記制御処理がさらに含むことを特徴とする付記１０に記載のプログラム。
（付記１２）
前記制御処理は、署名を前記第２のコンピュータに送信することをさらに含み、
前記代行処理における前記第２のコンピュータから前記第１のデータベースへのアクセスは、前記第２のコンピュータが前記第１のコンピュータから受信した前記署名を、前記第１のデータベースを管理する第３のコンピュータに送信することを含み、
前記署名は前記第３のコンピュータによる認証処理に使われる
ことを特徴とする付記１から１１のいずれか１項に記載のプログラム。
（付記１３）
サーバサイドの制御装置であって、
クライアントから、特定のパスへのアクセスを求める特定要求を受け付ける第１の受付手段と、
前記クライアントと前記制御装置との間のコネクションを、前記第１の受付手段による前記特定要求の受付を契機として確立する確立手段と、
前記クライアントのアクセス先であるアプリケーションがデータベースへのアクセスを求めるデータベースアクセス要求を、前記アプリケーションから受け付ける第２の受付手段と、
前記データベースアクセス要求にしたがって前記データベースにアクセスし、データベースアクセス結果を前記データベースから取得し、前記制御装置に前記データベースアクセス結果を送信する処理を、前記クライアントに実行させるためのスクリプトを、前記クライアントに送信し、
前記データベースアクセス要求を、前記スクリプトに含めて、または前記スクリプトとは別に、前記コネクションを介して前記クライアントに送信する送信手段と、
前記クライアントから前記データベースアクセス結果を受信して、前記データベースアクセス結果を前記アプリケーションに出力する出力手段
を備えることを特徴とする制御装置。
（付記１４）
第１のコンピュータが、
第２のコンピュータから、特定のパスへのアクセスを求める特定要求を受け付け、
前記第２のコンピュータと前記第１のコンピュータとの間のコネクションを、前記特定要求の受付を契機として確立し、
前記第２のコンピュータのアクセス先であるアプリケーションがデータベースへのアクセスを求めるデータベースアクセス要求を、前記アプリケーションから受け付け、
前記データベースアクセス要求にしたがって前記データベースにアクセスし、データベースアクセス結果を前記データベースから取得し、前記第１のコンピュータに前記データベースアクセス結果を送信する処理を、前記第２のコンピュータに実行させるためのスクリプトを、前記第２のコンピュータに送信し、
前記データベースアクセス要求を、前記スクリプトに含めて、または前記スクリプトとは別に、前記コネクションを介して前記第２のコンピュータに送信することで、前記処理を前記第２のコンピュータに実行させ、
前記第２のコンピュータから前記データベースアクセス結果を受信し、
前記データベースアクセス結果を前記アプリケーションに出力する
ことを特徴とする方法。
１００、１６０ Ｗｅｂサーバ
１０１ Ｗｅｂアプリケーション
１０２、１０２ａ ＤＢインタフェイス部
１０３ 振り分け部
１０４ スクリプト生成部
１０５、１０５ａ 対応表
１０６、１０６ａ〜１０６ｃ 設定ファイル
１０７ 所在情報
１１０ クライアントマシン
１１１ ブラウザ
１１２、１１３ ｉｆｒａｍｅ
１１４ ＤＢアクセス代行スクリプト
１２０、１７０、１８０ ＤＢサーバ
１２１、１８１ ＤＢ
１３０ ファイアウォール
１４０ イントラネット
１５０ 外部ネットワーク
１６１ ＤＢライブラリ
２００ コンピュータ
２０１ ＣＰＵ
２０２ メモリ
２０３ ネットワーク接続装置
２０４ 入力装置
２０５ 出力装置
２０６ 記憶装置
２０７ 駆動装置
２０８ バス
２１０ 可搬型記憶媒体
２２０ ネットワーク
３００、５００ 親ページ
３０１、３０２、５０１、５０２ ＜ｉｆｒａｍｅ＞ブロック
４００、６００ 子ページ
４０１ チャンク
４０２、６０１ アドレス代入文
４０３、６０２、６０３ 関数定義
４０４、４０５、６０４ ＜ｓｃｒｉｐｔ＞ブロック

Claims (7)

  1. 第１のコンピュータに、
    第２のコンピュータから、特定のパスへのアクセスを求める特定要求を受け付け、
    前記第２のコンピュータと前記第１のコンピュータとの間のコネクションを、前記特定要求の受付を契機として確立し、
    前記第２のコンピュータのアクセス先であるアプリケーションが第１のデータベースへのアクセスを求める第１のデータベースアクセス要求を、前記アプリケーションから受け付け、
    前記第１のデータベースアクセス要求にしたがって前記第１のデータベースにアクセスし、第１のデータベースアクセス結果を前記第１のデータベースから取得し、前記第１のコンピュータに前記第１のデータベースアクセス結果を送信する代行処理を、前記第２のコンピュータに実行させるための実行命令スクリプトを、前記第２のコンピュータに送信し、
    前記第１のデータベースアクセス要求を、前記実行命令スクリプトに含めて、または前記実行命令スクリプトとは別に、前記コネクションを介して前記第２のコンピュータに送信することで、前記代行処理を前記第２のコンピュータに実行させ、
    前記第２のコンピュータから前記第１のデータベースアクセス結果を受信し、
    前記第１のデータベースアクセス結果を前記アプリケーションに出力し、
    前記第２のコンピュータから、前記第１のコンピュータへのアクセスを求める第１のコンピュータアクセス要求を受け付け、
    前記第１のコンピュータアクセス要求に対応するセッションが存在するか否かを判断し、
    前記セッションが存在しない場合、
    新規セッションを生成し、
    前記第２のコンピュータを前記特定のパスにアクセスさせるための第１のコードと、前記アプリケーションのページを第２のコンピュータに表示させるための第２のコードを、前記第２のコンピュータに送信し、
    前記セッションが存在する場合、
    前記第１のコンピュータアクセス要求が前記特定要求ならば、確立した前記コネクションを前記セッションと対応づけて記憶手段に記憶し、
    前記第１のコンピュータアクセス要求が前記アプリケーションに対する要求ならば、前記第１のコンピュータアクセス要求を前記アプリケーションに出力する
    ことを含む制御処理を実行させるプログラム。
  2. 第１のコンピュータに、
    第２のコンピュータから、特定のパスへのアクセスを求める特定要求を受け付け、
    前記第２のコンピュータと前記第１のコンピュータとの間のコネクションを、前記特定要求の受付を契機として確立し、
    前記第２のコンピュータのアクセス先であるアプリケーションが第１のデータベースへのアクセスを求める第１のデータベースアクセス要求を、前記アプリケーションから受け付け、
    前記第１のデータベースアクセス要求にしたがって前記第１のデータベースにアクセスし、第１のデータベースアクセス結果を前記第１のデータベースから取得し、前記第１のコンピュータに前記第１のデータベースアクセス結果を送信する代行処理を、前記第２のコンピュータに実行させるための実行命令スクリプトを、前記第２のコンピュータに送信し、
    前記第１のデータベースアクセス要求を、前記実行命令スクリプトに含めて、または前記実行命令スクリプトとは別に、前記コネクションを介して前記第２のコンピュータに送信することで、前記代行処理を前記第２のコンピュータに実行させ、
    前記第２のコンピュータから前記第１のデータベースアクセス結果を受信し、
    前記第１のデータベースアクセス結果を前記アプリケーションに出力し、
    前記第２のコンピュータから、前記第１のコンピュータへのアクセスを求める第１のコンピュータアクセス要求を受け付け、
    前記第１のコンピュータアクセス要求に対応するセッションが存在するか否かを判断し、
    前記セッションが存在しない場合、
    新規セッションを生成し、
    前記第２のコンピュータを前記特定のパスにアクセスさせるための第１のコードを前記第２のコンピュータに取得させるためのコードと、前記アプリケーションのページを第２のコンピュータに表示させるための第２のコードを、前記第２のコンピュータに送信し、
    前記セッションが存在する場合、
    前記第１のコンピュータアクセス要求が前記特定要求ならば、確立した前記コネクションを前記セッションと対応づけて記憶手段に記憶し、
    前記第１のコンピュータアクセス要求が前記第１のコードを取得するための要求ならば、前記第１のコードを生成して前記第２のコンピュータに送信し、
    前記第１のコンピュータアクセス要求が前記アプリケーションに対する要求ならば、前記第１のコンピュータアクセス要求を前記アプリケーションに出力する
    ことを含む制御処理を実行させるプログラム。
  3. 第２のデータベースへのアクセスを求める第２のデータベースアクセス要求を前記アプリケーションから受け付け、
    前記第２のデータベースアクセス要求にしたがって前記第２のデータベースにアクセスし、
    第２のデータベースアクセス結果を前記第２のデータベースから取得し、
    前記第２のデータベースアクセス結果を前記アプリケーションに出力する
    ことを前記制御処理がさらに含む
    ことを特徴とする請求項１または２に記載のプログラム。
  4. サーバサイドの制御装置であって、
    クライアントから、特定のパスへのアクセスを求める特定要求を受け付ける第１の受付手段と、
    前記クライアントと前記制御装置との間のコネクションを、前記第１の受付手段による前記特定要求の受付を契機として確立する確立手段と、
    前記クライアントのアクセス先であるアプリケーションがデータベースへのアクセスを求めるデータベースアクセス要求を、前記アプリケーションから受け付ける第２の受付手段と、
    前記データベースアクセス要求にしたがって前記データベースにアクセスし、データベースアクセス結果を前記データベースから取得し、前記制御装置に前記データベースアクセス結果を送信する処理を、前記クライアントに実行させるためのスクリプトを、前記クライアントに送信し、
    前記データベースアクセス要求を、前記スクリプトに含めて、または前記スクリプトとは別に、前記コネクションを介して前記クライアントに送信する第１の送信手段と、
    前記クライアントから前記データベースアクセス結果を受信して、前記データベースアクセス結果を前記アプリケーションに出力する第１の出力手段と、
    前記クライアントから、前記制御装置へのアクセスを求める制御装置アクセス要求を受け付ける第３の受付手段と、
    前記制御装置アクセス要求に対応するセッションが存在するか否かを判断する判断手段と、
    前記セッションが存在しない場合に、新規セッションを生成する生成手段と、
    前記セッションが存在しない場合に、前記クライアントを前記特定のパスにアクセスさせるための第１のコードと、前記アプリケーションのページをクライアントに表示させるための第２のコードを、前記クライアントに送信する第２の送信手段と、
    前記セッションが存在する場合であって、且つ、前記制御装置アクセス要求が前記特定要求である場合に、確立した前記コネクションを前記セッションと対応づけて記憶する記憶手段と、
    前記セッションが存在する場合であって、且つ、前記制御装置アクセス要求が前記アプリケーションに対する要求である場合に、前記制御装置アクセス要求を前記アプリケーションに出力する第２の出力手段
    を備えることを特徴とする制御装置。
  5. サーバサイドの制御装置であって、
    クライアントから、特定のパスへのアクセスを求める特定要求を受け付ける第１の受付手段と、
    前記クライアントと前記制御装置との間のコネクションを、前記第１の受付手段による前記特定要求の受付を契機として確立する確立手段と、
    前記クライアントのアクセス先であるアプリケーションがデータベースへのアクセスを求めるデータベースアクセス要求を、前記アプリケーションから受け付ける第２の受付手段と、
    前記データベースアクセス要求にしたがって前記データベースにアクセスし、データベースアクセス結果を前記データベースから取得し、前記制御装置に前記データベースアクセス結果を送信する処理を、前記クライアントに実行させるためのスクリプトを、前記クライアントに送信し、
    前記データベースアクセス要求を、前記スクリプトに含めて、または前記スクリプトとは別に、前記コネクションを介して前記クライアントに送信する第１の送信手段と、
    前記クライアントから前記データベースアクセス結果を受信して、前記データベースアクセス結果を前記アプリケーションに出力する第１の出力手段と、
    前記クライアントから、前記制御装置へのアクセスを求める制御装置アクセス要求を受け付ける第３の受付手段と、
    前記制御装置アクセス要求に対応するセッションが存在するか否かを判断する判断手段と、
    前記セッションが存在しない場合に、新規セッションを生成する生成手段と、
    前記セッションが存在しない場合に、前記クライアントを前記特定のパスにアクセスさせるための第１のコードを前記クライアントに取得させるためのコードと、前記アプリケーションのページをクライアントに表示させるための第２のコードを、前記クライアントに送信する第２の送信手段と、
    前記セッションが存在する場合であって、且つ、前記制御装置アクセス要求が前記特定要求である場合に、確立した前記コネクションを前記セッションと対応づけて記憶する記憶手段と、
    前記セッションが存在する場合であって、且つ、前記制御装置アクセス要求が前記第１のコードを取得するための要求である場合に、前記第１のコードを生成して前記第２のコンピュータに送信する第３の送信手段と、
    前記セッションが存在する場合であって、且つ、前記制御装置アクセス要求が前記アプリケーションに対する要求である場合に、前記制御装置アクセス要求を前記アプリケーションに出力する第２の出力手段と、
    を備えることを特徴とする制御装置。
  6. 第１のコンピュータが、
    第２のコンピュータから、特定のパスへのアクセスを求める特定要求を受け付け、
    前記第２のコンピュータと前記第１のコンピュータとの間のコネクションを、前記特定要求の受付を契機として確立し、
    前記第２のコンピュータのアクセス先であるアプリケーションがデータベースへのアクセスを求めるデータベースアクセス要求を、前記アプリケーションから受け付け、
    前記データベースアクセス要求にしたがって前記データベースにアクセスし、データベースアクセス結果を前記データベースから取得し、前記第１のコンピュータに前記データベースアクセス結果を送信する処理を、前記第２のコンピュータに実行させるためのスクリプトを、前記第２のコンピュータに送信し、
    前記データベースアクセス要求を、前記スクリプトに含めて、または前記スクリプトとは別に、前記コネクションを介して前記第２のコンピュータに送信することで、前記処理を前記第２のコンピュータに実行させ、
    前記第２のコンピュータから前記データベースアクセス結果を受信し、
    前記データベースアクセス結果を前記アプリケーションに出力し、
    前記第２のコンピュータから、前記第１のコンピュータへのアクセスを求める第１のコンピュータアクセス要求を受け付け、
    前記第１のコンピュータアクセス要求に対応するセッションが存在するか否かを判断し、
    前記セッションが存在しない場合、
    新規セッションを生成し、
    前記第２のコンピュータを前記特定のパスにアクセスさせるための第１のコードと、前記アプリケーションのページを第２のコンピュータに表示させるための第２のコードを、前記第２のコンピュータに送信し、
    前記セッションが存在する場合、
    前記第１のコンピュータアクセス要求が前記特定要求ならば、確立した前記コネクションを前記セッションと対応づけて記憶手段に記憶し、
    前記第１のコンピュータアクセス要求が前記アプリケーションに対する要求ならば、前記第１のコンピュータアクセス要求を前記アプリケーションに出力する
    ことを特徴とする方法。
  7. 第１のコンピュータが、
    第２のコンピュータから、特定のパスへのアクセスを求める特定要求を受け付け、
    前記第２のコンピュータと前記第１のコンピュータとの間のコネクションを、前記特定要求の受付を契機として確立し、
    前記第２のコンピュータのアクセス先であるアプリケーションがデータベースへのアクセスを求めるデータベースアクセス要求を、前記アプリケーションから受け付け、
    前記データベースアクセス要求にしたがって前記データベースにアクセスし、データベースアクセス結果を前記データベースから取得し、前記第１のコンピュータに前記データベースアクセス結果を送信する処理を、前記第２のコンピュータに実行させるためのスクリプトを、前記第２のコンピュータに送信し、
    前記データベースアクセス要求を、前記スクリプトに含めて、または前記スクリプトとは別に、前記コネクションを介して前記第２のコンピュータに送信することで、前記処理を前記第２のコンピュータに実行させ、
    前記第２のコンピュータから前記データベースアクセス結果を受信し、
    前記データベースアクセス結果を前記アプリケーションに出力し、
    前記第２のコンピュータから、前記第１のコンピュータへのアクセスを求める第１のコンピュータアクセス要求を受け付け、
    前記第１のコンピュータアクセス要求に対応するセッションが存在するか否かを判断し、
    前記セッションが存在しない場合、
    新規セッションを生成し、
    前記第２のコンピュータを前記特定のパスにアクセスさせるための第１のコードを前記第２のコンピュータに取得させるためのコードと、前記アプリケーションのページを第２のコンピュータに表示させるための第２のコードを、前記第２のコンピュータに送信し、
    前記セッションが存在する場合、
    前記第１のコンピュータアクセス要求が前記特定要求ならば、確立した前記コネクションを前記セッションと対応づけて記憶手段に記憶し、
    前記第１のコンピュータアクセス要求が前記第１のコードを取得するための要求ならば、前記第１のコードを生成して前記第２のコンピュータに送信し、
    前記第１のコンピュータアクセス要求が前記アプリケーションに対する要求ならば、前記第１のコンピュータアクセス要求を前記アプリケーションに出力する
    ことを特徴とする方法。
JP2011058539A 2011-03-16 2011-03-16 プログラム、制御装置および方法 Expired - Fee Related JP5617709B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2011058539A JP5617709B2 (ja) 2011-03-16 2011-03-16 プログラム、制御装置および方法
US13/329,837 US8825703B2 (en) 2011-03-16 2011-12-19 Control device, control method, and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2011058539A JP5617709B2 (ja) 2011-03-16 2011-03-16 プログラム、制御装置および方法

Publications (2)

Publication Number Publication Date
JP2012194809A JP2012194809A (ja) 2012-10-11
JP5617709B2 true JP5617709B2 (ja) 2014-11-05

Family

ID=46829328

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2011058539A Expired - Fee Related JP5617709B2 (ja) 2011-03-16 2011-03-16 プログラム、制御装置および方法

Country Status (2)

Country Link
US (1) US8825703B2 (ja)
JP (1) JP5617709B2 (ja)

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014126982A (ja) * 2012-12-26 2014-07-07 Nec System Technologies Ltd 端末装置、外部機器の制御方法、及びプログラム
US9591056B2 (en) * 2013-01-29 2017-03-07 Facebook, Inc. Techniques for contact exporting
US11017069B2 (en) * 2013-03-13 2021-05-25 Lookout, Inc. Method for changing mobile communications device functionality based upon receipt of a second code and the location of a key device
CN104090897B (zh) * 2013-12-19 2016-05-04 深圳市腾讯计算机系统有限公司 访问元数据的方法、服务器及系统
JP5962702B2 (ja) * 2014-05-09 2016-08-03 コニカミノルタ株式会社 画像形成装置、ウエブアプリケーションシステムおよびプログラム
JP6603513B2 (ja) 2014-09-03 2019-11-06 キヤノン株式会社 通信装置及び情報処理装置及びそれらの制御方法、並びに記憶媒体
WO2016035293A1 (en) * 2014-09-03 2016-03-10 Canon Kabushiki Kaisha Communication apparatus, information processing apparatus, methods and computer-readable storage medium
JP6381426B2 (ja) * 2014-12-02 2018-08-29 キヤノン株式会社 情報処理装置、制御方法、及びプログラム
JP6274163B2 (ja) * 2015-07-22 2018-02-07 コニカミノルタ株式会社 画像形成装置及び情報表示方法
KR101729887B1 (ko) * 2016-01-25 2017-04-25 엔에이치엔엔터테인먼트 주식회사 롱폴링 처리 방법 및 시스템
US20190190986A1 (en) * 2017-12-19 2019-06-20 Avaya Inc. Long polling for clustered application load balancing
CN109669979A (zh) * 2018-12-18 2019-04-23 网易（杭州）网络有限公司 数据的处理方法及装置、存储介质
CN109948025B (zh) * 2019-03-20 2023-10-20 上海古鳌电子科技股份有限公司 一种数据引用记录方法
KR20200129776A (ko) * 2019-05-10 2020-11-18 삼성전자주식회사 재전송 공격에 대한 방어책을 포함하는 메모리 시스템의 구동 방법 및 이를 수행하는 메모리 시스템
US11119743B1 (en) * 2020-09-25 2021-09-14 Red Hat, Inc. Build time optimization using thread object variables
CN112491955B (zh) * 2020-10-23 2023-07-07 北京思特奇信息技术股份有限公司 一种基于代理服务器实现iframe系统数据交换的方法和系统
CN116700940B (zh) * 2023-08-08 2023-10-03 成都数智创新精益科技有限公司 一种基于封装类的请求处置方法及系统及装置及介质

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5944823A (en) 1996-10-21 1999-08-31 International Business Machines Corporations Outside access to computer resources through a firewall
US7464381B1 (en) * 2000-05-12 2008-12-09 Oracle International Corporation Content update proxy method
EP1645971B8 (en) * 2003-07-11 2016-03-30 Nippon Telegraph And Telephone Corporation Database access control method, database access control apparatus, proxy process server apparatus, program for database access control and recording medium recording the program
US20050138417A1 (en) * 2003-12-19 2005-06-23 Mcnerney Shaun C. Trusted network access control system and method
JP4463661B2 (ja) * 2004-11-01 2010-05-19 株式会社日立製作所 計算機システム、計算機、データベースアクセス方法及びデータベースシステム
US7716240B2 (en) * 2005-12-29 2010-05-11 Nextlabs, Inc. Techniques and system to deploy policies intelligently
KR20090089914A (ko) 2006-12-19 2009-08-24 팍스 인터렉티브 미디어, 인크. 각각의 개별 광고 임프레션을 위한 경매
JP2009015816A (ja) * 2007-06-05 2009-01-22 Hitachi Ltd Ｗｅｂアプリケーションの構成方法とそのシステム
US8280905B2 (en) * 2007-12-21 2012-10-02 Georgetown University Automated forensic document signatures
US8347347B2 (en) * 2008-01-09 2013-01-01 International Business Machines Corporation Password policy enforcement in a distributed directory when policy information is distributed
JP2010055560A (ja) 2008-08-29 2010-03-11 Toshiba Corp 中間システムおよびイベント駆動型サーバ拡張プログラム
JP5499524B2 (ja) * 2009-06-12 2014-05-21 富士通株式会社 中継プログラムおよび中継装置
DE112010004847T5 (de) * 2009-12-17 2012-11-08 International Business Machines Corporation Verwalteter Kanal für Asynchrone Anforderungen
US8285749B2 (en) * 2010-03-05 2012-10-09 Hitachi, Ltd. Computer system and recording medium
US9563878B2 (en) * 2011-02-01 2017-02-07 Sugarcrm Inc. System and method for intelligent data mapping, including discovery, identification, correlation and exhibit of CRM related communication data

Also Published As

Publication number Publication date
JP2012194809A (ja) 2012-10-11
US20120239698A1 (en) 2012-09-20
US8825703B2 (en) 2014-09-02

Similar Documents

Publication Publication Date Title
JP5617709B2 (ja) プログラム、制御装置および方法
US10282522B2 (en) Cross-application authentication on a content management system
US7908317B2 (en) System and method for URL compression
US9137210B1 (en) Remote browsing session management
US9122651B1 (en) Computer system to support failover in an event stream processing system
CA2732540C (en) Methods for optimizing a web content proxy server and devices thereof
US10148727B2 (en) Methods and systems for an end-to-end solution to deliver content in a network
US9679156B2 (en) Database virtualization
US10057207B2 (en) Smart navigation for shortened URLs
US10091111B2 (en) Methods and systems for an end-to-end solution to deliver content in a network
US20230216895A1 (en) Network-based media processing (nbmp) workflow management through 5g framework for live uplink streaming (flus) control
CN111325552A (zh) 数据处理方法及装置、电子设备、存储介质
US20180239516A1 (en) Methods for generating and publishing microsites and devices thereof
US9935977B1 (en) Content delivery employing multiple security levels
JP2016144186A (ja) 通信情報制御装置、中継システム、通信情報制御方法、および、通信情報制御プログラム
WO2014030487A1 (ja) プロキシ・サーバならびにその動作制御方法およびその動作制御プログラム
US11356382B1 (en) Protecting integration between resources of different services using service-generated dependency tags
US10645174B2 (en) Enabling multiple sessions in a single browser
Aivaliotis Mastering Nginx
CN118394731A (en) Data processing method and device
EP3051442A1 (en) Smart navigation for shortened urls
JP2013037626A (ja) オンラインストレージシステム及びオンラインストレージを利用する利用者端末

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20131129

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20140430

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20140617

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20140729

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: 20140819

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20140901

R150 Certificate of patent or registration of utility model

Ref document number: 5617709

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees