Novedades de Windows Communication Foundation
En este tema, se describen las características nuevas de Windows Communication Foundation (WCF).
Activación basada en la configuración
Normalmente, al hospedar un servicio de Windows Communication Foundation (WCF) en Internet Information Services (IIS) o el Servicio de activación de procesos de Windows (WAS), debe proporcionar un archivo .svc. El archivo .svc contiene el nombre del servicio y un generador de host de servicio personalizado opcional. Este archivo adicional agrega una sobrecarga de administración. La característica de activación basada en la configuración elimina la necesidad de tener un archivo .svc y, por lo tanto, la sobrecarga asociada. Para obtener más información, vea Activación basada en la configuración en IIS y WAS, Activación basada en la configuración.
Integración de System.Web.Routing
Al hospedar un servicio Windows Communication Foundation (WCF) en IIS, debe colocar un archivo .svc en el directorio virtual. Este archivo .svc especifica el generador de host de servicio que se debe usar, así como la clase que implementa el servicio. Al realizar solicitudes al servicio, debe especificar el archivo .svc en el URI, por ejemplo: https://contoso.com/ServicioDeEmpleados.svc. Para programadores que escriben servicios de REST, este tipo de URI no es óptimo. Los URI para los servicios de REST especifican un recurso determinado y normalmente no tienen ninguna extensión. La característica de integración de System.Web.Routing le permite hospedar un servicio de WCF que responde a los URI sin extensión. Para obtener más información, vea Integración de System.Web.Routing, Ejemplo de integración de SystemWebRouting.
Compatibilidad con varios enlaces de sitios de IIS
Al hospedar un servicio de Windows Communication Foundation (WCF) en Internet Information Services (IIS) 7.0, puede que desee proporcionar varias direcciones base que usen el mismo protocolo en el mismo sitio. Esto permite que el mismo servicio responda a varios URI diferentes. Esto es útil si desea hospedar un servicio que realiza escuchas en https://www.contoso.com y https://contoso.com. También es útil crear un servicio que tenga una dirección base para los usuarios internos y una dirección base independiente para los usuarios internos. Para obtener más información, vea Soportar múltiples enlaces de sitios de IIS,
Servicio de enrutamiento
El servicio de enrutamiento es un intermediario SOAP genérico que actúa como un enrutador de mensajes. La funcionalidad principal del servicio de enrutamiento es la capacidad de enrutar mensajes según su contenido, lo que permite reenviar un mensaje a un extremo de cliente en función de un valor dentro del propio mensaje, en el encabezado o el cuerpo del mensaje. Para obtener más información, vea Enrutar, Servicios de enrutamiento .
Compatibilidad con WS-Discovery
La característica del servicio de detección permite a las aplicaciones cliente detectar dinámicamente las direcciones de servicio durante el tiempo de ejecución de manera interoperable mediante WS-Discovery. La especificación de WS-Discovery describe los patrones de intercambio de mensajes (MEP) requeridos para realizar detecciones ligera de servicios, tanto por multidifusión (ad hoc) como por unidifusión (mediante un recurso de la red). Para obtener más información, vea Detección de WCF, Detección (ejemplos).
Extremos estándar
Los extremos estándar son extremos predefinidos con una o más de sus propiedades (dirección, enlace, contrato) fijas. Por ejemplo, todos los extremos de intercambio de metadatos especifican IMetadataExchange como su contrato, de modo que el desarrollador no tiene que especificar el contrato. Por lo tanto, el extremo MEX estándar tiene un contrato IMetadataExchange fijo. Para obtener más información, vea Extremos estándar, .
Servicios de flujo de trabajo
Con la introducción de un conjunto de actividades de mensajería, es más fácil que nunca implementar flujos de trabajo que envían y reciben datos. Estas actividades de mensajería le permiten modelar patrones de intercambio de mensajes complejos que van más allá del tradicional enviar/recibir o de la invocación de método de estilo RPC. Para obtener más información, vea Servicios de flujo de trabajo, Services, Services.
Atributo de versión de .NET Framework de destino
El atributo de versión de .NET Framework de destino se utiliza para especificar la versión del .NET Framework a la que va destinada una aplicación hospedada en IIS o WAS. Esto le permite compilar aplicaciones que van destinadas a .NET Framework 2.0, 3.5 o 4 mediante Visual Studio. Se trata de un conjunto de atributos dentro de una etiqueta <compilation> en el archivo Web.config de una aplicación, tal y como se muestra en el siguiente ejemplo.
<compilation debug="false"
targetFramework="4.0">
<assemblies>
<add assembly="System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
<add assembly="System.Xml.Linq, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
<add assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
<add assembly="System.Data.DataSetExtensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
</assemblies>
</compilation>
Cuando una aplicación hospedada en IIS o WAS tiene como destino una versión de .NET Framework que no está instalada, se produce una excepción que indica el problema. Si el moniker de la versión de .NET Framework de destino no se especifica en el archivo Web.config de la aplicación, el valor se deduce de la versión del grupo de aplicaciones configurada en IIS.
Debido a esta nueva característica, si intenta hospedar un servicio WCF escrito con .NET Framework 3.5 en un equipo que ejecuta .NET Framework 4, puede obtener una clase ProtocolException con el siguiente texto:
Excepción no controlada: System.ServiceModel.ProtocolException: El tipo de contenido texto/html; charset=utf -8 del mensaje de respuesta no coincide con el tipo de contenido del enlace (application/soap+xml; charset=utf-8). Si utiliza un codificador personalizado, asegúrese de que el método IsContentTypeSupported se implementa de forma correcta. Los primeros 1024 bytes de la respuesta fueron: '<html> <head> <title>El dominio de la aplicación o el grupo de aplicaciones está ejecutando la versión 4 o posterior de .NET Framework. Esto se puede producir si la configuración de IIS se ha establecido en 4.0 o posterior para esta aplicación web, o si está utilizando la versión 4.0 o posterior del servidor de desarrollo web de ASP.NET. El elemento <compilation> del archivo Web.config para esta aplicación web no contiene el atributo 'targetFrameworkMoniker' requerido para esta versión de .NET Framework (por ejemplo, '<compilation targetFrameworkMoniker=".NETFramework,Version=v4.0">'). Actualice el archivo Web.config con este atributo o configure la aplicación web para utilizar una versión diferente de .NET Framework.</title>...
Este error se produce porque el dominio de aplicación en el que se ejecuta IIS está ejecutando .NET Framework 4 y el servicio WCF espera ejecutarse en .NET Framework 3.5. Para obtener más información sobre cómo corregir este problema, vea Cómo: Hospedar un servicio WCF escrito con .NET Framework 3.5 en IIS que ejecuta .NET Framework 4.
WCF REST
Almacenamiento en memoria caché
El sistema .NET Framework 4 le permite aprovechar el mecanismo de almacenamiento en memoria caché declarativo disponible en ASP.NET en sus servicios de WCF REST. Esto le permite almacenar en memoria caché las respuestas de las operaciones de servicio de WCF REST. Cuando un usuario envía un protocolo HTTP GET al servicio que está configurado para almacenar en memoria caché, ASP.NET devuelve la respuesta almacenada en memoria caché y no se llama al método de servicio. Cuando la memoria caché expira, la próxima vez que un usuario envía un protocolo HTTP GET, se llama al método de servicio y la respuesta se vuelve a almacenar en memoria caché.
El sistema .NET Framework 4 también le permite implementar un almacenamiento en caché de HTTP GET condicional. En los escenarios en que se usa REST, los servicios suelen usar una operación HTTP GET condicional para implementar el almacenamiento en memoria caché del HTTP inteligente descrito en la especificación de HTTP. Para obtener más información, vea Soporte de almacenamiento en memoria caché para servicios web HTTP de WCF, Caching and Automatic Help Page.
Compatibilidad con formatos
El modelo de programación HTTP web de WCF permite determinar dinámicamente el mejor formato que debe emplear una operación de servicio para devolver su respuesta. Las respuestas pueden establecerse automáticamente como XML y JSON en función del encabezado Accept. Se han agregado API auxiliares para establecer el formato de una operación mediante programación. Para obtener más información, vea Formato de web HTTP de WCF, Selección de formato automática, Selección avanzada de formato.
Control de errores de HTTP REST
El control de errores HTTP web de WCF permite devolver errores de los servicios REST de WCF que especifican un código de estado HTTP y devuelven detalles de error con el mismo formato que la operación (por ejemplo, XML o JSON). Para obtener más información, vea Controlar errores de web HTTP de WCF, .
Características de implementación
Se ha simplificado la configuración necesaria para ejecutar un servicio y se han incluido nuevos extremos estándar para simplificar aún más la configuración de servicio. Para obtener más información sobre la nueva configuración simplificada, vea Configuración simplificada. Para obtener más información sobre los extremos estándar, vea Extremos estándar.
Al hospedar un servicio de Windows Communication Foundation (WCF) en IIS, debe colocar un archivo .svc en el directorio virtual. Este archivo .svc especifica el generador de host de servicio que se debe usar, así como la clase que implementa el servicio. Al realizar solicitudes al servicio, debe especificar el archivo .svc en el URI, por ejemplo: https://contoso.com/ServicioDeEmpleados.svc. Para programadores que escriben servicios de REST, este tipo de URI no es óptimo. Los URI para los servicios de REST especifican un recurso determinado y normalmente no tienen ninguna extensión. La característica de integración de System.Web.Routing le permite hospedar un servicio de WCF REST que responde a los URI sin extensión. Para obtener más información, vea Integración de System.Web.Routing.
JavaScript entre dominios
El relleno de JSON (JSONP) es un mecanismo que habilita el soporte de script entre sitios en exploradores web. JSONP está diseñado basándose en la capacidad de los exploradores web de cargar scripts desde un sitio diferente de aquel en el que se recuperó el documento cargado actualmente. El mecanismo funciona rellenando la carga de JSON con un nombre de función de devolución de llamada definido por el usuario, por ejemplo:
callback({ “a” = \“b\” });
En el ejemplo anterior, la carga de JSON, {“a” = \”b\”}, se ajusta en una llamada de función, callback. La función de devolución de llamada ya se debe definir en la página web actual. El tipo de contenido de una respuesta JSONP es "aplicación/javascript". Para obtener más información, vea JSONP.
Página de ayuda del servicio WCF REST
.NET Framework versión 4 proporciona una página de ayuda automática para servicios de WCF REST. Esta página de ayuda contiene una lista de descripciones de cada operación, formatos de solicitud y respuesta, así como esquemas. Para obtener más información, vea Página de ayuda del servicio web HTTP de WCF, Caching and Automatic Help Page.