通常、Enterprise JavaBeansとしてビジネス・コンポーネントをデプロイする場合、アプリケーション・モジュールのセッションBeanとしてデプロイしてください。こうすることによって、層に依存しないビジネス・コンポーネント・アーキテクチャを有効に利用できます。ただし、ビジネス・コンポーネント・フレームワークを使用すると、ビジネス・コンポーネントをサービスBeanとしてデプロイすることもできます。サービスBeanは、ローカル・モードでアプリケーション・モジュールをコールする汎用のEJBです。
J2EEに準拠するためだけにサービスBeanを使用する必要はありません。アプリケーション・モジュールのセッションBeanは、J2EEに完全に準拠する純粋なEJBセッションBeanです。これらBeanでは、ビジネス・コンポーネント・ライブラリにEJBアーキテクチャを処理するヘルパー・クラスがあります。
ビジネス・コンポーネントをサービスBeanとしてデプロイする場合、JDeveloperによって単純なEJBセッションBeanが作成され、セッションBeanとアプリケーション・モジュールの両方が別のクラスとしてデプロイされます。EJBは、ローカル・モードでクライアントが行うように、アプリケーション・モジュールをコールできます。
他のデプロイメント・モードと同様に、サービスBeanとしてデプロイされたアプリケーション・モジュールにメソッドをエクスポートできます。これらのメソッドは、EJBのリモート・インタフェースに公開され、RMIを使用してクライアントがアクセスできるようになります。ただし、他のデプロイメント・モードと異なり、ビジネス・コンポーネント・フレームワークのベース・メソッド(oracle.jbo
パッケージのインタフェースのメソッド)は、クライアント層から自動的にアクセスできるようにはなりません。クライアントでこれらのメソッドを使用するためには、リモート・インタフェースにこれらのメソッドを追加する必要があります。
サービスBeanには、アプリケーション・モジュールのセッションBeanと比べて次の長所があります。
サービスBeanは、リモート・アクセスを処理するためにビジネス・コンポーネント・アーキテクチャを使用しないため、サービスBeanのクライアントはビジネス・コンポーネント・ライブラリにアクセスする必要がありません。
ビジネス・コンポーネント・フレームワークを使用すると、ビジネス・コンポーネントでフレームワークのメソッドをオーバーライドすることによって、クライアントによるデータへのアクセスを厳密に制御できます。ただし、クライアントによるデータへのアクセスをより厳密に制御する必要がある場合は、サービスBeanを使用して、カスタム・メソッドのみをクライアントに公開できます。
サービスBeanの短所は次のとおりです。
通常、ビジネス・コンポーネント・フレームワークにより、層と層の間の通信に関する処理がすべて行われれます。サービスBeanを使用する場合は、EJBアーキテクチャに則して手動でコーディングする必要があります。
通常、ビジネス・コンポーネント・フレームワークを使用すると、ビジネス・ロジックによる変更に応じて継続的にリフレッシュされる行セットにクライアントがリモート・アクセスできます。サービスBeanでは、クライアントの行セットへのアクセスや行セットの同期化は自動的には提供されません。
サービスBeanではリモート対応の行セットが管理されないため、JClientまたはビジネス・コンポーネントJSPクライアントでは使用できません。
Business Component Browserではテストできません。
サービスBeanではリモート対応の行セットが管理されないため、Business Component Browserではテストできません。
一般的に、高度な対話型のデータ・アクセスがクライアントで必要な場合は、サービスBeanを使用しないでください。サービスBeanはバッチ処理のジョブに適しています。つまり、1回のラウンドトリップで、クライアントがカスタム・メソッドをコールし、そのメソッドによってビジネス・ロジック層で大量の処理が行われるような場合です。