RE: RM and RC, our experience
"Peter Furniss" <[email protected]>
| Newsgroups | gmane.comp.web.services.ws-arch |
|---|---|
| Message-ID | <[email protected]> |
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: [email protected] phone: +44 20 7670 1679 direct: +44 20 7670 1783 mobile: +44 7951 536168 13 Austin Friars, London EC2N 2JX > -----Original Message----- > From: [email protected] [mailto:[email protected]]On > Behalf Of Hao He > Sent: 19 December 2002 04:55 > To: 'Champion, Mike'; [email protected] > 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 >