RE: Issue: Synchronous vs. Asynch.

I think that has more to do with a transaction wrapper than the synch vs.
asynch question.  But that being said, maybe we need to define the terms.
What are we saying when we say Synchronous and Asynchronous?

Michael Oliver
Senior Technical Research Engineer
Product Marketing
Open Text Corporation
7391 S. BullRider Ave.
Tucson, AZ 85747
(520)574-8272 Voice
(520)574-8273 Fax
ollie@opentext.com
http://www.opentext.com

-----Original Message-----
From:	ietf-swap-request@w3.org [mailto:ietf-swap-request@w3.org] On Behalf
Of Karsten Illing
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 09:57:30 UTC