はじめに
私達はプレゼンテーション(層の)技術に関する現時点での見解を徹底的に見直さなければなりません。というのは、何年にも渡ってさまざまな制約が加えられていたことでIT業界では正道から外れたデザイン・パターンがまるで当然であるかのように考えられているからです。このことが現代においてもよいアプリケーションを作ることの大きな障害となっているのです。この記事では、(静的なWebサイトの対照としての)Webアプリケーションが特徴となるシン・クライアントのパラダイムは"その場しのぎの解決策"であり捨て去らなければならないと考えています。なぜこのようなことを言うのか理解していただくためにインターネットが広まり始めた90年代半ばに立ち戻りましょう。
経緯
インターネットが一般に広まるに連れ、ほぼ同時に２つの相反する発展がありました。(1)アプリケーションを少ない労力で簡単に配布できるという意味でユビキタスなクライアント・サイドの"アプリケーション・プラットフォーム"としてのブラウザの圧倒的な重要さと(2)同じプラットフォーム(ブラウザ)から多くの可能性を奪ったベンダー依存による分裂です。後述するNetscape社とMicrosoft社によるブラウザ戦争によって(リンク)、２つの製品群はwebのレンダリングとJavaScriptコードの実行において全く異なる挙動をとるようになってしまったのです。webアプリケーションがもう片方のブラウザで動かないということが頭にくるくらい一般的でした。一方ではインターネットを通してユーザにアプリケーションを配布するという要求が増大し、もう一方ではその配布先が信頼性の低いプラットフォームであるという状況に直面して(IT)業界にいったい何ができたでしょう。
最も一般的なアプローチはブラウザの最小限の機能―シンプルな形式のwebページのレンダリング、ハイパーリンク、フォームの送信、などなど―だけに依存するということでした。そして全てのプレゼンテーション・ロジックをサービス提供側がコントロールできるシステムの一部―Webサーバへと移動したのです。ビジネス・ロジックとプレゼンテーション・ロジックを一つのプラットフォームに融合させる複雑さを補助しようと多くのサーバ・サイドのwebフレーム・ワークが登場し始めました。これらのフレーム・ワークの中ではStrutsが初期の成功例になるでしょう。今日では実に50以上ものフレーム・ワークが存在していて、それぞれが他の製品に対する優位性を主張しています。
しかし、このようなフレーム・ワークの影響については置いておきましょう。(フレーム・ワークは)確かにサーバ・サイドのプレゼンテーション・ロジックに秩序をもたらし合理化しましたが、それはただその場しのぎの解決策を不滅の物にしただけなのです。プレゼンテーション層の凝集度は低いです。なぜならプレゼンテーションに関する責務は、アーキテクチャに無意味な筋違いの理由により、ブラウザとwebサーバに分断されているからです。同時に、サーバ・サイドにあるプレゼンテーション・ロジックとビジネス・ロジックの結合度は高いのです。とりわけ最近のwebフレーム・ワークはサーバ・サイドのテンプレート、設定ファイル、アノテーションといった様々な要素からクライアント(へ渡す情報)をサーバ上で生成しています。これによって本来分かり易いはずの(アプリケーション)構築が複雑になっているのです。今となってはwebフレーム・ワークは不要だというだけではありません、それ(フレーム・ワーク)がどのシステムでも標準のコンポーネントとして容認されていることが、より良いアプリケーション構築をしようという私達の努力の足かせとなっているのです。
流行の兆し
歴史を打ち破る開発方法が直近だけで少なくても３つあります。
- 昔からある定理の新たな流行、つまり、サービス指向アーキテクチャ(SOA)として知られている方法はプレゼンテーション層の外観を間接的に変化させます。どう定義するにせよ、SOAはビジネス・ロジックのまとめ方を合理化し、統一的なインタフェースを提供します。優れたアーキテクチャはアプリケーションの別の側面をそれぞれがカプセル化した分離されたレイヤで構成されます。そしてSOAによってユーザ・インタフェース(UI)は真のプレゼンテーション層としてすっきりと構成されるのです。このレイヤは一切のビジネス・ロジックを含まず、ビジネス・サービスの利用者となります。
- webアプリケーションの歴史における最初の10年間を特徴づけたブラウザ間の分断はだいぶ解消されました。事実上ほとんどのモダン・ブラウザが業界標準に準拠しています。もはやムラのあるプラットフォームへの依存関係を最小限に抑える戦略は必要なくなったのです。今なら全てのプレゼンテーション・ロジックを本来あるべきブラウザに配置し、ベンダ依存の実装を気にすることなく正しく動作することを確信できるのです。
- XMLはシステム間のデータ交換におけるリンガアフランカ(国際共通語)となりました。現実的には、SOAというのはまずはやり取りをするXMLドキュメントの設計であり、次に、そのやり取りに必要な配管工事(ネットワーク環境の構築)をすることです。以前に比べXMLを扱いやすいツールがありますし、新しい言語(とりわけスクリプト言語)はXMLを標準のデータ型として扱えるようになっていて、XMLを使うことは苦痛とはほど遠いことになりました。これらの近代的なツールによりSOAに対応したシステムを構築することは以前に比べると理に適ったことになりました。
一般的なアーキテクチャ・モデルであるSOFEA(サービス指向フロント・エンド・アーキテクチャ)を通してこれら全ての進化の恩恵に授かることができます。面白いのは、シン・クライアントやwebモデルの陰に隠れていた、リッチ・クライアントという古いパラダイムがその両者を上回るよいアーキテクチャへの道筋を示しているということです。
新しいモデルの基本的な原理はプレゼンテーションの関心事をビジネス・ロジックの関心事から切り離すことです。ビジネス・ロジックの関心事についてはSOAの原理の範疇にあります。従ってプレゼンテーション層は、明確に定義されたサービス・インタフェースを通してサービス指向のビジネス層と適合していなければなりません。SOAをアーキテクチャ的に離れた2つの領域(それがマーケティングや金融であろうと、"レイヤ"という技術的な領域であろうとも)間における明確に設計された構造化データの交換であると捉えると、プレゼンテーション層がこのような原理から除外される理由がありません。
このような適合性における重要な要素の一つはアプリケーションの入口から出口までデータの完全性に配慮することです。これはつまり、最近の一般的なサービス提供のパラダイムであるSOAP/WS-*やRESTを利用して、XMLをXMLペイロードとして扱えなければならないことを意味します。
新しいパラダイムの構成要素
上の図はこのアーキテクチャにおける重要な物理コンポーネントと論理プロセスの関係を示しています。アプリケーション・コンテナはクライアント・サイドのアプリケーションが稼働するプラットフォームに対する一般的な呼称です。これは決してサーバ・サイドのコンポーネントではないというのが重要です。アプリケーションとはこのプラットフォーム上で稼動するコードのことを指します。アプリケーションはアプリケーション・コンテナの一部ではありません。
他の場所から提供され稼動前のある時点でアプリケーション・プラットフォームにロードされるのです。ダウンロード・サーバというのは実行前にローカル環境にインストールするためのアプリケーションをクライアント・プラットフォームに配信するコンポーネントを指す用語です。サービス・インタフェースはサービス層の標準的なインタフェースです。サービス層はプレゼンテーション層とビジネス・ロジック層でXMLベースのドキュメントを交換する一般的な仕組みを提供します。
クライアント側で行われる基本的な処理が三つあります。アプリケーション・ダウンロードとは起動前にアプリケーションをアプリケーション・コンテナ上に取得する処理のことです。普通、この処理は一回のみになりますが、実行時にこの処理を行うこともできます。必要に応じてダウンロード・サーバから表示画面をロードするのです。しかし、この後半の方法で設計されたアプリケーションは画面表示フローの制御をサーバー・サイドのwebフレーム・ワークで行うという伝統的なwebアプリケーションのようには振舞いません。画面やページをロードしたクライアント・アプケーションが引き続きフローも制御することになります。プレゼンテーション・フローはどの画面(もしくはチャンネル固有の生成物)がユーザに対して表示されるかというロジックを表しています。データ交換は(Schema定義に準拠したXML文書)データをプレゼンテーション層とサービス層の間で交換する
根拠
このモデルの背後にあるメイン・テーマは直行する関心事の分離です。このことは過去常にに求められてきましたが、クライアント・プラットフォームの制限のせいでこれまで一度もなし得ませんでした。ところがやっとアプリケーションは本来あるべき姿で実装できる状況に変わったのです。ビジネス・ロジックが取り去られることによりプレゼンテーション層はより小さくなり、凝集度が高まり、分かりやすくそして保守性が高まるのです。同じようにプレゼンテーション・ロジックが除かれることでサーバ・サイドにも利点があります。
このパラダイムの結果
- インピーダンス・ミスマッチが一切ないプレゼンテーション層とビジネス・ロジック層によりシームレスな統合による無駄のないアーキテクチャ・モデル
- "webサーバ"の役割を(初めて)合理化
- プレゼンテーション層の最も自然なデザイン・パターンとしてMVCをサポート
- アプリケーションにおける一貫したデータの一貫性の保証；"シン・クライアント"モデルと"リッチ・クライアント"モデルの統合
- SOAPベースとRESTベース、両方のサポート
- サーバはプレゼンテーション関連のロジックという重荷から解放され、これまでより軽く、薄くなる
- 同じビジネス・サービスに対する複数のユーザ・インタフェースが低いコストで構築可能
- プレゼンテーション層の生成物を再利用しなければならないプレッシャーの削減―もしビジネス層がうまく設計されていればプレゼンテーション層から適切なサービスを呼び出すことで十分な再利用を達成できます
技術例
.Ajaxフレームワーク(Dojo、 jQuery、 Ext、 など)、GWT、TIBCO GI、XForms、Mozilla XUL、Microsoft Silverlight／XAML、Java WebStart、JavaFX Script、Adobe Flex、OpenLaszlo、など。
結論
このモデルの成果は、もはや古く頑なに守られている妥協の産物を作ることはないということについて特に新しいことを紹介してはいません。どのようにして新しい技術によってアプリケーションが本来あるべき姿で構築できるようになるのかということを示そうとしました。これは遂に到達したパラダイムなのです。
原文はこちらです：http://www.infoq.com/jp/articles/rationalizing-presentation-tier