RE: Leaky abstractions, protocols and all that.

> -----Original Message-----
> From: Marc.Hadley@Sun.COM [mailto:Marc.Hadley@Sun.COM]
> Sent: Monday, April 11, 2005 9:01 AM
> To: David Orchard
> Cc: David Hull; public-ws-async-tf@w3.org
> Subject: Re: Leaky abstractions, protocols and all that.
> 
> On Apr 8, 2005, at 6:27 PM, David Orchard wrote:
> >
> > I believe we are largely saying the same thing, which is good.  To use
> > your terminology, underlying protocols may or may not have a back
> > channel, and this presence or absence will affect the SOAP meps, WSDL
> > meps, and WS-A Fault configurations.
> 
> I'm not sure I agree that the presence or otherwise of a back channel
> affects the MEPs, it just affects the binding of those MEPs. E.g.
> request/response over SMTP is still request/response regardless of the
> lack of a connection oriented 'back channel'.

We seem to be moving apart.  I'm saying that an HTTP Connection has a back-channel that an application may want to make use of by selecting WSDL robust-in-only and a corresponding SOAP MEP instead of in-only for Fault reporting.  GregT did the same switch to talking about a connectionless protocol to prove that a back channel isn't present in all cases, which is not my point, though true.  But I guess I'm missing something, or maybe people just want to ignore HTTP.

> 
> > 2. I think you are agreeing with me.  I use "the soap mep leaks into
> > the wsdl mep" and you say "take into account".  To me, the "taking
> > into account" is the leakage.  So everywhere I say "leak" you
> > translate to "take into account" we should be good.
> >
> Clearly the underlying protocol binding needs to be able to support the
> WSDL MEP (either directly or as an aggregate of several supported
> MEPs), beyond that I'm not sure I understand the fine distinctions
> being made.

I'll try again then.  There is a relationship between a SOAP MEP and a WSDL MEP where the SOAP MEP affects the WSDL MEP, etc.  For example, if the WSDL MEP is robust-in-only and the SOAP MEP is in-only, there will be no FAULTs reported to the application from the SOAP MEP.  If the WSDL MEP is in-only and the SOAP MEP is request-response, the SOAP response will get dev/nulled.  

Looking from the top-down, one will probably pick SOAP meps that have at least the fidelity of the WSDL MEPs if possible.  Looking bottom up, one will probably pick WSDL meps that have at least the fidelity of the SOAP meps if possible.

> 
> > 3. Here, I really can't tell whether we agree or not.  I roughly
> > proposed that FaultTo support SOAP Faults transmitted on a
> > back-channel AND a discrete address for any protocol.  You agree that
> > there is a visible difference, but I can't tell whether you want the
> > FaultTo to support this "two-step" SOAP Fault transmission model.
> >
> I'm not sure I fully understand the need for this 'two step' fault
> model. If its a SOAP fault then presumably it should go where the
> FaultTo says, if its a underlying protocol fault/error then it may go
> over an available back channel (but then its not a SOAP fault so we
> don't need to model it in the WS-Addr/SOAP layer.

Imagine if you will, a SOAP fault is generated as part of receiving a SOAP message while the HTTP channel is open.  There are 2 possibilities from a wire perspective: Send the fault over the HTTP Channel, or send it to a FaultTo address.  Note that perhaps the SOAP Fault is generated and the FaultTo can't even be parsed by the receiver.  

I'm proposing that FaultTo be extended with "AllowAnonymous" to permit the HTTP back channel to be used when it is available.  This is obviously binding dependent, but then so is "anonymous" anyways.  

Cheers,
Dave

Received on Monday, 11 April 2005 17:16:32 UTC