Re: Issue: Synch/Asynch Web services

Roger:
   I know that this has been an issue that is v. close to your heart for 
a while ;-)

   However, I think it might help clarify things if you could lay out 
some of your thinking vis the *requirements* that you are trying to 
satisfy here.

   From a strictly technical POV, the distinction between synch and 
asynch has less merit than may at first appear. The reasons are (a) 
that either style may be simulated in the other and that (b) it appears 
to be related to a somewhat low-level aspect of the entire stack. 
Various people have pointed this out: synchronous at one level 'shows 
up' as asynchronous at another and vice-versa.

   What I would like to hear is what the business drivers are, from your 
perspective, that seems to make this a critical issue.

Frank

On Wednesday, August 13, 2003, at 08:10  PM, Cutler, Roger 
(RogerCutler) wrote:

>
> Indulge me, if you will, for a moment by pretending that the words I 
> use
> have meaning.
>
> The issue of asynchronous or synchronous operation is not, by any
> stretch of the imagination, an arbitrary choice by the application
> programmer.  It refers to functions of critical importance to real 
> users
> of Web services that some WS's may be capable of and others not -- by
> their nature.  If the WS-Desc WG is incapable of describing this aspect
> of what a Web service is capable of doing -- shame on them.  If the WSA
> WG is incapable of creating a framework in which this critical
> distinction can be understood -- uh ... words fail me.  I guess I'll
> just advise my company that Web services should be thought of only in
> terms of RPC operations for the foreseeable future.
>
> -----Original Message-----
> From: Cutler, Roger (RogerCutler)
> Sent: Wednesday, August 13, 2003 9:21 PM
> To: Geoff Arnold; Martin Chapman
> Cc: www-ws-arch@w3.org
> Subject: RE: Issue: Synch/Asynch Web services
>
>
>
> I think that you can take it to the bank that I would not "go along 
> with
> this".
>
> I suppose I can't do anything about it if you folks insist on living in
> a Mad Hatter world where the clocks have no hands and terms that the
> rest of the world understands somehow have no meaning.  However, if you
> fail to supply a framework for addressing issues critical to business 
> --
> and late bound -- usage cases of Web services I can and will pursue the
> issue until the last trump.
>
> -----Original Message-----
> From: Geoff Arnold [mailto:Geoff.Arnold@sun.com]
> Sent: Wednesday, August 13, 2003 4:48 PM
> To: Martin Chapman
> Cc: www-ws-arch@w3.org
> Subject: Re: Issue: Synch/Asynch Web services
>
>
>
> +1
>
> I personally think that we could probably punt on the use
> of "synchronous" and "asynchronous" at the MEP level,
> and simply describe the various MEPs in terms of legal
> state transitions. Important MEP issues such as mapping to transport
> messaging and observable conformance don't really depend on properties
> such as sync/async as much as they do on the kind of FSM analysis I
> described in my earlier email.
>
> This would allow us to confine the terms sync and async to a discussion
> of various application-level use cases and patterns. However, this 
> might
> be viewed as "ruling sync/async out of scope", since any consideration
> of application use cases is necessarily illustrative but non-normative.
> For this reason I'm not sure that everybody would go along with this.
>
> Whatever we *do* decide to do, we must be sure to preserve the
> distinction that Martin makes and not conflate different senses of
> sync/async.
>
> Geoff
>
> On Wednesday, August 13, 2003, at 02:35 PM, Martin Chapman wrote:
>
>> So the problem I see is in the defintion of infrastructure. To a real
>> end user anything beyond the IDE could be considered infrastructure
>> To a middelware vendor, the o/s and comms protocols are
> infrastructure.
>>
>> Each of these layers may provide sync and async models to its upper
>> level, and may in turn use sync
>> and async capabilities of the layer below (in a mix and macth
>> approach). So
>> the problem is at what level are we trying to
>> divide the world into the two groups. I believe this is the cruz of
>> this
>> perma thread.
>>
>> SOAP and WSDL, and by inference the WSA, only mandate what happens on
>> the wire, which is why Geoff has been sticking to the mep layer.
>> But I do think the context should at least be discussed in the WSA
>> document
>> and we should be able to reconcile the different views.
>>
>> Martin.
>>
>>
>>> -----Original Message-----
>>> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]
>>> On Behalf Of Cutler, Roger (RogerCutler)
>>> Sent: Wednesday, August 13, 2003 10:58 AM
>>> To: Martin Chapman; Doug Bunting
>>> Cc: Geoff Arnold; www-ws-arch@w3.org
>>> Subject: 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 Thursday, 14 August 2003 12:08:20 UTC