I had the pleasure of presenting on BizTalk 2004 at the Heartland Developer’s Conference 2004.  The whole conference was a lot of fun, and as Kent Tegels has noted, Joe Olsen did a great job in organizing the logistics for this event – you wouldn’t have known it was the first-of-a-kind (save for Joe’s mea culpa on caffeine…)

I had a chance to talk to Sam Gentile about the work he has been doing at Addesso.  This was enlightening, since in my non-BizTalk-work-life I do quite a bit mobile work in the field-force-automation space (using ruggedized Pocket PC devices – great fun!)

As to the presentation itself – one of the topics I discussed was BizTalk 2004’s scaling model, and the power of having being able to create multiple host instances for a single logical host definition that contains your orchestrations.  This gives you a “competing consumer” effect – multiple processes on multiple servers, all pulling from a common work queue.  In my talk, I suggested that this idea wasn’t new and related it back to a 1998 article in Enterprise Developer’s magazine.  In that article, an architect from Merrill Lynch was discussing the scaling difficulties in using NT4/MTS – the load balancing options weren’t pretty.  He proposed a pattern he dubbed “Auctioning” where clients would submit work to an MSMQ queue, and multiple servers (all running common server-side components) would pull work from that queue.  The benefits he articulated relate quite closely to what you will find in the parallel aspects of BizTalk 2004.

Check out this graphic from the article – it should look a little familiar to BizTalk folks.

Below is my paraphrase of the article’s main points, recast with BizTalk terms (and exactly relevant to BizTalk, I believe…)

• To load balance multiple servers, servers objects [orchestrations] should pull work from a global [per-host] work queue that clients place their requests in.
• Auctioning works well precisely because it relies on the message queue server [messagebox], not DCOM [or transport of choice], to route the request to the server object [orchestration].
• Server objects [orchestrations] compete for requests on the queue, so load balancing happens naturally; the server with the most available processing capability will automatically check the queue more often and service more requests. [unlike IP load balancing]
• If you add more server machines, the requests just get processed faster by more instances of the object [orchestration]
• If one server goes down, the remaining servers continue to process the requests. There's no single point of failure.

You can find the whole presentation (which also discussed BizTalk compared with traditional application servers) right here.