JP5144473B2 - 情報処理システムに用いるクライアント装置、サーバ装置及びフレームワークプログラム - Google Patents

Description

本発明は、カスタマイズが容易に行えることにより様々なクライアント装置を実現し得る情報処理システムに用いるクライアント装置、サーバ装置及びフレームワークプログラムに関する。

従来から、各種の業務処理がクライアントサーバシステムにより実行されている。一般的に、クライアントサーバシステムでは、クライアント装置からサーバ装置に処理要求データを送信し、サーバ装置で処理要求データに対応する処理結果データを生成し、サーバ装置からクライアント装置に処理結果データを送信する。

ここで、システム全体の処理性能を最適化するために、サーバ装置のみならず、クライアント装置で処理要求データの入力チェック等を行う形態のクライアントサーバシステムもある。

これまで、クライアントとしての機能を実現する装置自体の性能が未熟であったため、また、クライアント装置毎に高級な機能を備えるコストが高かったため、Ｗｅｂを用いたシステムが多く開発されてきた。

これに関し、近年では、単なるＷｅｂアプリケーションに比べ画面設計の自由度を高くするために、リッチクライアント化の傾向にある。リッチクライアントでは、従来に比べクライアント装置上での複雑な処理が実行されることになる。そのため、クライアント装置のシステム全体の開発に占めるコストは増加している。
特開２００６−７２９７８号公報

しかしながら、一般的なクライアントサーバシステムにおいて、新規クライアント装置の開発や、既存のクライアント装置の設計方針が変更されると、クライアント装置の機能を全て作り直しており、多大な開発コストを要する傾向がある。

特にデータエントリ系のシステム等においては、システムの利便性が業務効率化に影響するため、クライアント装置においてユーザのデータ入出力を支援するための機能が多く設けられている。よって、クライアント装置自体の開発、改造の対象となる機能が多くなる。

本発明は上記実情に鑑みてなされたものであり、異なるクライアント装置の開発、および改造に対応するため、容易にカスタマイズし得る、情報処理システムに用いるクライアント装置、サーバ装置及びフレームワークプログラムを提供することを目的とする。

本発明は、処理要求データを入力画面を介して受け付けるクライアント装置と、該クライアント装置に入力される処理要求データを処理して処理結果データを返信するサーバ装置とを備えた情報処理システムであって、前記クライアント装置が、ユーザインタフェース部に表示される入力画面を介して入力された処理要求データを取り込む手段と前記サーバ装置からの処理結果データを前記ユーザインタフェース部に出力する手段とを有するユーザインタフェース連携部、前記処理要求データに異常が生じているか否かを判定するための処理要求チェック情報を内蔵メモリに記憶しており、該処理要求チェック情報に基づいて、前記ユーザインタフェース部により入力された処理要求データの異常の有無をチェックする手段を有する入力チェック部、前記サーバ装置との通信方式に対応させてデータを変換するための通信ルール情報を内蔵メモリに記憶しており、前記サーバ装置へ前記処理要求データを送信する場合に前記通信ルール情報に基づいて該処理要求データを変換する手段と前記サーバ装置から前記処理結果データを受信する場合に前記通信ルール情報に基づいて該処理結果データを変換する手段とを有するデータ変換部、前記処理要求データを該サーバ装置に送信する手段と、前記サーバ装置から返信される処理結果データを受信する手段とを有する通信制御部、前記ユーザインタフェース連携部、前記入力チェック部、前記データ変換部、前記通信制御部、これら各部へ個別に接続して制御する全体制御部、を備えた情報処理システムに用いるクライアント装置、サーバ装置及びフレームワークプログラムである。

なお、本発明は、各装置、各部の集合体を「システム」として表現したが、これに限らず、以下の記載では各装置、各部毎に「装置」又は「プログラム」として表現してもよく、また、システム又は各装置毎に「方法」として表現してもよい。すなわち、本発明は、任意のカテゴリーで表現可能となっている。

＜作用＞
従って、本発明は、クライアント装置が、ユーザインタフェース連携部と、入力チェック部と、動作制御部と、データ変換部と、通信制御部と、全体制御部とを備えており、全体制御部が各部へ個別に接続して制御するので、全体制御部に接続する各部を個別に開発することができ、容易にカスタマイズし得る情報処理システムを提供することができる。

本発明によれば、クライアント装置の設計方針が変更されても容易にカスタマイズし得る、情報処理システムに用いるクライアント装置、サーバ装置及びフレームワークプログラムを提供することが可能となる。

以下、図面を参照して本発明の実施形態を説明する。

＜第１の実施形態＞
（情報処理システムの構成）
図１は本発明の第１の実施形態に係る情報処理システム１の構成を示す模式図である。

情報処理システム１は、「処理要求データ」を入力画面を介して受け付けるクライアント装置１００と、クライアント装置１００に入力される処理要求データを処理して「処理結果データ」を返信するサーバ装置２００とを備えている。

クライアント装置１００は、全体制御装置１１０・ユーザインタフェース装置１２０・ユーザインタフェース連携装置１３０・入力チェック装置１４０・動作制御装置１５０・データ変換装置１６０・通信制御装置１７０を備えている。なお、各装置は、予めコンピュータ読み取り可能な記憶媒体またはネットワークから得られた「プログラム」がコンピュータの内蔵メモリ（以下、単にメモリと記載する）にインストールされることにより、それぞれの機能を実現する。

