第 2 章 Java Enterprise System のアーキテクチャ

この章では、Java Enterprise System の配備の基礎となるアーキテクチャ概念の概要について説明します。

この章では、論理層、インフラストラクチャサービスレベル、およびサービス品質という 3 つの次元に従って Java Enterprise System の配備アーキテクチャを分析するフレームワークについて説明します。Java Enterprise System コンポーネントのアーキテクチャの機能がわかるように、次の図に、これらの 3 つの次元を直交する軸として図式化して示します。3 つの次元のフレームワークは、ビジネスソフトウェアソリューションの優れた配備アーキテクチャを設計するための重要な鍵になります。

図 2-1 Java Enterprise System のアーキテクチャのフレームワークにおける 3 つの次元

この章では、図 2-1 に示した 3 つの各次元を個別に検討し、その後、3 つの次元を 1 つのフレームワークに統合します。この章で説明する内容は、次のとおりです。

「次元 1 : 論理層」

「次元 2 : インフラストラクチャサービスレベル」

「次元 3 : サービス品質」

「3 つの次元の統合」

次元 1 : 論理層

分散型アプリケーションの標準的なアーキテクチャでは、アプリケーションロジックを複数の層に分割します。これらの層によって、サービスプロバイダおよびコンシューマの順序付けされた連鎖として、コンポーネントの論理的および物理的な構成を表現します。通常、1 つの層に含まれるコンポーネントは、隣接するプロバイダ層のコンポーネントから提供されるサービスを消費し、隣接するコンシューマ層の 1 つまたは複数のコンポーネントにサービスを提供します。

次の図は、配備アーキテクチャの論理層の次元を示しています。

図 2-2 次元 1 : 分散型エンタープライズアプリケーションの論理層

論理層について

ここでは、図 2-2 に示した 4 つの論理層について簡単に説明します。この説明では、例として、J2EE^TM プラットフォーム (Java 2 Platform, Enterprise Edition) コンポーネントモデルを使用して実装されたコンポーネントを取り上げます。ただし、CORBA など、その他の分散型のコンポーネントモデルも、このアーキテクチャをサポートしています。

クライアント層

クライアント層は、エンドユーザーがユーザーインタフェースを通して直接アクセスするアプリケーションロジックによって構成されます。クライアント層のロジックには、ブラウザベースのクライアント、デスクトップコンピュータ上で実行される Java コンポーネント、または携帯型のデバイス上で実行される J2ME^TM プラットフォーム (Java 2 Platform, Micro Edition) モバイルクライアントが含まれることがあります。

プレゼンテーション層

プレゼンテーション層は、クライアント層に配信するデータを準備し、クライアント層からのバックエンドビジネスロジックへの配信の要求を処理するアプリケーションロジックで構成されます。通常、プレゼンテーション層のロジックは、HTML 配信または XML 配信用のデータを準備したり、処理の要求を受信したりする Java サーブレットコンポーネントや JSP コンポーネントなどの J2EE コンポーネントで構成されます。プレゼンテーション層には、ビジネスサービス層のビジネスサービスに対する、個人向けにカスタマイズされ、セキュリティ保護されたアクセスを提供できるポータルサービスが含まれることがあります。

多くの場合、プレゼンテーション層のコンポーネントは再利用が可能であり、カスタマイズしたり、アプリケーションにプラグインとして追加したりできます。また、フェイルオーバーやスケーラビリティに関するプレゼンテーションサービスをレプリケートしたり、ネットワークの帯域幅やコンピューティングリソースが最適化されるように、これらのサービスをコンピューティングノードにマッピングすることもできます。

ビジネスサービス層

