JP5393242B2 - データ提供方法および中間サーバ装置 - Google Patents

Description

本発明は、データ提供方法およびサーバに関し、特に、クライアントに提供するデータに対してカスタマイズを行う技術に関する。

Software as a Service(SaaS)と呼ばれるソフトウェア機能の提供形態が注目を集めている。SaaSでは、WebサーバがWebアプリとしてソフトウェア機能を提供し(SaaSアプリと呼ぶ)、SaaSユーザはWebブラウザを用いてSaaSアプリを利用する。このような利用形態の元では、複数の企業が一つのSaaSアプリを利用することが想定されるため、企業毎又はユーザ毎にWebアプリを企業やユーザに合わせてカスタマイズすることが望まれている。この場合、既存のWebアプリを修正してカスタマイズ機能を追加したり、新規のWebアプリを開発する際にカスタマイズ機能を追加することは負担が大きい。

特許文献１記載の技術では、 Webブラウザがネットワークを介してカスタマイズ用データベースにアクセスしてカスタマイズ情報を取得し、そのカスタマイズ情報に基づいてWebブラウザに表示した要素のカスタマイズを実行する技術を開示している。

特開2000-222324号公報

しかしながら、特許文献１記載の技術では、Webブラウザがネットワークを介してWebサーバやプロキシサーバとは異なるデータベースへアクセスしてカスタマイズデータを取得するため、ネットワーク負荷が大きいという課題があった。また、データベースにアクセスする分カスタマイズされた表示を行うまで時間がかかる課題があった。また、Webブラウザ上に一度表示した要素に対してカスタマイズを施すため、Webブラウザの表示が乱れたように見えることがあるという課題があった。さらに、Webサーバが配信するデータを動的に生成したり、ユーザからの入力を受け付けたりするWebアプリの場合、ユーザからの入力をリポジトリに保存したり、表示したいデータに応じてURLが変更されたり、コンテンツがダイナミックに変更されたりするため、このような場合にはカスタマイズすることが困難であるという課題があった。

上記課題を解決するため、本発明は、クライアントと、クライアントとネットワークを介して接続された第１のサーバと、第１のサーバとネットワークを介して接続された第２のサーバと、を備えるシステムにおけるデータ提供方法であって、クライアントが第１のサーバにリクエストを送信するステップと、第１のサーバがクライアントからのリクエストを第２のサーバに送信するステップと、第２のサーバがリクエストに対するレスポンスデータを第１のサーバに送信するステップと、第１のサーバが第２のサーバからのレスポンスデータをクライアントに送信するステップと、を備える。第１のサーバは、クライアントからのカスタマイズ情報に基づいて第２のサーバから受信したレスポンスデータに対してカスタマイズを適用し、カスタマイズを適用したレスポンスデータをクライアントへ送信し、クライアントは、カスタマイズを適用したレスポンスデータを表示する。

本発明によれば、ネットワーク負荷を軽減したWebアプリのカスタマイズが可能となる。

本発明の実施形態に係るシステムの構成図。 コンピュータの構成図。 カスタマイズ適用時の処理の流れを示す図。 レスポンス加工処理の流れを示す図。 カスタマイズ情報格納リポジトリを示す図。 クライアント処理の流れを示す図。 プロキシサーバを介したWebページ表示イメージを示す図。 カスタマイズエディタ表示イメージを示す図。 カスタマイズ時の処理の流れを示す図。 確定確認イメージを示す図。 カスタマイズ種類の例を示す図。 カスタマイズ機能追加イメージを示す図。 追加したカスタマイズ機能のイメージを示す図。

本発明の実施形態では、WebブラウザとWebアプリを公開するWebサーバの間にプロキシサーバを配し、WebブラウザからWebサーバへのリクエストと、Webサーバからのレスポンスがプロキシサーバを経由するようにする。

プロキシサーバがレスポンスを受けると、そのレスポンスに適用すべきカスタマイズ情報が存在するかどうかを確認し、存在しているならばカスタマイズを実施する。各カスタマイズ情報はサーバ、クライアントのどちらで実施するかを示す属性を持つ。

サーバ側で実施するカスタマイズ情報であった場合、プロキシサーバで受け取ったレスポンスに対してカスタマイズを施す。

