以下、本発明の実施の形態について、図を用いて説明する。
実施の形態1.
図1は、本実施の形態に係る通信システム100の構成を示すブロック図である。
図1において、通信システム100は、端末装置200(「クライアント」ともいう)、サーバ装置300(単に「サーバ」ともいう)を備える。端末装置200、サーバ装置300は、それぞれが複数存在していてもよい。端末装置200とサーバ装置300は、インターネット400を介して互いに任意の方式で通信を行う。
端末装置200は、ウェブブラウザ201を実行する。ウェブブラウザ201は、ウェブページを画面に表示してユーザに閲覧させるアプリケーションソフトウェアである。サーバ装置300は、ウェブサーバ301を実行する。ウェブサーバ301は、ウェブページを提供するサーバソフトウェアである。サーバ装置300は、アプレットを保持しており、ウェブサーバ301は、アプレットを含むウェブページを提供することも可能である。ウェブブラウザ201は、ウェブページにアプレットが含まれている場合、ウェブページを画面に表示する際に、そのアプレットを実行する。アプレットは、通常のアプリケーションプログラムと異なり、ウェブブラウザ201上でのみ動作するプログラム(ここでは、プラグインも含むものとする)である。アプレットの代表例としては、Java(登録商標)アプレットが挙げられる。
端末装置200とサーバ装置300は、それぞれウェブブラウザ201とウェブサーバ301を利用して、インターネット400を介して互いにHTTP(HyperText・Transfer・Protocol)通信を行う。例えば、端末装置200は、サーバ装置300に対して、HTTPリクエストをウェブブラウザ201により送信してウェブページを要求する。サーバ装置300は、端末装置200から送信されたHTTPリクエストをウェブサーバ301により受信すると、受信したHTTPリクエストで要求されたウェブページのHTML(HyperText・Markup・Language)文書等のデータを含むHTTPレスポンスをウェブサーバ301により返信する。端末装置200は、サーバ装置300から送信されたHTTPレスポンスをウェブブラウザ201により受信すると、受信したHTTPレスポンスに含まれるデータを用いてウェブページをウェブブラウザ201の画面(ウィンドウ、フレーム、ダイアログ等)に表示する。
本実施の形態では、端末装置200は、ウェブブラウザ201によって、ウェブサービスページ401をサーバ装置300へ要求する。ウェブサービスページ401は、ウェブブラウザ201の画面に表示されるGUI411(Graphical・User・Interface)の部分と、ウェブブラウザ201で動作するウェブサービスアプレット421の部分とを含むウェブページである。GUI411は、例えば、JavaScript(登録商標)やHTMLで構成される。ウェブサービスアプレット421は、従来のウェブ3階層モデルにおけるウェブサーバ301と同様に、ウェブブラウザ201に対してウェブサービスを提供するアプレットである。
サーバ装置300は、ウェブサービスアプレット421の実体ファイル302を記憶装置に保持している。なお、ウェブサービスアプレット421がJava(登録商標)アプレットであれば、実体ファイル302は例えばJAR(Java・ARchive)ファイルとして保持されることになる。また、サーバ装置300は、従来のウェブ3階層モデルと同様に、サーバ側アプリケーション303(アプリケーションサーバ)やデータベース304を有している。サーバ装置300は、端末装置200からウェブサービスページ401が要求されると、サーバ側アプリケーション303によって、ウェブサービスページ401を生成し、ウェブサーバ301によって、ウェブサービスページ401を端末装置200へ送信する。また、サーバ装置300は、ウェブサーバ301によって、ウェブサービスアプレット421の実体ファイル302を端末装置200へ送信する。
端末装置200は、ウェブブラウザ201によって、ウェブサービスページ401とウェブサービスアプレット421の実体ファイル302とをサーバ装置300から受信すると、ウェブサービスページ401のGUI411の部分をウェブブラウザ201の画面に表示するとともに、ウェブブラウザ201によって、ウェブサービスアプレット421を実行する。
図2は、端末装置200の構成を示すブロック図である。
図2において、端末装置200は、第1通信部211、表示部212、実行部213、入力部214、第2通信部215を備える。各部の動作については後述する。
また、端末装置200は、処理装置251、記憶装置252、入力装置253、出力装置254等のハードウェアを備える。ハードウェアは端末装置200の各部によって利用される。例えば、処理装置251は、端末装置200の各部でデータや情報の演算、加工、読み取り、書き込み等を行うために利用される。記憶装置252は、そのデータや情報を記憶するために利用される。また、入力装置253は、そのデータや情報を入力するために、出力装置254は、そのデータや情報を出力するために利用される。
図3は、端末装置200のハードウェア構成の一例を示す図である。
図3において、端末装置200は、コンピュータであり、LCD901(Liquid・Crystal・Display)、キーボード902(K/B)、マウス903、FDD904(Flexible・Disk・Drive)、CDD905(Compact・Disc・Drive)、プリンタ906といったハードウェアデバイスを備えている。これらのハードウェアデバイスはケーブルや信号線で接続されている。LCD901の代わりに、CRT(Cathode・Ray・Tube)、あるいは、その他の表示装置が用いられてもよい。マウス903の代わりに、タッチパネル、タッチパッド、トラックボール、ペンタブレット、あるいは、その他のポインティングデバイスが用いられてもよい。
端末装置200は、プログラムを実行するCPU911(Central・Processing・Unit)を備えている。CPU911は、処理装置251の一例である。CPU911は、バス912を介してROM913(Read・Only・Memory)、RAM914(Random・Access・Memory)、通信ボード915、LCD901、キーボード902、マウス903、FDD904、CDD905、プリンタ906、HDD920(Hard・Disk・Drive)と接続され、これらのハードウェアデバイスを制御する。HDD920の代わりに、フラッシュメモリ、光ディスク装置、メモリカードリーダライタ又はその他の記憶媒体が用いられてもよい。
RAM914は、揮発性メモリの一例である。ROM913、FDD904、CDD905、HDD920は、不揮発性メモリの一例である。これらは、記憶装置252の一例である。通信ボード915、キーボード902、マウス903、FDD904、CDD905は、入力装置253の一例である。また、通信ボード915、LCD901、プリンタ906は、出力装置254の一例である。
通信ボード915は、LAN(Local・Area・Network)を介して、インターネット400に接続されている。通信ボード915は、LANに限らず、IP−VPN(Internet・Protocol・Virtual・Private・Network)、広域LAN、ATM(Asynchronous・Transfer・Mode)ネットワークといったWAN(Wide・Area・Network)を介して、インターネット400に接続されていても構わない。
HDD920には、オペレーティングシステム921(OS)、ウィンドウシステム922、プログラム群923、ファイル群924が記憶されている。プログラム群923のプログラムは、CPU911、オペレーティングシステム921、ウィンドウシステム922により実行される。プログラム群923には、本実施の形態の説明において「〜部」として説明する機能を実行するプログラムが含まれている。プログラムは、CPU911により読み出され実行される。ファイル群924には、本実施の形態の説明において、「〜データ」、「〜情報」、「〜ID(識別子)」、「〜フラグ」、「〜結果」として説明するデータや情報や信号値や変数値やパラメータが、「〜ファイル」や「〜データベース」や「〜テーブル」の各項目として含まれている。「〜ファイル」や「〜データベース」や「〜テーブル」は、RAM914やHDD920等の記憶媒体に記憶される。RAM914やHDD920等の記憶媒体に記憶されたデータや情報や信号値や変数値やパラメータは、読み書き回路を介してCPU911によりメインメモリやキャッシュメモリに読み出され、抽出、検索、参照、比較、演算、計算、制御、出力、印刷、表示といったCPU911の処理(動作)に用いられる。抽出、検索、参照、比較、演算、計算、制御、出力、印刷、表示といったCPU911の処理中、データや情報や信号値や変数値やパラメータは、メインメモリやキャッシュメモリやバッファメモリに一時的に記憶される。
本実施の形態の説明において用いるブロック図やフローチャートの矢印の部分は主としてデータや信号の入出力を示す。データや信号は、RAM914等のメモリ、FDD904のフレキシブルディスク(FD)、CDD905のコンパクトディスク(CD)、HDD920の磁気ディスク、光ディスク、DVD(Digital・Versatile・Disc)、あるいは、その他の記録媒体に記録される。また、データや信号は、バス912、信号線、ケーブル、あるいは、その他の伝送媒体により伝送される。
本実施の形態の説明において「〜部」として説明するものは、「〜回路」、「〜装置」、「〜機器」であってもよく、また、「〜ステップ」、「〜工程」、「〜手順」、「〜処理」であってもよい。即ち、「〜部」として説明するものは、ROM913に記憶されたファームウェアで実現されていても構わない。あるいは、「〜部」として説明するものは、ソフトウェアのみ、あるいは、素子、デバイス、基板、配線といったハードウェアのみで実現されていても構わない。あるいは、「〜部」として説明するものは、ソフトウェアとハードウェアとの組み合わせ、あるいは、ソフトウェアとハードウェアとファームウェアとの組み合わせで実現されていても構わない。ファームウェアとソフトウェアは、プログラムとして、フレキシブルディスク、コンパクトディスク、磁気ディスク、光ディスク、DVD等の記録媒体に記憶される。プログラムはCPU911により読み出され、CPU911により実行される。即ち、プログラムは、本実施の形態の説明で述べる「〜部」としてコンピュータを機能させるものである。あるいは、プログラムは、本実施の形態の説明で述べる「〜部」の手順や方法をコンピュータに実行させるものである。
サーバ装置300も、端末装置200と同様に、上記のようなコンピュータで実現できる。
図4及び図5は、ウェブサービスアプレット421を起動する際の通信システム100の動作を示す図である。
図4において、クライアント側では、ウェブブラウザ201により、HTML画面の呼び出しを行う。サーバ側では、サーバ側アプリケーション303により、クライアント側から受けた要求に合わせて、ウェブサービスアプレット421が埋め込まれている(<object>タグや<applet>タグを使用する)HTML文書であるウェブサービスページ401を出力する。前述したように、ウェブサービスアプレット421は、通常のJava(登録商標)アプレット等のようにHTML文書の中に埋め込まれてウェブブラウザ201の中で実行される。このHTML文書の中で、ウェブサービスアプレット421の部分にはウェブサービスを開始するために必要な情報が記述される。ウェブサービスアプレット421がJava(登録商標)アプレットの場合は、例えば、実行に必要なJARファイル名やダウンロード先ロケーション等が記述される。
以下、具体的な動作について説明する。
端末装置200は、ウェブブラウザ201を処理装置251により実行しており、ウェブブラウザ201の画面に任意ページ402(任意のウェブページ)を表示する。例えば任意ページ402にウェブサービスページ401へのリンクが含まれている場合、ユーザが入力装置253を操作して、そのリンクを選択すると、端末装置200の第1通信部211は、サーバ装置300に対し、ウェブサービスページ401の要求を含むHTTPリクエストをウェブブラウザ201によって送信する。
サーバ装置300は、ウェブサービスページ401の要求を含むHTTPリクエストをウェブサーバ301によって受信する。サーバ装置300は、受信したHTTPリクエストに含まれる要求をサーバ側アプリケーション303によって解析し、ウェブサービスアプレット421が埋め込まれているHTML文書、即ち、ウェブサービスページ401を生成する。そして、サーバ装置300は、端末装置200に対し、ウェブサービスページ401を含むHTTPレスポンスをウェブサーバ301によって送信する。
端末装置200の第1通信部211は、ウェブサービスページ401を含むHTTPレスポンスをウェブブラウザ201によって受信する。端末装置200の表示部212は、第1通信部211により受信されたHTTPレスポンスに含まれるウェブサービスページ401のGUI411をウェブブラウザ201の画面に表示する。この時点では、まだウェブサービスアプレット421の実体ファイル302がダウンロードされていないため、ウェブサービスアプレット421は起動されない。なお、端末装置200の第1通信部211は、ウェブサービスページ401とウェブサービスアプレット421とをウェブブラウザ201によって同時にダウンロード(同じHTTPレスポンスで受信)してもよい。
図5において、クライアント側では、ウェブブラウザ201により、ウェブサービスアプレット421のダウンロードと起動を行う。ウェブブラウザ201は、ウェブサービスアプレット421の部分(<object>タグや<applet>タグ)に記述されている内容を基にウェブサービスアプレット421の実体ファイル302をクライアント側にダウンロードした後、任意のTCP(Transmission・Control・Protocol)ポートを開いてウェブサービスを開始する。なお、ウェブブラウザ201は、オープンするポートが他の通信処理と競合しないように、かつ、不特定者からのアクセスを防ぐために、クライアント側のポートの使用状況を確認しながら任意の値域にあるポートをランダムに開く。また、ウェブブラウザ201は、ウェブサービスアプレット421が開始するまではGUI411の操作ができないような制御も行うものとする。ウェブサービスアプレット421がJava(登録商標)アプレットの場合は、例えば、ウェブサービスアプレット421のロード完了時にGUI411側にコールバックで通知する、あるいは、ステータス確認用のインタフェースを1つ公開しておきGUI411側から定期的にアクセスして確認するという方法で実装することができる。
以下、具体的な動作について説明する。
端末装置200の第1通信部211は、ウェブサービスページ401に埋め込まれているウェブサービスアプレット421を起動するため、サーバ装置300に対し、ウェブサービスアプレット421の実体ファイル302の要求を含むHTTPリクエストをウェブブラウザ201によって送信する。
サーバ装置300は、ウェブサービスアプレット421の実体ファイル302の要求を含むHTTPリクエストをウェブサーバ301によって受信する。サーバ装置300は、受信したHTTPリクエストに含まれる要求をサーバ側アプリケーション303によって解析し、ウェブサービスアプレット421に利用させるデータ(例えば、後述する地図データ)をデータベース304からサーバ側アプリケーション303によって抽出し、必要に応じてデータ処理を行った上でウェブサービスアプレット421の実体ファイル302に付加する。そして、サーバ装置300は、端末装置200に対し、ウェブサービスアプレット421の実体ファイル302を含むHTTPレスポンスをウェブサーバ301によって送信する。なお、サーバ装置300は、ウェブサービスアプレット421に利用させるデータを最初からウェブサービスアプレット421の実体ファイル302に付加しておくのではなく、ウェブサービスアプレット421からの要求があったときに初めて、その応答としてウェブサービスアプレット421にデータを送信するようにしてもよい。
端末装置200の第1通信部211は、ウェブサービスアプレット421の実体ファイル302を含むHTTPレスポンスをウェブブラウザ201によって受信する。端末装置200の実行部213は、第1通信部211により受信されたHTTPレスポンスに含まれるウェブサービスアプレット421の実体ファイル302を展開してウェブサービスアプレット421をウェブブラウザ201で起動する。本実施の形態では、ウェブサービスアプレット421はアプレット画面を表示しないものとする。そのため、ウェブサービスアプレット421は、例えばウェブサービスページ401に含まれる非表示のフレームに埋め込まれている(非表示のフレームに<object>タグや<applet>タグが記述される)。
ウェブサービスアプレット421は、ウェブブラウザ201上で起動されると、ウェブサービス(例えば、後述する地図表示サービス)を起動し、ウェブブラウザ201とのHTTP通信によりGUI411を操作可能にする(S101:起動処理)。ウェブサービスアプレット421がGUI411を制御する方法の詳細については後述する。
図6及び図7は、ウェブサービスアプレット421を使って画面遷移処理を行う際の通信システム100の動作を示す図である。
図6において、クライアント側では、サーバ側でウェブサービスアプレット421の実体ファイル302に付加されたデータ(例えば、後述する地図データ)を利用した処理(例えば、後述するイメージ生成処理)、定型の画面遷移や入力確認の処理等、クライアント側のみで実行できる処理については、ウェブサービスアプレット421内で実行し応答を返す。GUI411の部分、即ち、ウェブブラウザ201と、ウェブサービスアプレット421との間ではHTTPを使って通信する。これにより、GUI411の部分は標準のHTMLとJavaScript(登録商標)のみのノウハウで構築することができる。また、後述するように、応答情報に画像情報等を使うことにより、通常はHTMLとJavaScript(登録商標)のみでは実装することが難しい画像の動的生成処理等もクライアント側で実行することが可能になる。また、サーバ側への通信を抑制することにより通信トラフィックを減らしシステム全体のパフォーマンスを向上させることも可能になる。最近ではAJAX(Asynchronous・JavaScript+XML)等の普及により動的な処理をクライアント側で動くスクリプト言語で実装する例も増えてきているが、処理が複雑になればなるほどスクリプトが肥大化し、保守等の面で課題が多い。これに対し、本実施の形態では、スクリプトを規模が小さくて済むため、保守等が行いやすくなる。
以下、具体的な動作について説明する。
端末装置200の入力部214は、ユーザが入力装置253を操作してウェブサービスページ401のGUI411(表示部212によりウェブサービスページ401が表示されているウェブブラウザ201の画面)に入力する入力データ(例えば、キーボード902のキー入力、マウス903のクリックやポインタの移動)を受け付ける。端末装置200の第2通信部215は、実行部213によりウェブブラウザ201で実行されているウェブサービスアプレット421へ、入力部214により受け付けられた入力データを含むHTTPリクエストをウェブブラウザ201によって送信する。
ウェブサービスアプレット421は、ウェブブラウザ201から、ウェブブラウザ201の画面に表示されているウェブサービスページ401のGUI411に対する入力データを含むHTTPリクエストを受信する(S111:受信処理)。ウェブサービスアプレット421は、S111で受信したHTTPリクエストに含まれる、ウェブサービスページ401のGUI411に対する入力データに応じて所定の処理(例えば、後述するイメージ生成処理)を実行する(S112:実行処理)。ウェブサービスアプレット421は、S112で実行した処理の結果に基づいてウェブサービスページ401のGUI411を更新するための更新データ(応答情報)を生成する(S113:生成処理)。ウェブサービスアプレット421は、ウェブブラウザ201へ、S113で生成した更新データを含むHTTPレスポンスを返信する(S114:返信処理)。
端末装置200の第2通信部215は、ウェブサービスアプレット421から返信されたHTTPレスポンスをウェブブラウザ201によって受信する。端末装置200の更新部216は、第2通信部215により受信されたHTTPレスポンスに含まれる更新データに従って、ウェブサービスページ401のGUI411(表示部212によりウェブブラウザ201の画面に表示されているウェブサービスページ401)を更新する。
図7において、クライアント側では、データベース304の検索や更新の処理等、サーバ側のリソースへのアクセスが必要な処理については、サーバ側と連携して実行する。つまり、ウェブサービスアプレット421からウェブサーバ301にリクエストを投げて応答を返す。実際にサーバ側にアクセスする必要があるか否かはウェブサービスアプレット421の中で判断する。したがって、GUI411の部分からは、ウェブサービスアプレット421のみを使っているのかウェブサーバ301やサーバ側アプリケーション303も使っているのかを区別する必要はない。以下では、クライアント側がサーバ側と連携する場合、ウェブサービスアプレット421とウェブサーバ301が通信するものとして説明するが、ウェブサービスアプレット421とサーバ側アプリケーション303が直接通信しても構わない。また、ウェブサービスアプレット421とサーバ側アプリケーション303が直接通信する場合、両者間の通信は公開する必要がないため、通信のバイナリ化によって、性能を改善することが可能となる。さらに、この場合、独自の暗号化等を組み込むことも可能になる。例えば、SSL(Secure・Socket・Layer)を使うのは冗長だが単純な平文での通信は避けたいという場合等に有効である。
以下、具体的な動作について説明する。
図6の場合と同様に、端末装置200の入力部214は、ユーザが入力装置253を操作してウェブサービスページ401のGUI411(表示部212によりウェブサービスページ401が表示されているウェブブラウザ201の画面)に入力する入力データ(例えば、キーボード902のキー入力、マウス903のクリックやポインタの移動)を受け付ける。端末装置200の第2通信部215は、実行部213によりウェブブラウザ201で実行されているウェブサービスアプレット421へ、入力部214により受け付けられた入力データを含むHTTPリクエストをウェブブラウザ201によって送信する。
ウェブサービスアプレット421は、ウェブブラウザ201から、ウェブブラウザ201の画面に表示されているウェブサービスページ401のGUI411に対する入力データを含むHTTPリクエストを受信する(S121:受信処理)。ウェブサービスアプレット421は、S121で受信したHTTPリクエストに含まれる、ウェブサービスページ401のGUI411に対する入力データに応じて所定の処理(例えば、後述するイメージ生成処理)を実行する(S122:実行処理)。このとき、ウェブサービスアプレット421は、その処理を実行するためのデータが不足していないかどうかを判定し、データが不足していると判定した場合には、サーバ装置300に対し、データ(例えば、後述する地図データ)の要求を含むHTTPリクエストを送信する。
サーバ装置300は、データの要求を含むHTTPリクエストをウェブサーバ301によって受信する。サーバ装置300は、受信したHTTPリクエストに含まれる要求をサーバ側アプリケーション303によって解析し、当該要求に対応するデータをデータベース304から抽出する(S123)。そして、サーバ装置300は、ウェブサービスアプレット421に対し、抽出したデータを含むHTTPレスポンスをウェブサーバ301によって送信する(S124)。
ウェブサービスアプレット421は、サーバ装置300から、データを含むHTTPリクエストを受信すると、受信したデータを利用してS122で所定の処理を実行する。ウェブサービスアプレット421は、S122で実行した処理の結果に基づいてウェブサービスページ401のGUI411を更新するための更新データ(応答情報)を生成する(S125:生成処理)。ウェブサービスアプレット421は、ウェブブラウザ201へ、S125で生成した更新データを含むHTTPレスポンスを返信する(S126:返信処理)。
図6の場合と同様に、端末装置200の第2通信部215は、ウェブサービスアプレット421から返信されたHTTPレスポンスをウェブブラウザ201によって受信する。端末装置200の更新部216は、第2通信部215により受信されたHTTPレスポンスに含まれる更新データに従って、ウェブサービスページ401のGUI411(表示部212によりウェブブラウザ201の画面に表示されているウェブサービスページ401)を更新する。
なお、ウェブサービスアプレット421は、S122において、処理を実行するためのデータが不足している場合だけでなく、例えば、データベース304にデータを登録する場合やデータベース304のデータを更新する場合に、サーバ装置300に対し、その要求を含むHTTPリクエストを送信してもよい。この場合、サーバ装置300は、S123において、HTTPリクエストに含まれる要求に対応するデータ操作を実行する。
図8は、ウェブサービスアプレット421を終了する際の通信システム100の動作を示す図である。
図8において、ウェブサービスアプレット421は通常のアプレットと同様にウェブブラウザ201の中で稼動しているため、明示的に終了させなくても、表示している画面を閉じること等により終了処理が実行される。ただし、実際には確保しているサーバ側のリソースを解放する処理やクライアント側で確保しているメモリ等を解放する処理を行うことが望ましい。例えば、GUI411にて明示的な終了処理を要求するためのボタン等を設けておき、それがユーザによって選択されると、ウェブサービスアプレット421は、HTTP通信等に利用していたポートを閉じ、メモリを解放し、ウェブブラウザ201に終了通知を行う(S131:終了処理)。
以上説明したように、本実施の形態では、従来のMVCモデルにおいてサーバ側(サーブレット)で実装されているコントロール(C)の部分を、クライアント側(ウェブサービスアプレット421)で実装できる。つまり、下記のようにMVCモデルを構築しているといえる。
・コントロール(C):ウェブサービスアプレット421で実装する。
・モデル(M):データ操作用IF(インタフェース)としてサーブレット(サーバ側アプリケーション303)で実装する。
・ビュー(V):HTMLとJavaScript(登録商標)で実装する。
このように、本実施の形態によれば、MVCモデルにおけるコントロール(C)をクライアント側で実装できるため、負荷のかかる処理をサーバ側からクライアント側に分散できる。また、通信処理等にかかる負荷を軽減できる。さらに、本実施の形態によれば、MVCモデルにおけるビュー(V)にHTMLを使っているため、ウェブシステムとの親和性が高いシステムが構築できる。
実施の形態2.
本実施の形態では、実施の形態1をGIS(地理情報システム)に適用する。本実施の形態では、ウェブサービスアプレット421は、ウェブサービスの一例として地図表示サービスを提供する。
GISは、地理的位置を手がかりに、位置に関する情報をもったデータ(空間データ)を総合的に管理・加工し、視覚的に表示し、高度な分析や迅速な判断を可能にするシステムである。従来は、
・高価な地図情報を購入する必要がある。
・多量の幾何図形を使用するために高性能な専用端末が必要になる。
といったことから専用性の強いシステムで主に使われていたが、近年、ウェブ上で安価軽量に動作する基盤が整備されていたことにより急速に一般化が進んできている。
図9は、従来のGIS501の動作を示す図である。
図9に示すように、従来のGIS501では、道路や行政区等の情報を全て幾何図形(多角形、多角線、点情報等)として保持しておき業務に合わせて加工、解析するようなパターンで実装していた。したがって、単純に地図をクライアント端末のモニタ上に表示するだけでも以下のような処理をしていた。
(1)表示範囲内にある地図情報(幾何図形)を取得する。
(2)メモリ上に表示するイメージ領域を確保する。
(3)上記で確保したイメージ上に各幾何図形描画API(Application・Program・Interface)を使って取得した地図情報を描画する。
(4)描画したイメージをモニタ上に表示する。
さらに業務システムとして使うためには一般的には以下のような機能も必要になっていた。
・凡例表示機能:業務情報と連動させて行政区や設備を色換え表示する機能である。
・レイヤ表示機能:各幾何図形に論理的な意味をつけてまとめて表示種類や形状を変更する機能である。
・メッシュ分割機能:縮尺に合わせて予め幾何図形を矩形に分割しておき同時に使用する図形数を少なくする機能である。
図10は、ウェブ上で使われるGIS502の動作を示す図である。
以前は、GIS502をウェブ上で使う場合は、上記のような複雑な処理をブラウザ(ウェブブラウザ)の標準機能で実装することは難しいため、クライアント拡張型(専用のプラグインやアプレットを使用する)や、図10に示すようなサーバサイドイメージ生成型(クライアント側の要望に合わせてサーバ側でイメージを動的に生成する)等で実装していた。しかしながら、クライアント拡張型では、プラグインやアプレットの操作画面を用いていたため、HTMLだけで作られている画面との親和性が低いという課題があった。特に近年はDHTML(Dynamic・HTML)+JavaScript(登録商標)でクライアント側を実装することが主流になってきているため、そこに簡単に組み込めないというのが大きな課題となっていた。また、サーバサイドイメージ生成型では、サーバサイドに負荷がかかるため、ユーザが増えた場合に必要となるサーバ側のリソースが著しく増えるという課題があった。
図11は、ウェブ上で使われる別のGIS503の動作を示す図である。
図11に示すように、このGIS503では、以前のGIS502と異なり、単純に地図はあくまでも下図だと割り切ってウェブ上で軽量かつ安価に動くように下記のような方法で実装されている。
(1)地図は下図として予め各縮尺に合わせて静的なイメージファイルとして生成しておく。
(2)クライアント側では縮尺や表示範囲に合わせて単純にイメージを並べて表示する。
上記のように実装することにより、以前のGIS502で負荷がかかっていた動的イメージ生成処理が地図表示時に不要になるため全体の処理を軽量化することができる。また、上記の処理ならば基本的なDHTMLの機能でできるためウェブ画面に容易に組み込むことも可能である。さらに、最近のブラウザではイメージを重ねて表示することや簡単なベクトル図であればスクリプトで描画することができるようになったため、地図上に設備を表示するというような簡単な機能であれば十分に使えるようになってきている。しかしながら、下図に静的イメージを使うため用途に応じて任意の図形を動的に非表示にすることや色変えするといった機能やスクリプトで多量の図形(例えば、2万件以上)を描画する等が難しいため、複雑な機能を実現するのは困難である。
図12から図16までは、本実施の形態に係るGIS101の動作を示す図である。
GIS101の構成は、図1に示した実施の形態1に係る通信システム100の構成と同様である。
図12において、GIS101は初期処理を行う。まず、サーバ側からウェブサービスアプレット421をダウンロードし、クライアント側のウェブブラウザ201内で動かす。ウェブサービスアプレット421は、任意のポートを開いて地図表示サービスを開始する。サーバサイドからウェブサービスアプレット421のモジュール(実体ファイル302)をダウンロードして動かす処理には通常のプラグインやアプレットと同様の機能を利用できる。なお、地図表示サービスが立ち上がっているか等を事前に検知するような仕組みを設けてもよい。
以下、具体的な動作について説明する。
端末装置200は、ウェブブラウザ201を処理装置251により実行しており、ウェブブラウザ201の画面にメニュー画面404(ウェブサービスページ401へのリンクをメニューの一部として表示するウェブページ)を表示する。例えばユーザがマウス903等のポインティングデバイス(入力装置253の一例)を操作して、ウェブサービスページ401へのリンクを選択すると、端末装置200の第1通信部211は、サーバ装置300に対し、ウェブサービスページ401の要求を含むHTTPリクエストをウェブブラウザ201によって送信する。
サーバ装置300は、ウェブサービスページ401の要求を含むHTTPリクエストをウェブサーバ301によって受信する。サーバ装置300は、受信したHTTPリクエストに含まれる要求を、サーバ側アプリケーション303に実装される地図データ取得IF305によって解析し、ウェブサービスページ401を生成する。そして、サーバ装置300は、端末装置200に対し、ウェブサービスページ401を含むHTTPレスポンスをウェブサーバ301によって送信する。
端末装置200の第1通信部211は、ウェブサービスページ401を含むHTTPレスポンスをウェブブラウザ201によって受信する。続けて、端末装置200の第1通信部211は、サーバ装置300に対し、ウェブサービスページ401に埋め込まれているウェブサービスアプレット421を起動するため、ウェブサービスアプレット421の実体ファイル302の要求を含むHTTPリクエストをウェブブラウザ201によって送信する。
サーバ装置300は、ウェブサービスアプレット421の実体ファイル302の要求を含むHTTPリクエストをウェブサーバ301によって受信する。サーバ装置300は、受信したHTTPリクエストに含まれる要求をサーバ側アプリケーション303によって解析し、ウェブサービスアプレット421の実体ファイル302を含むHTTPレスポンスをウェブサーバ301によって送信する。
端末装置200の第1通信部211は、ウェブサービスアプレット421の実体ファイル302を含むHTTPレスポンスをウェブブラウザ201によって受信する。端末装置200の実行部213は、第1通信部211により受信されたHTTPレスポンスに含まれるウェブサービスアプレット421の実体ファイル302を展開してウェブサービスアプレット421をウェブブラウザ201で起動する。
ウェブサービスアプレット421は、ウェブブラウザ201上で起動されると、地図表示サービスを起動する(起動処理)。
端末装置200の表示部212は、第1通信部211により受信されたHTTPレスポンスに含まれるウェブサービスページ401のGUI411をウェブブラウザ201の画面に地図表示画面405(HTML+スクリプト)として表示する。この時点では、まだウェブサービスアプレット421が起動されただけであるため、地図表示画面405には地図のイメージ(画像)が表示されていない。
図13において、GIS101は地図表示(初期表示)処理を行う。地図表示画面405では、以前のGIS502や別のGIS503でサーバ側にリクエストを送るようにウェブサービスアプレット421に対して、縮尺、表示座標、表示範囲の情報を含むHTTPのリクエストを送信する。リクエストを受けたウェブサービスアプレット421はサーバ側に、縮尺、表示座標、表示範囲の情報を含むHTTPのリクエストを送信する。ウェブサービスアプレット421からリクエストを受けたサーバ側アプリケーション303は、データベース304に蓄積されている地図データ306(ベクトル)のうち、描画に必要な地図データ306を取得し、ウェブサービスアプレット421にHTTPのレスポンスとして送信する。サーバ側アプリケーション303から地図データ306をレスポンスとして受けたウェブサービスアプレット421は、受信した地図データ306をメモリ(記憶装置252の一例)内にキャッシュした後、イメージを生成し、HTTPのレスポンスとして地図表示画面405側に返す。地図表示画面405では受け取ったイメージの位置やサイズを調整して表示する。
以下、具体的な動作について説明する。
端末装置200の第2通信部215は、地図のイメージを地図表示画面405に表示するため、実行部213によりウェブブラウザ201で実行されているウェブサービスアプレット421へ、地図の初期イメージの要求を含むHTTPリクエストをウェブブラウザ201によって送信する。
ウェブサービスアプレット421は、ウェブブラウザ201から、地図の初期イメージの要求を含むHTTPリクエストを受信する(受信処理)。ウェブサービスアプレット421は、地図の初期イメージを地図表示画面405に表示するために必要な地図データ306を保持していないため、地図データ306が不足していると判定する。そして、ウェブサービスアプレット421は、サーバ装置300に対し、地図データ306の要求を含むHTTPリクエストを送信する。
サーバ装置300は、地図データ306の要求を含むHTTPリクエストをウェブサーバ301によって受信する。サーバ装置300は、受信したHTTPリクエストに含まれる要求をサーバ側アプリケーション303の地図データ取得IF305によって解析し、地図データ306をデータベース304から抽出する。そして、サーバ装置300は、ウェブサービスアプレット421に対し、抽出した地図データ306を含むHTTPレスポンスをウェブサーバ301によって送信する。
ウェブサービスアプレット421は、サーバ装置300から、地図データ306を含むHTTPリクエストを受信すると、受信したHTTPリクエストから地図データ306を取得する。ウェブサービスアプレット421は、取得した地図データ306を利用して、ユーザにより指定された、あるいは、デフォルトの緯度経度、縮尺、表示サイズ等(ユーザにより指定される場合は、受信処理で、緯度経度、縮尺、表示サイズ等を入力データとして含むHTTPリクエストを受信する)に適合する地図のイメージを生成する。即ち、所定の処理の一例として、イメージ生成処理を実行する(実行処理)。ウェブサービスアプレット421は、生成したイメージ(イメージ生成処理の結果)を、GIF(Graphics・Interchange・Format)、JPEG(Joint・Photographic・Experts・Group)、PNG(Portable・Network・Graphics)といった任意の形式に変換し、更新データとする(生成処理)。ウェブサービスアプレット421は、ウェブブラウザ201へ、生成した更新データを含むHTTPレスポンスを返信する(返信処理)。
端末装置200の第2通信部215は、ウェブサービスアプレット421から返信されたHTTPレスポンスをウェブブラウザ201によって受信する。端末装置200の更新部216は、第2通信部215により受信されたHTTPレスポンスに含まれる更新データから地図の初期イメージを取得して地図表示画面405に表示する。
図14において、GIS101は地図表示(拡大縮小、スクロール)処理を行う。地図表示画面405では、以前のGIS502や別のGIS503でサーバ側にリクエストを送るようにウェブサービスアプレット421に対して、拡大縮小、スクロール後の縮尺、表示座標、表示範囲の情報を含むHTTPのリクエストを送信する。リクエストを受けたウェブサービスアプレット421はキャッシュしている地図データ306を確認し、足りなかった場合はサーバ側に、縮尺、表示座標、表示範囲の情報を含むHTTPのリクエストを送信し、地図データ306(ベクトル)を取得した後、イメージを生成し、HTTPのレスポンスとして地図表示画面405側に返す。地図表示画面405では受け取ったイメージの位置やサイズを調整して表示する。なお、ウェブサービスアプレット421は、メモリ使用量に合わせてキャッシュした情報を破棄したり、連続する領域の情報を操作パターンに合わせて先読みしたりする等の制御をしてもよい。
以下、ウェブサービスアプレット421にて地図データ306が不足していた場合の具体的な動作について説明する。
端末装置200の入力部214は、ユーザがマウス903等のポインティングデバイス(入力装置253の一例)を操作して地図表示画面405に表示されているスクロールバー等を動かすと、スクロールバー等が動かされた方向や量を示す入力データを受け付ける。端末装置200の第2通信部215は、実行部213によりウェブブラウザ201で実行されているウェブサービスアプレット421へ、入力部214により受け付けられた入力データを含むHTTPリクエストをウェブブラウザ201によって送信する。
ウェブサービスアプレット421は、ウェブブラウザ201から、スクロールバー等が動かされた方向や量を示す入力データを含むHTTPリクエストを受信する(受信処理)。ウェブサービスアプレット421は、受信したHTTPリクエストに含まれる入力データから、地図のイメージを拡大縮小あるいはスクロールする方向や量を特定し、そのための地図データ306が不足していないかどうかを判定する。地図データ306が不足していると判定した場合には、ウェブサービスアプレット421は、サーバ装置300に対し、地図データ306の要求を含むHTTPリクエストを送信する。
サーバ装置300は、地図データ306の要求を含むHTTPリクエストをウェブサーバ301によって受信する。サーバ装置300は、受信したHTTPリクエストに含まれる要求をサーバ側アプリケーション303の地図データ取得IF305によって解析し、地図データ306をデータベース304から抽出する。そして、サーバ装置300は、ウェブサービスアプレット421に対し、抽出した地図データ306を含むHTTPレスポンスをウェブサーバ301によって送信する。
ウェブサービスアプレット421は、サーバ装置300から、地図データ306を含むHTTPリクエストを受信すると、受信したHTTPリクエストから地図データ306を取得する。ウェブサービスアプレット421は、取得した地図データ306を利用して、入力データに応じて拡大縮小あるいはスクロールした後の地図のイメージを生成する。即ち、所定の処理の一例として、イメージ生成処理を実行する(実行処理)。ウェブサービスアプレット421は、生成したイメージ(イメージ生成処理の結果)を、GIF、JPEG、PNGといった任意の形式に変換し、更新データとする(生成処理)。ウェブサービスアプレット421は、ウェブブラウザ201へ、生成した更新データを含むHTTPレスポンスを返信する(返信処理)。
端末装置200の第2通信部215は、ウェブサービスアプレット421から返信されたHTTPレスポンスをウェブブラウザ201によって受信する。端末装置200の更新部216は、第2通信部215により受信されたHTTPレスポンスに含まれる更新データから地図のイメージを取得し、地図表示画面405に現在表示しているイメージを、取得したイメージに切り替える。
以下、ウェブサービスアプレット421にて地図データ306が足りていた場合の具体的な動作について説明する。
ウェブサービスアプレット421が、受信したHTTPリクエストに含まれる入力データから、地図のイメージを拡大縮小あるいはスクロールする方向や量を特定し、そのための地図データ306が不足していないかどうかを判定するまでの動作は、上記と同様である。地図データ306が足りていると判定した場合には、ウェブサービスアプレット421は、保持している地図データ306を利用して、入力データに応じて拡大縮小あるいはスクロールした後の地図のイメージを生成する。即ち、所定の処理の一例として、イメージ生成処理を実行する(実行処理)。これ以降の動作も、上記と同様である。
図15において、GIS101はレイヤ処理(表示内容切替処理)を行う。地図表示画面405では、以前のGIS502や別のGIS503でサーバ側にリクエストを送るようにウェブサービスアプレット421に対して、任意の図形の表示、非表示を切り替える要求を含むHTTPのリクエストを送信する。リクエストを受けたウェブサービスアプレット421は、要求に合わせてイメージを作り直しHTTPのレスポンスとして地図表示画面405側に返す。地図表示画面405では受け取ったイメージの位置やサイズを調整して表示する。なお、地図データ306の読み込みをレイヤ単位に分割している場合等は、ウェブサービスアプレット421はサーバ側から地図データ306を取り出す必要がある。
具体的な動作については、図14の場合と同様である。
図16において、GIS101は図形選択処理を行う。地図表示画面405では、以前のGIS502や別のGIS503でサーバ側にリクエストを送るようにウェブサービスアプレット421に対して、任意の位置でマウスポインタの移動あるいはマウスクリック等のイベントが発生したことを通知するHTTPのリクエストを送信する。リクエストを受けたウェブサービスアプレット421は、通知された位置に、イベントに応じてシンボルを表示すべき図形(例えば、ランドマーク、建物、鉄塔)がないか確認し、あった場合はその図形の描画情報とキー情報(ランドマーク、建物、鉄塔等のID、住所コード等)を地図表示画面405側に戻す。地図表示画面405では受け取った情報を基に、対応する位置にシンボルをスクリプトで描画する等の処理を実行する。例えば、建物A〜Zが地図のイメージ上で黒い点として表示されており、いずれか建物の位置にマウス903のポインタが移動した(あるいは、その位置でマウス903がクリックされた)場合には点の色を赤色に切り替えることが定義されていたとする。建物Aの位置にポインタが移動すると(あるいは、その位置がクリックされると)、地図表示画面405では、その位置を通知するHTTPリクエストがウェブサービスアプレット421に送信される。ウェブサービスアプレット421は、HTTPリクエストにより通知された位置が建物Aの位置であることを検知すると、その位置が建物であることを通知するHTTPレスポンスを地図表示画面405に返す。地図表示画面405では、これに応じて、地図のイメージ上にてポインタが移動した位置(クリックされた位置)に赤い点のシンボルを描画する処理をスクリプトで実行する。あるいは、ウェブサービスアプレット421は、HTTPリクエストにより通知された位置が建物Aの位置であることを検知すると、その位置に赤い点のシンボルを描画するように指示するHTTPレスポンスを地図表示画面405に返す。地図表示画面405では、地図のイメージにてポインタが移動した位置(クリックされた位置)に、HTTPレスポンスにより指示されたシンボルを描画する処理をスクリプトで実行する。ここでは、どのような図形(例えば、ランドマーク、建物、鉄塔)を検知し、検知した図形に対してどのような処理(例えば、色を換える、あるいは、付加情報を表示する)を施すかを予めウェブサービスアプレット421が把握しているものとする。
以下、具体的な動作について説明する。
端末装置200の表示部212は、マウス903等のポインティングデバイス(入力装置253の一例)のポインタを地図表示画面405に表示する。端末装置200の入力部214は、ユーザがポインティングデバイスを操作して地図表示画面405に表示されているポインタを移動させる度に、移動したポインタの位置を特定する位置データを入力データとして受け付ける。端末装置200の第2通信部215は、入力部214により位置データが受け付けられる度に、実行部213によりウェブブラウザ201で実行されているウェブサービスアプレット421へ、入力部214により受け付けられた位置データを含むHTTPリクエストをウェブブラウザ201によって送信する。
ウェブサービスアプレット421は、ウェブブラウザ201から、位置データを含むHTTPリクエストを受信する(受信処理)。ウェブサービスアプレット421は、受信したHTTPリクエストに含まれる位置データで特定される位置が地図のイメージ上で予め決められた地点に一致するか否かを判定する。即ち、所定の処理の一例として、判定処理を実行する(実行処理)。ウェブサービスアプレット421は、一致すると判定した場合、当該地点の表示内容を所定の内容に変更することを指示する指示データを更新データとして生成する(生成処理)。前述した例であれば、ウェブサービスアプレット421は、位置データで特定される位置が建物Aのある地点に一致すると判定した場合、その地点に赤い点のシンボルを描画することを指示する指示データを生成する(生成処理)。あるいは、その地点に赤い点を描画したイメージを生成し、生成したイメージを、GIF、JPEG、PNGといった任意の形式に変換し、更新データとする(生成処理)。ウェブサービスアプレット421は、ウェブブラウザ201へ、生成した指示データ(更新データ)を含むHTTPレスポンスを返信する(返信処理)。
端末装置200の第2通信部215は、ウェブサービスアプレット421から返信されたHTTPレスポンスをウェブブラウザ201によって受信する。端末装置200の更新部216は、第2通信部215により受信されたHTTPレスポンスに含まれる指示データに従って、地図のイメージ上にシンボルを描画する。あるいは、端末装置200の更新部216は、第2通信部215により受信されたHTTPレスポンスに含まれる更新データから地図のイメージを取得し、地図表示画面405に現在表示しているイメージを、取得したイメージに切り替える。
以上説明したように、本実施の形態は、以前のGIS502(クライアント拡張型)と比較すると、画面自体を基本的なDHTMLで作れるため、同様にDHTMLで作られている業務画面に簡単に組み込むことができるという効果を奏する。また、本実施の形態は、以前のGIS502(サーバサイドイメージ生成型)と比較すると、最もリソースを消費するイメージの動的生成処理をクライアント側で動かせるため、多数のユーザから接続されてもリソースを充分に確保できるという効果を奏する。また、本実施の形態は、別のGIS503と比較すると、イメージを動的に生成できるため任意の図形の表示を切り替える等の処理が容易に実装できるという効果を奏する。また、イベントを検知させる図形等をメモリ上に保持することにより多量のデータでも取り扱うことができるという効果を奏する。
以下、図17及び図18を用いて、さらに、本実施の形態をGIS503と比較する。
例えば、地図表示(初期表示)処理を行う場合、図17に示すように、GIS503では、ブラウザがウェブサーバに対して地図の初期イメージを要求し、ウェブサーバから地図の初期イメージを取得する。ブラウザは、取得した地図の初期イメージを画面に表示する。イメージ上でランドマーク等(ポインタが重なると予め決められたシンボルデータが描画される地点)は黒い点で表されているものとする。
一方、図18に示すように、本実施の形態に係るGIS101では、ウェブブラウザ201がウェブサービスアプレット421に対して地図の初期イメージを要求する。ウェブサービスアプレット421は、ウェブブラウザ201から地図の初期イメージが要求されると、ウェブサーバ301に対して地図データ306及びシンボルデータを要求し、ウェブサーバ301から地図データ306及びシンボルデータを取得する。ウェブサービスアプレット421は、取得した地図データ306を用いて地図の初期イメージを生成するとともに、シンボルデータを保持しておく。そして、生成した地図の初期イメージをウェブブラウザ201に返す。ウェブブラウザ201は、ウェブサービスアプレット421から地図の初期イメージを取得し、取得した地図の初期イメージを画面に表示する。前述したように、イメージ上でランドマーク等(ポインタが重なると予め決められたシンボルデータが描画される地点)は黒い点で表されているものとする。
地図表示(初期表示)処理の後、例えば、図形選択処理を行う場合、図17に示すように、GIS503では、ユーザがマウス903等によりブラウザの画面上でポインタを移動させる度に、ブラウザがウェブサーバに対して移動後のポインタのXY座標をイベントデータとして通知する。ウェブサーバは、ブラウザからイベントデータを受け取る度に、そこで示されたポインタのXY座標に相当する位置にランドマーク等があるかどうかを判定する。そして、ウェブサーバは、その位置にランドマーク等があると判定した場合、その位置に描画するシンボルデータをブラウザに返す。ブラウザは、ウェブサーバからシンボルデータを受け取って、ポインタが移動した位置、即ち、ランドマーク等の位置に、そのシンボルデータを描画する。このように、ポインタが移動する度にクライアントとサーバとの間で通信が発生すると、負荷が著しく増大し、システムの性能が大幅に劣化することが予想される。なお、XY座標とランドマーク等の位置との対応関係を全てスクリプトに記述してしまえば、ポインタが移動する度にクライアントとサーバとの間で通信を行う必要はなくなる。しかしながら、ランドマーク等の数が膨大になると、スクリプトが大規模かつ複雑になり、不具合等を引き起こす要因となったり、保守作業が困難になったりする。また、動作しなくなる可能性もある。
一方、図18に示すように、本実施の形態に係るGIS101では、ユーザがマウス903等によりブラウザの画面上でポインタを移動させる度に、ウェブブラウザ201が同じクライアント上のウェブサービスアプレット421に対して移動後のポインタのXY座標をイベントデータとして通知する。ウェブサービスアプレット421は、ウェブブラウザ201からイベントデータを受け取る度に、そこで示されたポインタのXY座標に相当する位置にランドマーク等があるかどうかを判定する。そして、ウェブサービスアプレット421は、その位置にランドマーク等があると判定した場合、現在の地図のイメージ上で当該位置にシンボルデータを描画した地図の更新イメージを生成する。そして、生成した地図の更新イメージをウェブブラウザ201に返す。ウェブブラウザ201は、ウェブサービスアプレット421から地図の更新イメージを取得し、取得した地図の更新イメージを画面に表示する。あるいは、ウェブサービスアプレット421は、ランドマーク等があると判定した場合、その位置に描画するシンボルデータをウェブブラウザ201に返す。ウェブブラウザ201は、ウェブサービスアプレット421からシンボルデータを取得し、ポインタが移動した位置、即ち、ランドマーク等の位置に、そのシンボルデータを描画する。このように、本実施の形態では、ポインタが移動する度にクライアントとサーバとの間で通信が発生するのではなく、クライアント上で処理を行うことが可能なため、負荷が軽減でき、システムの性能が向上する。
本実施の形態では、ウェブサービスアプレット421は、地図表示サービスを提供するが、その他のウェブサービスを提供してもよい。その他のウェブサービスとしては、例えば、オンラインゲームやオンライン会議等のサービスが考えられる。