JP2010231314A - 端末装置及びプログラム - Google Patents

Abstract

【課題】ウェブシステムとの親和性が高く、かつ、サーバ側にかかる負荷及び通信処理等にかかる負荷が低いシステムを提供する。
【解決手段】端末装置２００は、ウェブブラウザ２０１でウェブサービスアプレット４２１を動作させる。ウェブサービスアプレット４２１は、ウェブサービスページ４０１のＧＵＩ４１１に対する入力データを含むＨＴＴＰリクエストをウェブブラウザ２０１から受信し、受信した入力データに応じて所定の処理を実行し、実行した処理の結果に基づいてウェブサービスページ４０１を更新するための更新データを生成し、生成した更新データを含むＨＴＴＰレスポンスを返信する。端末装置２００は、当該更新データに従ってウェブブラウザ２０１の画面に表示されているウェブサービスページ４０１のＧＵＩ４１１を更新する。
【選択図】図１

Description

本発明は、端末装置及びプログラムに関するものである。本発明は、特に、ウェブサービスアプレットを使ったウェブ３階層モデルに関するものである。

サーバからクライアント側にダウンロードしたアプレット（他のアプリケーションの中に組み込まれて実行される小さなプログラム。Ｊａｖａ（登録商標）アプレットやプラグイン等）を用いて、業務処理の効率化やネットワーク負荷の軽減等を図る技術が知られている（例えば、特許文献１〜３参照）。

特開平１１−１０２２８９号公報 特開２００１−１６７１６７号公報 特開２００２−２１５４４７号公報

ウェブサーバ、アプリケーションサーバ、データベースからなる従来のウェブ３階層モデルでは、それ以前のクライアントサーバ方式（２階層モデル）と比べると、クライアント側にアプリケーションを実装する必要がないため、システムの変更等が容易であり、柔軟性の高いシステムを構築することが可能であった。しかしながら、サーバに大きな負荷がかかる、連係が密になりすぎる、クライアント側で複雑なことができないといった課題があった。これらの課題の解決策として、前述したようなＪａｖａ（登録商標）アプレット等を用いたスマートクライアントモデルが挙げられるが、ウェブシステムとの親和性が低いという課題がある。

本発明は、例えば、ウェブシステムとの親和性が高く、かつ、サーバ側にかかる負荷及び通信処理等にかかる負荷が低いシステムを提供することを目的とする。

本発明の一の態様に係る端末装置は、
ウェブブラウザを処理装置により実行する端末装置であり、
ウェブページを提供するサーバ装置であって、前記ウェブページに対する入力データを受信すると、受信した入力データに応じて所定の処理を実行し、実行した処理の結果に基づいて前記ウェブページを更新するための更新データを生成し、生成した更新データを返信するアプレットを保持するサーバ装置から、前記ウェブページと前記アプレットとを前記ウェブブラウザによって受信する第１通信部と、
前記第１通信部により受信されたウェブページを前記ウェブブラウザの画面に表示する表示部と、
前記第１通信部により受信されたアプレットを前記ウェブブラウザで実行する実行部と、
ユーザが入力装置を操作して前記表示部により前記ウェブページが表示されている前記ウェブブラウザの画面に入力する入力データを受け付ける入力部と、
前記実行部により前記ウェブブラウザで実行されているアプレットへ、前記入力部により受け付けられた入力データを前記ウェブブラウザによって送信し、当該アプレットから返信される更新データを前記ウェブブラウザによって受信する第２通信部と、
前記第２通信部により受信された更新データに従って、前記表示部により前記ウェブブラウザの画面に表示されているウェブページを更新する更新部とを備えることを特徴とする。

前記アプレットは、前記所定の処理を実行する際に、前記所定の処理を実行するためのデータが不足している場合、前記サーバ装置から当該データを受信し、受信したデータを用いて前記所定の処理を実行することを特徴とする。

前記入力装置は、ポインティングデバイスであり、
前記表示部は、前記ポインティングデバイスのポインタを前記ウェブブラウザの画面に表示し、
前記入力部は、前記ユーザが前記ポインティングデバイスを操作して前記表示部により前記ウェブブラウザの画面に表示されているポインタを移動させる度に、移動したポインタの位置を特定する位置データを前記入力データとして受け付け、
前記第２通信部は、前記入力部により前記位置データが受け付けられる度に、前記実行部により前記ウェブブラウザで実行されているアプレットへ、当該位置データを前記ウェブブラウザによって送信し、当該アプレットから返信される更新データを前記ウェブブラウザによって受信することを特徴とする。

前記ウェブページは、地図を表示するページであり、
前記アプレットは、前記位置データを受信すると、受信した位置データで特定される位置が前記地図上で予め決められた地点に一致するか否かを判定する処理を前記所定の処理として実行し、一致すると判定した場合、当該地点の表示内容を所定の内容に変更することを指示する指示データを前記更新データとして生成することを特徴とする。

前記第２通信部は、前記実行部により前記ウェブブラウザで実行されているアプレットへ、前記入力部により受け付けられた入力データを含むＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ・Ｔｒａｎｓｆｅｒ・Ｐｒｏｔｏｃｏｌ）リクエストを前記ウェブブラウザによって送信し、当該アプレットから返信される更新データを含むＨＴＴＰレスポンスを前記ウェブブラウザによって受信することを特徴とする。

本発明の一の態様に係るプログラムは、
コンピュータにより実行されるウェブブラウザで動作するアプレットであり、
前記ウェブブラウザから、前記ウェブブラウザの画面に表示されるウェブページに対する入力データを受信する受信処理と、
前記受信処理が受信した入力データに応じて所定の処理を実行する実行処理と、
前記実行処理が実行した処理の結果に基づいて前記ウェブページを更新するための更新データを生成する生成処理と、
前記ウェブブラウザへ、前記生成処理が生成した更新データを返信する返信処理とをコンピュータに実行させることを特徴とする。

本発明の一の態様によれば、ウェブページに対する入力データを受信すると、受信した入力データに応じて所定の処理を実行し、実行した処理の結果に基づいて当該ウェブページを更新するための更新データを生成し、生成した更新データを返信するアプレットを、端末装置がウェブブラウザで動作させ、端末装置が当該更新データに従ってウェブブラウザの画面に表示されているウェブページを更新するため、ウェブシステムとの親和性が高く、かつ、サーバ側にかかる負荷及び通信処理等にかかる負荷が低いシステムを提供することが可能となる。

実施の形態１に係る通信システムの構成を示すブロック図である。 実施の形態１に係る端末装置の構成を示すブロック図である。 実施の形態１に係る端末装置のハードウェア構成の一例を示す図である。 実施の形態１に係る通信システムの動作を示す図である。 実施の形態１に係る通信システムの動作を示す図である。 実施の形態１に係る通信システムの動作を示す図である。 実施の形態１に係る通信システムの動作を示す図である。 実施の形態１に係る通信システムの動作を示す図である。 従来のＧＩＳの動作を示す図である。 ウェブ上で使われるＧＩＳの動作を示す図である。 ウェブ上で使われる別のＧＩＳの動作を示す図である。 実施の形態２に係るＧＩＳの動作を示す図である。 実施の形態２に係るＧＩＳの動作を示す図である。 実施の形態２に係るＧＩＳの動作を示す図である。 実施の形態２に係るＧＩＳの動作を示す図である。 実施の形態２に係るＧＩＳの動作を示す図である。 ウェブ上で使われる別のＧＩＳの動作を示す図である。 実施の形態２に係るＧＩＳの動作を示す図である。

以下、本発明の実施の形態について、図を用いて説明する。

実施の形態１．
図１は、本実施の形態に係る通信システム１００の構成を示すブロック図である。

図１において、通信システム１００は、端末装置２００（「クライアント」ともいう）、サーバ装置３００（単に「サーバ」ともいう）を備える。端末装置２００、サーバ装置３００は、それぞれが複数存在していてもよい。端末装置２００とサーバ装置３００は、インターネット４００を介して互いに任意の方式で通信を行う。

端末装置２００は、ウェブブラウザ２０１を実行する。ウェブブラウザ２０１は、ウェブページを画面に表示してユーザに閲覧させるアプリケーションソフトウェアである。サーバ装置３００は、ウェブサーバ３０１を実行する。ウェブサーバ３０１は、ウェブページを提供するサーバソフトウェアである。サーバ装置３００は、アプレットを保持しており、ウェブサーバ３０１は、アプレットを含むウェブページを提供することも可能である。ウェブブラウザ２０１は、ウェブページにアプレットが含まれている場合、ウェブページを画面に表示する際に、そのアプレットを実行する。アプレットは、通常のアプリケーションプログラムと異なり、ウェブブラウザ２０１上でのみ動作するプログラム（ここでは、プラグインも含むものとする）である。アプレットの代表例としては、Ｊａｖａ（登録商標）アプレットが挙げられる。

