{"id":1216,"date":"2005-12-29T21:50:00","date_gmt":"2005-12-30T01:50:00","guid":{"rendered":"http:\/\/www.markbaker.ca\/wp\/2005\/12\/29\/mandatory-tolerance\/"},"modified":"2005-12-29T21:50:00","modified_gmt":"2005-12-30T01:50:00","slug":"mandatory-tolerance","status":"publish","type":"post","link":"http:\/\/www.markbaker.ca\/blog\/2005\/12\/mandatory-tolerance\/","title":{"rendered":"Mandatory tolerance"},"content":{"rendered":"<p><a href=\"http:\/\/www.windley.com\/archives\/2005\/12\/the_tolerance_c.shtml\">Phil Windley summarizes<\/a>\na point by Dion Hinchecliffe;<\/p>\n\n<blockquote cite=\"http:\/\/www.windley.com\/archives\/2005\/12\/the_tolerance_c.shtml\">\nI spoke with Dion yesterday and he talked to me about governance mistakes he sees clients making. The number one problem is something he called the &#8220;tyranny of the `MUST understand&#8217; flag.&#8221; You get a SOAP-based Web service loaded up with WS-* header elements all tagged &#8216;MUST understand&#8217; and you end up with something every-bit as much a central command and control structure as if you&#8217;d just reintroduced the mainframe. No one can do anything unless they&#8217;re using the same toolset.\n<\/blockquote>\n\n<p>I think I understand the issue here, but I think there&#8217;s more to it than\nyou might extract from that paragraph.<\/p>\n\n<p>First off, mandatory extension mechanisms like\n<a href=\"http:\/\/www.w3.org\/TR\/2003\/REC-soap12-part1-20030624\/#soapmu\">mustUnderstand<\/a>\nare a Good Thing, because it makes messages more self-descriptive; <em>if<\/em> a message\nis extended in such a way that older processors can&#8217;t accurately interpret the\nmessage, then you need it to save those processors from processing a message\nwhich they can&#8217;t process.<\/p>\n\n<p>That said though, there needs to be recognition that there&#8217;s a fairly high\ncost of deployment of these kinds of extensions because each one that&#8217;s defined\nbasically bifurcates the space of interoperable agents (you know, just like\ndeploying a new service interface does &#8230; but that&#8217;s another issue 8-).<\/p>\n\n<p>And that&#8217;s where I agree with Dion.  If you find yourself using mustUnderstand\nin more than a handful of your interactions, chances are that you&#8217;ve messed up\nsomewhere, likely by failing to account for sufficient extensibility in previous\nversions.  In fact, I&#8217;d even extrapolate from that to suggest that if you&#8217;re using\nmustUnderstand in version 1.0 of your system, and that system is closed (i.e. behind\na firewall, or otherwise not interacting with pre-existing software), you&#8217;ve\n<em>definitely<\/em> screwed up.<\/p>\n\n<p>Speaking of which&#8230;  Perhaps the worst offender in this regard is\n<a href=\"http:\/\/www.w3.org\/TR\/ws-addr-soap\">WS-Addressing<\/a>,\nbecause it effectively mandates the use of at least one mandatory extension in every\nmessage; wsa:To.  Well, technically it doesn&#8217;t <em>require<\/em> that it be tagged as\nmandatory, but I think it&#8217;s pretty obvious that if a recipient didn&#8217;t understand\nwhere the message was addressed, that all hell would break lose if it tried to process\nit.  So, if you use WS-Addressing, then all of your messages are <em>prima facie\nunprocessable by all existing SOAP software<\/em>.  Oopsie!<\/p>","protected":false},"excerpt":{"rendered":"Phil Windley summarizes a point by Dion Hinchecliffe; I spoke with Dion yesterday and he talked to me about governance mistakes he sees clients making. The number one problem is something he called the &#8220;tyranny of the `MUST understand&#8217; flag.&#8221; You get a SOAP-based Web service loaded up with WS-* header elements all tagged &#8216;MUST [&hellip;]","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[26],"class_list":["post-1216","post","type-post","status-publish","format-standard","hentry","category-uncategorized","tag-soap"],"_links":{"self":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/posts\/1216","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/comments?post=1216"}],"version-history":[{"count":0,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/posts\/1216\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/media?parent=1216"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/categories?post=1216"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/tags?post=1216"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}