Before I begin, I promise I am working on getting my role link example up here.  There was some confusion with server space to upload the example to.

Ok….I know when I first started with BTS’04, it was slightly confusing to me what the whole host/host instance thing was.  A fairly new concept from the previous versions.  But, once the concept sinks in (things take longer for me 😉 ), it’s actually extremely useful.

So, we know that the Host is a “logical container”, and the Instance is the “physical container” for all your adapters, orchestrations, etc.  What can we do armed with this knowledge?  When we’re developing, everything runs under the default BizTalkServerApplication, and life is good.  But, we need to start thinking about production, and how this solution is going to run efficiently, be highly available, and be easily scalable.  This is were hosts and host instances come in.

It is best to decide on your hosts in the very beginning when planning your production environment.  Take a look at the design of your solution, look at the expected message volume, the different methods of receiving and sending messages, service level agreements, and hopefully by now you will have tested some of your design to get an idea of performance.  I find it is much better to create hosts down to the granular level.  By this I mean if you are receiving messages real-time, some as batch, some as file transports, some as HTTP, break your hosts down accordingly.  If you have some orchestrations that perform worse than others (a convoy perhaps), take that into account.  It doesn’t necessarily mean you have to create a host for each one, but lets say you your batch messages take a lot of processing  power…put those in their own host so you can isolate them and not affect your realtime messages.  Breaking your hosts down at a granular level will make it much easier to reconfigure your system once you are stress testing and you find you need to re-shuffle your configuration to increase performance.  This is because once you have your hosts created, and you have configured your adapters, orchestrations, etc to run in those hosts, all you need to do is create a new instance through BizTalk Admin console on whatever server you want it to run on.  Let’s say that you have one instance of your host for batch files on a server (which you wouldn’t do because you want to account for failover also….), and that server is heavily taxed, slowing throughput of all your batch files.  It is very easy to put another server out there, and simply configure a new host instance on it.  If we had not separated our hosts initially, it would be much more difficult to now split out that functionality.

Another good reason to create different hosts is for security reason.  I won’t go into detail here, but remember that hosts can be associated with different windows groups, and host instances can be configured to run as specific accounts.

As you can see, hosts and host instances provide us with load balancing.  BizTalk internally handles load balancing through instances of the host.  If you have instances of a host running on 3 separate servers, then BTS will handle dividing the load amongst the 3 boxes.  If one box were to fail, then the 2 remaining boxes would pick up the slack.  Similarly, if you need to add another box to decrease the load on the current 3, you can just configure a new instance of the host on a server, and BTS will now balance the load between the 4 boxes.

So, remember to seriously think about your hosts early on.  Think in terms of performance, functionality and scalability.  Read the paper on High Availability for BizTalk ’04.