RE: Issue: Synchronous vs. Asynch.

Excellent analogy.  The telephone conversation with the customer service rep
is synchronous, and she acknowledged your request and in a sense guaranteed
the response, but the actual change of state is asynchronous and you only
get confirmation of the transaction in the mail when your statement comes.

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:	Thursday, October 15, 1998 7:27 AM
To:	kswenson@ms2.com
Cc:	ietf-swap@w3.org
Subject:	Re: Issue: Synchronous vs. Asynch.

 > In my experience I have not seen the need to have this extra state while
 > terminating a process instance.  It is worth finding out from people
 > whether they have a specific need for this intermediate state at this
 > time.  Without any evidence of a strong need, I would be inclined to
 > stick with the terminate, suspend, and such commands as being
 > synchronous.

I guess the example I was thinking of would be where a process
is running on remote server.  My company wants or needs to change,
suspend, or interrupt the process.   Using SWAP, there are a couple
of ways I can see that I might want to do this.  One is to try
and patch the values of the running process, the other is to
stop it altogether and re-start a new one.   Now, suppose
that the particular activity that is active and executing
that you are trying suspend or stop actually has several
sub-activites and processes off on several other servers?
The level of activities could be arbitrarily deep.  HTTP
is generally not the most reliable network protocol.
Do I make an HTTP call, which in turn may make several
others, etc.?  At what point do I terminate the connection
and what sorts of results do I get if a conection fails
or times out down at a sub-connection?

I agree it should probably be configurable, I can see
using both.  We probably should add some sort of
end-to-end header that sets the keep-alive value.
Maybe something like the following: the value
allows the caller to specify a timeout in seconds
or never for synchronous calls.  A status code of either message
sent or not sent, or message completed or not-completed either from
the caller server or a downstream server.

Also, businesses live with inconsistent data all the time.
Again, take the purchase order processing example.  If I
call and cancel my order that I financed through the company,
they confirm for me while I am on the phone that okay
it's done.  In actuality, it doesn't get done while you
are on the phone and it just gets recorded at that point
and after you are finished with the phone call, the company
starts the cancellation order rolling.  It gets sent to
all parts of the company, manufacturing, marketing, customer
service, finance, etc.   Should cancelling my order using
a SWAP call over the WWW be any different?

Greg

Received on Thursday, 15 October 1998 10:47:44 UTC