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:
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" />
http://msdn2.microsoft.com/en-us/library/system.servicemodel.basichttpbinding.aspx
O link a seguir fala da configuração do NetTCPBinding:
<endpoint address="" binding="netTcpBinding" bindingConfiguration="Binding1" contract="Microsoft.ServiceModel.Samples.ICalculator" />
http://msdn2.microsoft.com/en-us/library/system.servicemodel.nettcpbinding.aspx
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" />
http://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 Technologieshttp://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.
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.
Olá Douglas, tudo certo?
Obrigado pelos comentários no blog! :)
De fato, o WCF oferece uma grande flexibilidade para a construção de serviços orientados a mensagens, multi-protocolos e multi-hosters.
Vale lembrar que o serviço é exposto através de um endpoint, formado pelo endereço (A = address), o contrato (C = contract) e o binding (B = bindind), o chamado A+B+C do WCF.
Para cenários de consumo de serviços de forma assíncrona o WCF oferece dois tipos de bindings nativamente: o NetMSMQBinding e o MSMQIntegrationBinding.
O NetMSMQBinding oferece um transporte baseado em MSMQ com encoding binário, permitindo uma boa performance para o tratamento de mensagens. Oferece também segurança no nível de transporte e mensagens, além de suporte a transações. Esse binding torna-se uma primeira escolha para cenários assíncronos de alta vazão e que precisem ser reliables, durables e no modelo queued One-Way Messaging.
Já o MSMQIntegrationBinding oferece um transporte para integração MSMQ com MSMQ encoding. Fornece a segurança do ambiente MSMQ, assim como o suporte a transação. É uma primeira escolha como binding para cenários de integração com aplicações MSMQ já existentes, além de ser de simples integração com o Host Integration Server e o Biztalk Server, quando existentes na solução.
Minha sugestão é olhar alguns exemplos de serviços usando o NetMSMQBinding. Creio que pode ser uma boa escolha para seu cenário.
Em tempo, o último post da série "Cenários de implementação de serviços com WCF" será sobre mensageria, não perca!
Ref.: http://blogs.msdn.com/wcamb/archive/tags/Cen_26002300_225_3B00_rios+de+servi_26002300_231_3B00_os+WCF/default.aspx
Por enquanto é só! Depois nos conta como foi sua experiência... :)