JP2010073093A

JP2010073093A - リッチクライアント型Ｗｅｂアプリケーションシステム、構築用フレームワークおよび構築方法

Info

Publication number: JP2010073093A
Application number: JP2008242314A
Authority: JP
Inventors: Hiroaki Ueda; 祐彰植田
Original assignee: Toshiba Corp; Toshiba Solutions Corp
Current assignee: Toshiba Corp; Toshiba Digital Solutions Corp
Priority date: 2008-09-22
Filing date: 2008-09-22
Publication date: 2010-04-02

Abstract

【課題】リッチクライアント開発におけるクライアントサイドの実装を均質化する。
【解決手段】業務画面を表示するクライアント６と、業務画面から入力された要求データに基づいて業務ロジック処理を実行し、その実行結果を応答データとしてクライアント６へ送信するサーバ７と、からなるリッチクライアント型Webアプリケーションであって、クライアント６が、業務画面に係る項目毎に、少なくとも入力桁数、入力タイプ、および表示属性を予め定義した画面項目定義ファイルに基づいて入力データのチェックを行い、チェックされた入力データを含む要求データをサーバ７に送信し、要求データに対してサーバ７から送信される応答データを受信し、この応答データに基づいて遷移画面を決定すると共に遷移画面に係る項目を探索し、応答データを貼り付けた業務画面を表示する。
【選択図】図４

Description

本発明は、MVCモデルに基づくリッチクライアント型Ｗｅｂアプリケーションシステム、構築用フレームワークおよび構築方法に関する。

近年、インターネットの発展に伴い、クライアントのＷｅｂブラウザからネットワーク上のサーバ内の業務アプリケーションに対して各種処理の要求を行い、サーバから返される処理結果をクライアント側において表示するＷｅｂアプリケーションシステムの導入が進められている。例えば、オンラインバンキング、旅行の予約、サーチエンジン、Ｗｅｂメールサービス、保険料の見積もり、株価のリアルタイム速報など様々なＷｅｂアプリケーションが企業の業務システムとして導入されている。

このＷｅｂアプリケーションシステムは、業務に直結するシステムであるので保守性や信頼性が高さと共に、開発期間が短いことが求められる。そのため、アプリケーションの設計手法として、ＭＶＣモデルに基づくフレームワークが広く用いられている。

ＭＶＣモデルは、ソフトウェアの設計モデルの一つであり、業務ロジックを実行するModel（モデル：M）、画面表示やファイルの入出力などModel（モデル）の処理結果を表現するView（ビュー：V）、入力を受け取ってその内容に応じてModel（モデル）およびView（ビュー）を制御するController（コントローラ：C）の３要素を組み合わせて設計する方法である。主処理はModel（モデル）に実装し、その処理結果がView（ビュー）に渡されることで、画面表示等が行なわれる。また、外部からの入力情報はController（コントローラ）が受け取り、処理が必要な場合はModel（モデル）に依頼し、出力が必要な場合はView（ビュー）に依頼する。このように、アプリケーションが機能毎に作成されることにより、独立性、再利用性、および拡張性を高めることができる。

しかし、従来型のＷｅｂアプリケーションシステムにおいては、クライアント側でＷｅｂブラウザを利用する構成のため、「ファンクションキーが使えない」、「レスポンスが悪い」などの問題があった。

そこで、上記の問題を解決する技術として、クライアント側にModel（モデル）やView（ビュー）を実装し、操作性や表現力を強化したリッチクライアント型Ｗｅｂアプリケーションシステムが知られている（例えば、特許文献１参照）。尚、リッチクライアント型Ｗｅｂアプリケーションは、RIA（Rich Internet Application）とも呼ばれている。
特開２００２−２１５３９４号公報

しかしながら、従来のリッチクライアント型Ｗｅｂアプリケーションは、操作性や表現力を向上させたことのトレードオフとして以下の二つの問題があった。

（１）Model（モデル）やController（コントローラ）についてもクライアントサイドで実装する必要があるが、クライアントサイドの実装を規定する仕組みが提供されていないため、業務アプリケーション毎の実装が可能である。すなわち、開発者によって異なる構成で実装が行われる恐れがある。
（２）クライアントサイドの開発言語がRIA製品固有のものであるので、開発においてはクライアント毎に処理記述言語を習得する必要があり、従来のＷｅｂ開発と比較して開発負荷（費用・時間）の増大が生じやすい。

