Arquitetura de Soluções

por Waldemir Cambiucci

Microsoft BizTalk Server 2006 R2 e o modelo ESB – Enterprise Service Bus.

Olá pessoal, tudo certo?


Essa semana tive uma bela discussão sobre SOA – Service Oriented Architecture – e o posicionamento do Microsoft BizTalk Server 2006 R2 (ou “BTS” para simplificar) nesse tipo de cenário. Se você tem acompanhado nossos papos sobre SOA aqui no blog, sabe que existem diversas questões que precisam ser tratadas para a construção de uma boa arquitetura de serviços. Latência, interfaces, proxies, protocolos, segurança, composição de aplicações, workflows, etc., são algumas das questões conhecidas.


Para entender como o BTS está relacionado ao assunto, vejamos um desenho básico sobre seu funcionamento:


image


A figura acima representa o fluxo de mensagens do BTS, onde pipes de entrada recebem mensagens do meio externo, permitindo operações como validação, transformação de campos, descriptografia, etc. As mensagens recebidas são então persistidas numa base de dados chamada MessageBox. Esse passo é importante para todo o processo de auditoria e rastreamento de mensagens dentro do ambiente BTS. Outro fator importante da persistência de mensagens é a possibilidade de recuperação de mensagens históricas, subscrição e publicação para destinatários diversos, além do disparo de orquestrações associadas. Mensagens podem ser interceptadas, disparando processos ou orquestrações de processo (workflows), que operam diversas atividades dentro do ambiente BTS, até a geração final das mensagens de saída para o meio externo.


De modo simplificado, uma das grandes funcionalidades do BTS é seu poder de mensageria, permitindo o tratamento de mensagens entre fonte/destino, com recursos de manipulação de dados, transformação, validação, assinatura, subscrição e roteamento. 


Porém, esse mesmo núcleo de mensageria pode ser usado como um HUB de serviços. Nesse contexto, é possível construir cenários onde serviços implementados no ambiente do BTS são publicados através de interfaces WCF – Windows Communication Foundation. Mensagens endereçadas para esses serviços podem ser tratadas, permitindo atividades como inspeção de propriedades, análises de negócio (com a consolidação de grupos de mensagens relacionadas), aplicação de regras de decisão sobre as mensagens recebidas, etc., através das próprias ferramentas do ambiente BTS. No modo mais simples de publicação de serviços, o ambiente BTS funcionará como um ponto central de disponibilidade de serviços com rastreamento de mensagens.


Nesse ponto, surge a discussão sobre ESB – Enterprise Service Bus, ou barramento de serviços. Mas o que é um barramento de serviços?


O termo ESB tem sido usado largamente em diversas discussões sobre SOA. Podemos interpretar o tema de acordo com o foco da discussão, passando de um simples repositório de serviços até o núcleo de orquestração ou motor de BPM – Business Process Management. Mais recentemente, ESB tem sido colocado apenas como um dos muitos componentes presentes numa infra-estrutura de suporte a SOA, ou SOI – Service Oriented Infrastructure.


Na minha opinião, uma boa definição de ESB é “um conjunto de patterns de arquitetura baseados em modelos tradicionais de EAI – Enterprise Application Integration, middlewares orientados a mensagens, Web Services e interfaces de serviços, integração com sistemas da plataforma alta ou aplicações de negócio (LOB – Line of Business), interoperabilidade com serviços registrados e repositório de serviços. Todos esses elementos podem ou não aparecer na arquitetura envolvendo ESB, dependendo das necessidades da solução.”


Considerando nossa introdução sobre BizTalk Server e o modelo ESB, agora podemos falar sobre o Microsoft ESB Guidance for BizTalk Server 2006 R2.


O desenho abaixo apresenta os principais componentes do ESB Guidance com BizTalk.


image


Note que para cada funcionalidade prevista no modelo ESB, temos um recurso BTS associado. Assim, é possível identificar os motores de orquestração, de transformação de mensagens, de regras de negócio e persistência associados às funcionalidades do ESB. Ao mesmo tempo, a interoperabilidade entre sistemas heterogêneos torna-se possível com o BTS+ESB, através de seus adaptadores de conexão como WCF, JMS, Pipes, etc. Existem mais de 300 adaptadores disponíveis hoje no mercado para o ambiente BTS, o que amplia seu poder de interoperabilidade.


Atualmente, diversas empresa do mercado brasileiro têm discutido sobre infra-estrutura SOA e plataformas ESB. Um dos principais motivadores dessa discussão é a evolução da atual plataforma de negócios da empresa para um modelo mais ágil, que permita composição de aplicações e serviços, enquanto garante uma melhor administração e governança sobre os componentes da arquitetura. É sempre bom lembrar que uma outra ferramenta importante para essa evolução são os modelos de maturidade ou otimização de infra-estrutura. Reconhecer o grau de maturidade de nossas capacidades de infra-estrutura é fator crítico para a estratégia de evolução a longo prazo.


Esse post foi apenas uma introdução sobre o assunto. Para saber mais sobre os recursos do ESB Guidance sobre o BizTalk Server, visite os links abaixo:


Microsoft ESB Guidance for BizTalk Server 2006 R2
Ref.: http://msdn.microsoft.com/en-us/library/cc487894.aspx


Microsoft ESB Guidance
Ref.: http://www.codeplex.com/esb


Por enquanto é só! Até o próximo post 🙂


Waldemir.