リッチ・クライアントの胎動と現在
リッチ・クライアントの胎動
「リッチ・クライアント」の文字が初めて書面を飾ったのは、2003年7月号の『日経システム構築』の特集1「ブラウザに代わる選択肢」と記憶しています。記事には、Biz/Browserのほか、.NET Framework、Flash、Curl、PDF（Portable Document Format）、XFA（XML Forms Architecture）などが登場しています。Flashを開発した米Macromediaが、まだ米Adobe Systemsに買収されていない時代です。
同記事のタイトルは「操作性、互換性、性能、ソフト配布の問題を解消する」となっています。要約（リード）部の末尾には、「以前のクライアント/サーバー・システムでは当たり前にできていたことを実現する」との表現もあります。リッチ・クライアント技術が待望されていた時代背景が読み取れます。実際、この頃からリッチ・クライアント技術が話題にのぼり、企業での利用が加速していきました。
Webシステムが推進されたものの、使ってみると、C/Sシステム時代の操作性はとても望めません。「何とかならないのか」といったニーズの中、「リッチ・クライアント」は広まりました。C/Sシステムと同様の画面をHTMLだけで構築することなどできるはずもなかったので、リッチ・クライアントは救いの神だったのです。
リッチ・クライアントの現在と今後の動向
Ajax（Asynchronous JavaScript + XML）技術を「リッチ・クライアント」「RIA」の1種として説明することも多いですね。しかし、筆者はAjaxのことをリッチ・クライアントであるとは捉えていません。
Ajaxは、JavaScriptとXMLという技術によって、HTTP転送の非同期通信を可能にしています。ユーザーが次に行う画面操作を予測して、必要な情報をあらかじめバックエンドで（ユーザー操作とは非同期に）ダウンロードしておくという設計/開発手法を指しています。
一方、Biz/Browser、AIR、Silverlight、Curl、Nexawebなどは、開発ツールとフロント・エンジン（ランタイム・エンジン）を持つ開発/実行プラットフォームです。Webブラウザと連携して動作することも可能ですし、単体でも、オフラインでも動作します。Ajaxと比較するようなものではありません。
ランタイムを使うリッチ・クライアントは、Webブラウザだけで動作するAjaxと異なり、クライアント・ソフトの互換性の問題も解決します。
仮に、Webブラウザだけで画面を実現した場合、「クライアント環境によって動作が異なる」という問題が生じます。これは、異なるベンダーから複数のWebブラウザが提供されていることに起因しています。例えば、Internet Explorer（IE）ではうまく動くけれどもFirefoxではエラーになる場合や、IE同士でもバージョンが異なるとうまく動かない、といったことが起きます。
AjaxはWebブラウザの基本機能だけを利用した汎用技術であるため、上記の互換性の課題を内在しています。ベンダー依存を嫌ってオープンな汎用技術だけで構築する選択は当然あって然るべきですが、その結果として、システム更改のタイミングとは独立した外部環境の変化に応じて、その都度、検証/改修コストが発生しているのが現実です。
一方、実行環境として専用のランタイムを利用するBiz/Browserの場合は、外部環境の差異を吸収しており、Webブラウザに依存した互換性の問題が起こりません。このことだけでも、コスト面でのメリットをもたらしていると思っています。
一般に、システムのライフサイクルにおけるTCO（総所有コスト）の70％～80％が保守/運用コストと言われています。ユーザー企業は、本来コストをかけるべき業務改善などのシステム更改にこそ、お金や資源を使うべきです。
リッチ・クライアント製品はいずれも、適用できるシステム・アーキテクチャの幅が広いです。例えば、Biz/Browserを用いたユーザー事例の1つに、既存のHTML画面をBiz/Browserで補完した例があります。この例では、Biz/Browserで再開発した一部の画面UIを除き、構築済みのHTML画面をそのまま生かしました。このうえで、HTML画面とは独立してデータの送受信をするようにしました。
新規に画面を作らなくても構築済みのHTML画面で十分、というケースもあるため、Webブラウザ（HTML）との連携機能は重要です。また、Biz/Browserは、WebサービスのWSDL（Web Service Definition Language）を解釈して利用する機能も備えており、SOA（サービス指向アーキテクチャ）連携が可能となっています。
代表的なリッチ・クライアントの現状
リッチ・クライアント/RIAの技術は、数年前の「先端技術」段階から、「中核技術」へと移行し、すでに「成熟技術」の域にかかっています。以下では、現状のリッチ・クライアント技術を総括するとともに、今後の動向を推測します。
開発プラットフォームとして提供されているリッチ・クライアント製品の場合、システムの主な構成要素は、以下の3つに分けられます。
- クライアントPC上で動作させるフロント側アプリケーション
- サーバー側で動作するアプリケーション
- クライアント側/サーバー側アプリケーションの開発ツール（IDE）
なお、Biz/Browserの場合、一般的なWebシステムと同様にサーバーとクライアントが疎結合の関係となり（サーバーはHTTPデータ転送だけを実行する単なるWebサーバーであり）、サーバー側には専用の仕組みを持ちません。
代表的なリッチ・クライアント製品の概要は、以下の通りです。
【AIR】
Flash/Flexはクライアント動作においてWebブラウザ（Flash Playerプラグイン）が必須でしたが、AIRでは、専用のランタイムを用意してデスクトップ上でも動作が可能になりました。これにより、従来では実現できなかったファイル・システムへのアクセスやネットワーク検知、ローカルDB（内蔵するSQLite）へのアクセスなどを実現できます。開発言語としては、Web標準の技術に加えてActionScript、PDF、FlashVideoなどを利用できます。
【Silverlight】
AIRのアプローチとは逆に、もともとデスクトップ上で動作していたアプリケーション（.NET）をWebブラウザのプラグインの上でも動作可能としたものです。UIの記述にXAMLというXMLベースのマークアップ言語を用います。特徴的な機能として、Windows Mediaのデコーダが内蔵されており、WMVやWMAファイルを再生できます。また、DeepZoomという巨大なビットマップ・イメージを対話型に操作する技術を持っています。
【Curl】
Curl言語を用います。HTMLのようなテキスト・フォーマットから3D（3次元）グラフィックス、オブジェクト指向までを、この言語から利用できます。開発したアプリケーションの適用範囲をクライアント側に限定する開発スタイルも可能です（サーバーとの疎結合を実現できます）。また、クライアントPC上で複数のバージョンを共存させることができます。
【Nexaweb】
JavaとXMLをベースとした開発/実行プラットフォームです。Ajax版、Java版、オフライン版の3種類を用意しており、それぞれ、クライアント側アプリケーションの実行環境が異なります。メッセージ通信を管理する機能を備えており、サーバーから情報をプッシュ配信するシステム・アーキテクチャも実現できます。
【Biz/Browser】
国産のリッチ・クライアントです。JavaScript記法に似たCRS（Chain Reflection Script）という言語を用います。サーバー側とは完全に疎結合です。クライアントPC上で複数バージョンが共存することも可能で、特に日本において重要な印刷機能を持っています。
リッチ・クライアントの今後
今後、リッチ・クライアントを提供する各ベンダーにとってキーワードとなり得るのは、以下のようなものではないでしょうか。
- クロスプラットフォーム
- クロスデバイス
- 開発支援
どんなに良い機能を持っていても、開発者の生産性/保守性を高める支援ができなければ、プラットフォームとは言えません。また、リッチ・クライアントにおけるUI設計の範囲は広く、HTMLとは比べ物になりません。こうした理由から、「開発支援」の範疇もおのずと広くなります。
現状でも、Biz/Browserは、開発コードから画面設計書を起こす機能や、コーディング規約を支援する機能など、各種の開発支援機能を持っています。システム構築は、最終的に動けばそれでよいというものではなく、設計、開発、ドキュメント作成なども絡む作業です。これらを総合的に支援する機能は、ますます充実していくでしょう。
最近では、HTML5の話題が多くなっています。「HTML5があればFlashがいらなくなる」といったことも囁かれていますが、今のところはまだ、Flashを置きかえることはできないでしょう。
米GoogleのHTML5への移行や米MicrosoftのIE9での対応など、HTML5が今後どういった方向になるのかをウォッチしていく必要があります、Webブラウザ間の互換性が課題となる点は、過去と同じです。
HTML5のような技術が登場しても、その技術を支援するソフトウエアが回りを埋めなければ、ミッション・クリティカルな業務に利用できず、HP（ホーム・ページ）などの利用に留まってしまいます。
これでリッチ・クライアントの現状と動向に関する解説は終わりますが、第5回で予定しているモバイルをテーマにした解説において、技術面の補足などを含めて再度解説する予定です。
次回は、「日本の帳票文化とツール」と題し、画面とは別にWebシステムの課題である帳票/印刷について解説します。
