Re: Issue: Synch/Asynch Web services

WSD had recently treated these as distinct patterns : In-Out (requires 
explicit correlation) vs. Request-Response (correlation is implicit, 
response is on the "same channel"). But it appears they have now 
collapsed them and have only "In-Out", which covers both cases. (I'd 
rather see these distinguished, since participants may need to know 
whether or not a message ID is required).

--Jon

Geoff Arnold wrote:
> 
> 
> On Tuesday, August 12, 2003, at 11:03 AM, Cutler, Roger (RogerCutler) 
> wrote:
> 
>>
>> Is the classic Request/Response always synchronous?  I thought that
>> there were two possibilities here:
>>
>> 1 - The one that's like a browser -- the requestor spins a clock until
>> the response gets back or gives up.  Two messages, one possible
>> ordering.  Synchronous.
>>
>> 2 - The one that's not like a browser -- the requestor sends off a
>> message with an ID, then goes about other business.  Some time, maybe a
>> long time later, the response comes back, the requestor looks at the ID,
>> correlates it with the request, and the transaction is done.  Same
>> number of messages, same ordering.  Asynchronous.
>>
>> I think we'd better agree about whether number 2 is synchronous or
>> asynchronous.  I think that it is asynchronous.
> 
> 
> You're talking about the implementation of the agent, not the
> properties of the MEP.
> 
> As to whether or not you need a transaction ID to allow for
> message correlation, that's strictly a function of the way you
> choose to implement a particular MEP over a particular transport.
> If you feel that you can rely upon a transport connection context
> for correlation, you can omit the ID. Architecturally this is
> bad future-proofing, however. Case in point: NFS. We originally
> implemented NFS over UDP with fixed ports, so we had to include
> XIDs (transaction IDs) in the RPC headers for request-response
> correlation. We didn't eliminate them when we added TCP support,
> which was good, because we were able to multiplex NFS transactions
> over a single TCP connection "for free".
> 
> I'd hate to find that our web service architecture was
> unable to exploit new transport providers because we
> had baked in a dependence on the session-level properties of a
> particular transport.
> 
> Finally "Some time, maybe a long time later" is not a defining
> characteristic of asynchrony. Or it shouldn't be. In fact,
> the most interesting and challenging issues arise when asynchronous
> patterns allow inadvertent race conditions. In many design
> choice, synchronous interactions are required in order to
> avoid races.
> 
> 
>

Received on Tuesday, 12 August 2003 12:16:15 UTC