JP2010191482A - クライアントサーバシステム、クライアント装置および業務処理振分プログラム - Google Patents

Abstract

【課題】業務処理の実行をクライアントまたはサーバに振り分けて、クライアントに掛かる負荷を分散することを課題とする。
【解決手段】クライアント１０は、業務処理を実行する場合に、業務処理をクライアント１０で実行するかサーバ２０で実行するかを判定する。この結果、クライアント１０で実行すると判定された場合には、業務処理をクライアント１０が実行し、サーバで実行すると判定された場合には、業務処理をサーバ２０において実行するように通信する。
【選択図】 図１

Description

本発明は、発生するイベントに対応した業務処理を行うクライアントサーバシステム、クライアント装置および業務処理振分プログラムに関する。

従来より、画面に対する利用者の操作をイベントとして捉え、発生するイベントに対応した業務処理を行う画面処理プログラムが開発されている。このような画面制御プログラムが適用されたクライアント装置と、業務処理を保持するサーバとを有するクライアントサーバシステムが知られている。

画面処理プログラムが適用されたクライアントでは、パネルと項目と操作の組み合わせで指定するイベントに業務処理を対応させて定義した定義情報を有する。そして、クライアントは、定義情報を用いて、クライアントで発生したイベントに対応した業務処理を実行する（例えば、特許文献１参照）。

具体的には、クライアントは、イベントに業務処理を対応させて定義したアクションマッピング定義情報を用いて、イベントに対応する業務処理を呼び出し、業務処理を実行する。ここで、クライアントは、対応するイベントが発生した際に、業務処理を行う業務処理プログラムをサーバからダウンロードして業務処理を行っている。

特開２００５−２７５９７０号公報

しかしながら、上記した画面処理プログラムが適用されたクライアントでは、クライアントで発生したイベントに対応する業務処理について、クライアント装置自身が実行するのみで、業務処理の実行をサーバ側に振り分けることができず、クライアント側の負荷が高くなるという課題があった。

そこで、この発明は、上述した従来技術の課題を解決するためになされたものであり、業務処理の実行をクライアントまたはサーバに振り分けて、クライアントに掛かる負荷を分散することを目的とする。

本願の開示するシステムは、一つの態様において、業務処理を実行する場合に、業務処理をクライアントで実行するかサーバで実行するかを判定し、クライアントで実行すると判定された場合には、業務処理をクライアントが実行し、サーバで実行すると判定された場合には、業務処理をサーバにおいて実行するように通信する。

本願の開示するクライアントサーバシステムの一つの態様によれば、業務処理の実行をクライアントまたはサーバに振り分けて、クライアントに掛かる負荷を分散するという効果を奏する。

図１は、実施例１に係るクライアントサーバシステムによる画面処理の概念を説明するための説明図である。 図２は、実施例１に係るクライアントの構成を示すブロック図である。 図３は、業務ロジックマッピング定義情報のＸＭＬ定義体項目の一例を示す図である。 図４は、クライアント未起動時およびクライアント起動時の処理を説明するための図である。 図５は、クライアント処理実行時について説明するための図である。 図６は、非同期通信を行った場合の問題点を説明するための図である。 図７は、イベントキューを使用したイベント制御処理を説明するための図である。 図８は、イベントキューを使用したイベント制御処理の具体例について説明するための図である。 図９は、実施例１に係るサーバの構成を示すブロック図である。 図１０は、実施例１に係るクライアントの処理動作を示すフローチャートである。 図１１は、実施例２に係るクライアントサーバシステムによる画面処理の概念を説明するための説明図である。 図１２は、実施例２に係るクライアントの処理動作を示すフローチャートである。 図１３は、実施例３に係るクライアントサーバシステムによる画面処理の概念を説明するための説明図である。 図１４は、実施例３に係るクライアントの処理動作を示すフローチャートである。 図１５は、実施例４に係るクライアントサーバシステムによる画面処理の概念を説明するための説明図である。 図１６は、実施例４に係るクライアントの処理動作を示すフローチャートである。 図１７は、業務処理振分プログラムを実行するコンピュータを示す図である。

以下に添付図面を参照して、この発明に係るクライアントサーバシステム、クライアント装置および業務処理振分プログラムの実施例を詳細に説明する。

以下の実施例では、実施例１に係るクライアントサーバシステムの概要および特徴、クライアントの構成、サーバの構成および処理の流れを順に説明し、最後に実施例１による効果を説明する。なお、本実施例では、Ｊａｖａ(登録商標)アプレットとして動作する画面処理プログラムが適用されたクライアント装置と、クライアント装置に接続されたサーバとを含むクライアントサーバシステムの場合を中心に説明する。

