Reza,
Can you please address your proposals to the EG initially?
Nigel
On 04/08/2011 16:21, Reza Rahman wrote:
> 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
>>
>>
>