JP4649301B2 - 通信方法及びサーバ装置 - Google Patents

Description

本発明は、クライアント・サーバシステムに関する。

ネットワークを介して様々なサービスを提供するサーバと、所望のサービスをサーバに対して要求するクライアントとから構成される、クライアント・サーバシステムが広く普及している。特に、インターネット上でＨＴＴＰ（hyperText transfer protocol）を使って通信するＷｅｂサーバとクライアントからなるWorldwide webシステム（あるいは単にＷｅｂシステムとも呼ばれる）は、大変広く利用されているクライアント・サーバシステムである。通常、サーバ上ではサーバプログラムが動作し、クライアント上ではブラウザなどの所定のツール（プログラム）が動作する。

インターネット上で提供されるサービスの内容も多岐に渡っており、ネットワーク経由で文字、静止画像、動画像、音声等の情報（たとえば、ホームページ、電子メール、デジタルコンテンツなど）や、プログラムなどを提供、配信あるいは転送などするサービス、また商品を販売するための電子店舗サービス、座席や部屋などの予約サービス、種々の仲介サービスなど、種々のサービスが既に存在し、また次々と新たな形態のサービスが出現している。

ところで、ＨＴＴＰを用いて通信するサーバは多様化するＷｅｂサービスに対応するため、ＷＥＢシステムが出現した当初の静的なＷｅｂページをクライアントリクエストに対して返すだけの単純な処理を行う静的なサーバから、リクエストパラメータやデータベースから取得した値に基づいてユーザの所望するＷｅｂページを動的に生成し、レスポンスを返すＷｅｂアプリケーションが動作するサーバに移行している。

例えばＷｅｂシステムを用いたポータルサイトではユーザの嗜好に合わせてカスタマイズしたＷｅｂページが動的に生成される。これはＣｏｏｋｉｅなどを用いてユーザを識別するとともに、予めユーザによって登録された本人の興味などに基づいて、Ｗｅｂアプリケーションがユーザ毎に動的にＷｅｂページを生成することによって実現されている。このような動的にページを生成するＷｅｂアプリケーションは様々な技術を用いて構築される。

例えばＰｅｒｌ言語やＣ言語によって動的にＷｅｂページを生成するCommon Gateway Interface（ＣＧＩ）技術、Ｊａｖａ（商標）バーチャルマシン上で動作するJava Servlet／JSP（Java Server Pages）技術、JavaScriptやVisualBasic Scriptなどのスクリプト言語、各種ActiveXコンポーネントを動作させるActive Server Pages（ＡＳＰ）技術などがある。

特に近年、クロス・プラットフォームで動作し、様々なツールベンダが開発環境を提供するJava ServletやＪＳＰなどといったＪ２ＥＥ（Java2 Enterprise Edition）技術が大きな注目を集めている。例えば、オープンソースコミュニティThe Apache Software Foundation （http://www.apache.org）が開発・メンテナンスを行なっているStruts（http://jakarta.apache.org/struts）はSun Microsystems社が提供するＪ２ＥＥ環境を用いたＷｅｂアプリケーション開発フレームワークのデファクトスタンダードとなっている。

ＳｔｒｕｔｓはＪＳＰに基づいた技術であり、ＪＳＰタグが出力するデータ（多くの場合はＨＴＭＬタグ）によってＷｅｂページを動的に生成する。さらに、Ｊａｖａのオブジェクト指向を利用したＪＳＦ（JavaSever Faces）フレームワークも２００３年初頭にSun Microsystems社からリリースされている（非特許文献１参照）。ＪＳＦで開発されたＷｅｂアプリケーションはＳｔｒｕｔｓで開発されたＷｅｂアプリケーションとは異なり、出力するデータ（多くの場合はＨＴＭＬタグ）を抽象化したコンポーネントから構成される。各コンポーネントは出力するデータの階層構造（ＨＴＭＬタグの階層構造など）に従ってコンポーネントツリーとしてＷｅｂアプリケーション内に保持される。これはＪａｖａを始めとしたオブジェクト指向言語で開発されスタンドアロン・アプリケーションやアプレット等といったＧＵＩ部品の階層構造から形成されるアプリケーションと酷似している。コンポーネントの階層構造によって、ＧＵＩ部品のドラッグ＆ドロップとプロパティのセットで開発を行なう従来のオブジェクト指向言語によるアプリケーション開発と同じように直感的な開発が可能となる。またＪＳＦはＪａｖａ技術の標準化を行なうJava Community Process（ＪＣＰ）で標準化をされており、今後様々な開発ツールによってサポートされると期待されている。

一方、サーバ側の進化とは別にＷｅｂページを閲覧するＷｅｂブラウザも大きな進化が進んでいる。動的にＷｅｂページをレスポンスする動的なサーバも基本的にはＨＴＭＬを出力する。

ＨＴＭＬとＷｅｂブラウザは元来情報を閲覧するためのツールであって、情報を入力するためのツールではなかった。そのため、情報入力ツールとして貧弱な機能しかもたない。例えばファンクションキーが使えない、ドラッグ＆ドロップが使えない、などその操作性に限界があった。こういった問題に対処するためにＨＴＭＬにJavaScriptやDynamic HTML（ＤＨＴＭＬ）を埋め込むことで、ある程度操作性や表現力を改善することはできる。しかし、Ｗｅｂシステムが出現する前のＣ／Ｓ（クライアント・サーバ）システムと比較するとまだ改善の余地がある。

ＪａｖａアプレットやＦｌａｓｈなどといったＷｅｂブラウザ上で動作する別のアプリケーションによってこの問題に対処することが可能である。

このようなＷｅｂブラウザ上で動作するアプリケーションは、ＨＴＭＬのアプリケーション起動命令タグによって、Ｗｅｂブラウザが指定されたＵＲＬからダウンロードするか予め各クライアントに配布済みのものをＷｅｂブラウザがロードして起動される。また、起動命令を出力するＷｅｂアプリケーションとは別に専用ツールを用いて別途開発する必要がある。アプリケーションの動作に必要となるソフトウェア環境はＷｅｂブラウザに予めインストールされたプラグインによって提供される。上述のようなＷｅｂブラウザ上で動作する別アプリケーションによってクライアントの操作性や表現力を向上させるとともに、クライアント側に専用のスタンドアロン・アプリケーションをインストールすることなくＣ／Ｓ型システムと同等、もしくはそれ以上の操作性をＷｅｂシステムで実現することが可能となってきた。

以上述べたように、Ｗｅｂアプリケーションとして動的なＷｅｂページを生成することでＷｅｂシステムの柔軟性や機能を向上させるとともに、Ｗｅｂブラウザ上で実行されるクライアント側アプリケーションによって操作性や表現力を向上させることが必要となってきている。その為には、クライアント側アプリケーションの起動命令を出力するようにＷｅｂアプリケーションを開発するとともに、クライアント側アプリケーションを別途開発する必要がある。

さらに、クライアント側アプリケーションに入力された値などをサーバ側と通信するためにクライアント側アプリケーション専用のアプリケーション・サーバを開発する必要がある。その場合、クライアント側アプリケーションが上記アプリケーション・サーバと通信し、入力値などの同期を行う。

Ｗｅｂアプリケーションはアプリケーション・サーバと直接、もしくはデータベースなどを介して上記値を取得し、Ｗｅｂページを生成するためのデータを更新する。

または、Ｗｅｂアプリケーションにクライアント側アプリケーションと通信するための専用オブジェクトを持たせることで、クライアント側アプリケーションの入力値を上記オブジェクトを介して取得し、Ｗｅｂページを生成するためのデータを更新する。
JavaServer FacesによるWebアプリケーション開発、川崎克己著、秀和システム、2004、ISBN-4798008303

１つのＷｅｂページ上に、Ｗｅｂアプリケーションで生成されたＧＵＩ部品と、クライアント側アプリケーションにより表示されるＧＵＩ部品とが共存する場合、クライアント側アプリケーションにより表示されるＧＵＩ部品の入力フィールドに入力された値と、Ｗｅｂアプリケーションにより生成されるＧＵＩ部品の表示フィールドに表示される値とを同期させるためには、例えば、クライアント側アプリケーション専用のアプリケーションサーバが必要となり、システム全体の開発効率を向上させる必要があった。

アプリケーションサーバがない場合は、Ｗｅｂアプリケーションにクライアント側アプリケーションと通信を行なうための専用オブジェクトが用いられる。クライアント側アプリケーションの入力値を分散オブジェクト方式の通信（Remote Method Invocation（ＲＭＩ）やRemote Procedure Call（ＲＰＣ）など）や、ソケットを介したＴＣＰ／ＩＰなどといった低レベル通信で専用オブジェクトと同期を取り、Ｗｅｂアプリケーションが動的にページを生成するために用いる値に同期させる。

この場合、専用通信を用いるため、通常は、ＨＴＴＰリクエストによって起動し、値を更新するＷｅｂアプリケーションが関知しない間にページ生成に用いる値が更新されるため、Ｗｅｂアプリケーションに不具合が生じないような開発が必要となる。さらに、不具合を回避するためには、Ｗｅｂアプリケーションの実装に依存するという問題点があった。

このように、従来は、１つのＷｅｂページ上に、Ｗｅｂアプリケーションで生成されたＧＵＩ部品と、クライアント側アプリケーションにより表示されるＧＵＩ部品とが共存する場合、クライアント側アプリケーションにより表示されるＧＵＩ部品の入力フィールドに入力された値と、Ｗｅｂアプリケーションあるいはクライアント側アプリケーションにより表示されるＧＵＩ部品の表示フィールドに表示される値とを容易に同期させることができないという問題点があった。

そこで、本発明は上記問題点に鑑み、１つのＷｅｂページ上に、Ｗｅｂアプリケーションで生成されたＧＵＩ部品と、クライアント側アプリケーションにより表示されるＧＵＩ部品とが共存する場合、クライアント側アプリケーションにより表示されるＧＵＩ部品の入力フィールドに入力された値に同期して（入力された値に対応するように）、Ｗｅｂアプリケーションあるいはクライアント側アプリケーションにより表示されるＧＵＩ部品の表示フィールドの表示更新が容易に行える通信方法、サーバ装置及びクライアント側アプリケーションを提供することを目的とする。

本発明のサーバ（Ｗｅｂアプリケーション）は、クライアント装置のブラウザで表示する第１のＧＵＩ部品群に対応するＨＴＭＬ（hyper text markup language）のエレメント群を生成するための第１のＵＩコンポーネント群と、クライアント装置で起動されるクライアントアプリケーションにより表示される第２のＧＵＩ部品群に対応する第２のＵＩコンポーネント群とを含むＵＩコンポーネントツリーと、第１及び第２のＧＵＩ部品群のうち表示フィールドに表示すべきデータを記憶する記憶手段とを備える。そして、クライアント装置から送信されたＨＴＴＰ（hyperText transfer protocol）リクエストに、第２のＧＵＩ部品群のうちの入力フィールドに入力された値と当該入力フィールドに対応するＵＩコンポーネントの識別子とを含むパラメータが含まれているときには、第２のＵＩコンポーネント群のうち、当該ＨＴＴＰリクエストのパラメータ中の識別子に対応するＵＩコンポーネントが、当該パラメータから値を取得し、当該値を用いて記憶手段を更新することにより、ＵＩコンポーネントツリーによる処理を通じて、サーバがクライアントアプリケーションにより表示される表示フィールドに入力された値に同期する。

（１）その後、（表示更新すべき表示フィールドがサーバにより表示されるＧＵＩ部品の場合、）第１のＧＵＩ部品群のうちの表示フィールドに対応するＵＩコンポーネントが、更新後の記憶手段から表示フィールドに表示すべきデータを取得して、当該取得したデータを表示するためのＨＴＭＬの表示エレメントを生成し、この表示エレメントを含むエレメント群と起動命令とを含むＨＴＴＰレスポンスを生成し、生成されたＨＴＴＰレスポンスをクライアント装置へ送信することにより、サーバにより表示される表示フィールド内の表示内容が、入力フィールドに入力された値に対応して更新される。

（２）また、（表示更新すべき表示フィールドがクライアントアプリケーションにより表示されるＧＵＩ部品の場合、）第１のＧＵＩ部品群のうちの表示フィールドに対応するＵＩコンポーネントが、更新後の記憶手段から表示フィールドに表示すべきデータを取得して、当該データと表示フィールドに対応する識別子とを含むＨＴＭＬのコメントエレメントを生成し、当該コメントエレメントを含むＨＴＴＰレスポンスを生成し、生成されたＨＴＴＰレスポンスをクライアント装置へ送信することにより、クライアントアプリケーションが、当該コメントエレメント内のデータを当該表示フィールドに表示する。この結果、クライアントアプリケーションにより表示される表示フィールド内の表示内容が、入力フィールドに入力された値に対応して更新される。

本発明によれば、ＨＴＴＰを用いて通信を行うクライアント（クライアントアプリケーション）とサーバ（Ｗｅｂアプリケーション）のそれぞれにより表示される複数のＧＵＩ部品を含むＷｅｂページ上への入力及びそれに対応する表示更新が容易に行える。

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

本実施形態にかかるＷｅｂサーバ、Ｗｅｂブラウザは、いずれも計算機上でソフトウェア（Ｗｅｂサーバプログラム、Ｗｅｂブラウザプログラム）を実行させることで実現することができる。この場合に、必要に応じてＯＳやドライバソフト、あるいは通信インターフェース装置、外部記憶装置、入出力装置といったハードウェアが搭載あるいは接続される。また、ユーザへの情報呈示／ユーザからの情報入力のために、グラフィカル・ユーザー・インターフェース（ＧＵＩ）を用いる必要がある。

本実施形態では、Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂシステムでの通信は、ＨＴＴＰプロトコルに従って行なわれる。ＨＴＴＰプロトコルに関してはＲＦＣ１９４５に示されているＨＴＴＰ１．０もしくはＲＦＣ２６１６に示されているＨＴＴＰ１．１を用いて説明する。

本実施形態では、図１に示すように、Ｗｅｂサーバ（簡単にサーバと呼ぶことがある）とＷｅｂクライアント（簡単にクライアントと呼ぶ）とが、ＬＡＮを介して接続され、クライアントからのリクエストがサーバに転送され、サーバは転送されたリクエストに対するレスポンスをクライアントに転送することで、ユーザへの情報の呈示・情報の入力が行なわれる場合について説明する。

また、サーバとクライアント（Ｗｅｂブラウザ）との間の通信プロトコルには、ＨＴＴＰプロトコルを用いる場合について説明する。

なお、図１では、クライアントとサーバとの間がＬＡＮで接続されている場合を示したが、バックボーンネットワークは、上記ＬＡＮである場合に限らず、インターネットやＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、公衆回線、ＰＨＳや携帯電話を用いた無線ネットワークなど、回線の種類を問わず適用可能である。

図１は、本実施形態に係るコンピュータ・ネットワークシステムの構成例を示したものである。図１において、Ｗｅｂサーバとしての計算機１（サーバ１）は、ＬＡＮ３を介してＷｅｂクライアントとしての計算機２（クライアント２）と接続する。計算機１は、Ｗｅｂアプリケーションプログラムを実行することにより、Ｗｅｂアプリケーション１１の機能を備えるＷｅｂサーバである。また、計算機２（クライアント２）は、Ｗｅｂブラウザプログラムを実行することにより、Ｗｅｂブラウザ（以下、簡単にブラウザと呼ぶ）１２の機能を備えるＷｅｂクライアントである。サーバ１は、クライアント２からのリクエストを受信すると、レスポンスを生成して返信する。

図１では、１つのサーバ１に対し、１つのクライアントが対応するが、勿論複数のサーバに対し複数のクライアントが対応する場合であっても適用可能である。この場合、各クライアントは、クッキー（Ｃｏｏｋｉｅ）などを用いたセッションによって識別され、サーバはセッション毎に、返送するレスポンスを動的に生成する。

（クライアントとサーバとの間の一般的な処理手順（１））
まず、図１に示す構成のクライアント・サーバシステムにおけるサーバ・クライアント間の通信の処理手順について説明する。

図２は、サーバ１のＷｅｂアプリケーション１１の機能構成例を示したものである。クライアント２のブラウザ１２上に、例えば図３に示すようなユーザインタフェースのＷｅｂページを表示するために、図３のＷｅｂページを構成するラベルや、テキスト入力フィールド、ボタンなどの複数のＧＵＩ部品のそれぞれ対応する複数のＵＩコンポーネントが階層的に接続されている。

図３に示すＷｅｂページに対応するＨＴＭＬテキストは、複数のエレメントからなる階層構造を有し、各エレメントはタグにより表されている。図２に示すような複数のＵＩコンポーネントからなる階層構造（これを「コンポーネントツリー」と呼ぶ）は、図３に示すＷｅｂページのＨＴＭＬテキストの階層構造と同一である。なお、図２は、ＵＩコンポーネントを組み合わせてユーザインタフェースを作成するためのJavaServer Faces（ＪＳＦ）に基づくものである。

図２において、サーバ１のＷｅｂアプリケーション１１は、複数のＵＩコンポーネント１０１ｂ〜１０１ｍを含む階層構造を有するＵＩコンポーネントツリー１０１ａを有する。また、サーバ１は、Ｗｅｂアプリケーション１１で、Ｗｅｂページを生成する際に用いる値を記憶するためのデータ保持部１０２を備えている。データ保持部１０２は、サーバ１が持つメモリに、Ｗｅｂページを生成する際に用いる値を記憶する。

ＵＩコンポーネント（HtmlForm）１０１ｃは、ＨＴＭＬのタグ＜ｆｏｒｍ＞を出力し、ＵＩコンポーネント（HtmlPanelGrid）１０１ｄ、１０１ｇ及び１０１ｋは、表示の整形を行なうＨＴＭＬのタグ＜ｔａｂｌｅ＞、＜ｔｒ＞、＜ｔｄ＞を出力し、ＵＩコンポーネント（HtmlOutputLabel）１０１ｅ、１０１ｈ及び１０１ｌは、タグのない通常の文字列を出力し、ＵＩコンポーネント（HtmlCommandLink）１０１ｆは、「＜ａ ｈｒｅｆ＝ｕｒｌ＞文字列＜／ａ＞」という文字列とそのリンク先を出力し、ＵＩコンポーネント（HtmlInputText）１０１ｉは、入力テキストフィールド「＜ｉｎｐｕｔ ｔｙｐｅ＝”ｔｅｘｔ”＞」を出力し、ＵＩコンポーネント（HtmlCommandButton）１０１ｊは、サブミットボタン「＜ｉｎｐｕｔ ｔｙｐｅ＝”ｓｕｂｍｉｔ”＞」を出力し、ＵＩコンポーネント（HtmlSelectManyListbox）１０１ｍは、複数個の要素を表示可能なリストボックス「＜ｓｅｌｅｃｔ＞要素＜／ｓｅｌｅｃｔ＞」を出力する。

ユーザインタフェース上の各ＧＵＩ部品には識別子が与えられ、当該ＧＵＩ部品を出力する当該ＧＵＩ部品に対応するＵＩコンポーネントは、当該ＧＵＩ部品と同一の識別子をもつ。

各ＵＩコンポーネントは、クライアント２から送信された、パラメータのないＧＥＴリクエストを受信すると、各ＵＩコンポーネントが再帰的に階層構造に従ってＨＴＭＬタグを出力することでＨＴＭＬレスポンスを生成し返信する。その際、必要に応じてＵＩコンポーネントはデータ保持部１０２から、当該データ保持部１０１で記憶されたデータを取得し、ＨＴＭＬタグを生成する。

図２ではHtmlSelectManyListbox１０１ｍが、データ保持部１０２から“2005/02/18”というデータを取得し、ｓｅｌｅｃｔタグを生成する。

ＪＳＦの場合、データ保持部１０２は、バッキングビーンと呼ばれる。このバッキングビーンと、そこに記憶されているデータを用いてＨＴＭＬのエレメントを生成するＵＩコンポーネントとの関連付けは、Ｗｅｂアプリケーションプログラムに記述されている。

図２は、Ｗｅｂのプレゼンテーション層に対応したコンポーネントツリーを示しているが、上記データ保持部１０２とコンポーネントの関連付けをはじめとしたＷｅｂアプリケーションのアプリケーション・ロジックやコンポーネントツリーの開発にはタグを用いるのが一般的である。

ＪＳＦを用いたＷｅｂアプリケーションプログラムも、ＪＳＰタグによって記述される。図２の各ＵＩコンポーネントに対応するタグクラスとＴＬＤ（Tag Library Description）によってＪＳＰタグが定義されている。Ｗｅｂアプリケーション１１は、各ＪＳＰタグに対応する各エレメントからなる所望の階層構造を有する。サーバ１が、Ｗｅｂアプリケーションプログラムを実行することにより、サーバ１上に、図２に示したようなＵＩコンポーネントツリー１０１ａが形成される。また、ＪＳＰタグのプロパティに、アプリケーション・ロジックを記述することで、上記バッキングビーンとＵＩコンポーネントの関連付けなどが行える。

図３は、図２にＵＩコンポーネントツリー１０１ａにより生成されたＨＴＭＬテキストを用いて、クライアント２のブラウザ１２により表示されるＷｅｂページの一例を示したものである。

クライアントのブラウザ１２は、例えば、「http://www.hello.co.jp/world.jsp」というＵＲＬに対してリクエストを出し、サーバ１のＷｅｂアプリケーション１１が、このリクエストを受けて、レスポンスを返信し、クライアント２のブラウザ１２がこのレスポンスを受信し、描画を行なって、図３に示すようなＷｅｂページ２０１が表示される。

