RM and RC, our experience

Hao He <[email protected]>
Newsgroups gmane.comp.web.services.ws-arch
Message-ID <686B9E7C8AA57A45AE8DDCC5A81596AB046AE20B@sydthqems01.INT.TISA.COM.AU>
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
InterScan_Disclaimer.txt (text/plain, 438 B)
=====================================================================
WARNING -This e-mail, including any attachments, is for the 
personal use of the recipient(s) only.
Republication and re-dissemination, including posting to news 
groups or web pages, is strictly prohibited without the express
prior consent of
Thomson Legal & Regulatory Limited
ABN 64 058 914 668
=====================================================================
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.