We’re developing a new middle tier for our application suite. We’re looking to rewrite our business logic and data access layers in C#, as they are currently in VB6 and published via COM+.
What we’re trying to decide is how exactly to make this middle tier available to different clients. We’ll be using WCF to do this, and we’ve decided that we’ll use a variety of bindings in order to facilitate each different client’s needs, including a netTcpBinding for our desktop app, a net.Tcp and/or named pipe binding for an internet app running either locally or on a machine within the network, and some flavor of HTTP binding for an external web API.
What we’re trying to decide is how to host our service. It seems like most places I go to say IIS is the way to go, but it seems like you’d get better performance out of the BLL/DAL portion of it if it was under a Windows Service, and @marc_s here on SO seems to recommend self-hosting more often than not. So do we host it under IIS, under a service, or some hybrid where perhaps a thin service is hosted in IIS for the HTTP endpoint and consumes the main service via a net.tcp or named pipe binding? Separating it out allows for there to be a physical separation if desired, as well as allowing for the possibility of IIS going down, which would still leave the service running for those clients that access the endpoints it publishes.
Also, what about scalability and reliability? Is there much difference between the two hosting environments that way?
I realize there’s a lot of questions similar to this, but I haven’t been able to find quite the information I’ve been looking for, so links to more concrete help work just as well as an answer.
Reading this answer would seem to suggest that self-hosting is marc_s’s preference based on accepting the overhead in coding the host yourself:
IIS WCF service hosting vs Windows Service
IIS gives you a lot of stuff for free. I would say considering this beforehand is not a bad idea, but nothing is better than measuring performance metrics to get the cold, hard facts about what is best for your solution.
Try IIS and if it’s really that poor, create your own host. It’s not exactly expensive to get it going in IIS – and there are some tuning tips around the web.
Update: posted this just after marc_s commented. I agree in principle, but doing the hosting yourself could prove to be overhead for no benefit. IIS is out of the box to some degree, and has it’s limitations – limitations you may never encounter.
I’m unsure of the relevance of this feedback, but we use IIS to host .NET Remoting objects for our application. It is currently going through quite a considerable performance metric gathering process in preparation for a near factor of 10 scale up due to a new client. For us, IIS has not been identified as anything worth worrying about. About the only sticking point people have is that it is over HTTP (older IIS version for us), so is a little more message-heavy as opposed to TCP perhaps.
Update: this MSDN article touches upon self-hosting and discusses some points to consider:
http://msdn.microsoft.com/en-us/library/bb332338.aspx#msdnwcfhc_topic3