Hibernateの作者でありSeamプロジェクトの指導者であるGavin Kingが、彼のJEE 6の機能に対するウィッシュリストを含む投稿のシリーズのうちの一番目を投稿した。Gavinのリストにおける最初の項目は、ステートレスセッションビーンとステートフルセッションビーンに対する並行性モードの追加である。彼は三つのオプションを提案している。
- 並行性なし。デフォルトであり、現在サポートされている振舞いである。 Beanは並列クライアントをサポートしていない。二つのリクエストが同時に到着すると、コンテナはConcurrentAccessExceptionを投げることが許されている。
- Bean管理の並行性: Beanは複数のスレッドからの並列アクセスをサポートし、揮発性のデータ構造へのアクセスを管理する責任がある。
- コンテナ管理の並行性: Beanは並列クライアントをサポートし、コンテナはBean実装に到達する前に並行しているスレッドの同期を確実に行う責任を負う。
Gavin が提案する二番目の項目は、軽量の非同期処理である。彼は、現在のJMSとEJBタイマーでは不十分だと主張している。加えて、@Timeoutが付与されたメソッドを一つのBean内に複数定義できること、スケジューリングのオプションをさらに増やすことを提唱している。三番目に述べられている項目は、ステートフルなWebサービスエンドポイントである。
... 現在、ステートレスセッションビーンのみがWebサービスのエンドポイントに成り得ます。WS-ContextsかWS-Addressing(もしくは何か別のWS-ほにゃほにゃ)と少し統合すれば、ステートフルセッションビーンがWebサービスのエンドポイントとして動作するようにサポートできるのではないでしょうか。実際これがどのように見えるかはまだ知りませんが、Seam/WSにおそらく関連したところで実験しようとしています。
Gavinのウィッシュリストの締めくくりは、EJBのビジネスインターフェースを省略可能に、JMS/JavaMailの単純化、拡張されたロギングインジェクション、EJBメタアノテーションである。彼は省略可能なビジネスインターフェースに関してこう主張している。
現在、EJBはすべてのセッションビーンが@Localインターフェースか@Remoteインターフェースを持つよう強制しています。これはビジネスロジックとクライアントの間で明確に定義されたAPIを持つセッションビーンがビジネス層に存在していた場合は理解できない要件でもありませんでした。...特に、Seamのような環境では、 BeanのクライアントはEL式の入ったJSFページだけだったりするので、インターフェースは全体的に余分なのです! ... インターフェースは省略可能であるべきで、もしインターフェースがなかった場合、Beanクラスのpublicメソッドがセッションビーンのビジネスメソッドとして取り扱われるべきです。...（原文は2007年4月2日にリリースされた記事です）