［実施例１に係るクライアントサーバシステムの概要］
まず最初に、図１を用いて、実施例１に係るクライアントサーバシステムの概要を説明する。図１は、実施例１に係るクライアントサーバシステムの概要を説明するための図である。同図に示すように、クライアントサーバシステム１は、クライアント１０およびサーバ２０を有する。クライアント１０は、イベントと業務処理との対応付けを業務ロジックマッピング定義情報として定義する。

ここで、イベント指定は、画面上でカーソルが位置付けられているパネルおよび項目ならびに利用者の操作の組み合わせによって行う。すなわち、イベントとしてボタン押下などの操作だけでなく項目を指定することによって、項目と操作の任意の組み合わせについてイベントを定義することができる。

例えば、アクション「１」に対応するイベントは、カーソルがパネル「Ｐ００１」の項目「ＦＬＤ１」に位置する場合に「ＥＮＴＥＲキー」が操作されたときに発生する。このように、パネルとパネル内の項目と操作との組み合わせでイベントを指定することによって、多様な画面操作に対してイベントを定義することができる。

また、業務ロジックマッピング定義情報では、パネルごとにイベントと業務処理とを対応付けるのではなく、イベントとアクションを対応付けて記憶している。さらに、業務ロジックマッピング定義情報では、アクションを一意に識別する「アクション」と、業務処理を一意に識別するＩＤを示す「処理」と、業務処理を実行する処理主体を示す「種別」と、サーバが業務処理を実行するのに必要なデータである「送信データ」とを対応付けて記憶する。

なお、イベントは、パネルとパネル内の項目と操作との組み合わせによって指定するが、パネル間や項目間で共通するイベントについては、パネルや項目の指定を省略することができる。

このような構成のもと、クライアント１０は、業務ロジックマッピング定義情報に従って、イベントおよび処理の登録ならびにパネルの作成などの初期化処理を行い表示パネル情報記憶部１５ｂに記憶された画面に表示するパネルについての情報である表示パネル情報を用いて、初期パネルを表示する。

続いて、クライアント１０は、利用者の画面操作によってイベントが発生すると、表示パネル情報と業務ロジックマッピング定義情報とを用いて、イベントからアクション（図１の例では、アクション３）を特定する。そして、クライアント１０は、特定したアクションに対応する業務処理（図１の例では、業務処理ｃ）を実行する業務処理として決定する。

ここで、クライアント１０は、決定された業務処理をクライアント１０で実行するかサーバ２０で実行するかを判定する。具体的には、クライアント１０は、実行することが決定された業務処理に対応する「種別」を業務ロジックマッピング定義情報から読み出し、種別が「クライアント」の場合には、業務処理を呼び出して実行する。

また、クライアント１０は、業務処理に対応する種別が「サーバ」の場合には、サーバ２０が業務処理に必要なデータを作成し、サーバ２０に送信する。具体的には、クライアント１０は、業務ロジックマッピング定義情報に従い、送信データを作成する。例えば、クライアント装置１０は、業務処理「業務処理ｃ」をサーバで実行する場合には、項目Ａ、項目Ｂに入力されたデータであるＦＬＤ１、ＦＬＤ２のデータを送信データとして作成し、サーバ２０に送信する。

そして、サーバ２０は、送信データをクライアント１０から受信した場合には、受信された送信データを用いて、業務処理を実行する。その後、クライアント１０は、サーバ２０から業務処理の実行結果を受信する。

このように、クライアントサーバシステム１では、クライアント１０またはサーバ２０のいずれが業務処理を実行するか判定し、クライアント１０もしくはサーバ２０に業務処理を振り分ける。これにより、クライアントサーバシステム１では、業務処理の負担をクライアント１０だけでなく、サーバ２０にも分担させるとともに、処理主体を意識した作り込みを不要とすることができる。

［クライアントの構成］
次に、図２を用いて、図１に示したクライアント１０の構成を説明する。図２は、実施例１に係るクライアント１０の構成を示すブロック図である。同図に示すように、このクライアント１０は、画面制御部１１、システム制御部１２、イベント制御部１３、通信制御部１４、記憶部１５を有し、ネットワーク等を介してサーバ２０と接続される。以下にこれらの各部の処理を説明する。

画面制御部１１は、パネルを表示する処理部である。また、この画面制御部１１は、パネル上でのユーザのマウス操作やキーボード操作をイベントとして受け付け、受け付けたイベントをイベント制御部１３に通知する。

システム制御部１２は、接続されたサーバ２０との間でやり取りする各種情報に関する通信を制御する。具体的には、システム制御部１２は、クライアント１０が起動する際に、起動時に必要な情報、かつクライアントで必要な情報のみを抜粋してダウンロードし、業務ロジックマッピング定義情報記憶部１５ａ、表示パネル情報記憶部１５ｂに記憶させる。

