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 Wednesday, 13 August 2003 17:46:55 UTC