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.