Hi all,
[I'm still in the process to join the EG, so I post this to the users
mailing list, instead.]
I think that JMS spans different logical layers, and that's how I'll
separate my priorities.
The highest, purely functional, business logic layer is most important
for me to address. One option is using CDI events, another one is what
we call the MessageApi, which hides message sending and receiving behind
a clean business interface (see
http://java.net/projects/messageapi;
recent update: new article:
http://java.net/projects/messageapi/downloads/download/MessageAPI.pdf).
The layer below that is concerned with message topology, addressing,
routing, delaying, selecting, etc. Most requirements this layer
addresses are non-functional, but it often contains some business logic,
too. A large part of JMS 1.1 is concerned with this layer and JMS 2.0
could add a lot by making that easier, e.g. with annotations. But it's
important to find the right balance between what we (optionally) want in
the code (functional aspects) and what we want in the MOM configuration
(non-functional aspects).
The third layer defines the logical message format. This layer is a core
part of JMS 1.1, but I'd like to get rid of it (cf. MessageApi), i.e.
actually deprecate it. But maybe that's just too radical ;)
The fourth layer would define the wire format, but I suspect
standardizing this would be too limiting for implementations. There are
other groups that try that, and settling on one could delay this JSR too
much. I think it would be easier to find broad adoption if we'd instead
define a plugin mechanism that all containers and implementations would
have to support, so you can have multiple JMS implementations running in
one container and configure which one to use for which message.
Maybe it would be a good idea to align the words we use with those used
by others, esp.
http://www.enterpriseintegrationpatterns.com
Regards
Rüdiger