{"id":506,"date":"2004-10-27T00:28:00","date_gmt":"2004-10-27T04:28:00","guid":{"rendered":"http:\/\/www.markbaker.ca\/wp\/2004\/10\/27\/steve-maine-responds\/"},"modified":"2004-10-27T00:28:00","modified_gmt":"2004-10-27T04:28:00","slug":"steve-maine-responds","status":"publish","type":"post","link":"http:\/\/www.markbaker.ca\/blog\/2004\/10\/steve-maine-responds\/","title":{"rendered":"Steve Maine responds"},"content":{"rendered":"<p>&#8230; to my <a href=\"http:\/\/www.markbaker.ca\/2002\/09\/Blog\/2004\/10\/25#2004-10-ws-why\">latest<\/a>.\nHe <a href=\"http:\/\/hyperthink.net\/blog\/CommentView,guid,5fbc4e45-6d89-433b-8f60-e29ea7902743.aspx\">writes<\/a>;<\/p>\n\n<blockquote>\nGiven that in Mark&#8217;s world a SOAP envelope is not a SOAP message, then I&#8217;m assuming that a SOAP message must logically be {SOAP envelope + other stuff}. Considering Mark&#8217;s position with respect to REST, I&#8217;m assuming that the magical &#8220;other stuff&#8221; is a resource URI and an HTTP protocol verb. I don&#8217;t want to put words in Mark&#8217;s mouth, but that&#8217;s my interpretation of his view of the world.\n<\/blockquote>\n\n<p>Pretty close, yes, but the &#8220;other stuff&#8221; is more than just the HTTP envelope of\nURI\/method\/headers, it&#8217;s also the stuff contributed by TCP\/IP, Ethernet, or whatever\nelse frames the SOAP envelope.\n\n<blockquote>\nIf my assumptions about Mark&#8217;s view are correct, I have a hard time seeing why it&#8217;s so important that this &#8220;other stuff&#8221; be externalized from the envelope. I don&#8217;t see why including the destination URI and protocol verb as headers is such an offensive concept. This is, after all, exactly what WS-Addressing does &#8211; it puts all the information necessary to process an envelope inside of the envelope itself, so the envelope is totally decoupled from its delivery mechanism. What am I missing here &#8211; why is having the envelope stand on its own such a terrible thing? It&#8217;s still a &#8220;document wrapper&#8221; at that point &#8211; one that happens to be fully self-describing, in fact.\n<\/blockquote>\n\n<p>Actually, it&#8217;s not in fact, self-descriptive, which is a large part\nof my complaint and concern.<\/p>\n\n<p>If you worked your way up the stack,\noutside-in through the message, each frame tells you how to\nprocess the next; the ethernet frame includes a field which says that it\n<a href=\"http:\/\/www.iana.org\/assignments\/ethernet-numbers\">contains an IP packet<\/a>,\nthe IP packet contains a field which says\n<a href=\"http:\/\/www.iana.org\/assignments\/protocol-numbers\">it&#8217;s a TCP packet<\/a>,\nthe TCP packet contains a port number which says\n<a href=\"http:\/\/www.iana.org\/assignments\/port-numbers\">it&#8217;s an HTTP message<\/a>,\nand the HTTP message contains a header which says\n<a href=\"http:\/\/www.ietf.org\/rfc\/rfc3902.txt\">it&#8217;s a SOAP message<\/a>.\nAlong the way, of course, the semantics of the message are determined,\nincluding the application semantics provided by HTTP; the operation,\nmessage endpoints (the request URI), and the various headers.  But\nthere is nothing in the Ethernet, IP, TCP, HTTP, or even SOAP specs\nwhich says to expect that there are actually\n<em>new<\/em>\n<a href=\"http:\/\/www.w3.org\/Submission\/2004\/SUBM-ws-addressing-20040810\/#_Toc77464325\">operations<\/a>, and\n<em>new<\/em>\n<a href=\"http:\/\/www.w3.org\/Submission\/2004\/SUBM-ws-addressing-20040810\/#_Toc77464317\">endpoint references<\/a>\nwhich override those of HTTP, within the SOAP envelope itself.<\/p>\n\n<p>Some more good comments and questions &#8230;<\/p>\n\n<blockquote>\nI&#8217;m curious as to what&#8217;s most important to Mark &#8211; constraining the number of verbs or using HTTP as a universal protocol. Hypothetically, what if WS-Addressing was written such that the wsa:Action URI was constrained to 4 verbs, each of which had a direct 1:1 correspondence with an HTTP protocol verb?  That&#8217;s sort of the thought experiment I see in the WS-Transfer protocol. That&#8217;s a compromise that offers REST-style universal semantics while still keeping all the information required to process an envelope inside of the envelope itself. Along with that comes the ability to use any mechanism of moving bits from point A to point B and removes the strict reliance on HTTP.\n<\/blockquote>\n\n<p>What&#8217;s most important, IMO, is the constrained interface.  So yah, I&#8217;d\nbe all for stuffing more things into the SOAP envelope if wsa:Action were\nconstrained to uniform interface semantics.  But such an envelope, for all\nthe same reasons of self-description above, would only be suitable to be\nused on top of transport protocols (like TCP), not application protocols.<\/p>\n\n<p>What you describe in that last sentence is &#8220;protocol independence&#8221;, and\nI consider it the root of all WS-Evil (so to speak).  HTTP isn&#8217;t a bit moving\nprotocol, TCP is.  HTTP provides the application semantics, just like WS-Transfer\ndoes.  Would you consider it a selling point that your WS-Transfer-using app\nwas made independent of WS-Transfer?  I didn&#8217;t think so.  That&#8217;s how absurd I\nsee the requirement that apps which use HTTP should do so independent of HTTP.<\/p>\n\n<blockquote>\nI think he&#8217;s incorrect about his first statement &#8211; to be technically correct, you&#8217;d have to say that WS-Transfer reinvents HTTP on top of SOAP on top of any number of network protocols, one of which happens to coincidentally be HTTP\n<\/blockquote>\n\n<p>Yes, true.  I just like saying &#8220;HTTP over SOAP over HTTP&#8221;. 8-)<\/p>","protected":false},"excerpt":{"rendered":"&#8230; to my latest. He writes; Given that in Mark&#8217;s world a SOAP envelope is not a SOAP message, then I&#8217;m assuming that a SOAP message must logically be {SOAP envelope + other stuff}. Considering Mark&#8217;s position with respect to REST, I&#8217;m assuming that the magical &#8220;other stuff&#8221; is a resource URI and an HTTP [&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-506","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\/506","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=506"}],"version-history":[{"count":0,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/posts\/506\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/media?parent=506"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/categories?post=506"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/tags?post=506"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}