JP2007133893A - Ｗｅｂアプリケーション生成装置及び方法 - Google Patents

Abstract

【課題】 Ｗｅｂアプリケーションを実行するアプリケーションサーバを開発する際に、データ、ロジック、画面の各モジュールに分けて記述するフレームワークを提供する。
【解決手段】 Ｗｅｂページの入力内容２０１をデータオブジェクト２０３に変換する入力内容変換手段２０６と、データオブジェクト２０３の種類とコマンドの組合せを各処理ルーチンにマッピングする第１の外部定義ファイル２０７と、処理ルーチンを複数備える処理ロジック２０５と、データオブジェクト２０３の種類とコマンドと第１の外部定義ファイル２０７に基づいて処理ロジック２０５から適当な処理ルーチンを決定する処理ルーチン決定手段２０６と、処理ロジック２０５の処理結果とデータオブジェクト２０４の種類の組合せを表示用コンポーネント２０２にマッピングする第２の外部定義ファイル２０７と、を備える。
【選択図】 図２

Description

本発明は、企業の基幹業務などを処理するビジネスアプリケーションソフトウェアの開発効率と保守性を向上させる技術に関する。

企業業務におけるデータエントリシステム、ワークフローシステムなどのビジネスアプリケーションでは、図４７に示すように、データベースサーバ５４０２の管理するデータを、クライアント５４０３からアプリケーションサーバ５４０１を介して操作する、という方式がとられてきた。近年、このようなビジネスアプリケーションはＷｅｂアプリケーションとして実現されるようになった。

そして、Ｗｅｂブラウザを制御する役割を果たすアプリケーションサーバ５４０１の開発には、従来より様々な試みがなされてきている。代表的なものとしてＳｅｒｖｌｅｔ（サーブレット）、ＪＳＰ（Ｊａｖａ（登録商標） Ｓｅｒｖｅｒ Ｐａｇｅｓ）を用いたアプリケーションサーバ５４０１がある。

Ｓｅｒｖｌｅｔを用いたアプリケーションサーバ５４０１は、図４８に示すように、画面表示を規定するＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）５５０１、画面データ５５０２、ロジック５５０３（画面の入力のハンドリング、入力データのチェック、データの加工、データベースサーバ５４０２へのデータの伝達などを行う）を一つのモジュールとして記述して実現される。

また、ＪＳＰを用いたアプリケーションサーバ５４０１は、図４９に示すように、Ｊａｖａ Ｂｅａｎ（Ｊａｖａ、Ｊａｖａ Ｂｅａｎｓは、サンマイクロシステムズ・インコーポレーテッドの登録商標）というオブジェクトに格納された画面データ５６０２とＨＴＭＬ５６０１とロジック５６０３から成るモジュールとして記述するか、あるいは、ＨＴＭＬ５６０１’からなるモジュールと、画面データ５６０２’とロジック５６０３’をＪａｖａ Ｂｅａｎオブジェクトに格納するように記述して実現される。

一般にビジネスアプリケーションでは扱うデータが多量となるため、アプリケーションサーバ５４０１は、データ（画面データ）、ロジック、画面（ＨＴＭＬ等）を各モジュールに分けて記述して実現し、それぞれのモジュールを再利用したいという要求がある。しかしながら、図４８や図４９に示したように、ＳｅｒｖｌｅｔやＪＳＰ等の従来技術を用いたアプリケーションサーバ５４０１では、これらのモジュールの分離が困難であった。

そこで本発明の課題は、Ｗｅｂアプリケーションを実行するアプリケーションサーバを開発する際にデータ、ロジック、画面の各モジュールに分けて記述するフレームワークを提供することにより、Ｗｅｂアプリケーションの開発効率と保守性を向上することにある。

上述した課題を解決するために、本発明ではＷｅｂアプリケーションをカスタムタグ付きＨＴＭＬ、データオブジェクト、ロジックに分け、カスタムタグ付きＨＴＭＬとロジックの間をマッピングファイルによってマッピングし、両者間のデータのやり取りにデータオブジェクトを用いるようにした。

本発明の一態様によれば、Ｗｅｂページの入力内容をデータオブジェクトに変換する入力内容変換手段と、複数の処理ルーチンを備える処理ロジックと、前記データオブジェクトの種類とコマンドの組合せを前記各処理ルーチンにマッピングする第１の外部定義ファイルと、前記データオブジェクトの種類とコマンドと前記第１の外部定義ファイルに基づいて前記処理ロジックの備える処理ルーチンから適当な処理ルーチンを決定する処理ルーチン決定手段と、前記処理ロジックの処理結果とデータオブジェクトの種類の組み合わせを表示用コンポーネントにマッピングする第２の外部定義ファイルと、を備える。

また、本発明の別の一態様によれば、クライアントに提供するデータを有し、且つ該データのデータ構造を表すインタフェースを実装するデータオブジェクトを取得する手段と、前記データオブジェクトが有するデータについてのＷｅｂページ画面における表示方法をＨＴＭＬによる記述によって定義する定義文を取得する手段と、前記データオブジェクトに実装されている前記インタフェースに基づいて該データオブジェクトの有するデータと前記定義文とを関連付けることによって、該データが表示されるＷｅｂページ画面を表現するＨＴＭＬ文を生成する手段と、を備える。

また、本発明の更なる別の一態様によれば、処理の内容が定義されている処理ロジックであって、予め用意されている該処理ロジックの名称となる文字列を生成する手段と、前記文字列を用いて前記処理ロジックを呼び出すＨＴＭＬ文であって、前記処理ロジックについての実行条件であって予め用意されている該実行条件に合致するイベントがクライアントで発生したときに該処理ロジックを呼び出して実行する、という処理を該クライアントに行なわせる該ＨＴＭＬ文を生成する手段と、を備える。

このような構成をとることにより、Ｗｅｂアプリケーションシステムにおいて画面表示を規定するＨＴＭＬ、データオブジェクト、及び処理の内容を規定するロジックの連携がそれぞれ疎となることになり、各モジュールの再利用性が向上し、開発効率と保守性を上げることができる。

本発明によれば、Ｗｅｂアプリケーションシステムにおいて画面表示を規定するＨＴＭＬ、データオブジェクト、処理の内容を規定するロジックの連携が疎となることになり、各モジュールの再利用性を向上させ、開発効率と保守性を上げることができる。また、サーバにおける処理を時間的スコープの大きなものから小さなものに分岐して処理を進めることにより、スレッドセーフを実現したり、各スコープにおける処理に前処理、後処理を追加し、処理の前判断やエラー処理を柔軟に行えるという効果を得ることができる。

以下、本発明の実施の形態を図面を参照しながら説明する。
図１は、本発明の概略を示す図である。本発明を実施するＵＪＩ（宇治）なるアプリケーションサーバは、図示するように、画面表示を規定するＨＴＭＬ１０１、画面データ１０２、ロジック１０３の３つのモジュールから構成される。尚、ＨＴＭＬ１０１は画面表示を規定できるものなら何れのものでも良い。

図２は、本発明の原理構成を示す図である。図１のＨＴＭＬ１０１に対応するものが入力用ＪＳＰ２０１及び表示用ＪＳＰ２０２であり、図１の画面データ１０２に対応するものが入力用Ｊａｖａ Ｂｅａｎ２０３及び表示用Ｊａｖａ Ｂｅａｎ２０４、図１のロジック１０３に対応するのがユーザロジック２０５である。入力用ＪＳＰ２０１は画面をデータにアサインする機能を備え、表示用ＪＳＰ２０２はデータを画面に表示する機能を備
える。ＵＪＩエンジン２０６は、入力用ＪＳＰ２０１の画面データを例えばＪａｖａ Ｂｅａｎなどのデータオブジェクトに変換する（（１）、（５）、（６））。すなわち、入力用ＪＳＰ２０１の画面データは入力用Ｊａｖａ Ｂｅａｎ２０３に変換される。ユーザロジック２０５は複数の処理ルーチンから構成されており、ＵＪＩエンジン２０６がデータオブジェクト（入力用Ｊａｖａ Ｂｅａｎ２０３）の種類及びコマンドと外部のマッピングファイル２０７とに基づいて、適当な処理ルーチンを決定する（（５）、（６）、（７））。ユーザロジック２０５では、決定された処理ルーチンを用いてデータオブジェクトである入力用Ｊａｖａ Ｂｅａｎ２０３を処理し（２）、表示用Ｊａｖａ Ｂｅａｎ２０４として出力する（（３））。表示用Ｊａｖａ Ｂｅａｎ２０４はＵＪＩエンジン２０６によって表示用ＪＳＰ２０２の画面データに変換され（（４）、（５）、（６））、また処理結果とデータオブジェクトである表示用Ｊａｖａ Ｂｅａｎの種類の組み合わせを外部のマッピングファイル２０７から探し出し、表示すべき部品を決定する。このように、本発明はデータオブジェクトが画面を規定するＨＴＭＬとロジックとの間に介在するような構成をとるので、画面とロジックとを疎に連結することを可能とする。

図３は、本発明の第１の実施例のシステム構成を示す図である。クライアントからのリクエスト３０１はフロントコンポーネント３０２で受信される。そして、リクエスト３０１に含まれるリクエストデータはＵＪＩエンジン３０４で自動解析され、データオブジェクトである入力用Ｊａｖａ Ｂｅａｎ３０３が自動生成される。ＵＪＩエンジン３０４では、更に、コマンドマッピング３０５を参照し、リクエストデータから生成されたデータオブジェクトの種類とコマンドとからユーザロジック３０７での処理を決定する。ユーザロジック３０７では、生成されたデータオブジェクトを読み込み、該決定に従って処理を行い、処理結果として表示用Ｊａｖａ Ｂｅａｎ３０９を設定する。ここで、ＵＪＩエンジン３０４はページマッピング３０６を参照し、表示用Ｊａｖａ Ｂｅａｎ３０９から表示用ＪＳＰ３１０、すなわち画面表現が決定される。尚、表示用ＪＳＰ３１０にはページレイアウトを規定するテンプレート３０８がインクルードされ、このテンプレート３０８に従って表示部品が配置されるようになっている。

図３では本発明の第１の実施例のシステム構成を示しその動作概要を述べたが、図４を用いて、本発明の第１の実施例のシステムの具体的な動作を説明する。図４は、ユーザが何処にいるかを示す「行き先掲示板」というＷｅｂアプリケーションの様子を示したものである。ユーザを一覧表示するユーザ一覧表示画面４０１、ユーザの状態を編集するユーザ状態編集画面４０２、ユーザの行き先候補を編集するプロファイル編集画面４０３、新規ユーザを登録するユーザ登録画面４０４はそれぞれ、クライアントでＷｅｂブラウザによって表示されるものである。ユーザ一覧表示画面４０１において、ログインボタン４０５が押し下げられる（クリックされる）とユーザ状態編集画面４０２に遷移する。ユーザ一覧表示画面４０１で、ユーザ登録ボタン４０６が押し下げられるとユーザ登録画面４０４に遷移する。同様に、各画面４０２〜４０４の各ボタンが押し下げられると、対応する図４に示した矢印のように画面が遷移する。このとき、ログイン４０５、ユーザ登録ボタン４０６、変更ボタン４０７、ログアウトボタン４０８等の画面の各ボタンはユーザがシステムに対して処理を要求するためのコマンドに相当する。

また、例えばユーザ「松塚」がユーザ状態として表示できる「自席」、「出張」、「年次」という３状態の他に「会議室」という状態を追加したい場合には、ユーザ状態編集画面４０２において、プロファイル編集ボタン４０９を押し下げる。すると画面表示はプロファイル編集画面４０３に遷移する。ここで、ユーザ「松塚」が「追加」の欄に例えば「会議室」と入力し、変更ボタン４１０を押し下げると新たな状態が加えられたプロファイル編集画面が表示される。

以下、図５及び図６で、図４のアプリケーションのシステム構成とその動作概要を説明
する。
図５は、クライアントからのリクエストが受信されてから、処理が完了するまでの動作概要を示すものである。Ｗｅｂブラウザに表示される、ユーザ一覧表示画面５０１、ユーザ状態編集画面５０２、プロファイル編集画面５０３、ユーザ登録画面５０４は、それぞれ図４の画面に対応している。それぞれの画面から、ログイン、ユーザ登録、プロファイル編集、ログアウト、変更、ユーザ追加、キャンセル等のコマンドがＵＪＩ５０６に伝達される（実線矢印）と、それぞれの画面データがデータオブジェクトであるＪａｖａ Ｂｅａｎ５０５に自動的に変換される（点線矢印）。また、ＵＪＩ５０６は、コマンドマッピング５０７（後述）を参照し、伝達されたコマンドとデータオブジェクトの種類との組み合わせに基づいて分岐すべき処理を処理５０８〜５１２の中から選択する。そして選択された処理にデータオブジェクトを渡す。データオブジェクトが渡されると、選択された処理の内容に沿って、そのデータオブジェクトが処理される。

図６は、データオブジェクトの処理が終わり、クライアントへレスポンスが返されるまでの動作概要を示すものである。処理が終わり、処理結果としてのＪａｖａ Ｂｅａｎ６０１が作成される。そして、ＵＪＩ５０６において、ページマッピング６０２（後述）が参照され、処理結果（成功、失敗、完了等）と作成されたＪａｖａ Ｂｅａｎ６０１との組み合わせから表示すべきページがページ５０１〜５０４の中から決定される。表示すべきページには作成されたＪａｖａ Ｂｅａｎ６０１が渡され、それをもとに新たなページが表示される。

図７（а）、（ｂ）にコマンドマッピングの一部、図７（ｃ）にページマッピングの一部を示す。コマンドマッピングは入力データオブジェクトの種類、コマンド、処理から成るテーブルで構成される。また、ページマッピングは出力データオブジェクトの種類、処理結果、画面から成るテーブルで構成される。

図７（а）、（ｂ）に示すように、コマンドマッピングによって、入力データオブジェクトの種類とコマンドとの組み合わせから分岐すべき処理が決定される。図７（а）は入力データオブジェクトの種類が同一で、コマンドの種類が異なる場合のコマンドマッピングを示したものである。図７（а）より、入力データオブジェクトの種類が「ユーザ状態」で、コマンドが「プロファイル編集」の場合、プロファイル変更処理に処理を分岐させることが決定されることがわかる。また、図７（ｂ）は、入力データオブジェクトの種類が異なり、コマンドが同一な場合のコマンドマッピングを示したものである。図４に示したように「変更」コマンドは様々な画面で用いられる。しかし、コマンドが同一であっても、コマンドが発生したときに分岐すべき処理はそれぞれ異なる。図４のユーザ状態編集画面４０２において「変更」コマンドが発生した場合は、ユーザ状態変更処理に処理を分岐させなければならず、プロファイル編集画面４０３において「変更」コマンドが発生した場合はプロファイル変更処理に処理を分岐させなければならない。図７（ｂ）に示すコマンドマッピングでは、入力データオブジェクトの種類が「ユーザ状態」で「変更」コマンドが発生するとユーザ状態変更処理に処理を分岐させ、入力データオブジェクトの種類が「プロファイル編集」で「変更」コマンドが発生したときにはプロファイル編集処理に分岐させるように規定することができる。このように、本発明のコマンドマッピングは入力データオブジェクトの種類とコマンドの組み合わせから分岐すべき処理を決定するため、コマンドが同一であっても、入力データオブジェクトの種類から分岐すべき処理を適切に選択することができる。

また、図７（ｃ）に示すページマッピングによって、出力データオブジェクトの種類と処理結果との組み合わせから、表示すべき画面が決定される。ページマッピングにおいてもコマンドマッピングと同様に、出力データオブジェクトの種類と処理結果との組み合わ
せで画面が決定されるため、処理結果が同一であっても、出力データオブジェクトの種類から表示すべき画面を適切に選択することが可能である。

尚、コマンドマッピング、ページマッピングは、外部定義ファイルで、開発者が自由に設定できるものである。これにより開発における柔軟性を高めることができる。
以上、本発明の第１の実施例のシステム全体の動作を説明したが、次に、各動作間についてより具体的に説明する。

