J2EE関連の最新トピックをわかりやすく解説
J2EE Watch ［4］

導入段階を迎えたリッチクライアント（前編）

宮下知起
2004/9/4

J2EEプラットフォーム上でリッチクライアントを実現したいというニーズが増えている。しかし、多くのリッチクライアント技術はサーバ環境に大きく依存しないものとなっている。そこで今回から2回にわたり、注目を浴びるリッチクライアント製品について、2004年7月に開催されたソフトウェア開発環境展（SODEC)の取材情報も含めながら解説しよう。

---

　「リッチクライアント」が昨年（2003年）後半辺りからメディアやイベント、各種セミナーなどをにぎわしているが、ここに来て、リッチクライアントはいよいよ導入段階を迎えてきているようだ。野村総合研究所が今年5月に発表したリッチクライアントに関するユーザーの意識調査からもその傾向はうかがえる。調査によると、現在利用されているクライアントの中でリッチクライアントの割合は約13％、2年後のリッチクライアント率は現在の約2倍の28％という結果が出ている（出典：野村総合研究所 ニュースリリース「次世代の企業システムクライアントが検討段階から導入段階へ〜リッチ・クライアントに関するユーザ意識調査結果で判明〜」）。

　しかし、リッチクライアントの定義が広く正確に認知されたかについては疑問だ。リッチクライアントの定義は、ベンダによって異なっていたり、リッチクライアントを実現するテクノロジもさまざまであるため、その定義は分かりづらいものになっている。そこで本稿では、リッチクライアントとは何かを明確にし、現在登場している主要なリッチクライアント技術の特徴を紹介することにしたい。前編の今回は、リッチクライアントの定義と、リッチクライアント製品の分類について紹介しよう。後編では、主要なリッチクライアント製品を個別に紹介する。

■リッチクライアントというキーワードの発祥は？

　そもそも、リッチクライアントというキーワードは1990年代半ばに登場していたものだ。当時のリッチクライアントは、Dumb（ダム）端末やX端末、ネットワークアプライアンスなどのシンクライアント（Thin Client）で実現されるシステムに対し、PCなどのリッチなハードウェアリソースをクライアントに用いて実現されるクライアント／サーバ型システムのクライアント環境のことを指した。リッチクライアントは、ファットクライアントと呼ばれることもあった。

　CPUやメモリといった豊富なハードウェア資源を生かし、操作性や表現力の高いユーザーインターフェイスと業務処理を実装した豊か（Rich）なクライアントソフトウェア、もしくはクライアント環境全体のことをリッチクライアントといっていたわけだが、当時のリッチクライアントの背景には、PCの高性能化と低価格化があった。社内LANや専用回線によるネットワークの普及とともに、リッチなクライアントを生かしたクライアント／サーバが主流となったのだ。データの管理はサーバ側で中央集約型に行い、ユーザーインターフェイスとクライアント側で行った方がよい処理はクライアント側に実装するというモデルだ。

■HTMLクライアントの反省を受けて再登場

　1990年代後半になると、インターネットの普及とともに、クライアント環境の主流がWebブラウザとHTMLを利用したHTMLクライアントへと置き換わっていった。Webブラウザは、クライアントアプリケーションが抱えていた数々の問題を解決した。データだけでなく、ビジネスロジックとユーザーインターフェイスの生成をすべてサーバ側に集約することで、従来までクライアントアプリケーションが抱えていた大量クライアントへのアプリケーション配布の課題、クライアント管理の高コスト性の課題を解決した。特にクライアント数の多い大規模システムにおいては、TCO削減に大きく貢献した。

　しかし、その一方でHTMLクライアントは操作性において劣るという課題を露呈した。特に、データエントリ業務を中心とするレガシーからのHTMLクライアントへのマイグレーションが進むにつれ、（1）キーボードだけで操作できない、（2）画面遷移が多く操作性が悪い、（3）頻繁にサーバとの通信が発生しパフォーマンスが劣る、といった課題があらわになったのだ。コストは大幅に削減できたものの、特に多数の入力項目があるデータエントリ系の業務システムにおいては、入力生産性の低下が直接業務全体の生産性低下につながる。つまり、“システム投資のROIの観点からは、HTMLクラアントは有効ではないケースがある”ことが明確になってきた。

　また、OCRや大量の帳票を含むレガシーアプリケーションの場合、操作性が低下するだけでなく、HTMLクライアントにリッチな機能を実装するため開発コストが増大し、HTMLクライアントではマイグレーションが阻まれる結果となっている。

　こういったHTMLクライアントの反省を受けて登場したのがリッチクライアントだ。配布や管理が容易というWebブラウザをクライアントに用いるメリットを引き継ぎながら、キーボード操作ができ、操作性やビジュアルに優れたユーザーインターフェイスを備え、クライアント側でも処理を実装することでサーバ負荷や通信負荷を削減するという、クライアント／サーバにおけるクライアントソフトウェアと同様のメリットをもたらす数々の技術が、リッチクライアントというキーワードを伴って登場してきた。

