RE: An analysis of mustUnderstand and related issues

Hello. 

Some comments on Noahs and Henriks comments: 

Henrik said ---> 

>>> As the processing model doesn't allow for partial success,
>>> applications may always have to perform some form for
>>> compensation if the processing suddenly goes wrong in the
>>> middle.
>>>

Noah responded ----> 

>Whoa... that seems really complicated, and as noted above
>I don't see where the spec requires this. Nothing in
>SOAP says anything regarding atomicity.  Indeed, we
>seem to have been quite clear in other discussions
>that anything resembling transactions is separate
>from core SOAP.

I agree with Noah. 

How far do we want to go in the direction of atomicity? Especially
distributed atomicity? (even if we were willing to change SOAP in this
area). 

Distributed atomicity: 

This is next to impossible to achieve. Async Response error messages that 
exactly backtrack can get lost without guaranteed delivery or get
permanently
stuck and require manual intervention. If you closely examine guaranteed 
delivery (every flavor that I know of) there are corner cases where messages

are not guaranteed to reach the destination and the error is not guaranteed
to 
make it back to the sender. Also many of them require retries from the send
side
and therefore messages are duplicated and processed twice. There are even
cases 
where the outcome of the message (processed or not processed) is "unknown"
to 
the sender. Also synchoronous messages typically do not support guaranteed 
delivery of any kind and clearly distributed atomocity does not apply to
them. 
I am sure Henrik is not proposing this?  

Single node atomocity: 

Clearly some of the actors like a cache manager have nothing to do with
persistence
and clearly are not really covered by atomicity aspects. Insisting all
persistence 
at a node share the same logging mechanism and transaction manager (unless
you want 
to get into the never never land of two phase commits) is a dracoonean
limitation. 
Even in the case of two phase commits, there is heuristic completion. Also
two 
phase commits really dictates the kind of server technology and the way apps
are 
written and therefore are darcoonean constraints. I suspect Henrik is not
proposing 
this either? 

Implications of retries: 

One thing that occurs to me is what is the implications to SOAP
mustunderstand when 
messages are transparently retried, say,  due to a protocol on top (assuming
guaranteed 
delivery or any kind of retries - even at the transport level for certain
kinds of async transports - is out of scope for SOAP itself). 

This is not a question about atomicity but duplication. For example what if
a billing 
record is emitted twice by executing a mustunderstand? Is there any concept
of 
idempotency? Clearly SOAP does not address such broader issues I dont think?


atomocity, guaranteed delivery, duplication and idempotency are very complex
issues.
Do we want to go there with SOAP or leave it to a higher level?

Received on Friday, 25 May 2001 01:46:23 UTC