RE: Proposal for Async Extensions

 

> -----Original Message-----
> From: public-ws-async-tf-request@w3.org 
> [mailto:public-ws-async-tf-request@w3.org] On Behalf Of Anish 
> Karmarkar
> Sent: Wednesday, Jun 15, 2005 4:04 PM
> To: Marc Hadley
> Cc: David Hull; public-ws-async-tf@w3.org
> Subject: Re: Proposal for Async Extensions
> 
> 
> Marc Hadley wrote:
> > On Jun 15, 2005, at 3:36 PM, David Hull wrote:
> > 
> >>>
> >>>> Bindings MAY provide optimized means of transferring particular
> >>>> forms of messages with this [action].
> >>>>
> >>>
> >>>
> >>> E.g. by not sending a SOAP message at all unless it:
> >>>
> >>>
> >>>> This message MAY also have any other content, as appropriate.
> >>>>
> >>>
> >>>
> >>> How would such 'other content' occur given that there's no
> >>> 'application level response or fault' ?
> >>>
> >>
> >> This would (most likely) just include other headers, 
> notably [message
> >> id] if correlation is not natively provided, and possibly headers
> >> required by security etc.  See
> >> http://lists.w3.org/Archives/Public/public-ws-async-tf/2005Jun/ 
> >> 0005.html.
> >> There's at least a prima facie case that acks may still 
> need to carry
> >> non-trivial header information, and I would not want to rule that
> >> possibility out.  Thus the ack is defined as a full-fledged SOAP
> >> message, with an optimized representation if people like 
> that sort  of 
> >> thing.
> >>
> >>
> >>>
> >>> I must confess I really don't like these 'magic' SOAP 
> messages that
> >>> don't really exist. What's the point of this conceit.
> >>>
> >>
> >> It appears by saying that an HTTP exchange (and an 
> exchange on similar
> >> bindings) is always a SOAP request-response MEP, a great 
> deal of the
> >> anguish over how to bind to SOAP MEPs simply goes away.  
> If the return
> >> message were always just an empty marker, I would be 
> indifferent.  But
> >> if we get to use the SOAP processing model to handle problems like
> >> reliability and security that will most likely come up 
> anyway and  we've
> >> already solved using SOAP, I think the case becomes considerably  
> >> stronger.
> >>
> > But then we get into the problem of getting two responses 
> in a simple  
> > request-response MEP and you have to answer questions like 
> which is  the 
> > 'real' response, how can you tell, are there any explicit timing  
> > concerns etc. It sounds simple on the surface but raises a lot of  
> > questions, at least in my mind.
> > 
> 
> +1
> 
> If two SOAP messages are being sent back, it is no longer a simple 
> request-response.

I agree. However, I don't think that David was advocating two SOAP
messages being sent back. It seems to me that he is advocating an HTTP
ack (no SOAP response) for the initial message, not two  SOAP responses.
This is what we have been discussing all along. 

David, could you clarify? 
 
> 
> -Anish
> --
> 

--umit

> ...
> <snip/>
> 
>

Received on Wednesday, 15 June 2005 23:31:07 UTC