■リッチクライアントの定義はベンダによってさまざま

　ところで、マイクロソフトの「スマートクライアント」やサン・マイクロシステムズの「Java Web Start」で実現するクライアントJavaアプリケーションを、リッチクライアントと呼ぶケースもあるようだ。マイクロソフトのスマートクライアントは、HTTP／Webサービスを使うことでアプリケーションの配布・管理を容易にするとともに、クライアント／サーバと同様にリッチな操作性を実現するものだ。クライアントにインストールされた.NET Frameworkが、HTTP／Webサービスへの対応とアプリケーションの実行環境、バージョン管理の機能を担う。

　Java Web Startも、スマートクライアントとモデルが似ている。SwingやAWT、SWTを使ったJavaアプリケーションをHTTPによってダウンロード、クライアント側で実行する。バージョン管理の機構をJava Web Startが担い、サーバ側のアプリケーションが更新されていなければクライアント側にダウンロード済みのJavaアプリケーションを実行、更新れていればダウンロードして実行する。

　スマートクライアントもJava Web Startも、ふたを開けてみれば従来のクライアントアプリケーションに、インターネット／イントラネットを介した配布、バージョン管理の自動化などの仕組みを追加したものということができるだろう。HTMLクライアントの延長線上にあるモデルではないだけに、そもそもの現在のリッチクライアントというキーワードが指し示す意味からは少し異なる領域のモデルであると筆者は考える。

　最近登場しているリッチクライアント技術の多くは、Webブラウザのプラグインモジュールやラインタイムを提供する。キーボード操作を可能にし、リッチなユーザーインターフェイスを実現するプログラムをクライアント側で実行する。これに該当するのが「Flash」（マクロメディア）、「Biz/Browser」（アクシスソフト）、「Curl」（カール・アジアパシフィック）、「Facado」（大洋システムテクノロジー）、「Nexaweb」（ヴィークスネットワーク）、「Visual Frame」（メディア情報開発）などだ。一方で、サーバ集中のアーキテクチャは残しながら、キーボード操作が可能でリッチなインターフェイスを実現する「FlyingServ J-Frame Server」（東芝ソリューション）のようなユニークな製品もある。

　FlashやBiz/Browser、Curlは、プラグイン環境の上でダウンロードされたプログラムが実行され、リッチなUIを実現する。一方で、NexawebやFacado、Visual Frameは、クライアント上にユーザーインターフェイスを実現するためのレンダラを置く。そして、サーバ側からXMLやXULの形式で送られる画面情報をレンダラが解釈し、クライアント側のUI描画を行う。FlyingServ J-Frame Serverの場合は、UIはサーバ上で実行されるため、クライアント側にはキーボード操作をハンドリングするためのモジュールが置かれているだけだ。このように、ベンダによって方法はさまざまであるため、「クライアント側でプログラムが実行されるのでなければリッチクライアントとはいえない」といった意見も出てきているようだが、リッチクライアントに最終的に求められるのはアーキテクチャの美しさではなく、エンドユーザーの利益だ。そのような議論に、筆者は意義を感じていない。

　ところで、「RIA」（Rich Internet Application）（“アール・アイ・エー”とも“リア”とも呼ばれる）というキーワードも、リッチクライアントと同じ意味で使われることが多い。2003年10月、アイ・ティ・フロンティア、ビジネスアーキテクツ、マクロメディアの3社が発起人となりRIAコンソーシアムが発足したが、同コンソーシアムはRIAを、デスクトップソフトウェアのリアルタイム性の高いユーザーインターフェイス、Webアプリケーションの容易な実装性、そしてインタラクティブコミュニケーションの表現力を兼ね備えたWebアプリケーションと定義している。マクロメディアの最近のメッセージでは、RIAはリッチクライアント技術を利用し、業務生産性の向上と顧客満足度を向上させたWebアプリケーションと定義しているようだ。また、RIAで実現した業務アプリケーションを「エンタープライズRIA」と呼ぶこともあるようだ。

■適用領域に応じてリッチクライアントを選ぶべき

　リッチクライアント製品は、ターゲットとするアプリケーションによって得意・不得意がある。大きくは、企業内における業務アプリケーションと、BtoCを中心とする顧客サービスの2つに分けることができるだろう。

　データエントリ業務に代表されるような業務アプリケーションでは、高い生産性を実現するために、キーボードを扱える高い操作性が求められる。一方で、Eコマースサイトのような顧客サービスにおいては、コンバージョンレートを向上させるために、商品やサービスの内容を簡単にそしてリアルに確認できるビジュアル性や使いやすいナビゲーションが求められる。前者の業務生産性に特化して考えられた製品はBiz/BrowserやVisual Frame、FlyingServ J-Frame Serverなどの国産リッチクライアント製品だ。

