Deploying separate or multiple WCF services for each IIS application?
I am at the center of an internal discussion about IIS hosting. For a given enterprise application, we have N WCF services.
One option is to host each WCF service in its own IIS application. This means that each service has its own web.config and [possibly] its own application pool.
Another option is to hose all WCF services in one IIS application. This means one web.config for all these services and one application pool.
The custom option gives you the flexibility to customize different configurations (IIS and web.config) for each service. Individual application pools will allow more granular control over process reset.
The general option is simpler and possible because the IIS and application configuration (web.config) must be the same for each service.
I am looking for advice / best practice between these two options.
source to share
Working in the same type of corporate environment as the one you are describing, we find the best practice to be:
-
Group similar functionality into Applications, which are then hosted under a single WCF service. This gives us for example. CustomerService, AccountsService, etc.
-
Each service has its own application. Domain to provide separation of process and separation of security with other services. That is, each service runs in the context of an ActiveDiretory (AD) account, and this allows us to enforce the security of downstream resources, such as SQL Server databases.
eg. CustomerService runs under DOMAIN \ CustomerServiceUser. We can then secure, for example, stored procedures associated with customer functions so that they can only be executed by the CustomerServiceUser. We can then use integrated protection for our connection to the SQL server. This allows you to manage enterprise-level permissions at the Active Directory level.
- We deploy scripts for both the IIS configuration and our web.config files. This has the advantage that IIS configuration can also be kept in source control as well as transform files for our web.config files. Then we have the full version history or our configuration and can additionally use this to quickly deploy additional machines if we decide to duplicate and load the balance of services.
This is what we consider to be best practice, although your organization's requirements may vary.
source to share