そこで、本発明は、上記従来技術の問題に鑑み、リッチクライアント開発におけるクライアントサイドの実装を均質化すると共に、リッチクライアント毎の開発言語の習得を必要としないリッチクライアント型Ｗｅｂアプリケーションシステム、構築用フレームワーク、および構築方法を提供することを目的とする。

本発明に係るリッチクライアント型Ｗｅｂアプリケーションシステムは、業務画面を表示するクライアントと、このクライアントにネットワークを介して接続され、前記業務画面から入力された要求データに基づいて業務ロジック処理を実行し、その実行結果を応答データとして前記クライアントへ送信するサーバと、からなり、前記クライアントが、前記業務画面に係る項目毎に、少なくとも入力桁数、入力タイプ、および表示属性を予め定義した画面項目定義ファイルに基づいて前記項目の入力データのチェック処理を実行するチェック処理部と、前記チェック処理後の入力データを含む前記要求データを前記サーバに送信する要求データ送信部と、前記送信された要求データに対して前記サーバから送信される前記応答データを受信する応答データ受信部と、前記受信された応答データに含まれる遷移形態指定情報に基づいて前記業務画面からの遷移先となる画面を決定する次画面遷移部と、前記応答データに含まれる項目識別情報に基づいて前記遷移先となる画面に係る項目を探索し、前記項目識別情報が一致する項目に前記応答データを貼り付けるデータ貼付部と、前記応答データ受信部で受信された前記応答データを内部記憶領域へ保持するデータ保持部と、前記業務画面からの表示要求に基づいて前記内部記憶領域から前記応答データを抽出するデータ抽出部と、を備えることを特徴とする。

本発明に係るリッチクライアント型Ｗｅｂアプリケーションシステムの構築用フレームワークは、業務画面を表示するクライアントと、このクライアントにネットワークを介して接続され、前記業務画面から入力された要求データに基づいて業務ロジック処理を実行し、その実行結果を応答データとして前記クライアントへ送信するサーバと、からなるリッチクライアント型Ｗｅｂアプリケーションシステムの構築用フレームワークであって、前記クライアントに、前記業務画面に係る項目毎に、少なくとも入力桁数、入力タイプ、および表示属性を予め定義した画面項目定義ファイルに基づいて前記項目の入力データのチェック処理を実行するチェック処理部と、前記チェック処理後の入力データを含む前記要求データを前記サーバに送信する要求データ送信部と、前記送信された要求データに対して前記サーバから送信される前記応答データを受信する応答データ受信部と、前記受信された応答データに含まれる遷移形態指定情報に基づいて前記業務画面からの遷移先となる画面を決定する次画面遷移部と、前記応答データに含まれる項目識別情報に基づいて前記遷移先となる画面に係る項目を探索し、前記項目識別情報が一致する項目に前記応答データを貼り付けると共に、前記応答データを内部記憶領域へ保持するデータ貼付部と、前記業務画面からの表示要求に基づいて前記内部記憶領域から前記応答データを抽出するデータ抽出部と、を実装することを特徴とする。

本発明に係るリッチクライアント型Ｗｅｂアプリケーションシステムの構築方法は、業務画面を表示するクライアントと、このクライアントにネットワークを介して接続され、前記業務画面から入力された要求データに基づいて業務ロジック処理を実行し、その実行結果を応答データとして前記クライアントへ送信するサーバと、からなるリッチクライアント型Ｗｅｂアプリケーションシステムの構築方法であって、前記クライアントが、前記業務画面に係る項目毎に、少なくとも入力桁数、入力タイプ、および表示属性を予め定義した画面項目定義ファイルに基づいて前記項目の入力データのチェック処理を実行するチェック処理ステップと、前記クライアントが、前記チェック処理後の入力データを含む前記要求データを前記サーバに送信する要求データ送信ステップと、前記クライアントが、前記送信された要求データに対して前記サーバから送信される前記応答データを受信する応答データ受信ステップと、前記クライアントが、前記受信された応答データに含まれる遷移形態指定情報に基づいて前記業務画面からの遷移先となる画面を決定する次画面遷移ステップと、前記クライアントが、前記応答データに含まれる項目識別情報に基づいて前記遷移先となる画面に係る項目を探索し、前記項目識別情報が一致する項目に前記応答データを貼り付けるデータ貼付ステップと、前記クライアントが、前記応答データ受信ステップで受信された前記応答データを内部記憶領域へ保持するデータ保持ステップと、前記クライアントが、前記業務画面からの表示要求に基づいて前記内部記憶領域から前記応答データを抽出するデータ抽出ステップと、を有することを特徴とする。

