JP6089363B2 - ネットワーク通信システム、サーバプッシュ通信制御サーバ、クライアント端末、サーバプッシュ通信制御方法、情報処理方法、およびプログラム - Google Patents

Description

本発明は、ネットワーク通信システムに関し、特に、サーバプッシュ通信を用いたネットワーク通信システムに関するものである。

従来、ＨＴＴＰプロトコルのウェブアプリケーションは、ＨＴＴＰプロトコルが一方向の半二重通信しかサポートしないという点で、制約を受けている。具体的には、アプリケーションの起点がクライアント側のブラウザであり、バックエンドシステム（サーバシステム）への要求という一方向の通信のみサポートするということである。つまり、従来のブラウザとサーバからなるウェブシステムは、一方向の半二重の通信チャネルシステムということである。従って、従来のクライアント／サーバアプリケーションのモデルと比較すると、ＨＴＴＰプロトコルでは、クライアント側が種々のバックエンドシステムと連続的なピアツーピアや全二重通信接続又は双方向半二重通信接続ができないようになっている。加えて、リアルタイムアプリケーション領域では、ＨＴＭＬコンテンツでの複数のユーザが能動的に情報を共有する、リアルタイムサービスの需要が増加している。

一方、従来のウェブブラウザベースのクライアントアプリケーションは、データ要求及び応答が一方向に流れる通信として制約されている。双方向通信をエミュレートする従来の試みは、例えば、コメット・アンド・リバース・アジャック（Ｃｏｍｅｔ ａｎｄ Ｒｅｖｅｒｓｅ Ａｊａｘ）において具現化されるポーリング技術がある。これによれば、サーバ側からクライアント側へ情報をプッシュすることができるように見える。このＣｏｍｅｔアプリケーションは、ストリーミングおよびロングポーリングの２つの主要なカテゴリに分類できる。

ストリーミングＣｏｍｅｔ（非特許文献１参照）を使用するアプリケーションでは、要求イベントに応じクライアントのブラウザからサーバに接続するために単一の持続的な接続を持つ。サーバは新しい応答イベントを送信するたびに、クライアント側で受信し実行する。ストリーミングＣｏｍｅｔを達成するための具体的なテクニックは、非表示のｉｆｒａｍｅとＸＭＬＨｔｔｐＲｅｑｕｅｓｔがある。

非表示のｉｆｒａｍｅは、動的なウェブアプリケーションの基本的なテクニックであり、“永遠フレーム”と呼ばれる。ｉｆｒａｍｅで受信完了イベントが発生すると、各ｓｃｒｉｐｔがブラウザで実行する。非表示のｉｆｒａｍｅの方法の一つの利点は、すべての一般的なブラウザで動作することで、２つの欠点は、信頼性のあるエラー処理方法の欠如、およびリクエスト呼び出しプロセスの状態を追跡することが不可能なことである。

ＸＭＬＨｔｔｐＲｅｑｕｅｓｔ（ＸＨＲ）は、ブラウザとサーバ間の通信のためのＡｊａｘアプリケーションで使用されるサーバブラウザコメットメッセージング（ｓｅｒｖｅｒ−ｂｒｏｗｓｅｒ Ｃｏｍｅｔ ｍｅｓｓａｇｉｎｇ）のためのツールである。ＸＨＲはストリーミングコメットトランスポートとして使用することができ、マルチパートの応答を受け入れる。ＸＨＲが提供するｏｎｒｅａｄｙｓｔａｔｅｃｈａｎｇｅは各メッセージが到着すると、イベントに割当てたコールバック関数を呼び出す。ＸＨＲストリーミングはリーミング接続を確立するのにＨＴＴＰヘッダパケットを一度しか送信しないため、最小のオーバーヘッドしか課さない。しかしＸＨＲストリーミングは、ルーティング経路による予想不能な接続／切断及び実質的なバッファリング待ち時間の影響受けるため、信頼できない。

