JP4117889B2 - ウェブアプリケーションを実行するための通信を制御するコンピュータおよびその方法 - Google Patents

Description

本発明は、ウェブアプリケーションを実行するための通信を制御するシステムに関し、特に複数のセッションが使用されるサーバと端末装置との間の通信制御を行うシステムおよびその方法に関する。

今日、コンピュータネットワーク（以下、ネットワークと略す）を利用して、離れた場所にあるセンターシステム（以下、センターと略す）とリモートオフィスとを接続して業務を遂行することが実現されている。リモートオフィスでは、業務の必要に応じて、端末装置によりネットワークを介してセンターのサーバにアクセスし、所望のアプリケーションを利用したり、データをダウンロードまたはアップロードしたりすることが行われる。インターネット等のウェブベースのネットワークの普及に伴い、最近では、リモートオフィスが利用するアプリケーションは、ウェブアプリケーション（Ｊａｖａ（米国サン・マイクロシステムズ社の商標）サーブレット等）の形態で提供されることが多くなっている。

ここで、それぞれのアプリケーションが固有の回線を介して利用されるのであれば、各アプリケーションで必要な通信帯域を固定的に確保することができる。これに対し、各アプリケーションがウェブアプリケーションの形態で提供される場合、複数のアプリケーションが同時に使用されると、回線の持つ通信帯域をこれら複数のアプリケーションで分け合うこととなる。
一方で、リモートオフィスの端末装置からセンターのサーバにアクセスして行われる業務には、迅速な処理の実行が要求されるものもあれば、時間的な制約の厳しくない処理もある。そのため、実行中のアプリケーションで均等に通信帯域を分けると、実行されるアプリケーションの種類によっては、作業効率の低下を招来してしまう。

例えば、リモートオフィスにおいて、商品の受注や発注を行う業務は、迅速に処理が実行されることが好ましい。一方、データをダウンロードする作業は、迅速さを要求されることは少ないが、実行中は回線を使用し続けるという特徴がある。そのため、受発注業務とデータのダウンロードとが同時に実行されると、迅速を要する受発注業務の作業が遅れ、作業効率が低下してしまうこととなる。

この受発注業務のような迅速さを要する業務に対して優先的に回線を使用させるために、アプリケーションの種類に基づいて通信帯域を割り振る制御方法が考えられる。この制御方法によれば、迅速な処理を要求されるアプリケーションに対して広い通信帯域を設定し、迅速な処理を要求されないアプリケーションに対して狭い通信帯域を設定することにより、広い通信帯域を設定されたアプリケーションを使用する場合には、他のアプリケーションが使用されているか否かに関わらず、高速な通信により迅速に処理を実行することが可能となる。

また、通信帯域の割り当てを偏重させる通信制御を行う従来技術としては、アプリケーションを使用するユーザやアクセスした端末装置に応じて通信帯域を割り振る制御方法が提案されている（例えば、特許文献１、２参照）。この従来技術によれば、広い通信帯域を割り当てられた特定のユーザがログオンした場合には、そのユーザが使用するアプリケーションにおいて広い通信帯域を利用できるため、他のユーザが他のアプリケーションを使用しているか否かに関わらず、高速な通信により迅速に処理を実行することが可能となる。

特開２０００−９２１２３号公報 特開２００３−１６０３１号公報

上述したように、コンピュータネットワークによりリモートオフィスを実現するシステムでは、作業効率の低下を防止するために、複数のセッションに対して回線の使用帯域を均等に割り振るのではなく、アプリケーションやユーザに応じて偏重させて割り振る従来技術がある。

しかしながら、アプリケーションの種類に基づいて通信帯域を設定する制御方法では、アプリケーションごとに割り当てられる通信帯域が固定されてしまう。そのため、あるアプリケーションが単独で使用されている場合であっても、そのアプリケーションに対して設定された通信帯域しか利用することができない。作業効率の観点からは、他のアプリケーションが使用されていない場合には、特に迅速な処理を要求されない業務であっても、使用中のアプリケーションが空いている通信帯域を全部使えるように動的な制御を行うことが好ましいが、そのような制御はできない。

また、ユーザや端末装置ごとに使用可能な通信帯域を割り振る従来技術では、ログオンユーザに応じて利用可能な通信帯域が決まってしまうことになる。そのため、狭い通信帯域を割り当てられたユーザが迅速な処理が要求される作業を行う場合には作業効率の著しい低下を招くこととなる。ユーザごとに使用可能なアプリケーションを制限し、迅速な処理が要求される作業を行うユーザのみに広い通信帯域を割り当てるようにすることも可能である。しかし、この場合でも、狭い通信帯域を割り当てられたユーザは、他にログオンユーザが存在するか否かに関わらず、与えられた狭い通信帯域しか利用することができないため、作業効率の向上に限界がある。

そこで本発明は、ウェブアプリケーションの実行を通じてリモートオフィスの環境を提供するシステムにおいて、空いている通信帯域を効率よく使用しつつ、迅速な処理が要求される作業のためのアプリケーションにはより広い通信帯域を割り当てるような動的制御を可能とすることにより、リモートオフィスにおける作業効率を向上させることを目的とする。

