本ドキュメントでは、リッチクライアントについての説明を行っています。
クライアント側にクライアントシステムを導入し、クライアントシステムがサーバシステムと通信を行いながら処理していくシステムです。
クライアントにシステムを導入することにより、クライアント側で処理が行えるだけでなく、高い表現力や操作性などを実現できます。
HTML と Web ブラウザを利用したシステムです。 Servlet や JSP などの技術がこれに当たります。
クライアント/サーバ型システムの欠点であったクライアント側システムの配布の手間などがなくなり、 また実行環境が容易に準備できるため、初期導入や保守の手間が大幅に改善されました。
クライアント/サーバ型システムにしても、Web アプリケーションシステムにしても、それぞれにデメリットがあります。
さて、リッチクライアントとは何か?ということですが、一言で言えば、 クライアント/サーバシステムの表現力の高さ・操作性の良さと Web アプリケーションの配布のし易さを両立させたシステムです。
とても曖昧な表現ですが、そもそも明確なリッチクライアントの定義というものはなく、 表現力・操作性と配布のしやすさを両立させたシステムを指します。
リッチクライアントの定義自体が曖昧なため、リッチクライアント技術によって得手不得手に大きな差はありますが、 基本的には以下のようなメリットを持っています。
リッチクライアントと一口に言っても、リッチクライアント技術はいくつも存在し、 それぞれ得意分野・苦手分野などが異なります。
ただし、大別すれば2つの種類に分けることができ、それぞれ大まかな特性があります。
Web ブラウザにプラグインを導入することで実行可能なリッチクライアントです。
実行環境をプラグインできる Web ブラウザがあれば実行可能であるため、実行環境を整える手間がかかりません。
また、実行環境のアップグレードもプラグインアップグレードで済むため、OS に直接インストールする必要がありません。
クライアントにインストールされた独自の実行環境上で動作するリッチクライアントです。
独自の実行環境は、それ自体が多機能なことが多く、機能性・開発効率の面で期待できますが、 クライアントに実行環境をインストールする必要があるため、実行環境を整える手間は大きくなります。
いくつかのリッチクライアント技術の動作環境などについて以下にまとめました。
Flash | Ajax | EclipseRCP | Curl | Swing | ||
---|---|---|---|---|---|---|
開発言語 | ActionScript MXML Java + LZX JavaScript |
JavaScript xml HTML CSS |
Java SWT |
Curl | Java | |
タイプ | ブラウザベース | ブラウザベース | スタンドアロン | ブラウザベース スタンドアロン どちらも可能 |
スタンドアロン | |
ライセンス | 開発環境 | Macromedia Flash Professional 8(有償) Flex Builder(有償) IDE for Laszlo(無償) |
Web アプリケーションと同様の開発環境で開発可能 | Eclipse3(無償) | Surge Lab IDE(有償) | JDK(無償) |
クライアント実行環境 | Macromedia Flash Player(無償) OpenLaszlo(無償) |
Webブラウザのみで動作可能 | JRE(無償) | Surge RTE(無償) | JRE(無償) | |
その他 | Flexサーバライセンス(有償) | − | 営利目的の場合はJavaライセンス規約に従いライセンス料が発生する。 | Curlサーバライセンス(有償) | 営利目的の場合はJavaライセンス規約に従いライセンス料が発生する。 |
リッチクライアント技術でも、それぞれ得意分野・苦手分野は異なっています。
例えば Ajax で構築されたシステムとして有名なところに GoogleMap がありますが、 今までの Google を使い慣れた人ならば、非常に使いやすいインターフェースであると言えるでしょう。 これがもし Flash などで構築されたとしたら、パソコンに慣れていないエンドユーザにとって使いやすいものだったでしょうか?
このように、Ajax はユーザインターフェースが Web アプリケーションとほぼ同じであるため、 既にWeb アプリケーションシステムとして確立されたインターフェースを持つシステムであれば、 Flash などよりもユーザに受け入れられやすいと考えられます。
必要とするものが異なれば、どのリッチクライアントが良いかという判断も変わってきます。 それぞれのリッチクライアント技術の特性を見極めた上で、必要に応じて使い分けることが重要なのです。