端末装置２００とサーバ装置３００は、それぞれウェブブラウザ２０１とウェブサーバ３０１を利用して、インターネット４００を介して互いにＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ・Ｔｒａｎｓｆｅｒ・Ｐｒｏｔｏｃｏｌ）通信を行う。例えば、端末装置２００は、サーバ装置３００に対して、ＨＴＴＰリクエストをウェブブラウザ２０１により送信してウェブページを要求する。サーバ装置３００は、端末装置２００から送信されたＨＴＴＰリクエストをウェブサーバ３０１により受信すると、受信したＨＴＴＰリクエストで要求されたウェブページのＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ・Ｍａｒｋｕｐ・Ｌａｎｇｕａｇｅ）文書等のデータを含むＨＴＴＰレスポンスをウェブサーバ３０１により返信する。端末装置２００は、サーバ装置３００から送信されたＨＴＴＰレスポンスをウェブブラウザ２０１により受信すると、受信したＨＴＴＰレスポンスに含まれるデータを用いてウェブページをウェブブラウザ２０１の画面（ウィンドウ、フレーム、ダイアログ等）に表示する。

本実施の形態では、端末装置２００は、ウェブブラウザ２０１によって、ウェブサービスページ４０１をサーバ装置３００へ要求する。ウェブサービスページ４０１は、ウェブブラウザ２０１の画面に表示されるＧＵＩ４１１（Ｇｒａｐｈｉｃａｌ・Ｕｓｅｒ・Ｉｎｔｅｒｆａｃｅ）の部分と、ウェブブラウザ２０１で動作するウェブサービスアプレット４２１の部分とを含むウェブページである。ＧＵＩ４１１は、例えば、ＪａｖａＳｃｒｉｐｔ（登録商標）やＨＴＭＬで構成される。ウェブサービスアプレット４２１は、従来のウェブ３階層モデルにおけるウェブサーバ３０１と同様に、ウェブブラウザ２０１に対してウェブサービスを提供するアプレットである。

サーバ装置３００は、ウェブサービスアプレット４２１の実体ファイル３０２を記憶装置に保持している。なお、ウェブサービスアプレット４２１がＪａｖａ（登録商標）アプレットであれば、実体ファイル３０２は例えばＪＡＲ（Ｊａｖａ・ＡＲｃｈｉｖｅ）ファイルとして保持されることになる。また、サーバ装置３００は、従来のウェブ３階層モデルと同様に、サーバ側アプリケーション３０３（アプリケーションサーバ）やデータベース３０４を有している。サーバ装置３００は、端末装置２００からウェブサービスページ４０１が要求されると、サーバ側アプリケーション３０３によって、ウェブサービスページ４０１を生成し、ウェブサーバ３０１によって、ウェブサービスページ４０１を端末装置２００へ送信する。また、サーバ装置３００は、ウェブサーバ３０１によって、ウェブサービスアプレット４２１の実体ファイル３０２を端末装置２００へ送信する。

端末装置２００は、ウェブブラウザ２０１によって、ウェブサービスページ４０１とウェブサービスアプレット４２１の実体ファイル３０２とをサーバ装置３００から受信すると、ウェブサービスページ４０１のＧＵＩ４１１の部分をウェブブラウザ２０１の画面に表示するとともに、ウェブブラウザ２０１によって、ウェブサービスアプレット４２１を実行する。

図２は、端末装置２００の構成を示すブロック図である。

図２において、端末装置２００は、第１通信部２１１、表示部２１２、実行部２１３、入力部２１４、第２通信部２１５を備える。各部の動作については後述する。

また、端末装置２００は、処理装置２５１、記憶装置２５２、入力装置２５３、出力装置２５４等のハードウェアを備える。ハードウェアは端末装置２００の各部によって利用される。例えば、処理装置２５１は、端末装置２００の各部でデータや情報の演算、加工、読み取り、書き込み等を行うために利用される。記憶装置２５２は、そのデータや情報を記憶するために利用される。また、入力装置２５３は、そのデータや情報を入力するために、出力装置２５４は、そのデータや情報を出力するために利用される。

図３は、端末装置２００のハードウェア構成の一例を示す図である。

図３において、端末装置２００は、コンピュータであり、ＬＣＤ９０１（Ｌｉｑｕｉｄ・Ｃｒｙｓｔａｌ・Ｄｉｓｐｌａｙ）、キーボード９０２（Ｋ／Ｂ）、マウス９０３、ＦＤＤ９０４（Ｆｌｅｘｉｂｌｅ・Ｄｉｓｋ・Ｄｒｉｖｅ）、ＣＤＤ９０５（Ｃｏｍｐａｃｔ・Ｄｉｓｃ・Ｄｒｉｖｅ）、プリンタ９０６といったハードウェアデバイスを備えている。これらのハードウェアデバイスはケーブルや信号線で接続されている。ＬＣＤ９０１の代わりに、ＣＲＴ（Ｃａｔｈｏｄｅ・Ｒａｙ・Ｔｕｂｅ）、あるいは、その他の表示装置が用いられてもよい。マウス９０３の代わりに、タッチパネル、タッチパッド、トラックボール、ペンタブレット、あるいは、その他のポインティングデバイスが用いられてもよい。

端末装置２００は、プログラムを実行するＣＰＵ９１１（Ｃｅｎｔｒａｌ・Ｐｒｏｃｅｓｓｉｎｇ・Ｕｎｉｔ）を備えている。ＣＰＵ９１１は、処理装置２５１の一例である。ＣＰＵ９１１は、バス９１２を介してＲＯＭ９１３（Ｒｅａｄ・Ｏｎｌｙ・Ｍｅｍｏｒｙ）、ＲＡＭ９１４（Ｒａｎｄｏｍ・Ａｃｃｅｓｓ・Ｍｅｍｏｒｙ）、通信ボード９１５、ＬＣＤ９０１、キーボード９０２、マウス９０３、ＦＤＤ９０４、ＣＤＤ９０５、プリンタ９０６、ＨＤＤ９２０（Ｈａｒｄ・Ｄｉｓｋ・Ｄｒｉｖｅ）と接続され、これらのハードウェアデバイスを制御する。ＨＤＤ９２０の代わりに、フラッシュメモリ、光ディスク装置、メモリカードリーダライタ又はその他の記憶媒体が用いられてもよい。

ＲＡＭ９１４は、揮発性メモリの一例である。ＲＯＭ９１３、ＦＤＤ９０４、ＣＤＤ９０５、ＨＤＤ９２０は、不揮発性メモリの一例である。これらは、記憶装置２５２の一例である。通信ボード９１５、キーボード９０２、マウス９０３、ＦＤＤ９０４、ＣＤＤ９０５は、入力装置２５３の一例である。また、通信ボード９１５、ＬＣＤ９０１、プリンタ９０６は、出力装置２５４の一例である。

通信ボード９１５は、ＬＡＮ（Ｌｏｃａｌ・Ａｒｅａ・Ｎｅｔｗｏｒｋ）を介して、インターネット４００に接続されている。通信ボード９１５は、ＬＡＮに限らず、ＩＰ−ＶＰＮ（Ｉｎｔｅｒｎｅｔ・Ｐｒｏｔｏｃｏｌ・Ｖｉｒｔｕａｌ・Ｐｒｉｖａｔｅ・Ｎｅｔｗｏｒｋ）、広域ＬＡＮ、ＡＴＭ（Ａｓｙｎｃｈｒｏｎｏｕｓ・Ｔｒａｎｓｆｅｒ・Ｍｏｄｅ）ネットワークといったＷＡＮ（Ｗｉｄｅ・Ａｒｅａ・Ｎｅｔｗｏｒｋ）を介して、インターネット４００に接続されていても構わない。

ＨＤＤ９２０には、オペレーティングシステム９２１（ＯＳ）、ウィンドウシステム９２２、プログラム群９２３、ファイル群９２４が記憶されている。プログラム群９２３のプログラムは、ＣＰＵ９１１、オペレーティングシステム９２１、ウィンドウシステム９２２により実行される。プログラム群９２３には、本実施の形態の説明において「〜部」として説明する機能を実行するプログラムが含まれている。プログラムは、ＣＰＵ９１１により読み出され実行される。ファイル群９２４には、本実施の形態の説明において、「〜データ」、「〜情報」、「〜ＩＤ（識別子）」、「〜フラグ」、「〜結果」として説明するデータや情報や信号値や変数値やパラメータが、「〜ファイル」や「〜データベース」や「〜テーブル」の各項目として含まれている。「〜ファイル」や「〜データベース」や「〜テーブル」は、ＲＡＭ９１４やＨＤＤ９２０等の記憶媒体に記憶される。ＲＡＭ９１４やＨＤＤ９２０等の記憶媒体に記憶されたデータや情報や信号値や変数値やパラメータは、読み書き回路を介してＣＰＵ９１１によりメインメモリやキャッシュメモリに読み出され、抽出、検索、参照、比較、演算、計算、制御、出力、印刷、表示といったＣＰＵ９１１の処理（動作）に用いられる。抽出、検索、参照、比較、演算、計算、制御、出力、印刷、表示といったＣＰＵ９１１の処理中、データや情報や信号値や変数値やパラメータは、メインメモリやキャッシュメモリやバッファメモリに一時的に記憶される。

