I spent the last couple of days on a Biztalk training course with Biztalk Bill Chesnut. Although I’ve seen a few of Bill’s high-level Biztalk presentations I haven’t gone so deep before. What struck me is just how “service oriented” Biztalk is, without being too “in your face” about it. Although its implementation internally is heavily tied to XML and Schema, it goes beyond the view that some people have of SO where it is directly equated with Web Services over HTTP. Biztalk allows your business processes to consume other kinds of structured data (like delimited files) in the same way that you consume Xml, and its adapter architecture de-couples it from any one particular transport. Also Biztalk puts a friendly face on Xml Schema and Xslt in various designer tools, and much of the terminology (bindings, ports etc) reads as if it has come straight from a WSDL file. The concept of “long-running” (ie non-2PC) transactions and compensation actions are directly aligned with the current thinking on SO and transactions. It seems like a very enlightened product. I get the feeling that (like relational databases) all .NET developers will need to have some familiarity with Biztalk rather than it being solely the realm of specialists.
I still think I have a little way to go before I get the “zen of biztalk”, for example there seems to be some operations you could do in a map or in an orchestration – which is better? Also when is it better to call an orchestration vs. sending a message out on a send port that another orchestration happens to be listening on?
Biztalk Likes:
- XML schema everywhere
- Tenants of SO seem widely used (without being too “difficult” or “precious” about it)
- Rules engine uses XPath internally
- Familiar .NET concepts.
Biztalk Dislikes
- Extremely highly graphical programming environment. I like typing better.
Cool Biztalk tool: Microsoft SDC in the <?xml:namespace prefix = st1 ns = “urn:schemas-microsoft-com:office:smarttags” />
Useful Resource: Aaron Skonnard’s Biztalk Wiki