Application Servers

BizTalk is an application server, but it is designed as a distributed system. There are several specific servers in a BizTalk installation and each runs specific services. The first is the BizTalk Application Server; this is what most people would think is a "BizTalk Server". The BizTalk application is a Windows service that runs in the background on the server, in a similar way to any other service like IIS or SQL Server. Each BizTalk Server can run multiple instances of this runtime that function independently of each other. It is these services (introduced later as host instances) that actually pull the queued work items from the Message Box for processing.

Database Servers

The second set of servers/services are the Database Servers. These host the databases for BizTalk that were covered earlier. They also host Notification Services for use with BAM. Because the Message Box is the heart of BizTalk, the database servers play a critical role in any BizTalk environment. They also run SQL Jobs that are a vital part of the BizTalk architecture. Finally, they run Analysis Services when using BAM Aggregations.

Web Servers

Web Servers also serve an important role in BizTalk. Two specific areas served are as endpoints for HTTP/Web Services/WCF and the BAM Portal; both of which run on IIS. Adapter endpoints must be on a server with the BizTalk Runtime installed, but the BAM Portal only needs the BAM Portal components installed and can thus be on a non-BizTalk Server.

Enterprise Single Sign-On Servers

The Enterprise Single Sign-On service provides secure credential storage for BizTalk solutions. This service is a mandatory part of any server hosting the BizTalk runtime. This is necessary in BizTalk because many applications require non-Active Directory authentication, such as the FTP, DB2, and Oracle Adapters. SSO allows BizTalk to securely store credentials for use by the Adapters. Many other settings are also stored here, which is how BizTalk is able to share credentials and configuration information between different servers in a collection of BizTalk Servers, known as a group.

Each BizTalk server runs its own instance of the SSO service, but one must be designated as the Master Secret Server, which is used to prime the pump, so to speak, for the other SSO servers, by hosting the encryption key used to make the SSO store secure. The other servers in the BizTalk group (introduced next) securely request the master secret from the master secret server and keep a cached copy, checking periodically to see if the secret has changed.

These servers comprise the core parts you would expect in a Visio diagram of a BizTalk environment. In fact, they also match what you would expect from a SharePoint installation or many other systems. Depending on the environment, they could all be on one physical server. This would not, however, be very desirable. They could also be spread over a dozen servers in a large, highly available environment. In Chapter 4, Operating BizTalk, we will cover more about specific topologies and how they might look from an infrastructure perspective.

The BizTalk group

This BizTalk group is the top level abstraction of BizTalk. It is a logical container for everything in a BizTalk installation. The group generally has an analogy to an enterprise, department, or division of the organization that it serves. Applications, servers, and the databases we discussed before belong to one, and only one, BizTalk group. The group is associated with a BizTalk management database, and when you connect to a group via the BizTalk Administration Console, you are actually connecting to this management database, which provides command and control for the entire group. The group itself is purely an abstract construct. It doesn't physically exist on a server; it is all the servers that are involved in a BizTalk installation represented as a collection or single container for ease of organization.

We use the BizTalk group to operate on BizTalk on a global scale, that is to say on all servers in the group at once. From within the BizTalk group, we can see all servers that are part of the group and all applications in the group, as well as their status, which we can also control. If we stop an application in BizTalk, which is done through the group level, it stops simultaneously on every server in that group. The best way to understand the group is to see it through the BizTalk Administration Console. When we look at the Administration Console, we can see the group displayed in a graphical format and this makes it more clear as to how it is structured, as shown in the following screenshot:

We can clearly see sections for Applications, Parties, and Platform Settings. These are all attributes of the group as a whole and are displayed as such by being directly beneath the BizTalk group to which they belong.

A typical enterprise will have several BizTalk groups, normally one for integration/developer testing (used after individual developers check in their changes), one for UAT or user testing, and a production environment. Promotion of a solution through these environments is an important aspect of getting the most out of BizTalk and provides many opportunities for control and audit.