本実施の形態の説明において用いるブロック図やフローチャートの矢印の部分は主としてデータや信号の入出力を示す。データや信号は、ＲＡＭ９１４等のメモリ、ＦＤＤ９０４のフレキシブルディスク（ＦＤ）、ＣＤＤ９０５のコンパクトディスク（ＣＤ）、ＨＤＤ９２０の磁気ディスク、光ディスク、ＤＶＤ（Ｄｉｇｉｔａｌ・Ｖｅｒｓａｔｉｌｅ・Ｄｉｓｃ）、あるいは、その他の記録媒体に記録される。また、データや信号は、バス９１２、信号線、ケーブル、あるいは、その他の伝送媒体により伝送される。

本実施の形態の説明において「〜部」として説明するものは、「〜回路」、「〜装置」、「〜機器」であってもよく、また、「〜ステップ」、「〜工程」、「〜手順」、「〜処理」であってもよい。即ち、「〜部」として説明するものは、ＲＯＭ９１３に記憶されたファームウェアで実現されていても構わない。あるいは、「〜部」として説明するものは、ソフトウェアのみ、あるいは、素子、デバイス、基板、配線といったハードウェアのみで実現されていても構わない。あるいは、「〜部」として説明するものは、ソフトウェアとハードウェアとの組み合わせ、あるいは、ソフトウェアとハードウェアとファームウェアとの組み合わせで実現されていても構わない。ファームウェアとソフトウェアは、プログラムとして、フレキシブルディスク、コンパクトディスク、磁気ディスク、光ディスク、ＤＶＤ等の記録媒体に記憶される。プログラムはＣＰＵ９１１により読み出され、ＣＰＵ９１１により実行される。即ち、プログラムは、本実施の形態の説明で述べる「〜部」としてコンピュータを機能させるものである。あるいは、プログラムは、本実施の形態の説明で述べる「〜部」の手順や方法をコンピュータに実行させるものである。

サーバ装置３００も、端末装置２００と同様に、上記のようなコンピュータで実現できる。

図４及び図５は、ウェブサービスアプレット４２１を起動する際の通信システム１００の動作を示す図である。

図４において、クライアント側では、ウェブブラウザ２０１により、ＨＴＭＬ画面の呼び出しを行う。サーバ側では、サーバ側アプリケーション３０３により、クライアント側から受けた要求に合わせて、ウェブサービスアプレット４２１が埋め込まれている（＜ｏｂｊｅｃｔ＞タグや＜ａｐｐｌｅｔ＞タグを使用する）ＨＴＭＬ文書であるウェブサービスページ４０１を出力する。前述したように、ウェブサービスアプレット４２１は、通常のＪａｖａ（登録商標）アプレット等のようにＨＴＭＬ文書の中に埋め込まれてウェブブラウザ２０１の中で実行される。このＨＴＭＬ文書の中で、ウェブサービスアプレット４２１の部分にはウェブサービスを開始するために必要な情報が記述される。ウェブサービスアプレット４２１がＪａｖａ（登録商標）アプレットの場合は、例えば、実行に必要なＪＡＲファイル名やダウンロード先ロケーション等が記述される。

以下、具体的な動作について説明する。

端末装置２００は、ウェブブラウザ２０１を処理装置２５１により実行しており、ウェブブラウザ２０１の画面に任意ページ４０２（任意のウェブページ）を表示する。例えば任意ページ４０２にウェブサービスページ４０１へのリンクが含まれている場合、ユーザが入力装置２５３を操作して、そのリンクを選択すると、端末装置２００の第１通信部２１１は、サーバ装置３００に対し、ウェブサービスページ４０１の要求を含むＨＴＴＰリクエストをウェブブラウザ２０１によって送信する。

サーバ装置３００は、ウェブサービスページ４０１の要求を含むＨＴＴＰリクエストをウェブサーバ３０１によって受信する。サーバ装置３００は、受信したＨＴＴＰリクエストに含まれる要求をサーバ側アプリケーション３０３によって解析し、ウェブサービスアプレット４２１が埋め込まれているＨＴＭＬ文書、即ち、ウェブサービスページ４０１を生成する。そして、サーバ装置３００は、端末装置２００に対し、ウェブサービスページ４０１を含むＨＴＴＰレスポンスをウェブサーバ３０１によって送信する。

端末装置２００の第１通信部２１１は、ウェブサービスページ４０１を含むＨＴＴＰレスポンスをウェブブラウザ２０１によって受信する。端末装置２００の表示部２１２は、第１通信部２１１により受信されたＨＴＴＰレスポンスに含まれるウェブサービスページ４０１のＧＵＩ４１１をウェブブラウザ２０１の画面に表示する。この時点では、まだウェブサービスアプレット４２１の実体ファイル３０２がダウンロードされていないため、ウェブサービスアプレット４２１は起動されない。なお、端末装置２００の第１通信部２１１は、ウェブサービスページ４０１とウェブサービスアプレット４２１とをウェブブラウザ２０１によって同時にダウンロード（同じＨＴＴＰレスポンスで受信）してもよい。

図５において、クライアント側では、ウェブブラウザ２０１により、ウェブサービスアプレット４２１のダウンロードと起動を行う。ウェブブラウザ２０１は、ウェブサービスアプレット４２１の部分（＜ｏｂｊｅｃｔ＞タグや＜ａｐｐｌｅｔ＞タグ）に記述されている内容を基にウェブサービスアプレット４２１の実体ファイル３０２をクライアント側にダウンロードした後、任意のＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ・Ｃｏｎｔｒｏｌ・Ｐｒｏｔｏｃｏｌ）ポートを開いてウェブサービスを開始する。なお、ウェブブラウザ２０１は、オープンするポートが他の通信処理と競合しないように、かつ、不特定者からのアクセスを防ぐために、クライアント側のポートの使用状況を確認しながら任意の値域にあるポートをランダムに開く。また、ウェブブラウザ２０１は、ウェブサービスアプレット４２１が開始するまではＧＵＩ４１１の操作ができないような制御も行うものとする。ウェブサービスアプレット４２１がＪａｖａ（登録商標）アプレットの場合は、例えば、ウェブサービスアプレット４２１のロード完了時にＧＵＩ４１１側にコールバックで通知する、あるいは、ステータス確認用のインタフェースを１つ公開しておきＧＵＩ４１１側から定期的にアクセスして確認するという方法で実装することができる。

以下、具体的な動作について説明する。

端末装置２００の第１通信部２１１は、ウェブサービスページ４０１に埋め込まれているウェブサービスアプレット４２１を起動するため、サーバ装置３００に対し、ウェブサービスアプレット４２１の実体ファイル３０２の要求を含むＨＴＴＰリクエストをウェブブラウザ２０１によって送信する。

サーバ装置３００は、ウェブサービスアプレット４２１の実体ファイル３０２の要求を含むＨＴＴＰリクエストをウェブサーバ３０１によって受信する。サーバ装置３００は、受信したＨＴＴＰリクエストに含まれる要求をサーバ側アプリケーション３０３によって解析し、ウェブサービスアプレット４２１に利用させるデータ（例えば、後述する地図データ）をデータベース３０４からサーバ側アプリケーション３０３によって抽出し、必要に応じてデータ処理を行った上でウェブサービスアプレット４２１の実体ファイル３０２に付加する。そして、サーバ装置３００は、端末装置２００に対し、ウェブサービスアプレット４２１の実体ファイル３０２を含むＨＴＴＰレスポンスをウェブサーバ３０１によって送信する。なお、サーバ装置３００は、ウェブサービスアプレット４２１に利用させるデータを最初からウェブサービスアプレット４２１の実体ファイル３０２に付加しておくのではなく、ウェブサービスアプレット４２１からの要求があったときに初めて、その応答としてウェブサービスアプレット４２１にデータを送信するようにしてもよい。

端末装置２００の第１通信部２１１は、ウェブサービスアプレット４２１の実体ファイル３０２を含むＨＴＴＰレスポンスをウェブブラウザ２０１によって受信する。端末装置２００の実行部２１３は、第１通信部２１１により受信されたＨＴＴＰレスポンスに含まれるウェブサービスアプレット４２１の実体ファイル３０２を展開してウェブサービスアプレット４２１をウェブブラウザ２０１で起動する。本実施の形態では、ウェブサービスアプレット４２１はアプレット画面を表示しないものとする。そのため、ウェブサービスアプレット４２１は、例えばウェブサービスページ４０１に含まれる非表示のフレームに埋め込まれている（非表示のフレームに＜ｏｂｊｅｃｔ＞タグや＜ａｐｐｌｅｔ＞タグが記述される）。

