Comments on: Gutting the SOAP processing model http://stage.vambenepe.com/archives/118 IT management in a changing IT world Tue, 09 Mar 2010 22:10:17 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: William Vambenepe — Missing out on the OCCI fun http://stage.vambenepe.com/archives/118#comment-96727 William Vambenepe — Missing out on the OCCI fun Wed, 21 Oct 2009 07:38:13 +0000 http://stage.vambenepe.com/archives/118#comment-96727 [...] just this: the answer (in the form of the SOAP processing model) to these simple questions (here is more about the SOAP processing model and the abuses it has suffered if you’re interested). WSDL is something else. The WS-* stack is also something else. [...] [...] just this: the answer (in the form of the SOAP processing model) to these simple questions (here is more about the SOAP processing model and the abuses it has suffered if you’re interested). WSDL is something else. The WS-* stack is also something else. [...]

]]> By: William Vambenepe’s blog » Blog Archive » REST in practice for IT and Cloud management (part 1: Cloud APIs) http://stage.vambenepe.com/archives/118#comment-79440 William Vambenepe’s blog » Blog Archive » REST in practice for IT and Cloud management (part 1: Cloud APIs) Thu, 16 Jul 2009 08:17:15 +0000 http://stage.vambenepe.com/archives/118#comment-79440 [...] of the WS-* stack (especially the parts related to resource management) and who genuinely likes the SOAP processing model I have a tendency to be a little defensive about REST, which is often defined in opposition to [...] [...] of the WS-* stack (especially the parts related to resource management) and who genuinely likes the SOAP processing model I have a tendency to be a little defensive about REST, which is often defined in opposition to [...]

]]> By: William Vambenepe’s blog » Blog Archive » WS-Transfer, its WSDL and its WS-I compliance: the art of engineered uselessness http://stage.vambenepe.com/archives/118#comment-40016 William Vambenepe’s blog » Blog Archive » WS-Transfer, its WSDL and its WS-I compliance: the art of engineered uselessness Mon, 28 Apr 2008 19:37:40 +0000 http://stage.vambenepe.com/archives/118#comment-40016 [...] 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 [...] [...] 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 [...]

]]> By: William Vambenepe’s blog » Blog Archive » Comparing Joe Gregorio’s RESTful Partial Updates to WS-ResourceTransfer http://stage.vambenepe.com/archives/118#comment-33545 William Vambenepe’s blog » Blog Archive » Comparing Joe Gregorio’s RESTful Partial Updates to WS-ResourceTransfer Fri, 15 Feb 2008 08:44:18 +0000 http://stage.vambenepe.com/archives/118#comment-33545 [...] of this, I read his proposal with interest. I have mentioned before that WS-RT isn’t the best-looking cow in the corral so I was ready to like Joe’s presumably simpler [...] [...] of this, I read his proposal with interest. I have mentioned before that WS-RT isn’t the best-looking cow in the corral so I was ready to like Joe’s presumably simpler [...]

]]> By: vbp http://stage.vambenepe.com/archives/118#comment-10500 vbp Fri, 13 Jul 2007 16:22:08 +0000 http://stage.vambenepe.com/archives/118#comment-10500 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. 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.

]]> By: John Cowan http://stage.vambenepe.com/archives/118#comment-10493 John Cowan Fri, 13 Jul 2007 14:11:01 +0000 http://stage.vambenepe.com/archives/118#comment-10493 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. 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.

]]>