Servicios WCF y ASP.NET

En este tema se tratan los servicios de hospedaje de Windows Communication Foundation (WCF) en paralelo con ASP.NET y el hospedaje de ellos en el modo de compatibilidad de ASP.NET.

Hospedaje de WCF en paralelo con ASP.NET

Los servicios de WCF hospedados en Internet Information Services (IIS) se pueden encontrar con páginas .ASPX y servicios Web ASMX dentro de un dominio de aplicación común e individual. ASP.NET proporciona servicios de infraestructura común como administración de Appdomain y compilación dinámica en tiempo de ejecución de HTTP de ASP.NET e WCF. La configuración predeterminada para WCF es en paralelo con ASP.NET.

El tiempo de ejecución de HTTP de ASP.NET controla las solicitudes de ASP.NET, pero no participa en el procesamiento de solicitudes destinadas a servicios de WCF, aunque estos servicios se hospeden en el mismo Appdomain que el contenido de ASP.NET. En su lugar, el modelo de servicios de WCF intercepta los mensajes direccionados a los servicios WCF y los enruta a través de la pila de transporte/canal de WCF.

Los resultados del modelo en paralelo son de la siguiente manera:

• Los servicios de ASP.NET e WCF pueden compartir el estado del Appdomain. Dado que los dos marcos pueden coexistir en el mismo Appdomain, WCF también pueden compartir el estado del Appdomain con ASP.NET (incluidas las variables estáticas, los eventos, etc.).

• Los servicios de WCF se comportan de forma coherente, independientemente del entorno de hospedaje y del transporte. El tiempo de ejecución de HTTP de ASP.NET se acopla de manera intencionada al entorno de hospedaje de IIS/ASP.NET y a la comunicación HTTP. De manera inversa, WCF está diseñado para comportarse de forma consistente en diferentes entornos de hospedaje (WCF se comporta de forma consistente dentro y fuera de IIS) y transportes (un servicio hospedado en IIS 7.0 tiene un comportamiento coherente en todos los extremos que expone, incluso aunque algunos de esos extremos utilicen protocolos distintos de HTTP).

• Dentro de un Appdomain, las características implementadas por el tiempo de ejecución de HTTP se aplican al contenido de ASP.NET pero no a WCF. Muchas características específicas de HTTP de la plataforma de aplicaciones de ASP.NET no se aplican a los servicios de WCF hospedados dentro de un Appdomain que incluya contenido de ASP.NET. Ejemplos de estas características incluyen lo siguiente:

  • HttpContext: el valor de propiedad Current siempre es null cuando se obtiene acceso a ella desde un servicio de WCF. Use la clase RequestContext en su lugar.

  • Autorización basada en archivos: el modelo de seguridad de WCF no permite la lista de control de acceso (ACL) aplicada al archivo .svc del servicio a la hora de decidir si se autoriza una solicitud de servicio.

  • Autorización de URL basada en configuración: de forma similar, el modelo de seguridad de WCF no se adhiere a ninguna regla de autorización basada en URL especificada en el elemento de configuración <authorization> de System.Web. Estos valores se pasan por alto para solicitudes de WCF si un servicio reside en un espacio de direcciones URL protegido por reglas de autorización de URL de ASP.NET.

  • Extensibilidad de HttpModule: la infraestructura de hospedaje de WCF intercepta las solicitudes de WCF cuando se genera el evento PostAuthenticateRequest y no devuelve el procesamiento a la canalización HTTP de ASP.NET. Los módulos que están codificados para interceptar las solicitudes en fases posteriores de la canalización no interceptan las solicitudes de WCF.

  • Suplantación de ASP.NET: de forma predeterminada, las solicitudes de WCF siempre se ejecutan con la identidad de proceso de IIS, aun cuando ASP.NET se configura para permitir la suplantación mediante la opción de configuración <identity impersonate=”true” /> de System.Web.

Estas restricciones solo se aplican a los servicios de WCF hospedados en la aplicación de IIS. La presencia de WCFno afecta al comportamiento del contenido de ASP.NET.

Las aplicaciones de WCF que requieren la funcionalidad que proporciona tradicionalmente la canalización HTTP deberían considerar la posibilidad de usar equivalentes de WCF, que no dependen del host ni del transporte:

• OperationContext en lugar de HttpContext.

• ServiceAuthorizationBehavior en lugar de la autorización de archivo/URL de ASP.NET.

• IDispatchMessageInspector o los canales dispuestos en capas personalizados en lugar de los módulos HTTP.

• Suplantación para cada operación utilizando WCF en lugar de la suplantación de System.Web.

De manera alternativa, puede considerar ejecutar sus servicios en el modo de compatibilidad ASP.NET de WCF.

Hospedaje de servicios de WCF en el modo de compatibilidad de ASP.NET

