W3C home > Mailing lists > Public > ietf-swap@w3.org > October 1998

RE: Issue: Synchronous vs. Asynch.

From: <kswenson@ms2.com>
Date: Thu, 15 Oct 1998 01:27:39 -0700
Message-ID: <C70BCBAA61B5D111BFDB00A0C9AB25620B7A0A@ms2.com>
To: gbolcer@ics.uci.edu, ietf-swap@w3.org
You raise an interesting point.

One of the big advnatages of web-style interaction is that there is a
point in time where the client and the server are connected, where the
request is sent, handled, and the response is received.  The duration of
this connection can be as long as you want, within reason and
practibility.  If the server is not available, the connection is
refused, and the there is no question about whether the operation was
handled or not.

It is my belief that in order to satisfy the need of the workflow user,
a workflow server in general needs to be able know the exact state of a
workflow instance at the time that a user accesses it, and needs to
leave the user knowning exactly what state it is in after the
interaction.  In my experience the time needed for a workflow server to
switch from one well defined state to another is very small.  It is
highly undesirable from the human perspective to take an action and not
know whether your action really "took".  This is a long-winded way to
say that a workflow engine always knows its (new) state at the time that
is returns the result of the request.

When you say that the "terminate" command is asynchronous, then what
that means is that there is an extra intemediate state between running
and terminated.  For example, the request to terminate command puts the
workflow (unambiguously) into the "waiting for termination" state, and
that some other event (possibly internal to the workflow engine) takes
it ultimately to the "terminated" state.  

As for clean-up, that might happen after termination, and might easily
be handled as a substate of the termination state (e.g.
termination.initial and termination.cleaned-up) 

In my experience I have not seen the need to have this extra state while
terminating a process instance.  It is worth finding out from people
whether they have a specific need for this intermediate state at this
time.  Without any evidence of a strong need, I would be inclined to
stick with the terminate, suspend, and such commands as being

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

> -----Original Message-----
> From: Gregory Alan Bolcer [mailto:gbolcer@gambetta.ics.uci.edu]
> Sent: Wednesday, October 14, 1998 9:29 AM
> To: ietf-swap@w3.org
> Subject: Issue: Synchronous vs. Asynch.
> This might be an issue to consider.
> Assume that you invoke a remote workflow
> process across the Internet.  You monitor
> the changes wither by subscribing to change
> events or polling using the SWAP monitoring
> methods.  You (the workflow at your end) decide
> that things have changed and you want to 
> stop or suspend the remote process (or even
> just change the values in some significant way).  Do
> you invoke the appropriate suspend commands
> and wait to receive the termination values or
> do you send the termination commands and subscribe for
> the terminations values?   The question is,
> should this take place synchronously or asynchronously?
> I would argue for the latter as it implies less intrusive control
> on a foreign system.   As a long running process
> will definitely have to do some cleanup that may well go beyond
> reasonable http and rpc timeouts.  
> The analogy is a regular computer operating system.
> When you are the user kill a process, from your standpoint
> it looks like you are actually doing the termination,
> but what is happening is you are 'requesting' that the
> operating system terminte the process, which it
> evaluates, schedules, completes, and cleans up.
> Any comments?
> Greg
Received on Thursday, 15 October 1998 04:26:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:58:59 UTC