Iis Wcf Service Hosting VS Windows Service

WCF: Difference between hosting in IIS and WIndows service

Check out the documentation: https://msdn.microsoft.com/en-us/library/ms730158%28v=vs.110%29.aspx

It is awesome!

And the answer to your questions depends on what kind of application you are building and other requirements on the application/environment...!

IIS WCF service hosting vs Windows Service

To answer at those question :

We ran some tests and we found out
that when we're adding bindings in
IIS, it doesn't update config file of
our service. That means that we would
need to maintain the configuration in
two different places. It's not logic,
right ?

When you use IIS to host your service, you must configure your App.config file or web.config file to allow IIS to expose some binding, so in your configuration file, you will put all your binding you allow to your wcf service. Http, net.tcp etc...

In your binding you will not specified address, because you will specified those address in IIS directly.

In IIS you must allow the binding available in the advanced settings of your web site. After that you will set new binding for your web site "web service" and add every bindings you want listen, and specify the address.

You will specify the address directly in IIS.

There's an example.

Your configuration file:

<services>
    <service name="ServiceName">                    
        <endpoint address=""
            binding="basicHttpBinding"
            bindingConfiguration="httpMode"
            contract="IContract" />                 
        <endpoint address=""
            binding="netTcpBinding"
            contract="IContract" />
        <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
    </service>
</services>

In your IIS advenced setting your will put

http,net.tcp in Enabled Protocols

After that you will go in your binding into IIS. Put your binding for http normaly and add a new binding net.tcp, in the binding configuration put the port and virtual directory like

8001:*

This setting allow all connection into the 8001 port for any virtual directory.

You also must to have the feature "WCF Activation, (Http activation and Non-Http Activation)" installed on your server.

Hosting WCF in IIS 7.5 vs Windows Service for Performance Considerations

With the release of AppFabric for IIS, hosting WCF services on IIS 7.5 have gotten a bit easier and more reliable. AppFabric allows you to configure services to start up on application pool start and prevent the pool from recycling like a normal web application. It also provides methods to allow your WCF service to log information about its health and monitor the service.

For my most recent WCF project, I've gone with ASP.Net 4 and AppFabric with .svc extensions for hosting the code. (Currently, AppFabric has issues monitoring services that are routed - so an .svc file is required)

Here are a couple more useful links about WCF and AppFabric:

• Monitoring your WCF services with AppFabric
• AppFabric-enabled WCF Data Service Walkthrough (C#)

Another advantage I've seen in the IIS method is it allows you to create pages next to it to help monitor, maintain, and configure the services. With a Windows Service you have to either edit your config files by hand or create an application to handle it for you. The ability to host WCF next to WebForms/MVC applications for management is a huge plus in my book. Obviously, you'd need to make sure it's secured in some way to prevent others from peering in and seeing the status/configuring it.

Hosting the same WCF Service in IIS and in Windows Service

A WCF service is simply an assembly that abides by the WCF hosting interface and then provides a client interface that allows it to be accessed.

Hosting a WCF service occurs equally in IIS, Windows service, WinForm application, or a console application. It truly doesn't matter.

The client interface remains unchanged, although how the interface is exposed might change depending on hosting scenario. For example, you'll probably use one the http bindings in the IIS case, but might use TCP binding for Windows services. These bindings can be defined in the config file, so the code doesn't necessarily have to change to accommodate being hosted one way or the other.

In short, creating the WCF service should be independent of how it will eventually be hosted. For ease of maintenance on your part, though, I'd pick one or the other - Windows service or IIS.

Windows Service vs Hosted WCF Service

I do not fully understand the point why a windows service should be used on the client side in order to communicate with the WCF service. But the question was not about architectural patterns...

So, for inter-process communication I would use NetNamedPipeBinding.
You can find more information on how to decide which binding to use here.

Using a WCF service for inter-process communication does not feel overkill to me at all. Actually WCF services are quite lightweight except the host initialization process, which should not happen frequently in case of a windows service I guess. WCF provides reliability and extensibility in exchange for this tiny inconvenience.

[EDITED]

I just reread you post, and I would like to clarify some details about the hosting. You can host a WCF service in a Windows Service, which is explained here, but not the other way around. Sorry, if I misunderstood your question. And yes, TCP/IP for inter-process communication is definitely an overkill, but NetNamedPipeBinding uses shared memory according to this article, so it should be the fastest way.

WAS hosting vs. Windows Service hosting

Recently I had to answer very similar question and these are the reasons why I decided to use IIS 7.0 and WAS instead of Windows Service infrastructure.

1. IIS 7.0 is much more robust host and it comes with numerous features that make debugging easy. Failed requests tracing, worker process recycling, process orphaning to name a few.
2. IIS 7.0 gives you more option to specify what should happen with the worker process in certain circumstances.
3. If you host your service under IIS it doesn't have a worker process assigned to it until the very first request. This is something that was a desired behaviour from my perspective but it might be different in your case. Windows Service gives you the ability to start your service in a more deterministic way.
4. From my experience WAS itself doesn't provide increased reliability. It's biggest advantage is that it exposes the richness of IIS to applications that use protocols different than HTTP. By different I mean: TCP, named pipes and MSMQ.
5. The only disadvantage of using WAS that I'm aware of is that the address your service is exposed at needs to be compliant with some sort of pattern. How it looks like in case of MSMQ is described here

---

Related Topics