概念: Web アーキテクチャ パターン
トピック
最も一般的なパターンは次の 3 つです。
シン Web クライアント (Thin Web Client) - インターネット ベースのアプリケーションに主として使用されます インターネット ベースのアプリケーションでは、クライアントの構成のコントロールがほとんどありません。クライアントに必要なものは、(フォームが使用可能な) 標準的な Web ブラウザだけです。ビジネス論理はすべてサーバー上で実行されます。
ファット Web クライアント (Thick Web Client) - アーキテクチャ上重要な量のビジネス論理がクライアント コンピュータ上で実行されます。通常は、クライアントが動的 HTML、Java アプレット、ActiveX コントロールを利用して、ビジネス論理を実行します。サーバーとのコミュニケーションは依然として HTTP で行われます。
Web デリバリ (Web Delivery) - HTTP プロトコルを使用してクライアントとサーバーとのコミュニケーションを行うほかに、IIOP や DCOM などのその他のプロトコルを使用して、分散オブジェクト システムをサポートできます。Web ブラウザは主として、分散オブジェクト システムのデリバリとコンテナのデバイスとして機能します。
このリストは完全とは言い切れません。特に、技術革命が毎年発生していると思われる業界の場合は、完全とは言えません。確かに、高いレベルでは、Web アプリケーションの最も一般的なアーキテクチャ パターンを表現しています。どのパターンでも同様に、複数のパターンを 1 つのアーキテクチャに適用することが考えられます。
シン Web クライアント アーキテクチャ パターンは、インターネット ベースのアプリケーションに役立ちます。インターネット ベースのアプリケーションでは、最低限のクライアント構成のみを保証できます。クライアント ブラウザのページ要求の実現中に、すべてのビジネス論理がサーバー上で実行されます。
このパターンに最も適切な適用対象は、インターネット ベースの Web アプリケーション、またはクライアントが最低限の計算能力しか備えていないか、構成をコントロールしない環境です。
e-コマースのインターネット アプリケーションの大部分はこのパターンを使用します。なぜなら、十分なクライアント機能を持たないという理由だけでなんらかの分野の顧客を排除することは、ビジネス上好ましくないからです。通常の e-コマース アプリケーションは、できるだけ大きい顧客プールに到達しようとしますが、結局、Commodore Amiga ユーザーの財布も、Windows NT ユーザーの財布も同じ意味をもつのです。
シン Web クライアント アーキテクチャ パターンでは、主要なコンポーネントがサーバー上に存在します。多くの方法で、このアーキテクチャは最低限の Web アプリケーション アーキテクチャを表現します。主要なコンポーネントは次のとおりです。
クライアント ブラウザ-フォームが使用可能な標準的な HTML ブラウザ。このブラウザは、一般化されたユーザー インターフェイス デバイスとして機能します。シン Web クライアント アーキテクチャで使用する場合、ほかに提供されるサービスは、クッキーの受け入れと、クッキーを返す機能だけです。アプリケーション ユーザーは、このブラウザを使用して、Web ページ (HTML ページかサーバー ページ) を要求します。返されるページには、完全にフォーマットされたユーザー インターフェイス (テキストと入力のコントロール) が含まれ、このインターフェイスはクライアントのディスプレイ上でブラウザによって描画されます。システムとのユーザー相互作用はすべて、ブラウザを通じて行われます。
Web サーバー-すべてのクライアント ブラウザにとって最も重要なアクセス ポイント。シン Web クライアント アーキテクチャ内のクライアント ブラウザは、Web サーバー経由でのみシステムにアクセスします。Web サーバーは、Web ページ (静的 HTML ページまたはサーバー ページ) の要求を受け入れます。その要求に応じて、Web サーバーはサーバー サイドの処理を開始できます。サーバー スクリプト ページ (CGI、ISAPI、NSAPI のモジュール) が要求された場合、Web サーバーは、適切なスクリプト インタプリタまたは実行可能モジュールに処理を委譲します。どの場合も、HTML ブラウザでの描画に適した HTML フォーマットのページが出力されます。
HTTP 接続 - クライアント ブラウザと Web サーバーの間で使用される最も一般的なプロトコル。このアーキテクチャ要素は、クライアントとサーバーの間のコネクションレス タイプのコミュニケーションを表現します。クライアントとサーバーの間で情報が送信されるたびに、両者の間に新しい独立した接続が確立されます。HTTP 接続のバリエーションの 1 つは、Secure Sockets Layer (SSL) によるセキュア HTTP 接続です。このタイプの接続は、クライアントとサーバーの間で転送される情報を、公開鍵と秘密鍵の暗号化技術を使用して暗号化します。
HTML ページ - サーバー サイドの処理が行われないユーザー インターフェイスとコンテンツ情報を持つ Web ページ。通常、HTML ページには説明的なテキストが入ります (指示やヘルプの情報、または HTML 入力フォームなど)。Web サーバーが HTML ページの要求を受信すると、サーバーは単純にそのファイルを取り出し、フィルタ処理をせずに、要求側のクライアントに返します。
サーバー ページ - なんらかのサーバー サイドの処理が行われる Web ページ。通常、サーバー ページは、スクリプト ページ (Active Server Pages、Java サーバー ページ、Cold Fusion ページ) としてサーバー上に実装され、アプリケーション サーバー上のフィルタによって、または実行可能モジュール (ISAPI または NSAPI) によって処理されます。これらのページは、すべてのサーバー サイドのリソース (たとえば、ビジネス論理コンポーネント、データベース、レガシー システム、マーチャント アカウント システムなど) にアクセスできる可能性があります。
アプリケーション サーバー - サーバー サイドのビジネス論理を実行するための主要なエンジン。アプリケーション サーバーは、サーバー ページ内のコードの実行を担当し、Web サーバーと同じコンピュータ上に置くことができ、Web サーバーと同じプロセス空間内での実行さえ可能です。アプリケーション サーバーは、論理的には独立したアーキテクチャ要素です。なぜなら、ビジネス論理の実行のみを扱い、Web サーバーとは完全に異なる技術を使用できるからです。
次の図は、シン Web クライアント アーキテクチャの論理ビューのダイアグラムを示しています。

