Partager via

WCF versus BizTalk Server - Uma discussão inicial sobre implantação de serviços.

  • Article

Olá pessoal, tudo certo? Let's talk about coding? :)

Conversei esta semana com um cliente, onde encontramos um cenário de integração onde era possível identificar serviços usando WCF - Windows Communication Foundation e serviços publicáveis num ESB sobre BizTalk Server. Muitas vezes, nos deparamos com esse tipo de situação, onde devemos decidir qual o cenário de transporte mais aderente. Vários fatores colaboram nessa decisão assim, temos aqui um post que fala um pouco de recomendações e cenários.

Começando pelo BizTalk Server, este produto nasceu para integração, uns 7 anos atrás. Houve bastante evolução na plataforma algo longo do tempo, enquanto recebia novos recursos para gerenciamento de processos, transformação de documentos, orquestração, recuperação, monitoração, etc. A nova versão 2006 R2 veio com algumas novas funcionalidades, entre elas o WCF e o WF - Windows Workflow Foundation também suportados. Além desses frameworks, ainda o suporte a EDI, incluindo o X12 e o schema EDIFACT, EDI transaction batching e RFID.

Quando decidir por uma publicação de serviços sobre BizTalk Server (BTS)?
Quando o volume de mensagens esperado for grande e houver aderência ao tempo de processamento de cada mensagem. Surge então a discussão sobre latência. Devemos avaliar o tempo de cada tipo de mensagem trafegada pelo BTS, afim de comparar com o SLA - Service Level Agreement - do serviço ou negócio consumidor da mensagem. Existem diversos recursos e operações que podemos executar sobre uma mensagem, como transformações, adição de campos, assinatura por certificados, validação de origem/destino, etc. além da já esperada persistência da mensagem no MessageBox do BizTalk. Ou seja, temos muitos fatores que podem aumentar ainda mais a latência de uma mensagem. Por isso, é crítico avaliar qual o tempo de resposta esperado pela solução, antes da simples adoção por uma infra-estrutura BTS.

E para os serviços que exigem performance e latência muito baixa?
WCF é a infra-estrutura mais indicada para conectividade entre serviços. E nesse cenário, o WCF ainda oferece uma série de combinações de meios de transporte, cada um com benefícios específicos para cada cenários. Então vejamos:

  • Quando o cenário envolver Web Services, Federated Security, Reliable Delivery, Transação Integrada e principalmente, integração com tudo que fala SOAP/HTTP. o Binding mais indicado para o EndPoint WCF é o BasicHttpBinding. É assim a primeira escolha para compatibilidade com WS Basic Profile 1.1.

O link a seguir exemplifica como configurar um BasicHttpBinding no config file de uma aplicação:

<endpoint address=""
binding="basicHttpBinding"
bindingConfiguration="Binding1"
contract="Microsoft.ServiceModel.Samples.ICalculator" />

https://msdn2.microsoft.com/en-us/library/system.servicemodel.basichttpbinding.aspx

  • Quando o cenário envolve confiabilidade de entrega e necessidade de desempenho máximo na comunicação entre máquinas e processos, isto é, cenários de conexão WCF-a-WCF sensíveis a largura de banda e desempenho, recomenda-se o NetTCPBinding. Algumas das vantagens do NetTCPBinding é o supote a segurança de mensagens, autenticação, o uso de TCP para entrega de mensagens e o encondig binário, o que garante maior compactação e economia de banda.

O link a seguir fala da configuração do NetTCPBinding:

<endpoint address=""
binding="netTcpBinding"
bindingConfiguration="Binding1"
contract="Microsoft.ServiceModel.Samples.ICalculator" />

https://msdn2.microsoft.com/en-us/library/system.servicemodel.nettcpbinding.aspx

  • Finalmente, para os cenários onde existe integração com aplicações MSMQ já existentes ou integração simples com o Host Integration Server e o BizTalk, aplicamos o transporte com o NetMsmqBinding.

O link a seguir exemplifica como configurar um NetMsmqBinding no config file de uma aplicação:

<endpoint address="net.msmq://localhost/private/ServiceModelSamples"
binding="netMsmqBinding"
contract="Microsoft.ServiceModel.Samples.IQueueCalculator" />

https://msdn2.microsoft.com/en-us/library/system.servicemodel.netmsmqbinding.aspx

Como sabemos, o WCF ainda suporta outros mecanismos de transporte não tratados aqui, como WSDualHttpBinding, WSHttpBinding, NetPeerTcpBinding e NetNamedPipeBinding. Assim, é importante avaliarmos a natureza de cada serviço e a conexão entre processos, para a correta escolha do mecanismo de transporte mais indicado.

Ainda existe um artigo muito interessante sobre performance do WCF, que colabora para nossa discussão. Veja aqui:

A Performance Comparison of Windows Communication Foundation (WCF) with Existing Distributed Communication Technologies
https://msdn2.microsoft.com/en-us/library/bb310550.aspx  

Um post longo, mas o assunto é importante. Em outras conversas, vamos falar um pouco mais sobre WCF e BizTalk.

Por enquanto é só. Até o próximo post longo! :)

Waldemir.

Comments

  • Anonymous
    July 08, 2008
    Olá Waldemir, mto bom seu post! :) Particularmente não sabia que o WCF possuía essas várias formas de comunicação, praticamente serve para qualquer cenário né (síncrono, assíncrono, only request, request/response, security, etc). Tenho um cenário que o meio de transporte precisa ser síncrono (recebe um request e deve devolver um response em um curto espaço de tempo), mas pode haver casos que demore (pois depende de uma outra resposta para responder). Como poderia tratar isso com WCF? Qual o melhor meio de transporte para tal processo? Hoje estou tratando como síncrono (exponho o processo como um web service request/response e trato a resposta caso demore com um time-out, chamando outro método de resposta assíncrono caso caia em exception. Funciona mas não é o estado da arte :) Grande abraço e parabéns pelo blog, mto bom! Douglas Mello.

  • Anonymous
    July 08, 2008
    The comment has been removed