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

My vote was to NOT add anything to WSDL 2.0.


--
Tom Jordahl
Macromedia Server Development

-----Original Message-----
From: Jonathan Marsh [mailto:jmarsh@microsoft.com] 
Sent: Wednesday, June 23, 2004 3: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 Wednesday, 23 June 2004 16:21:21 UTC