batching replies for response reply pattern

[Tom Rutt <tom@coastin.com>]

I now have a strong opinion that the rm-fault reporting mechanism should 
remain independent , at least conceptually, from the soap fault model.

We should reserve the soap fault model to pertain to the payload of the 
reliable message.  Its wsdl defines an operation supported
by a web service instance, and we should keep the soap fault model f to 
pertain to the payload of the wsdl operation.

Case 1:
For wsdl request/response operation types, a soap fault can occur for a 
reliable request which was delivered ,
but then encountered an application level fault due to something wrong 
in the payload (soap body of request which
is not under control of Sending RMP) or application processing space 
outside the realm of the Receiving rmp.

That means a WS RM ack can be delivered on a soap fault.

Case 2: (a little more complicated)
Lets try to keep our rm fault mechanism outside of the soap fault model.

That would mean, that for the response reply pattern with wsdl two way 
messages, the return message could conceivably carry
an indication of an RM fault., which is not itself carried on a soap 
fault.  However this might cause problems.

We have agreed that a message with an RM fault indication MUST not be 
delivered by the Receiving RMP.
If the message cannot be delivered due to an rm header error, then there 
could be no meaningful data for the responder to put
into the soap body for the WSDL response  In fact the responding 
application is outside of the decision to issue and RM fault
reply for that messageID.  Thus in the response reply pattern case, the 
RM reply will Most likely end up on a soap fault,
associated with the wsdl operation itself.

But conceptually, I think it works to keep the rm fault model and the 
soap fault model separate and distinct

A natural consequence is that sometimes RM fault conditions may result 
in soap fault conditions, especially for the respone reply pattern.

If we take this principal, there is no Fundamental problem having a 
rm-response for a response reply pattern message having a batch of
acks or fault indications.   However, this would not work in all 
applications, since in some cases the different requests in a group could
come from different sources.

Thus perhaps we can soften the wording to allow a receiving RMP to batch 
both acks and fault indications on the response, for all reply 
patterns.  Giving extra information to the Sending RMP would help in 
cases where the previous tranport connection is no longer available
to return a prior ack.  If it goes to the wrong source, then it can be 
ignored by that source, but if the source knows about
the message IDs it will most likely appreciate the extra reply information.

Tom Rutt

Tom Rutt.  .

-- 
----------------------------------------------------
Tom Rutt		email: tom@coastin.com; trutt@fsw.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133