EJB 3.0の登場

EJB 3.0の登場

XDocletでのコード生成の仕組みが、Java SE 5で登場したアノテーションの仕組みで実現することができるようになってきました。また、EJBに変わる手段として登場してきた「軽量コンテナ」は 「DI（Dependency Injection）コンテナ」とも呼ばれ、依存性を動的に注入する技術が導入されていましたが、これもEJB 3に導入しました。EJB 3はこのような技術の集大成として、良いものを取り入れていく形で、仕様が完成しました。

結果として、セッションBeanとメッセージ駆動型Beanが残り、エンティティBeanはEJB 2.1で進化を止めることになりました。その代わり、Java SEでもJava EEでも利用できるJPA（Java Persistence API）として生まれ変わることになったのです。

図4：EJB 3でのEJBの種類
（画像をクリックすると別ウィンドウに拡大図を表示します）

セッションBeanではホームインターフェースも廃止され、インターフェースと実装クラスの2つになりました。アノテーションの記述でデプロイメント記述子相当の役割も担うことになっています。従ってOOADの思想に基づき、インターフェースプログラミングをすることがEJBを実装することそのものになります。

図5：EJB 3の構成要素
（画像をクリックすると別ウィンドウに拡大図を表示します）

そしてEJBに回帰

このようにEJB誕生の経緯や歩んできた道は間違いではなく、常に注目されてきた技術です。それ故に進化の過程で否定される時期があったかもしれません。しかしJavaテクノロジーを用いて企業システムを構築するための「Java EE」として捉えると、EJBは必須コンポーネントであるのは間違いありません。

軽量からはじまったSpring Frameworkが企業システムで必要となる機能を取り込み重量化しているのは、この事実を顕著に示しているといえます。

EJB 3となり、もう開発者はEJBを利用しているという意識をすることがなくなりました。なぜならPOJOでエンティティオブジェクトやビジネスロジックが記述できるのです。アノテーションを利用しコンテナにEJBであることを伝え、リソースは同じくアノテーションを利用してDIによりインジェクトされます。 実装ではほとんどルールがなく、記述するのはただのJavaのクラスです。ある時期皆がこぞって「軽量コンテナ」を利用したことを考えれば、標準仕様のEJB 3を利用しないことの方が不自然になるでしょう。

現在、EJBは更なる進化のためにJSR 318で「Enterprise JavaBeans is an architecture for the development and deployment of component-based business applications.」として、EJB 3.1の仕様策定が進んでいます。

JBoss EAP 4.2ではEJB 3を利用することが可能です。次回はJBoss EAP 4.2.0でEJB 3とJPAを持ちいたエンティティを実装して動作させてみます。