第2回　鍵はPOJOベースのアプリケーション・デザイン

Page.1

Page.2

---

POJOなサービス・オブジェクトをEJBでラッピングする

　Springコンテナをビジネス層に使用することで、もはやEJBコンテナは不要であるかのように思われる方も多いかと思います。しかし、そんなことはありません。もし、システムの要件が以下の問いに1つでも当てはまるならEJBの採用を検討すべきです。

• 2フェーズコミットメントに参加できないレガシーなリソースを同一トランザクション内で扱わなければいけない部分があるか
• ビジネス・ロジック内でトランザクションをネストして、コミットとロールバックを個別に行わなければいけない部分があるか
• 機能的に分散したアプリケーションを連携する必要があるか
  
• 分散アプリケーションの連携において、トランザクションを伝搬させたい
• 分散アプリケーションの連携において、ユーザーIDやロール情報を透過的に扱いたい
  

　この場合には、POJOなサービス・オブジェクトをデレゲート呼び出しするSessionBeanのラッパークラスを用意すればよいでしょう。Springフレームワークには、POJOをラップしたSessionBeanに対して、ルックアップ・サービスとビジネス・デレゲートの実装を含むプロキシーのバイトコードをランタイムに生成し、クライアントに提供する機能があります。Java EE 5.0と同様に、もうルックアップ・サービスもビジネス・デレゲートも実装する必要がないのです。

　以下が、SessionBeanラッパーのためのSpring定義ファイルの例です。

　これはちょうど、従来のルックアップ・サービスの設定ファイルに相当するものと考えられます。もし、EJBでラップせずにPOJOのサービスを使用したい場合には、上記の定義を以下のものと差し替えればよいでしょう。

　クライアント（すなわち、JSFバッキング・ビーン）から見て、両者は全く同じものに見えます。このメリットは、JSF開発において有効に利用できます。後者の定義を使用してPOJOでワイヤリングしたWARファイルは、デプロイ処理のオーバーヘッドがほとんどないため、デプロイと動作確認のサイクルを短時間に繰り返すことができ、JSF開発を効率的に進めることができます。比較的サイクルの長い結合テストの際には、前者の設定ファイルに基づいてEJBを含むEARを使用すればよいでしょう。

　EJBそのもの開発は、XDocletとカスタムdocletを組み合わせることで、アプリケーション開発者はPOJOなサービス・オブジェクトの実装に完全に集中することができます。SpringフレームワークとEJBサポートを利用したより詳細な解説は本連載の第4回に予定しています。

ビジネス・オブジェクトはCMPではなく、  HibernateでO/Rマッピングする

　前回簡単に紹介したように、EJB 3.0のエンティティ・ビーンは、Hibernateと同様POJOとして実装することができ、両者の機能には多くの共通点があります。残念ながら、HibernateのSessionクラスとEJB 3.0のEntityManagerクラスのAPIには互換性がありませんので、Java EE 5.0への移行に当たって最も影響を受けるのは、Hibernate実装のDAOクラスです。しかし、少なくとも両者の実装の違いは、DAOクラスの実装に隠ぺいされるため、DAOを使用するビジネス層のサービス・オブジェクトには全く影響を与えないことが保証されます。もし、CMPベースのエンティティ・ビーンで、ビジネス・オブジェクトを実装してしまったら、EJB 2.x仕様への依存性が将来問題となるでしょう。

　インテグレーション層へのHibernateの採用の最大のメリットは、DAOクラスの単体テストがEJBコンテナなしで実施可能なことです。これは、SpringフレームワークのDIと組み合わせることにより、その効果は大きくなります。通常、Hibernateを利用したDAOオブジェクトは、 SessionFactoryオブジェクト、DataSourceオブジェクトとの依存関係を持っています（図3）。

図3　Hibernate DAOの依存関係

　これをSpringでワイヤリングすると以下のようになります。

　ここで、dataSourceは、アプリケーションサーバにJNDI名で登録されたリソースとして設定されているため、このままではEJBコンテナ上でしかDAOを動かすことはできません。ここでも、Springと組み合わせることで、この問題を簡単に解決することができます。Springには、JDBC DriverManagerクラスをラップしたDataSource互換クラスとして、DriverManagerDataSourceクラスが用意されており、EJBコンテナの外で利用できる便利なDataSource実装です。DAOの単体テストを実施する場合には、上述のSpring設定ファイルの dataSource定義の部分を以下のものと置き換えることで、DAOの単体テストが可能になります。

　Java EE 5.0の場合も、EntityManagerをEJBコンテナ外で使用するためのAPIが用意されています（JavaOne開催中に公開されたPublic Review版の「EJB 3.0 Persistence API」の5.2.2.2節を参照ください）。

まとめ

　このように、SpringのDIは、プレゼンテーション層からインテグレーション層の3層にわたって、独立性の高いアプリケーション・コンポーネントを結合し、状況に合わせたワイヤリングを工夫することで、さまざまな状況に対応することができます。ワイヤリング変更は、開発サイクルにおける単体テスト実施のための短期的な変更から、Java EE 5.0コンテナへのマイグレーションのような長期的な変更があります。いずれの場合も、POJOを意識した独立性の高いコンポーネントをベースにアプリケーションを設計することで、環境の変化に強く、長期的に再利用可能なアプリケーションを実現することが可能となります。

　次回は、プレゼンテーション層のJSFに注目し、POJOベースでの具体的な開発手法について解説します。

2/2

INDEX
第2回　JSF、Spring、Hibernateが最適な組み合わせ
	Page1 古典的なWebアプリケーション・アーキテクチャ POJOベースのWebアプリケーション・アーキテクチャ なぜ、プレゼンテーション層はStrutsではなく、JSFなのか？
	Page2 POJOなサービス・オブジェクトをEJBでラッピングする ビジネス・オブジェクトはCMPではなく、HibernateでO/Rマッピングする まとめ

Java Solution全記事一覧

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）