John,
Thanks. I look forward to seeing your proposals!
Nigel
On 12/08/2011 23:51, John D. Ament wrote:
> Nigel,
>
> Yes, but I don't like calling them "phases," more like "two alternative APIs."
>
> On Fri, Aug 12, 2011 at 6:15 AM, Nigel Deakin <nigel.deakin_at_oracle.com <mailto:nigel.deakin_at_oracle.com>> wrote:
>
> 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
>>
>>
>>
>>
>