ビジネス・コンポーネント・プロジェクトを開発する際は、クライアント・コード、ビジネス・ロジックおよびデータベースという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モジュールへのデプロイによるネットワーク通信量の減少は、処理要求の増加に見合うだけの価値があります。
層の非依存性には複数の利点があります。
非依存性は、クライアント・インタフェースおよびファクトリ・パターンを使用してメンテナンスできます。