上記の目的を達成するため、本発明は、次のようなコンピュータとして実現される。このサーバは、ネットワークを介して端末装置からのアクセスを受け付け、ウェブアプリケーションを実行する。そして、ウェブアプリケーションに対して設定されたデータ送信に対する優先度を管理するための優先度管理テーブルと、ウェブアプリケーションごとに使用しているユーザの数を管理するためのユーザ管理テーブルと、優先度の異なる複数のウェブアプリケーションが同時に使用されている場合に、特定の優先度が設定された少なくとも１つのウェブアプリケーションの使用に伴うデータ送信に対して、優先度管理テーブルに登録されている優先度およびユーザ管理テーブルに登録されている各ウェブアプリケーションのユーザ数に基づいて特定される通信帯域を動的に割り当てるアプリケーション実行部とを備えることを特徴とする。

より詳細には、アプリケーション実行部は、バースト単位でデータ送信を行うたびに一定時間のスリープを挟むことにより、データ送信に対する通信帯域の割り当てを制御する。また、アプリケーション実行部は、各優先度のウェブアプリケーションの個々のセッションにおけるデータ送信に対して、各ウェブアプリケーションの優先度に応じて設定された特定の割合となるように通信帯域の割り当てを行う。

一方、このアプリケーション実行部は、上記のように通信帯域の割り当てを行う代わりに、各ウェブアプリケーションの優先度に応じて設定された特定の割合となるように、各ウェブアプリケーションに対する通信帯域の割り当てを行い、かつ各ウェブアプリケーションのユーザ数で対応するウェブアプリケーションに割り当てられた通信帯域を分割することにより、ウェブアプリケーションにおける個々のセッションに割り当てられる通信帯域を求めることもできる。また、このアプリケーション実行部は、特定の優先度のウェブアプリケーションを使用する複数のセッションが実行されている場合に、ウェブアプリケーションの使用に伴うデータ送信に対して割り当てられた通信帯域により、各セッションにおけるデータ送信を行うことも可能である。

さらにこのコンピュータは、ユーザが使用する回線単位でユーザの情報を管理するためのユーザ管理テーブルを備える構成とすることができる。この場合、アプリケーション実行部は、ユーザ管理テーブルに登録されているユーザの情報に基づいて、同時に使用されている複数のウェブアプリケーションが共通の回線を利用して使用されている場合に、複数のウェブアプリケーションに関して、優先度に基づく通信帯域の割り当てを行う。

また他の観点からは、上記の目的を達成する本発明は、次のようなコンピュータとしても実現される。このサーバは、ネットワークを介して端末装置からのアクセスを受け付け、ウェブアプリケーションを実行する。そして、ウェブアプリケーションごとに使用しているユーザの数を管理するユーザ管理テーブルと、このユーザ数に基づいて、複数のウェブアプリケーションがそれぞれ１人以上のユーザによって使用されていると判断される場合に、複数のウェブアプリケーションによるデータ送信を行う際に、少なくとも１つのウェブアプリケーションに関して、バースト単位で送信を行うたびに一定時間のスリープを挟むことにより、各ウェブアプリケーションによるデータ送信に特定の通信帯域が割り当てられるように制御するアプリケーション実行部とを備える。

さらに本発明は、コンピュータによるウェブアプリケーションの実行方法としても実現される。この方法は、複数のウェブアプリケーションに関して各ウェブアプリケーションを使用するユーザ数を調べるステップと、複数のウェブアプリケーションがそれぞれ１人以上のユーザによって使用されていると判断される場合に、この複数のウェブアプリケーションによるデータ送信を行う際に、少なくとも１つのウェブアプリケーションに関して、バースト単位で送信を行うたびに一定時間のスリープを挟むことにより、各ウェブアプリケーションによるデータ送信に特定の通信帯域が割り当てられるように制御するステップとを含むことを特徴とする。ここで、より詳細には、制御ステップでは、予め特定された割合にしたがって、各ウェブアプリケーションの個々のセッションにおけるデータ送信に対して通信帯域の割り当てが行われる。あるいは、この制御ステップでは、各ウェブアプリケーションに対する通信帯域の割り当てが行われ、かつウェブアプリケーションを使用するユーザ数で対応するウェブアプリケーションに割り当てられた通信帯域が分割されることにより、ウェブアプリケーションにおける個々のセッションに割り当てられる通信帯域が求められる。

さらに、この方法は、ウェブアプリケーションのセッション開始時に、各ウェブアプリケーションのユーザ数が管理されるユーザ管理テーブルにおけるウェブアプリケーションのユーザ数の値を１増加させるステップと、ウェブアプリケーションのセッション終了時に、ユーザ管理テーブルにおけるウェブアプリケーションのユーザ数の値を１減少させるステップとをさらに含む構成とすることができる。この場合、ユーザ数を調べるステップでは、ユーザ管理テーブルが参照されて、所望のウェブアプリケーションを使用するユーザ数が取得される。

以上のように構成された本発明によれば、複数のウェブアプリケーションが同時に使用される場合に、ウェブアプリケーションの種類とユーザ数に応じて使用通信帯域を適宜に割り振るという動的な制御を行うことにより、迅速な処理が要求される作業のためのウェブアプリケーションには、より広い通信帯域を割り当てることができ、ウェブアプリケーションを用いた作業の効率を向上させることができる。
また、本発明によれば、使用中のウェブアプリケーションによって回線の持つ帯域を適宜に分配することにより、空いている通信帯域を効率よく使用する動的な通信制御（帯域制御）が可能となる。

