JP5552991B2 - アプリケーション配備装置、アプリケーション配備方法およびアプリケーション配備プログラム - Google Patents

Description

本発明は、アプリケーション配備装置、アプリケーション配備方法およびアプリケーション配備プログラムに関する。

従来、Ｗｅｂアプリケーションシステムでは、複数台用意されたサーバに対して処理を振り分け、この複数台のサーバに負荷を分散することで大量のアクセスを処理することが知られている。

このようなＷｅｂアプリケーションシステムにおいて、Ｗｅｂサーバに接続されるデータベースサーバが単一である場合には、単一のデータベースサーバが処理を行うので、データベースサーバがボトルネックとなり、処理が遅延することがある。このため、スケーラビリティ向上のために、Ｗｅｂサーバに複数のデータベースサーバを接続することが実施されている。

具体的には、Ｗｅｂアプリケーションシステムは、データベースサーバとして、参照用データベースサーバ（以下、参照用ＤＢサーバという）および更新用データベースサーバ（以下、更新用ＤＢサーバという）を有する。ここで、図１７を用いて、Ｗｅｂアプリケーションシステムについて具体的に説明する。図１７に示すように、ロードバランサ（図１７の例では、ＬＢと記載）、複数のＷｅｂサーバ、参照用ＤＢサーバ、更新用ＤＢサーバおよびバックアップＤＢサーバを有する。ロードバランサは、複数台用意されたＷｅｂサーバのうち、いずれかのＷｅｂサーバに対して処理を振り分ける。

このようなＷｅｂアプリケーションシステムにおいて、Ｗｅｂサーバは、参照アプリおよび更新アプリを保持する。そして、Ｗｅｂサーバは、ロードバランサを介して更新要求を受け付けた場合には、更新アプリが更新用ＤＢサーバにアクセスして更新用ＤＢの更新を行う。また、Ｗｅｂサーバは、ロードバランサを介して参照要求を受け付けた場合には、参照アプリが参照用ＤＢサーバにアクセスして参照用ＤＢを参照する。

ここで、Ｗｅｂアプリケーションシステムは、更新用ＤＢに格納されたデータを定期的に参照用ＤＢにコピーするレプリケーション処理を行うことで、参照用ＤＢのデータと更新用ＤＢのデータとの一貫性を確保している。ところが、レプリケーション処理を行うまでは参照用ＤＢと更新用ＤＢとで内容が一致しない場合があり、データを更新するユーザが更新用データベースに問い合わせる場合がある。

例えば、日記のようなＷｅｂサイトでは、書き込まれた日記がレプリケーション処理を行うまでの数秒〜数分間は読むことができない可能性がある。つまり、日記の所有者は、結果がリアルタイムで反映されないと、本当に日記が登録されたのか確認することができない。このため、コンテンツの所有者（以下、コンテンツ所有者という）が最新のデータを保持する更新用ＤＢに問い合わせを行う場合がある。

例えば、コンテンツ所有者が更新用ＤＢに問い合わせを行う方法として、アプリ内に参照用ＤＢと更新用ＤＢのＵＲＬを記述し、Ｗｅｂアプリケーションのなかで接続先データベースを変えるようにプログラムを手動で記述することが考えられる。このようなＷｅｂアプリケーションを実行した場合の処理について図１８を用いて説明する。例えば、図１８に示すように、ブラウザからログイン時に利用者ＩＤが入力された場合に（図１８の（１）参照）、ＡＰサーバは、Ｗｅｂで利用されるセッション情報記憶部に利用者ＩＤを格納する（図１８（２）参照）。

そして、ブラウザからデータの要求を受け付けると（図１８の（３）参照）、ＡＰサーバは、利用者ＩＤを参照し（図１８の（４）参照）、読み込むデータの所有者ＩＤが利用者ＩＤと一致する場合には更新用ＤＢに問い合わせ、一致しない場合には参照用ＤＢに問い合わせる（図１８の（５）参照）。

特開２００２−１３２５６８号公報 特開２００６−４３２８号公報

ところで、上述した接続先データベースを変えるようなプログラムを手動で記述する方法では、プログラムを記述するための開発コストがかかるとともに、変更後のプログラムのテストにコストがかかるという課題があった。

一つの側面では、プログラムを手動で変更することなくアクセス先データベースの振り分けを適切に行うことを目的とする。

第一の案では、アプリケーション配備装置は、コンテンツの所有者の識別子を保存するプログラムをコンテンツへアクセスするコンテンツアクセスプログラムに追加する。そして、アプリケーション配備装置は、コンテンツの参照を要求する利用者の識別子とプログラムによって保存された識別子とを用いて更新用記憶部または参照用記憶部にアクセスするプログラムに、コンテンツアクセスプログラムを変換する。

Ｗｅｂアプリケーションを手動で変更することなくアクセス先データベースの振り分けを適切に行うことができる。

