W3C home > Mailing lists > Public > www-ws-arch@w3.org > September 2002

WSA diffs from REST

From: Mark Baker <distobj@acm.org>
Date: Thu, 19 Sep 2002 14:53:23 -0400
To: www-ws-arch@w3.org
Message-ID: <20020919145323.E1944@www.markbaker.ca>

Re my previous proposal[1] to include a comparison of Web services
architecture constraints, and REST constraints - which received some
support - I've taken a stab at providing some of that text, simply by
going down the list of constraints that Roy describes, and talking
about how I see the common use of SOAP+WSDL fitting in.

The list of constraints I'm working from is here;

  http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1

I left out "code on demand", because it's an optional constraint, and
Web services haven't used it, from what I've seen.

==snip==
1. Client/server

The SOAP processing model describes the roles of "SOAP sender" and "SOAP
receiver", and the additional role of "SOAP intermediary" which combines
the sender and receiver roles, permitting the separation of concerns of
service provider and consumer.  As such, the Web services architecture
also adopts the client/server constraint.

2. Stateless

Neither SOAP nor WSDL attempt to constrain interactions between SOAP
nodes to being stateless or stateful.  It is quite possible to use SOAP
and WSDL to build both types of services, and this is currently common
practice with many publically available Web services.  Therefore, the
Web services architecture does not adopt the stateless constraint.

3. Cache

SOAP and WSDL say nothing about caching.  While SOAP caching extensions
have been discussed, there is currently no requirement that the
cacheability of a message be implicitly or explicitly indicated.
Therefore, the Web services architecture does not adopt the cache
constraint.

4. Uniform Interface

WSDL exists primarily to define interfaces specific to each Web
service.  Therefore, the Web services architecture does not adopt
the uniform interface constraint.

5. Layered System

SOAP defines a processing model which encourages the clean layering of
functionality between nodes, including intermediaries which comprise the
layers.  Therefore, the Web services architecture accepts the layering
constraint.
==snip==

FWIW, I see this partly as a means for integrating some of the harvesting
results into the document.  More of that harvesting work could be
integrated in than I've done here though, obviously.  All suggestions
for doing this are welcome.

Also, we could generalize this section to include any additional
constraints we feel that the Web services architecture should use - but
I couldn't think of any constraints that WSA uses, other than those
listed above.  Anyone?

 [1] http://lists.w3.org/Archives/Public/www-ws-arch/2002Aug/0242

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@acm.org
http://www.markbaker.ca        http://www.idokorro.com
Received on Thursday, 19 September 2002 14:53:22 GMT

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