以下、添付図面を参照して、本発明を実施するための最良の形態（以下、実施形態）について詳細に説明する。
図１は、本実施形態によるリモートオフィスシステムの概念を説明する図である。
図１に示すように、本実施形態のシステムは、センター１０とセンター１０への接続拠点であるリモートオフィス２０とからなり、センター１０にはサーバ１００が備えられ、リモートオフィス２０には端末装置２００が備えられている。サーバ１００と端末装置２００とは、インターネット等のコンピュータネットワーク３００で接続されている。なお、図１にはリモートオフィス２０が１つのみ記載されているが、１つのセンター１０に対して複数のリモートオフィス２０を設けることができる。また、複数のセンター１０を設けることも可能である。各リモートオフィス２０には、複数台の端末装置２００を設置することができる。端末装置２００としては、パーソナルコンピュータ等のコンピュータ装置やＰＤＡ（Personal Digital Assistant）等のネットワーク機能を備えた情報機器を用いることができる。

図１において、センター１０のサーバ１００は、複数のウェブアプリケーションやデータベースを備える。そして、リモートオフィス２０の端末装置２００からアクセスすることにより、ウェブアプリケーションにより提供される機能を利用したり、各種データのダウンロードやアップロードを行ったりすることができる。本実施形態では、サーバ１００に備えられるウェブアプリケーションに関してデータ送信に対する優先度という概念を導入し、優先度の高いアプリケーション（以下、高優先アプリケーション）と優先度の低いアプリケーション（以下、低優先アプリケーション）とを設定する。そして、高優先アプリケーションと低優先アプリケーションとが同時に実行されている場合は、各アプリケーションの優先度に応じて使用通信帯域を制限する制御を動的に行う。これにより、高優先アプリケーションに対して所定量以上のデータ流量を確保させることができる。詳しくは後述するが、高優先アプリケーションおよび低優先アプリケーションは、それぞれ複数設定することができる。なお、以下の説明において、高優先アプリケーションと低優先アプリケーションとを特に区別する必要がない場合は、単にアプリケーションと表記する。

図２は、本実施形態のサーバ１００として好適なコンピュータ装置のハードウェア構成の例を模式的に示した図である。
図２に示すコンピュータ装置は、演算手段であるＣＰＵ（Central Processing Unit：中央処理装置）１０１と、Ｍ／Ｂ（マザーボード）チップセット１０２およびＣＰＵバスを介してＣＰＵ１０１に接続されたメインメモリ１０３と、同じくＭ／Ｂチップセット１０２およびＡＧＰ（Accelerated Graphics Port）を介してＣＰＵ１０１に接続されたビデオカード１０４と、ＰＣＩ（Peripheral Component Interconnect）バスを介してＭ／Ｂチップセット１０２に接続された磁気ディスク装置（ＨＤＤ）１０５、ネットワークインターフェイス１０６と、さらにこのＰＣＩバスからブリッジ回路１０７およびＩＳＡ（Industry Standard Architecture）バスなどの低速なバスを介してＭ／Ｂチップセット１０２に接続されたフレキシブルディスクドライブ１０８およびキーボード／マウス１０９とを備える。

なお、図２は本実施形態を実現するコンピュータ装置のハードウェア構成を例示するに過ぎず、本実施形態を適用可能であれば、他の種々の構成を取ることができる。例えば、ビデオカード１０４を設ける代わりに、ビデオメモリのみを搭載し、ＣＰＵ１０１にてイメージデータを処理する構成としても良いし、外部記憶装置として、ＡＴＡ（AT Attachment）やＳＣＳＩ（Small Computer System Interface）などのインターフェイスを介してＣＤ−Ｒ（Compact Disc Recordable）やＤＶＤ−ＲＡＭ（Digital Versatile Disc Random Access Memory）のドライブを設けても良い。

図３は、本実施形態のサーバ１００の機能構成を示す図である。
図３に示すように、サーバ１００は、アプリケーションの起動時に必要な前処理を実行する前処理部１１０と、前処理部１１０による前処理の施されたアプリケーションを起動して実行するアプリケーション実行部１２０と、アプリケーションを使用するためのセッションを管理するセッション管理部１３０と、アプリケーションを格納したアプリケーション格納部１５０とを備える。また、本実施形態によるデータ通信の帯域制御を行うために必要な情報を格納するユーザ識別テーブル１４１、リモートオフィス管理テーブル１４２、ユーザ管理テーブル１４３、優先度管理テーブル１４４を備える。これらのテーブルは、例えばサーバ１００を図２に示したコンピュータ装置で実現した場合、メインメモリ１０３や磁気ディスク装置１０５等の記憶装置に格納して保持される。

図４は、ユーザ識別テーブル１４１の構成例を示す図である。
図４に示すように、ユーザ識別テーブル１４１には、リモートオフィス２０における端末装置２００のユーザ（リモートオフィス２０の構成員）の識別情報（ユーザＩＤ）と、そのユーザが所属するリモートオフィス２０の識別情報（リモートオフィス番号）とが対応付けられて登録される。リモートオフィス２０の各端末装置２００は、共通の回線を介してセンター１０のサーバ１００に接続される。したがって、ユーザ識別テーブル１４１においてユーザが所属するリモートオフィス２０の情報を管理することは、回線単位でユーザの情報を管理することを意味する。

