- From: Cutler, Roger (RogerCutler) <RogerCutler@ChevronTexaco.com>
- Date: Wed, 10 Jul 2002 07:42:36 -0700
- To: "'Mark Baker'" <distobj@acm.org>, "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>
- cc: www-ws-arch@w3.org
Now you are getting to what I think is a very relevant point. I may be mistaken, but I do not think that it is possible to require that every message arrives at its destination. Nor do I think it is possible to require that both sender and recipient of a message end up with a common understanding of what has happened. So "reliable messaging" does not mean exactly that, right? Would some of this problem go away if we were more in agreement about what "reliable messaging" means? -----Original Message----- From: Mark Baker [mailto:distobj@acm.org] Sent: Wednesday, July 10, 2002 9:35 AM To: Champion, Mike Cc: www-ws-arch@w3.org Subject: Re: [RTF] AC019 proposal to WSA WG [snip] > > Maybe you can answer me this; why is it important that HTTP GET or > > PUT messages be reliably delivered? > > Because lots and lots of developers say that this is an issue, and > many member companies proprietary web services architectures have or > propose a solution to the reliability issue, and because if > reliability isn't covered in the WSA the developers will use > incompatible proprietary solutions, and the absence of a solution to a > commonly cited problem in the WSA will seriously undermine its credibility in the industry. I agree with most of that, but you appear to be associating "reliability" with "reliable messaging", so I can understand your concern. But I'm not ruling out reliability (that would be quite daft!), I'm just saying that there are ways of addressing it that don't invole requiring that every message arrive at its destination, and that it is primarily a function of the architectural style in use as to which solution is the most appropriate. Thanks. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@acm.org http://www.markbaker.ca http://www.idokorro.com
Received on Wednesday, 10 July 2002 10:43:35 UTC