SOAP Web Services: Built on Tight Coupling?

Share the article!


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?“:

  1. The RPC approach which is one of the selling points of SOAP can’t be called loosely coupled.

  2. 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. 

Share the article!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>