jsr343-experts@jms-spec.java.net

[jsr343-experts] Re: Message-API

From: Nigel Deakin <nigel.deakin_at_oracle.com>
Date: Tue, 22 Nov 2011 18:04:18 +0000

On 22/11/2011 09:14, Rüdiger zu Dohna wrote:
> Hi all,
>
> I had a very nice long chat with Nigel at devoxx. We agreed that the MessageApi will probably have to prove itself
> better before it can be put into a Java EE standard. The concepts look promising, but they have to stand the test of
> a bigger community to make sure that it's not just the confusing offspring of an ivory tower project, but are robust
> and practicable. I will still try to separate something that can be seen as proposal for an eventually optional
> chapter of the standard, while the implementation becomes more complete. If it catches on and things get faster than
> they do right now, it might happen that it still can be added to the 2.0 spec, but that's not very likely to happen
> without a bigger user base.
>
> I've moved the Wiki page with the proposed annotations over to the MessageApi java.net project:
> http://java.net/projects/messageapi/pages/Annotations
>
> And I've put up a FAQ for the kind of questions Nigel thinks need good answers, before it can go into the standard:
> http://java.net/projects/messageapi/pages/FAQ
>
> Maybe some members of the user group want to help promoting this. It might be useful to move the project over to Seam
> or some other place, so it becomes more visible to more potential users and, of course, more potential contributors.

Yes, it was great to meet Rüdiger and have an opportunity to give MessageAPI the attention it deserves. It's an elegant
piece of software.

I agree with Rüdiger's summary above. My main concern was to clarify the relationship to technologies such as async EJBs
and generally see how it fits on with other technologies.

One detail I hadn't spotted until Rüdiger pointed it out was that like a async EJB call it allows the client to invoke a
remote method asynchronously, though with JMS QoS. However unlike async EJB it doesn't provide a direct mechanism for
the server to return data back to the client.

Rüdiger and I agreed that perhaps the best way forward is to see whether there was wider community interest in using
this mechanism for other applications before we needed to consider standardisation.

Nigel