- From: Mark Baker <distobj@acm.org>
- Date: Fri, 13 Dec 2002 09:17:08 -0500
- To: "Newcomer, Eric" <Eric.Newcomer@iona.com>
- Cc: www-ws-arch@w3.org
Hi Eric, On Fri, Dec 13, 2002 at 08:07:40AM -0500, Newcomer, Eric wrote: > Mark, > > The problem, as always, is that "broke" is not an absolute concept, certainly not in the specifications under discussion here. Many implementations of Web services specifications actually work. The argument is over how well, and that must involve considering what the implementations are used for. As I've said many times, the use case for Web services is very different than the use case for hypertext document exchange. "broke", as a determination, can be made when you have a problem, and a form of solution which doesn't solve that problem. Wouldn't you say? Problem; machine-to-machine integration over the Internet. Solution; services where each has an interface different than the others That's broken, sorry. I don't know any other way to say it. I could perhaps be more sensitive with my wording, but the message would remain the same. Look at every other form of Internet-scale integration solution that has ever existed; IMAP, LDAP, FTP, SMTP, NFS, etc.. None of those use the uniform interface constraint (since that's specific to the Web), but all use a single network interface that defines a coordination language for that application. > The argument seems to be that HTTP was never designed for Web services, and therefore should not be used for them. Or at least, to implement Web services the same way as hypertext systems were implemented. This is like saying telephone lines were never designed for use by fax machines or modems, and therefore should not be used to send digital signals. All communication over telephone lines should be done using analog voices, since that's what they were designed for. "HTTP was never designed for Web services" is absolutely right. But HTTP *was* designed to solve the problems Web services are trying to solve. That's an important distinction, I'd say. > My view of your proposed text is not at the right level for the architecture document, and that's why I voted not to close the issue. It starts out ok, but at the end becomes prescriptive text of constraint, while to be self-consistent it needs to be descriptive text at the conceptual level. HTTP might be a useful reference as an example, but not as concrete information. > > The text is fine up to this point: > > "...so we feel that interfaces richer than GET/PUT/POST/etc.. are necessary." My point there was that GET/PUT/POST is the interface used by browsers. I could have been clearer about that, granted. > The concept of Web services being used for program-program interaction as compared with hypertext being used for human interaction is correct, and something we can all agree with. No. Hypertext is as much for machines as it is for humans. It doesn't care who's consuming it. It's just data with links to other data, whether that's my home page linking to my favorite online games, or an invoice linking to products that were purchased. MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Web architecture consulting, technical reports, evaluation & analysis
Received on Friday, 13 December 2002 09:12:22 UTC