n層のビジネス・コンポーネント・アーキテクチャの理解

ビジネス・コンポーネント・プロジェクトを開発する際は、クライアント・コード、ビジネス・ロジックおよびデータベースという3つの異なるロジック層があるものとして考える必要があります。ただし、これらの3つのロジック層は、複数の物理構成にデプロイできます。クライアント・コードは、Javaコード(GUIアプリケーション、JSP、Enterprise JavaBeansなど)を記述できる任意の場所にデプロイできます。また、Business Components for Javaを使用して作成するビジネス・ロジックは、層に依存しません。アプリケーション・モジュールは、ビジネス・コンポーネントまたはクライアント・コードを変更せずに複数のプラットフォームにデプロイできます。

共通デプロイメント構成

ビジネス・コンポーネントおよびクライアント・コードは、Javaをデプロイできる任意の場所にデプロイできます。ただし、一般的なデプロイメント構成としては、次の4つがあります。

クライアント・コード ビジネス・コンポーネント
クライアント・マシン上のJavaクライアント クライアント・マシン上
クライアント・マシン上のJavaクライアント EJBセッションBeanまたはCORBAサーバー・オブジェクトとして
サーバーのWebモジュールのサーブレット/JSP(ブラウザからアクセス) Webモジュール内
サーバーのWebモジュールのサーブレット/JSP(ブラウザからアクセス) EJBセッションBeanまたはCORBAサーバー・オブジェクトとして

ビジネス・コンポーネントがEJBセッションBeanまたはCORBAサーバー・オブジェクトとしてデプロイされる場合、この構成はリモート・デプロイメントと呼ばれます。層に依存しないということは、ビジネス・コンポーネントのデプロイをリモートと、Webモジュールまたはクライアント・マシンとの間で、コードに変更を加えずに切り替えられることを意味します。

これは、他のプログラミング・スタイルと比べて非常に優れた点です。ビジネス・コンポーネント・フレームワークを使用しない場合は、デプロイメント構成をベースにアプリケーション全体を計画する必要があります。EJBをベースに設計されたアプリケーションは、独立した物理ビジネス・ロジック層を持たないクライアント/サーバー・アプリケーションとはまったく異なるものとみなされます。ビジネス・コンポーネント・フレームワークを使用する場合は、ビジネス・コンポーネントEJBおよびローカルにデプロイされたビジネス・コンポーネント・アーカイブをまったく同じ方法でプログラミングおよび起動できます。

デプロイメント構成の選択

ビジネス・コンポーネント・アプリケーションの構成を選択する場合は、次の点について検証します。

Thinクライアントと複雑なユーザー・インタフェースを持つクライアントのどちらを持つ方が重要ですか

サーブレットまたはJSPクライアント・コードを使用すると、クライアント・マシンの負荷が大幅に軽減されます。Webサーバーがすべての処理を行い、クライアント・マシンはHTMLのレンダリングのみ行う必要があります。一方、Javaクライアントでは、クライアント・マシンがJavaを実行する必要がありますが、リアルタイムの対話および複雑なユーザー・インタフェースが可能です。

マシン速度よりもネットワーク速度の方が重要ですか

ビジネス・コンポーネントをリモートにデプロイすると、クライアント・コードを処理する負荷が軽減されます。この場合のデメリットは、クライアント・コードがビジネス・コンポーネントEJBにアクセスするため、ネットワークの通信量が増えることです。クライアント・コードがWebサーバーなどの高速な中央マシンで実行される場合、Webモジュールへのデプロイによるネットワーク通信量の減少は、処理要求の増加に見合うだけの価値があります。

層の非依存性の利点

層の非依存性には複数の利点があります。

層の非依存性のメンテナンス

非依存性は、クライアント・インタフェースおよびファクトリ・パターンを使用してメンテナンスできます。