また、システム制御部１２は、後述するイベント判定部１３ｂによってクライアント１０で業務処理を実行すると判定された場合に、クライアントで動作する業務処理をサーバ２０からダウンロードし、業務ロジックマッピング定義情報記憶部１５ａ、表示パネル情報記憶部１５ｂに記憶させる。

記憶部１５は、イベント制御部１３および通信制御部１４による各種処理に必要なデータおよびプログラムを格納するが、特に、業務ロジックマッピング定義情報記憶部１５ａおよび表示パネル情報記憶部１５ｂを有する。

業務ロジックマッピング定義情報記憶部１５ａは、業務ロジックマッピング定義情報をＸＭＬ形式で記憶した記憶部である。図３は、業務ロジックマッピング定義情報のＸＭＬ定義体項目の一例を示す図である。

同図に示すように、このＸＭＬ定義体項目では、業務ロジックマッピング定義情報を定義するタグ「ｌｏｇｉｃ−Ｍａｐｐｉｎｇ」には、アクションを定義するタグ「ａｃｔｉｏｎ」が含まれる。そして、タグ「ａｃｔｉｏｎ」には、の属性としてアクション発生元のパネルを識別する「ｐａｎｅｌ−ｉｄ」と、アクション発生項目を識別する「ｉｔｅｍ−ｉｄ」と、操作を識別する「ａｃｔｉｏｎ−ｉｄ」が定義される。

また、「ａｃｔｉｏｎ」の中に、アクションコードを表わす「ｌｏｇｉｃ」が定義されている。この「ｌｏｇｉｃ」には、処理において、サーバロジックを呼び出すか、クライアントロジックを呼び出すか指定する「ｔｙｐｅ」と、呼び出す業務処理を表わす「ｍａｉｎ」とが含まれている。つまり、「ｔｙｐｅ」では、業務処理ごとにクライアント１０で実行するかサーバ２０で実行するかが指定されている。

また、「ｌｏｇｉｃ」には、サーバ２０に送信するデータ「ｄａｔｅ」が定義されている。そして、「ｄａｔｅ」には、サーバ２０に送信する項目のｉｔｅｍ−ｉｄを定義する「ｉｔｅｍ−ｉｄ」が含まれる。

表示パネル情報記憶部１５ｂは、画面に表示するパネルについての情報を記憶した記憶部である。この表示パネル情報記憶部１５ｂに記憶される情報は、画面制御部１１によって使用される。

イベント制御部１３は、各種の処理手順などを規定したプログラムおよび所要データを格納するための内部メモリを有し、これらによって種々の処理を実行するが、特に、初期化処理部１３ａ、イベント判定部１３ｂ、業務処理実行部１３ｃを有する。

初期化処理部１３ａは、業務ロジックマッピング定義情報に従って、イベントおよび処理の登録ならびにパネルの生成を初期化処理として行う処理部である。また、初期化処理部１３ａは、表示パネル情報記憶部１５ｂに記憶された表示パネル情報を用いてパネルを作成し、画面制御部１１を介してパネルを表示する。なお、パネルの生成は、初期化処理時以外にパネルが表示される場合に行うこともできる。

ここで、クライアント１０の起動時における処理について図４を用いて説明する。図４は、クライアント未起動時およびクライアント起動時の処理を説明するための図である。同図に示すように、クライアント１０は、未起動時には、クライアント上には何も資産がない状態である（図４の（１）参照）。そして、クライアント１０は、起動処理が行われると、起動処理を行った旨をサーバ２０に通知し、起動時に必要な情報、かつクライアントで必要な情報のみを抜粋してダウンロードする（図４の（２）参照）。

つまり、クライアント１０では、起動時にサーバ２０から定義情報や業務処理をダウンロードする必要がなく、業務処理に必要な定義情報や業務処理については、必要になったタイミングでダウンロードを行う（後に詳述する図５参照）。

イベント判定部１３ｂは、業務処理を実行する場合に、当該業務処理をクライアント１０で実行するかサーバ２０で実行するかを判定する。具体的には、イベント判定部１３ｂは、利用者の画面操作によってイベントが発生すると、イベントキューへの登録を行い、イベントキューからイベントを取り出す。なお、イベントキューについては、後に、図６〜図８を用いて説明する。

そして、イベント判定部１３ｂは、表示パネル情報と業務ロジックマッピング定義情報とを用いて、イベントからアクションを特定し、特定されたアクションに対応する業務処理を実行する業務処理として決定する。

その後、イベント判定部１３ｂは、実行することが決定された業務処理に対応する「種別」を業務ロジックマッピング定義情報から読み出し、種別が「クライアント」であるか「サーバ」であるか判定する。この結果、イベント判定部１３ｂは、種別が「クライアント」の場合には、業務処理を実行する旨を業務処理実行部１３ｃに通知する。また、クライアント１０は、業務処理に対応する種別が「サーバ」の場合には、サーバ２０が業務処理を実行する旨の通知を通信制御部１４の業務処理データ送信部１４ａに通知する。