ビジネスサービス層は、アプリケーションの主要な機能を実行するロジックで構成されます。これらの機能には、データの処理、ビジネスルールの実装、複数のユーザーの調整、データベースや旧バージョンのシステムのような外部リソースの管理などがあります。通常、ビジネスサービス層は、EJB コンポーネントやメッセージ駆動型 Beans (MDB) などのように、J2EE 分散型コンポーネントモデルに準拠している、密接に結合されたコンポーネントで構成されます。個々の J2EE コンポーネントは、在庫情報サービスや税額計算サービスなどの複雑なビジネスサービスを配信するように組み立てることができます。個々のコンポーネントおよびサービスの構成部品は、SOAP (Simple Object Access Protocol) インタフェース標準に準拠している、緩やかに結合した Web サービスとしてカプセル化することができます。ビジネスサービスは、エンタープライズカレンダサーバーのようなスタンドアロンサーバーとして構築することもできます。

ビジネスサービスの各種の実装では、特定のコンピューティングノード上での常駐および実行が可能な特定のアプリケーション機能をカプセル化します。この方法によって、再利用可能なコンポーネントをカスタマイズしたり、プラグインとしてアプリケーションに追加することが可能になります。プレゼンテーション層のロジックと同様に、フェイルオーバーやスケーラビリティに関するビジネスサービスのプロバイダをレプリケートしたり、ネットワークの帯域幅やコンピューティングリソースが最適化されるように、これらのサービスプロバイダをコンピューティングノードにマッピングしたりできます。

データ層

データ層は、ビジネスロジックで使用されるデータで構成されます。このデータは、データベース管理システムに格納されている持続アプリケーションデータであることも、LDAP (Lightweight Directory Access Protocol) データストアに格納されているリソース情報およびディレクトリ情報であることもあります。このデータには、外部ソースからのデータ供給や旧バージョンのコンピューティングシステムからアクセス可能なデータが含まれることがあります。

論理的および物理的な独立性

図 2-2 のプレゼンテーションサービス層とビジネスサービス層に示したサービスは、このモデルの中心となる部分です。これらのサービスは、多数のクライアントをサポートできる、マルチスレッド対応のソフトウェアプロセスです。これらのクライアントは、エンドユーザークライアントであることも、その他のサービスであることもあります。

図 2-2 に示したアーキテクチャの次元では、4 つの層の論理的および物理的な独立性が強調されています。この独立性により、ネットワーク環境内のさまざまなコンピューティングノード間でアプリケーションのロジックを簡単にパーティション分割することができます。

論理的な独立性: アーキテクチャモデルの 4 つの層は論理的な独立性を表している。つまり、1 つの層 (たとえば、ビジネスサービス層) のアプリケーションロジックを、他の層のロジックとは関係なく変更できる。プレゼンテーション層またはクライアント層のロジックを変更またはアップグレードしなくても、ビジネスロジックの実行を変更できる。このような独立性により、たとえば、ビジネスロジックを変更しなくても、新しいタイプのクライアントを導入できる

物理的な独立性: 4 つの層は物理的な独立性も表している。つまり、一般的に、異なる層のロジックは異なるハードウェアプラットフォーム上に (たとえば、CPU 構成、チップセット、オペレーティングシステムが異なるプラットフォーム上に) 配備する。この独立性により、個々のコンピューティング要件および最大限に拡張されたネットワーク帯域幅に最適に対応するように、コンピューティングノード上の分散型アプリケーションコンポーネントを実行することが可能になる

層によるアーキテクチャの例

アーキテクチャ設計での論理層の使用例として、Messaging Server によって提供される電子メール通信サービスを取り上げます。次の図に示すように、電子メールサービスは多数の Messaging Server コンポーネントを使用して実装されます。

Messaging Server の機能を論理的に独立したコンポーネントとして分割することで、これらのコンポーネントを 1 つの物理環境内にある別々のコンピューティングノードに分散させることが可能になります。物理的に分割すると、これらのコンポーネントのレプリケーションを簡単に実行したり、各コンポーネントにそれぞれ異なる可用性ソリューションを適用したり、各コンポーネントのセキュリティに異なる方法を採用することができます。

次元 2 : インフラストラクチャサービスレベル