また、直接的ポーリングのオーバーヘッドを回避するために、ロングポーリングとして知られる方法が開発された（非特許文献２参照）。非同期ポーリングとしても知られているロングポーリングは、ターゲットウェブサーバシステムに要求を発行し、即座の応答を与えるのではなく、サーバはある定義されたインターバルまで遅延し、新たな情報が応答として与えられるのを待機する。このようにロングポーリングは、クライアントがイベント（またはイベントのセット）のためにサーバをポーリングする必要がある。そして、ブラウザからサーバにＡｊａｘスタイルの要求を行い、サーバから完全な応答をブラウザに送信する。その後、ブラウザが後続のイベントを取得するために、新しい長いポーリング要求を開始する。このロングポーリングを達成するための具体的な技術は、ＸＭＬＨｔｔｐＲｅｑｕｅｓｔのロングポーリングと、Ｓｃｒｉｐｔタグのロングポーリングがある。

ＸＭＬＨｔｔｐＲｅｑｕｅｓｔのロングポーリングは、ＸＨＲの標準的な使用と同じように動作する。ブラウザが応答する前に、利用できるようにデータを待つ可能性のあるサーバの非同期要求を行う。応答は、エンコードされたデータ形式またはＪａｖａＳｃｒｉｐｔ(登録商標)である。レスポンスの処理の終了時に、ブラウザは次のイベントを待つために、別のＸＨＲを作成して送信する。したがって、ブラウザは常に各イベントが発生したように、サーバにリクエストを送る。

ｉｆｒａｍｅまたはＸＭＬＨｔｔｐＲｅｑｕｅｓｔとは異なり、Ｓｃｒｉｐｔタグによる任意のＵＲＩによって得られたＪａｖａＳｃｒｉｐｔ(登録商標)コードは、カレントのＨＴＭＬドキュメントで実行される。ロングポーリングコメットトランスポートは動的に作成することによって作成することができる。このメソッドは、クロスドメインの実装を可能にしながら、クロスブラウザであるという利点がある。この方法の欠点は、関与するサーバの潜在的なセキュリティリスクがあり、合わせて複雑さやパフォーマンスの理由から望ましくない。

なお、この種の関連する技術として、特許文献１に記載されたものが挙げられる。

Ｗｉｋｉｐｅｄｉａ（ｈｔｔｐ：／／ｊａ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／Ｃｏｍｅｔ） Ｗｉｋｉｐｅｄｉａ（ｈｔｔｐ：／／ｊａ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／ＸＭＬＨｔｔｐＲｅｑｕｅｓｔ＃．Ｅ３．８３．ＡＤ．Ｅ３．８３．Ｂ３．Ｅ３．８２．Ｂ０．Ｅ３．８３．９Ｄ．Ｅ３．８３．ＢＣ．Ｅ３．８３．ＡＡ．Ｅ３．８３．Ｂ３．Ｅ３．８２．Ｂ０）

特開２０１０−５５５６０号公報

ここで、ウェブソケット等のＷｅｂ技術を用いれば、ＴＣＰ接続による全二重シングルを介した通信チャネルを提供することができる。特にウェブソケットのＡＰＩはＷ３Ｃによって標準化され、ウェブソケットのプロトコルはＩＥＴＦとしてＲＦＣ６４５５によって標準化されており、インディペンデントなＴＣＰベースのプロトコルである。これは、サーバがクライアントによって要求されることなく、ブラウザにコンテンツを送信するための標準化された方法を提供し、接続を開いたままのメッセージを前後に渡されることを可能にすることによって実現している。この利点は、単一のＴＣＰ／ＩＰ接続で非同期の双方向ストリーミングが完全にできるだけでなく、ＨＴＴＰヘッダが少なくて済むという点であり、さらに重要なのはブラウザからでもサービスからでも同じメッセージフォーマットを使えば済むことである。

しかし、ウェブソケットを用いたウェブアプリケーション開発は、これまでのＨＴＴＰプロトコルを用いたサーバでページを生成するサーバサイドアプリケーションになじまないものである。このため、ウェブソケットとＡｊａｘの組み合わせによるサーバプッシュ機能を、これまでのＣｏｍｅｔ技術と置き換えることにより、従来のウェブアプリケーション開発のスタイルからの変更点を最小限として、ウェブアプリケーションを開発することが望まれている。つまり、ビジネス及び他の商業的サービス、リクリエーション及び情報を含む全ての特性のウェブサービスにアクセスすることに使用できるウェブアプリケーションに対し、ウェブソケットとＡｊａｘの組み合わせによるサーバプッシュ機能を代替する容易な手段が要望されている。