業務処理実行部１３ｃは、業務処理をクライアント１０で実行すると判定された場合には、業務処理をクライアント１０が実行する。ここで、クライアントが業務処理を実行する場合について、図５を用いて説明する。図５は、クライアント処理実行時について説明するための図である。

同図に示すように、イベント判定部１３ｂは、クライアント１０で動作する業務処理をサーバ２０からダウンロードして実行される。つまり、クライアント１０が業務処理を実行すると判定された場合にのみ、業務処理に必要な定義情報や業務処理についてダウンロードを行えばよい。

通信制御部１４は、業務処理をサーバ２０で実行すると判定された場合には、当該業務処理を前記サーバにおいて実行するように通信するが、特に、業務処理データ送信部１４ａおよび業務処理データ受信部１４ｂを有する。

業務処理データ送信部１４ａは、業務処理をサーバで実行すると判定された場合には、業務処理に必要なデータをサーバ２０に対して送信する。具体的には、通信制御部１４は、サーバ２０が業務処理を実行する旨の通知をイベント判定部１３ｂから受信すると、業務ロジックマッピング定義情報に従い、送信データを作成し、サーバ２０に送信する。例えば、業務処理データ送信部１４ａは、業務処理「業務処理ｃ」をサーバで実行する場合には、項目Ａ、項目Ｂに入力されたデータであるＦＬＤ１、ＦＬＤ２のデータを送信データとして作成し、サーバ２０に非同期通信で送信する。

業務処理データ受信部１４ｂは、サーバ２０から業務処理の結果を非同期通信で受信する。ここで、非同期通信を行った場合の問題点について、図６を用いて説明する。図９左側のフローに示すように、非同期通信を行った場合、サーバ２０にイベント（処理１）の実行を依頼した後、スレッドが一旦開放される。このため、図９右側のフローに示すように、イベント（処理１）をサーバに実行するように依頼した後、イベント（処理１）が実行中にも関わらず、別のイベント（処理２）が実行されてしまう。このため、非同期通信終了までの間に発生したイベント（処理２）が本来実施させたくないにも関わらずイベント（処理１）よりも先に実行されてしまう。

そこで、クライアント１０では、記憶領域にイベントキューを有して、イベントが順次実行できるように管理している。図７は、イベントキューを使用したイベント制御処理を説明するための図である。同図に示すように、クライアント１０では、発生したイベントをそのまま実行するのではなく、一旦キューに格納した後に、イベントを順次実行する。これにより、イベント１０は、非同期通信を利用しつつ発生したイベントを順次実行することが可能である。

ここで、イベントキューを使用したイベント制御処理の具体例について説明する。図８は、イベントキューを使用したイベント制御処理の具体例について説明するための図である。同図に示すように、クライアント１０は、イベント（処理１）が発生すると、そのイベント（処理１）をイベントキューに登録した後、イベント実行処理として、イベントキューにアクセスし、イベントキューから「処理１」を取得する。そして、クライアント１０は、取得された「処理１」をサーバ２０において実行させるために、サーバ２０に非同期通信で送信する。

そして、クライアント１０は、処理１が実行中に、別のイベント（処理２）が発生した場合には、イベント（処理２）をイベントキューに登録するとともに、イベントキューを参照する。ここで、クライアント１０は、イベントキューを参照して、処理１が処理中であることを確認し、処理２を実行しない。

その後、クライアント１０は、サーバ２０から処理１の結果を非同期通信で受信すると、処理１が完了したとして、イベントキューから処理１を削除し、イベントキューを確認する再起呼出しを行う。ここで、クライアント１０は、イベントキューに現在処理中の処理がないことを確認する。そして、クライアント１０は、イベントキューにアクセスし、イベントキューから処理２を取得して実行する。その後、クライアント１０は、処理２の実行が完了すると、イベントキューを確認する再起呼出しを行ってイベントキューに待機中の処理がないことを確認し、処理を終了する。

［サーバの構成］
次に、図９を用いて、図１に示したクサーバ２０の構成を説明する。図９は、実施例１に係るサーバ２０の構成を示すブロック図である。同図に示すように、このサーバ２０は、システム制御部２１、通信制御部２２、イベント制御部２３、記憶部２４を有し、ネットワーク等を介してクライアント１０と接続される。以下にこれらの各部の処理を説明する。

システム制御部２１は、接続されたクライアント１０との間でやり取りする各種情報に関する通信を制御する。具体的には、システム制御部２１は、クライアント１０が起動した際に、起動時に必要な情報、かつクライアントで必要な情報をクライアント１０に送信する。また、システム制御部２１は、クライアント１０で業務処理を実行する場合に、クライアント１０で動作する業務処理をクライアント１０に送信する。