図１は、実施例１に係るアプリケーション配備装置の構成を示すブロック図である。 図２は、実施例２に係るＷｅｂアプリケーションシステムの構成を説明する図である。 図３は、実施例２に係る配備サーバの構成を示す図である。 図４は、配備記述子にフィルタ要素を追加する処理を説明する図である。 図５は、ＤＢコネクションの変換処理を説明する図である。 図６は、リスナクラスのプログラム例を示す図である。 図７は、フィルタクラスのプログラム例を示す図である。 図８は、Ｗｅｂアプリケーションシステムの処理を説明する図である。 図９は、コンテンツ所有者がコンテンツを参照する場合の処理を説明する図である。 図１０は、コンテンツ読者がコンテンツを参照する場合の処理を説明する図である。 図１１は、実施例２に係る配備サーバの配備記述子変更手順を説明するためのフローチャートである。 図１２は、実施例２に係る配備サーバのＤＢコネクション変換手順を説明するためのフローチャートである。 図１３は、実施例２に係るＷｅｂアプリケーションシステムのコンテンツ追加時の処理手順を説明するためのフローチャートである。 図１４は、実施例２に係るＷｅｂアプリケーションシステムのコンテンツ参照時の処理手順を説明するためのフローチャートである。 図１５は、実施例３に係る配備サーバの構成を示す図である。 図１６は、Ｗｅｂアプリケーションシステムの処理を説明する図である。 図１７は、従来のＷｅｂアプリケーションシステムを説明する図である。 図１８は、従来のＷｅｂアプリケーションシステムの処理を説明する図である。

以下に、本願の開示するアプリケーション配備装置、アプリケーション配備方法およびアプリケーション配備プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。

まず、図１を用いて、実施例１に係るアプリケーション配備装置の構成について説明する。図１は、実施例１に係るアプリケーション配備装置の構成を示すブロック図である。

実施例１のアプリケーション配備装置１は、プログラム追加部１ａ、プログラム変換部１ｂを有し、アプリケーションサーバ２に接続されている。アプリケーションサーバ２は、利用者端末３、更新用記憶部４および参照用記憶部５とそれぞれ接続されている。アプリケーションサーバ２は、利用者端末３からの要求に応じて、更新用記憶部４および参照用記憶部５に対してアクセスしてアプリケーションを実行する。

利用者端末３は、アプリケーションサーバ２に対してコンテンツの更新要求または参照要求を送信する。更新用記憶部４は、アプリケーションサーバ２によってアクセスされ、最新のコンテンツを保持する。参照用記憶部５は、アプリケーションサーバ２によってアクセスされ、更新用記憶部４が保持するコンテンツの複製を保持する。

アプリケーション配備装置１のプログラム追加部１ａは、更新用記憶部４および参照用記憶部５に記憶されたコンテンツの所有者の識別子を保存するプログラムを、コンテンツへアクセスするコンテンツアクセスプログラムに追加する。プログラム変換部１ｂは、コンテンツの参照を要求する利用者の識別子とプログラムによって保存された識別子とを用いて更新用記憶部４または参照用記憶部５にアクセスするプログラムに、コンテンツアクセスプログラムを変換する。

このように、アプリケーション配備装置１は、コンテンツへアクセスするコンテンツアクセスプログラムを自動で追加および変換し、更新用記憶部４または参照用記憶部５のいずれかをアクセス先として振り分ける。この結果、アプリケーション配備装置１は、プログラムを手動で変更することなく、プログラムを記述するための開発およびテストにかかるコストを削減してアクセス先の振り分けを適切に行うことができる。

以下の実施例では、実施例２に係るＷｅｂアプリケーションシステム、配備サーバの構成および処理の流れを順に説明し、最後に実施例２による効果を説明する。

［Ｗｅｂアプリケーションシステムの構成］
まず、図２を用いて、配備サーバを含むＷｅｂアプリケーションシステム全体の構成を説明する。図２は、実施例２に係るＷｅｂアプリケーションシステムの構成を説明する図である。図２に示すように、Ｗｅｂアプリケーションシステム１００は、配備サーバ１０、複数のＡＰ（Ａｐｐｌｉｃａｔｉｏｎ）サーバ２０、ブラウザ３０、ＬＢ（Ｌｏａｄ Ｂａｌａｎｃｅｒ）４０、参照用ＤＢ（ＤａｔａＢａｓｅ）５０、更新用ＤＢ６０を有する。

配備サーバ１０は、ＡＰサーバ２０と接続されており、ＡＰサーバ２０上に配置されたＷｅｂアプリのファイル形式であるＷａｒファイルおよびＤＢ定義情報ファイルを読み取り、配備サーバ１０上で作成されたＷｅｂアプリをＡＰサーバ２０上に配備する。

ＡＰサーバ２０は、外部との通信やメモリへのアクセス手段を提供するためのプラットフォームであるコンテナ機能を有し、Ｗａｒファイルとして開発されたＷｅｂアプリを実行させる。Ｗｅｂアプリは、ＡＰサーバ２０内のメモリにセッション情報等を格納することができるようになっている。また、ＡＰサーバ２０の後方には、更新用ＤＢ６０と参照用ＤＢ５０とが接続されている。

ＡＰサーバ２０は、ロードバランサ４０を介して更新要求を受け付けた場合には、更新用ＤＢ６０のデータを更新を行い、また、ロードバランサ４０を介して参照要求を受け付けた場合には、参照用ＤＢ５０のデータを参照する。また、ＡＰサーバ２０は、各ＤＢ５０、６０に接続するためのＵＲＬが記述されたＤＢ定義情報を保存する。このＤＢ定義情報は、例えばＸＭＬファイルとして保存される。また、ＡＰサーバ２０は、更新用ＤＢ６０に格納されたデータを定期的に参照用ＤＢ５０にコピーするレプリケーション処理を行うことで、参照用ＤＢ５０のデータと更新用ＤＢ６０のデータとの一貫性を確保している。