図８は、クライアントからのリクエストデータを入力用Ｊａｖａ Ｂｅａｎに変換させる（図３の３０１、３０３間）ためのプログラム記述を示す図である。この記述により、データ入力用ＨＴＭＬページ８０１にデータが入力されると、データ入力用ＨＴＭＬページ８０１の特定項目（LoginBean ）に対応したクラス名（図８の（１））であって、各入力欄の名前（name）をプロパティ（図８の（２）、（２）’）として持つデータオブジェクト入力用Ｊａｖａ Ｂｅａｎ８０２が生成される。

図９は、実行すべきロジックの処理をコマンドマッピングを用いて決定する（図３の３０５、３０７間）部分のプログラム記述を示す図である。コマンドマッピング９０２には、データ入力用ＨＴＭＬページ９０１の特定項目に対応したクラス名（LoginBean ）と、押し下げられたボタン（submit）の名前（name）の組み合わせが、ユーザロジック９０３（ハンドラ）のメソッドにマッピングされている。これにより、例えばデータ入力用ＨＴＭＬページ９０１でログインボタンが押し下げられると、ユーザロジック９０３のlogin メソッドが実行されることになる（図９の（１））。同様に、データ入力用ＨＴＭＬページ９０１でパスワード変更ボタンが押し下げられると、ユーザロジック９０３のchangePasswordメソッドが実行されることになる（図９の（２））。

図１０は、ユーザロジックが表示用データオブジェクトを設定する（図３の３０７、３０９間）部分のプログラム記述を示す図である。ユーザロジック（ハンドラ）１００１は、データベース１００２などを使用して処理を行い、処理の結果として表示が必要である値と処理結果とを表示用データオブジェクト（Ｊａｖａ Ｂｅａｎ）１００３に設定する。

図１１は、ページマッピングを介して表示すべきページを決定する（図３の３０９、３１０間）部分のプログラム記述を示す図である。ページマッピング１１０２では、クラス名（UserBean）とユーザロジック（ハンドラ）で設定される処理結果の組み合わせが表示すべきビュー（この場合ＪＳＰ）にマッピングされている。これにより、表示用Ｊａｖａ
Ｂｅａｎ１１０１に設定された処理結果が例えばsucceeded の場合、login-succeeded.jsp １１０３が選択され（図１１の（１））、これと図３のテンプレート３０８とが合わされて表示画面が決定される。同様に、表示用Ｊａｖａ Ｂｅａｎ１１０１に設定された処理結果がfailedの場合、login-failed.jsp１１０４が選択され（図１１の（２））、これと図３のテンプレート３０８とが合わされて表示画面が決定される。

図１２は、ＪＳＰから表示画面を出力する（図３の３１０）部分のプログラム記述を示す図である。表示用ＪＳＰ１２０１は、データ取得用のタグを使用して表示用Ｊａｖａ Ｂｅａｎ１２０２からデータを取得し、取得されたデータを出力ＨＴＭＬ１２０３として出力する。

図１３は、表示画面に複数の表示部品を配置する場合のテンプレート（図３の３０８、３１０間）について説明する図である。ユーザロジック（ハンドラ）１３０１は、同時に複数の表示用Ｊａｖａ Ｂｅａｎを設定するようにすることができる。例えば、図１３の
ようにバナー用のＪａｖａ Ｂｅａｎ１３０２、メニュー用のＪａｖａ Ｂｅａｎ１３０３、コンテンツ用のＪａｖａ Ｂｅａｎ１３０４がユーザロジック１３０１で設定されると、それぞれのＪａｖａ Ｂｅａｎに対応するＪＳＰがそれぞれのＪａｖａ Ｂｅａｎからデータを取得してそれぞれの表示画面を作成する。テンプレート１３０５にはＪＳＰごとに表示位置が規定されているため、作成された各表示画面がテンプレート１３０５に基づいて配置され、出力ＨＴＭＬ１３０６が出力される。

上述のように、本発明第１の実施例のシステムではＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）リクエストをデータオブジェクトに変換して処理し、処理結果のデータオブジェクトをレスポンスに変換してクライアントに返す仕組みについて詳細に述べた。次に、同一の仕組みを利用して、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）ファイルを処理する本発明の第２の実施例のシステムについて述べる。図１４、１５にそのシステム構成を示す。

図１４は、アプリケーションサーバがＸＭＬファイルを受信したときにそのＸＭＬファイルがロジック（ハンドラ）で処理されるまでを示す図であり、図１５はロジック（ハンドラ）でそのＸＭＬファイルの処理が終わり、クライアントへレスポンスが返されるまでを示す図である。

まず、図１４において、サーバがＸＭＬインスタンス１４０１を受信すると、そのＸＭＬをＸＭＬ Ｄａｔａ Ｂｉｎｄｉｎｇエンジン１４０４で処理を行ってデータオブジェクト（Ｂｅａｎインスタンス１４０５）を作成する。この際、受け取ったＸＭＬインスタンス１４０１からオブジェクトの種類を特定することができるため、種類の異なるＸＭＬを同一エンジンで受け取ることができる。ここでは、オブジェクトの種類は、ＸＭＬマッピングファイル（不図示、後述）を利用して特定される。また、ＵＪＩエンジン１４０３は、コマンドマッピング１４０２を参照することによって、ＸＭＬのタグからロジック（ハンドラ）で実行すべき処理（メソッド）を決定する。

図１５において、ロジック（ハンドラ）１５０１では、ＨＴＴＰリクエストのときと全く同様にして送信用のデータオブジェクト（Ｂｅａｎインスタンス１５０２）が作成される。これが再び、ＸＭＬ Ｄａｔａ Ｂｉｎｄｉｎｇエンジン１４０４でＸＭＬに変換されて送信用ＸＭＬ１５０３が出力される。

尚、データオブジェクトを生成するＸＭＬ Ｄａｔａ Ｂｉｎｄｉｎｇエンジン１４０４は、ファクトリクラスから呼び出される。そのため、ファクトリクラスをＢｉｎｄｉｎｇエンジンの種類毎に用意することで、柔軟に複数のＢｉｎｄｉｎｇエンジンに対応することができる。

図１６及び図１７は図１４及び図１５に示したシステムの動作概要を示すものである。図１６は、図１４に対応し、アプリケーションサーバがＸＭＬファイルを受信してからロジック（ハンドラ）で処理されるまでを示した図であり、図１７は図１５に対応し、ロジックで処理が終了してから、クライアントへレスポンスを返すまでを示した図である。

図１６において、注文伝票１６０１、出荷伝票１６０２等のＸＭＬファイルがアプリケーションサーバに対して送信される（実線矢印）と、それぞれの画面データがデータオブジェクトであるＪａｖａ Ｂｅａｎ１６０５に自動的に変換される（点線矢印）。また、ＵＪＩ１６０３において、ＸＭＬマップファイル１６０６を利用してＸＭＬインスタンスのオブジェクトの種類が特定され、ＸＭＬ Ｄａｔａ Ｂｉｎｄｉｎｇエンジン１６０４で受信したＸＭＬに対応するデータオブジェクトが作成される。またＵＪＩ１６０３で、ＸＭＬのタグとコマンドマッピング１６０７から、分岐すべき処理を処理１６０８、１６
０９、１６１０等の中から選択する。そして、選択された処理にデータオブジェクトを渡す。データオブジェクトが渡されると、選択された処理の内容に沿ってそのデータオブジェクトが処理される。

処理が終わると、図１７において、処理結果であるＪａｖａ Ｂｅａｎ１７０１がＵＪＩ１６０３に渡される。このＪａｖａ Ｂｅａｎ１７０１は、ＸＭＬ Ｄａｔａ Ｂｉｎｄｉｎｇエンジン１６０４で送信用ＸＭＬインスタンス１７０２に変換される。

このように第２の実施例のシステムでは受信したＸＭＬをＸＭＬ Ｄａｔａ Ｂｉｎｄｉｎｇエンジンでデータオブジェクトに変換してからロジック（ハンドラ）に渡すので、ＨＴＴＰリクエストの時と同じ処理を実現する場合、第１の実施例のシステムのロジック（ハンドラ）と同一のロジック（ハンドラ）のメソッドをそのまま利用することができる。

以上、本発明の第１及び第２の実施例のシステム構成、システム動作について詳細に説明したが、次にこれらの実施例に共通するシステムの動作の仕組みについて説明する。
本発明のシステムを構成するオブジェクトは、各々が処理されるときの時間軸上における相対的な位置関係に基づいてシステム、アプリケーション、セッション、リクエストの４段階の時間的スコープに分類することができる。図１８（а）に示すように、システム１８０１は、システム全体で一つ存在するもので、アプリケーションサーバの起動からサーバの終了までをそのスコープとする。また、アプリケーション１８０２は、システム内の各アプリケーション毎に１つ存在し、アプリケーションの開始から終了までをそのスコープとする。セッション１８０３は、クライアント毎に一つずつ存在するもので、クライアントの接続から切断（またはタイムアウトなど）までをそのスコープとする。そして、リクエスト１８０４は、あるクライアントからの一回のリクエストにつき一つ存在するもので、クライアントからのリクエストを処理してレスポンスを返すまでをスコープとする。図１８（ｂ）に、各オブジェクト間の相関関係を示す。システム１８０１内に複数のアプリケーション１８０２が存在し、各アプリケーション１８０２に接続する複数のクライアントからのセッション１８０３が存在する。そして、クライアントからのリクエストは、予め用意されるハンドラ１８０５で処理される。尚、図１８ （ａ）に示すリクエスト１８０４は、図１８（ｂ）の各オブジェクトが実行される際の１スレッドに対応する。

このようにシステムを構成するオブジェクトが段階的な時間的スコープを持つことによって、クライアントからのリクエストを処理する場合に、より大きなスコープを持つオブジェクトから小さなオブジェクトに分岐（dispatch）して処理を進めていくことができる。すなわち図１９に示すように、フロントコンポーネント１９０１にクライアントからリクエストが送信されてくると、システムに一つ存在するディスパッチャ１９０２が対応するアプリケーション１９０３に処理を分岐する。更にアプリケーション１９０３は、リクエストを送信してきたクライアントに対応するセッション１９０４に処理を分岐し、セッション１９０４は、リクエストに対応するハンドラ１９０５に処理を分岐する。

本発明のシステムでは、クライアントからのリクエストをより大きなスコープから小さなスコープに分岐して処理していくため、アプリケーション、セッション、ハンドラの各オブジェクトをユーザ拡張可能またはユーザ定義可能としておくと次のような効果が得られる。（尚、本実施例のシステムでは、アプリケーション１９０３とセッション１９０４をユーザ拡張可能、フロントコンポーネント１９０１、表示用ページ１９０６、ハンドラ１９０５、コマンドマップ１９０９、ページマップ１９１０、ＲｅｓｐｏｎｓｅＢｅａｎ１９０８及びＲｅｑｕｅｓｔＢｅａｎ１９１１をユーザ定義可能として実装した。）
ユーザ拡張可能またはユーザ定義可能なオブジェクトに対して、SingleThreadModel １
９１２というインタフェースを実装させると（図１９（ｂ））、そのオブジェクトの動作が同時に最大１スレッドまで制限される。この機能を利用すれば、それぞれのスコープの動作がスレッドセーフとなり、すなわち、例えば同一データ編集などのデータ処理は、同時に複数行わせないようにすることができる。このようにすることを「シングルスレッド動作制限」という。前述の「行き先掲示板」アプリケーション（図４）において、ユーザ変更とプロファイル編集は同一データを対象とするので、スレッドセーフにしておく必要がある。この場合、図２０（а）に示すように実装すればよい。すなわち、メソッド：ユーザ変更２００７、メソッド：プロファイル編集２００８を含むハンドラ２００４にSingleThreadModel インタフェースを実装させる。ここで、メソッド：ログイン処理２００５、メソッド：ログアウト処理２００６、メソッド：ユーザ登録、は特にスレッドセーフにしなくてよいため、ハンドラ２００４’、２００４’’にはSingleThreadModel インタフェースは実装させない。同様に、セッション、アプリケーションにおいても、スレッドセーフにしたい場合、SingleThreadModel インタフェースを実装させればよい（２００２’、２００３’）。SingleThreadModel インタフェースを実装する場合の記述の仕方は、図２０（ｂ）のようにすればよく、同図には、セッション２００３’にSingleThreadModel インタフェースが実装された場合が示されている。

また、ユーザ拡張可能またはユーザ定義可能なオブジェクトである、アプリケーション、セッション、ハンドラオブジェクトに前処理（preprocessor）、後処理（postprocessor ）インタフェースを実装させることができる。これにより、各オブジェクトの本番処理の実行の前後に処理を付け加えることができる。すなわち、図２１のシーケンス図に示すように、クライアントのリクエストの本番処理（ハンドラメソッド）（図２１の（２））の前処理（図２１の（１））、後処理（図２１の（３））を加えることができ、同様に、セッション（図２１の（５））に対する前処理（図２１の（４））、後処理（図２１の（６））、アプリケーション（図２１の（８））に対する前処理（図２１の（７））、後処理（図２１の（９））を追加することができる。

この機能を利用して、例えば前処理（図２１の（１））では、ロジックのハンドラメソッドの本番処理（図２１の（２））の前に予め状態管理による判断を行ってハンドラメソッドの処理をスキップするチェックルーチンを設けるようにすることが可能である。また、後処理（図２１の（３））では、前処理（図２１の（１））または本番処理（図２１の（２））でエラーが出たときにそのエラーを回復させるためのエラーハンドリングを設けておくことができる。これらは、エラーが出なかったときでも、共通の後処理を記述するために利用することもできる。同様に、各セッションについて、１クライアントに対する共通の前処理、後処理を記述することができ、アプリケーションでは複数クライアントに対する共通の前処理、後処理を記述することができる。各前処理、後処理はそれぞれのスコープのオブジェクトに別々に実装することができるため、きめ細かい制御ができる。

以上のように、本発明のシステムの動作の仕組みを用いれば、スレッドセーフを実現させたり、各スコープにおける処理に前処理、後処理を追加することで処理の前判断やエラー処理が柔軟に行なえるようになるという効果を得ることができる。

次に、本発明のアプリケーションサーバにおけるロジックのハンドラからブラウザにリクエストを行うための仕組みについて説明する。
Ｗｅｂアプリケーションでは、例えば、処理Ａのリクエストがクライアントから送られてきたが、何らかのことが起こったために、処理Ａを続行するか否かをユーザ（クライアント）に問い合わせ、その回答に基づいて処理Ａを続行するか若しくは異なる処理を行うようにするという場合がある。このように、処理の途中でユーザ（クライアント）に問い合わせが行なわれ、この問い合わせの結果に基づいて処理を行っていく場合、一般のＷｅ
ｂアプリケーションシステムでは、図２２（а）に示すようなシーケンスで行っている。処理Ａのリクエスト（図２２（а）の（１））がサーバに送信されると、サーバではそれを受信し、ハンドラ１が処理を始める。すると、処理Ａは全て終了していないが、ユーザに処理Ａを続行するかどうか質問する（図２２（а）の（２））。クライアントには、２７０１のような画面が表示され、ユーザが「はい」「いいえ」の何れかの回答を返す（図２２（а）の（３））。それに基づき、ハンドラ２が処理を始める。

このように、一般のＷｅｂアプリケーションでは、処理Ａが全て完了していなくてもハンドラの処理を中断しなくてはならない場合がある。また、ユーザの回答が「はい」、「いいえ」などの場合、何の質問に対する「はい」、「いいえ」なのかを規定した中間処理のためのマッピング定義が必要である。

そこで、本発明のシステムに、以下に述べるようなアプリケーションサーバにおけるロジックのハンドラからブラウザにリクエストを行う仕組みを導入し、一般のＷｅｂアプリケーションシステムを改善した。

