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