RE: Issue: Synchronous vs. Asynch.

Could you expand on the details of this example a little?
Are you saying that you have a well-defined resting state
of the workflow engine that for some period of time that it
is in that state can not be suspended?  Or are you saying that
there are some transient operations that must not be interupted?

----------------------------------------------------------------
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: Karsten Illing [mailto:k.illing@gis.ibfs.de]
> Sent: Thursday, October 15, 1998 1:05 AM
> To: gbolcer@ics.uci.edu; ietf-swap@w3.org
> Subject: Re: Issue: Synchronous vs. Asynch.
> 
> 
> I agree with Christoph Bussler that it should be possible for 
> the caller to
> chosse between a synchronous or asyncronous suspend command. 
> The reason why
> I support the customizable way is my experience with our own 
> workflow. 
> There are some special points in the process where you will get data 
> inconsitency, if you have asyncronous suspend commands. It is 
> not possible
> to avoid these points for synchronous suspension.
> 
> Karsten
> 
> --------------------------------------------------------------
> --------------
> 
>   Karsten Illing
>   GiS Gesellschaft fuer integrierte Systemplanung mbH
>   Abt. Softwareentwicklung SE/S
>   Junkersstrasse 2
>   D-69469 Weinheim
> 
>   Tel.:[+49] 6201/503-46
>   Fax.:[+49] 6201/503-66
>   EMail:k.illing@gis.ibfs.de 
> --------------------------------------------------------------
> --------------
>   
> 
> ----------
> > Von: Gregory Alan Bolcer <gbolcer@gambetta.ics.uci.edu>
> > An: ietf-swap@w3.org
> > Betreff: Issue: Synchronous vs. Asynch.
> > Datum: Mittwoch, 14. Oktober 1998 18:29
> > 
> > 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:35:07 UTC