図５は、リモートオフィス管理テーブル１４２の構成例を示す図である。
図５に示すように、リモートオフィス管理テーブル１４２には、リモートオフィス番号と、そのリモートオフィス２０とセンター１０との間の回線の属性情報（回線の種別、回線速度、通信帯域等）とが対応付けられて登録される。ユーザ識別テーブル１４１が回線単位でユーザの情報を管理するためのものであるとの観点に立てば、リモートオフィス管理テーブル１４２は、端末装置２００がサーバ１００に接続する回線ごとに当該回線の属性情報を管理することを意味する。本実施形態による通信帯域の制御は、同一回線を利用して複数のアプリケーションが使用される場合に有効である。一方、異なる回線においては、回線ごとに通信帯域の制御方法を変えても問題はない。したがって、回線ごとにその属性を管理し、この情報を参照することで、各回線に適した通信制御を適用することが可能となる。

図６は、ユーザ管理テーブル１４３の構成例を示す図である。
図６に示すように、ユーザ管理テーブル１４３には、リモートオフィス番号と、そのリモートオフィス番号で特定されるリモートオフィス２０において使用されるアプリケーションの識別情報（アプリケーションＩＤ）と、そのアプリケーションを使用したセッションを現在行っているユーザの数（使用ユーザ数）とが対応付けられて登録される。

図７は、優先度管理テーブル１４４の構成例を示す図である。
図７に示すように、優先度管理テーブル１４４には、アプリケーションＩＤと、そのアプリケーションの優先度（高優先アプリケーションか低優先アプリケーションかの別を示す情報）とが対応付けられて登録される。

これらのテーブルを参照すると、アクセス要求に対する認証時に得られるユーザＩＤをキーとしてユーザ識別テーブル１４１を検索することにより、当該ユーザが所属するリモートオフィス２０が分かる。このリモートオフィス２０の番号をキーとしてリモートオフィス管理テーブル１４２を検索することにより、当該リモートオフィス２０が使用している回線の属性情報が得られる。また、このリモートオフィス番号とアプリケーションＩＤをキーとしてユーザ管理テーブル１４３を検索すれば、当該アプリケーションを使用しているリモートオフィス２０ごとのユーザ数がわかる。そして、このアプリケーションＩＤをキーとして優先度管理テーブル１４４を検索することにより、このアプリケーションが高優先アプリケーションか低優先アプリケーションかの別を知ることができる。

前処理部１１０は、例えば図２のプログラム制御されたＣＰＵ１０１にて実現される。この前処理部１１０は、任意のリモートオフィス２０の端末装置２００からのアクセス要求を受け付けて、本実施形態による通信制御を実現するための前処理を実行する。この前処理により、アクセス要求に応じて起動されるアプリケーションに、本実施形態による通信制御を支援するためのプログラム（以下、支援プログラム）が追加される。アプリケーションに追加される支援プログラムの詳細については後述する。

図８は、前処理部１１０による前処理の動作を説明するフローチャートである。なおここでは、アプリケーションがＪａｖａサーブレットとして作成されており、支援プログラムはオブジェクトとしてアプリケーションに追加されるものとする。
サーバ１００は、端末装置２００からアクセス要求を受信すると、まず基本認証やフォーム・ベースの認証等の認証処理を実行する。この認証の結果、アクセス要求が受け付けられると、前処理部１１０による前処理が開始される。図８を参照すると、前処理部１１０は、まずサーバ１００の認証によって得られたユーザＩＤを取得する（ステップ８０１）。次に前処理部１１０は、取得したユーザＩＤに関するセッション情報をセッション管理部１３０に問い合わせて取得し（ステップ８０２）、受け付けたアクセス要求が新規のセッションを開始するアクセス要求か、既に実行されているセッションに対するアクセス要求かを調べる（ステップ８０３）。

受け付けたアクセス要求が新規のセッションを開始するアクセス要求であるならば、前処理部１１０は、支援プログラムのオブジェクトを生成して、このアクセス要求に応じて起動されるアプリケーションのHttpSessionに生成されたオブジェクトをセットする（ステップ８０４）。そして、前処理部１１０は、アプリケーション実行部１２０に処理を移行する（ステップ８０５）。一方、受け付けたアクセス要求が既に実行されているセッションに対するアクセス要求である場合は、前処理部１１０は何らの処理も行わず、アプリケーション実行部１２０に処理を移行する（ステップ８０５）。

アプリケーション実行部１２０は、例えば図２のプログラム制御されたＣＰＵ１０１にて実現される。このアプリケーション実行部１２０は、前処理部１１０により前処理の施されたアプリケーションを起動し、セッションを開始してその処理を実行する。アプリケーションを実行する際、前処理部１１０により追加されたプログラムも実行される。実行中のセッションの情報はセッション管理部１３０において管理される。また、アプリケーション実行部１２０は、アプリケーションにより実行されるデータ送信（ダウンロード）時に、本実施形態による通信制御を実行する。具体的な制御については後述するが、本実施形態では、バーストモデルによるデータ送信において、バースト単位で送信を行うたびに、一定時間のスリープを挟むことにより、各アプリケーションにおけるデータ流量を調整する。なお、アプリケーション実行部１２０によるデータ送信は、例えば図２のネットワークインターフェイス１０６を介して行われる。

