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 Tuesday, 12 August 2003 17:55:01 UTC