RE: Proposal and issues surrounding MustUnderstand faults

Hi glen. 

you said ----> 

"it would be good to bring up how Faults are generated, and look carefully
at the 
current SOAP assumption that there is exactly one Fault per message, with a
single
<faultcode>."

This brings up the issue I posted earlier about the sender playing russian
roulette
where he learns about faults generated by a single intermediary or endpoint
one at a 
time and has to keep resending until it succeeds. This can easily happen
because mustunderstand faults are due to version or capability
incompatibility and the sender 
never really knows or needs to know the version of the intermediaries and
endpoints. 
This is not a reasonable way to communicate. 

It would also be nice if we could consider a way for the endpoint to
generate all 
the mustunderstand faults even if an actor in the middle did not understand
a block 
he was supposed to consume. It might be useful to let this block pass
through 
unprocessed and let the endpoint generate a complete fault set. This again
avoids
the russian roulette problem in the presence of distributed actors who are
supposed
to consume them. Again I am planting a seed of an idea for consideration. 

regards
jay kasi

-----Original Message-----
From: Glen Daniels [mailto:gdaniels@macromedia.com]
Sent: Friday, May 11, 2001 4:24 PM
To: xml-dist-app@w3.org
Subject: Proposal and issues surrounding MustUnderstand faults


Hi folks!

On this week's conference call, I volunteered to take a crack at a proposal
for dealing with the difficulty of getting back useful information regarding
which headers in particular were the cause of a MustUnderstand fault.

This message proposes two possible solutions for the problem, and suggests a
bit more exploration into the issue of faults in general.

As background/context, you can read the description of the issue at [1].

** PROPOSAL 1 : Use the <Fault> element

This proposal involves EITHER extending the Fault element with another
sibling to <faultcode>,<faultactor>,etc. :

<faultcode>MustUnderstand</faultcode>
<faultheaders>
 <myNS:Header1 xmlns:myNS="http://some.com"/>
</faultheaders>

OR changing the rules of section 4.4 to allow the <detail> element to carry
information relating to headers, and adding the same <faultheaders> element
underneath <detail>.

** PROPOSAL 2 : Use the header

A similar proposal involves echoing back the offending headers in the
<SOAP-ENV:Header> section of the fault response:

<Envelope>
 <Header>
  <SOAP-EXT:MisunderstoodHeaders>
   <myNS:Header1 xmlns:myNS="http://some.com" mustUnderstand="1">
     Nobody understands me.
   </myNS:Header1>
  </SOAP-EXT:MisunderstoodHeaders>
 </Header>
 <Body>
  <Fault>
   <faultcode>MustUnderstand</faultcode>
  </Fault>
 </Body>
</Envelope>

The second one more cleanly fits the SOAP extensibility model, I think.
This
is potentially one of the "normative extensions" we could add to the spec,
since while not absolutely essential, it would be very handy if most
processors
out there implemented this.

On a slightly broader note, I think in parallel with our discussion of the
potential symmetry and/or differences between headers and bodies, it would
be
good to bring up how Faults are generated, and look carefully at the current
SOAP assumption that there is exactly one Fault per message, with a single
<faultcode>.  While convenient in some ways from a processing point of view,
this does generate a contended resource - and there may be ways in which
fault
information can be orthogonally added to a message in the same way extension
data will be.  I don't want to go into this too deeply in this note, but did
want to sprout the seed of this discussion, which came up on the call.

--Glen

[1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Apr/0097.html

Received on Friday, 11 May 2001 19:48:41 UTC