クライアント側で実行するカスタマイズ情報であった場合、カスタマイズを施すプログラムをレスポンスに埋め込みWebブラウザに送出する。

また、レスポンスに対してユーザがさらに変更を加えることができるようにカスタマイズエディタプログラムもレスポンスに埋め込む。

Webブラウザでは、レスポンスを画面に表示する。レスポンスにクライアント側で実行すべきカスタマイズ情報が含まれているならばそのカスタマイズを実行する。また、カスタマイズエディタのプログラムも実行し、ユーザがカスタマイズ情報を作成できるようにする。

また、カスタマイズエディタで作成したカスタマイズ情報に異常があった場合、そのカスタマイズ情報を適用するとカスタマイズエディタでどのような操作も受け付けなくなってしまうことがある。そこで、カスタマイズ情報に状態も含め、カスタマイズ情報を追加又は修正した直後はテスト状態とし、最初にそのカスタマイズ情報を適用するときは無効状態にする。同時に、テスト状態のカスタマイズ情報を適用した場合はレスポンスにこのカスタマイズ情報を確定して良いかどうかを確認する機能も含める。ユーザが確定すると、そのカスタマイズ情報の状態は有効となる。このようにすることで、異常なカスタマイズ情報が適用される回数を一回のみとする。

従来はカスタマイズ情報の適用先を特定するためにURLを用いていたが、Webアプリの場合、ユーザからのデータ入力によりページが増加するため、予めURLを知ることは難しいという問題があったが、適用先のURLを正規表現で表したり、適用先のページの中に特定の要素が存在するか否か等の特徴を判定する条件を与えたりすることで適用先を柔軟に表現することを可能とする。

図1に本発明の実施形態の構成図を示す。Webブラウザ111が動作するWebブラウザ処理装置110、Webサーバ131が稼動するWebサーバ処理装置130、プロキシサーバ121が稼動するプロキシサーバ処理装置120が各々ネットワーク100を介して接続している。

プロキシサーバ121はWebサーバ131が返すレスポンスを加工するレスポンス加工処理部122、ユーザが予め作成したカスタマイズ情報を格納するカスタマイズ情報格納リポジトリ123、レスポンスに埋め込んでユーザがカスタマイズ情報を作成可能とするカスタマイズエディタプログラム124がある。

Webサーバ131は、ユーザの入力を受け付けたり、動的にページを生成したりするWebアプリであっても良い。

各処理装置、即ちWebブラウザ処理装置110、プロキシサーバ処理装置120、Webサーバ処理装置130は、図2に示すコンピュータ200の構成を備えており、Webブラウザ111、Webサーバ131、プロキシサーバ121はプログラムで実現する。

図2に一般的なコンピュータ200の構成を示す。ハードディスク203には，プログラムやデータを保存する。ここではハードディスクを例に説明するが、磁気ディスクや不揮発性メモリなどの各種記憶装置であればこれに限られない。中央処理装置202では，これらハードディスク203に蓄えたプログラムやデータを必要に応じてメモリ201に読み込み、中央処理装置202を用いて処理する。ビデオメモリ204は，表示に用いるメモリであり，ビデオメモリ204への変更は，表示装置205に反映する。通信装置206は、ネットワークを介して別のコンピュータと通信するために利用する。通信により、得られたプログラム又はデータは中央処理装置202を用いてハードディスク203に保存したり、メモリ201に格納して処理したりする。以下の図面で説明する本実施形態の処理動作も、各処理装置における中央処理装置202が各処理動作を実行するプログラムやデータをメモリ201に読み込み、必要な処理を実行したり、通信装置206を介して他の処理装置と通信する。

なお、図1のレスポンス加工処理部122はハードウェアでもソフトウェアでも良い。ソフトウェアである場合には、上述のように図2の中央処理装置202によって必要な処理が実行される。また、カスタマイズエディタプログラム124も図2の中央処理装置202によって必要な処理が実行される。カスタマイズ情報格納リポジトリ123は、記憶装置であるハードディスク203に格納される。

