“Stateless” server – the concept (complexity 2 of 5)

This is mostly an introductory piece to the next post. It covers the concept of the stateless server, which BizTalk (its processing part) is.

BizTalk is built to be a symbiosis of two servers: processing server (send/receive, processing, applications – that’s the one you install from the BizTalk CD) and persistence server (persistence, routing – SQL Server with databases, tables, and stored procs created remotely).

The processing server – actual BizTalk node – was architected to be stateless, that is containing no application state. This way if any BizTalk node gets down, it does not matter. There is no loss of state (or data) because there is no state on BizTalk nodes. Some other BizTalk node picks up the work from where it was last persisted in the SQL Server.

Let consider few examples. If HTTP message comes and the power goes down. If message was not yet persisted in the database (message box) then the sender did not received “400 OK” and HTTP connection will time out, so the sender will know that the message did not came through. Similarly, if instead of power failure something happened during the processing of the message, the sender will get something like “500 …” or other HTTP error. These cases are exactly the same as if connectivity is lost, e.g. some roadwork cut the cable. These cases require the sender to send the message again.

When the message is received and persisted, the processing server health does not matter anymore, because the message is now in the database. Now the sender got its “400 OK” and the message is “handed off”. If BizTalk node gets down, it does not matter anymore, because the message is in the database and it will be picked up by some other node.

Similar picture is present for most other adapters and transports. It is also the case for BizTalk applications – orchestrations. When an orchestration sends or receives a message, its state is saved in the database, so even if BizTalk will go down, the orchestration will be revived (rehydrated) from the point after sending or receiving a message. And, as you can guess, putting the message for delivery into the message box and persisting the state of an orchestration is done in the same transaction. So, even if some simple steps may be repeated, no communications with an external world going through BizTalk are repeated or missed.

“Stateless server” architecture helps to build scalable and fault-tolerant messaging solutions and applications that continue to run despite individual hardware failures. Of course, it does not come for free. Stateless server is not a silver bullet, magically resolving all the problems. And anyway, there could not be a fault-tolerant systems on a single machine. However, it is the critical part allowing to build such systems – see future posts on how to do that.

What’s also important, stateless server significantly simplifies the development. It allows to create applications (orchestrations) in a usual stateful manner, but when they run they have the advantages of stateless programs. If you worked with 3-tier architectures or J2EE, you should know that the main advantage of stateless components (data access components in 3-tier designs, business logic and data access beans in J2EE) is scalability. Their disadvantage is the need for stricter development and design discipline that needs to be enforced. With BizTalk you don’t have to do that, in fact, you can write a single application (orchestration) that spans several HTTP submissions from different sessions and different people – BizTalk infrastructure transparently takes care of the state.

Now, what’s the catch? Is BizTalk really “stateless”? Yes, it is, except… That’s what the next post is about.