RE: [ws-rx] PR035, PR009, PR020: DA defs

ws-rx message

A bit of research shows that your transactional delivery case has actually been implemented (JMS Binding Component to JBI http://www.glassfishwiki.org/jbiwiki/attach/JMSBC/Reliability%20JMSBC.pdf ), which reinforces the notion that that as long as an [RMD] implementation precisely states what it means by "delivery", then we have no ambiguity on the message consumer side.

> To say that the RMD can only "deliver" the message to the AD once would need a formal

I believe we only need an "abstract" definition of Deliver, which we already have. Our messaging model defines "Deliver" as the act of transfering a message from RMD to AD - meaning somewhere along the way, a transfer or responsibility takes place, which is really what matters here. Maybe our abstract def of Deliver should make that clearer.

As an RMD implementer, I can decide to implement Deliver the way I like (queuing, callback, store in a database, etc.) provided that (a) I clearly state the delivery semantics of my product (i.e. at what point it releases responsibility) and that (b) my product supports the DA for this concrete definition. The user - or party responsible for the app destination - knows then what to expect.

Taking an extreme case, my RMD product could pass (to AD) every received message. But I could state that my RMD is able to annotate the duplicate occurrences of any message with a "duplicate" tag, and that Deliver operation only concerns those non-annotated messages - the others are to be taken as some kind of notifications. Then I can claim AtMostOnce support.

> Does that mean that it will only ATTEMPT delivery to the AD once? What of that fails?

> What if there is transactionality between the RMD and AD such that a failed processing
> of the message results in a rollback?

Then I would have defined my concrete definition of Deliver e.g. as: "successful delivery transaction via XA interface" , which my RMD is supposed to control - i.e. if the transaction fails, the RMD is aware of it and may retry - but only until first successful completion when under AtMostOnce. Such a concrete transactional definition of AtMostOnce DA has been used in the JMS BC.

> Would a retry be in violation of the expressed DA since the
> message is delivered more than once?

Not if Delivery is clearly defined by my implementation as being transactional - with transaction not retried after first successful completion - like in JMS BC.

As a conclusion I think it is OK to mention " delivery" in DA definitions like we did in the past in this TC - which in turn would make it much easier for our users to understand intuitively these DAs.

Thanks,