test

Sun Java Enterprise System 2005Q4 技術の概要

Java Enterprise System アーキテクチャーのフレームワーク

Java ES コンポーネントは、分散型エンタープライズ版ソフトウェアソリューションの配備をサポートします。

ビジネス要件によって課されるパフォーマンス、可用性、セキュリティー、スケーラビリティー、および保守性のレベルで必要な機能を実現するには、これらのソフトウェアソリューションを適切に設計する必要があります。

分散型エンタープライズ版ソフトウェアソリューションの設計には、アーキテクチャーの次元の多くが関係します。それらの次元は、そのようなシステムの構築に使用される多数のソフトウェアコンポーネント間の対話をさまざまな観点から見ることができる観点を表します。特に、分散型システムの設計にはアーキテクチャーの次の 3 つの次元が関係します。

ソリューションアーキテクチャーのこれらの 3 つの次元を次の図に示します。

図 2–1 ソリューションアーキテクチャーの次元

論理層、インフラストラクチャーサービスレベル、およびサービス品質を備えた 3 次元フレームワークを示す図。

これらの 3 つの次元によって、ソフトウェアソリューションに必要なサービス機能とサービス品質の実現に必要な、アプリケーションコンポーネントとインフラストラクチャーコンポーネントの両方の、ソフトウェアコンポーネント間の関係を統合する単一のフレームワークを表します。

次の各項では、3 つの各次元を個別に説明し、その後、3 つの次元を 1 つのフレームワークに統合して説明します。

次元 1: インフラストラクチャーサービスの依存関係

分散型のエンタープライズアプリケーションの対話型ソフトウェアコンポーネントには、基本となるインフラストラクチャーサービスのセットが必要です。 これに基づいて、分散しているコンポーネント間で相互に通信したり、それぞれの動作を調整したり、セキュリティー保護されたアクセスを実装することなどが可能になります。ここでは、これらのインフラストラクチャーサービスを提供するためにいくつかの Java ES コンポーネントが果たす主な役割について説明します。

インフラストラクチャーサービスレベル

分散型のソフトウェアシステムを設計する場合、そのほとんどがカスタム開発コンポーネントで構成されるか、または追加設定の必要ない Java ES コンポーネントで構成されるかにかかわらず、多数のインフラストラクチャーサービスを組み込む必要があります。これらのサービスは、多数のレベルで機能します。

ソリューションアーキテクチャーのインフラストラクチャーサービスの依存関係の次元 を、図 2–2 に示します。この図に示されているレベルは、図 1–1 のインフラストラクチャーサービス層を詳細化したものです。

図 2–2 のサービス階層とサービス間の依存関係が、ソリューションの論理アーキテクチャーの重要な次元を構成します。これらのインフラストラクチャーサービスは、Java ES システムサービスコンポーネント (「システムサービスコンポーネント」を参照) の役割を理解するための概念上の基礎になります。

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

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

最下位レベルのオペレーティングシステムプラットフォームサービスから最上位レベルの統合サービスまでの分散型サービスインフラストラクチャーのレベルを示す図。

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

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

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

Java Enterprise System インフラストラクチャーサービスコンポーネント

Java ES コンポーネントは、図 2–2 に示した分散型インフラストラクチャーサービスレベルを実装したものです。Java ES システムサービスコンポーネントのさまざまなレベル内における位置関係を、図 2–3 に示します。

図 2–3 Java ES システムサービスコンポーネント

分散型のインフラストラクチャーサービスのさまざまなレベルにおける Java ES システムサービスコンポーネントの位置付けを示す図。

注 –

図 2–3 に示したオペレーティングシステムプラットフォームは正式には Java Enterprise System の一部ではありませんが、Java ES コンポーネントをサポートするオペレーティングシステムプラットフォームを示すために、この図に含めてあります。

Java Enterprise System インフラストラクチャーサービスの依存関係

一般に、図 2–3 に示した各 Java ES システムサービスコンポーネントは、インフラストラクチャー内でその下にあるコンポーネントに依存し、その上にあるコンポーネントをサポートします。それらの依存関係とサポートの関係は、論理アーキテクチャーを設計する上で重要な要素です。

