Web Things, by Mark Baker

Dave Bettin comments on my previous blog entry. He writes;

Mark Baker discusses the causality of redundant message metadata due to the protocol independence nature of Soap. HTTP is not the omnipresent protocol in the services ecosystem; i.e., there are internal business cases where HTTP is not necessary and straight TCP is preferred. I want my metadata to live in the Soap packet; I don’t want leaky metadata abstractions.

I don’t mean to offend Dave with this comment, but that response is typical of what I hear when I make my claim that protocol independence is a bug.

So, how to respond? Let me try a few on for size;

• HTTP was just an example in that entry; the message metadata issue is important to the use of all application protocols … but not transport protocols. If you’re using a transport protocol, like TCP, then all the message metadata should be in the SOAP envelope as TCP doesn’t provide any of its own.
• So you agree SOAP is broken, as you can’t define a service which returns faults?
• Comparing HTTP and TCP is like comparing HTML and Ethernet.
• You can have your metadata in the SOAP packet, but firewalls won’t find it there, as they look for it in HTTP, SMTP, and other application protocols. If firewall admins learn that metadata important to their duties (i.e. protecting their intranets) is being hidden from them, you’ll be shutdown pronto.
• SOAP, the spec, should be protocol independent, permitting bindings to protocols other than HTTP to be created. It’s the use of SOAP which shouldn’t be protocol independent.

Perhaps one or more of those will take. 8-)