Hosts

Hosts are the next level in the abstraction and hosts are also a purely abstract concept. A BizTalk host defines a logical runtime component; it is an organizational unit for BizTalk that allows separate physical servers to be represented together as a single unit. Hosts are almost like a virtual machine in reverse; they represent a virtual process that can actually exist in multiple physical processes on multiple servers concurrently. That concurrent part is what makes BizTalk so much more powerful than typical clustering. Unlike in a cluster, hosts in a BizTalk group are meant to run concurrently, meaning that two or more servers running the same host instance will not only have automatic fail over, but they will run in an active-active fashion, fully utilizing their potential. Hosts allow us to create a single larger "virtual process" out of many different machines; hence the notion of them being like a virtual machine in reverse. Hosts are the organizational units that equate to the work queues we discussed earlier. Recall that when messages are delivered to subscriptions they are placed into work queues; these work queues are organized by hosts. This gives us the unique ability in BizTalk to tailor our runtime environments to the type of processing our solutions require. If we have solutions that are heavily involved in sending messages to a web service, we can distribute this load over multiple servers though host configurations.

Hosts are also the place where performance settings can be set for the specific purpose that the host is fulfilling. These include throttling, which can be resource, rate, or orchestration-based (covered in Operations Guidance). This is even more significant in BizTalk 2010, where settings that were once global across all hosts in the group are no longer; specifically the Message Box Polling Interval. This is the timespan that the runtime will query the Message Box to check for pending queued work items. Lower polling times allow lower latency, but at the cost of overhead that will reduce throughput. This means a specific host can be set up to be High Throughput or Low Latency, two opposing goals that were not possible to be balanced in a single BizTalk group in older versions of the platform. Fortunately, BizTalk 2010 remedies this and, if nothing else, it is worth the upgrade just for this feature. Because a server can only belong to a single BizTalk group and the licenses are not inexpensive, the alternative in older versions was to simply have two groups. Thankfully, this is no longer the case.

Host instances

A host instance is, as the name implies, the instantiation of a BizTalk Host. This is the executable runtime process that people generally think of as BizTalk. A host instance runs under a Windows user account and on a specific server within the BizTalk group. A host instance is the Windows service for a given host. Each host configured on a server gets its own Windows service, which is automatically created. This is where the processing is actually done; maps, orchestrations, pipelines, and business rules all execute in the context of a host instance. Host instances are powerful constructs different from many programmatic concepts that developers come across. They are indeed processes, but being in a .NET platform they contain app domains and thread pools all their own. They are heavy weight constructs capable of performing all of BizTalk's processing in a single one of them (which is the default upon installation, but not appropriate for a true server installation). Importantly, a server can only have one host instance for a given host, this is not the limitation it may at first appear in the context of the previous statement about their capability. It is a well-designed and thought out construct.

On a server that is running Host Instances, they will be visible within the Services MMC just like any other Windows service, as shown in the following screenshot:

This Windows service functions like most .NET applications and thus has many other settings that can be set at the host instance level. In BizTalk 2010 .NET CLR, orchestration and memory throttling settings are set at this host instance level.

The following is a figure depicting the relationship between the group, hosts, servers, and host instances in BizTalk:

Isolated vs. in-process hosts

Finally, we have the concept of in-process versus isolated host instances. In-process host instances run the BizTalk runtime executable, which covers everything we discussed earlier about host instances. It is a Windows service running on the specific server within the BizTalk group. An isolated host instance is isolated in the sense that it runs in another process context, most often Internet Information Services (IIS). This is isolated, and called such, because it has a limited role that it can fulfill as it is not the BizTalk service executable we described previously.

It is generally a host specifically for receive adapter and cannot perform orchestration, tracking, or send operations. Because these host instances are not in the BizTalk runtime, their status will always appear as Unavailable in the BizTalk Administration Console, as they are not equipped with the same instrumentation that the in-process hosts instances have been.