Views
- State: published
SOAP Web Services: Built on Tight Coupling?
|
|
In a former life, I composed XML specifications (see: B2B Messaging Header) for standards committees. Back then, I felt that these XML standards were getting nowhere, fast forward 3 years later and we've digressed further.
Eric van der Vlist writes an article "SOAP Web Services: built on a contradiction?":
- The RPC approach which is one of the selling points of SOAP can't be called loosely coupled.
- If the SOAP layer can use existing protocols such as HTTP, the usage that is done of these protocols is such that the infrastructure needs to be totally refactored to be suited for Web Services.
Furthermore, he reveals that many real world applications tend to have an REST architecture. It's clear that to achieve widespread interoperability (afterall isn't that the goal of webservices?), loosely coupled solutions are the method of choice. Doug Kaye put together a short table on the subject, however I wasn't convinced so I put together my own:
| Tight Coupling | Loose Coupling | |
| Interface | Class and Methods | REST like (i.e. fixed verbs) |
| Messaging | Procedure Call | Document Passing |
| Typing | Static | Dynamic |
| Synchronization | Synchronous | Asynchronous |
| References | Named | Queried |
| Ontology (Interpretation) | By Prior Agreement | Self Describing (On The Fly) |
| Schema | Grammar Based | Pattern Based |
| Communication | Point to Point | Multicast |
| Interaction | Direct | Brokered |
| Evaluation (Sequencing) | Eager | Lazy |
| Motivation | Correctness, Efficiency | Adaptability, Interoperability |
In summary, if the goal is to achieve better interoperability then we need to deviate from the familiar and be prepared to make some hard choices.
Last modified 2003-07-30 04:15 PM


