Picking up where we left off in the Service Bus Introduction, this post will walk through a Relayed Messaging sample in order to highlight how the AppFabric Service Bus could be utilized to build Hybrid applications.  In addition to the basic sample, I will also demonstrate how to provision a BizTalk Server 2010 Receive Location on the Service Bus.

Earlier this week I participated in a discussion thread on LinkedIn regarding the usage of the WCF SQL Adapter in BizTalk Server and I wanted to summarize some of my thoughts and the recommended best practices regarding this particular scenario.

Basic Requirement

Using the WCF SQL Adapter in BizTalk, we need to issue a select statement against multiple tables in SQL Server through the use of INNER JOINs.

The reports of my death are greatly exaggerated. ~Mark Twain (or BizTalk Server)

For the past 5 years or so, various technologists have been predicting or even proclaiming the untimely demise of Microsoft BizTalk Server.  Usually these predictions come in the form of blog posts espousing the new hotness whether it was a new product from Microsoft or a competing product claiming it was a better middleware solution than BizTalk.  Oddly enough, the chatter ramps up the loudest shortly after Microsoft releases a new CTP of technology X that may be tangentially related to an existing product like BizTalk.  The problem with all of the proclamations is that they never seem to come from the Microsoft Product Development groups or BizTalk MVPs.  I am not an MVP, but I do consider myself to be plugged in to what is happening with BizTalk.  With that in mind, I would like to briefly take a look at the current state of BizTalk's life and put an end to the urban legend.

In an effort to maintain control over the proliferation of application servers and data, many organizations have undertaken projects to consolidate and integrate systems.  One of the first hurdles in undertaking an integration project is determining the most efficient integration technology.  Unfortunately, just within the Microsoft stack, there are technologies that consistently cause confusion and are often misused.  For example, the lines are continuing to blur when comparing BizTalk Server to Windows Workflow especially now that hosting Workflows using Windows Server AppFabric can provide functionality that appears similar to BizTalk.  However, there are still quite a few giveaways when you need one versus the other.  Underneath most applications, we commonly find a data platform and for many organizations, their platform of choice is SQL Server.  The intersection of just these 3 technologies leads many to ask the question, "if I want to integrate System A with System B, which technology should I use?"  Many times there are no hard and fast rules, but with some careful thought and consideration of organization demands and technological capabilities, the fog will lift and a clear answer will emerge.  This post will by no means provide the definitive answer, but I will provide a few common scenarios that might help illuminate the path.

During my past BizTalk engagements, I have had the opportunity to work closely with my clients in developing flexible and maintainable applications.  One of the most common issues that I come across is the misuse of some of the shapes available within the Orchestration Designer.  By misuse, I simply mean to say that many BizTalk developers will drag and drop shapes into an orchestration to implement the business process, but do not take into account the implications of doing so.  More often than not, the result of selecting the wrong shape for the job is not seen until the application is tested or even worse, the production environment.  One of the primary reasons that BizTalk is used is the opportunity to build loosely coupled, flexible and scalable applications.  By choosing the wrong shape, many developers will wind up doing exactly the opposite, thus setting the application down the course of tight coupling and brittle implementation. 

BizTalk development on virtual machines has become an essential part of the development process.  The speed with which you can tear down and build up BizTalk VMs means you spend less time configuring environments and more time developing artifacts.  Typically, an instance of one of these environments contains everything (BizTalk, SQL Server, Visual Studio, etc.) running on a single VM machine.  Spinning up a new development environment is as easy cloning your base image.  Occasionally, though, you need a development or sandbox environment that’s a little more than a virtualized BizTalk “island”, of sorts, with everything running on a single VM.  

In the BizTalk Server 2009 documentation for the topic How to Handle Typed Fault Contracts in Orchestrations, the documentation assumes the reader is calling a web service based on the SOAP 1.2 specification.  The code sample presented will not work if the user is configuring a WCF Send Adapter to call a web service based on the SOAP 1.1 specification.  When the code sample is used as it is presented against a service based on the SOAP 1.1 specification, the user will most likely see an error like System.InvalidOperationException: Unable to find match for inbound body path expression.