Hosted Service Shutdown

I've talked a bit in the past about the tradeoffs of using IIS to host your service applications. In order to use IIS as a host, you must give up some level of control about how your application functions. This is similarly true with any other host you might imagine, even if we use host in a broader sense than just WCF services, such as with SQL Server. By selecting a host, you exchange control over certain aspects in your application in return for getting certain services for free. For example, IIS gives you a configuration model, tooling, health management, process activation, and other services. A service hosted inside of a Windows process might receive a different set of benefits.

In order to make a good selection of a host, you have to understand these tradeoffs and be able to apply them to your application scenario to make a hosting decision. As an example, consider the aspect of service lifetime. When you host a service application in IIS, you give up some control over when the service is stopped, started, and executed. Your service will be activated by message arrivals. Your service may be stopped at any time based on the needs of the host, such as due to a lack of available memory, a lack of recent activity, or because of receiving a certain number of requests. These service shutdowns may or may not be predictable to you or give you an opportunity to react to them.

A service that stops and starts at times necessitates a different strategy of design than a service that runs all of the time. A process that is long-running but intermittent needs to have some way to persist progress so that starting and stopping does not lose important work. A process that is continuously long-running might have different concerns, such as remaining extremely stable and carefully cleaning up resources. Both strategies can lead to the same goal and there's no reason to believe that there has to be a significant difference in performance or latency between the two. However, the two strategies are very different and very much aligned to different hosting models.

When you commit to using a particular host with your application, you should take some time to understand how your application can best be adapted to the host's expectations. Similarly, when you are designing an application before committing to using a particular host, you should understand what the important constraints are for each of the hosts that you are considering. This obviously requires some planning to have a candidate list of hosts and understand their tradeoffs. The return on that investment comes once the host is selected and you find that your application needs few modifications to work well with the host.

Next time: No Choice for Data Contracts

Comments

• Anonymous
  September 23, 2008
  Every time you open a connection to another machine you need to have a port both at the local machine

• Anonymous
  September 24, 2008
  It's great that you mention that. I've been looking for resources in this topic for a while now, but found nothing. Most people just ignore process recycling (they hope their background thread would finish in time) or recomend disabling it (although IIS has much more reasons to recycle). Could you point to some other sources of information? I'm particularly interested in hosting under WAS and some pattern for persisting processes, or broader analisys of "things to consider" when implementing such designs. 10x in advance!