Nigel,
Thanks for posting this. John and I will start work on it ASAP. We'll
try to put this on Google doc/some other public space so we can all
review progress and collaborate. I am thinking it should be two
different documents for the two separate approaches. In fact, once we
have a bit more detail, it might not be a bad idea to publish the
proposals as blogs and get community feedback?
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
>
>