1990年代の中ごろからインターネットが普及し、企業間での通信でも利用されるようになり、前述したクライアントが利用するアプリケーションの問題を、HTMLとWebブラウザを使って解決しようとしました。標準でインストールされているWebブラウザを利用すれば、コストもあまり掛かりませんし、各クライアントにアプリケーションをインストールする手間やプラットフォームに依存せずに企業システムが運営できます。このときはHTMLを使ったクライアントシステムなので、「HTMLクライアント」「Webクライアント」と呼ばれます。
また、前述したC/Sモデルの「ファットクライアント」に対して、HTMLクライアントはあまり機能を必要としないため、「シン(thin、やせた、小さい)クライアント」とも呼ばれます。C/Sモデルでは、サーバとクライアントの「分散型処理システム」でしたが、シンクライアントではサーバが主に作業するので、メインフレーム時代と同じく「中央集権型システム」に戻ったのです。
しかし、このモデルにも欠点がありました。
HTMLをメインに使っているので、「ファットクライアント」のときに比べれば操作性や表現性が非常に落ちたのです。例えば、表データをボタン1つで並び替えたり、キレイな図版を作成したり、といった加工の部分が、HTMLベースだとなかなかうまくいかなかったのです。
HTMLではできない部分を補完するために、CSSやJSP、ASP、PHP、Perlなどのサーバサイドの技術が導入されましたが、複数の言語が交じった開発に問題が生じたり、Webブラウザによって動作したりしなかったり、と新たな問題が発生したのです(当時はInternet ExplorerとNetscape Navigatorの「第1次ブラウザ戦争」中で、Webブラウザによって表示が異なったり、独自の規格を生み出したり、とさまざまなトラブルが頻発していました)。
編集部注:第1次ブラウザ戦争の詳細を知りたい読者は連載第4回「いまさら聞けない“Web標準”、そしてXHTML+CSS」の「『Web標準? Webを標準化することかな?』」をご参照ください。
加えて、作業のたびにサーバサイドとデータのやりとりをするため、ネットワークに接続していないと作業はできませんでした。
「ファットクライアント」の分かりやすい操作性と高機能さ、「HTMLクライアント」の低コストで手間要らず、この2つの長所を取り入れて生まれたのが「リッチクライアント」です。このリッチクライアントは2003年後半ごろから注目を受け始め、リッチクライアントのサービスや商品が多数出現しました。が、技術的な問題もあり、なかなか一般的なものにはなりませんでした。
GoogleマップやGmailなどで話題を集めたAjaxの出現で、リッチクライアントは一気に脚光を浴びます。GmailやGoogleカレンダー、GoogleドキュメントなどはWebクライアントで手軽に操作ができるうえに、プラットフォームの制約は少なく、サーバサイドでデータを管理し、コストも掛からない点など先ほど挙げたリッチクライアントの特徴にぴったり当てはまりますね(Ajaxの参考・詳細はこちら)。
リッチクライアントを支える技術はAjaxだけではありません。代表的なものをいくつかピックアップして見てみましょう(アルファベット順)。
「Biz/Browser」はアクシスソフトが開発・販売をするリッチクライアントシステムです。ミッションクリティカルな業務…… つまり、24時間365日稼働している基幹業務システムに特化されています。業務専用端末に匹敵するといわれる入力画面を開発可能な点などが特徴です(参考・詳細はこちら)。
カール社が提供する、マサチューセッツ工科大学の出身者によって開発されたリッチクライアントツールです。オブジェクト指向の言語であり、HTMLのようなテキストフォーマットから2Dや3Dといったグラフィックスまで表現する能力を持っています。また先日、一部のオープンソース化が発表されました(参考・詳細はこちら)。
EclipseはIBM社が開発した、Javaをベースにした開発環境です。プラグインによって拡張でき、オープンソース化されています。このEclipseのGUI技術を使ったリッチクライアント用のプラットフォームがEclipse RCPで、RCPはRich Client Platformの略称です(参考・詳細はこちら)。
さらに次ページでは、リッチクライアント技術をいろいろ紹介します。まさに群雄割拠です。
Copyright © ITmedia, Inc. All Rights Reserved.