全体制御装置１１０は、ユーザインタフェース連携装置１３０・入力チェック装置１４０・動作制御装置１５０・データ変換装置１６０・通信制御装置１７０に個別に接続して各装置を制御するものである。換言すると、全体制御装置１１０には、各装置との接続インタフェースが設けられており、接続された装置に対して個別に制御が可能となっている。

ユーザインタフェース装置１２０（以下、ＵＩ装置１２０と記載する）は、一般的なマウスやキーボード、ディスプレイ等で構成され、クライアント装置１００を操作するユーザに対してデータの入出力を可能にするものである。ここでは、ＵＩ装置１２０に表示される入力画面を介して、処理要求データが入力される。例えば、ＵＩ装置１２０では、図２に示すような従業員新規登録処理画面などが表示される。また、この画面上で入力された従業員情報の登録を要求する処理要求データがサーバ装置２００に送信される。

ユーザインタフェース連携装置１３０（以下、ＵＩ連携装置１３０と記載する）は、ＵＩ装置１２０と連携し、ＵＩ装置１２０を介して入力された処理要求データを取り込む機能と、サーバ装置２００からの処理結果データをＵＩ装置１２０に出力する機能とを有するものである。

入力チェック装置１４０は、処理要求データに異常（以下エラーともいう）が生じているか否かを判定するための「処理要求チェック情報」を予め内蔵メモリ１４１に記憶しており、この処理要求チェック情報に基づいて、ＵＩ連携装置１３０により取り込まれた処理要求データにエラーが生じているか否かをチェックする。

具体的には、入力チェック装置１４０は、図３に示すような、画面チェック情報１４１０、画面定義情報１４２０及びコンポーネントチェック情報１４３０の３つのテーブル情報を記憶している。

画面チェック情報１４１０には、主キーの識別情報１４１１に対応づけて、対象画面名１４１２とチェックコード名１４１３とが書き込まれている。対象画面名１４１２は、処理要求データが入力された画面をチェック対象として指定するための情報である。チェックコード名１４１３は、対象画面名１４１２に入力された処理要求データに適用されるチェックコードの名称を示す。チェックコードは内蔵メモリ１４１に格納されており、チェックコード名１４１３の指定により読み出される。そして、このチェックコードの中に「処理要求チェック情報」が含まれており、処理要求データが正常であるか否かが判定される。例えば、図３の画面チェック情報１４１０の識別情報Ａ００１では、“LoginForm”画面に入力された処理要求データのチェックには、“CheckForm.checkLoginForm”のチェックコードのプログラムが呼び出されて処理が実行される。

画面定義情報１４２０には、主キーの識別情報１４２１に対応づけて、画面名１４２２、コンポーネント名１４２３、タイプ１４２４が記憶されている。画面名１４２２は画面を指定する情報であり、コンポーネント名１４２３は画面を構成するコンポーネントを識別する情報であり、タイプ１４２４はコンポーネントに入力される処理要求データのチェックに適用されるルールを識別するための情報である。このタイプ１４２４から、後述するコンポーネントチェック情報１４３０のチェックコード名が選択される。図３の画面定義情報１４２０の識別情報Ｂ００１の例では、“EntryForm”画面上の“TextBox1”コンポーネントに“Name”タイプのルールが適用される。また、数値を取得するコンポーネントであっても、“NumberField1”コンポーネントには“Age”タイプのルール、“NumberField2”コンポーネントには“Money”タイプのルール、というようにコンポーネントごとに異なるルールが適用されることもある。

コンポーネントチェック情報１４３０には、主キーである識別情報１４３１に対応づけて、タイプ１４３２とチェックコード名１４３３とが記憶される。図３の例では、“EntryForm”画面の“TextBox1”コンポーネントは画面定義情報１４２０によって“Name”タイプであるので、これに対応するチェックコードである“CheckRule.checkName”がコンポーネントチェック情報１４３０から呼び出される。

さらに詳しくは、入力チェック装置１４０は、図４に示すフローチャートの動作を行なう。入力チェック装置１４０は、処理要求データに異常があるか否かを判定する場合、まず画面定義情報１４２０を参照する（Ｎ１）。それから、入力チェック装置１４０は、識別情報１４２１で示された順にコンポーネントのタイプに対応するチェックコードを実行する（Ｎ２）。すなわち、入力チェック装置１４０は、入力された処理要求データと、画面定義情報１４２０の画面名１４２２及びコンポーネント名１４２３とを照合し、登録されているコンポーネントがあれば（Ｎ３−Ｙｅｓ）、そのコンポーネント名に対応するタイプ１４２４を取得する（Ｎ４）。続いて、入力チェック装置１４０は、取得したタイプに対応するチェックコード名１４３３をコンポーネントチェック情報１４３０から読み出す（Ｎ５）。そして、入力チェック装置１４０は、対象となるコンポーネントに対し、取得したチェックコード名１４３３で示されたチェックコードの処理を実行して、処理要求データにエラーが生じているか否かのチェックを行う（Ｎ６）。チェックの結果、処理要求データにエラーが生じている場合（Ｎ７−Ｙｅｓ）には、そのエラー内容を内蔵メモリに記録する（Ｎ８）。入力チェック装置１４０は、この処理を、画面定義情報１４２０に記憶されている全てのコンポーネント名１４２３について繰り返す（Ｎ２−Ｎｏ）。

