{"id":605,"date":"2004-12-22T09:54:00","date_gmt":"2004-12-22T13:54:00","guid":{"rendered":"http:\/\/www.markbaker.ca\/wp\/2004\/12\/22\/ws-addressing-and-http-as-transfer-protocol\/"},"modified":"2004-12-22T09:54:00","modified_gmt":"2004-12-22T13:54:00","slug":"ws-addressing-and-http-as-transfer-protocol","status":"publish","type":"post","link":"http:\/\/www.markbaker.ca\/blog\/2004\/12\/ws-addressing-and-http-as-transfer-protocol\/","title":{"rendered":"WS-Addressing and HTTP as transfer protocol"},"content":{"rendered":"<p>An interesting\n<a href=\"http:\/\/www.pacificspirit.com\/blog\/2004\/12\/20\/ruminations_on_wsaddressing_and_transfer_protocols\">post from Dave<\/a>.  A few comments&#8230;<\/p>\n\n<blockquote>\nI&#8217;ve been saying for a while now that I think it&#8217;s a shame that SOAP 1.2 didn&#8217;t define a general SOAP to HTTP binding that used HTTP as a transfer protocol, for the previous 2 reasons.\n<\/blockquote>\n\n<p>It does, Dave.  The default binding is a transfer binding; I made sure\nof that.  I think you&#8217;re confusing how people use it with how it&#8217;s defined.\nWeb services proponents generally think that a SOAP envelope is a SOAP\nmessage, yet that interpretation is not licensed anywhere in the spec, and\nis even explicitly rejected in the HTTP binding where the\n<a href=\"http:\/\/www.w3.org\/TR\/2003\/REC-soap12-part2-20030624\/#http-reqbindwaitstate\">state transition table<\/a>\nclearly shows HTTP response codes affecting SOAP message semantics.  It&#8217;s\nalso alluded to in the\n<a href=\"http:\/\/www.w3.org\/TR\/soap12-part1\/#encapsulation\">glossary<\/a>\nwhere the definition of the two terms <em>differ<\/em> (you think this was\naccidental?  Hah! 8-).<\/p>\n\n<blockquote>\nI would love it if there was a reasonable way to bridge the SOAP\/WS-Addressing world and the HTTP Transfer protocol world, but I just don&#8217;t see that each side really want the features of the other side. The SOAP\/WSA folks want the SOAP processing model for Asynch, and don&#8217;t care about the underlying protocol. The Web folks want their constrained verbs and URIs and don&#8217;t care about SOAP processing model.\n<\/blockquote>\n\n<p>Avert ye eyes!  False dichotomy alert!!  You can get the SOAP processing model,\nand HTTP as transfer protocol (including asynch, which HTTP handles just fine despite\ninsistance from many that it doesn&#8217;t) simply by using SOAP in the manner prescribed\nin the SOAP 1.2 spec and default HTTP binding.  In order to do so though, you need\nto give up on the idea of a new (non-URI) identifier syntax.  <em>This is really not\na big deal!<\/em>.  We are, after all, primarily talking about <em>syntactical<\/em>\ndifferences here.  What EPRs are trying to do is comparable to inventing a new\nalphabet for the english language; perhaps there are benefits, but I think the\nphoenician alphabet has a, <em>ahem<\/em>, rather large and insurmountable head start\nin deployment, making those benefits &#8211; if they exist at all &#8211; completely\ninconsequential.<\/p>\n\n<p>Dave then makes a really interesting statement of the &#8220;protocol independent&#8221; variety;<\/p>\n\n<blockquote>\nHere&#8217;s a test case: Would the Atom protocol switch to using WS-Addressing and then use the HTTP as Transport binding(s) and HTTP as Transfer binding? Seems to me not likely. The Atom folks that want to use HTTP as Transfer have baked the verbs into their protocol, and they won&#8217;t want to switch away from being HTTP-centric. And same as I don&#8217;t see the SOAP centric folks wanting to &#8220;pollute&#8221; their operations and bindings with HTTP-isms.\n<\/blockquote>\n\n<p>Emphasis on &#8220;baked the verbs into their protocol&#8221;.  Seriously &#8211;\nno matter how you slice it you&#8217;re <em>always<\/em> baking verbs into a\n&#8220;protocol&#8221;, because an application developer has to know what verbs they&#8217;re\nusing.  The problem as I see it, again, is one of nomenclature; that Web services\nproponents have a very narrow RPC-inspired definition of &#8220;protocol&#8221; (transport),\nand their mental models built around this definition simply can&#8217;t fully absorb\nthe implications of the broader definition used in the IETF and W3C (transfer).\nThey simply can&#8217;t conceive of something called a &#8220;protocol&#8221; playing such an\n<em>enormously<\/em> significant role in a distributed system, yet this is precisely\n<em>how<\/em> all existing Internet scale systems are built, and precisely\n<em>why<\/em> Web services proponents haven&#8217;t yet realized that the Web is what\nthey&#8217;ve been trying to build, at least since the quest for &#8220;document oriented&#8221;\nservices began in 2001\/2002.<\/p>\n\n<p>One might also look at Dave&#8217;s statements and ask themselves, well, if they&#8217;re\ngoing to be dependent on a protocol, then it might as well be the most successful\none ever developed rather than one which has struggled for deployment anywhere\nexcept <em>behind<\/em> the firewall.  And somebody please remind me; why is it\ndesirable to be independent of a transfer protocol, but dependent on SOAP the\nprotocol?<\/p>","protected":false},"excerpt":{"rendered":"An interesting post from Dave. A few comments&#8230; I&#8217;ve been saying for a while now that I think it&#8217;s a shame that SOAP 1.2 didn&#8217;t define a general SOAP to HTTP binding that used HTTP as a transfer protocol, for the previous 2 reasons. It does, Dave. The default binding is a transfer binding; I [&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,34],"class_list":["post-605","post","type-post","status-publish","format-standard","hentry","category-uncategorized","tag-soap","tag-w3c"],"_links":{"self":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/posts\/605","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=605"}],"version-history":[{"count":0,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/posts\/605\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/media?parent=605"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/categories?post=605"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/tags?post=605"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}