Compartir a través de


Características de simplificación de WCF

En este tema se describen las características nuevas que simplifican la escritura de aplicaciones WCF.

gRPC como alternativa a WCF

gRPC es un marco RPC moderno que es una alternativa popular a WCF. gRPC se basa en HTTP/2, que proporciona una serie de ventajas sobre WCF, entre las que se incluyen:

  • Rendimiento: gRPC es mucho más eficaz que WCF, especialmente para las conexiones de larga duración.
  • Escalabilidad: gRPC está diseñado para escalar a un gran número de clientes y servidores.
  • Seguridad: gRPC admite una variedad de mecanismos de seguridad, como TLS y autenticación.
  • Multiplataforma: gRPC es independiente de la plataforma y se puede usar con una variedad de lenguajes de programación.

Para obtener más información sobre el desarrollo o la migración de aplicaciones WCF a gRPC, consulte:

Archivos de configuración generados simplificados

Al agregar una referencia de servicio en Visual Studio o al usar la herramienta SvcUtil.exe se genera un archivo de configuración de cliente. En versiones anteriores de WCF, estos archivos de configuración contenían el valor de cada propiedad de enlace incluso si el valor era el predeterminado. En WCF 4.5, los archivos de configuración generados solo contienen las propiedades de enlace que se establecen en un valor no predeterminado.

El siguiente es un ejemplo de un archivo de configuración generado por WCF 3.0.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <system.serviceModel>
        <bindings>
            <basicHttpBinding>
                <binding name="BasicHttpBinding_IService1" closeTimeout="00:01:00"
                    openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
                    allowCookies="false" bypassProxyOnLocal="false"
                    hostNameComparisonMode="StrongWildcard" maxBufferSize="65536"
                    maxBufferPoolSize="524288" maxReceivedMessageSize="65536"
                    messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
                    useDefaultWebProxy="true">
                    <readerQuotas maxDepth="32" maxStringContentLength="8192"
                        maxArrayLength="16384" maxBytesPerRead="4096"
                        maxNameTableCharCount="16384" />
                    <security mode="None">
                        <transport clientCredentialType="None" proxyCredentialType="None"
                            realm="" />
                        <message clientCredentialType="UserName" algorithmSuite="Default" />
                    </security>
                </binding>
            </basicHttpBinding>
        </bindings>
        <client>
            <endpoint address="http://localhost:36906/Service1.svc" binding="basicHttpBinding"
                bindingConfiguration="BasicHttpBinding_IService1" contract="IService1"
                name="BasicHttpBinding_IService1" />
        </client>
    </system.serviceModel>
</configuration>

El siguiente es un ejemplo del mismo archivo de configuración generado por WCF 4.5.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <system.serviceModel>
        <bindings>
            <basicHttpBinding>
                <binding name="BasicHttpBinding_IService1" />
            </basicHttpBinding>
        </bindings>
        <client>
            <endpoint address="http://localhost:36906/Service1.svc" binding="basicHttpBinding"
                bindingConfiguration="BasicHttpBinding_IService1" contract="IService1"
                name="BasicHttpBinding_IService1" />
        </client>
    </system.serviceModel>
</configuration>

Desarrollo de contrato primero

WCF admite ahora el desarrollo de contrato primero. La herramienta svcutil.exe tiene un modificador /serviceContract que permite generar contratos de servicio y datos a partir de un documento WSDL.

Agregar referencia de servicio desde un proyecto de subconjuntos portátiles

Los programadores de ensamblados de .NET pueden usar proyectos de subconjuntos portátiles para mantener un único árbol de origen y un único sistema de compilación mientras que se mantiene la compatibilidad con varias implementaciones de .NET (escritorio, Silverlight, Windows Phone y Xbox). En los proyectos de subconjuntos portátiles, solo se hace referencia a las bibliotecas de .NET que constituyen ensamblados que pueden usarse en cualquier otra implementación de .NET. La experiencia del desarrollador es igual que agregar una referencia de servicio en cualquier otra aplicación cliente de WCF. Para más información, consulte Agregar referencia de servicio en un proyecto de subconjuntos portátiles.

Valor predeterminado del modo de compatibilidad de ASP.NET cambiado

WCF proporciona el modo de compatibilidad de ASP.NET para conceder a los desarrolladores acceso total a las características en la canalización HTTP de ASP.NET al escribir servicios WCF. Para usar este modo, debe establecer el aspNetCompatibilityEnabled atributo en true en la sección <serviceHostingEnvironment> de web.config. Además, cualquier servicio de este dominio de aplicación debe tener la propiedad RequirementsMode en su atributo AspNetCompatibilityRequirementsAttribute establecido en Allowed o Required. De manera predeterminada, AspNetCompatibilityRequirementsAttribute ahora se establece en Allowed y la plantilla de aplicación de servicio WCF predeterminada establece el atributo aspNetCompatibilityEnabled en true. Para más información, consulte Novedades de Windows Communication Foundation 4.5 y Servicios WCF y ASP.NET.

