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. The Process area is popularly called “Host”. Host can be mapped to several BizTalk machine within a 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, the Data area can also be scaled out. BizTalk runtime data primarily resides in one MessageBox database. It is feasible to use multiple MessageBox databases in single BizTalk Server Group. All these Message Boxes operate as one big virtual Message Box. For developers and BizTalk runtime, things do not change while interacting with the Data area. This is because only Message Agent performs interaction with the Message Box, in both cases of single or multiple Message Boxes. So for runtime, interaction remains intact and limited to the Message Agent while the agent takes away the pain of the rest of the complications (dealing with single or multiple Message Boxes).

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

The Master Message Box stores all subscription information and helps the Message Agent match and route messages to the appropriate Message Box (subordinate). In case of activation subscription, the message is routed to any subordinate MessageBox in round robin fashion while in case of instance subscription; the message is routed to the MessageBox (subordinate) holding the dehydrated instance orchestration. So the primary task of the Master MessageBox is to do subscription matching and routing.

While the Master MessageBox 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 MessageBox and then on this MessageBox stores state data (persistence point) for the 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.