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

This is a good example of why it is important to define client side behavior
regarding mustUnderstand. This scenario can become really ugly. What if the
client is
operating in a reliable delivery mode and fails to recognize the ack, it
will
continue to send orders for "1000 cases of widgets" until a "valid"
confirmation is received.
So what's going to happen with those 1,000,000 cases of widgets if the
client
fails to properly recognize the acknowledgement?

It's important to define processing behavior for mustUnderstand on both the
client and server to avoid situations like those described above.


Dick Brooks
Group 8760
110 12th Street North
Birmingham, AL 35203
dick@8760.com
205-250-8053
Fax: 205-250-8057
http://www.8760.com/

InsideAgent - Empowering e-commerce solutions

> -----Original Message-----
> From: xml-dist-app-request@w3.org [mailto:xml-dist-app-request@w3.org]On
> Behalf Of Roger Wolter
> Sent: Friday, April 27, 2001 10:12 AM
> To: Mark Nottingham; Frystyk
> Cc: xml-dist-app@w3.org
> Subject: 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 12:27:00 UTC