また、図1では簡単にするために各々Webブラウザ111、Webサーバ131、プロキシサーバ121が一つずつであるシステムを示しているが、通常のWebシステムでは各々複数存在することが一般的である。Webサーバ131が複数存在するときは、各Webサーバ131に対してプロキシサーバ121を配しても良いし、一つのプロキシサーバ121を通して複数のWebサーバ131にアクセスするように配置しても良い。一つのプロキシサーバ121を通して複数のWebサーバ131にアクセスする場合には、アクセス先となるWebサーバ131に関する情報がプロキシサーバ121に送信され、当該情報に基づいてプロキシサーバ121からWebサーバ131へのアクセスが実行される。

また、図1ではWebブラウザ111、Webサーバ131、プロキシサーバ121を別々の処理装置で稼動させているが、同じ処理装置上で稼動させても良い。

プロキシサーバ121はリバースプロキシサーバとして稼動しても良いし、フォワードプロキシサーバとして稼動しても良い。

リバースプロキシサーバではWebサーバへの振り分けの設定を予め施しておき、Webブラウザ111がリバースプロキシサーバのIPアドレス宛にリクエストを出すと適切なWebサーバ131にリクエストを転送し、Webサーバ131からのレスポンスをWebブラウザ111に戻す。プロキシサーバ121ではリクエスト又はレスポンスに対して適当な処理を施すことができる。

フォワードプロキシサーバではWebブラウザ111にフォワードプロキシサーバのIPアドレスを設定し、Webブラウザ111からWebサーバ131に出すリクエスト、Webサーバ131から受けるレスポンスは自動的にフォワードプロキシサーバを経由する。フォワードプロキシサーバでは、リクエスト、レスポンスに対して適当な処理を実施することができる。図3にWebサーバ131が返すレスポンスに対して適用するカスタマイズ情報があるときに、そのカスタマイズ情報を適用する処理の流れを示す。

事前にWebサーバ131を利用するユーザ301が誰であるかを、ログイン処理等を用いて判別しているものとする。

ユーザ301がリンククリック等302を行うと、Webブラウザ111はプロキシサーバ121にリクエスト303を送出し、プロキシサーバ121も同様にリクエスト304をWebサーバ131に送出する。Webサーバ131にリクエスト304を送出する。Webサーバ131がリクエスト304を受け取ると、リクエスト304に応じた処理305を実施し、レスポンス306を返す。

プロキシサーバ121がレスポンス306を受けると、そのレスポンス306に対してレスポンス加工処理307を実施し、加工したレスポンス308を返す。

Webブラウザ111が加工したレスポンス308を受け取るとクライアント処理309としてレスポンスに含まれるHTMLを表示したり含まれるプログラムを実行したりする。Webブラウザ111はその結果を表示310し、ユーザ301は閲覧する。

図4にレスポンス加工処理307の流れを示す。

最初にWebサーバ131が返したレスポンスを解析する（401）。Webサーバ131はレスポンスとしてHTMLデータを返すことが一般的であるが、このHTMLデータはテキストデータであり、プログラムで加工するのが困難である。そこで、HTMLデータに含まれる要素をDocument Object Model(DOM)等のオブジェクトにすることで加工し易くする。ここではDOMにしたこととして説明する。

次に、カスタマイズ情報格納リポジトリ123からカスタマイズ情報を検索する（402）。以下のステップの説明に先立ち、カスタマイズ情報について図5を用いて説明する。

カスタマイズ情報は、Webサーバ131のレスポンスをどのようにカスタマイズすべきかを示す情報である。カスタマイズ情報は図5に示すカスタマイズ情報格納リポジトリ123に格納する。図5の各行が一つのカスタマイズ情報である。各カスタマイズ情報は、ID501、適用条件502、適用組織・ユーザ503、カスタマイズ内容504、状態505、実行箇所506を持つ。

ID501はカスタマイズ情報を一意に識別するIDである。

適用条件502は、カスタマイズ内容504を適用するHTMLの条件を格納する。以下のような適用条件が考えられる。

（１）リクエスト先URLの条件・・・リクエスト先のURLを適用条件として利用する。URLは固定で記述するだけでなく、正規表現で記述し、その正規表現に合うURLのときにだけカスタマイズ内容を適用するようにしても良い。

（２）HTMLに含まれる要素の有無・・・HTMLに含まれる要素の有無を適用条件として利用する。例えば、HTML内のIDがtable_idである表が存在することを条件とする場合、その要素を取得するためにXPathを用い、存在の有無を確認する方法が考えられる。XPathの例としては、例えば「//table[＠id=’table_id’]」などが考えられる。