ブラウザ３０は、ロードバランサ４０とインターネットを介して接続される利用者端末において利用者が情報を閲覧するためのソフトウェアである。具体的には、ブラウザ３０は、利用者のリクエストを受け付け、ロードバランサ４０にリクエストを送信し、また、ロードバランサから受信したＷｅｂページを利用者端末に表示する。

ロードバランサ４０は、複数のＡＰサーバ２０と接続され、複数のリクエストの負荷分散を行う。具体的には、ロードバランサ４０は、ブラウザ３０からリクエストを受信すると、複数用意されたＡＰサーバ２０中の一台を選択し、選択されたＡＰサーバ２０にリクエストを送信する。

次に、図３を用いて、図２に示した配備サーバ１０の構成を説明する。図３は、実施例２に係る配備サーバの構成を示すブロック図である。図３に示すように、この配備サーバ１０は、ファイル解凍部１１、配備記述子変換部１２、ＤＢコネクション変換部１３、Ｗｅｂコンテンツ変換部１４、ファイル圧縮部１５を有する。以下にこれらの各部の処理を説明する。

ファイル解凍部１１は、圧縮形式のＷｅｂアプリファイルであるＷａｒファイルを読み取り、通常のファイルに解凍する。ここでＷａｒファイルとは、ＪＣＰ（Ｊａｖａ（登録商標） Ｃｏｍｍｕｎｉｔｙ Ｐｒｏｃｅｓｓ）の定めるＳｅｒｖｌｅｔ仕様に則っており、リクエストに対してどのプログラムを呼び出すかを定義するための配備記述子、Ｊａｖａのプログラム本体であるクラスファイル、ＨＴＭＬやＪＳＰ等のＷｅｂコンテンツから構成される。

配備記述子変換部１２は、リクエストに対してどのプログラムを呼び出すかを定義するための配備記述子にＳｅｒｖｌｅｔフィルタを追加する。具体的には、配備記述子変換手段１２は、ＨＴＴＰのリクエストにパスワードが含まれる場合に付随するＨＴＴＰクエリテキストをユーザＩＤとしてＨＴＴＰセッション情報に保存するＳｅｒｖｌｅｔフィルタを追加する。

ここで、図４を用いて、配備記述子にフィルタ要素を追加する処理を説明する。図４は、配備記述子にフィルタ要素を追加する処理を説明する図である。まず、配備記述子変換手段１２は、配備記述子に＜ｌｉｓｔｅｎｅｒ＞要素があるか判定する。この結果、配備記述子変換手段１２は、＜ｌｉｓｔｅｎｅｒ＞要素がないと判定した場合には、図４に示すように、＜ｌｉｓｔｅｎｅｒ−ｃｌａｓｓ＞要素を追加する。また、配備記述子変換手段１２は、＜ｌｉｓｔｅｎｅｒ＞要素があると判定した場合には、＜ｌｉｓｔｅｎｅｒ＞要素内の最後に＜ｌｉｓｔｅｎｅｒ−ｃｌａｓｓ＞要素を追加する。

続いて、配備記述子変換手段１２は、＜ｆｉｌｔｅｒ＞要素があるか判定する。この結果、配備記述子変換手段１２は、＜ｆｉｌｔｅｒ＞要素がないと判定した場合には、図４に示すように、＜ｓｅｒｖｌｅｔ＞要素の直前に＜ｆｉｌｔｅｒ＞要素（図４の（１）参照）と＜ｆｉｌｔｅｒ−ｍａｐｐｉｎｇ＞要素（図４の（２）参照）を追加する。

また、配備記述子変換手段１２は、＜ｆｉｌｔｅｒ＞要素があると判定した場合には、最後の＜ｆｉｌｔｅｒ＞要素の直後に＜ｆｉｌｔｅｒ＞要素を追加し、最後の＜ｆｉｌｔｅｒ−ｍａｐｐｉｎｇ＞要素の直後に＜ｆｉｌｔｅｒ−ｍａｐｐｉｎｇ＞要素を追加する。

このように配備記述子を変更することで、Ｗｅｂアプリの起動時に「com.fujitsu.ServletListener」というリスナクラスが実行され、すべてのリクエスト処理の最初に「com.fujitsu.PasswordFilter」というフィルタクラスが実行されることを定義することができる。なお、リスナクラスおよびフィルタクラスについては、後に図６および図７を用いて詳述する。

ＤＢコネクション変換部１３は、データベースへのアクセスを行うＪａｖａクラスに対して、実行されるＳＱＬに所有者ＩＤが含まれていれば更新用ＤＢ６０へのコネクションを生成し所有者ＩＤが含まれていなければ参照用ＤＢ５０へのコネクションを生成するプログラムをアスペクト指向技術により埋め込む。

例えば、ＤＢコネクション変換部１３は、「Connection#createStatement()」メソッドや「Connection#prepareStatement()」メソッド等の、クエリを実行するためのオブジェクトを作成するコードをアスペクト指向言語等の静的解析技術でＪａｖａクラスファイル内から検索する。

そして、ＤＢコネクション変換部１３は、図５の上部に示すようなプログラムの場合には、コネクションを生成するコード部分（図５（３）参照）の前に、コンテンツ所有者ＩＤか否かの候補の一覧を取得するためのコード（図５（４）参照）を追加する。