通信制御部２２は、クライアント１０が業務処理をサーバ２０で実行すると判定した場合には、業務処理に必要なデータをクライアント１０から受信し、イベント制御部２３に通知する。

イベント制御部２３は、通信制御部２２から業務処理に必要なデータを受信した場合に、業務処理を実行し、通信制御部２２を介してクライアント１０に送信する。

記憶部２４は、通信制御部２２およびイベント制御部２３による各種処理に必要なデータおよびプログラムを格納するが、特に、業務ロジックマッピング定義情報をＸＭＬ形式で記憶した定義情報記憶部２４ａと、業務処理を記憶した業務処理記憶部２４ｂとを有する。

［クライアントによる処理］
次に、図１０を用いて、実施例１に係るクライアント１０による処理を説明する。図１０は、実施例１に係るクライアント１０の処理動作を示すフローチャートである。

同図に示すように、クライアント１０のイベント判定部１３ｂは、利用者の画面操作等によってイベントが発生すると（ステップＳ１０１肯定）、イベントキューへの登録を行い（ステップＳ１０２）、イベントキューからイベントを取り出す（ステップＳ１０３）。

そして、イベント判定部１３ｂは、表示パネル情報と業務ロジックマッピング定義情報とを用いて、イベントからアクションを特定し、特定されたアクションに対応する業務処理を実行する業務処理として決定する（ステップＳ１０４）。

その後、イベント判定部１３ｂは、業務処理をクライアント１０で実行するかを判定する（ステップＳ１０５）。具体的には、イベント判定部１３ｂは、実行することが決定された業務処理に対応する「種別」を業務ロジックマッピング定義情報から読み出し、種別が「クライアント」であるか「サーバ」であるか判定する。この結果、イベント判定部１３ｂは、業務処理をクライアント１０で実行すると判定された場合には（ステップＳ１０５肯定）、業務処理実行部１３ｃが業務処理を実行する（ステップＳ１０６）。

また、業務処理をサーバ２０で実行すると判定された場合には（ステップＳ１０５否定）、業務処理データ送信部１４ａは、業務ロジックマッピング定義情報に従い、送信データを作成し（ステップＳ１０７）、サーバ２０に送信する（ステップＳ１０８）。例えば、通信制御部１４は、業務処理「業務処理ｃ」をサーバで実行する場合には、項目Ａ、項目Ｂに入力されたデータであるＦＬＤ１、ＦＬＤ２のデータを送信データとして作成し、サーバ２０に非同期通信で送信する。その後、業務処理データ受信部１４ｂは、サーバ２０から業務処理の結果を非同期通信で受信する（ステップＳ１０９）。

[実施例１の効果]
上述してきたように、クライアント１０は、業務処理を実行する場合に、業務処理をクライアントで実行するかサーバで実行するかを判定し、クライアントで実行すると判定された場合には、業務処理をクライアントが実行し、サーバで実行すると判定された場合には、業務処理をサーバにおいて実行するように通信する。このため、業務処理の実行をクライアントまたはサーバに振り分けて、クライアントに掛かる負荷を分散することが可能である。

また、実施例１によれば、業務処理の実行をクライアントまたはサーバに振り分ける処理を行うことが可能であるので、業務処理について処理主体を意識した作りこみが不要となり、柔軟なクライアントサーバシステムを開発することが可能である。

ところで、上記の実施例１では、サーバが実行する業務処理に対応付けて、サーバに送信する送信データが定義されている場合を説明したが、本実施例はこれに限定されるものではなく、画面上の変更項目のみを自動で抽出し、送信データを作成するようにしてもよい。

そこで、以下の実施例２では、画面上の変更項目のみを自動で抽出し、送信データを作成する場合として、図１１および図１２を用いて、実施例２におけるクライアント１０ａの概要および処理について説明する。図１１は、実施例２に係るクライアント１０ａの概要を説明するための図であり、図１２は、実施例２に係るクライアント１０ａの処理手順を説明するためのフローチャートである。

まず最初に、実施例２に係るクライアント１０ａの概要を説明する。図１１に示すように、クライアント１０ａの業務ロジックマッピング定義情報では、実施例１と同様に「アクション」と「処理」と「種別」とを対応付けて記憶するが、サーバが業務処理を実行するのに必要なデータである「送信データ」を定義していない。

このような構成のもと、クライアント１０ａは、実施例１と同様に、決定された業務処理をクライアント１０ａで実行するかサーバ２０ａで実行するかを判定する。この結果、クライアント１０ａは、決定された業務処理をサーバ２０ａが実行すると判定した場合には、実施例１とは異なり、画面上で変更されたデータのみを抽出して送信データを作成し、サーバ２０ａに送信する。

つまり、クライアント１０ａは、画面上の変更項目のみを自動で抽出して送信データを作成するので、業務ロジックマッピング定義上に、送信データを定義しなくてもよい。また、クライアント１０ａは、画面上の変更項目のみを送信データとして送信するので、サーバ２０ａとの通信量を削減することができる。

