- From: Assaf Arkin <arkin@intalio.com>
- Date: Thu, 9 Jan 2003 17:49:39 -0800
- To: "Hao He" <Hao.He@thomson.com.au>, "'Mark Baker'" <distobj@acm.org>, "'Champion, Mike'" <Mike.Champion@SoftwareAG-USA.com>
- Cc: <www-ws-arch@w3.org>
> Here is my attempt at defining loose coupling. Coupling is the dependency > between interacting systems. Dependency can be classified as real > dependency and artificial dependency. Real dependency is the features or > services one consumes from other systems. Artificial dependency > is the thing > one has to follow in order to consume the features or services provided by > other systems. Typical artificial dependency in IT are: language > dependency, > platform dependency, API dependency ... > > There are two rules here: > 1. One can never reduce real dependency but itself is evolving. > 2. One can never get rid of artificial dependency but one can reduce > artificial dependency or the cost of artificial dependency. > > Hence, loose coupling describes the state when artificial > dependency or the > cost of artificial dependency has been reduced to the minimum. I like this definition a lot! > So, to really compare between REST and SOAP, we just need to look > at compare > the artificial dependency and the cost introduced by them. Let me speculate. REST advocates would point out that in REST the only artificial dependency is HTTP itself, while in SOAP you have both HTTP and SOAP. SOAP avocates will argue that using TCP without HTTP has even less artificial dependency, but since SOAP is becoming ubiquitous, this is a non-factor. REST advocates would then point out you don't need to know anything about the structure of the message so the artificial dependency is lower. WSA advocates would point out that in practice you do need to know the structure of the message (or at least machines do, we humans don't), and since the problem they are addressing (machine understanding) requires that, they would consider REST and SOAP to be equivalent. REST advocates would then point out you only need to know four methods: GET, PUT, DELETE and POST. SOAP advocates would point out you only need to know two methods: GET and POST. REST advocates would point out that all you need is a URI, SOAP advocates would point out that it's a message encoding issue, XML vs URI makes no difference, and besides it's URL not URI. URLs are not loosely coupled. REST advocates would point out that you can expect an operation to have specific semantics based on the method name, SOAP advocates would point out not having to manage the individual state transitions of the service actually reduces coupling. REST advocates would then point out that you can only build REST applications using REST, while SOAP advocates would point out that if you loosely couple the model from the underlying protocol you can actually build REST applications using SOAP. REST advocates would then explain how you put a queue in the middle to decouple the services, SOAP advocates would point out that you need to know there's a queue, so the SOAP approach is more loosely coupled. Deadlock? arkin > > Thoughts? > > Hao >
Received on Thursday, 9 January 2003 20:50:32 UTC