分散型のエンタープライズアプリケーションの対話型ソフトウェアコンポーネントには、基本となるインフラストラクチャサービスのセットが必要です。これに基づいて、分散しているコンポーネント間で相互に通信したり、それぞれの動作を調整したり、セキュリティ保護されたアクセスを実装することなどが可能になります。分散型のサービスのこのようなセットによって、分散型コンポーネントを構築するときの基礎となるインフラストラクチャが形成されます。

分散型のインフラストラクチャサービス

概念的に説明すると、分散型のインフラストラクチャサービスとは、異なる多くのレベルに分散しているサービスのセットのことです。次の図に示すように、これらのサービスによって、配備アーキテクチャのインフラストラクチャサービスレベルの次元が構成されています。

図 2-4 次元 2 : 分散型のインフラストラクチャサービスレベル

図 2-4 に示したレベルは、最下位レベルのオペレーティングシステムサービスから最上位レベルのアプリケーションサービスや統合サービスまでの、さまざまな分散型サービス間の一般的な依存関係を反映しています。通常、各サービスはその下にあるサービスに依存し、その上にあるサービスをサポートします。

ただし、上位レベルのサービスは、中間のレベルに依存せずに、下位レベルのサービスと直接対話することができます。たとえば、一部の実行時サービスは、中間にあるサービスレベルを介さずに、プラットフォームサービスに直接依存する場合があります。また、図 2-4 に示したレベルは厳密に定義されたものではありません。監視サービスや管理サービスなどのその他のサービスレベルも、ここでの概念的な説明に含まれることがあります。

一般的に、図 2-4 に示したサービスは、下位レベルのプラットフォームサービス、上位レベルのアプリケーションサービス、およびミドルウェアサービスという 3 つのグループのいずれかに該当します。ミドルウェアサービスは、他の 2 つのグループの中間にあることから付けられた名前です。

次に、さまざまなサービスについて簡単に説明し、関連する場合には Java プログラミング言語のアーチファクトの参考情報も示します。図 2-4 の最下位レベルのサービスから順に説明します。

オペレーティングシステムプラットフォーム: コンピューティングノード上で実行されるすべてのプロセスに対する基本的なサポートを提供する。オペレーティングシステム (Solaris^TM オペレーティングシステム、Linux、Windows など) は、物理デバイスの他に、メモリ、スレッド、および JVM^TM (Java Virtual Machine) マシンのサポートに必要なその他のリソースを管理する

ネットワークトランスポート: 異なるコンピューティングノード上で実行される分散型のアプリケーションコンポーネント間の通信に対する、基本的なネットワークサポートを提供する。これらのサービスには、TCP や HTTP などのプロトコルに対するサポートも含まれる。上位レベルのその他の通信プロトコル (「メッセージ層」を参照) は、これらの基本的なトランスポートサービスに依存している

持続: スタティックデータ (ユーザー、ディレクトリ、設定などの情報) およびダイナミックアプリケーションデータ (頻繁に更新される情報) へのアクセス、およびその格納に対する基本的なサポートを提供する

メッセージング: アプリケーションコンポーネント間の同期および非同期の通信に対するサポートを提供する。同期メッセージングでは、メッセージをリアルタイムで送受信する。これには、J2EE コンポーネント間のリモートメソッドの呼び出し (RMI) や Web サービスとの SOAP 対話も含まれる。非同期メッセージングの通信では、直後に受信するコンシューマの準備状況に関係なく、メッセージを送信する。JMS (Java Message Service) や ebXML などの非同期メッセージングの仕様では、信頼性の保証およびその他のメッセージング方式をサポートする

実行時: J2EE モデルや CORBA モデルなどの分散型のコンポーネントモデルで必要となるサポートを提供する。実行時サービスには、密接に結合された分散型コンポーネントに必要なリモートメソッドの呼び出しの他に、コンポーネントの状態 (ライフサイクル) の管理、スレッドプールの管理、同期 (相互排他ロック)、持続サービス、分散するトランザクションの監視、分散する例外の処理などが含まれる。J2EE 環境では、これらの実行時サービスはアプリケーションサーバーまたは Web サーバーの EJB、Web、およびメッセージ駆動型 Bean (MDB) コンテナから提供される