その後、ＤＢコネクション変換部１３は、その所有者ＩＤが、実行されるＳＱＬに含まれるかどうかを判定し、含まれていれば更新用ＤＢ６０へのコネクションを生成し、含まれていなければ参照用ＤＢ５０へのコネクションを生成するコード（図５の（５）参照）を追加する。なお、ｕｐｄａｔｅやｃｒｅａｔｅ等データベースの更新を行うＳＱＬを実行する場合には、更新用ＤＢへのコネクションを生成するようなコードとする。

Ｗｅｂコンテンツ変換部１４は、ＨＴＭＬファイル及びＪＳＰファイルの中を検索し、ｔｙｐｅ属性が「ｐａｓｓｗｏｒｄ」となっている＜ｉｎｐｕｔ＞要素があるか否かを判定する。この結果、Ｗｅｂコンテンツ変換部１４は、ｐａｓｓｗｏｒｄ属性の＜ｉｎｐｕｔ＞要素がある場合には、同じフォーム要素内に隠しメッセージである「＜ｉｎｐｕｔ ｔｙｐｅ＝“ｈｉｄｄｅｎ” ｎａｍｅ＝“ＣＯＮＴＡＩＮＳ＿ＰＡＳＳＷＯＲＤ＿ＦＩＥＬＤ” Ｖａｌｕｅ＝“ＴＲＵＥ”＞」を追加する処理を行う。

つまり、ＨＴＭＬ入力フォームがパスワード情報を含んでおり、所有者がＩＤを入力した可能性が高いと判断し、“ＣＯＮＴＡＩＮＳ＿ＰＡＳＳＷＯＲＤ＿ＦＩＥＬＤ”が含まれていれば、そのときの値をセッションに保存するように隠しメッセージを追加する。なお、ＩＤとパスワードは同一の入力フォームを用いられることが多く、パスワードと一緒に入力される情報の中にＩＤ情報が含まれる確率が高い。

ファイル圧縮部１５は、変換後配備記述子、変換後クラスファイルおよび変換後Ｗｅｂコンテンツをリスナクラスおよびフィルタクラスとともに圧縮し、変換後アプリとして生成する。この変換後アプリは、ＡＰサーバ２０上にネットワーク経由で転送、配備され、実行システム上で実行される。

ここで、図６の例を用いてリスナクラスについて説明する。図６は、リスナクラスのプログラム例を示す図である。リスナクラスは、配備されたＷｅｂアプリが起動する際に一度だけ実行される。そして、リスナクラスは、図６に示すように、ＤＢ定義ファイルから抽出した更新用ＤＢ及び参照用ＤＢのＵＲＬをメモリ上に保存しておき、後でアプリ内で使えるようにする機能を有している。具体的には図５で示すコード（５）内で使用されている。

図７は、フィルタクラスのプログラム例を示す図である。フィルタクラスは、Ｓｅｒｖｌｅｔ仕様により、リクエストの最初に呼び出され、ＨＴＴＰリクエストの情報を読み取ることができるようになっている。フィルタクラス「ＰａｓｓｗｏｒｄＦｉｌｔｅｒ」は、ＨＴＴＰリクエストの情報を検索し、ＣＯＮＴＡＩＮＳ＿ＰＡＳＳＷＯＲＤ＿ＦＩＥＬＤという名称のパラメータが存在しているかをチェックする。ＣＯＮＴＡＩＮＳ＿ＰＡＳＳＷＯＲＤ＿ＦＩＥＬＤパラメータが存在すれば、ヘルパクラス（ＳｃａｌｅｏｕｔＨｅｌｐｅｒ）を呼び出し、すべてのパラメータの内容をセッション（ユーザごとのメモリ情報）に保存する。この内容が、所有者ＩＤの候補となる。

ここで、図８を用いて、Ｗｅｂアプリケーションシステムにおけるコンテンツ参照処理を説明する。図８は、Ｗｅｂアプリケーションシステムの処理を説明する図である。図８に示すように、Ｗｅｂアプリケーションシステム１００では、ブラウザ３０からログイン時に利用者ＩＤの入力が受け付けられると、ＬＢ４０に利用者ＩＤを送信する（図８の（１）参照）。そして、Ｗｅｂアプリケーションシステム１００では、ＬＢ４０からＡＰサーバ２０に利用者ＩＤが送信されると、フィルタがパスワードとともに送られた文字列を利用者ＩＤと特定し、セッション情報に利用者ＩＤを格納する（図８の（２）参照）。

その後、Ｗｅｂアプリケーションシステム１００では、ブラウザ３０からデータ参照要求を受け付けると（図８の（３）参照）、ＬＢ４０を介して、ＡＰサーバ２０にデータ参照要求を送信する。そして、ＡＰサーバ２０のアプリは、データ参照要求を受け付けると、ＳＱＬを発行する。続いて、ＡＰサーバ２０のＤＢ振り分けエンジンがＳＱＬを解析し、ｗｈｅｒｅ句内に利用者ＩＤと一致するものが１件以上あるかセッション情報の利用者ＩＤを参照する（図８の（４）参照）。この結果、ｗｈｅｒｅ句内に利用者ＩＤと一致するものが１件以上ある場合には、更新用ＤＢ６０に問い合わせ、また、利用者ＩＤと一致するものがない場合には、参照用ＤＢ５０に問い合わせる（図８の（５）参照）。

