Servicios WCF y ASP.NET

En este tema se describe cómo hospedar servicios de Windows Communication Foundation (WCF) en paralelo con ASP.NET y hacerlo en modo de compatibilidad de ASP.NET.

Hospedaje de WCF en paralelo con ASP.NET

Los servicios WCF hospedados en Internet Information Services (IIS) se pueden encontrar con páginas .ASPX y servicios web ASMX dentro de un único dominio de aplicación común. ASP.NET proporciona servicios de infraestructura comunes, como la administración de AppDomain y la compilación dinámica para WCF y el runtime HTTP de ASP.NET. La configuración predeterminada de WCF está en paralelo con ASP.NET.

El runtime HTTP de ASP.NET controla las solicitudes de ASP.NET, pero no participa en el procesamiento de solicitudes destinadas a los servicios WCF, aunque estos servicios se hospeden en el mismo AppDomain que el contenido de ASP.NET. En su lugar, el modelo de servicios WCF intercepta los mensajes dirigidos a los servicios WCF y los enruta mediante la pila de canales y transporte de WCF.

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

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

• Los servicios WCF se comportan de forma coherente, independientemente del entorno de hospedaje y el 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. Por el contrario, WCF está diseñado para comportarse de forma coherente en entornos de hospedaje (WCF se comporta de forma coherente tanto dentro como fuera de IIS) y en el transporte (un servicio hospedado en IIS 7.0 y versiones posteriores tiene un comportamiento coherente en todos los puntos de conexión que expone, incluso si algunos de esos puntos de conexión usan protocolos distintos de HTTP).

• Dentro de un AppDomain, las características que implementa el runtime 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 WCF hospedados dentro de un AppDomain que contiene contenido de ASP.NET. Ejemplos de estas características incluyen lo siguiente:

  • HttpContext: Current siempre es null cuando se accede desde un servicio WCF. En su lugar, use RequestContext.

  • 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 que protegen reglas de autorización de URL de ASP.NET.

  • Extensibilidad de HttpModule: la infraestructura de hospedaje de WCF intercepta las solicitudes de W 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 manera 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 WCF hospedados en la aplicación de IIS. La presencia de WCF no afecta al comportamiento del contenido de ASP.NET.

Las aplicaciones de WCF que requieren la función 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.

Como alternativa, puede considerar la posibilidad de ejecutar los servicios en el modo de compatibilidad ASP.NET de WCF.

Hospedaje de servicios 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 nivel 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 mediante 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 forma idéntica a ASMX con respecto a las siguientes características de ASP.NET:

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

• Autorización basada en archivo: los servicios 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 dirección URL configurable: las reglas de autorización de direcciones URL de ASP.NET se aplican para las solicitudes de WCF cuando el servicio WCF se ejecuta en modo de compatibilidad de ASP.NET.

• Extensibilidad de HttpModuleCollection: dado que los servicios 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 la invocación del servicio y después de esta.

• Suplantación de ASP.NET: los servicios WCF se ejecutan mediante 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 mediante 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. El valor de false indica que todos los servicios WCF que se ejecutan en la aplicación no se ejecutarán en 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. El valor predeterminado para este atributo es Allowed.

[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
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 permiten a los servicios WCF comunicarse a través de protocolos distintos de HTTP. Pero los servicios WCF que se ejecutan en aplicaciones que han habilitado el modo de compatibilidad de ASP.NET no pueden exponer puntos de conexión que no sean HTTP. Este tipo de configuración genera una excepción de activación cuando el servicio recibe su primer mensaje.

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

Consulte también

• AspNetCompatibilityRequirementsAttribute
• Características de hospedaje de Windows Server AppFabric