本発明によれば、リッチクライアント開発におけるクライアントサイドの実装を均質化すると共に、リッチクライアント毎の開発言語の習得を必要としないリッチクライアント型Ｗｅｂアプリケーションシステム、構築用フレームワークおよび構築方法が提供される。

以下、本発明の実施形態について図面を用いて説明する。図１は、本発明の一実施形態に係るリッチクライアント型Ｗｅｂアプリケーションシステムの全体構成例を示すブロック図である。同図に示されるように、本実施形態に係るリッチクライアント型Ｗｅｂアプリケーションシステムは、Ｗｅｂクライアント１、Ｗｅｂサーバ２、アプリケーションサーバ３、およびデータベースサーバ４から構成され、LAN（Local Area Network）やインターネットなどのネットワーク５を介してクライアントサイド６とサーバサイド７に分類されている。

Ｗｅｂクライアント１は、業務画面の表示機能やＷｅｂサーバ２との通信機能などを備えるコンピュータであり、例えばＰＣ（Personal Computer）、ＰＤＡ（Personal Digital Assistants）、携帯電話などが挙げられる。Ｗｅｂクライアント１の台数に特に制限はない。

Ｗｅｂサーバ２は、Ｗｅｂクライアント１（リッチクライアント）からネットワーク５を介して送信されるＨＴＴＰ（Hyper Text Transfer Protocol）リクエストを受信すると共に、このリクエストに対するレスポンスを送信するサーバコンピュータである。

アプリケーションサーバ３は、Ｗｅｂサーバ２を介してＷｅｂクライアント１から取得されるＨＴＴＰリクエストに対して業務ロジック処理を行うサーバコンピュータである。

データベースサーバ４は、データベースを保有し、アプリケーションサーバ３からデータの検索や更新などの要求を受けた際に処理を行い、その実行結果をアプリケーションサーバ３に返すサーバコンピュータである。

Ｗｅｂサーバ２、アプリケーションサーバ３、およびデータベースサーバ４には、例えば処理能力の高いコンピュータを用い、これらは連携して稼動するものとする。

図２は、Ｗｅｂクライアント１、Ｗｅｂサーバ２、およびアプリケーションサーバ３に適用されるコンピュータの構成例を示す図である。同図に示すように、Ｗｅｂクライアント１などに適用されるコンピュータは、ＣＰＵ（Central Processing Unit）１１、ＲＯＭ（Read Only Memory）１２、ＲＡＭ（Random Access Memory）１３、インターフェース１４、システムバス１５、入力装置１６、表示装置１７、通信装置１９、および補助記憶装置１８から構成されている。

ＣＰＵ１１は、ＲＯＭ１２やＲＡＭ１３に格納されたプログラムやデータなどを用いて各種の演算処理を実行する処理装置である。ＲＯＭ１２は、コンピュータを機能させるための基本プログラムや環境ファイルなどを記憶する読み取り専用の記憶装置である。ＲＡＭ１３は、ＣＰＵ１１が実行するプログラムやプログラムの実行に必要なデータを記憶する記憶装置であり、高速な読み出しと書き込みが可能である。インターフェース１４は、各種のハードウェアとシステムバス１５との接続を仲介する装置およびプログラムである。システムバス１５は、ＣＰＵ１１、ＲＯＭ１２、ＲＡＭ１３、およびインターフェース１４で共有される情報伝達路である。

また、インターフェース１４には、入力装置１６、表示装置１７、補助記憶装置１８、および通信装置１９などのハードウェアが接続されている。入力装置１６は、ユーザからの入力を処理する装置であり、例えばキーボードやマウスなどである。表示装置１７は、ユーザに対して演算結果や作成画面などを表示する装置であり、例えばＣＲＴ、液晶ディスプレイ、プラズマディスプレイなどである。補助記憶装置１８は、プログラムやデータを蓄積する大容量の記憶装置であり、例えばハードディスク装置などである。通信装置１９は、コンピュータをネットワーク５に接続する装置であり、例えばモデムやＮＩＣ（Network Interface Card）などである。

