Gavin King posted the first part of his wish list for the next version of the Java EE specs, focusing on EJB Session Beans.
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...
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.
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?
It would be nice if the spec defined a callback on how the application server selects a node to notify an MDB when a message is posted to a Queue. For example, if my cluster has four nodes - two in Indiana and two in California, I would like to have a say in which two nodes should process messages during certain times etc.
> <ul> > <li><strong>Concurrent session beans</strong><br/> > <blockquote> > <p>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. </p> > </blockquote> > </li>
Concurrent Session Beans to support Singletons?? Strange. I wonder if King really understands Session Beans.