ウェブサービスアプレット４２１は、ウェブブラウザ２０１上で起動されると、ウェブサービス（例えば、後述する地図表示サービス）を起動し、ウェブブラウザ２０１とのＨＴＴＰ通信によりＧＵＩ４１１を操作可能にする（Ｓ１０１：起動処理）。ウェブサービスアプレット４２１がＧＵＩ４１１を制御する方法の詳細については後述する。

図６及び図７は、ウェブサービスアプレット４２１を使って画面遷移処理を行う際の通信システム１００の動作を示す図である。

図６において、クライアント側では、サーバ側でウェブサービスアプレット４２１の実体ファイル３０２に付加されたデータ（例えば、後述する地図データ）を利用した処理（例えば、後述するイメージ生成処理）、定型の画面遷移や入力確認の処理等、クライアント側のみで実行できる処理については、ウェブサービスアプレット４２１内で実行し応答を返す。ＧＵＩ４１１の部分、即ち、ウェブブラウザ２０１と、ウェブサービスアプレット４２１との間ではＨＴＴＰを使って通信する。これにより、ＧＵＩ４１１の部分は標準のＨＴＭＬとＪａｖａＳｃｒｉｐｔ（登録商標）のみのノウハウで構築することができる。また、後述するように、応答情報に画像情報等を使うことにより、通常はＨＴＭＬとＪａｖａＳｃｒｉｐｔ（登録商標）のみでは実装することが難しい画像の動的生成処理等もクライアント側で実行することが可能になる。また、サーバ側への通信を抑制することにより通信トラフィックを減らしシステム全体のパフォーマンスを向上させることも可能になる。最近ではＡＪＡＸ（Ａｓｙｎｃｈｒｏｎｏｕｓ・ＪａｖａＳｃｒｉｐｔ＋ＸＭＬ）等の普及により動的な処理をクライアント側で動くスクリプト言語で実装する例も増えてきているが、処理が複雑になればなるほどスクリプトが肥大化し、保守等の面で課題が多い。これに対し、本実施の形態では、スクリプトを規模が小さくて済むため、保守等が行いやすくなる。

以下、具体的な動作について説明する。

端末装置２００の入力部２１４は、ユーザが入力装置２５３を操作してウェブサービスページ４０１のＧＵＩ４１１（表示部２１２によりウェブサービスページ４０１が表示されているウェブブラウザ２０１の画面）に入力する入力データ（例えば、キーボード９０２のキー入力、マウス９０３のクリックやポインタの移動）を受け付ける。端末装置２００の第２通信部２１５は、実行部２１３によりウェブブラウザ２０１で実行されているウェブサービスアプレット４２１へ、入力部２１４により受け付けられた入力データを含むＨＴＴＰリクエストをウェブブラウザ２０１によって送信する。

ウェブサービスアプレット４２１は、ウェブブラウザ２０１から、ウェブブラウザ２０１の画面に表示されているウェブサービスページ４０１のＧＵＩ４１１に対する入力データを含むＨＴＴＰリクエストを受信する（Ｓ１１１：受信処理）。ウェブサービスアプレット４２１は、Ｓ１１１で受信したＨＴＴＰリクエストに含まれる、ウェブサービスページ４０１のＧＵＩ４１１に対する入力データに応じて所定の処理（例えば、後述するイメージ生成処理）を実行する（Ｓ１１２：実行処理）。ウェブサービスアプレット４２１は、Ｓ１１２で実行した処理の結果に基づいてウェブサービスページ４０１のＧＵＩ４１１を更新するための更新データ（応答情報）を生成する（Ｓ１１３：生成処理）。ウェブサービスアプレット４２１は、ウェブブラウザ２０１へ、Ｓ１１３で生成した更新データを含むＨＴＴＰレスポンスを返信する（Ｓ１１４：返信処理）。

端末装置２００の第２通信部２１５は、ウェブサービスアプレット４２１から返信されたＨＴＴＰレスポンスをウェブブラウザ２０１によって受信する。端末装置２００の更新部２１６は、第２通信部２１５により受信されたＨＴＴＰレスポンスに含まれる更新データに従って、ウェブサービスページ４０１のＧＵＩ４１１（表示部２１２によりウェブブラウザ２０１の画面に表示されているウェブサービスページ４０１）を更新する。

図７において、クライアント側では、データベース３０４の検索や更新の処理等、サーバ側のリソースへのアクセスが必要な処理については、サーバ側と連携して実行する。つまり、ウェブサービスアプレット４２１からウェブサーバ３０１にリクエストを投げて応答を返す。実際にサーバ側にアクセスする必要があるか否かはウェブサービスアプレット４２１の中で判断する。したがって、ＧＵＩ４１１の部分からは、ウェブサービスアプレット４２１のみを使っているのかウェブサーバ３０１やサーバ側アプリケーション３０３も使っているのかを区別する必要はない。以下では、クライアント側がサーバ側と連携する場合、ウェブサービスアプレット４２１とウェブサーバ３０１が通信するものとして説明するが、ウェブサービスアプレット４２１とサーバ側アプリケーション３０３が直接通信しても構わない。また、ウェブサービスアプレット４２１とサーバ側アプリケーション３０３が直接通信する場合、両者間の通信は公開する必要がないため、通信のバイナリ化によって、性能を改善することが可能となる。さらに、この場合、独自の暗号化等を組み込むことも可能になる。例えば、ＳＳＬ（Ｓｅｃｕｒｅ・Ｓｏｃｋｅｔ・Ｌａｙｅｒ）を使うのは冗長だが単純な平文での通信は避けたいという場合等に有効である。

以下、具体的な動作について説明する。

図６の場合と同様に、端末装置２００の入力部２１４は、ユーザが入力装置２５３を操作してウェブサービスページ４０１のＧＵＩ４１１（表示部２１２によりウェブサービスページ４０１が表示されているウェブブラウザ２０１の画面）に入力する入力データ（例えば、キーボード９０２のキー入力、マウス９０３のクリックやポインタの移動）を受け付ける。端末装置２００の第２通信部２１５は、実行部２１３によりウェブブラウザ２０１で実行されているウェブサービスアプレット４２１へ、入力部２１４により受け付けられた入力データを含むＨＴＴＰリクエストをウェブブラウザ２０１によって送信する。

ウェブサービスアプレット４２１は、ウェブブラウザ２０１から、ウェブブラウザ２０１の画面に表示されているウェブサービスページ４０１のＧＵＩ４１１に対する入力データを含むＨＴＴＰリクエストを受信する（Ｓ１２１：受信処理）。ウェブサービスアプレット４２１は、Ｓ１２１で受信したＨＴＴＰリクエストに含まれる、ウェブサービスページ４０１のＧＵＩ４１１に対する入力データに応じて所定の処理（例えば、後述するイメージ生成処理）を実行する（Ｓ１２２：実行処理）。このとき、ウェブサービスアプレット４２１は、その処理を実行するためのデータが不足していないかどうかを判定し、データが不足していると判定した場合には、サーバ装置３００に対し、データ（例えば、後述する地図データ）の要求を含むＨＴＴＰリクエストを送信する。

サーバ装置３００は、データの要求を含むＨＴＴＰリクエストをウェブサーバ３０１によって受信する。サーバ装置３００は、受信したＨＴＴＰリクエストに含まれる要求をサーバ側アプリケーション３０３によって解析し、当該要求に対応するデータをデータベース３０４から抽出する（Ｓ１２３）。そして、サーバ装置３００は、ウェブサービスアプレット４２１に対し、抽出したデータを含むＨＴＴＰレスポンスをウェブサーバ３０１によって送信する（Ｓ１２４）。

ウェブサービスアプレット４２１は、サーバ装置３００から、データを含むＨＴＴＰリクエストを受信すると、受信したデータを利用してＳ１２２で所定の処理を実行する。ウェブサービスアプレット４２１は、Ｓ１２２で実行した処理の結果に基づいてウェブサービスページ４０１のＧＵＩ４１１を更新するための更新データ（応答情報）を生成する（Ｓ１２５：生成処理）。ウェブサービスアプレット４２１は、ウェブブラウザ２０１へ、Ｓ１２５で生成した更新データを含むＨＴＴＰレスポンスを返信する（Ｓ１２６：返信処理）。

図６の場合と同様に、端末装置２００の第２通信部２１５は、ウェブサービスアプレット４２１から返信されたＨＴＴＰレスポンスをウェブブラウザ２０１によって受信する。端末装置２００の更新部２１６は、第２通信部２１５により受信されたＨＴＴＰレスポンスに含まれる更新データに従って、ウェブサービスページ４０１のＧＵＩ４１１（表示部２１２によりウェブブラウザ２０１の画面に表示されているウェブサービスページ４０１）を更新する。

なお、ウェブサービスアプレット４２１は、Ｓ１２２において、処理を実行するためのデータが不足している場合だけでなく、例えば、データベース３０４にデータを登録する場合やデータベース３０４のデータを更新する場合に、サーバ装置３００に対し、その要求を含むＨＴＴＰリクエストを送信してもよい。この場合、サーバ装置３００は、Ｓ１２３において、ＨＴＴＰリクエストに含まれる要求に対応するデータ操作を実行する。

