I've been working with BizTalk 2006 R2 for the last few months on a new project and I have to say I'm not a fan. I recognise the advantages of a guaranteed messaging system and business process modelling tool but just can't learn to love it.
As an agile developer who does not use a designer I find the point and click, drag and drop to be anathema to my usual working practices. Rather than develop code you primarily build a set of UI components in a designer to model business processes (using orchestrations), drag and drop links between two schemas (with maps) and provide integration points via administration settings have to be configured and settings tweaked to get the system lined up to integrate the messages.
When it works, it is pretty intuitive - a beginners BizTalk training course sets you in the right direction and you can achieve rather a lot. But where I feel it falls down are the pain points it causes when you want to do something slightly more advanced. Take consuming a java web service as an example - not only was the feasibility spike work for this excruciatingly long but it was frustrating and a severe blow to morale.
I thought the days of empirical trial and error programming were far behind me but that it just what was required with the black box that is BizTalk - when one approach didn't work, we had to think of a new way... trying this led to further pain points and yet another idea of a different direction to go in after searching for similar woes on google.
The kind of thing I'm talking about is generating items via the WCF wizard when pointing at a web service wsdl where 20+ xsd files are created but then won't compile because of incorrect schema locations caused by a namespace split across multiple files. It didn't even work out of the box.
On top of this, using web service references caused mysterious NullReferenceExceptions in the WCF Marshaller classes with very limited stack trace information in the event log.
Not only is this pain energy sapping but it eats into productivity. I'm sure BizTalk experts would have sailed through our problem and could offer us some real insight into how to solve our problem... but most likely only because they have been through the same trial and error process. I'm all for problem solving as that is precisely what we do as developers but building your craft on black box error resolution is definitely not for me.
I haven't had the time to look at other messaging solutions such as NServiceBus, but I hope to do so in the future - relinquishing the fine detail code level control over what I develop is not something I want to buy into and this is precisely what I've had to do with BizTalk.
2 comments: