Multiple Message Boxes in BizTalk (Scale out message box)

BizTalk runtime can be divided into “Process” and “Data” area in larger terms. Orchestrations, receive handler, send handler etc. run under process area. Process area is popularly called “Host”. Host can be mapped to several BTS machine in BizTalk Server group to achieve higher scalability. Such mapping instance is called “Host Instance”. So one “Host” achieves scalability using its multiple “Host Instances”.

Similar to process area, data area can also be scaled out. BizTalk runtime data primarily resides in MessageBox database. It is feasible to use multiple MessageBox databases in single BizTalk Server Group. All these message boxes operate as a big virtual message box. For developers and BizTalk runtime, things do not change while interacting with data area. This is because only message agent performs interaction with message box in both cases of single or multiple message boxes. So for runtime, interaction remains intact and limited to message agent while agent takes pain of rest of the complications (dealing with single or multiple message boxes).

When multiple MessageBox databases are used in BizTalk Server group, one database plays role of Master MessageBox while rest become subordinates (they do not get name of subordinate, this is just analogy). Let’s see how these message boxes segregate process time responsibilities to help in getting greater scalability.

 

Master message box stores all subscription information and help message agent match and route messages to appropriate message box (subordinate). In case of activation subscription, message is routed to any subordinate message box in round robin fashion while in case of instance subscription; message is routed to message box (subordinate) holding dehydrated instance orchestration. Primary task of master message box is do subscription matching and routing.

While master message box focuses on routing, subordinate message boxes hold state data associated to running and dehydrated orchestrations. When an activation orchestration is triggered, it is locked to a subordinate message box and their on this message box stores state data (persistence point) for locked orchestration. Subordinate message boxes also store dehydrated orchestration (long running orchestration inactive for long time, or orchestration using correlations).

This kind of clear segregation in responsibilities allows better scalability and faster performance in BizTalk processing.

Comments

• Anonymous
  October 31, 2006
  I hope that with SQL 2005 one can scale the BT MessageBox by partitioning the tables .....
• Anonymous
  October 31, 2006
  I am not sure about it. I don't think it is a good idea to touch messagebox database for table partition unless BizTalk itself provides some guidelines for this. Lemme further investigate on this....or let us know if you have anything to share with.