図３は、リッチクライアント型ＷｅｂアプリケーションシステムをMVCモデルで表した図である。同図に示されるように、クライアントサイド６はView（ビュー）およびRIA開発の特性であるModel（モデル）とController（コントローラ）で構成される。一方、サーバサイド７はModel（モデル）とController（コントローラ）で構成される。そして、クライアントサイド６のModel（モデル）およびController（コントローラ）をRIAFW（Rich Internet Application Framework）の通信コンポーネントとして実装すると共に、サーバサイド７のController（コントローラ）についてもRIAFWの通信コンポーネントとして実装する。

図４は、リッチクライアント型Ｗｅｂアプリケーションシステムを構成するモジュールの相関図である。同図において、クライアントサイド６には、通信制御部２１、チェック処理部２２、要求データ送信部２３、応答データ受信部２４、次画面遷移部２５、データ貼付部２６、画面表示部２７、内部記憶領域２８、およびデータ抽出部２９が含まれ、サーバサイド７には要求データ受信部３１、DMC３２、制御部３３、業務ロジック呼出部３４、業務ロジック３５、データベース３６、および応答データ送信部３７が含まれている。また、破線で囲まれた領域は、RIAFWとして隠蔽化された状態で実装されるモジュール群を表し、画面項目定義ファイルなどの定義ファイルに基づいてチェック処理部２２や次画面遷移部２５の処理内容が決定されることが示されている。

また、図４に示されるように、業務画面からサーバサイド７への通信は、RIAFW内のチェック処理部２２から通信コンポーネント本体である通信制御部２１を経て要求データ送信部２３に連携され、サーバサイド７では要求データ受信部３１からDMC３２および制御部３３を経て業務ロジック呼出部３４に連携される。サーバサイド７から業務画面への通信は、応答データ受信部２４でデータを受信し、この受信データが通信制御部２１を経て次画面遷移部２５およびデータ貼付部２６で処理され、最終的に業務画面が表示されることで一連の動作が完結する。

以下、図４に示されるクライアントサイド６およびサーバサイド７の構成要素について詳細に説明する。

通信制御部２１は、クライアントとサーバ間の通信を制御するプログラムであり、クライアントサイド６の通信コンポーネントの本体に相当する。

チェック処理部２２は、画面項目定義ファイルに基づいて業務画面の表示項目に対する共通のチェック処理を行うプログラムである。具体的には、必須項目のチェック、桁数・タイプのチェックなどを行う。また、画面表示部２７と連携してエラーメッセージの表示も行う。

画面項目定義ファイルは、画面項目の入力桁数、入力タイプ（文字型・日付型・数値型等）、表示属性（必須・入力不可・非表示等）を定義している。図５は、画面項目定義ファイルの具体例を示す図である。

要求データ送信部２３は、業務画面における入力データを含む要求データ（リクエスト）をサーバサイド７に送信するプログラムである。要求データには、入力データ、業務画面のフォームデータ、業務画面での操作情報（アクション情報）などが含まれる。尚、本実施形態では、通信項目定義ファイル内で定義された項目のみを画面から取り出してHTTP POST形式に変換して送信する。この場合、HTML画面のフォーム内から送信（SUBMIT）された時と同様の形式で送信されることにより、サーバサイド７での処理は従来の仕組みをそのまま利用できる利点がある。

通信項目定義ファイルは、クライアントとサーバ間で通信対象とする項目を定義する。クライアントサイド６（要求データ送信部２３）とサーバサイド７（要求データ受信部３１）で同じものを利用するが、クライアントサイド６ではinput側、サーバサイド７ではoutput側の定義情報のみ利用すれば良い。この通信項目定義ファイルでは、業務ロジック３５で必要とするデータのみを通信対象とすると好適である。図６は、通信項目定義ファイルの具体例を示す図である。

応答データ受信部２４は、要求データ送信部２３から送信された要求データ（リクエスト）に対してサーバサイド７から送信されたXMLデータを応答データ（レスポンス）として受信して解析を行い、その解析結果を通信制御部２１に出力するプログラムである。

次画面遷移部２５は、応答データ受信部２４で受信した応答データに含まれる次遷移画面の画面IDと遷移形態指定情報に基づいて次画面を決定するプログラムである。具体的には、遷移形態指定情報が“Next”ならば同じWindowで別画面に切り替える、“Dialog”ならば子画面（Dialog）を表示する、“this”ならば画面遷移をせずに同一画面を表示する、“Window”ならば新しいブラウザWindowを開く、というように設定する。

データ貼付部２６は、応答データを次画面の表示項目の設定値として貼り付ける処理を行うプログラムである。例えば、応答データに含まれる項目IDをキーとして次画面において該当する項目を探し、項目IDが一致する項目の値として設定する。また、データ貼付部２６は、応答データを内部記憶領域２８に格納する。

