- From: Champion, Mike <Mike.Champion@SoftwareAG-USA.com>
- Date: Thu, 19 Sep 2002 15:30:22 -0600
- To: Mark Baker <distobj@acm.org>
- Cc: www-ws-arch@w3.org
> -----Original Message----- > From: Mark Baker [mailto:distobj@acm.org] > Sent: Thursday, September 19, 2002 5:08 PM > To: Champion, Mike > Cc: www-ws-arch@w3.org > Subject: Representing HTTP in arch diagrams > > > I don't know what you mean by "knowledge of the interaction > mechanism". > And why would you need to hard code important URIs? I don't follow. The "conventional wisdom" would go something like this: In the human-readable Web, interaction is done by typing in URLs or clicking on hyperlinks, discovery is done by reading the text associated with hyperlinks or using a search engine, and publication is done "by hand" with HTTP PUT/POST, FTP, or whatever. For the machine-processable Web, discovery and description are more problematic -- one needs to either hard-code the actual URLs, or code up the rules for building specific requests into a URI and some way of determining the server to send HTTP request to. Thus, SOAP was devised as a standardized and programmer-friendly way to do the interaction, WSDL was devised as a way to rigorously describe the format of SOAP requests and responses, and various discovery mechanisms are being devised to make it possible to find WSDL descriptions. Furthermore, SOAP has become protocol independent, so HTTP is not necessarily a part of the interaction. So, how do you suggest we "draw" HTTP into the picture? (Especially considering that it is not strictly speaking necessary in the SOAP/WSDL world?) I like the idea of explaining how SOAP/WSDL evolved to address the challenges that people had trying to automate Web-style interactions without a human in the loop. One can do things with HTTP alone, of course --a point you might have made once or twice :-) -- but then how does description and discovery work? I'm just asserting that this is generally done with application-level code rather than declarative languages such as WSDL in a RESTful application. Do you disagree? Anyway, that's what I meant by "hard coded": URIs are generated by application code rather than SOAP messages generated from a declarative description. Maybe that's not helpful, since of course one could infer the URIs from RDF metadata or whatever, and the declarative/procedural issue is orthogonal to all this. But as a practical matter in today's technology, I do think that WSDL evolved to help people avoid the hassles of "hard coding" URI generation logic.
Received on Thursday, 19 September 2002 17:30:56 UTC