最小限のシン Web クライアント アーキテクチャ
最小限のシン Web クライアント アーキテクチャには、Web アプリケーションに通常は存在するいくつかの一般的なオプション コンポーネント、特にデータベースが欠落しています。ほとんどの Web アプリケーションは、データベースを使用して、ビジネス データの永続性を実現しています。データベースを使用して、ページそのものを格納する場合もあります (ただし、このようなデータベースの使用方法は、異なるアーキテクチャ パターンを表現します)。Web アプリケーションは、ビジネス データの永続性を実現するために複数の技術を使用できるので、このアーキテクチャ コンポーネントのラベルには、汎用性の高い用語である Persistence が使用されます。Persistence コンポーネントには、Transaction Processing Monitor (TPM) の使用可能な用途も含まれます。
システムにデータベースを接続する最も単純な方法は、サーバー ページ内のスクリプトに、Persistence コンポーネントへの直接アクセスを許可することです。この直接アクセスでさえ、標準的なデータ アクセス ライブラリ (RDO、ADO、ODBC、JDBC、DBLib など) を利用して、煩雑な作業を行います。この場合、サーバー ページには、データベース スキーマについての知識があります。リレーショナル データベース システムの場合は、必要な SQL ステートメントを作成、実行して、データベース内のデータにアクセスできます。小規模でそれほど複雑でない Web アプリケーションでは、これで十分なこともあります。しかし、大規模で堅牢なシステムの場合は、完全なビジネス オブジェクト レイヤを使用したほうが適切です。
ビジネス オブジェクト コンポーネントは、ビジネス論理をカプセル化します。このコンポーネントは、通常はアプリケーション サーバー上でコンパイル、実行されます。ビジネス オブジェクトのアーキテクチャ コンポーネントを持つことの利点の 1 つは、その他の Web サーバーまたはクライアント サーバーのシステムが、同じコンポーネントを使用して同じビジネス論理を呼び出せることです。たとえば、インターネット ベースの店頭では、すべてのコンシューマ作業にサーバー ページとシン Web クライアント アーキテクチャ パターンを使用し、請求部門では、データとビジネス論理へのより高度なアクセスを必要とし、Web ベースのシステムよりもクライアント サーバー システムの使用を希望する場合が考えられます。請求部門のシステムは、Web ベースの店頭と同じアプリケーション サーバー上で同じビジネス コンポーネントを利用できる上に、より高度な独自のクライアント ソフトウェアを使用できます。
リレーショナル データベースは、主流のビジネスでは最も一般的なタイプのデータベースなので、アプリケーション サーバーとデータベースの間に通常は追加のアーキテクチャ コンポーネントが存在します。そして、オブジェクトとリレーショナル データベースの間のマッピング サービスを提供します。このマッピング レイヤそのものは、さまざまな方法で実装できます。このコンポーネントについての詳しい説明は、本書の対象外です。
このアーキテクチャ パターンに一般的に追加されるその他のオプションは、レガシー システムとの統合、そして e-コマース アプリケーションの場合は、マーチャント アカウント システムです。どちらにアクセスする場合も、ビジネス オブジェクトが使用されます (または、形式的なビジネス オブジェクト コンポーネントを持たないシステムの場合は、アプリケーション サーバーが使用されます)。レガシー システムでは、会計システムや製造スケジュール計画システムを表現できます。マーチャント アカウント システムを使用すると、インターネット Web アプリケーションがクレジット カードによる支払を受け入れて処理することができます。オンライン マーケットへの参入を希望する中小企業が使用できるマーチャント アカウント システムは多数あります。大企業の場合はおそらく、このコンポーネントは、クレジット カードの要求を処理できる既存のシステムとのインターフェイスになるでしょう。
これらのオプション コンポーネントを配置すると、シン Web クライアント アーキテクチャ パターンの論理ビューがより完全なものになります。この論理ビューを次の図に示します。