本発明は、このような事情に鑑みてなされたものであり、ウェブソケット等の全二重通信技術とＡｊａｘ等の半二重通信技術の組み合わせによってなされるもので、サーバ側が起点となって出されるサーバプッシュ要求をブラウザ側で受信し、受信したイベントを介してブラウザからサーバプッシュ・データを取得するための要求を送出することによる、双方向の半二重の通信チャネルシステムを形成するネットワーク通信システムを提供することを目的とする。

上記課題を解決するため、本発明は、複数台のウェブサーバから成るシステムで、バックエンドのアプリケーションサーバ（コンテンツサーバ）をサービス毎に分散させておきながら、ユーザから利用するサービスポイントは１つとする構成であるウェブアプリケーションのネットワーク通信システムにおいて、それぞれのサービスからサーバプッシュ要求を受け取り、クライアント端末のブラウザにサーバプッシュ要求を送出するサーバプッシュ通信制御サーバと、クライアント端末のブラウザでサーバプッシュ要求を受け取る機構と合わせてサーバプッシュ・データを取得するための要求を送出するプログラムで構成される。

詳しくは、第一の発明は、複数のコンテンツサーバと、サーバプッシュ通信制御サーバと、これらをシングルドメインとして構成するリバースプロキシサーバと、を備えるサーバシステムと、クライアント端末上で、複数のコンテンツフレーム及びサーバプッシュ通信制御フレームを備えたブラウザと、が所定のネットワークを介して繋がるネットワーク通信システムであって、前記ブラウザの前記複数のコンテンツフレームの各々は、前記複数のコンテンツサーバの各々と１対１で対応しており、対応するコンテンツサーバからの情報に応じて、各コンテンツフレームの表示が決定されるようになっており、前記複数のコンテンツサーバのうちの一のコンテンツサーバで、前記複数のコンテンツフレームのうちの対応する一のコンテンツフレームの一の更新要求が発生すると、前記一のコンテンツサーバが、前記サーバプッシュ通信制御サーバに前記一の更新要求を送信し、前記サーバプッシュ通信制御サーバが、受信した前記一の更新要求を、前記リバースプロキシサーバを介して、前記ブラウザの前記サーバプッシュ通信制御フレームに送信し、前記サーバプッシュ通信制御フレームが、受信した前記一の更新要求を、対応する前記一のコンテンツフレームに送信し、前記一のコンテンツフレームが、受信した前記一の更新要求に基づき、対応する前記一のコンテンツサーバに対して一の更新情報要求を送信し、前記一のコンテンツサーバが、受信した前記一の更新情報要求に応じて、一の更新情報を前記一のコンテンツフレームに送信し、前記一のコンテンツフレームが、受信した前記一の更新情報に基づき、表示を更新するように構成されたネットワーク通信システムとしたことを特徴とする。

ここで、クライアント端末のブラウザとサーバプッシュ通信制御サーバとの間では、ＴＣＰ／ＩＰベースの通信接続を確立し、クライアント端末のブラウザはサーバプッシュ通信制御サーバからのリクエストを常に待つ。ＴＣＰ／ＩＰベースの通信接続は、ソースとターゲット起点との間にセキュアな通信経路を与えるクロス起点通信ブリッジを含む。サーバプッシュ通信制御サーバにおいて、要求識別ウェブアプリケーションサービスに対して規定の関係を有するターゲットサーバによって提供されるターゲット定義サービスへはＨＴＭＬでの接続である。

また、第二の発明は、第一の発明の構成に加え、前記サーバプッシュ通信制御サーバが、受信した前記一の更新要求を、前記リバースプロキシサーバを介して、前記ブラウザの前記サーバプッシュ通信制御フレームに送信する通信を、ウェブソケット通信で行うことを特徴とする。

第一の発明によれば、従来のウェブアプリケーション開発のスタイルからの変更点を最小限とした上で、コンテンツサーバ側から更新要求があるまでは、クライアント端末側ではサーバに向けて通信を行わないため、ネットワークに対する通信負荷を劇的に軽減することができ、かつ、所定のサーバプッシュ通信に基づいて、クライアント端末のブラウザで常に新しい情報を表示することができるネットワーク通信システムとすることができる。

また、第二の発明によれば、第一の発明の効果に加え、サーバプッシュ通信制御サーバが、受信した一の更新要求を、リバースプロキシサーバを介して、ブラウザのサーバプッシュ通信制御フレームに送信する通信を、ウェブソケット通信で行うため、具体的に、ネットワークに対する通信負荷を劇的に軽減した上で、クライアント端末のブラウザで常に新しい情報を表示することができる有効な通信システムとすることができる。

