Olá pessoal, tudo certo?

Recentemente, acompanhei uma discussão de arquitetura onde me foi apresentado um desenho de infra-estrutura simplificado, como esse:

image

Até aqui, nada de novo, tenho certeza que muitos de vocês já viram cenários como esse. O que chamou minha atenção foi o "barramento" no meio do desenho, o chamado Enterprise Service Bus (ESB). Após notá-lo entre as várias caixas de servidores, perguntei sobre a real necessidade do ESB na arquitetura e quais seriam as funcionalidades do barramento que seriam aproveitadas na solução.

Ouvi como resposta um sonoro : "é óbvio!!! precisamos publicar os serviços num barramento de serviços!!" :) Certo! Um barramento de serviços é importante, mas quais funcionalidades você vai utilizar a partir do barramento de serviços? : "ora!!! um barramento de serviços é um barramento de serviços!!!" :(

image Enfim, acabei descobrindo que o chamado barramento de serviços poderia até ser trocado por uma barra de Ethernet no desenho acima, pois de fato, a solução não mapeava qualquer funcionalidade envolvida numa camada ESB tradicional, nada além da ideia do varal universal de serviços....

Esse é um erro comum em muitos cenários hoje em dia. Diversas empresas já colocaram um barramento de serviços sem um detalhamento prévio ou conhecimento dos reais desafios que um barramento pretende endereçar.

Por exemplo, veja um artigo de Dezembro de 2007, que inicia o assunto de um modo bem interessante, posicionando a dificuldade em termos de integração e hub de aplicações, algo como :

image

Services Fabric: Fine Fabrics for New-Era Systems
Ref.: http://msdn.microsoft.com/en-us/architecture/cc168621.aspx

Muito bem, já deu para perceber que existe muito mais que apenas um "barramento" nesse assunto. Como o autor bem coloca, precisamos responder quais issues iremos atender com nosso ESB em nossa solução.

A Microsoft disponibiliza um pacote de Enteprise Service Bus chamado ESB Guidance. É interessante ver que a Microsoft define um ESB como um "conjunto de patterns de mensageria, EAI, integração e barramento de serviços", relacionando assim uma série de recursos. Entre os recursos mais importantes temos:

  • Monitoração de Atividades de Negócio
  • Motor de Regras de Negócio
  • Integração de Aplicações
  • Serviços de Transformação
  • Serviços de Resolução (UDDI)
  • Serviços de Itinerário
  • Serviços de Exceções
  • Repositório e Registro de Serviços
  • Portal de Gerenciamento

O desenho a seguir apresenta o mapa de funcionalidades do ESB Guidance 2.0 da Microsoft, disponível de forma gratuíta através do CodePlex, veja:

image

Enterprise Service Bus Guidance
Ref.: http://www.codeplex.com/esb/

Vale destacar que o ESB Guidance aproveita a infra-estrutura de mensageria e integração de aplicações (EAI) disponibilizada pelo produto BizTalk Server. Assim, o pacote estende as funcionalidades do produto para a criação de uma infra-estrutura de barramento de serviços, como vemos acima. Enquanto o ESB Guidance 1.0 trabalha com o BizTalk Server 2006 R2 (atual), o ESB Guidance 2.0 trabalhará sobre o BizTalk Server 2009, previsto ainda para esse semestre.

Para finalizar, o ESB Guidance 2.0 CTP2 - Janeiro 2009 foi recentemente disponibilizado no CodePlex para download. Confira:

ESB Guidance 2.0 CTP2 - January 2009
Ref.: http://www.codeplex.com/esb/Release/ProjectReleases.aspx?ReleaseId=21605

Sem dúvida, ESB é um componente crítico para soluções de serviços e integração de aplicações de forma padronizada no ambiente corporativo. Não deixem de acompanhar esse assunto em suas discussões.

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

Waldemir.