この章では、Java Enterprise System (Java ES) ソリューションの基礎となるアーキテクチャー概念の概要について説明します。この章では、Java ES コンポーネントである、システムサービスコンポーネントとサービス品質コンポーネントの両方を使用してどのように分散型エンタープライズソリューションをサポートするかを示します。
Java ES ソリューションアーキテクチャーには 2 つの側面があります。論理アーキテクチャーと配備アーキテクチャーです。論理アーキテクチャーは、ソリューションの論理的な構築ブロック (ソフトウェアコンポーネント) 間の対話を示します。配備アーキテクチャーは、論理アーキテクチャーから物理的なコンピューティング環境へのマッピングを示します。Java ES コンポーネントは、論理アーキテクチャーと配備アーキテクチャーの両方で重要な役割を果たします。
この章では、Java ES ソリューションのアーキテクチャーの設計のためのアーキテクチャーのフレームワークについて説明し、その後にそのアーキテクチャーのフレームワークに基づいたソリューションアーキテクチャーの例を示します。
この章で説明する内容は、次のとおりです。
Java ES コンポーネントは、分散型エンタープライズ版ソフトウェアソリューションの配備をサポートします。
ビジネス要件によって課されるパフォーマンス、可用性、セキュリティー、スケーラビリティー、および保守性のレベルで必要な機能を実現するには、これらのソフトウェアソリューションを適切に設計する必要があります。
分散型エンタープライズ版ソフトウェアソリューションの設計には、アーキテクチャーの次元の多くが関係します。それらの次元は、そのようなシステムの構築に使用される多数のソフトウェアコンポーネント間の対話をさまざまな観点から見ることができる観点を表します。特に、分散型システムの設計にはアーキテクチャーの次の 3 つの次元が関係します。
インフラストラクチャーサービスの依存関係: この次元では、分散型ソリューションのサポートにおけるシステムサービスコンポーネント (「システムサービスコンポーネント」を参照) の役割に重点を置いています。
論理層: この次元では、ソリューションコンポーネントをネットワークまたはインターネット環境に配備するためのソリューションコンポーネントの論理的および物理的な独立性に重点を置いています。
サービスの品質: この次元では、サービス品質コンポーネント (「サービス品質コンポーネント」を参照) の役割も含め、可用性、セキュリティー、スケーラビリティー、保守性といったサービス品質の要件をどのようにして実現するかに重点を置いています。
ソリューションアーキテクチャーのこれらの 3 つの次元を次の図に示します。
これらの 3 つの次元によって、ソフトウェアソリューションに必要なサービス機能とサービス品質の実現に必要な、アプリケーションコンポーネントとインフラストラクチャーコンポーネントの両方の、ソフトウェアコンポーネント間の関係を統合する単一のフレームワークを表します。
次の各項では、3 つの各次元を個別に説明し、その後、3 つの次元を 1 つのフレームワークに統合して説明します。
分散型のエンタープライズアプリケーションの対話型ソフトウェアコンポーネントには、基本となるインフラストラクチャーサービスのセットが必要です。 これに基づいて、分散しているコンポーネント間で相互に通信したり、それぞれの動作を調整したり、セキュリティー保護されたアクセスを実装することなどが可能になります。ここでは、これらのインフラストラクチャーサービスを提供するためにいくつかの Java ES コンポーネントが果たす主な役割について説明します。
分散型のソフトウェアシステムを設計する場合、そのほとんどがカスタム開発コンポーネントで構成されるか、または追加設定の必要ない Java ES コンポーネントで構成されるかにかかわらず、多数のインフラストラクチャーサービスを組み込む必要があります。これらのサービスは、多数のレベルで機能します。
ソリューションアーキテクチャーのインフラストラクチャーサービスの依存関係の次元 を、図 2–2 に示します。この図に示されているレベルは、図 1–1 のインフラストラクチャーサービス層を詳細化したものです。
図 2–2 のサービス階層とサービス間の依存関係が、ソリューションの論理アーキテクチャーの重要な次元を構成します。これらのインフラストラクチャーサービスは、Java ES システムサービスコンポーネント (「システムサービスコンポーネント」を参照) の役割を理解するための概念上の基礎になります。
一般的に、図 2–2 に示したサービスは、大きく 3 つのグループに分けられます。下位レベルのプラットフォームサービス、上位レベルのアプリケーションサービス、およびミドルウェアサービスのグループです。なお、ミドルウェアサービスという名前は、ほかの 2 つのグループの間にあることから付けられたものです。
次の各段落では、さまざまなインフラストラクチャーサービスレベルについて説明し、関連する場合には Java プログラミング言語のアーチファクトの参考情報も示します。図 2–2 に示された各サービスレベルについて、最下位レベルから順に説明します。
オペレーティングシステムプラットフォーム: コンピュータ上で実行されるすべてのプロセスに対し、基本的なサポートを提供します。オペレーティングシステム (SolarisTM オペレーティングシステム、Linux、Microsoft Windows など) は、物理デバイスのほかに、メモリー、スレッド、および JVMTM (Java Virtual Machine) マシンのサポートに必要なその他のリソースを管理します。
ネットワークトランスポート: 異なるコンピュータ上で実行されている分散型アプリケーションコンポーネント間での通信に必要な、基本的なネットワークサポートを提供します。これらのサービスには、TCP や HTTP などのプロトコルに対するサポートも含まれます。上位レベルのその他の通信プロトコル (「メッセージングレベル」を参照) は、これらの基本的なトランスポートサービスに依存しています。
持続: 静的データ (ユーザー、ディレクトリ、設定情報など) と動的アプリケーションデータ (頻繁に更新される情報) の両方に対するアクセスや格納に必要なサポートを提供します。
メッセージング: アプリケーションコンポーネント間の同期および非同期の通信に対するサポートを提供します。同期メッセージングでは、メッセージをリアルタイムで送受信します。 これには、J2EE コンポーネント間のリモートメソッドの呼び出し (RMI) や Web サービスとの SOAP 対話も含まれます。非同期メッセージングの通信では、直後に受信するコンシューマの準備状況に関係なく、メッセージを送信します。JMS (Java Message Service) や ebXML などの非同期メッセージングの仕様では、信頼性の保証およびその他のメッセージング方式をサポートします。
実行時: J2EE モデルや CORBA モデルなどの分散型のコンポーネントモデルで必要となるサポートを提供します。実行時サービスには、密接に結合された分散型コンポーネントに必要なリモートメソッドの呼び出しの他に、コンポーネントの状態 (ライフサイクル) の管理、スレッドプールの管理、同期 (相互排他ロック)、持続サービス、分散するトランザクションの監視、分散する例外の処理などが含まれます。J2EE 環境では、これらの実行時サービスはアプリケーションサーバーまたは Web サーバーの EJBTM、Web、およびメッセージ駆動型 Bean コンテナから提供されます。
セキュリティーとポリシー: アプリケーションリソースへのセキュリティー保護されたアクセスに必要なサポートを提供します。これらのサービスには、グループまたはロールに基づく分散型リソースへのアクセスを制御するポリシーのサポートや、シングルサインオン 機能が含まれます。シングルサインオンを使用すると、ある分散型システム内の 1 つのサービスに対するユーザー認証を、同じシステム内の他のサービス (J2EE コンポーネント、ビジネスサービス、Web サービスなど) に自動的に適用できます。
ユーザーの共同作業: ユーザー間の直接通信およびエンタープライズ内とインターネット環境内でのユーザー間の共同作業に対するサポートで重要な役割を果たすサービスを提供します。これらのサービスは、一般的にスタンドアロンサーバー (電子メールサーバーやカレンダサーバーなど) から提供されるアプリケーションレベルのビジネスサービスです。
統合: 既存のビジネスサービスを集約するサービスを提供します。ポータルと同様にサービスにアクセスするための共通インタフェースを提供するか、これらのサービスを本稼動ワークフロー内で調整するプロセスエンジンを使用し、統合することによって行います。統合は、異なる企業間における企業間 (B2B) 統合として行なわれることもあります。
図 2–2 に示したサービスレベルは、最下位レベルのオペレーティングシステムサービスから最上位レベルのアプリケーションサービスや統合サービスまで、さまざまなインフラストラクチャーサービス間の一般的な依存関係を反映しています。通常、各サービスはその下にあるサービスに依存し、その上にあるサービスをサポートします。
ただし、図 2–2 は、インフラストラクチャーサービスの厳密な階層を表しているわけではありません。上位レベルのサービスは、中間のレベルに依存せずに、下位レベルのサービスと直接対話することができます。たとえば、一部の実行時サービスは、中間にあるサービスレベルを介さずに、プラットフォームサービスに直接依存する場合があります。さらに、監視サービスや管理サービスなどのその他のサービスレベルも、ここでの概念的な説明に含まれることがあります。
Java ES コンポーネントは、図 2–2 に示した分散型インフラストラクチャーサービスレベルを実装したものです。Java ES システムサービスコンポーネントのさまざまなレベル内における位置関係を、図 2–3 に示します。
図 2–3 に示したオペレーティングシステムプラットフォームは正式には Java Enterprise System の一部ではありませんが、Java ES コンポーネントをサポートするオペレーティングシステムプラットフォームを示すために、この図に含めてあります。
一般に、図 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 に基づくコンポーネント |
分散型エンタープライズアプリケーションの相互に作用するソフトウェアコンポーネントは、いくつかの論理層に存在するとみなすことができます。これらの層は、提供するサービスの性質に基づいて、ソフトウェアコンポーネントの論理的および物理的な独立性を表しています。
ソリューションアーキテクチャーの論理層の次元を、次の図に示します。
論理層アーキテクチャーは基本的に、図 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 機能ごとに異なるセキュリティーを実装できます。
すでに説明したアーキテクチャーの 2 つの次元 (インフラストラクチャーサービスの依存関係および論理層) では、主にアーキテクチャーの論理的な面に焦点を当てました。 つまり、サービスをエンドユーザーに配信するためにどのような方法で対話するか、あるいはどのようなコンポーネントが必要であるかについてです。一方、配備されるソリューションで同様に重要な次元は、サービス品質の要件を満たすためのソリューションの機能です。
ソリューションアーキテクチャーのサービスの品質の次元は、Java ES サービス品質コンポーネントが果たす役割を明らかにします。
ビジネスの運営におけるインターネットサービスや e コマースサービスの重要性が増しているため、これらのサービスのパフォーマンス、可用性、セキュリティー、スケーラビリティー、および保守性は、高いパフォーマンスを備えた大規模な配備アーキテクチャーの重要なサービス品質要件になりました。
優れたソフトウェアソリューションを設計するには、適切なサービス品質要件を設定し、それらの要件を満たすアーキテクチャーを設計する必要があります。いくつかの重要なサービス品質により、サービス品質要件を指定します。これらのサービス品質を次の表に要約してあります。
表 2–2 ソリューションアーキテクチャーに影響するサービス品質
システムサービス品質 |
説明 |
---|---|
ユーザーの負荷条件に関する応答時間の測定 |
|
システムのリソースやサービスがエンドユーザーにアクセス可能になる頻度 (システムの「稼働時間」) の測定。 |
|
システムとそのユーザーの整合性を記述する要素の複雑な組み合わせ。セキュリティーには、システムの物理セキュリティー、ネットワークセキュリティー、アプリケーションおよびデータのセキュリティー (ユーザーの認証および承認)、またセキュリティー保護された情報のトランスポートも含まれます。 |
|
配備されたシステムに対して、随時、容量を拡張する機能。通常、スケーラビリティーにはシステムへのリソースの追加が含まれるが、追加時に配備アーキテクチャーを変更する必要はありません。 |
|
システムでリソースを追加せずに、異常なピーク負荷使用を処理する機能 |
|
配備されたシステムの保守のしやすさ。 システムの監視、発生した問題の修復、ハードウェアおよびソフトウェアのコンポーネントのアップグレードなどが含まれます。 |
サービス品質の次元は、ソリューションの配備アーキテクチャーに、つまりアプリケーションコンポーネントとインフラストラクチャーコンポーネントが物理環境内でどのように配備されるかに、大きな影響を与えます。
配備アーキテクチャーに影響を与えるサービス品質は、互いに密接に関係しています。あるシステム品質に対する要件がほかのサービス品質の設計に影響を与えることが、よくあります。たとえば、セキュリティーのレベルを上げるとパフォーマンスに影響を与える可能性がありますが、これに伴って可用性にも影響が生じます。冗長性を使用して可用性の問題に対処するためにコンピュータを追加すると、保守コスト (保守性) に影響を与える可能性があります。
ビジネスの要件と制約の両方を満たす配備アーキテクチャーを設計するには、複数のサービス品質が相互に関連する仕組み、およびこれらのかね合いを理解しておくことが重要です。
システムサービスコンポーネントまたは分散型アプリケーションコンポーネントが提供するサービス品質を向上するために、主にいくつかの Java ES コンポーネントが使用されます。これらのソフトウェアコンポーネントは、多くの場合、ロードバランサやファイアウォールなどのハードウェアコンポーネントとともに使用されます。
「サービス品質コンポーネント」で紹介した Java ES サービス品質コンポーネントについて、次に要約します。
可用性コンポーネント: 可用性コンポーネントは、配備されたソリューションがほぼ連続的に稼働することを可能にします。
アクセスコンポーネント: アクセスコンポーネントは、システムサービスへのインターネットからのセキュリティー保護されたアクセスを可能にし、また多くの場合ルーティング機能も提供します。
管理コンポーネント: 管理コンポーネントは、システムコンポーネントの保守性を向上させます。
次の表は、アーキテクチャーの観点からの最も重要な Java ES サービス品質コンポーネントと、それらの各コンポーネントが最も影響を及ぼすシステム品質を示しています。
表 2–3 サービス品質コンポーネントと影響を受けるシステム品質
コンポーネント |
影響を受けるシステム品質 |
---|---|
スケーラビリティー |
|
High Availability Session Store | |
Sun Cluster | |
Web Proxy Server |
Sun Cluster ソフトウェアは、高可用性サービスおよび高スケーラビリティーサービスを、Java ES コンポーネントおよび Java ES インフラストラクチャーがサポートするアプリケーションに対して提供します。
クラスタとは緩やかに結合された一連のコンピュータのことであり、サービス、システムリソース、およびデータの単一のクライアントビューを一括して提供します。クラスタの内部では、冗長コンピュータ、インターコネクト、データ記憶域、およびネットワークインタフェースを使用して、クラスタベースのサービスおよびデータに高可用性を提供します。
Sun Cluster ソフトウェアは、メンバーノードおよびその他のクラスタリソースの健全性を継続的に監視します。障害が発生した場合、Sun Cluster ソフトウェアは監視対象のリソースのフェイルオーバーを開始するために介入し、内部の冗長性を使用して、リソースへのほぼ連続的なアクセスを可能にします。
Messaging Server および Calendar Server 用のデータストアサービスをサポートする 2 つのノードから成るクラスタを次の図に示します。
Sun Cluster データサービスパッケージ (Sun Cluster エージェントと呼ばれることもある) が、すべての Java ES システムサービスコンポーネントに利用できます。カスタム開発されたアプリケーションコンポーネント用のエージェントを記述することもできます。
Sun Cluster ソフトウェアによる制御が行われるので、スケーラブルなサービスも提供できます。クラスタのグローバルファイルシステムおよびクラスタ内の複数のノードの機能を利用して、インフラストラクチャーサービスやアプリケーションサービスを実行することにより、サービスの複数の並行インスタンス間で、これらのサービスに対して増加する要求のバランスを取ることができます。したがって、正しく設定されていれば、Sun Cluster ソフトウェアは分散型のエンタープライズアプリケーションに高可用性とスケーラビリティーの両方を提供できます。
Sun Cluster 環境をサポートするのに必要な冗長性のために、ソリューションに Sun Cluster を含めると、物理環境に必要なコンピュータやネットワークリンクの数がかなり増えます。
Sun Cluster の可用性サービスは、ほかの Java ES コンポーネントが提供するサービスとは異なり、分散型のピアツーピアサービスです。したがって、Sun Cluster ソフトウェアは、クラスタ内のすべてのコンピュータにインストールする必要があります。
図 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 に基づいたソフトウェアソリューションの配備を理解するのに重要な設計の面を明らかにします。
Java Enterprise System は、広範なソフトウェアソリューションをサポートします。
多くのソリューションは、開発作業を行わずに、Java Enterprise System に含まれるコンポーネントを使ってすぐに設計および配備できます。その他のソリューションには、新しいビジネスまたはプレゼンテーションサービスを提供するカスタム J2EE コンポーネントの開発を必要とする、広範な開発が必要になる場合があります。これらのカスタムコンポーネントを SOAP (Simple Object Access Protocol) インタフェース標準に準拠する Web サービスとしてカプセル化することができます。多くのソリューションは、この 2 つの方法を組み合わせて使用します。
ここでは、前の節のアーキテクチャーの概念に基づき、Java Enterprise System がすぐに使用できるソリューションをどのようにしてサポートするのかを示す例を取り上げます。
企業は、一般に従業員間の通信、特に電子メールサービスやカレンダサービスをサポートする必要があります。そのような企業は、内部の Web サイトやその他のリソースに対する個人向けにカスタマイズされたアクセスを企業全体にわたる認証および承認サービスに基づいて従業員に提供すると便利であるとみなします。また、それらの企業は、シングル Web サインオンによりすべてのエンタープライズサービスへのアクセスが可能になるように、すべてのエンタープライズサービスで従業員のアイデンティティーを追跡することを望みます。
多数のビジネス要件の一部の例である、このような特定のビジネス要件を次の表にまとめてあります。
表 2–4 ビジネス要件の要約: 通信のシナリオ
ビジネス要件 |
説明 |
必要な Java ES サービス |
---|---|---|
シングルサインオン |
セキュリティー保護されたエンタープライズリソースおよびサービスへのアクセス (Web アクセスはシングルサインオンの単一の ID に基づく)。 |
アイデンティティーサービス |
メッセージング カレンダ |
従業員と外部との電子メールメッセージング。 電子的な従業員用のカレンダ機能や会議の設定。 |
通信サービスと共同作業サービス |
ポータルアクセス |
電子メール、カレンダ、内部 Web ページなどの通信サービスへの単一の Web ベースの個人向けにカスタマイズされたアクセスポイント。 |
ポータルサービス |
さらに、企業には、これらのサービスを提供するソフトウェアシステムのパフォーマンス、可用性、ネットワークセキュリティー、およびスケーラビリティーに関する要件があります。
表 2–4 で示したポータルサービス、通信サービス、およびアイデンティティーサービスを Java ES コンポーネントを使用して配信するための論理アーキテクチャーを次の図に示します。このアーキテクチャーは、Messaging Server の論理的に異なる設定を、それぞれが異なるサービスを提供するために、別々のコンポーネントとして扱います。
コンポーネントは、標準の論理層を表す横の次元、またインフラストラクチャーサービスレベルを表す縦の次元に配置されています。コンポーネント間の対話は、分散型インフラストラクチャーサービスとしての各コンポーネントの機能 (インフラストラクチャーサービスレベル間の対話) または階層アプリケーションアーキテクチャー内の各コンポーネントの役割 (論理層内または論理層間の対話) に依存します。
このアーキテクチャーでは、Directory Server に格納されたユーザー情報にアクセスする Access Manager が、プレゼンテーション層の Portal Server およびその他の Web ベースコンポーネントに対する、シングルサインオン認証および承認の仲介役として機能します。Messaging Server コンポーネントには、データ層のメッセージストア (Messaging Server-STR)、ビジネスサービス層の送信および取得コンポーネント、プレゼンテーション層の HTTP アクセスコンポーネントおよび Communications Express が含まれます。
論理アーキテクチャーは、さまざまな Java ES コンポーネント間のインフラストラクチャーサービスの依存関係も示します。たとえば、Portal Server は、メッセージングチャネルとカレンダチャネルには Communications Express を利用し、認証および承認サービスには Access Manager を利用します。これらのコンポーネントは、今度は、ユーザー情報および設定データのために Directory Server を利用します。多数のコンポーネントは、Web Server が提供する Web コンテナサービスを必要とします。
Java ES ソリューションの論理設計の詳細については、『Sun Java Enterprise System 2005Q4 配備計画ガイド』を参照してください。
論理アーキテクチャーから配備アーキテクチャーに移行する際には、サービス品質要件が最も重要になります。たとえば、保護されたサブネットやファイアウォールを使用して、バックエンドデータへのセキュリティーバリアを設けることができます。多くのコンポーネントの可用性とスケーラビリティーの要件は、複数のコンピュータにコンポーネントを配備し、ロードバランサを使用してレプリケートしたコンポーネント間に要求を分散することによって満たすことができます。
ただし、より高い可用性要件の水準が適用された場合や大量のディスク容量が必要な場合は、他の可用性ソリューションの方が適しています。たとえば、Messaging Server ストアに Sun Cluster を、Directory Server にマルチマスターレプリケーションを使用できます。
Java ES ソリューションの配備設計の詳細については、『Sun Java Enterprise System 2005Q4 配備計画ガイド』を参照してください。
この節では、この章で使用されている重要な技術用語について説明します。ここでは、用語間の関係や Java Enterprise System の文脈でどのように使用されているかの説明に重点を置いています。
特定のコンピューティング機能を実行し、ビジネスサービスをエンドユーザーまたはほかのアプリケーションコンポーネントに対して提供する、カスタム開発されたソフトウェアコンポーネント。通常、アプリケーションコンポーネントは、CORBA や J2EETM プラットフォームなどの分散型コンポーネントモデルに準拠しています。これらのコンポーネントを単独であるいは組み合わせて、Web サービスとしてカプセル化できます。
分散型アプリケーション (またはその他のソフトウェアシステム) の論理的および物理的な構築ブロックと、それら構築ブロック間の相互関係を示した設計。分散型のエンタープライズアプリケーションの場合、アーキテクチャー設計には一般的に、アプリケーションの論理アーキテクチャーと配備アーキテクチャーの両方が含まれます。
複数のクライアントに代わってビジネスロジックを実行するアプリケーションコンポーネントまたはコンポーネントアセンブリ (したがって、マルチスレッド対応プロセスである)。また、ビジネスサービスは、Web サービスとしてカプセル化された分散型コンポーネントアセンブリであってもかまいませんし、スタンドアロンのサーバーであってもかまいません。
ソフトウェアサービスを要求するソフトウェア。(注: ユーザーのことではない。エンドユーザーを参照)。別のサービスを要求するサービス、またはエンドユーザーがアクセスする GUI コンポーネントがクライアントになる場合もあります。
論理アーキテクチャーから物理的なコンピューティング環境へのマッピングを示す上位レベルの設計。物理環境には、イントラネット環境またはインターネット環境のコンピュータ、コンピュータ間のネットワークリンク、およびソフトウェアのサポートに必要なその他の物理デバイスが含まれます。
分散型アプリケーションの論理的な構築ブロックとそれら構築ブロック間の関係 (またはインタフェース) を記述した設計。論理アーキテクチャーには、分散型アプリケーションコンポーネント、およびこれらのアプリケーションのサポートに必要なインフラストラクチャーサービスの両方が含まれます。
分散型のサービスまたは関連する一連のサービスを、外部インタフェースを使ってサービスにアクセスするクライアントに対して提供する、マルチスレッド対応のソフトウェアプロセス。ハードウェアのサーバーとは区別されます。
アクセス可能性、サービスのカプセル化、および検出に関する標準インターネットプロトコルに準拠したサービス。この標準インターネットプロトコルには、SOAP (Simple Object Access Protocol) メッセージングプロトコル、WSDL (Web Service definition Language) インタフェース定義、および UDDI (Universal Discovery, Description, and Integration) レジストリ標準が含まれます。