表 2–1 に、Java ES システムサービスコンポーネント間の具体的な関係を示します。この表では図 2–3 と同様に、最上位から順に記載しています。

表 2–1 Java ES システムサービスコンポーネント間の関係

コンポーネント 

依存するサーバー 

サポートするサーバー 

Portal Server 

Application Server または Web Server 

Access Manager 

Directory Server 

対応するチャネルを使用するように設定されている場合Calendar Server Messaging Server Instant Messaging 

 

Messaging Server 

Directory Server 

Access Manager (シングルサインオン用) 

Calendar Server (電子メール通知用) 

Portal Server (メッセージングチャネル用) 

Instant Messaging 

Directory Server 

Access Manager (シングルサインオン用) 

Portal Server (インスタントメッセージングチャネル用) 

Calendar Server 

Directory Server 

Messaging Server (電子メール通知サービス用) 

Access Manager (シングルサインオン用) 

Portal Server (カレンダチャネル用) 

Access Manager 

Application Server または Web Server 

Directory Server 

Portal Server 

シングルサインオン用に設定されている場合: Calendar Server Messaging Server Instant Messaging 

Application Server 

Message Queue 

Directory Server (管理オブジェクト用) 

Portal Server 

Access Manager 

Message Queue 

Directory Server (管理オブジェクト用) 

Application Server 

Web Server 

Access Manager (アクセス制御用) 

Portal Server 

Access Manager 

Directory Server 

なし 

Portal Server 

Calendar Server 

Messaging Server 

Instant Messaging 

Access Manager 

Service Registry 

なし 

Applcation Server に基づくコンポーネント 

次元 2: 論理層

分散型エンタープライズアプリケーションの相互に作用するソフトウェアコンポーネントは、いくつかの論理層に存在するとみなすことができます。これらの層は、提供するサービスの性質に基づいて、ソフトウェアコンポーネントの論理的および物理的な独立性を表しています。

ソリューションアーキテクチャーの論理層の次元を、次の図に示します。

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

4 つの論理層を示す図。左からクライアント層、プレゼンテーション層、ビジネスサービス層、データ層。

論理層アーキテクチャーは基本的に、図 1–1 の分散型エンタープライズアプリケーション層を表します。「インフラストラクチャーサービスレベル」で説明した Java ES システムサービスコンポーネントは、図 2–4 に示したすべての論理層に含まれるアプリケーションコンポーネントをサポートします。ただし、論理層の概念は、Messaging Server や Calendar Server など、アプリケーションレベルのサービスを提供するシステムサービスコンポーネントにも当てはまります。

論理層について

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

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

図 2–4 に示したアーキテクチャーの次元は、コンポーネントの論理的および物理的な独立性に重点を置いており、4 つの異なる層として表現されています。これらの層は、ネットワーク環境内のさまざまなコンピュータ間でのアプリケーションロジックの区分を表しています。

システムコンポーネントに適用される層によるアーキテクチャー

図 2–3 で示したように、Java ES インフラストラクチャーサービスコンポーネントは、分散型ソフトウェアソリューションの基盤となるインフラストラクチャーサポートを提供します。ただし、それらのソリューションの一部には、Java ES コンポーネントが直接提供するアプリケーションレベルサービスが含まれます。それらのソリューションは、論理層の設計方法を使用します。

たとえば、Messaging Server が提供する電子メール通信サービスは、いくつかの論理的に区別された Messaging Server 設定を使用して実装されます。これらの異なる設定はそれぞれ、一連の異なるサービスを提供します。メッセージングソリューションを設計するときには、これらの異なる設定は、次の図に示すように別々の論理層に存在する個々のコンポーネントとして表されます。

図 2–5 Messaging Server: 層によるアーキテクチャーの例

4 つの論理層に分散している Messaging Server コンポーネントを示す図。

注 –