例えば、図９を用いて、コンテンツ所有者がコンテンツを登録し、それを自分自身で確認する場合の処理を説明する。図９は、コンテンツ所有者がコンテンツを参照する場合の処理を説明する図である。トップページのＨＴＭＬコンテンツには、ＩＤ、パスワードの入力フォームがあり、この入力フォームにはｔｙｐｅ＝ｐａｓｓｗｏｒｄの＜ｉｎｐｕｔ＞要素が存在するので、パスワードと同時に入力されたＩＤが、ヘルパクラスを通じてセッション情報に保存される。例えば、図９の左側に示すように、ＩＤとして「ｔａｎａｋａ」と入力した場合には、ｔａｋａｎａという文字列がセッション情報に保存される。

その後、コンテンツ利用者が日記等のコンテンツを登録し、再度自身の作成したコンテンツの一覧を表示する。その際に、図９の右上のようなコードが実行されると、ｓｔａｔｅｍｅｎｔオブジェクトのｉｄ部分には「ｔａｋａｎａ」という文字列が入るので、この文字列がセッション情報の文字列を一致し、更新用ＤＢのＵＲＬが使用される。

また、図１０を用いて、コンテンツ読者がコンテンツを参照する場合の処理を説明する。図１０は、コンテンツ読者がコンテンツを参照する場合の処理を説明する図である。図１０に示すように、コンテンツ読者である「ｓｕｚｕｋｉ」がコンテンツ所有者「ｔａｎａｋａ」とは異なるＩＤでログインすると、セッション情報に「ｓｕｚｕｋｉ」が保存される。次にコンテンツ読者である「ｓｕｚｕｋｉ」さんが、ｔａｎａｋａさんのコンテンツ一覧表示を押下すると、図１０の右上のようなコードが実行される。ここで、ｓｔａｔｅｍｅｎｔオブジェクトのｉｄ部分には「ｔａｋａｎａ」という文字列が入るので、この文字列がセッション情報の文字列と一致せず、参照用ＤＢのＵＲＬが使用される。

［配備サーバによる処理］
次に、図１１および図１２を用いて、実施例２に係る配備サーバ１０による処理を説明する。図１１は、実施例２に係る配備サーバの配備記述子変更手順を説明するためのフローチャートである。図１２は、実施例２に係る配備サーバのＤＢコネクション変換手順を説明するためのフローチャートである。

図１１に示すように、配備サーバ１０は、配備記述子を読み込むと（ステップＳ１０１）、＜ｌｉｓｔｅｎｅｒ＞要素があるか判定する（ステップＳ１０２）。この結果、配備サーバ１０は、＜ｌｉｓｔｅｎｅｒ＞要素があると判定した場合には（ステップＳ１０２肯定）、＜ｌｉｓｔｅｎｅｒ＞要素内の最後に＜ｌｉｓｔｅｎｅｒ−ｃｌａｓｓ＞要素を追加する（ステップＳ１０３）。

そして、配備サーバ１０は、＜ｌｉｓｔｅｎｅｒ＞要素がないと判定した場合には（ステップＳ１０２否定）、＜ｌｉｓｔｎｅｒ−ｃｌａｓｓ＞要素を追加する（ステップＳ１０４）。

続いて、配備サーバ１０は、＜ｆｉｌｔｅｒ＞要素があるか判定する（ステップＳ１０５）。この結果、配備サーバ１０は、＜ｆｉｌｔｅｒ＞要素があると判定した場合には（ステップＳ１０５肯定）、最後の＜ｆｉｌｔｅｒ＞要素の直後に＜ｆｉｌｔｅｒ＞要素を追加する（ステップＳ１０６）。そして、最後の＜ｆｉｌｔｅｒ−ｍａｐｐｉｎｇ＞要素の直後に＜ｆｉｌｔｅｒ−ｍａｐｐｉｎｇ＞要素を追加する（ステップＳ１０７）。

また、配備サーバ１０は、＜ｆｉｌｔｅｒ＞要素がないと判定した場合には（ステップＳ１０５否定）、＜ｓｅｒｖｌｅｔ＞要素の直前に＜ｆｉｌｔｅｒ＞要素と＜ｆｉｌｔｅｒ−ｍａｐｐｉｎｇ＞要素を追加する（ステップＳ１０８）。

次に、図１２を用いて、ＤＢコネクション変換処理を説明する。図１２に示すように、配備サーバ１０は、Ｊａｖａプログラムを読み込み（ステップＳ２０１）、コネクション取得部分があるか判定する（ステップＳ２０２）。この結果、配備サーバ１０は、コネクション取得部分がない場合には（ステップＳ２０２否定）、ＤＢコネクション変換処理を終了する。また、配備サーバ１０は、コネクション取得部分がある場合には（ステップＳ２０２肯定）、プログラムのメソッドの先頭に所有者ＩＤ候補一覧を取得する命令を追加する（ステップＳ２０３）。

そして、配備サーバ１０は、コネクションを生成するコード部分について、実行されるＳＱＬに所有者ＩＤが含まれていれば更新用ＤＢ６０へのコネクションを生成し所有者ＩＤが含まれていなければ参照用ＤＢ５０へのコネクションを生成するコードを追加する（ステップＳ２０４）。その後、配備サーバ１０は、最後の＜ｆｉｌｔｅｒ−ｍａｐｐｉｎｇ＞要素の直後に＜ｆｉｌｔｅｒ−ｍａｐｐｉｎｇ＞要素を追加する（ステップＳ２０５）。

