RE: Issue: Synchronous vs. Asynch.

>Excellent analogy.  The telephone conversation with the customer service
rep
>is synchronous, and she acknowledged your request and in a sense guaranteed
>the response, but the actual change of state is asynchronous and you only
>get confirmation of the transaction in the mail when your statement comes.

Exactly the kind of thing I was thinking of when I first thought of Event
Notification Protocol.  The events happen asynchronously (the "actual change
of state") but the notification request/response is performed synchronously.

As far as resource unavailability goes, this should be handled by something
like TCP/IP's exponential backoff algorithm (although which algorithm should
be used I am not expert enough to say at this moment), rather than
introducing asynchronous requests and notifications into the protocol.  If
we reduce the both the request to change state and the notification of state
change to synchronous request/responses, I think we'll gain a significant
reduction in the complexity of the workflow protocol.  I have a hunch that
the asynchronicities (new word?) of workflow probably demand that each
workflow process will handle the amount of asynchronicity in its process
differently (or at least differently enough that these should not be
enshrined in the protocol).

If SWAP handles both process state changes and process state change
notifications, that should (IMHO) provide the tools needed for workflow over
TCP/IP.  What each workflow process should do when it cannot either initiate
a state change or when it receives no notification of state changes probably
depends on the workflow process (a travel&living expenditure approval is
different than control of a steel mill).

Just my $0.02US...
==========================================================
Mark Leighton Fisher          Thomson Consumer Electronics
fisherm@indy.tce.com          Indianapolis, IN
"Browser Torture Specialist, First Class"

Received on Thursday, 15 October 1998 11:40:51 UTC