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 13:35:29 UTC