<?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: Does BizTalk have man-boobs?</title>
	<atom:link href="http://www.richardhallgren.com/does-biztalk-have-man-bobs/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.richardhallgren.com/does-biztalk-have-man-bobs/</link>
	<description>.NET, BizTalk and integration focused scribbles</description>
	<lastBuildDate>Tue, 01 Jun 2010 22:09:55 -0500</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Dexter Legaspi</title>
		<link>http://www.richardhallgren.com/does-biztalk-have-man-bobs/comment-page-1/#comment-368</link>
		<dc:creator>Dexter Legaspi</dc:creator>
		<pubDate>Fri, 22 May 2009 12:46:06 +0000</pubDate>
		<guid isPermaLink="false">http://www.richardhallgren.com/does-biztalk-have-man-bobs/#comment-368</guid>
		<description>actually, only points 1 &amp; 4 are the only reasons to use BizTalk...and for one other reason: EXPANDABILITY

what BizTalk gives you over other custom architecture, is that it provides you an underlying fail-safe and scalable archictecture without having to write code.  you got the transactions, built-in queueing, retries, suspended message monitoring and even throttling if the system is suddenly overwhelmed with messages.  these are the things that most developers are taking for granted and don&#039;t even realize that it&#039;s very difficult to implement.  

it&#039;s funny, because we started with BizTalk 2004 (moved to 2006 shortly) and some other group were laughing at us and they decided to write their own.  Guess what?  years later, the BizTalk 2006 systems are still chugging and the home-growned EAI app got replaced after a few years of headaches.

now over to EXPANDABILITY, once you get to know how BizTalk works, 2 &amp; 3 are hardly a reason.  The tools are just enough, but not that compelling anymore when you find the shortcomings.  For example, BizTalk maps are EASY, but very limited...Fortunately, you CAN reference an XSLT in your BizTalk map, which opens a whole lot of other options.  Also, BizTalk has a number of Adapters and Pipeline components, but the beauty of this is Microsoft has a supported set of APIs and SDKs so you can easily roll your own Adapters and plug-ins!  Microsoft could have easily decided to make this a black box, but they didn&#039;t...and that was an awesome decision.

