{"id":238,"date":"2003-12-18T07:31:00","date_gmt":"2003-12-18T11:31:00","guid":{"rendered":"http:\/\/www.markbaker.ca\/wp\/?p=75"},"modified":"2003-12-18T07:31:00","modified_gmt":"2003-12-18T11:31:00","slug":"message-metadata","status":"publish","type":"post","link":"http:\/\/www.markbaker.ca\/blog\/2003\/12\/message-metadata\/","title":{"rendered":"Message metadata"},"content":{"rendered":"<p>From early on in my work as a member of the\n<a href=\"http:\/\/www.w3.org\/2001\/xp\/Group\/\">XML Protocol WG<\/a> to make\n<a href=\"http:\/\/www.w3.org\/TR\/soap12\/\">SOAP 1.2<\/a> usable in a REST\nbased architecture, I found myself up against the unmoveable force known\nas &#8220;protocol independence&#8221;.<\/p>\n\n<p>I was reflecting on this experience in the car this morning, and\nrealized that I could perhaps explain the different viewpoints &#8211; of\n&#8220;protocol independence&#8221; and &#8220;transport vs. transfer&#8221; specifically &#8211; in\nterms of message metadata.<\/p>\n\n<p>Message metadata is that data in a message which defines the context\nfor interpretation of the rest of the data in the message.  Application\nprotocols typically have a handful of pieces of it.  For example, HTTP has\n<a href=\"http:\/\/www.w3.org\/Protocols\/rfc2616\/rfc2616-sec5.html#sec5\">the protocol version, request methods, request URIs<\/a>,\nand <a href=\"http:\/\/www.w3.org\/Protocols\/rfc2616\/rfc2616-sec6.html#sec6\">response codes<\/a>,\nand each one of those changes the meaning of their message fundamentally.<\/p>\n\n<p>My issue with &#8220;protocol independence&#8221;, which essentially says that you\nshould put everything you need to know in the SOAP envelope, is that it requires\nme to a) disregard the metadata already provided by application protocols, and\nb) requires me to reinvent the same mechanisms higher up!  Here&#8217;s two examples\nof that form of reinvention;<\/p>\n\n<ul>\n<li>the one I talk about a lot; defining a new <a href=\"http:\/\/www.w3.org\/TR\/soap12-part2\/#rpcinvocation\">place<\/a> to put the requested operation<\/li>\n<li><a href=\"http:\/\/www-106.ibm.com\/developerworks\/webservices\/library\/ws-add\/\">putting the target identifier in the SOAP envelope<\/a><\/li>\n<\/ul>\n\n<p>One type of message metadata that hasn&#8217;t, to my knowledge, been reinvented,\nis the response code metadata.  I don&#8217;t mean the response codes themselves,\nas SOAP does have different standard fault types.  I mean a standardized place\nin a SOAP envelope which indicates whether the SOAP message is a fault or not.\n<em>What&#8217;s that you say?  The mere presence of a SOAP fault in the body of the\nenvelope is sufficient information to identify the fault?<\/em>  Ah, I see.  Well\nthen, you&#8217;ve got a message metadata problem.  To explain it, consider a Web\nservice with an operation whose job is to return the last fault that the service\ngenerated.  How do you distinguish between the success of that operation and its\nfailure?  Both return faults inside the SOAP envelope!  One way would be to define a\nwrapper that encapsulates the fault in the not-a-real-fault case, thereby hiding\nit.  But that wrapper is exactly the kind of message metadata that I&#8217;m talking\nabout!!  Another case of reinvention, and again, completely unnecessary when\nyou&#8217;re using an application protocol which already has a place for such metadata.\nWhen you consider that SOAP doesn&#8217;t define this wrapper, then you have to conclude\nthat either a) SOAP is broken, as it prevents me from defining services which\nreturn data that looks like a fault, or b) there&#8217;s another way to use SOAP, as an\n<a href=\"http:\/\/www.markbaker.ca\/2002\/09\/Blog\/\/2002\/10\/30#2002-10-soap-definition\">extension protocol<\/a> which reuses the message\nmetadata of the underlying protocol (when it has any, which all application protocols do).<\/p>","protected":false},"excerpt":{"rendered":"From early on in my work as a member of the XML Protocol WG to make SOAP 1.2 usable in a REST based architecture, I found myself up against the unmoveable force known as &#8220;protocol independence&#8221;. I was reflecting on this experience in the car this morning, and realized that I could perhaps explain the [&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,40],"class_list":["post-238","post","type-post","status-publish","format-standard","hentry","category-uncategorized","tag-soap","tag-xml"],"_links":{"self":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/posts\/238","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=238"}],"version-history":[{"count":0,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/posts\/238\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/media?parent=238"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/categories?post=238"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/tags?post=238"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}