図９は、アプリケーション実行部１２０によるデータ送信時の動作を説明するフローチャートである。なお図８の場合と同様に、アプリケーションがＪａｖａサーブレットとして作成されているものとする。
アプリケーション実行部１２０は、まずInputStreamを取得し（ステップ９０１）、次いでOutputStreamを取得する（ステップ９０２）。そして、アプリケーション実行部１２０は、アプリケーションの優先度に応じて通信帯域を制御するプログラム（以下、通信制御プログラム）のオブジェクトを生成し、ステップ９０１で取得されたInputStreamのデータがなくなるまで、このオブジェクトにより通信制御を行う（ステップ９０３）。

セッション管理部１３０は、例えば図２のプログラム制御されたＣＰＵ１０１にて実現される。このセッション管理部１３０の機能は、既存のウェブアプリケーションサーバにおけるセッション管理機能と同様であり、前処理部１１０によりセッションオブジェクトが生成された際に、そのセッションに関する情報（セッションを行うユーザのユーザＩＤ、セッションにおいて使用されるアプリケーションのアプリケーションＩＤ等）を取得し管理する。この情報は、例えば図２のメインメモリ１０３等の記憶手段に格納されて、対応するセッションが終了するまで保持される。

アプリケーション格納部１５０は、例えば図２の磁気ディスク装置１０５にて実現され、端末装置２００からのアクセスにより使用される各種のアプリケーションが格納されている。上述した優先度管理テーブル１４４には、このアプリケーション格納部１５０に格納されたアプリケーションの優先度が登録されている。

次に、前処理部１１０によりアプリケーションに付加される支援プログラムについて説明する。
図１０は、支援プログラムの実現例であるＪａｖａクラスを示す図である。
図１０に示す支援プログラムのコンストラクタでは、図８のステップ８０１で得られたユーザＩＤをキーとしてユーザ識別テーブル１４１が参照されて、このユーザの属するリモートオフィス２０のリモートオフィス番号が取得される。そして、このリモートオフィス番号と起動するアプリケーションのアプリケーションＩＤとが格納される。

また、図１０の支援プログラムでは、valueBoundメソッドとvalueUnboundメソッドとが実行される。valueBoundメソッドは、セッション生成時に、アプリケーションのHttpSession.setAttributeの実行によって呼び出される。そして、コンストラクタで格納されたリモートオフィス番号とアプリケーションＩＤに対応するユーザ管理テーブル１４３の項目における使用ユーザ数の値を１増加させる。また、valueUnboundメソッドは、セッション消滅時に呼び出される。そして、コンストラクタで格納されたリモートオフィス番号とアプリケーションＩＤに対応するユーザ管理テーブル１４３の項目における使用ユーザ数の値を１減少させる。なお、セッションの消滅には、端末装置２００からの要求による意図的な終了と、端末装置２００からのアクセスが一定期間以上なかった場合に時間切れによって消滅する場合とがあるが、いずれの場合もvalueUnboundメソッドが実行される。

次に、アプリケーション実行部１２０により実行される通信制御プログラムについて説明する。
図１１は、通信制御プログラムの実施例であるＪａｖａクラスを示す図である。
図１１に示す通信制御プログラムのコンストラクタでは、InputStreamの値、OutputStreamの値、ユーザＩＤ、アプリケーションＩＤ、１回のバーストで送信するデータサイズ（len）が取得され格納される。ここで、lenの値はアプリケーションの初期化パラメータから取得される。

また、図１１の通信制御プログラムでは、writeメソッドが実行され、その中でさらにsleepTimeメソッドが実行される。writeメソッドでは、バーストごとにlenだけのデータがInputStreamから受信され、OutputStreamに送信される。そして、バースト間ではsleepTimeメソッドが呼び出され、このsleepTimeメソッドにより決定される時間だけスリープされる。

ここで、sleepTimeメソッドに関してさらに詳細に説明する。
上述したように、図１１に示した通信制御プログラム（FlowControlStreamクラス）のwriteメソッドはOutputStreamに対してデータを１度にlen（単位はKバイト）ずつバースト的に送信する。そして、バースト間ではsleepTimeメソッドによって決定される時間（単位は秒）だけスリープする。したがって、実効的なデータ送信帯域は、
len＊８／sleepTime（Ｋｂｐｓ）
で表されることとなる。これに基づき、sleepTimeメソッドのアルゴリズムを次のようにすることができる。

図１２は、sleepTimeメソッドのアルゴリズムを示すフローチャートである。
図１２を参照すると、sleepTimeメソッドでは、まず図１１に示した通信制御プログラムのコンストラクタで格納されたユーザＩＤをキーとしてユーザ識別テーブル１４１が参照されて、このユーザが属するリモートオフィス２０のリモートオフィス番号が取得される。そして、取得されたリモートオフィス番号をキーとしてユーザ管理テーブル１４３が参照されて、同じリモートオフィス２０においてどのアプリケーションがそれぞれ何人のユーザに使用されているかが調べられる。また、この工程で得られた現在使用中のアプリケーションのアプリケーションＩＤをキーとして優先度管理テーブル１４４が参照されて、現在使用中の各アプリケーションに関して高優先アプリケーションか低優先アプリケーションかの別が調べられる。そしてさらに、これらの情報に基づいて、現在使用中のアプリケーションに関して、高優先アプリケーションの使用ユーザ数Ｎ-highと低優先アプリケーションの使用ユーザ数Ｎ-lowとが求められる（ステップ１２０１）。

