<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/wordpress-mu-1.0" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: SOAP and High Performance: An Oxymoron?</title>
	<link>http://tssblog.blogs.techtarget.com/2007/07/27/soap-and-high-performance-an-oxymoron/</link>
	<description></description>
	<pubDate>Sat, 07 Nov 2009 20:30:10 +0000</pubDate>
	<generator>http://wordpress.org/?v=wordpress-mu-1.0</generator>

	<item>
		<title>by: LC</title>
		<link>http://tssblog.blogs.techtarget.com/2007/07/27/soap-and-high-performance-an-oxymoron/#comment-498</link>
		<pubDate>Wed, 01 Aug 2007 17:07:57 +0000</pubDate>
		<guid>http://tssblog.blogs.techtarget.com/2007/07/27/soap-and-high-performance-an-oxymoron/#comment-498</guid>
					<description>You missed the point...
Use-cases will drive the decision. If you have a business critical  service requiring integration with a multitude of client platforms (from VB6 client apps to IBM MQSeries), the *safest* bet is a SOAP Service over HTTP. On the other-hand (the article example - financial services) where performance has a much higher priority - SOAP payload  may not be a consideration. Simply put SOAP serves a need, however there are other solutions to other problems too.</description>
		<content:encoded><![CDATA[<p>You missed the point&#8230;<br />
Use-cases will drive the decision. If you have a business critical  service requiring integration with a multitude of client platforms (from VB6 client apps to IBM MQSeries), the *safest* bet is a SOAP Service over HTTP. On the other-hand (the article example - financial services) where performance has a much higher priority - SOAP payload  may not be a consideration. Simply put SOAP serves a need, however there are other solutions to other problems too.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Dave</title>
		<link>http://tssblog.blogs.techtarget.com/2007/07/27/soap-and-high-performance-an-oxymoron/#comment-497</link>
		<pubDate>Wed, 01 Aug 2007 01:25:35 +0000</pubDate>
		<guid>http://tssblog.blogs.techtarget.com/2007/07/27/soap-and-high-performance-an-oxymoron/#comment-497</guid>
					<description>Okay maybe 3k is a slight overstatement. But 1/2 - 1k would be correct! That's still way too much overhead.

The corrected title of this posting should read: "SOAP and high-performance: a moron".

-- Dave</description>
		<content:encoded><![CDATA[<p>Okay maybe 3k is a slight overstatement. But 1/2 - 1k would be correct! That&#8217;s still way too much overhead.</p>
<p>The corrected title of this posting should read: &#8220;SOAP and high-performance: a moron&#8221;.</p>
<p>&#8211; Dave
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Dave</title>
		<link>http://tssblog.blogs.techtarget.com/2007/07/27/soap-and-high-performance-an-oxymoron/#comment-496</link>
		<pubDate>Wed, 01 Aug 2007 01:22:27 +0000</pubDate>
		<guid>http://tssblog.blogs.techtarget.com/2007/07/27/soap-and-high-performance-an-oxymoron/#comment-496</guid>
					<description>ICE? YAML? JSON?

Take your pick!

But anyone who thinks that 3k of deep-nested XML in a SOAP envelope t to send a basic 1-string snippet of information between 2 apps "does not have a performance issue" needs their head read!</description>
		<content:encoded><![CDATA[<p>ICE? YAML? JSON?</p>
<p>Take your pick!</p>
<p>But anyone who thinks that 3k of deep-nested XML in a SOAP envelope t to send a basic 1-string snippet of information between 2 apps &#8220;does not have a performance issue&#8221; needs their head read!
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: LC</title>
		<link>http://tssblog.blogs.techtarget.com/2007/07/27/soap-and-high-performance-an-oxymoron/#comment-495</link>
		<pubDate>Wed, 01 Aug 2007 01:16:07 +0000</pubDate>
		<guid>http://tssblog.blogs.techtarget.com/2007/07/27/soap-and-high-performance-an-oxymoron/#comment-495</guid>
					<description>The word is interoperability. In the pragmatic world, across vendor frameworks, various standards and platforms, SOAP services the interoperability problem very well. Performance is a consideration, but when two systems can not communicate with each other, performance is not the first NFR to be considered.

In summary I guess, sometime performance is a trade-off for interoperability</description>
		<content:encoded><![CDATA[<p>The word is interoperability. In the pragmatic world, across vendor frameworks, various standards and platforms, SOAP services the interoperability problem very well. Performance is a consideration, but when two systems can not communicate with each other, performance is not the first NFR to be considered.</p>
<p>In summary I guess, sometime performance is a trade-off for interoperability
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Jim Cakalic</title>
		<link>http://tssblog.blogs.techtarget.com/2007/07/27/soap-and-high-performance-an-oxymoron/#comment-494</link>
		<pubDate>Tue, 31 Jul 2007 19:08:01 +0000</pubDate>
		<guid>http://tssblog.blogs.techtarget.com/2007/07/27/soap-and-high-performance-an-oxymoron/#comment-494</guid>
					<description>Hmm ... sounds like a reinvention of JINI/JavaSpaces.</description>
		<content:encoded><![CDATA[<p>Hmm &#8230; sounds like a reinvention of JINI/JavaSpaces.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Anonymous</title>
		<link>http://tssblog.blogs.techtarget.com/2007/07/27/soap-and-high-performance-an-oxymoron/#comment-493</link>
		<pubDate>Tue, 31 Jul 2007 18:31:01 +0000</pubDate>
		<guid>http://tssblog.blogs.techtarget.com/2007/07/27/soap-and-high-performance-an-oxymoron/#comment-493</guid>
					<description>No, this view is not entirely correct...
SOAP by itself has no performance issue,

http://webservices.sys-con.com/read/250512.htm</description>
		<content:encoded><![CDATA[<p>No, this view is not entirely correct&#8230;<br />
SOAP by itself has no performance issue,</p>
<p><a href='http://webservices.sys-con.com/read/250512.htm' rel='nofollow'>http://webservices.sys-con.com/read/250512.htm</a>
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