シン Web クライアントの論理ビュー
Web アプリケーションのサーバー コンポーネントの大部分は、Web ベースでないアプリケーションにもあります。Web アプリケーションのバック エンドの設計とアーキテクチャは、メインフレーム システムやクライアント / サーバー システムの設計と違いがありません。Web アプリケーションでは、ほかのシステムと同じ理由で、データベースやトランザクション処理モニタ (TPM) を使用しています。Enterprise Java Beans (EJB) や Microsoft の Transaction Server (MTS) といった新しいツールと技術は、Web アプリケーションを想定して導入されましたが、それ以外のアプリケーション アーキテクチャにも同じように適しています。
Web アプリケーションのサーバー サイドのコンポーネントのアーキテクチャと設計は、クライアント サーバー システムの場合とまったく同じに扱われます。このアーキテクチャ パターンで重点が置かれているのは、Web、そして Web アプリケーション固有のコンポーネントなので、使用可能なバック エンド サーバー アーキテクチャの詳細なレビューは、このパターンの範囲外です。
このアーキテクチャ パターンの基本となる主要な動的性は、クライアントからの Web ページ要求に応答する場合にのみビジネス論理が実行されるということです。クライアントはシステムを使用するために、HTTP プロトコルを使用して Web サーバーに Web ページを要求します。要求されたページが、Web サーバーのファイル システム上の HTML ファイルである場合は、単純にこのファイルを取得して、要求側のクライアントに返します。
要求されたページがスクリプト ページである場合は、そのページには解釈可能なコードがあり、クライアントに返す前にこのコードを処理する必要があるので、Web サーバーはアプリケーション サーバーにこのアクションを委譲します。アプリケーション サーバーはページ内のスクリプトを解釈し、指示があれば、サーバー サイドのリソース (データベース、電子メール サービス、レガシー システムなど) と相互作用します。スクリプト コードは、アプリケーション サーバーと Web サーバーを通じて、ページ要求に付随する特殊な情報にアクセスできます。この情報は、ユーザーが入力したフォーム フィールドの値、ページ要求に付加されたパラメータなどです。最終的には、クライアントへの返送に適した、正しいフォーマットの HTML ページが作成されます。
このページは、ISAPI や NSAPI DLL のような実行可能モジュールの場合もあります。DLL (ダイナミック リンク ライブラリ) は、アプリケーション サーバーによって実行時にロードと実行が可能なコンパイルされたライブラリです。このモジュールは、スクリプト ページがアクセスできるページ要求についての詳細情報 (フォーム フィールドの値やパラメータ) と同じ情報にアクセスできます。
このパターンの動的な振る舞いのポイントは、ページ要求の処理中にのみビジネス論理が呼び出されることです。ページ要求が実現されると、その結果が要求側のクライアントに返され、クライアントとサーバーの間の接続が終了されます。要求の実現後にビジネス プロセスが残ることがありますが、通常はそのようなことはありません。
このタイプのアーキテクチャに最適なアプリケーションは、ユーザーが許容できる応答時間内 (そしてクライアント ブラウザに許可されるタイムアウトの値以内) にサーバー応答を完了できるアプリケーションです。この時間は通常はせいぜい数秒です。長く続くビジネス プロセスの開始と監視をアプリケーションがユーザーに許可する必要がある場合は、これは最適なアーキテクチャ パターンではないかもしれません。ただし、プッシュ技術を使用すると、長い間実行されるプロセスをクライアントが監視できます。たいてい、プッシュ技術は、サーバーのポーリングを定期的に行うにすぎません。
このアーキテクチャ パターンのもう 1 つの主な結果は、高度なユーザー インターフェイスの機能が限定されることです。ブラウザがユーザー インターフェイスのデリバリ メカニズム全体として機能するので、ユーザー インターフェイスのウィジェットとコントロールはすべてブラウザによって使用できなければなりません。一般的なブラウザの大部分、そして HTML の仕様では、これらはいくつかのテキスト入力フィールドとボタンに限定されています。一方、このようなユーザー インターフェイスの厳しい制限がプラス材料であると考えることもできます。シンプルなインターフェイスでも十分な場合は、かえってユーザー インターフェイスの機能が少ないために、開発チームが「かっこよい」「いかした」インターフェイスの開発に労力を費やさずに済むようになります。
ファット Web クライアント アーキテクチャ パターンは、シン Web クライアント パターンを拡張したものであり、クライアント サイドのスクリプトとカスタム オブジェクト (ActiveX コントロールや Java アプレット) を使用します。ファット Web クライアント パターンという名前が付けられたのは、クライアントがシステムのビジネス論理の一部を実際に実行できるので、単なる一般化されたユーザー インターフェイス コンテナ以上のものになるからです。
ファット Web クライアント アーキテクチャ パターンに最も適切な適用対象は、特定のクライアント構成とブラウザ バージョンを想定できること、高度なユーザー インターフェイスを必要とすること、特定の量のビジネス論理をクライアント上で実行できること、という条件の一部または全部を満たす Web アプリケーションです。シン Web クライアント パターンとファット Web クライアント パターンの違いのほとんどは、システムのビジネス論理の実行でブラウザが果たす役割にあります。
ファット Web クライアントの使用が必要になる強い動機は、強化されたユーザー インターフェイス機能、ビジネス論理のクライアント実行の 2 つです。高度なユーザー インターフェイスを使用すると、3D モデルの表示と変更や、財務グラフのアニメーション化ができます。ActiveX コントロールを使用して、クライアント サイドの監視機器との通信が可能になる場合もあります。たとえば、遠隔地の患者を毎日監視する必要がある機関が、血圧や血糖値などのバイタル サインを測定できる医療機器を使用すると、往診を週 2 回に減らすことができます。
クライアントが単独でビジネス論理を実行できる場合もあります。このような場合、プロセスの実行に必要なすべてのデータがクライアント上で入手できる必要があります。この論理は、入力されたデータの妥当性チェックのように単純なものが考えられます。日付の正確性をチェックしたり、ほかの日付と比較することができます (たとえば、生年月日は初診日より前であること)。システムのビジネスのルールによっては、これまで入力した値に応じて、一部のフィールドを入力可能にしたり入力不可にします。
クライアント サイドのスクリプト、アプレット、コントロール、プラグインの最も明白な用途は、インターネット上の、強化されたユーザー インターフェイスのフォームでの使用です。Java スクリプトは、多くの場合、HTML ページ内でボタンやメニュー項目の色またはイメージを変更するために使用されます。Java アプレットと ActiveX コントロールは、多くの場合、高度な階層ツリー表示のコントロールの作成に使用されます。
Shockwave の ActiveX コントロールとプラグインは、現在インターネット上で使用されている最も一般的なユーザー インターフェイス コンポーネントの 1 つです。これを使用すると、相互に作用するアニメーションが可能になり、魅力的なグラフィックスでインターネット サイトに趣きを添えることが主な使用目的ですが、シミュレーションの表示やスポーツ イベントの監視にも使用されます。
一部のインターネット サイトでは、Microsoft のエージェント コントロールを使用することによって、ブラウザ内でユーザーが Web サイト内を移動できるようにする音声コマンドを受け入れたり、アクションを実行しています。
インターネットから、ある医療ソフトウェア会社は、患者の記録と請求を管理するための Web ベースのイントラネット アプリケーションを開発しました。この Web ベースのユーザー インターフェイスは、クライアント サイドのスクリプトを多用して、データの妥当性をチェックし、サイト内でのユーザーの移動を助けています。スクリプトのほかにも、このアプリケーションはいくつかの ActiveX コントロールを使用して XML コンテンツを管理し、情報の主要なエンコーディング方式として使用しています。
クライアントとサーバーの間のコミュニケーションは、シン Web クライアント パターンの場合と同様に、すべて HTTP を使用して行われます。HTTP は「コネクションレス」タイプのプロトコルなので、ほとんどの場合は、クライアントとサーバーの間のオープンな接続はありません。ページ要求の間のみ、クライアントは情報を送信します。したがって、クライアント サイドのスクリプト、ActiveX コントロール、Java アプレットは、クライアント上のオブジェクトのみとの相互作用に限定されます。
ファット Web クライアント パターンは、特定のブラウザ機能 (ActiveX コントロールや Java アプレット) を利用して、クライアント上のビジネス論理を実行します。ActiveX コントロールがコンパイルされ、HTTP によってクライアントにダウンロード可能なバイナリ実行可能ファイルがブラウザによって呼び出されます。これらの ActiveX コントロールは本質的に COM オブジェクトなので、クライアント サイドのリソースを完全に支配できます。ActiveX コントロールは、ブラウザとクライアント システムそのものの両方との相互作用ができます。したがって、ActiveX コントロール (特にインターネット上のもの) は、通常は、信頼できる第三者機関によって「認証」されます。
一般的な HTML ブラウザの最新バージョンでは、クライアント サイドのスクリプトも使用できます。Java スクリプトや VB スクリプトで作成されたスクリプトを HTML ページに組み込むことができます。このスクリプト機能を使用すると、システムのビジネス論理の一部である可能性があるコードを、ブラウザそのものが実行 (または解釈) できます。「可能性がある」としたのは、クライアント スクリプトが、ユーザー インターフェイスの外来の側面だけに貢献し、実際にはビジネス論理の一部ではないことが非常によくあるからです。どちらの場合も、潜在的にアーキテクチャ上重要な要素 (すなわちスクリプト) があって、それらは HTML ページの内部に組み込まれ、そのように表現される必要があります。
ファット Web クライアント パターンは、実際はシン Web クライアント パターンを単に拡張したものなので、アーキテクチャ上重要な要素のほとんどは同じです。ファット Web クライアント パターンで追加された要素は、次のとおりです。
クライアント スクリプト - HTML フォーマットのページに組み込まれた JavaScript または Microsoft® VirtualBasic® スクリプト。ブラウザがスクリプトを解釈します。HTML、そしてブラウザがクライアント スクリプトに提供する Document Object Model インターフェイスは、W3C (インターネットの標準化団体) が定義しています。
XML 文書 - XML (拡張可能マークアップ言語) を使用してフォーマットされた文書。XML 文書は、ユーザー インターフェイス フォーマットを持たないコンテンツ (データ) を表現します。
ActiveX コントロール - クライアント スクリプト内での参照と、必要な場合にクライアントへの「ダウンロード」が可能な COM オブジェクト。その他の COM オブジェクトと同様に、クライアント リソースに完全にアクセスできます。クライアント コンピュータを保護するための主要なセキュリティ メカニズムは、認証と署名の使用です。ActiveX コントロールがクライアントにダウンロードされようとしているときに、ActiveX コントロールを受け入れないようにするか、ユーザーに警告するようにインターネット ブラウザを構成できます。認証と署名のメカニズムは、信頼できる第三者機関を通じて、そのコントロールの作成者の識別情報を単に確かめるだけにすぎません。
Java アプレット - ブラウザのコンテキストで実行される、自己完結型でコンパイル済みのコンポーネント。セキュリティ上の理由で、クライアント サイドのリソースにしかアクセスできません。Java アプレットは、高度なユーザー インターフェイス要素として使用されると同時に、ユーザー インターフェイス以外の目的 (XML 文書の解析や複雑なビジネス論理のカプセル化) にも使用されます。
Java Bean - 大規模で複雑なシステムに容易に組み込めるようにする特定のインターフェイスを実装する Java コンポーネント。Bean (豆) という用語は、このコンポーネントが持つ小さい性質と 1 つの目的を反映します。カップいっぱいのコーヒーを入れるには、普通は 1 個より多くの豆が必要です。ActiveX は、Microsoft 中心のアーキテクチャにおいて Java Bean と類似しています。
次の図は、ファット Web クライアント アーキテクチャの論理ビューのダイアグラムを示しています。

