<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Gutting the SOAP processing model</title>
	<atom:link href="http://stage.vambenepe.com/archives/118/feed" rel="self" type="application/rss+xml" />
	<link>http://stage.vambenepe.com/archives/118</link>
	<description>IT management in a changing IT world</description>
	<pubDate>Tue, 19 Aug 2008 22:34:46 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6</generator>
		<item>
		<title>By: William Vambenepe&#8217;s blog &#187; Blog Archive &#187; WS-Transfer, its WSDL and its WS-I compliance: the art of engineered uselessness</title>
		<link>http://stage.vambenepe.com/archives/118#comment-40016</link>
		<dc:creator>William Vambenepe&#8217;s blog &#187; Blog Archive &#187; WS-Transfer, its WSDL and its WS-I compliance: the art of engineered uselessness</dc:creator>
		<pubDate>Mon, 28 Apr 2008 19:37:40 +0000</pubDate>
		<guid isPermaLink="false">http://stage.vambenepe.com/archives/118#comment-40016</guid>
		<description>[...] people (hints: Armonk; Blue) pushed hard to put WS-RT instructions in the body rather than in headers, seriously compromising its ability to seamlessly compose with existing SOAP [...]</description>
		<content:encoded><![CDATA[<p>[...] people (hints: Armonk; Blue) pushed hard to put WS-RT instructions in the body rather than in headers, seriously compromising its ability to seamlessly compose with existing SOAP [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: William Vambenepe&#8217;s blog &#187; Blog Archive &#187; Comparing Joe Gregorio&#8217;s RESTful Partial Updates to WS-ResourceTransfer</title>
		<link>http://stage.vambenepe.com/archives/118#comment-33545</link>
		<dc:creator>William Vambenepe&#8217;s blog &#187; Blog Archive &#187; Comparing Joe Gregorio&#8217;s RESTful Partial Updates to WS-ResourceTransfer</dc:creator>
		<pubDate>Fri, 15 Feb 2008 08:44:18 +0000</pubDate>
		<guid isPermaLink="false">http://stage.vambenepe.com/archives/118#comment-33545</guid>
		<description>[...] of this, I read his proposal with interest. I have mentioned before that WS-RT isn&#8217;t the best-looking cow in the corral so I was ready to like Joe&#8217;s presumably simpler [...]</description>
		<content:encoded><![CDATA[<p>[...] of this, I read his proposal with interest. I have mentioned before that WS-RT isn&#8217;t the best-looking cow in the corral so I was ready to like Joe&#8217;s presumably simpler [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: vbp</title>
		<link>http://stage.vambenepe.com/archives/118#comment-10500</link>
		<dc:creator>vbp</dc:creator>
		<pubDate>Fri, 13 Jul 2007 16:22:08 +0000</pubDate>
		<guid isPermaLink="false">http://stage.vambenepe.com/archives/118#comment-10500</guid>
		<description>Fair enough John, but even if your SOAP messages only go over HTTP there are many things you get from SOAP headers that you don't find in HTTP headers. Obviously more syntactic room (multiple lines), but more importantly the processing model that I talk about in the article (including the mustUnderstand attribute). In addition, the "X-" convention used to support extensions in HTTP headers only takes you so far  compared to XML namespaces as used in headers.
So you do get some value by using SOAP headers instead of HTTP headers (which doesn't mean it's always better to use them of course). On the other hand, when you move from the SOAP headers to the SOAP body you actually loose value, as I tried to illustrate.</description>
		<content:encoded><![CDATA[<p>Fair enough John, but even if your SOAP messages only go over HTTP there are many things you get from SOAP headers that you don&#8217;t find in HTTP headers. Obviously more syntactic room (multiple lines), but more importantly the processing model that I talk about in the article (including the mustUnderstand attribute). In addition, the &#8220;X-&#8221; convention used to support extensions in HTTP headers only takes you so far  compared to XML namespaces as used in headers.<br />
So you do get some value by using SOAP headers instead of HTTP headers (which doesn&#8217;t mean it&#8217;s always better to use them of course). On the other hand, when you move from the SOAP headers to the SOAP body you actually loose value, as I tried to illustrate.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John Cowan</title>
		<link>http://stage.vambenepe.com/archives/118#comment-10493</link>
		<dc:creator>John Cowan</dc:creator>
		<pubDate>Fri, 13 Jul 2007 14:11:01 +0000</pubDate>
		<guid isPermaLink="false">http://stage.vambenepe.com/archives/118#comment-10493</guid>
		<description>You're quite right to say that those who ignore SOAP headers end up reinventing them in the body.  But then again, SOAP headers themselves are the result of ignoring HTTP headers and reinventing them in the HTTP body.  (Non-HTTP SOAP is nothing but a figment.)

HTTP headers were designed to be just as extensible as SOAP headers, yet almost all APIs throw away any that are not used directly by the infrastructure.</description>
		<content:encoded><![CDATA[<p>You&#8217;re quite right to say that those who ignore SOAP headers end up reinventing them in the body.  But then again, SOAP headers themselves are the result of ignoring HTTP headers and reinventing them in the HTTP body.  (Non-HTTP SOAP is nothing but a figment.)</p>
<p>HTTP headers were designed to be just as extensible as SOAP headers, yet almost all APIs throw away any that are not used directly by the infrastructure.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
