Olá pessoal, tudo certo?

No post anterior vimos que a interoperabilidade na plataforma Microsoft pode ser organizada em 3 níveis básicos de complexidade:

• Interop in the Framework
• Interop in the Box
• Interop in the Cloud

Os recursos assim agrupados permitem um melhor entendimento das necessidades de cada solução, seja através da customização com WCF, WF, seja via um motor de mensageria e transformação com o BizTalk Server ou um barramento de mensanges com o ESB Guidance, ou até mesmo um modelo de integração entre empresas através da nuvem, no chamado ISB - Internet Service Bus, como .NET Services do Azure.

Falamos também de 4 componentes importantes para a interoperabilidade no ambiente enterprise (local). Vejamos:

O que usar?

• Microsoft® BizTalk® Server (BTS) : BizTalk oferece uma pilha ampla de adaptadores, orquestração, mensageria e protocolos para a construção de soluções preparadas para EAI - Enterprise Application Integration. Através de ferramentas de mapeamento de mensagens, manipulação de schemas, transformação, monitoração e regras de negócio, o ambiente BTS permite a construção de soluções de mensageria em cenários de elevado volume de mensagens e vazão;
  
• Microsoft Host Integration Server (HIS) : HIS oferece uma plataforma para a conectar aplicações com sistemas da plataforma IBM zSeries e iSeries. Ainda, HIS suporta a conexão de dados entre Microsoft Message Queuing (MSMQ) e o IBM WebSphere MQ;
  
• Microsoft Message Queuing (MSMQ) : o MSMQ permite a conexão de entre aplicações usando um modelo de fila de mensagens. MSMQ oferece a garantia de entrega de mensagens, mensagens baseadas em prioridades e segurança. Ele suporta a integração com sistemas parcialmente conectados ou temporariamente offline. MSQM também suporta cenários de mensageria síncrona e assíncrona;
  
• Microsoft Enterprise Service Bus (ESB) Guidance : o ESB Guidance é uma unidade lógica que oferece uma arquitetura desacoplada baseada em mensagens, usando para isso a infra-estrutura do BizTalk Server. O ESB Guidance é na verdade um conjunto de templates e patterns que extendem as funcionalidades do BTS, adicionando características como roteamento de mensagens, repositório de serviços, garantia de entrega, segurança de mensagens, registro de serviços e tratamento unificado de exceções;

Cada uma das tecnologias acima aplica patterns de arquitetura importantes para diversos cenários de integração em TI. Porém, cada cenário exige uma tecnologia mais adequada que a outra. Adotar um modelo síncrono de mensageria quando nossa solução permite cenários parcialmente conectado pode ser desastraso, por exemplo. Então, surge a pergunta:

Quando usar?

Considere o uso de BizTalk Server quando:

• quando a solução interage com múltiplos web services via uma orquestração, como parte de uma arquitetura orientada a serviços (SOA), suportando as latências de I/O devido a transformação de mensagens, persistência de mensagens para tracing ou latência devido subscrição/distribuição de mensagens;
• quando a solução deseja suportar processos business-to-business (B2B), incluindo padrões de indústria como EDIFACT, ANSCI X12, HL7, HIPAA, or SWIFT.
• quando a solução exige a execução de serviços em paralelo, com mecanismos facilitadores para esse tipo de orquestração e sincronização entre processos;
• quando a solução exige alta confiabilidade e infra-estrutura dedicada para escalabilidade, com garantia de entrega e recuperação de mensagens;
• quando a solução necessita medir KPI's - Key Performance Indicators de negócio, através de um motor de análise como BAM - Business Analysis Manager, que deve fornecer uma visibilidade em tempo real sobre os dados processados pela solução;
• quando a solução deseja abstrair a lógica de negócios e aplicações através de políticas, que podem ser alteradas de acordo com as necessidades de negócio da solução;

Considere o uso de Host Integration Server quando:

• quando a solução precisa suportar interação com aplicações IBM zSeries ou iSeries;
• quando a solução deve integrar BizTalk com DB2, WebSphere MQ, Aplicações Host (em plataforma alta) ou servidores de arquivos;
• quando a solução deve integrar mensageria MSMQ com WebSphere MQ;

Considere o uso de Message Queuing quando:

• quando a solução deve suportar interação entre aplicações baseada em mensagens;
• quando a solução precisa integrar plataformas Microsoft e Não-Microsoft, suportando a conversação assíncrona;
• quando a solução precisa suportar conversação SRMP - SOAP Reliable Messaging Protocol entre as aplicações envolvidas;

Considere o uso de Enterprise Service Bus Guidance quando:

• quando a solução necessita suportar a abordagem de mensageria com itinerário de mensagens ou roteamento entre sistemas envolvidos;
• quando a solução deve suportar a resolução dinâmica de roteamento de mensagens;
• quando a solução deve usar transformação de mensagens dinâmicamente;
• quando a solução deve suportar um gerenciamento de exceções de forma unificada e robusta, para a integração de sistemas EAI;
• quando a solução necessita de uma abordagem de repositóio de serviços, para publicação de funcionalidades envolvidas;

O mapa acima é uma relação parcial de benefícios ou aspectos de arquitetura que justificam cada tecnologia para uma dada solução. Claro, para alguns cenários, podemos abrir mão dos pacotes acima e simplesmente implementar nossos próprios componentes de integração, interoperabilidade ou orquestração usando frameworks como o WCF - Windows Communication Foundation e o WF - Windows Workflow Foundation, sempre considerando o esforço de nosso próprio desenvolvimento.

No final, podemos construir uma matriz de decisão, que pode nos ajudar no momento de análilse de uma solução e as tecnologias mais indicadas. Fica a dica para ampliar esse estudo e detalhamento destacando os aspectos mais importantes para sua própria solução.

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

Waldemir.