次に、図１２を用いて実施例２に係るクライアント１０ａの処理について説明する。実施例２に係るクライアント１０ａの処理は、図１０に示した実施例１に係る処理と比較して、画面上の変更項目のみを自動で抽出して送信データを作成する点が相違する。

すなわち、図１２に示すように、クライアント１０ａは、業務処理をクライアント１０ａで実行するかクライアント２０ａで実行するかを判定した結果（ステップＳ２０５）、業務処理をサーバ２０ａで実行すると判定された場合には（ステップＳ２０５否定）、画面上の変更項目のみを抽出して（ステップＳ２０７）、送信データを作成する（ステップＳ２０８）。

このように、上記の実施例２では、クライアント１０ａは、業務処理をサーバにおいて実行するように、画面上の変更項目を抽出し、抽出された項目をサーバ側に送信するので、画面上の変更項目のみを送信データとして送信する結果、サーバ２０ａとの通信量を削減することが可能である。

ところで、上記の実施例１、２では、業務処理について、クライアントが実行するのかサーバが実行するのか予め定義されている場合を説明したが、本実施例はこれに限定されるものではなく、クライアントの負荷状況とサーバの負荷状況とに応じて、クライアントもしくはサーバのどちらで実行する業務処理であるかを判定するようにしてもよい。

そこで、以下の実施例３では、クライアントの負荷状況とサーバの負荷状況とに応じて、クライアントもしくはサーバのどちらで実行する業務処理であるかを判定する場合として、図１３および図１４を用いて、実施例３におけるクライアント１０ｂの概要および処理について説明する。図１３は、実施例３に係るクライアント１０ｂの概要を説明するための図であり、図１４は、実施例３に係るクライアント１０ｂの処理手順を説明するためのフローチャートである。

まず最初に、実施例３に係るクライアント１０ｂの概要を説明する。図１３に示すように、クライアント１０ｂの業務ロジックマッピング定義情報では、実施例１と同様に「アクション」と「処理」とを対応付けて記憶するが、業務処理を実行する処理主体を示す「種別」については定義を行わなくてもよい。なお、クライアント１０ｂまたはサーバ２０ｂ側でないと処理できない業務処理については、種別を定義する必要がある。

このような構成のもと、クライアント１０ｂは、実行する業務処理を決定した後、クライアントの負荷状況とサーバの負荷状況とを判断して、業務処理をクライアント１０ｂで実行するかサーバ２０ｂで実行するかを判定する。

具体的には、クライアント１０ｂは、実行することが決定された業務処理に対応する「種別」が業務ロジックマッピング定義情報に定義されているか検索し、業務処理に対応する「種別」が定義されている場合には、実施例１と同様に、「種別」を読み出して、業務処理を実行する主体が「クライアント」であるか「サーバ」であるかを判定する。

一方、クライアント１０ｂは、業務処理に対応する「種別」が定義されていない場合には、クライアント１０ｂの負荷状況（例えば、ＣＰＵまたはメモリの使用率など）と、サーバ２０ｂの負荷状況（例えば、レスポンス時間など）とを判断して、業務処理をクライアント１０ｂで実行するかサーバ２０ｂで実行するかを自動的に判定する。

つまり、クライアント１０ｂは、クライアントの負荷状況とサーバの負荷状況とに応じて、クライアントもしくはサーバのどちらで実行する業務処理であるかを判定するので、クライアント１０ｂおよびサーバ２０ｂの状態に応じた業務処理の自動分散を行うことができる。

次に、図１４を用いて実施例３に係るクライアント１０ｂの処理について説明する。実施例３に係るクライアント１０ｂの処理は、図１０に示した実施例１に係る処理と比較して、クライアントの負荷状況とサーバの負荷状況とに応じて、クライアントもしくはサーバのどちらで実行する業務処理であるかを判定する点が相違する。

すなわち、図１４に示すように、実施例１と同様に、表示パネルと業務ロジックマッピング定義情報とを用いて、実行する業務処理を決定した後（ステップＳ３０４）、実施例２に係るクライアント１０ｂでは、決定された業務処理に対応する「種別」の定義があるか判定する（ステップＳ３０５）。

その結果、クライアント１０ｂは、業務処理に対応する「種別」が定義されている場合には（ステップＳ３０５肯定）、実施例１と同様に、「種別」を読み出し、「種別」に従ってクライアント１０ｂまたはサーバ２０ｂで業務処理を実行する（ステップＳ３０６）。

また、クライアント１０ｂは、業務処理に対応する「種別」が定義されていない場合には（ステップＳ３０５否定）、クライアント１０ｂの負荷状態およびサーバ２０ｂの負荷状態を判断し、クライアント１０ｂの負荷状態およびサーバ２０ｂの負荷状態に応じて、種別を決定する（ステップＳ３０７）。