（３）HTMLに含まれる要素の値・・・HTMLに含まれる要素の値が特定の値だったときにのみカスタマイズ内容を適用する。HTMLに含まれる要素の値を取得する方法は上記同様XPathを用いる方法が考えられる。上記複数の条件をand/orで組み合わせて適用条件としても良い。

適用組織・ユーザ503は、Webサーバ131のユーザ301の属性に応じてカスタマイズ内容を適用するかどうかを判定する。ユーザ301の属性としては、例えば、組織名、部・課名、ユーザ名などが考えられる。

各属性が特定の値のときにカスタマイズ内容を適用するように設定する。また、各ユーザ301の上記ユーザ属性は、別途ユーザ管理リポジトリ等を用いて管理していることを想定する。

カスタマイズ内容504は、HTMLデータに対するカスタマイズの内容である。カスタマイズ内容504は、実行可能なプログラムで記述しても良いし、カスタマイズ定義として記述して別のプログラムでカスタマイズ定義を解釈しながらカスタマイズを実施するように構成しても良い。

状態505は、カスタマイズ内容504の適用状態を示しており、以下のような状態505を持つことが考えられる。

（１）test・・・テスト状態であることを表す。カスタマイズ情報を新規に作成した直後はテスト状態となる。詳しくは後述する。

（２）available・・・有効状態であることを表す。

（３）disable・・・無効状態であることを表す。

なお、どのように状態が移り変わるかについては後述する。

実行箇所506はカスタマイズを実行する箇所を表す。以下が考えられる。

（１）server・・・プロキシサーバ121で実行することを表す。Webサーバ131が返すHTML内に存在する要素をカスタマイズする場合、serverを設定すれば良い。

（２）client・・・Webブラウザ111で実行するカスタマイズ情報であることを表す。Webブラウザ111でHTML内に含まれるプログラムを実行したときに出現する要素をカスタマイズする場合、clientを設定し、その要素が出現後、カスタマイズを実施するようにする。

また、server、clientを明示的に記述するのではなく、条件で記述する方法も考えられる。例えば、URLが特定の正規表現に合致するとき、サーバプロキシで受け取ったレスポンスに特定の要素が存在するとき、特定の要素が特定の値を持つとき、等の条件を組み合わせ、条件が成り立つ場合はserverで処理し、成り立たない場合はclientとして処理する、等と、プロキシサーバ121内で判定しても良い。

ここで、図4の説明に戻る。カスタマイズ情報を検索する処理402では、解析したレスポンスデータ、利用しているユーザ301、状態505を参照し、適用すべきカスタマイズ情報を探す処理である。

次に、カスタマイズ情報格納リポジトリ123内の各行を取得する（403）。具体的には次の3つの判定を実施し、全てに適合するカスタマイズ情報を取得する。即ち、URLや解析したレスポンスが適用条件に適合するかを評価し判定、現在ログインしているユーザ名とユーザの属性情報が、適用組織・ユーザに適合するかを評価し判定、状態がtest、availableであるかを判定、の３つの判定である。全てのカスタマイズ情報について検索処理を終えたら、取得した各カスタマイズ情報について以下の処理を実施する。

サーバ側カスタマイズ情報であるかどうかを判定し（404）、サーバ側カスタマイズ情報であればサーバ側カスタマイズを実行する（405）。カスタマイズを実行すると、レスポンスを解析する処理401で作成したDOMを変更することになる。

次に、クライアント側カスタマイズ情報が存在するか判定し（406）、存在する場合にはDOMにクライアント側カスタマイズ情報を埋め込む（407）。カスタマイズ情報の状態がtestであるかを判定し（408）、testであれば、カスタマイズ情報可能リポジトリの本カスタマイズ情報の状態をdisableにする処理409を実施し、確定確認を行う処理を埋め込む（410）。確定確認については図10の画面を用いて後で説明する。

検索した結果得られた全カスタマイズ情報について処理し終えたなら（411）、DOMにテキストエディタプログラムを埋め込む（412）。カスタマイズエディタプログラム124はWebブラウザで実行可能なJavaScript（登録商標）等のプログラムで実現する。

最後に、DOMをテキストデータに変換する処理413を実行し、Webブラウザに加工したレスポンスデータ308を返す。

