“SOA Patterns with BizTalk Server 2009″ starts off with a brief summary of the goals and benefits of service-oriented architectures,
and then describes how BizTalk Server and the Windows Communication Foundation (WCF) supports actual implementation of SOA.

I think it’s safe to say that while many of the more experienced BizTalk architects and developers already accept the wisdom of taking a service-oriented approach for designing BizTalk Server solutions,
there are still many BizTalk solutions out there that do not conform to SOA principles, and this is often the source of users’ frustration with BizTalk.
BizTalk Server, which I often call “the Swiss-Army-Knife” of systems integration tools, is inherently SOA-friendly. While it can be used to create point-to-point EAI or B2B solutions, or simply provide integration utility services without using SOA principles, these features should be treated as “accommodating exceptions” rather than the rule.

Richard shows “how-to” architect SOA-compliant solutions using critical and challenging scenarios, and he backs up these designs with real working models. This is not a software feature-based “how-to” book
with detailed lab instructions to guide the novice step-by-step to accomplish narrow objectives. This is an architect’s guide to building solutions based on best practices we all should aspire to.
(Having said that, more advanced readers are likely to discover a few counter-intuitive, undocumented configuration details
that may have eluded them.)

After the first two chapters that explain the basics of BizTalk Server and the WCF, this book quickly gets down to business with code and implementation details, some of which are fairly complex for many readers who are new to BizTalk, WCF, XML Schemas, and C# .NET code.
The downloaded code samples supplied from the publisher’s website are undocumented and require additional configuration to set up properly. Determined problem-solvers will prevail, but for the WCF or BizTalk novice, I would definitely recommend taking a class before tackling the configuration details which can lead to some confusion.
Fortunately, the book is easy enough to follow without needing the code.

Some may dismiss this book when they see so many chapters devoted to WCF “because we’re not using WCF”. That would be their first mistake!
As a messaging engine, BizTalk provides the mechanisms for routing and interpreting messages, but the transport of messages are dependent on adapters that publish and consume messages via the BizTalk Messaging Bus.
Although BizTalk has a standard framework for implementing adapter interfaces, these adapters are relatively tightly-coupled to specific systems or vendor-specific implementations of standard protocols on one end, and BizTalk on the other end.
The use of messaging to marshall data across platforms and process boundaries can be defeated when tied to adapters which explicitly require point-to-point connections or proprietary interfaces.

WCF provides a more neutral transport layer for loosely-coupled, interoperable interchanges that delivers more reliable capabilities than we had hoped for from web service standards, and can be reused outside of BizTalk Server.

Richard does a good job of explaining the role of abstraction layers and hiding implementation details. He takes a clever “peel-the-onion” approach in exposing how the BizTalk-WCF Wizards generate artifacts (like WSDLs) through a variety of use cases. We can see from a design perspective “the devil in the details”, and liberate ourselves by manipulating the output through proper design input.

For those who still want to use BizTalk Server without using WCF,
there’s still alot of great SOA design principles such as asynchronous messaging patterns and code reuse in this book which apply to best practices for designing BizTalk Server solutions. XML schema design, efficient use of ports and maps, and basic publish-subscribe techniques
are extensively covered throughout the book. One of the most difficult hurdles for new BizTalk developers to overcome is understanding its core architecture, and how to work with the messaging engine instead of fighting it for absolute control. I think Richard will be successful in nudging them toward a more composite design style that results in less refactoring of procedural code.

“Hey! I learned something new!” In Chapter 7, Richard uses the promoted property, BTS.EmpRRCorrelationToken, which the BizTalk messaging engine uses to associate a response message with the port instance
waiting to send a result to the caller. This is just one example of many “nuggets of gold” that you will find in this book. In fact, for such a small book (less than an inch thick), it is packed with use cases and hidden treasures that would take me months to exploit in my everyday projects.
I’ll bet that people will be blogging on some of these topics for months into the future.

For instance, Richard’s chapter on Versioning SOA components is not a subject to be taken lightly. I spent an entire afternoon thinking (again) about the vast consequences of changing components in a service-oriented, highly-distributed system where IT environments are mixed with static and dynamic systems. Richard provides sensible solutions for versioning assemblies, namespaces, and configurations, which admittedly, may not apply to all components that comprise a particular process. When you consider that clients may need versioning as well as services, and throw in versions of entire environments (JDE, J2EE, etc.),
this can become quite complicated and overwhelming.

Yet, architecting for change is like trying to design for reusability:
some think it’s a luxury they can’t afford under tight deadlines and budget constraints, and that it’s futile to “code the future”.
Yet the future is not as far off as we might think!
Richard outlines specific scenarios that help us reuse code within the scope of our current projects to make our own lives easier.
He offers techniques for versioning endpoints and implementing “flexible fields” for changes that could easily throw a project behind schedule.
Incorporating these best practices in our solutions now, inevitably builds confidence over time that change CAN be managed in agile systems.

Richard’s chapter on the WCF SQL Adapter is one of the best examples of how BizTalk and WCF work together with RPC-style resources like SQL Server. He clearly demonstrates “how-to” provide transactional integrity for operations that span multiple tables without relying on stored procedures we may not own.
He also tackles one of the most common challenges:
listening for changes in a database without excessive polling or using database triggers. Leveraging SQL Query Notifications, this section ties in to an earlier chapter on using Event Messages in conjunction with Document Messages to construct powerful event-based processes.

Finally, the book concludes with three chapters on UDDI, ESB Guidance, and What’s Next for future BizTalk versions.

I haven’t used the ESB Guidance Toolkit, mostly because it was a third-party vendor offering that hasn’t been supported by Microsoft in the past, but I believe this policy changed right before this book went to print.
SOA governance is an important topic, and I can only look forward to Microsoft offering its own enterprise-class SOA Repository that would integrate UDDI and Oslo modelling tools into VSTS along with usage policies.

Lastly, I’d like to conclude with an appeal to readers of this book to participate in on-going conversations online so we can follow up on many of the sound recommendations Richard proposes. I also welcome comments from SOA architects using non-Microsoft technologies.
Call some WCF services from Java clients, and tell us about your experience!

Craig Erickson is the Principal Consultant at Flo Technologies, a consulting firm that specializes in BizTalk solutions
and offers on-demand BizTalk Server and WCF training.