RE: RM and RC, our experience

Sounds neat. And obviously fits your application requirements.

Presumably it won't hurt if the client makes a request that gets through to
the server and the
client never finds out.

How is a repeating request detected ? - are the application parameters
sufficient to identify
it ?

Do you ever tidy up the status URL's ? Or
perhaps they have to be kept indefinitely anyway for business reasons.

Peter

------------------------------------------
Peter Furniss
Chief Scientist, Choreology Ltd

   Cohesions 1.0 (TM)
   Business transaction management software for application coordination

web: http://www.choreology.com
email:  peter.furniss@choreology.com
phone:  +44 20 7670 1679
direct: +44 20 7670 1783
mobile: +44 7951 536168
13 Austin Friars, London EC2N 2JX

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Hao He
> Sent: 19 December 2002 04:55
> To: 'Champion, Mike'; www-ws-arch@w3.org
> Subject: RM and RC, our experience
>
>
>
> I'd like to share some of our experience on RM and RC.  Our solution does
> not handle extreme cases such
> as: network or server is down longer than the time required for
> any meanful
> business interaction.  However, this solution seems to be good enough for
> most of our situation.
>
> First, we put all coordination duties on the client side.
> The process works like this:
> 1. Client POSTs a message to its Server.
> 2. The Server returns a receipt with a URL to the request status
> and starts
> processing.  If a repeating request is received, the Server
> returns the same
> receipt as if it were received the first time and does nothing.
> 3. Client GETs its request status from the URL.
>
> If there is a network problem in Step 1, the client simply retries again
> until a receipt is received or
> it decides to give up.
>
> If there is a problem after Step 2, the client just keep GETing and GET is
> cheap.
>
> This solution would partially answer Mike's question on how GET
> and POST can
> provide a sufficient coordination language.
>
> Hao
>

Received on Friday, 20 December 2002 10:02:14 UTC