画面表示部２７は、業務画面を表示すると共に、業務画面上で入力されたデータおよび処理要求をチェック処理部２２やデータ抽出部２９へ出力するプログラムであり、MVCモデルのView機能を提供する。

データ抽出部２９は、クライアントサイド６の業務画面からの表示要求に応じて内部記憶領域２８から応答データを抽出するプログラムである。

要求データ受信部３１は、クライアントサイド６からPOST形式で送信された要求データを受信し、この要求データをDMC３２にセットするプログラムである。

DMC（Data Model Container）３２は、クライアントサイド６から送信されたデータ、業務ロジック３５からの戻り値、画面に表示するデータ等のデータ群を格納する記憶領域である。DMC３２において各種データを共通に管理することで、後述する業務ロジック呼出部３４は業務ロジック制御ファイルに基づいて様々な画面データに対応する業務ロジック処理を呼び出すことができる。

制御部３３は、要求データ受信部３１で受信された要求データのDMC３２への格納、DMC３２からのデータ抽出、業務ロジック呼出部３４への処理要求、および応答データ送信部３７への処理要求を行うプログラムであり、サーバサイド７における各種処理の制御および仲介を行う。

業務ロジック呼出部３４は、業務ロジック制御ファイルの定義情報を読み込み、業務画面上でのアクションに対応する業務ロジック３５（ストアドプロシージャやクエリなど）を呼び出すプログラムである。

業務ロジック制御ファイルは、ストアドプロシージャやクエリ等の業務ロジック３５の制御パラメータとしてinput（引数）、output（戻り値）、呼び出すプロシージャ（またはSQL）を定義する。具体的には、業務ロジック制御ファイルは、DMC３２内の特定のデータ（業務画面からの要求データ）とそのデータに対応する業務ロジック３５を定義する。図７は、業務ロジック制御ファイルの具体例を示す図である。

応答データ送信部３７は、業務ロジック３５での実行結果、画面遷移定義ファイルで指定された次画面ID、遷移形態指定情報、およびエラーが発生した場合のエラー情報などを含むXML形式の電文を組み立て、応答データとしてクライアントサイド６に送信するプログラムである。

画面遷移定義ファイルは、応答データ送信部３７（サーブレット）の挙動を定義する。具体的には、業務画面のフォーム情報（ActionForm）、業務画面における動作情報（Action）、業務ロジックの実行結果の転送先の画面ＩＤ、クライアントとサーバ間のリクエスト・レスポンス時に行われる処理（ログ出力などのフィルタ）などを関連付けて定義する。図８は、画面遷移定義ファイルの具体例を示す図である。

図９は、本発明の一実施形態に係るリッチクライアント型Ｗｅｂアプリケーションシステムの構築手順の具体例を示すフローチャートである。

先ず、ＲＩＡ開発作業の上流工程として業務設計、業務画面設計、帳票設計を行う（Ｓ９０１）。次に、Ｓ９０１の設計情報に基づいてクライアントサイド６にＭＶＣモデルのコントローラ（Ｃ）として実装されるモジュールの設計を行い、このモジュールを呼び出すための引数をＭＶＣ引数定義ファイル内に定義する（Ｓ９０２）。ここでは、ＭＶＣ引数定義ファイルは汎用の表計算ソフトウェアで作成されたファイルとする。次に、モジュールの実行条件を決定する各種の定義ファイル（通信項目定義ファイル、画面遷移定義ファイル、業務ロジック制御ファイル）を生成する各種のファイル生成マクロをＭＶＣ引数定義ファイルの定義情報に基づいて実行し、定義ファイルをそれぞれ生成する（Ｓ９０３、Ｓ９０４、Ｓ９０５）。また、Ｓ９０２と平行してサーバサイド７を構成するデータベース３６の設計を行い、クライアントサイド６で表示する業務画面に係る項目の定義情報を画面項目定義ファイル内に定義する（Ｓ９０６）。そして、この画面項目定義ファイルに対応する画面ソースプログラム生成マクロを実行することで画面ソースプログラムを生成する（Ｓ９０７）。

図１０は、本発明の一実施形態に係るリッチクライアント型Ｗｅｂアプリケーションシステムにおける処理の具体例を示すフローチャートである。

先ず、クライアントサイド６において、画面表示部２７は、業務画面を表示する（Ｓ１００１）。

