Re: Issue: Synch/Asynch Web services

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 11:58:27 UTC