図 2–5 は、完全な論理アーキテクチャーを表しているわけではありません。図を簡略化するために、多くの Java ES コンポーネントが省略されています。コンポーネント間を接続する線は、対話を表します。

Messaging Server 機能を論理的に異なる層に分けることにより、Messaging Server の論理的に区別された設定を物理環境内の異なるコンピュータに配備できます。物理的に分離すると、サービス品質の要件 (「次元 3: サービスの品質」を参照) を柔軟に満たすことができます。たとえば、インスタンスごとに異なる可用性ソリューションを提供したり、Messaging Server 機能ごとに異なるセキュリティーを実装できます。

次元 3: サービスの品質

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

ソリューションアーキテクチャーのサービスの品質の次元は、Java ES サービス品質コンポーネントが果たす役割を明らかにします。

サービス品質

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

優れたソフトウェアソリューションを設計するには、適切なサービス品質要件を設定し、それらの要件を満たすアーキテクチャーを設計する必要があります。いくつかの重要なサービス品質により、サービス品質要件を指定します。これらのサービス品質を次の表に要約してあります。

表 2–2 ソリューションアーキテクチャーに影響するサービス品質

システムサービス品質 

説明 

パフォーマンス

ユーザーの負荷条件に関する応答時間の測定 

可用性

システムのリソースやサービスがエンドユーザーにアクセス可能になる頻度 (システムの「稼働時間」) の測定。

セキュリティー

システムとそのユーザーの整合性を記述する要素の複雑な組み合わせ。セキュリティーには、システムの物理セキュリティー、ネットワークセキュリティー、アプリケーションおよびデータのセキュリティー (ユーザーの認証および承認)、またセキュリティー保護された情報のトランスポートも含まれます。 

スケーラビリティー

配備されたシステムに対して、随時、容量を拡張する機能。通常、スケーラビリティーにはシステムへのリソースの追加が含まれるが、追加時に配備アーキテクチャーを変更する必要はありません。 

潜在能力

システムでリソースを追加せずに、異常なピーク負荷使用を処理する機能 

保守性

配備されたシステムの保守のしやすさ。 システムの監視、発生した問題の修復、ハードウェアおよびソフトウェアのコンポーネントのアップグレードなどが含まれます。 

サービス品質の次元は、ソリューションの配備アーキテクチャーに、つまりアプリケーションコンポーネントとインフラストラクチャーコンポーネントが物理環境内でどのように配備されるかに、大きな影響を与えます。

配備アーキテクチャーに影響を与えるサービス品質は、互いに密接に関係しています。あるシステム品質に対する要件がほかのサービス品質の設計に影響を与えることが、よくあります。たとえば、セキュリティーのレベルを上げるとパフォーマンスに影響を与える可能性がありますが、これに伴って可用性にも影響が生じます。冗長性を使用して可用性の問題に対処するためにコンピュータを追加すると、保守コスト (保守性) に影響を与える可能性があります。

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

Java Enterprise System サービス品質コンポーネント

システムサービスコンポーネントまたは分散型アプリケーションコンポーネントが提供するサービス品質を向上するために、主にいくつかの Java ES コンポーネントが使用されます。これらのソフトウェアコンポーネントは、多くの場合、ロードバランサやファイアウォールなどのハードウェアコンポーネントとともに使用されます。

「サービス品質コンポーネント」で紹介した Java ES サービス品質コンポーネントについて、次に要約します。

次の表は、アーキテクチャーの観点からの最も重要な Java ES サービス品質コンポーネントと、それらの各コンポーネントが最も影響を及ぼすシステム品質を示しています。

表 2–3 サービス品質コンポーネントと影響を受けるシステム品質

コンポーネント 

影響を受けるシステム品質 

Communications Express

セキュリティー

スケーラビリティー 

Directory Proxy Server

セキュリティー

スケーラビリティー

High Availability Session Store 

可用性

Portal Server, Secure Remote Access

セキュリティー

スケーラビリティー

Sun Cluster 

可用性

スケーラビリティー

Web Proxy Server 

セキュリティー パフォーマンス 保守性

Sun Cluster ソフトウェア