次に、このsleepTimeメソッドが実行されているアプリケーション自身が高優先アプリケーションか否かが判断される（ステップ１２０２）。そして、自身が高優先アプリケーションであるならば、次の数１式によって、この高優先アプリケーションにおける実効的なデータ送信帯域Ｂ-effが算出される（ステップ１２０３）。

なお、Ｂ-totalは回線自体の通信帯域である。また、Ｂ-highは高優先アプリケーションのユーザに対して付与される帯域使用度、Ｂ-lowは低優先アプリケーションのユーザに対して付与される帯域使用度である。帯域使用度とは、全体の帯域を各アプリケーションの個々のユーザ（セッション）に分割して割当てるための割合である。

一方、このsleepTimeメソッドが実行されているアプリケーションが低優先アプリケーションであるならば、次の数２式によって、この低優先アプリケーションにおける実効的なデータ送信帯域Ｂ-effが算出される（ステップ１２０４）。

以上のようにして算出されたデータ送信帯域Ｂ-effを用いて、次の数３式により、データ送信時にバースト間でスリープさせる時間sleepTimeが算出される（ステップ１２０５）。

ここで、高優先アプリケーションおよび低優先アプリケーションに対してどのように帯域が割り当てられるかを、具体例を挙げて説明する。
例えば、回線の通信帯域Ｂ-totalを１０００Ｋｂｐｓとし、高優先アプリケーションのユーザの帯域使用度Ｂ-highと低優先アプリケーションのユーザの帯域使用度Ｂ-lowの割合を４対１とする。そして、高優先アプリケーション、低優先アプリケーションとも、２人のユーザにより実行されている（すなわち２つずつのセッションが設定されている）場合を考える。なお、具体的なセッションの態様としては、高優先アプリケーションおよび低優先アプリケーションが１つずつ存在して、それぞれに２つのセッションが設定されているとしても良い。また、高優先アプリケーションおよび低優先アプリケーションはそれぞれ複数存在して、各２つの高優先アプリケーションおよび低優先アプリケーションにそれぞれ１つずつのセッションが設定されているとしても良い。

この例では、高優先アプリケーションのユーザに割り当てられる帯域は、４００Ｋｂｐｓ（＝１０００Ｋｂｐｓ＊４／（２＊４＋２＊１））であり、低優先アプリケーションのユーザに割り当てられる帯域は、１００Ｋｂｐｓ（＝１０００Ｋｂｐｓ＊１／（２＊４＋２＊１））である。

以上のようにして、高優先アプリケーションを使用する作業と低優先アプリケーションを使用する作業とが同時に行われ、これらの作業によって同時に回線が使用される場合に、予め設定された割合にしたがって、高優先アプリケーションの作業に対して優先的に多くの通信帯域が割り当てられることとなる。一方、高優先アプリケーションの作業または低優先アプリケーションの作業のどちらかのみが行われる場合は、他方のアプリケーションを使用するユーザ数（Ｎ-lowまたはＮ-high）が０になるので、使用されているアプリケーションのユーザ数で全体の帯域Ｂ-totalを割った値が各作業に対して均等に割り当てられることとなる。このように、本実施形態によれば、優先度の異なるアプリケーションが同時に使用されているか否かに応じて、各アプリケーションに割り当てられる通信帯域を動的に制御することが可能となる。そして、優先度の異なるアプリケーションが同時に使用されている場合には、高優先アプリケーションに対して優先的に多くの通信帯域が割り当てられるので、迅速な処理の実行が要求される高優先アプリケーションを用いた作業が遅れて作業効率が低下することを防ぐことができる。

上記の具体例では、高優先アプリケーションの個々のユーザ（セッション）に割り当てられる帯域と低優先アプリケーションの個々のユーザ（セッション）に割り当てられる帯域との割合を予め設定しておき、設定された割合となるように各アプリケーションのユーザ（セッション）に通信帯域を割り当てた。すなわち、高優先アプリケーションを使用するユーザおよび低優先アプリケーションを使用するユーザがそれぞれ何人いても、高優先アプリケーションの個々のユーザに割り当てられる帯域と低優先アプリケーションの個々のユーザに割り当てられる帯域との割合は同一（予め設定された値、上記の例では４対１）である。

これに対し、高優先アプリケーションと低優先アプリケーションとが同時に使用される場合に各アプリケーションに割り当てられる通信帯域の割合を設定することもできる。高優先アプリケーションや低優先アプリケーションのユーザが複数いる場合は、各アプリケーションに割り当てられた通信帯域をユーザ数で割って各ユーザに割り当てる。例えば、回線の通信帯域を１０００Ｋｂｐｓ、各アプリケーションに割り当てられる通信帯域の割合を４対１とし、高優先アプリケーションのユーザ数を１、低優先アプリケーションのユーザ数を２とする。この場合、高優先アプリケーションには８００Ｋｂｐｓ（＝１０００Ｋｂｐｓ＊４／（４＋１））が割り当てられ、低優先アプリケーションには２００Ｋｂｐｓ（＝１０００Ｋｂｐｓ＊１／（４＋１））が割り当てられる。そして、高優先アプリケーションのユーザ数は１なので、結果的にこのユーザには８００Ｋｂｐｓが割り当てられる。一方、低優先アプリケーションのユーザ数は２なので、結果的にこのユーザには１００Ｋｂｐｓ（＝２００Ｋｂｐｓ／２）が割り当てられる。このように、アプリケーションに対して優先度に応じた帯域の割合を決めておく場合、各アプリケーションのユーザ数によって、高優先アプリケーションの個々のユーザに割り当てられる帯域と低優先アプリケーションの個々のユーザに割り当てられる帯域との割合が変化することとなる。