図８は、ウェブサービスアプレット４２１を終了する際の通信システム１００の動作を示す図である。

図８において、ウェブサービスアプレット４２１は通常のアプレットと同様にウェブブラウザ２０１の中で稼動しているため、明示的に終了させなくても、表示している画面を閉じること等により終了処理が実行される。ただし、実際には確保しているサーバ側のリソースを解放する処理やクライアント側で確保しているメモリ等を解放する処理を行うことが望ましい。例えば、ＧＵＩ４１１にて明示的な終了処理を要求するためのボタン等を設けておき、それがユーザによって選択されると、ウェブサービスアプレット４２１は、ＨＴＴＰ通信等に利用していたポートを閉じ、メモリを解放し、ウェブブラウザ２０１に終了通知を行う（Ｓ１３１：終了処理）。

以上説明したように、本実施の形態では、従来のＭＶＣモデルにおいてサーバ側（サーブレット）で実装されているコントロール（Ｃ）の部分を、クライアント側（ウェブサービスアプレット４２１）で実装できる。つまり、下記のようにＭＶＣモデルを構築しているといえる。
・コントロール（Ｃ）：ウェブサービスアプレット４２１で実装する。
・モデル（Ｍ）：データ操作用ＩＦ（インタフェース）としてサーブレット（サーバ側アプリケーション３０３）で実装する。
・ビュー（Ｖ）：ＨＴＭＬとＪａｖａＳｃｒｉｐｔ（登録商標）で実装する。

このように、本実施の形態によれば、ＭＶＣモデルにおけるコントロール（Ｃ）をクライアント側で実装できるため、負荷のかかる処理をサーバ側からクライアント側に分散できる。また、通信処理等にかかる負荷を軽減できる。さらに、本実施の形態によれば、ＭＶＣモデルにおけるビュー（Ｖ）にＨＴＭＬを使っているため、ウェブシステムとの親和性が高いシステムが構築できる。

実施の形態２．
本実施の形態では、実施の形態１をＧＩＳ（地理情報システム）に適用する。本実施の形態では、ウェブサービスアプレット４２１は、ウェブサービスの一例として地図表示サービスを提供する。

ＧＩＳは、地理的位置を手がかりに、位置に関する情報をもったデータ（空間データ）を総合的に管理・加工し、視覚的に表示し、高度な分析や迅速な判断を可能にするシステムである。従来は、
・高価な地図情報を購入する必要がある。
・多量の幾何図形を使用するために高性能な専用端末が必要になる。
といったことから専用性の強いシステムで主に使われていたが、近年、ウェブ上で安価軽量に動作する基盤が整備されていたことにより急速に一般化が進んできている。

図９は、従来のＧＩＳ５０１の動作を示す図である。

図９に示すように、従来のＧＩＳ５０１では、道路や行政区等の情報を全て幾何図形（多角形、多角線、点情報等）として保持しておき業務に合わせて加工、解析するようなパターンで実装していた。したがって、単純に地図をクライアント端末のモニタ上に表示するだけでも以下のような処理をしていた。
（１）表示範囲内にある地図情報（幾何図形）を取得する。
（２）メモリ上に表示するイメージ領域を確保する。
（３）上記で確保したイメージ上に各幾何図形描画ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ・Ｐｒｏｇｒａｍ・Ｉｎｔｅｒｆａｃｅ）を使って取得した地図情報を描画する。
（４）描画したイメージをモニタ上に表示する。

さらに業務システムとして使うためには一般的には以下のような機能も必要になっていた。
・凡例表示機能：業務情報と連動させて行政区や設備を色換え表示する機能である。
・レイヤ表示機能：各幾何図形に論理的な意味をつけてまとめて表示種類や形状を変更する機能である。
・メッシュ分割機能：縮尺に合わせて予め幾何図形を矩形に分割しておき同時に使用する図形数を少なくする機能である。

図１０は、ウェブ上で使われるＧＩＳ５０２の動作を示す図である。

以前は、ＧＩＳ５０２をウェブ上で使う場合は、上記のような複雑な処理をブラウザ（ウェブブラウザ）の標準機能で実装することは難しいため、クライアント拡張型（専用のプラグインやアプレットを使用する）や、図１０に示すようなサーバサイドイメージ生成型（クライアント側の要望に合わせてサーバ側でイメージを動的に生成する）等で実装していた。しかしながら、クライアント拡張型では、プラグインやアプレットの操作画面を用いていたため、ＨＴＭＬだけで作られている画面との親和性が低いという課題があった。特に近年はＤＨＴＭＬ（Ｄｙｎａｍｉｃ・ＨＴＭＬ）＋ＪａｖａＳｃｒｉｐｔ（登録商標）でクライアント側を実装することが主流になってきているため、そこに簡単に組み込めないというのが大きな課題となっていた。また、サーバサイドイメージ生成型では、サーバサイドに負荷がかかるため、ユーザが増えた場合に必要となるサーバ側のリソースが著しく増えるという課題があった。

図１１は、ウェブ上で使われる別のＧＩＳ５０３の動作を示す図である。

図１１に示すように、このＧＩＳ５０３では、以前のＧＩＳ５０２と異なり、単純に地図はあくまでも下図だと割り切ってウェブ上で軽量かつ安価に動くように下記のような方法で実装されている。
（１）地図は下図として予め各縮尺に合わせて静的なイメージファイルとして生成しておく。
（２）クライアント側では縮尺や表示範囲に合わせて単純にイメージを並べて表示する。

上記のように実装することにより、以前のＧＩＳ５０２で負荷がかかっていた動的イメージ生成処理が地図表示時に不要になるため全体の処理を軽量化することができる。また、上記の処理ならば基本的なＤＨＴＭＬの機能でできるためウェブ画面に容易に組み込むことも可能である。さらに、最近のブラウザではイメージを重ねて表示することや簡単なベクトル図であればスクリプトで描画することができるようになったため、地図上に設備を表示するというような簡単な機能であれば十分に使えるようになってきている。しかしながら、下図に静的イメージを使うため用途に応じて任意の図形を動的に非表示にすることや色変えするといった機能やスクリプトで多量の図形（例えば、２万件以上）を描画する等が難しいため、複雑な機能を実現するのは困難である。

図１２から図１６までは、本実施の形態に係るＧＩＳ１０１の動作を示す図である。

ＧＩＳ１０１の構成は、図１に示した実施の形態１に係る通信システム１００の構成と同様である。

図１２において、ＧＩＳ１０１は初期処理を行う。まず、サーバ側からウェブサービスアプレット４２１をダウンロードし、クライアント側のウェブブラウザ２０１内で動かす。ウェブサービスアプレット４２１は、任意のポートを開いて地図表示サービスを開始する。サーバサイドからウェブサービスアプレット４２１のモジュール（実体ファイル３０２）をダウンロードして動かす処理には通常のプラグインやアプレットと同様の機能を利用できる。なお、地図表示サービスが立ち上がっているか等を事前に検知するような仕組みを設けてもよい。

以下、具体的な動作について説明する。

端末装置２００は、ウェブブラウザ２０１を処理装置２５１により実行しており、ウェブブラウザ２０１の画面にメニュー画面４０４（ウェブサービスページ４０１へのリンクをメニューの一部として表示するウェブページ）を表示する。例えばユーザがマウス９０３等のポインティングデバイス（入力装置２５３の一例）を操作して、ウェブサービスページ４０１へのリンクを選択すると、端末装置２００の第１通信部２１１は、サーバ装置３００に対し、ウェブサービスページ４０１の要求を含むＨＴＴＰリクエストをウェブブラウザ２０１によって送信する。

サーバ装置３００は、ウェブサービスページ４０１の要求を含むＨＴＴＰリクエストをウェブサーバ３０１によって受信する。サーバ装置３００は、受信したＨＴＴＰリクエストに含まれる要求を、サーバ側アプリケーション３０３に実装される地図データ取得ＩＦ３０５によって解析し、ウェブサービスページ４０１を生成する。そして、サーバ装置３００は、端末装置２００に対し、ウェブサービスページ４０１を含むＨＴＴＰレスポンスをウェブサーバ３０１によって送信する。

端末装置２００の第１通信部２１１は、ウェブサービスページ４０１を含むＨＴＴＰレスポンスをウェブブラウザ２０１によって受信する。続けて、端末装置２００の第１通信部２１１は、サーバ装置３００に対し、ウェブサービスページ４０１に埋め込まれているウェブサービスアプレット４２１を起動するため、ウェブサービスアプレット４２１の実体ファイル３０２の要求を含むＨＴＴＰリクエストをウェブブラウザ２０１によって送信する。