図２３（а）に示すように、本発明のシステムでは、サーバにおいて、ハンドラ呼び出し前にスレッド緩衝オブジェクト（シンクロナイザ）を設け、ハンドラの動作を監視するようにする。これにより、処理Ａのリクエスト（図２３（а）の（１））がサーバに送信されると、サーバではシンクロナイザが受信し、ハンドラ１に渡され（図２３（а）の（２））、ハンドラ１が起動して処理が始まる。そこで、処理Ａが全て終了していないが、ユーザに処理Ａを続行するかどうか質問をする場合、ハンドラ１はクライアントにコールバックするメソッドを呼び出す（図２３（а）の（３））。シンクロナイザでは、ハンドラのメソッドを、ブラウザ（クライアント）への返り値として返す（図２３（а）の（４））。クライアントには、２２０１のような画面が表示され、ユーザが「はい」「いいえ」の何れかの回答を返す（図２３（а）の（５））。それがシンクロナイザに受信され、ハンドラ１に渡される（図２３（а）の（６））。この後、ハンドラ１は、処理を継続する。このように、スレッド緩衝オブジェクトが設けられることで、ハンドラの処理を中断させる必要がなくなる。また、サーバを実現するためのプログラムの記述においても、一般的なＷｅｂアプリケーションでは図２２（ｂ）に示すように、ハンドラ１、ハンドラ１の返り値に対するイベントを受けるハンドラ２などを記載しなくてはならないのに対し、本発明では図２３（ｂ）（ｃ）に示すように、一つのハンドラ内に条件分岐文で記述することができるため、プログラム記述的に非常に容易である。

なお、以上までに説明した本発明の実施例では、クライアントからの入力としてＨＴＴＰ、ＸＭＬ等を対象としたが、クライアントからリクエストであればどのようなものでもよく、また、これらの本発明の実施例では、クライアントのリクエストをＪａｖａ Ｂｅａｎというデータオブジェクトに変換したが、他のデータオブジェクトでもよい。

以上までに説明した実施例に係る発明は、クライアントからの入力をデータオブジェクトに変換し、それを処理し、処理結果として得られるデータオブジェクトをクライアントへのレスポンスに変換して送信することを特徴とするものであり、また、サーバにおける処理を時間的スコープに分類し、スコープの大きなものから小さなものに分岐して処理を進めることを特徴とするものである。

次に、本発明の更なる実施例について説明する。
これより説明する実施例は、Ｗｅｂアプリケーションを実行するアプリケーションサーバを開発する際に、画面の見かけの定義（ビュー）とその画面中に埋め込まれるデータとを分離して実装するようにして、Ｗｅｂアプリケーションの開発効率と保守性とを共に向
上させるものである。

この実施例では、Ｗｅｂアプリケーションにおける表示部を、表示データオブジェクトと、画面の見かけ（ビュー）の定義とに分けて用意する。このとき、表示データオブジェクトは、表示データ自体を有し、テーブル（表）構造や木構造などのデータ構造（本実施例ではこのデータ構造を「モデル」と称することとする）を表すインタフェースであってその表示データについてのものを実装した構造体クラスとして作成する。また、ビューの定義は、この実施例においてはＪＳＰ（Java Server Pages ）を用いて記述する（ビューの定義は、単にＨＴＭＬで記述するようにしてもよい）。

この表示データオブジェクトとビューの定義とがサーバにおいて実行されると、上述したインタフェースに対応する実行エンジンによって表示データを画面の所定位置に割り当てる（アサインする）ＨＴＭＬ文が生成される。その後、このＨＴＭＬ文がクライアントに送付されると、クライアントの備えるＷｅｂブラウザによって対応する画面表示が行なわれる。

なお、これより説明する上述した実施例を、既に説明した他の実施例と区別するために、「第３の実施例」と称することとする。
まず図２４について説明する。同図は、本発明の第３の実施例のシステム構成を示している。

モデルオブジェクト３００１は、サーバ側に設けられているデータベースなどのバックエンドから取得されるクライアントに表示すべきデータを保持し、また、クライアントから送付されたデータをバックエンドに渡すために保持するオブジェクトであり、後述するモデルインタフェース３００２を実装する。なお、モデルオブジェクト３００１は、表示用モデルオブジェクト３００１ａと入力用モデルオブジェクト３００１ｂとして別々に設けることも可能であり、また、表示用と入力用とを共用する単一のモデルオブジェクト３００１として設けることも可能である。

モデルインタフェース３００２は、特定のモデルの構造を表すインタフェースであり、例えば、テーブル構造についてはテーブルモデル用、木構造についてはツリーモデル用などというように、対象とするデータ構造に応じたインタフェースが用意される。

フレームワークエンジン３００３は、表示用モデルオブジェクト３００１ａに実装されているモデルインタフェース３００２に基づいて、表示用モデルオブジェクト３００１ａに保持されているデータを取り出し、表示用ＪＳＰ３００４の定義に従ってＨＴＭＬ文を生成する。また、ブラウザ３００５に対して入力されたデータを解析して入力用モデルオブジェクト３００１ｂに渡す。

表示用ＪＳＰ３００４は表示データをＨＴＭＬで表現するときの画面の見かけ（ビュー）が定義されているものであり、独自のタグを導入したＪＳＰで記述される。
ブラウザ３００５はクライアントに装備され、表示用ＪＳＰ３００４の定義に基づいてフレームワークエンジン３００３で生成されたＨＴＭＬに従った画面表示をで行なうものである。

フロントコンポーネント３００６は、ブラウザ３００５から発せられるリクエストを受け付けてフレームワークエンジン３００３に渡すものであり、例えばＪＳＰコンポーネントあるいはサーブレットなどを利用するが、ＨＴＴＰリクエストを受信し、その受信内容
に応じたフレームワークエンジン３００３を呼び出すことができるものであればどのようなものでもよい。

次に、図２４のモデルインタフェース３００２について、テーブル構造のモデルを表すテーブルモデルインタフェースを例に挙げて更に詳細に説明する。
図２５は、テーブルモデルインタフェースの宣言例を示す図である。この例では、大きく分けてデータ取得のためのメソッド、データクラスの取得のためのメソッド、及びデータの（バックエンドへの）代入のためのメソッドでテーブルモデルインタフェースが定義されている。

これらのメソッドについて更に説明すると、データ取得のためのメソッドとしてはテーブルの列数を取得するメソッド（getColumnCount）、テーブルの行数を取得するメソッド（getRowCount ）、及びテーブルの各セルのデータを取得するメソッド（getValueAt）が図２５の定義に用いられている。

データクラスの取得のためのメソッドとしては、列及び行の各々について定義される「クラス」を特定する文字列を各々取得するメソッド（getColumnClass及びgetRowClass ）が図２５の定義に用いられている。この「クラス」とは、各列若しくは各行に属するデータについての表示方法（例えば表示位置やフォントの大きさといった書式等）の様式をそれぞれ定義するために使用されるものであり、これは後述するレンダラタグの”cls” 属性を示すものである。

データの代入のためのメソッド（setValueAt）は、このテーブルモデルに対応するモデルアップデートの処理（後述）により呼び出されることによって、このテーブルモデルで示されるデータ構造に依存したデータ形式でクライアントからのリクエストの内容（セルの値及びそのセルのテーブル上の位置）がバックエンドに渡される。

次に、本発明の第３の実施例においてＨＴＭＬ文が生成される様子を、図２６を用いて説明する。同図は、図２４に示すテーブルモデル用のフレームワークエンジン３００３に図２５に示す宣言がなされているテーブルモデルインターフェースを実現する表示用のモデルオブジェクト３００１ａ（Ａ）を与えると、フレームワークエンジン３００３が、表示用ＪＳＰ３００４に相当するＪＳＰソース（Ｂ）に基づいて生成ＨＴＭＬ文（Ｃ）を生成することを示している。なお、説明の便宜のため、図２６（Ｂ）及び図２６（Ｃ）の各行頭には行番号を付している。

図２６の（Ｂ）ＪＳＰソースについて説明する。
図２６（Ｂ）において、第１行はこのＪＳＰソースとモデルオブジェクト（Ａ）との対応関係を指定するものである。

第１行を更に説明すると、“id=...”には対応するモデルオブジェクトがこのＪＳＰソース内において参照されるときの名称が指定され、“cls=... ”はこのＪＳＰソースと対応するモデルオブジェクトのクラス名が指定される。

また、第１行において、“request=... ”にはモデルオブジェクト（Ａ）のフレームワークエンジン３００３内での生存期間が指定される。これは、生成ＨＴＭＬ文（Ｃ）をクライアントに送付してブラウザ３００５に画面表示を行なわせた後に、このモデルオブジェクトに応じたリクエストがクライアントから返信される場合を考慮したものである。すなわち、trueが指定されているときには、このようなリクエストの内容を直ちにモデルオ
ブジェクトに代入できるようにするために、ＨＴＭＬ文の生成後もモデルオブジェクト（Ａ）がフレームワークエンジン３００３内の記憶領域に保持される。一方、false が指定されているときには、ＨＴＭＬ文の生成後はモデルオブジェクト（Ａ）のフレームワークエンジン３００３内の記憶領域で保持されない。

図２６（Ｂ）の第２行目以降は、テーブルモデルを表示するための画面の見かけの定義がタグを用いてなされている部分であり、この部分は「ビュー」と総称されている。
ビューの記述はビュータグを用いて行なわれる。第２行目にはテーブルモデルのためのビュータグの開始タグが示されており（<uomf:table >）、この第２行目と第１８行目のテーブルモデル用ビュータグの終了タグ（</uomf:table>）との間に幾つかのテーブル用のレンダラが記述される。

レンダラとは、指定の表示場所でのデータの表示にどのような表示方法を用いるかを定義するものである。図２６（Ｂ）の第３行目から第１７行目にかけての記述では、テーブルモデルのためのレンダラの定義が（ａ）から（ｅ）の計５つなされている。これらのテーブルレンダラの定義を簡単に説明すると、（ａ）はテーブルタグ（<table> 及び</table>）を生成させるためのもの、（ｂ）はテーブルの行の表示方式を定義するもの、（ｃ）はテーブルにおける通常の列の表示方式を定義するもの、（ｄ）はテーブルにおける各列の見出しが示されるセル（ヘッダセル）の表示方式を定義するもの、（ｅ）はテーブルにおけるデータ入力（データ更新）の可能なセルについての表示方式を定義するものである。

各レンダラには、テーブルモデル用レンダラタグの開始タグ（<uomf:tableRenderer>）がその最初の行に記述され、これに対応する終了タグ（</uomf:tableRenderer> ）がその最後の行に記述される。そして、このレンダラタグの開始タグと終了タグとに挟まれた行の記述によってデータの表示方法が定義される。このデータの表示方法についての定義を構成する個々の要素をレンダラエレメントと称している。

レンダラタグでは“type”と“cls ”とについての指定がなされる。これらは、レンダラに定義された表示方法で表示を行なう画面上の場所を特定するためのものである。これらの指定内容は扱うモデルの種類によって予め指定される。

“type”には、本実施の形態におけるテーブルモデルでは、table （表全体）、row （行）、column（列）のいずれかが指定され、これらによりレンダラに定義された表示方法で表示を行なうテーブルの場所が特定される。

“cls ”は、本実施の形態におけるテーブルモデルでは、上述した“type”がrow 又はcolumnに指定されているときに指定が可能である（指定のないこともある）。これは、前述したテーブルモデルインタフェースの宣言例（図２５）におけるgetRowClass 及びgetColumnClassの両メソッドと連動しているものであり、例えば列の表示を行なう際にはテーブルモデルインタフェースのgetColumnClassメソッドが呼び出される。そして、ビューのレンダラの定義が参照され、“type”がcolumnであって、“cls ”が呼び出されたメソッドについての戻り値に対応しているレンダラでの表示方法の定義が、その列の表示のための表示方法としてＨＴＭＬ文の生成に使用される。なお、呼び出されたメソッドについての戻り値が無い（ヌルである）ときには“cls ”の指定のないレンダラについての表示方法の定義が使用される。

“cls ”は、本実施の形態におけるテーブルモデルでは、具体的にはheader若しくはeditableが指定される。
レンダラにおける表示方法の定義は周知のＨＴＭＬのタグを用いて記述されるが、ここにレンダラエレメントタグという特殊なタグを導入する。図２６（Ｂ）においては、<uomf:children> 及び<uomf:value>がレンダラエレメントタグである。<uomf:children> は、このタグの位置に他のレンダラでの表示方法の定義を展開する動作をフレームワークエンジンに行なわせ、<uomf:value>は、このタグの位置にモデルインタフェースから取得した値（表示データ）を表示させるようにする動作をフレームワークエンジンに行なわせる。

これらのタグのより詳細な動作は扱うモデルの種類によって予め規定される。本実施の形態におけるテーブルモデルでは、<uomf:children> は、前述したレンダラタグにおける“type”の指定がtable （表全体）であるときにこのタグが出現したときには行についてのレンダラ（“type”の指定がrow であるレンダラ）で定義されている表示方式をこの位置に展開して挿入し、“type”の指定がrow （行）であるレンダラでこのタグが出現したときには列についてのレンダラ（“type”の指定がcolumnであるレンダラ）で定義されている表示方式をこの位置に展開して挿入することが規定されている。また、<uomf:value>は、“type”の指定がcolumnであるレンダラにおいてのみ使用可能であり、テーブルモデルインタフェースの宣言例（図２５）で使用されているgetValueAtメソッドによって取得される値をこの位置に挿入することが規定されている。

以下、図２６を参照しながら、フレームワークエンジンによって（Ｃ）の生成ＨＴＭＬ文が生成される様子を説明する。
まず、フレームワークエンジンは（Ａ）のモデルオブジェクトがテーブルモデルインタフェースを実装していることを認識し、テーブルモデル用のフレームワークエンジンを起動する。そして、このテーブルモデルインタフェースのgetColumnCount及びgetRowCount の両メソッドが呼び出され、表示するテーブルの列数及び行数が認識される。この結果、ここでは３行３列のテーブルを表示されることが認識される。

次に、（Ｂ）のＪＳＰソースにおいて、“type”がtable に指定されている（ａ）のテーブルレンダラの定義がまず参照され、（Ｃ）の生成ＨＴＭＬ文の第１行目が生成される。

ここで、（ａ）のテーブルレンダラの定義（（Ｂ）の第４行目）にはレンダラエレメントタグ<uomf:children> が記述されており、（ａ）のレンダラタグにおける“type”はtable に指定されているので、行についてのテーブルレンダラ、すなわち（Ｂ）のＪＳＰソースにおける（ｂ）のテーブルレンダラの定義の展開が行なわれ、（Ｃ）の生成ＨＴＭＬ文の第２行目が生成される。

ここで、（ｂ）のテーブルレンダラの定義（（Ｂ）の第７行目）にもレンダラエレメントタグ<uomf:children> が記述されており、（ｂ）のレンダラタグにおける“type”はrow に指定されているので、列についてのテーブルレンダラの定義の展開が行なわれる。但し、（Ｂ）のＪＳＰソースには、（ｃ）、（ｄ）、（ｅ）という列についてのテーブルレンダラ（“type”の指定がcolumnであるレンダラ）が３つ記述されているので、これらのうちのどのテーブルレンダラの定義の展開を行なうかが問題となる。

このとき、フレームワークエンジンでは、（Ａ）のモデルオブジェクトから、表示させるテーブルの１行目の各列のセルの値の取得、及びテーブルモデルインタフェースのgetColumnClassメソッドの呼び出しも行なわれている。これらの処理により、ここで取得されたセルの値は、“品名”、“単価”、“個数”という３つの文字列データであり、呼び出されたメソッドについての戻り値はこれら３つのいずれの値についてもheaderであった。

そこで、フレームワークエンジンは、このメソッドについての戻り値に基づき、（Ｂ）のＪＳＰソースにおける（ｄ）のテーブルレンダラの定義が選択され、その定義の展開を実行する。その結果、表示させるテーブルの１行目の表示方式を示すＨＴＭＬ文（（Ｃ）の生成ＨＴＭＬ文の第３、第４、第５行目）が、（ｄ）のテーブルレンダラの定義内容（（Ｂ）の第１３行目）に基づいて生成される。ここで、（ｄ）のテーブルレンダラの定義にはレンダラエレメントタグ<uomf:value>が含まれているので、この部分にはモデルオブジェクトから取得された各セルの値が挿入される。

ここまでで、先に行なった（ｂ）のテーブルレンダラの定義（（Ｂ）の第７行目）におけるレンダラエレメントタグ<uomf:children> についての展開が完了し、そのタグに続く次の定義の記述に基づいて（Ｃ）の生成ＨＴＭＬ文の第６行目が生成され、テーブルの１行目の表示のためのＨＴＭＬ文の生成が完了する。

