W3C home > Mailing lists > Public > www-ws-desc@w3.org > June 2004

RE: Issue 130: Asynch request/response HTTP binding needed

From: David Orchard <dorchard@bea.com>
Date: Thu, 24 Jun 2004 03:54:25 -0700
Message-ID: <32D5845A745BFB429CBDBADA57CD41AF087AACA6@ussjex01.amer.bea.com>
To: "Jonathan Marsh" <jmarsh@microsoft.com>, "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>, "Tom Jordahl" <tomj@macromedia.com>, "Web Services Description" <www-ws-desc@w3.org>

Jonathan, I don't quite know why we can't bind the interface operation to the existing SOAP Req-resp.  Is that because the SOAP MEP selection in the default binding rules?

My thinking is that in a request response scenario, the operation is request response.  How this is bound to the wire, say as a callback, is part of the binding and not part of the operation.  Thus it belongs in the binding.

I would have thought that we could say the that the WSDL bindings allow us to bind message references either directly to the matching protocol operation references, or bind message references to protocol operation references that the binding author chooses.  

I think I was suggesting that the binding be configurable in mapping the abstract message references to protocol message references, rather than new MEPs or even bindings.  

This is different (and imho somewhat simpler) than the WS-MD callback mep.  WS-MD provides a composite callback MEP that consists of 2 meps (either 2 * in or 2 * in/out) combined into the callback.  I think that model is also useful, but the simplest possible thing is to treat in/out as 2 different messages and bind them accordingly.  This makes the association between the request and the response explicit (as they are in the operation) without requiring the WS-MD extension or the BPEL servicelink extension.

Cheers,
Dave