次に、入力チェック装置１４０は、入力画面上でのコンポーネント単位でのチェック処理が完了すると、画面単位での入力データのエラーチェックを実施する。まず、入力チェック装置１４０は、画面チェック情報１４１０を参照する（Ｎ９）。それから、入力チェック装置１４０は、識別情報１４１１で示された順に、対象画面名１４１２に対応するチェックコードを実行する（Ｎ１０）。すなわち、入力チェック装置１４０は、入力された処理要求データと、画面チェック情報１４１０の対象画面名１４１２とを照合し、登録されている対象画面名があれば（Ｓ１１−Ｙｅｓ）、その対象画面名に対応するチェックコード名１４１３を読み出す（Ｓ１２）。そして、入力チェック装置１４０は、対象画面に対し、取得したチェックコード名１４３３で示されたチェックコードの処理を実行して、処理要求データにエラーが生じているか否かのチェックを実行する（Ｓ１３）。チェックの結果、処理要求データにエラーが生じている場合（Ｎ１４−Ｙｅｓ）には、そのエラー内容を内蔵メモリに記録する（Ｎ１５）。入力チェック装置１４０は、この処理を画面チェック情報１４１０に記憶されている全ての対象画面名１４１２について繰り返す（Ｎ１０）。

動作制御装置１５０は、処理要求データを修正するための「修正データ」を予め内蔵メモリ１５１に記憶しており、入力チェック装置１４０により処理要求データに異常があると判定された場合、修正データに基づいて、処理要求データの異常が修正可能であるか否かを判定するとともに、修正可能であれば該処理要求データを修正するものである。また、動作制御装置１５０は、処理結果データに異常があるか否かを判定するための「処理結果チェック情報」を予め内蔵メモリ１５１に記憶しており、処理結果チェック情報に基づいて、サーバ装置２００から返信された処理結果データの異常の有無をチェックするとともに、異常があればエラーデータを生成する機能を有している。

具体的には、動作制御装置１５０は、図５に示すような動作ルール情報１５１０を記憶する。動作ルール情報１５１０には、主キーである識別情報１５１１に関連づけて、エラー原因１５１２、エラー種別１５１３、対象範囲１５１４、処理コード１５１５が記憶されている。エラー原因１５１２は、入力チェック装置１４０により処理要求データに異常があると判定された場合、異常があると判定された処理要求データの画面上での入力箇所を示す。エラー種別１５１３には、処理要求チェック情報との比較から、処理要求データのエラー内容の重大度が書き込まれる。ここでは、エラー種別は“警告”、“補正可能”、“修復不能”の３つに大別される。最も軽度のエラーの場合はエラー種別が“警告”となる。この場合、エラーのコメントを付記する形で対応する処理コードが実行される。エラー種別が“補正可能”である場合は、処理コードの実行により、データ内容が修正される。エラー種別が“修復不能”である場合は、処理コードの実行は行なわれず、エラー情報が要求元に差し戻される。対象範囲１５１４は、エラーの影響範囲が画面単位なのかコンポーネント単位なのかを示している。処理コード１５１５は、実際の処理を実行するプログラムであり、「修正データ」及び「処理結果チェック情報」が含まれている。図５には、指定された処理を呼び出す際の引数を受け渡す範囲が示されている。エラー種別が“警告”の場合のコメントの付加、“補正可能”の場合のデータの修正、“修復不能”の際のエラー処理を規定する情報が示される。

データ変換装置１６０は、サーバ装置２００との通信方式に対応させてデータを変換するための「通信ルール情報１６１０」を予め内蔵メモリ１６１に記憶しており、サーバ装置２００へ処理要求データを送信する場合、この通信ルール情報１６１０に基づいて処理要求データを変換するものである。また、データ変換装置１６０は、サーバ装置２００から処理結果データを受信する場合、通信ルール情報１６１０に基づいて処理結果データを変換する。要するに、このデータ変換によって、クライアント装置１００のＵＩ装置１１０上でのデータの保持形式と、サーバ装置２００と通信するためのデータの形式との間での独立性が保たれることになる。なお、通信ルール情報１６１０には、図６に示すように、主キーの識別情報１６１１に対応づけて、リクエスト名１６１２・通信方式１６１３・データ変換方式１６１４・通信先サーバ情報１６１５が記憶されている。リクエスト名１６１２は、処理要求データの種類を照合するための情報である。通信方式１６１３は、通信先サーバ装置と通信する方式を示す情報である。データ変換方式１６１４は、通信方式１６１３に対応させて送受信するデータの変換方式を示す情報である。通信先サーバ情報１６１５は、処理要求データの処理を実行させるサーバ装置を示す情報である。

通信制御装置１７０は、処理要求データをサーバ装置２００に送信する機能と、サーバ装置２００から返信される処理結果データを受信する機能とを有するものである。なお、通信制御装置１７０は、通信方式をユーザ定義により切り替えることが可能である。

サーバ装置２００は、全体制御装置２１０・通信制御装置２２０・データ変換装置２３０・データチェック装置２４０・動作制御装置２５０・ロジック情報読出装置２６０・ロジック実行装置２７０を備えている。