サーバ装置３００は、ウェブサービスアプレット４２１の実体ファイル３０２の要求を含むＨＴＴＰリクエストをウェブサーバ３０１によって受信する。サーバ装置３００は、受信したＨＴＴＰリクエストに含まれる要求をサーバ側アプリケーション３０３によって解析し、ウェブサービスアプレット４２１の実体ファイル３０２を含むＨＴＴＰレスポンスをウェブサーバ３０１によって送信する。

端末装置２００の第１通信部２１１は、ウェブサービスアプレット４２１の実体ファイル３０２を含むＨＴＴＰレスポンスをウェブブラウザ２０１によって受信する。端末装置２００の実行部２１３は、第１通信部２１１により受信されたＨＴＴＰレスポンスに含まれるウェブサービスアプレット４２１の実体ファイル３０２を展開してウェブサービスアプレット４２１をウェブブラウザ２０１で起動する。

ウェブサービスアプレット４２１は、ウェブブラウザ２０１上で起動されると、地図表示サービスを起動する（起動処理）。

端末装置２００の表示部２１２は、第１通信部２１１により受信されたＨＴＴＰレスポンスに含まれるウェブサービスページ４０１のＧＵＩ４１１をウェブブラウザ２０１の画面に地図表示画面４０５（ＨＴＭＬ＋スクリプト）として表示する。この時点では、まだウェブサービスアプレット４２１が起動されただけであるため、地図表示画面４０５には地図のイメージ（画像）が表示されていない。

図１３において、ＧＩＳ１０１は地図表示（初期表示）処理を行う。地図表示画面４０５では、以前のＧＩＳ５０２や別のＧＩＳ５０３でサーバ側にリクエストを送るようにウェブサービスアプレット４２１に対して、縮尺、表示座標、表示範囲の情報を含むＨＴＴＰのリクエストを送信する。リクエストを受けたウェブサービスアプレット４２１はサーバ側に、縮尺、表示座標、表示範囲の情報を含むＨＴＴＰのリクエストを送信する。ウェブサービスアプレット４２１からリクエストを受けたサーバ側アプリケーション３０３は、データベース３０４に蓄積されている地図データ３０６（ベクトル）のうち、描画に必要な地図データ３０６を取得し、ウェブサービスアプレット４２１にＨＴＴＰのレスポンスとして送信する。サーバ側アプリケーション３０３から地図データ３０６をレスポンスとして受けたウェブサービスアプレット４２１は、受信した地図データ３０６をメモリ（記憶装置２５２の一例）内にキャッシュした後、イメージを生成し、ＨＴＴＰのレスポンスとして地図表示画面４０５側に返す。地図表示画面４０５では受け取ったイメージの位置やサイズを調整して表示する。

以下、具体的な動作について説明する。

端末装置２００の第２通信部２１５は、地図のイメージを地図表示画面４０５に表示するため、実行部２１３によりウェブブラウザ２０１で実行されているウェブサービスアプレット４２１へ、地図の初期イメージの要求を含むＨＴＴＰリクエストをウェブブラウザ２０１によって送信する。

ウェブサービスアプレット４２１は、ウェブブラウザ２０１から、地図の初期イメージの要求を含むＨＴＴＰリクエストを受信する（受信処理）。ウェブサービスアプレット４２１は、地図の初期イメージを地図表示画面４０５に表示するために必要な地図データ３０６を保持していないため、地図データ３０６が不足していると判定する。そして、ウェブサービスアプレット４２１は、サーバ装置３００に対し、地図データ３０６の要求を含むＨＴＴＰリクエストを送信する。

サーバ装置３００は、地図データ３０６の要求を含むＨＴＴＰリクエストをウェブサーバ３０１によって受信する。サーバ装置３００は、受信したＨＴＴＰリクエストに含まれる要求をサーバ側アプリケーション３０３の地図データ取得ＩＦ３０５によって解析し、地図データ３０６をデータベース３０４から抽出する。そして、サーバ装置３００は、ウェブサービスアプレット４２１に対し、抽出した地図データ３０６を含むＨＴＴＰレスポンスをウェブサーバ３０１によって送信する。

ウェブサービスアプレット４２１は、サーバ装置３００から、地図データ３０６を含むＨＴＴＰリクエストを受信すると、受信したＨＴＴＰリクエストから地図データ３０６を取得する。ウェブサービスアプレット４２１は、取得した地図データ３０６を利用して、ユーザにより指定された、あるいは、デフォルトの緯度経度、縮尺、表示サイズ等（ユーザにより指定される場合は、受信処理で、緯度経度、縮尺、表示サイズ等を入力データとして含むＨＴＴＰリクエストを受信する）に適合する地図のイメージを生成する。即ち、所定の処理の一例として、イメージ生成処理を実行する（実行処理）。ウェブサービスアプレット４２１は、生成したイメージ（イメージ生成処理の結果）を、ＧＩＦ（Ｇｒａｐｈｉｃｓ・Ｉｎｔｅｒｃｈａｎｇｅ・Ｆｏｒｍａｔ）、ＪＰＥＧ（Ｊｏｉｎｔ・Ｐｈｏｔｏｇｒａｐｈｉｃ・Ｅｘｐｅｒｔｓ・Ｇｒｏｕｐ）、ＰＮＧ（Ｐｏｒｔａｂｌｅ・Ｎｅｔｗｏｒｋ・Ｇｒａｐｈｉｃｓ）といった任意の形式に変換し、更新データとする（生成処理）。ウェブサービスアプレット４２１は、ウェブブラウザ２０１へ、生成した更新データを含むＨＴＴＰレスポンスを返信する（返信処理）。

端末装置２００の第２通信部２１５は、ウェブサービスアプレット４２１から返信されたＨＴＴＰレスポンスをウェブブラウザ２０１によって受信する。端末装置２００の更新部２１６は、第２通信部２１５により受信されたＨＴＴＰレスポンスに含まれる更新データから地図の初期イメージを取得して地図表示画面４０５に表示する。

図１４において、ＧＩＳ１０１は地図表示（拡大縮小、スクロール）処理を行う。地図表示画面４０５では、以前のＧＩＳ５０２や別のＧＩＳ５０３でサーバ側にリクエストを送るようにウェブサービスアプレット４２１に対して、拡大縮小、スクロール後の縮尺、表示座標、表示範囲の情報を含むＨＴＴＰのリクエストを送信する。リクエストを受けたウェブサービスアプレット４２１はキャッシュしている地図データ３０６を確認し、足りなかった場合はサーバ側に、縮尺、表示座標、表示範囲の情報を含むＨＴＴＰのリクエストを送信し、地図データ３０６（ベクトル）を取得した後、イメージを生成し、ＨＴＴＰのレスポンスとして地図表示画面４０５側に返す。地図表示画面４０５では受け取ったイメージの位置やサイズを調整して表示する。なお、ウェブサービスアプレット４２１は、メモリ使用量に合わせてキャッシュした情報を破棄したり、連続する領域の情報を操作パターンに合わせて先読みしたりする等の制御をしてもよい。

以下、ウェブサービスアプレット４２１にて地図データ３０６が不足していた場合の具体的な動作について説明する。

端末装置２００の入力部２１４は、ユーザがマウス９０３等のポインティングデバイス（入力装置２５３の一例）を操作して地図表示画面４０５に表示されているスクロールバー等を動かすと、スクロールバー等が動かされた方向や量を示す入力データを受け付ける。端末装置２００の第２通信部２１５は、実行部２１３によりウェブブラウザ２０１で実行されているウェブサービスアプレット４２１へ、入力部２１４により受け付けられた入力データを含むＨＴＴＰリクエストをウェブブラウザ２０１によって送信する。

ウェブサービスアプレット４２１は、ウェブブラウザ２０１から、スクロールバー等が動かされた方向や量を示す入力データを含むＨＴＴＰリクエストを受信する（受信処理）。ウェブサービスアプレット４２１は、受信したＨＴＴＰリクエストに含まれる入力データから、地図のイメージを拡大縮小あるいはスクロールする方向や量を特定し、そのための地図データ３０６が不足していないかどうかを判定する。地図データ３０６が不足していると判定した場合には、ウェブサービスアプレット４２１は、サーバ装置３００に対し、地図データ３０６の要求を含むＨＴＴＰリクエストを送信する。

サーバ装置３００は、地図データ３０６の要求を含むＨＴＴＰリクエストをウェブサーバ３０１によって受信する。サーバ装置３００は、受信したＨＴＴＰリクエストに含まれる要求をサーバ側アプリケーション３０３の地図データ取得ＩＦ３０５によって解析し、地図データ３０６をデータベース３０４から抽出する。そして、サーバ装置３００は、ウェブサービスアプレット４２１に対し、抽出した地図データ３０６を含むＨＴＴＰレスポンスをウェブサーバ３０１によって送信する。

