- From: Glyn Normington <glyn_normington@uk.ibm.com>
- Date: Fri, 19 Oct 2001 14:12:48 +0100
- To: "Williams, Stuart" <skw@hplb.hpl.hp.com>
- Cc: xml-dist-app@w3.org
Stuart, That was a helpful reply - thank you! The mystery of QoS should start to unravel when features are further defined. I am trying to discern the relationship between SOAP, MEPs, features, and transport bindings. Would it be fair to say that a transport binding may implement SOAP with a particular set of MEPs and a particular set of features? If this is the case, I wonder if multi-hops scenarios with more than one transport binding involved effectively result in only the MEPs and features common to all of the involved transport bindings being implemented? Glyn "Williams, Stuart" To: Glyn Normington/UK/IBM@IBMGB <skw@hplb.hpl.hp. cc: xml-dist-app@w3.org com> Subject: RE: SOAP Binding Framework, HTTP Binding, MEP documents Sent by: xml-dist-app-requ est@w3.org 19/10/01 12:12 Please respond to "Williams, Stuart" Hi Glyn, > -----Original Message----- > From: Glyn Normington [mailto:glyn_normington@uk.ibm.com] > Sent: 16 October 2001 15:27 > To: xml-dist-app@w3.org > Subject: Re: SOAP Binding Framework, HTTP Binding, MEP documents > > > Some initial comments: > > 1. I cannot find a clear statement in these documents about whether or not > XMLP will define a common behaviour in respect of at-most-once delivery, > out-of-order delivery, and message loss. I guess there are two thing here... the 'contract' between SOAP and the things (applications) that use SOAP and the 'contract' between SOAP and the bindings/underlying protocols that SOAP uses. The TBTF work is focussed on the latter, although the two are clearly related. In terms of the way the TBTF framework is cast, the contract between SOAP and binding will be modular in that a binding will declare that it supports a particular set of transport meps and features. Delivery QoS is something that I would expect us to cast as a feature and the semantics of that feature with respect to its use in conjunction with different transport meps will need to be well defined. I know this too is not a clear answer to your question, but I hope it gets you some way to understanding the thinking that's going on. > 2. R604 says that the XMLP spec. must consider message paths > over multiple transport protocols. > Does the working group intend to consider transports which exhibit > re-delivery, out-of-order delivery, and message loss? I think so... the current HTTP binding SOAP 1.1 says nothing about management of the underlying HTTP connection so I would contend that we're already in a world that makes no guarantees about delivery order; equally it HTTP operations can fail, so we're in an environment that is lossy; multiple-delivery... not sure if there's a failure mode in HTTP that can do this eg. authentication failures and redirection may cause re-transmission of a SOAP message... what are the semantics with respect to the delivery of earlier copies... that's probably a stretch... I'd think that it should be as if they had not been sent. Some folks are considering SMTP and I have certainly expreienced the occasional mail-loop, message loss and re-sequencing of message. > 3. The HTTP binding describes a state transition in the > requesting SOAP node from 'waiting' to 'requesting' in > the case of a 3xx redirection response. Should the state transition > diagram in MEP be updated to reflect this? Well spotted... I was aware of this one, but didn't fix the diagram. Partially because the direct handling of 3xx in the description is a bit tentatative. > Glyn Normington Regards Stuart Williams
Received on Friday, 19 October 2001 09:15:01 UTC