W3C home > Mailing lists > Public > www-ws-arch@w3.org > February 2003

Issues, trout ponds and other dangerous regions

From: Francis McCabe <fgm@fla.fujitsu.com>
Date: Mon, 17 Feb 2003 14:04:07 -0800
To: www-ws-arch@w3.org
Message-Id: <BC0EA79F-42C3-11D7-93F0-000393A3327C@fla.fujitsu.com>

David gives an eloquent defense of REST in  
[http://www.w3.org/2002/02/mid/ 
007d01c2d325$5c30fc00$c10ba8c0@beasys.com;list=www-ws-arch]; however it  
appears that he re-opens issues that need resolving.

In the current WSA document, in several places, it is stated that Web  
services are NOT tied to specific technologies and protocols (such as  
HTTP, SOAP, WSDL etc.) In fact, currently, the ONLY hard nailed-down  
technology choices are URIs and XML.

If the WSA is to be technology neutral, then it is not appropriate to  
`bang on about' POST vs GET in the document; although constraints such  
as idempotency are definitely `in scope'. On the other hand, if the WSA  
is to be technology centered, then we need to make that choice  
explicit, and soon.

The second nettle is more conceptual: the distinction between resources  
and services. There is a relationship, but perhaps not one that is  
immediately obvious. In my opinion these concepts are at different  
levels of abstraction: a resource is an entity that has an actual  
presence and a service is a means of achieving tasks. Services require  
realizations, and such realizations are resources; but resources can be  
`of' anything and are not tied to services. On the other hand, services  
have descriptions which are not of the service itself but of how to  
interact with them.

This distinction is important because, if the focus is on services as  
opposed to resources, then a large number of concepts need to be `put  
into place' that have no relevance to the strict resource view. A good  
example is the service provider. It is an important concept for a  
service oriented architecture; but has no special equivalent for  
resource. (Owner, however, is a concept that applies to both.)

Finally, there is the hoary old one concerning generic interfaces vs.  
specific interfaces. Again, so far, we have been pretty muddled about  
this. [Personal opinion: it is not possible to completely capture the  
semantics of a message without grasping both the verb and the object of  
the message. Definitely there are different styles of architecture,  
where there is a rich though generic set of verbs that everyone is  
expected to agree on, and where there is an essentially infinite set of  
verbs and everyone is expected to come up with their own definitions. I  
am somewhat persuaded of the merits of the generic case; but its a can  
o'worms defining the spanning set.]
Received on Monday, 17 February 2003 17:05:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:14 GMT