図３において、「休暇申請」という文字列２０１ｅは、図２のHtmlOutputLabel１０１ｅによって生成された文字列である。「出張申請」という文字列２０１ｆは、図２のHtmlCommandLink１０１ｆによって生成されたリンク文字列である。「日付」という文字列２０１ｈは、図２のHtmlOutputLabel１０１ｈによって生成された文字列である。入力テキストボックス２０１ｉは、図２のHtmlInputText１０１ｉによって生成されたものである。「取得」と表示されているサブミットボタン２０１ｊは、図２のHtmlCommandButton１０１ｊで生成されたサブミットボタンである。「取得済み」という文字列２０１ｌは、図２のHtmlOutputLabel１０１ｌによって生成された文字列である。「２００５／０２／１８」が唯一の要素となっているリストボックス２０１ｍは、図２のHtmlSelectManyListbox１０１ｍによって生成されたリストボックスである。

図３のＷｅｂページの描画に利用されるＨＴＭＬテキストは、図２の各ＵＩコンポーネントが出力したＨＴＭＬタグによって構成されている。ただし、図２及び図３の例ではリストボックス２０１ｍに対応するHtmlSelectManyListbox１０１ｍのみが、対応するＪＳＰタグにバッキングビーンズを関連付けることでＨＴＭＬタグを動的に生成し、それ以外のＨＴＭＬタグは、Ｗｅｂアプリケーション１１を開発する際に、対応するＪＳＰタグに予め指定した静的な文字列から生成されたものである。

Ｗｅｂアプリケーション１１の処理は、次に示すような６つのフェーズに分類される。即ち、（１）ＵＩコンポーネントツリーの生成・復元（Restore Viewフェーズ）、（２）リクエスト値の適用（Apply Request Valuesフェーズ）、（３）入力値の検証（Process Validationsフェーズ）、（４）モデルの更新（Update Model Valuesフェーズ）、（５）アプリケーションロジックの呼び出し（Invoke Applicationフェーズ）、（６）レスポンスのレンダリング（Render Responseフェーズ）。

（１）Restore Viewフェーズは、ＪＳＰタグから図２に示したようなＵＩコンポーネントとＵＩコンポーネントツリーを生成・復元するフェーズである。（２）Apply Request Valuesフェーズは、クライアントからのリクエスト中のパラメータから、各ＵＩコンポーネントに対応する識別子をキーに、値を取得するフェーズである。（３）Process Validationsフェーズは、クライアント側で入力された入力値のチェックである。（４）Update Model Valuesフェーズは、（３）Process Validationsフェーズで検証した値をバッキングビーンズで保存させるフェーズである。（５）Invoke Applicationフェーズは、データベースの呼び出しや、各フェーズでキューされたイベントを実行するフェーズである。（６）Render Responseフェーズは、各ＵＩコンポーネントが、それぞれに対応するＨＴＭＬタグを生成し、レスポンスを返した後、ＵＩコンポーネントを保存するフェーズである。

上記６つのフェーズからなる処理フロー（ライフサイクル）を図６に示す。

ステップＳ１は上記（１）Restore Viewフェーズに対応し、ステップＳ３は上記（２）Apply Request Valuesフェーズに対応し、ステップＳ４は上記（３）Process Validationsフェーズに対応し、ステップＳ５は上記（４）Update Model Valuesフェーズに対応し、ステップＳ６は上記（５）Invoke Applicationフェーズに対応し、ステップ７は上記（６）Render Responseフェーズに対応する。

クライアント２のブラウザ１２からリクエスト（Hypertext transfer protocol (ＨＴＴＰ)のＧＥＴリクエスト、ポストリクエスト）を受け付けると、ステップＳ１の（１）Restore Viewフェーズが始まる。

ブラウザ１２から、例えば、「http://www.hello.co.jp/world.jsp」というＵＲＬで指定されたリソース（図３に示すようなＷｅｂページ）へのリクエスト（例えば、ＧＥＴリクエスト）を初めて受け取ると、ステップＳ１の（１）Restore Viewフェーズが始まり、コンポーネントツリー１０１ａが生成される。この後、ステップＳ２へ進む。この初めてのリクエストの場合、当該リクエストには、クライント側で入力された入力値や、ボタン押下により発生するイベントなど（リクエスト・パラメータ）が含まれていないため、ステップＳ２から、ステップＳ７の（６）Render Responseフェーズへ以降する。

ステップＳ７では、各ＵＩコンポーネントが、それぞれに対応するＨＴＭＬタグを生成し、図３に示すようなＷｅｂページに対応するＨＴＭＬテキストを生成する。そして、このＨＴＭＬテキストを含むレスポンスをクライアント２に返した後、各ＵＩコンポーネントを保存する。

ブラウザ１２は、サーバ１からの上記レスポンスを受けて、当該レスポンスに含まれるＨＴＭＬテキストを用いて、図３に示したようなＷｅｂページを表示する。

ブラウザ１２から、図３に示すようなＷｅｂページ上の入力テキストフィールド２０１ｉに、ユーザにより入力された入力値を含む（リクエスト・パラメータを含む）リクエスト（例えば、ＰＯＳＴリクエスト）を受け付けた場合、ステップＳ１の（１）Restore Viewフェーズでは、レスポンス時に保存してあったＵＩコンポーネントツリー１０１ａを復元し、ステップＳ２へ進む。ＰＯＳＴリクエストには、リクエスト・パラメータが含まれているので、ステップＳ２からステップＳ３へ進む。

この場合、受け取ったリクエストの「ｂｏｄｙ」エレメントには、入力テキストフィールド２０１ｉというＧＵＩ部品の識別子（当該ＧＵＩ部品に対応するＵＩコンポーネントの識別子）と、当該識別子に対応するＵＩコンポーネントに渡すべき入力値と、イベントとが含まれている。そこで、ステップＳ３では、当該リクエストに含まれている入力値やイベントを、当該入力値やイベントを受け取るべきＵＩコンポーネントが取得し、当該ＵＩコンポーネントは、この取得した入力値やイベントを一時保存する。その後、ステップＳ４の（３）Process Validationsフェーズへ移行する。

ステップＳ４では、ステップＳ３でＵＩコンポーネントに保持された（適用された）入力値のデータ型などを検証し、エラーが出なかった場合には、ステップＳ５へ進む。なお、エラーが出た場合には、その後の値の更新処理は行われない。

ステップＳ５の（４）Update Model Valuesフェーズでは、ＵＩコンポーネントで一時保持された値をデータ保持部１０２で記憶する。その後、ステップＳ６へ進む。

ステップＳ６の（５）Invoke Applicationフェーズは、例えば、ボタンの押下といったイベントに対してロジックを呼び出し、このロジックの結果によって、次の画面遷移先を決定する。その後、ステップＳ７へ進む。

ステップＳ７の（６）Render Responseフェーズは、各ＵＩコンポーネントが、次の画面を表示するためのＨＴＭＬタグを生成し、レスポンスをクライアント２へ返す。

なお、図６のステップＳ４の（３）Process Validationsフェーズの処理は本発明の要旨ではないので説明は省略する。ＪＳＦに関する詳細は、「JavaServer FacesによるWebアプリケーション開発」（川崎克己著、秀和システム、2004、ISBN-4798008303）に記載されている。

図４は、図２に示した機能を有するＷｅｂアプリケーション１１を備えたサーバ１と、ブラウザ１２を備えたクライアント２との間でＨＴＴＰを用いた通信を行い、クライアント２のブラウザ１２で、Ｗｅｂページを表示し、このＷｅｂページ上にユーザにより入力された値で、サーバ１のデータ保持部１０２を更新するための手順と、更新後のデータ保持部１０２に記憶された値で、表示の更新を行うための手順について説明する。

まず、クライアント２のブラウザ１２から、「http://www.hello.co.jp/world.jsp」というＵＲＬを指定した、パラメタなしのＧＥＴリクエストを送信する（ステップＰ１）。該リクエストを受信したサーバ１のＷｅｂアプリケーション１１は、図６のステップＳ１の（１）Restore Viewフェーズで、各ＵＩコンポーネントを生成または復元し、ステップＳ７の（６）Render Responseフェーズで、各ＵＩコンポーネントがＨＴＭＬタグを出力し、レスポンスを生成する。このとき、図２のHtmlSelectManyListbox１０１ｍは、データ保持部１０２から文字列「２００５／０２／１８」を取得し（ステップＰ２ａ）、リストボックスを動的に生成する（ステップＰ２）。

Ｗｅｂアプリケーション１１は、ステップＰ２で生成されたレスポンスをブラウザ１２に返信する（ステップＰ３）。ブラウザ１２は、レスポンスを受信し、画面を描画することで、図３に示したようなＷｅｂページを表示する。

図３に示したような表示状態のときに、クライアント２のユーザは、図３の入力テキストフィールド２０１ｉに文字列「２００５／０３／０４」を入力し、サブミットボタン２１ｊを押下すると、ブラウザ１２が「http://www.hello.co.jp/world.jsp」に対してＰＯＳＴリクエストを送信する（ステップＰ４）。このＰＯＳＴリクエストには、入力テキストフィールド２０１ｉに対応する識別子「ｔｆ１」をキーとし、入力値「２００５／０３／０４」を値（バリュー）とするリクエスト・パラメータ「ｔｆ１＝２００５／０３／０４」が含まれている。なお、ここで、入力テキストフィールド２０１ｉは、図２のHtmlInputText１０１ｉが出力するので、この入力テキストフィールド２０１ｉは、ＵＩコンポーネントのHtmlInputText１０１ｉの識別子「ｔｆ１」をもち、この識別子「ｔｆ１」が、リクエスト・パラメータのキーとして含まれている。

ステップＰ５において、ＰＯＳＴリクエストを受信したＷｅｂアプリケーション１１は、まず、図６のステップＳ１の（１）Restore Viewフェーズで、各ＵＩコンポーネントを復元し、ステップＳ２へ進む。当該ＰＯＳＴリクエストには、上記リクエスト・パラメータが含まれているため、ステップＳ３へ進む。ステップＳ３の（２）Apply Request Valuesフェーズでは、ＵＩコンポーネントのHtmlInputText１０１ｉが、上記リクエストパラメータから、識別子「ｔｆ１」をキーに、値「２００５／０３／０４」を取得し、ステップＳ４へ進む。ステップＳＳ４の処理は、本実施形態の要旨にかかる重要な処理ではないので、説明は省略する。次に、ステップＳ５へ進む。

ステップＳ５の（４）Update Model Valuesフェーズでは、HtmlInputText１０１ｉは、データ保持部１０２に、当該取得した値「２００５／０３／０４」を記憶し（ステップＰ６ａ）、ステップＳ６を経由して、ステップＳ７へ進む。ステップＳ７の（６）Render Responseフェーズでは、各ＵＩコンポーネントはＨＴＭＬタグエレメントを出力し、レスポンスを生成する。このとき、図２のHtmlSelectManyListbox１０１ｍは、データ保持部１０２から、既に記憶されていた文字列「２００５／０２／１８」、及びステップＳ５で記憶した文字列「２００５／０３／０４」を取得し（ステップＰ５ｂ）、リストボックスを動的に生成する。

Ｗｅｂアプリケーション１１は、ステップＰ５で生成されたレスポンスを、ブラウザ１２に返信する（ステップＰ６）。ブラウザ１２は、レスポンスを受信し、画面を描画することで図５に示したように、Ｗｅｂページが表示される。

図３に示したＷｅｂページのリストボックス２０１ｍには、文字列「２００５／０２／１８」の１つだけが表示されているが、図５のＷｅｂページのリストボックス２０１ｍには、２つの文字列「２００５／０２／１８」及び「２００５／０３／０４」が表示されている。

図４のステップＰ２で、図６のステップＳ１及びステップＳ７の（１）Restore Viewフェーズ及び（６）Render Responseフェーズが実行され、図４のステップＰ５で、図６のステップＳ１〜ステップＳ７の６つのフェースが実行される。

このように、図４のステップＰ４と、ステップＰ５の（１）Restore Viewフェーズ、（２）Apply Request Valuesフェーズ、（３）Process Validationsフェーズ、（４）Update Model Valuesフェーズの処理により、クライアント２のブラウザ１２で表示されているＷｅｂページ上への新たなデータの入力に対応して、サーバ１のデータ保持部１０２に記憶されているデータを更新する（サーバ１をクライアント２に同期させる）。

また、図４のステップＰ５の（６）Render Responseフェーズと、ステップＰ６の処理により、更新後のデータ保持部１０２で保持されているデータと、クライアント２のブラウザにより表示されたＷｅｂページ上のリストボックス２０１ｍの表示内容とを一致するように表示更新する（クライアント２をサーバ１に同期させる）。

（クライアントとサーバとの間の一般的な処理手順（２））
次に、サーバ１のＷｅｂアプリケーション１１により、ユーザ・インターフェース（Ｗｅｂページ）上の一部のＧＵＩ部品を表示し、残りのＧＵＩ部品をクライアントアプリケーションが表示する場合について説明する。

この場合のサーバ１の機能構成例を図７に示し、クライアント２のブラウザ１２上の表示例を図８に示す。また、クライアント２が、（例えばサーバ１から取得した）クライアントアプリケーションプログラムを実行することにより、クライアント２が備える機能、すなわち、クライアントアプリケーション３０１の機能構成例を図９に示す。

図７のＷｅｂアプリケーション１１の各機能は、図２と同様、サーバ１でＷｅｂアプリケーションプログラムを実行することにより実現され、図２と同様に、ＵＩコンポーネントツリー１０１ａを有する。なお、図７において、図２と同一部分には同一符号を付し、異なる部分について説明する。すなわち、図７では、図２のHtmlPanelGrid１０１ｇと、その子のＵＩコンポーネント１０１ｈ〜１０１ｊの代わりに、ブラウザ１２上のクライアントアプリケーション３０１の起動を命令するＨＴＭＬタグ（＜ｏｂｊｅｃｔ＞か＜ｅｍｂｅｄ＞など）を出力するＵＩコンポーネント「クライアントアプリケーション起動」１０１ｎが挿入されている。さらに、図７では、後述の図８のクライアントアプリケーション３０１と通信を行なう通信部１０３が新たに追加されている。

サーバ制御部１０６は、サーバ１全体の制御を司る。

クライアントアプリケーション記憶部１０５には、クライアント２へ渡すクライアントアプリケーションプログラムが記憶されている。

まず、Ｗｅｂアプリケーション１１の通信部１０３を用いて、サーバ１をクライアント２に同期させる場合について、図１０を参照して説明する。

クライアント２のユーザが、ブラウザ１２に、「http://www.hello.co.jp/world.jsp」というＵＲＬへのＧＥＴリクエストを送信させる（ステップＰ１１）。リクエストを受信したＷｅｂアプリケーション１１は、（１）Restore Viewフェーズ及び（６）Render Responseフェーズを実行し（ステップＰ１２）、レスポンスを返す（ステップＰ１３）。このレスポンスには、図７に示すように、クライアントアプリケーションを起動するためのＵＩコンポーネント１０１ｎにより生成されたクライアントアプリケーションの起動命令と、クライアントアプリケーションの保存場所を示す情報を有するＨＴＭＬテキストが含まれている。

このレスポンスを受信したブラウザ１２は、このＨＴＭＬテキストを解釈してユーザインターフェースを描画するとともに（ステップＰ１４）、クライアントアプリケーションの保存場所に対してＧＥＴリクエストを送信する（ステップＰ１５）。

クライアントアプリケーション記憶部１０５は、このＧＥＴリクエストを受けて、クライアントアプリケーションのアーカイブを読み出し、これをボディとするレスポンスを返信する（ステップＰ１６）。

レスポンスを受信したブラウザ１２により、クライアントアプリケーション３０１が起動される（ステップＰ１７）。このとき、クライアント１のブラウザ１２上に表示されるＷｅｂページには、図３と同様に、各ＧＵＩ部品が表示される。なお、図８において図３と同一部分には同一符号を付し、異なる部分についてのみ説明する。すなわち、図８では、ＧＵＩ部品２０１ｈ、２０１ｉ、２０１ｊを含む領域２０１ｚが、（図７のＵＩコンポーネント１０１ｎにより出力されたＨＴＭＬタグによって起動された）クライアントアプリケーション３０１により表示されている。

図９において、クライアントアプリケーション３０１は、図８の領域２０１ｚ及びＧＵＩ部品２０１ｈ〜２０１ｊのそれぞれに対応する複数のコンポーネント３０１ｚ、３０１ｈ〜３０１ｊからなるコンポーネントツリー３０１ａと、イベントハンドラ３０１と、通信部３０２を備えている。

コンポーネントツリー３０１ａは、コンポーネント（JApplet）３０１ｚを最上位のノードとし、その子ノードとして、コンポーネント（JLable）３０１ｈ、コンポーネント（JTextField）３０１ｉ、コンポーネント（JButton）３０１ｊが接続された階層構造を有する。クライアントアプリケーション３０１が起動されると、コンポーネントツリー３０１ａ上の各コンポーネント３０１ｚ、３０１ｈ〜３０１ｊが、それぞれ、ユーザインタフェース上の領域２０１ｚ及びＧＵＩ部品２０１ｈ〜２０１ｊとして表示される。

一般に、オブジェクト指向言語で開発されたアプリケーションは、コンポーネントツリー３０１ａのように、ＧＵＩ部品を階層化した構造になっている。

JApplet３０１ｚは、図８のＧＵＩ部品２０１ｈ〜２０１ｊを表示するための図８の領域２０１ｚに対応する。JLabel３０１ｈは、図８の「日付」という文字列のＧＵＩ部品２０１ｉに対応する。JTextField３０１ｉは、図８の入力テキストボックス２０１ｉに対応する。JButton３０１ｊは、図８の「取得」と表示されたサブミットボタン２０１ｊに対応する。

クライアントアプリケーション３０１は、クライアント２の通信部３０２を介して、サーバ１と通信を行う。イベントハンドラ３０３は、ここでは、サブミットボタン２０１ｊの押下により発生したイベントを処理する。

クライアント２のブラウザ１２上で、ユーザが、入力テキストボックス２０１ｉに、「２００５／０３／０４」と入力し、「取得」ボタン２０１ｊを押下すると、これを検知したJButton３０１ｊでイベント（ActionEvent）が発生する（ステップＰ１８）。そのリスナであるイベントハンドラ３０３が、JTextField３０１ｉから上記入力値を取得する。そして、通信部３０２から、ＨＴＴＰによる通信、ＲＭＩやＲＰＣなどといった分散オブジェク方式による通信、ソケットを介したＴＣＰ／ＩＰによる通信などの専用通信を用いて、サーバ１へ、クライアント２での入力値を送信する（ステップＰ１９）。

図７のサーバ１のＷｅｂアプリケーション１１が、通信部１０３を備える場合、クライント２から送信されてきた入力値は、この通信部１０３で受信される（ステップＰ２０）。そして、データ保持部１０２を受信した入力値で更新するためのメソッドを用いて、当該入力値をデータ保持部１０２に記憶する（ステップＰ２１）。

以上の処理により、サーバ１をクライアント２に同期させている。

なお、上記のようにしてサーバ１がクライアント２に同期した後、更新されたデータ保持部１０２の内容を、クライアント２のブラウザ１２上に反映させるためには、クライアント２から再度同一ＵＲＬにリクエストを送信し、図１０のステップＰ１１〜ステップＰ１７を行って、Ｗｅｂページのリロードすればよい。

なお、クライアントアプリケーション記憶部１０５は、必ずしもサーバ１が備えている必要はなく、サーバ１とは別個の装置上に設けられていてもよいし、クライアント１のローカルディスク装置に保存されていても良い。ただし、クライアントアプリケーションがＪａｖａアプレットの場合は、図７のように、サーバ１が当該クライアントアプリケーションを記憶し、サーバ１からクライアント２へダウンロードする必要がある。

次に、サーバ１が、図７に示すように、上記Ｗｅｂアプリケーション１１の他に、サーバ制御部１０６及びデータベース１０４を備え、上記通信部１０３ではなく、サーバ制御部１０６が、クライアント２の通信部３０２から送信された、図８のＷｅｂページ上に入力された入力値を受信する場合について、図１１を参照して説明する。

ユーザが、ブラウザ１２に「http://www.hello.co.jp/world.jsp」というＵＲＬへのＧＥＴリクエストを送信させる処理（ステップＰ１１）から、クライアントアプリケーション３０１が通信部３０２での専用通信を用いて、ユーザにより入力された入力値を送信する（ステップＰ１９）までは、図１０と同様であり、説明は省略する。

図１１では、専用通信を用いて、クライアント２から送信された入力値「２００５／０３／０４」は、サーバ制御部１０６により受信される（ステップＰ３１）。サーバ制御部１０６は、受信した入力値をデータベース１０４に記憶するための命令をデータベース１０４へ出力する（ステップＰ３２）。データベース１０４は、この命令を受け取ると、当該入力値を記憶する（ステップＰ３３）。

次に、クライアント２のユーザが、ブラウザ１２上のリロードボタンを押下するなどして、クライアント２のブラウザ１２から、サーバ１のＷｅｂアプリケーション１１に、ＧＥＴリクエストが送信される（ステップＰ３４）。リクエストを受信したＷｅｂアプリケーション１１は、上記６つのフェーズを実行し、そのうちの（５）Invoke Applicationフェーズの処理で、データベース１０４から、記憶された上記入力値を取得し、この入力値をデータ保持部１０２に記憶する（ステップＰ３５）。以上の処理により、サーバ１をクライアント２に同期させている。

なお、上記のようにして、サーバ１がクライアント２に同期した後、Ｗｅｂアプリケーション１１は、ステップＰ３５の上記６つのフェーズのうち、（６）Render Responseフェーズの処理によって、各ＵＩコンポーネントがＨＴＭＬタグを出力し、レスポンスを生成する。このとき、図７のHtmlSelectManyListbox１０１ｍは、データ保持部１０２から文字列「２００５／０３／０４」を取得し、リストボックスを動的に生成する（ステップＰ３５）。生成されたレスポンスは、Ｗｅｂブラウザ１２へ送信される（ステップＰ３６）。

