JavaOne TokyoでEJBスペックリードのデミケル氏、3.0の最新動向を語る：JavaOne Tokyo 2005 Report

EJBは扱いやすいものとなる。従来までの難解さを払拭し、エンタープライズJavaアプリケーション開発で要となるEJB 3.0は、正式公開に向けて洗練されてきた。

[山田和夫，ITmedia]

　バージョン2.1までのEJB（Enterprise Java Beans）は何かと批判の高いテクノロジーだった。

　パフォーマンスに対する批判にはじまり、アプリケーションの作りづらさ、扱いも難しいという批判は多くの開発者がEJB採用を躊躇するものだった。エンタープライズ向けのJavaアプリケーション開発で必須といえるEJBが、3.0で大きく生まれ変わろうとしている。

　まったく別物といってもよいほどの変貌を遂げながら、同時に互換性と移行パスを提供するEJB 3.0のセッションは、10日まで東京国際フォーラムで開催された「JavaOne Tokyo 2005」のセッション会場がほぼ満席とよいほどの人気を博す内容となった。スピーカーはEJB 3.0のスペックリードを務める米Sun Microsystemsのリンダ・デミケル氏。

　セッションではEJB 3.0のファイナルドラフトへと向けた作業から、全体的な目的や「Simplified EJB 3.0 API」の特徴をEJB 2.1との比較を用いながら概観した上で、EJBのみならず「Javaの」永続化APIへと拡張されていく「Java Persistence API」にも簡単に触れた。

インタフェースの激減

　EJB 3.0の特徴としてとにかく最初に目立つのが、必要なインタフェースの減少だ。

　これまでのEJBは、リモートオブジェクトを扱う以上インタフェースが必要になるのは理解できても、いかにも回りくどいと感じるコーディングスタイルを要求していた。EJBの過剰とも感じられるインタフェースの利用は、開発コスト、保守コスト、開発者のストレスとなっていたのだ。それが必要最小限にまでそぎ落とされたため、EJB 3.0のプログラミングモデルは爽快にすら感じる。

　今回のセッションで象徴的なのは、EJB 2.1との比較において「EJB 3.0では、これはなくなりました」という説明が多かったことだ。例えば、EntityBeanを筆頭とするEnterpriseBeanは必要なくなった。これによって、エンティティを実装する際によく目にした、次のような例、

public void ejbActivate(){}

public void ejbPassivate(){}

public void ejbRemove(){}

　　：

　　：

といった形式的でうんざりするようなコードが不要になる。interfaceをimplementsするというスタイルではなくなるため、実装の不要なメソッドはスタブすら不要になるのだ。

　形式的なコードといえばJNDIの記述も不要になる。InitialContextを作ってオブジェクトをルックアップするといった、決まりきった手続きは姿を消し、次のような、

@Resource

DataSource ds;

アノテーション記述が可能になる。ここでも、EJBオブジェクトにたどり着くまでの数行が姿を消す。たかが数行、されど数行である。

　姿を消したから機能が低下したというわけではない。アノテーションを用いるうえで1つのポイントになっているのが、デフォルト値の多用だ。

　数多くのデフォルトが提供されていることがコードの単純化に大きく寄与している。共通のパラメータや典型的な利用法は、あらかじめデフォルトとして与えられているからだ。

　例えば、CMT（Container-managedトランザクション）がデフォルトとなり、BMT（Bean-managedトランザクション）を使いたい場合にはアノテーションで指定するといった具合だ。トランザクションやセキュリティの振る舞いには、このようなデフォルトが多く与えられていることも、開発者の負担を減らす。

フットワークを軽くする永続化API

　Java Persistence APIは、もともとEJBのうちエンティティBeanの単純化を目標としていた。それが開発者から強く要請されているものであることは、HibernateのようなO/Rマッピングソフトウェアの流行が示していた。

　ここでのポイントの1つに、EJBコンテナを要求しない永続化APIという目標があったが、それは議論に伴って拡張されていき、現在はJavaの共通な永続化APIとして検討されている。

　EJB 3.0のエンティティはこの永続化APIに基づくため、いわばEJBではなく普通のJavaBeansがEJBで扱えることになる。これは開発者にとってメリットが大きく、これまでのように永続化が億劫に感じることは減るはずだ。さらにこのAPIは目標を高めて、サービスプロバイダアーキテクチャを取り入れようとしている。つまり、永続化APIプロバイダをプラグインして利用するものだ。

互換性と移行パス

　従来のEJBからEJB 3.0の移行は段階的に、徐々に行える。

　エンティティの実装方法が劇的に変わっても、クライアントからのビューは変わらない。昨日までのEJBクライアントは明日からのEJB 3.0オブジェクトを呼び出すことができる。いくら複雑だといってもデプロイメントディスクリプタから逃れることのできないプロジェクトはあるだろう。そのようなプロジェクトではDIを使わずにデプロイメントディスクリプタを使うという選択肢もある。

新たに必要な学習は“アノテーション”

　これらの変化は、アノテーション、DI（依存性注入）、AOPといった最新の、あるいは注目の技術を惜しみなく投入した結果だ。

　例えば従来デプロイメントディスクリプタに延々と記述していた、コンテナや環境に関する設定は、前述の@Resourceのようなアノテーションを用いたDIスタイルに姿を変える。ビジネスロジックのメソッド呼び出しを包み込むようにコントロールする@Interceptorsのアノテーションは、AOPを実現する仕組みだ。

　しかし、それらの最新技術は（概念はともかくとして）新しく覚えなければならないことは必ずしも多くなく、ほぼアノテーションの理解・記述に集約されるといえることに気が付くだろう。

　従来のEJBへの批判が、その使いにくさに基づくものであることを考えると当然のことで、スピーカー、リンダ・デミケル氏の「EJB 3.0がデベロッパーに使ってもらえるように」という発言がその気持ちを物語っているだろう。

　現在、夏に発表されたPR版に集まった意見を集約し、12月に発表することを目標としたファイナルドラフトへと向けて、作業は進行中であるという。