セキュリティとポリシー: アプリケーションリソースへの安全なアクセスをサポートする。これらのサービスには、シングルサインオン機能の他に、分散しているリソースへのグループベースまたはロールベースのアクセスを管理するポリシーに対するサポートも含まれる。シングルサインオンを使用すると、ある分散型システム内の 1 つのサービスに対するユーザー認証を、同じシステム内の他のサービス (J2EE コンポーネント、ビジネスサービス、Web サービスなど) に自動的に適用できる

ユーザーの共同作業: ユーザー間の直接通信およびエンタープライズ内とインターネット環境内でのユーザー間の共同作業に対するサポートで重要な役割を果たすサービスを提供する。これらのサービスは、一般的にスタンドアロンサーバー (電子メールサーバーやカレンダサーバーなど) から提供されるアプリケーションレベルのビジネスサービスである

統合: 既存のビジネスサービスを集約するサービスを提供する。その手段として、ポータルと同様に既存のビジネスサービスにアクセスするための共通インタフェースを提供するか、これらのビジネスサービスを本稼動ワークフロー内で調整するプロセスエンジンによって統合する。統合は、異なる企業間における企業間 (B2B) 統合として行なわれることもある

Java Enterprise System の実装

Java Enterprise System によって、図 2-4 に示す分散型インフラストラクチャサービスの次元が実装されます。さまざまなレベルにおける Java Enterprise System コンポーネントの位置付けは、次の図のとおりです。

図 2-5 Java Enterprise System: 分散型のインフラストラクチャサービス

図 2-5 に示した分散型インフラストラクチャサービスの Java Enterprise System 実装は、分散型インフラストラクチャサービスのスタック内のさまざまなレベルでサービスを提供する独立したソフトウェアサーバー (システムサーバー) によって構成されています。これらのサービスは、多数のクライアントをサポートできる、マルチスレッド対応のサーバープロセスを提供します。



注	図 2-5 には、分散型のインフラストラクチャサービスの提供に直接的に関係しない多くの Java Enterprise System コンポーネントは記載されていません。これらのコンポーネントは、次のようなサポート機能を提供します。 Portal Server, Mobile Access はワイヤレスクライアントから Portal Server へのアクセスを提供する Portal Server, Secure Remote Access はエンタープライズファイアウォールの外にあるブラウザベースのクライアントから Portal Server へのアクセスを提供する Directory Proxy Server はエンタープライズファイアウォールの外にあるブラウザベースのクライアントから Directory Server へのアクセスを提供する Sun Cluster はインフラストラクチャサービスに高可用性を提供する。これについては、アーキテクチャのサービス品質の次元に関するセクションで説明する (「例: Sun Cluster」を参照)

Java Enterprise System サーバー

Java Enterprise System サーバーは、図 2-5 に示すすべてのレベルを一括して実行します。各システムサーバーは、分散型のエンタープライズアプリケーションを支援する特定のサービスまたはサービスのセットを提供します。これらのシステムサービス自体が、提供する各サーバーの特徴になります。各サーバーが提供するサービスの簡単な説明については表 1-1 を参照してください。

システムサーバー間の依存関係

インフラストラクチャ内で、一般的に各システムサーバーはその下にあるサーバーに依存し、その上にあるサーバーをサポートします。表 2-1 に、各種の Java Enterprise System サーバー間の具体的な依存関係を示します。この表では図 2-5 と同様に、上位のサーバーから順に記載しています。