全体制御装置２１０は、通信制御装置２２０・データ変換装置２３０・データチェック装置２４０・動作制御装置２５０・ロジック情報読出装置２６０に個別に接続して各装置を制御するものである。すなわち、全体制御装置２１０には、各装置との接続インタフェースが設けられており、接続された装置に対して個別に制御が可能となっている。

通信制御装置２２０は、処理要求データを該クライアント装置１００から受信する機能と、クライアント装置１００へ処理結果データを送信する機能とを有する。

データ変換装置２３０は、クライアント装置１００との通信方式に対応させてデータを変換するための「サーバ側通信ルール情報２３２０」を内蔵メモリ２３１に記憶しており、クライアント装置１００から処理要求データを受信する場合、サーバ側通信ルール情報２３２０に基づいて該処理要求データを変換する。また、データ変換装置２３０は、クライアント装置１００へ処理結果データを送信する場合、サーバ側通信ルール情報２３２０に基づいて処理結果データを変換する。このデータ変換によって、サーバ装置２００でのデータの保持形式と、クライアント装置１００と通信するためのデータの形式との間での独立性が保たれる。なお、サーバ側通信ルール情報２３２０には、図７に示すように、主キーの識別情報２３２１に対応づけて、通信方式２３２２・データ変換方式２３２３が記憶されている。通信方式２３２２は、クライアント装置１００と通信する方式を示す情報である。データ変換方式２３２３は、通信方式２３２２に対応させて送受信するデータの変換方式を示す情報である。

データチェック装置２４０は、処理要求データに異常が生じているか否かを判定するための「データチェック情報」を内蔵メモリに記憶しており、このデータチェック情報に基づいて、クライアント装置１００から受信した処理要求データの異常の有無をチェックするものである。データチェック装置２４０が記憶するデータチェック情報は、クライアント装置１００の入力チェック装置１４０が記憶する処理要求チェック情報と同様のものを利用することができる。

動作制御装置２５０は、処理要求データを修正するための「サーバ側修正データ」を内蔵メモリに記憶しており、データチェック装置２４０により処理要求データに異常があると判定された場合、サーバ側修正データに基づいて、処理要求データの異常が修正可能であるか否かを判定するとともに、修正可能であれば処理要求データを修正する。

ロジック情報読出装置２６０は、処理要求データと、この処理要求データを処理するためのロジックコード名とを対応づけた「要求ロジック対応ルール情報２６１０」を内蔵メモリ２６１に記憶しており、データチェック装置２４０により異常が無いと判定された処理要求データ、あるいは動作制御装置２５０により修正された処理要求データに対して適用されるロジックコード名を要求ロジック対応ルール情報２６１０から読み出すものである。

具体的には、ロジック情報読出装置２６０は、図８に示すような要求ロジック対応ルール情報２６１０を記憶する。要求ロジック対応ルール情報２６１０には、主キーである識別情報２６１１に関連づけて、リクエスト名２６１２とロジックコード名２６１３とが記憶されている。全体制御装置２１０からロジック情報読出装置２６０にクライアント装置１００から発行された処理要求データが送出され、ロジック情報読出装置２６０に合致するリクエスト名２６１２があると、そのリクエスト名に対応するロジックコード名２６１３が読み出される。読み出されたロジックコード名２６１３は全体制御装置２１０に送出される。

ロジック実行装置２７０は、ロジック情報読出装置２６０により読み出されたロジックコード名９１３に対応するロジックコードを実行して処理結果データを生成するものである。

（情報処理システムの動作）
次に本実施形態に係る情報処理システム１の動作を図９のフローチャートを用いて説明する。

始めにクライアント装置１００からサーバ装置２００に処理要求データを送信する際の手順を説明する。

まず、クライアント装置１００のユーザインタフェース装置１２０から処理要求データが入力される（Ｓ１）。続いて、全体制御装置１１０によりＵＩ連携装置１３０が制御されて、入力された処理要求データが全体制御装置１１０に取り込まれる。そして、全体制御装置１１０から入力チェック装置１４０に処理要求データが送出される。入力チェック装置１４０では、予め記憶された処理要求チェック情報との比較により、処理要求データにエラーが生じているか否かがチェックされる（Ｓ２）。そして、入力チェック装置１４０からエラーが生じているか否かのチェック結果が全体制御装置１１０に送出される。

全体制御装置１１０に、入力チェック装置１４０からエラーが生じていない旨のチェック結果が送出された場合（Ｓ２−Ｙｅｓ）、全体制御装置１１０からデータ変換装置１６０に処理要求データがそのまま送出される。続いて、データ変換装置１６０により、処理要求データが送信先サーバ装置との通信方式に対応したデータに変換され、変換されたデータが全体制御装置１１０に送出される（Ｓ３）。そして、全体制御装置１１０の制御により、通信制御装置１７０を介して、送信先サーバ装置との通信方式に対応した処理要求データが当該サーバ装置に送信される（Ｓ４）。

一方、ステップＳ２において、処理要求データにエラーが生じている旨のチェック結果が全体処理装置１１０に送出された場合（Ｓ２−Ｎｏ）、全体制御装置１００から動作制御装置１５０に処理要求データが送出される。