Now, having that said...BizTalk tech is on its last legs...since MS developed a better tech in the form of Workflows...and with &quot;Dublin&quot; coming, and WF 4.0 incorporating more BizTalk-like features (like correlation), BizTalk is getting less and less attention...especially with that price tag.</description>
		<content:encoded><![CDATA[<p>actually, only points 1 &amp; 4 are the only reasons to use BizTalk&#8230;and for one other reason: EXPANDABILITY</p>
<p>what BizTalk gives you over other custom architecture, is that it provides you an underlying fail-safe and scalable archictecture without having to write code.  you got the transactions, built-in queueing, retries, suspended message monitoring and even throttling if the system is suddenly overwhelmed with messages.  these are the things that most developers are taking for granted and don&#8217;t even realize that it&#8217;s very difficult to implement.  </p>
<p>it&#8217;s funny, because we started with BizTalk 2004 (moved to 2006 shortly) and some other group were laughing at us and they decided to write their own.  Guess what?  years later, the BizTalk 2006 systems are still chugging and the home-growned EAI app got replaced after a few years of headaches.</p>
<p>now over to EXPANDABILITY, once you get to know how BizTalk works, 2 &amp; 3 are hardly a reason.  The tools are just enough, but not that compelling anymore when you find the shortcomings.  For example, BizTalk maps are EASY, but very limited&#8230;Fortunately, you CAN reference an XSLT in your BizTalk map, which opens a whole lot of other options.  Also, BizTalk has a number of Adapters and Pipeline components, but the beauty of this is Microsoft has a supported set of APIs and SDKs so you can easily roll your own Adapters and plug-ins!  Microsoft could have easily decided to make this a black box, but they didn&#8217;t&#8230;and that was an awesome decision.</p>
<p>Now, having that said&#8230;BizTalk tech is on its last legs&#8230;since MS developed a better tech in the form of Workflows&#8230;and with &#8220;Dublin&#8221; coming, and WF 4.0 incorporating more BizTalk-like features (like correlation), BizTalk is getting less and less attention&#8230;especially with that price tag.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Look Ma ! An evil middleware product! &#171; Santosh Benjamin&#8217;s Weblog</title>
		<link>http://www.richardhallgren.com/does-biztalk-have-man-bobs/comment-page-1/#comment-350</link>
		<dc:creator>Look Ma ! An evil middleware product! &#171; Santosh Benjamin&#8217;s Weblog</dc:creator>
		<pubDate>Mon, 23 Feb 2009 22:14:10 +0000</pubDate>
		<guid isPermaLink="false">http://www.richardhallgren.com/does-biztalk-have-man-bobs/#comment-350</guid>
		<description>[...] on this issue. I was just doing some final prep for my VBUG talk tomorrow and came across Richard Hallgren&#8217;s oddly titled post. Richard writes about a QCon webcast of a session done by Martin Fowler and Jim Webber and [...]</description>
		<content:encoded><![CDATA[<p>[...] on this issue. I was just doing some final prep for my VBUG talk tomorrow and came across Richard Hallgren&#8217;s oddly titled post. Richard writes about a QCon webcast of a session done by Martin Fowler and Jim Webber and [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Santosh Benjamin</title>
		<link>http://www.richardhallgren.com/does-biztalk-have-man-bobs/comment-page-1/#comment-349</link>
		<dc:creator>Santosh Benjamin</dc:creator>
		<pubDate>Mon, 23 Feb 2009 21:38:27 +0000</pubDate>
		<guid isPermaLink="false">http://www.richardhallgren.com/does-biztalk-have-man-bobs/#comment-349</guid>
		<description>Richard, Spot on. I agree with these points. It&#039;s also rather ironic that the very &#039;agilists&#039; who want to write all this code &#039;test first&#039;, will then stress the importance of pre-built frameworks and good reliable tools, and will then be selective about what they mean (for example, NHibernate, yes, oh yes!! its open source..it must be divine , but BizTalk, no way too big !!! and its from MS.. it has to be evil ) Sometimes all I want to say, is &quot;bah! humbug!!&quot;</description>
		<content:encoded><![CDATA[<p>Richard, Spot on. I agree with these points. It&#8217;s also rather ironic that the very &#8216;agilists&#8217; who want to write all this code &#8216;test first&#8217;, will then stress the importance of pre-built frameworks and good reliable tools, and will then be selective about what they mean (for example, NHibernate, yes, oh yes!! its open source..it must be divine , but BizTalk, no way too big !!! and its from MS.. it has to be evil ) Sometimes all I want to say, is &#8220;bah! humbug!!&#8221;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Richard</title>
		<link>http://www.richardhallgren.com/does-biztalk-have-man-bobs/comment-page-1/#comment-289</link>
		<dc:creator>Richard</dc:creator>
		<pubDate>Tue, 21 Oct 2008 05:52:37 +0000</pubDate>
		<guid isPermaLink="false">http://www.richardhallgren.com/does-biztalk-have-man-bobs/#comment-289</guid>
		<description>@Simon: Thanks for your post. 

I do agree that not all integration in a project necessarily has to be solves using BizTalk. I have however not seen a project where one would use both BizTalk and NServiceBus i combination (I&#039;m not sure that&#039;s what you saying either) ... And sure I also a agree that when solving these edge cases that lives outside BizTalk you&#039;ll need more experience developers. 

I still however think that my point on BizTalk development vs. custom development are valid.</description>
		<content:encoded><![CDATA[<p>@Simon: Thanks for your post. </p>
<p>I do agree that not all integration in a project necessarily has to be solves using BizTalk. I have however not seen a project where one would use both BizTalk and NServiceBus i combination (I&#8217;m not sure that&#8217;s what you saying either) &#8230; And sure I also a agree that when solving these edge cases that lives outside BizTalk you&#8217;ll need more experience developers. </p>
<p>I still however think that my point on BizTalk development vs. custom development are valid.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Simon Segal</title>
		<link>http://www.richardhallgren.com/does-biztalk-have-man-bobs/comment-page-1/#comment-288</link>
		<dc:creator>Simon Segal</dc:creator>
		<pubDate>Sat, 18 Oct 2008 01:24:51 +0000</pubDate>
		<guid isPermaLink="false">http://www.richardhallgren.com/does-biztalk-have-man-bobs/#comment-288</guid>
		<description>Your four points made are extremely pertinent to small scale projects where scale and throughput are not large concerns in particular. Your example where you site the developer whom wears responsibility for the code that &quot;lost a message&quot; and I would like to refine that idea a little. Messages in an SOA that include BTS in it&#039;s architecture wont necessarily always include BTS at every endpoint. Often enough some process whether it be a long running service hosted in a workflow of some a custom executable, will need to make sure that it&#039;s messages are managed in a durable way and not simply lost on the transport for example. Frameworks like NServiceBus handle this very well. 

Curiously, yes Fowler is wearing leather pants - oh my, what does he think he&#039;s doing? :)</description>
		<content:encoded><![CDATA[<p>Your four points made are extremely pertinent to small scale projects where scale and throughput are not large concerns in particular. Your example where you site the developer whom wears responsibility for the code that &#8220;lost a message&#8221; and I would like to refine that idea a little. Messages in an SOA that include BTS in it&#8217;s architecture wont necessarily always include BTS at every endpoint. Often enough some process whether it be a long running service hosted in a workflow of some a custom executable, will need to make sure that it&#8217;s messages are managed in a durable way and not simply lost on the transport for example. Frameworks like NServiceBus handle this very well. </p>
<p>Curiously, yes Fowler is wearing leather pants &#8211; oh my, what does he think he&#8217;s doing? <img src='http://www.richardhallgren.com/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
</channel>
</rss>
