Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Este tópico discute os novos recursos que tornam a escrita de aplicativos WCF mais simples.
gRPC como alternativa ao WCF
gRPC é uma estrutura RPC moderna que é uma alternativa popular ao WCF. O gRPC é construído com base no HTTP/2, que oferece uma série de vantagens em relação ao WCF, incluindo:
- Desempenho: o gRPC é muito mais eficiente do que o WCF, especialmente para conexões de longa duração.
- Escalabilidade: o gRPC foi projetado para ser dimensionado para um grande número de clientes e servidores.
- Segurança: o gRPC suporta uma variedade de mecanismos de segurança, incluindo TLS e autenticação.
- Multiplataforma: o gRPC é neutro em relação à plataforma e pode ser usado com uma variedade de linguagens de programação.
Para obter mais informações sobre como desenvolver ou migrar aplicativos WCF para gRPC, consulte:
- Por que recomendamos gRPC para desenvolvedores WCF
- Comparando WCF com gRPC
- Introdução ao gRPC para desenvolvedores WCF
Arquivos de configuração gerados simplificados
Quando você adiciona uma referência de serviço no Visual Studio ou usa a ferramenta SvcUtil.exe, um arquivo de configuração do cliente é gerado. Em versões anteriores do WCF, esses arquivos de configuração continham o valor de cada propriedade de ligação, mesmo que seu valor seja o valor padrão. No WCF 4.5, os arquivos de configuração gerados contêm apenas as propriedades de vinculação que são definidas como um valor não padrão.
A seguir está um exemplo de um arquivo de configuração gerado pelo 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>
A seguir está um exemplo do mesmo arquivo de configuração gerado pelo 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>
Contract-First Desenvolvimento
O WCF agora tem suporte para desenvolvimento orientado a contrato. A ferramenta svcutil.exe tem uma opção /serviceContract que permite gerar contratos de serviço e dados a partir de um documento WSDL.
Adicionar referência de serviço de um projeto de subconjunto portátil
Os projetos de subconjuntos portáteis permitem que os programadores de montagem .NET mantenham uma única árvore de código-fonte e construam o sistema enquanto ainda suportam várias implementações .NET (desktop, Silverlight, Windows Phone e Xbox). Os projetos de subconjuntos portáteis fazem referência apenas a bibliotecas portáteis do .NET que são assemblies que podem ser usados em qualquer implementação do .NET. A experiência do desenvolvedor é a mesma que adicionar uma referência de serviço em qualquer outro aplicativo cliente WCF. Para obter mais informações, consulte Adicionar referência de serviço em um projeto de subconjunto portátil.
Alteração do padrão do modo de compatibilidade do ASP.NET
O WCF fornece o modo de compatibilidade ASP.NET para conceder aos desenvolvedores acesso total aos recursos do pipeline HTTP do ASP.NET ao desenvolver serviços WCF. Para usar este modo, deve-se definir o atributo aspNetCompatibilityEnabled como true na secção <serviceHostingEnvironment> do web.config. Além disso, qualquer serviço neste appDomain precisa ter a propriedade RequirementsMode no seu AspNetCompatibilityRequirementsAttribute definida como Allowed ou Required. Por padrão AspNetCompatibilityRequirementsAttribute , agora está definido como Allowed e o modelo de aplicativo de serviço WCF padrão define o aspNetCompatibilityEnabled atributo como true. Para obter mais informações, consulte O que há de novo no Windows Communication Foundation 4.5 e WCF Services and ASP.NET.
Melhorias no streaming
Novo suporte para streaming assíncrono foi adicionado ao WCF. Para habilitar o streaming assíncrono, adicione o comportamento do DispatcherSynchronizationBehavior ponto de extremidade ao host de serviço e defina a sua AsynchronousSendEnabled propriedade como
true. Isso pode beneficiar a escalabilidade quando um serviço está enviando mensagens transmitidas para vários clientes que estão lendo lentamente. O WCF não bloqueia mais um thread por cliente e liberará o thread para atender outro cliente.Removidas as limitações em torno do buffer de mensagens quando um serviço é hospedado no IIS. Em versões anteriores do WCF ao receber uma mensagem para um serviço hospedado no IIS que usava transferência de mensagens de streaming, ASP.NET armazenava em buffer a mensagem inteira antes de enviá-la para o WCF. Isso causaria um grande consumo de memória. Esse buffer foi removido no .NET Framework 4.5 e agora os serviços WCF hospedados no IIS podem começar a processar o fluxo de entrada antes que toda a mensagem tenha sido recebida, permitindo assim o streaming verdadeiro. Isso permite que o WCF responda imediatamente às mensagens e permite melhorar o desempenho. Além disso, não é mais necessário especificar um valor para
maxRequestLength, o limite de tamanho ASP.NET em solicitações de entrada. Se essa propriedade for definida, ela será ignorada. Para obter mais informações sobremaxRequestLength, consulte <httpRuntime> configuration element. Você ainda precisará configurar o maxAllowedContentLength, Para obter mais informações, consulte Limites de solicitação do IIS.
Novos valores padrão de transporte
A tabela a seguir descreve as configurações que foram alteradas e onde encontrar informações adicionais.
| Propriedade | Ligado | Novo padrão | Mais informações |
|---|---|---|---|
| tempo limite para a inicialização do canal | NetTcpBinding | 30 segundos | Esta propriedade determina quanto tempo uma conexão TCP pode levar para autenticar-se usando o protocolo .NET Framing. Um cliente precisa enviar alguns dados iniciais antes que o servidor tenha informações suficientes para executar a autenticação. Esse tempo limite é intencionalmente menor do que o ReceiveTimeout (10 min) para que clientes mal-intencionados não autenticados não mantenham as conexões vinculadas ao servidor por muito tempo. O valor padrão é 30 segundos. Para mais informações sobre ChannelInitializationTimeout |
| ouvirAtraso | NetTcpBinding | 16 * número de processadores | Esta propriedade de nível de socket descreve o número de solicitações de "aceitação pendente" que serão enfileiradas. Se a fila de espera de escuta ficar cheia, novos pedidos de soquete serão rejeitados. Para mais informações sobre ListenBacklog |
| maxPendingAceites | ElementoDeLigaçãoDeTransporteOrientadoPorConexão SMSvcHost.exe |
2 * número de processadores para transporte 4 * número de processadores para SMSvcHost.exe |
Essa propriedade limita o número de canais que o servidor pode ter aguardando em um ouvinte. Quando MaxPendingAccepts é demasiado baixo, haverá um pequeno intervalo de tempo em que todos os canais de espera iniciaram o serviço de conexões, mas nenhum novo canal começou a escutar. Uma conexão pode chegar durante esse intervalo e falhará porque nada está esperando por ela no servidor. Esta propriedade pode ser configurada definindo a MaxPendingConnections propriedade para um número maior. Para obter mais informações, consulte MaxPendingAccepts e Configurando o serviço de compartilhamento de porta Net.TCP |
| máximo de ligações pendentes | ElementoDeLigaçãoDeTransporteOrientadoPorConexão | 12 * número de processadores | Esta propriedade controla quantas conexões um transporte aceitou, mas que ainda não foram processadas pelo ServiceModel Dispatcher. Para definir esse valor, use MaxConnections na ligação ou maxOutboundConnectionsPerEndpoint no elemento de ligação. Para mais informações sobre MaxPendingConnections |
| receiveTimeout (tempo limite de recepção) | SMSvcHost.exe | 30 segundos | Esta propriedade especifica o tempo limite para ler os dados de enquadramento TCP e executar a distribuição de conexão a partir das conexões subjacentes. Isso existe para limitar o tempo máximo que o serviço SMSvcHost.exe é mantido ativo para ler os dados do preâmbulo de uma ligação recebida. Para obter mais informações, consulte Configurando o serviço de compartilhamento de porta Net.TCP. |
Observação
Esses novos padrões são usados somente se você implantar o serviço WCF em uma máquina com o .NET Framework 4.5. Se você implantar o mesmo serviço em uma máquina com o .NET Framework 4.0, os padrões do .NET Framework 4.0 serão usados. Nesses casos, recomenda-se definir essas configurações explicitamente.
XmlDictionaryReaderQuotas
XmlDictionaryReaderQuotas contém valores de cota configuráveis para leitores de dicionário XML que limitam a quantidade de memória utilizada por um codificador durante a criação de uma mensagem. Embora essas cotas sejam configuráveis, os valores padrão foram alterados para diminuir a possibilidade de que um desenvolvedor precise defini-las explicitamente.
MaxReceivedMessageSize A cota não foi alterada para que ainda possa limitar o consumo de memória, evitando a necessidade de você lidar com a complexidade do XmlDictionaryReaderQuotas. A tabela a seguir mostra as cotas, seus novos valores padrão e uma breve explicação para que cada cota é usada.
| Nome da cota | Valor padrão | Descrição |
|---|---|---|
| MaxArrayLength | Int32.MaxValue | Obtém e define o comprimento máximo de matriz permitido. Essa cota limita o tamanho máximo de uma matriz de primitivas que o leitor XML retorna, incluindo matrizes de bytes. Essa cota não limita o consumo de memória no próprio leitor XML, mas em qualquer componente que esteja usando o leitor. Por exemplo, quando o DataContractSerializer usa um leitor protegido com MaxArrayLength, ele não desserializa matrizes de bytes maiores que essa cota. |
| MaxBytesPerRead | Int32.MaxValue | Obtém e define o máximo de bytes permitidos retornados para cada leitura. Essa cota limita o número de bytes que são lidos em uma única operação de leitura ao ler a marca de início do elemento e seus atributos. (Em casos não transmitidos, o nome do elemento em si não é contabilizado na quota). Ter muitos atributos XML pode consumir um tempo de processamento desproporcional porque os nomes dos atributos precisam ser verificados quanto à exclusividade. MaxBytesPerRead atenua esta ameaça. |
| MaxDepth | 128 nós de profundidade | Essa cota limita a profundidade máxima de aninhamento de elementos XML. MaxDepth interage com MaxBytesPerRead: o leitor sempre mantém dados na memória para o elemento atual e todos os seus antepassados, de modo que o consumo máximo de memória do leitor é proporcional ao produto dessas duas configurações. Ao desserializar um gráfico de objeto profundamente aninhado, o desserializador é forçado a acessar toda a pilha e lançar um StackOverflowException. Existe uma correlação direta entre o aninhamento XML e o aninhamento de objetos para o DataContractSerializer e o XmlSerializer. MaxDepth é utilizado para atenuar esta ameaça. |
| MaxNameTableCharCount | Int32.MaxValue | Essa cota limita o número máximo de caracteres permitido em uma tabela de nomes. A tabela de nomes contém determinadas cadeias de caracteres (como namespaces e prefixos) que são encontradas ao processar um documento XML. Como essas cadeias de caracteres são armazenadas em buffer na memória, essa cota é usada para evitar buffering excessivo quando o streaming é esperado. |
| MaxStringContentLength | Int32.MaxValue | Essa cota limita o tamanho máximo da cadeia de caracteres que o leitor XML retorna. Essa cota não limita o consumo de memória no próprio leitor XML, mas no componente que está usando o leitor. Por exemplo, quando o DataContractSerializer usa um leitor protegido com MaxStringContentLength, ele não desserializa cadeias de caracteres maiores do que essa cota. |
Importante
Consulte "Usando XML com segurança" em Considerações de segurança para dados para obter mais informações sobre como proteger seus dados.
Observação
Esses novos padrões são usados somente se você implantar o serviço WCF em uma máquina com o .NET Framework 4.5. Se você implantar o mesmo serviço em uma máquina com o .NET Framework 4.0, os padrões do .NET Framework 4.0 serão usados. Nesses casos, recomenda-se definir essas configurações explicitamente.
Validação de configuração do WCF
Como parte do processo de compilação no Visual Studio, os arquivos de configuração do WCF agora são validados. Uma lista de erros de validação ou avisos são exibidos no Visual Studio se a validação falhar.
Dicas de ferramentas do Editor XML
Para ajudar os desenvolvedores de serviço WCF novos e existentes a configurar seus serviços, o editor XML do Visual Studio agora fornece dicas de ferramentas para cada elemento de configuração e suas propriedades que fazem parte do arquivo de configuração de serviço.
As Melhorias do BasicHttpBinding
Permite que um único ponto de extremidade WCF suporte diferentes modos de autenticação.
Permite que as configurações de segurança de um serviço WCF sejam controladas pelo IIS