RE: Issue: Synch/Asynch Web services

Uh, that's not the way I would have put it, but I think that it is
reasonably accurate.  Might depend, however, where it leads.  It's not
exactly clear to me what all the implications are of approaching the
issue in this way, but I think I see the logic of doing so.  It is
PARTICULARLY not clear to me that the groups you indicate are the same
as synchronous and asysnchronous (although I suppose they might be), but
you may be correct (again, depending on where this leads) that this
grouping captures the issues of practical importance.

The more I ponder your statements (other than phrases like "the world",
which are a bit vague) the better I like them and the more hope I have
that the approach might be useful.

-----Original Message-----
From: Martin Chapman [mailto:martin.chapman@oracle.com] 
Sent: Wednesday, August 13, 2003 12:36 PM
To: Cutler, Roger (RogerCutler); 'Doug Bunting'
Cc: 'Geoff Arnold'; www-ws-arch@w3.org
Subject: RE: Issue: Synch/Asynch Web services


Roger,
If I understand you correctly, you would like to divide the world into
two important groups (ignoring what we call them): One where there is an
assumption that the "infrastructure" will correlate messages, and the
other where there is no 
assumption about the infratsructure and thus the application level  has
to deal with it.

Is this a correct interpretaion?
 
Comments/ questions to follow depending on answer.

Martin.