次に、テーブルの２行目の表示のためのＨＴＭＬ文の生成が開始され、行についてのテーブルレンダラ、すなわち（Ｂ）のＪＳＰソースにおける（ｂ）のテーブルレンダラの定義の再度の展開が行なわれ、（Ｃ）の生成ＨＴＭＬ文の第７行目が生成される。

ここで、前回と同様に（ｂ）のテーブルレンダラの定義にレンダラエレメントタグ<uomf:children> の列についてのテーブルレンダラの定義への展開が行なわれる。
このとき、フレームワークエンジンでは、（Ａ）のモデルオブジェクトから、表示させるテーブルの２行目の各列のセルの値の取得、及びテーブルモデルインタフェースのgetColumnClassメソッドの呼び出しも行なわれ、これらの処理により、ここで取得されたセルの値は、“ＸＶ−５０８０”、“１９８，０００”、“”（ヌル）という３つのデータであり、呼び出されたメソッドについての戻り値は、最初の２つのセルについての値はヌルデータであり、最後のセルについての値はeditableであった。

そこで、フレームワークエンジンは、最初の２つのセルについてのこのメソッドの戻り値に基づき、（Ｂ）のＪＳＰソースにおける（ｃ）のテーブルレンダラの定義の展開を実行する。その結果、表示させるテーブルの２行１列目及び２行２列目の表示方式を示すＨＴＭＬ文（（Ｃ）の生成ＨＴＭＬ文の第８及び第９行目）が、（ｃ）のテーブルレンダラの定義内容（（Ｂ）の第１０行目）に基づいて生成される。ここで、（ｃ）のテーブルレンダラの定義にもレンダラエレメントタグ<uomf:value>が含まれているので、この部分にはモデルオブジェクトから取得された各セルの値が挿入される。

更に、フレームワークエンジンは、上述した最後のセルについてのこのメソッドの戻り値に基づき、（Ｂ）のＪＳＰソースにおける（ｅ）のテーブルレンダラの定義の展開を実行する。その結果、表示させるテーブルの２行３列目の表示方式を示すＨＴＭＬ文（（Ｃ）の生成ＨＴＭＬ文の第１０行目）が、（ｅ）のテーブルレンダラの定義内容（（Ｂ）の第１６行目）に基づいて生成される。

ここまでで、先に行なった（ｂ）のテーブルレンダラの定義（（Ｂ）の第７行目）におけるレンダラエレメントタグ<uomf:children> についての展開が完了し、そのタグに続く次の定義の記述に基づいて（Ｃ）の生成ＨＴＭＬ文の第１１行目が生成され、テーブルの２行目の表示のためのＨＴＭＬ文の生成が完了する。

（Ｃ）の生成ＨＴＭＬ文の第１２行目から第１６行目まで（テーブルの３行目の表示のためのＨＴＭＬ文）が生成される流れは、上述したテーブルの２行目の表示のためのＨＴＭＬ文（（Ｃ）の生成ＨＴＭＬ文の第７行目から第１１行目まで）と同様である。

ここまでで、先に行なった（ａ）のテーブルレンダラの定義（（Ｂ）の第４行目）におけるレンダラエレメントタグ<uomf:children> についての展開が完了し、そのタグに続く次の定義の記述に基づいて（Ｃ）の生成ＨＴＭＬ文の第１７行目が生成される。こうして、（Ｃ）に示すテーブルの表示のためのＨＴＭＬ文の生成が完了する。

なお、前述したように、生成されたＨＴＭＬ文はクライアントに宛てて送出される。この後、このＨＴＭＬ文に対応するリクエストがクライアントから送付されてきたときにそのリクエストがどのモデルオブジェクトについてのものであるかを容易に特定できるようにするために、ブラウザによって入力フィールドがクライアントで表示されない、いわゆるｈｉｄｄｅｎ属性のｉｎｐｕｔタグ（<input type=hidden>）がこの生成されたＨＴＭＬ文に追加されて送出される。このｉｎｐｕｔタグには、モデルの種類を示す文字列とＨＴＭＬ文の生成に用いられたビュー毎に一意なＩＤ（識別子）とが記述されるようにして、これらのデータがそのリクエストに自動的に含まれるようにする。

図２４に示すテーブルモデル用のフレームワークエンジン３００３が、ブラウザ３００５によってクライアントにテーブルを表示させるためのＨＴＭＬ文を生成する、以上までに説明した処理を、図２７、図２８、及び図２９に示すフローチャートに沿って更に説明する。なお、この処理を「表示時の処理」と称することとする。

フレームワークエンジン３００３は、まず、表示用ＪＳＰ３００４を読み込み、表示用ＪＳＰ３００４に含まれているビュータグを検出する。続いてそのビュータグによって示されているビューに含まれている各レンダラを、レンダラタグで指定されている“type”及び“cls ”に基づいて分類してバッファの所定の場所に登録する。更に、この登録を終えた後に、フレームワークエンジン３００３は、ビュータグに指定されているモデルオブジェクト３００１からデータを取得しながら図２７、図２８、及び図２９に示すフローチャートに沿った処理を開始する。なお、ここまでの処理を「ビュータグの解析処理」と総称することとする。

図２７には、テーブルモデル用のフレームワークエンジン３００３によって行なわれる表示時の制御処理の全体フローが示されている。
図２７に示す処理が開始されると、まず、ビューの一意ＩＤが生成される（Ｓ３１０１）。ビューの一意ＩＤは、前述したように、ＨＴＭＬ文の生成に用いられる表示用ＪＳＰ３００４のビュー毎に一意なＩＤであり、例えば“ｕｊｉ．ｍｏｄｅｌ．００００１”などのように、共通のプレフィックス（接頭辞）（“ｕｊｉ．ｍｏｄｅｌ．”の部分）とＨＴＭＬ文生成の度に異なる連番の数字（“００００１”の部分）とを組み合わせたものを生成するようにすればよい。このビュー毎に異なる一意なＩＤは、複数のモデルオブジェクトについての表示がクライアントで行なわれ、それらの各々についてのリクエストをサーバが受け取ったときに、受け取ったリクエストがそれぞれどのモデルオブジェクトについてのものであるかを識別できるようにするために用いられるものであり、クライアントではモデルオブジェクトに対応するＩＤを含んだリクエストが生成される。

続いて、前述した処理によってフレームワークエンジン３００３の有するバッファに登録されている各レンダラから、“type”がtable に指定されているものが取得される（Ｓ３１０２）。

その後、レベルをtable とし、子レベルをrow としたときのレンダラ表示処理が実行される（Ｓ３１０３）。レンダラ表示処理は図２８にフローチャートで示した処理であり、その詳細は後述する。

上述したＳ３１０３の処理によってテーブルを表示させるためのＨＴＭＬ文が生成される。そこで、フレームワークエンジン３００３は、前述したｈｉｄｄｅｎ属性のｉｎｐｕｔタグを生成してこのＨＴＭＬ文に追加する（Ｓ３１０４）。ここで生成されるｉｎｐｕｔタグは例えば下記のようなものとする。
<input type=hidden name=”uji.model” value=”uji.model.00001”>
<input type=hidden name=”uji.model.00001” value=”table”>
ここで、“ｕｊｉ．ｍｏｄｅｌ．００００１”は先に生成されたビューの一意ＩＤの例である。これらのｉｎｐｕｔタグがＨＴＭＬ文に追加されることによって、このＨＴＭＬ文に対応するリクエストにこれらの情報が含まれるようになり、リクエストとモデルオブジェクト３００１との対応関係が明らかになる。

次に、図２７のＳ３１０３において実行される、図２８にフローチャートで示すレンダラ表示処理について説明する。
なお、以降の説明及び図面においては、今までに用いていたレンダラエレメントタグの表記（例えば<umof:children> ）に加え、uomf: の接頭辞を略した表記（例えば<children>）も併用することとする。

まず、このレンダラ表示処理が呼び出されたときのレベルが何であったかが調べられ、このレベルが“type”に指定されているレンダラにおける表示方式を定義している要素が未だ残されているか否かが判定され（Ｓ３２０１）、判定結果がＹｅｓならば、次の要素（レンダラエレメント）がひとつ取得され（Ｓ３２０２）、Ｓ３２０３に処理が進む。一方、Ｓ３２０１の判定結果がＮｏならばこのレンダラ表示処理が終了し、元の処理へ戻る。

続いて、Ｓ３２０２の処理によって取得された要素がどのようなものであるかが判定される（Ｓ３２０３、Ｓ３２０６、Ｓ３２０８、Ｓ３２１０）。
この結果、取得された要素がビュータグであるならば（Ｓ３２０３の判定結果がＹｅｓ）、前述したビュータグの解析処理がこのビュータグに対して行なわれ（Ｓ３２０４）、その後、前述した図２７の処理をこのビュータグについて実行し（Ｓ３２０５）、この処理の終了後はＳ３２０１へ処理が戻る。

このＳ３２０４及びＳ３２０５の処理は、あるビューの記述中に別のビューの記述がなされている（ビューがネストしている）ときに行なわれるものであり、例えば、テーブルモデルのあるセル中に更に別のモデルが存在するような場合に対応させるためのものである。

Ｓ３２０２の処理によって取得された要素が<children>のレンダラエレメントタグであるならば（Ｓ３２０６の判定結果がＹｅｓ）、このレンダラ表示処理が呼び出されたときの子レベルが何であったかが調べられ、この子レベルについての表示処理が実行され（Ｓ３２０７）、この処理の終了後はＳ３２０１へ処理が戻る。子レベルがrow であるときの表示処理は図２９（Ａ）にフローチャートで示されており、子レベルがcolumnであるときの表示処理は図２９（Ｂ）にフローチャートで示されている。これらの表示処理は後で説明する。

また、Ｓ３２０２の処理によって取得された要素が<name>のレンダラエレメントタグであるならば（Ｓ３２０８の判定結果がＹｅｓ）、後にリクエストにおいて使用される要素に名前付けを行なう処理が実行され（Ｓ３２０９）、この処理の終了後はＳ３２０１へ処
理が戻る。

ここで、<name>のレンダラエレメントタグについて説明する。このタグは、所定の規則に従った名前をフレームワークエンジンに生成させるものである。
本実施例においては、この名前は図３０の（Ａ）に示す規則に従って生成される。ここで、モデル固有位置とは、あるモデルでの自己の位置を一意に表すための文字列であり、例えば、テーブルモデルにおいて２行３列目を表すのであれば、“２＿３”などというように文字列を生成すればよい。このとき、前述したビューの一意ＩＤの生成例（“ｕｊｉ．ｍｏｄｅｌ．００００１”）をそのまま流用すれば、このときに<name>のレンダラエレメントタグに応じて生成される名前は図３０の（Ｂ）のようになる。

このような規則による名前付けを行うことにより、この名前からモデルオブジェクト及びそのモデルにおける位置を特定することができる。
<name>のレンダラエレメントタグを使用したレンダラの定義例を図３１に示す。同図に示す定義の記述を説明すると、<uomf:value/> によってモデルオブジェクトから取得された値が更新前の値としてテーブル中の更新可能なセルに挿入されてクライアントで表示される。ここで、このセルの値がクライアントにおいて更新されるとリクエストが送信される。このリクエストでは、<uomf:name/>で生成される名前が更新後のセルの値を参照するための参照名として用いられる。こうすることによって、テーブルモデルエンジンでは、前述した名前付けの規則により、モデルオブジェクト及びそのモデルにおける位置をこの参照名から特定することができるので、クライアントで生成するひとつのリクエスト中に複数の更新データを含ませるようにすることもでき、更に、異なるモデルオブジェクトについての複数の更新データをひとつのリクエストに含ませることもできる。

また、前述したような、ネストしているビューの中に<uomf:name> のレンダラエレメントタグが記述されている場合には、図３０の（Ｃ）に示す例のように、ネストの外側で生成される名前（例えば図３０の（Ｂ）に示される名前）をプレフィックスとしたものに連番の数字等を組み合わせて前述のビュー一意ＩＤを生成し、そのビュー一意ＩＤにそのネストしているビューにおけるモデル固有位置を組み合わせたものをレンダラエレメントタグについての名前として生成するようにする。この名前付けの規則により、生成された名前から、ネストの存在及びビューの継承関係を認識すること、及びそのネストに係るモデルを特定することができる。

図２８の説明に戻る。
Ｓ３２０２の判定処理によって取得された要素が<value> のレンダラエレメントタグであるならば（Ｓ３２１０の判定結果がＹｅｓ）、このテーブルモデルにおける現在の位置に対応する値がモデルオブジェクトから取得され（Ｓ３２１１）、この後にＳ３２０１へ処理が戻る。

一方、Ｓ３２０２の判定処理によって取得された要素が上述したいずれのタグともことなるものであるならば（Ｓ３２０３、Ｓ３２０６、Ｓ３２０８、Ｓ３２１０の判定結果が全てＮｏ）、この取得された要素が生成ＨＴＭＬ文にそのまま表示され（Ｓ３２１２）、この後にＳ３２０１へ処理が戻る。

以上までの処理がレンダラ表示処理である。
次に、上述したレンダラ表示処理のＳ３２０７において実行される、子レベルについて
の表示処理を説明する。前述したように子レベルがrow であるときの表示処理は図２９（Ａ）にフローチャートで示されており、子レベルがcolumnであるときの表示処理は図２９（Ｂ）にフローチャートで示されている。

まず、図２９（Ａ）のフローチャートを説明する。
まず、変数ｒｏｗの値が０とされ、この変数ｒｏｗの値がgetRowCount()メソッドの戻り値（すなわちテーブルの行数）を超えるまでＳ３３０２からＳ３３０４までの処理が繰り返される（Ｓ３３０１）。

続いて、モデルオブジェクト３００１から、変数ｒｏｗの値で示される行についての行クラス（getRowClass()）が取得される（Ｓ３３０２）。
次に、フレームワークエンジン３００３の有するバッファに登録されている各レンダラより、取得された行クラスが“cls ”に指定されており、且つ、“type”がrow に指定されているレンダラが取得される（Ｓ３３０３）。

ここで、レベルをrow とし、子レベルをcolumnとしたときのレンダラ表示処理が実行される（Ｓ３３０４）。ここで実行されるレンダラ処理は、既に説明した、図２８に示されているものである。

その後、変数ｒｏｗの値に１を加算した結果の値が改めて変数ｒｏｗに代入され、Ｓ３３０１へ処理が戻る（Ｓ３３０５）。変数ｒｏｗの値が前述した条件に達したならばこの処理が終了し、元の処理へ戻る。

次に、図２９（Ｂ）のフローチャートを説明する。この処理は、基本的には上述した図２９（Ａ）と同様の処理が実行される。
まず、変数ｃｏｌｕｍｎの値が０とされ、この変数ｃｏｌｕｍｎの値がgetcolumnCount()メソッドの戻り値（すなわちテーブルの列数）を超えるまでＳ３４０２からＳ３４０４までの処理が繰り返される（Ｓ３４０１）。

続いて、モデルオブジェクト３００１から、変数ｒｏｗの値で示される行についての列クラス（getColumnClass()）が取得される（Ｓ３４０２）。
次に、フレームワークエンジン３００３の有するバッファに登録されている各レンダラより、取得された列クラスが“cls ”に指定されており、且つ、“type”がcolumnに指定されているレンダラが取得される（Ｓ３４０３）。

ここで、レベルをcolumnとし、子レベルを無し（ヌル）としたときのレンダラ表示処理が実行される（Ｓ３４０４）。ここで実行されるレンダラ処理も、既に説明した、図２８に示されているものである。

その後、変数ｃｏｌｕｍｎの値に１を加算した結果の値が改めて変数ｃｏｌｕｍｎに代入され、Ｓ３４０１へ処理が戻る（Ｓ３４０５）。変数ｃｏｌｕｍｎの値が前述した条件に達したならばこの処理が終了し、元の処理へ戻る。

以上までの処理が表示処理である。
なお、この表示処理が終了した後に、フレームワークエンジン３００３は、表示用ＪＳ
Ｐ３００４のＪＳＰソースとモデルオブジェクト３００１との対応関係が示されている記述（図２６（Ｂ）の例では第１行目）を参照し、図３２に示す記憶領域管理処理を実行する。すなわち、この記述でrequest がtrueに設定されているか否かが判定され（Ｓ３５０１）、この判定結果がＹｅｓならば、フレームワークエンジン３００３の有する記憶部に保持されているモデルオブジェクト３００１の内容をその後も継続し（Ｓ３５０２）、この判定結果がＮｏならば、フレームワークエンジン３００３の有する記憶部におけるモデルオブジェクト３００１の記憶領域を解放する（Ｓ３５０３）。

