リッチクライアントでは利用者の習熟度や環境の変化などに応じて,アプリケーションを見直さなければならないことも多い。将来の変化に柔軟に対応できるように,拡張性を保ちたい。

工夫3 クライアント側に「MVC」

図1●リッチクライアントにMVCモデルを適用した例と,拡張性を高めた例
図1●リッチクライアントにMVCモデルを適用した例と,拡張性を高めた例
セカンドファクトリーの三枝正稔氏は,デザインや視覚効果に関する処理(View)と,業務的な処理(Model)の独立性を高めるべく工夫した(右)。ModelとViewをControllerで仲介し,やり取りする引数を情報(Entity)として渡す。このモデルならサーバーからデータをプッシュする場合にも対応できる
[画像のクリックで拡大表示]

 一般に拡張性を保つには,アプリケーションに「MVC(Model-View-Controller)モデル」を適用するとよい。MVCモデルをリッチクライアントに適用すると,クライアントにMVCがあり,サーバーにはMVCのうちModelとControllerがくる(図1左)。クライアントのControllerで要求を受け付け,クライアントのModelでサーバーのControllerへ送り,サーバーのModelで処理してクライアントのViewに反映する流れとなる。

 だが,この構成では拡張性という点では不十分である。通常はクライアントからサーバーに要求を出してその応答を受け取る処理の流れになるが,リッチクライアント技術によってはそれにとどまらない。サーバーからクライアントにデータをプッシュする処理の流れもある(例えば,第7回で紹介するリアルタイム通信はこれに該当する)。その流れの場合,図1左の構成ではサーバーから受信したデータをクライアントのControllerで受け取れないので,データを加工してからViewに渡す,といった制御ができない。

 そこでセカンドファクトリーの三枝正稔氏(デベロップメントセンター テクニカルマネージャー)は,プッシュ通信でも利用できる図1右のモデルを採用した。クライアントのViewとModelの結合度を下げ,Controller経由で全情報をやり取りする。この構成ならば,サーバーからの情報をクライアントのModelで受け取りControllerへ転送,Controllerが表示(View)すべきか処理(Model)すべきかを判断できる。

 プッシュ通信に当面対応しないシステムでも,このモデルで設計しておけば,将来的に見直しがあったとき改修範囲を少なくできる。

工夫4 汎用的なインタフェースに

 サーバーとの通信設計の原則は,通信回数は少なく,そのうえでやり取りするデータ量は小さく――である。しかし旭化成メディカルの常盤正樹氏(透析事業部 課長)は,透析医療施設向けパッケージ「eカルテ棚@透析」のUI開発で,あえてそれを破った。

 常盤氏は,同ソフトのUI開発にFlashを利用したが,リッチクライアントの製品・技術が増えていたことから,「どの製品・技術が生き残るか分からない」と感じていた。Flashを選択した理由の一つは,ライセンス料が不要だからである。パッケージ製品なのでコストを抑えたい意向もあったが,将来の技術動向が読み切れない状況で大きな投資はできないとの判断だ。

 「いずれリッチクライアント技術を切り替えるかも」――。その前提に立ち,クライアント・アプリケーションとサーバー・アプリケーションの独立性を高めた。Flashにはバイナリ通信技術「Flash Remoting」が備わっているが,その採用を見送り,汎用的なインタフェースにした。データ量は増えるがXMLデータをHTTPSで通信する。「(バイナリ通信ならば)データ量が少なくなり高速に処理できると分かっていたが,クライアントとサーバーが密結合になる」(常盤氏)。

 通信回数を抑えるには,画像(JPEG)データとしてダウンロードした患者のカルテ情報は,クライアントにキャッシュした方がよい。だが,キャッシュしないようにHTTPリクエストに“no-cache”を指定した。「患者の個人情報をむやみにクライアントに残すわけにはいかない」(常盤氏)からだ。