本発明の実施の形態に係るネットワーク通信システムの基本構成を示す図である。 本発明の実施の形態に係るネットワーク通信システムを使用したクライアント端末のブラウザの表示例を示す図である。

以下、この発明の実施の形態について図１及び図２を用いて説明する。

図１は、本発明の実施の形態に係るネットワーク通信システムの基本構成を示す図である。また、図２は、本発明の実施の形態に係るネットワーク通信システムを使用したクライアント端末のブラウザの表示例を示す図である。

まず、図１及び図２を用いて本実施の形態のネットワーク通信システムの構成について説明する。

本実施の形態のネットワーク通信システムは、複数のサーバからなるサーバシステム１０と、クライアント端末としてのパーソナルコンピュータ上に実装されたブラウザ（Ｗｅｂブラウザ）２０が、ネットワークとしてのインターネットＮを介して、ＴＣＰ/ＩＰベースの通信接続を確立して構成されている。

このうち、サーバシステム１０は、複数のコンテンツサーバ１１，１２，１３とサーバプッシュ通信制御サーバ１４とリバースプロキシサーバ１５を有する構成となっている。

複数のコンテンツサーバ１１，１２，１３は、後述するブラウザ２０のコンテンツフレーム２１，２２，２３にそれぞれ１対１で対応しており、コンテンツＡサーバ１１が後述するコンテンツＡ用フレーム２１に表示する情報（ここでは天気情報）を送信するものであり、コンテンツＢサーバ１２が後述するコンテンツＢ用フレーム２２に表示する情報（ここではカレンダー情報）を送信するものであり、コンテンツＣサーバ１３が後述するコンテンツＣ用フレーム２３に表示する情報（ここでは時刻情報）を送信するものである。なお、ここでは、コンテンツサーバとしてＡ〜Ｃの３つのサーバを挙げているが、これ以外にもコンテンツサーバを有していて、サーバシステム１０に４つ以上のコンテンツサーバを有する構成となっていても良い。

サーバプッシュ通信制御サーバ１４は、各コンテンツサーバ１１，１２，１３から送信された、対応するコンテンツフレーム２１，２２，２３に対する更新要求を受信し、サーバプッシュ技術を用いて、リバースプロキシサーバ１５及びインターネットＮ等のネットワークを介して、クライアント端末のブラウザ２０の各コンテンツフレーム２１，２２，２３に当該更新要求を送信するものである。本実施の形態では、サーバプッシュ技術として、ウェブソケット通信を用いるようになっている。このウェブソケット通信では、サーバシステム１０側からサーバプッシュ通信があるまでは、クライアント端末のブラウザ２０側から更新情報の要求等の通信を一切行わないため、ネットワークに対する通信負荷を大幅に軽減することができる。

リバースプロキシサーバ１５は、サーバプッシュ通信制御サーバ１４から送信された各コンテンツサーバ１１，１２，１３からの更新要求を、１のドメインで管理するためのサーバである。これにより、インターネットＮ等のネットワーク上からは、サーバシステム１０全体がシングルドメインの１つのサーバから構成されているかのように見せることができる。

また、ブラウザ２０は、複数のコンテンツフレーム２１，２２，２３を有すると共に、サーバプッシュ通信制御フレーム２４を有する構成となっている。なお、本実施の形態では、図２に示すような業務管理Ｗｅｂアプリケーションにおける一部のコンテンツフレームに、本発明のネットワーク通信システムを適用したものについて説明する。このため、ブラウザ２０上には、本発明のネットワーク通信システムを利用したコンテンツフレーム以外に、業務データを表示する売上管理表フレーム２５、実績グラフフレーム２６、巡回予定表フレーム２７等が表示されるようになっているが、詳しい説明は省略する。

複数のコンテンツフレーム２１，２２，２３は、前記したサーバシステム１０のコンテンツサーバ１１，１２，１３にそれぞれ対応しており、図２に示すように、コンテンツＡ用フレーム２１がコンテンツＡサーバ１１からの更新要求に対応して更新情報を取得してコンテンツの表示（ここでは天気情報の表示）を行うものであり、コンテンツＢ用フレーム２２がコンテンツＢサーバ１２からの更新要求に対応して更新情報を取得してコンテンツの表示（ここではカレンダー情報の表示）を行うものであり、コンテンツＣ用フレーム２３がコンテンツＣサーバ１３からの更新要求に対応して更新情報を取得してコンテンツの表示（ここでは時刻情報の表示）を行うものである。なお、ここでは、コンテンツフレームとしてＡ〜Ｃの３つのフレームを挙げているが、これ以外にもコンテンツフレームを有していて、ブラウザ２０に４つ以上のコンテンツフレームを有する構成となっていても良い。

