Hello all, I finally made it to the EG! Most of my experience comes from
the consulting realm, so I often times see what it is like for a client to
deploy JMS as a messaging infrastructure.
1. CDI Integration
I'm responsible today for a simple library for supporting JMS in CDI 1.0
applications. In my opinion, it should be a core capability. This would
include support for event management over JMS (firing CDI events results in
messages being sent). In addition, JMS messages should be able to be
forwarded and handled as observer methods.
Being able to inject resources also seems very useful; allowing for a
cleaner API to send messages to destinations that can be injected (ala
@Inject @New Session session; )
2. Simplified APIs
Today JMS requires a true javax.jms.Message instance to work against. For
some reason, creating Message objects requires a session. It would be
easier if you can just fire Serializables, byte[]s, Strings, etc. Obviously
this wouldn't allow for setting properties, reply to's, etc so there is
trade off. Maybe also providing a map of <String,Object> as parameters
would be useful in the payload?
It would be ideal to move away from needing to look up destinations and
simply telling the API "send this data to this destination."
3. Bootstrapping/Configuration
It should be possible to bootstrap a JMS Container the same way you can
bootstrap EJB in 3.1 and the proposed CDI 1.1 capability. I think doing
something like javax.jms.spi.JMSContainer.startup() (with parameters for a
config file, a config object, or similar) would make the most sense. Java
SE 6's service providers are very powerful. In addition, it should be
possible that if JMSContainer.startup returns a JMSContainer instance, then
that also provides lookup capabilities for any destination provided,
assuming that destinations still need to be looked up.
4. MDB replacement
Conceptually, I like MDBs for their built in transaction capabilities.
However, an MDB should be able to run across multiple destinations; and
should be able to operate independent of whether it is a queue or a topic.
This ties in to my CDI capabilities, where MDBs could simply be reduced down
to a CDI observer. A single class, supporting multiple observers within the
same or different methods would allow for a lot more code reuse (as
potentially the message could be intercepted by any old POJO or EJB and have
direct access to the actual bean). One area of strong consistency is the
"mappedName" attribute, where in some containers it is allowed to be a JNDI
location of a destination that this MDB is bound to.
Regards,
John