Topics
Enterprise Architecture
Enterprise JavaBeans 3.0仕様入門
Pages:
1,
2,
3,
4,
5,
6
EJB 2.1仕様では、開発者は
ejbActivate()、
ejbPassivate()、
ejbLoad()、
ejbStore()な どのさまざまなコールバックメソッドをBeanクラスに実装する必要がありました。3.0では、これらのメソッドの実装を強制されることはありません。 EJB 3.0では、Bean開発者は不必要なコールバックメソッドを実装する必要はない代わりに、任意のメソッドをコールバックメソッドとして指定し、ライフサ イクルイベントの通知を受け取ることができます。コールバックメソッドには、定義済みのライフサイクルイベントコールバック注釈のいずれか1つを付ける必 要があります。ライフサイクルイベントのコールバックメソッド注釈の例には、
PostConstruct、
PreDestroy、
PostActivate、
PrePassivateなどがあります。イベントコールバックメソッドには、すべてのタイプのエンタープライズBeanに共通のものと、エンティティBeanに対する
PostPersistのように各Beanタイプに固有のものがあります。
コールバックメソッドは、Beanクラス本体またはBeanリスナクラスのどちらかで定義できます。Beanリスナクラスは、関連付けられたBeanクラス上で
CallbackListener注 釈を使用して表されます。コールバックメソッドに対して使用する注釈はどちらのクラスでも同じであり、メソッドシグネチャだけが異なります。リスナクラス で定義されるコールバックメソッドはオブジェクトをパラメータに取る必要がありますが、コールバックがBean本体の中で発生する場合これは不要です。こ のオブジェクトパラメータを使用して、リスナクラス内のメソッドにBeanインスタンスを渡すことができます。次の例では、エンティティBean内にコー ルバックメソッドを配置しています。
@Entity public class AccountBean{ @PostPersist insertAccountDetails(AccountDetails accountDetails) public void createAccount(){} }
リスナクラスを作成し、Beanクラスに追加する例を見てみましょう。次のコードは、コールバックリスナAccountListenerを定義します。
/* Adds callback listener to bean class */ @CallbackListener AccountListener public class AccountBean{ public void createAccount(){} }
次のコードは、コールバックリスナAccountListenerをAccount Beanに追加します。
/* Callback method defined inside a Listener class*/ public class AccountListener{ @PostPersist insertAccountDetails( AccountDetails accountDetails){} }
@PostPersistを使用して、データベースに挿入された直後のオブジェクトに対して呼び出されるメソッドを登録しています。この場合、
AccountBean内の
createAccount()メソッドを使用してアカウントが挿入されるたびに、メソッド
insertAccountDetails()が直ちに呼び出されます。
「例外によるコンフィグレーション」のアプローチは、EJB 3.0での開発作業を全面的に簡素化するために用いられるガイド方法論です。その意図は、デフォルトが適切でない箇所でのみコードを書くという方針を開発 者に徹底することにより、作業の簡素化を図るというものです。
たとえば、多くの場合、明示的なメタデータ注釈要素の代わりにデフォルトを使用できます。そのようなケースでは、開発者は注釈を厳密に指定した場合と同じ結果を得るためにメタデータ注釈を指定する必要はありません。たとえば、(注釈
@Entityで 表される)エンティティBeanのデフォルトのエンティティタイプはCMPであり、これはBeanがコンテナ管理永続性を持つことを示しています。これら のデフォルトにより、エンタープライズBeanの注釈付けがきわめて容易になります。デフォルトは常に最も一般的な仕様を表します。たとえば、注釈が指定 されない場合のエンタープライズBeanに対しては、コンテナ管理のトランザクション境界設定(作業単位のデータベースへのコミットまたはロールバックを Beanではなくコンテナが管理する)が想定されます。同様に、セッションBeanおよびメッセージ駆動型Beanに対しては、最も一般的な使用形態であ るという理由から、Beanのすべてのpublicメソッドを公開するデフォルトのビジネスインタフェースが生成されます。
O/Rマッピングまたは永続性のモデルは、「抽象的、永続性、スキーマベース」のアプローチから、今日の主流であるさまざまなPOJO関連アプローチの影響を受けたものに大きく変貌しました。 O/Rマッピングは注釈を使用して指定されます。O/Rマッピングのメタデータは、アプリケーションドメインのエンティティおよび関係をデータベースにマッピングするための、アプリケーション側の要件および想定内容を表現します。
EJB 2.1では、開発者は主キー生成などの特定のデータベース固有操作を実行するために、独自のメカニズムを使用していました。EJB 3.0では、さまざまなデータベース固有操作のサポートが提供されています。O/Rマッピングモデルはその性質上、ネイティブSQLをサポートします。こ の記事では永続性フレームワークの詳細については解説しませんが、概略についてはエンティティBeanの変更点についての説明の中で必要に応じて言及しま す。詳細については、
EJB 3.0 API仕様のサイトから、EJB 3.0の永続性関連のドキュメントをダウンロードしてください。
EJB 3.0では、注釈、依存性注入メカニズム、簡易なルックアップメカニズムの利用を通じて、環境依存性およびJNDIアクセスのカプセル化に対処しています。
エンタープライズBeanのコンテキストは、そのコンテナコンテキストと、そのリソースコンテキストおよび環境コンテキストを構成します。Beanは次の2つの方法で、そのリソース参照、およびそのコンテキスト内の他の環境エントリにアクセスすることができます。
@EJB public AddressHome addressHome;と記述すると、"AddressHome"というJNDI名を持つEJBが自動的にルックアップされます。
javax.ejb.EJBContextインタフェースに追加されたメソッド
Object lookup(String name)を使用します。このメソッドは、BeanのJNDI環境ネーミングコンテキストにバインドされたリソースやその他の環境エントリをルックアップするために使用できます。