Re: mustUnderstand on client side

This sounds like a higher-level design issue for the application (or
the modules that it chooses to use ;). There are a number of
conditions that may prevent the client from receiving or
understanding the server's response, without the server knowing this.
A well-designed ordering system might have an order rollback
mechanism, and/or an order verification mechanism.



On Fri, Apr 27, 2001 at 08:12:05AM -0700, Roger Wolter wrote:
> 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)
> 

-- 
Mark Nottingham
http://www.mnot.net/

Received on Friday, 27 April 2001 20:09:45 UTC