図6にクライアント処理の流れを示す。クライアントはWebブラウザであり、HTMLのレンダリング機能及びJavaScript（登録商標）の実行機能を持つものとする。まず、HTMLのレンダリング機能を用い、レスポンスに含まれるHTMLを表示する（601）。Webサーバ131が返す本来のレスポンスにJavaScript（登録商標）コードが含まれているならそれも実行することでWebブラウザ内にページを表示する。

レスポンスにクライアント側カスタマイズ情報が存在するなら（602）、JavaScript（登録商標）の実行機能を用いてクライアント側カスタマイズを実行する（603）ことにより、Webブラウザに表示したページに修正を加える。最後に、カスタマイズエディタを実行する（604）。カスタマイズエディタもJavaScript（登録商標）により実現されていることを想定する。

以上の処理の結果、生成されるWebページの表示イメージを図7に示す。ページの右下にカスタマイズボタン701を新たに追加している。これがカスタマイズエディタへの入り口となる。このようにカスタマイズエディタへの入り口は普段は邪魔にならないように目立たない位置に配置する。

カスタマイズボタン701を押すと、図8に示すようにカスタマイズメニュー801を表示する。カスタマイズの様子を、社員情報一覧テーブル806内の一番右の操作列を削除する作業を例に説明する。

カスタマイズメニュー801の「テーブル変更」のサブメニューから「列の削除」を選択すると、列の削除ダイアログ802を表示する。削除したい範囲803を選択し、「適用条件」、「実行箇所」、「公開範囲」を設定する。

OKボタン804を押下したときの処理の流れを図9に示す。

カスタマイズ指示901を出すと、Webブラウザ111からユーザ301が設定したカスタマイズ情報902をプロキシサーバ121に送出する。

プロキシサーバ121はカスタマイズ情報格納処理903を行いカスタマイズ情報格納リポジトリ123に、カスタマイズ情報を格納する。このとき、カスタマイズ情報の状態はtestとする。

次に、Webブラウザ111で現在表示しているページをリロードする。現在と同じURLに対してWebブラウザからリクエスト303を送出する。プロキシサーバ121を介してWebサーバにリクエスト304が到達すると、Webサーバ131における処理305を行い、レスポンス306を返す。プロキシサーバ121がレスポンス306を受け取ると、レスポンス加工処理307を実施する。レスポンス加工処理は図4と同様である。

今回は、状態がtestであるカスタマイズ情報が含まれており、カスタマイズ情報を検索する処理において、状態がtestであるカスタマイズ情報を取得したらそのカスタマイズ情報の状態をdisableにする。

次に、加工したレスポンス308をWebブラウザ111に送出し、図6で示したクライアント処理310を実施することでユーザに対してカスタマイズ結果を表示310する。(確定ボタン押下904以降のシーケンスについての説明は後述する。)
カスタマイズ結果、表示する画面の例を図10に示す。削除を指定した列803を削除したページを表示し、「カスタマイズを確定してよろしいですか？」というメッセージを表示した確定確認ダイアログ1001を表示することで確定確認を行う。キャンセルボタンを押すと現在のページをリロードする。リロード時は列の削除のカスタマイズがdisable状態であるため、カスタマイズは適用されない。

図9後半部分を用いて、確定ボタン押下時の処理を説明する。確定ボタン押下904を行うとWebブラウザ111は確定指示905をプロキシサーバに対して実施する。確定したいカスタマイズ情報がどれであるのかを示すIDが同時に送信されるように設定してあるものとする。プロキシサーバ121では、確定処理として、カスタマイズ情報格納リポジトリ123のID501に対応するカスタマイズ情報の状態505をavailableに変更する。

以上の処理により、プロキシサーバ121を通して、適用条件、適用組織・ユーザに合うページを読み込んだときに列の削除のカスタマイズが実施されるようになる。

これまでは、Webサーバ131が出力したレスポンスに対するカスタマイズのみを説明したが、プロキシサーバ121がリクエスト加工処理部を持ち、リクエストに対してカスタマイズを実施しても良い。例えば、Webブラウザ111でユーザ301が入力したデータを、プロキシサーバ121で適切に変換し、Webサーバ131に送信する処理が考えられる。具体例として、ユーザはWebブラウザ111に、社員の氏名を入力すると、リクエスト加工処理部で社員の氏名を社員番号に変換してWebサーバ131に送出し、Webサーバ131では社員番号を受け付けて処理する等が考えられる。