表 2-1 Java Enterprise System サーバーの依存関係
Java Enterprise System コンポーネント	サポートするサーバー	依存するサーバー
Portal Server		Identity Server Application Server または Web Server Directory Server Portal Server のチャネルを使用するように設定されている場合 Calendar Server Messaging Server Instant Messaging
Messaging Server	Calendar Server (電子メール通知用) Portal Server (メッセージングチャネル用)	Identity Server (シングルサインオン用) Web Server (Web インタフェース) Directory Server
Instant Messaging	Portal Server (インスタントメッセージングチャネル用)	Identity Server (シングルサインオン用) Directory Server
Calendar Server	Portal Server (カレンダチャネル用)	Messaging Server (電子メール通知サービス用) Identity Server (シングルサインオン用) Web Server (Web インタフェース) Directory Server
Identity Server	Portal Server シングルサインオン用に設定されている場合 Calendar Server Instant Messaging Messaging Server	Application Server または Web Server Directory Server
Application Server	Portal Server Identity Server	Message Queue Directory Server (オプション)
Message Queue	Application Server	Directory Server (オプション)
Web Server	Portal Server Identity Server	Identity Server (オプション : アクセス制御)
Directory Server	Portal Server Calendar Server Messaging Server Instant Messaging Identity Server	なし

システムサーバーの構造

各 Java Enterprise System サーバーはそれぞれ異なるサービスを提供しますが、すべてのシステムサーバーに共通する特徴があります。一般的に、各システムサーバーでは次のような種類のソフトウェアコンポーネントまたはサブコンポーネントを使用します。

システムサービスサブコンポーネント

サポートサービスサブコンポーネント

共有コンポーネント

次の図にこれらのサブコンポーネントを図式化して示し、この後のセクションで各サブコンポーネントについて簡単に説明します。

システムサービスサブコンポーネント

各 Java Enterprise System サーバーから提供される主要なシステムサービスの概要は、表 1-1 にまとめています。

各サーバーでは、提供するサービスをそれぞれ独自の方法で実装しています。Java 言語で記述されるサーバーもあれば、C や C++ で記述されるサーバーもあります。また、1 つのサブコンポーネントを使用して固有のシステムサービスを実装するサーバーもあれば、多数のサブコンポーネントを使用するサーバーもあります。たとえば、Portal Server ではリライタ、デスクトップ、および NetMail の各サブコンポーネントを使用して、Portal Server の主要なシステムサービスを提供します。

サポートサービスサブコンポーネント

各システムサーバーには、システムサービスが依存する各種のサポートサービスを提供するサブコンポーネントが数多く含まれています。図 2-6 に示したサポートサービスは、通常、Java Enterprise System から提供される分散型のインフラストラクチャサービスに対応しています。たとえば、次のような依存関係があります。

接続サービスはネットワークトランスポートサービスに依存し、ミドルウェアメッセージングサービスを必要とする場合もある

セキュリティサービスは通常、持続サービスの他にアイデンティティサービスとポリシーサービスに依存する

リソースマネージャサービスはプラットフォームサービスに依存する

サポートサービスは、ほかの Java Enterprise System サーバーによって外部から提供されることもあります。ただし、多くの場合は、サーバーの内部にサポートサービスが実装されます。Java Enterprise System の目的は、共通の内部サービスを抽出して、これらをロガーサービスや通信サービスなどのようなシステムレベルのサービスとして実装することです。

共有コンポーネント

ほとんどの Java Enterprise System サーバーでは、サポートサービスのほかに、多数のローカルサービスにも依存しています。これらのサービスは、多くの場合、異なるオペレーティングシステム間の移植性を提供するために使用されます。これらのサービスの実体は、特定のコンピューティングノード上で実行されるすべてのシステムサーバーが使用できる共有コンポーネントとしてローカルにインストールされたライブラリです。Java Enterprise System の共有コンポーネントの例として、Java 2 Platform, Standard Edition (J2SE^TM プラットフォーム)、Netscape Portable Runtime (NSPR)、Network Security Services (NSS)、Network Security Services for Java (JSS) などがあります。完全なリストについては、「共有コンポーネント」を参照してください。

次元 3 : サービス品質

すでに説明したアーキテクチャの 2 つの次元 (論理層およびインフラストラクチャサービスレベル) では、主にアーキテクチャの論理的な面を定義しました。つまり、サービスをエンドユーザーに配信するためにどのような方法で対話するか、あるいはどのようなコンポーネントが必要であるかを定義しました。一方、配備されるソリューションで同様に重要な次元は、サービス品質の要件を満たすためのソリューションの機能です。