Sun Cluster ソフトウェアは、高可用性サービスおよび高スケーラビリティーサービスを、Java ES コンポーネントおよび Java ES インフラストラクチャーがサポートするアプリケーションに対して提供します。

クラスタとは緩やかに結合された一連のコンピュータのことであり、サービス、システムリソース、およびデータの単一のクライアントビューを一括して提供します。クラスタの内部では、冗長コンピュータ、インターコネクト、データ記憶域、およびネットワークインタフェースを使用して、クラスタベースのサービスおよびデータに高可用性を提供します。

Sun Cluster ソフトウェアは、メンバーノードおよびその他のクラスタリソースの健全性を継続的に監視します。障害が発生した場合、Sun Cluster ソフトウェアは監視対象のリソースのフェイルオーバーを開始するために介入し、内部の冗長性を使用して、リソースへのほぼ連続的なアクセスを可能にします。

Messaging Server および Calendar Server 用のデータストアサービスをサポートする 2 つのノードから成るクラスタを次の図に示します。

図 2–6 Sun Cluster ノードによる可用性の設計

Sun Cluster 可用性設計に含まれる冗長のコンピュータ、データストア、およびインターコネクトを示す図。

Sun Cluster データサービスパッケージ (Sun Cluster エージェントと呼ばれることもある) が、すべての Java ES システムサービスコンポーネントに利用できます。カスタム開発されたアプリケーションコンポーネント用のエージェントを記述することもできます。

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

Sun Cluster 環境をサポートするのに必要な冗長性のために、ソリューションに Sun Cluster を含めると、物理環境に必要なコンピュータやネットワークリンクの数がかなり増えます。

Sun Cluster の可用性サービスは、ほかの Java ES コンポーネントが提供するサービスとは異なり、分散型のピアツーピアサービスです。したがって、Sun Cluster ソフトウェアは、クラスタ内のすべてのコンピュータにインストールする必要があります。

アーキテクチャーの 3 つの次元の統合

図 2–1 に示し、前のいくつかの節で説明したアーキテクチャーの 3 つの次元を 1 つのものとして捉えると、分散型ソフトウェアソリューションを設計するためのフレームワークが得られます。3 つの次元 (インフラストラクチャーサービスの依存関係、論理層、およびサービス品質) は、ソリューションアーキテクチャーで Java ES コンポーネントが果たす役割を明らかにします。

各次元は、それぞれアーキテクチャーの異なる面を表します。すべてのソリューションアーキテクチャーが、それらのすべての次元を考慮する必要があります。たとえば、ソリューションアーキテクチャーの各論理層の分散型コンポーネント (次元 2) は、適切なインフラストラクチャーコンポーネント (次元 1) と適切なサービス品質コンポーネント (次元 3) のサポートが必要です。

同様に、ソリューションアーキテクチャーに含まれるコンポーネントは、アーキテクチャーの次元ごとに異なる役割を果たします。たとえば、Directory Server はデータ層のバックエンドコンポーネント (次元 2) と持続サービスのプロバイダ (次元 1) の両方とみなされます。

Directory Server はこれらの 2 つの次元の中心に位置するため、この Java ES コンポーネントには、サービスの品質の問題 (次元 3) が最も重要です。Directory Server の障害はビジネスシステムに多大な影響を及ぼすので、このコンポーネントの高可用性設計は非常に重要であり、Directory Server はユーザーや設定に関する機密情報の格納に使用されるため、このコンポーネントのセキュリティーの設計も非常に重要です。

Java ES コンポーネントに関するこれらの 3 つの次元の相互作用は、ソリューションの論理アーキテクチャーとソリューションの配備アーキテクチャーの設計に影響します。

「Java Enterprise System アーキテクチャーのフレームワーク」で説明したアーキテクチャーフレームワークに基づく詳細な設計方法論を概説することは、このマニュアルの対象外です。ただし、3 次元のアーキテクチャーフレームワークは、Java Enterprise System に基づいたソフトウェアソリューションの配備を理解するのに重要な設計の面を明らかにします。