以上説明した実施形態では、高優先アプリケーションおよび低優先アプリケーションの各々に関して２つのセッションがある場合を説明した。しかしながら、システムの態様や使用環境によっては、例えば、同一のリモートオフィスにおいて、一時点では、高優先アプリケーションと低優先アプリケーションが、ともにたかだか一つずつしか実行されないと仮定できる場合がある。この場合は、高優先アプリケーションおよび低優先アプリケーションの帯域使用度の割合を定めるのではなく、高優先アプリケーションが使用されている場合に低優先アプリケーションの使用帯域のみを制限するといった簡易な制御によって、高優先アプリケーションに対して優先的に多くの通信帯域を割り当てることが可能である。

かかる制御では、高優先アプリケーションと同時に使用される際の低優先アプリケーションの使用可能な帯域を定め、そのようなデータ送信帯域を実現するスリープ時間sleepTimeを予め算出しておく。そして、sleepTimeメソッドでは、ユーザ管理テーブル１４３を参照して高優先アプリケーションのユーザ数が１であるか否かを判断し、高優先アプリケーションのユーザ数が１である場合に、予め算出してあるスリープ時間sleepTimeをwriteメソッドに返すようにする。

なお、回線の通信帯域に十分な余裕がある場合は、高優先アプリケーションによる作業と低優先アプリケーションによる作業とが同時に複数実行されるシステムにおいても、このような簡易な制御を行うことは可能である。この場合、例えば高優先アプリケーションが同時に使用されている場合の低優先アプリケーションの使用帯域を１００Ｋｂｐｓとすると、低優先アプリケーションを用いた作業が２つ行われている場合は２００Ｋｂｐｓ（＝１００Ｋｂｐｓ＊２）が低優先アプリケーションに使用されることとなり、それだけ高優先アプリケーションの使用帯域が圧迫されることとなる。しかし、全体の通信帯域が十分に大きければ、低優先アプリケーションの使用帯域の合計がそのユーザ数に応じて増加してもその差異は微少なものとなる。したがって、高優先アプリケーションの作業において行われる通信に対する影響も小さく、作業効率の大きな低下を招くこともない。

また、上記の実施形態では、アプリケーションを高優先アプリケーションと低優先アプリケーションの２種類に分けたが、３種類以上の優先度を設定し、動的な通信制御を行うことも可能である。この場合も、それぞれの優先度のアプリケーションに対して帯域使用度を設定し、sleepTimeメソッドにおいて、上述した数１、２式を拡張した計算により各優先度のアプリケーションにおける実効的なデータ送信帯域を計算してスリープ時間を求めれば良い。

さらに、本実施形態の高優先アプリケーションおよび低優先アプリケーションの他に、そのいずれにも属さないウェブアプリケーションを混在させることもできる。例えば、一旦起動した後はほとんどローカルな処理のみが実行されるために回線をあまり使用しないウェブアプリケーションは、たとえセッションが張られて作業が行われていても、他のアプリケーションによる通信に対してほとんど影響を与えない。したがって、本実施形態による通信制御の対象となる高優先アプリケーションおよび低優先アプリケーションのいずれにも属さないウェブアプリケーションとして、これらの優先度が設定されたアプリケーションと併存させても問題はない。この場合、高優先アプリケーションまたは低優先アプリケーションのいずれかと優先度を持たないウェブアプリケーションとが同時に実行されていたとしても、優先度が設定されたアプリケーションに対する本実施形態による動的な通信制御は行われないこととなる。

この他、ユーザ識別テーブル１４１に個々のユーザの属性を登録しておき、本実施形態による通信制御に組み合わせることもできる。このユーザ属性としては、例えば「職位（社長、課長など）」や「職種（営業職、サービス職など）」を登録することができる。これらのユーザ属性を加味し、ある属性のユーザがあるアプリケーションを使用する場合には、これを高優先アプリケーションとして扱い、他の属性のユーザが同じアプリケーションを使用する場合には、これを低優先アプリケーションとして扱うといった制御を行うことが考えられる。さらにまた、これらの数種類の通信制御をリモートオフィス２０ごとに使い分けることも可能である。

本実施形態によるリモートオフィスシステムの概念を説明する図である。 本実施形態のサーバとして好適なコンピュータ装置のハードウェア構成の例を模式的に示した図である。 本実施形態のサーバの機能構成を示す図である。 本実施形態のユーザ識別テーブルの構成例を示す図である。 本実施形態のリモートオフィス管理テーブルの構成例を示す図である。 本実施形態のユーザ管理テーブルの構成例を示す図である。 本実施形態の優先度管理テーブルの構成例を示す図である。 本実施形態の前処理部による前処理の動作を説明するフローチャートである。 本実施形態のアプリケーション実行部によるデータ送信時の動作を説明するフローチャートである。 本実施形態の支援プログラムの実現例であるＪａｖａクラスを示す図である。 本実施形態の通信制御プログラムの実現例であるＪａｖａクラスを示す図である。 図１１の通信制御プログラムにおけるsleepTimeメソッドのアルゴリズムを示すフローチャートである。