次に、図２４に示すシステムにおいて、ブラウザ３００５から発せられるリクエストをフレームワークエンジン３００３が受け取ってモデルオブジェクト３００１を更新する動作について説明する。なお、この動作を「リクエスト時の動作」と称することとする。

図３３は、図２４に示すシステムにおけるリクエスト時の動作の概要を説明する図である。
まず、フレームワークエンジン３００３により生成された、通常の（ｈｉｄｄｅｎ属性でない）<input> タグを含むＨＴＭＬ文をクライアントが受け取り、クライアントに装備されているブラウザ３００５がそのＨＴＭＬ文に基づいてテーブルを表示させている。ここで、この<input> タグに対応するデータがクライアントに入力されると、ブラウザ３００５はこのデータを含むＨＴＴＰによるリクエストをサーバ側に送信する。

サーバのフロントコンポーネント３００６は、このＨＴＴＰリクエストを受信すると、フレームワークエンジン３００３を起動させるための指示を与え、リクエストをフレームワークエンジン３００３に渡す。

フレームワークエンジン３００３では、まず、受け取ったリクエストがどのモデルについてのものかを判断する。この判断は、前述したｈｉｄｄｅｎ属性の<input> タグの作用によってリクエストに含まれるモデルの種類についての情報を利用する。ここで、例えば、このリクエストがテーブルモデルについてのものであると判断されれば、テーブルモデル用のエンジンが選択されて起動される。

続いて、フレームワークエンジン３００３は、同じくｈｉｄｄｅｎ属性の<input> タグの作用によってリクエストに含まれることとなる、ビューの一意ＩＤから、このリクエストに含まれるデータを代入すべきモデルオブジェクト３００１を特定する。

そして、特定されたモデルオブジェクト３００１がフレームワークエンジン３００３内の記憶領域に保持されていればその保持されているものに対してリクエストに含まれていたデータを代入し、保持されていなければ、モデルオブジェクト３００１を改めて生成してそのデータの代入を行なう。

なお、モデルオブジェクト３００１へデータを代入するには、その代入すべきデータをモデルに応じた更新メソッドに変換し、モデルオブジェクトを更新させるインタフェースメソッド（例えば図２５に示したテーブルモデルインタフェース３００２を更新するのであれば、setValueAtメソッド）を呼び出すことにより、モデルオブジェクト３００１の更新を行うようにすればよい。

フレームワークエンジン３００３で行なわれる、上述したリクエスト時の制御処理の処理内容を図３４にフローチャートで示す。
図３４では、この制御処理の全体フローを（Ａ）として示し、この制御処理の途中で実
行されるテーブルモデル用のモデルアップデート処理を（Ｂ）として示している。

クライアントのブラウザ３００５で生成された、前述した表示処理によって生成されたＨＴＭＬ文に基づく表示に応じて入力されたデータを含むリクエストには、前述した名前付けの規則に基づくそのデータの参照名が示されていることは既に説明した。そこで、フレームワークエンジン３００３は、リクエストを受け取ると、まず、そのリクエストに含まれているその参照名を全て取り出す。そして、取り出された参照名のうちのひとつが変数ｋｅｙに代入される（Ｓ３６０１）。

ここで、この変数ｋｅｙの値が、フレームワークエンジン３００３で扱えるモデルを表すものであるか否かが判定され（Ｓ３６０２）、この判定結果がＹｅｓならば、続いてその変数ｋｅｙに対応するモデルオブジェクト３００１がフレームワークエンジン３００３の有する記憶部に保持されているか否かが判定される（Ｓ３６０３）。

このＳ３６０３の判定結果がＹｅｓならば、その記憶部に保持されているモデルオブジェクト３００１が取得され（Ｓ３６０４）、このＳ３６０３の判定結果がＮｏならば、改めてモデルオブジェクト３００１が作成される（Ｓ３６０５）。そして、このモデルオブジェクト３００１に対してモデルアップデート処理が施される（Ｓ３６０６）。

モデルアップデート処理を完了した後、若しくはＳ３６０２の判定結果がＮｏであったときには、リクエストから取り出されている別の参照名が変数ｋｅｙに設定され、その後、上述したＳ３６０２からＳ３６０６までの処理が取り出された全ての参照名について行なわれるまで、処理が繰り返される（Ｓ３６０７）。

次に、上述したＳ３６０６の処理において実行される、図３４（Ｂ）に示すテーブルモデル用のモデルアップデート処理について説明する。
まず、変数ｋｅｙの値（すなわち、リクエストに含まれる更新データの参照名）が分解され、その名前を構成している前述したモデル固有位置から、テーブルモデル上の行（row ）及び列（column）の位置が取得される（Ｓ３７０１）。

そして、モデルオブジェクト３００１のsetValueAt()メソッドが呼び出され、取得されたテーブルモデルの行と列との位置、及びこの参照名により参照される更新データの値がそのメソッドに渡されることにより、モデルオブジェクト３００１が更新され（Ｓ３７０２）、その後は図３４（Ａ）に処理が戻る。

以上までの処理をフレームワークエンジン３００３が実行することによって、ブラウザ３００５から発せられるリクエストに基づいたモデルオブジェクト３００１の更新が行なわれる。

以上までに説明した本発明の第３の実施例を実施するクライアントサーバシステムの例を図３５に示す。
サーバ３０１０は、モデルフレームワーク処理部３０１１、Ｗｅｂサーバ部３０１２、バックエンド３０１３を備える。

モデルフレームワーク処理部３０１１は、図２４におけるフレームワークエンジン３００３に相当する機能を実行する。
Ｗｅｂサーバ部３０１２は、モデルフレームワーク処理部３０１１で生成されたＨＴＭ
Ｌ文をクライアント（３０２０ａ、３０２０ｂ、３０２０ｃ、…）に送る機能と、クライアント（３０２０ａ、３０２０ｂ、３０２０ｃ、…）からの陸エンストを受け付けてモデルフレームワーク処理部３０１１に渡すフロントコンポーネント３００６に相当する機能とを実行する。

バックエンド３０１３は、データベース３０１４に蓄積されているデータの操作を行ない、モデルオブジェクト３００１を使用してモデルフレームワーク処理部３０１１とデータの授受を行なう。

クライアント（３０２０ａ、３０２０ｂ、３０２０ｃ、…）はブラウザ３００５を装備し、サーバ３０１０から送られてくるＨＴＭＬ文に基づいた画面の表示、及び、その表示画面に含まれている入力フォームへの入力に対応するリクエストの生成及びサーバ３０１０へ宛てての送信を行なうものである。

次に、本発明の更なる実施例について説明する。
これより説明する実施例は、Ｗｅｂアプリケーションを開発する際に、ロジックである処理スクリプトの定義を呼び出す記述を画面の見かけを定義するモジュールには直接記述せずに利用可能とするものであり、処理スクリプトの定義によって表現されるロジックの部品化が可能となり、ロジックと画面定義との分離が進むことによって、ロジックの再利用性を高めてＷｅｂアプリケーションの開発効率を向上させるというものである。

なお、これより説明する上述した実施例を、既に説明した他の実施例と区別するために、「第４の実施例」と称することとする。
まず、図３６について説明する。同図は本発明の第４の実施例によってスクリプトが生成される様子を示しており、（Ａ）に示す記述文に対して後述するコンテンツ変換処理が施されることによって（Ｂ）に示すスクリプトを含むＨＴＭＬ文が生成されることを示している。

図３６（Ａ）及び（Ｂ）の記述内容は、ブラウザによる表示において、ある入力用のフォーム部品に対してなされるクリック操作に応じて、クリック操作がなされたことを通知する警告画面を表示させる処理を行なう処理スクリプトを実行させるというものである。なお、説明の便宜のため、図３６の（Ａ）及び（Ｂ）の各行頭には行番号を付している。

従来のＷｅｂアプリケーションの開発手法によれば、上述した処理をブラウザに行なわせるためには、図３６（Ｂ）に示すようなＨＴＭＬ文、すなわち、スクリプト部分の呼び出しを行なう条件となるプロパティの記述（図３６（Ｂ）第８行目の記述）と、処理スクリプト自体の動作の定義（図３６（Ｂ）第１行目から第６行目の記述）とを直接記述し、更にこの両者の関連を示すためにその双方に処理スクリプトの名前（図３６（Ｂ）の例ではaction123() ）を記述する必要があった。そのため、何らかの理由によってこれらのどちらかに修正が必要となっても、結局両者を参照してその一方に対する修正が他方に影響を与えていないかを確認する必要が生じてしまうため、保守性に問題があった。また、このために、結局は処理スクリプトの動作定義とその処理スクリプトの呼び出しを行なう部分とを同一のコンポーネントに記述することとなり、処理スクリプトの動作定義の再利用性も低かった。

一方、この第４実施例では、同図（Ａ）に示すような各種のタグを用いた記述文を作成し、この記述文に対してコンテンツ変換処理を施すことで（Ｂ）に示すスクリプトを含むＨＴＭＬ文を自動的に生成させるようにするものである。同図（Ａ）には、処理スクリプ
トに名称が指定されておらず、更に、処理スクリプトを起動させる条件を示すプロパティ（同図（Ｂ）の第８行目の“onclick=”で始まり、処理スクリプト名を指定する記述）も記述されていない。

まず、同図（Ａ）を説明する上で必要な概念を説明する。
図３７は、本発明の第４の実施例で使用されるオブジェクトの構成を示している。
コンポーネント（ScriptComponent ）オブジェクト４００１は、ブラウザによって画面中に表示されているオブジェクトに対するイベントの発生元となるオブジェクトであり、図３６（Ａ）の例における<input> タグ（ValidInputTag オブジェクト４０１１）はコンポーネントタグと呼ばれる。コンポーネントタグはアクションタグをその内部に有しており、そのアクションタグに記述されるプロパティの内容である、処理スクリプトの呼び出しを行うためのイベントの指定が行なわれる。

コンテナ（ScriptContainer ）オブジェクト４００２は、コンポーネントオブジェクト４００１の管理やアクションオブジェクト４００３の有する処理スクリプトの出力を行なうオブジェクトであり、図３６（Ａ）の例における<form>タグ（ValidFormTagオブジェクト４０１２）はコンテナタグと呼ばれる。なお、コンテナオブジェクト４００２はコンポーネントオブジェクト４００１を継承しており、自らがイベントの発生元となることもある。

アクション（ScriptAction）オブジェクト４００３は、ロジックである処理の定義がスクリプトによりなされるオブジェクトであり、図３６（Ａ）の例における<action >タグはアクションタグと呼ばれる。なお、アクションタグはカスタムアクションタグ（CustomActiontag オブジェクト４０１３ａ）とマイアクションタグ（MyActiontag オブジェクト４０１４ｂ）とがあるが、この詳細は後述する。

スクリプト呼び出し部（ScriptCaller）オブジェクト４００４は、イベントの発生に応じて個別に処理スクリプトの呼び出しを行なうときの各処理スクリプトの呼び出し法や戻り値の解釈法を決定するオブジェクトである。

次に、図３８について説明する。同図はコンテンツ変換処理の概要を説明する図である。以下、図３６（Ａ）に示した記述文が変換される様子を図３８を参照しながら説明する。

まず、（Ａ）の第１行目に記述されているコンテナオブジェクト４１０２である<form>タグの記述内容がコンテンツ変換装置を実行する処理装置の有する記憶部に記憶され、第２行目に記述されているコンポーネントオブジェクト４１０１である<input>タグの記述内容が同様に記憶される。

次に、第３行目にアクションオブジェクト４１０３である<action>タグが記述されている。
<action>タグではevent プロパティの指定が必ずなされている。このプロパティの指定によって、この<action>タグとこれに対応する終了タグとの間に記述されているスクリプトがどのコンポーネントで発生するどのようなイベントに対して実行されるものなのかが示される。（Ａ）の例では、この<action>タグを直接内包している第２行目の<input> タグで発生する“クリック操作”のイベントを対象としていることが示されている。

そこで、コンポーネントオブジェクト４１０１である第２行目の<input> タグに、この<input> が有するアクションオブジェクト４１０３として第３行目の<action>タグが登録される（図３８（ａ））。

次に、第３行目の<action>タグから第５行目の<action>タグの終了タグとの間（すなわち第４行目のみ）に記述されているスクリプト（“alert(“clicked!”) ”）がアクションオブジェクト４１０３である<action>タグにおいて実行されるスクリプトとして記憶される。

続いて、第６行目に第２行目の<input> タグに対応する終了タグが記述されている。ここで、<input> タグの生成（すなわち、図３６（Ｂ）の第８行目）が開始され（図３８（ｂ））、<input> タグについての記憶内容（すなわち、図３６（Ａ）の第１行目の記述内容である“input name=”field1” ”）が出力される。

続いて、この<input> タグに先に登録されていたアクションオブジェクト４１０３である<action>タグに対し出力指示の通知が行なわれる（図３８（ｂ））。
この出力通知が<action>タグによって受け取られると、この<action>タグについての前述したプロパティについての指定内容がコンポーネントオブジェクト４１０１に送られて生成中の<input> タグに追加される（図３８（ｄ））。図３６（Ａ）の例では、event プロパティが“click”に指定されているので、<input> タグには“onclick=”が出力されるようにしておく。ここまでで、コンポーネントオブジェクト４１０１による<input> タグの大枠の生成が完了する。

更に、ここで、前述したスクリプトが保持されているアクションオブジェクト４１０３である<action>タグがコンテナオブジェクト４１０２である<form>タグに登録される（図３８（ｅ））。

最後に、図３６（Ａ）の第７行目に第１行目の<form>タグに対応する終了タグが記述されている。ここで、コンテナオブジェクト４１０２である<form>タグの生成（図３８（ｆ））が開始され、まず、図３６（Ｂ）の第１行目の出力が行なわれる。

続いて、スクリプトの呼び出し部分の生成がスクリプト呼び出し部オブジェクト４１０４に指示される（図３８（ｇ））。ここでは、まず、処理スクリプトの名前（action123(target)）が自動生成されて図３６（Ｂ）の第２行目及び第５行目が出力され、続いてこの処理スクリプトの戻り値が定義される第４行目が出力される。更に、この処理スクリプトの呼び出し元であるコンポーネントオブジェクト４１０１である第８行目の<input> タグに、処理スクリプトの名前を出力する。

そして最後に、<form>タグに先に登録されていたアクションオブジェクト４１０３である<action>タグに指示され（図３８（ｈ））、前述したスクリプトが図３６（Ｂ）の第３行目として出力される。この後に、コンテナオブジェクト４１０２である<form>タグによって、図３６（Ｂ）の第６行目、第７行目、及び第９行目が出力され、図３６（Ｂ）のＨＴＭＬ文の生成が完了する。

以上までに説明した、コンテンツ変換処理をフローチャートで示したものが図３９及び図４０である。次に、このフローチャートについて説明する。
まず、図３９において、処理が開始されると、図３６（Ａ）に示すような記述文が先頭行から読み出される。

この読み出された行にアクションタグが記述されているか否かが判定され（Ｓ４２０１）、アクションタグでないならば（Ｓ４２０１の判定結果がＮｏ）、この行に記述されているタグの内容が記憶部に記憶され（Ｓ４２０２）、その後はＳ４２０１へ処理が戻ってこの行の次の行についての判定処理が繰り返される。

一方、読み出された行にアクションタグが記述されているならば（Ｓ４２０１の判定結果がＹｅｓ）、このアクションタグを含んでいるコンポーネントタグにこのアクションタグが登録され（Ｓ４２０３）、続いてこのアクションタグの開始タグと終了タグとの間に記述されている処理スクリプトが記憶部に記憶される（Ｓ４２０４）。

次に、アクションタグの終了タグが記述されている行の次の行が読み出され、この行にコンポーネントタグの終了タグが記述されているか否かが判定される（Ｓ４２０５）。この結果、コンポーネントタグの終了タグがこの行に記述されていなければ（Ｓ４２０５の判定結果がＮｏ）、Ｓ４２０１へ処理が戻ってこの行についての判定処理が繰り返される。