> -----Original Message-----
> From: Jonathan Marsh [mailto:jmarsh@microsoft.com]
> Sent: Wednesday, June 23, 2004 12:00 PM
> To: Sanjiva Weerawarana; Tom Jordahl; David Orchard; Web Services
> Description
> Subject: RE: Issue 130: Asynch request/response HTTP binding needed
> 
> 
> Let me make sure I understand your +1, and Tom's.  Do you 
> agree that we
> should add an async pattern, though note that it requires an extension
> to provide addressing information, or that since we can't provide such
> an addressing mechanism we should not do the pattern at all?
> 
> A further question on how this would impact the spec: As I 
> understand it
> the In-Out pattern has nothing that precludes async.  I don't 
> think our
> SOAP/HTTP binding itself prohibits this either.  So are we 
> talking about
> a new SOAP MEP, a peer of the SOAP Request-Response Message Exchange
> Pattern [1] and it's binding to HTTP [2]?  If so that doesn't 
> seem like
> a trivial task, nor one that could or should not be defined 
> outside the
> 3-part WSDL spec.
> 
> [1]
> http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#singlereqrespmep
> [2] http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#soapinhttp
> 
> > -----Original Message-----
> > From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]
> On
> > Behalf Of Sanjiva Weerawarana
> > Sent: Wednesday, June 23, 2004 8:53 AM
> > To: Tom Jordahl; 'David Orchard'; 'Web Services Description'
> > Subject: Re: Issue 130: Asynch request/response HTTP binding needed
> > 
> > 
> > +1 .. with sadness, but not for the lack of extra work.
> > 
> > Sanjiva.
> > 
> > ----- Original Message -----
> > From: "Tom Jordahl" <tomj@macromedia.com>
> > To: "'David Orchard'" <dorchard@bea.com>; "'Web Services 
> Description'"
> > <www-ws-desc@w3.org>
> > Sent: Wednesday, June 23, 2004 9:26 PM
> > Subject: RE: Issue 130: Asynch request/response HTTP binding needed
> > 
> > 
> > >
> > >
> > > I think this ties in with my old quest to get the output and
> > output/input
> > > MEPs removed from the spec OR specified in a way that we can have
> > > interoperable implementations.
> > >
> > > Supporting Async request/response requires the first service (or
> > operation)
> > > to receive the address on where to send the response.  We 
> can either
> > specify
> > > this as a part of WSDL 2.0 and everyone will implement it the same
> way
> > (and
> > > interoperate).  Or we can say nothing, and if you want to 
> do it, you
> > will
> > > have to implement something (WS-Addressing?) that not everyone may
> have.
> > >
> > > It makes me sad to say that at this point, saying nothing seems to
> be
> > the
> > > way to go.
> > >
> > > --
> > > Tom Jordahl
> > > Macromedia Server Development
> > >
> > > -----Original Message-----
> > > From: www-ws-desc-request@w3.org 
> [mailto:www-ws-desc-request@w3.org]
> On
> > > Behalf Of David Orchard
> > > Sent: Tuesday, June 22, 2004 1:33 PM
> > > To: Web Services Description
> > > Subject: RE: Issue 130: Asynch request/response HTTP 
> binding needed
> > >
> > >
> > > Without tracking down the reference, I think that I posted a
> response
> > that
> > > said something like I don't think that any asynch binding requires
> the
> > > engagement of an addressing/delivery mechanism.  I'm 
> reminded of our
> > > "operation name" discussions on this.  If we don't require the
> > description
> > > of the operation name uniqueness mechanism in the WSDL, 
> then I don't
> > think
> > > that we need to spec the callback mechanism is WSDL.  Certainly
> > something
> > > will have to be there, but that can be done in some other means.
> Simply
> > > that there is an expectation of one is sufficient.  If a service
> > provider
> > > does not describe their callback mechanism in some out-of-band,
> > extension,
> > > or f&p form, then it will be a pretty useless service.  
> Same way if
> a
> > > service provider can't distinguish between operations on it's end
> it's
> > > fairly useless.
> > >
> > > Caveat Servico Providemptor?
> > >
> > > Dave
> > >
> > > > -----Original Message-----
> > > > From: www-ws-desc-request@w3.org
> [mailto:www-ws-desc-request@w3.org]On
> > > > Behalf Of Jonathan Marsh
> > > > Sent: Tuesday, June 22, 2004 8:09 AM
> > > > To: Web Services Description
> > > > Subject: Issue 130: Asynch request/response HTTP binding needed
> > > >
> > > >
> > > >
> > > > [Reviving this thread for the telcon this week.]
> > > >
> > > > Sanjiva's mail below lays out the proposal on the table, and
> > > > the primary
> > > > issue with it - that it requires the use of an addressing
> mechanism,
> > > > presumably an extension engaged in the WSDL and marked required.
> Have
> > > > we learned anything new since January?
> > > >
> > > > > -----Original Message-----
> > > > > From: www-ws-desc-request@w3.org
> [mailto:www-ws-desc-request@w3.org]
> > > > On
> > > > > Behalf Of Sanjiva Weerawarana
> > > > > Sent: Friday, January 30, 2004 4:46 PM
> > > > > To: Martin Gudgin; Philippe Le Hegaret; David Orchard
> > > > > Cc: Web Services Description
> > > > > Subject: Re: Asynch request/response HTTP binding needed
> > > > >
> > > > >
> > > > > "Martin Gudgin" <mgudgin@microsoft.com> writes:
> > > > > > PAOS is slightly different. It has two MEPs, the one I
> > > > think you are
> > > > > > thinking of works as follows:
> > > > > >
> > > > > > Given nodes A and B:
> > > > > >
> > > > > > 1. node A makes an HTTP GET to node B.
> > > > > > 2. Node B sends a SOAP Request as the HTTP response.
> > > > > > 3. Node A responds with a SOAP response in an HTTP POST to
> Node B.
> > > > > > 4. Node B responds with some HTTP response ( typically a
> > > > web page )
> > > > > >
> > > > > > Gudge
> > > > >
> > > > > I understood what DaveO wanted as:
> > > > >
> > > > > 1. node A makes an HTTP POST to node B with a SOAP Request and
> > > > >    information on where to POST the HTTP response to
> > > > > 2. node B responds with something like 201 OK
> > > > > 3. later on, node B makes an HTTP POST to node A with a
> > > > SOAP Response
> > > > > 4. node A responds with something like 201 OK
> > > > >
> > > > > DaveO??
> > > > >
> > > > > I like this a lot but unfortunately one needs WS-Addressing or
> > > > something
> > > > > similar to send the "information on where to POST the HTTP
> response
> > > > to".
> > > > >
> > > > > Sanjiva.
> > > > >
> > > >
> > > >
> 
> 
Received on Thursday, 24 June 2004 06:54:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:31 GMT