そして、動作制御装置１５０により、予め記憶された修正データとの比較により、処理要求データのエラーが修復可能であるか否かが判定される（Ｓ５）。修復可能であると判定された場合（Ｓ５−Ｙｅｓ）、動作制御装置１５０により処理要求データが修正され、修正された処理要求データが全体制御装置１１０に送出される（Ｓ６）。一方、修復可能ではないと判定された場合（Ｓ５−Ｎｏ）、動作制御装置１５０によりエラーデータが生成されて全体制御装置１１０に送出される（Ｓ７）。この場合、全体制御装置１１０の制御により、サーバ装置２００との通信は行なわれず、エラーが生じた旨がＵＩ装置１２０に出力される。

次にサーバ装置２００がクライアント装置１００から処理要求データを受信したときの手順を説明する。

まず、サーバ装置２００の通信制御装置２２０の機能により、クライアント装置１００からの処理要求データが受信される（Ｓ８）。続いて、データ変換装置２３０の機能により、受信された処理要求データがサーバ装置２００内で処理可能な形式に変換される（Ｓ９）。

次に、データチェック装置２４０で、受信した処理要求データにエラーが生じているか否かが判定される（Ｓ１０）。そして、処理要求データにエラーが生じているか否かのチェック結果がデータチェック装置２４０から全体制御装置２１０に送出される。

データチェック装置２４０から全体制御装置２１０に処理要求データにエラーが生じていない旨のチェック結果が送出されると（Ｓ１０−Ｙｅｓ）、その処理要求データに対応するロジックコード名の読出命令が全体制御装置２１０からロジック情報読出装置２６０に送出される。続いて、ロジック情報読出装置２６０により、処理要求データに含まれるリクエスト名に基づいて要求ロジック対応ルール情報からロジックコード名が読み出され、全体制御装置２１０に送出される（Ｓ１１）。続いて、全体制御装置２１０により、ロジックコード名がロジック実行装置２７０に送出される。ロジック実行装置２７０では、ロジックコード名に対応するロジックコードが実行され、実行された結果が処理結果データとして生成される（Ｓ１２）。そして、ロジック実行装置２７０から全体制御装置２１０に処理結果データが送出される。続いて、全体制御装置２１０のデータ変換装置２３０の制御により、クライアント装置１００との通信方式にあわせて処理結果データが変換されて送信される（Ｓ１３）。

一方、ステップＳ１０において、データチェック装置２４０から全体制御装置２１０に処理要求データにエラーが生じている旨のチェック結果が送出されると（Ｓ１０−Ｎｏ）、動作制御装置２５０により、処理要求データの修正が可能であるか否かがサーバ側修正データに基づいて判定される（Ｓ１４）。処理要求データの修正が可能であると動作制御装置２５０により判定された場合（Ｓ１４−Ｙｅｓ）、処理要求データが修正される（Ｓ１５）。そして、ステップＳ１１に続く。これに対し、処理要求データの修正が不可能であると動作制御装置２５０により判定された場合（Ｓ１４−Ｎｏ）、処理結果データとしてエラーデータが生成される（Ｓ１６）。そして、このエラーデータがデータ変換装置２３０により変換された後、クライアント装置１００に送出される。

次にクライアント装置１００がサーバ装置２００から処理結果データを受信したときの手順を説明する。

クライアント装置１００によりサーバ装置２００から処理結果データが受信されると、全体制御装置１１０によりデータ変換装置１６０が制御される。そして、処理結果データがデータ変換装置１６０によりクライアント装置１００内で処理可能な形式に変換される（Ｓ１７）。

続いて、全体制御装置１１０の動作制御装置１５０の制御により、予め記憶された処理結果チェック情報との比較から、処理結果データにエラーが生じているか否かが確認される（Ｓ１８）。エラーが生じていなければ（Ｓ１８−Ｙｅｓ）、処理結果データがＵＩ装置１２０を介して出力される（Ｓ１９）。一方、エラーが生じていれば、動作制御装置１５０により、エラーデータが生成される（Ｓ１８−Ｎｏ，Ｓ７）。そして、エラーデータがＵＩ装置１２０を介して出力される。

（情報処理システムの効果）
以上説明したように、本実施形態に係る情報処理システム１は、クライアント装置１００が、ＵＩ連携装置１３０・入力チェック装置１４０・動作制御装置１５０・データ変換装置１６０・通信制御装置１７０・全体制御装置１１０を備えており、全体制御装置１１０が各装置に個別に接続して制御するので、全体制御装置１１０に接続する各装置を個別に開発することができる。それゆえ、情報処理システム１の機能を削除または追加するといったカスタマイズを容易に行なうことができる。

換言すると、本実施形態に係る情報処理システム１のクライアント装置１００は、全体制御装置１１０と各装置とのインタフェースが統一化されており、例えば通信モジュールの入れ替え等が容易な構成となっている。

このため、新規にリッチクライアントのシステムを構築する場合においても、既存のファットクライアントやシンクライアントに対応したシステムから、同じインタフェースに基づく各装置を流用することが可能となる。

また、情報処理システム１は、サーバ装置２００が、通信制御装置２２０・データ変換装置２３０・データチェック装置２４０・動作制御装置２５０・ロジック情報読出装置２６０・ロジック実行装置２７０・全体制御装置２１０を備えており、全体制御装置２１０が各装置に個別に接続して制御するので、全体制御装置２１０に接続する各装置を個別に開発することができる。それゆえ、情報処理システム１の機能を削除または追加するといったカスタマイズを容易に行なうことができる。

