Re: Issue: Synchronous vs. Asynch.

Greg,

Async. mechanism is ideal for long lived process interactions. 
What about, if we want to retrieve data values generated by
the process instance or query on the status of the
process instance, do we need to subscribe
to this request and wait for the data to come? 
SWAP also need to support synchronous mechanism
as well to address these short lived interactions.
  
Any comments?

Surendra


On Wed, 14 Oct 1998, Gregory Alan Bolcer wrote:

> 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 01:44:39 UTC