Reading Craig’s post again I had to go back and re-read Joel’s Law on Abstractions .

It reminded me of how I’ve been thinking about BizTalk and the abstractions that it provides.   As you can probably tell from my level of interest (Shannon – my SO –  would call it an obsession or perserveration) and number of posts  I think BizTalk is a incredible product, so much so that I’ve dedicated my work life to it over any other technology (considering the size and complexity of BizTalk that might not have really been a choice ).  That said – all products that create abstractions are inherently leaky (again read carefully – this doesn’t make BizTalk a bad product in any way). 

IMO the two key abstractions that are the “leakiest” in BizTalk are its integration with the CLR and its pub/sub architecture.  Be very clear about what I mean here – I do not mean that BizTalk’s integeration with the CLR is *bad*.  Far from it.  What I mean is that in order to be competent at using BizTalk you have to understand the CLR very well.  You have to know exactly how the CLR works, and then you have to understand how BizTalk uses and interacts with it.  Failing to do this will lead to hours of unproductive BizTalk development time.

The pub/sub architecture in BizTalk is the same.  It is a brilliant design IMO.  But you can start to develop in BizTalk without even knowing there is a pub/sub architecture (create a simple BizTalk application – nowhere does it ask you to set up a subscription) *until* you get your first “no matching subscription found for the message X” error message.

What does this all mean? To quote Joel – “there is no free lunch”.  Development is hard, BizTalk is hard, the CLR is hard, XML and Web Services are hard.  Gain power from knowledge.