概念: J2EE 導入構成

トピック

概論To top of page

J2EE プラットフォームは、さまざまな標準の導入構成の開発と導入をサポートします。標準の導入構成はアプリケーション開発からの多くの推察を必要とします。以下のセクションで、最も一般的な導入構成の説明とそれらの長所と短所を説明します。

J2EE の概念をまだ理解していない場合は、『概念: J2EE の概要』に記載されている J2EE の概念を参照してから、先に進んでください。

スタンドアロンの導入構成 To top of page

最初の導入構成は、図 1 で示されています。この構成では、Web コンテナーも EJB コンテナーも存在しません。クライアントは EIS リソースに直接アクセスし、プレゼンテーション論理、ビジネス論理、統合論理をクライアント自身で操作します。

本文の説明に関連する図

図 1: スタンドアロンの導入構成

一見すると、この構成は、EIS リソースで保持されるデータの簡単な操作を提供するアプリケーションにとって魅力的な提案に見えるかもしれません。しかし、この構成には多くの潜在的な欠点があります。

EIS リソースへの変更は、アプリケーションの実装に大きな影響を与えることがあります。影響は、多くの場合に、データベース・テーブルの構造など各 EIS リソースの内部構造に直接依存します。アプリケーション自身に対するあらゆる変更は、すべてのユーザーに完全に通知される必要があります。アプリケーションが導入される中央のサーバーが存在しないので、クライアントは最新の修正に直接アクセスできません。

また、この導入構成では責務の分割を推進しません。例えば、プレゼンテーション論理とビジネス論理が密接に結合するため、アプリケーションの拡張や保守のサポートが難しくなる場合が多くあります。

しかし、この導入構成の真の問題は、アプリケーションの拡張を決定したときに浮上してきます。クライアント・ワークステーションはパフォーマンス特性が限られているので、多くのコンピューターでの分散型処理が理想です。しかし、スタンドアロン構成は、分散型処理をサポートするように設計されていません。また、EIS リソースへの多くのクライアントによる同時アクセスをサポートしようとすると、アプリケーションが EIS リソース自身により同時データベース接続数などの制約を受ける可能性があります。

EJB 中心の導入構成 To top of page

EJB 中心の導入構成を図 2 に示します。この構成では、EJB コンテナーがクライアント・コンテナーと EIS リソースの間に位置します。Web コンテナーは存在しません。プレゼンテーション論理はクライアントにあり、ビジネス論理は EJB にあります。EIS リソースに直接アクセスするのではなく、クライアントからのすべての要求は、適切な EJB によって管理されます。したがって、クライアントは EIS リソースの変更から保護されます。

本文の説明に関連する図

図 2: EJB 中心の導入構成

EJB 中心の導入構成は、スタンドアロンの導入構成の多くの問題に対処するように設計されています。スケーラビリティーの観点からは、J2EE プラットフォーム実装では、多くのコンピューター間での分散型処理が可能です。また、EJB コンテナーは、データベース接続などの限られたリソースの効率的な使用を保証します。アプリケーションの拡張と保守の観点からは、この構成はプレゼンテーション論理とビジネス論理の分割も推進します。

しかし、EJB 中心の導入構成の欠点の 1 つは、ユーザー・インターフェースへの小規模な変更であっても、すべてのユーザーへのアプリケーションの完全な通知を必要とすることです。EJB でカプセル化されたビジネス論理は、サーバー上に再導入できます (それによって、ユーザーが変更にすぐにアクセスできるようにします) が、これはプレゼンテーション論理には該当しません。アプリケーションのルック・アンド・フィールは頻繁に変更される可能性があるので、これでは不便です。

Web 中心の導入構成To top of page

Web 中心の導入構成を図 3 に示します。この構成では、Web コンテナーは、クライアント・コンテナーと EIS リソースの間に位置します。EJB コンテナーは存在しません。プレゼンテーション論理とビジネス論理は Web コンテナーで要素 (JSP とサーブレット) によって処理されます。この構成では、HTML のような簡単なマークアップ言語がクライアントで使用されますが、XML や WML も使用できます。

本文の説明に関連する図

図 3: Web 中心の導入構成

通常の場合、Web 中心の導入構成は、ビジネス論理のサポートよりも、作成されたアプリケーションのルック・アンド・フィールに重点を置いています。この構成は、アプリケーションの外観の頻繁な変更をサポートし、今日では広く使用されています。

Web 中心の導入構成には多くの長所があります。まず、クライアントは、EIS リソースに直接アクセスしないので、EIS リソースへの変更による影響を受けません。次に、アプリケーション全体がサーバーに存在するため、ユーザーに通知せずにアプリケーション全体を再導入できます。

場合によっては、EJB を使用しなくても対象のジョブを十分に処理できます。しかし、その一方で、EJB を省略すると、スタンドアロンの導入構成で挙げられたいくつかの問題が発生します。特に、この構成は、プレゼンテーション論理とビジネス論理の間の明確な責務の分割を推進しないため、要素が密接に結合されてアプリケーションの拡張と保守の妨げになる場合が多くあります。また、スタンドアロンの導入構成でのすべてのスケーラビリティーの問題は、Web 中心のアーキテクチャーにも該当します。

多層の導入構成 To top of page

多層の導入構成を図 4 に示します。この構成は、Web コンテナーと EJB コンテナーを両方含み、ほかの導入構成で説明されたすべての長所があり、欠点はありません。プレゼンテーション論理は Web コンテナー内で要素によって処理され、ビジネス論理は EJB コンテナー内で EJB によって処理されます。

本文の説明に関連する図

図 4: 多層の導入構成

クライアントは、EIS リソースに直接アクセスしないので、EIS リソースへの変更による影響を受けません。また、アプリケーション全体がサーバーに存在するため、ユーザーに通知せずにアプリケーション全体を再導入できます。

スケーラビリティーの観点からは、並行処理のサポートのために分散型処理が可能です。また、スケーラビリティーの観点からは、EJB コンテナーは、データベース接続などの限られたリソースの効率的な使用を保証します。

アプリケーションの拡張と保守の観点からは、この構成は責務の明確な分割も推進します。プレゼンテーション論理は EIS リソースから分離され、ビジネス論理はルック・アンド・フィールから分離されています。この明確な分離は、異なった技術を持つ開発者への作業の割り振りを可能にするので、プレゼンテーション論理とビジネス論理を並行して開発できます。

多層の導入構成は、あるクライアントのデバイス (Web ブラウザーなど) からほかのデバイス (PDA など) への移行も容易にします。EJB でカプセル化されたビジネス論理は変更しないでそのまま使用できるため、アプリケーションの完全な書き換えは必要ありません。

まとめると、多くの導入構成があり、それぞれに長所と短所があります。J2EE プラットフォームの目的の 1 つは、企業の懸案事項に対応すると同時に、組織にとって適切であると判断された導入構成がどれであっても柔軟にサポートできることです。



Rational Unified Process   2003.06.15