> -----Original Message-----
> From: www-ws-arch-request@w3.org
> [mailto:www-ws-arch-request@w3.org] On Behalf Of Cutler, 
> Roger (RogerCutler)
> Sent: Tuesday, August 12, 2003 2:47 PM
> To: Doug Bunting
> Cc: Geoff Arnold; www-ws-arch@w3.org
> Subject: RE: Issue: Synch/Asynch Web services
> 
> 
> 
> I don't know the answers to the questions you ask.
> 
> I do know that there are some end cases of Web services that
> I KNOW are inherently for synchronous operations and others 
> that are inherently for asynchronous operations.  I know that 
> because in the end cases the other side just won't work.  Or 
> at least I don't know how to make them work and I really 
> don't think it's possible.
> 
> Suppose you have a Web services that accepts as input a
> minimal SOAP message (minimal in the header), and as data 
> just, "Add", "2", and "3"
> -- with the corresponding WSDL definition somewhere that says 
> that these are numbers and so on.  This WS returns a minimal 
> SOAP message that has one item of data -- "5".  Or you set it 
> up however the REST people want to do it. I don't think that 
> this WS can be used asynchronously because unless you hold 
> onto the connection you have no idea what the answer is in 
> response to.  (Unless there is something about SOAP as used 
> in WS's that I seriously don't know -- which is, of course, 
> possible). If you send the WS two add requests and they come 
> back in the opposite order, how do you know?
> 
> On the other hand, in realistic terms (and I do think that
> realism has some place in this discussion), if you have a WS 
> that will take an unpredictable amount of time to return an 
> answer that ranges, typically, from a day to a month (as 
> might actually be the case if the WS puts into play behind 
> the scenes some sort of workflow involving people), that WS, 
> in reasonable terms, cannot be used synchronously.  How is a 
> potential requestor supposed to discover that?  "Suck and 
> see"?  It seems that is the current state of the art, at 
> least as far as I can tell.
> 
> I have, for my own amusement, made up a definition of
> synchronous that I think is conceptually clean (although 
> probably inappropriate for general use by the WG).  Under MY 
> definition the second case would certainly not admit 
> synchronous operation, and there is absolutely nothing wrong 
> with the way the distinction is made.  (I am aware that there 
> is sort of a time/message logic duality in the theoretical 
> understanding of distributed systems, but if you look into 
> the foundations of that duality I think you find -- a 
> duality, not one or the other.  Time is not an inadmisable 
> concept in distributed systems.)  I believe that under the 
> definition being proposed in the straw poll, which I think is 
> not exactly conceptually clean but kind of hits most of the 
> relevant high points, I think that the same could probably be said. 
> 
> Neither of the endpoint examples above has ANYTHING
> WHATSOEVER to do with the binding, underlying protocols or 
> implementation details.  They are features that can describe 
> the Web service itself.  Whether current WSDL is capable of 
> doing so is another matter, and possibly an interesting question.
> 
> -----Original Message-----
> From: Doug Bunting [mailto:Doug.Bunting@sun.com]
> Sent: Tuesday, August 12, 2003 3:43 PM
> To: Cutler, Roger (RogerCutler)
> Cc: Geoff Arnold; www-ws-arch@w3.org
> Subject: Re: Issue: Synch/Asynch Web services
> 
> 
> 
> Thanks Roger,
> 
> The proposed definition is not incorrect but answers a different
> question than you are asking or that you believe the "world 
> at large" is
> 
> asking.  It states the classic request / response interaction is a
> synchronous MEP but says nothing about agents implementing 
> such an MEP. 
>   In this particular case, the binding to a particular protocol could 
> result in either synchronous or asynchronous agents.  As Geoff said 
> earlier, this is a property of the binding and not just of the MEP in 
> question.  (Not sure we would label the binding as synchronous or 
> asynchronous...)
> 
> It remains important to note that synchronous MEPs are possible over
> protocols without direct correlation features.  Are you 
> really trying to
> 
> identify those service implementations that *require* correlation
> features independent of the underlying protocol in use, the 
> instances of
> 
> synchronous MEPs bound using asynchronous agents?
> 
> thanx again,
> 	doug
> 
> On 12-Aug-03 11:44, Cutler, Roger (RogerCutler) wrote:
> > It is really important that WSA nails down definitions for
> >     "synchronous" and "asynchronous", because this will
> >     allow me to have confidence that Web services will
> support, in an
> > interoperable way, synchronous and asynchronous implementations
> > (particulartly the latter, since this is where the problems 
> are most
> > likely to arise, is the most different from the historical starting
> > point of Web services, and is the most typical of core business
> > processes) in applying Web services to
> >     business applications. If they don't do so, I won't be 
> able to use
> 
> > them at all for core business processes -
> >     or I'll have to trust to luck that they will work or be 
> > intereperable instead.  If I cared a lot about late
> binding, I would
> > also not be able to implement late bound business processes
> that are
> > sensitive to whether the WS will support synchronous or asynchronous
> > operations.   Nailing down the definitions will not, in 
> itself, enable
> > these desirable outcomes, but is a necessary pre-condition for
> > addressing the real issues, which I tried to sketch in section 4 of 
> > http://lists.w3.org/Archives/Public/www-ws-arch/2003Aug/0001.html.
> > 
> > To respond to another implied question, it really doesn't
> matter if an
> 
> > approach is formally verifiable if it is incorrect.  It looks to me 
> > like this one is incorrect -- it says that an MEP that is agreed by
> > (virtually) all to be asynchronous is synchronous.  Since
> the MEP in
> > question is very commonly used in practical situations, I'd
> consider
> > that to be a considerable drawback.
> > 
> > 
> > -----Original Message-----
> > From: Geoff Arnold [mailto:Geoff.Arnold@Sun.COM]
> > Sent: Tuesday, August 12, 2003 12:52 PM
> > To: Cutler, Roger (RogerCutler)
> > Cc: www-ws-arch@w3.org
> > Subject: Re: Issue: Synch/Asynch Web services
> > 
> > 
> > 
> >>Also -- I do not agree that sync/async is only an implementation
> >>issue. I think it is pretty clear that certain Web 
> services, by their
> >>nature, can be used sync but not async -- or async but not
> sync -- or
> >>in both ways.  That means to me that it is not an implementation
> >>issue.
> > 
> > 
> > Can we replace the notion of being "used" sync or async
> with something
> 
> > a little more precise? What would be observably different? And "in 
> > both ways"...?!
> > 
> > 
> >>It also happens to be an issue that is really important to
> people who
> >>are interested in business applications of Web services.  These
> >>persistent attempts to declare the concepts either to be 
> meaningless
> >>or out of scope are very discouraging.
> >>
> > 
> > Hmmmmm........ I'm surprised that you would characterize a formally 
> > verifiable approach grounded in message exchange patterns as either 
> > meaningless or out of scope. But you just said something much more 
> > interesting to me: "It also happens to be an issue that is really 
> > important to people who are interested in business
> applications of Web
> 
> > services." Presumably this means that you (or others) are able to 
> > complete the following paragraph:
> >     It is really important that WSA nails down definitions for
> >     "synchronous" and "asynchronous", because this will
> >     allow me to ______________ in applying Web services to
> >     business applications. If they don't do so, I won't be able to -
> >     or I'll have to ___________ instead.
> > 
> > Curious,
> > 
> > Geoff
> > 
> > 
> > 
> > 
> 
> 
> 
> 
>

Received on Wednesday, 13 August 2003 14:00:21 UTC