EJB 3.1の専門家グループは、JCPを通じて仕様のEarly Draft(source)を公開したEJBの新しいバージョンは、Java EE 6仕様の一部として、2008年の終わりにリリースすることを目標としており、EJB 3から始まった作業の簡略化に基づき、Javaエンタープライズのコミュニティから要求された新しい機能の追加を狙っている。重要な変更は以下のとおり。
- 別個のローカルビジネスインタフェースなしで、セッションビーンへのアクセスを提供する、簡略化されたローカルビュー。これによって開発者は、ビーンクラスのみを利用して、コンポーネントを実装することができる。
- シングルトンセッションビーンコンポーネント: アプリケーションが実行される各JVMに対して、アプリケーションごとに一度、インスタンス化されるシングルトンセッションビーンコンポーネントは、アプリケーションの状態をキャッシュするために、簡略化されたメソッドを提供することを目的としている。シングルトンはEJBのように、トランザクション管理、セキュリティ、リモーティング、DIなどの、EJBの標準的なミドルウェアサービスにアクセスできる。コンテナがセッションビーンクラスのnewInstanceメソッドを呼び出すと、シングルトンが起動される。デフォルトでは、コンテナがインスタンス化するタイミングの決定に責任を持つ。しかし、開発者は@Startupアノテーションや対応するデプロイメント記述子のエントリを利用することで、起動時にインスタンス化することを要求できる。あるシングルトンを別のシングルトンより前に初期化しなければならない場合、(@DependsOnアノテーションを指定することで)別のシングルトンに依存することができる。シングルトンセッションビーンは、それを生成したコンテナが存続している間、生存するが、状態はシャットダウンやJVMのクラッシュによって失われる。それは共有されることを意図しているので、コンテナ管理あるいは開発者による個々のビーン管理において、並列アクセスをサポートする。
- カレンダーベースのEJBタイマー式と自動生成されるタイマー: タイマーサービスは、UNIXのcron機能に似たカレンダーベースの構文を利用して表されるスケジュールの、タイマーコールバックを可能にする。たとえば、以下のスケジュールは「毎週月曜日、水曜日、金曜日の3時15分」を表している。: @Schedule(minute=”15”, hour=”3”, dayOfWeek=”Mon,Wed,Fri”) タイマーサービスはまた、ビーンクラスのメタデータやデプロイメント記述子に基づく、タイマーの自動生成もサポートする。自動生成されるタイマーは、アプリケーションをデプロイするコンテナによって生成される。
- 非同期セッションビーンの呼び出し: デフォルトでは、セッションビーンの呼び出しは、その間、クライアントをブロックする。非同期メソッドの呼び出しで、コンテナはクライアントに制御を戻し、別のスレッドで呼び出しの処理を継続する。非同期メソッドは、クライアントが結果の値の取得、例外のチェック、あるいは処理中に呼び出しのキャンセルを試みることを可能にする、Futureオブジェクトを返すことができる。
- Java EE WebプロファイルなどのJava EEプロファイルとして提供される、エンタープライズJavaビーン機能の軽量なサブセットの定義: このサブセットは以下ような、EJB 3.1 APIの一部をサポートする。ステートレス、ステートフル、およびシングルトンビーン、ローカルビジネスビューおよびインタフェースを必要としないビュー、同期メソッドの呼び出し、インターセプター、宣言的なセキュリティ、コンテナ管理のトランザクション(CMT)境界、ビーン管理のトランザクション(BMT)境界、エンタープライズビーン環境、JPA 2.0、JTA 1.1のユーザトランザクションインタフェース、共通アノテーション 1.0、および基盤となるJava SE 6プラットフォームでサポートされるエンタープライズAPI(JDBC、RMI-IIOP、JNDI、JAXP、Java IDLおよびJAAS)。軽量EJBコンテナはエンタープライズビーンのインスタンスのために、JNDI APIの名前空間を提供しなければならない。パッケージングの必要条件もまた、EJBコンポーネントを.warファイルディレクトリ内にパッケージできるよう、簡略化される。この場合、EJBはejb-jarを必要とせず、WEB-INF/classesディレクトリ内に置かれる。ejb-jar.xmlデプロイメント記述子をWEB-INF内に置くのは任意だ。
スペックリードのKen Saksはブログ(source)を立ち上げ、EJBコンポーネントの共通的なマッピングのサポートなど、専門家グループが作業している項目に関する、さらなる情報を提供している。
開発者のフラストレーションの共通する要因のひとつは、EJBの参照の解決とルックアップに利用されるマッピング情報(たとえば、グローバルJNDI名)にポータビリティがないことです。私たちは、ベンダー固有のEJBコンポーネントのマッピングを必要とせずに、アプリケーションをデプロイできるようにするために、マッピング情報を標準化する方法を調査します。
専門家グループは、まだEJB 3.1を定義するプロセスの初期にいるので、機能のリストは変更される可能性がある。それはまた、コメントエイリアスを通じて専門家グループにフィードバックを提供することで、仕様の次のバージョンの策定に関わる、絶好の機会でもある。