　後者の要件を満たす代表は柔軟なデザインとムービーによる表現力を備えたFlashということができる。Flashと同様にビジュアル性に優れるという点では、Curlも挙げられる。Curlの開発環境には豊富なAPIが容易されているため、自由度の高い3Dグラフィックスを実現する能力が非常に高い。特にリアルタイム性が要求されるグラフィック表示に強みを持ち、為替や株式など、リアルタイムに市場が変化する金融商品の取引用端末には適した特徴を持つ。同様にリアルタイム性とグラフ表現力に強いという点では、Facadoも挙げられる。Curlほどプログラミングの柔軟度は高くないが、あらかじめ用意されたコンポーネントでグラフを容易に実現できる。

　リッチクライアントのもう1つのメリットは、企業内アプリケーションにおいて、データの視覚化が分析力の向上をもたらし、経営判断のスピード化にもつながるという点だろう。今後、BIやOLAPにリッチクライアントが適用される可能性は高い。視覚化という点では、FlashやCurlが強みを発揮するといえる。

　企業内アプリケーション、BtoBにおけるもう1つのトピックとしては帳票がある。帳票機能をあらかじめ用意しているのはBiz/BrowserやVisual Frameだ。Flashについても、サードパーティーから帳票のためのコンポーネントが提供されている。また、Curlも柔軟なプログラミングが可能な特性を生かし、収縮可能な帳票画面の生成を得意とする。

■クライアントモジュールの配布とライセンスでも適用分野を考慮

　リッチクライアント製品のライセンスは、クライアントライセンスである場合が多い。大量クライアントの導入にクライアントライセンスを必要とする製品を選択した場合はコストに気を付ける必要がある。クライアントライセンスを必要とするのは、Biz/BrowserやCurlなどだ。

　一方でFlashはクライアントライセンスを必要としない。さらにFlashはWebコンテンツの世界ではGIFやJPEGなどの画像データ同様にメジャーなムービーデータであり、FlashのPCへのインストール率は非常に高い。そのため、大量のクライアント導入や、EコマースなどのBtoCサイトに適している。クライアントライセンスを必要としたり、独自のクライアントモジュールを配布する必要があるリッチクライアントは、BtoCには不適合といえるだろう。また、BtoBにおいても、取引先にクライアントライセンスの購入やモジュールのインストールを要求しなければならないので、柔軟性を欠くといえる。

■言語や開発環境もさまざまに異なる

　開発環境は、既存エンジニアのスキル確保の問題、開発生産性などを考慮しながら選択すべきだ。GUIで開発できる統合開発環境が充実しているか否か、使用する言語がエンジニアにとってなじみやすいか否かは重要な要素だ。

　Biz/BrowserではBiz/Designerという統合開発環境を用意している。画面をGUIで設計できるほか、イベントハンドラをJavaScriptによく似た言語で記述する。JavaScriptの理解があれば入りやすい。

　Flashの場合は、Flash MXというデザイナ向けのツールが提供されるほか、開発者向けにはMacromedia Flexが提供されている。Flexは、XMLのみでFlashの画面設計ができ、ロジックをActionScriptで記述する。ActionScriptはECMAScript準拠の言語であるため、JavaScript 1.4の理解があれば開発できる。Flexにも統合開発環境が提供される。Macromedia Flex BuilderはXML定義とFlash画面をリアルタイムに同期させながら開発できる。Flex BuilderはEclipseのプラグインとしても提供される（Flexは米国ではすでに出荷されている。日本国内では10月の出荷予定だ）。

　FlyingServe J-Frame Serverは、純然たるJavaアプリケーションを開発すればよい。同製品は、クライアントアプリケーションをサーバ側で実行し、生成された画面をクライアント側に返す。そのため、Webを意識したプログラミングは必要なく、クライアントJavaに慣れた開発者にはなじみやすいだろう。よって、開発にはEclipseなど、使い慣れた開発環境が使える。

　Facadoは実体はアプレットである。専用のEclipseプラグインが提供されるため、GUIによる容易な画面設計が可能だ。あらかじめ提供されるコンポーネントを使った開発スタイルをとるが、カスタマイズしたい場合は独自にアプレットを作成することになる。

　このように標準ベースの言語に準拠した製品もあれば、NexawebのようにXULとSVGで画面設計を行ったり、CurlのようにCurl言語を使用するものもある。Nexawebの場合、開発にはEclipseベースのNexaweb Studioが提供される。これもGUIベースでの容易な画面設計を可能にする。

　以上、前編ではリッチクライアントの定義と、リッチクライアント製品の簡単な分類を試みた。後編では、各リッチクライアント技術の詳細について解説することにしよう。

Java Solution全記事一覧

　

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）