John,
Thanks for the update.
Is it still our plan to separate your plans into the two phases we discussed?
Phase 1: Improving the API for sending and for synchronously receiving messages
Phase 2: Improving the API for asynchronously receiving messages
(The reasons for me proposing this split can be seen further down this email)
Nigel
On 12/08/2011 02:08, John D. Ament wrote:
> Agreed, however I will likely be breaking out the proposal into two distinct sections:
>
> 1. CDI Support for JMS Client APIs
> 2. TypeSafe JMS Messaging using annotations and CDI Events.
>
> Rather than call any of it "Seam JMS" oriented; and to draw distinctions between the API capabilities, requirements
> and design aspects.
>
> - John
>
> On Thu, Aug 11, 2011 at 8:37 PM, Reza Rahman <reza_rahman_at_lycos.com <mailto:reza_rahman_at_lycos.com>> wrote:
>
> 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 <http://www.avg.com>
> Version: 10.0.1390 / Virus Database: 1518/3807 - Release Date: 08/03/11
>
>
>
>