RE: Issue: Synchronous vs. Asynch.

Hi Greg,

you made a nice case with your "inconsistency" example. Closely looking, it
is not really inconsistency we are talking about but a "guaranteed promise".
When you call to cancel an order, they confirm this to you (synchronous to
your call). Implicitely they promise you to do the cancellation internally
later on (asynchronous to your call). They reliable store the cancellation
message for later processing (or start a workflow :-)) Often you get a
confirmation letter as soon as the cancellation "really" took place
(asynchronous response).

Thanks,

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: 	Gregory Alan Bolcer[SMTP:gbolcer@gambetta.ics.uci.edu]
> Reply To: 	gbolcer@ics.uci.edu
> Sent: 	Thursday, October 15, 1998 7:26 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:48:05 UTC