Rüdiger
On 30/03/2012 10:35, Rüdiger zu Dohna wrote:
> Nigel,
>
> On 2012-03-29, at 15:29, Nigel Deakin wrote:
>> On 29/03/2012 12:01, Rüdiger zu Dohna wrote:
>>> On 2012-03-29, at 12:27, Nigel Deakin wrote:
>>>> You offer two alternatives.
>>>>
>>>> 1. Binding to CDI events.
>>>>
>>>> In this, you are defining a listener on a CDI event. How is this related to JMS? Are you suggesting that when a JMS
>>>> message is received the JMS provider automatically fires a CDI event containing the message payload?
>>>> If not, what are you suggesting?
>>> Yes, exactly. The same would work for the sender as well,
>>> and the only thing the business code _has_ to care about,
>>> is one annotation on the event type.
>>> Everything else has useful defaults.
>> So how would the incoming JMS message be converted into a CDI event? Are you proposing a standard mechanism for doing this?
> I think the MDB, that's created for you under the hood to do the actual binding, should be able to convert xml or JSON TextMessage, MapMessages, Serialized objects, and maybe custom conversions. The default encoding for the sender would be xml and could be changed with annotations. But we'd also have to standardize on what to annotate in order to specify JMS custom properties and settings (destination name, ttl, delay, priority, etc.).
So this seems to be a variation in your MessageAPI proposal that uses CDI as the mechanism for calling the business
methods on the server side.
(As I see it, MessageAPI is a way of directly exposing asynchronously-invoked server-side business methods on the client
using a mechanism that hides the details of encoding the request and its parameters in an XML message, sending it, and
decoding it on the server.)
I'm not trying to start a discussion on the merits of this proposal, but to clarify that this is not a proposal to
directly map incoming messages (any incoming message, from any type of application) to CDI events - which is something
that has been suggested in the past.
Nigel