{ End Bracket }
リッチ アプリケーションとリーチ アプリケーション
Terry Crowley
リッチ (rich) アプリケーションとリーチ (reach) アプリケーションの違いは、これまでのところ明確でした。リッチ アプリケーションは本来コンピュータ上で実行され、ローカル グラフィック、CPU、メモリ、およびストレージ機能を利用してきました。リーチ アプリケーションは HTML で作成されてブラウザに展開され、システムへの依存を最小限に抑えていました。最近は、この境界線がぼやけてきています。AJAX アプリケーションは大量のコードをダウンロードし、洗練され、応答性の高いアプリケーションを提供できます。Flash、Silverlight™、および Google Gears などのランタイムを使用すれば、ローカルの CPU およびグラフィックス機能やローカル ストレージを利用したり、オフラインで実行したりすることのできるアプリケーションを作成できます。
リッチ アプリケーション側では、ClickOnce によるマネージ アプリケーションの展開機能や、Microsoft® SoftGrid® などのアプリケーションの仮想化およびストリーミング用ツールによって、本来のリッチ アプリケーションの面倒な展開が大幅に軽減されました。さらに重要なのは、リモート データと対話するリッチ クライアントの機能を強化し、より洗練されたものにすることです。Microsoft OneNote® がこの良い例です。OneNote は個人用のノートが取れるアプリケーションだと考えられていることが多いですが、サーバーまたはサービス上に保存されたノートブックを共有できる優れた "それだけで動く" 機能が用意されています。リモート データは透過的にバックグラウンドでキャッシュされ、ネットワーク接続が変化した場合でも、アプリケーションの応答性は常に維持されます。ローカル キャッシュにより、オフラインでのアクセスがサポートされます。変更はシームレスにマージされ、厄介な手動でのオーバーヘッドが生じることなしに、wiki と同様のコラボレーションが実現します。
HTML リーチ アプリケーションは、複雑さを "切り離し"、主なビジネスの問題に焦点を置くことで、迅速に展開するというメリットを最初に実現しました。機能が追加されるにつれ、複雑さも増します。AJAX アプリケーションが持つ非同期の本質は応答性の高いユーザー エクスペリエンスに不可欠ですが、複数の未解決の非同期対話およびユーザー エクスペリエンスに対するそれらの影響の状態を管理することが複雑になる場合があります。
Model View Controller デザイン パターンは堅牢なプログラミング モデルを提供する点では優れていますが、サーバーとブラウザに分散された場合に、モデルとビューの間の境界線は拡張されます。ローカルでの応答性とオフライン機能を提供する場合は、モデルのより多くの部分をローカル クライアントに移動することが議論されますが、これによりサーバーとクライアントの境界が複雑になり、この境界を越えて状態および基になるアプリケーション モデルを管理するしくみが複雑になります。クライアントにダウンロードする必要のあるデータの量を最小限に抑えるようにし、その部分モデルをローカルでどのように操作するかを管理することは、本来ストレスの多い作業です。
JavaScript などのスクリプト言語は生産性を大きく向上できますが、リーチ アプリケーションで実行されるコードが大量になり複雑さが増えるにつれ、こうした複雑さを管理するために Silverlight での ECMAScript 4 または C# などの "大規模プログラミング" をサポートする言語がますます欠かせなくなってきています。筆者は何万行もの JavaScript コードを書いてアプリケーションを構築してきたチームに多大な尊敬の念を抱いていますが、JavaScript には何十年もの間取り上げられてきた大規模なアプリケーションの構造化に不可欠な言語機能が欠けています。
リーチ アプリケーションにオフライン機能を提供することを検討しているとき、ほとんどの人がこれをどれほど軽視しているかということに筆者は驚きました。ローカルにあるキーおよび値のストア、または簡単なデータベースへのアクセスが提供されて、それで終わりました。とんでもないことです。優れたアプリケーションには高度なセマンティック モデルがあります。高度なモデルであるほど、ローカル状態は複雑になり、そのローカル状態をマージしてサーバーに戻す処理 (ユーザー モデルなど) は複雑になります。
リモート データと対話するリッチ アプリケーションについて、筆者はいつも Microsoft の Pat Helland の次の言葉を思い出します。「私たちはアインシュタインの宇宙に住んでいるのですから、同時性などというものは存在しないのです。」2 フェーズ コミットなどのデータベース技術は、本来は同時性の錯覚を提供しようとするものですが、応答性と洗練されたスケーラビリティ機能が犠牲になります。
もっと良い方法は、システムの分散コンポーネントは常に "実世界の" 異なるビューを持つものであり、最終的にあまり高度な整合性を求めることはできないことを受け入れることです。これは、システムの分散コンポーネントの基になるモデルの整合性を常に維持するよう骨を折るのではなく (そして、結果として脆弱で応答しないシステムを構築するのではなく)、不整合性を受け入れ、堅牢性を維持しつつこれらの避けられない不整合性をどのように解決するかに尽力する必要があることを意味しています。このような疎結合モデルは多くの場合、最終的に優れたアーキテクチャ戦略となります。宇宙物理学がこの考えの中心基盤をなしていることを認識するのは良いことです。
結局、リーチ アプリケーションとリッチ アプリケーションの境界や機能の境目がなくなるにつれて、これらのアプリケーションを構築する開発者が直面する問題も収束していくことでしょう。困難な問題を解決している最中には、優れたデザイン戦略のほか、優れたツールも必要です。
Terry Crowley は Microsoft テクニカル フェローであり、Office 開発部門のディレクターです。彼は過去 25 年間にわたり Microsoft、Vermeer、Beyond、および BBN でインターネット対応の高度なアプリケーションを開発してきました。