W3C home > Mailing lists > Public > www-ws-arch@w3.org > December 2002

RE: RM and RC, our experience

From: Peter Furniss <peter.furniss@choreology.com>
Date: Fri, 20 Dec 2002 11:56:16 -0000
To: "Hao He" <Hao.He@thomson.com.au>, "'Champion, Mike'" <Mike.Champion@SoftwareAG-USA.com>, <www-ws-arch@w3.org>
Message-ID: <LLEBILBKKFJFAFMCFCHJAEJKDLAA.peter.furniss@choreology.com>

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 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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:01 UTC