ウェブサービスアプレット４２１は、サーバ装置３００から、地図データ３０６を含むＨＴＴＰリクエストを受信すると、受信したＨＴＴＰリクエストから地図データ３０６を取得する。ウェブサービスアプレット４２１は、取得した地図データ３０６を利用して、入力データに応じて拡大縮小あるいはスクロールした後の地図のイメージを生成する。即ち、所定の処理の一例として、イメージ生成処理を実行する（実行処理）。ウェブサービスアプレット４２１は、生成したイメージ（イメージ生成処理の結果）を、ＧＩＦ、ＪＰＥＧ、ＰＮＧといった任意の形式に変換し、更新データとする（生成処理）。ウェブサービスアプレット４２１は、ウェブブラウザ２０１へ、生成した更新データを含むＨＴＴＰレスポンスを返信する（返信処理）。

端末装置２００の第２通信部２１５は、ウェブサービスアプレット４２１から返信されたＨＴＴＰレスポンスをウェブブラウザ２０１によって受信する。端末装置２００の更新部２１６は、第２通信部２１５により受信されたＨＴＴＰレスポンスに含まれる更新データから地図のイメージを取得し、地図表示画面４０５に現在表示しているイメージを、取得したイメージに切り替える。

以下、ウェブサービスアプレット４２１にて地図データ３０６が足りていた場合の具体的な動作について説明する。

ウェブサービスアプレット４２１が、受信したＨＴＴＰリクエストに含まれる入力データから、地図のイメージを拡大縮小あるいはスクロールする方向や量を特定し、そのための地図データ３０６が不足していないかどうかを判定するまでの動作は、上記と同様である。地図データ３０６が足りていると判定した場合には、ウェブサービスアプレット４２１は、保持している地図データ３０６を利用して、入力データに応じて拡大縮小あるいはスクロールした後の地図のイメージを生成する。即ち、所定の処理の一例として、イメージ生成処理を実行する（実行処理）。これ以降の動作も、上記と同様である。

図１５において、ＧＩＳ１０１はレイヤ処理（表示内容切替処理）を行う。地図表示画面４０５では、以前のＧＩＳ５０２や別のＧＩＳ５０３でサーバ側にリクエストを送るようにウェブサービスアプレット４２１に対して、任意の図形の表示、非表示を切り替える要求を含むＨＴＴＰのリクエストを送信する。リクエストを受けたウェブサービスアプレット４２１は、要求に合わせてイメージを作り直しＨＴＴＰのレスポンスとして地図表示画面４０５側に返す。地図表示画面４０５では受け取ったイメージの位置やサイズを調整して表示する。なお、地図データ３０６の読み込みをレイヤ単位に分割している場合等は、ウェブサービスアプレット４２１はサーバ側から地図データ３０６を取り出す必要がある。

具体的な動作については、図１４の場合と同様である。

図１６において、ＧＩＳ１０１は図形選択処理を行う。地図表示画面４０５では、以前のＧＩＳ５０２や別のＧＩＳ５０３でサーバ側にリクエストを送るようにウェブサービスアプレット４２１に対して、任意の位置でマウスポインタの移動あるいはマウスクリック等のイベントが発生したことを通知するＨＴＴＰのリクエストを送信する。リクエストを受けたウェブサービスアプレット４２１は、通知された位置に、イベントに応じてシンボルを表示すべき図形（例えば、ランドマーク、建物、鉄塔）がないか確認し、あった場合はその図形の描画情報とキー情報（ランドマーク、建物、鉄塔等のＩＤ、住所コード等）を地図表示画面４０５側に戻す。地図表示画面４０５では受け取った情報を基に、対応する位置にシンボルをスクリプトで描画する等の処理を実行する。例えば、建物Ａ〜Ｚが地図のイメージ上で黒い点として表示されており、いずれか建物の位置にマウス９０３のポインタが移動した（あるいは、その位置でマウス９０３がクリックされた）場合には点の色を赤色に切り替えることが定義されていたとする。建物Ａの位置にポインタが移動すると（あるいは、その位置がクリックされると）、地図表示画面４０５では、その位置を通知するＨＴＴＰリクエストがウェブサービスアプレット４２１に送信される。ウェブサービスアプレット４２１は、ＨＴＴＰリクエストにより通知された位置が建物Ａの位置であることを検知すると、その位置が建物であることを通知するＨＴＴＰレスポンスを地図表示画面４０５に返す。地図表示画面４０５では、これに応じて、地図のイメージ上にてポインタが移動した位置（クリックされた位置）に赤い点のシンボルを描画する処理をスクリプトで実行する。あるいは、ウェブサービスアプレット４２１は、ＨＴＴＰリクエストにより通知された位置が建物Ａの位置であることを検知すると、その位置に赤い点のシンボルを描画するように指示するＨＴＴＰレスポンスを地図表示画面４０５に返す。地図表示画面４０５では、地図のイメージにてポインタが移動した位置（クリックされた位置）に、ＨＴＴＰレスポンスにより指示されたシンボルを描画する処理をスクリプトで実行する。ここでは、どのような図形（例えば、ランドマーク、建物、鉄塔）を検知し、検知した図形に対してどのような処理（例えば、色を換える、あるいは、付加情報を表示する）を施すかを予めウェブサービスアプレット４２１が把握しているものとする。

以下、具体的な動作について説明する。

端末装置２００の表示部２１２は、マウス９０３等のポインティングデバイス（入力装置２５３の一例）のポインタを地図表示画面４０５に表示する。端末装置２００の入力部２１４は、ユーザがポインティングデバイスを操作して地図表示画面４０５に表示されているポインタを移動させる度に、移動したポインタの位置を特定する位置データを入力データとして受け付ける。端末装置２００の第２通信部２１５は、入力部２１４により位置データが受け付けられる度に、実行部２１３によりウェブブラウザ２０１で実行されているウェブサービスアプレット４２１へ、入力部２１４により受け付けられた位置データを含むＨＴＴＰリクエストをウェブブラウザ２０１によって送信する。

ウェブサービスアプレット４２１は、ウェブブラウザ２０１から、位置データを含むＨＴＴＰリクエストを受信する（受信処理）。ウェブサービスアプレット４２１は、受信したＨＴＴＰリクエストに含まれる位置データで特定される位置が地図のイメージ上で予め決められた地点に一致するか否かを判定する。即ち、所定の処理の一例として、判定処理を実行する（実行処理）。ウェブサービスアプレット４２１は、一致すると判定した場合、当該地点の表示内容を所定の内容に変更することを指示する指示データを更新データとして生成する（生成処理）。前述した例であれば、ウェブサービスアプレット４２１は、位置データで特定される位置が建物Ａのある地点に一致すると判定した場合、その地点に赤い点のシンボルを描画することを指示する指示データを生成する（生成処理）。あるいは、その地点に赤い点を描画したイメージを生成し、生成したイメージを、ＧＩＦ、ＪＰＥＧ、ＰＮＧといった任意の形式に変換し、更新データとする（生成処理）。ウェブサービスアプレット４２１は、ウェブブラウザ２０１へ、生成した指示データ（更新データ）を含むＨＴＴＰレスポンスを返信する（返信処理）。

端末装置２００の第２通信部２１５は、ウェブサービスアプレット４２１から返信されたＨＴＴＰレスポンスをウェブブラウザ２０１によって受信する。端末装置２００の更新部２１６は、第２通信部２１５により受信されたＨＴＴＰレスポンスに含まれる指示データに従って、地図のイメージ上にシンボルを描画する。あるいは、端末装置２００の更新部２１６は、第２通信部２１５により受信されたＨＴＴＰレスポンスに含まれる更新データから地図のイメージを取得し、地図表示画面４０５に現在表示しているイメージを、取得したイメージに切り替える。

以上説明したように、本実施の形態は、以前のＧＩＳ５０２（クライアント拡張型）と比較すると、画面自体を基本的なＤＨＴＭＬで作れるため、同様にＤＨＴＭＬで作られている業務画面に簡単に組み込むことができるという効果を奏する。また、本実施の形態は、以前のＧＩＳ５０２（サーバサイドイメージ生成型）と比較すると、最もリソースを消費するイメージの動的生成処理をクライアント側で動かせるため、多数のユーザから接続されてもリソースを充分に確保できるという効果を奏する。また、本実施の形態は、別のＧＩＳ５０３と比較すると、イメージを動的に生成できるため任意の図形の表示を切り替える等の処理が容易に実装できるという効果を奏する。また、イベントを検知させる図形等をメモリ上に保持することにより多量のデータでも取り扱うことができるという効果を奏する。

以下、図１７及び図１８を用いて、さらに、本実施の形態をＧＩＳ５０３と比較する。

例えば、地図表示（初期表示）処理を行う場合、図１７に示すように、ＧＩＳ５０３では、ブラウザがウェブサーバに対して地図の初期イメージを要求し、ウェブサーバから地図の初期イメージを取得する。ブラウザは、取得した地図の初期イメージを画面に表示する。イメージ上でランドマーク等（ポインタが重なると予め決められたシンボルデータが描画される地点）は黒い点で表されているものとする。