ファット Web クライアント アーキテクチャ パターンの論理ビュー
ファット Web クライアント パターンの主要な動的性には、シン Web クライアント パターンの動的性に加えて、クライアント上でビジネス論理を実行する機能が含まれます。クライアントとサーバーの間のコミュニケーションは、シン Web クライアント パターンと同様に、すべてページ要求の間に行われます。ただし、スクリプト、コントロール、アプレットを使用して、クライアント上でビジネス論理を部分的に実行できます。
ページは、クライアント ブラウザに送信されるときに、スクリプト、コントロール、アプレットを含むことができます。これらは単に、ユーザー インターフェイスの強化、ビジネス論理への貢献のために使用できます。最も単純なビジネス論理の使用法は、フィールドの妥当性チェックです。クライアント スクリプトを使用すると、入力情報が有効かどうかを調べるチェックを、1 つのフィールドだけでなく、特定の Web ページのすべてのフィールドで行うことができます。たとえば、ユーザーが自分のコンピュータ システムを構成できる e-コマース アプリケーションでは、スクリプトを使用すると、互換性のないオプションを指定できないようにすることができます。
Java アプレット と ActiveX のコントロールを使用できるようにするには、HTML ページのコンテンツ内で指定しなければなりません。これらのコントロールとアプレットは、ページ内のスクリプトとは関係なく動作するか、ページ内のスクリプトによって駆動されるようにできます。HTML ページ内のスクリプトは、ブラウザから送信される特殊なイベントに応答できます。こうしたイベントは、ブラウザが Web ページのロードをたった今完了したことや、ユーザーのマウスがページの特定の領域の上で今動いたことを示すことができます。
これらは、ブラウザの Document Object Model (DOM) インターフェイスにアクセスできます。このインターフェイスは、ブラウザへの、そしてページ内の HTML コンテンツへのアクセスを、スクリプト、コントロール、アプレットに与えるための W3C 標準です。Microsoft と Netscape によるこのモデルの実装は、動的 HTML (DHTML) です。DHTML は、DOM インターフェイスの単なる実装以上のものです。特定の DHTML にはイベントが含まれ、本書の執筆時点では、これは DOM Level 1 仕様書には含まれていません。
Document Object Model の中核には、XML 文書の処理専用のインターフェイスがあります。XML は、設計者が独自の特殊目的タグを作成できる柔軟性の高い言語です。DOM インターフェイスを使用すると、クライアント スクリプトが XML 文書にアクセスできます。
クライアントとサーバーの間での情報交換の標準メカニズムとして XML を使用することは、クライアント上での特殊なコンポーネントの使用によって可能になります。ActiveX コントロールまたは Java アプレットをクライアント上に置くと、単独で XML 文書の要求や送信ができます。たとえば、HTML ページに組み込まれた Java アプレットは、Web サーバーから XML 文書の HTTP リクエストを出すことができます。Web サーバーは、要求された情報を見つけて処理し、HTML 文書ではなく XML フォーマットの文書を返します。依然としてクライアント上の HTML ページ内で実行中のアプレットは、XML 文書を受け入れると、これを解析し、ブラウザ内の現在の HTML 文書と相互作用して、そのユーザー用のコンテンツを表示します。この一連の処理は、クライアント ブラウザ内の 1 つの HTML ページのコンテキストで発生します。
このパターンの最大の結果は、ブラウザ実装間での移植性です。すべての HTML ブラウザが Java スクリプトや VirtualBasic スクリプトをサポートするとは限りません。その上、ActiveX コントロールを使用できるのは、Microsoft Windows ベースのクライアントだけです。特定のブランドのクライアント ブラウザが排他的に使用される場合でも、Document Object Model の実装に微妙な違いがあります。
クライアント スクリプト、コントロール、アプレットが使用される際に、テスト チームは、サポートされるクライアント構成ごとに、完全なテスト シナリオを実行する必要があります。重大なビジネス論理がクライアント上で実行されるので、関与するすべてのブラウザで一貫して正しく動作することが重要です。すべてのブラウザが同じに動作するとは想定しないでください。同じソース コードでもブラウザが違えば動作が違うというだけではなく、ブラウザが同じでも、オペレーティング システムが違えば動作が一貫していない可能性があります。
Web デリバリ アーキテクチャ パターンという名前が付けられたのは、これがなければ従来の分散オブジェクト クライアント / サーバーであったシステムのデリバリ メカニズムとして Web が主として使用されるからです。このタイプのアプリケーションは、実際は、単に Web サーバーとクライアント ブラウザを重要なアーキテクチャ要素としてたまたま含んでいる分散オブジェクト クライアント / サーバー アプリケーションとして見ることもできます。このようなシステムが、分散オブジェクトを持つ Web アプリケーションなのか、それとも Web 要素を持つ分散オブジェクト システムなのかにかかわらず、最終的なシステムは同じになります。これらの 2 つの観点が同じシステムであるという事実、そして分散オブジェクト システムが慎重なモデリングを必要とするシステムとして常に見られてきたことにより、本書のテーマ、すなわち Web アプリケーションはほかのソフトウェア システムと同様のモデリングと設計が必要であるということがよりいっそう強調されます。
Web デリバリ アーキテクチャ パターンに最も適切な適用対象は、クライアントとネットワークの構成にかなりのコントロールがある場合です。このパターンは、インターネット ベースのアプリケーションに特に適しているわけではありません。なぜなら、インターネット ベースのアプリケーションでは、クライアント構成へのコントロールがまったくまたはほとんどないか、ネットワーク コミュニケーションの信頼性が低くなっているからです。
このアーキテクチャの最大の長所は、Web アプリケーションのコンテキストで既存のビジネス オブジェクトを利用できることです。クライアントとサーバーの間で直接的で永続的なコミュニケーションが可能なので、前に示した 2 つの Web アプリケーション パターンの制限を克服できます。クライアントを利用して、さらに多くのビジネス論理を実行できます。
このアーキテクチャ パターンを単独で使用することはまずありません。実際には、このパターンは、前に示したパターンの 1 つまたは両方と組み合わせて使用されます。典型的なシステムでは、高度なユーザー インターフェイスを必要としないシステムの部分、または大規模なクライアント アプリケーションをサポートできるほどクライアント構成が強くない部分に、前に示したアーキテクチャ パターンの 1 つまたは両方を利用します。
CNN Interactive Web サイトは、インターネット上で最もアクセス頻度の高いニュース サイトの 1 つです。パブリック アクセスの大部分は、従来のブラウザやストレート HTML 3.2 で行われますが、この Web サイトの背後には、ブラウザ、サーバー、分散オブジェクトで構成された高度な CORBA ベースのネットワークがあります。このシステムのケース スタディは、公開された分散型コンピューティングでした。
ある医療ソフトウェア会社が、患者、診療記録、請求を管理する Web アプリケーションを作成しました。このシステムの請求の側面は、ユーザー コミュニティ全体のきわめて小さい部分によってのみ使用されます。請求用のレガシー システムのほとんどは、FoxPro で作成されていました。この新しい Web ベースのシステムでは、古い FoxPro のレガシー コードを利用し、変換ユーティリティを使用してユーザー インターフェイスとビジネス論理用の ActiveX 文書を構築しました。その結果できたのは、患者と診療記録用のファット Web クライアント ベースの Web アプリケーションに、請求操作用の Web デリバリ ベースの Web アプリケーションを統合したシステムでした。
Web デリバリとその他の Web アプリケーション アーキテクチャ パターンとの最も重要な違いは、クライアントとサーバーの間のコミュニケーション方式です。その他のパターンでは、主要なメカニズムは HTTP でした。HTTP は、ユーザーとサーバーの間の相互作用作業に関して、設計者に厳しい制限を与えるコネクションレス プロトコルです。Web デリバリ パターンでアーキテクチャ上重要な要素には、シン Web クライアント パターンの説明で挙げられたすべての要素に加えて、次のものが含まれます。
DCOM - Distributed COM は、Microsoft の分散オブジェクト プロトコルです。これを使用すると、1 つのコンピュータ上のオブジェクトが、別のコンピュータ上のオブジェクトのメソッドと相互作用するか呼び出すことができます。
IIOP - Internet Inter-Orb Protocol は、インターネットで (または TCP/IP ベースのネットワークで) 分散オブジェクトと相互作用するための OMG の CORBA プロトコルです。
RMI (JRMP) - Remote Method Invocation は、ほかのコンピュータ上のオブジェクトと相互作用する Java の方法です。JRMP (Java Remote Method Protocol) は、RMI 固有のプロトコルですが、使用可能なプロトコルは必ずしもこれだけではありません。RMI は CORBA の IIOP を使用して実装できます。
次の図は、Web デリバリ アーキテクチャ パターンの論理ビューのダイアグラムを示しています。

