Creating Scalable Configurations
If the application using it is not too large, the entire BizTalk Server 2004 engine can be installed on a single computer. In many cases, though, this is not a satisfactory solution. The number of messages that the engine must handle might be too great for one computer, or redundancy might be required to make the system more reliable. To meet requirements like these, the BizTalk Server 2004 engine can be deployed in a number of ways.
A fundamental concept for deploying the engine is the idea of a host. A host can contain various items, including orchestrations, adapters, and pipelines. Hosts are only logical constructs; to use them, actual host instances must be created. Each host instance is a Windows process, and as the following figure shows, it can contain various elements.

In the example shown here:
- Computer A runs two host instances. One contains a receive adapter and a receive pipeline, while the other contains the orchestrations P and Q.
- Computer B runs just one host instance, also containing the two orchestrations P and Q.
- Computer C, like computer A, runs two host instances, but neither of them contains an orchestration. Instead, each of these instances contains a send pipeline and send adapter.
- Computer D houses the MessageBox database that is used by all of the host instances in this configuration.
This example illustrates several ways in which hosts might be used. For example, because both computers A and B run host instances that contain the orchestrations P and Q, BizTalk Server 2004 can automatically assign requests to these orchestrations based on the availability and current load on each computer. This enables a business process to scale up as needed for high-volume applications.
In the previous figure, notice also that computer C contains two different ways to handle outgoing messages. One way might rely on a standard BizTalk Server 2004 adapter, such as the HTTP adapter, while the other might use a custom adapter to communicate with a particular application.
Grouping all output processing on a single computer like this can make good sense in some situations. And because each host instance is isolated from every other host instance—they are different processes—it is safer to run code that is not completely trusted, such as a new custom adapter, in a separate instance. In addition, even though this example contains only a single instance of the MessageBox database, you can replicate or cluster the databases to avoid creating a single point of failure.
In BizTalk Server 2004, you do not cluster services.
See Also
Monitoring Applications: Health and Activity Tracking
To download updated BizTalk Server 2004 Help from www.microsoft.com, go to http://go.microsoft.com/fwlink/?linkid=20616.Copyright © 2004 Microsoft Corporation.All rights reserved.