Aunque el modelo de WCF está diseñado para comportarse de forma coherente en los diferentes entornos de hospedaje y transportes, a menudo hay escenarios en los que una aplicación no requiere este grado de flexibilidad. El modo de compatibilidad de ASP.NET de WCF es conveniente para escenarios que no requieren la capacidad de hospedar fuera de IIS ni de comunicarse sobre protocolos que no sean HTTP, pero que usan todas las características de la plataforma de aplicaciones web ASP.NET.

A diferencia de la configuración en paralelo predeterminada, donde la infraestructura de hospedaje de WCF intercepta los mensajes de WCF y los enruta fuera de la canalización HTTP, los servicios de WCF que se ejecutan en modo de compatibilidad de ASP.NET participan totalmente en el ciclo de vida de la solicitud HTTP de ASP.NET. En el modo de compatibilidad, los servicios de WCF utilizan la canalización HTTP a través de una implementación IHttpHandler, de manera similar a la forma en que se tratan las solicitudes de páginas ASPX y servicios Web ASMX. Como resultado, WCF se comporta de manera idéntica a ASMX con respecto a las siguientes características de ASP.NET:

• HttpContext: los servicios de WCF que se ejecutan en modo de compatibilidad de ASP.NET pueden tener acceso a Current y a su estado asociado.

• Autorización basada en archivo: los servicios de WCF que se ejecutan en modo de compatibilidad de ASP.NET pueden ser seguros si se asocian las listas de control de acceso (ACL) del sistema de archivos al archivo .svc del servicio.

• Autorización de URL configurable: las reglas de autorización de URL de ASP.NET se aplican para las solicitudes de WCF cuando el servicio de WCF se está ejecutando en modo de compatibilidad de ASP.NET.

• Extensibilidad deHttpModuleCollection: dado que los servicios de WCF que se ejecutan en modo de compatibilidad de ASP.NET participan totalmente en el ciclo de vida de la solicitud HTTP de ASP.NET, cualquier módulo HTTP configurado en la canalización HTTP puede funcionar en solicitudes de WCF antes de y después de la invocación del servicio.

• Suplantación de ASP.NET: los servicios de WCF se ejecutan utilizando la identidad actual del subproceso ASP.NET suplantado, que puede diferir de la identidad de proceso de IIS si se ha habilitado la suplantación de ASP.NET de la aplicación. Si se habilitan la suplantación de ASP.NET y la de WCF para una operación de servicio determinada, la implementación del servicio se ejecuta finalmente utilizando la identidad obtenida de WCF.

El modo de compatibilidad de ASP.NET de WCF se habilita en el nivel de la aplicación a través de la siguiente configuración (ubicada en el archivo Web.config de la aplicación):

    <system.serviceModel>        <serviceHostingEnvironment aspNetCompatibilityEnabled="true" />    </system.serviceModel>

Este valor, si no se especifica, es "false" de manera predeterminada. Al establecer este valor en "true", se indica que todos los servicios de WCF que se ejecuten en la aplicación lo hacen en el modo de compatibilidad de ASP.NET.

Dado que el modo de compatibilidad de ASP.NET implica una semántica de procesamiento de solicitudes diferente de la predeterminada de WCF, las implementaciones de servicios individuales tienen la capacidad de controlar si se ejecutan dentro de una aplicación para la que se ha habilitado el modo de compatibilidad de ASP.NET. Los servicios pueden utilizar el AspNetCompatibilityRequirementsAttribute para indicar si admiten el modo de compatibilidad de ASP.NET.

[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Required)]

public class CalculatorService : ICalculatorSession

{//Implement calculator service methods.}

La siguiente tabla muestra cómo el valor del modo de compatibilidad de toda la aplicación interactúa con el nivel expresado de compatibilidad del servicio individual:

Valor de modo de compatibilidad de la aplicación	[AspNetCompatibilityRequirementsMode] Configuración	Resultado observado
aspNetCompatibilityEnabled = “true”	Required	El servicio se activa correctamente.
aspNetCompatibilityEnabled = “true”	Allowed	El servicio se activa correctamente.
aspNetCompatibilityEnabled = “true”	NotAllowed	Se produce un error de activación cuando el servicio recibe un mensaje.
aspNetCompatibilityEnabled = “false”	Required	Se produce un error de activación cuando el servicio recibe un mensaje.
aspNetCompatibilityEnabled = “false”	Allowed	El servicio se activa correctamente.
aspNetCompatibilityEnabled = “false”	NotAllowed	El servicio se activa correctamente.

Nota:
IIS 7.0 y WAS permite a los servicios de WCF comunicarse a través de protocolos que no sean HTTP. Sin embargo, no se permite a los servicios de WCF que se ejecutan en aplicaciones que han habilitado el modo de compatibilidad de ASP.NET exponer extremos que no sean HTTP. Este tipo de configuración genera una excepción de activación cuando el servicio recibe su primer mensaje.

Para obtener más información sobre cómo habilitar el modo de compatibilidad de ASP.NET para los servicios de WCF, vea AspNetCompatibilityRequirementsMode.

Vea también

Referencia

AspNetCompatibilityRequirementsAttribute

Otros recursos

Características de hospedaje de Windows Server App Fabric