test

Sun Java Enterprise System 2005Q4 技術の概要

第 2 章 Java Enterprise System ソリューションアーキテクチャー

この章では、Java Enterprise System (Java ES) ソリューションの基礎となるアーキテクチャー概念の概要について説明します。この章では、Java ES コンポーネントである、システムサービスコンポーネントとサービス品質コンポーネントの両方を使用してどのように分散型エンタープライズソリューションをサポートするかを示します。

Java ES ソリューションアーキテクチャーには 2 つの側面があります。論理アーキテクチャーと配備アーキテクチャーです。論理アーキテクチャーは、ソリューションの論理的な構築ブロック (ソフトウェアコンポーネント) 間の対話を示します。配備アーキテクチャーは、論理アーキテクチャーから物理的なコンピューティング環境へのマッピングを示します。Java ES コンポーネントは、論理アーキテクチャーと配備アーキテクチャーの両方で重要な役割を果たします。

この章では、Java ES ソリューションのアーキテクチャーの設計のためのアーキテクチャーのフレームワークについて説明し、その後にそのアーキテクチャーのフレームワークに基づいたソリューションアーキテクチャーの例を示します。

この章で説明する内容は、次のとおりです。

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 に基づいたソフトウェアソリューションの配備を理解するのに重要な設計の面を明らかにします。

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 の論理的に異なる設定を、それぞれが異なるサービスを提供するために、別々のコンポーネントとして扱います。

図 2–7 エンタープライズ通信のシナリオの論理アーキテクチャー

エンタープライズ通信シナリオの例の論理アーキテクチャーを示す図。

コンポーネントは、標準の論理層を表す横の次元、またインフラストラクチャーサービスレベルを表す縦の次元に配置されています。コンポーネント間の対話は、分散型インフラストラクチャーサービスとしての各コンポーネントの機能 (インフラストラクチャーサービスレベル間の対話) または階層アプリケーションアーキテクチャー内の各コンポーネントの役割 (論理層内または論理層間の対話) に依存します。

このアーキテクチャーでは、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 コンポーネントがクライアントになる場合もあります。

配備アーキテクチャー

論理アーキテクチャーから物理的なコンピューティング環境へのマッピングを示す上位レベルの設計。物理環境には、イントラネット環境またはインターネット環境のコンピュータ、コンピュータ間のネットワークリンク、およびソフトウェアのサポートに必要なその他の物理デバイスが含まれます。

論理アーキテクチャー

分散型アプリケーションの論理的な構築ブロックとそれら構築ブロック間の関係 (またはインタフェース) を記述した設計。論理アーキテクチャーには、分散型アプリケーションコンポーネント、およびこれらのアプリケーションのサポートに必要なインフラストラクチャーサービスの両方が含まれます。

サーバー

分散型のサービスまたは関連する一連のサービスを、外部インタフェースを使ってサービスにアクセスするクライアントに対して提供する、マルチスレッド対応のソフトウェアプロセス。ハードウェアのサーバーとは区別されます。

Web サービス

アクセス可能性、サービスのカプセル化、および検出に関する標準インターネットプロトコルに準拠したサービス。この標準インターネットプロトコルには、SOAP (Simple Object Access Protocol) メッセージングプロトコル、WSDL (Web Service definition Language) インタフェース定義、および UDDI (Universal Discovery, Description, and Integration) レジストリ標準が含まれます。