ビジネスの運営におけるインターネットサービスや e-コマースサービスの重要性が増しているため、これらのサービスのパフォーマンス、可用性、セキュリティ、スケーラビリティ、および保守性は、高いパフォーマンスを備えた大規模な配備アーキテクチャの重要な要件になりました。

言い換えると、多数の重要なサービス品質に関連するビジネス上の要件を満たすことが、配備アーキテクチャにとって重要な次元になりました。この品質は、次の表にまとめたサービス品質の要件を指定するために最もよく使用されます。

表 2-2 次元 3 : 配備アーキテクチャに影響を与えるサービス品質
システムの品質	説明
パフォーマンス	ユーザーの負荷条件に関する応答時間の測定
可用性	システムのリソースやサービスがエンドユーザーにアクセス可能になる頻度、およびシステムの稼働時間として認識される頻度の測定
セキュリティ	システムとそのユーザーの整合性を記述する要素の複雑な組み合わせ。セキュリティには、セキュリティ保護された情報のトランスポート、およびユーザーの認証と承認が含まれる
スケーラビリティ	配備されたシステムに対して、随時、容量を拡張したりユーザーを追加したりする機能。通常、スケーラビリティにはシステムへのリソースの追加が含まれるが、追加時に配備アーキテクチャを変更する必要はない
潜在的な容量	システムでリソースを追加せずに、異常なピーク負荷使用を処理する機能
保守性	配備されたシステムを簡単に管理できる機能。システムの監視、発生した問題の修復、ハードウェアおよびソフトウェアのコンポーネントのアップグレードなどの作業が含まれる

配備アーキテクチャに影響を与えるシステムの各種の質は、密接に関連しています。1 つのシステムの質に関する要件は、他のシステムの質に関する要件や設計に影響を与えることがあります。たとえば、セキュリティのレベルを上げるとパフォーマンスに影響を与える可能性がありますが、これに伴って可用性にも影響が生じます。可用性の問題に対処するためにサーバーを追加すると、保守コスト (保守性) に影響を与える可能性があります。

ビジネスの要件と制約の両方を満たすアーキテクチャを設計するには、システムの複数の質が相互に関連する仕組み、およびこれらのかね合いを理解しておくことが重要です。

サービス品質の要件の適用

表 2-2 に示したシステムの質に対するサービス品質の要件は通常、システム全体のレベルで記述されます。つまり、システム全体に適用されます。ただし、ソフトウェアシステムの全体的な機能は、システム内のさまざまなアプリケーションコンポーネントやインフラストラクチャコンポーネント間の複雑な対話の結果です。

このため、サービス品質の要件は通常、1 つのアーキテクチャ内のすべてのインフラストラクチャサービスレベルで、すべての層に対して適用されます。多くの場合、これらの要件は、コンポーネント単位でコンポーネントに適用されます。

たとえば、高可用性を想定しているシステムの場合、障害発生の可能性がシステム内でもっとも高いポイントを検討し、他への影響がもっとも大きいこれらの障害への対策にまず重点を置く必要があります。このようなハイリスクのコンポーネントに対する高可用性ソリューションは、使用頻度が低いコンポーネントまたはシステム全体に影響する障害が発生しないコンポーネントに対する高可用性ソリューションよりも、要求される条件が厳しくなります。

同じような問題は、パフォーマンス、セキュリティ、およびスケーラビリティを検討するときにも発生します。システム内の潜在的な弱点やボトルネックを理解し、システム内の各コンポーネントに適切なアーキテクチャソリューションを組み込むには、十分な分析が必要です。

例: Sun Cluster

Java Enterprise System コンポーネントの 1 つである Sun Cluster が、サービス品質のアーキテクチャの具体的な次元に対応しています。

Sun Cluster ソフトウェアは、Java Enterprise System および Java Enterprise System インフラストラクチャに基づいたアプリケーションに対する高可用性サービスおよびスケーラビリティサービスを提供します。

