Gavin King, currently lead of the Seam project, and prior to that of Hibernate, started to share some of his ideas about enhancements to the next version of the Java EE spec in EE 6 wish list part I: EJB Session Beans. The first installment of his Java EE 6 wish list focuses on six new features for EJB Session Beans:

• Concurrent session beans
  

  One major reason why we need concurrent beans is to support the idea of singleton beans which share state between all threads on a single node. Singletons are useful as caches, or for holding application configuration data... Actually, introducing singletons could help kill two birds with one stone...

• Lightweight asynchronicity
  

  Currently, there are two approaches to asynchronous processing in EJB. The first is JMS. JMS is perfectly reasonable for cases where I have well-defined quality of service requirements, such as guaranteed delivery, etc. However, it's overkill for many cases. The second approach is the EJB timer service... If the timer service is going to become generally useful, it's going to need some major enhancements...

• Stateful web service endpoints
  

  Currently, only stateless session beans may function as web service endpoints. With some integration with WS-Contexts or WS-Addessing (or whatever WS-blahblah is appropriate), we would be able to support a stateful session bean that acts as a web service endpoint.

• Replication callbacks
  

  Currently some containers overload the @PrePassivate and @PostActivate callbacks when replicating, while others don't. Passivation has distinctly different semantics to replication, so this is not really appropriate. But some kind of callback is needed.

• Optional business interface
  

  The fifth item on my wishlist is a pure ease-of-use concern. Currently, EJB mandates that all session beans have some @Local or @Remote interface. This was not an unreasonable requirement when session beans were understood to exist in a business tier, with a well-defined API sitting between the business logic and the client. But now that we're using session beans everywhere - even for presentation logic - it's clear that defining the local interface for every bean is simply a PITA.... The interface should be optional, and when it is missing, the public methods of the bean class should be taken as the business methods of the session bean.

• Simplified JMS/JavaMail sending
  

  The sixth item ... is to simplify JMS message and JavaMail sending. Currently, it is possible to inject a Topic or Queue using @Resource, but of course what I'm really interested in is QueueSender or TopicPublisher.

What's on your EJB features wish list for Java EE 6?