このレスポンスを受信したブラウザは、上記ステップＰ１４〜ステップＰ１７を行うことにより、ブラウザ上の表示が更新される。すなわち、サーバ１で更新されたデータ保持部１０２の内容が、クライアント２のブラウザ上に反映され、クライアント２がサーバ１に同期することとなった。

以上説明したように、従来は、ユーザインタフェース上のクライアントアプリケーションにより生成されるＧＵＩ部品に、ユーザにより入力された入力値で、サーバ１のデータ保持部１０２で保持すべきデータを更新する（サーバ１をクライアント２に同期させる）場合、図１０では、サーバ１の通信部１０３で上記入力値を受け取り、データ保持部１０３を更新し、図１１では、サーバ制御部１０６で上記入力値を受け取ってデータベース１０４に一時記憶し、その後、クライアントから再びＧＥＴリクエストを受けてときに、このＧＥＴリクエストに対応するＪＳＦの６つのフェーズの処理を実行する過程で、データベース１０４に記憶された入力値でデータ保持部１０２を更新していた。

すなわち、従来は、クライアントアプリケーション３０１により表示されるＧＵＩ部品に、ユーザにより入力された入力値で、サーバ１のデータ保持部１０２を更新する（サーバ１をクライアント２に同期させる）場合、図７〜図１１に示したように、図６に示すようなＪＳＦで規定されている６つのフェーズを含む処理手順を介さずに、当該入力値をサーバ１へ送信し、サーバ１のデータ保持部１０２を更新していた。

サーバ１をクライアント２に同期させるためのＪＳＦで規定されている６つのフェーズを含む処理手順を行っていないということは、Ｗｅｂアプリケーション１１が関知していないところで、サーバ１のデータ保持部１０２で記憶されているデータが更新されている、ということである。

従って、図１０や図１１に示す手順では、Ｗｅｂアプリケーション１１が、サーバ１のデータ保持部１０２の更新を認識できずに、不具合を生ずる可能性があった。

本発明は、このような不具合をなくすために、Ｗｅｂアプリケーション１１が、ＪＳＦで規定されている６つのフェーズを含む処理手順を行って、サーバ１をクライアント２に同期させるためのデータ保持部１０２の更新を行う。

このために、サーバ１のＷｅｂアプリケーション１１のＵＩコンポーネントツリー１０１ａは、クライアント２のクライアントアプリケーション３０１のコンポーネントツリー３０１ａ上の各コンポーネント（各ＧＵＩ部品）に対応するＵＩコンポーネントを含む。

次に、本発明の実施形態について説明する。

（第１の実施形態）
図１２は、サーバ１の要部を示したもので、サーバ１でＷｅｂアプリケーションプログラムを実行することにより実現される、主に、Ｗｅｂアプリケーション１１の機能構成例を示したものである。

図１３は、クライアント２の要部の構成例を示したもので、主に、クライアント２が、サーバ１から送信されたクライアントアプリケーションプログラムを実行することにより実現される機能、すなわち、クライアントアプリケーション３０１の機能構成例を示したものである。

図１４は、サーバ１とクライアント２との間の処理手順を示したものである。

図１２に示したＷｅｂアプリケーション１１と、図７のＷｅｂアプリケーション１１との構成上の差異は、図７の「クライアントアプリケーション起動」というＵＩコンポーネント１０１ｎのかわりに、図１２ではクライアントアプリケーション３０１を構成するコンポーネントに対応するＵＩコンポーネント４０１ｚ、４０１ｈ〜４０１ｊがコンポーネントツリー３０１ａの階層構造と同一の階層構造でＵＩコンポーネントツリー１０１ａに挿入されている点である。なお、図１２において、図７と同一部分は同一符号を付している。

図１２のＵＩコンポーネント（UIJApplet）４０１ｚ、ＵＩコンポーネント（UIJLabel）４０１ｈ、ＵＩコンポーネント（UIJTextField）４０１ｉ、ＵＩコンポーネント（UIJButton）４０１ｊは、図１３のコンポーネント（JApplet）３０１ｚ、コンポーネント（JLabel）３０１ｈ、コンポーネント（JTextField）３０１ｉ、コンポーネント（JButton）３０１ｊに、それぞれ対応する。

図１３のクライアントアプリケーション３０１と、図９のクライアントアプリケーション３０１との構成上の差異は、図１３では、イベントハンドラ３０３の代わりに、イベント−ＨＴＴＰリクエスト変換部３０４及びＧＥＴリクエスト送信命令部３０５が追加されている点である。なお、図１３において、図９と同一部分は同一符号を付している。

コンポーネントツリー３０１ａは、図９と同様、コンポーネント（JApplet）３０１ｚを最上位のノードとし、その子ノードとして、コンポーネント（JLable）３０１ｈ、コンポーネント（JTextField）３０１ｉ、コンポーネント（JButton）３０１ｊが接続された階層構造を有する。クライアントアプリケーション３０１が起動されると、コンポーネントツリー３０１ａ上の各コンポーネント３０１ｚ、３０１ｈ〜３０１ｊが、それぞれ、図１５に示したように、ユーザインタフェース上の領域２０１ｚ及びＧＵＩ部品２０１ｈ〜２０１ｊとして表示される。

コンポーネントツリー３０１ａ上のコンポーネント３０１ｚ、３０１ｈ〜３０１ｊは、それぞれに対応する、ユーザインタフェース上の領域２０１ｚ及びＧＵＩ部品２０１ｈ〜２０１ｊの識別子はもつ。コンポーネントツリー３０１ａ上のコンポーネント３０１ｚ、３０１ｈ〜３０１ｊのそれぞれに対応するＷｅｂアプリケーション１１上のＵＩコンポーネント４０１ｚ、４０１ｈ〜４０１ｊも、それぞれに対応するユーザインタフェース上の領域２０１ｚ及びＧＵＩ部品２０１ｈ〜２０１ｊの識別子はもつ。

図１２のＵＩコンポーネント４０１ｚ、４０１ｈ〜４０１ｊの機能は、ほぼ他のＵＩコンポーネントと同様で、リクエスト・パラメータから、当該ＵＩコンポーネントの識別子に一致するキーと値とのペアを検索し、そのようなペアがみつかったら、当該値を取得し、（４）Update Model Valuesフェーズで、バッキングビーンズ（データ保持部１０２）にその値を保存し、（６）Render Responseフェーズで、ＨＴＭＬタグを出力するという機能である。なお、ここでは、上記リクエスト・パラメータから値を取得し、バッキングビーンズに保存するという値取得処理は、サーバ１のＷｅｂアプリケーション１１のＵＩコンポーネント（UIJTextField）４０１ｉのみが行い、それ以外のＧＵＩ部品に対応するＵＩコンポーネントは、当該処理を行わない。

第１の実施形態において、図１２のＵＩコンポーネント４０１ｚ、４０１ｈ〜４０１ｊが、他のＵＩコンポーネントと異なる点は、（６）Render Responseフェーズにおいて、上記ＵＩコンポーネントはＨＴＭＬタグを出力しない。あるいは出力したとしてもＨＴＭＬのコメントタグなどを出力し、ブラウザが解釈可能なタグは出力しない点である。

また、ＵＩコンポーネント（UIJApplet）４０１ｚは、図７の「クライアントアプリケーション起動」ＵＩコンポーネント１０１ｎと同様に、アプリケーション起動命令タグを（６）Render Responseフェーズで出力する。ここでは、ＵＩコンポーネント（UIJApplet）４０１ｚの子ＵＩコンポーネント４０１ｈ〜４０１ｊは、ＨＴＭＬのコメントタグ（＜！−− −−＞）を（６）Render Responseフェーズで出力するものとする。

上述の機能を持つＵＩコンポーネントは、ＪＳＦの標準ＵＩコンポーネントを継承し、必要に応じてメソッドをオーバーライドすることで実装することが可能である。

Sun Microsystems社がリリースしたＪＳＦ１．１のリファレンス実装では、ＵＩコンポーネント（UIJApplet）４０１ｚは、javax.faces.component.UIPanelクラスを承継し、ＵＩコンポーネント（UIJLabel）４０１ｈは、javax.faces.component.UIOutputクラスを承継し、ＵＩコンポーネント（UIJTextField）４０１ｉは、javax.faces.component.UIInputクラスを承継し、ＵＩコンポーネント（UIJButton）４０１ｊは、javax.faces.component.UICommandクラスを継承することで実装可能である。

上記ＪＳＦの標準ＵＩコンポーネントの上位クラスにあたるjavax.faces.component.UIComponentクラスで定義されるｄｅｃｏｄｅメソッドをオーバーライドすることで、当該ＵＩコンポーネントは、リクエスト・パラメータから当該ＵＩコンポーネントの識別子に対応する値を取得する。本実施形態では、該メソッドをオーバーライドするのは値取得処理を行うＵＩコンポーネント（UIJTextFeild）４０１ｉである。UIJTextField４０１ｉは、(２) Apply Request Valuesフェーズで、当該メソッドを実行することでリクエスト・パラメータから値を抽出する。

また、同じくjavax.faces.component.UIComponentクラスで定義されるencodeBegin，encodeChildren，encodeEndの各メソッドをオーバーライドすることで、各ＵＩコンポーネントは、所望のタグを出力する。該メソッド群は、（６）Render Responseフェーズで呼び出される。

ＵＩコンポーネントでencodeChildrenメソッドが実行されると、当該ＵＩコンポーネントの子コンポーネントのメソッド群を順番に呼び出す。これによって階層構造に従って再帰的にメソッド群が呼び出され、ＪＳＰタグでの階層構造に従ってＨＴＭＬタグが生成される。

本実施形態では、UIJApplet４０１ｚは、アプリケーション起動命令タグを出力し、その子コンポーネント４０１ｈ〜４０１ｊは、ＨＴＭＬのコメントタグを出力する。なお、各ＵＩコンポーネントの識別子は、各コンポーネントに対応するタグクラス及びＴＬＤファイルでプロパティ「ｉｄ」により定義され、ＪＳＦアプリケーションを開発する際に、各ＵＩコンポーネントに対応するＪＳＰタグの当該プロパティにユニークな識別子を指定することで、各ＵＩコンポーネントにユニークな識別子が設定される。

図１３のクライアントアプリケーション３０１に含まれるイベント−ＨＴＴＰリクエスト変換部３０４は、ユーザ操作によって発生したイベントを受けて、このイベントをＨＴＴＰリクエストに変換する。例えば、本実施形態の場合、コンポーネント（JButton）３０１ｊに対応するユーザインタフェース上のボタン２０１ｊの押下に伴い発生したActionEventをＨＴＴＰのリクエストに変換する。このＨＴＴＰのリクエストを通信部３０２を用いてＷｅｂアプリケーション１１へ送信する。

ここでは、イベント−ＨＴＴＰリクエスト変換部３０４は、リクエストヘッダーにセッションＩＤを示すＣｏｏｋｉｅが挿入された、ＰＯＳＴリクエストを生成する。該セッションＩＤはブラウザとＷｅｂアプリケーション１１とが確立したセッションのＩＤである。また、当該ＰＯＳＴリクエストのボディとして、コンポーネント（JTextField）３０１ｉに対応するＧＵＩ部品２０１ｉから取得した入力値「２００５／０３／０４」を値、当該コンポーネント（JTextField）３０１ｉに予め定義された識別子をキーとしたリクエスト・パラメータを生成する。ここで、JTextField３０１ｉ及びＷｅｂアプリケーション１１のUIJTextField４０１ｉの識別子を「ｔｆ１」とすると、リクエスト・パラメータは「ｔｆ１＝２００５／０３／０４」となる。

イベント−ＨＴＴＰリクエスト変換部３０４は、各コンポーネントから、当該コンポーネントの上記識別子を取得する。この識別子は、各コンポーネントのｎａｍｅ属性で指定されている。

ｎａｍｅ属性はＪａｖａのＵＩコンポーネントのすべての上位クラスとなるjava.awt.Componentクラスが実装している。そのためＪａｖａ標準のすべてのＧＵＩ部品で、ｎａｍｅ属性を利用することが可能である。ただし、自作ＧＵＩ部品で該クラスを継承しないものはｎａｍｅ属性あるいは当該ＧＵＩ部品をユニークに識別するための属性を実装する必要がある。なお、クライアントアプリケーション３０１の各コンポーネント３０１ｚ、３０１ｈ〜３０１ｊの識別子は、当該コンポーネントに対応する、Ｗｅｂアプリケーション１１のＵＩコンポーネント４０１ｚ、４０１ｈ〜４０１ｊの識別子、すなわち、「ｉｄ」プロパティの値と一致する。

本実施形態では、値として、文字列（Ｓｔｒｉｎｇオブジェクト）を用いているが、サーバ１及びクライアント２との間で同期を取りたい値が、Ｓｔｒｉｎｇオブジェクト以外の別のオブジェクトの場合は、直列化した上でＢａｓｅ６４によって文字列（Ｓｔｒｉｎｇオブジェクト）に変換し、リクエスト・パラメータとして利用できない文字「＝」及び「＋」をそれぞれ「＿」及び空白に変換することで同期対象とすることが可能である。この場合、リクエスト・パラメータから値を抽出するＵＩコンポーネントが該変換に対して逆の変換をすることで元のオブジェクトを取得する。また、直列化することができないオブジェクトは、イベント−ＨＴＴＰリクエスト変換部３０４とＵＩコンポーネントとの間で、予め定められた独自の文字列への変換及び逆変換ルールを実装することで値の同期が可能となる。

ＧＥＴリクエスト送信命令部３０５は、上述のイベント−ＨＴＴＰリクエスト変換部３０４で生成・送信されたＰＯＳＴリクエストに対するＷｅｂアプリケーション１１からのレスポンスを受信した際に、ブラウザ１２に対し、ＧＥＴリクエストをＷｅｂアプリケーション１１へ送信するように命令する機能を持つ。本実施形態のように、クライアントアプリケーション３０１がＪａｖａアプレットの場合、ＧＥＴリクエスト送信命令部３０５はApplet.showDocument(URL)を実行することなどに該当する。

次に、図１４を参照しながら、サーバ１をクライアント２に同期させ、クライアント２をサーバ１へ同期させる場合の処理手順について説明する。なお、図１４において、図１０と同一部分には同一符号を付している。

まず、サーバ１をクライアント２に同期させる上り方向の処理動作について説明する。

クライアント２のブラウザ１２から、「http://www.hello.co.jp/world.jsp」というＵＲＬへのＧＥＴリクエストが送信されてから、クライアント２で、クライアントアプリケーション３０１により、ブラウザ１２上に、図１５に示すようなユーザインタフェースを表示するまでの処理（ステップＰ１１〜ステップＰ１７）は、図１０と同様であり、説明は省略する。

ユーザが、図１５の入力テキストフィールド２０１ｉに、文字列「２００５／０３／０４」を入力し、取得ボタン２０１ｊ（コンポーネント（JButton）３０１ｊ）を押下すると（ステップＰ１８）、イベント（ActionEvent）が発生する。

ActionEventのリスナとして登録してあるイベント−ＨＴＴＰリクエスト変換部３０４が、コンポーネント（JTextField）３０１ｉから入力値「２００５／０３／０４」と、当該コンポーネントに予め定義された識別子「ｔｆ１」を取得し、この識別子をキーとしたリクエスト・パラメータ「ｔｆ１＝２００５／０３／０４」を生成する。そして、このリクエスト・パラメータを含む上述のＰＯＳＴリクエストを生成する（ステップＰ４１）。クライアントアプリケーション３０１は、通信部３０２を用いて、Ｗｅｂアプリケーション１１に、当該ＰＯＳＴリクエストを送信する（ステップＰ４２）。

サーバ１のＷｅｂアプリケーション１１では、当該ＰＯＳＴリクエストを受信すると、以下に示すような処理が行われる（ステップＰ４３）。すなわち、図６に示した一連の処理動作が行われる。

まず、当該リクエストに含まれるＣｏｏｋｉｅで指定されたセッションＩＤを有するＷｅｂアプリケーション１１の各ＵＩコンポーネントが、図６のステップＳ１の（１）Restore Viewフェーズで復元される。

図６のステップＳ２では、当該リクエストにリクエスト・パラメータが含まれていることから、ステップＳ３へ進む。

ステップＳ３の（２）Apply Request Valuesフェーズでは、当該リクエスト・パラメータに含まれている識別子と同一の識別子をもつＵＩコンポーネント（UIJTextField）４０１ｉが、当該リクエスト・パラメータから、値「２００５／０３／０４」を取得し、ステップＳ４へ進み、さらにステップＳ５へ進む。

ステップＳ５の（４）Update Model Valuesフェーズでは、UIJTextField４０１ｉは、データ保持部１０２に、当該取得した値「２００５／０３／０４」を記憶し、ステップＳ６を経由して、ステップＳ７へ進む。

以上の処理手順により、クライアント２のブラウザ上への新たなデータの入力に対応して、サーバ１のデータ保持部１０２で保持すべきデータが更新された。すなわち、サーバ１がクライアント２に同期した。

引き続き、図１４を参照して、クライアント２上のＷｅｂページの表示更新するための処理、すなわち、クライアント２をサーバ１に同期させるための処理手順について説明する。

ステップＳ７の（６）Render Responseフェーズでは、各ＵＩコンポーネントはＨＴＭＬタグエレメントを出力し、レスポンスを生成する。このとき、図１５のリストボックス２０１ｍを生成する、図１２のHtmlSelectManyListbox１０１ｍは、データ保持部１０２に既に登録済みの日付「２００５／０２／１８」と、上記ステップＳ５で新たに登録された日付「２００５／０３／０４」を取得して、それらを要素とするリストボックスを生成する。

ステップＰ４４では、Ｗｅｂアプリケーション１１で生成されたレスポンスがクライアント２へ返信される。