サーバプッシュ通信制御フレーム２４は、各コンテンツサーバ１１，１２，１３からサーバプッシュ通信制御サーバ１４、リバースプロキシサーバ１５及びインターネットＮ等のネットワークを介して送信された、各コンテンツフレーム２１，２２，２３に対する更新要求を受信し、各コンテンツフレーム２１，２２，２３に当該更新要求を送信するものである。前記したように、本実施の形態では、サーバプッシュ技術として、ウェブソケット通信を用いるようになっているため、サーバシステム１０側からサーバプッシュ通信があるまでは、クライアント端末のブラウザ２０側から更新情報の要求等の通信を一切行わないようになっている。これにより、ネットワークに対する通信負荷を大幅に軽減することができる。

次に、このネットワーク通信システムを用いた一のコンテンツフレームの更新に関する制御の流れについて、図１を用いて説明する。

例えば、複数のコンテンツサーバ１１，１２，１３のうちの一のコンテンツサーバとしてのコンテンツＡサーバ１１で、複数のコンテンツフレーム２１，２２，２３のうちの対応する一のコンテンツフレームとしてのコンテンツＡ用フレーム２１の一の更新要求（最新の天気情報に更新するように求める要求）が発生した場合には、まず、一のコンテンツサーバとしてのコンテンツＡサーバ１１が、サーバプッシュ通信制御サーバ１４に一の更新要求を送信する（矢印（１））。

次に、サーバプッシュ通信制御サーバ１４が、コンテンツＡサーバ１１から受信した一の更新要求を、リバースプロキシサーバ１５を介して、ネットワークとしてのインターネットＮを通じ、ブラウザ２０のサーバプッシュ通信制御フレーム２４に送信する（矢印（２））。このとき、通信技術としてウェブソケット通信を用いて送信する。

次に、サーバプッシュ通信制御フレーム２４が、コンテンツＡサーバ１１からサーバプッシュ通信制御サーバ１４、リバースプロキシサーバ１５及びインターネットＮを介して受信した一の更新要求を、対応する一のコンテンツフレームとしてのコンテンツＡ用フレーム２１に送信する（矢印（３））。

次に、一のコンテンツフレームとしてのコンテンツＡ用フレーム２１が、コンテンツＡサーバ１１からサーバプッシュ通信制御サーバ１４、リバースプロキシサーバ１５、インターネットＮ及びサーバプッシュ通信制御フレーム２４を介して受信した一の更新要求に基づき、対応する一のコンテンツサーバとしてのコンテンツＡサーバ１１に対して一の更新情報要求（最新の天気情報の要求）を送信する（矢印（４））。なお、この通信には、Ａｊａｘ技術を利用している。

次に、一のコンテンツサーバとしてのコンテンツＡサーバ１１が、一のコンテンツフレームとしてのコンテンツＡ用フレーム２１から受信した一の更新情報要求に応じて、一の更新情報（最新に天気情報）をコンテンツＡ用フレーム２１に送信する（矢印（５））。なお、この通信も、Ａｊａｘ技術を利用して行う。

そして、コンテンツＡ用フレーム２１が、コンテンツＡサーバ１１から受信した一の更新情報に基づき、ブラウザ２０における当該フレーム２１の表示（天気情報）を最新のものに更新する（（６）再表示）。

なお、この制御の流れは、他のコンテンツサーバ１２，１３から対応するコンテンツフレーム２２，２３に対する更新要求が発生したときも同様である。例えば、コンテンツＢサーバ１２とコンテンツＢ用フレーム２２の間では、日にち変更があったときに前記したような（１）〜（６）の通信が行われてコンテンツＢ用フレーム２２の日にち表示が更新され、コンテンツＣサーバ１３とコンテンツＣ用フレーム２３の間では、時刻確認又は時刻調整の情報があったときに前記したような（１）〜（６）の通信が行われてコンテンツＣ用フレーム２３の時刻表示が更新される。

