1. Configuring JMS
The JMS API should not rely on JNDI, so it is usable outside an application
server (inside Tomcat, a batch or a lightweight ESB).
This configuration should include pooling of JMS ressources.
We should work on this with the other members of JEE 7, as this is currently
an open debate:
http://agoncal.wordpress.com/2011/06/10/debate-and-what-about-configuration-in-java-ee-7/
2. Simplifying the JMS API
The current API should be simplified:
- Some parts of the APIs are unclear, for instance the acknowledgement part.
We should just have "auto", "client", "dups-ok" or "transacted", like what
Spring JMS uses.
- There should be an easier API to send and receive messages, like Spring's
JMSTemplate. Utility libraries and wrappers shouldn't be needed for simple
use cases.
3. Using Annotations
Like every other specifications, JMS should be used with annotations.
4. Using MDB everywhere
MDBs should not be reserved for application servers. We should have
"message-driven POJOs" as seen in Spring JMS, by using annotations on a
simple Java object.
5. Clustering and failover
As the theme of JEE 7 is "the cloud", there should be some
clustering/failover facilities in the specification.
For instance, we should be able to configure failover as in ActiveMQ from
the standard configuration:
http://activemq.apache.org/failover-transport-reference.html
We should also have a callback for catching failures, in order to implement
some specific business logic for those cases.
6. Batching
We should be able to do send messages in batches, and not only one at a
time.
--
Julien Dubois
Twitter: @juliendubois <http://twitter.com/#!/juliendubois>