Harry Pierson talked a bit about the stuff he's learning on BizTalk Server in Morning Coffee 12 entry (btw, loving the, keep it up!). Looks like he's attending a great class with Matt Milner . A few comments that sparked my interest: Harry says that conceptually BizTalk hasn't changed all that much since the 2000/2002 days. I'm not sure I'd agree, but that would depend on what he means by "conceptually" I'd say that from an architecture point of view, the the change between 2002 and 2004 was a very significant one, requiring you to adapt to a lot of new stuff. Here's why I feel this way: The orchestration engine was pretty much rewritten. The designer by itself is a great improvement, but it's far more than that: There's no more interpreted XLANG, now we have XLANG/s Orchestrations (*.odx) are compiled down to C# and then to MSIL. Now we have a pretty powerful correlation mechanism as well as convoys. Native .NET support (it is .NET after all!) The messaging model changed significantly: Most of the terminology changed. Remember channels, AICs and Receive Functions? The messaging model is now mostly symmetrical, unlike in 2000/2002 where the send and receive sides were very different. The pipeline model is far nicer (have I mentioned I love pipelines? they're fantastic!). The adapter framework. Sure beats down anything we had in 2000/2002! Writing adapters is still hard, but writing them in .NET is far easier. Application Integration Components (AIC) were a kludge, anyway. New features: Enterprise Single Sign-On Business Activity Monitoring: Don't disregard the power of BAM, it's one of the coolest features in BizTalk and coming soon to WCF and WF thanks to the new BAM interceptors for WCF and WF in BizTalk 2006 R2. Business Rules Engine Maybe it's just me, but I do consider that the change between 2002 and 2004 to be very significant and a much needed improvement. But I'd agree that from some points of view, yes, BizTalk is still BizTalk (e.g. you still use it for the same and a lot of the usage scenarios haven't changed at a conceptual level). Personally, I consider understanding the BizTalk architecture an absolute must for any BizTalk developer, and as you can see, I get all excited talking about it Harry also mentioned something I've heard a lot of people say: that the Pub/Sub engine in the BizTalk MessageBox was mostly useful for messaging-only scenarios. I agree that's what it might seem so at first but just to reinforce what Matt said in the class: The Message Box really is the heart of BizTalk and the Pub/Sub engine in it is exactly what gives it that power! So let me briefly enumerate just why the Pub/Sub engine is extremely relevant to orchestrations in BizTalk: The Pub/Sub engine processes any message that comes into BizTalk, and that includes messages that fire orchestration instances. Even when you do the simplest Port to Orchestration bindings, subscriptions are still created/evaluated/matched in the MessageBox to enable the processing Read More...