［Ｗｅｂアプリケーションシステムによる処理］
次に、図１３および図１４を用いて、実施例２に係るＷｅｂアプリケーションシステム１００による処理を説明する。図１３は、実施例２に係るＷｅｂアプリケーションシステムのコンテンツ追加時の処理手順を説明するためのフローチャートである。図１４は、実施例２に係るＷｅｂアプリケーションシステムのコンテンツ参照時の処理手順を説明するためのフローチャートである。

図１３に示すように、ＡＰサーバ２０は、配備記述子を読み込み（ステップＳ３０１）、リスナクラスを実行して（ステップＳ３０２）、ＡＰサーバ２０のメモリ内に参照用ＤＢ５０および更新用ＤＢ６０のＵＲＬを保存する（ステップＳ３０３）。そして、コンテンツ所有者がブラウザ３０からサイトのトップページのＵＲＬを入力してロードバランサ４０にアクセスすると（ステップＳ３０４）、ロードバランサ４０がＨＴＴＰリクエストをＡＰサーバ２０に送信する（ステップＳ３０５）。

続いて、ＡＰサーバ２０は、ロードバランサ４０からＨＴＴＰリクエストを受信し、配備記述子に従って該当のＷｅｂページを返却する（ステップＳ３０６）。なお、Ｗｅｂページには、パスワードの入力が含まれるので、「ＣＯＮＴＡＩＮＳ＿ＰＡＳＳＷＯＲＤ＿ＦＩＥＬＤ」パラメータが追加されている。

そして、コンテンツ所有者がブラウザ３０から「ＩＤ」、「パスワード」を入力してログインする（ステップＳ３０７）。そして、ブラウザ３０からロードバランサ４０に「ＩＤ」、「パスワード」が通知され、ロードバランサ４０が再度同一のＡＰサーバ２０に送信する（ステップＳ３０８）。

そして、ＡＰサーバ２０は、フィルタプログラムを呼び出し、「ＣＯＮＴＡＩＮＳ＿ＰＡＳＳＷＯＲＤ＿ＦＩＥＬＤ」パラメータが存在するため、セッション情報にコンテンツ所有者のＩＤを追加する（ステップＳ３０９）。続いて、ＡＰサーバ２０は、配備記述子に従ってＵＲＬに対応するクラスファイルを呼び出し、認証を行ってコンテンツ所有者にＷｅｂページを返却する（ステップＳ３１０）。

その後、コンテンツ所有者が日記などのコンテンツをブラウザから入力して登録ボタンを押下すると（ステップＳ３１１）、コンテンツがロードバランサ４０経由でＡＰサーバ２０に送信され、ＵＲＬに対応するクラスファイルが呼び出される（ステップＳ３１２）。そして、登録のプログラムが更新系であるため、更新用ＤＢ６０に対して書き込みが行われ（ステップＳ３１３）、ＡＰサーバ２０が登録完了ページをコンテンツ所有者に返却する（ステップＳ３１４）。

続いて、コンテンツ所有者が自分で登録したコンテンツの一覧の参照を要求するために、コンテンツの一覧の選択ボタンを押下すると（ステップＳ３１５）、ロードバランサ４０経由でＡＰサーバ２０にリクエストが送信され、ＵＲＬに対応するクラスファイルが呼び出される（ステップＳ３１６）。そして、ＡＰサーバ２０は、一覧表示画面が参照系であり、所有者のＩＤがＳＱＬ内に含まれているため更新用ＤＢ６０のコネクションが使用され、更新用ＤＢ６０に対して参照が行われる（ステップＳ３１７）。

次に、図１４を用いて、コンテンツ参照処理を説明する。図１４に示すように、ＡＰサーバ２０は、配備記述子を読み込み（ステップＳ４０１）、リスナクラスを実行して（ステップＳ４０２）、ＡＰサーバ２０のメモリ内に参照用ＤＢ５０および更新用ＤＢ６０のＵＲＬを保存する（ステップＳ４０３）。そして、コンテンツ読者がブラウザ３０からサイトのトップページのＵＲＬを入力してロードバランサ４０にアクセスすると（ステップＳ４０４）、ロードバランサ４０がＨＴＴＰリクエストをＡＰサーバ２０に送信する（ステップＳ４０５）。

続いて、ＡＰサーバ２０は、ロードバランサ４０からＨＴＴＰリクエストを受信し、配備記述子に従って該当のＷｅｂページを返却する（ステップＳ４０６）。なお、Ｗｅｂページには、パスワードの入力が含まれるので、「ＣＯＮＴＡＩＮＳ＿ＰＡＳＳＷＯＲＤ＿ＦＩＥＬＤ」パラメータが追加されている。

そして、コンテンツ読者がブラウザ３０から「ＩＤ」、「パスワード」を入力してログインする（ステップＳ４０７）。そして、ブラウザ３０からロードバランサ４０に「ＩＤ」、「パスワード」が通知され、ロードバランサ４０が再度同一のＡＰサーバ２０に送信する（ステップＳ４０８）。

そして、ＡＰサーバ２０は、フィルタプログラムを呼び出し、「ＣＯＮＴＡＩＮＳ＿ＰＡＳＳＷＯＲＤ＿ＦＩＥＬＤ」パラメータが存在するため、セッション情報にコンテンツ読者のＩＤを追加する（ステップＳ４０９）。続いて、ＡＰサーバ２０は、配備記述子に従ってＵＲＬに対応するクラスファイルを呼び出し、認証を行ってコンテンツ読者にＷｅｂページを返却する（ステップＳ４１０）。

