Use it for SQL schema generation using Add Generated items 
wizard.

Use it for Send and receive Port

Custom Pipeline components extend the behavior of Pipelines 
to include processing data of virtually any format. They 
can be a powerful solution if you support legacy systems 
that require integration with other products, but your 
legacy data format does not follow standards.

YES.

This will be in case when you route the failed messages.

If you use XML object, then you can get any *.xml messages 
into orchestration

yes, whenever we are using the .net class we assighn the 
message without shema

yes by using XML Document datatype

Having version attribute in the root node name

having root node and name space you can version your schema

Use Document Version attribute of schema

When A message is passed through biztalk without being 
processed then it is called Message Routing.

When A message is passed based on certain field value of 
schema, it is called content routing.

Host is nothing but the logical container of host instance.
from which we can create host instance.

Host instance is a Win-NT service.

A BizTalk Server Host is a logical set of zero or more 
BizTalk Server run-time processes in which you deploy items 
such as adapter handlers, receive locations (including 
pipelines), and orchestrations.

A host instance is the process where the message 
processing, receiving, and transmitting occurs You install 
a host instance on each server running BizTalk Server 2006 
that has one or more hosts mapped to that server

If the application using it is not too large, the entire 
BizTalk Server 2004 engine can be installed on a single 
computer. In many situations, however, this is not the 
right solution. The number of messages 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 things, including 
orchestrations, adapters, and pipelines. Hosts are just 
logical constructs; to use them, a BizTalk Server 2004 
administrator must cause actual host instances to be 
created. Each host instance is a Windows process, and as 
the following figure shows, it can contain various elements.
Figure 6 Host computers
 
In this figure:
•	Computer A runs two host instances. One contains a 
receive adapter and receive pipeline, while the other 
contains the orchestrations P and Q. 
•	Computer B runs just one host instance, also 
containing the 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 allows a business process to 
scale up as needed for high-volume applications. 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. It is also 
worth pointing out that even though this example contains 
only a single instance of the MessageBox database, you can 
also replicate or cluster the databases to avoid creating a 
single point of failure.
Managing Applications
The BizTalk Server 2004 engine provides a range of 
services, and several different tools are used to manage 
this environment. The primary tool is the BizTalk 
Administration console, a Microsoft Management Console 
(MMC) snap-in. This tool enables you to create hosts, 
assign hosts to computers, start and stop orchestrations, 
and perform many other administration tasks. You can even 
dynamically add computers and specify what hosts should be 
assigned to them while an application is running—there is 
no need to shut the application down to make these changes. 
You can also access the functions of the Administration 
console programmatically through Windows Management 
Instrumentation (WMI), which enables you to create scripts 
that automate management functions.

Use content Base routing

create receive port and Send Port.
while configuring send port provide filter condition as
BTS.Receiveportname=<receive_portname you created>

Can have custom functoids, custom pipelines, custom
adapters, custom way of calling BRE, calling external .NET
assemblies

Kris

use custom developed .NET components by calling 
external .NET
assemblies

Surjit
Bangalore

create one port, port type as dynamic.
Drag one expression shape in orchastration.
in that type, Portname(Microsoft.XLANGS.BaseTypes.Addresses)
= Address url.

Create a MAP in Biz talk and add first name and  last name
strings with space in between and map to destination schema
node. Use that map in port to port binding either in recieve
port or in send port.

Use the looping functoid to link FirstName and LastName to 
Name. use this map as outbound map in send port binding.

We use Stored procedure or updategram to put data in SQL 
Adapter.

promoted property makes schema variables visible for data 
segregation , distinguished property makes the variable 
visible within the orchestration.

There are two different ways in which you can
programmatically access an attribute or element in BizTalk,
they are called Distinguished Field and Promoted Property.
The main differences between them are summarized in the
table below.

Promoted properties can do everything and more than
distinguished fields, but this doesn't mean that
distinguished fields are less useful. Actually you should
prefer the use distinguished fields whenever possible:

	Distinguished Field	Promoted Property
Syntax	msgOrder.CustomerId	msgOrder(BookShop.CustomerId)
Access method	Using XPath in runtime.	Inserted in message
context during pipeline processing.
Can be accesses by	Only in code in orchestrations.	Both in
orchestration code and in the messaging configuration (e.g.
filters on send ports).
Storage	Only run-time access	A promoted property is stored
in the message context.
Constrained by message contents	Yes, only values within the
message may be accessed.	No, any type value can be promoted
in a pipeline (there is no need for the value to be
contained in the message).
Routable	No	Yes, as they are attached to the message context
they can be used for routing
Expensive (whatever that means)	No	Yes, even if they are
never used they are always read and inserted into the
message context. As the message is passed through the
MessageBox and Orchestration the context needs to be copied
and stored.
Visible in HAT	No	Yes
Size limit	Unlimited	Max 256 characters
XSD type support	More than prom.prop.	Less than dist.fields

Which one of these two ways to access elements/attributes in
a message should you choose? The answer will present itself
if you answer the following questions:

    * Do you need to route on the information in the
element/attribute?
    * Do you need to track the element/attribute?
    * Do you need to use information that can only be
dynamically created, i.e., it is not directly accessible in
the message.

If the answer to any of these questions is Yes, then you
need to use a promoted property. If the answers to all
questions are No, then you should use a distinguished field.

Depending on the type of solution you are creating you will
find that you use one of these more than the other.
Messaging solutions typically use promoted properties to
route incoming messages to the correct destination, there is
no need to use distinguished fields in messaging solutions
as you no way of accessing the value.

If you are building a solution containing orchestrations
that model business processes you will probably mainly use
distinguished fields. The reason for this is that you will
have less need for the routing capabilities of promoted
properties, and as it is less expensive from a performance
perspective to use distinguished fields you should prefer
these. In orchestrations you can use distinguished fields in
a number of ways; conditions for looping and decisions
shapes, expression shape and message assignment shape.

Basic rule for which to use would be: always use a
distinguished field, unless you have to route, track, or
correlate on the source content, then use a property (i.e.
promoted field).

Promoted properties can be accessed in Orchestrations, 
ports, pipelines, schemas.They Use server resources.
Distingished fields are light weight and can be accessed 
only in Orchestrations