次に、画面表示部２７は、業務画面における入力情報がサーバサイド７への処理要求か否かを判定する（Ｓ１００２）。ここで、サーバサイド７への処理要求と判定された場合には、Ｓ１００３へ進む。これに対し、サーバサイド７への処理要求ではないと判定された場合にはＳ１００１へ戻る。

Ｓ１００３において、チェック処理部２２は、画面項目定義ファイルの定義情報を参照し、業務画面における入力データに対して必須項目チェックなどの共通化されたチェック処理を行う。

次に、チェック処理部２２は、エラー項目の有無を判定する（Ｓ１００４）。ここで、エラー項目有りと判定された場合には、Ｓ１００１へ戻ってエラーメッセージを業務画面に表示する。これに対し、エラー項目無しと判定された場合には、要求データ送信部２３は、通信制御部２１からの制御情報に基づいて画面項目定義ファイルを参照し、業務画面における入力データ、業務画面のフォーム情報、および業務画面での動作情報などを要求データとしてサーバサイド７へ送信する（Ｓ１００５）。

次に、サーバサイド７において、要求データ受信部３１は、要求データを受信し（Ｓ１００６）、受信した要求データをＤＭＣ３２へ格納する（Ｓ１００７）。また、制御部３３は、ＤＭＣ３２へのデータ格納を検知すると、業務ロジック呼出部３４を起動すると共に、ＤＭＣ３２から取り出したデータを業務ロジック呼出部３４へ出力する。

次に、業務ロジック呼出部３４は、制御部３３を介して取得したデータに基づいて業務ロジック制御ファイルを参照し、業務ロジック制御ファイルの定義情報と要求データに応じた業務ロジック３５を呼び出し、処理を行わせる（Ｓ１００８）。業務ロジック３５における実行結果は、業務ロジック呼出部３４と制御部３３を介してＤＭＣ３２へセットされると共に、応答データ送信部３７へ出力される。

次に、応答データ送信部３７は、制御部３３を介して業務ロジック３５における実行結果を取得し、この業務ロジック３５での実行結果や、画面遷移定義ファイルで指定された次画面ID、遷移形態指定情報、およびエラーが発生した場合のエラー情報などを含むXML形式の電文を組み立て、応答データとしてクライアントサイド６に送信する（Ｓ１００９）。

次に、クライアントサイド６において、応答データ受信部２４は、要求データ送信部２３から送信した要求データ（リクエスト）に対してサーバサイド７（応答データ送信部３７）から送信されたXML形式の応答データ（レスポンス）を受信し、通信制御部２１に出力する（Ｓ１０１０）。

次に、次画面遷移部２５は、通信制御部２１を介して応答データ受信部２４で受信した応答データを取得し、この応答データに含まれる次遷移画面の画面IDと遷移形態指定情報に基づいて遷移先の画面（次画面）を決定し、この画面の識別情報と応答データをデータ貼付部２６に出力する（Ｓ１０１１）。

次に、データ貼付部２６は、応答データから項目ＩＤと項目データを抽出すると共に、項目ＩＤをキーとして次画面において該当する項目を探し、ＩＤの一致する項目に対して項目データを貼り付ける（Ｓ１０１２）。また、Ｓ１０１２と平行して、データ貼付部２６は、応答データを内部記憶領域２８へ格納する（Ｓ１０１３）。

次に、画面表示部２７は、データ貼付部２６から出力される次画面ＩＤおよび項目データに基づいて新たな業務画面を表示する（Ｓ１０１４）。

次に、データ抽出部２９は、業務画面における入力情報が応答データの表示要求か否かを判定する（Ｓ１０１５）。ここで、入力情報が格納されている応答データの表示要求と判定された場合には、内部記憶領域２８から応答データを取り出すと共に必要なデータを抽出し、業務画面に出力する（Ｓ１０１６）。これに対して、入力情報が応答データの表示要求ではないと判定された場合には、Ｓ１０１７へ進む。

Ｓ１０１７において、画面表示部２７は、業務画面における入力情報が画面表示の終了要求か否かを判定する。ここで、入力情報が画面表示の終了要求と判定された場合には、業務画面の表示を終了して一連の処理を終える。これに対して、画面表示の終了要求ではないと判定された場合には、Ｓ１００１へ戻り、終了要求が行われるまで上記の処理が繰り返される。

したがって、本実施形態に係るリッチクライアント型Ｗｅｂアプリケーションシステムは以下の効果を奏する。