符号の説明

１０…センター、２０…リモートオフィス、１００…サーバ、１０１…ＣＰＵ（Central Processing Unit：中央処理装置）、１０３…メインメモリ、１０５…磁気ディスク装置（ＨＤＤ）、１１０…前処理部、１２０…アプリケーション実行部、１３０…セッション管理部、１４１…ユーザ識別テーブル、１４２…リモートオフィス管理テーブル、１４３…ユーザ管理テーブル、１４４…優先度管理テーブル、１５０…アプリケーション格納部

Claims (10)

1. ネットワークを介して端末装置からのアクセスを受け付け、ウェブアプリケーションを実行するコンピュータにおいて、
   ウェブアプリケーションに対して設定されたデータ送信に対する優先度を管理するための優先度管理テーブルと、
   ウェブアプリケーションごとに使用しているユーザの数を管理するためのユーザ管理テーブルと、
   優先度の異なる複数のウェブアプリケーションが同時に使用されている場合に、特定の優先度が設定された少なくとも１つのウェブアプリケーションの使用に伴うデータ送信に対して、前記優先度管理テーブルに登録されている優先度および前記ユーザ管理テーブルに登録されている各ウェブアプリケーションのユーザ数に基づいて特定される通信帯域を動的に割り当てるアプリケーション実行部と
   を備えることを特徴とするコンピュータ。
2. 前記アプリケーション実行部は、バースト単位でデータ送信を行うたびに一定時間のスリープを挟むことにより、前記データ送信に対する通信帯域の割り当てを制御することを特徴とする請求項１に記載のコンピュータ。
3. 前記アプリケーション実行部は、各優先度のウェブアプリケーションの個々のセッションにおけるデータ送信に対して、各ウェブアプリケーションの優先度に応じて設定された特定の割合となるように通信帯域の割り当てを行うことを特徴とする請求項１に記載のコンピュータ。
4. 前記アプリケーション実行部は、前記特定の優先度のウェブアプリケーションを使用する複数のセッションが実行されている場合に、当該ウェブアプリケーションの使用に伴うデータ送信に対して割り当てられた通信帯域により、各セッションにおけるデータ送信を行うことを特徴とする請求項１に記載のコンピュータ。
5. ユーザが使用する回線単位でユーザの情報を管理するためのユーザ管理テーブルをさらに備え、
   前記アプリケーション実行部は、前記ユーザ管理テーブルに登録されているユーザの情報に基づいて、同時に使用されている複数のウェブアプリケーションが共通の回線を利用して使用されていると判断される場合に、当該複数のウェブアプリケーションの使用に伴うデータ送信に対して、前記優先度および前記ユーザ数に基づく通信帯域の割り当てを行うことを特徴とする請求項１に記載のコンピュータ。
6. コンピュータによりウェブアプリケーションを実行する方法であって、
   前記コンピュータが、複数のウェブアプリケーションに関して各ウェブアプリケーションに設定されたデータ送信に対する優先度を調べるステップと、
   前記コンピュータが、複数のウェブアプリケーションに関して各ウェブアプリケーションを使用するユーザ数を調べるステップと、
   前記コンピュータが、優先度の異なる複数のウェブアプリケーションが同時に使用されている場合に、特定の優先度が設定された少なくとも１つのウェブアプリケーションの使用に伴うデータ送信に対して、各ウェブアプリケーションにおける前記優先度および前記ユーザ数に基づいて特定される通信帯域を動的に割り当てるステップと
   を含むことを特徴とする方法。
7. 前記通信帯域を動的に割り当てるステップでは、バースト単位でデータ送信を行うたびに一定時間のスリープを挟むことにより、前記データ送信に対する通信帯域の割り当てが制御されることを特徴とする、請求項６に記載の方法。
8. 前記通信帯域を動的に割り当てるステップでは、各優先度のウェブアプリケーションの個々のセッションにおけるデータ送信に対して、各ウェブアプリケーションの優先度に応じて設定された特定の割合となるように通信帯域の割り当てが行われることを特徴とする、請求項６に記載の方法。
9. 前記通信帯域を動的に割り当てるステップでは、ユーザが使用する回線単位で管理されたユーザの情報に基づいて、同時に使用されている複数のウェブアプリケーションが共通の回線を利用して使用されていると判断される場合に、当該複数のウェブアプリケーションの使用に伴うデータ送信に対して、前記優先度および前記ユーザ数に基づく通信帯域の割り当てを行うことを特徴とする、請求項６に記載の方法。
10. 前記コンピュータが、前記ウェブアプリケーションのセッション開始時に、各ウェブアプリケーションのユーザ数が管理されるユーザ管理テーブルにおける当該ウェブアプリケーションのユーザ数の値を１増加させるステップと、
    前記コンピュータが、前記ウェブアプリケーションのセッション終了時に、前記ユーザ管理テーブルにおける当該ウェブアプリケーションのユーザ数の値を１減少させるステップとをさらに含み、
    前記ユーザ数を調べるステップでは、前記ユーザ管理テーブルが参照されて、所望のウェブアプリケーションを使用するユーザ数が取得されることを特徴とする請求項６に記載の方法。

Images