- ベストアンサー
ひとつのインターフェースで複数のＥＪＢクラスを参照する
- インターフェースが同じなら複数のＥＪＢクラスを参照する構成は可能か
- Ｂｅａｎごとにインタフェースが違う場合はこの構成はむりか
- 共通ＲｅｍｏｔｅＩ／Ｆ側にＢｅａｎ１～Ｎのインタフェースを定義し、使わないインターフェースの実装も行う必要がある
- みんなの回答 （1）
- 専門家の回答
質問者が選んだベストアンサー
- ベストアンサー
> 仮にＢｅａｎごとにインタフェースが違うならこの構成はむりなのでしょうか？ 「ひとつのインターフェースで複数のＥＪＢクラスを参照する」の続きと言うことですが、Beanごとのインタフェースが違うんなら、Remote や Homeインタフェースを共有するというのは、EJB設計上問題があると思うのですが。。。 > 共通ＲｅｍｏｔｅＩ／Ｆ側にＢｅａｎ１～Ｎのインタフェースの定義をしてさらに > Ｂｅａｎ１～Ｎに使わないインターフェースの実装も行わないとだめだということですよね．．．． . そういうことになりますね。。。 このような状況に対応する方法としては、以下の２パターンがあると思います。 １．EJBを呼び出すメソッドを子サーブレットに実装させる ２．個別のEJBを呼び出すEJBを用意する プロキシクラスとか、アダプタクラスとか呼ばれる呼び出し元と 呼び出し先の間のブリッジになるクラスを使う １の方は、親サーブレットに callEJB() といったメソッドを用意し、子サーブレットで、EJB呼び出しを実装するというものです。 最初の質問で、子サーブレットは独自の処理を実装するとなっていましたが、 EJBクラスのI/Fが別々ということであれば、それは既に独自の処理となると思うので、 EJB呼び出し用のメソッドを子サーブレットごとに実装していきます。 ２の方では、ブリッジになるEJBを用意し、サーブレットからはこのEJBに呼び出したい EJBの情報を渡します。それで、このブリッジになるEJB内で、受け取った情報に 合わせたEJBを呼び出して結果を返却します。 ２の方は、フレームワークを作成するときなどに一般に使われる方法だと思います。 特に、ブリッジに渡す情報を外部ファイル化したり、パラメータ化したりすると 新しいEJBの追加時の修正個所が局所化できると思います。 ただし２の場合、単純な場合でも、少なくとも２回EJB呼び出しが発生するので、 呼び出しのオーバーヘッドが気になるところですが。。。 ＃ EJB2.0 からは、LocalHome、Local インタフェースが定義できるので、 ＃ それらを使うことも考慮すべきですね
お礼
お返事ありがとうございました。 いろいろと考えたのですが、２の方法で考えてみようかと 思っています。ＥＪＢを２回呼び出さないといけないので 処理時間が気になりますが、それは実際に作ってみて検証を してみようと思っています。