I have recently bought the two books Apress put out about BizTalk 2006, “Pro BizTalk 2006” and “BizTalk 2006 Recipes“, and started by reading the first. After the first hundred pages, I can say that this is possibly the most in-depth BizTalk book I’ve read (versions 2000/2002 included :-)), with several details about the insides of BizTalk Server and little tips that can be helpful, and I highly recommend it as a medium/advanced book for developers and architects.
There are some aspects of what I’ve read so far that I dislike, however, and where I think the authors could have selected different approaches:
- Naming Conventions: the book includes a set of BizTalk naming conventions, essential in BizTalk development, but what I think is unnecessary is (table 2.3, p.61) the definition of prefix/identifier-based conventions for the names of shapes in Orchestrations.
Example: If the graphical shape itself represents a Send, why have its name be “Snd_MessageName” and instead of simply “MessageName”? That’s 4 characters wasted in a shape whose size does not grow to accomodate its name. Plus, if the names of the shapes are not identifiers (as variable or message names are), using underscores and casing instead of spaces and readable text is a loss of legibility. - Code Examples in VB.NET: I have never met a BizTalk 2004/2006 developer that uses VB.NET, C# is the language of choice. VB.NET might be a good selection if this was a beginner’s book, but this not being the case, I personally think this is was a poor option.
There are obviously personal preferences in this issue, but the fact that expressions are written in C#-like code, and that the code generated by the ODX cross-compiler is C#, might have been good objective reasons to a difference choice. - Factoring of Visual Studio projects: this is a topic that is more important than it seems, and frequently ignored both in published documentation and examples. The traditional wisdom, when doing BizTalk development, is to factor developments into projects named for example Project.Orchestrations, Project.Schemas, Project.Pipelines, etc., i.e., grouping by type of artifact. This book, unfortunately, makes similar recommendations.
The problem of this type of recommendation is that it doesn’t take in consideration operational issues, especially when long-running processes are involved: imagine you have 2 orchestrations and 2 schemas, and you factor these into a MyProject.Orchestrations and MyProject.Schemas projects. One of the orchestrations waits for a confirmation from a user, and is typically long-running, the other is short-lived. You deploy these into production environments, and all is well. Some time later, there is a need to update the schema used in the short-lived orchestration. What happens? To replace the schemas assembly you have to replace the orchestration assembly as well, and this terminates the long-running processes, which is not good. Having given some importance to the versioning issues, which can indeed help avoid this problem, the authors could have gone for a more refined approach in this factoring issue.
I typically use two approaches: first, factor together artifacts that are versioned simultaneously (example: if a schema changes, it is very likely that any maps using it will also change). This is, by the way, the solution recommended in a Microsoft Webcast done by a couple of BizTalk Rangers a while back. Second, use Domain Driven Design techniques (and here I am referring to Allen’s book with this title) and factor together semantically related artifacts. This also helps when teams of several developers are working in a BizTalk solution.
Factoring BizTalk artifacts into projects is not a simple issue, but these techniques can help guide you in your developments. - Schema versioning: the authors correctly recommend using the namespaces of schemas to do schema-versioning. What I dislike is the usage of .Net-like version numbers instead of schema change/publish date. In page 55, a suggestion is made to use http://Microsoft.BizTalk/Service/v1.0.0.0, where I think something like http://Microsoft.BizTalk/Service/2006/11/18 should be used instead. You do lose the immediate connection to the .Net version, but if schemas are to be published outside your organization or department, this shouldn’t be exposed. Also note that using the date is frequent both in internal BizTalk schemas and W3C recommendations.
Also note that, in page 16, it should read “Windows SharePoint Services (v2.0)” instead of “SharePoint Portal Server”.
Even with these issues, like I said at the start, I highly recommend this book. Buy it, you won’t be disappointed. The only thing that is missing is Adapter development.
