Your Opinion Needed: Asynchronous Message Listeners (MDB) in JMS 2.1
Get involved in refining the programming model for declarative message listeners for JMS. MDB has been the only way to do this in Java EE for a long time.
Join the DZone community and get the full member experience.Join For Free
One of the highest priority items left over from JMS 2/Java EE 7 is revisiting the programming model for declarative message listeners for JMS. MDB has been the only way to do this in Java EE for a long time. MDBs definitely have a few things going for them: their syntax is very simple, they are very type-safe yet they provide quite a bit of power behind the scenes for listening to JMS messages in a very safe, reliable and scalable way.
MDBs do however have a couple of weaknesses. One is that they have a very generic JCA based syntax today that is more verbose than they can be. Creating a more JMS-specific syntax also opens up the possibility of a few usability improvements. The other is that an arbitrary managed bean cannot declaratively consume messages - they must be converted to an MDB via the @MessageDriven annotation. This means that for example a REST or WebSocket endpoint cannot declaratively consume JMS messages. I outlined some of these issues during JMS 2 viathis JIRA entry. The JMS 2.1 specification lead Nigel Deakin has recently written up a draft proposal to start tackling some of these possible improvements. The proposal is very detailed and easy to understand for all but the most inexperienced Java EE developers. Nigel is actively looking for your feedback right now. Providing feedback is extremely easy to do and Nigel has done a great job outlining how you can get involved in JMS 2.1.
Nigel has decided to start this work by still focusing on improving MDBs. His plan is to make some early progress and then tackling opening this functionality up to other beans such as CDI. Is this a sound approach or should we be focusing on CDI right now as well? Is simply improving MDB all that is needed? What do you think of the syntax? More recently I've also proposed carrying the new syntax further to create handy abstractions for common message processing patterns. What do you think of this idea? Do you have ideas of your own?
Now is your opportunity to chime in and help design a sound API we can all use. If you are an active JUG member or already part of Adopt-a-JSR you can even participate as a group and provide your input though your JUG.
Published at DZone with permission of Reza Rahman, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.