Hi folks,
I am primarily concerned with modernizing the JMS API towards better
ease-of-use/productivity for developers/end-users. I would like for us
to take a look at the Seam 3 JMS Module, Apache MyFaces CODI JMS Module,
OpenWebBeans JMS Extensions, Spring JmsTemplate, CDI, EJB 3.1 and come
up with a self-contained higher level abstraction for both sending and
receiving JMS messages. It has always been a bit puzzling to me as to
why such essentials abstractions are left to third-parties and other
specifications when they could be addressed by the JMS specification
itself. Finally doing this in JMS 2 should be relatively easy with the
advent of CDI and the CDI Portable Extensions SPI.
I am hesitant to be too specific on some of this because I believe that
we should start with some basic ideas and hash out the details as a
group. Here are the specific things I would like to see from a
relatively high level:
* Making better use of unchecked exceptions. The overuse of checked
exceptions in the current JMS API makes it cumbersome without really
adding much value.
* The capability to inject not just connection factories and
destinations but also connections, sessions, producers and receivers in
a thread-safe fashion into any Java EE component.
* Sending JMS messages using CDI Events in a highly declarative fashion.
* Receiving JMS messages through CDI Observers in a highly declarative
fashion. Such an API should take into account concurrency, pooling,
transactions, reliability and acknowledgment much like EJB Message
Driven Beans do today albeit using much older, component-model-centric
semantics.
If helpful, I am happy to share further design details on any of the
above. We have done some of the initial design work for the Resin
approach to CDI/EJB/JMS messaging. As such, it didn't take us long to
come up with the design for Resin in a relatively portable fashion.
I do see the other issues slated in the JMS 2 proposal as being very
important as well. These include cloud support, improved pluggability as
well as any incremental API changes to better reflect common vendor
extensions and any possible advancements in the (relatively mature)
field of messaging -- as long as there is clear/concrete benefits to the
end user/developer (with backwards compatibility in mind given the very
wide deployment of the JMS API).
Cheers,
Reza