また、クライアント装置１００は、各機能が異なるリッチクライアントを用いる構築技術により実現されてもよい。これにより、処理要求データの入力に際して、一般的なＷｅｂアプリケーションに比して利便性の高い様々なユーザインタフェースを提供することができる。更に、動作制御装置１５０によって、処理要求データのエラーの種類に応じた後処理としてクライアント装置１００のアプリケーション側で定義した処理もできる。

そして、情報処理システム１は、全体制御装置１１０が各装置と個別に接続して制御する構成であるので、リッチクライアントシステムの開発を標準化し、生産性と品質の向上に資するものである。

また、クライアント装置１００において、ＵＩ連携装置１３０・入力チェック装置１４０・動作制御装置１５０・データ変換装置１６０・通信制御装置１７０・全体制御装置１１０は、個別のプログラムがコンピュータに組み込まれることにより実現されるので、各装置のカスタマイズにより、リッチクライアントシステムを容易に構築することができる。

リッチクライアントシステムは、例えば図１０に示すような構成で実現される。この例では、４種類のクライアントの実装技術が挙げられている。なお、ここでは、クライアントの実装技術、および通信方式、サーバ、ＤＢＭＳ(Database Management System)がそれぞれ複数ある構成を示しているが、この一部分でシステムを構成してもよいし、さらに複数利用してシステムを構成してもよい。

ユーザ５０Ａが利用するクライアント装置１００Ａは、Ｗｅｂブラウザ単体で実現可能な環境である。Ajax(Asynchronous JavaScript + XML)などの例がこれにあたる。ユーザ５０Ａはブラウザ５１Ａを介して情報処理システムにアクセスする。クライアント装置１００ＡはJavaScript（サン・マイクロシステムズ社の商標）などのブラウザ上で稼動可能なスクリプトにより実現される。

ユーザ５０Ｂが利用するクライアント装置１００Ｂは、Ｗｅｂブラウザ上のプラグイン５２Ｂを利用する構成である。Adobe社（Adobeはアドビシステムズ社の商標）のFlashプラグインを用いた例などがこれにあたる。この構成の場合には、ユーザ５０Ｂは情報処理システム利用前にブラウザ５１Ｂ上へプラグイン５２Ｂの導入を済ませておく必要がある。

ユーザ５０Ｃが利用するクライアント装置１００Ｃは、プラグインに加えてクライアントへのランタイムが必要となる構成である。この構成の場合には、ユーザ５０Ｃは情報処理システム利用前にＷｅｂブラウザ５１Ｃへのプラグイン５２Ｃの導入に加えて、クライアント装置１００Ｃへのランタイムモジュール５３Ｃの導入が必要である。ランタイムモジュール５３Ｃは、クライアント装置１００Ｃの資源を利用することが可能である。

ユーザ５０Ｄが利用するクライアント装置１００Ｄは、Ｗｅｂブラウザを利用しない構成である。この構成の場合には、ユーザ５０Ｄの明示・非明示に関らず、クライアント装置１００Ｄへのクライアントモジュールのインストール作業が必要となる。

以上のように、さまざまな実装技術とその方式により実現されたクライアント装置１００Ａ〜１００Ｄがあり、それぞれ複数の通信方式６１〜６３に対応している。

また、サーバ装置２００Ａ，２００Ｂも同様に、複数の実装技術と方式とにより構成され、また複数の通信方式６１〜６３に対応している。

これにより、構築する情報処理システムにおいて、クライアント装置、サーバ装置、通信方式に関する必要な要件により、それぞれのサーバ装置及びクライアント装置の実現技術と通信方式とを選択することが可能となる。また、これらは共存可能であり、複数の方式によるクライアントを単一システム内に同居させることもできる。また、通信方式が合致すれば、異なる実現技術によるクライアント装置もしくはサーバ装置と接続可能である。

＜その他＞
なお、本発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。更に、異なる実施形態に構成要素を適宜組み合わせてもよい。

なお、上記実施形態に記載した手法は、コンピュータに実行させることのできるプログラムとして、磁気ディスク（フロッピー（登録商標）ディスク、ハードディスクなど）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤなど）、光磁気ディスク（ＭＯ）、半導体メモリなどの記憶媒体に格納して頒布することもできる。

また、この記憶媒体としては、プログラムを記憶でき、かつコンピュータが読み取り可能な記憶媒体であれば、その記憶形式は何れの形態であっても良い。

また、記憶媒体からコンピュータにインストールされたプログラムの指示に基づきコンピュータ上で稼働しているＯＳ（オペレーティングシステム）や、データベース管理ソフト、ネットワークソフト等のＭＷ（ミドルウェア）等が上記実施形態を実現するための各処理の一部を実行しても良い。

さらに、本発明における記憶媒体は、コンピュータと独立した媒体に限らず、ＬＡＮやインターネット等により伝送されたプログラムをダウンロードして記憶または一時記憶した記憶媒体も含まれる。

また、記憶媒体は１つに限らず、複数の媒体から上記実施形態における処理が実行される場合も本発明における記憶媒体に含まれ、媒体構成は何れの構成であっても良い。

尚、本発明におけるコンピュータは、記憶媒体に記憶されたプログラムに基づき、上記実施形態における各処理を実行するものであって、パソコン等の１つからなる装置、複数の装置がネットワーク接続されたシステム等の何れの構成であっても良い。

また、本発明におけるコンピュータとは、パソコンに限らず、情報処理機器に含まれる演算処理装置、マイコン等も含み、プログラムによって本発明の機能を実現することが可能な機器、装置を総称している。

