<?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"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: The benefits of an ESB</title>
	<atom:link href="http://www.soabloke.com/2008/01/31/the-benfits-of-an-esb/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.soabloke.com/2008/01/31/the-benfits-of-an-esb/</link>
	<description>pushing soa up the slope (with a pointy stick)</description>
	<lastBuildDate>Tue, 30 Nov 2010 19:23:34 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
	<item>
		<title>By: Saul</title>
		<link>http://www.soabloke.com/2008/01/31/the-benfits-of-an-esb/comment-page-1/#comment-640</link>
		<dc:creator>Saul</dc:creator>
		<pubDate>Wed, 21 Apr 2010 01:51:18 +0000</pubDate>
		<guid isPermaLink="false">http://www.soabloke.com/2008/01/31/the-benfits-of-an-esb/#comment-640</guid>
		<description>@Jeff, thanks for your comment. I agree that change is always difficult but a code change can have different degrees of impact depending on the architecture of your system. My point is that a Service Bus architecture helps promote architectural practices such as loose-coupling which minimise the cost of change.

I also agree that architects should carefully consider the benefits and costs of adopting an ESB architecture. There is complexity which needs to be offset by benefits. But benefits can be realised in the right circumstances - one man&#039;s bloat is another man&#039;s infrastructure.

There are other point-mechanisms for addressing each of the benefits I describe. My experience is that these other mechanisms eventually add up to just another middleware layer in the end. I&#039;d be happy for you to expand on your experience if it is different!</description>
		<content:encoded><![CDATA[<p>@Jeff, thanks for your comment. I agree that change is always difficult but a code change can have different degrees of impact depending on the architecture of your system. My point is that a Service Bus architecture helps promote architectural practices such as loose-coupling which minimise the cost of change.</p>
<p>I also agree that architects should carefully consider the benefits and costs of adopting an ESB architecture. There is complexity which needs to be offset by benefits. But benefits can be realised in the right circumstances &#8211; one man&#8217;s bloat is another man&#8217;s infrastructure.</p>
<p>There are other point-mechanisms for addressing each of the benefits I describe. My experience is that these other mechanisms eventually add up to just another middleware layer in the end. I&#8217;d be happy for you to expand on your experience if it is different!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jeff</title>
		<link>http://www.soabloke.com/2008/01/31/the-benfits-of-an-esb/comment-page-1/#comment-639</link>
		<dc:creator>Jeff</dc:creator>
		<pubDate>Tue, 20 Apr 2010 21:17:47 +0000</pubDate>
		<guid isPermaLink="false">http://www.soabloke.com/2008/01/31/the-benfits-of-an-esb/#comment-639</guid>
		<description>Changes are inevitable and when a schema is changed, the ESB needs to be updated as well as or instead of the client(s) consuming the XML.  What&#039;s the difference, a code change is a code change, we&#039;re just doing it in a different place now.

I can go on and on, but the other &quot;benefits&quot; can also be strategically implemented without the use of an ESB.  The ESB simply introduces another middleware component that can be difficult to diagnose during failure and/or introduce issues during deployment.  It is a good example of code bloat and should be seriously reconsidered prior to implementing in your enterprise.</description>
		<content:encoded><![CDATA[<p>Changes are inevitable and when a schema is changed, the ESB needs to be updated as well as or instead of the client(s) consuming the XML.  What&#8217;s the difference, a code change is a code change, we&#8217;re just doing it in a different place now.</p>
<p>I can go on and on, but the other &#8220;benefits&#8221; can also be strategically implemented without the use of an ESB.  The ESB simply introduces another middleware component that can be difficult to diagnose during failure and/or introduce issues during deployment.  It is a good example of code bloat and should be seriously reconsidered prior to implementing in your enterprise.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kashif</title>
		<link>http://www.soabloke.com/2008/01/31/the-benfits-of-an-esb/comment-page-1/#comment-386</link>
		<dc:creator>Kashif</dc:creator>
		<pubDate>Tue, 27 Jan 2009 14:37:06 +0000</pubDate>
		<guid isPermaLink="false">http://www.soabloke.com/2008/01/31/the-benfits-of-an-esb/#comment-386</guid>
		<description>Precise and to the point....it has cleared few of my confusions about ESB</description>
		<content:encoded><![CDATA[<p>Precise and to the point&#8230;.it has cleared few of my confusions about ESB</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: biorneferndale</title>
		<link>http://www.soabloke.com/2008/01/31/the-benfits-of-an-esb/comment-page-1/#comment-265</link>
		<dc:creator>biorneferndale</dc:creator>
		<pubDate>Sun, 04 Jan 2009 12:43:19 +0000</pubDate>
		<guid isPermaLink="false">http://www.soabloke.com/2008/01/31/the-benfits-of-an-esb/#comment-265</guid>
		<description>Thanks for all you ideas! I sure will be back to visit your site again so i can learn more.</description>
		<content:encoded><![CDATA[<p>Thanks for all you ideas! I sure will be back to visit your site again so i can learn more.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: jjettervu69</title>
		<link>http://www.soabloke.com/2008/01/31/the-benfits-of-an-esb/comment-page-1/#comment-264</link>
		<dc:creator>jjettervu69</dc:creator>
		<pubDate>Sun, 04 Jan 2009 12:15:02 +0000</pubDate>
		<guid isPermaLink="false">http://www.soabloke.com/2008/01/31/the-benfits-of-an-esb/#comment-264</guid>
		<description>I also agree..</description>
		<content:encoded><![CDATA[<p>I also agree..</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: johnny</title>
		<link>http://www.soabloke.com/2008/01/31/the-benfits-of-an-esb/comment-page-1/#comment-262</link>
		<dc:creator>johnny</dc:creator>
		<pubDate>Tue, 30 Dec 2008 17:42:06 +0000</pubDate>
		<guid isPermaLink="false">http://www.soabloke.com/2008/01/31/the-benfits-of-an-esb/#comment-262</guid>
		<description>qpeTPx Thanks for good post</description>
		<content:encoded><![CDATA[<p>qpeTPx Thanks for good post</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Sue Massey</title>
		<link>http://www.soabloke.com/2008/01/31/the-benfits-of-an-esb/comment-page-1/#comment-6</link>
		<dc:creator>Sue Massey</dc:creator>
		<pubDate>Wed, 30 Jan 2008 22:26:23 +0000</pubDate>
		<guid isPermaLink="false">http://www.soabloke.com/2008/01/31/the-benfits-of-an-esb/#comment-6</guid>
		<description>I found your site on google blog search and read a few of your other posts.  Keep up the good work.  Just added your RSS feed to my feed reader.  Look forward to reading more from you.

- Sue.</description>
		<content:encoded><![CDATA[<p>I found your site on google blog search and read a few of your other posts.  Keep up the good work.  Just added your RSS feed to my feed reader.  Look forward to reading more from you.</p>
<p>- Sue.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

