- From: Mark Baker <distobj@acm.org>
- Date: Thu, 19 Sep 2002 14:53:23 -0400
- To: www-ws-arch@w3.org
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 UTC