その後、コンテンツ読者が読みたいコンテンツ所有者を選択し、そのコンテンツ一覧ボタンを押下すると（ステップＳ４１１）、ロードバランサ４０経由でＡＰサーバ２０にリクエストが送信され、ＵＲＬに対応するクラスファイルが呼び出される（ステップＳ４１２）。そして、ＡＰサーバ２０は、一覧表示画面が参照系であり、所有者のＩＤがＳＱＬ内に含まれていないため参照用ＤＢ５０のコネクションが使用され、参照用ＤＢ５０に対して参照が行われる（ステップＳ４１３）。なお、レプリケーションのタイミングによっては、最新のコンテンツが見られない可能性がある。

[実施例２の効果]
上述してきたように、配備サーバ１０は、最新のコンテンツを保持する更新用ＤＢ６０と、更新用ＤＢ６０が保持するコンテンツの複製を保持する参照用記憶部５０とに記憶されたコンテンツの所有者の利用者ＩＤを保存するＳｅｒｖｌｅｔフィルタを配備記述子に追加する。そして、配備サーバ１０は、コンテンツの参照を要求する利用者の利用者ＩＤとプログラムによって保存された利用者ＩＤとを用いて更新用ＤＢ６０または参照用ＤＢ５０にアクセスするプログラムをデータベースへのアクセスを行うＪａｖａクラスに埋め込む。

このため、配備サーバ１０は、プログラムを手動で変更することなく、プログラムを記述するための開発およびテストにかかるコストを削減してアクセス先データベースの振り分けを適切に行うことができる。

また、実施例２によれば、配備サーバ１０は、プログラム追加部が追加するプログラムは、利用者のリクエストにパスワードが含まれる場合に、リクエストを記述するリクエストテキストをコンテンツ所有者の利用者ＩＤとして保存する。このため、ＩＤとパスワードは同一の入力フォームを用いられることが多く、適切に利用者ＩＤを取得することができる。

また、実施例２によれば、配備サーバ１０は、所有者の利用者ＩＤを保存するプログラムを追加するとともに、更新用ＤＢ６０および参照用ＤＢ５０のコネクション情報を作成し、コネクション情報を用いて更新用ＤＢ６０または参照用ＤＢ５０にアクセスするプログラムを、データベースへのアクセスを行うＪａｖａクラスに埋め込む。この結果、更新用ＤＢ６０および参照用ＤＢ５０に対して事前に作成されたコネクション情報を用いてアクセスすることが可能である。

ところで、上記の実施例２では、Ｗｅｂコンテンツ変換部１４の代わりにＳｅｒｖｌｅｔフィルタが、ＨＴＭＬファイルの中に「<input type=“password” name=“***”>」を検出した場合に、同じフォーム要素内に<input type=“hidden”name=“CONTAINS_PASSWORD_FIELD”value=“TRUE”>を追加するようにしてもよい。

そこで、以下の実施例３では、Ｓｅｒｖｌｅｔフィルタが、アプリが出力したＨＴＭＬ情報を変換して、「ＨＴＭＬファイルの中に「<input type=“password” name=“***”>」を検出した場合に、同じフォーム要素内に<input type=“hidden”name=“CONTAINS_PASSWORD_FIELD”value=“TRUE”>を追加する」処理を行う場合として、図１５および図１６を用いて、実施例３に係る配備サーバについて説明する。図１５は、実施例３に係る配備サーバの構成を示す図である。図１６は、Ｗｅｂアプリケーションシステムの処理を説明する図である。

まず最初に、実施例３に係る配備サーバ１０ａの構成を説明する。図１５に示すように、配備サーバ１０ａは、図３に示した配備サーバ１０と比較して、Ｗｅｂコンテンツ変換部１４がなく、フィルタクラスＡを新たに有する点が相違する。かかる配備サーバ１０ａにおいて、フィルタクラスＡは、内部に前処理を行うための前処理フィルタと、後処理を行うための後処理フィルタを有している。前処理フィルタの役割が実施例３のフィルタクラスと同様であるが、後処理フィルタが後処理としてＨＴＭＬ情報を変更するための処理を行う。

後処理は、アプリが出力したＨＴＭＬを変換して、実施例１のＷｅｂコンテンツ変換部１４と同様に、「ＨＴＭＬファイルの中に「<input type=“password” name=“***”>」を検出した場合に、同じフォーム要素内に<input type=“hidden”name=“CONTAINS_PASSWORD_FIELD”value=“TRUE”>を追加する」処理を行う。

これにより、実施例２とほぼ同等のフローで同等の機能を提供することが可能となる。また、実施例３では、最終的に出力されるＨＴＭＬ情報に対して変換が行われる利点がある。

ここで、図１６を用いて、実施例３にかかるＷｅｂアプリケーションシステムの処理を説明する。図１６は、Ｗｅｂアプリケーションシステムの処理を説明する図である。図１６に示すように、実施例３にかかるＷｅｂアプリケーションシステムでは、ブラウザ３０からログイン時に利用者ＩＤの入力が受け付けられると、ＬＢ４０に利用者ＩＤを送信する（図１６の（１）参照）。そして、ＬＢ４０からＡＰサーバ２０に利用者ＩＤが送信されると、フィルタＡがパスワードとともに送られた文字列を利用者ＩＤと特定し、セッション情報に利用者ＩＤを格納する（図１６の（２）参照）。

