- From: Mark Baker <distobj@acm.org>
- Date: Sun, 11 Aug 2002 15:11:35 -0400
- To: Christopher B Ferris <chrisfer@us.ibm.com>
- Cc: www-ws-arch@w3.org
On Sun, Aug 11, 2002 at 09:22:39AM -0400, Christopher B Ferris wrote: > Yes! So why all the Web services specs that have nothing to do with > this?! 8-) > > <cbf> > What makes you say this? In many regards, this pattern is fully realized in > Web services technology. WSDL is the general equivalent of the HTML form. > The "client" can retrieve (GET) the WSDL description for the service it > desires > and use it to construct the appropriate message to send to the service > (HTML > form POST). Of course, you're probably saying to yourself, but there's no > "wash, rinse, repeat" to this pattern, and I would tend to agree. However, > the > technology doesn't prevent it either. > </cbf> This is a good point to drill down on. You have to look really closely at the roles and responsibilities of the components in a form based transaction, in order to get the machine- processable version of it right. We have two components here; the agent - in this case a user agent controlled by a human user - and the server. A GET from the user agent to the server returns a form (let's assume a POST form for simplicity's sake). The form basically declares the type of document that the user agent should submit. The user agent then punts to the user to fill in the form. A machine processable version of a form should work the same way. The difference is that there's no human to punt to, so the server has to declare the type of document that it wants in return, rather than expecting a user to infer the type. For example, it should say "send me a description of a person" (where "description of a person" is an RDF type identified by a URI), instead of "send me data", where the type of data is expressed only in a human-processable manner. The main difference between this approach and WSDL is that WSDL focuses on operations *and* data types, whereas the REST approach focuses on just data types, and fixes the operation. Another way to look at that, is that receiving some WSDL lists the methods, but it doesn't tell you which method to invoke, meaning that the agent is expected to know that a priori. Or as Paul has said, WSDL is principally a design-time artifact, not a runtime one like a form. > HTML, by virtue of being a very general format for human consumption > (i.e. all resources can have an HTML representation), solved this > problem for humans because there came an expectation that if you said > "Accept: text/html", you'd get something for the vast majority of > resources. What we need, is a similar format/model for machines, such > as RDF. > > <cbf> > So, what I read into this is you are saying "throw out WSDL and SOAP > and use RDF instead". What's wrong with replacing the application/rdf+xml > you suggest above with application/soap+xml and/or application/wsdl+xml? > </cbf> SOAP and WSDL do very different things than RDF does. SOAP and WSDL can't be used to express the state of any resource; you can't use them to say "the temperature is 33 degress celsius", for example. I think that should answer Mike's question too. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@acm.org http://www.markbaker.ca http://www.idokorro.com
Received on Sunday, 11 August 2002 15:10:59 UTC