A BizTalk host is a logical container representing one or more BizTalk Server run-time instances. Hosts are virtual process boundaries that provide an administrative and a security context for running instances of a BizTalk application. A BizTalk Host provides a container for items such as adapter handlers, receive locations (including pipelines), and orchestrations. Once you have defined a BizTalk host, you can then create instances of it. When creating an instance, you specify the name of a physical server for the host instance to execute on along with a service account for the host to run under. The following figure shows the relationship between servers, hosts, and host instances. A BizTalk group is an organizational unit. Multiple computers running BizTalk Server can be in a single BizTalk group, but all servers in the group share a BizTalk Configuration database (the BizTalkMgmtDb database). When you create a new Host in BizTalk all you are doing is creating an entry in a table adm_Host in the BizTalk Management database and nothing more.  You can attach an Orchestration to this Host, but it won't run until you create a Host Instance.  When you create a Host Instance you actually create a Windows Service and this is what does the work.  So you can start and stop Host Instances but Hosts have no such concept. You cannot add a BizTalk server to the same host more than once. A single host instance can be added to multiple hosts. Items—such as adapter handlers, receive locations (including pipelines), and orchestrations—contained in BizTalk hosts can perform receiving, sending and processing of messages. For every host created, a corresponding set of queue table is made in BizTalk Message Box database

• BizTalkServerApplicationQ (main queue) – host polls this table to collect message pending for processing.
• BizTalkServerApplicationQ_Scheduled (scheduled queue) – this is created but never actually used by BizTalk.
• InstanceStateMessageReferences_BizTalkServerApplication (state queue) – holds the list of messages that have been processed but are required later
• BizTalkServerApplicationQ_Suspended (suspended queue) – suspended message are stored here.

Hosts can be either in-process or isolated.

In-process Hosts

An in-process host instance executes as a Windows service. The BizTalk tools automatically create this service when a new host is created. In-process hosts represent service instances that an administrator creates, deletes, and fully controls with Windows Management Instrumentation (WMI) and the BizTalk Administration Console. In-process hosts have the following characteristics:

• You can enlist any orchestration into an in-process host.
• An in-process host can host any send handler.
• An in-process host can host any of the receive handlers except for SOAP and HTTP:
• • • FILE
    • FTP
    • MQSeries
    • MSMQ
    • POP3
    • SQL
    • Windows SharePoint Services
• The first in-process host you create in a BizTalk Server deployment is the default host and you cannot delete it. The BizTalk Message Queuing adapter uses the default host for static handler configuration. Adding an adapter automatically creates receive and send ports for the default host.

Isolated Hosts

The isolated host is used in conjunction with the HTTP and some WCF receive handlers. They primarily host adapters that are designed to run outside of the normal BizTalk Server runtime process; for example, external processes such as Internet Information Services (IIS) application pools. Isolated hosts have the following characteristics:

• You cannot enlist orchestrations into an isolated host.
• An isolated host cannot host send handlers.
• An isolated host can host only the receive handlers associated with HTTP/S and SOAP adapters (the isolated-type adapters).
• An isolated host cannot host tracking.
• An isolated host cannot be the default host.
• The status of an isolated host is always Status Unavailable. BizTalk Server does not access the status information for external processes.

The BizTalkServerApplication host is the default host for any adapters or orchestrations that you create and for outbound SOAP messages generated by BizTalk, whereas the BizTalkServerIsolatedHost is used for messages received via the SOAP adapter. There are several good reasons for this split. In-bound SOAP messages are handled by Internet Information Server (IIS), not the BizTalk Server engine, unlike other adapters. Also, you can think of messages being received from IIS as being far less trusted than those from other adapters; in many cases they will be received over an untrusted network, such as the Internet. Many adapters, such as the SOAP adapter, need to be hosted by processes other than the BizTalk NT Service. The isolated host model enables this and effectively means that an adapter may be hosted outside of BizTalk. For these scenarios, the adapter actually loads the BizTalk Messaging Engine and, subsequently, the Message Agent into its process address space. This ensures that the same out-of-process communication is required regardless of whether the adapter is hosted by BizTalk or as an isolated adapter. This split allows you to run an isolated host under a different service account with bare minimum permissions to the BizTalk MessageBox, delivering a great security solution. Of course, you can configure each BizTalk host instance with a different service account, enabling the same approach to be used throughout your deployment.

32 bit vs. 64 Bit Hosts

A 32-bit host instance can only address to a maximum of 2 GB. That limits the amount of memory that a process can take. Therefore, as a guideline, it is recommended to configure hosts as 64-bit hosts by not selecting 32-bit only as a 64-bit hosts can address a much higher memory space (up to 7 TB). However, the FTP, POP3 and SQL adapters are not supported to run on 64-bit host instances, and should be run in 32-bit host instances.

Trusted and Untrusted Hosts

BizTalk Server enables hosts identified as authentication trusted to indicate that the sender of a message that the trusted host is queuing to the MessageBox database is an entity other than the trusted host itself. The primary purposes of authentication trust are to enable pipelines to resolve to a Product ID (PID) and pass that PID along to consuming services for use in authorization and outbound party resolution, and to enable the transmission of the sender Windows Security ID (SSID) along to consuming services for use in orchestration action authorization. For more on authentication and authorization, refer Security Features in BizTalk Server

Related links:

https://msdn.microsoft.com/en-us/library/ee276854(v=bts.10).aspx