その後、ブラウザ３０からデータ参照要求を受け付けると（図１６の（３）参照）、ＬＢ４０を介して、ＡＰサーバ２０にデータ参照要求を送信する。そして、ＡＰサーバ２０のアプリは、データ参照要求を受け付けると、ＳＱＬを発行する。続いて、ＡＰサーバ２０のＤＢ振り分けエンジンがＳＱＬを解析し、ｗｈｅｒｅ句内に利用者ＩＤと一致するものが１件以上あるかセッション情報の利用者ＩＤを参照する（図１６の（４）参照）。

この結果、ｗｈｅｒｅ句内に利用者ＩＤと一致するものが１件以上ある場合には、更新用ＤＢ６０に問い合わせ、また、利用者ＩＤと一致するものがない場合には、参照用ＤＢ５０に問い合わせる。

このように実施例３によれば、ＳＰファイルやＨＴＭＬファイルを使わずに、直接ＳｅｒｖｌｅｔクラスからＨＴＭＬ情報を生成する場合には、最終的に出力されるＨＴＭＬ情報に対して変換を行ことができる。

さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では実施例４として本発明に含まれる他の実施例を説明する。

（１）システム構成等
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、ファイル解凍部１１と配備記述子変換部１２を統合してもよい。

（２）プログラム
なお、本実施例で説明したアプリケーション配備方法は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。このプログラムは、インターネットなどのネットワークを介して配布することができる。また、このプログラムは、ハードディスク、フレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することもできる。

１ アプリケーション配備装置
１ａ プログラム追加部
１ｂ プログラム変換部
２ アプリケーションサーバ
３ 利用者端末
４ 更新用記憶部
５ 参照用記憶部
１０ 配備サーバ
１１ ファイル解凍部
１２ 配備記述子変換部
１３ ＤＢコネクション変換部
１４ Ｗｅｂコンテンツ変換部
１５ ファイル圧縮部
２０ ＡＰサーバ
３０ ブラウザ
４０ ロードバランサ
５０ 参照用ＤＢ
６０ 更新用ＤＢ

Claims (5)

1. 最新のコンテンツを保持する更新用記憶部と、該更新用記憶部が保持するコンテンツの複製を保持する参照用記憶部とに記憶されたコンテンツの所有者の識別子を保存する処理をコンピュータに実行させる保存プログラムのコードを、コンテンツへアクセスする処理をコンピュータに実行させるコンテンツアクセスプログラムのコードへ追加するプログラムコード追加部と、
   前記コンテンツの参照を要求する利用者の識別子と前記保存プログラムの実行によって保存された識別子とを用いて前記更新用記憶部または前記参照用記憶部にアクセスする処理をコンピュータに実行させるアクセスプログラムへ、前記コンテンツアクセスプログラムを変換するプログラム変換部と
   を有することを特徴とするアプリケーション配備装置。
2. 前記プログラムコード追加部によりコードが追加された前記コンテンツアクセスプログラムは、該コンテンツアクセスプログラムのコードにおける前記利用者のリクエストにパスワードが含まれる場合に、該リクエストを記述するリクエストテキストをコンテンツ所有者の識別子として保存する処理をコンピュータに実行させるプログラムである
   ことを特徴とする請求項１に記載のアプリケーション配備装置。
3. 前記プログラムコード追加部は、前記所有者の識別子を保存する処理をコンピュータに実行させる前記保存プログラムのコードとともに、前記更新用記憶部および前記参照用記憶部のコネクション情報を作成する情報作成プログラムのコードを前記コンテンツアクセスプログラムのコードへ追加し、
   前記プログラム変換部は、前記コネクション情報を用いて前記更新用記憶部または前記参照用記憶部にアクセスするする処理をコンピュータに実行させる前記アクセスプログラムへ、前記コンテンツアクセスプログラムを変換する
   ことを特徴とする請求項１または２に記載のアプリケーション配備装置。
4. 最新のコンテンツを保持する更新用記憶部と、該更新用記憶部が保持するコンテンツの複製を保持する参照用記憶部とに記憶されたコンテンツの所有者の識別子を保存する処理をコンピュータに実行させる保存プログラムのコードを、コンテンツへアクセスする処理をコンピュータに実行させるコンテンツアクセスプログラムのコードへ追加するプログラムコード追加ステップと、
   前記コンテンツの参照を要求する利用者の識別子と前記保存プログラムの実行によって保存された識別子とを用いて前記更新用記憶部または前記参照用記憶部にアクセスする処理をコンピュータに実行させるアクセスプログラムへ、前記コンテンツアクセスプログラムを変換するプログラム変換ステップと
   を含んだことを特徴とするアプリケーション配備方法。
5. 最新のコンテンツを保持する更新用記憶部と、該更新用記憶部が保持するコンテンツの複製を保持する参照用記憶部とに記憶されたコンテンツの所有者の識別子を保存する処理をコンピュータに実行させる保存プログラムのコードを、コンテンツへアクセスする処理をコンピュータに実行させるコンテンツアクセスプログラムのコードへ追加するプログラムコード追加手順と、
   前記コンテンツの参照を要求する利用者の識別子と前記保存プログラムの実行によって保存された識別子とを用いて前記更新用記憶部または前記参照用記憶部にアクセスする処理をコンピュータに実行させるアクセスプログラムへ、前記コンテンツアクセスプログラムを変換するプログラム変換手順と
   をコンピュータに実行させることを特徴とするアプリケーション配備プログラム。

Images