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>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>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
>>>
>>>
>>>
>>
>