以上のように、本実施の形態では、複数のコンテンツサーバ１１，１２，１３と、サーバプッシュ通信制御サーバ１４と、これらをシングルドメインとして構成するリバースプロキシサーバ１５と、を備えるサーバシステム１０と、クライアント端末上で、複数のコンテンツフレーム２１，２２，２３及びサーバプッシュ通信制御フレーム２４を備えたブラウザ２０と、が所定のネットワークとしてのインターネットＮを介して繋がるネットワーク通信システムであって、前記ブラウザ２０の前記複数のコンテンツフレーム２１，２２，２３の各々は、前記複数のコンテンツサーバ１１，１２，１３の各々と１対１で対応しており、対応するコンテンツサーバ１１，１２，１３からの情報に応じて、各コンテンツフレーム２１，２２，２３の表示が決定されるようになっており、前記複数のコンテンツサーバ１１，１２，１３のうちの一のコンテンツサーバとしてのコンテンツＡサーバ１１で、前記複数のコンテンツフレーム２１，２２，２３のうちの対応する一のコンテンツフレームとしてのコンテンツＡ用フレーム２１の一の更新要求が発生すると、前記一のコンテンツサーバとしてのコンテンツＡサーバ１１が、前記サーバプッシュ通信制御サーバ１４に前記一の更新要求を送信し、前記サーバプッシュ通信制御サーバ１４が、受信した前記一の更新要求を、前記リバースプロキシサーバ１５を介して、前記ブラウザ２０の前記サーバプッシュ通信制御フレーム２４に送信し、前記サーバプッシュ通信制御フレーム２４が、受信した前記一の更新要求を、対応する前記一のコンテンツフレームとしてのコンテンツＡ用フレーム２１に送信し、前記一のコンテンツフレームとしてのコンテンツＡ用フレーム２１が、受信した前記一の更新要求に基づき、対応する前記一のコンテンツサーバとしてのコンテンツＡサーバ１１に対して一の更新情報要求を送信し、前記一のコンテンツサーバとしてのコンテンツＡサーバ１１が、受信した前記一の更新情報要求に応じて、一の更新情報を前記一のコンテンツフレームとしてのコンテンツＡ用フレーム２１に送信し、前記一のコンテンツフレームとしてのコンテンツＡ用フレーム２１が、受信した前記一の更新情報に基づき、表示を更新するように構成されたネットワーク通信システムとしたことを特徴とする。

そして、本実施の形態によれば、コンテンツサーバ１１，１２，１３側から更新要求があるまでは、クライアント端末側ではサーバに向けて通信を行わないため、ネットワークとしてのインターネットＮに対する通信負荷を劇的に軽減することができ、その上で、所定のサーバプッシュ通信に基づいて、クライアント端末のブラウザ２０で常に新しい情報を表示することができるネットワーク通信システムとすることができる。

特に、クライアント端末のブラウザ２０における複数のコンテンツフレーム２１，２２，２３が、それぞれ対応するコンテンツサーバ１１，１２，１３から更新情報を得て表示を更新するようなシステムの場合、ロングポーリング等を含むブラウザ２０側からの起点による従来の半二重通信で更新情報を得ようとすると、ブラウザ２０側から所定間隔で更新情報を要求する通信がコンテンツフレーム数分だけ必要となるため、ネットワークに対する通信負荷が大きくなってしまう可能性が高いが、本実施の形態のような、各コンテンツサーバ１１，１２，１３側から更新要求があるまではブラウザ２０のコンテンツフレーム２１，２２，２３側から通信を行わないシステムとすれば、このような状況のネットワークに対する通信負荷を大きく軽減することができるものである。

また、コンテンツサーバ側からコンテンツフレーム側に更新要求の通信を行った後の通信技術は、Ａｊａｘ技術等の既知の技術を利用することができるため、従来のシステムに対するソースコードの追加、変更を最小限にすることができ、従来のシステムに本技術を比較的簡単に導入することができる。

また、本実施の形態では、前記した構成に加え、前記サーバプッシュ通信制御サーバ１４が、受信した前記一の更新要求を、前記リバースプロキシサーバ１５を介して、前記ブラウザ２０の前記サーバプッシュ通信制御フレーム２４に送信する通信を、ウェブソケット通信で行うことを特徴とする。

