<?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: BizTalk Blogs and UdiDahan.com, strange bedfellows?</title>
	<atom:link href="http://www.udidahan.com/2007/12/19/biztalk-blogs-and-udidahancom-strange-bedfellows/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.udidahan.com/2007/12/19/biztalk-blogs-and-udidahancom-strange-bedfellows/</link>
	<description>Enterprise Development Expert &#38; SOA Specialist</description>
	<lastBuildDate>Sat, 11 Feb 2012 15:16:10 -0600</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: udidahan</title>
		<link>http://www.udidahan.com/2007/12/19/biztalk-blogs-and-udidahancom-strange-bedfellows/comment-page-1/#comment-12807</link>
		<dc:creator>udidahan</dc:creator>
		<pubDate>Fri, 21 Dec 2007 07:29:24 +0000</pubDate>
		<guid isPermaLink="false">http://udidahan.weblogs.us/2007/12/19/biztalk-blogs-and-udidahancom-strange-bedfellows/#comment-12807</guid>
		<description>Simon,

Consider the case where your service needs to make use of numerous legacy backend systems, from CICS, SAP, old Sybase DBs, each with its own ugly format. That is one of BizTalk&#039;s strengths. As long as you don&#039;t need high performance for those sorts of things (upwards of a couple hundred messages per second), then BizTalk may even turn out to be cost effective.

A lot of the people I work with would say that the above is a stretch, even for me, to play nice with BizTalk. Yet every product has its sweet spot, however small.

The general idea is to use the above as a stop-gap solution as you phase out and re-engineer your systems to support the larger SOA vision.</description>
		<content:encoded><![CDATA[<p>Simon,</p>
<p>Consider the case where your service needs to make use of numerous legacy backend systems, from CICS, SAP, old Sybase DBs, each with its own ugly format. That is one of BizTalk&#8217;s strengths. As long as you don&#8217;t need high performance for those sorts of things (upwards of a couple hundred messages per second), then BizTalk may even turn out to be cost effective.</p>
<p>A lot of the people I work with would say that the above is a stretch, even for me, to play nice with BizTalk. Yet every product has its sweet spot, however small.</p>
<p>The general idea is to use the above as a stop-gap solution as you phase out and re-engineer your systems to support the larger SOA vision.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Simon Segal</title>
		<link>http://www.udidahan.com/2007/12/19/biztalk-blogs-and-udidahancom-strange-bedfellows/comment-page-1/#comment-12797</link>
		<dc:creator>Simon Segal</dc:creator>
		<pubDate>Fri, 21 Dec 2007 05:15:22 +0000</pubDate>
		<guid isPermaLink="false">http://udidahan.weblogs.us/2007/12/19/biztalk-blogs-and-udidahancom-strange-bedfellows/#comment-12797</guid>
		<description>Look forward to returning after the break and recommencement of the bashing! Seriously though, I am curious about whether you still see 
Biztalk as being relevant from &#039;behind&#039; the service as you once put it?</description>
		<content:encoded><![CDATA[<p>Look forward to returning after the break and recommencement of the bashing! Seriously though, I am curious about whether you still see<br />
Biztalk as being relevant from &#8216;behind&#8217; the service as you once put it?</p>
]]></content:encoded>
	</item>
</channel>
</rss>

