Procedimientos recomendados de hospedaje de Internet Information Services
Este tema describe algunos de los procedimientos recomendados para hospedar servicios de la aplicación Windows Communication Foundation (WCF).
Implementación de servicios WCF como DLL
La implementación de un servicio WCF como una DLL que se implementa en el directorio \bin de una aplicación web permite reutilizar el servicio fuera del modelo de aplicación web, por ejemplo, en un entorno de pruebas que no puede tener implementado Internet Information Services (IIS).
Hosts de servicio de aplicaciones hospedadas en IIS
No use las API imperativas hospedadas automáticamente para crear nuevos hosts de servicio que realicen escuchas en transportes de red que el entorno de hospedaje de IIS no admite de forma nativa (por ejemplo, IIS 6.0 para hospedar servicios TCP, porque la comunicación TCP no se admite de forma nativa en IIS 6.0). No se recomienda este enfoque. Los hosts de servicio creados de manera imperativa no se conocen dentro del entorno de hospedaje de IIS. El punto crítico es que el procesamiento realizado por servicios creados imperativamente no se tiene en cuenta por parte de IIS cuando determina si el grupo de aplicaciones de hospedaje está inactivo. El resultado es que las aplicaciones que tienen hosts de servicio creados de esta manera imperativa tienen un entorno de hospedaje de IIS que elimina de manera agresiva los procesos de host de IIS.
URI y extremos hospedados en IIS
Los puntos de conexión para un servicio hospedado en IIS se deberían configurar utilizando Identificadores uniformes de recursos relativos (URI), no direcciones absolutas. Esto garantiza que la dirección de punto de conexión cae dentro del conjunto de direcciones URI que pertenecen a la aplicación de hospedaje y asegura que la activación basada en mensaje ocurre tal y como se esperaba.
Administración de estado y reciclaje de procesos
El entorno de hospedaje de IIS se optimiza para servicios que no mantienen el estado local en memoria. IIS recicla el proceso del host en respuesta a diversos eventos externos e internos, produciendo que se pierda cualquier estado volátil almacenado exclusivamente en memoria. Los servicios hospedados en IIS deberían almacenar su estado externo al proceso (por ejemplo, en una base de datos) o en una caché en memoria que se puede recrear con facilidad si tiene lugar un evento de reciclaje de aplicación.
Nota
Los protocolos que usa WCF para la confiabilidad y seguridad de la capa de mensajes usan el estado volátil en memoria. Las sesiones confiables y las sesiones de seguridad WCF pueden finalizar inesperadamente debido a reciclajes de la aplicación. Las aplicaciones hospedadas en IIS que usan estos protocolos no deben depender de la clave de sesión que proporciona WCF para correlacionar el estado de la capa de aplicación (por ejemplo, una construcción de la capa de aplicación o un encabezado de correlación personalizado) o deshabilitar el reciclaje de procesos de IIS para la aplicación hospedada.
Optimización del rendimiento en escenarios de nivel medio
Para un rendimiento óptimo en un escenario de nivel medio (un servicio que llama a otros servicios en respuesta a los mensajes entrantes), cree una instancia del cliente de servicio WCF en el servicio remoto una vez y reutilícelo en varias solicitudes entrantes. La creación de instancias de los clientes del servicio WCF es una operación costosa en comparación con la realización de una llamada de servicio en una instancia de un cliente preexistente, y los escenarios de nivel medio generan ganancias de rendimiento distintas mediante el almacenamiento en caché de clientes remotos a través de solicitudes. Los clientes del servicio WCF son seguros para subprocesos, por lo que no es necesario sincronizar el acceso a un cliente a través de varios subprocesos.
Los escenarios de nivel medio también generan ganancias de rendimiento utilizando API asincrónicas generadas por la opción svcutil /a. La opción /a hace que la Herramienta de utilidad de metadatos de ServiceModel (Svcutil.exe) genere métodos BeginXXX/EndXXX para cada operación de servicio, lo que permite realizar llamadas de larga duración a servicios remotos, que se realizarán en subprocesos en segundo plano.
WCF en escenarios multitarjeta o de varios nombres
Puede implementar servicios WCF en una granja de servidores web de IIS, donde un conjunto de equipos comparte un nombre externo común (como http://www.contoso.com), pero los diferentes nombres de host los direccionan de forma individual (por ejemplo, http://www.contoso.com puede dirigir el tráfico a dos máquinas diferentes denominadas http://machine1.internal.contoso.com y http://machine2.internal.contoso.com). WCF admite por completo este escenario de implementación, pero necesita una configuración especial del sitio web de IIS que hospeda los servicios WCF para mostrar el nombre de host correcto (externo) en los metadatos del servicio (lenguaje de descripción de servicios Web).
Para asegurarse de que el nombre de host correcto aparece en los metadatos del servicio que WCF genera, configure la identidad predeterminada para que el sitio web de IIS que hospeda los servicios WCF use un nombre de host explícito. Por ejemplo, los equipos que residen en la granja www.contoso.com deben usar un enlace de sitio de IIS de *:80:www.contoso.com para HTTP y *:443:www.contoso.com para HTTPS.
Puede configurar los enlaces de sitio web de IIS utilizando el complemento de Microsoft Management Console (MMC).
Los grupos de aplicaciones que se ejecutan en contextos de usuario diferentes sobrescriben los ensamblados desde otras cuentas en la carpeta temporal
Para asegurarse de que los grupos de aplicaciones que se ejecutan en diferentes contextos de usuario no puedan sobrescribir los ensamblados desde otras cuentas en la carpeta de archivos ASP.NET temporales, use identidades diferentes y carpetas temporales para las diferentes aplicaciones. Por ejemplo, si tiene dos aplicaciones virtuales /Application1 y / Application2, puede crear dos grupos de aplicaciones, A y B, con dos identidades diferentes. El grupo de aplicaciones A se puede ejecutar bajo una identidad de usuario (user1), mientras que el grupo de aplicaciones B se puede ejecutar bajo otra identidad de usuario (user2) y configurar /Application1 para que use A y /Application2 para que use B.
En Web.config, puede configurar la carpeta temporal mediante <system.web/compilation/@tempFolder>. Para /Application1, puede ser "c:\tempForUser1" y para application2 puede ser "c:\tempForUser2". Conceda el permiso de escritura correspondiente a estas carpetas para las dos identidades.
A continuación, user2 no puede cambiar la carpeta de generación de código para /application2 (bajo c:\tempForUser1).
Habilitar el procesamiento asincrónico
Los mensajes que se envían a un servicio WCF hospedado en IIS 6.0 y versiones anteriores se procesan de forma sincrónica de forma predeterminada. ASP.NET llama a WCF en su propio subproceso (el subproceso de trabajo ASP.NET) y WCF usa otro subproceso para procesar la solicitud. WCF acapara el subproceso de trabajo de ASP.NET hasta que este complete su procesamiento. Esto lleva a un procesamiento sincrónico de las solicitudes. El procesamiento de las solicitudes de forma asincrónica permite una mayor escalabilidad, ya que reduce el número de subprocesos necesarios para procesar una solicitud (WCF no retiene el subproceso ASP.NET mientras está procesando la solicitud). No se recomienda el uso del comportamiento asincrónico en máquinas que ejecuten IIS 6.0, ya que no es posible limitar las solicitudes entrantes que exponen al servidor a ataques por denegación de servicio (DOS). A partir de IIS 7.0, se ha introducido un acelerador de solicitudes simultáneas: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\2.0.50727.0]"MaxConcurrentRequestsPerCpu. Con este nuevo acelerador, el procesamiento asincrónico se puede usar de forma segura. De forma predeterminada en IIS 7.0, se registran el controlador y el módulo asincrónicos. Si se ha deshabilitado, puede habilitar manualmente el procesamiento asincrónico de las solicitudes en el archivo Web.config de la aplicación. La configuración que se use depende de la configuración de aspNetCompatibilityEnabled. Si ha establecido aspNetCompatibilityEnabled en false, configure el objeto System.ServiceModel.Activation.ServiceHttpModule tal y como se muestra en el fragmento de código de configuración siguiente.
<system.serviceModel>
<serviceHostingEnvironment aspNetCompatibilityEnabled="false" />
</system.serviceModel>
<system.webServer>
<modules>
<remove name="ServiceModel"/>
<add name="ServiceModel"
preCondition="integratedMode,runtimeVersionv2.0"
type="System.ServiceModel.Activation.ServiceHttpModule, System.ServiceModel,Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
</modules>
</system.webServer>
Si ha establecido aspNetCompatibilityEnabled en true, configure el objeto System.ServiceModel.Activation.ServiceHttpHandlerFactory tal y como se muestra en el fragmento de código de configuración siguiente.
<system.serviceModel>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
</system.serviceModel>
<system.webServer>
<handlers>
<clear/>
<add name="TestAsyncHttpHandler"
path="*.svc"
verb="*"
type="System.ServiceModel.Activation.ServiceHttpHandlerFactory, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
/>
</handlers>
</system.webServer>