Mejoras en streaming

  • Se ha agregado a WCF una nueva compatibilidad para streaming asincrónico. Para habilitar el streaming asincrónico, agregue el comportamiento de punto de conexión DispatcherSynchronizationBehavior al host de servicio y establezca la propiedad AsynchronousSendEnabled en true. Esto puede beneficiar a la escalabilidad cuando un servicio envía mensajes de secuencias a varios clientes que leen despacio. WCF ya no bloquea un subproceso por cliente y liberará el subproceso para atender a otro cliente.

  • Se han quitado las limitaciones sobre el almacenamiento en búfer de mensajes cuando un servicio está hospedado en IIS. En versiones anteriores de WCF, al recibir un mensaje para un servicio hospedado por IIS que usaba transferencia de mensajes de streaming, ASP.NET almacenaba en búfer todo el mensaje antes de enviarlo a WCF. Esto provocaba que el consumo de memoria fuera grande. Este almacenamiento en búfer se ha quitado en .NET Framework 4.5 y ahora los servicios WCF hospedados en IIS pueden empezar a procesar el flujo de entrada antes de que se haya recibido el mensaje completo, lo que permite streaming auténtico. Esto permite que WCF responda inmediatamente a los mensajes y permite mejorar el rendimiento. Además, ya no es necesario especificar un valor para maxRequestLength, el límite de tamaño de ASP.NET en las solicitudes entrantes. Si se establece esta propiedad, se omite. Para más información sobre maxRequestLength, consulte elemento de configuración <httpRuntime>. Todavía deberá configurar maxAllowedContentLength. Para más información, consulte Límites de solicitud de IIS.

Nuevos valores de transporte predeterminados

En la tabla siguiente se describen los valores que han cambiado y dónde encontrar información adicional.

Propiedad Activado Nuevo valor predeterminado Más información
channelInitializationTimeout NetTcpBinding 30 segundos Esta propiedad determina cuánto tiempo puede tardar una conexión TCP en autenticarse a sí misma mediante el protocolo de tramas .NET. Un cliente debe enviar algunos datos iniciales antes de que el servidor tenga información suficiente para realizar la autenticación. Este tiempo de expiración se ha hecho intencionadamente más breve que ReceiveTimeout (10 min) para que los clientes no autenticados y malintencionados no conserven las conexiones con el servidor durante mucho tiempo. El valor predeterminado es 30 segundos. Para más información sobre ChannelInitializationTimeout
listenBacklog NetTcpBinding 16 * número de procesadores Esta propiedad del nivel de socket describe el número de solicitudes "pendientes de aceptación" que se van a poner en cola. Si la cola de trabajos pendientes de escucha se llena, las nuevas solicitudes de socket se rechazarán. Para más información sobre ListenBacklog
maxPendingAccepts ConnectionOrientedTransportBindingElement

SMSvcHost.exe
2 * número de procesadores para transporte

4 * número de procesadores para SMSvcHost.exe
Esta propiedad limita el número de canales que el servidor pueda tener en espera en un agente de escucha. Cuando MaxPendingAccepts es demasiado bajo, hay un pequeño intervalo de tiempo en el que todos los canales en espera han iniciado conexiones de mantenimiento, pero sin que ningún canal nuevo haya empezado a escuchar. Una conexión puede llegar durante este intervalo y producirá un error porque no hay nada en espera en el servidor. Esta propiedad se puede configurar si se establece la propiedad MaxPendingConnections en un número mayor. Para más información, consulte MaxPendingAccepts y Configuración del servicio de uso compartido de puertos Net.TCP.
maxPendingConnections ConnectionOrientedTransportBindingElement 12 * número de procesadores Esta propiedad controla cuántas conexiones ha aceptado un transporte pero no las ha seleccionado el distribuidor de ServiceModel. Para establecer este valor, use MaxConnections en el enlace o maxOutboundConnectionsPerEndpoint en el elemento de enlace. Para más información sobre MaxPendingConnections
receiveTimeout SMSvcHost.exe 30 segundos Esta propiedad especifica el tiempo de expiración para la lectura de datos de trama de TCP y para la conexión mediante el envío desde las conexiones subyacentes. Existe para limitar el tiempo que el servicio SMSvcHost.exe se mantiene ocupado para leer los datos de preámbulo de una conexión entrante. Para más información, consulte Configuración del servicio de uso compartido de puertos Net.TCP.

Nota

