Nigel,
Yes - of course. I was actually thinking you should do the blog on
behalf of the EG once we have discussed it a bit (perhaps on Java.net).
If you are OK with it, we can get it syndicated with TSS, JavaLobby and
InfoQ to reach a wider audience.
Cheers,
Reza
On 8/4/2011 11:31 AM, Nigel Deakin wrote:
> 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
>>>
>>>
>>
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1391 / Virus Database: 1518/3810 - Release Date: 08/04/11
>
>