一方、この行にコンポーネントタグの終了タグがこの行に記述されていれば（Ｓ４２０５の判定結果かＹｅｓ）、このコンポーネントタグについての生成が開始されて記憶部に記憶されているこのコンポーネントタグについての記述内容が出力され（Ｓ４２０６）、更に、このコンポーネントタグに登録されているアクションタグのプロパティが追加される（Ｓ４２０７）。

次に、図４０に処理が進み、ここで、追加されたアクションタグのプロパティの内容が調べられ、このプロパティで指定されているイベントが、このコンポーネントでサポートされているものであるか否かが判定される（Ｓ４２０８）。この結果、指定されているイベントがこのコンポーネントでサポートされていないものであるならば（Ｓ４２０８の判定結果がＮｏ）、このコンテンツ変換処理の処理結果として元の記述文に誤りが存在することを示すエラー通知が出力され（Ｓ４２０９）、処理が終了する。

一方、指定されているイベントがこのコンポーネントでサポートされているものであったならば（Ｓ４２０８の判定結果がＹｅｓ）、コンポーネントタグの生成が完了し（Ｓ４２１０）、生成されたコンポーネントタグが記憶部に一時的に保管される。更に、このコンポーネントタグに登録されていたアクションタグがコンテナタグに登録される。

次に、コンポーネントタグの終了タグが記述されていた行の次の行が読み出され、この行にコンテナタグの終了タグが記述されているか否かが判定される（Ｓ４２１２）。この結果、コンテナタグの終了タグがこの行に記述されていなければ（Ｓ４２１２の判定結果がＮｏ）、Ｓ４２０１（図３９）へ処理が戻ってこの行についての判定処理が繰り返される。

一方、この行にコンテナタグの終了タグがこの行に記述されていれば（Ｓ４２１２の判定結果かＹｅｓ）、このコンテナタグについての出力が開始されて記憶部に記憶されているこのコンテナタグについての記述内容が出力される（Ｓ４２１３）。

続いて、スクリプト呼び出し部オブジェクトによって処理スクリプトの名前が自動生成されて出力され（Ｓ４２１４）、更に一時的に保管されているコンポーネントタグにその名前が記述されることによってコンポーネントタグと処理スクリプトとが関連付けられる。

その後、このコンテナタグに登録されているアクションタグに関連付けて記述されていて先に記憶部に記憶させていた処理スクリプトが出力され（Ｓ４２１５）、そして最後に<script>タグの出力やコンテナタグの終了タグの出力などが行なわれてコンテナタグの生成が完了する（Ｓ４２１６）。

以上の処理が実行されることによって、図３６（Ａ）に示すような記述文から図３６（Ｂ）に示すようなＨＴＭＬ文が生成される。
なお、このコンテンツ変換処理は、サーバに単独で設けられる処理エンジンによって処理させるようにしてもよいが、前述した本発明の第３の実施例で説明したフレームワークエンジンによって、前述した表示処理に併せて処理させるようにしてもよい。このとき、コンテンツ変換処理での変換対象であるＪＳＰソースは、モデルを表示するための画面の見かけの定義が行なわれるビューにおけるレンダラの要素として記述される。

次にこの第４の実施例の応用について説明する。
図３６では処理を定義するスクリプトを記述文（Ａ）に記述（第４行目）に記述していたが、この処理スクリプトを記述文（Ａ）中では記述せずに、部品化されている処理スクリプトを利用する手法についてまず説明する。

図４１は、処理スクリプトを別に用意する場合のスクリプト記述例を示す図である。
図３６（Ａ）に示した記述文では、全てのタグにsf: なる接頭辞を付していたが、図４１（Ａ）に示す記述文では、アクションタグ<action>にmy: なる接頭辞が付されている。このタグ<my:action> はマイアクションタグと称されており、コンテンツ変換処理においてこのタグが検出されたときには、予め用意されている処理スクリプトがＳ４２１５（図４０）の処理で出力されるようにする。なお、これに対して、今まで説明したsf: なる接頭辞を付したアクションタグは特にカスタムアクションタグと称されている。

図４１（Ａ）に記述されたマイアクションタグに対応するスクリプトである、文字列の最小文字数をチェックする処理スクリプトの定義例を図４２に示す。図４２に示す定義例では、マイアクションタグに指定されるMinLength プロパティを受け取るためのsetMinLength()が定義され、更に、outputFunctionBodyメソッドにおいて、出力オブジェクトWriterに対して、上述したプロパティの内容を埋め込んだ処理スクリプトを出力させることが指示されている。

図３９及び図４０に示されているコンテンツ変換処理を実行させると、図３９のＳ４２０４の処理において図４２に示されているような処理スクリプトが記憶部に記憶され、その後の図４０のＳ４２１５の処理において、その処理スクリプトが出力されるときに、変数min への値の代入がなされた出力が行なわれる。その結果、図４１（Ａ）の記述文から図４１（Ｂ）に示すＨＴＭＬ文が生成される。

次に図４３について説明する。同図は、同一のイベントに対して複数のアクションが対応する場合のスクリプト記述例を示す図である。
図４３（Ａ）の記述文では、第２行目に示されている<input> タグが、第３行目及び第６行目の２つのアクションタグを有している。このような場合には、図３９及び図４０に示されているコンテンツ変換処理において、図３９のＳ４２０５の判定処理の作用により、Ｓ４２０１からＳ４２０５にかけての処理が２度行なわれ、その結果、<input> タグにこれら２つのアクションタグが登録され、更にそれぞれのアクションタグについての処理
スクリプトが記憶される。

その後、図３９のＳ４２０７の処理において２つのアクションタグから<input> タグにプロパティが追加されると、コンテンツ変換処理では、これら２つのアクションタグに指定されている”event” の内容が同一であることが認識される。

この認識結果に基づいて、コンテンツ変換処理では、図４０のＳ４２１４の処理において、処理スクリプトの名前の自動生成に加え、図４３（ｂ）の第２行目から第８行目（（ａ）の部分）に示す、２つの処理スクリプトを順に実行させるための処理スクリプトの自動生成がスクリプト呼び出し部オブジェクトで行なわれる。このスクリプト呼び出し部オブジェクトによる処理スクリプトの自動生成によって、同一イベントと複数の処理スクリプトとの対応関係が確立される。

その後、Ｓ４２１５において、図４３（Ｂ）の第９行目から第１２行目（（ｂ）の部分）及び第１３行目から第１９行目（（ｃ）の部分）の出力が行なわれる。
次に図４４について説明する。同図は、コンテナタグでイベントが発生する場合のスクリプト記述例を示している。

図４４（Ａ）において、第６行目のアクションタグの記述において、event プロパティが“”form.submit” ”に指定されている。この記述は、nameプロパティが”form”に指定されているコンテナタグについてのアクションタグであることを示している。

このようなプロパティの指定がなされているコンテナタグについては、図３９及び図４０に示されているコンテンツ変換処理において、図３９のＳ４２０３の処理であるアクションタグの登録が、コンポーネントタグの代わりにコンテナタグに対して行なわれるようにする。更に、図４０のＳ４２１３の処理におけるコンテナタグについての記述内容の出力の際に、Ｓ４２０７からＳ４２１０にかけてのコンポーネントタグに対して行なわれる処理がコンテナタグに対して施されるようにする。こうすることにより、図４４（Ｂ）の第１４行目（（ａ）の行）が生成されるようになり、コンテナタグで発生するイベントに対してスクリプトを実行させることが可能となる。

以上まで説明した本発明の各実施例を実施するシステムで使用される、サーバの各処理エンジン及びクライアントの構成を図４５に示す。これらはいずれも、ＣＰＵ５００１、記憶部５００２、入力部５００３、出力部５００４、Ｉ／Ｆ部５００５を有し、各構成要素がバス５００６を介して相互に接続されている。

各構成要素の機能を説明すると、ＣＰＵ（中央処理装置）５００１は制御プログラムを実行することで各構成要素を制御する。
記憶部５００２はＲＯＭ（リードオンリメモリ）やＲＡＭ（ランダムアクセスメモリ）、磁気記憶装置等を備えており、ＣＰＵ５００１に各構成要素を制御させる制御プログラムの記憶、ＣＰＵ５００１が制御プログラムを実行する際のワークエリア、あるいは各種データの記憶領域として使用される。

入力部５００３はマウスやキーボード等を有しており、ユーザによる操作に対応する各種のデータが取得される。
出力部５００４はディスプレイなどを有しており、各種のデータを提示してユーザに通知するものである。

Ｉ／Ｆ部５００５はネットワークに接続するためのインタフェース機能を提供するものであり、ネットワークを介して他の機器とのデータ授受を可能とするものである。
なお、この図４５に示されている構成は、標準的なコンピュータが有しているものと同様の構成であり、従って、本発明を標準的なコンピュータで実施することも勿論可能である。

図４６は、本発明に係わるコンピュータ等の情報処理装置で実行される各種のソフトウェアプログラム等の提供方法を説明する図である。プログラム等は例えば以下の（ａ）〜（ｃ）の３つの方法の中の任意の方法により提供される。

( ａ) コンピュータ等の情報処理装置５３０１にインストールされて提供される。この場合、プログラム等は例えば出荷前にプレインストールされる。
( ｂ) 可搬型記録媒体５３０２に格納されて提供される。この場合、可搬型記憶媒体５３０２に格納されているプログラム等は、コンピュータ等の情報処理装置２３０１の外部記憶装置にインストールされる。可搬型記憶媒体５３０２の例としては、フロッピー（登録商標）ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、ＤＶＤ−ＲＯＭなどがある。

( ｃ) ネットワーク５３０３上のプログラム提供サーバ５３０４から提供される。この場合、基本的には、コンピュータなどの情報処理装置５３０１がプログラム提供サーバ５３０４に格納されているプログラム等をダウンロードすることによって、そのプログラム等を取得する。この場合には、ソフトウェアプログラムを表現するデータ信号で搬送波を変調して得られる伝送信号を、プログラム提供サーバ５３０４から伝送媒体であるネットワーク５３０３を通じて伝送し、情報処理装置５３０１では受信した伝送信号を復調してソフトウェアプログラムを再生することで当該ソフトウェアプログラムの実行が可能となる。

（付記１） クライアントからのリクエストをサーバで処理し、クライアントにレスポンスを返すＷｅｂシステムであって、
前記サーバで、前記リクエストをデータオブジェクトに変換して処理し、処理結果であるデータオブジェクトを前記クライアントへのレスポンスに変換して返すことを特徴とするＷｅｂシステム。

（付記２） Ｗｅｂアプリケーションを開発・実行するためのシステムであって、
入力内容をデータオブジェクトに変換する入力内容変換手段と、
複数の処理ルーチンを備える処理ロジックと、
前記データオブジェクトの種類とコマンドの組合せを前記各処理ルーチンにマッピングする第１の外部定義ファイルと、
前記データオブジェクトの種類と前記コマンドと前記第１の外部定義ファイルに基づいて前記処理ロジックの備える処理ルーチンから適当な処理ルーチンを決定する処理ルーチン決定手段と、
を備えることを特徴とするＷｅｂアプリケーション開発・実行システム。

（付記３） 付記２記載のＷｅｂアプリケーション開発・実行システムであって、
前記入力内容変換手段は、ＨＴＭＬで記述されたデータ入力ページの特定項目を前記データオブジェクトのクラス名とし、該データ入力用ページに設けられている各入力欄の名前を前記データオブジェクトの属性に対応させて、データオブジェクト用プログラムを自動生成することを特徴とするＷｅｂアプリケーション開発・実行システム。

（付記４） Ｗｅｂアプリケーションを開発・実行するためのシステムであって、
複数の処理ルーチンを備える処理ロジックと、
前記処理ロジックの処理結果とデータオブジェクトの種類の組み合わせを表示用コンポーネントにマッピングする第２の外部定義ファイルと、
を備えることを特徴とするＷｅｂアプリケーション開発・実行システム。

（付記５） 付記４記載のＷｅｂアプリケーション開発・実行システムであって、
更に、
表示するページに配置する複数の表示用コンポーネントの配置の仕方を規定したテンプレートファイルを備え、
前記テンプレートファイルに基づいて複数の前記処理ロジックの処理結果を出力することを特徴とするＷｅｂアプリケーション開発・実行システム。

（付記６） 付記２記載のＷｅｂアプリケーション開発・実行システムであって、
更に、
ＸＭＬのタグとデータオブジェクトをマッピングするＸＭＬマッピングファイルと、
ＸＭＬのタグとデータオブジェクトとの相互変換を行うＸＭＬ Ｄａｔａ Ｂｉｎｄｉｎｇエンジンを備え、
前記入力内容としてＸＭＬで記述されたタグを受信した場合に、
前記ＸＭＬ Ｄａｔａ Ｂｉｎｄｉｎｇエンジンは、前記受信したＸＭＬのタグと前記ＸＭＬマッピングファイルに基づいて、前記受信したＸＭＬを前記データオブジェクトに変換し、
前記処理ルーチン決定手段は、前記データオブジェクトと前記受信したＸＭＬのタグと前記第１の外部定義ファイルに基づいて前記処理ロジック内の処理ルーチンから適当な処理ルーチンを決定し、
前記ＸＭＬ Ｄａｔａ Ｂｉｎｄｉｎｇエンジンは、前記処理ロジックの処理結果として得られるデータオブジェクトをＸＭＬのタグに変換して出力する、
ことを特徴とするＷｅｂアプリケーション開発・実行システム。

（付記７） 付記６記載のＷｅｂアプリケーション開発・実行システムであって、
前記ＸＭＬマッピングファイルは、或るＨＴＴＰによるデータと同一の処理を施すＸＭＬのタグを、前記或るＨＴＴＰによるデータと同一種類のデータオブジェクトにマッピングすることを特徴とするＷｅｂアプリケーション開発・実行システム。

（付記８） 付記２記載のＷｅｂアプリケーション開発・実行システムであって、
前記処理ロジックにおける各処理ルーチンは、時間的スコープの大きな順にシステム、アプリケーション、セッション、リクエストの４段階のうちのいずれかの前記スコープに属性定義されており、
前記処理ロジックが処理を行う場合には、より大きなスコープからより小さなスコープに分岐して処理を進めていくことを特徴とするＷｅｂアプリケーション開発・実行システム。

（付記９） 付記８記載のＷｅｂアプリケーション開発・実行システムであって、
いずれかのの前記スコープが属性定義されている前記処理ルーチンに前処理または後処理のインタフェースを設けることを特徴とするＷｅｂアプリケーション開発・実行システム。

（付記１０） 付記９記載のＷｅｂアプリケーション開発・実行システムであって、
前記前処理のインタフェースに状態の制御を行うためのチェックルーチンを設けること
を特徴とするＷｅｂアプリケーション開発・実行システム。

（付記１１） 付記９記載のＷｅｂアプリケーション開発・実行システムであって、
前記後処理のインタフェースに前記スコープが属性定義されている前記処理ルーチンごとのエラーを回復させるためのエラーハンドリング処理を設けることを特徴とするＷｅｂアプリケーション開発・実行システム。

（付記１２） 付記８記載のＷｅｂアプリケーション開発・実行システムであって、
前記スコープが属性定義されている前記処理ルーチンのいずれかにシングルスレッド動作制限を設けることを特徴とするＷｅｂアプリケーション開発・実行システム。

（付記１３） コンピュータにより使用されたときにそれによって読み出されるプログラムを記録した記録媒体であって、
入力内容をデータオブジェクトに変換するステップと、
前記データオブジェクトの種類と、コマンドと、前記データオブジェクトの種類とコマンドの組合せを各処理ルーチンにマッピングする外部定義ファイルと、に基づいて処理ロジック内の処理ルーチンから適当な処理ルーチンを決定するステップと、
を前記コンピュータに行わせるためのプログラムを記録したコンピュータ読み出し可能記録媒体。

（付記１４） クライアントからのリクエストをサーバで処理し、クライアントにレスポンスを返すＷｅｂシステムであって、
前記サーバで前記リクエストに応じて処理される各オブジェクトは、各々が処理されるときの時間軸上における相対的な位置関係に基づいた時間的スコープについての属性定義がされており、
前記サーバは、より大きな時間的スコープが定義されているオブジェクトから小さな時間的スコープが定義されているオブジェクトに分岐して前記リクエストに応じたオブジェクトの処理を進めていくことを特徴とするＷｅｂシステム。

