Freigeben über

Is BizTalk really always stateless?

  • Artikel

Really stateless?

Not exactly. The server architecture is stateless, however BizTalk has add-ons like custom adapters that may compromise stateless status or require additional configuration work to keep it.

Here is an example. Configure a receive location with a file adapter. Now, sender puts a lot of files into the receive folder, and BizTalk is picking them up. Notice, that because of this file receive location BizTalk machine is not stateless anymore. So if the machine with the folder is down, messages cannot be retrieved until the machine gets back online. To make it scalable and reliable you have to put additional effort into putting this folder on a network share, on RAID or SAN storage, etc. Of course, most people don’t do that because they use file adapter in cases when application level protocol can handle transport level faults.

MSMQ/T

It’s different with more reliable transports, especially MSMQ. MSMQT adapter, which is part of the BizTalk, works in a stateless manner as expected. User does not have to do anything to achieve this, it works like magic, but behind the scenes it was not so simple. Let see, what was done to make MSMQT a “good citizen.”

First, MSMQT does not have local queues, it uses BizTalk MessageBox as a persistent storage. Hence, the actual state (queue) is stored on the SQL Server machine.

So, everything is fine? Not yet. What if several BizTalk machines are behind NLB (Network Load Balancing)? MSMQT uses exactly once in order delivery. Hence, only one machine at a time can process messages for a particular receive location – otherwise the order cannot be guaranteed. However, if this machine is down, another machine in the group should be able to pick up the work. How is it done?

When MSMQ TCP connection is established, MSMQT locks an object in the database which is associated 1:1 with the receive location. This ensures that no other machine will pick up the connection for the receive location. If the machine owning the connection goes down or the connection times out, the object is released. So the next time connection is reestablished by the external machine, it may go to a different machine in a group and continue where the first machine dropped off.

Again, user does not see this, it all happens behind the scenes. What the user sees is a reliable delivery of messages from outside to the BizTalk MessageBox and back.

MSMQ/C

If you will look into SDK samples, you will find another adapter – MSMQ/C. It is delivered as a sample, but if you visit Beta place, you know that a fully supported version is coming. This adapter does not implement MSMQ server and does not talk over the wire. Instead, it uses MSMQ service available in Windows (Message Queuing component of Windows). What it means is that a message first receive by Windows MSMQ and put into a local queue on the disk. Then MSMQ/C adapter picks it up from the queue and puts into the MessageBox.

What it means for the stateless status, is that you’ve got a local persistence store – MSMQ Queue. If machine with this particular store goes down, the messages that are already there and not consumed by BizTalk are unavailable.

You still can make it scalable and fault-tolerant, MSMQ has an elaborate story for that and you will have to follow it and configure MSQM service to work under NLB and on a cluster. In particular, it may involve making MSMQ queues a cluster resource, binding MSMQ to the NLB IP address, etc. This additional administrative cost is the result of breaking stateless status of an individual BizTalk server machine.

Notice, that the second store also gives you some headaches when it comes to backup and restore story, but let touch backup and restore in a separate article.

Any others?

Any other perpetrators breaking the stateless status? Not many. You see, the problem with the local storage may only exist if it is used as an intermediate between sender and receiver. File or MSMQ queue are examples of such intermediate storage. In this case, sender delivers the message to the intermediate non-BizTalk storage and has no clue, what happens next. Once you have an intermediate storage, you have to administer it and make sure that it is scalable and fault-tolerant, at least, if you care for that.

Another example of such intermediate storage is SQL Adapter, which uses a SQL Server table to submit the data. In this case, scalability and fault-tolerance is very easy to achieve, however, it still requires extra administration. So in most cases, it is useful to stick to the stateless server concept.

Comments

  • Anonymous
    October 06, 2004
    "if you visit Beta place, you know that a fully supported version is coming"

    Is there a betaplace code to access this beta?
  • Anonymous
    October 07, 2004
    It's MSMQBeta
  • Anonymous
    September 08, 2005
    MSMQT supports only one mode for MSMQ protocol -- transactional exactly once in order. Now, how MSMQ...
  • Anonymous
    March 23, 2007
    MSMQT supports only one mode for MSMQ protocol -- transactional exactly once in order. Now, how MSMQ