Estos valores predeterminados nuevos se usan solo si implementa el servicio WCF en un equipo con .NET Framework 4.5. Si implementa el mismo servicio en un equipo con .NET Framework 4.0, se usan los valores predeterminados de .NET Framework 4.0. En tales casos se recomienda configurar estos valores de forma explícita.

XmlDictionaryReaderQuotas

XmlDictionaryReaderQuotas contiene valores de cuota configurables para los lectores de diccionario de XML que restringen la cantidad de memoria usada por un codificador mientras se crea un mensaje. Aunque estas cuotas son configurables, los valores predeterminados han cambiado para reducir la posibilidad de que un desarrollador tenga que establecerlas explícitamente. La cuota de MaxReceivedMessageSize no se ha cambiado, de modo que aún puede limitar el consumo de memoria para evitar que sea necesario tratar la complejidad de XmlDictionaryReaderQuotas. En la tabla siguiente se muestran las cuotas, sus nuevos valores predeterminados y una breve descripción de para qué se usa cada cuota.

Nombre de cuota Valor predeterminado Descripción
MaxArrayLength Int32.MaxValue Obtiene y establece la longitud máxima permitida de matriz. Esta cuota limita el tamaño máximo de una matriz de primitivas que devuelve el lector XML, incluidas las matrices de bytes. Esta cuota no limita el consumo de la memoria en el propio lector XML, sino en cualquier componente que esté utilizando el lector. Por ejemplo, cuando DataContractSerializer utiliza un lector protegido con MaxArrayLength, no deserializa matrices de bytes mayores que esta cuota.
MaxBytesPerRead Int32.MaxValue Obtiene y establece el máximo permitido de bytes devueltos para cada lectura. Esta cuota limita el número de bytes que se leen en una operación de lectura única al leer la etiqueta de inicio de elemento y sus atributos. (En los casos en que no haya transmisión, el propio nombre del elemento no se cuenta para la cuota). Tener demasiados atributos XML puede usar un tiempo de proceso desproporcionado porque se tiene que comprobar la unicidad de los nombres de atributo. MaxBytesPerRead mitiga esta amenaza.
MaxDepth 128 nodos de profundidad Esta cuota limita la profundidad máxima del anidamiento de elementos XML. MaxDepth interactúa con MaxBytesPerRead: el lector siempre mantiene los datos en memoria para el elemento vigente y todos sus antecesores, por lo que el consumo máximo de la memoria del lector es proporcional al producto de estos dos valores. Al deserializar un gráfico de objetos profundamente anidado, el deserializador se ve obligado a obtener acceso a la pila completa e iniciar una StackOverflowExceptionirrecuperable. Existe una correlación directa entre anidamiento de XML y anidamiento de objeto para DataContractSerializer y XmlSerializer. MaxDepth se usa para mitigar esta amenaza.
MaxNameTableCharCount Int32.MaxValue Esta cuota limita el número máximo de caracteres permitidos en un objeto nametable. La tabla de nombres contiene ciertas cadenas (como espacios de nombres y prefijos) que se encuentran al procesar un documento XML. Como estas cadenas están almacenadas en búfer en la memoria, esta cuota se usa para evitar el almacenamiento en búfer excesivo cuando se espera streaming.
MaxStringContentLength Int32.MaxValue Esta cuota limita el tamaño máximo de la cadena que el lector XML devuelve. Esta cuota no limita el consumo de la memoria en el propio lector XML, sino en el componente que está utilizando el lector. Por ejemplo, cuando DataContractSerializer utiliza un lector protegido con MaxStringContentLength, no deserializa cadenas mayores que esta cuota.

Importante

Consulte "Uso de XML de forma segura" en Consideraciones de seguridad para los datos para obtener más información sobre cómo proteger los datos.

Nota

Estos valores predeterminados nuevos se usan solo si implementa el servicio WCF en un equipo con .NET Framework 4.5. Si implementa el mismo servicio en un equipo con .NET Framework 4.0, se usan los valores predeterminados de .NET Framework 4.0. En tales casos se recomienda configurar estos valores de forma explícita.

Validación de la configuración de WCF

Como parte del proceso de compilación en Visual Studio, los archivos de configuración de WCF ahora se validan. Se muestra una lista de errores de validación o advertencias en Visual Studio si se produce un error en la validación.

Información sobre herramientas del editor XML

Para ayudar a los desarrolladores de servicios WCF nuevos y existentes a configurar sus servicios, el Editor XML de Visual Studio proporciona ahora información sobre herramientas para cada elemento de configuración que forma parte del archivo de configuración del servicio y sus propiedades.

Mejoras de BasicHttpBinding

  1. Permite a un único extremo de WCF responder a distintos modos de autenticación.

  2. Permite que la configuración de seguridad de un servicio WCF esté controlada por IIS