- From: Mark Baker <distobj@acm.org>
- Date: Wed, 10 Jul 2002 07:59:27 -0400
- To: "Cutler, Roger (RogerCutler)" <RogerCutler@ChevronTexaco.com>
- Cc: 'www-ws-arch@w3.org
Hi Roger, On Tue, Jul 09, 2002 at 10:13:41PM -0700, Cutler, Roger (RogerCutler) wrote: > I honestly do not understand this discussion. Is there some fundamental > disconnect here? If so, what would get people talking about the same > issues? I think there is a fundamental disconnect here. But ... > I sort of thought that the requirements for web services, and thus the > architecture, are supposed to be driven by usage cases and scenarios. I agree completely! > It > seems to me that there are numerous usage cases and scenarios that > illustrate the importance of reliable messaging mechanisms that are widely > agreed upon so that one may expect all the parties of a transaction to deal > with this messaging issue in a compatible and mutually understood manner. I > personally think that this requirement is EXTREMELY important, right up > there with the security issues. I don't see how web services can > successfully be used in realistic business situations without well > understood and agreed upon solutions in both areas. I absolutely agree that a reliability solution is required. I just disagree that reliable messaging is suitable in all cases. On the Web, it's a very costly and unnecessary means of achieving reliability. > Frankly, if the best the REST approach can do is say that the application > programmer can deal with 404's, I don't really have a lot of desire to hear > much of anything else about REST. I don't understand. 404 is not an aspect of unreliability, it's something that happens when a Web service provider screws up (primarily, there are other valid reasons for a 404). The only possible way to resolve it is to place a requirement on Web services providers, not the architecture. Something like; "Web services providers MUST always ensure that their published Web services be found. This includes declaring when they've been retired, or when they've relocated." Do we really want to do that? IMO, not supporting a 404 solution won't make the problem go away, it will just make the error non-standardized so that you have no idea why your request didn't work. I consider that a bad thing. > But surely that is not where this > discussion has to be, is it? Is there some way of restating, or possibly > understanding in a different way, the legitimate concerns on both sides of > the controversy in such a way that they are not so mutually incompatible? Yes, I've been trying to get at this. I've been proposing what I feel is a legitimately compromise. Let me rephrase it; "will support a reliability solution befitting the chosen architectural style" How's that? 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 09:40:50 UTC