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
Read More...