この結果、クライアント１０ｂは、業務処理をクライアント１０ｂで実行すると判定された場合には（ステップＳ３０８肯定）、実施例１と同様に、業務処理を実行する（ステップＳ３０９）。また、クライアント１０ｂは、業務処理をサーバ２０ｂで実行すると判定された場合には（ステップＳ３０８否定）、実施例１と同様に、業務ロジックマッピング定義情報に従って送信データを作成してサーバ２０ｂに送信し、その後サーバ２０ｂから業務処理の結果を受信する（ステップＳ３１０〜Ｓ３１２）。

このように、上記の実施例３では、クライアント１０の負荷状況とサーバ２０の負荷状況とに応じて、クライアントもしくはサーバのどちらで実行する業務処理であるかを判定するので、クライアント１０ｂおよびサーバ２０ｂの状態に応じた業務処理の自動分散を行うことが可能である。

ところで、上記の実施例１〜３では、クライアントとサーバとの接続関係が一対一である場合に、業務処理をクライアントかサーバに振り分ける処理を説明したが、本実施例はこれに限定されるものではなく、クライアントが複数のサーバと接続関係にある場合であってもよい。

そこで、以下の実施例４では、クライアントが複数のサーバと接続関係にある場合に、任意のサーバに対して業務処理に必要なデータを送信する場合として、図１５および図１６を用いて、実施例４におけるクライアント１０ｃの概要および処理について説明する。図１５は、実施例４に係るクライアント１０ｃの概要を説明するための図であり、図１６は、実施例４に係るクライアント１０ｃの処理手順を説明するためのフローチャートである。

まず最初に、実施例４に係るクライアント１０ｃの概要を説明する。図１５に示すように、クライアント１０ｃの業務ロジックマッピング定義情報では、実施例１と同様に「アクション」と「処理」と「種別」とを対応付けて記憶するとともに、業務処理を実行するサーバを示す「接続先サーバ」が定義されている。

このような構成のもと、クライアント１０ｃは、業務処理をクライアント１０ｃで実行するかサーバ２０ｃで実行するかを判定し、業務処理に対応する種別が「サーバ」の場合には、業務ロジックマッピング定義情報から「接続先サーバ」を読み出す。そして、クライアント１０ｃは、読み出された「接続先サーバ」から、業務処理を実行するサーバを特定し、特定されたサーバに対して業務処理に必要なデータを送信する。

つまり、クライアント１０ｃは、業務ロジックマッピング定義上に接続先サーバの指定を可能とすることで、任意のサーバ上で業務処理を実行させる。この結果、任意のサーバ上で業務処理呼び出しが可能となることにより、複数サーバの業務処理結果を統合し、１画面上に表示するといった制御が可能となる。

次に、図１６を用いて実施例４に係るクライアント１０ｃの処理について説明する。実施例４に係るクライアント１０ｃの処理は、図１２に示した実施例２に係る処理と比較して、業務処理をサーバが実行する場合に、接続先サーバ情報を取得し、複数のサーバのうち、いずれのサーバに送信データを送信するか判断する点が相違する。

すなわち、図１６に示すように、実施例２と同様に、業務処理をクライアント１０ｃで実行するかを判定した結果（ステップＳ４０５）、クライアント１０ｃは、決定された業務処理をサーバ２０ａが実行すると判定した場合には（ステップＳ４０５否定）、画面上の変更項目のみを抽出する（ステップＳ４０７）。その後、実施例４に係るクライアント１０ｃでは、接続先サーバ情報を取得する（ステップＳ４０８）。

そして、クライアント１０ｃは、送信データを作成し（ステップＳ４０９）、接続先サーバ情報に該当するサーバに対して送信データを送信する（ステップＳ４１０）。その後、クライアント１０ｃは、サーバから業務処理の結果を受信する（ステップＳ４１１）。

このように、上記の実施例４では、クライアント１０ｃは、業務処理ごとに、業務処理を実行するサーバを示す接続先サーバ情報を記憶し、業務処理をサーバで実行すると判定された場合には、接続先サーバ情報を取得する。そして、クライアント１０ｃは、接続先サーバ情報から業務処理を実行するサーバを特定し、特定されたサーバに対して業務処理を実行するので、任意のサーバ上で業務処理呼び出しが可能となり、複数サーバの業務処理結果を統合し、１画面上に表示するといった制御が可能となる。

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

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

（２）プログラム
ところで、上記の実施例で説明した各種の処理は、あらかじめ用意されたプログラムをコンピュータで実行することによって実現することができる。そこで、以下では、図１７を用いて、上記の実施例と同様の機能を有するプログラムを実行するコンピュータの一例を説明する。図１７は、業務処理振分プログラムを実行するコンピュータを示す図である。

