EJB 3.1を以前触ったときとくらべてみた

どうも今日も体調が優れないので小ネタで。

NetBeans6.5RC2をいれたのでいろいろとテストを。今日はGlassfishV3のアップデートセンターが動いているようなので更新リストを見るとEJB3.1の更新があった。早速入れる。あいかわらずWebアプリしか使えないけど。

Webプロジェクトにjavax.ejb.jarをライブラリに追加。これで準備はOK。

以前と同様にStatefulやMessageDrivenは動かない模様。Singletonは動くようになった模様。ローカルのJNDI名の登録も以前のような不思議なものではなく、それらしいものにちゃんとなったようだ。Statefulを使わないアプリも多そうだからこれだけでもかなり実用的といったところかな。


ログを見ると実装クラスのみは「no interface view」というらしい。インターフェースがある場合は「business view」。

JNDIの命名規則

EJBタイプ JNDI名
no interface view java:global/warファイル名/実装クラス名
no interface view java:global/warファイル名/実装クラス名#実装クラス完全修飾名
business view java:global/warファイル名/実装クラス名#インターフェース完全修飾名

となるようだ。

つまり、実装クラスだけの場合2つ登録される。また、「#」のあとに完全修飾名があることで、複数のインターフェースを実装した場合、どちらのインターフェースで取得するかが選択可能というわけだ。


1つのインターフェースで複数の実装クラスがあった場合、どちらを使えばいいのかわからないため、デプロイ時にエラーではじかれる。business viewの場合は@Localを省略しないほうがわかりやすいかもしれない。


JNDI名に完全修飾名が必ずつくことによってJavaEE6対応以外のフレームワークも対応がしやすい・・・といいなぁ。

GlassfishV3上でVisualWebJSFも動くようになった模様。もうこれで大概のアプリは開発できそうだ。あとはVisualWebJSFがJSF2.0対応してJPAも2.0にあがれば、まじで標準APIのみで十分やっていけるだろう。

体調がよければ明日あたりGlassfishV3上でJSF2.0 + EJB3.1 + JPA1.0をやってみたい。JPAはまだまだ2.0がでそうにないから、仕方がない。


ずっとEJBは3.0からDIコンテナの中でも最も敷居が低いといい続けてきたのだが、JNDI名が標準化され、ejb-jarが必要なく、war単体で使えるようになった3.1はもっとも手軽に扱えるコンテナになったと思う。よくあるDIコンテナのようにトランザクションAOPがどうだとかそういうことを考える必要がないから。セットアップが容易ってのはやっぱり重要。標準APIだけに別途jarをセットアップしたりする必要もないし、各種IDEでもサポートされることだろう。

個人的にURLを意識するアプリはフロントエンドをT2FrameworkビジネスロジックEJB3.1、管理ツールや業務アプリはJSF2.0 + EJB3.1という組み合わせがベターになるのかなと。さらにRESTやりたいのならJAX-RSで、SOAPやりたいならJAX-WSで、ガリガリ書きたいのならwicketで。

ビジネスロジックを共通化したいのならejb-jarにしてこれら複数のwarからのビジネスロジックのリクエストをうけれるようにするといいかと。フロントエンドに依存しないビジネスロジックに特化したコンテナという姿がやっと日の目を見る気がします。ejb-jarでリモートインターフェースならばEJBクライアントとしてSwingなどのアプリから高速にアクセスも可能ですし。


[追記]
EJB3.1 EJB 3.1のキーワード作ってみた。