Should I host my WCF service in IIS?

Question

So I'm designing a WCF service. I'm unexperienced with WCF, and I'm trying to decide whether it should be hosted in IIS, or a custom Windows service.. Or some other option?

Things to consider:

• It needs to load data from a database on startup.
• It needs to maintain this data across requests, not load it each time.
• It needs to process multiple requests simultaneously.
• It needs to be as configurable as possible regarding endpoints.
• It will be calling native dlls quite a lot.

I suspect hosting it in IIS would simplify certain things, but I'm not sure it would be a good idea in this situation.

What are my options, and what are their pros and cons?

Answer 1

You need to basically look at three options:

1) Hosting in IIS6 (Windows Server 2003/2003 R2): in this scenario, you can only host HTTP protocols - nothing else. This is quite a limitation in itself, you cannot use e.g. netTcp for Intranet scenarios.

2) Hosting in IIS7 / WAS (Vista, Server 2008): this gives you more option in terms of protocols supported, and the hosting environment looks like a winner at first.

3) Self-hosting: in this scenario, it's totally up to you to do whatever you need to do to host and run your services.

If you throw out option #1 for now (if you only have IIS6 available, I'd always use self-hosting), it's down to IIS7 vs. self-hosting.

IIS7 gives you "activation on demand", e.g. your service code is not in memory at all times, but will be loaded and instantiated once a request comes in. That can be a plus.

On the other hand, hosting in IIS7/WAS robs you of the ability to specify your own endpoints - your endpoint and thus service address is the virtual directory where your "MyService.svc" file lives - period. You cannot change that in any way, shape or form.

Self-hosting might look like a lot of work - but it does give you the best flexibility: you can pick your protocols as you like, you can set up your own addressing scheme the way you like it, and you have total control over what gets done when. You can introduce your own custom ServiceHost if you need to do some extra work to host services, and so on.

Unless you're just playing around with WCF a bit, I would always recommend and vote for self-hosting - if you need to have the WCF service running at all times, inside a Windows NT Service (that's the best solution for production environments), and if you're developing/debugging, you can totally host your WCF services in a console app which you can launch and stop at your leisure.

So to make a long story short: in the end, if you really want control over what's happening, I would always recommend self-hosting.

This might change once the new "Dublin" Server-Addon by Microsoft comes out - sometime after .NET 4 is launched, probably early in 2010 - but that's still too early to tell.

Hope this helps.

Marc

Answer 2

I prefer self hosted services myself (Windows service). With that said there are valid reasons for going either way.

There are some valuable articles in MSDN regarding different WCF hosting strategies.

Here is a good summary of why you might choose to use IIS as your service host.

Answer 3

I would say that without IIS7 and WAS you cannot host anything but HTTP based endpoints using IIS. As such you would most likely want to self host for flexibility.

As for your data considerations, any service can be coded with state such that data is cached etc.

Multiple requests will require you to use WCF concurrency. You want to set attributes on your service host:

[System.ServiceModel.ServiceBehavior(UseSynchronizationContext = false,
    InstanceContextMode = System.ServiceModel.InstanceContextMode.PerCall,
    ConcurrencyMode = System.ServiceModel.ConcurrencyMode.Multiple)]
public class MyService : IMyService
{
}

WCF is a big beast, I recommend you have a look at Juval Lowy's book and anything else you can get your hands on, you will not learn it in a day.