なお、ここではWebブラウザ111にWebサーバ131からのレスポンスを表示させた後にカスタマイズする例を示しているが、いったんカスタマイズした後はカスタマイズ情報をプロキシサーバ121のカスタマイズ情報格納リポジトリ123に格納しておき、その後はWebブラウザ111からの設定処理をすることなく自動的にカスタマイズした内容をWebブラウザ111で表示することが可能である。

本実施例では、カスタマイズの例として、テーブルからの列の削除を用いて説明したが、他にも図11に示すようなカスタマイズが考えられる。

図11においてカスタマイズ種類1101はカスタマイズメニュー801に表示する名前を表し、説明1102はカスタマイズの説明を表し、ユーザ設定情報1103はカスタマイズエディタを通してユーザが入力する情報を表し、例1104はカスタマイズの具体例を表す。

各カスタマイズ種類1101について以下で説明する。

文字列変更は、ページ内に存在する特定の文字列を別の文字列に変更するカスタマイズである。

属性変更はページ内に存在する要素の属性を変更するカスタマイズである。色やフォントサイズなどの属性を変更できる。

入力フォーム変更は、ユーザからの入力を受け付ける入力フォームを変更するカスタマイズである。

テーブル変更は、テーブル(表)の見た目、操作性を変更するカスタマイズである。

閲覧権限追加は、ページの閲覧権限を追加するカスタマイズである。

カスタマイズ権限追加は、カスタマイズ機能毎に利用権限を設定するカスタマイズである。

カスタマイズ機能追加は、プログラム又は複数のカスタマイズ機能を組み合わせて新たにカスタマイズ機能を追加するカスタマイズである。

要素追加は、ページに新たな要素を追加するカスタマイズである。

要素削除は、ページ内の要素を削除するカスタマイズである。

マッシュアップは、別のWebサーバやWebアプリから情報を取得し、カスタマイズ対象のページに埋め込むカスタマイズである。

プログラムは、ページのカスタマイズを実現するプログラムを記述することで実現するカスタマイズする。

管理は、カスタマイズではなく、既に施したカスタマイズの状態を変更したり、公開範囲を変更したり、カスタマイズ情報を削除したりする機能である。

カスタマイズ機能追加についてより詳細に説明する。カスタマイズ機能追加イメージを図12に示す。

画面のテーマを設定するカスタマイズ機能を作成する様子を例に説明する。テーマとは画面の色調を表し、例えば春を選択すると画面の背景をピンクにし、文字を赤に変更する等の変更がなされるものとする。

カスタマイズ機能追加ダイアログ1200を表示し、ユーザ301はカスタマイズ機能を定義する。メニュー名1201には、どのような名前でカスタマイズメニュー801に追加するのかを設定する。ユーザ設定項目1202は、このカスタマイズ機能を利用するユーザ301が追加するカスタマイズ機能を利用するにあたって設定する項目を表す。項目名、入力フォーム、変数名、型で構成する。項目名は、質問の名前である。入力フォームでは、ユーザからの入力方法を指定する。本例では、春、夏、秋、冬の何れかを選択できるように設定している。変数名は、カスタマイズを実行するプログラムで利用するときの変数名である。型は入力するデータの型である。

カスタマイズプログラム1203はカスタマイズプログラムを設定する欄であり、ファイルで指定することを想定する。ここを編集可能なテキストエリア等にすることによりカスタマイズ機能追加ダイアログ1200内で直接コードを変更する方法も考えられる。

既存のカスタマイズ機能をプログラムで容易に利用できるライブラリとして提供することで簡単にカスタマイズ機能を作成できるようにする。今回は、属性変更によりHTMLの各要素の背景色及び、各文字の色を変更するため、カスタマイズプログラムから既存の属性変更機能を簡単に活用できるようにライブラリ化しておくと良い。

作成したカスタマイズ機能を登録すると、図13に示すようにカスタマイズメニュー801にテーマ変更メニュー1302を追加し、これを選択するとテーマ変更ダイアログ1300が出現する。テーマ変更ダイアログ1300では、設定項目1202の設定に従って春、夏、秋、冬を選択する入力フォーム1301が出現する。適当なテーマを選択してOKボタン1303を押下するとテーマが変更され、ページの彩色が変わる。

