Nigel,
Just to keep you informed, John and I met in-person today.
He agreed to write the "Seam JMS" style proposal while I concentrate on
the "Spring JMS" style proposal. As part of my analysis, I will explore
the possibility of a completely new JMS API. We will both look for ways
to make incremental changes to improve the existing API while writing
our proposals. For John's proposal, we agreed to include the option of
injecting the existing JMS objects (in line with my previous examples)
as well as a JMS/CDI event bridge. I still do not believe the JMS/CDI
bridge can be a flexible, general purpose solution that leaves the
capabilities of the existing API intact. Similarly we both agreed that
the "Spring JMS" style has weaknesses and some strengths.
We hope to get the initial proposals ready for review by next week.
Cheers,
Reza
On 8/4/2011 4:55 AM, Nigel Deakin wrote:
> Here are some minutes from a phone call that John, Reza and I had
> yesterday. One-line-summary: Reza and John have agreed to work
> together and produce a more detailed proposal along the lines
> described below, which could then be reviewed by this EG. Many thanks!
> Nigel
>
>
>
> On the call: Nigel, John, Reza
> Minute taker: Nigel
>
> Reza and John have offered to work together to develop proposals to
> address "(JMS_SPEC-33) Improving the JMS API with API simplifications,
> annotations and CDI"
>
> The purpose of this call was to agree on the scope of that proposal,
> and a suitable phasing.
>
> Scope
> -----
>
> The proposal would be aimed at improving the way that JMS was used in
> Java EE applications.
>
> Improving the way that JMS is used in Java SE applications was
> considered hightly desirable but a secondaery requirement.
>
> Phasing
> -------
>
> Nigel explained that he thought any proposals should be divided into
> two phases:
>
> Phase 1: Improving the API for sending and for synchronously receiving
> messages
> Phase 2: Improving the API for asynchronously receiving messages
>
> Phase 1 was a higher priority than Phase 2 because whereas Java EE
> applications currently have no choice other than to use the JMS API
> for sending and for synchronously receiving messages, applications
> that asynchronously receive messages can (and must) use MDBs which are
> declarative and already completely hide the JMS API.
>
> Dependencies
> ------------
>
> Phase 1 could probably be built as a later on top of the existing, or
> slightly modified, JMS API. It would have minimal dependencies on the
> Java EE platform or on other Java EE specs.
>
> Phase 2 would require close integration with the Java EE platform, for
> the same reason that means MDBs are implemented in the platform rather
> than the JMS provider. There would be dependencies on changes to the
> Java EE platform and to other Java EE specs.
>
> Nigel explained that he was advocating this two-stage approach becayse
> Phase 2 looked as if it would take more time and require more
> negotiation with other groups, and he didn't want this to prevent the
> EG making rapid progress with Phase 1.
>
> Phase 1 in more detail
> ----------------------
>
> We discussed Phase 1 in more detail. It was agreed there were two main
> possible approaches:
>
> 1. A new API which used resource injection and annotation. The SEAM
> JMS project was suggested as an example of this approach. Reza had
> already published some examples of such an API.
>
> 2. A simplified "plain old" Java API, not using resource injection or
> annotation, which provided various utility methods for sending and
> synchronously receiving messages. The Spring JMSTemplate class was
> suggested as an example of this approach.
>
> In both cases, whilst the goal would to devise something that would
> use the existing JMS API, this would not preclused small changes to
> the JMS API if this would allow a simpler API overall. One suggestion
> providing message factory methods which didn't depend on a Session
> object.
>
> It was likely that the RI for both approaches could be used by other
> vendors, though it was not intended to precluse vendors offering their
> own implementations.
>
> There was also a third option, to develop a completely new JMS API,
> not using resource injection or annotation, and NOT built on top of
> the existing API. This wasn't something EG members have suggested so
> far and although it might be worth including in any review of options,
> it didn't seem a likely option.
>
> Timscales
> ---------
>
> Reza and John suggested that would aim to have some proposals that
> they could share with the EG in about two weeks.
>
>
>
>
>
>
>
>
>
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1390 / Virus Database: 1518/3807 - Release Date: 08/03/11
>
>