3

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.

Zann Anderson
  • 4,767
  • 9
  • 35
  • 56
  • 1
    You've already mentioned my preference, which I can only repeat: any decent production WCF service ought to be self-hosted, in my opinion. IIS and even WAS in IIS 7/7.5 just isn't really a service hosting environment - too many other factors that cause more harm than good. With a NT service, you have total control over protocol and URL's. – marc_s Mar 15 '11 at 21:42

1 Answers1

3

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

Community
  • 1
  • 1
Adam Houldsworth
  • 63,413
  • 11
  • 150
  • 187
  • I agree IIS and especially WAS in IIS 7.5 has its benefit; yet, I would still argue that a) the benefits of self-hosting are **significant** (even just being able to **fully define** your URL's and not being forced into an artificial schema like with IIS/WAS and its virtual dirs), and b) the effort needed to do self-hosting is really **not at all difficult**! A few lines of simple C# code in a NT service (for which you have a VS template) and you're done! – marc_s Mar 15 '11 at 21:51
  • @marc_s definitely self-hosting can be fired up in a 15 minute console job, but a requirement as basic as scalability is not 'simple' to consider when coding the host yourself. This is the trade-off to make. The OP asks about reliability and scalability differences - this entirely depends on your effort in coding the host. My 15 minute console job is not scalable or reliable - the same 15 minutes in IIS gets me that. – Adam Houldsworth Mar 15 '11 at 21:55
  • @Adam - if it really does require more work in order to make things scale with self-hosting, what kind of work? @marc_s, can you speak to what's required for scalability when self-hosting? Also, how much of a performance difference is there, really? Is it significant? Does the overhead of the ServiceHost being spun up and the service class being instantiated make that big of a difference? What about throughput? Is there any significant difference in the number of calls that can be handled one way or the other? – Zann Anderson Mar 15 '11 at 22:02
  • Not sure really, because I think WCF self-hosted still spins up worker threads. This starts to get into a discussion about whether one server is enough etc. For most situations, self-host vs IIS is a semantic discussion, as I inferred in my answer about trying IIS first anyway. For large payloads or heavy traffic, then you'd need to worry about this IMHO. As marc_s mentions, self-host gives you full control, so when you hit an IIS limitation your self-host suddenly looks like golden boy. Are you going to hit those limitations? – Adam Houldsworth Mar 15 '11 at 22:06
  • Unfortunately I do not know WCF with IIS to an in-depth enough degree to tell you exactly where IIS is going to sting you. It sounds like you need to know exactly what is required from your host, and then cross-reference this with what IIS can provide and is known to cause headaches in. I still stand by my first answer about performance, don't worry about it too much before you actually measure it. – Adam Houldsworth Mar 15 '11 at 22:09
  • @Adam, @marc_s, thanks for all the input. I'll do some more searching on where IIS might fall short and whether we'll be likely to bump into those. Also, thanks for the link to the MSDN article - I hadn't seen that one before. – Zann Anderson Mar 15 '11 at 22:27
  • what limitations are you guys talking about when hosting WCF in IIS 7+? I've used both self hosted Windows services and IIS and I can say **without a doubt** I prefer IIS as a host. Process life cycle management, shadow copy dlls (in place update), new **webdeploy** feature, and probably others. I can live with an .svc extension - however, if it bothers too much, then use Url rewrite module or new routing capabilities in WCF 4.0 to get 'pretty' addresses. :) – Zach Bonham Mar 15 '11 at 22:35
  • @Zach Bonham I was just referring to limitations as a catch all under the assumption that it can't do everything :-) I've no idea specifically what they are. It was more to showcase the point that unless you know exactly what they are, you cannot assume you will ever encounter them. – Adam Houldsworth Mar 15 '11 at 22:37
  • @Adam, i believe you have pretty much complete control, especially with IIS7 (IIS6 is more constrained, but still worth looking at). You can create your own host/host factory if you need/want to (e.g. to better integration IoC containers with WCF types). The best part of all, if you *do* hit a wall, you can then fall back to a Windows service and the trivial amount of code to host it (it really is not much). like others mention, target IIS7 and fall back to a service only if necessary. – Zach Bonham Mar 15 '11 at 22:55
  • @Zach cool, thanks for the explanation - "others" would also be me :-) – Adam Houldsworth Mar 15 '11 at 22:57
  • Essentially, the concern is that before my time with the company there have been serious issues with IIS including both performance and reliability problems, so I'm trying to go into this with my eyes wide open as far as what direction to take here. One other thing, I just read about AppFabric. Are any of you familiar with it and is it worth my time to look into? One of the things it claims to provide is, "Simplified deployment and management of WCF and WF services hosted in WAS", which is one of the concerns we have here... – Zann Anderson Mar 15 '11 at 22:57
  • 1
    @Zannjaminderson I'd fire up another question for that - more likely to catch some knowledgeable attention. – Adam Houldsworth Mar 15 '11 at 22:59