（付記１５） 付記１４記載のＷｅｂシステムであって、
各オブジェクトには、時間的スコープの大きな順に、システム、アプリケーション、セッション、リクエストのうちのいずれかのスコープの属性定義がなされることを特徴とするＷｅｂシステム。

（付記１６） クライアントからのリクエストをサーバで処理し、クライアントにレスポンスを返すＷｅｂシステムであって、
サーバでの処理ルーチン呼び出し時に該処理ルーチンによる処理の動作を監視し、該処理の進行を継続させるオブジェクトを該サーバで実行することを特徴とするＷｅｂシステム。

（付記１７） クライアントとの間で各種のデータを授受するサーバ側に設けられ、該クライアントに提供するデータが表示されるＷｅｂページ画面を表現するＨＴＭＬ文を生成するＷｅｂアプリケーション生成装置であって、
前記クライアントに提供するデータを有し、且つ該データのデータ構造を表すインタフェースを実装するデータオブジェクトが格納されるデータオブジェクト格納手段と、
前記データオブジェクトが有するデータについての前記Ｗｅｂページ画面における表示方法をＨＴＭＬによる記述によって定義する定義文が格納される定義文格納手段と、
前記データオブジェクトに実装されている前記インタフェースに基づいて該データオブジェクトの有するデータと前記定義文とを関連付けることによって、該データが表示されるＷｅｂページ画面を表現するＨＴＭＬ文を生成するＨＴＭＬ文生成手段と、
を有することを特徴とするＷｅｂアプリケーション生成装置。

（付記１８） 付記１７記載のＷｅｂアプリケーション生成装置であって、
前記定義文はＪａｖａＳｅｒｖｅｒ Ｐａｇｅｓ（ＪＳＰ）によって定義され、
前記ＨＴＭＬ文生成手段は、ＪＳＰによって定義された定義文から前記ＨＴＭＬ文を生成する、
ことを特徴とするＷｅｂアプリケーション生成装置。

（付記１９） 付記１７記載のＷｅｂアプリケーション生成装置であって、
前記データ構造に対応して定義される属性であるデータクラスを取得するデータクラス取得手段を更に有し、
前記ＨＴＭＬ文生成手段は、前記データクラスに基づいて前記データオブジェクトの有するデータに関連付ける前記定義文を選択する、
ことを特徴とするＷｅｂアプリケーション生成装置。

（付記２０） 付記１７記載のＷｅｂアプリケーション生成装置であって、
前記ＨＴＭＬ文生成手段により生成されたＨＴＭＬ文によって表現されるＷｅｂページ画面に示されている入力フォームへの入力データを含むリクエストであって前記クライアントから送付される該リクエストを取得するリクエスト取得手段と、
前記リクエストに前記データと共に含まれている、前記ＨＴＭＬ文生成手段により生成されたＨＴＭＬ文に含まれていた文字列であって、該ＨＴＭＬ文の生成の基礎とされたインタフェースを特定する文字列と該インタフェースにより表されるデータ構造における特定の位置を示す文字列とからなる該文字列に基づいて、該文字列で特定されるインタフェースにより表されるデータ構造における特定の位置のデータを該リクエストに含まれていたデータに更新するデータ更新手段と、
を更に有することを特徴とするＷｅｂアプリケーション生成装置。

（付記２１） 付記２０記載のＷｅｂアプリケーション生成装置であって、
前記リクエストに前記データと共に含まれている文字列は、該入力フォームに対して入力されるデータを参照するパラメータ名を示すことを特徴とするＷｅｂアプリケーション生成装置。

（付記２２） 付記２０記載のＷｅｂアプリケーション生成装置であって、
前記リクエストには、異なるインタフェースに基づいて生成されたＨＴＭＬ文についての前記データ及び前記文字列が含まれることを特徴とするＷｅｂアプリケーション生成装置。

（付記２３） 付記２０記載のＷｅｂアプリケーション生成装置であって、
前記データ更新手段は、前記データオブジェクト格納手段に格納されているデータオブジェクトの有する前記データを前記リクエストに含まれていたデータに更新することを特徴とするＷｅｂアプリケーション生成装置。

（付記２４） 付記２０記載のＷｅｂアプリケーション生成装置であって、
前記リクエストに前記データと共に含まれている文字列は、前記ＨＴＭＬ文の生成の基礎とされたインタフェースを特定する文字列と該インタフェースにより表されるデータ構造における特定の位置を示す文字列とからなる文字列に、更に該位置のデータ群が有するデータ構造を表すインタフェースを特定する文字列と該インタフェースにより表されるデータ構造における特定の位置を示す文字列とからなる文字列を組み合わせて成り、
前記データ更新手段は、前記文字列で特定されるデータ構造における特定の位置に更に有しているデータ構造における特定の位置のデータを前記リクエストに含まれていたデー
タに更新する、
ことを特徴とするＷｅｂアプリケーション生成装置。

（付記２５） クライアントとの間で各種のデータを授受するサーバ側で、該クライアントに提供するデータが表示されるＷｅｂページ画面を表現するＨＴＭＬ文を生成する方法であって、
前記クライアントに提供するデータを有し、且つ該データのデータ構造を表すインタフェースを実装するデータオブジェクトを取得し、
前記データオブジェクトが有するデータについての前記Ｗｅｂページ画面における表示方法をＨＴＭＬによる記述によって定義する定義文を取得し、
前記データオブジェクトに実装されている前記インタフェースに基づいて該データオブジェクトの有するデータと前記定義文とを関連付けることによって、該データが表示されるＷｅｂページ画面を表現するＨＴＭＬ文を生成する、
を有することを特徴とするＷｅｂアプリケーション生成方法。

（付記２６） クライアントとの間で各種のデータを授受するサーバ側で、コンピュータに実行させることによって、該クライアントに提供するデータが表示されるＷｅｂページ画面を表現するＨＴＭＬ文を生成する制御を該コンピュータに行なわせる制御プログラムを記録した記録媒体であって、
前記クライアントに提供するデータを有し、且つ該データのデータ構造を表すインタフェースを実装するデータオブジェクトを取得する制御と、
前記データオブジェクトが有するデータについての前記Ｗｅｂページ画面における表示方法をＨＴＭＬによる記述によって定義する定義文を取得する制御と、
前記データオブジェクトに実装されている前記インタフェースに基づいて該データオブジェクトの有するデータと前記定義文とを関連付けることによって、該データが表示されるＷｅｂページ画面を表現するＨＴＭＬ文を生成する制御と、
をコンピュータに行なわせる制御プログラムを記憶した記憶媒体。

（付記２７） クライアントとの間で各種のデータを授受するサーバ側で、コンピュータに実行させることによって、該クライアントに提供するデータが表示されるＷｅｂページ画面を表現するＨＴＭＬ文を生成する制御を該コンピュータに行なわせる制御プログラムを含む搬送波に具現化されたコンピュータ・データ・シグナルであって、該制御プログラムは、
前記クライアントに提供するデータを有し、且つ該データのデータ構造を表すインタフェースを実装するデータオブジェクトを取得する制御と、
前記データオブジェクトが有するデータについての前記Ｗｅｂページ画面における表示方法をＨＴＭＬによる記述によって定義する定義文を取得する制御と、
前記データオブジェクトに実装されている前記インタフェースに基づいて該データオブジェクトの有するデータと前記定義文とを関連付けることによって、該データが表示されるＷｅｂページ画面を表現するＨＴＭＬ文を生成する制御と、
をコンピュータに行なわせる。

（付記２８） クライアントとの間で各種のデータを授受するサーバ側に設けられ、該クライアントに提供するデータが表示されるＷｅｂページ画面を表現するＨＴＭＬ文を生成するＷｅｂアプリケーション生成装置であって、
処理の内容が定義されている処理ロジックが格納される処理ロジック格納手段と、
前記処理ロジックの実行条件が格納される実行条件格納手段と、
前記処理ロジックの名称となる文字列を生成する処理ロジック名生成手段と、
前記文字列を用いて前記処理ロジックを呼び出すＨＴＭＬ文であって、前記実行条件に合致するイベントが前記クライアントで発生したときに該処理ロジックを呼び出して実行
する、という処理を該クライアントに行なわせる該ＨＴＭＬ文を生成するＨＴＭＬ文生成手段と、
を有することを特徴とするＷｅｂアプリケーション生成装置。

（付記２９） 付記２８記載のＷｅｂアプリケーション生成装置であって、
前記処理ロジックはスクリプトによって定義されていることを特徴とするＷｅｂアプリケーション生成装置。

（付記３０） 付記２８記載のＷｅｂアプリケーション生成装置であって、
前記処理ロジック格納手段及び前記実行条件格納手段には、前記処理ロジック及び前記実行条件が共に定義されている同一のコンポーネントにおける該処理ロジック及び該実行条件がそれぞれ格納されることを特徴とするＷｅｂアプリケーション生成装置。

（付記３１） 付記２８記載のＷｅｂアプリケーション生成装置であって、
前記処理ロジック格納手段には複数の前記処理ロジックが格納され、
複数の前記処理ロジックのそれぞれの前記実行条件のうちのいずれかが同一であるときに、該実行条件が同一である該処理ロジックを順に実行する処理ロジックを生成する処理ロジック生成手段を更に有し、
前記文字列生成手段は、複数の前記処理ロジック、及び前記処理ロジック生成手段により生成された処理ロジックに対して各々異なる名称となる文字列を生成し、
前記ＨＴＭＬ文生成手段は、前記文字列を用いて前記処理ロジック生成手段により生成された処理ロジックを呼び出すＨＴＭＬ文であって、同一であった前記実行条件に合致するイベントが前記クライアントで発生したときに該処理ロジックを呼び出して実行する、という処理を該クライアントに行なわせる該ＨＴＭＬ文を生成する、
ことを特徴とするＷｅｂアプリケーション生成装置。

（付記３２） 付記２８記載のＷｅｂアプリケーション生成装置であって、
前記処理ロジックと該処理ロジックの実行条件との対応関係の妥当性を確認する確認手段を更に有することを特徴とするＷｅｂアプリケーション生成装置。

（付記３３） クライアントとの間で各種のデータを授受するサーバ側で、該クライアントに提供するデータが表示されるＷｅｂページ画面を表現するＨＴＭＬ文を生成するＷｅｂアプリケーション生成方法であって、
処理の内容が定義されている処理ロジックであって、予め用意されている該処理ロジックの名称となる文字列を生成し、
前記文字列を用いて前記処理ロジックを呼び出すＨＴＭＬ文であって、前記処理ロジックについての実行条件であって予め用意されている該実行条件に合致するイベントが前記クライアントで発生したときに該処理ロジックを呼び出して実行する、という処理を該クライアントに行なわせる該ＨＴＭＬ文を生成する、
ことを特徴とするＷｅｂアプリケーション生成方法。

（付記３４） クライアントとの間で各種のデータを授受するサーバ側で、コンピュータに実行させることによって、該クライアントに提供するデータが表示されるＷｅｂページ画面を表現するＨＴＭＬ文を生成する制御を該コンピュータに行なわせる制御プログラムを記録した記録媒体であって、
処理の内容が定義されている処理ロジックであって、予め用意されている該処理ロジックの名称となる文字列を生成する制御と、
前記文字列を用いて前記処理ロジックを呼び出すＨＴＭＬ文であって、前記処理ロジックについての実行条件であって予め用意されている該実行条件に合致するイベントが前記クライアントで発生したときに該処理ロジックを呼び出して実行する、という処理を該ク
ライアントに行なわせる該ＨＴＭＬ文を生成する制御と、
をコンピュータに行なわせる制御プログラムを記憶した記憶媒体。

（付記３５） クライアントとの間で各種のデータを授受するサーバ側で、コンピュータに実行させることによって、該クライアントに提供するデータが表示されるＷｅｂページ画面を表現するＨＴＭＬ文を生成する制御を該コンピュータに行なわせる制御プログラムを含む搬送波に具現化されたコンピュータ・データ・シグナルであって、該制御プログラムは、
処理の内容が定義されている処理ロジックであって、予め用意されている該処理ロジックの名称となる文字列を生成する制御と、
前記文字列を用いて前記処理ロジックを呼び出すＨＴＭＬ文であって、前記処理ロジックについての実行条件であって予め用意されている該実行条件に合致するイベントが前記クライアントで発生したときに該処理ロジックを呼び出して実行する、という処理を該クライアントに行なわせる該ＨＴＭＬ文を生成する制御と、
をコンピュータに行なわせる。

（付記３６） コンピュータに、
入力内容をデータオブジェクトに変換するステップと、
前記データオブジェクトの種類と、コマンドと、前記データオブジェクトの種類とコマンドの組合せを各処理ルーチンにマッピングする外部定義ファイルと、に基づいて処理ロジック内の処理ルーチンから適当な処理ルーチンを決定するステップと、
を実行させるためのプログラム。

（付記３７） クライアントとの間で各種のデータを授受するサーバ側で、コンピュータに実行させることによって、該クライアントに提供するデータが表示されるＷｅｂページ画面を表現するＨＴＭＬ文を生成する制御を該コンピュータに行なわせる制御プログラムであって、
前記クライアントに提供するデータを有し、且つ該データのデータ構造を表すインタフェースを実装するデータオブジェクトを取得する制御と、
前記データオブジェクトが有するデータについての前記Ｗｅｂページ画面における表示方法をＨＴＭＬによる記述によって定義する定義文を取得する制御と、
前記データオブジェクトに実装されている前記インタフェースに基づいて該データオブジェクトの有するデータと前記定義文とを関連付けることによって、該データが表示されるＷｅｂページ画面を表現するＨＴＭＬ文を生成する制御と、
をコンピュータに行なわせるための制御プログラム。

（付記３８） クライアントとの間で各種のデータを授受するサーバ側で、コンピュータに実行させることによって、該クライアントに提供するデータが表示されるＷｅｂページ画面を表現するＨＴＭＬ文を生成する制御を該コンピュータに行なわせる制御プログラムであって、
処理の内容が定義されている処理ロジックであって、予め用意されている該処理ロジックの名称となる文字列を生成する制御と、
前記文字列を用いて前記処理ロジックを呼び出すＨＴＭＬ文であって、前記処理ロジックについての実行条件であって予め用意されている該実行条件に合致するイベントが前記クライアントで発生したときに該処理ロジックを呼び出して実行する、という処理を該クライアントに行なわせる該ＨＴＭＬ文を生成する制御と、
をコンピュータに行なわせるための制御プログラム。

