Deploying Multiple WCF Services In Same IIS Virtual Directory
in [Dot Net]
|
Prev: Help regarding programatically generating CSR
Next: The new EC2Studio allows working with several Amazon EC2 Accounts.
From: Allan.Iverson on 17 Dec 2009 18:13 I'm responsible for helping .NET developers at a Fortune 100 company and I have a general question. Recently a team of .NET developers created a intranet WPF Browser application and 4 distinct WCF services that support requirements of that application. Each WCF service has multiple web methods and overall each service appears to be a coherent entity from a functional perspective. However the team implemented all four services in a single Visual Studio 2008 project. So that project has four .SVC files, four managed assemblies, four unique service contracts and a single shared web.config for storing bindings, endpoints, etc. While technically this should work fine it's not the way that I would have structured the overall projects solution. Note: We host all of our WCF services in IIS 6.0, and will be moving soon to IIS 7.0. We also have in place an automated build and deployment process that basically was architected to deploy each Visual Studio Web Type project to it's own virtual directory, so seperating the services during deployment is not something we can easily do. Here are some of the drawback I see to this approach: 1.) Multiple .SVC files precludes specifying a default document to be served up when clients browse to the services virtual directory. 2.) As our .NET IIS deployment standard calls for creating a specific application pool for each virtual directory, having multiple WCF services in the same virtual directory needlessly couples the services, should one service misbehave, and we have to recycle the app pool. 3.) Having a single web.config file governing four WCF Services, by necessity is more complex, than having a single web.config file for each service. This would increase the chances that a misconfiguration in this file would affect four services at runtime as opposed to only one. We could mitigate the clutter by sourcing into the web.config seperate stanzas for each specific web service configuration but that still doesn't remove the runtime dependencies forced by a single web.config file. While I certainly don't think this approach would be even close to a 'Best Practice' I'm reluctant to force the team to refactor each WCF service into it's own individual project. I'm looking for any comments or insights members can supply to help me make a more informed decision. |