ところで、ステップＰ４２では、ブラウザ１２ではなく、クライアントアプリケーション３０１が通信部３０２を用いてＰＯＳＴリクエストを送信していた。従って、ステップＰ４４で送信されるレスポンスは、クライアント２の通信部３０２を介して、クライアントアプリケーション３０１により受け取られる。従って、この時点では、ブラウザ１２上の表示は更新されない。そして、レスポンスを受け取ったクライアントアプリケーション３０１のＧＥＴリクエスト送信命令部３０５は、ブラウザ１２に再度ＧＥＴリクエストを送信させるための命令、例えば、Applet.showDocument(http://www.hello.co.jp/world.jsp)をブラウザ１２へ出力する（ステップＰ４５）。

当該命令を受けたブラウザ１２は、当該命令で指定されたＵＲＬに、ＧＥＴリクエストを送信する（ステップＰ４６）。ＧＥＴリクエストを受信したＷｅｂアプリケーション１１では、上記ステップＰ４３と同様、図６に示した一連の処理動作が行われる（ステップＰ４７）。このとき、図６のステップＳ２では、当該リクエストにリクエスト・パラメータが含まれていないことから、ステップＳ７へ進む。ステップＳ７の（６）Render Responseフェーズでは、各ＵＩコンポーネントはＨＴＭＬタグエレメントを出力し、レスポンスを生成する。このとき、図１５のリストボックス２０１ｍを生成する、図１２のHtmlSelectManyListbox１０１ｍは、データ保持部１０２に既に登録済みの日付「２００５／０２／１８」と、上記ステップＳ５で新たに登録された日付「２００５／０３／０４」を取得して、それらを要素とするリストボックスを生成する。

ステップＰ４８では、Ｗｅｂアプリケーション１１で生成されたレスポンスがクライアント２へ返信される。なお、ステップＰ４６では、ブラウザ１２がＧＥＴリクエストを送信していたので、ステップＰ４８で送信されるレスポンスは、クライアント２のブラウザ１２により受け取られる。

この時点で、ブラウザ１２は、更新された日付を持つリストボックスを含むＷｅｂページを表示し、画面が更新される。その結果、クライアント２がサーバ１に同期した。

なお、ステップＰ４３で送信されたレスポンスには、クライアントアプリケーション起動命令タグが含まれているため、ブラウザ１２は、再度、クライアントアプリケーション記憶部１０５に対してＧＥＴリクエストを送信し（ステップＰ５０）、クライアントアプリケーションのアーカイブを取得し（ステップＰ５１）、クライアントアプリケーションを再起動する（ステップＰ５２）。この時点でブラウザ１２による表示は、完全に更新され、図１６に示す表示状態になる。

なお、第１の実施形態では、ＰＯＳＴリクエスト中のリクエスト・パラメータの書式として、「ｔｆ１＝２００５／０３／０４」としているが、この場合に限らず、変換ルールを定めることで、「ｔｆ１＝ｎ，“２００５／０３／０４の変換後の文字列“」とすることも可能である。これによって、入力フィールド２０１ｉに入力される値が文字列ではない場合でも対応可能となる。例えば、入力フィールド２０１ｉにリストやテーブルを用いることも可能となる。前者の場合Ｓｔｒｉｎｇの一次元配列を、後者の場合Ｓｔｒｉｎｇの二次元配列を変換すればよい。ただし、以後の実施形態では、説明の簡単のためにリクエストパラメータとして「ｔｆ１＝２００５／０３／０４」という書式を用いるものとする。

また、第１の本実施形態では、クライアントアプリケーションにより表示される各ＧＵＩ部品に対応するＷｅｂアプリケーション１１のＵＩコンポーネント群が、ＧＵＩ部品群の階層構造と同じ階層構造をもつ場合を示しているが、この第１の実施形態及び他の実施形態は、この場合に限らない。ＵＩコンポーネント群が、ＧＵＩ部品群の階層構造とは異なる階層構造を持っている場合も、階層構造をもたない場合も、第１の実施形態及び他の実施形態に適用可能である。

しかし、ＵＩコンポーネント群がＧＵＩ部品群と同じ階層構造をもつことで、Ｗｅｂアプリケーションとクライアントアプリケーションの開発時に、開発者に両者の構造を分かり易くするという効果がある。また、両者の階層構造を一致させることで、一方のアプリケーションを入力として他方のアプリケーションのテンプレートを機械的に生成するツールなどの開発が容易になる。ここでツールは、例えばアプレットプログラムが入力されると、アプレットプログラムを構成する各ＧＵＩ部品に対応するＪＳＰタグが同一の階層構造で配置されたＪＳＰページのテンプレートを生成する。もしくは、ＧＵＩ部品に対応するＪＳＰタグを階層的に配置したＪＳＰページを入力として、同一の階層構造をもつＧＵＩ部品から構成されるアプレットプログラムのテンプレートを生成する。このように、望ましくは、Ｗｅｂアプリケーションとクライアントアプリケーションとは同一の階層構造をもつことが望ましい。

（第２の実施形態）
図１７は、サーバ１の要部を示したもので、サーバ１でＷｅｂアプリケーションプログラムを実行することにより実現される、主に、Ｗｅｂアプリケーション１１の機能構成例を示したものである。

図１８は、クライアント２の要部の構成例を示したもので、主に、クライアント２が、取得したクライアントアプリケーションプログラムを起動することにより実現される機能、すなわち、クライアントアプリケーション３０１の機能構成例を示したものである。

図１９は、サーバ１とクライアント２との間の処理手順を示したものである。

図２０は、ユーザにより値が入力される前のユーザインタフェースの表示例を示し、図２１は、ユーザにより値が入力された後、サーバ１とクライアント２とが相互に同期したときの画面表示例である。なお、図１９及び図２０において、図１５、図１６と同一部分には同一符号を付している。

図１７に示したＷｅｂアプリケーション１１と、図１２に示したＷｅｂアプリケーション１１との差異は、図１２では、取得済みの休暇の日付を表示するためのＧＵＩ部品２０１ｌ、２０１ｍを、Ｗｅｂアプリケーションから送信されるレスポンスを用いてブラウザに表示するために、ＵＩコンポーネント（HtmlOutputLabel）１０１ｌとＵＩコンポーネント（HtmlSelectManyListbox）１０１ｍを用いているが、これらの代わりに、図１７では、ＧＵＩ部品２０１ｌ、２０１ｍをクライアント２のクライアントアプリケーション３０１で表示するために、ＵＩコンポーネント（UIJApplet）４０１ｚの子のＵＩコンポーネントの、ＵＩコンポーネント（UIJLabel）５０１ｌと、ＵＩコンポーネント（UIJList）５０１ｍが挿入されている点である。なお、図１７において、図１２と同一部分には同一符号を付している。

図１７のＷｅｂアプリケーション１１のＵＩコンポーネントツリー１０１ａのＵＩコンポーネント（UIJApplet）４０１ｚの子のＵＩコンポーネント４０１ｈ〜４０１ｊ、５０１ｌ、５０１ｍは、いずれも（６）Render Responseフェーズで、ＨＴＭＬのコメントタグ（＜！−− −−＞）などのＷｅｂブラウザが解釈しないタグエレメントを出力し、これらタグには、クライアント１側と同期を取りたいＧＵＩ部品（コンポーネント）の識別子と値とが挿入されている。すなわち、コメントタグであれば、例えば、＜！−− ｌｓｔ１＝２００５／０２／１８ −−＞を出力する。なお、第２の実施形態では、コメントタグを用いる場合を例にとり説明するが、この場合に限らず、ブラウザ１２が解釈しないタグであればどのようなタグを用いても良い。

ＵＩコンポーネント（UIJApplet）４０１ｚは、第１の実施形態と同様、（６）Render Responseフェーズで、クライアントアプリケーション起動命令タグを出力する。

図１８のクライアントアプリケーション３０１と、図１３のクライアントアプリケーション３０１との差異は、図１８のクライアントアプリケーション３０１には、取得済みの休暇の日付を表示するためのＧＵＩ部品２０１ｌ、２０１ｍに対応するコンポーネント（JLabel）６０１ｌとコンポーネント（JList）６０１ｍが、コンポーネントツリー３０１ａに新たに追加されている点である。また、図１８のクライアントアプリケーション３０１は、図１３のＧＥＴリクエスト送信命令部３０５の代わりに、レスポンス適用部３０６が追加されている。レスポンス適用部３０６は、Ｗｅｂアプリケーション１１からのレスポンスから、上述のコメントタグ内に記述されている値を取得し、ＧＵＩ部品に適用する機能を持つ。なお、図１８において、図１３と同一部分には同一符号を付している。

なお、ここで、上記第１の実施形態と同様、図１７のＵＩコンポーネント（UIJLabel）５０１ｌとＵＩコンポーネント（UIJList）５０１ｍは、図１８のコンポーネント（JLabel）６０１ｌとコンポーネント（JList）６０１ｍにそれぞれ対応する。そして、図１７のＵＩコンポーネント（UIJLabel）５０１ｌと、図１８のコンポーネント（JLabel）６０１ｌ（図２０及び図２１のＧＵＩ部品２０１ｌ）とは同じ識別子をもち、図１７のＵＩコンポーネント（UIJList）５０１ｍは、図１８のコンポーネント（JList）６０１ｍ（図２０及び図２１のＧＵＩ部品２０１ｍ）と同じ識別子をもつ。

このような構成において、図１８のイベント−ＨＴＴＰリクエスト変換部３０４が送信したＰＯＳＴリクエストを、図１７のＷｅｂアプリケーション１１が受けたとき、ＵＩコンポーネント（UIJList）５０１ｍは、図６の（６）Render Responseフェーズの処理で、リストボックスに表示すべき値をデータ保持部１０２から取得し、取得した値と当該ＵＩコンポーネント（UIJList）５０１ｍの識別子がコメントとして挿入されたコメントタグ（＜！−−UIJList５０１ｍの識別子＝取得した値−−＞）を出力する。このようなコメントタグ（コメントエレメント）を含むＨＴＭＬテキストが、当該ＰＯＳＴリクエストに対するレスポンスとして、クライアント２へ返送される。

このレスポンスは、図１８の通信部３０２で受信され、レスポンス適用部３０６へ渡される。レスポンス適用部３０６は、当該レスポンスに含まれる上記コメントタグから上記識別子と値を取得し、当該識別子に対応するコンポーネント（UIJList）６０１ｍ、すなわち、リストボックス２０１ｍに当該値をセットする。

次に、図１９を参照しながら、サーバ１をクライアント２に同期させる場合の処理手順及び、クライント２をサーバ１に同期させる場合の処理手順について説明する。なお、図１９において、図１０、図１４と同一部分には同一符号を付している。

図１９のステップＰ１１〜ステップＰ１８、ステップＰ４１〜ステップＰ４３までのサーバ１をクライアント２に同期させるまでの処理は、図１０、図１４と同一である。すなわち、ステップＰ１１〜ステップＰ１７までの処理により、ブラウザ１２上に、図２０に示すようなユーザインタフェースが表示される。なお、ここでは、過去に、入力テキストフィールド２０１ｉに、「２００５／０２／１８」が入力して、この値をリストボックス２０１ｍに表示するための（クライアント２とサーバ１とが互いに同期するための）、図１９に示す処理手順を既に実行した後の状態を示している。なお、ステップＰ１１〜ステップＰ１７までの処理により、図２０に示すようなユーザインタフェースを表示するための手法は、第３の実施形態で説明する。

ユーザが、図２０の入力テキストフィールド２０１ｉに、文字列「２００５／０３／０４」を新たに入力し、取得ボタン２０１ｊを押下すると、イベント（ActionEvent）が発生する。すると、イベント−ＨＴＴＰリクエスト変換部３０４が、入力テキストフィールド２０１ｉから入力値「２００５／０３／０４」と、当該ＧＵＩ部品に予め定義された識別子「ｔｆ１」を取得し、この識別子をキーとしたリクエスト・パラメータ「ｔｆ１＝２００５／０３／０４」を生成する。そして、このリクエスト・パラメータを含むＰＯＳＴリクエストを生成し、通信部３０２からサーバ１へ送信する（ステップＰ１８、ステップＰ４１、ステップＰ４２）。

サーバ１では、当該ＰＯＳＴリクエストを受信すると、図６に示した一連の処理動作を行い、当該リクエスト中のリクエスト・パラメータに含まれている識別子と同一の識別子をもつＵＩコンポーネント（UIJTextField）４０１ｉが、当該リクエスト・パラメータから、値「２００５／０３／０４」を取得し、この値をデータ保持部１０２に記憶する（ステップＰ４３）。

以上の処理手順により、クライアント２のブラウザ上への新たなデータの入力に対応して、サーバ１のデータ保持部１０２で保持すべきデータが更新された。すなわち、サーバ１がクライアント２に同期した。

次に、クライント２をサーバ１に同期させる場合の処理手順について説明する。

ステップＳ４３において、ＵＩコンポーネント（UIJTextField）４０１ｉが、当該リクエスト・パラメータに含まれていた値「２００５／０３／０４」をデータ保持部１０２に記憶すると、次に、ＵＩコンポーネント（UIJList）５０１ｍは、図６の（６）Render Responseフェーズで、データ保持部１０２から、リストボックスに表示すべき値を全て取得し、取得した値と当該ＵＩコンポーネント（UIJList）５０１ｍの識別子がコメントとして挿入されたコメントエレメント、例えば、＜！−−ｌｓｔ１＝２００５／０２／１８，２００５／０３／０４−−＞を生成する。このようなコメントエレメントを含むレスポンスが、クライアント２のクライアントアプリケーション３０１へ返信される（ステップＰ６１）。

上記レスポンスをクライアント２の通信３０２を介して受信したクライアントアプリケーション３０１は、そのレスポンスを、レスポンス適用部３０６に渡す（ステップＰ６２）。当該レスポンスを受け取ったレスポンス適用部３０６は、当該レスポンス中のコメントタグに、クライアントアプリケーション３０１中のＵＩコンポーネントのいずれかの識別子が含まれているときには、当該コメントタグから、当該識別子（ここでは、UIJList５０１ｍの識別子「ｌｓｔ１」）とともに書き込まれている値（ここでは、「２００５／０２／１８」、「２００５／０３／０４」）を取り出す（ステップＰ６３）。そして、この取り出された値を、当該識別子「ｌｓｔ１」に対応するＧＵＩ部品であるリストボックス２０１ｍにセットする（表示させる）。すなわち、「２００５／０２／１８」及び「２００５／０３／０４」が、リストボックス２０１ｍに表示される（ステップＰ６４）。このときのブラウザ上の表示例を図２１に示す。

以上の処理手順により、サーバ１で更新されたデータ保持部１０２の内容が、クライアント２のブラウザ上に反映され、クライアント２がサーバ１に同期することとなった。

（第３の実施形態）
第３の実施形態では、上記第２の実施形態のように、クライアントアプリケーション３０１が、データ保持部１０２に記憶された値を表示するＧＵＩ部品、例えば、上記第２の実施形態ではリストボックス２０１ｍ（コンポーネント（JList）６０１ｍ）を含む場合に、クライアントアプリケーション起動時に、当該ＧＵＩ部品に、Ｗｅｂアプリケーション１１からＰａｒａｍタグを用いて通知された、データ保持部１０２が持つ初期値を表示させる機能（Ｐａｒａｍタグ適用部３０７）について説明する。

ここでは、第２の実施形態に、この機能（Ｐａｒａｍタグ適用部３０７）を適用した場合を例にとり説明する。

サーバ１の構成は、第２の実施形態の図１７と同様である。また、Ｗｅｂアプリケーション１１では、クライアント２からリクエストを受けたときに、（６）Render Responseフェーズにおいて、ＵＩコンポーネント（UIJList）５０１ｍは、データ保持部１０２が保持する初期値を取得すると、当該初期値と、ＵＩコンポーネント（UIJList）５０１ｍの識別子を含む、ＪＳＰの（ＵＩコンポーネント（UIJApplet）４０１ｚが出力するクライアントアプリケーション起動命令タグの）パラメータタグエレメント（Ｐａｒａｍタグ）を生成する点が、第２の実施形態と異なる。

クライアント２の構成例を図２２に示す。なお、図１８と同一部分には同一符号を付している。図２２において図１８と異なる点は、図２２のクライアントアプリケーション３０１では、新たなに、Ｐａｒａｍタグ適用部３０７が追加されている。

Ｐａｒａｍタグ適用部３０７は、Ｗｅｂアプリケーション１１からのレスポンスに含まれるＰａｒａｍタグに含まれている値を抽出し、当該Ｐａｒａｍタグに含まれている識別子で特定されるＵＩコンポーネントに、当該抽出された値を適用する機能を有する。

次に、図２３を参照して、図１９のステップＰ１１〜ステップＰ１７の処理により、Ｗｅｂアプリケーション１１が保持する初期値を、クライアントアプリケーションに表示させるための処理手順を説明する。なお、ここでは、第３の実施形態に係る要部について説明し、それ以外は、図１９と同様である。

ステップＰ１１で、ブラウザ１２から送信されたＧＥＴリクエストを、Ｗｅｂアプリケーション１１が受信すると、ステップＰ１２において、Ｗｅｂアプリケーション１１のUIJList５０１ｍは、（６）Render Responseフェーズの処理で、データ保持部１０２から値を取得し、UIApplet４０１ｚが出力するクライアントアプリケーション起動命令のＰａｒａｍタグ<applet ….><Param name=lst1 value=2005/02/18></applet>を生成する。

このＰａｒａｍａタグをもつクライアントアプリケーション起動命令を含むレスポンスが、ブラウザ１２に返信される（ステップＰ１３）。

このレスポンスを受信したブラウザ１２は、このＨＴＭＬテキストを解釈してユーザインターフェースを描画するとともに（ステップＰ１４）、クライアントアプリケーションの保存場所に対してＧＥＴリクエストを送信する（ステップＰ１５）。

クライアントアプリケーション記憶部１０５は、このＧＥＴリクエストを受けて、クライアントアプリケーションのアーカイブを読み出し、これをボディとするレスポンスを返信する（ステップＰ１６）。

レスポンスを受信したブラウザ１２により、クライアントアプリケーション３０１が起動される（ステップＰ１７ａ）。

ブラウザ１２により起動されたクライアントアプリケーション３０１は、起動後に、Ｐａｒａｍタグで指定された値を取得する。例えば、Ｐａｒａｍタグ適用部３０７は、クライアントアプリケーションがアプレットの場合、Applet.getParameter()を用いて、Ｐａｒａｍタグ内の識別子と値を取得する。ブラウザ１２がクライアントアプリケーションプログラムを取得し、起動すると、Ｐａｒａｍタグ適用部３０７は、上記処理により識別子（ｌｓｔ１）で識別されるJList６０１ｍに値を出力し（ステップＰ１７ｂ）、描画を更新する。更新した結果、ブラウザ１２の表示状態は図２０に示したようになる。

第３の実施形態では、クライアントアプリケーション起動時の初期値の表示方法について説明している、勿論クライアントアプリケーションの再起動時にクライアントアプリケーションの表示を更新する場合にも適用可能である。

（第４の実施形態）
次に、第４の実施形態として、第３の実施形態で用いたＰａｒａｍタグと、第２の実施形態で用いたコメントタグとを用いて、クライアント２とサーバ１との間で相互に同期させるための手法について説明する。

サーバ１の構成は、第２の実施形態の図１７と同様である。また、Ｗｅｂアプリケーション１１では、クライアント２からＰＯＳＴリクエストを受けたときに、（６）Render Responseフェーズにおいて、ＵＩコンポーネント（UIJList）５０１ｍは、データ保持部１０２が保持する値を取得すると、当該値と、ＵＩコンポーネント（UIJList）５０１ｍの識別子を含む、コメントタグを生成する。さらに、Ｗｅｂアプリケーション１１では、クライアント２からＧＥＴリクエストを受けたときに、（６）Render Responseフェーズにおいて、ＵＩコンポーネント（UIJList）５０１ｍは、データ保持部１０２が保持する値を取得すると、当該値と、ＵＩコンポーネント（UIJList）５０１ｍの識別子を含む、ＵＩコンポーネント（UIJApplet）４０１ｚが出力するクライアントアプリケーション起動タグのＰａｒａｍタグを生成する。

クライアント２の構成例は図２２と同様である。

図２４は、サーバ１をクライアント２に同期させる場合の処理手順及び、クライント２をサーバ１に同期させる場合の処理手順について説明する。なお、図２４において、ステップＰ１１からステップＰ１７までの処理は、第３の実施形態の図２３と同様である。また、図２４のステップＰ１８以降は、第２の実施形態の図１９と同様である。すなわち、第３の実施形態で説明したように、ステップＰ１１からステップＰ１７までの処理により、図２０に示すような画面がブラウザ１２により表示される。

その後、ユーザが、図２０の入力テキストフィールド２０１ｉに、文字列「２００５／０３／０４」を新たに入力し、取得ボタン２０１ｊを押下すると、イベント（ActionEvent）が発生する。そして、イベント−ＨＴＴＰリクエスト変換部３０４が、コンポーネント（JTextField）３０１ｉから入力値「２００５／０３／０４」と、当該コンポーネントに予め定義された識別子「ｔｆ１」を取得し、この識別子をキーとしたリクエスト・パラメータ「ｔｆ１＝２００５／０３／０４」を生成する。そして、このリクエスト・パラメータを含むＰＯＳＴリクエストを生成し、通信部３０２からサーバ１へ送信する（ステップＰ１８、ステップＰ４１、ステップＰ４２）。以降の処理は、第２の実施形態の図１９と同様であり、ステップＰ６４では、図２１に示すように、表示内容が更新される。

（第５の実施形態）
第５の実施形態では、ユーザインタフェースに、クライアントアプリケーション３０１により表示されるテキストフィールドと、Ｗｅｂアプリケーション１１から送信されたＨＴＭＬのタグエレメントにより表示されるテキストフィールドとが存在する場合に、この２つのテキストフィールドのそれぞれに入力された２つの入力値で、サーバ１のデータ保持部１０２を更新し、更新後のデータ保持部１０２内の値で、ユーザインタフェースの表示を更新するための手法について説明する。

図２５は、第５の実施形態に係るサーバ１の有する機能の構成例を示したもので、主に、サーバ１でＷｅｂアプリケーションプログラムを実行することにより実現される機能（Ｗｅｂアプリケーション１１）の構成例を示している。なお、図２５において、図１２と同一部分には同一符号を付している。

図２６は、第５の実施形態に係るクライアント２の有する機能の構成例を示したもので、主に、クライアント２でクライアントアプリケーションプログラムを起動することにより実現される機能（クライアントアプリケーション３０１）の構成例を示している。なお、図２６において、図１３と同一部分には同一符号を付している。

図２８は、クライアント２のブラウザにより最初に表示される画面表示例を示している。また、図２９は、図２８の入力テキストフィールド２０１ｑ、２０１ｉに、削除する「取得済み」の日付、新たな日付をそれぞれ入力した後に、サーバ１とクライアント２との間で相互に同期がとれたときの画面表示例を示している。

図２８及び図２９において、文字列「削除日付」、テキストフィールドなどのＧＵＩ部品２０１ｐ、２０１ｑが新たに追加されている。これらＧＵＩ部品は、Ｗｅｂアプリケーション１１のＵＩコンポーネント（HtmlOutputLabel）６０１ｐと、ＵＩコンポーネント（HtmlInputText）６０１ｑによりそれぞれ生成されたものである。

文字列「登録日時」、テキストフィールド、「実行」ボタンといったＧＵＩ部品２０１ｈ〜２０１ｊが、クライアントアプリケーション３０１により表示される。

図２５のＷｅｂアプリケーション１１は、第１の実施形態と同様、ユーザインタフェース上の休暇の「取得済み」日付を表示するためのリストボックス２０１ｍを、ＵＩコンポーネント（HtmlSelectManyListbox）１０１ｍにより生成している。また、「取得済み」の日付を削除するための入力テキストフィールド２０１ｑを、ＵＩコンポーネント（HtmlInputText）６０１ｑにより生成している。

図２５でのＷｅｂアプリケーション１１では、フィルター部７０１が追加されている点で、第１の実施形態と大きく異なるが、Ｗｅｂアプリケーション１１のＵＩコンポーネント４０１ｚ、４０１ｈ〜４０１ｊは、第１の実施形態と同様、ブラウザ１２が解釈可能なＨＴＭＬタグは出力しない。

なお、ここでは、Ｗｅｂアプリケーション１１のうち、ＵＩコンポーネントツリー１０１ａにより、図６に示す処理を行う部分をＷｅｂアプリケーション１１の本体と呼ぶ。

Ｗｅｂアプリケーション１１のフィルター部７０１は、リクエスト受信部７０１ａ、リクエストパラメータ抽出部７０１ｂ、リクエスト応答部７０１ｃ、リクエストパラメータマージ部７０１ｄ、リクエスト種別判定部７０１ｅ、リクエスト転送部７０１ｆから構成される。

ここで、図３０に示すフローチャートを参照して、フィルター部７０１の処理動作について説明する。

フィルター部７０１のリクエスト受信部７０１ａは、クライアント２からのリクエストをＷｅｂアプリケーション１１の本体が受信する前に、当該リクエストをインターセプトする。

リクエスト受信部７０１ａが、クライアント２からのリクエストを受信する（ステップＴ１）と、まず、リクエスト種別判定部７０１ｅが、受信したＨＴＴＰリクエストの種別を判定する。まず、リクエストのメソッドを調べる（ステップＴ２）。メソッドがＧＥＴであればそのままＷｅｂアプリケーション１１の本体に転送する（ステップＴ１１）。メソッドがＰＯＳＴであれば、リクエスト・パラメータに予め定められたフラグパラメータ（例えばapplet=appletなど）が入っているか否かを調べる（ステップＴ３）。当該フラグパラメータが含まれている場合、当該リクエストは、「１番目のリクエスト」であると判定する。

次に、リクエストパラメタータ抽出部７０１ｂは、この１番目のリクエストから、フラグパラメータ以外のパラメータを抽出する（ステップＴ４）。そして、１番目のリクエストに含まれているセッションＩＤとともに、抽出されたパラメータを、リクエスト・パラメータ一時記憶部７０２に記憶する（ステップＴ５）。このとき、セッションＩＤを検索時のキーとなるように、抽出されたパラメータを、リクエスト・パラメータ一時記憶部７０２に記憶する。そして、リクエスト応答部７０１ｃが、１番目のフィルター処理が成功した旨のレスポンス（２００ ＯＫなど）をクライアント２へ返信する（ステップＴ６）。

その後、再び、クライアント２からのリクエストを受信すると、上記同様に処理を行う。このとき、ステップＴ３において、受信したＰＯＳＴリクエスト中にフラグパラメータが入っていない場合、ステップＴ７へ進み、当該ＰＯＳＴリクエスト中のセッションＩＤが、１番目のリクエストと判定されているリクエストのものと同一かどうかを判定する（ステップＴ７）。セッションＩＤが同一であれば、リクエスト種別判定部７０１ｅは、当該受信したＰＯＳＴリクエストは「２番目のリクエスト」であると判定する。

２番目のリクエストが得られると、次に、リクエストパラメータマージ部７０１ｄが、リクエストパラメータ一時記憶部７０２から、前回のステップＴ５で記憶した、１番目のリクエスト中のリクエスト・パラメータを取得する。そして、１番目と２番目のリクエスト中のリクエスト・パラメータをマージし、リクエストパラメータ一時記憶部７０２から、取得した１番目のリクエストのリクエスト・パラメータを削除する（ステップＴ８）。

その後、リクエスト転送部７０１ｆは、マージされたリクエスト・パラメータを含むＰＯＳＴリクエストを、Ｗｅｂアプリケーションの本体に転送する（ステップＴ９）。

なお、ステップＴ７で、今回受信したリクエスト中のセッションＩＤが、１番目のリクエストのセッションＩＤと異なる場合には、リクエスト応答部７０１ｃが、フィルター処理が失敗した旨のレスポンス（500 Internal Server Errorなど）をクライアントに返信する（ステップＴ１０）。

なお、フィルター部７０１は、ＪＳＦの場合、サーブレットフィルターを図３０に示した処理を行うように実装することで実現可能である。また、リクエストパラメータ一時記憶部７０２は、ＪＳＦの場合、HttpSessionオブジェクトに対応する。

図２６のクライアントアプリケーション３０１は、イベント−ＨＴＴＰリクエスト変換部３０４、サブミット命令部３０８及びエラー処理部３０９が含む。

サブミット命令部１３１４は、イベント−ＨＴＴＰリクエスト変換部３０４が、通信部３０２を介して送信したＰＯＳＴリクエストに対する１番目のフィルター処理が成功した旨のレスポンス（200 OKなど）を受信した際に、ブラウザ１２に、ＰＯＳＴリクエストを送信するように（サブミットするように）命令する。

クライアントアプリケーションがアプレットの場合、Javaメソッドを呼び出すことでJavaScriptを実行し、ブラウザ１２にサブミットさせることが可能である。

エラー処理部３０９は、イベント−ＨＴＴＰリクエスト変換部３０４が、通信部３０２を介して送信したＰＯＳＴリクエストに対するフィルター処理失敗のレスポンス（500 Internal Server Errorなど）を受信した際に、処理を終了してエラーが発生したことをユーザに通知する。通知するためにはポップアップでメッセージを出力しても良いし、クライアントアプリケーション３０１上にエラーメッセージを表示しても良い。

図２７は、サーバ１とクライアント２との間の処理手順を示したものである。なお、図２７において、図１４と同一部分には同一符号付している。

ユーザが、ブラウザ１２に、例えば、「http://www.hello.co.jp/world.jsp」というＵＲＬを入力し、該ＵＲＬに対するＧＥＴリクエストを送信すると（ステップＰ１０１）、フィルター部７０１が受信する（ステップＰ１０２）。

フィルター部７０１では、図３０に示すような処理動作を行う。すなわち、リクエスト受信部７０１ａが、当該ＧＥＴリクエストを受信すると（ステップＴ１）、リクエスト種別判定部７０１ｅは、当該リクエストのメソッドがＧＥＴであるため、ステップＴ１１へ進み、当該リクエストをＷｅｂアプリケーション１１の本体に転送する（ステップＰ１０３）。

その後、クライアントアプリケーション３０１を起動するまでのステップＰ１２からステップＰ１７までの処理は、図１０と同様であり、説明は省略する。

ステップＰ１７までの処理により、ブラウザ１２に、図２８に示すようなユーザインターフェースが表示されたとする。図２８では、取得済みの休暇の日付として、リストボックス２０１ｍに「２００５／０２／１８」が表示されている。

さて、ユーザが、図３４の入力テキストフィールド２０１ｉに追加したい日付文字列「２００５／０３／０４」を入力し、入力テキストフィールド２０１ｑに削除したい日付文字列「２００５／０２／１８」を入力した後、実行ボタン２０１ｊを押下するとActionEevntが発生する（ステップＰ１８）。

このとき、当該ActionEventをフックした、イベント−ＨＴＴＰリクエスト変換部３０４は、予め定められたフラグパラメータ（例えば、applet=applet）と、入力テキストフィールド２０１ｉの識別子及び値「tf1=2005/03/04」とを＆で繋いだ「applet=applet&tf1=2005/03/04」をリクエスト・パラメータとして含む、ＰＯＳＴリクエストを生成する（ステップＰ１０１）。そして、このＰＯＳＴリクエストを通信部３０２を介してＷｅｂアプリケーション１１へ送信する（ステップＰ１０２）。

当該リクエストは、まず、Ｗｅｂアプリケーション１１のフィルター部７０１により受信される。フィルター部７０１では、図３０に示すような処理動作を行う（ステップＰ１０３）。すなわち、リクエスト受信部７０１ａが、当該ＰＯＳＴリクエストを受信すると（ステップＴ１）、リクエスト種別判定部７０１ｅは、当該ＰＯＳＴリクエストのリクエスト・パラメータにフラグパラメータ（applet=applet）が入っていることから、「１番目のリクエスト」であると判定する（ステップＴ２〜ステップＴ３）。そして、リクエストパラメタータ抽出部７０１ｂは、この１番目のリクエストから、フラグパラメータ以外のパラメータを抽出する（ステップＴ４）。そして、１番目のリクエストに含まれているセッションＩＤとともに、抽出されたパラメータを、リクエスト・パラメータ一時記憶部７０２に記憶する（ステップＴ５）。リクエスト応答部７０１ｃが、１番目のフィルター処理が成功した旨のレスポンスをクライアント２へ返信する（ステップＴ６）。

このようにしてＷｅｂアプリケーション１１からレスポンスが送信されると（ステップｐ０４）、当該レスポンスは、クライント２のクラインとアプリケーション３０１は、通信部３０２介して受信される。

このレスポンスを受けて（ステップＰ１０５）、サブミット命令部３０８が、ブラウザ１２に対し、ＰＯＳＴリクエストを送信するように（サブミットするように）命令する（ステップＰ１０６）。

この命令を受けて、ブラウザ１２は、入力テキストフィールド２０１ｑの識別子「ｔｆ２」と、当該入力テキストフィールド２０１ｑに入力された値「２００５／０２／１８」とからなるリクエスト・パラメータ「ｔｆ２＝２００５／０２／１８」を、そのボディに含むＰＯＳＴリクエストを送信する（ステップＰ１０７）。

当該リクエストは、Ｗｅｂアプリケーション１１のフィルター部７０１により受信される。フィルター部７０１では、図３０に示すような処理動作を行う（ステップＰ１０８）。すなわち、リクエスト受信部７０１ａが、当該ＰＯＳＴリクエストを受信すると（ステップＴ１）、リクエスト種別判定部７０１ｅは、当該ＰＯＳＴリクエストのリクエスト・パラメータにフラグパラメータ（applet=applet）が存在せず（ステップＴ２〜ステップＴ３）、しかも、当該リクエスト中のセッションＩＤが、「１番目のリクエスト」のセッションＩＤと同一であることから、当該受信したＰＯＳＴリクエストは「２番目のリクエスト」であると判定する（ステップＴ７）。

２番目のリクエストが得られると、次に、リクエストパラメータマージ部７０１ｄが、リクエストパラメータ一時記憶部７０２から、１番目のリクエスト中のリクエスト・パラメータを取得する。そして、１番目と２番目のリクエスト中のリクエスト・パラメータをマージし（結合し）、リクエストパラメータ一時記憶部７０２から、取得した１番目のリクエストのリクエスト・パラメータを削除する（ステップＴ８）。その後、リクエスト転送部７０１ｆは、マージされたリクエスト・パラメータを含むＰＯＳＴリクエストを、Ｗｅｂアプリケーション１１本体に転送する（ステップＴ９）。

このようにして、２つのリクエストパラメータがマージされたＰＯＳＴリクエストが、Ｗｅｂアプリケーション１１の本体に転送されると（ステップＰ１０９）、当該リクエストを受信したＷｅｂアプリケーション１１は、図６の処理を行う（ステップＰ１１０）。

すなわち、（２）Apply Request Valuesフェーズで、図２５のUIJTextField４０１ｉが
マージされたリクエスト・パラメータ中の値「２００５／０３／０４」を取得し、図２５のHtmlInputText６０１ｑが、マージされたパラメータ中の値「２００５／０２／１８」を取得する。そして、（４）Update Model Valuesフェーズでは、データ保持部１０２に「２００５／０３／０４」が記憶され、「２００５／０２／１８」が削除される。

以上の処理により、サーバ１がクライント２に同期した。

次に、（６）Render Responseフェーズでは、各ＵＩコンポーネントはＨＴＭＬタグエレメントを出力し、レスポンスを生成する。このとき、更新後のデータ保持部１０２からは、「２００５／０２／１８」は存在しないため、図２８のリストボックス２０１ｍを生成する、図２５のHtmlSelectManyListbox１０１ｍは、更新後のデータ保持部１０２に記憶されている「２００５／０３／０４」を取得して、それらを要素とするリストボックスを生成する。

ステップＰ１１１では、Ｗｅｂアプリケーション１１で生成されたレスポンスがクライアント２へ返信される。

当該レスポンスはブラウザ１２で受信され、ブラウザ１２は、当該レスポンスを用いて、ユーザインタフェースを描画することで、表示が更新する（ステップＰ１１２）。すなわち、ユーザインタフェース上のリストボックス２０１ｍの表示が更新され、リストボックス２０１ｍには「２００５／０３／０４」が表示される。

さらに、ブラウザ１２は、当該レスポンスに含まれるクライアントアプリケーション起動命令により、ＧＥＴリクエストをクライアントアプリケーション記憶部１０５に送信し（ステップＰ１１３）、クライアントアプリケーションプログラムを取得する（ステップＰ１１４）。

そして、ブラウザ１２は、クライアントアプリケーション３０１を再起動して、ユーザインタフェース上のＧＵＩ部品２０１ｈ〜２０１ｊが表示される（ステップＰ１１５）このときの画面表示例を図２９に示す。

以上の処理により、サーバ１とクライアント２とが相互に同期した。

（第６の実施形態）
上記第５の実施形態では、ユーザインタフェースに、クライアントアプリケーション３０１により表示される入力フィールド２０１ｉと、Ｗｅｂアプリケーション１１により生成されるＨＴＭＬのタグエレメントにより表示される入力フィールド２０１ｑとが存在する場合に、この２つの入力フィールドのそれぞれに入力された２つの入力値で、サーバ１のデータ保持部１０２を更新し、更新後のデータ保持部１０２内の値で、ブラウザ１２上のユーザインタフェースの表示を更新するための手法を示した。

上記第５の実施形態では、特に、ユーザインターフェースのリストボックス２０１ｍは、Ｗｅｂアプリケーション１２により生成されるＨＴＭＬのタグエレメントにより表示される場合の手法を示した。

次に、第６の実施形態では、ユーザインターフェースのリストボックス２０１ｍは、クライントアプリケーション３０１により表示される場合について説明する。

図３１は、第６の実施形態に係るサーバ１の有する機能の構成例を示したもので、主に、サーバ１でＷｅｂアプリケーションプログラムを実行することにより実現される機能（Ｗｅｂアプリケーション１１）の構成例を示している。なお、図３１において、図１７、図２５と同一部分には同一符号を付している。

図３２は、第５の実施形態に係るクライアント２の有する機能の構成例を示したもので、主に、クライアント２でクライアントアプリケーションプログラムを起動することにより実現される機能（クライアントアプリケーション３０１）の構成例を示している。なお、図３２において、図１８、図２６と同一部分には同一符号を付している。

図３４は、クライアント２のブラウザにより最初に表示される画面表示例を示している。また、図３５は、図３４の入力テキストフィールド２０１ｑ、２０１ｉに、削除する「取得済み」の日付、新たな日付をそれぞれ入力した後に、サーバ１とクライアント２との間で相互に同期がとれたときの画面表示例を示している。

図３４及び図３５において、文字列「削除日付」、テキストフィールドなどのＧＵＩ部品２０１ｐ、２０１ｑは、Ｗｅｂアプリケーション１１のＵＩコンポーネント（HtmlOutputLabel）６０１ｐと、ＵＩコンポーネント（HtmlInputText）６０１ｑによりそれぞれ生成されたものである。

文字列「登録日時」、テキストフィールド、「実行」ボタン、文字列「取得済み」、リストボックス、といったＧＵＩ部品２０１ｈ〜２０１ｊ、２０１ｌ、２０１ｍは、クライアントアプリケーション３０１のコンポーネント３０１ｈ〜３０１ｊ、６０１ｌ、６０１ｍにそれぞれ対応する。

図３１のＷｅｂアプリケーション１１は、図２５のＷｅｂアプリケーションのＵＩコンポーネント（HtmlPanelGrid）１０１ｋ、ＵＩコンポーネント（HtmlOutputLabel）１０１ｌとＵＩコンポーネント（HtmlSelectManyListbox）１０１ｍの代わりに、クライアントアプリケーション３０１のコンポーネント６０１ｌ、６０１ｍに対応する、ＵＩコンポーネント（UIJLabel）５０１ｌとＵＩコンポーネント（UIJList）５０１ｍを備えている。

このような構成により、図３１のＷｅｂアプリケーション１１は、前述の第３の実施形態と同様、Ｐａｒａｍタグを用いて、クライアントアプリケーション３０１に、ユーザインタフェース上のＧＵＩ部品に表示すべき値を通知する。このために、Ｗｅｂアプリケーション１１がＧＥＴ／ＰＯＳＴリクエストを受信した際の（６）Render Responseフェーズにおいて、ＵＩコンポーネント（UIJList）５０１ｍが、データ保持部１０２が保持する値を取得し、当該値と、ＵＩコンポーネント（UIJList）５０１ｍの識別子を含む、Ｐａｒａｍタグを生成する。このＰａｒａｍタグは、第３の実施形態と同様、ＵＩコンポーネント（UIJApplet）４０１ｚが出力するクライアントアプリケーション起動タグに含まれている。

クライアントアプリケーション起動タグのＰａｒａｍタグは、例えば、次のような形式のものである。

<applet ...><Param name=lst1 value=2005/02/18></applet>
ここで、「ｌｓｔ１」は、ＵＩコンポーネント（UIJList）５０１ｍ及びクライアントアプリケーション３０１のコンポーネント（JList）６０１ｍの識別子である。また、値「２００５／０２／１８」は、（６）Render Responseフェーズで、データ保持部１０２に保存されていた値である。

図３２のクライアントアプリケーション３０１と、図２６のクラインとアプリケーション３０１とで異なる点は、図３２のクライアントアプリケーション３０１では、図２６のクライントアプリケーション３０１のコンポーネントツリー３０１ａに、文字列「取得済み」、リストボックス、といったＧＵＩ部品２０１ｌ、２０１ｍに対応するコンポーネント（JLabel）６０１ｌと、コンポーネント（JList）６０１ｍが追加されている。また、図３２のクライアントアプリケーション３０１には、第３の実施形態で説明した、Ｐａｒａｍタグ適用部３０７が追加されている。

Ｐａｒａｍタグ適用部３０７は、クライアントアプリケーション起動時に、コンポーネント（JList）６０１ｍに対応するリストボックス２０１ｍに、Ｗｅｂアプリケーション１１からＰａｒａｍタグを用いて通知された、データ保持部１０２が持つ値を表示させる。

図３３は、サーバ１とクライアント２との間の処理手順を示したものである。なお、図３３において、図２７と同一部分には同一符号付している。

図３３の、ステップＰ１０１で、ユーザが、ブラウザ１２に、例えば、「http://www.hello.co.jp/world.jsp」というＵＲＬを入力し、該ＵＲＬに対するＧＥＴリクエストを送信してから、ステップＰ１７で、クライアントアプリケーション３０１を起動するまでの処理は、図２７と同様であり、異なる点についてのみ説明する。すなわち、ステップＰ１２で、ＧＥＴリクエストを受信したＷｅｂアプリケーション１１のＵＩコンポーネント（UIJList）５０１ｍは、（６）Render Responseフェーズにおいて、データ保持部１０２に既に記憶されていた値「２００５／０２／１８」を上述のようにＰａｒａｍタグに挿入する。このＰａｒａｍタグを有するクライアントアプリケーション起動タグを含むレスポンスが、ブラウザ１２へ返信される（ステップＰ１３）。

さて、ステップＰ１７で、クライアントアプリケーション３０１が起動されると（ステップＰ１７ａ）、Ｐａｒａｍタグ適用部３０７は、ステップＰ１３でＷｅｂアプリケーション１１から送信されたレスポンス中のＰａｒａｍタグから、識別子と値を抽出し、当該識別子に対応するＵＩコンポーネント（JList）６０１ｍ、すなわち、リストボックス２０１ｍに、当該抽出された値を出力する（ステップＰ１７ｂ）。その結果、図３４に示すように、リストボックス２０１ｍには、値「２００５／０２／１８」が表示される。

続いて、第５の実施形態と同様、ユーザが、図３４の入力テキストフィールド２０１ｉに追加したい日付文字列「２００５／０３／０４」を入力し、入力テキストフィールド２０１ｑに削除したい日付文字列「２００５／０２／１８」を入力した後、実行ボタン２０１ｊを押下するとActionEevntが発生する（ステップＰ１８）。

その後のステップＰ１０１〜ステップＰ１０９までの処理は、第５の実施形態と同様であり、説明は省略する。

ステップＰ１０９で転送された、２つのリクエストパラメータがマージされたＰＯＳＴリクエストを受信すると、ステップＰ１１０において、Ｗｅｂアプリケーション１１は、図６の処理を行う。

すなわち、（２）Apply Request Valuesフェーズで、図２５のUIJTextField４０１ｉがマージされたリクエスト・パラメータ中の値「２００５／０３／０４」を取得し、図２５のHtmlInputText６０１ｑが、マージされたパラメータ中の値「２００５／０２／１８」を取得する。そして、（４）Update Model Valuesフェーズでは、データ保持部１０２に「２００５／０３／０４」が記憶され、「２００５／０２／１８」が削除されて、サーバ１がクライント２に同期した。

ここまでの処理は、第５の実施形態と同様である。第５の実施形態と異なるのは、（６）Render Responseフェーズの処理である。

第６の実施形態では、（６）Render Responseフェーズにおいて、UIJList５０１ｍは、更新後のデータ保持部１０２に既に記憶されていた値「２００５／０３／０４」を上述のようにＰａｒａｍタグに挿入する。このＰａｒａｍタグを有するクライアントアプリケーション起動タグを含むレスポンスが、ブラウザ１２へ返信される（ステップＰ１１１）。

当該レスポンスはブラウザ１２で受信され、さらに、ブラウザ１２は、当該レスポンスに含まれるクライアントアプリケーション起動命令により、クライアントアプリケーション記憶部１０５から、クライアントアプリケーションプログラムを取得する（ステップＰ１１３〜ステップＰ１１４）。

そして、ブラウザ１２は、上記ステップＰ１７と同様、クライアントアプリケーション３０１を再起動する（Ｐ１１５ａ）。すると、Ｐａｒａｍタグ適用部３０７は、ステップＰ１１４でＷｅｂアプリケーション１１から送信されたレスポンス中のＰａｒａｍタグから、識別子と値を抽出し、当該識別子に対応するＵＩコンポーネント（JList）６０１ｍ、すなわち、リストボックス２０１ｍに、当該抽出された値を出力する（ステップＰ１１５ｂ）。その結果、図３５に示すように、リストボックス２０１ｍには、値「２００５／０３／０４」が表示される。

以上の処理により、サーバ１とクライアント２が相互に同期した。

（第７の実施形態）
次に、クライアントアプリケーションの起動時に、クライアントアプリケーションにより表示される各ＧＵＩ部品の属性（フォント、背景色など）を変更するための手法について説明する。

ここでは、第１の実施形態で説明したＷｅｂアプリケーション及びクライアントアプリケーションの場合を例にとり、クライアントアプリケーションにより表示される各ＧＵＩ部品の属性（フォント、背景色など）を変更するための機能及び処理動作について説明する。

図３６は、Ｗｅｂアプリケーションの構成例を示したものである。なお、図３６において、第１の実施形態で説明した図１２のＷｅｂアプリケーションと同一部分には同一符号を付している。

図３７は、クライアントアプリケーションの構成例を示したものである。なお、図３７において、第１の実施形態で説明した図１３のクライアントアプリケーションと同一部分には同一符号を付している。

図３６及び図３７において、第１の実施形態と異なる点は、図３６及び図３７では、ＧＵＩ部品の属性を、当該ＧＵＩ部品に対応するタグに対応付けるための機能が追加されている。

ここでは、具体例としては、コンポーネント（JLabel）３０１ｈに対応するＧＵＩ部品の前景色「foreground」属性と、当該コンポーネントに対応するＵＩコンポーネント（UIJLabel）４０１ｈにより生成されるタグの属性「foreground」と定義する。

このために、ＵＩコンポーネント（UIJLabel）４０１ｈのタグクラスとＴＬＤ（Tag Library Description）ファイルに、「foreground」属性を定義することで、Ｗｅｂアプリケーションプログラムが記述されているＪＳＰファイル中のＵＩコンポーネント（UIJLabel）４０１ｈのタグの属性に、「foreground」を記述することが可能となる。

ＪＳＦの場合、バッキングビーンズを「bean1」とすると、そのプロパティ「fore （private java.awt.Color fore）」に対して、「foreground=”#{bean1.fore}”」という書式でバリューバインディングすればよい。ただし、ＪＳＦや後述のencodeBegin(), encodeEnd()メソッドで「fore」プロパティを取得できるようにするために、「bean1」に「fore」プロパティのゲッターメソッドを用意する必要がある。

ここでは、「fore」プロパティは定数値であり、セッターメソッドはあっても良いが不要である。また、バリューバインディングではなく、文字列で「public static定数（具体例として文字列“java.awt.Color.red”など）」を指定しても良い。

ＪＳＦの詳細は、「JavaServer FacesによるWebアプリケーション開発」（川崎克己著、秀和システム、2004、ISBN-4798008303）に記載されている。

なお、本実施形態では、「bean1」の「fore」プロパティが後述の属性データ保持部８０１に相当する。

図３６のＷｅｂアプリケーション１１において、図１２のＷｅｂアプリケーション１１と異なる点は、図３６では、クライアントアプリケーション３０１に対応する各ＵＩコンポーネント４０１ｚ、４０１ｈ〜４０１ｊに対し、属性Paramタグ生成部８０２ｚ、８０２ｈ〜８０２ｊが新たに追加され、さらに、属性データ保持部８０１も新たに追加されている点である。

各ＵＩコンポーネント４０１ｚ、４０１ｈ〜４０１ｊに対応する各属性Paramタグ生成部８０２ｚ、８０２ｈ〜８０２ｊは、ブラウザ１２からのリクエストを受けて実行される、（６）Render Responseフェーズにおいて、当該ＵＩコンポーネントの識別子と属性名、及び属性データ保持部８０１に保持されている属性の定数値を含むParamタグを生成する。

以下、各ＵＩコンポーネント４０１ｚ、４０１ｈ〜４０１ｊに対応する各属性Paramタグ生成部８０２ｚ、８０２ｈ〜８０２ｊを区別する必要がない場合には、属性Paramタグ生成部８０２と呼ぶ。

Paramタグは、ＵＩコンポーネントの識別子と属性とその定数値を表現できる書式であればどのようなものであっても良い。また、Paramタグ生成部８０２は、リクエスト元がブラウザ１２の場合に限らず、クライアントアプリケーションの場合でも、（６）Render Responseフェーズで、上記Paramタグを出力しても良い。この場合、クライアントアプリケーションもParamタグを含むレスポンスを受信するが、クライアントアプリケーションはParamタグを認識しないため誤動作は発生しない。

属性Paramタグ生成部８０２は、（６）Render Responseフェーズにおいて、encodeBegin()メソッドもしくはendcodeEnd()メソッドで、属性データ保持部８０１に記憶されている属性の定数値と、ＵＩコンポーネントの識別子を取得し、後述のようなParamタグを出力する。

以下の説明では、UIJLabel４０１ｈに対応するＧＵＩ部品２０１ｈの「foreground」属性を変更する場合を例にとり説明する。この場合、UIJLabel４０１ｈに対応する属性Paramタグ生成部８０２ｈが、「foreground」属性のParamタグを生成する。生成されるParamタグは、例えば、<Param name=l1 value=foreground,n, 文字列への変換後の定数値>である。ここで、ｎは、定数値を文字列に変換するためのルール番号を指定する。定数値を文字列に変換するためには、（ａ）定数値がStringオブジェクトなので変換の必要なし、（ｂ）定数値が直列化可能なため定数値を直列化した上でBase64によって文字列に変換する、（ｃ）文字列でpublic static定数を指定する（例えば、文字列“java.awt.Color.red“など）、（ｄ）独自の変換ルール、などのように複数の変換方式が考えられる。

そこで、変換方式と数値ｎを予め対応付けしておくことで、どのような変換を行なったかをクライアント側に通知する。クライアントアプリケーションは、上述のｎによって特定される変換ルールの逆変換を行なうことで元の定数値を取得可能となる。

図３７クライアントアプリケーション３０１において、図１３のＷｅｂアプリケーション３０１と異なる点は、図３７において、属性Paramタグ適用部３１０が新たに追加されている。

属性Paramタグ適用部３１０は、クライアントアプリケーション起動後に、上述のＰａｒａｍタグから属性とその定数値を取得し、必要に応じて定数値を復元し、当該Ｐａｒａｍタグ内の識別子に対応するＧＵＩ部品に、当該属性の定数値を適用する機能を有する。

図３８は、サーバ１とクライアント２との間の処理手順を示したものである。なお、図３８において、図１４と同一部分には同一符号を付し、異なる部分について説明する。

すなわち、図３８では、図１４のステップＰ１２、ステップＰ１７、ステップＰ４７、ステップＰ５２の処理動作が異なる。

図３８のステップＰ１２において、Ｗｅｂアプリケーション１１が、ＧＥＴリクエストを受信すると、（６）Render Responseフェーズにおいて、属性Ｐａｒａｍタグ生成部８０２ｈは、属性データ保持部８０１に保持されている定数値（java.awt.Color.redオブジェクト）を取得する（ステップＰ１２ｂ）。そして、（例えば「foreground」属性を赤色とする）Ｐａｒａｍタグをクライアントアプリケーション起動命令タグのサブタグとして生成する（ステップＰ１２ｃ）。ステップＰ１３では、当該Ｐａｒａｍタグを含むレスポンスをクライアントへ送信する。

当該Ｐａｒａｍタグを含むレスポンスを受信したブラウザ１２は、ステップＰ１５及びステップＰ１６を経て、ステップＰ１７において、クライアントアプリケーション３０１を起動する（ステップＰ１７ａ）。

ステップＰ１７において、クライアントアプリケーションが起動されると、属性Ｐａｒａｍタグ適用部３１０が、上記Ｐａｒａｍタグ内の識別子に対応するＧＵＩ部品２０１ｈの、当該Ｐａｒａｍタグにより指定された属性を、当該Ｐａｒａｍタグで指定された値（前景色を赤色）に設定する（ステップｐ７ｃ）。これにより、図１５のユーザインタフェース上のＧＵＩ部品２０１ｈ、すなわち、文字列「日付」の文字の色が赤色に更新される。

ステップＰ４７においても上記ステップＰ１２と同様である。すなわち、（６）Render Responseフェーズにおいて、属性Ｐａｒａｍタグ生成部８０２ｈは、属性データ保持部８０１に保持されている定数値（java.awt.Color.redオブジェクト）を取得する（ステップＰ４７ｂ）。そして、（例えば「foreground」属性を赤色とする）Ｐａｒａｍタグをクライアントアプリケーション起動タグのサブタグとして生成する（ステップＰ１２ｃ）。ステップＰ４８では、当該Ｐａｒａｍタグを含むレスポンスをクライアントへ送信する。

ステップＰ５２においても上記ステップＰ１７と同様である。すなわち、クライアントアプリケーションが起動されると、属性Ｐａｒａｍタグ適用部３１０が、上記Ｐａｒａｍタグ内の識別子に対応するＧＵＩ部品２０１ｈの、当該Ｐａｒａｍタグにより指定された属性を、当該Ｐａｒａｍタグで指定された値（前景色を赤色）に設定する（ステップＰ５２ｃ）。これにより、図１６のユーザインタフェース上のＧＵＩ部品２０１ｈ、すなわち、文字列「日付」の文字の色が赤色に更新される。

なお、属性Ｐａｒａｍタグ適用部３１０に、予めJLabel３０１ｈに対し、「foreground」属性のセッターメソッドsetForeground(java.awt.Color)を登録しておくことで、上記Ｐａｒａｍタグから抽出した「foreground」属性の属性値をＧＵＩ部品の上記セッターメソッド経由でJLabel３０１ｈに適用することで、ＧＵＩ部品２０１ｈ、すなわち、文字列「日付」の文字の色が赤色に更新することができる。

また、ＧＵＩ部品のBeanInfoが保持するＧＵＩ部品の属性と、そのセッターメソッドの組み合わせを機械的に抽出し、予め属性Ｐａｒａｍタグ適用部３１０に登録しておくことでも実現可能である。

以後の実施形態においても、クライアントアプリケーションの属性Ｐａｒａｍタグ適用部３１０が、上記のように、ＧＵＩ部品の属性と、そのセッターメソッドの組み合わせを登録をしておくことで、レスポンス内の属性値を用いて、ＧＵＩ部品の属性を変更することが可能である。

なお、上記説明は、第１の実施形態のＷｅｂアプリケーション及びクライアントアプリケーションの場合を例にとり説明したが、第２〜第６の実施形態のＷｅｂアプリケーション及びクライアントアプリケーションに対しても、上記同様にして、クライアントアプリケーションにより表示される各ＧＵＩ部品の属性（フォント、背景色など）を変更することができる。

すなわち、Ｗｅｂアプリケーション１１に、属性データ保持部８０１と、クライアントアプリケーション３０１の各ＧＵＩ部品に対応する各ＵＩコンポーネントに対し、属性Ｐａｒａｍタグ生成部８０２を追加する。また、クライアントアプリケーション３０１に、属性Ｐａｒａｍタグ適用部３１０を追加する。

さらに、Ｗｅｂアプリケーション１１の（６）Render Responseフェーズの処理で、属性Ｐａｒａｍタグ生成部８０２は、属性データ保持部８０１から、属性の定数値を取得して、ＧＵＩ部品の識別子と属性名と属性値を含むＰａｒａｍタグを生成し、当該Ｐａｒａｍタグを含むレスポンスをクライアントへ送信する。

ブラウザ１２は、クライアントアプリケーションを起動、もしくは再起動した後に、属性Ｐａｒａｍタグ適用部３１０が、当該Ｐａｒａｍタグ内の属性値を、対応するＧＵＩ部品に設定する。

このような機能及び処理動作により、前述の第２〜第６の実施形態のクライアントアプリケーションは、ＧＵＩ部品２０１ｈの文字の色を赤色に変更することができる。

（第８の実施形態）
クライアント１において、ユーザ操作により、Ｗｅｂアプリケーションへ送信した値を用いて、（５）Invoke Applicationフェーズで、ビジネスロジックを実行し、その結果に応じてクライアントアプリケーションにより表示されるＧＵＩ部品の属性（色、フォントなど）を変更するための手法について説明する。

図３９は、Ｗｅｂアプリケーションの構成例を示したものである。なお、図３９において、第１の実施形態で説明した図１２のＷｅｂアプリケーション、第７の実施形態で説明した図３６のＷｅｂアプリケーションと同一部分には同一符号を付している。

図４０は、クライアントアプリケーションの構成例を示したものである。なお、図４０において、第１の実施形態で説明した図１３のクライアントアプリケーション、第７の実施形態で説明した図３７のクライアントアプリケーションと同一部分には同一符号を付している。

第７の実施形態では、ＧＵＩ部品の属性値は、常に同じであったが、第８の実施形態では、属性値が変更可能になっている。

ＪＳＦの場合は、バリューバインディングされたプロパティを変更可能にするために、当該プロパティに対応するセッターメソッドをバッキングビーンズに用意する必要がある。以下、本実施形態では、クライアントアプリケーション３０１のＵＩコンポーネント（JLabel）３０１ｘの属性「text」と、それに対応するＷｅｂアプリケーション１１のＵＩコンポーネント（UIJLabel）４０１ｘの属性「text」とを例にとり説明する。

図３９のＷｅｂアプリケーション１１において、図３６のＷｅｂアプリケーション１１と異なる点は、図３９では、ＵＩコンポーネントツリー１０１ａに、ＵＩコンポーネント（UIJLabel）４０１ｈの他に、属性値の変動するＵＩコンポーネント（UIJLabel）４０１ｘが追加されている。これに伴い、ＵＩコンポーネント（UIJLabel）４０１ｘに対応する属性Ｐａｒａｍタグ生成部８０４ｘも追加されている。

また、クライアントから送信された値に応じて属性データ保持部８０１に記憶されている属性値を変更するビジネスロジック８０５が新たに追加されている。

以下、各ＵＩコンポーネント４０１ｚ、４０１ｈ〜４０１ｊ、４０１ｘに対応する各属性変数Ｐａｒａｍタグ生成部８０２ｚ、８０２ｈ〜８０２ｊ、８０２ｘを区別する必要がない場合には、属性変数Ｐａｒａｍタグ生成部８０２と呼ぶ。

属性データ保持部８０１に記憶されている属性値は、クライアント２から送信された値に応じて、（５）Invoke Applicationフェーズで実行されるビジネスロジック８０５によって変更される。

属性Ｐａｒａｍタグ生成部８０２は、ブラウザ１２からのリクエストを受けて実行される、（６）Render Responseフェーズにおいて、当該ＵＩコンポーネントの識別子と属性名、及び属性データ保持部８０２に記憶されている属性値を含むＰａｒａｍタグを生成する。

属性データ保持部８０２は、データ保持部１０２同様、バッキングビーンズのプロパティが相当し、バッキングビーンズのプロパティに変動値を定義した（ＧＵＩ部品に対応する）ＵＩコンポーネントの属性をバリューバインディングすることで、（６）Render Responseフェーズで、第７の実施形態と同じ形式のＰａｒａｍタグを出力する。

コンポーネント（JLabel）３０１ｈの属性「text」とそれに対応するＵＩコンポーネント（UIJLabel）４０１ｈの属性「text」を例にすると、バッキングビーンズ「bean2」に定義されたStringプロパティ「str」に対し、バリューバインディングは「text=”#{bean2.str}”」と表すことができる。なお、バッキングビーンズのプロパティは第７の実施形態のように、定数ではなく変数であるため、バッキングビーンズの該プロパティには、ゲッターメソッドに加えてセッターメソッドを用意する必要がある。

図４０のクライアントアプリケーション３０１において、図３７のクライアントアプリケーション３０１と異なる点は、図４０では、コンポーネントツリー３０１ａに、コンポーネント（JLabel）３０１ｈの他に、クライアント２のユーザへのメッセージを表示するための、属性値の変動するＵＩコンポーネント（JLabel（２））３０１ｘが追加されている。

属性Paramタグ適用部３１０は、クライアントアプリケーション起動後に、上述のＰａｒａｍタグから属性名とその値を取得し、当該Ｐａｒａｍタグ内の識別子に対応するＧＵＩ部品に、当該属性の値を適用する機能を有する。

図４１は、サーバ１とクライアント２との間の処理手順を示したものである。なお、図４１において、図３８と同一部分には同一符号を付し、主に異なる部分について説明する。

まず、図４１のステップＰ１２において、Ｗｅｂアプリケーション１１が、ＧＥＴリクエストを受信すると、（６）Render Responseフェーズにおいて、属性Ｐａｒａｍタグ生成部８０２ｘは、属性データ保持部８０１（bean2の「str」属性）から、属性値を取得する（ステップＰ１２ｂ）。「str」属性の初期値は文字列“ ”であるものとする。そして、取得した属性値、（ここでは、初期値の“ ”）を含むＰａｒａｍタグをクライアントアプリケーション起動タグのサブタグとして生成する（ステップＰ１２ｃ）。ステップＰ１３では、当該Ｐａｒａｍタグを含むレスポンスをクライアントへ送信する。

当該Ｐａｒａｍタグを含むレスポンスを受信したブラウザ１２は、ステップＰ１５及びステップＰ１６を経て、ステップＰ１７において、クライアントアプリケーション３０１を起動する（ステップＰ１７ａ）。

ステップＰ１７において、クライアントアプリケーションが起動されると、属性Ｐａｒａｍタグ適用部３１０が、上記Ｐａｒａｍタグ内の識別子に対応するＧＵＩ部品（ＵＩコンポーネント（JLabel（２））３０１ｘ）の、当該Ｐａｒａｍタグにより指定された属性を、当該Ｐａｒａｍタグで指定された値に設定する（ステップＰ７ｃ）。ここでは、属性値は“ ”であるから、表示される文字列はない。従って、図１５に示したようなユーザインタフェースが表示される。

続いて、ユーザが、図１５の入力テキストフィールド２０１ｉに、文字列「２００５／０３／０４」を入力し、取得ボタン２０１ｊを押下すると（ステップＰ１８）、ＵＩコンポーネント（JTextField）３０１ｉの識別子「ｔｆ１」と、入力値「２００５／０３／０４」とを示すリクエスト・パラメータ「ｔｆ１＝２００５／０３／０４」を含むＰＯＳＴリクエストが、Ｗｅｂアプリケーション１１へ送信される（ステップＰ４２）。

サーバ１のＷｅｂアプリケーション１１では、当該ＰＯＳＴリクエストを受信すると、以下に示すような処理が行われる（ステップＰ４３）。すなわち、図６に示した一連の処理動作が行われる。

このとき、（４）Update Model Valuesフェーズでは、UIJTextField４０１ｉは、データ保持部１０２に、当該ＰＯＳＴリクエスト中のリクエストパラメータ内の値「２００５／０３／０４」を記憶することで、クライアント２のブラウザ上への新たなデータの入力に対応して、サーバ１のデータ保持部１０２で保持すべきデータが更新された。すなわち、サーバ１がクライアント２に同期した（ステップＰ４３ａ）。なお、ステップＰ４３ａの処理は、第１の実施形態と同様である。

第８の実施形態では、次の（５）Invoke Applicationフェーズにおいて、ビジネスロジック８０５が実行される。

図４２は、ビジネスロジック８０５の処理動作を示すフローチャートである。ビジネスロジック８０５は、当該ＰＯＳＴリクエストの送信日時が予め定められた期限内であるときには、属性データ保持部８０１の属性値（bean2の「str」属性の値）を“ ”に変更し（ステップＴ０１、ステップＴ１０２）、当該送信日時が当該期限を越えているときには、属性データ保持部８０１の属性値（bean2の「str」属性の値）を“期限内に申請してください”に変更する（ステップＴ０１、ステップＴ１０３）。

ここでは、当該ＰＯＳＴリクエストの送信日時が当該期限を越えているとする。従って、ビジネスロジック８０５は、属性データ保持部８０１の属性値（bean2の「str」属性の値）を初期値“ ”から“期限内に申請してください”に更新する（ステップＰ４３ｂ）。

そして、（６）Render Responseフェーズにおいて、各ＵＩコンポーネントはＨＴＭＬタグエレメントを出力し、レスポンスを生成する。このとき、図１５のリストボックス２０１ｍを生成する、図３９のHtmlSelectManyListbox１０１ｍは、データ保持部１０２に既に登録済みの日付「２００５／０２／１８」と、データ保持部１０２の更新により新たに登録された日付「２００５／０３／０４」を取得して、それらを要素とするリストボックスを生成する。ステップＰ４４では、Ｗｅｂアプリケーション１１で生成されたレスポンスがクライアント２へ返信される。

当該レスポンスを受け取ったクライアントアプリケーション３０１のＧＥＴリクエスト送信命令部３０５は、ブラウザ１２に再度ＧＥＴリクエストを送信させる（ステップＰ４５、ステップＰ４６）。

当該ＧＥＴリクエストを受信したＷｅｂアプリケーション１１では、上記ステップＰ１２と同様、図６に示した一連の処理動作が行われる（ステップＰ４７）。このとき、（６）Render Responseフェーズにおいて、属性Ｐａｒａｍタグ生成部８０２ｘは、属性データ保持部８０１（bean2の「str」属性）から、更新された属性値を取得する（ステップＰ４７ｂ）。「str」属性の更新後の値は“期限内に申請してください”である。そして、取得した属性値を含むＰａｒａｍタグ（クライアントアプリケーション起動タグのサブタグ）を生成する（ステップＰ４７ｃ）。ステップＰ４８では、当該Ｐａｒａｍタグを含むレスポンスをクライアントへ送信する。

当該Ｐａｒａｍタグを含むレスポンスを受信したブラウザ１２は、ステップＰ５０及びステップＰ５１を経て、ステップＰ５２において、クライアントアプリケーション３０１を起動する（ステップＰ５２ａ）。

ステップＰ５２において、クライアントアプリケーションが起動されると、属性Ｐａｒａｍタグ適用部３１０が、上記Ｐａｒａｍタグ内の識別子に対応するＧＵＩ部品、すなわち、ＵＩコンポーネント（JLabel（２））３０１ｘの、当該Ｐａｒａｍタグにより指定された属性を、当該Ｐａｒａｍタグで指定された値に設定する（ステップＰ５２ｃ）。ここでは、JLabel（２）３０１ｘの属性値は、“期限内に申請してください”であるから、図４３に示すように、ユーザインタフェース上に、文字列２０１ｘ、すなわち、“期限内に申請してください”が表示される。なお、この文字列２０１ｘの文字の色は、クライアントアプリケーション３０１の開発時に予め指定しておいても良いし、第７の実施形態で説明した手法を用いて、文字の色を設定してもよい。

なお、上記説明は、第１の実施形態のＷｅｂアプリケーション及びクライアントアプリケーションの場合を例にとり説明したが、第５、第６の実施形態のＷｅｂアプリケーション及びクライアントアプリケーションに対しても、上記同様にして、クライアントアプリケーションにより表示される各ＧＵＩ部品の属性（表示する文字列、フォント、背景色など）を、クライアント２のユーザ操作に応じて変更することができる。

すなわち、Ｗｅｂアプリケーション１１に、属性データ保持部８０１と、ビジネスロジック８０５、クライアントアプリケーション３０１に対応する各ＵＩコンポーネントに対し、属性Ｐａｒａｍタグ生成部８０２を追加する。また、クライアントアプリケーション３０１に、属性Ｐａｒａｍタグ適用部３１０を追加する。

さらに、Ｗｅｂアプリケーション１１の（５）Invoke Applicationフェーズで、ビジネスロジック８０５を実行して、属性データ保持部８０１に記憶されている属性値を更新する。また、（６）Render Responseフェーズの処理で、属性Ｐａｒａｍタグ生成部８０２は、属性データ保持部８０１から、属性の値を取得して、ＵＩコンポーネントの識別子と属性名と属性値を含むＰａｒａｍタグを生成し、当該Ｐａｒａｍタグを含むレスポンスをクライアントへ送信する。

ブラウザ１２は、クライアントアプリケーションを起動、もしくは再起動した後に、属性Ｐａｒａｍタグ適用部３１０が、当該Ｐａｒａｍタグ内の属性値を、対応するＵＩコンポーネントに適用することで、クライアントアプリケーション３０１に属性の値を設定する。

（第９の実施形態）
前述の第８の実施形態では、主に第１の実施形態のＷｅｂアプリケーション及びクライアントアプリケーションの場合を例にとり、Ｐａｒａｍタグを用いて、ＧＵＩ部品の属性値を通知する場合を説明した。

次に、第２の実施形態のＷｅｂアプリケーション及びクライアントアプリケーションの場合を例にとり、コメントタグを用いて、ＧＵＩ部品の属性値（色、フォントなど）を通知する場合について説明する。

図４４は、Ｗｅｂアプリケーションの構成例を示したものである。なお、図４４において、第２の実施形態で説明した図１７のＷｅｂアプリケーション、第８の実施形態で説明した図３９のＷｅｂアプリケーションと同一部分には同一符号を付している。

図４５は、クライアントアプリケーションの構成例を示したものである。なお、図４５において、第２の実施形態で説明した図１８のクライアントアプリケーション、第８の実施形態で説明した図４０のクライアントアプリケーションと同一部分には同一符号を付している。

前述の第８の実施形態と同様、ＪＳＦの場合には、バリューバインディングされたプロパティを変更可能にするために、当該プロパティに対応するセッターメソッドをバッキングビーンズに用意する必要がある。

以下、本実施形態では、クライアントアプリケーション３０１のコンポーネント（JLabel（３））６０１ｙの属性「text」と、それに対応するＷｅｂアプリケーション１１のＵＩコンポーネント（UIJLabel（３））４０１ｙの属性「text」とを例にとり説明する。

図４４のＷｅｂアプリケーション１１において、図１７のＷｅｂアプリケーション１１と異なる点は、図４４では、ＵＩコンポーネントツリー１０１ａに、属性値の変動するＵＩコンポーネント（UIJLabel（３））４０１ｙが追加されている。また、図４４では、クライアントアプリケーション３０１に対応する各ＵＩコンポーネント４０１ｚ、４０１ｈ〜４０１ｊ、４０１ｌ、４０１ｍ、４０１ｙに対し、属性コメントタグ生成部８０６ｚ、８０６ｈ〜８０６ｊ、８０６ｍ、８０６ｙが新たに追加され、さらに、属性データ保持部８０１、ビジネスロジック８０５も新たに追加されている。

以下、各ＵＩコンポーネント４０１ｚ、４０１ｈ〜４０１ｊ、４０１ｌ、４０１ｍ、４０１ｙに対応する各属性コメントタグ生成部８０６ｚ、８０６ｈ〜８０６ｊ、８０６ｍ、８０６ｙを区別する必要がない場合には、属性コメントタグ生成部８０６と呼ぶ。

属性コメントタグ生成部８０６は、クライアントアプリケーション３０１からのリクエストを受けて実行される、（６）Render Responseフェーズにおいて、当該属性コメントタグ生成部８０６に対応するＵＩコンポーネントの識別子と属性名、及び属性データ保持部８０１に保持されている属性の定数値を含むコメントタグを生成する。

属性データ保持部８０１、ビジネスロジック８０５については、前述の第８の実施形態と同様である。

属性データ保持部８０１は、データ保持部８０１と同様に、バッキングビーンズのプロパティが相当し、バッキングビーンズのプロパティに変動値を定義したＧＵＩ部品に対応するＵＩコンポーネントの属性をバリューバインディングすることで、（６）Render Responseフェーズにおいて、当該ＧＵＩ部品の識別子と属性名、変換ルール番号、変換後の値をコメントタグに挿入して出力する。生成されるコメントタグは、例えば、＜！−−ｊｌ３＝ｔｅｘｔ，ｎ，変換後の文字列 −−＞である。

JLabel６０１ｙの属性「text」とそれに対応するUIJLabel４０１ｙの属性「text」を例にとすると、バッキングビーンズ「bean2」に定義されたStringプロパティ「str」に対し、バリューバインディングは、ｔｅｘｔ＝”＃｛ｂｅａｎ２．ｓｔｒ｝”と表される。なお、バッキングビーンズのプロパティは定数ではなく変数であるため、バッキングビーンズの該プロパティにはゲッターメソッドに加えてセッターメソッドを用意する必要がある。

図４５のクライアントアプリケーション３０１において、図１８のクライアントアプリケーション３０１と異なる点は、図４５において、コンポーネントツリー３０１ａには、属性値の変動するＵＩコンポーネント（JLabel（３））６０１ｙが追加されている。JLabel（３）６０１ｙは、Ｗｅｂアプリケーション１１のＵＩコンポーネント（UIJLabel）４０１ｙに対応する。また、属性コメントタグ適用部３１１が新たに追加されている。

属性コメントタグ適用部３１１は、クライアントアプリケーション起動後に、上述のコメントタグから属性とその値を取得し、当該コメントタグ内の識別子に対応するＧＵＩ部品に、当該属性の値を適用する機能を有する。すなわち、属性コメントタグ適用部３１１は、コメントタグにより指定されたＧＵＩ部品の指定された属性を、指定された値に更新する。その際、必要に応じてｎで指定された変換ルールの逆返変換を行なうことで属性の変更後の値を復元する。

図４６は、サーバ１とクライアント２との間の処理手順を示したものである。なお、図４６において、図１９と同一部分には同一符号を付し、主に異なる部分について説明する。

第２の実施形態と同様、ステップＰ１１〜ステップＰ１７までの処理により、ブラウザ１２上に、図２０に示すようなユーザインタフェースが表示される。

ユーザが、図２０の入力テキストフィールド２０１ｉに、文字列「２００５／０３／０４」を新たに入力し、取得ボタン２０１ｊを押下すると、ＵＩコンポーネント（JTextField）３０１ｉの識別子「ｔｆ１」と、入力された文字列「２００５／０３／０４」有するリクエスト・パラメータ「ｔｆ１＝２００５／０３／０４」を含むＰＯＳＴリクエストが、通信部３０２からサーバ１へ送信される（ステップＰ１８、ステップＰ４１、ステップＰ４２）。

サーバ１では、当該ＰＯＳＴリクエストを受信すると、図６に示した一連の処理動作を行う（ステップＰ４３）。すなわち、第２の実施形態と同様、（４）Update Model Valuesフェーズにおいて、当該リクエスト中のリクエスト・パラメータに含まれている識別子と同一の識別子をもつＵＩコンポーネント（UIJTextField）４０１ｉが、当該リクエスト・パラメータから、値「２００５／０３／０４」を取得し、この値をデータ保持部１０２に記憶する（ステップＰ４３ａ）。この結果、クライアント２のブラウザ上への新たなデータの入力に対応して、サーバ１のデータ保持部１０２で保持すべきデータが更新された。すなわち、サーバ１がクライアント２に同期した。

また、第９の実施形態では、次の（５）Invoke Applicationフェーズにおいて、ビジネスロジック８０５が実行される。

ビジネスロジック８０５は、例えば、第８の実施形態と同様、図４２に示したような処理動作を行う。ここでは、当該ＰＯＳＴリクエストの送信日時が当該期限を越えているとする。従って、ビジネスロジック８０５は、属性データ保持部８０１の属性値（「bean2」の「str」属性の値）を初期値“ ”から“期限内に申請してください”に更新する（ステップＰ４３ｃ）。

そして、（６）Render Responseフェーズにおいて、UIJLabel(3)４０１ｙの属性コメントタグ生成部８０６ｙが属性データ保持部１０２（「bean2」の「str」属性）から該更新された値 “期限内に申請してください” 取得して（ステップＰ４３ｄ）、該属性値を含むコメントタグ（属性コメントタグ）を生成する（ステップＰ４３ｅ）。

一方、（６）Render Responseフェーズでは、第２の実施形態と同様、各ＵＩコンポーネントはＨＴＭＬタグエレメントを出力する。このとき、図２０のリストボックス２０１ｍに対応するＵＩコンポーネント（UIJList）５０１ｍは、データ保持部１０２から、リストボックスに表示すべき値を全て取得し、取得した値と当該ＵＩコンポーネント（UIJList）５０１ｍの識別子がコメントとして挿入されたコメントタグ、例えば、＜！−ｌｓｔ１＝２００５／０２／１８，２００５／０３／０４−＞を生成する（ステップＰ４３ｅ）。

上記ステップＰ４３ｅで生成された属性コメントタグ、及びステップＰ４３ｄで生成されたコメントタグを含むレスポンスが、クライアント２へ返信される（ステップＰ６１）。

上記レスポンスをクライアント２の通信３０２を介して受信したクライアントアプリケーション３０１は、第２の実施形態と同様、そのレスポンスを、レスポンス適用部３０６に渡す（ステップＰ６２）。当該レスポンスを受け取ったレスポンス適用部３０６は、当該レスポンス中のコメントタグに、クライアントアプリケーション３０１中のＵＩコンポーネントのいずれかの識別子が含まれているときには、当該コメントタグから、当該識別子（ここでは、UIJList５０１ｍの識別子「ｌｓｔ１」）とともに書き込まれている値（ここでは、「２００５／０２／１８」、「２００５／０３／０４」）を取り出す（ステップＰ６３）。そして、この取り出された値を、当該識別子「ｌｓｔ１」に対応するＧＵＩ部品であるリストボックス２０１ｍにセットする（表示させる）。すなわち、「２００５／０２／１８」及び「２００５／０３／０４」が、リストボックス２０１ｍに表示される（ステップＰ６４）。

以上の処理手順により、サーバ１で更新されたデータ保持部１０２の内容が、クライアント２のブラウザ上に反映され、クライアント２がサーバ１に同期することとなった。

第９の実施形態では、さらに、上記レスポンスを受信したクライアントアプリケーション３０１の属性コメントタグ適用部３１１が、当該レスポンスから属性コメントタグを抽出する（ステップＰ６５）。そして、属性コメントタグ内の属性値を必要に応じて復元し（ステップＰ６６）、当該属性コメントタグ内の識別子に対応するＧＵＩ部品の属性値を更新する（ステップＰ６７）。ここでは、ＵＩコンポーネントJLabel(3)６０１ｙに対応するＧＵＩ部品２０１ｙの属性値が更新される。すなわち、図２０のように、ＧＵＩ部品２０１ｙが表示されていない状態から、図４７に示すように、“期限内に申請してください”という文字列のＧＵＩ部品２０１ｙが表示される。

なお、上記説明は、第２の実施形態のＷｅｂアプリケーション及びクライアントアプリケーションの場合を例にとり説明したが、第４の実施形態のＷｅｂアプリケーション及びクライアントアプリケーションに対しても、上記同様にして、クライアントアプリケーションにより表示される各ＧＵＩ部品の属性（表示する文字列、フォント、背景色など）を、クライアント２のユーザ操作に応じて変更することができる。

すなわち、Ｗｅｂアプリケーション１１に、属性データ保持部８０１と、ビジネスロジック８０５、クライアントアプリケーション３０１に対応する各ＵＩコンポーネントに対し、属性コメントタグ生成部８０６を追加する。また、クライアントアプリケーション３０１に、属性コメントタグ適用部３１１を追加する。

さらに、Ｗｅｂアプリケーション１１の（５）Invoke Applicationフェーズで、ビジネスロジック８０５を実行して、属性データ保持部８０１に記憶されている属性値を更新する。また、（６）Render Responseフェーズの処理で、属性コメントタグ生成部８０６は、属性データ保持部８０１から、属性の値を取得して、ＵＩコンポーネントの識別子と属性名と属性値を含むコメントタグを生成し、当該コメントタグを含むレスポンスをクライアントへ送信する。

クライアントアプリケーション３０１は、当該レスポンスを受信すると、属性コメントタグ適用部３１０が、当該コメントタグ内の属性値を、対応するＧＵＩ部品に適用する。

上記第１乃至第９の実施形態では、クライアントアプリケーションにより、ユーザインタフェース上に１つの入力インタフェースが表示される場合について説明したが、この場合に限らず、クライアントアプリケーションにより、ユーザインタフェース上に複数の入力インタフェースが表示される場合でも適用可能である。

また、上記第７乃至第９の実施形態では、１つのＧＵＩ部品に対し、その属性を変更する場合を例にとり説明したが、同時に複数のＧＵＩ部品の属性を変更することも、全く同様にして行うことができる。

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

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

第１乃至第９の実施形態にかかるシステムの構成例を示した図。 Ｗｅｂアプリケーションの機能構成例を示した図。 ブラウザの表示例を示した図。 サーバ・クライアント間の処理手順を説明するための図。 ブラウザの表示例を示した図。 ＷｅｂアプリケーションのＵＩコンポーネント群の処理動作を説明するためのフローチャート。 Ｗｅｂアプリケーションの他の機能構成例を示した図。 ブラウザの表示例を示した図。 クライアントアプリケーションの機能構成例を示した図。 図７及び図９に対応するサーバ・クライアント間の処理手順を説明するための図。 図７及び図９に対応するサーバ・クライアント間の他の処理手順を説明するための図。 第１の実施形態にかかるＷｅｂアプリケーションの機能構成例を示した図。 第１の実施形態にかかるクライアントアプリケーションの機能構成例を示した図。 第１の実施形態にかかるサーバ・クライアント間の処理手順を説明するための図。 ユーザインタフェースの画面表示例を示した図。 ユーザインタフェースの更新後の画面表示例を示した図。 第２の実施形態にかかるＷｅｂアプリケーションの機能構成例を示した図。 第２の実施形態にかかるクライアントアプリケーションの機能構成例を示した図。 第２の実施形態にかかるサーバ・クライアント間の処理手順を説明するための図。 ユーザインタフェースの画面表示例を示した図。 ユーザインタフェースの更新後の画面表示例を示した図。 第３の実施形態にかかるクライアントアプリケーションの機能構成例を示した図。 第３の実施形態にかかるサーバ・クライアント間の処理手順を説明するための図。 第４の実施形態にかかるサーバ・クライアント間の処理手順を説明するための図。 第５の実施形態にかかるＷｅｂアプリケーションの機能構成例を示した図。 第５の実施形態にかかるクライアントアプリケーションの機能構成例を示した図。 第５の実施形態にかかるサーバ・クライアント間の処理手順を説明するための図。 ユーザインタフェースの画面表示例を示した図。 ユーザインタフェースの更新後の画面表示例を示した図。 フィルター部の処理動作を説明するためのフローチャート。 第６の実施形態にかかるＷｅｂアプリケーションの機能構成例を示した図。 第６の実施形態にかかるクライアントアプリケーションの機能構成例を示した図。 第６の実施形態にかかるサーバ・クライアント間の処理手順を説明するための図。 ユーザインタフェースの画面表示例を示した図。 ユーザインタフェースの更新後の画面表示例を示した図。 第７の実施形態にかかるＷｅｂアプリケーションの機能構成例を示した図。 第７の実施形態にかかるクライアントアプリケーションの機能構成例を示した図。 第７の実施形態にかかるサーバ・クライアント間の処理手順を説明するための図。 第８の実施形態にかかるＷｅｂアプリケーションの機能構成例を示した図。 第８の実施形態にかかるクライアントアプリケーションの機能構成例を示した図。 第８の実施形態にかかるサーバ・クライアント間の処理手順を説明するための図。 ビジネスロジックの処理動作を説明するためのフローチャート。 ユーザインタフェースの更新後の画面表示例を示した図。 第９の実施形態にかかるＷｅｂアプリケーションの機能構成例を示した図。 第９の実施形態にかかるクライアントアプリケーションの機能構成例を示した図。 第９の実施形態にかかるサーバ・クライアント間の処理手順を説明するための図。 ユーザインタフェースの更新後の画面表示例を示した図。

符号の説明

１…サーバ
２…クライアント
３…ＬＡＮ
１１…Ｗｅｂアプリケーション
１２…ブラウザ

Claims (23)

1. ブラウザを備えるクライアント装置と、
   前記クライアント装置の前記ブラウザで表示する第１のＧＵＩ部品群に対応するＨＴＭＬ（hyper text markup language）のエレメント群を生成するための第１のＵＩコンポーネント群と、前記クライアント装置で起動されるクライアントアプリケーションにより表示される第２のＧＵＩ部品群に対応する第２のＵＩコンポーネント群と、前記第１及び第２のＧＵＩ部品群のうち表示フィールドに表示すべきデータを記憶する記憶手段と、を備えたＷｅｂアプリケーションを備えるサーバ装置とがＨＴＴＰ（hyperText transfer protocol）を用いて通信を行う通信システムにおける通信方法において、
   前記Ｗｅｂアプリケーションが、前記ブラウザからの第１のＨＴＴＰリクエストを受けて、前記第１のＧＵＩ部品群に対応する前記エレメント群と、前記クライアント装置で前記クライアントアプリケーションを起動させるための起動命令とを含む第１のＨＴＴＰレスポンスを生成する第１の生成ステップと、
   前記第１のＨＴＴＰレスポンスを前記ブラウザへ送信する第１のレスポンス送信ステップと、
   前記ブラウザが、前記第１のＨＴＴＰレスポンスを用いて、前記第１のＧＵＩ部品群を表示するとともに、前記クライアントアプリケーションを起動して、前記第２のＧＵＩ部品群を表示する第１の表示ステップと、
   前記クライアントアプリケーションが、前記第１の表示ステップにおいて表示された前記第２のＧＵＩ部品群のうちの入力フィールドに入力された入力データと前記入力フィールドに対応するＵＩコンポーネントの識別子とをパラメータとして含む第２のＨＴＴＰリクエストを前記Ｗｅｂアプリケーションへ送信するステップと、
   前記Ｗｅｂアプリケーションが前記第２のＨＴＴＰリクエストを受信するステップと、
   前記第２のＵＩコンポーネント群のうち、前記第２のＨＴＴＰリクエストのパラメータ中の前記識別子に対応するＵＩコンポーネントが、前記パラメータから前記入力データを取得し、当該入力データを用いて前記記憶手段を更新する更新ステップと、
   を有することを特徴とする通信方法。
2. 前記Ｗｅｂアプリケーションが、前記更新ステップの後に、前記第２のＨＴＴＰリクエストに対応する第２のＨＴＴＰレスポンスを前記クライアントアプリケーションへ送信する第２のレスポンス送信ステップと、
   前記クライアントアプリケーションが前記第２のＨＴＴＰレスポンスを受信するステップと、
   前記クライアントアプリケーションが、前記第２のＨＴＴＰレスポンスを受信するステップの後に、前記ブラウザに第３のＨＴＴＰリクエストを送信させるステップと、
   前記ブラウザからの前記第３のＨＴＴＰリクエストを受けて、前記第１及び第２のＵＩコンポーネント群が、前記第１のＧＵＩ部品群に対応する前記エレメント群、及び前記起動命令を含む第３のＨＴＴＰレスポンスを生成する第２の生成ステップと、
   前記Ｗｅｂアプリケーションが、前記第３のＨＴＴＰレスポンスを、前記ブラウザへ送信する第３のレスポンス送信ステップと、
   前記ブラウザが前記第３のＨＴＴＰレスポンスを受信するステップと、
   前記ブラウザが、前記第３のＨＴＴＰレスポンスを用いて、前記第１のＧＵＩ部品群を表示するとともに、前記クライアントアプリケーションを起動して、前記第２のＧＵＩ部品群を表示する第２の表示ステップと、
   を有することを特徴とする請求項１記載の通信方法。
3. 前記第２の生成ステップは、前記第１のＧＵＩ部品群のうちの表示フィールドに対応するＵＩコンポーネントが、更新後の前記記憶手段から前記表示フィールドに表示すべきデータを取得して、当該取得したデータを表示するためのＨＴＭＬのエレメントを生成するステップを含むことを特徴とする請求項２記載の通信方法。
4. 前記第２のＵＩコンポーネント群のうち、前記第２のＧＵＩ部品群のうちの表示フィールドに対応するＵＩコンポーネントが、前記更新ステップによる更新後の前記記憶手段から前記表示フィールドに表示すべきデータを取得して、当該データと前記表示フィールドに対応する識別子とを含むＨＴＭＬの第１のコメントエレメントを生成するステップを含み、当該第１のコメントエレメントを含む第２のＨＴＴＰレスポンスを生成する第２の生成ステップと、
   前記Ｗｅｂアプリケーションが、前記第２のＨＴＴＰレスポンスを、前記クライアントアプリケーションへ送信する第２のレスポンス送信ステップと、
   前記クライアントアプリケーションが前記第２のＨＴＴＰレスポンスを受信するステップと、
   前記クライアントアプリケーションが、前記第２のＨＴＴＰレスポンスに含まれる前記第１のコメントエレメント内のデータを前記表示フィールドに表示する第２の表示ステップと、
   を有することを特徴とする請求項１記載の通信方法。
5. 前記第１の生成ステップは、前記第２のＵＩコンポーネント群のうち前記表示フィールドに対応するＵＩコンポーネントが、前記記憶手段から前記表示フィールドに表示すべきデータを取得して、当該データと前記表示フィールドに対応する識別子とを含む前記起動命令のパラメータタグエレメントを生成するステップを含み、前記第１のＧＵＩ部品群に対応する前記エレメント群と、前記パラメータタグエレメント及び前記起動命令を含む前記第１のＨＴＴＰレスポンスを生成し、
   前記第１の表示ステップは、前記クライアントアプリケーションを起動して、前記第２のＧＵＩ部品群を表示するとともに、前記パラメータタグエレメント内のデータを前記表示フィールドに表示することを特徴とする請求項１記載の通信方法。
6. ブラウザを備えるクライアント装置と、
   前記クライアント装置の前記ブラウザで表示する第１のＧＵＩ部品群に対応するＨＴＭＬ（hyper text markup language）のエレメント群を生成するための第１のＵＩコンポーネント群と、前記クライアント装置で起動されるクライアントアプリケーションにより表示される第２のＧＵＩ部品群に対応する第２のＵＩコンポーネント群と、前記第１及び第２のＧＵＩ部品のうちの表示フィールドに表示すべきデータを記憶する記憶手段と、を備えたＷｅｂアプリケーションを備えるサーバ装置とが、ＨＴＴＰ（hyperText transfer protocol）を用いて通信を行う通信システムにおける通信方法において、
   前記Ｗｅｂアプリケーションが、前記ブラウザからの第１のＨＴＴＰリクエストを受けて、前記第１のＧＵＩ部品群に対応する前記エレメント群と、前記クライアント装置で前記クライアントアプリケーションを起動させるための起動命令とを含む第１のＨＴＴＰレスポンスを生成する第１の生成ステップと、
   前記第１のＨＴＴＰレスポンスを前記ブラウザへ送信する第１のレスポンス送信ステップと、
   前記ブラウザが、前記第１のＨＴＴＰレスポンスを用いて、前記第１のＧＵＩ部品群を表示するとともに、前記クライアントアプリケーションを起動して、前記第２のＧＵＩ部品群を表示する第１の表示ステップと、
   前記クライアントアプリケーションが、前記第１の表示ステップにおいて表示された前記第２のＧＵＩ部品群のうちの第１の入力フィールドに入力された入力データと、前記第１の入力フィールドに対応するＵＩコンポーネントの識別子とを含むパラメータを有する第２のＨＴＴＰリクエストを前記Ｗｅｂアプリケーションへ送信するステップと、
   前記Ｗｅｂアプリケーションが前記第２のＨＴＴＰリクエストを受信するステップと、
   前記Ｗｅｂアプリケーションが前記第２のＨＴＴＰリクエストの受信に成功した旨の第２のレスポンスを前記クライアントアプリケーションに送信する第２のレスポンス送信ステップと、
   前記クライアントアプリケーションが、前記第２のレスポンスを受けて、前記ブラウザに、前記第１の表示ステップにおいて表示された前記第１のＧＵＩ部品群のうちの第２の入力フィールドに入力された入力データと、前記第２の入力フィールドに対応するＵＩコンポーネントの識別子とを含むパラメータを有する第３のＨＴＴＰリクエストを前記Ｗｅｂアプリケーションへ送信させるステップと、
   前記Ｗｅｂアプリケーションが前記第３のＨＴＴＰリクエストを受信するステップと、
   前記Ｗｅｂアプリケーションが、前記第２のＨＴＴＰリクエストの前記パラメータ内の前記入力データ及び識別子と、前記第３のＨＴＴＰリクエストの前記パラメータ内の前記入力データ及び識別子とをパラメータとして含む第４のＨＴＴＰリクエストを生成するステップと、
   前記第１及び第２のＵＩコンポーネント群のうち、前記第４のＨＴＴＰリクエストのパラメータ中の各識別子に対応するＵＩコンポーネントが、当該パラメータから前記入力データを取得し、当該入力データを用いて前記記憶手段を更新するステップと、
   前記Ｗｅｂアプリケーションの前記第１及び第２のＵＩコンポーネント群が、前記更新するステップの後に、前記第１のＧＵＩ部品群に対応する前記エレメント群、及び前記起動命令を含む第３のＨＴＴＰレスポンスを生成する第２の生成ステップと、
   前記Ｗｅｂアプリケーションが、前記第３のＨＴＴＰレスポンスを、前記ブラウザへ送信する第３のレスポンス送信ステップと、
   前記ブラウザが前記第３のＨＴＴＰレスポンスを受信するステップと、
   前記ブラウザが、前記第３のＨＴＴＰレスポンスを用いて、前記第１のＧＵＩ部品群を表示するとともに、前記クライアントアプリケーションを起動して、前記第２のＧＵＩ部品群を表示する第２の表示ステップと、
   を有することを特徴とする通信方法。
7. 前記第２の生成ステップは、前記第１のＧＵＩ部品群のうちの表示フィールドに対応するＵＩコンポーネントが、更新後の前記記憶手段から前記表示フィールドに表示すべきデータを取得して、当該取得したデータを表示するためのＨＴＭＬのエレメントを生成するステップを含むことを特徴とする請求項６記載の通信方法。
8. 前記第２の生成ステップは、前記第２のＧＵＩ部品のうちの表示フィールドに対応するＵＩコンポーネントが、更新後の前記記憶手段から前記表示フィールドに表示すべきデータを取得して、当該データと前記表示フィールドに対応する識別子とを含む前記起動命令のパラメータタグエレメントを生成するステップを含み、前記第１のＧＵＩ部品群に対応する前記エレメント群と、前記パラメータタグエレメント及び前記起動命令を含む前記第３のＨＴＴＰレスポンスを生成し、
   前記第２の表示ステップは、前記クライアントアプリケーションを起動して、前記第２のＧＵＩ部品群を表示するとともに、前記パラメータタグエレメント内のデータを前記表示フィールドに表示することを特徴とする請求項６記載の通信方法。
9. 前記第１の生成ステップは、前記第２のＧＵＩ部品群のうちの表示フィールドに対応するＵＩコンポーネントが、前記記憶手段から前記表示フィールドに表示すべきデータを取得して、当該データと前記表示フィールドに対応する識別子とを含む前記起動命令のパラメータタグエレメントを生成するステップを含み、前記第１のＧＵＩ部品群に対応する前記エレメント群と、前記パラメータタグエレメント及び前記起動命令を含む前記第１のＨＴＴＰレスポンスを生成し、
   前記第１の表示ステップは、前記クライアントアプリケーションを起動して、前記第２のＧＵＩ部品群を表示するとともに、前記パラメータタグエレメント内のデータを前記表示フィールドに表示することを特徴とする請求項６記載の通信方法。
10. 前記Ｗｅｂアプリケーションは、前記第２のＧＵＩ部品群のうちの属性変更対象のＧＵＩ部品の属性値を記憶する属性記憶手段をさらに備え、
    前記第２の生成ステップは、前記第２のＵＩコンポーネント群のうちの前記属性変更対象のＧＵＩ部品に対応するＵＩコンポーネントが、前記属性記憶手段から当該ＧＵＩ部品に対応する属性値を取得して、当該属性値と当該ＧＵＩ部品に対応する識別子とを含む前記起動命令のパラメータタグエレメントを生成するステップを含み、前記第１のＧＵＩ部品群に対応する前記エレメント群と、前記パラメータタグエレメント及び前記起動命令を含む前記第３のＨＴＴＰレスポンスを生成し、
    前記第２の表示ステップは、前記クライアントアプリケーションを起動して、前記第２のＧＵＩ部品群を表示するとともに、前記パラメータタグエレメント内の属性値を用いて、前記属性変更対象のＧＵＩ部品の属性を変更することを特徴とする請求項２記載の通信方法。
11. 前記第１の生成ステップは、前記第２のＵＩコンポーネント群のうちの前記属性変更対象のＧＵＩ部品に対応するＵＩコンポーネントが、前記属性記憶手段から当該ＧＵＩ部品に対応する属性値を取得して、当該属性値と当該ＧＵＩ部品に対応する識別子とを含む前記起動命令のパラメータタグエレメントを生成するステップを含み、前記第１のＧＵＩ部品群に対応する前記エレメント群と、前記パラメータタグエレメント及び前記起動命令を含む前記第１のＨＴＴＰレスポンスを生成し、
    前記第１の表示ステップは、前記クライアントアプリケーションを起動して、前記第２のＧＵＩ部品群を表示するとともに、前記パラメータタグエレメント内の属性値を用いて、前記属性変更対象のＧＵＩ部品の属性を変更することを特徴とする請求項１記載の通信方法。
12. 前記Ｗｅｂアプリケーションは、前記第２のＧＵＩ部品群のうちの属性変更対象のＧＵＩ部品の属性値を記憶する属性記憶手段をさらに備え、
    前記第１の生成ステップは、前記第２のＵＩコンポーネント群のうちの前記属性変更対象のＧＵＩ部品に対応するＵＩコンポーネントが、前記属性記憶手段から当該ＧＵＩ部品に対応する属性値を取得して、当該属性値と当該ＧＵＩ部品に対応する識別子とを含む前記起動命令のパラメータタグエレメントを生成するステップを含み、前記第１のＧＵＩ部品群に対応する前記エレメント群と、前記パラメータタグエレメント及び前記起動命令を含む前記第１のＨＴＴＰレスポンスを生成し、
    前記第１の表示ステップは、前記クライアントアプリケーションを起動して、前記第２のＧＵＩ部品群を表示するとともに、前記パラメータタグエレメント内の属性値を用いて、前記属性変更対象のＧＵＩ部品の属性を変更することを特徴とする請求項６記載の通信方法。
13. 前記第２の生成ステップは、前記第２のＵＩコンポーネント群のうちの前記属性変更対象のＧＵＩ部品に対応するＵＩコンポーネントが、前記属性記憶手段から当該ＧＵＩ部品に対応する属性値を取得して、当該属性値と当該ＧＵＩ部品に対応する識別子とを含む前記起動命令のパラメータタグエレメントを生成するステップを含み、前記第１のＧＵＩ部品群に対応する前記エレメント群と、前記パラメータタグエレメント及び前記起動命令を含む前記第３のＨＴＴＰレスポンスを生成し、
    前記第２の表示ステップは、前記クライアントアプリケーションを起動して、前記第２のＧＵＩ部品群を表示するとともに、前記パラメータタグエレメント内の属性値を用いて、前記属性変更対象のＧＵＩ部品の属性を変更することを特徴とする請求項６記載の通信方法。
14. 前記Ｗｅｂアプリケーションが前記第２のＨＴＴＰリクエストのパラメータ中の前記入力データを基に前記属性記憶手段に記憶されている前記属性値を変更する変更ステップをさらに有し、
    前記第２の生成ステップは、前記第２のＵＩコンポーネント群のうちの前記属性変更対象のＧＵＩ部品に対応するＵＩコンポーネントが、前記属性記憶手段から前記変更ステップで変更された属性値を取得して、当該属性値と当該ＧＵＩ部品に対応する識別子とを含む前記起動命令のパラメータタグエレメントを生成することを特徴とする請求項１０記載の通信方法。
15. 前記Ｗｅｂアプリケーションが前記第４のＨＴＴＰリクエストのパラメータ中の前記入力データを基に前記属性記憶手段に記憶されている前記属性値を変更する変更ステップをさらに有し、
    前記第２の生成ステップは、前記第２のＵＩコンポーネント群のうちの前記属性変更対象のＧＵＩ部品に対応するＵＩコンポーネントが、前記属性記憶手段から前記変更ステップで変更された属性値を取得して、当該属性値と当該ＧＵＩ部品に対応する識別子とを含む前記起動命令のパラメータタグエレメントを生成することを特徴とする請求項１３記載の通信方法。
16. 前記第２のＧＵＩ部品群のうちの属性変更対象のＧＵＩ部品の属性値を記憶する属性記憶手段をさらに備えた前記Ｗｅｂアプリケーションが、
    前記第２のＨＴＴＰリクエストのパラメータ中の前記入力データを基に前記属性記憶手段に記憶されている前記属性値を変更する変更ステップをさらに有し、
    前記第２の生成ステップは、前記第２のＵＩコンポーネント群のうちの前記属性変更対象のＧＵＩ部品に対応するＵＩコンポーネントが、前記属性記憶手段から前記変更ステップで変更された属性値を取得して、当該属性値と当該ＧＵＩ部品に対応する識別子とを含むＨＴＭＬの第２のコメントエレメントを生成するステップをさらに含み、前記第１及び第２のコメントエレメントを含む前記第２のＨＴＴＰレスポンスを生成し、
    前記第２の表示ステップは、前記第２のコメントエレメント内の属性値を用いて、前記属性変更対象のＧＵＩ部品の属性を変更することを特徴とする請求項４記載の通信方法。
17. ブラウザを備えるクライアント装置から送信されたＨＴＴＰ（hyperText transfer protocol）リクエストを受信する受信手段と、
    前記ブラウザで表示する第１のＧＵＩ部品群、及び前記ブラウザにより起動されるクライアントアプリケーションにより表示される第２のＧＵＩ部品群のうち、表示フィールドに対応するＧＵＩ部品に表示すべきデータを記憶する記憶手段と、
    前記第１のＧＵＩ部品群に対応するＨＴＭＬ（hyper text markup language）のエレメント群を生成するための第１のＵＩコンポーネント群と、前記第２のＧＵＩ部品群に対応する第２のＵＩコンポーネント群とを含み、前記ＨＴＴＰリクエストを受けて、
    （ａ）前記第１のＧＵＩ部品群のうちの表示フィールドに対応するＵＩコンポーネントで、前記記憶手段から前記表示フィールドに表示すべきデータを取得して、当該取得したデータを表示するためのＨＴＭＬの表示エレメントを生成し、
    （ｂ）前記表示エレメントを含む前記エレメント群と、前記クライアントアプリケーションを起動させるための起動命令とを含むＨＴＴＰレスポンスを生成する第１の生成手段と、
    前記第１の生成手段で生成された前記ＨＴＴＰレスポンスを送信する送信手段とを備えるＷｅｂアプリケーションを備え、
    前記受信手段で受信された前記ＨＴＴＰリクエストに、送信済のＨＴＴＰレスポンスを用いて前記クライアント装置が前記クライアントアプリケーションを起動することにより表示された前記第２のＧＵＩ部品群のうちの入力フィールドに入力された値と前記入力フィールドに対応するＵＩコンポーネントの識別子とを含むパラメータが含まれているときには、前記第１の生成手段は、前記ＨＴＴＰリクエストに対するＨＴＴＰレスポンスを生成するよりも前に、前記第２のＵＩコンポーネント群のうち、前記ＨＴＴＰリクエストのパラメータ中の前記識別子に対応するＵＩコンポーネントで、前記パラメータから前記値を取得し、当該値を用いて前記記憶手段を更新することを特徴とするサーバ装置。
18. ブラウザを備えるクライアント装置から送信されたＨＴＴＰ（hyperText transfer protocol）リクエストを受信する受信手段と、
    前記ブラウザで表示する第１のＧＵＩ部品群、及び前記ブラウザにより起動されるクライアントアプリケーションにより表示される第２のＧＵＩ部品群のうち、表示フィールドに対応するＧＵＩ部品に表示すべきデータを記憶する記憶手段と、
    前記第１のＧＵＩ部品群に対応するＨＴＭＬ（hyper text markup language）のエレメント群を生成するための第１のＵＩコンポーネント群と、前記第２のＧＵＩ部品群に対応する第２のＵＩコンポーネント群とを含み、前記ＨＴＴＰリクエストを受けて、
    （ａ）前記第２のＧＵＩ部品群のうちの表示フィールドに対応するＵＩコンポーネントで、前記記憶手段から前記表示フィールドに表示すべきデータを取得して、当該データと前記表示フィールドに対応する識別子とを含むＨＴＭＬの第１のコメントエレメントを生成し、
    （ｂ）前記エレメント群と、前記クライアントアプリケーションを起動させるための起動命令と、前記第１のコメントエレメントとを含むＨＴＴＰレスポンスを生成する第１の生成手段と、
    前記第１の生成手段で生成されたＨＴＴＰレスポンスを送信する送信手段とを備えるＷｅｂアプリケーションを備え、
    前記受信手段で受信された前記ＨＴＴＰリクエストに、送信済のＨＴＴＰレスポンスを用いて前記クライアント装置が前記クライアントアプリケーションを起動することにより表示された前記第２のＧＵＩ部品群のうちの入力フィールドに入力された値と前記入力フィールドに対応するＵＩコンポーネントの識別子とを含むパラメータが含まれているときには、前記第１の生成手段は、前記ＨＴＴＰリクエストに対するＨＴＴＰレスポンスを生成するよりも前に、前記第２のＵＩコンポーネント群のうち、前記ＨＴＴＰリクエストのパラメータ中の前記識別子に対応するＵＩコンポーネントで、前記パラメータから前記値を取得し、当該データを用いて前記記憶手段を更新することを特徴とするサーバ装置。
19. 前記Ｗｅｂアプリケーションが、
    前記受信手段で受信された、予め定められたフラグデータを含む第１のＨＴＴＰリクエストから、ＵＩコンポーネントの識別子と値とを含む第１のパラメータを抽出するとともに、その後に前記受信手段で受信された第２のＨＴＴＰリクエストから、ＵＩコンポーネントの識別子と値とを含む第２のパラメータを抽出し、前記第１及び第２のパラメータを含む前記第１の生成手段へ入力するＨＴＴＰリクエストを生成する第２の生成手段を、
    さらに具備したことを特徴とする請求項１７または１８記載のサーバ装置。
20. 前記第１の生成手段は、
    前記受信手段で受信されたＨＴＴＰのＧＥＴリクエストを受けて、
    前記第２のＵＩコンポーネント群のうち前記表示フィールドに対応するＵＩコンポーネントが、前記記憶手段から前記表示フィールドに表示すべきデータを取得して、当該データと前記表示フィールドに対応する識別子とを含む前記起動命令のパラメータタグエレメントを生成し、
    前記第１のＧＵＩ部品群に対応する前記エレメント群と、前記パラメータタグエレメント及び前記起動命令を含む前記ＨＴＴＰレスポンスを生成することを特徴とする請求項１８記載のサーバ装置。
21. 前記Ｗｅｂアプリケーションは、前記第２のＧＵＩ部品群のうちの属性変更対象のＧＵＩ部品の属性値を記憶する属性記憶手段をさらに具備し、
    前記第１の生成手段は、前記第２のＵＩコンポーネント群のうちの前記属性変更対象のＧＵＩ部品に対応するＵＩコンポーネントで、前記属性記憶手段から当該ＧＵＩ部品に対応する属性値を取得して、当該属性値と当該ＧＵＩ部品に対応する識別子とを含む前記起動命令のパラメータタグエレメントを生成し、
    前記第１のＧＵＩ部品群に対応する前記エレメント群と、前記パラメータタグエレメント及び前記起動命令を含む前記ＨＴＴＰレスポンスを生成することを特徴とする請求項１７記載のサーバ装置。
22. 前記Ｗｅｂアプリケーションが、
    前記受信手段で受信された前記ＨＴＴＰリクエストに含まれている、前記第２のＧＵＩ部品群のうちの入力フィールドに入力された入力データと前記入力フィールドに対応するＵＩコンポーネントの識別子とを含むパラメータの前記入力データを基に、前記属性記憶手段に記憶されている前記属性値を変更する属性変更手段をさらに具備したことを特徴とする請求項２１記載のサーバ装置。
23. 前記Ｗｅｂアプリケーションは、
    前記第２のＧＵＩ部品群のうちの属性変更対象のＧＵＩ部品の属性値を記憶する属性記憶手段と、
    前記受信手段で受信された前記ＨＴＴＰリクエストに含まれている、前記第２のＧＵＩ部品群のうちの入力フィールドに入力された入力データと前記入力フィールドに対応するＵＩコンポーネントの識別子とを含むパラメータの前記入力データを基に、前記属性記憶手段に記憶されている前記属性値を変更する属性変更手段とをさらに具備し、
    前記第１の生成手段は、前記第２のＵＩコンポーネント群のうちの前記属性変更対象のＧＵＩ部品に対応するＵＩコンポーネントで、前記属性記憶手段から当該ＧＵＩ部品に対応する属性値を取得して、当該属性値と当該ＧＵＩ部品に対応する識別子とを含むＨＴＭＬの第２のコメントタグエレメントを生成し、
    前記第１のＧＵＩ部品群に対応する前記エレメント群と、前記起動命令と、前記第１及び第２のコメントエレメントとを含む前記ＨＴＴＰレスポンスを生成することを特徴とする請求項１８記載のサーバ装置。

Images