RE: Issue: Synchronous vs. Asynch.

Anything is possible, but I would ask in what case is Synchronous needed?  A
workflow between systems usually some business process, like an approval, an
application of data to some business process that returns results when it
completes.

To me Synchronous usually relates to real time control, a continuous data
stream or a tightly coupled command and result, not a business workflow
process that is a request and a response.

If you can make a case for the need for Synchronous communications between
workflow engines then please do.

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 Bussler, Christoph
Sent:	Wednesday, October 14, 1998 12:01 PM
To:	gbolcer@ics.uci.edu; ietf-swap@w3.org; 'ollie@opentext.com'
Subject:	RE: Issue: Synchronous vs. Asynch.

Can it be made an option so that the caller can decide which way to go
for the specific case if the remote system implements both?

Christoph

> ----------------------------------------------------------------------
> ----------------------------------------------------------
> Dr. Christoph Bussler
>
> The Boeing Company
> Applied Research and Technology
> P.O. Box 3707, M/S 7L-70
> Phone: [+1] 425-865-4576
> Seattle, WA 98124-2207
> Fax: [+1] 425-865-2964
> U.S.A.                                                   E-Mail:
> christoph.bussler@pss.boeing.com
> ----------------------------------------------------------------------
> ----------------------------------------------------------
>
> ----------
> From: 	Michael Oliver[SMTP:ollie@opentext.com]
> Reply To: 	ollie@opentext.com
> Sent: 	Wednesday, October 14, 1998 10:35 AM
> To: 	gbolcer@ics.uci.edu; ietf-swap@w3.org
> Subject: 	RE: Issue: Synchronous vs. Asynch.
>
> I think Asynchronous should be the rule.
>
> There is nothing that says that an Asynchronous response can't be
> immediate
> and thereby meet the needs of processes that need to be tightly
> coupled but
> as you point out, remote systems may have constraints that prevent
> Synchronous response.
>
> 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 Gregory Alan Bolcer
> 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 Wednesday, 14 October 1998 17:28:03 UTC