Las agrupaciones de aplicaciones IIS ejecutan un único proceso de trabajo (de forma predeterminada). Dentro de ese proceso de trabajo, se crea un AppDomain para cada aplicación de IIS (sitio web). Hasta donde yo sé, cualquier código que se ejecute dentro de esa aplicación IIS se ejecutará en el mismo AppDomain (a menos que, por supuesto, esté creando sus propios dominios de aplicación secundarios en el código). Puede ajustar el número de procesos de trabajo por sitio web, pero solo realísticamente haga esto si descubre que tiene problemas de rendimiento (que no pueden resolverse mediante la segregación de los grupos de aplicaciones). Si ejecuta varios dominios de aplicaciones por sitio web, el código que se ejecuta en esos dominios de aplicaciones separados no puede compartir estado (por ejemplo, la sesión InProc), y solo se puede comunicar a través de la serialización, lo que no es ideal.
En lo que respecta a ASP.NET y WCF; cuando se alojan en IIS, se ejecutan de forma predeterminada en modo paralelo, dentro del mismo AppDomain, esto les permite compartir el estado, pero las solicitudes WCF no son procesadas por el tiempo de ejecución ASP.NET, en cambio las llamadas a servicios WCF son interceptadas y procesadas por el tiempo de ejecución WCF. (Aunque las llamadas a los archivos .svc todavía se enrutan a través de ASP.NET inicialmente). En el modo lado a lado, las llamadas WCF no obedecen a la configuración, seguridad, suplantación, etc. que puede haber configurado para su sitio web ASP.NET.
WCF en IIS también se puede ejecutar en el modo de compatibilidad ASP.NET, en el que la implementación de WCF se gestiona mediante un controlador http y, por lo tanto, también se procesa mediante la interconexión ASP.NET. Si considera que sus servicios solo necesitan soporte HTTP, podría considerar alojar el servicio en modo de compatibilidad para obtener acceso a la potencia y flexibilidad de la canalización de ASP.NET.
En lo que respecta al modo de canalización integrada y clásica, en modo integrado, ASP.NET se ejecuta con el w3wp.exe como una parte integrada de la canalización de proceso de IIS. Esto significa que cualquier cosa que use controladores personalizados, etc., que pueda haber conectado a la canalización (incluso cuando se sirve contenido que no sea de ASP.NET, por ejemplo, PHP), se cargará y ejecutará en el mismo AppDomain.
En modo clásico, ASP.NET se ejecuta en su proceso de trabajador propietario, aspnet_wp.exe, y está conectado a la interconexión de proceso de IIS como un filtro ISAPI. Creo que la misma mecánica alrededor del uso de AppDomain se aplica aquí también.
Servicio web WCF o ASP .NET? – Jeff