分散型エンタープライズアプリケーションの相互に作用するソフトウェアコンポーネントは、いくつかの論理層に存在するとみなすことができます。これらの層は、提供するサービスの性質に基づいて、ソフトウェアコンポーネントの論理的および物理的な独立性を表しています。
ソリューションアーキテクチャーの論理層の次元を、次の図に示します。
論理層アーキテクチャーは基本的に、図 1–1 の分散型エンタープライズアプリケーション層を表します。「インフラストラクチャーサービスレベル」で説明した Java ES システムサービスコンポーネントは、図 2–4 に示したすべての論理層に含まれるアプリケーションコンポーネントをサポートします。ただし、論理層の概念は、Messaging Server や Calendar Server など、アプリケーションレベルのサービスを提供するシステムサービスコンポーネントにも当てはまります。
ここでは、図 2–4 に示した 4 つの論理層について簡単に説明します。この説明では、J2EETM プラットフォーム (Java 2 Platform, Enterprise Edition) コンポーネントモデルを使用して実装されたコンポーネントを取り上げます。ただし、CORBA など、その他の分散型のコンポーネントモデルも、このアーキテクチャーをサポートしています。
クライアント層: クライアント層は、エンドユーザーがユーザーインタフェースを通して直接アクセスするアプリケーションロジックによって構成されます。クライアント層のロジックには、ブラウザベースのクライアント、デスクトップコンピュータ上で実行される Java コンポーネント、または携帯型のデバイス上で実行される J2METM プラットフォーム (Java 2 Platform, Micro Edition) モバイルクライアントが含まれることがあります。
プレゼンテーション層: プレゼンテーション層は、クライアント層に配信するデータを準備し、クライアント層からのバックエンドビジネスロジックへの配信の要求を処理するアプリケーションロジックで構成されます。プレゼンテーション層のロジックは通常、Java サーブレットコンポーネントや JSP コンポーネントなどの J2EE コンポーネントから構成されます。これらのコンポーネントは、HTML 形式や XML 形式の配信用データを準備したり、処理要求を受信したりします。また、この層にはポータルサービスが含まれることもあります。ポータルサービスは、ビジネスサービス層のビジネスサービスへのパーソナル化、セキュリティー保護、およびカスタマイズされたアクセス機能を提供できます。
ビジネスサービス層: ビジネスサービス層は、アプリケーションの主要機能を実行するロジックで構成されます。それらの機能には、データの処理、ビジネスルールの適用、複数ユーザーの調整、データベースや旧バージョンシステムのような外部リソースの管理などがあります。通常、この層は、Java オブジェクト、EJB コンポーネント、メッセージ駆動型 Beans などの J2EE 分散型コンポーネントモデルに準拠する、密接に結合されたコンポーネントで構成されます。個々の J2EE コンポーネントは、在庫情報サービスや税額計算サービスなどの複雑なビジネスサービスを配信するように組み立てることができます。個々のコンポーネントやサービスアセンブリは、サービス指向アーキテクチャーモデル内で緩やかに結合された、SOAP (Simple Object Access Protocol) インタフェース標準に準拠した Web サービスとしてカプセル化できます。ビジネスサービスは、エンタープライズカレンダサーバーやメッセージングサーバーのような単独のサーバーとして構築することもできます。
データ層: データ層は、ビジネスロジックで使用される持続データを提供するサービスで構成されます。このデータは、データベース管理システムに格納されているアプリケーションデータであることも、LDAP (Lightweight Directory Access Protocol) データストアに格納されているリソース情報およびディレクトリ情報であることもあります。このデータサービスには、外部ソースからのデータ供給や旧バージョンのコンピューティングシステムからアクセス可能なデータが含まれることがあります。
図 2–4 に示したアーキテクチャーの次元は、コンポーネントの論理的および物理的な独立性に重点を置いており、4 つの異なる層として表現されています。これらの層は、ネットワーク環境内のさまざまなコンピュータ間でのアプリケーションロジックの区分を表しています。
論理的な独立性: アーキテクチャーモデルの 4 つの層は、論理的な独立性を表しています。ある層 (ビジネスサービス層など) のアプリケーションロジックは、ほかの層のロジックとは無関係に変更することができます。プレゼンテーション層またはクライアント層のロジックを変更またはアップグレードしなくても、ビジネスロジックの実行を変更できます。このような独立性により、たとえば、ビジネスサービスコンポーネントを変更しなくても、新しいタイプのクライアントコンポーネントを導入できます。
物理的な独立性: 4 つの層は、物理的な独立性も表しています。各層内のロジックは、それぞれ異なるハードウェアプラットフォーム上に (つまり、異なるプロセッサ構成、チップセット、およびオペレーティングシステム上に) 配備できます。この独立性により、個々のコンピュータティング要件および最大限に拡張されたネットワーク帯域幅に最適に対応するように、コンピュータ上の分散型アプリケーションコンポーネントを実行することが可能になります。
アプリケーションコンポーネントやインフラストラクチャーコンポーネントをハードウェア環境 (つまり、配備アーキテクチャー) にマッピングする方法は、ソフトウェアソリューションの規模や複雑さに応じて、さまざまな要因によって決定されます。小規模の配備の場合は、配備アーキテクチャーに含まれるのは数台のコンピュータのみである場合があります。大規模の配備の場合は、ハードウェア環境へのコンポーネントのマッピングには、各コンピュータの速度と演算能力、ネットワークリンクの速度と帯域幅、セキュリティーおよびファイアウォールの考慮事項、高可用性およびスケーラビリティーのためのコンポーネントのレプリケーションの方針などの要素を考慮する場合があります。
図 2–3 で示したように、Java ES インフラストラクチャーサービスコンポーネントは、分散型ソフトウェアソリューションの基盤となるインフラストラクチャーサポートを提供します。ただし、それらのソリューションの一部には、Java ES コンポーネントが直接提供するアプリケーションレベルサービスが含まれます。それらのソリューションは、論理層の設計方法を使用します。
たとえば、Messaging Server が提供する電子メール通信サービスは、いくつかの論理的に区別された Messaging Server 設定を使用して実装されます。これらの異なる設定はそれぞれ、一連の異なるサービスを提供します。メッセージングソリューションを設計するときには、これらの異なる設定は、次の図に示すように別々の論理層に存在する個々のコンポーネントとして表されます。
図 2–5 は、完全な論理アーキテクチャーを表しているわけではありません。図を簡略化するために、多くの Java ES コンポーネントが省略されています。コンポーネント間を接続する線は、対話を表します。
Messaging Server 機能を論理的に異なる層に分けることにより、Messaging Server の論理的に区別された設定を物理環境内の異なるコンピュータに配備できます。物理的に分離すると、サービス品質の要件 (「次元 3: サービスの品質」を参照) を柔軟に満たすことができます。たとえば、インスタンスごとに異なる可用性ソリューションを提供したり、Messaging Server 機能ごとに異なるセキュリティーを実装できます。