使い勝手に関する利用者の要求をうまく洗い出せれば,リッチクライアント・プロジェクトの大きな課題は乗り越えたことになる。後は設計・開発・テストとなるが,これらの工程にはリッチクライアント特有のポイントがある。第4回,第5回では設計・開発・テストのポイントのうち,特に重要な(1)応答性,(2)拡張性,(3)使い勝手の検証と改善――の3点に絞り,そのコツを事例に基づく工夫として説明する。

 リッチクライアントとサーバーとの通信設計によって,「応答性は大きく変わる」(SIベンダーのサイエントビジネスアソシエイツ 糸山準二氏)。使い勝手を左右するだけに,工夫がいる。

工夫1 複数回の通信をまとめる

 日本航空のWebサイトにある国内線予約ページ。その初心者向けのユーザー・インタフェース(UI)は,米Adobe Systemsのリッチクライアント技術「Flash」で実装されている。元々Webベースの予約システムがあり,そのシステムのサーバー・アプリケーションを修正せずにFlashアプリケーションを追加した(図1)。既存システムのインタフェースを再利用することで改修量を削減できたが,その方針ではFlashアプリケーションの応答性能に問題を起こす可能性があった。通信部分を工夫することで乗り越えた。

図1●既存のWebシステムに手を入れずにリッチ化
図1●既存のWebシステムに手を入れずにリッチ化
日本航空は,Web予約システムをFlashでリッチ化して操作性を向上した。その際,既存システムをできるだけ改修せずに済むよう工夫した。サーバー側に「Webサービス化プロキシ」を構築し,Flashアプリケーションで必要になる情報をまとめて返せるようにした。クライアントから1回の通信で複数の情報を取得できるので,応答性の劣化を防いだ
[画像のクリックで拡大表示]

 以前からあるWeb予約システムでは,往復のチケットを予約しようとしても,往路空席情報と復路空席情報を別々のページで確認しなければならなかった。そこでFlash版の予約画面では,往路空席情報と復路空席情報を一つの画面で参照できるようにした。

 だが,Flash版の一つの画面で情報を参照するのに,往路と復路の計2回,Web予約システムのサーバー・アプリケーションと通信しなければならない。インターネット上を2往復すると,応答性能が悪化すると考えられた。

 そこで,Web予約システムの手前に「Webサービス化プロキシ」を設置した。Flashアプリケーションから空席照会のリクエストがあると,Webサービス化プロキシが受け付け,Web予約システムから往路と復路それぞれの空席情報を取得する。その結果をWebサービス化プロキシがまとめて,クライアントのFlashアプリケーションに対して1回の通信で返す。

 この方法ならば,Webサービス化プロキシとWeb予約システムは遅延の小さいLAN上の通信で済むので,インターネット越しに2回の通信をするよりトータルの遅延は小さくて済む。