一方、図１８に示すように、本実施の形態に係るＧＩＳ１０１では、ウェブブラウザ２０１がウェブサービスアプレット４２１に対して地図の初期イメージを要求する。ウェブサービスアプレット４２１は、ウェブブラウザ２０１から地図の初期イメージが要求されると、ウェブサーバ３０１に対して地図データ３０６及びシンボルデータを要求し、ウェブサーバ３０１から地図データ３０６及びシンボルデータを取得する。ウェブサービスアプレット４２１は、取得した地図データ３０６を用いて地図の初期イメージを生成するとともに、シンボルデータを保持しておく。そして、生成した地図の初期イメージをウェブブラウザ２０１に返す。ウェブブラウザ２０１は、ウェブサービスアプレット４２１から地図の初期イメージを取得し、取得した地図の初期イメージを画面に表示する。前述したように、イメージ上でランドマーク等（ポインタが重なると予め決められたシンボルデータが描画される地点）は黒い点で表されているものとする。

地図表示（初期表示）処理の後、例えば、図形選択処理を行う場合、図１７に示すように、ＧＩＳ５０３では、ユーザがマウス９０３等によりブラウザの画面上でポインタを移動させる度に、ブラウザがウェブサーバに対して移動後のポインタのＸＹ座標をイベントデータとして通知する。ウェブサーバは、ブラウザからイベントデータを受け取る度に、そこで示されたポインタのＸＹ座標に相当する位置にランドマーク等があるかどうかを判定する。そして、ウェブサーバは、その位置にランドマーク等があると判定した場合、その位置に描画するシンボルデータをブラウザに返す。ブラウザは、ウェブサーバからシンボルデータを受け取って、ポインタが移動した位置、即ち、ランドマーク等の位置に、そのシンボルデータを描画する。このように、ポインタが移動する度にクライアントとサーバとの間で通信が発生すると、負荷が著しく増大し、システムの性能が大幅に劣化することが予想される。なお、ＸＹ座標とランドマーク等の位置との対応関係を全てスクリプトに記述してしまえば、ポインタが移動する度にクライアントとサーバとの間で通信を行う必要はなくなる。しかしながら、ランドマーク等の数が膨大になると、スクリプトが大規模かつ複雑になり、不具合等を引き起こす要因となったり、保守作業が困難になったりする。また、動作しなくなる可能性もある。

一方、図１８に示すように、本実施の形態に係るＧＩＳ１０１では、ユーザがマウス９０３等によりブラウザの画面上でポインタを移動させる度に、ウェブブラウザ２０１が同じクライアント上のウェブサービスアプレット４２１に対して移動後のポインタのＸＹ座標をイベントデータとして通知する。ウェブサービスアプレット４２１は、ウェブブラウザ２０１からイベントデータを受け取る度に、そこで示されたポインタのＸＹ座標に相当する位置にランドマーク等があるかどうかを判定する。そして、ウェブサービスアプレット４２１は、その位置にランドマーク等があると判定した場合、現在の地図のイメージ上で当該位置にシンボルデータを描画した地図の更新イメージを生成する。そして、生成した地図の更新イメージをウェブブラウザ２０１に返す。ウェブブラウザ２０１は、ウェブサービスアプレット４２１から地図の更新イメージを取得し、取得した地図の更新イメージを画面に表示する。あるいは、ウェブサービスアプレット４２１は、ランドマーク等があると判定した場合、その位置に描画するシンボルデータをウェブブラウザ２０１に返す。ウェブブラウザ２０１は、ウェブサービスアプレット４２１からシンボルデータを取得し、ポインタが移動した位置、即ち、ランドマーク等の位置に、そのシンボルデータを描画する。このように、本実施の形態では、ポインタが移動する度にクライアントとサーバとの間で通信が発生するのではなく、クライアント上で処理を行うことが可能なため、負荷が軽減でき、システムの性能が向上する。

本実施の形態では、ウェブサービスアプレット４２１は、地図表示サービスを提供するが、その他のウェブサービスを提供してもよい。その他のウェブサービスとしては、例えば、オンラインゲームやオンライン会議等のサービスが考えられる。

１００ 通信システム、１０１ ＧＩＳ、２００ 端末装置、２０１ ウェブブラウザ、２１１ 第１通信部、２１２ 表示部、２１３ 実行部、２１４ 入力部、２１５ 第２通信部、２５１ 処理装置、２５２ 記憶装置、２５３ 入力装置、２５４ 出力装置、３００ サーバ装置、３０１ ウェブサーバ、３０２ 実体ファイル、３０３ サーバ側アプリケーション、３０４ データベース、３０５ 地図データ取得ＩＦ、３０６ 地図データ、４００ インターネット、４０１ ウェブサービスページ、４０２，４０３ 任意ページ、４０４ メニュー画面、４０５ 地図表示画面、４１１ ＧＵＩ、４２１ ウェブサービスアプレット、５０１，５０２，５０３ ＧＩＳ、９０１ ＬＣＤ、９０２ キーボード、９０３ マウス、９０４ ＦＤＤ、９０５ ＣＤＤ、９０６ プリンタ、９１１ ＣＰＵ、９１２ バス、９１３ ＲＯＭ、９１４ ＲＡＭ、９１５ 通信ボード、９２０ ＨＤＤ、９２１ オペレーティングシステム、９２２ ウィンドウシステム、９２３ プログラム群、９２４ ファイル群。

Claims (6)

1. ウェブブラウザを処理装置により実行する端末装置において、
   ウェブページを提供するサーバ装置であって、前記ウェブページに対する入力データを受信すると、受信した入力データに応じて所定の処理を実行し、実行した処理の結果に基づいて前記ウェブページを更新するための更新データを生成し、生成した更新データを返信するアプレットを保持するサーバ装置から、前記ウェブページと前記アプレットとを前記ウェブブラウザによって受信する第１通信部と、
   前記第１通信部により受信されたウェブページを前記ウェブブラウザの画面に表示する表示部と、
   前記第１通信部により受信されたアプレットを前記ウェブブラウザで実行する実行部と、
   ユーザが入力装置を操作して前記表示部により前記ウェブページが表示されている前記ウェブブラウザの画面に入力する入力データを受け付ける入力部と、
   前記実行部により前記ウェブブラウザで実行されているアプレットへ、前記入力部により受け付けられた入力データを前記ウェブブラウザによって送信し、当該アプレットから返信される更新データを前記ウェブブラウザによって受信する第２通信部と、
   前記第２通信部により受信された更新データに従って、前記表示部により前記ウェブブラウザの画面に表示されているウェブページを更新する更新部とを備えることを特徴とする端末装置。
2. 前記アプレットは、前記所定の処理を実行する際に、前記所定の処理を実行するためのデータが不足している場合、前記サーバ装置から当該データを受信し、受信したデータを用いて前記所定の処理を実行することを特徴とする請求項１に記載の端末装置。
3. 前記入力装置は、ポインティングデバイスであり、
   前記表示部は、前記ポインティングデバイスのポインタを前記ウェブブラウザの画面に表示し、
   前記入力部は、前記ユーザが前記ポインティングデバイスを操作して前記表示部により前記ウェブブラウザの画面に表示されているポインタを移動させる度に、移動したポインタの位置を特定する位置データを前記入力データとして受け付け、
   前記第２通信部は、前記入力部により前記位置データが受け付けられる度に、前記実行部により前記ウェブブラウザで実行されているアプレットへ、当該位置データを前記ウェブブラウザによって送信し、当該アプレットから返信される更新データを前記ウェブブラウザによって受信することを特徴とする請求項１又は２に記載の端末装置。
4. 前記ウェブページは、地図を表示するページであり、
   前記アプレットは、前記位置データを受信すると、受信した位置データで特定される位置が前記地図上で予め決められた地点に一致するか否かを判定する処理を前記所定の処理として実行し、一致すると判定した場合、当該地点の表示内容を所定の内容に変更することを指示する指示データを前記更新データとして生成することを特徴とする請求項３に記載の端末装置。
5. 前記第２通信部は、前記実行部により前記ウェブブラウザで実行されているアプレットへ、前記入力部により受け付けられた入力データを含むＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ・Ｔｒａｎｓｆｅｒ・Ｐｒｏｔｏｃｏｌ）リクエストを前記ウェブブラウザによって送信し、当該アプレットから返信される更新データを含むＨＴＴＰレスポンスを前記ウェブブラウザによって受信することを特徴とする請求項１から４までのいずれかに記載の端末装置。
6. コンピュータにより実行されるウェブブラウザで動作するアプレットであるプログラムにおいて、
   前記ウェブブラウザから、前記ウェブブラウザの画面に表示されるウェブページに対する入力データを受信する受信処理と、
   前記受信処理が受信した入力データに応じて所定の処理を実行する実行処理と、
   前記実行処理が実行した処理の結果に基づいて前記ウェブページを更新するための更新データを生成する生成処理と、
   前記ウェブブラウザへ、前記生成処理が生成した更新データを返信する返信処理とをコンピュータに実行させることを特徴とするプログラム。

Images