以上のように、本発明の実施形態により、既存のアプリをカスタマイズ可能にすることができる。さらに、プロキシサーバとWebブラウザのどちらでもカスタマイズを実施可能とすることで、従来Webブラウザで行っていたカスタマイズの量をなくす又は減らすことができるため、Webブラウザで一度表示した要素に変更を加える場合に起こりがちな画面のちらつきを防ぐことができる。

また、Webブラウザにカスタマイズのために必要な情報をプロキシサーバで埋め込んだ上でWebブラウザにレスポンスを返すため、従来技術に比べネットワーク負荷を軽減できる。

また、カスタマイズ情報の状態を管理して、異常があるカスタマイズ情報が適用されることが一回のみとすることで、容易に異常状態から復帰できるようになる。

さらに、カスタマイズの適用先を柔軟に表現できるようにすることで様々なWebアプリのカスタマイズに適用可能となる。

100 ネットワーク
110 Webブラウザ処理装置
111 Webブラウザ
120 プロキシサーバ処理装置
121 プロキシサーバ
122 レスポンス加工処理部
123 カスタマイズ情報格納リポジトリ
124 カスタマイズエディタプログラム
130 Webサーバ処理装置
131 Webサーバ
200 コンピュータ
201 メモリ
202 中央処理装置
203 ハードディスク
204 ビデオメモリ
205 表示装置
206 通信装置
501 ID欄
502 適用条件欄
503 適用組織・ユーザ欄
504 カスタマイズ内容欄
505 状態欄
506 実行箇所欄
701 カスタマイズボタン
801 カスタマイズメニュー
802 列の削除ダイアログ
803 削除する範囲
804 OKボタン
805 キャンセルボタン
1001 確定確認ダイアログ
1002 確定ボタン
1003 キャンセルボタン
1200 カスタマイズ機能追加ダイアログ
1201 メニュー名欄
1202 ユーザ設定項目欄
1203 カスタマイズプログラム設定欄
1204 OKボタン
1205 キャンセルボタン
1300 テーマ変更ダイアログ
1301 テーマ名選択
1302 テーマ変更メニュー
1303 OKボタン
1304 キャンセルボタン

Claims (12)

1. クライアント装置と、前記クライアント装置と通信する第１のサーバ装置と、前記第１のサーバ装置と通信する第２のサーバ装置と、を備えるシステムにおけるデータ提供方法であって、
   前記第１のサーバ装置が、
   前記クライアント装置からのリクエストを前記第２のサーバ装置へ送信するステップと、
   前記クライアント装置からカスタマイズ情報を受信し、前記カスタマイズ情報をテスト状態にして格納されていた場合に、前記テスト状態のカスタマイズ情報を前記リクエストに対する前記第２のサーバ装置から受信したレスポンスデータに適用し、適用した前記テスト状態のカスタマイズ情報を無効状態にするステップと、
   前記カスタマイズ情報を適用した前記レスポンスデータを前記クライアント装置へ送信するステップと、を実行する
   ことを特徴とするデータ提供方法。
2. 請求項１に記載のデータ提供方法であって、
   前記第１のサーバが、
   前記カスタマイズ情報を適用した前記レスポンスデータと共に、前記クライアント装置に確認ダイアログを表示させるプログラムを、前記クライアントへ送信するステップと、
   前記クライアント装置において表示された前記確認ダイアログに対して、前記カスタマイズ情報の適用を確定させる指示が入力されたら、無効状態にされている前記カスタマイズ情報を有効状態にするステップと、を実行する
   ことを特徴とするデータ提供方法。
3. 請求項２に記載のデータ提供方法であって、
   第１のサーバ装置が、
   対応するカスタマイズ情報が存在するレスポンスデータを前記第２のサーバ装置から受信した場合に、当該対応するカスタマイズ情報が無効状態であれば、当該カスタマイズ情報を適用しないレスポンスデータを送信するステップを実行する
   ことを特徴とするデータ提供方法。