本発明の第１の実施形態に係る情報処理システム１の構成を示す模式図である。 同実施形態に係るＵＩ装置１２０に表示される画面の一例を示す模式図である。 同実施形態に係る入力チェック装置１４０に記憶されるテーブル情報の一例を示す模式図である。 同実施形態に係る入力チェック装置１４０の動作を説明するためのフローチャートである。 同実施形態に係る動作制御装置１５０に記憶される動作ルール情報の一例を示す模式図である。 同実施形態に係るデータ変換装置１６０に記憶される通信ルール情報の一例を示す模式図である。 同実施形態に係るデータ変換装置２３０に記憶されるサーバ側通信ルール情報の一例を示す模式図である。 同実施形態に係るロジック情報読出装置２６０に記憶される要求ロジック対応ルール情報の一例を示す模式図である。 同実施形態に係る情報処理システム１の動作を説明するためのフローチャートである。 同実施形態に係る情報処理システム１の適用例を示す図である。

符号の説明

１・・・情報処理システム、１００・・・クライアント装置、１１０・・・全体制御装置、１２０・・・ユーザインタフェース装置、１３０・・・ユーザインタフェース連携装置、１４０・・・入力チェック装置、１５０・・・動作制御装置、１６０・・・データ変換装置、１７０・・・通信制御装置、２００・・・サーバ装置、２１０・・・全体制御装置、２２０・・・通信制御装置、２３０・・・データ変換装置、２４０・・・データチェック装置、２５０・・・動作制御装置、２６０・・・ロジック情報読出装置、２７０・・・ロジック実行装置。

Claims (8)

1. 処理要求データを入力画面を介して受け付けるクライアント装置と、該クライアント装置に入力される処理要求データを処理して処理結果データを返信するサーバ装置とを備えた情報処理システムに用いるクライアント装置であって、
   入力画面を表示するユーザインタフェース部と、
   前記ユーザインタフェース部に表示される入力画面を介して入力された処理要求データを取り込む手段と、前記サーバ装置からの処理結果データを前記ユーザインタフェース部に出力する手段とを有するユーザインタフェース連携部と、
   前記処理要求データに異常が生じているか否かを判定するための処理要求チェック情報を内蔵メモリに記憶しており、該処理要求チェック情報に基づいて、前記ユーザインタフェース部により入力された処理要求データの異常の有無をチェックする手段を有する入力チェック部と、
   前記サーバ装置との通信方式に対応させてデータを変換するための通信ルール情報を内蔵メモリに記憶しており、前記サーバ装置へ前記処理要求データを送信する場合、前記通信ルール情報に基づいて該処理要求データを変換する手段と、前記サーバ装置から前記処理結果データを受信する場合、前記通信ルール情報に基づいて該処理結果データを変換する手段とを有するデータ変換部と、
   前記処理要求データを該サーバ装置に送信する手段と、前記サーバ装置から返信される処理結果データを受信する手段とを有する通信制御部と、
   前記ユーザインタフェース連携部と、前記入力チェック部と、前記データ変換部と、前記通信制御部とに個別に接続して制御する全体制御部と、
   を備えたことを特徴とするクライアント装置。
2. 請求項１に記載のクライアント装置において、前記処理要求データを修正するための修正データを内蔵メモリに記憶しており、前記入力チェック部により処理要求データに異常があると判定された場合にエラーデータを生成する手段と、前記修正データに基づいて、該処理要求データの異常が修正可能であるか否かを判定するとともに、修正可能であれば該処理要求データを修正する手段とを有した、前記全体制御部で制御される動作制御部を備えたことを特徴とするクライアント装置。
3. 処理要求データを入力画面を介して受け付けるクライアント装置と、該クライアント装置に入力される処理要求データを処理して処理結果データを返信するサーバ装置とを備えた情報処理システムに用いるサーバ装置であって、
   前記処理要求データを該クライアント装置から受信する手段と、前記クライアント装置へ前記処理結果データを送信する手段とを有するサーバ側通信制御部と、
   前記クライアント装置との通信方式に対応させてデータを変換するためのサーバ側通信ルール情報を内蔵メモリに記憶しており、前記クライアント装置から前記処理要求データを受信する場合、前記サーバ側通信ルール情報に基づいて該処理要求データを変換する手段と、前記クライアント装置へ前記処理結果データを送信する場合、前記サーバ側通信ルール情報に基づいて該処理結果データを変換する手段とを有するサーバ側データ変換部と、
   前記処理要求データに異常が生じているか否かを判定するためのデータチェック情報を内蔵メモリに記憶しており、該データチェック情報に基づいて、前記クライアント装置から受信した処理要求データの異常の有無をチェックする手段を有するデータチェック部と、
   前記処理要求データと、該処理要求データを処理するためのロジック識別情報とを対応づけた要求ロジック対応ルール情報を内蔵メモリに記憶しており、前記データチェック部により異常が無いと判定された処理要求データ、あるいはサーバ側動作制御部により修正された処理要求データに対して適用されるロジック識別情報を前記要求ロジック対応ルール情報から読み出すロジック情報読出部と、
   前記ロジック情報読出部により読み出されたロジック識別情報に対応するロジック情報を実行して処理結果データを生成するロジック実行部と、
   前記サーバ側通信制御部と、前記サーバ側データ変換部と、前記データチェック部と、前記ロジック情報読出部とに個別に接続して制御するサーバ側全体制御部と、
   を備えたことを特徴とするサーバ装置。