同図に示すように、クライアント装置としてのコンピュータ６００は、ＨＤＤ６１０、ＲＡＭ６２０、ＲＯＭ６３０およびＣＰＵ６４０をバス６５０で接続して構成される。

そして、ＲＯＭ６３０には、上記の実施例と同様の機能を発揮する業務処理振分プログラム、つまり、図１７に示すように、業務処理判定プログラム６３１、業務処理データ送信プログラム６３２が予め記憶されている。なお、プログラム６３１、６３２については、図２に示したクライアント１０の各構成要素と同様、適宜統合または分散してもよい。

そして、ＣＰＵ６４０が、これらのプログラム６３１、６３２をＲＯＭ６３０から読み出して実行することで、図１７に示すように、各プログラム６３１、６３２は、業務処理判定プロセス６４１、業務処理データ送信プロセス６４２として機能するようになる。各プロセス６４１、６４２は、図２に示したイベント判定部１３ｂ、業務処理データ送信部１４ａにそれぞれ対応する。

また、ＨＤＤ６１０には、図１７に示すように、業務ロジックマッピング定義データ６１１および表示パネルデータ６１２が設けられる。なお、業務ロジックマッピング定義データ６１１および表示パネルデータ６１２は、図２に示した業務ロジックマッピング定義情報記憶部１５ａおよび表示パネル情報記憶部１５ｂに対応する。そして、ＣＰＵ６４０は、業務ロジックマッピング定義データ６１１および表示パネルデータ６１２に対してデータを登録するとともに、ＲＡＭ６２０に格納し、ＲＡＭ６２０に格納されたデータに基づいて処理を実行する。

１ クライアントサーバシステム
１０ クライアント
１１ 画面制御部
１２ システム制御部
１３ イベント制御部
１３ａ 初期化処理部
１３ｂ イベント判定部
１３ｃ 業務処理実行部
１４ 通信制御部
１４ａ 業務処理データ送信部
１４ｂ 業務処理データ受信部
１５ 記憶部
１５ａ 業務ロジックマッピング定義情報記憶部
１５ｂ 表示パネル情報記憶部

Claims (6)

1. 業務処理を実行する場合に、当該業務処理をクライアントで実行するかサーバで実行するかを判定する業務処理判定部と、
   前記業務処理判定部によって前記業務処理をクライアントで実行すると判定された場合には、当該業務処理をクライアントが実行する業務処理実行部と、
   前記業務処理判定部によって前記業務処理をサーバで実行すると判定された場合には、当該業務処理を前記サーバにおいて実行するように通信する業務処理データ通信部と、
   を備えることを特徴とするクライアントサーバシステム。
2. 前記業務処理判定部は、前記クライアントの負荷状況と前記サーバの負荷状況とに応じて、クライアントもしくはサーバのどちらで実行する業務処理であるかを判定することを特徴とする請求項１に記載のクライアントサーバシステム。
3. 前記業務処理ごとに、当該業務処理を実行するサーバを示す接続先サーバ情報を記憶する接続先サーバ情報記憶部をさらに備え、
   前記業務処理データ通信部は、前記業務処理判定部によって前記業務処理をサーバで実行すると判定された場合には、前記接続先サーバ情報記憶部から前記接続先サーバ情報を取得し、当該接続先サーバ情報から業務処理を実行するサーバを特定し、当該サーバに対して業務処理を実行するように通信することを特徴とする請求項１または２に記載のクライアントサーバシステム。
4. 前記業務処理データ通信部は、前記業務処理判定部によって前記業務処理をサーバで実行すると判定された場合には、画面上の変更項目を抽出し、抽出された項目をサーバ側に送信することを特徴とする請求項１〜３のいずれか一つに記載のクライアントサーバシステム。
5. 業務処理を実行する場合に、当該業務処理をクライアントで実行するかサーバで実行するかを判定する業務処理判定部と、
   前記業務処理判定部によって前記業務処理をクライアントで実行すると判定された場合には、当該業務処理をクライアントが実行する業務処理実行部と、
   前記業務処理判定部によって前記業務処理をサーバで実行すると判定された場合には、当該業務処理を前記サーバにおいて実行するように通信する業務処理データ通信部と、
   を備えることを特徴とするクライアント装置。
6. 業務処理を実行する場合に、当該業務処理をクライアントで実行するかサーバで実行するかを判定する業務処理判定手順と、
   前記業務処理判定手順によって前記業務処理をクライアントで実行すると判定された場合には、当該業務処理をクライアントが実行する業務処理実行手順と、
   前記業務処理判定手順によって前記業務処理をサーバで実行すると判定された場合には、当該業務処理を前記サーバにおいて実行するように通信する業務処理データ通信手順と、
   をコンピュータに実行させることを特徴とする業務処理振分プログラム。

Images