4. 請求項２または３に記載のデータ提供方法であって、
   前記第１のサーバ装置が、
   前記クライアント装置へ送信する前記レスポンスデータについて、対応するカスタマイズ情報が存在し、当該対応するカスタマイズ情報が有効状態であれば、当該カスタマイズ情報を適用したレスポンスデータを送信するステップを実行する
   ことを特徴とするデータ提供方法。
5. 請求項３に記載のデータ提供方法であって、
   前記第１のサーバ装置が、
   前記確認ダイアログに対して、前記カスタマイズ情報の適用をキャンセルする指示が入力されたら、
   前記第２のサーバ装置へ、前記リクエストを送信して、前記レスポンスデータを前記第２のサーバ装置からリロードするステップを実行する
   ことを特徴とするデータ提供方法。
6. 請求項１から５のいずれか一に記載のデータ提供方法であって、
   前記クライアント装置は、Webブラウザ処理装置であり、
   前記第１のサーバ装置は、プロキシサーバ処理装置であり、
   前記第２のサーバ装置は、Webサーバ処理装置である
   ことを特徴とするデータ提供方法。
7. クライアント装置とサーバ装置とに通信により接続される中間サーバ装置であって、 前記クライアント装置または前記サーバ装置と通信するための通信部と、
   前記クライアント装置または前記サーバ装置から前記通信部を介して受信したデータを記憶する記憶部と、
   前記通信部と前記記憶部とを制御する演算部と、を備え、
   前記通信部は、
   前記クライアント装置から受信したリクエストを、前記サーバ装置へ送信し、
   前記演算部は、
   前記クライアント装置からカスタマイズ情報を受信し、テスト状態にして、前記記憶部へ格納されていた場合には、
   前記テスト状態のカスタマイズ情報を前記リクエストに対する前記サーバ装置から受信したレスポンスデータに適用し、
   適用した前記テスト状態のカスタマイズ情報を無効状態にし、
   前記通信部は、前記カスタマイズ情報を適用した前記レスポンスデータを前記クライアント装置へ送信する
   ことを特徴とする中間サーバ装置。
8. 請求項７に記載の中間サーバ装置であって、
   前記通信部は、
   前記カスタマイズ情報を適用した前記レスポンスデータと共に、前記クライアント装置に確認ダイアログを表示させるプログラムを、前記クライアントに送信し、
   前記通信部が、前記クライアント装置において表示された前記確認ダイアログに対して、前記カスタマイズ情報の適用を確定させる指示を、前記クライアント装置から受信した場合に、前記演算部は、前記記憶部に格納されている、無効状態にされている前記カスタマイズ情報を有効状態にする
   ことを特徴とする中間サーバ装置。
9. 請求項８に記載の中間サーバ装置であって、
   前記通信部が、対応するカスタマイズ情報が存在するレスポンスデータを前記第２のサーバ装置から受信した場合に、前記演算部は、当該対応するカスタマイズ情報が無効状態であれば、前記レスポンスデータに当該カスタマイズ情報を適用せず、
   前記通信部は、当該カスタマイズ情報を適用しないレスポンスデータを前記クライアント装置へ送信する
   ことを特徴とする中間サーバ装置。
10. 請求項８または９に記載の中間サーバ装置であって、
    前記演算部は、前記クライアント装置へ送信する前記レスポンスデータについて、対応するカスタマイズ情報が存在し、当該対応するカスタマイズ情報が有効状態であれば、当該カスタマイズ情報を適用し、
    前記通信部は、当該カスタマイズ情報を適用した前記レスポンスデータを、前記クライアント装置へ送信する
    ことを特徴とする中間サーバ装置。
11. 請求項９に記載の中間サーバ装置であって、
    前記通信部は、
    前記クライアント装置において表示された前記確認ダイアログに対して、前記カスタマイズ情報の適用をキャンセルする指示を、前記クライアント装置から受信した場合に、
    前記第２のサーバ装置へ、前記リクエストを送信して、前記レスポンスデータを前記サーバ装置からリロードする
    ことを特徴とする中間サーバ装置。
12. 請求項７から１１のいずれか一に記載の中間サーバ装置であって、
    前記クライアント装置は、Webブラウザ処理装置であり、
    前記サーバ装置は、Webサーバ処理装置であり、
    前記中間サーバ装置は、プロキシサーバ処理装置である
    ことを特徴とする中間サーバ装置。
    

Images