Yes. Although our discussions are intended to be open, and individuals can make contributions at any stage, I think the
EG needs to reach a degree of consensus before actively inviting comments on anything, otherwise we risk confusing the
wider community.
jms-spec.java.net contains a wiki which you should be able to add content to, if you think that would be useful.
Nigel
On 04/08/2011 16:54, Reza Rahman wrote:
> 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
>>
>>
>