The more that two parties agree upon, the more that can be accomplished between them without additional coordination.
Additional coordination is expensive. It not uncommonly requires years of standardization and years more to deploy the new software to support it. Therefore, if we can leverage existing deployed agreement, that’s always best…
If two parties agree to communicate via TCP/IP, on some specific port, ad-hoc integration capabilities are limited to sending and receiving bits reliably between two points. Want to exchange data? Want to invoke a method? Sorry, additional agreement is required.
If two parties agree to communicate via the common use of SOAP-over-HTTP, ad-hoc integration capabilities are limited to remote method invocation with standardized faults in response. Want to invoke a method? No problem! Want to exchange data? Sorry, that requires additional agreement on a set of methods that facilitate data exchange.
If two parties agree to communicate via HTTP (or other transfer protocols), ad-hoc integration capabilities include data exchange.
… and so on, and so on, up the stack.
I’ve found that placing new technologies in the context of this coordination-centric view of the world as an excellent litmus test for the potential success of those technologies.
It also helps me to evaluate some design choices in large scale systems where an existing system is being “reused”. For instance, I consider the Web services notion of “protocol independence” to be prima facie a bad idea because it knocks us down a notch in terms of what can be coordinated a priori; whereas without tunneling we can use HTTP for data exchange, with tunneling we can only use it for method invocation.