クラスタは、緩やかに結合したコンピューティングノードのセットであり、サービス、システムリソース、およびデータの単一のクライアントビューを一括して提供します。クラスタの内部では、冗長コンピューティングノード、インターコネクト、データ格納域、およびネットワークインタフェースを使用して、クラスタベースのサービスおよびデータに高可用性を提供します。クラスタソフトウェアは、メンバーノードおよびその他のクラスタリソースの健全性を継続的に監視し、内部の冗長性を利用して、障害の発生時にもクラスタリソースへのほぼ連続するアクセスを提供します。

また、Cluster エージェントはクラスタによってホストされるソフトウェアサービスを継続的に監視します。障害の発生時に、これらのソフトウェアエージェントはフェイルオーバーとして機能するか、監視しているサービスを再起動します。Cluster エージェントはすべての Java Enterprise System サーバーに対応しているので、Java Enterprise System インフラストラクチャの最上位で実行される分散型のコンポーネントまたはサービスの実装用としてカスタム Cluster エージェントを記述できます。Cluster ソフトウェアは、このようにして高可用性サービスを提供します。なお、これはサービスレベルでの高可用性であり、セッションレベルのフェイルオーバー機能は提供されていません。

Cluster ソフトウェアによる制御が行なわれるので、クラスタでスケーラビリティサービスを提供することもできます。クラスタのグローバルファイルシステムおよびクラスタ内の複数のノードの機能を利用して、インフラストラクチャサービスやアプリケーションサービスを実行することにより、サービスの複数の並行インスタンス間で、これらのサービスに対して増加する要求のバランスを取ることができます。したがって、正しく設定されていれば、Cluster ソフトウェアは分散型のエンタープライズアプリケーションに高可用性とスケーラビリティの両方を提供できます。

Cluster サービスをサポートするには冗長性が必要となるため、ソリューションに Cluster サービスを組み込むと、ユーザーのコンピューティング環境に与える影響が大きくなります。つまり、Cluster サービスを組み込むと、ユーザーの物理トポロジで必要となるコンピューティングノードとネットワークリンクの数が大幅に増加します。

Java Enterprise System サーバーから提供されるサービスとは異なり、Cluster サービスは分散型のピアツーピアサービスです。したがって、Cluster ソフトウェアは、クラスタ内のすべてのコンピューティングノードにインストールする必要があります。

3 つの次元の統合

ここまでの各セクションでは、アーキテクチャの 3 つの次元について個別に説明してきましたが、これらを統合すると、アーキテクチャ設計におけるアプリケーションやインフラストラクチャコンポーネントの役割の理解に役立つフレームワークが形成されます。

基本的に、配備アーキテクチャの各論理層 (最初の次元) 内の分散型コンポーネントは、適当なインフラストラクチャサービス (2 番目の次元) からサポートされている必要があります。この 2 つの次元のマトリックス内にある各コンポーネントは、サービス品質 (3 番目の次元) の要件を満たすように配備する必要があります。

次の図に、これらの 3 つの次元が統合された状態を概念的に示します。

図 2-7 Java Enterprise System アーキテクチャにおける 3 つの次元の統合

このフレームワークで、たとえば Directory Server はバックエンドおよび下位レベルの Java Enterprise System コンポーネントとして分類されます。したがって、その他の多くのコンポーネントは Directory Server に依存することになり、Directory Server に障害が発生すると、ビジネスシステムに非常に大きな影響が生じます。このため、Directory Server は高可用性である必要があります。

Directory Server はユーザーや設定に関する機密情報の格納に使用されるため、セキュリティが侵害された場合にも重大な影響が生じます。このため、Directory Server および使用するすべての通信チャネルに高度なセキュリティ保護を適用する必要があります。

図 2-7 に示したアーキテクチャのフレームワークを使用する設計方法の概要は、このマニュアルでは扱っていません。ただし、3 次元のアーキテクチャを見ることで、Java Enterprise System 使用による分散型エンタープライズ配備の提供を理解するうえで重要な Java Enterprise System の一面が明らかになります。

前へ目次索引次へ
Sun Java Enterprise System 2004Q2 技術の概要