RE: mustUnderstand on client side

I think this is especially dangerous in a RPC style communication.  For
example, if a client sends an order for 1000 cases of blue widgets to a
server, the server processes the order and returns an acknowledgment
with a mustUnderstand header that the client can handle, do we really
want the Soap processor on the client to generate an error?  What
happens to all those widgets?  How does the client determine whether the
order succeeded or not?  May be better approach would be to return a
warning that made it clear that the action succeeded but processing the
response failed.

-----Original Message-----
From: Mark Nottingham [mailto:mnot@akamai.com] 
Sent: Monday, April 23, 2001 12:55 PM
To: Frystyk
Cc: soapbuilders@yahoogroups.com; xml-dist-app@w3.org
Subject: Re: mustUnderstand on client side



Just thinking out loud...

There seem to be a number of conflicting interests re: what do to
with a fault. It seems *most* tied to an application's message
exchange pattern (i.e., request/response will probably send a fault
back in the response, one way will probably propogate the fault to
the destination if possible, etc.). I can imagine that default fault
handling behaviours might be defined for each, and a module can be
built that will explicitly tell processors what do do with faults in
the exception cases.



On Sun, Apr 22, 2001 at 07:11:57PM -0700, Henrik Frystyk Nielsen wrote:
> 
> The basic SOAP processing model described in [1] doesn't know about
> servers or clients but only "SOAP processors" which is the reason why
> SOAP in general walks a fine line when talking about *generating* a
> fault vs. *sending* a fault. The latter is only mentioned in the HTTP
> binding and the RPC convention as these two talk about "requests" and
> "responses". That is, SOAP distinguishes between generating a fault
and
> sending a fault message somewhere.
> 
> Within the context of a request/response model, I think the right
thing
> for an HTTP client that cannot accept/obey the SOAP message semantics
is
> to fault the processing or to suggest that the message is saved for
> later processing by a more savvy processor. The latter is similar to
> what clients do when receiving a response with an unknown media type.
> 
> It is important that a SOAP processor doesn't break the processing
model
> and merely ignores the SOAP rules just because it may not be in a
> position where it can notify the sender about the fault.
> 
> Henrik
> 
> [1] http://www.w3.org/TR/SOAP/#_Toc478383491
> 
> Doug Davis wrote:
> >
> >I see 3 choices:
> >  1 - ignore it
> >  2 - fault back to the server
> >  3 - fault back to the client
> >
> >While 2 is probably what "should" happen, I doubt many
> >will be able to support this.  1 seems most likely, but
> >scares me.  3 seems like a nice middle of the road solution.
> >8-)
> >
> >Paul Kulchenko wrote:
> >
> >Since it's possible to return Header from server to client 
> >also, what should client do if this header has mustUnderstand 
> >attribute or wrong actor?

-- 
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA USA)

Received on Friday, 27 April 2001 11:51:52 UTC