(57)【要約】本発明に係るウェブアプリケーションサーバ用支援プログラムを用いることによって、ウェブアプリケーションにおける複数画面の遷移を含む処理フローの実行処理順序をサーバ側で完全に制御することができ、当該処理フローを「一単位の実行可能なプログラムコード」として記述することが可能となる。また、ウェブアプリケーションサーバ用支援プログラムを用いることによって、クライアントに送信するＨＴＭＬ文書に含まれる入力フォームの各項目等を、サーバにフォーム台帳として逐一記録させておき、クライアントから当該入力フォームに対応する入力データを受け取る際にフォーム台帳の項目と比較・検証させて、アプリケーションプログラムに依存することなく不正な入力を自動的に破棄等させることが可能となる。
2004057483.tif 000002
【特許請求の範囲】
【請求項１】
通信装置を用いてクライアントにウェブ情報を送信し、該通信装置において前記ウェブ情報に対する前記クライアントからの返信情報を受信して該返信情報を記憶装置に記憶させ、前記記憶装置に記憶される一連の処理の処理ステップに従って、前記返信情報に基づく処理を実行するウェブアプリケーションサーバの制御部に、
前記クライアントを特定するためのクライアント特定情報と前記ウェブ情報を特定するためのウェブ特定情報とを当該ウェブ情報に付加させる情報付加処理と、
前記クライアント特定情報と前記ウェブ特定情報とが付加された前記ウェブ情報を特定の前記処理ステップにおいて前記通信装置を用いて前記クライアントに送信させる情報送信処理と、
前記ウェブ情報に付加された前記クライアント特定情報及び前記ウェブ特定情報と、前記ウェブ情報が前記クライアントに送信されたときの前記処理ステップに関する処理情報とを、前記ウェブ情報が前記クライアントに送信される度に前記記憶装置に記憶させる情報記憶処理と、
前記クライアントより返信される返信情報を、前記通信装置において受信させる情報受信処理と、
受信された返信情報にクライアント特定情報とウェブ特定情報とが含まれていないかを検出させる返信情報検出処理と、
前記返信情報よりクライアント特定情報及びウェブ特定情報が検出され、かつ、検出された前記クライアント特定情報及び前記ウェブ特定情報が前記記憶装置に記憶される前記クライアント特定情報及び前記ウェブ特定情報と同一である場合に、前記記憶装置に記憶された前記処理情報より求められる処理ステップの次の処理ステップを前記記憶装置より求めて実行させ、前記返信情報よりクライアント特定情報及びウェブ特定情報が検出され、かつ、検出された前記クライアント特定情報と前記記憶装置に記憶される前記クライアント特定情報とは同一であるが、前記返信情報より検出されたウェブ特定情報と前記記憶装置に記憶される前記ウェブ特定情報とが異なる場合には、前記記憶装置に記憶された前記処理情報より求められる処理ステップを再度実行させる業務実行処理と
を実行させることを特徴とするウェブアプリケーションサーバ用支援プログラム。
【請求項２】
前記記憶装置は、メンバ変数の設定項目別の作業領域として前記一連の処理において使用されるデータ宣言部と、前記一連の処理において前記返信情報に含まれるデータを前記設定項目毎に記憶するデータ記憶部とを備え、
前記制御部に対して
前記ウェブ情報に前記クライアントにデータを入力させるためのデータ入力フォームが含まれている場合には、当該ウェブ情報を前記クライアントに送信する際に前記データ入力フォームにより入力される入力データの設定項目の種類を前記データ宣言部より判別し、前記情報記憶処理において前記クライアント特定情報、前記ウェブ特定情報、前記処理情報とともに前記記憶装置に記憶させ、
前記返信情報より検出されたクライアント特定情報及びウェブ特定情報が前記記憶装置に記憶される前記クライアント特定情報及び前記ウェブ特定情報と同一であって、前記返信情報より検出された入力データの設定項目の種類と前記記憶装置に記憶される入力データの設定項目の種類とが同一である場合には、前記業務実行処理において、検出された前記入力データを設定項目毎に前記データ記憶部に記憶させ
ることを特徴とする請求項１に記載のウェブアプリケーションサーバ用支援プログラム。
【請求項３】
前記ウェブ情報に前記データ入力フォームが複数含まれている場合であって、前記データ入力フォームに従って入力される入力データの設定項目の種類が重複する場合には、
前記制御部に、
設定項目の種類が重複する入力データの識別を行うための識別子を前記データ入力フォーム毎に付して前記ウェブ情報に含ませる識別子追加処理を実行させるとともに、
前記情報記憶処理において、前記データ入力フォームにおいて入力される入力データの設定項目の種類を前記識別子に関連付けて前記記憶装置に記憶させ、
前記業務実行処理において、前記返信情報より検出される前記入力データの設定項目の種類と前記記憶装置に記憶される設定項目の種類とが同一識別子毎に一致する場合には、検出された前記入力データの設定項目を前記記憶装置に記憶させた識別子に基づいて区別して設定項目毎に前記データ記憶部に記憶させ
ることを特徴とする請求項２に記載のウェブアプリケーションサーバ用支援プログラム。
【請求項４】
前記情報記憶処理の後に、前記情報受信処理を行うために必要な情報を前記記憶装置に退避させて前記制御部に他の処理を実行させ、
前記情報受信処理により前記返信情報を受信したときに、前記退避された情報を復帰させて前記制御部に前記返信情報検出処理を再開させ
ることで前記ウェブアプリケーションサーバにおいて並列処理を実現させることを特徴とする請求項１に記載のウェブアプリケーションサーバ用支援プログラム。
【請求項５】
クライアントにデータを入力させるためのデータ入力フォームが含まれるウェブ情報を通信装置を用いて前記クライアントに送信し、該通信装置において前記データ入力フォームに従って入力された入力データを返信情報として前記クライアントから受信し、メンバ変数の設定項目別の作業領域として使用されるデータ宣言部と、前記返信情報に含まれるデータを前記設定項目毎に記憶するデータ記憶部とを備える記憶装置に前記入力データを記憶させるウェブアプリケーションサーバの制御部に対して、
当該ウェブ情報に前記クライアントにデータを入力させるためのデータ入力フォームを付加させる情報付加処理と、
前記データ入力フォームが付加された前記ウェブ情報を前記通信装置を用いて前記クライアントに送信させる情報送信処理と、
前記データ入力フォームにより入力される入力データの設定項目の種類を前記記憶装置に記憶される前記データ宣言部より判別して、前記ウェブ情報が前記クライアントに送信される度に前記記憶装置に記憶させる情報記憶処理と、
前記クライアントより返信される返信情報を、前記通信装置において受信させる情報受信処理と、
受信された返信情報に前記入力データが含まれていないかを検出させる返信情報検出処理と、
前記返信情報より前記入力データが検出され、かつ検出された入力データの設定項目の種類と、前記記憶装置に記憶される設定項目の種類とが同一である場合には、検出された前記入力データを設定項目毎に前記データ記憶部に記憶させる業務実行処理と
を実行させることを特徴とするウェブアプリケーションサーバ用支援プログラム。
【請求項６】
前記ウェブ情報に前記データ入力フォームが複数含まれている場合であって、前記データ入力フォームに従って入力される入力データの設定項目の種類が重複する場合には、
前記制御部に、
設定項目の種類が重複する入力データの識別を行うための識別子を前記データ入力フォーム毎に付して前記ウェブ情報に含ませる識別子追加処理を実行させるとともに、
前記情報記憶処理において、前記データ入力フォームにおいて入力される入力データの設定項目の種類を前記識別子に関連付けて前記記憶装置に記憶させ、
前記業務実行処理において、前記返信情報より検出される前記入力データの設定項目の種類と前記記憶装置に記憶される設定項目の種類とが同一識別子毎に一致する場合には、検出された前記入力データの設定項目を前記記憶装置に記憶させた識別子に基づいて区別して設定項目毎に前記データ記憶部に記憶させ
ることを特徴とする請求項５に記載のウェブアプリケーションサーバ用支援プログラム。
【請求項７】
前記情報記憶処理の後に、前記情報受信処理を行うために必要な情報を前記記憶装置に退避させて前記制御部に他の処理を実行させ、
前記情報受信処理により前記返信情報を受信したときに、前記退避された情報を復帰させて前記制御部に前記返信情報検出処理を再開させ
ることで前記ウェブアプリケーションサーバにおいて並列処理を実現させることを特徴とする請求項５に記載のウェブアプリケーションサーバ用支援プログラム。
【請求項８】
通信装置を用いてクライアントにウェブ情報を送信し、
該通信装置において前記ウェブ情報に対する前記クライアントからの返信情報を受信して該返信情報を記憶装置に記憶させ、前記記憶装置に記憶される前記一連の処理の処理ステップに従って、前記返信情報に基づく処理を制御部が実行するサーバにおいて、
前記クライアントを特定するためのクライアント特定情報と前記ウェブ情報を特定するためのウェブ特定情報とを当該ウェブ情報に付加させる情報付加処理と、
前記クライアント特定情報と前記ウェブ特定情報とが付加された前記ウェブ情報を特定の前記処理ステップにおいて前記通信装置を用いて前記クライアントに送信する情報送信処理と、
前記ウェブ情報に付加された前記クライアント特定情報及び前記ウェブ特定情報と、前記ウェブ情報が前記クライアントに送信されたときの前記処理ステップに関する処理情報とを、前記ウェブ情報が前記クライアントに送信される度に前記記憶装置に記憶させる情報記憶処理と、
前記クライアントより返信される返信情報を、前記通信装置に受信させる情報受信処理と、
受信された返信情報にクライアント特定情報とウェブ特定情報とが含まれていないかを検出する返信情報検出処理と、
前記返信情報よりクライアント特定情報及びウェブ特定情報が検出され、かつ、検出された前記クライアント特定情報及び前記ウェブ特定情報が前記記憶装置に記憶される前記クライアント特定情報及び前記ウェブ特定情報と同一である場合に、前記記憶装置に記憶された前記処理情報より求められる処理ステップの次の処理ステップを前記記憶装置より求めて実行し、前記返信情報よりクライアント特定情報及びウェブ特定情報が検出され、かつ、検出された前記クライアント特定情報と前記記憶装置に記憶される前記クライアント特定情報とは同一であるが、前記返信情報より検出されたウェブ特定情報と前記記憶装置に記憶される前記ウェブ特定情報とが異なる場合には、前記記憶装置に記憶された前記処理情報より求められる処理ステップを再度実行する業務実行処理と
を前記制御部が実行することを特徴とするサーバ。
【請求項９】
前記記憶装置は、メンバ変数の設定項目別の作業領域として前記一連の処理において使用されるデータ宣言部と、前記一連の処理において前記返信情報に含まれるデータを前記設定項目毎に記憶するデータ記憶部とを備え、
前記制御部は、
前記ウェブ情報に前記クライアントにデータを入力させるためのデータ入力フォームが含まれている場合に、当該ウェブ情報を前記クライアントに送信する際に前記データ入力フォームにより入力される入力データの設定項目の種類を前記データ宣言部より判別し、前記情報記憶処理において前記クライアント特定情報、前記ウェブ特定情報、前記処理情報とともに前記記憶装置に記憶し、
前記返信情報より検出されたクライアント特定情報及びウェブ特定情報が前記記憶装置に記憶される前記クライアント特定情報及び前記ウェブ特定情報と同一であって、前記返信情報より検出された入力データの設定項目の種類と前記記憶装置に記憶される入力データの設定項目の種類とが同一である場合には、前記業務実行処理において、検出された前記入力データを設定項目毎に前記データ記憶部に記憶する
ことを特徴とする請求項８に記載のサーバ。
【請求項１０】
前記ウェブ情報に前記データ入力フォームが複数含まれている場合であって、前記データ入力フォームに従って入力される入力データの設定項目の種類が重複する場合には、
前記制御部は、
設定項目の種類が重複する入力データの識別を行うための識別子を前記データ入力フォーム毎に付して前記ウェブ情報に含ませる識別子追加処理を行うとともに、
前記情報記憶処理において、前記クライアント特定情報、前記ウェブ特定情報、前記処理情報とともに、前記データ入力フォームにおいて入力される入力データの設定項目の種類を前記識別子に関連付けて前記記憶装置に記憶させ、
前記業務実行処理において、前記返信情報より検出されたクライアント特定情報及びウェブ特定情報が前記記憶装置に記憶される前記クライアント特定情報及び前記ウェブ特定情報と同一であって、前記返信情報より検出される前記入力データの設定項目の種類と前記記憶装置に記憶される設定項目の種類とが同一識別子毎に一致する場合には、検出された前記入力データの設定項目を前記記憶装置に記憶させた識別子に基づいて区別して設定項目毎に前記データ記憶部に記憶させ
ることを特徴とする請求項８に記載のサーバ。
【発明の詳細な説明】
【技術分野】  本発明は、クライアントにウェブ情報を送信するとともに、ウェブ情報に対するクライアントからの返信情報を受信して、返信情報に基づく一連の処理を実行するサーバとこのサーバに用いられる支援プログラムに関する。
【背景技術】  インターネット等のネットワークに接続されたウェブサーバに対して、クライアントからウェブ情報（例えばＨＴＭＬ文書）の送信要求があった場合には、図２２に示すように、ウェブサーバ３０は、要求対象となるウェブ情報３１をＵＲＬによって特定してクライアント３２に送信することによって、クライアント３２の要求に応じた情報提供を行っている。
今日では、クライアント３２による送信要求に応じてウェブ情報３１をただ単に返信するだけではなく、図２３に示すように、クライアント３２からの要求に応じてある一連の処理を行うウェブアプリケーションサーバ３３が数多く用いられている。ウェブアプリケーションサーバ３３は、いわゆるフロントエンド（クライアント３２）とバックエンド（データベース管理システム等）との中間に位置する一種の支援プログラム（ミドルウェア）を備えており、この支援プログラムは、一連の処理を行うために必要な処理環境を整えて各種処理の流れを効率よく制御する役割を果たしている。また、ウェブアプリケーションサーバ３３を用いることによって、ブラウザを備えているクライアント３２であれば、ほとんどの処理をウェブアプリケーションサーバ３３で処理させることができるので、クライアント３２のハードウェア能力に依存せずに処理を行うことが可能となっている（例えば、日経ＢＰ社出版局編「デジタル用語辞典２００２−２００３年版」日経ＢＰ社発行、２００２年３月１８日第３版、４３１ページ参照）。
ところで、既存のウェブアプリケーションサーバ３３では、一連の処理に必要なＨＴＭＬ文書を生成するためのプログラム（以下、ビューとする。）が予め用意されており、ウェブアプリケーションサーバ３３は、クライアント３２のＨＴＭＬ文書の送信要求に応じて順次処理に必要なＨＴＭＬ文書を生成してクライアント３２に送信し、そのＨＴＭＬ文書の入力フォームに基づいて入力された入力データをクライアント３２から受信することによって、一連の処理に必要なデータを取得する。
例えば、図２４に示すような商品の発注処理を行うウェブアプリケーションサーバ３３においては、クライアント３２で注文入力を行うための注文入力画面を生成するビュー（以下、「ビューＡ」とする。）と、注文入力画面の入力フォームに対するクライアント３２からの注文データに応じてその注文データの確認をクライアント３２で行ってもらうための注文確認画面を生成するビュー（以下、「ビューＢ」とする。）と、注文確認画面における注文了解データに応じて注文処理が完了した旨の表示を行う注文完了画面を生成するビュー（以下、「ビューＣ」とする。）とが予め用意されている。ウェブアプリケーションサーバ３３は、注文データや注文了解データをクライアント３２から受信すると、注文内容（例えば、銘柄、数量、合計金額、発送先等）をデータベース３４に記憶し、データベース３４に記憶された注文内容に基づいて商品発送処理等を行っている。
【発明の開示】
【発明が解決しようとする課題】  しかしながら、ウェブアプリケーションサーバ３４では、ビューＡ〜ビューＣがネットワークを介していつでもアクセス可能な状態となっているので、クライアント３２は発注処理の流れに関係なくビューＡ〜ビューＣにアクセスすることができる。図２４に示した発注処理において処理がビューＡからビューＣまでの手順に従って実際に行われているか否かは、クライアント３２の送信要求に委ねられている。
このため、図２５に示すように、ビューＡに対するクライアント３２からの応答に対して次のＨＴＭＬ文書の送信要求先がビューＢとなるようにビューＡには次の送信要求先が記憶されているが、その送信要求先がビューＢになるか否かはクライアント３２の送信要求次第であり、ビューＡの次にビューＢが送信される予定となっていても、場合によってはクライアント３２がビューＢではなくビューＣの送信要求を行ってしまい、ウェブアプリケーションサーバ３３がビューＢにより生成されるＨＴＭＬ文書ではなくビューＣにより生成されたＨＴＭＬ文書をクライアント３２に送信してしまうおそれがある。
また、図２６に示すように、クライアント３２においてビューＢの注文確認用のＨＴＭＬ文書が送信され、その後にビューＣにより生成された発注処理が完了した旨のＨＴＭＬ文書が送信され発注処理が完了した後に、クライアント３２はブラウザの「戻る」ボタンを押すことによってキャッシュ内に記憶されていたビューＢのＨＴＭＬ文書の画面を再度表示させることができる。クライアント３２は、このようにキャッシュ内に記憶されていたビューＢの画面に従って再度ウェブアプリケーションサーバ３３に注文了解データを返信してしまうおそれがあり、再度注文了解データをウェブアプリケーションサーバ３３に返信した場合には二重に注文処理を行ってしまうという問題がある。
さらに、図２７に示すように、クライアント３２がビューＡに対応する注文データをウェブアプリケーションサーバ３３に返信する前に、悪意のある第三のクライアント３５がクライアント３２になりすまして他の注文データを送信してしまうおそれがある。この場合、従来のウェブアプリケーションサーバ３３では、送信された注文データが、どのクライアントから送信されたどのＨＴＭＬ文書に基づく返信であるかを判断することができないので、受信し注文データをクライアント３２より送信された注文データであると判断して発注処理を進めてしまう場合があり、クライアント３２とウェブアプリケーションサーバ３３との間で安全な発注処理を行うことが困難であるという問題があった。
また、一般的なＨＴＭＬ文書においては、ビューＡ〜ビューＣのそれぞれのビュー内に、クライアント３２が入力する必要のある入力項目が直接記述されているので、処理の変更等により入力項目が増減した場合には、各ビューの項目をそれぞれのビュー毎に変更しなければならず、変更処理に多大な労力を要するという問題があった。
本発明は、上記の問題に鑑みて為されたものであり、クライアントにウェブ情報を送信するとともに、ウェブ情報に対するクライアントからの返信情報を受信して、返信情報に基づく一連の処理を実行するサーバにおいて、サーバが一連の処理の処理過程を把握することによって処理手順に沿わない処理がなされることを防止することができ、さらに、一連の処理に用いられるウェブ情報の内容を容易に変更することが可能なサーバ及びそのサーバに用いられる支援プログラムを提供することを課題とする。
【課題を解決するための手段】  上記課題を解決するために、本発明は、通信手段を用いてクライアントにウェブ情報を送信し、該通信手段において前記ウェブ情報に対する前記クライアントからの返信情報を受信して該返信情報を記憶手段に記憶させ、前記記憶手段に記憶される一連の処理の処理ステップに従って、前記返信情報に基づく処理を実行するウェブアプリケーションサーバの制御部に、前記クライアントを特定するためのクライアント特定情報と前記ウェブ情報を特定するためのウェブ特定情報とを当該ウェブ情報に付加させる情報付加処理と、前記クライアント特定情報と前記ウェブ特定情報とが付加された前記ウェブ情報を特定の前記処理ステップにおいて前記通信手段を用いて前記クライアントに送信させる情報送信処理と、前記ウェブ情報に付加された前記クライアント特定情報及び前記ウェブ特定情報と、前記ウェブ情報が前記クライアントに送信されたときの前記処理ステップに関する処理情報とを、前記ウェブ情報が前記クライアントに送信される度に前記記憶手段に記憶させる情報記憶処理と、前記クライアントより返信される返信情報を、前記通信手段において受信させる情報受信処理と、受信された返信情報にクライアント特定情報とウェブ特定情報とが含まれていないかを検出させる返信情報検出処理と、前記返信情報よりクライアント特定情報及びウェブ特定情報が検出され、かつ、検出された前記クライアント特定情報及び前記ウェブ特定情報が前記記憶手段に記憶される前記クライアント特定情報及び前記ウェブ特定情報と同一である場合に、前記記憶手段に記憶された前記処理情報より求められる処理ステップの次の処理ステップを前記記憶手段より求めて実行させ、前記返信情報よりクライアント特定情報及びウェブ特定情報が検出され、かつ、検出された前記クライアント特定情報と前記記憶手段に記憶される前記クライアント特定情報とは同一であるが、前記返信情報より検出されたウェブ特定情報と前記記憶手段に記憶される前記ウェブ特定情報とが異なる場合には、前記記憶手段に記憶された前記処理情報より求められる処理ステップを再度実行させる業務実行処理とを実行させるウェブアプリケーションサーバ用支援プログラムであることを特徴とする。
また、前記記憶手段が、メンバ変数の設定項目別の作業領域として前記一連の処理において使用されるデータ宣言部と、前記一連の処理において前記返信情報に含まれるデータを前記設定項目毎に記憶するデータ記憶部とを備え、前記制御部に対して前記ウェブ情報に前記クライアントにデータを入力させるためのデータ入力フォームが含まれている場合には、当該ウェブ情報を前記クライアントに送信する際に前記データ入力フォームにより入力される入力データの設定項目の種類を前記データ宣言部より判別し、前記情報記憶処理において前記クライアント特定情報、前記ウェブ特定情報、前記処理情報とともに前記記憶手段に記憶させ、前記返信情報より検出されたクライアント特定情報及びウェブ特定情報が前記記憶手段に記憶される前記クライアント特定情報及び前記ウェブ特定情報と同一であって、前記返信情報より検出された入力データの設定項目の種類と前記記憶手段に記憶される入力データの設定項目の種類とが同一である場合には、前記業務実行処理において、検出された前記入力データを設定項目毎に前記データ記憶部に記憶させる様にしてもよい。
さらに、前記ウェブ情報に前記データ入力フォームが複数含まれている場合であって、前記データ入力フォームに従って入力される入力データの設定項目の種類が重複する場合には、前記制御部に、設定項目の種類が重複する入力データの識別を行うための識別子を前記データ入力フォーム毎に付して前記ウェブ情報に含ませる識別子追加処理を実行させるとともに、前記情報記憶処理において、前記クライアント特定情報、前記ウェブ特定情報、前記処理情報とともに、前記データ入力フォームにおいて入力される入力データの設定項目の種類を前記識別子に関連付けて前記記憶手段に記憶させ、前記業務実行処理において、前記返信情報より検出されたクライアント特定情報及びウェブ特定情報が前記記憶手段に記憶される前記クライアント特定情報及び前記ウェブ特定情報と同一であって、前記返信情報より検出される前記入力データの設定項目の種類と前記記憶手段に記憶される設定項目の種類とが同一識別子毎に一致する場合には、検出された前記入力データの設定項目を前記記憶手段に記憶させておいた識別子に基づいて区別して設定項目毎に前記データ記憶部に記憶させる様にしてもよい。
また、本発明は、クライアントにデータを入力させるためのデータ入力フォームが含まれるウェブ情報を通信装置を用いて前記クライアントに送信し、該通信装置において前記データ入力フォームに従って入力された入力データを返信情報として前記クライアントから受信し、メンバ変数の設定項目別の作業領域として使用されるデータ宣言部と、前記返信情報に含まれるデータを前記設定項目毎に記憶するデータ記憶部とを備える記憶装置に前記入力データを記憶させるウェブアプリケーションサーバの制御部に対して、当該ウェブ情報に前記クライアントにデータを入力させるためのデータ入力フォームを付加させる情報付加処理と、前記データ入力フォームが付加された前記ウェブ情報を前記通信手段を用いて前記クライアントに送信させる情報送信処理と、前記データ入力フォームにより入力される入力データの設定項目の種類を前記記憶手段に記憶される前記データ宣言部より判別して、前記ウェブ情報が前記クライアントに送信される度に前記記憶手段に記憶させる情報記憶処理と、前記クライアントより返信される返信情報を、前記通信手段において受信させる情報受信処理と、受信された返信情報に前記入力データが含まれていないかを検出させる返信情報検出処理と、前記返信情報より前記入力データが検出され、かつ検出された入力データの設定項目の種類と、前記記憶手段に記憶される設定項目の種類とが同一である場合には、検出された前記入力データを設定項目毎に前記データ記憶部に記憶させる業務実行処理とを実行させるウェブアプリケーションサーバ用支援プログラムであることを特徴とする。
このウェブアプリケーションサーバ用支援プログラムにおいて、前記ウェブ情報に前記データ入力フォームが複数含まれている場合であって、前記データ入力フォームに従って入力される入力データの設定項目の種類が重複する場合には、前記制御部に、設定項目の種類が重複する入力データの識別を行うための識別子を前記データ入力フォーム毎に付して前記ウェブ情報に含ませる識別子追加処理を実行させるとともに、前記情報記憶処理において、前記データ入力フォームにおいて入力される入力データの設定項目の種類を前記識別子に関連付けて前記記憶手段に記憶させ、前記業務実行処理において、前記返信情報より検出される前記入力データの設定項目の種類と前記記憶手段に記憶される設定項目の種類とが同一識別子毎に一致する場合には、検出された前記入力データの設定項目を前記記憶手段に記憶させた識別子に基づいて区別して設定項目毎に前記データ記憶部に記憶させる様にしてもよい。
さらに望ましくは、上述したウェブアプリケーションサーバ用支援プログラムにおいて、前記情報記憶処理の後に、前記情報受信処理を行うために必要な情報を前記記憶手段に退避させて前記制御部に他の処理を実行させ、前記情報受信処理により前記返信情報を受信したときに、前記退避された情報を復帰させて前記制御部に前記返信情報検出処理を再開させることで前記ウェブアプリケーションサーバにおいて並列処理を実現させるようにしても良い。
また、上述したウェブアプリケーションサーバ用支援プログラムにより実現される機能を備えたウェブアプリケーションプログラムであってもよく、さらに、ウェブアプリケーションサーバ用支援プログラムにより実現される機能を備えたオペレーティングシステムであってもよい。
さらに本発明は、通信手段を用いてクライアントにウェブ情報を送信し、該通信手段において前記ウェブ情報に対する前記クライアントからの返信情報を受信して該返信情報を記憶手段に記憶させ、前記記憶手段に記憶される前記一連の処理の処理ステップに従って、前記返信情報に基づく処理を制御部が実行するサーバにおいて、前記クライアントを特定するためのクライアント特定情報と前記ウェブ情報を特定するためのウェブ特定情報とを当該ウェブ情報に付加させる情報付加処理と、前記クライアント特定情報と前記ウェブ特定情報とが付加された前記ウェブ情報を特定の前記処理ステップにおいて前記通信手段を用いて前記クライアントに送信する情報送信処理と、前記ウェブ情報に付加された前記クライアント特定情報及び前記ウェブ特定情報と、前記ウェブ情報が前記クライアントに送信されたときの前記処理ステップに関する処理情報とを、前記ウェブ情報が前記クライアントに送信される度に前記記憶手段に記憶させる情報記憶処理と、前記クライアントより返信される返信情報を、前記通信手段に受信させる情報受信処理と、受信された返信情報にクライアント特定情報とウェブ特定情報とが含まれていないかを検出する返信情報検出処理と、前記返信情報よりクライアント特定情報及びウェブ特定情報が検出され、かつ、検出された前記クライアント特定情報及び前記ウェブ特定情報が前記記憶手段に記憶される前記クライアント特定情報及び前記ウェブ特定情報と同一である場合に、前記記憶手段に記憶された前記処理情報より求められる処理ステップの次の処理ステップを前記記憶手段より求めて実行し、前記返信情報よりクライアント特定情報及びウェブ特定情報が検出され、かつ、検出された前記クライアント特定情報と前記記憶手段に記憶される前記クライアント特定情報とは同一であるが、前記返信情報より検出されたウェブ特定情報と前記記憶手段に記憶される前記ウェブ特定情報とが異なる場合には、前記記憶手段に記憶された前記処理情報より求められる処理ステップを再度実行する業務実行処理とを前記制御部が実行するサーバであることを特徴とする。
また、前記記憶手段が、メンバ変数の設定項目別の作業領域として前記一連の処理において使用されるデータ宣言部と、前記一連の処理において前記返信情報に含まれるデータを前記設定項目毎に記憶するデータ記憶部とを備え、前記制御部は、前記ウェブ情報に前記クライアントにデータを入力させるためのデータ入力フォームが含まれている場合に、当該ウェブ情報を前記クライアントに送信する際に前記データ入力フォームにより入力される入力データの設定項目の種類を前記データ宣言部より判別し、前記情報記憶処理において前記クライアント特定情報、前記ウェブ特定情報、前記処理情報とともに前記記憶手段に記憶し、前記返信情報より検出されたクライアント特定情報及びウェブ特定情報が前記記憶手段に記憶される前記クライアント特定情報及び前記ウェブ特定情報と同一であって、前記返信情報より検出された入力データの設定項目の種類と前記記憶手段に記憶される入力データの設定項目の種類とが同一である場合には、前記業務実行処理において、検出された前記入力データを設定項目毎に前記データ記憶部に記憶してもよい。
さらに、前記ウェブ情報に前記データ入力フォームが複数含まれている場合であって、前記データ入力フォームに従って入力される入力データの設定項目の種類が重複する場合には、前記制御部は、設定項目の種類が重複する入力データの識別を行うための識別子を前記データ入力フォーム毎に付して前記ウェブ情報に含ませる識別子追加処理を行うとともに、前記情報記憶処理において、前記クライアント特定情報、前記ウェブ特定情報、前記処理情報とともに、前記データ入力フォームにおいて入力される入力データの設定項目の種類を前記識別子に関連付けて前記記憶手段に記憶させ、前記業務実行処理において、前記返信情報より検出されたクライアント特定情報及びウェブ特定情報が前記記憶手段に記憶される前記クライアント特定情報及び前記ウェブ特定情報と同一であって、前記返信情報より検出される前記入力データの設定項目の種類と前記記憶手段に記憶される設定項目の種類とが同一識別子毎に一致する場合には、検出された前記入力データの設定項目を前記記憶手段に記憶させた識別子に基づいて区別して設定項目毎に前記データ記憶部に記憶させる様にしてもよい。
また、本発明は、クライアントにデータを入力させるためのデータ入力フォームが含まれるウェブ情報を通信手段を用いて前記クライアントに送信し、該通信手段において前記データ入力フォームに従って入力された入力データを返信情報として前記クライアントから受信し、メンバ変数の設定項目別の作業領域として使用されるデータ宣言部と、返信情報に含まれるデータを前記設定項目毎に記憶するデータ記憶部とを備える記憶手段に前記入力データを記憶させ制御部を有するサーバにおいて、当該ウェブ情報に前記クライアントにデータを入力させるためのデータ入力フォームを付加する情報付加処理と、前記データ入力フォームが付加された前記ウェブ情報を前記通信手段を用いて前記クライアントに送信する情報送信処理と、前記データ入力フォームにより入力される入力データの設定項目の種類を前記記憶手段に記憶される前記データ宣言部より判別して、前記ウェブ情報が前記クライアントに送信される度に前記記憶手段に記憶させる情報記憶処理と、前記クライアントより返信される返信情報を、前記通信手段に受信させる情報受信処理と、受信された返信情報に前記入力データが含まれていないかを検出する返信情報検出処理と、前記返信情報より前記入力データが検出され、かつ検出された入力データの設定項目の種類と、前記記憶手段に記憶される設定項目の種類とが同一である場合には、検出された前記入力データを設定項目毎に前記データ記憶部に記憶する業務実行処理とを前記制御部が実行するサーバであることを特徴とする。
上述したサーバにおいて、前記ウェブ情報に前記データ入力フォームが複数含まれている場合であって、前記データ入力フォームに従って入力される入力データの設定項目の種類が重複する場合には、前記制御部は、設定項目の種類が重複する入力データの識別を行うための識別子を前記データ入力フォーム毎に付して前記ウェブ情報に含ませる識別子追加処理を行うとともに、前記情報記憶処理において、前記データ入力フォームにおいて入力される入力データの設定項目の種類を前記識別子に関連付けて前記記憶手段に記憶させ、前記業務実行処理において、前記返信情報より検出される前記入力データの設定項目の種類と前記記憶手段に記憶される設定項目の種類とが同一識別子毎に一致する場合には、検出された前記入力データの設定項目を前記記憶手段に記憶させた識別子に基づいて区別して設定項目毎に前記データ記憶部に記憶させてもよい。
【発明の効果】  以上説明したように本発明を用いることによって、サーバが実行する一連の処理をサーバでその処理ステップの処理状況を確認しながら実行することが可能となる。
また、本発明では、返信情報に含まれる入力データの設定項目の種類が、送信したウェブ情報の入力フォームにおいて入力可能な設定項目の種類に対応するものであるか否かを制御部が判断して、入力データの設定項目と記憶されたが設定項目とが一致する場合にはその入力データをデータ宣言部に関連付けて自動的にデータ記憶部に記憶させることができるので、意図しない入力データがクライアントからの返信情報としてデータ記憶部に記憶されてその後の処理に反映されることを防止することができる。
さらに、ウェブ情報の送信時及び返信情報の受信時にのみ、記憶部に記憶された必要なデータを読み出して（復帰させて）制御部に必要な処理を行わせることができるので、制御部は複数の一連の処理を同時に実行するマルチタスク環境を容易に実現することが可能となる。
【図面の簡単な説明】
【図１】本発明に係るサーバのソフトウェア構成を示したブロック図である。
【図２】  本発明に係るサーバのハードウェア構成を示したブロック図である。
【図３】  本発明に係るサーバとクライアントとのデータの送受信関係を示したデータフロー図である。
【図４】  牡蛎料理の注文処理の処理手順を示したストリームプログラムのプログラムリストを示した図である。
【図５】  牡蛎料理の注文処理に用いられるクラス定義プログラムのプログラムリストを示した第１の図である。
【図６】  牡蛎料理の注文処理に用いられるクラス定義プログラムのプログラムリストを示した第２の図である。
【図７】  牡蛎料理の注文処理に用いられるＨＴＭＬ文書のデータ定義示した図である。
【図８】  牡蛎料理の注文処理のステップ２において使用されるＨＴＭＬ文書の表示画面を示した第１の図である。
【図９】  牡蛎料理の注文処理のステップ２において使用されるＨＴＭＬ文書の表示画面を示した第２の図である。
【図１０】  牡蛎料理の注文処理のステップ３において使用されるＨＴＭＬ文書の表示画面を示した第１の図である。
【図１１】  牡蛎料理の注文処理のステップ３において使用されるＨＴＭＬ文書の表示画面を示した第２の図である。
【図１２】  牡蛎料理の注文処理における調味料の種類に関するエラー表示が為されたＨＴＭＬ文書の表示画面を示した図である。
【図１３】  牡蛎料理の注文処理のステップ５において使用されるＨＴＭＬ文書の表示画面を示した図である。
【図１４】  牡蛎料理の注文処理において牡蛎の銘柄、牡蛎の調理方法、添える調味料、コメントの項目が２組表示されたＨＴＭＬ文書の表示画面を示した図である。
【図１５】  ３つのウィンドウを有するＨＴＭＬ文書の表示画面の概略を示した図である。
【図１６】  ３つのウィンドウを有するＨＴＭＬ文書を作成するためのストリームプログラムのプログラムリストを示した図である。
【図１７】  ３つのウィンドウを有するＨＴＭＬ文書を作成するために用いられるページ定義を示した図である。
【図１８】  ３つのウィンドウを有するＨＴＭＬ文書の表示画面を示した図である。
【図１９】  識別子を用いて牡蛎の銘柄、コメントからなる複数組の設定項目を区別して記憶部に記憶させ、返信情報よりそれぞれの識別子に対応する入力データの設定項目を抽出してそれぞれデータ記憶部に記憶する処理を示した模式図である。
【図２０】  ストリームプログラムの有無に拘わらず、設定項目を記憶部に記憶させ、返信情報より対応する設定項目を抽出してデータ記憶部に記憶する処理を示した模式図である。
【図２１】  積算情報を時分情報に変換して記憶部に記憶させ、返信情報より対応する時分情報を抽出して積算情報に復元してデータ記憶部に記憶する処理を示した模式図である。
【図２２】  ウェブサーバとクライアントとの間におけるウェブ情報の送受信方法を示した概略図である。
【図２３】  従来のウェブアプリケーションサーバとクライアントとの間におけるウェブ情報の送受信方法を示した概略図である。
【図２４】  ウェブアプリケーションサーバとクライアントとの間における商品の発注処理の方法を示した概略図である。
【図２５】  ウェブアプリケーションサーバに対してクライアントが発注処理の流れに関係なくウェブ情報の送信要求を行ってしまう場合を示した図である。
【図２６】  ウェブアプリケーションサーバに対してクライアントが二重に発注処理をしてしまう場合を示した図である。
【図２７】  ウェブアプリケーションサーバに対して第三のクライアントが注文データを送信してしまう場合を示した図である。
【発明を実施するための最良の形態】  以下、本発明の実施の形態を、図面を用いて説明する。
図１は、本発明に係るウェブアプリケーションサーバのソフトウェア構成を示したブロック図である。このサーバ１は、Ｗｉｎｄｏｗｓ（登録商標）やＬｉｎｕｘ等のＯＳ（ｏｐｅｒａｔｉｎｇ  ｓｙｓｔｅｍ）２と、ＯＳ２上で動作するｃｇｉｏｓ３と、ｃｇｉｏｓ３に基づいて実行されるアプリケーションソフトウェア４とによって構成されている。
ｃｇｉｏｓ３は、ｃｇｉｏｓ用に記載されたアプリケーションソフトウェア４を実行するミドルウェアであり、アプリケーションソフトウェア４を従来のＯＳであるＯＳ２上で動かすためのエミュレータとしての役割を有している。また、ｃｇｉｏｓ３は、ウェブサーバ用アプリケーションとしての機能及びＣＧＩ（Ｃｏｍｍｏｎ  Ｇａｔｅｗａｙ  Ｉｎｔｅｒｆａｃｅ）機能に加えて、後述するｃｇｉｏｓ特有の機能を備えているので、ウェブアプリケーションサーバ用の支援ソフトウェア（ウェブアプリケーションサーバ用支援プログラム）としての役割も有している。このｃｇｉｏｓ３を用いることによって、ｃｇｉｏｓ３において実現される処理を、プログラマーがアプリケーションソフトウェア４用のプログラムにおいて直接記述しなくても、ｃｇｉｏｓ３が自動的に実行するので、プログラム作成労力の軽減を図ることが可能となる。
図２は、サーバ１のハードウェア構成の概略を示したブロック図である。サーバ１は、クライアント７との間で各種データ（情報）の送受信を行う送受信部８と、ＣＰＵからなる制御部９と、ハードディスクからなる記憶部１０及びデータベース１１とを備えている。
クライアント７は、パソコン、ＰＤＡ（Ｐｅｒｓｏｎａｌ  Ｄｉｇｉｔａｌ  Ａｓｓｉｓｔａｎｃｅ）又は携帯電話等のブラウザを備えた通信機器である。送受信部８はＮＩＣ（Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅ  Ｃａｒｄ）等により構成され、この送受信部８を用いることによって、サーバ１はネットワーク１２を介してクライアント７との間でデータの送受信を行うことが可能となっている。ネットワーク１２は外部に公開されるインターネット等のオープンなネットワークであっても、外部に公開されていないＬＡＮ等のネットワークであってもよい。なお、図２においてはネットワーク１２にはクライアント７が１台のみ接続されているが、複数接続されていてもかまわない。
記憶部１０には、ｃｇｉｏｓ３用のプログラム言語により記述されたアプリケーションソフトウェア４が記録されている。アプリケーションソフトウェア４は、ストリームプログラムとクラス定義プログラムとがコンパイルされることにより生成される。サーバ１は、そのアプリケーションソフトウェア４に基づいて、例えばクライアントから商品の注文を受け付ける受付処理のような一連の窓口処理（フロントエンドに対するバックエンド側のインターフェースに関する処理）を実行する。
ここで、ストリームプログラムにはその窓口処理の全体的な流れが記述され、窓口処理の各段階における具体的な処理はクラス定義プログラムに記述されている。そして、このクラス定義プログラムがストリームプログラムに引用され、窓口処理が実行される。また、ｃｇｉｏｓ３はクラス定義プログラムで使用されるメンバ変数をクラス定義プログラムのインスタンス（オブジェクト指向プログラム技術において一般的に使用されているインスタンスを意味し、クラスがオブジェクトの型を示すのに対して、インスタンスはオブジェクトの実体を示す。）ごとに管理する機能を有し、あるクラス定義プログラムのインスタンスからクライアント７に向けて送信されたメンバ変数が返信時にそのインスタンスのメンバ変数に戻るよう制御しているので（メンバ変数を発行するインスタンスと、メンバ変数を吸収するインスタンスとが同一）、ストリームプログラムがクラス定義プログラムに記載された処理命令を引用する場合には、ストリームプログラムにおいてメンバ変数を直接引数として記載する必要がない。したがって、引用される処理命令が異なるクラスに属するものであっても、また同一のクラスに属するものであっても、ストリームプログラムではそのクラスにおけるメンバ変数に左右されることなく処理手順を示すことが可能となっている。
また、記憶部１０には、窓口処理における処理の段階を示す処理ステップ情報や、次述するセッション値（クライアント特定情報）及び乱数値（ウェブ特定情報）が記憶（退避）される。ここで、処理ステップ情報とは、より具体的には制御部９が処理を行う際に参照するプログラムカウンタのアドレス値を記憶した情報である。さらに、記憶部１０には、窓口処理においてクライアント７からデータが入力された際に、そのときの処理に関わるインスタンスごとに入力データを設定項目として分けて記憶するデータ記憶部が設けられている。
データベース１１には、窓口処理において処理が確定した入力データが入力される。データベース１１は、この点において、窓口処理において入力された入力データを一時的に保存するデータ記憶部と相違する。データベース１１に記憶される設定項目は、クラス定義プログラムで宣言されるメンバ変数の設定項目と同期されており、クラス定義プログラムにおいて設定項目が変更されると、ｃｇｉｏｓ３が自動的に同期される設定項目を変更する。
制御部９は、サーバ１を構成するコンピュータのＣＰＵであり、アプリケーションソフトウェア４に従って各種処理を行うほか、ｃｇｉｏｓ３のカーネル（ｃｇｉｏｓの基本機能を実現する部分）の指示に従ってｃｇｉｏｓ３特有の機能を実現させるための処理を実行する。以下、ｃｇｉｏｓ３の指示に基づいて制御部９によって実行されるｃｇｉｏｓ３特有の機能を説明する。
図３は、サーバ１からクライアント７に送信されるＨＴＭＬ文書（ウェブ情報）及びクライアント７からサーバ１に返信される返信情報との送受信関係を示したデータフロー図である。
クライアント７によって取引開始ページのＨＴＭＬ文書の送信要求（取引開始ページのＵＲＬへのアクセス要求）がなされた場合、制御部９は、セッション値と乱数値と生成する。ここで、セッション値とは、サーバ１が特定のクライアント７のために行う一連の窓口処理を識別するために用いられる値であり、制御部９は、このセッション値を用いることによってその窓口処理の内容の特定及びクライアント７の特定を行う。また、乱数値は、サーバ１がクライアント７に対して送信するＨＴＭＬ文書を特定するために用いられるものである。なお、本実施例ではＨＴＭＬ文書の特定を行うために乱数値を用いることとしたが、ＨＴＭＬ文書の特定を行うことが可能な識別情報としての機能を有するものであるならば乱数値に限定されるものではない。また、サーバ１は、ストリームプログラムに記述されている第１の処理ステップにおける処理命令をクラス定義プログラムから引用することによって第１の処理ステップに用いられるＨＴＭＬ文書（以下、第１のＨＴＭＬ文書とする。）を生成する。
その後、制御部９は、生成したセッション値と乱数値とを暗号化し、暗号化されたセッション値と乱数値とをＨＴＭＬのＨＩＤＤＥＮパラメータを用いて第１のＨＴＭＬ文書に付加して送受信部よりクライアント７に送信する。また、制御部９は、第１のＨＴＭＬ文書の送信と同時に、セッション値、乱数値、処理ステップ情報を記憶部１０に記憶（退避）し、さらに、第１のＨＴＭＬ文書にクライアント７にデータを入力させるための入力フォームが設けられている場合には、入力フォームにより入力することが可能な設定項目情報をインスタンス毎に記憶する。その後、制御部９は窓口処理から解放される。
サーバ１より送信された第１のＨＴＭＬ文書がクライアント７において受信されると、第１のＨＴＭＬ文書がクライアント７のウェブブラウザ画面上に表示される。クライアント７は、第１のＨＴＭＬ文書の入力フォームに従ってデータ（入力データ）を入力することができ、入力処理を行った後に「次へ」等のボタンをクリックすることによって、取引開始ページのＵＲＬへのアクセス要求を再度行うとともに、入力処理が行われた入力データと、暗号化されたセッション値及び乱数値とを返信情報としてサーバ１に返信する。なお、サーバ１のｃｇｉｏｓ３は、セッション値及び乱数値に基づいてクライアント及びＨＴＭＬ文書の特定を行っているので、クライアント７からサーバ１へのアクセス要求が行われるＵＲＬは、取引開始ページのＵＲＬだけである。この点において、サーバ１は、窓口処理の処理内容毎に異なるＵＲＬをアクセス要求先として指定する従来のウェブアプリケーションサーバと相違する。
返信情報がサーバ１の送受信部８に返信されると、制御部９は、一連の窓口処理を再開する。制御部９では、返信情報に暗号化されたセッション値および乱数値が含まれているか否かの検出を行い、セッション値及び乱数値が含まれていない場合には、受信した返信情報はサーバ１が送信したＨＴＭＬ文書とは無関係に返信された情報であると判断する。
返信情報より暗号化されたセッション値および乱数値が検出された場合には、制御部９は、暗号化されたセッション値及び乱数値を抽出して復号化するとともに、記憶部１０に記憶されていたセッション値及び乱数値を読み出して、復号化されたセッション値及び乱数値を、記憶部１０に記憶されているセッション値及び乱数値と比較する。制御部９は、復号化されたセッション値と記憶部１０に記憶されているセッション値とが同一である場合には、ＨＴＭＬ文書を送信したクライアントと、返信情報を返信したクライアントとが同一クライアントであると判断する。一方、比較されるセッション値が異なる場合、制御部９はクライアントが異なるものと判断して受信した返信情報を破棄する。
比較されるセッション値が同一である場合、制御部９は、さらに復号化された乱数値と第１のＨＴＭＬ文書を送信したときに記憶部１０に記憶された乱数値とが同一であるか否かを比較し、乱数値が同一である場合には、第１のＨＴＭＬ文書の入力フォームに従ってクライアント７が入力した入力データが返信情報として返信されたものであると判断し、乱数値が異なる場合には第１のＨＴＭＬ文書とは異なるＨＴＭＬ文書に基づく処理に対する返信情報であると判断する。
セッション値及び乱数値を比較することによって、制御部９が、受信した返信情報が第１のＨＴＭＬ文書の入力フォーム基づく返信情報であると判断した場合には、記憶部１０に記憶されているクラス定義プログラムにおけるインスタンス毎の設定項目情報と、返信情報のインスタンス毎の入力データの設定項目情報とを比較し、記憶部１０に記憶されている設定項目と一致する入力データを、そのインスタンスにおいて用いられる設定項目毎に区分けしてデータ記憶部に記憶する。このように、クライアント７によって入力された入力データをクラス定義プログラムに用いられるインスタンスのメンバ変数の設定項目毎にデータ記憶部に記憶させておくことによって、ストリームプログラムがその後の処理ステップにおいてクラス定義プログラムに記載された処理命令を引用する場合には、データ記憶部に記憶されたインスタンス毎の入力データを設定項目毎の既設値としてその後の処理に利用される。記憶部１０に記憶されている設定項目と一致しない入力データは破棄される。その後、制御部９は、記憶部１０に記憶された処理ステップ情報より、ストリームプログラムに示された一連の窓口処理においてどの処理ステップまで処理が終了しているかを判断し、判断される処理ステップの次の処理ステップ、つまり第２の処理ステップの処理を実行する。
第２の処理ステップにおいて、制御部９は、ストリームプログラムの第２の処理ステップで引用されている処理命令を実行することによって第２の処理ステップに用いられるＨＴＭＬ文書（以下、第２のＨＴＭＬ文書とする。）を生成する。その後、制御部９は、第２のＨＴＭＬ文書であることを特定するための他の乱数値を生成し、第１の処理ステップにおいて生成したセッション値とともに暗号化して第２のＨＴＭＬ文書に付加する。
制御部９は、第２のＨＴＭＬ文書を、送受信部８を介してクライアント７に送信し、さらに、第２のＨＴＭＬ文書の送信と同時に、セッション値、乱数値、処理ステップ情報、第２のＨＴＭＬ文書の入力フォームに使用されたクラス定義プログラム毎の設定項目情報を記憶部１０に記憶（退避）して、第１の処理ステップにおいて説明した処理と同様の処理を繰り返す。
第１の処理ステップにおいて返信された返信情報に、暗号化されたセッション値および乱数値が含まれている場合であって、暗号化されたセッション値と記憶部１０に記憶されているセッション値は同一であるが乱数値が異なる場合には、第１のＨＴＭＬ文書に対してクライアント７が返信情報を返信したものではないと判断できるので、記憶部１０に記憶される処理ステップ情報により特定される処理を再度繰り返して実行する。再度処理を繰り返して実行する場合には、制御部９は、受信された返信情報を破棄し、再度第１のＨＴＭＬ文書を作成して前述のセッション値と新たに作成した第１のＨＴＭＬ文書を特定するための新たな乱数値とを暗号化して第１のＨＴＭＬ文書に付加する。その後、制御部９は送受信部１０を介して第１のＨＴＭＬ文書を再度クライアント７に送信する。再度第１のＨＴＭＬ文書を送付する場合に、制御部９は、記憶部１０に記憶されている乱数値のみを変更して再度記憶部１０にセッション値、処理ステップ情報等の各種情報を記憶（退避）する。
制御部９は、上記の処理を繰り返して、ストリームプログラムに記憶されている処理ステップを順次実行し、一連の処理の終わりに記憶部１０のデータ記憶部に更新記憶された入力データを、一連の窓口処理における確定したデータとしてデータベース１１に登録する処理を行った後に、窓口処理が終了した旨のＨＴＭＬ文書を作成してクライアント７に送信して処理を終了する。
次に、簡単なストリームプログラム及びクラス定義プログラムを用いて、より具体的にサーバ１とクライアント７との間のデータの送受信方法を説明する。
図４〜図７は牡蛎料理の注文処理における実行プログラムを示したプログラムリストであり、図４はストリームプログラム、図５，６は、牡蛎料理の注文に関するクラス定義プログラム、図７は、図４に示したストリームプログラムに従って作成されるＨＴＭＬ文書のページ定義を示したプログラムである。
牡蛎料理の注文処理は、基本的に５つの処理ステップによって完了する。ステップ１は、使用されるクラスの宣言及び生成されたインスタンスで用いられる設定項目の初期値設定を行う処理ステップである。
ステップ２は、クライアントに牡蛎の銘柄、調理方法、添える調味料の３種類の設定項目のデータの入力と、コメントの入力を行ってもらう処理ステップであり、この処理を行うために注文入力画面（以下、ページＡ１とする。）のＨＴＭＬ文書がサーバ１からクライアント７に送信される。図８及び図９はページＡ１に該当する画面表示を示したものである。
ステップ３は、クライアント７において入力された牡蛎の銘柄、調理方法、添える調味料、コメントの内容を確認してもらう処理ステップである。この処理を行うために、ステップ１においてクライアント７によって入力された注文内容を確認表示させる注文確認画面（以下、ページＢ１とする。）のＨＴＭＬ文書がサーバ１からクライアント７に送信される。図１０及び図１１がページＢ１に該当する画面表示を示したものである。なお、ステップ３では、クライアント７により入力された調味料の種類が２種類以下であるか否かを検査するエラー処理が実行される。３種類以上の場合には、図１２に示すようなエラーメッセージが画面上に表示される。
ステップ４は、注文の確認が為された設定値情報をデータベース１１に記憶する処理である。
ステップ５は、ステップ３で確認された内容により牡蛎料理の注文を承った旨を知らせる処理ステップであり、この処理を行うためにステップ３で確認された注文内容と注文処理が完了した旨とを表示する注文完了画面（以下、ページＣ１とする）のＨＴＭＬ文書がサーバ１からクライアント７に送信される。図１３がページＣ１に該当する画面表示である。
また、図７（ａ）に示したプログラムは、ページＡ１のＨＴＭＬ文書を作成するためのページ定義を示したものであり、（ｂ）に示したプログラムは、ページＢ１のＨＴＭＬ文書を作成するためのページ定義を示したものであり、（ｃ）に示したプログラムは、ページＣ１のＨＴＭＬ文書を作成するためのページ定義を示したものである。図７（ａ）〜（ｃ）に示したプログラムは、ＨＴＭＬ（Ｈｙｐｅｒｔｅｘｔ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）で記載されており、＜ｈ３＞〜＜／ｈ３＞はＨＴＭＬ文書の表示画面上に見出しを表示させるためのタグである。また、＜ｉｎｐｕｔ  ｔｙｐｅ＝ｓｕｂｍｉｔ  ａｃｔｉｏｎ＝″ｎｅｘｔ″ｌａｂｅｌ＝″次へ″＞は、「次へ」と書かれたボタンを表示させるタグであり、クライアント７でこのボタンがクリックされた場合には、返信情報として”ｎｅｘｔ”という戻り値がサーバ１に返信される。＜＃ｓｌｏｔ＞は、ストリームプログラムの所定の処理ステップにおいて呼び出されたクラス定義プログラムの処理命令に応じてその表示内容が変化することを示したものである。
図５、６に示したクラス定義プログラムを説明する。このクラス定義プログラムは、牡蛎料理の注文に用いられる設定項目ごとのメンバ変数の宣言と、その設定項目情報を用いて処理される処理命令とをまとめたものであり、牡蛎料理の注文に関する処理の際に必要な情報が集約されている。図５，６に示したクラス定義プログラムにおいては、ｐａｃｋａｇｅ  ＯｙｓｔｅｒＯｒｄｅｒ；に示されるようにＯｙｓｔｅｒＯｒｄｅｒというクラスが定義されている。
クラス定義プログラムは、＃ＢＥＧＩＮ＃ＤＥＣＬＡＲＥ〜＃ＥＮＤ＃ＤＥＣＬＡＲＥで挟まれた部分で示された設定項目のデータ宣言部ｐ１と、ｓｕｂ〜｛  〜〜  ｝で示された処理命令部ｐ２〜ｐ７とで構成されている。
データ宣言部ｐ１では、データベース１１に対応する設定項目毎のメンバ変数の宣言を行っており、注文ＩＤ、牡蛎の銘柄を示すコード、調理方法を示すコード、調味料コードを入力するための符号付整数型のメンバ変数宣言と、調理方法についてのコメントを入力するためのテキスト入力用のメンバ変数宣言とが行われている。クラス定義プログラムがコンパイルされると、コンパイルの度に宣言されたメンバ変数に対応する設定項目がデータベースに作成される。このため、クラス定義プログラムにおいてメンバ変数の設定項目が変更された場合には、クラス定義プログラムのコンパイルの際に自動的にデータベース１１の設定項目も変更される。
処理命令部ｐ２は、クラスで用いられる設定項目毎の記憶領域を、記憶部１０のデータ記憶部に確保することによりインスタンスを生成する処理命令である。
処理命令部ｐ３は、データ記憶部に記憶された入力データを、データベース１１に登録する際に用いるシーケンス番号を生成する処理命令であり、この処理命令を実行させることによって、データベース１１にデータが登録されるときに既に登録されているデータ上に上書き保存されることを防止することが可能となる。
処理命令部ｐ４は、インスタンスで使用される設定項目の初期化を行う処理命令である。この処理命令がストリームプログラムにおいて引用されて実行されると、牡蛎の銘柄の銘柄コードを入力するためのインスタンスのメンバ変数｛ｂｒａｎｄ｝に岩牡蛎を示す設定値１が代入され、調理方法コードを入力するためのメンバ変数｛ｒｅｃｉｐｅ｝に生食を示す設定値１が代入され、調味料コードを入力するためのメンバ変数｛ｔｒｉｍｍｉｎｇ｝にレモンのみを示す設定値２が代入され、調理方法のコメントを入力するメンバ変数｛ｃｏｍｍｅｎｔ｝が空欄に設定される。
処理命令部ｐ５は、ページＡ１に設けられる注文入力フォームを作成するための処理命令である。この処理命令がストリームプログラムで引用されて実行されると、図８に示すようなＨＴＭＬ文書（ページＡ１）が作成される。ｃｇｉｏｓ３の指示に従って制御部９は、作成されたページＡ１に従ってクライアント７がデータを入力することが可能な設定項目を、ページＡ１を作成する際に引用されたインスタンスに関連づけて記憶部１０に記憶する。クライアント７が、ページＡ１に基づいて牡蛎の銘柄の種類等の入力データ２０の設定を行ってから、画面上の「次へ」ボタン２１をクリックすると、サーバ１に対して返信情報が送信される。返信情報が送信されたサーバ１では、返信情報に含まれる入力データの設定項目が記憶部１０に記憶される設定項目に該当するか否かの判断を制御部９が行い、該当する設定項目がある場合には、記憶部１０のデータ記憶部に記憶されている設定項目毎の入力データを返信情報に含まれる入力データへ自動的に更新し、該当しない場合には返信情報に含まれる入力データを破棄する。
処理命令部ｐ６は、返信情報に調味料コードに関連する設定項目の入力データが含まれており、さらに記憶部１０にも調味料コードに関連する設定項目が記憶されている場合であって、互いの設定項目は一致するが、入力コードのデータ値が許容データ値でない場合、例えば、調味料コードが同時に３種類選択された場合に、ページＡ１上にエラーメッセージを表示させる処理命令である。
処理命令部ｐ７は、ページＢ１において表示される注文確認項目と、ページＣ１において表示される注文完了項目とを作成する処理命令である。ページＢ１とページＣ１とは画面最上部に表示される見出しの表示と画面の最下部に表示されるボタンの種類が異なるだけで、牡蛎の銘柄、調理方法、調味料、コメントからなる表示項目は同じであるため、ステップ２における注文確認画面及びステップ４における注文完了画面の両方のＨＴＭＬ文書を作成する際に用いられる。
次にストリームプログラムについて説明する。ストリームプログラムは、クラス定義プログラムに記載された処理命令を引用することによって一連の窓口処理の流れが記述されたプログラムである。このストリームプログラムを用いることによって、ウェブアプリケーションにおける実行処理順序を「一単位の実行可能なプログラムコード」として記録することが可能となる。
図４に示すストリームプログラムは、ｔｏｐ、ｆｉｒｓｔ、ｓｅｃｏｎｄ、ｔｈｉｒｄ、ｆｏｕｒｔｈの５つの処理ステップによって構成されており、この処理ステップの情報が、処理ステップ情報として記憶部１０に記憶される。
まずｕｓｔｒｅａｍ  ｉｎｐｕｔ＿ｏｒｄｅｒ（＄ｏ）［＃注文入力ストリーム  〜〜  ］において、このストリームプログラムが注文入力ストリームであることを説明するとともに、この注文入力ストリームにおいて使用されるクラスが＄ｏで示される一つのインスタンスだけであることを宣言している。
ｔｏｐ：＄ｏ＝ｎｅｗ＜ＡＰＰ＞：：ＯｙｓｔｅｒＯｒｄｅｒ（＄Ｓ）；
より、ｎｅｗ処理命令（処理命令部ｐ２）が実行されることによってＯｙｓｔｅｒＯｒｄｅｒで示されるクラス用の記憶領域が確保され、その記憶領域に＄ｏで示されるインスタンスが生成される。さらに、＄ｏ−＞ｄｅｆａｕｌｔ；によって処理命令ｄｅｆａｕｌｔ（処理命令部ｐ４）が実行されて、＄ｏで示されるインスタンスの設定項目の初期値設定が行われる。
なお、このストリームプログラムにおいては、１つのインスタンス＄ｏしか使用されていないが、複数のインスタンスを用いて一連の処理を行う場合には、
ｓｔｒｅａｍ  ｉｎｐｕｔ＿ｏｒｄｅｒ（＄ｏ１，＄ｏ２）［＃注文入力ストリーム
ｔｏｐ：
＄ｏ１＝ｎｅｗ＜ＡＰＰ＞：：ＯｙｓｔｅｒＯｒｄｅｒ（＄Ｓ）；
＄ｏ１−＞ｄｅｆａｕｌｔ；
＄ｏ２＝ｎｅｗ＜ＡＰＰ＞：：ＯｙｓｔｅｒＯｒｄｅｒ（＄Ｓ）；
＄ｏ２−＞ｄｅｆａｕｌｔ；
に示すように同一のクラスを用いて複数のインスタンス＄ｏ１、＄ｏ２を宣言することも可能である。
次の処理ステップｆｉｒｓｔでは、図７（ａ）に示したページ定義を利用して、図８に示すページＡ１が作成される。ここで、＄Ｖ−＞［ＳＬＯＴ］＝［ｓｌｏｔ＝＞＄ｏ−＞ｉｎｐｕｔ］；と記載されていることから、図７（ａ）の＜＃ｓｌｏｔ＞のタグの部分に、インスタンス＄ｏのｉｎｐｕｔ処理命令（処理命令部ｐ５）によって作成される注文入力フォームが、はめ込まれるようにして表示される。処理ステップｆｉｒｓｔのプログラムには記載されていないが、ｆｉｒｓｔの処理ステップにより作成されたページＡ１には、セッション値と乱数とが暗号化されて付加され、さらに、記憶部１０にセッション値、乱数値、処理ステップ情報（ここでは処理ステップがｆｉｒｓｔである旨の情報）が記憶されるとともに、ｉｎｐｕｔ処理命令において使用される設定項目情報、具体的には、牡蛎の銘柄、牡蛎の料理方法、添える調味料、コメントの４つの設定項目情報がインスタンス＄ｏに関連付けて記憶される。また、
ｉｆ（＄Ｖ−＞［ａｃｔｉｏｎ］ｅｑ″ｎｅｘｔ″）［ｇｏｔｏ  ｓｅｃｏｎｄ；］
ｇｏｔｏ  ｆｉｒｓｔ；
より、ページＡ１において図８に示される「次へ」ボタン２１がクリックされると、ストリームプログラムにおける次の処理ステップｓｅｃｏｎｄに制御部９の処理が移行する。
なお、ページＡ１の「次へ」ボタン２１がクリックされると処理ステップｓｅｃｏｎｄに制御部９の処理が移行することとなるが、処理が移行される前に、既に説明したように、制御部９がクライアント７からの返信情報を取得して、セッション値、乱数値、入力データにおける設定項目情報の抽出・比較処理を行う。制御部９は、返信情報よりセッション値及び乱数値が検出されない場合及びセッション値が一致しない場合には、返信情報を破棄する。また、検出されたセッション値と記憶部１０に記憶されたセッション値は同一であるが、検出される乱数値と記憶部１０に記憶される乱数値が異なる場合には、クライアント７においてブラウザの「戻る」ボタン２２等を押してキャッシュに記憶されている古いＨＴＭＬ文書を表示させた後に、その古いＨＴＭＬ文書に基づいて返信情報が返信されたものと判断することができる。古いＨＴＭＬ文書に基づいて返信情報が返信されたものと判断された場合、制御部９は再度処理ステップｆｉｒｓｔの処理を実行し、検出されたセッション値及び乱数値が記憶部１０に記憶されるセッション値及び乱数値と一致する場合には、返信情報よりクライアント７が入力した入力データの設定項目を検出して、データ記憶部の設定項目に、該当する入力データを更新記憶させる。該当しない項目の入力データに関してはそのデータを破棄してから、次の処理ステップｓｅｃｏｎｄに処理を移行する。
次の処理ステップｓｅｃｏｎｄでは、ページＢを作成する前に、制御部９返信情報の内容についてエラーがないかチェックする。
ｉｆ（＄ｏ−＞［ＥＲＲＯＲ］＝＄ｏ−＞ｃｈｅｃｋ）［ｇｏｔｏ  ｆｉｒｓｔ；］
によって、インスタンス＄ｏのｃｈｅｃｋ処理命令（処理命令部分ｐ６）の処理が実行され、クライアント７おいて調味料が３種類選択された場合には、処理ステップｆｉｒｓｔに戻って、図１２に示すようにエラー表示を表示させる。
処理ステップｓｅｃｏｎｄにおいて、調味料が図８に示すように１種類しか選択されていない場合には、図７（ｂ）に示したページ定義を利用して、図１０に示したページＢ１が作成される。また、図９に示すように、調味料の選択が２種類以下である場合には、図１１に示したページＢ１が作成される。
このページＢ１の作成の際には、インスタンス＄ｏのｐｒｉｎｔ処理命令（処理命令部ｐ７）の処理が実行され、処理ステップｆｉｒｓｔにおいて返信情報としてクライアント７からサーバ１に返信されたページＡ１の入力データが表示される。ページＢ１においては、ページＡ１と違って「注文実行」ボタンと、「戻る」ボタンとが表示される。ここで「注文実行」ボタンがクリックされると次の処理ステップであるｔｈｉｒｄに処理が進み、「戻る」ボタンをクリックすると一つ前の処理ステップであるｆｉｒｓｔの処理に戻ることとなる。
次の処理ステップｔｈｉｒｄでは、インスタンス＄ｏに用いられるメンバ変数｛ｏｒｉｄ｝に対してｎｅｘｔｏｒｉｄ処理命令（処理命令部ｐ３）を実行することによってシーケンス番号を代入し、＄＄Ｓ［ＤＡ］−＞ｓａｖｅＯｂｊｅｃｔ（＄ｏ）；により、シーケンス番号が入力されたメンバ変数｛ｏｒｉｄ｝を主キーとしてインスタンス＄ｏの設定項目毎の入力データがデータベース１１に記憶される。
その後、処理ステップがｆｏｕｒｔｈに進んで、図７（ｃ）に示したページ定義を利用して、図１３に示したページＣ１が作成される。処理ステップｆｏｕｒｔｈにより一通りの牡蛎料理の注文処理が終了するが、ビューＣ１に表示される「最初に戻る」ボタンをクリックすることによって、再度処理ステップｆｉｒｓｔの処理を繰り返し行うことが可能である。
以上説明したように本発明に係るサーバ１は、サーバ１が実行する一連の窓口処理をサーバ１でその処理ステップの処理状況を確認しながら実行することが可能となる。このため、一連の窓口処理が手順に従って行われるか否かがクライアント７に委ねられていた従来のウェブアプリケーションサーバに較べて、本発明に係るサーバ１は、一連の窓口処理が処理手順に従って実行されるように、サーバ７に送信するＨＴＭＬ文書の表示内容を制御することができ、サーバ１側の裁量で窓口処理を進めることによって意図しない処理の遷移を防止することが可能となる。
また、実行プログラムを作成するプログラマーはストリームプログラムを作成するだけで、クライアントの特定及び処理ステップ毎の返信情報の確認等の処理をプログラム上に記述しなくても、クライアントの特定、返信情報における入力データの保存等が確実に実行されるので、プログラム作成の労力が低減されるとともに、プログラムの修正・変更処理が容易になる。
さらに、本発明に係るサーバ１は、ｃｇｉｏｓ３の指示により、返信情報に含まれる入力データの設定項目の種類が、送信したＨＴＭＬ文書の入力フォームにおいて入力可能な設定項目の種類に対応するものであるか否かを制御部９が判断して、入力データの設定項目と記憶されたが設定項目とが異なる場合にはその入力データを破棄し、一致する場合にはその入力データをインスタンスに関連付けて自動的に記憶部１０のデータ記憶部に記憶させることができる。このため、本発明に係るサーバ１において、意図しない入力データがクライアント７からの返信情報として記憶されてその後の処理に反映されることを防止することができる。
また、プログラマーは、返信情報に含まれる入力データが適正なデータであるか否かの判断を行う処理をプログラムで規定しておく必要がないので、プログラム作成労力の一層の低減を図ることが可能となるとともに、サーバ１の安定性向上を図ることが容易となる。
さらに、ＨＴＭＬ文書の送信時及び返信情報の受信時にのみ、記憶部１０に記憶された必要なデータを読み出して（復帰させて）制御部９に必要な処理を行わせることができるので、制御部９は複数のストリームプログラムを用いたマルチタスク処理を容易に実現することが可能となる。
また、クラス定義プログラムごとに一連の窓口処理で使用される設定項目毎のメンバ変数とその設定項目を利用する処理命令とがまとめられており、他のクラス定義プログラムやストリームプログラムにおいてメンバ変数は記載されないので、一連の窓口処理で使用されるメンバ変数が変更される場合であっても、クラス定義プログラム内のメンバ変数の宣言内容を変更するだけで良い。このため、他のクラス定義プログラム及びストリームプログラム等を変更することなく、クラス定義プログラムに記載されるメンバ変数の設定項目や処理命令を変更するだけで容易に仕様変更を行うことが可能となり柔軟性に富んだシステム構築を行うことが可能となる。特に、ｃｇｉｏｓ３では、同一ストリームプログラムにおいて同一のクラスから生成された複数のインスタンスが用いられている場合であっても、ｃｇｉｏｓ３がクラスのメンバ変数を、各インスタンスの設定項目毎に管理するので、プログラマーはストリームにおいて使用されるメンバ変数の設定項目が重複する場合であっても、プログラム上でその違いを明確にすることなくストリームプログラムを作成することができる。
例えば、図１４に示すように、１画面において牡蛎の銘柄、牡蛎の調理方法、添える調味料、コメントの項目を２組表示させるページＤを作成する場合、ストリームプログラムにおいては、＄ｏ１と＄ｏ２との２つのインスタンスを宣言することによって、ＯｙｓｔｅｒＯｒｄｅｒクラスに使用されるメンバ変数の設定項目毎のデータを、＄ｏ１と＄ｏ２とからなる識別子を用いてそれぞれを区別し、別々に記憶する。ビューＤをクライアント７に送信する場合には、入力フォームにおけるインスタンス＄ｏ１の設定項目（牡蛎の銘柄、牡蛎の調理方法、添える調味料、コメント）とインスタンス＄ｏ２の設定項目（牡蛎の銘柄、牡蛎の調理方法、添える調味料、コメント）とを区別して記憶部１０に記憶させ、返信情報より入力データを検出する場合も、インスタンス＄ｏ１の入力データの設定項目（牡蛎の銘柄、牡蛎の調理方法、添える調味料、コメント）とインスタンス＄ｏ２の入力データの設定項目（牡蛎の銘柄、牡蛎の調理方法、添える調味料、コメント）とを区別して抽出し、それぞれデータ記憶部に別々の入力データとして記憶する。
具体的に、図１９を用いて、図１４に示す入力フォームの設定項目のうち“牡蛎の銘”柄欄と“コメント”欄だけに注目して、上述した処理を説明する。図１９に示すように、サーバ１の制御部９は、ｃｇｉｏｓ３を用いて“牡蛎の銘柄”、“コメント”の設定項目を２つの識別子＄ｏ１と＄ｏ２とを用いてそれぞれ区別し、一意に区別される通し番号（例えば、“ａ”、“ｂ”、“ｃ”・・・）を割り付けて記憶部１０に記憶させる。制御部９は、インスタンス＄ｏ１の設定項目として、牡蛎の銘柄に関するデータであって１〜３の数値により選択される選択形式のデータ“ａ”と、コメントに関するデータであってテキスト形式のデータであるデータ“ｂ”とを記憶部１０に入力フォーム台帳として記憶させる。同様に制御部９は、インスタンス＄ｏ２の設定項目として、牡蛎の銘柄に関するデータであって１〜３の数値により選択される選択形式のデータ“ｃ”と、コメントに関するデータであってテキスト形式のデータであるデータ“ｅ”とを記憶部１０に入力フォーム台帳として記憶させる。
その後、制御部９は、２つの入力フォーム２０を含むＨＴＭＬ文書を作成してクライアント７に送信する。クライアント７により入力フォームに対応する返信情報が返信されると、制御部９は、返信情報の設定項目が記憶部１０に記憶された入力フォーム台帳の設定項目に該当するか否かの判断を行う。該当する場合、制御部９は、返信情報に含まれるデータ“ａ”がインスタンス＄ｏ１の“牡蛎の銘柄”に関するデータであり、データ“ｂ”がインスタンス＄ｏ１の“コメント”に関するデータであり、データ“ｃ”が、インスタンス＄ｏ２の“牡蛎の銘柄”に関するデータであり、データ“ｄ”がインスタンス＄ｏ２の“コメント”に関するデータであると判断し、それぞれのデータをデータ記憶部に記憶する。
このように、重複する設定項目からなる入力フォームをＨＴＭＬ文書で作成する場合であっても、各設定項目に対応する処理命令を１つ用意して、同一クラスを用いて複数のインスタンスを生成することによって、各設定項目の区分けをｃｇｉｏｓで自動的に行わせることができ、クラス定義プログラムの処理命令だけを変更するだけで容易に入力フォームの表示形式、設定項目等の仕様変更を容易に行うことができる。さらに、クラス定義プログラムで使用されるメンバ変数は他のクラス定義プログラムやストリームプログラム等に依存しないので、クラス定義プログラムの設定項目等を変更しても、その変更に起因するシステム全体のエラーの発生を低減させることができる。
なお、ｃｇｉｏｓ３は、一連の窓口処理の流れを示すストリームプログラムと、このストリームプログラムで使用されるインスタンスのメンバ変数とそのメンバ変数を用いる処理命令とでまとめたクラス定義プログラムとを組み合わせてプログラム構成を行うので、今までのＨＴＭＬ文書の作成技法では困難であったと入力フォームを容易に作成することが可能となる。例えば、注文されたデータの一覧表をＨＴＭＬ文書において作成する場合には、表外枠、見出し、各種設定項目等をインスタンスの処理命令により特定の出力形式で作成し、作成された一覧表をストリームプログラムにおいて引用することによって、一覧表をＨＴＭＬ文書に挿入するようにして貼り付けることが可能となるので、各行が入力フォームを持つような表一覧を簡単に作成することができる。さらに、ストリームプログラムから他のストリームプログラムを呼び出すことも可能であるため、上述の牡蛎料理の注文処理を示したストリームプログラムにおいて、表一覧を作成する表一覧作成ストリームを呼び出し、この表一覧作成ストリームにおいてインスタンスから表一覧を作成するための処理命令を引用して表一覧を作成し、表一覧作成後に牡蛎調理の注文処理のストリームに処理を戻すことも可能である。さらに、表一覧を作成する方法を応用することによって、ＨＴＭＬ文書における表一覧の他に、Ｍｉｃｒｏｓｏｆｔ  ｅｘｃｅｌ（登録商標）に対して一覧表形式にデータを出力することも可能である。
また、ストリームプログラムにおいて他のストリームプログラムを呼び出す方法とＨＴＭＬ文書を作成するためのページ定義とを活用することによってウェブページにおけるウィンドウ管理をサーバ１で行うことが可能となる。従来のウェブアプリケーションでは、基本的に１つのウェブページでは１つの処理しか実行することができず、複数の処理を行う場合にはクライアント７が使用するブラウザのフレーム機能を用いることが一般的であった。しかしながらブラウザのフレーム機能の動作は、基本的にクライアント７の裁量に委ねられているので、サーバ１が意図する形式のウィンドウ表示とならない場合があった。ｃｇｉｏｓ３では、ＨＴＭＬ文書のページ定義によりウィンドウ表示形式を決定し、各ウィンドウ内で個別にストリームプログラムを実行させて、各ストリームプログラムの実行結果として出力されるＨＴＭＬ文書を該当するウィンドウに貼り付けて１つのウェブページを生成することができるので、ブラウザのフレーム機能に依存することなくウィンドウ管理を行うことが可能となる。
さらに、ウィンドウ毎に実行される各ストリームプログラムの処理に応じて記憶部１０に記憶されたデータの読み出し（復帰）、記憶（退避）を行うことができるので、マルチウィンドウを用いたマルチタスク処理を簡易に実現することが可能となる。
図１５に示すような３つのウィンドウを有するＨＴＭＬ文書をｃｇｉｏｓ３で作成する方法を、図１６に示したストリームプログラムと、図１７に示したページ定義とを用いて説明する。まず、図１６（ａ）に示した起動ストリームプログラムにより、ウィンドウの設定がされていないウェブページ（起動ストリームプログラムのｐ＿ｆｏｒｋ（″￣″，″／￣／″，″ｔｈｉｓ″）の″ｔｈｉｓ″がその旨を示している）上で図１６（ｂ）に示すウィンドウ起動ストリームプログラムを実行し、ｐ＿ｗａｉｔ（）により起動ストリームプログラムの処理の待機を行う。
起動ストリームプログラムにおいてウィンドウ起動ストリームプログラムが実行されると、図１７（ａ）に示したページ定義が用いられた図１５に示すような３つのウィンドウが形成され、このウィンドウの″ｍｅｎｕ″部分において図１６（ｃ）に示すメニューストリームプログラムが実行される。
メニューストリームプログラムが実行されて、ウィンドウの”ｍｅｎｕ”部分に図１７（ｂ）に示したページ定義のメニュー表示が表示され、メニュー表示において注文入力がクリックされるとウィンドウのｖｉｅｗ部分において牡蛎料理の注文処理に関するストリームプログラムが実行されて、図１８に示すように牡蛎料理の注文に関する入力フォームが作成される。また、メニュー表示において注文一覧表示がクリックされると、注文一覧表示を行うストリームプログラムが実行される。
このように、複数のページ定義と、複数のストリームプログラムを活用することによって、一連の窓口処理の内容に応じて入力フォーム等を表示させるウィンドウを使い分けることが可能となる。さらに、クライアント７のブラウザにおけるフレーム機能に依存されずにウィンドウ管理を行うことができるので、サーバ１側で意図したウィンドウ表示をクラインアント７のウェブページ上で表示させることが可能となる。
以上本発明に係るサーバを説明してきたが、本発明に係るサーバは上記発明の実施の形態に示したものに限定されるものではない。例えば、本発明の実施の形態においては、ｃｇｉｏｓ３がＯＳ上で動くミドルウェアであるものとして説明を行ったが、ウェブサーバ用アプリケーション（例えばＡｐａｃｈｅ等）において実行される支援ソフトウェア（支援プログラム）であっても良い。さらに、ｃｇｉｏｓ３自体がオペレーションシステムであって、オペレーションシステムにおいてｃｇｉｏｓ特有の機能を実現させたものであっても良い。
また、サーバ１がｃｇｉｏｓ３の機能を利用して処理を行う場合に、必ずしもストリームプログラムを用いる必要はなく、ストリームプログラムを用いずに、クライアント７に送信する入力フォームの設定項目を入力フォーム台帳として記憶部１０に記憶し、クライアント７から返信された返信情報の設定項目と記憶部１０に記憶された設定項目とを対比して受信した設定項目の種類が同一であるか否かの判断を行うようにしてもよい。
例えば、制御部９は、図２０に示すように、入力フォームにおいてクライアント７が入力可能な設定項目に対してそれぞれ通し番号“ａ”〜“ｃ”を割り付けて記憶部１０に入力フォーム台帳として記憶させる。このとき制御部９は、牡蛎の銘柄に関するデータであって１〜３の数値により選択される選択形式のデータをデータ“ａ”とし、コメントに関するデータであってテキスト形式のデータをデータ”ｂ”とし、クライアント７に送信するＨＴＭＬ文書に設定されるボタンを押下したことを示すボタンアクションデータをデータ“ｃ”として記憶部１０に記憶させる。
その後、制御部９は、クライアント７から返信された返信情報を受信して返信情報からデータ“ａ”〜“ｃ”に該当する情報を抽出し、記憶部１０に入力フォーム台帳として記憶される設定項目の種類と返信情報の”ａ”〜”ｃ”の設定項目の種類とを比較して一致する場合には、牡蛎の銘柄、コメントのデータをデータ記憶部に記憶し、一致しない場合には受信した返信情報を破棄する。例えば、返信情報に含まれるデータ“ａ”の値が９である場合、制御部９は、入力フォーム台帳よりデータ“ａ”が１〜３の数値により選択される選択形式のデータであることを判断し、データ“ａ”が９である返信情報が不適切なものであるものと判断して返信情報を破棄する。
このように、ストリームプログラムの有無に拘わらずサーバ１がクライアント７に送信するＨＴＭＬ文書の入力フォームの設定項目を記憶部１０に記憶させ、クライアント７より受信した返信情報の設定項目が記憶部１０に記憶された入力データの設定項目と同一種類か否かを判断することによって、意図しない入力データが返信情報としてデータ記憶部に記憶されてその後の処理に反映されることを防止することが可能となる。
また、サーバ１がｃｇｉｏｓ３の機能を利用して、記憶部１０に記憶させる入力フォームの情報を、サーバ１の処理に適したデータ形式からクライアント７でのデータ入力に適したデータ形式に加工・変更を行った後にクライアント７に送信し、返信された返信情報を加工・変更を行う前の形式に復元した後にサーバ１において処理を実行する様にしてもよい。
例えば、ＵＮＩＸは、１９７０年１月１日０時０分０秒からの積算秒数を用いて一般的な時間の管理を行っている。このため、入力フォームにおいてクライアント７に“年”、“月”、“日”、“分”を別々に分けて選択させる場合、ｃｇｉｏｓ３では、積算秒数で示される日時情報（以下、積算情報とする）と、“年”、“月”、“日”、“分”等の単位で表示される日時情報（以下、時分情報とする）との変換を行う”Ｃａｌｅｎｄａｒタグ”処理モジュールを利用して、積算情報と時分情報との変換を行ってもよい。具体的には、図２１に示すように、“年”に関するデータであって西暦表記された２０００、２００１・・・の数値により選択される選択形式のデータをデータ“ａ”とし、“月”に関するデータであって１〜１２の数値により選択される選択形式のデータをデータ“ｂ”とし、“日”に関するデータであって１〜３１の数値により選択される選択形式のデータをデータ“ｃ”として記憶部１０に記憶させ、クライアント７に、入力フォームとして日時情報が加えられてＨＴＭＬ文書を送信する。
クライアント７から返信情報が返信されると、サーバ１は受信した返信情報よりデータ“ａ”、“ｂ”、“ｃ”の設定項目が記憶部１０に記憶された設定項目と同一種類のものかどうかの判断を行い、異なる場合には返信情報を破棄し、同一である場合には、ｃｇｉｏｓ３の”Ｃａｌｅｎｄａｒタグ”処理モジュールを利用して返信情報に含まれる時分情報を積算情報に変換し、データ記憶部に記憶する。
このように、ｃｇｉｏｓ３において、サーバ１での処理に適したデータ形式を入力フォームの設定項目に応じたデータに変換し、変換したデータを入力フォーム台帳として記憶部１０に記憶させるとともに、クライアント７から返信された返信情報の設定項目と記憶部１０に記憶される設定項目とを比較し、設定項目の種類が一致する場合には、返信情報をサーバ１の処理に適したデータ形式に変換することによって、プログラマが返信情報に含まれる入力データの変換処理プログラムを作成することなく返信情報のデータをサーバ１に適したデータ形式で使用することが可能となる。
さらに、入力フォームとしてチェックボックスが用意されている場合、入力フォームの設定項目の種類に加えて、チェックボックスをチェック済にした設定項目を特定してその項目がチェック済となっている旨を記憶部１０に記憶させてもよい。
具体的には、クライアント７に送信するＨＴＭＬ文書にチェックボックス欄を設け、そのチェックボックス欄を予めチェック済としてＨＴＭＬ文書を作成してクライアント７に送信する。このとき制御部９は、入力フォームの設定項目の他に、その設定項目のうちチェックボックスをチェック済みとした項目にチェックボックスがチェック済として設定されている旨のデータを対応付けて記憶部１０に記憶させる。
その後、制御部９は、クライアント７より返信された返信情報の設定項目と入力フォーム台帳の設定項目とを比較し、入力フォーム台帳においてチェック済として記録されたチェックボックスの設定項目に対応する情報が、返信情報に含まれているか否かを判断する。通常、クライアント７から返信されるチェックボックスに関する情報は、チェックボックスがチェックされている場合には返信情報に含まれて返信されるが、チェックボックスがチェックされていない場合（チェック済であったものをチェックなしに変更した場合を含む）には含まれない。このため、制御部９は、返信された返信情報の設定項目のうち、チェック済としたチェックボックスに関する情報が含まれているか否かを、入力フォーム台帳の情報を参照しながら判断する。チェック済として記録されたチェックボックスに関する情報が返信情報に含まれていない場合、制御部９は、クライアント７が意図的にチェックボックスのチェックを外したものと判断する。
このように、入力フォーム台帳としてチェックボックスの設定項目の種類とチェック済とされたチェックボックスの設定項目とを記憶部１０に記憶させることにより、記憶部１０にチェック済として記憶されたチェックボックスに関する情報が返信された返信情報に含まれていない場合には、クライアント７が意図的にチェックを外したものと判断することができ、チェックボックスにおいてチェックがされていないという情報を積極的に知得することが可能となる。また、これらの判断はｃｇｉｏｓ３の機能を用いることによって、チェックボックスのチェックが外されたか否かの判断をプログラムによって実現させる必要性がなくなるので、プログラムの作成労力・作成工程の低減を図ることが可能となる。
【図１】
2004057483.tif 000003
【図２】
2004057483.tif 000004
【図３】
2004057483.tif 000005
【図４】
2004057483.tif 000006
【図５】
2004057483.tif 000007
【図６】
2004057483.tif 000008
【図７】
2004057483.tif 000009
【図８】
2004057483.tif 000010
【図９】
2004057483.tif 000011
【図１０】
2004057483.tif 000012
【図１１】
2004057483.tif 000013
【図１２】
2004057483.tif 000014
【図１３】
2004057483.tif 000015
【図１４】
2004057483.tif 000016
【図１５】
2004057483.tif 000017
【図１８】
2004057483.tif 000018
【図１６】
2004057483.tif 000019
【図１７】
2004057483.tif 000020
【図１９】
2004057483.tif 000021
【図２０】
2004057483.tif 000022
【図２１】
2004057483.tif 000023
【図２２】
2004057483.tif 000024
【図２３】
2004057483.tif 000025
【図２４】
2004057483.tif 000026
【図２５】
2004057483.tif 000027
【図２６】
2004057483.tif 000028
【図２７】
2004057483.tif 000029
【国際調査報告】
2004057483.tif 000030
2004057483.tif 000031
2004057483.tif 000032
2004057483.tif 000033