Why I'm falling in love with BizTalk

Nice post Aaron - one small nit - BizTalk's pub/sub isn't based on XML at all - it is based on promoted properties. A *few* promoted properties are *sometimes* initialized from XML (like MessageType), but promoted properites themselves are just name/value pairs which don't have to be XML or have anything to do with XML. Promoted properties do have schemas associated with them - but really just for the namespace URI and the type. BizTalk is also happy to pass around non-XML messages - and there is also support for Custom formatters that don't rely on XML at all.

Aaron - very interesting post. I've been suggesting Biztalk as the integration point for a new in house delivery/build/test system that VSTS just isn't grown up enough to handle.

We need an orchestration engine, and want to use web services as the connectors so one day we CAN use VSTS. It seemed to me that Biztalk was worth a look for use as the OE rather than writing our one.

I think your post just convinced me further

What I *don't* love about BizTalk - price.

Christian - I definately think it is worth the price - for what you can get 7k US (for standard) or 25k US (for enterprise) seems easily worth it. I think the thing to remember is that the competition (TIBCO,WebMethods etc) for BizTalk is way way more expensive.

Good point, Jon. You've driven home points #3-4 even further and helped show that BizTalk truly doesn't make many assumptions. I realize there are numerous ways (via its flexibile extensibility points #4) to do what you suggest, but alas, the primary developer experience for promoting information that feeds the pub/sub engine centers around XSD. And since I'm an XML guy through and through, this makes me very happy. ;-)

Jon - That price isn't quite right. Don't forget to add the price of SQL Server, upon which BizTalk is dependent. Microsoft has a habit of (very wisely ?) making their server products dependent upon each other.

As for the cost/benefit, that depends, but the equation changes when you start adding SQL licenses.

They may not have paid you to write this, but I wish they'd pay you to write some decent documentation.

BizTalk is very powerful, but the documentation and supporting tools just suck, and the BizTalk team seems to be a taking a "it's on my blog, so it's documented" approach.

I'm really looking forward to BTS 2006 - I'm hoping they'll spend the time that they should have spent on 2004 to tighten up all those annoying frayed edges.

We are small microsoft e-commerce site. The price of biztalk makes it pretty much useless for companies like mine.

So i am not even playing with it.

Christian - you are correct - I left out the SQL licensing price, I do not claim to be a BizTalk licensing cost expert - I do see what BizTalk can do, and I know how long it would take me and a team of developers to build it using SQL Server - so I assume the database cost for a custom application as well. For many enterpise applications I would jump on BizTalk as a bargain over custom development. But that is just my opinion.

Have you tried testing the throughput of the SOAP transports with real world orchestrations? Good luck on getting anything better than 1 transaction per second.

We're looking at future SKU differentiation in order to make the technology appealing to a broader audience in future versions. That includes the possibility of reworking price points.

Integration and process server technology is still very young. We suffer from that a bit as does the rest of the industry. BizTalk Server 2006 does indeed buff out those rough edges you run up against with the current product.

We don't believe that blogging replaces documentations at all. We've been steadily improving the documentation since RTM. If you haven't downloaded the latest docs please do so. Also you'll notice a link on each doc page that enables you to provide feedback directly to the User Experience team which writes the docs. We take customer input serious and this is a great way for us to collect actionable feedback that we can apply to the next round of documentation updates if customers use it.

As for the BizTalk related blogging, we’re proud of the community that has sprung up. It's a lot of fun to interact with partners and customers in near real time during all stages of the product life cycle. I personally hope that the community keeps getting stronger.

Finally on performance; if you're truly seeing 1 transaction per second then something isn't right. The SOAP adapter and heavy use of orchestration will knock your transaction rates down. Depending on what you're doing you should be able to get that up over a hundred Tx/sec. on a well tuned BizTalk server farm. I've attached a couple of perf related links below (Mea culpa - one is a blog :^).

Finally keep on using and blogging BizTalk Server. The BizTalk Product group does hear you and we're working hard to address your concerns.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/bts_2004wp/html/04d20926-20d2-4098-b701-52238a267eba.asp

http://blogs.msdn.com/biztalkperformance/

Warm regards,
Mike Woods
mwoods@microsoft.com
Sr. Technical Product Manager
Microsoft Corporation

Biztalk and AgileMethods are the different views to implement SOA architectures. In this article I talked about both flavors of software development

Can't BTS use free MSDE, MS SQL Server 2005 Express?

Guennadi Vanine

the points are so beutifully expressed and laid out . My favorite is

<i>What's funny about these points is that they contain all the various XML/WS buzz-words most of us are sick of hearing - in fact, I'm even having a hard time writing this. But BizTalk seems to bring them to life. </i>

just a quick though on how you can compare Biztalk with Tibco, webMethods on price where Biztalk is clearly lacking some of the core concepts of a genuine integration platform?


I was always curious on where the actual integration platform - the communication between external parties, internal offices and manufacturing plants etc will be done.

We are all waiting for WCF on that one :-P

Andreas,

Would you please enlighten me on what "BizTalk is clearly lacking" as a "genuine integration platform"? It's the BizTalk messaging layer, which is focused purely on integration that I find most interesting, compelling, and competitive.

Biztalk messaging layer is MSMQ and supports/runs on only MS Windows. If you have a heterogenous OS environment, like most real world has, MSMQ is not an option and one needs to consider non MS MQ solutions like IBM's.

Biztalk might support open standars at XML level, but at implementation level, specially where reliability of transactions is required, it is downright proprietary and practically not an option.

BizTalk messaging is not built on MSMQ but rather SQL Server. MSMQ is one possible transport that you can use to get messages in and out of the message box.

BizTalk is all about interoperability and integration. It comes with numerous adapters for connecting to any transport or common enterprise application. The adapter framework also allows anyone to write custom adapters, which has fueled a healthy 3rd party adapter community.

BizTalk itself must run on Windows but nothing else throughout the system has to.

Have you compared BizTalk with other vendor's SOA offering. Such as Oracle and IBM?

BizTalk's support for Web service looks like an afterthought. Trying to call a web service using a SOAP send port is a nightmare. Similarly, creating a SOAP receive port has undue number of steps.

Much of the problem stems from appalling documentation.