そして、本実施の形態によれば、前記した効果に加え、サーバプッシュ通信制御サーバ１４が、受信した一の更新要求を、リバースプロキシサーバ１５を介して、ブラウザ２０のサーバプッシュ通信制御フレーム２４に送信する通信を、ウェブソケット通信で行うため、具体的に、ネットワークとしてのインターネットＮに対する通信負荷を劇的に軽減した上で、クライアント端末のブラウザ２０で常に新しい情報を表示することができる有効な通信システムとすることができる。

ここで、ウェブソケット等のＷｅｂ技術を用いれば、ＴＣＰ接続による全二重シングルを介した通信チャネルを提供することができる。特にウェブソケットのＡＰＩはＷ３Ｃによって標準化され、ウェブソケットのプロトコルはＩＥＴＦとしてＲＦＣ６４５５によって標準化されており、インディペンデントなＴＣＰベースのプロトコルである。これは、サーバがクライアントによって要求されることなく、ブラウザにコンテンツを送信するための標準化された方法を提供し、接続を開いたままのメッセージを前後に渡されることを可能にすることによって実現している。この利点は、単一のＴＣＰ／ＩＰ接続で非同期の双方向ストリーミングが完全にできるだけでなく、ＨＴＴＰヘッダが少なくて済むという点であり、さらに重要なのはブラウザからでもサービスからでも同じメッセージフォーマットを使えば済むことである。

なお、以上説明した実施の形態は、本発明の理解を容易にするために記載されたものであって、本発明を限定するために記載されたものではない。

例えば、前記した実施の形態では、サーバシステム１０とブラウザ２０の間を繋ぐネットワークとしてインターネットＮを挙げたが、本発明はこれに限るものではなく、他のネットワークを介する通信システムであっても良い。

また、前記した実施の形態では、サーバプッシュ通信制御サーバ１４からサーバプッシュ通信制御フレーム２４までの通信をウェブソケット通信で行うようになっていたが、本発明はこれに限らず、サーバ側からのサーバプッシュ通信があるまで、クライアント端末のブラウザ側からサーバ側に対して通信を行わない通信方式であれば、ウェブソケット通信以外の通信方式を適用しても良い。

１０ サーバシステム
１１ コンテンツＡサーバ（コンテンツサーバ）
１２ コンテンツＢサーバ（コンテンツサーバ）
１３ コンテンツＣサーバ（コンテンツサーバ）
１４ サーバプッシュ通信制御サーバ
１５ リバースプロキシサーバ
２０ ブラウザ
２１ コンテンツＡ用フレーム（コンテンツフレーム）
２２ コンテンツＢ用フレーム（コンテンツフレーム）
２３ コンテンツＣ用フレーム（コンテンツフレーム）
２４ サーバプッシュ通信制御フレーム
Ｎ インターネット（ネットワーク）

Claims (5)

1. 複数のコンテンツサーバと、サーバプッシュ通信制御サーバと、これらをシングルドメインとして構成するリバースプロキシサーバと、を備えるサーバシステムと、
   複数のコンテンツフレーム及びサーバプッシュ通信制御フレームを備えたブラウザが動作するクライアント端末と、
   が所定のネットワークを介して繋がるネットワーク通信システムであって、
   前記ブラウザの前記複数のコンテンツフレームの各々は、前記複数のコンテンツサーバの各々と１対１で対応しており、対応するコンテンツサーバからの情報に応じて、各コンテンツフレームの表示が決定されるようになっており、
   前記複数のコンテンツサーバのうちの一のコンテンツサーバで、前記複数のコンテンツフレームのうちの対応する一のコンテンツフレームの一の更新要求が発生すると、
   前記一のコンテンツサーバが、前記サーバプッシュ通信制御サーバに前記一の更新要求を送信し、
   前記サーバプッシュ通信制御サーバが、受信した前記一の更新要求を、前記リバースプロキシサーバを介して、前記ブラウザの前記サーバプッシュ通信制御フレームに送信し、
   前記サーバプッシュ通信制御フレームが、受信した前記一の更新要求を、対応する前記一のコンテンツフレームに送信し、
   前記一のコンテンツフレームが、受信した前記一の更新要求に基づき、対応する前記一のコンテンツサーバに対して一の更新情報要求を送信し、
   前記一のコンテンツサーバが、受信した前記一の更新情報要求に応じて、一の更新情報を前記一のコンテンツフレームに送信し、
   前記一のコンテンツフレームが、受信した前記一の更新情報に基づき、表示を更新するように構成されたことを特徴とするネットワーク通信システム。
