Microsoft BizTalk Server 2010 Patterns [Paperback]

This book is broken into two distinct parts. The first part it is a general introduction to the important parts of BizTalk Server 2010: understanding what is BizTalk, when to use it and its capabilities, appropriate topologies for different scenarios (architecture, scalability, availability) and an introduction to the fundaments parts of the platform like BAM, Business Rules and BizTalk artifacts (orchestrations, pipelines, maps, schemas). This part is mainly theory with lot of core patterns.

The second part is written in a form of history, love this part, telling how he began to implement BizTalk integrations on a particular customer, start for the basic scenario (Pass thru) to more robust and complex scenarios. This second part the shifts from theory to practice presenting real world integration patterns explained step-by-step (BAM and Unit Tests, messaging solutions, error handling, BRE, orchestration patterns like convoys ...)

It is a great book and highly recommended. Congratulations to the author: Dan Rosanova (two time MVP BizTalk Server).

First of all it is a great book, and in the first part it extensively details the important parts of BizTalk, how to structure your solution, X/LANG, architecture and its components like BAM, artefacts (i.e. orchestrations, pipelines, maps), operation architecture (i.e. scalability, availability), (unit) testing and messaging concepts. The second part the focus shifts from theory to practice and will be very appealing for professionals that develop BizTalk solutions. This part delivers you the skills to implement error handling, use the WCF-SQL Adapter capabilities, learn BRE (i.e. policies, vocabularies and rules), deal with flat files and bindings, BAM, SQL Broker (Notifications), SharePoint, orchestration patterns (i.e. conveys), handling zombies and some other concepts.

Second reason is that this book neatly fits in with other BizTalk books published by PACKT like :

* Microsoft BizTalk 2010: Line of Business Systems Integration
* SOA Patterns with BizTalk Server 2009

Third and final reason you will be a better BizTalk professional or architect, when applying the knowledge found in BizTalk Patterns book and others. Who wouldn't want that!

I really want to like this book. Right off the bat the title is awesome with a capital A. Right up my alley as it were. For a long time there has been a lack of literature about the more practical details around patterns and anti-patterns and how they are implemented in BizTalk. I am not saying that there has not been anything about patterns, there is a ton of them, but nothing really about how to implement them in a BizTalk solution, and how to do that in practice. Enter this book.

Oh, how I would like to like his book. I am however somewhat disappointed, but you should definitely buy it.

Insightful author
There are chapters and headings that underline how very insightful the author is about BizTalk and its implementation. Headers that are very helpful in summarizing all the disparate definitions that you might already have about BizTalk. One particular header is "When to use BizTalk", which does the best job ever to answer that question. Another is "Visual Studio solution structure" that explains in very practical and well-grounded points how the author feels the solution has to be structured. In my opinion; if you do not already have a solution structure document, use this one.

Author style
The text oozes with practical knowledge and a lot of humor as well. There is no doubt in my mind what so ever that the author, does not only know what he is talking about, but also that there is quite a lot that has been left out of the book in order to shorten the text. He does a very good job of taking a practical approach to development and architecture. He makes use of the same example solution throughout the book. This makes you feel for the solution as you might do for a real life solution. You started it and have seen it grow from a mere file-copy solution to being a core process handler in the enterprise. Another good point in doing this is that he shows the importance of doing the architecture right from the start. To really think ahead and figure out what might be next in order not to "paint yourself into a corner". I think there is too little of this in the book. I would have liked more of a discussion about what might be the best solution within the current context. As all of you know; the problem usually is not to find a solution, but to find the best one within a certain context. That is the beauty of BizTalk in my opinion.

Also, once I would like to read a BizTalk book that assumes I know BizTalk and can tell the difference between a pipeline and a map, and know how to use custom xslt. This book does not, and spends few too many pages about the basics. I think this is due to the editor or publisher. They think you need that in order to make the book complete. I would say you do not. Anyone that would pick up this book feels confident about the basics. The title says so.

Practical approach
The author takes a very practical approach, and together with the code supplied you can easily follow along and learn hands on as well. Once again I would like to point out that some parts might focus too much on the practical but some people really like that so it is just an opinion.

Then there is another thing about the book as a whole. Due to the fact that the author wants you to see the solution grow as it might in a real life scenario, the disposition of the book is partly totally off the wall. The same chapter covers Unit testing and BAM, and another mixes configuring WCF-receive and BRE.

So tell me, what should I do?
So, bottom line: Should you buy this book? Of course you should! The technical aspect of it together with the experience of the author is an opportunity you should not miss. Another point I would like to reiterate is that it fills a gap in the integration literature and I would especially recommend it to people that have worked with BizTalk for two years and changed projects during that time. It might be time to move ahead and have an option during the next ICC meeting.

Though I would like to discuss certain parts about solution structure with the author, there are a lot of tips and tricks I will use in the future.