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

Re: Issue: Synchronous vs. Asynch.

From: Karsten Illing <k.illing@gis.ibfs.de>
Date: Thu, 15 Oct 1998 10:04:58 +0200
Message-ID: <19981015084232.29189.qmail@gis.ibfs.de>
To: gbolcer@ics.uci.edu, ietf-swap@w3.org
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:04:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 22 March 2009 02:44:17 GMT