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

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

From: Jeff Mischkinsky <jeff.mischkinsky@oracle.com>
Date: Thu, 24 Jun 2004 21:29:44 -0700
Message-Id: <4.3.2.7.2.20040624211649.07fd9ce0@rgmamerimap.oraclecorp.com>
To: "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>, "Tom Jordahl" <tomj@macromedia.com>, "'Jonathan Marsh'" <jmarsh@microsoft.com>, "'Web Services Description'" <www-ws-desc@w3.org>

At 06:30 PM 6/23/2004, Sanjiva Weerawarana wrote:

>Same here; there is nothing called an "asynch" pattern IMO.

I tend to agree and don't believe we should even be defining one. I've seen 
this discussion, what about billion times or so, in every forum which sets 
out discuss distributed application processing.

In my book, the discussion never seems to end because it winds up 
conflating different concepts/issues. Asynch is a programming language 
issue. Has to do with whether your thread blocks or not when the action 
that initiates the pattern is made, usually the initial request. A separate 
issue is whether a response/ack comes back on the same "channel" or not, to 
the same thread, process, node, whatever. A separate issue is whether the 
receiver and the sender have to be "connected".

Pick every combination and someone has implemented it. And I suspect all 
the different combinations have been called asynch.

One has to have a very carefully defined layered model, with well defined 
abstraction layers, and not confuse the layers in order to sort this out.

I suspect DaveO is wanting to support disconnected sender/receiver and 
allow for the response to a request to come back somewhere else. Even then 
you have to decide if the request is delivered via callback (which some 
call events), or whether some entity is responsible for polling to get it. 
Blocking is somewhat independent.

cheers,
   jeff



>As
>you Jonathan noted nothing precludes one from doing In-Out with
>asynch stuff .. in fact the use of WS-Addressing ReplyTo, for
>example, already allows that.
>
>Sanjiva.
>
>----- Original Message -----
>From: "Tom Jordahl" <tomj@macromedia.com>
>To: "'Jonathan Marsh'" <jmarsh@microsoft.com>; "'Web Services Description'"
><www-ws-desc@w3.org>
>Sent: Thursday, June 24, 2004 2:20 AM
>Subject: 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.
> > > > > >
> > > > >
> > > > >

Jeff Mischkinsky                      jeff.mischkinsky@oracle.com
Consulting Member Technical Staff     +1(650)506-1975
Director, Web Services Standards      500 Oracle Parkway M/S 4OP9
Oracle Corporation                    Redwood Shores, CA 94065
Received on Friday, 25 June 2004 01:07:11 GMT

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