RE: Issue: Synchronous vs. Asynch.

> -----Original Message-----
> From: Michael Oliver [mailto:ollie@opentext.com]
> 
> Anything is possible, but I would ask in what case is 
> Synchronous needed?  A
> workflow between systems usually some business process, like 
> an approval, an
> application of data to some business process that returns 
> results when it
> completes.
> 
> To me Synchronous usually relates to real time control, a 
> continuous data
> stream or a tightly coupled command and result, not a 
> business workflow
> process that is a request and a response.

We do need to be clear about what we mean by sync and async:
Remember, a workflow is a mechanism to provide asynchronicity.
You ask for something now, and someone does it at a different 
time later.  Thus, naturally, the business process is async.

The question then is whether a single person's interaction with
that workflow engine needs also to be asynchronous.  One of the 
things I really like about accessing my bank account from the 
web is that I get the amount in the account at this instance.
When I authorize a transaction, and it returns immediately that 
it has been successful, then I know that it happened.  There is 
a big difference between this and receiving the same information
via email even just a few minutes later.

Consider a simple workflow with step1, step2, step3 & step4.  When I 
go to interact with this workflow to tell it to go from step2 to step3

* is there any reason that the workflow server can not tell me 
  immediately whether I succeeded or not?  
* Is there any reason that the server will not know that it is 
  (or is not) in step 2?  
* Is there any reason that it can not tell me right away that my 
  request succeeded, and that it is now in Step 3?
* If it is not in step 2, is there any reason that it can not 
  tell me right away that my request is not possible. 
 
In my experience, workflow systems can determine their state and
transition to another state in a fraction of a second, and I can
not imagine any reason that existing workflow systems would not be 
able to do so.

There is, however, confusion between the workflow engine changing
state, and other asynchronous automated activities between the 
people interactions.  In otherwords, the SWAP interaction from 
me may put it from step 2 to step 3, but then there is an automated
activity that takes 3 hours to take it from step 3 to step 4.
Taking three hours in this case does not necessitate that the
SWAP support asynchronous interaction.  

> If you can make a case for the need for Synchronous 
> communications between
> workflow engines then please do.

The need is that by restricting the client server interaction to 
synchronous, we end up with a much simpler protocol both from use
as well as from implementation.  This is an important benefit of
SWAP.

We could make it user selectable, but then the protocol could be
selected by the user too.  Most of the requests for asynchronous 
client/server interactions can be modeled as a more elaborate 
internal state machine, but we should be sure that there is a
justifiable need.

-Keith

----------------------------------------------------------------
Keith D. Swenson, kswenson@ms2.com, MS2 Inc.
2440 W. El Camino Real, Mountain View, CA, 94040
tel: +1 650 623-2329,  fax: +1 650 967-7394

Received on Thursday, 15 October 1998 05:09:57 UTC