-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 sequence of data and processes pieces 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 here 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, here 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 will be created. Reliability is good enough, 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. In this case the life duration on this service instance is unpredictable. We cannot manage the external services, we don't know when they respond. 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, so a large number of dehydrated service instances do not clog the computer.
Another problem with long-running services is a 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, that 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 data should be unique, so each response can be correlated with correspondent 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 in 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 respond in any way. It would be clever 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 instances and if some instance does not respond, it is pronounced dead and removed from memory.
The requests to the external services can return errors for different reasons. Sometimes the external service returns legitimated business error and we cannot do anything with it. A request is processed with error and it will be an error again, if we repeat the request. But most frequently the error is temporary. For example, the network is overloaded, the database is overloaded, the I/O queue is overcrowded, the external service is busy, etc. 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 only, if the request is retried too many 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 for the requests to the external systems
And it happens, the Microsoft has 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 will not decrease.
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, otherwise a request starts a new service instance.
There is a heartbeat and the dead instance cleanup mechanisms.
There is a retry system which automatically resends requests to the external services.
And here is the main feature of the BizTalk Server, its famous reliability. The BizTalk Server processing power is 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 affected. The BizTalk Server automatically restarted, hundreds or thousands interrupted service instances are restored and work as nothing had happened.
| posted on Friday, August 30, 2013 4:46 PM