4. 請求項３に記載のサーバ装置において、前記処理要求データを修正するためのサーバ側修正データを内蔵メモリに記憶しており、前記データチェック部により処理要求データに異常があると判定された場合にサーバ側エラーデータを生成する手段と、前記サーバ側修正データに基づいて、該処理要求データの異常が修正可能であるか否かを判定するとともに、修正可能であれば該処理要求データを修正する手段とを有した、前記サーバ側全体制御部で制御されるサーバ側動作制御部を備えたことを特徴とするサーバ装置。
5. 処理要求データを入力画面を介して受け付けるクライアント装置と、該クライアント装置に入力される処理要求データを処理して処理結果データを返信するサーバ装置とを備えた情報処理システムに用いる、諸情報を記憶する内蔵メモリを備えたクライアント装置で動作するフレームワークプログラムであって、
   前記クライアント装置に、
   前記クライアント装置に入力画面を表示させるユーザインタフェース部、
   前記ユーザインタフェース部に表示される入力画面を介して入力された処理要求データを取り込む手段と、前記サーバ装置からの処理結果データを前記ユーザインタフェース部に出力する手段とを有するユーザインタフェース連携部、
   前記処理要求データに異常が生じているか否かを判定するための処理要求チェック情報を内蔵メモリに記憶しており、該処理要求チェック情報に基づいて、前記ユーザインタフェース部により入力された処理要求データの異常の有無をチェックする手段を有する入力チェック部、
   前記サーバ装置との通信方式に対応させてデータを変換するための通信ルール情報を内蔵メモリに記憶しており、前記サーバ装置へ前記処理要求データを送信する場合、前記通信ルール情報に基づいて該処理要求データを変換する手段と、前記サーバ装置から前記処理結果データを受信する場合、前記通信ルール情報に基づいて該処理結果データを変換する手段とを有するデータ変換部、
   前記処理要求データを該サーバ装置に送信する手段と、前記サーバ装置から返信される処理結果データを受信する手段とを有する通信制御部、
   前記ユーザインタフェース連携部と、前記入力チェック部と、前記データ変換部と、前記通信制御部とに個別に接続して制御する全体制御部、
   として機能させるためのフレームワークプログラム。
6. 請求項５に記載のフレームワークプログラムにおいて、前記処理要求データを修正するための修正データを内蔵メモリに記憶しており、前記入力チェック部により処理要求データに異常があると判定された場合にエラーデータを生成する手段と、前記修正データに基づいて、該処理要求データの異常が修正可能であるか否かを判定するとともに、修正可能であれば該処理要求データを修正する手段とを有した、前記全体制御部で制御される動作制御部、としても機能させるためのフレームワークプログラム。
7. 処理要求データを入力画面を介して受け付けるクライアント装置と、該クライアント装置に入力される処理要求データを処理して処理結果データを返信するサーバ装置とを備えた情報処理システムに用いる、諸情報を記憶する内蔵メモリを備えたサーバ装置で動作するフレームワークプログラムであって、
   前記サーバ装置に、
   前記処理要求データを該クライアント装置から受信する手段と、前記クライアント装置へ前記処理結果データを送信する手段とを有するサーバ側通信制御部、
   前記クライアント装置との通信方式に対応させてデータを変換するためのサーバ側通信ルール情報を内蔵メモリに記憶しており、前記クライアント装置から前記処理要求データを受信する場合、前記サーバ側通信ルール情報に基づいて該処理要求データを変換する手段と、前記クライアント装置へ前記処理結果データを送信する場合、前記サーバ側通信ルール情報に基づいて該処理結果データを変換する手段とを有するサーバ側データ変換部、
   前記処理要求データに異常が生じているか否かを判定するためのデータチェック情報を内蔵メモリに記憶しており、該データチェック情報に基づいて、前記クライアント装置から受信した処理要求データの異常の有無をチェックする手段を有するデータチェック部、
   前記処理要求データと、該処理要求データを処理するためのロジック識別情報とを対応づけた要求ロジック対応ルール情報を内蔵メモリに記憶しており、前記データチェック部により異常が無いと判定された処理要求データ、あるいはサーバ側動作制御部により修正された処理要求データに対して適用されるロジック識別情報を前記要求ロジック対応ルール情報から読み出すロジック情報読出部、
   前記ロジック情報読出部により読み出されたロジック識別情報に対応するロジック情報を実行して処理結果データを生成するロジック実行部、
   前記サーバ側通信制御部と、前記サーバ側データ変換部と、前記データチェック部と、前記ロジック情報読出部とに個別に接続して制御するサーバ側全体制御部、
   として機能させるためのフレームワークプログラム。
8. 請求項７に記載のフレームワークプログラムにおいて、前記処理要求データを修正するためのサーバ側修正データを内蔵メモリに記憶しており、前記データチェック部により処理要求データに異常があると判定された場合にエラーデータを生成する手段と、前記サーバ側修正データに基づいて、該処理要求データの異常が修正可能であるか否かを判定するとともに、修正可能であれば該処理要求データを修正する手段とを有した、前記サーバ側全体制御部で制御されるサーバ側動作制御部、としても機能させるためのフレームワークプログラム。

Images