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> 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
>> Version: 10.0.1390 / Virus Database: 1518/3807 - Release Date: 08/03/11
>>
>>
>>
>