（１）クライアントサイド６のModel（モデル）とController（コントローラ）をRIAFW内に隠蔽化することにより、クライアントサイド６の実装の均質化と業務アプリケーション開発者の開発負荷を低減できる。具体的には、RIAFWの開発者はクライアントサイド６およびサーバサイド７の通信コンポーネントを開発し、業務アプリケーションの開発者はRIAFWから提供されるクライアントサイド６のModel（モデル）機能やController（コントローラ）機能を利用して開発を行うこととなる。

（２）業務アプリケーション開発者は、クライアントサイド６のModel（モデル）とController（コントローラ）の開発において、クライアントサイド６のRIAFWに適合する各種の定義ファイルの作成のみを行えば良い。すなわち、業務アプリケーション開発者がRIA製品毎に異なった開発言語を習得する必要が無くなり、開発負荷を低減できる。定義ファイルがXML形式の場合には、例えば汎用の表計算ソフトウェアを使用することで容易に作成可能である。

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

本発明の一実施形態に係るリッチクライアント型Ｗｅｂアプリケーションシステムの全体構成例を示すブロック図。Ｗｅｂクライアント１、Ｗｅｂサーバ２、およびアプリケーションサーバ３に適用されるコンピュータの構成例を示す図。リッチクライアント型ＷｅｂアプリケーションシステムをMVCモデルで表した図。リッチクライアント型Ｗｅｂアプリケーションシステムを構成するモジュールの相関図。画面項目定義ファイルの具体例を示す図。通信項目定義ファイルの具体例を示す図。業務ロジック制御ファイルの具体例を示す図。画面遷移定義ファイルの具体例を示す図。本発明の一実施形態に係るリッチクライアント型Ｗｅｂアプリケーションシステムの構築手順の具体例を示すフローチャート。本発明の一実施形態に係るリッチクライアント型Ｗｅｂアプリケーションシステムにおける処理の具体例を示すフローチャート。

符号の説明

１…Ｗｅｂクライアント、
２…Ｗｅｂサーバ、
３…アプリケーションサーバ、
４…データベースサーバ、
５…ネットワーク、
６…クライアントサイド、
７…サーバサイド、
１１…ＣＰＵ、
１２…ＲＯＭ、
１３…ＲＡＭ、
１４…インターフェース、
１５…システムバス、
１６…入力装置、
１７…表示装置、
１８…補助記憶装置、
１９…通信装置、
２１…通信制御部、
２２…チェック処理部、
２３…要求データ送信部、
２４…応答データ受信部、
２５…次画面遷移部、
２６…データ貼付部、
２７…画面表示部、
２８…内部記憶領域、
２９…データ抽出部、
３１…要求データ受信部、
３２…DMC、
３３…制御部、
３４…業務ロジック呼出部、
３５…業務ロジック、
３６…データベース、
３７…応答データ送信部。

Claims