Web デリバリ アーキテクチャ パターンの論理ビュー
Web デリバリ アーキテクチャ パターンの主要な動的性は、ブラウザを使用して、分散オブジェクト システムを提供することです。ブラウザは、ブラウザとは関係なくサーバー層内のオブジェクトと通信するビジネス オブジェクトとユーザー インターフェイスを含むために使用されます。クライアント オブジェクトとサーバー オブジェクトとのコミュニケーションは、IIOP、RMI、DCOM のプロトコルを使用して発生します。
Web ブラウザを使用しなければ分散オブジェクト クライアント サーバーであったシステムで Web ブラウザを使用することの主な利点は、ブラウザには、必要なコンポーネントをサーバーから自動的にダウンロードする機能が組み込まれていることです。新品のコンピュータをネットワークに接続する場合、互換性のある Web ブラウザさえあればアプリケーションの使用を開始できます。特殊なソフトウェアを手動でクライアントにインストールする必要がありません。なぜなら、そのような管理はブラウザがユーザーの代わりに行うからです。必要になった時点でコンポーネントがクライアント上で提供、インストールされます。Java アプレットと ActiveX コントロールの両方について、クライアントへの送信とクライアント上でのキャッシュが自動的にできます。(適切な Web ページをロードした結果として) これらのコンポーネントがアクティブ化されると、サーバー オブジェクトとの非同期コミュニケーションに関与できるようになります。
このパターンの最大の結果は、ブラウザ実装間での移植性です。このパターンを使用するには、信頼できるネットワークが必要です。クライアント オブジェクトとサーバー オブジェクトとの接続が HTTP 接続よりはるかに長く続くので、サーバーに散発的な障害が発生すると、ほかの 2 つのアーキテクチャでは問題になりませんが、このパターンでは深刻な問題になります。
|