Procedimientos recomendados de hospedaje de Internet Information Services
En este tema se describen algunos procedimientos recomendados para hospedar los servicios de Windows Communication Foundation (WCF).
Implementación de servicios WCF como DLL
Implementar un servicio de 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 implantad Internet Information Services (IIS).
Hosts de servicio de aplicaciones hospedadas en IIS
No utilice las mismas API de host imperativas para crear nuevos hosts de servicio que realicen escuchas en transportes de red no admitidos nativamente por el entorno de hospedaje de IIS (por ejemplo, IIS 6.0 para hospedar servicios TCP, porque la comunicación TCP no se admite de manera nativa en IIS 6.0). Éste enfoque no se recomienda. Los hosts del 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 servicios 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 extremos 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 extremo 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 una variedad de 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 WCF utiliza para la confiabilidad del nivel de mensaje y seguridad utilizan el estado en memoria volátil. Las sesiones confiables y de seguridad de WCF pueden finalizarse de manera inesperada debido a reciclajes de las aplicaciones. Las aplicaciones hospedadas en IIS que hacen uso de estos protocolos no deberían depender de la clave de sesión proporcionada por WCF para correlacionar el estado de nivel de aplicación (por ejemplo, una construcción del nivel 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 de WCF para el servicio remoto una vez y reutilícelo en varias solicitudes entrantes. Crear instancias de los clientes del servicio de WCF es una operación costosa relativa a hacer una llamada de servicio en una instancia de un cliente preexistente, y los escenarios de nivel medio generan ganancias de rendimiento distintas almacenando en memoria caché los clientes remotos de las solicitudes. Los clientes del servicio de WCF son seguros para subprocesos, por lo que no es necesario sincronizar el acceso a un cliente en 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 ServiceModel Metadata Utility Tool (Svcutil.exe) genere métodos BeginXXX/EndXXX para cada operación del servicio, que permite llamadas potencialmente de ejecución prolongada para los servicios remotos, que se van a realizar en subprocesos de fondo.
WCF en escenarios multitarjeta o de varios nombres
Puede implementar servicios de WCF dentro de una granja de servidores web de IIS, donde un conjunto de equipos comparte un nombre externo común (como https://www.contoso.com) pero son direccionados individualmente por nombres de host diferentes (por ejemplo, https://www.contoso.com podría dirigir el tráfico a dos equipos diferentes denominados (http://machine1.internal.contoso.com y http://machine2.internal.contoso.com). WCFadmite totalmente este escenario de implementación, pero requiere una configuración especial del sitio web de IIS que hospeda los servicios de WCF para mostrar el nombre del host correcto (externo) en los metadatos del servicio (lenguaje de descripción de servicios web).
Para asegurarse de que el nombre del host correcto aparece en los metadatos de servicio que WCF genera, configure la identidad predeterminada para que el sitio web de IIS que hospeda los servicios de WCF utilice un nombre de host explícito. Por ejemplo, los equipos que residen dentro de la granja www.contoso.com deberían utilizar 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 pueden sobrescribir los ensamblados desde otras cuentas en la carpeta de archivos ASP.NET temporales, utilice identidades diferentes y carpetas temporales para las aplicaciones diferentes. 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).