2. 前記サーバプッシュ通信制御サーバが、受信した前記一の更新要求を、前記リバースプロキシサーバを介して、前記ブラウザの前記サーバプッシュ通信制御フレームに送信する通信を、ウェブソケット通信で行うことを特徴とする請求項１に記載のネットワーク通信システム。
3. 複数のコンテンツサーバから送信された複数の各コンテンツを表示する複数のコンテンツフレームとサーバプッシュ通信制御フレームとを有するブラウザが動作するクライアント端末であって、
   サーバプッシュ通信制御サーバが、複数のコンテンツサーバのうちの一のコンテンツサーバにおいて発生した更新要求であり、クライアント端末のブラウザが有する複数のコンテンツフレームのうちの一のコンテンツフレームに対する更新要求を、前記一のコンテンツサーバから受信し、当該受信した更新要求を、リバースプロキシサーバを介して前記クライアント端末に送信すると、前記サーバプッシュ通信制御サーバから送信された更新要求を、リバースプロキシサーバを介して受信し、
   前記更新要求の受信に対応して、当該更新要求に対するコンテンツフレームに対応する一のコンテンツサーバであって、前記複数のコンテンツサーバのうちの一のコンテンツサーバに対して、コンテンツの更新の要求である更新情報要求を送信し、
   前記更新情報要求の送信に応じて、前記一のコンテンツサーバから、前記コンテンツフレームに表示されるコンテンツを更新する更新情報を受信し、
   前記更新情報の受信に応じて、前記コンテンツフレームの表示を更新するクライアント端末。
4. 複数のコンテンツサーバから送信された複数の各コンテンツを表示する複数のコンテンツフレームとサーバプッシュ通信制御フレームとを有するブラウザが起動しているクライアント端末における情報処理方法であって、
   サーバプッシュ通信制御サーバが、複数のコンテンツサーバのうちの一のコンテンツサーバにおいて発生した更新要求であり、クライアント端末のブラウザが有する複数のコンテンツフレームのうちの一のコンテンツフレームに対する更新要求を、前記一のコンテンツサーバから受信し、当該受信した更新要求を、リバースプロキシサーバを介して、前記クライアント端末に送信すると、
   クライアント端末が、
   前記サーバプッシュ通信制御サーバから送信された更新要求を、リバースプロキシサーバを介して受信し、
   前記更新要求の受信に対応して、当該更新要求に対するコンテンツフレームに対応する一のコンテンツサーバであって、前記複数のコンテンツサーバのうちの一のコンテンツサーバに対して、コンテンツの更新の要求である更新情報要求を送信し、
   前記更新情報要求の送信に応じて、前記一のコンテンツサーバから、前記コンテンツフレームに表示されるコンテンツを更新する更新情報を受信し、
   前記更新情報の受信に応じて、前記コンテンツフレームの表示を更新する、
   ことを特徴とする情報処理方法。
5. 複数のコンテンツサーバから送信された複数の各コンテンツを表示する複数のコンテンツフレームとサーバプッシュ通信制御フレームとを有するブラウザが起動しているクライアント端末において動作するプログラムであって、
   サーバプッシュ通信制御サーバが、複数のコンテンツサーバのうちの一のコンテンツサーバにおいて発生した更新要求であり、クライアント端末のブラウザが有する複数のコンテンツフレームのうちの一のコンテンツフレームに対する更新要求を、前記一のコンテンツサーバから受信し、当該受信した更新要求を、リバースプロキシサーバを介して、前記クライアント端末に送信すると、
   コンピュータに、
   前記サーバプッシュ通信制御サーバから送信された更新要求を、リバースプロキシサーバを介して受信し、
   前記更新要求の受信に対応して、当該更新要求に対するコンテンツフレームに対応する一のコンテンツサーバであって、前記複数のコンテンツサーバのうちの一のコンテンツサーバに対して、コンテンツの更新の要求である更新情報要求を送信し、
   前記更新情報要求の送信に応じて、前記一のコンテンツサーバから、前記コンテンツフレームに表示されるコンテンツを更新する更新情報を受信し、
   前記更新情報の受信に応じて、前記コンテンツフレームの表示を更新する、 処理を実行させることを特徴とするプログラム。