本発明の概略を示す図である。 本発明の原理構成を示す図である。 本発明の第１の実施例のシステム構成を示す図である。 本発明の第１の実施例のシステムの具体的な動作の様子を示す図である。 図４に示すアプリケーションのシステム構成とその動作（クライアントからのリクエストを受信し、処理するまで）概要を説明する図である。 図４に示すアプリケーションのシステム構成とその動作（クライアントへレスポンスを返すまで）概要を説明する図である。 （а）、（ｂ）はコマンドマッピングの一部、（ｃ）はページマッピングの一部を示す図である。 クライアントからのリクエストデータを入力用Ｊａｖａ Ｂｅａｎに変換するプログラム記述を示す図である。 コマンドマッピングを介して実行すべきロジックの処理を決定するプログラム記述を示す図である。 ユーザロジックが表示用データオブジェクトを設定するプログラム記述を示す図である。 ページマッピングを介して表示すべきページを決定するプログラム記述を示す図である。 ＪＳＰから表示画面を出力するプログラム記述を示す図である。 表示画面に複数の表示部品を配置する場合のテンプレートについて説明する図である。 本発明の第２の実施例のシステム構成を示す図（その１）である。 本発明の第２の実施例のシステム構成を示す図（その２）である。 ＸＭＬファイルを処理するシステムの動作（ＸＭＬファイルを受信して、処理するまで）概要を示す図である。 ＸＭＬファイルを処理するシステムの動作（ＸＭＬファイルを受信した時に、処理結果を返すまで）概要を示す図である。 （а）は、本発明のシステムを構成するオブジェクトのスコープを説明する図であり、（ｂ）はオブジェクト間の相関関係を示す図である。 （а）は、クライアントからのリクエスト処理を説明する図であり、（ｂ）はSingleThreadModel の実装を説明する図である。 （а）は、SingleThreadModel の具体的な実装を示す図であり、（ｂ）はSingleThreadModel の実装のプログラム記述例を示す図である。 クライアントのリクエストを処理する場合のシーケンス図である。 （а）は、一般のアプリケーションサーバにおいてロジックのハンドラからブラウザにコールバックする仕組みを説明する図であり、（ｂ）はそのプログラム記述例を示す図である。 （а）は、本発明のアプリケーションサーバにおいてロジックのハンドラからブラウザにリクエストを行う仕組みを説明する図であり、（ｂ）、（ｃ）はそのプログラム記述例を示す図である。 本発明の第３の実施例のシステム構成を示す図である。 テーブルモデルインタフェースの宣言例を示す図である。 本発明の第３の実施例において、ＨＴＭＬ文が生成される様子を説明する図である。 表示時の制御処理の処理内容を示すフローチャート（その１）である。 表示時の制御処理の処理内容を示すフローチャート（その２）である。 表示時の制御処理の処理内容を示すフローチャート（その３）である。 <name>のレンダラエレメントタグを説明する図である。 <name>のレンダラエレメントタグを使用したレンダラの定義例を示す図である。 記憶領域管理処理の処理内容を示すフローチャートである。 図２４に示すシステムにおけるリクエスト時の動作の概要を説明する図である。 リクエスト時の制御処理の処理内容を示すフローチャートである。 本発明の第３の実施例を実施するクライアントサーバシステムの例を示す図である。 本発明の第４の実施例によってＨＴＭＬ文が生成される様子を示す図である。 本発明の第４の実施例で使用されるオブジェクトの構成を示す図である。 コンテンツ変換処理の概要を説明する図である。 コンテンツ変換処理の処理内容を示すフローチャート（その１）である。 コンテンツ変換処理の処理内容を示すフローチャート（その２）である。 処理スクリプトを別に用意する場合のスクリプト記述例を示す図である。 文字列の最小文字数をチェックする処理スクリプトの定義例を示す図である。 同一のイベントに対して複数のアクションが対応する場合のスクリプト記述例を示す図である。 コンテナタグでイベントが発生する場合のスクリプト記述例を示す図である。 本発明の各実施例を実施するシステムに使用される、サーバの各処理エンジン及びクライアントの構成を示す図である。 本発明に係わるソフトウェアプログラム等の提供方法を説明する図である。 ビジネスアプリケーションの実施形態を示す図である。 Ｓｅｒｖｌｅｔを用いたアプリケーションサーバのシステム構成を示す図である。 ＪＳＰを用いたアプリケーションサーバのシステム構成を示す図である。

符号の説明

１０１ ＨＴＭＬ
１０２ 画面データ
１０３ ロジック
２０１ 入力用ＪＳＰ
２０２ 表示用ＪＳＰ
２０３ 入力用Ｊａｖａ Ｂｅａｎ
２０４ 表示用Ｊａｖａ Ｂｅａｎ
２０５ ユーザロジック
２０６ ＵＪＩエンジン
２０７ マッピングファイル
３０１ ＨＴＴＰリクエスト
３０２ フロントコンポーネント
３０３ 入力用Ｊａｖａ Ｂｅａｎ
３０４ ＵＪＩエンジン
３０５ コマンドマッピング
３０６ ページマッピング
３０７ ユーザロジック
３０８ テンプレート
３０９ 表示用Ｊａｖａ Ｂｅａｎ
３１０ 表示用ＪＳＰ
４０１ ユーザ一覧表示画面
４０２ ユーザ状態編集画面
４０３ プロファイル編集画面
４０４ ユーザ登録画面
４０５ ログインボタン
４０６ ユーザ登録ボタン
４０７ 変更ボタン
４０８ ログアウトボタン
４０９ プロファイル編集ボタン
４１０ 変更ボタン
４１１ 戻るボタン
４１２ 変更ボタン
４１３ 戻るボタン
５０１ ユーザ一覧表示画面
５０２ ユーザ状態編集画面
５０３ プロファイル編集画面
５０４ ユーザ登録画面
５０５ Ｊａｖａ Ｂｅａｎ（自動生成）
５０６ ＵＪＩ
５０７ コマンドマッピング
５０８ ログイン処理
５０９ ログアウト処理
５１０ ユーザ状態変更処理
５１１ プロファイル変更処理
５１２ ユーザ登録処理
６０１ Ｊａｖａ Ｂｅａｎ（処理内で作成）
６０２ ページマッピング
８０１ データ入力用ＨＴＭＬページ
８０２ 入力用Ｊａｖａ Ｂｅａｎ
９０１ データ入力用ＨＴＭＬページ
９０２ コマンドマッピング
９０３ ユーザロジック（ハンドラ）
１００１ ユーザロジック（ハンドラ）
１００２ データベース
１００３ 表示用Ｊａｖａ Ｂｅａｎ
１１０１ 表示用Ｊａｖａ Ｂｅａｎ
１１０２ ページマッピング
１１０３ login-succeded.jsp
１１０４ login-failed.jsp
１２０１ 表示用ＪＳＰ
１２０２ 表示用Ｊａｖａ Ｂｅａｎ
１２０３ 出力ＨＴＭＬ
１３０１ ユーザロジック（ハンドラ）
１３０２ 表示用Ｊａｖａ Ｂｅａｎ（バナー用）
１３０３ 表示用Ｊａｖａ Ｂｅａｎ（メニュー用）
１３０４ 表示用Ｊａｖａ Ｂｅａｎ（コンテンツ用）
１３０５ テンプレート
１３０６ 出力用ＨＴＭＬ
１４０１ ＸＭＬインスタンス
１４０２ コマンドマッピング
１４０３ ＵＪＩエンジン
１４０４ ＸＭＬ Ｄａｔａ Ｂｉｎｄｉｎｇエンジン
１４０５ Ｂｅａｎインスタンス
１５０１ ロジック（ハンドラ）
１５０２ 送信用のデータオブジェクト
１５０３ 送信ＸＭＬインスタンス
１６０１ 注文伝票ＸＭＬ
１６０２ 出荷伝票ＸＭＬ
１６０３ ＵＪＩ
１６０４ ＸＭＬ Ｄａｔａ Ｂｉｎｄｉｎｇエンジン
１６０５ Ｊａｖａ Ｂｅａｎ
１６０６ ＸＭＬマップファイル
１６０７ コマンドマッピング
１６０８ 注文処理
１６０９ 出荷処理
１６１０ 処理
１７０１ Ｊａｖａ Ｂｅａｎ
１７０２ 送信ＸＭＬ
１８０１ システム
１８０２ アプリケーション
１８０３ セッション
１８０４ リクエスト
１８０５ ハンドラ
１９０１ フロントコンポーネント
１９０２ ディスパッチャ
１９０３ アプリケーション
１９０４ セッション
１９０５ ハンドラ
１９０６ 表示用ページ
１９０７ Ｄｉｓｐａｔｃｈ Ｃｏｎｔｅｘｔ
１９０８ ＲｅｓｐｏｎｓｅＢｅａｎ
１９０９ コマンドマップ
１９１０ ページマップ
１９１１ ＲｅｑｕｅｓｔＢｅａｎ
１９１２ ＳｉｎｇｌｅＴｈｒｅａｄＭｏｄｅｌ
２００１ システム
２００２ アプリケーション
２００３ セッション
２００４ ハンドラ
２００５ ログイン処理メソッド
２００６ ログアウト処理メソッド
２００７ ユーザ変更メソッド
２００８ プロファイル編集メソッド
２００９ ユーザ登録メソッド
３００１ モデルオブジェクト
３００１ａ 表示用モデルオブジェクト
３００１ｂ 入力用モデルオブジェクト
３００２ モデルインタフェース
３００３ フレームワークエンジン
３００４ 表示用ＪＳＰ
３００５ ブラウザ
３００６ フロントコンポーネント
３０１０ サーバ
３０１１ モデルフレームワーク処理部
３０１２ Ｗｅｂサーバ部
３０１３ バックエンド
３０１４ データベース
３０２０ａ、３０２０ｂ、３０２０ｃ クライアント
４００１、４１０１ コンポーネントオブジェクト
４００２、４１０２ コンテナオブジェクト
４００３、４１０３ アクションオブジェクト
４００４、４１０４ スクリプト呼び出し部
４０１１ ValidInputTag オブジェクト
４０１２ ValidFormTagオブジェクト
４０１３ａ CustomActionTag オブジェクト
４０１３ｂ MyActionTag オブジェクト
５００１ ＣＰＵ
５００２ 記憶部
５００３ 入力部
５００４ 出力部
５００５ Ｉ／Ｆ部
５００６ バス
５３０１ 情報処理装置（コンピュータ）
５３０２ 可搬型記録媒体
５３０３ ネットワーク
５３０４ プログラム提供サーバ
５４０１ アプリケーションサーバ
５４０２ データベースサーバ
５４０３ クライアント
５５０１ ＨＴＭＬ
５５０２ 画面データ
５５０３ ロジック
５６０１ ＨＴＭＬ
５６０２ 画面データ
５６０３ データ

Claims (7)

1. ネットワークを介して接続されているクライアント装置との間で各種のデータを授受するサーバ装置側に設けられ、該クライアント装置に提供するデータが表示されるＷｅｂページ画面を表現しているＨＴＭＬ文を生成するＷｅｂアプリケーション生成装置であって、
   前記クライアント装置に提供するデータを有しているデータオブジェクトであって、且つ該データのデータ構造を表すインタフェースを実装している該データオブジェクトが格納されるデータオブジェクト格納手段と、
   前記データオブジェクトが有するデータについての前記Ｗｅｂページ画面における表示方法をＨＴＭＬによる記述によって前記データ構造毎に定義している定義文が格納される定義文格納手段と、
   前記データオブジェクト格納手段に前記データオブジェクトが格納されたときに、該データオブジェクトに実装されている前記インタフェースで表されているデータ構造に基づいて該データオブジェクトの有するデータと前記定義文格納手段に格納されている定義文とを関連付けることによって、該データが表示されるＷｅｂページ画面を表現するＨＴＭＬ文を生成するＨＴＭＬ文生成手段と、
   を有することを特徴とするＷｅｂアプリケーション生成装置。
2. 請求項１記載のＷｅｂアプリケーション生成装置であって、
   前記データ構造に対応して定義される属性であるデータクラスを取得するデータクラス取得手段を更に有し、
   前記ＨＴＭＬ文生成手段は、前記データクラスに基づいて前記データオブジェクトの有するデータと前記定義文格納手段に格納されている定義文とを関連付ける、
   ことを特徴とするＷｅｂアプリケーション生成装置。
3. 請求項１記載のＷｅｂアプリケーション生成装置であって、
   前記ＨＴＭＬ文生成手段により生成されたＨＴＭＬ文を前記クライアント装置へ送付した後に前記クライアント装置から送付されてくるリクエストであって該ＨＴＭＬ文によって表現されているＷｅｂページ画面に示されている入力フォームへの入力データを含むリクエストを取得するリクエスト取得手段と、
   前記リクエストに前記入力データと共に含まれている、前記ＨＴＭＬ文生成手段により生成されたＨＴＭＬ文に含まれていた文字列であって、該ＨＴＭＬ文の生成の基礎とされたインタフェースを特定する文字列と該インタフェースにより表されるデータ構造における特定の位置を示す文字列とからなる該文字列に基づいて、該文字列で特定されるインタフェースにより表されるデータ構造における特定の位置のデータを該リクエストに含まれていたデータに更新するデータ更新手段と、
   を更に有することを特徴とするＷｅｂアプリケーション生成装置。
4. 請求項３記載のＷｅｂアプリケーション生成装置であって、
   前記リクエストに前記入力データと共に含まれている文字列は、前記ＨＴＭＬ文の生成の基礎とされたインタフェースを特定する文字列と該インタフェースにより表されるデータ構造における特定の位置を示す文字列とからなる文字列に、更に該位置のデータ群が有するデータ構造を表すインタフェースを特定する文字列と該インタフェースにより表されるデータ構造における特定の位置を示す文字列とからなる文字列を組み合わせて成り、
   前記データ更新手段は、前記文字列で特定されるデータ構造における特定の位置に更に有しているデータ構造における特定の位置のデータを前記リクエストに含まれていたデータに更新する、
   ことを特徴とするＷｅｂアプリケーション生成装置。
5. ネットワークを介して接続されているクライアント装置との間で各種のデータを授受するサーバ装置側に設けられるＷｅｂアプリケーション生成装置において行われる、該クライアント装置に提供するデータが表示されるＷｅｂページ画面を表現しているＨＴＭＬ文を生成する方法であって、
   前記クライアント装置に提供するデータを有しているデータオブジェクトであって、且
   つ該データのデータ構造を表すインタフェースを実装するデータオブジェクトを前記Ｗｅｂアプリケーション生成装置が取得して該Ｗｅｂアプリケーション生成装置の有する記憶部に記憶し、
   前記データオブジェクトが有するデータについての前記Ｗｅｂページ画面における表示方法をＨＴＭＬによる記述によって前記データ構造毎に定義している定義文を前記Ｗｅｂアプリケーション生成装置が取得して該Ｗｅｂアプリケーション生成装置の有する記憶部に記憶し、
   前記Ｗｅｂアプリケーション生成装置の有する記憶部から前記データオブジェクトを読み出して該データオブジェクトに実装されている前記インタフェースで表されているデータ構造に基づいて該データオブジェクトの有するデータと該Ｗｅｂアプリケーション生成装置の有する記憶部に格納されている定義文とを関連付けることによって、該データが表示されるＷｅｂページ画面を表現するＨＴＭＬ文を生成する、
   ことを特徴とするＷｅｂアプリケーション生成方法。
6. ネットワークを介して接続されているクライアント装置との間で各種のデータを授受するサーバ装置側に設けられるコンピュータに、該クライアント装置に提供するデータが表示されるＷｅｂページ画面を表現しているＨＴＭＬ文を生成する制御を行わせるための制御プログラムを記録した記録媒体であって、
   前記クライアント装置に提供するデータを有しているデータオブジェクトであって、且つ該データのデータ構造を表すインタフェースを実装するデータオブジェクトを取得して前記コンピュータの有する記憶部に記憶させる制御と、
   前記データオブジェクトが有するデータについての前記Ｗｅｂページ画面における表示方法をＨＴＭＬによる記述によって前記データ構造毎に定義している定義文を取得して前記コンピュータの有する記憶部に記憶させる制御と、
   前記コンピュータの有する記憶部から前記データオブジェクトを読み出して該データオブジェクトに実装されている前記インタフェースで表されているデータ構造に基づいて該データオブジェクトの有するデータと該コンピュータの有する記憶部に格納されている定義文とを関連付けることによって、該データが表示されるＷｅｂページ画面を表現するＨＴＭＬ文を生成する制御と、
   を前記コンピュータに行わせるための制御プログラムを記録した記録媒体。
7. ネットワークを介して接続されているクライアント装置との間で各種のデータを授受するサーバ装置側に設けられるコンピュータに、該クライアント装置に提供するデータが表示されるＷｅｂページ画面を表現しているＨＴＭＬ文を生成する制御を行わせるための制御プログラムであって、
   前記クライアント装置に提供するデータを有しているデータオブジェクトであって、且つ該データのデータ構造を表すインタフェースを実装するデータオブジェクトを取得して前記コンピュータの有する記憶部に記憶させる制御と、
   前記データオブジェクトが有するデータについての前記Ｗｅｂページ画面における表示方法をＨＴＭＬによる記述によって前記データ構造毎に定義している定義文を取得して前記コンピュータの有する記憶部に記憶させる制御と、
   前記コンピュータの有する記憶部から前記データオブジェクトを読み出して該データオブジェクトに実装されている前記インタフェースで表されているデータ構造に基づいて該データオブジェクトの有するデータと該コンピュータの有する記憶部に格納されている定義文とを関連付けることによって、該データが表示されるＷｅｂページ画面を表現するＨＴＭＬ文を生成する制御と、
   を前記コンピュータに行わせるための制御プログラム。

Images