業務画面を表示するクライアントと、
このクライアントにネットワークを介して接続され、前記業務画面から入力された要求データに基づいて業務ロジック処理を実行し、その実行結果を応答データとして前記クライアントへ送信するサーバと、からなり、
前記クライアントが、
前記業務画面に係る項目毎に、少なくとも入力桁数、入力タイプ、および表示属性を予め定義した画面項目定義ファイルに基づいて前記項目の入力データのチェック処理を実行するチェック処理部と、
前記チェック処理後の入力データを含む前記要求データを前記サーバに送信する要求データ送信部と、
前記送信された要求データに対して前記サーバから送信される前記応答データを受信する応答データ受信部と、
前記受信された応答データに含まれる遷移形態指定情報に基づいて前記業務画面からの遷移先となる画面を決定する次画面遷移部と、
前記応答データに含まれる項目識別情報に基づいて前記遷移先となる画面に係る項目を探索し、前記項目識別情報が一致する項目に前記応答データを貼り付けるデータ貼付部と、
前記応答データ受信部で受信された前記応答データを内部記憶領域へ保持するデータ保持部と、
前記業務画面からの表示要求に基づいて前記内部記憶領域から前記応答データを抽出するデータ抽出部と、
を備えることを特徴とするリッチクライアント型Ｗｅｂアプリケーションシステム。
前記要求データ送信部は、前記クライアントと前記サーバの間の通信対象項目を予め定義した通信項目定義ファイルに基づいて前記要求データを前記サーバへ送信し、かつ、
前記サーバが、
前記クライアントから送信された前記要求データを受信する要求データ受信部と、
前記要求データと前記業務ロジック処理の実行条件との関係を予め定義した業務ロジック制御ファイルに基づいて前記業務ロジック処理を呼び出し、前記受信された要求データに対する処理を行わせる業務ロジック呼出部と、
前記要求データおよび前記業務ロジック処理の実行結果に応じた画面遷移指定情報を予め定義した画面遷移定義ファイルに基づいて前記実行結果から前記応答データを作成し、前記クライアントへ送信する応答データ送信部と、
を有することを特徴とする請求項１記載のリッチクライアント型Ｗｅｂアプリケーションシステム。
業務画面を表示するクライアントと、
このクライアントにネットワークを介して接続され、前記業務画面から入力された要求データに基づいて業務ロジック処理を実行し、その実行結果を応答データとして前記クライアントへ送信するサーバと、
からなるリッチクライアント型Ｗｅｂアプリケーションシステムの構築用フレームワークであって、
前記クライアントに、
前記業務画面に係る項目毎に、少なくとも入力桁数、入力タイプ、および表示属性を予め定義した画面項目定義ファイルに基づいて前記項目の入力データのチェック処理を実行するチェック処理部と、
前記チェック処理後の入力データを含む前記要求データを前記サーバに送信する要求データ送信部と、
前記送信された要求データに対して前記サーバから送信される前記応答データを受信する応答データ受信部と、
前記受信された応答データに含まれる遷移形態指定情報に基づいて前記業務画面からの遷移先となる画面を決定する次画面遷移部と、
前記応答データに含まれる項目識別情報に基づいて前記遷移先となる画面に係る項目を探索し、前記項目識別情報が一致する項目に前記応答データを貼り付けると共に、前記応答データを内部記憶領域へ保持するデータ貼付部と、
前記業務画面からの表示要求に基づいて前記内部記憶領域から前記応答データを抽出するデータ抽出部と、
を実装することを特徴とするリッチクライアント型Ｗｅｂアプリケーションシステムの構築用フレームワーク。
前記要求データ送信部は、前記クライアントと前記サーバの間の通信対象項目を予め定義した通信項目定義ファイルに基づいて前記要求データを前記サーバへ送信し、かつ、
前記サーバに、
前記クライアントから送信された前記要求データを受信する要求データ受信部と、
前記要求データと前記業務ロジック処理の実行条件との関係を予め定義した業務ロジック制御ファイルに基づいて前記業務ロジック処理を呼び出し、前記受信された要求データに対する処理を行わせる業務ロジック呼出部と、
前記要求データおよび前記業務ロジック処理の実行結果に応じた画面遷移指定情報を予め定義した画面遷移定義ファイルに基づいて前記実行結果から前記応答データを作成し、前記クライアントへ送信する応答データ送信部と、
を実装することを特徴とする請求項３記載のリッチクライアント型Ｗｅｂアプリケーションシステムの構築用フレームワーク。
業務画面を表示するクライアントと、このクライアントにネットワークを介して接続され、前記業務画面から入力された要求データに基づいて前記業務ロジック処理を実行し、その実行結果を応答データとして前記クライアントへ送信するサーバと、からなるリッチクライアント型Ｗｅｂアプリケーションシステムの構築方法であって、
前記クライアントが、前記業務画面に係る項目毎に、少なくとも入力桁数、入力タイプ、および表示属性を予め定義した画面項目定義ファイルに基づいて前記項目の入力データのチェック処理を実行するチェック処理ステップと、
前記クライアントが、前記チェック処理後の入力データを含む前記要求データを前記サーバに送信する要求データ送信ステップと、
前記クライアントが、前記送信された要求データに対して前記サーバから送信される前記応答データを受信する応答データ受信ステップと、
前記クライアントが、前記受信された応答データに含まれる遷移形態指定情報に基づいて前記業務画面からの遷移先となる画面を決定する次画面遷移ステップと、
前記クライアントが、前記応答データに含まれる項目識別情報に基づいて前記遷移先となる画面に係る項目を探索し、前記項目識別情報が一致する項目に前記応答データを貼り付けるデータ貼付ステップと、
前記クライアントが、前記応答データ受信ステップで受信された前記応答データを内部記憶領域へ保持するデータ保持ステップと、
前記クライアントが、前記業務画面からの表示要求に基づいて前記内部記憶領域から前記応答データを抽出するデータ抽出ステップと、
有することを特徴とするリッチクライアント型Ｗｅｂアプリケーションシステムの構築方法。