-Are you stupid? The BizTalk Server is an Integration Server. It is nothing to do with Application servers.
That’s what you are probably thinking now…
Let’s discuss different application types.
Sequential Processing Application
These applications work as single-threaded processes. An application gets the data potions and processes them one after another.
One exemplar of such kind is a file processing application. An application reads a file and processes it, then it reads another file, etc. An application starts with a new file only after finishes with a current file. It works with data in sequence; it processes one data portion then starts with another.
OS works as an application server for such applications. The applications are started by users of when OS is started. Widows Service is such application. OS provides the additional management features like an automatic restart after failure, etc.
The Service [Application]
An example of this kind of applications is a web-site. An Application Server example is the Internet Information Server (IIS). A Service Application is constantly waiting a request from clients. A separate service instance is started for each client request.
If there are too many requests, the application server places the waiting requests in a queue, so the requests are not over flood the server. For the sequential application only a single application instance is working at the time, for the service application many application instances are working simultaneously, one instance per a client request.
Usually a service does not store the client data to a durable storage. If the service instance is crashed for any reason, a client just repeats a request and a new service instance is created. Reliability is good, if the service instance works for a short period of time. But if a service instance works for hours or days, the possibility of the crash increases and reliability is not good.
The Long-Running Service
In the simplest case a service instance gets a client request, processes it, returns the result data, and that’s it. A little bit more complex case, when a service instance itself requests data from an external service. The life duration on this service instance is unpredictable in this case. We cannot manage the external services, we don’t know when they response. Our service instance can possible wait hours and days, and the Application server can move the service instance snapshot to the durable storage and move it back when it gets the result from an external service. This process is called dehydration-hydration, and it increases the service reliability. Also it frees the computer resources, a big number of dehydrated service instances do not clog the computer.
Another problem with long-running services is the request correlation.
Everything is simple if a new independent service instance is created for every client request, a service instance process a request, and returns a result to client. But now the service instance itself requests an external service. Imagine hundreds service instances are working simultaneously and all of them send requests to an external service. The external service processes these requests and returns the responses back. As a result we have hundreds service instances and hundreds responses. How to route a response to the right service instance, which requested exactly this response? Each such response must have some information which links this response exactly with the correct service instance. The process of linking is called the correlation. For example, the service instance Id is included in the request, and then this Id is moved into a response and is used for routing this response back, to correlate this response with the right service instance.
The correlation date should be unique, so each response can be correlated with one and only one service instance.
Ideally the application server provides the correlation mechanism.
Another problem with long-running services is the “dead instance cleanup”. For example, a service instance makes a request to an external service and doesn’t get a response back for predefined period of time. The external service could be down, the network could be overloaded, etc.; there could be many reasons in the distributed world. In another example, the service instance is hanged and does not response in any way. It would be cleaver to declare such service instances as “dead” and remove them from memory.
One popular method for the dead instance cleanup is the “heartbeat measure”. A special heartbeat service periodically requests all working service instance and if some instance does not response, cleanup this instance from memory.
The requests to the external services can return errors for different reasons. Sometimes the external service returns legitimated error and we cannot do anything with it. A request is processed with error and it will be an error if we repeat the processing. But most frequently the error is temporary. For example, the network was overloaded, the database was overloaded, the I/O queue is overcrowded, and the external service is busy. In such cases the request could be repeated after a small delay and after several times we get the good response back. The error will be raised, if the request is retried defined number of times.
So we have a list of additional functionality for the application server which works with the long-running services:
- a durable storage for the service instances
- a correlation mechanism
- a system for monitoring and cleanup of the dead instances
- a retry system of the requests to the external system
And it happens, the Microsoft such application server in its arsenal. It is the BizTalk Server.
The BizTalk database, which is called the Message Box, performs as the reliable data storage. The service instance could dehydrate in this storage and wait here infinite time. Thousand, hundred thousand service instances could wait and the performance of the whole system is not decreased.
The correlation mechanism is a part of the Message Box. Requests are analyzed and routed to the service instance, which is waiting exactly this request, or a request starts a new service instance.
There is a heartbeat and the dead instance cleanup.
There is a retry system which automatically repeats the requests to the external services.
And here is the main feature of the BizTalk Server, its famous reliability. The BizTalk Server processing power simply spreads between several computers and data is stored on the SQL clusters. Deployed applications are working for years without any attention. Power grid could be down, the servers could crash, the network went down, the hard drives could fail. But the applications are not. The BizTalk Server automatically restarted, hundreds or thousands interrupted service instances restore and work as nothing had happened.
| posted on Friday, August 30, 2013 4:46 PM