Entendendo a integração de aplicativos empresariais – os benefícios do ESB para EAI

Na atual infraestrutura empresarial, a integração de aplicativos e sistemas é uma preocupação cada vez maior.  A ampla variedade de abordagens e ideologias que visam a atingir essa meta é uma prova disso.  Quando você está começando a pesquisar soluções de integração de dados e aplicativos, é fácil se perder em uma infinidade de acrônimos, opiniões e linguagens confusas de marketing.

Muitas vezes, os rápidos avanços da tecnologia de EAI para atender à demanda crescente da empresa por integração resultam em argumentos sobre o que a EAI é ou não ou sobre como as pequenas diferenças entre uma abordagem exclusiva ou outra a transformam na única solução viável.

Neste artigo, nós esclareceremos as confusões com uma análise fácil de entender e claramente organizada da evolução da EAI.

Começando com uma breve história sobre a origem da EAI, nós percorreremos todos os grandes desenvolvimentos da arquitetura de EAI e aprenderemos como, agora, os sistemas tradicionais de EAI "hub and spoke" com base em intermediador estão sendo substituídos por arquiteturas ágeis, distribuídas e baseadas em padrões de barramento de serviço corporativo.

I. As origens da EAI

A. Quando a integração ponto a ponto não é boa o bastante

B. A abordagem de EAI

II. EAI tradicional

A. O modelo de intermediador

B. Vantagens e desvantagens

III. ESB – o próximo passo da EAI

A. Principais recursos

B. Benefícios

C. Quando usar um ESB

A integração de aplicativos empresariais, ou EAI, existe como um termo técnico desde o início da década de 2000, mas o problema central que ela tenta resolver é muito mais antigo.  Em resumo, a EAI é uma abordagem ou, mais precisamente, uma categoria geral de abordagens para oferecer interoperabilidade entre os vários sistemas diferentes que compõem uma infraestrutura empresarial comum.

Por sua natureza, as arquiteturas empresariais tendem a consistir em muitos sistemas e aplicativos, que oferecem os vários serviços com os quais as empresas contam para administrar os negócios diários.  Uma só organização pode usar diferentes sistemas, desenvolvidos internamente ou licenciados de um fornecedor terceirizado, para gerenciar a cadeia de suprimentos, os relacionamentos com os clientes, as informações dos funcionários e a lógica de negócios.  Muitas vezes, essa modularização é desejável.  Em teoria, dividir a tarefa de administrar uma empresa em várias funcionalidades menores permite a fácil implementação dos melhores e mais recentes avanços tecnológicos de cada área e a rápida adaptação às necessidades dinâmicas dos negócios.

No entanto, para obter os benefícios desse tipo de sistema modular e distribuído, uma organização deve implementar tecnologias que lidam com os problemas apresentados por essa arquitetura:

• Interoperabilidade: os vários componentes da infraestrutura podem usar diferentes sistemas operacionais, formatos de dados e linguagens, impedindo a conexão por meio de uma interface padrão.
• Integração de dados: para que um sistema modular e distribuído seja funcional, é essencial ter um método padrão para lidar com o fluxo de dados entre aplicativos e sistemas para aplicar a consistência no banco de dados.
• Solidez, estabilidade e escalabilidade: como elas são a cola que une uma infraestrutura modular, as soluções de integração devem ser altamente sólidas, estáveis e dimensionáveis.

Antes do desenvolvimento de abordagens do tipo EAI, os problemas de integração eram resolvidos, em grande parte, usando a integração ponto a ponto.  Em um modelo de integração ponto a ponto, um componente exclusivo de conector é implementado para cada par de aplicativos ou sistemas que devem se comunicar.   Esse conector lida com toda a transformação de dados, a integração e todos os outros serviços relacionados a mensagens que devem acontecer apenas entre o par específico de componentes que ele foi criado para integrar.

Quando usado com pequenas infraestruturas, em que é necessário integrar apenas dois ou três sistemas, esse modelo pode funcionar muito bem, oferecendo uma leve solução de integração adaptada às necessidades da infraestrutura.  No entanto, à medida que componentes adicionais são adicionados a uma infraestrutura, o número de conexões ponto a ponto necessário para criar uma arquitetura abrangente de integração começa a aumentar exponencialmente.

Uma infraestrutura de três componentes exige somente três conexões ponto a ponto para ser considerada totalmente integrada.  Por comparação, a adição de apenas dois mais componentes aumenta esse número para 10 conectores.  Isso já significa abordar um nível não gerenciável de complexidade e, quando que uma infraestrutura incluir sistemas de 8 ou 9 componentes e o número de conexões saltar para 30, a integração ponto a ponto não será mais uma opção viável.

Lembre-se de que todos esses conectores devem ser desenvolvidos e mantidos separadamente entre as mudanças de versão do sistema, mudanças de escalabilidade e muito mais (ou, em alguns casos, devem ser até mesmo adquiridos de um fornecedor por um alto custo) e, assim, a inadequação da integração ponto a ponto para cenários empresariais complexos se torna dolorosamente clara.

Para evitar a complexidade e a propensão a falhas da integração de infraestruturas complexas usando uma abordagem ponto a ponto, as soluções de EAI usam vários modelos de middleware para centralizar e padronizar práticas de integração em toda uma infraestrutura.

Em vez de cada aplicativo exigir um conector separado para se conectar ao outros conectores, os componentes de uma infraestrutura baseada em EAI usam métodos padronizados para se conectar a um sistema comum que é responsável por oferecer integração, intermediação de mensagens e funcionalidades de confiabilidade para toda a rede.

Em outras palavras, a EAI resolve o problema de integração de sistemas modulares tratando a integração como uma tarefa de um sistema, como qualquer outra tarefa, e não como um emaranhado complicado de conexões frágeis.  Os sistemas de EAI reúnem adaptadores para fins de conectividade, mecanismos de transformação de dados para converter dados em um formato adequado para uso pelo consumidor, mecanismos modulares de integração para lidar com muitos cenários diferentes e complexos de encaminhamento ao mesmo tempo e outros componentes para apresentar uma solução unificada de integração.

A EAI afrouxa as conexões rigidamente vinculadas da integração ponto a ponto. Um aplicativo pode enviar uma mensagem sem qualquer conhecimento da localização do consumidor, dos requisitos de dados ou do uso da mensagem – todas essas informações podem ser processadas pela implementação da EAI. Isso proporciona uma arquitetura mais flexível, em que é possível adicionar e remover novas partes conforme necessário simplesmente alterando a configuração do provedor de EAI, e um desenvolvimento modular simplificado em que vários aplicativos podem reutilizar um só serviço.

Muitas abordagens modernas de EAI também aproveitam a oportunidade apresentada adicionando um mecanismo central de integração para consolidar ainda mais as tarefas de mensagens.  Além de integração de dados, uma EAI moderna também pode incluir funcionalidades como administração de rede, segurança, aceleração e escalabilidade.

As primeiras soluções de EAI do mercado tiveram a ideia de unificar a integração literalmente e incorporaram todas as funcionalidades necessárias para integração em hubs centrais, chamados de intermediadores.

Nesta seção, nós analisaremos as vantagens e as desvantagens desse modelo e aprenderemos por que ele está sendo abandonado em detrimento da arquitetura de ESB.

Em uma abordagem intermediada de EAI, um mecanismo central de integração chamado de intermediador reside na parte central da rede e oferece todas as transformações de mensagens, encaminhamentos e outras funcionalidades entre aplicativos.  Toda a comunicação entre os aplicativos deve passar pelo hub (núcleo), o que permite que o hub mantenha a simultaneidade de dados para toda a rede.

Geralmente, as implementações do modelo de intermediador também oferecem ferramentas de monitoramento e auditoria que permitem que os usuários acessem informações sobre o fluxo de mensagens em seus sistemas, bem como ferramentas para acelerar a complicada tarefa de configurar o mapeamento e o encaminhamento entre muitos sistemas e aplicativos.

Como em todas as abordagens de integração com EAI, o modelo de intermediador permite um vínculo fraco entre os aplicativos.

Isso significa que os aplicativos podem se comunicar de modo assíncrono, enviando mensagens e continuando o trabalho sem ter que aguardar uma resposta do destinatário, sabendo exatamente como a mensagem chegará ao endpoint ou, em alguns casos, sabendo até mesmo o endpoint da mensagem.

Uma abordagem de intermediador também permite que toda a configuração de integração seja realizada em um repositório central, o que significa uma configuração menos repetitiva.

Assim como em qualquer outro modelo de arquitetura que use um mecanismo central, a desvantagem é que o intermediador pode se tornar um ponto único de falha da rede.  Como o intermediador é responsável por toda a simultaneidade entre os conjuntos de dados e os estados do aplicativo, todas as mensagens entre os solicitantes devem passar por ele.

Sob carga intensa, o intermediador pode se tornar um gargalo de mensagens.  Um só destino central para todas as mensagens também dificulta o uso do modelo de intermediador com sucesso entre grandes distâncias geográficas.

Por fim, as implementações do modelo de intermediador geralmente são produtos exclusivos e pesados que visam a oferecer suporte ao subconjunto de tecnologia de um fornecedor específico.  Isso poderá apresentar problemas caso o cenário de integração envolva produtos de vários fornecedores, sistemas desenvolvidos internamente ou produtos legados que não são mais compatíveis com o fornecedor.

O modelo de intermediador da EAI foi implementado com sucesso por algumas empresas, mas a grande maioria dos projetos de integração que usa esse modelo acabou falhando.  Com a falta de padrões claros para a arquitetura de EAI e o fato de a maioria das soluções iniciais ser patenteada, os primeiros produtos de EAI eram caros, pesados e, às vezes, não funcionavam como esperado a menos que um sistema fosse razoavelmente homogêneo.

Os efeitos desses problemas foram amplificados pelo fato de o modelo de intermediador ter tornado o sistema de EAI em um ponto único de falha da rede.  Um componente com mau funcionamento significaria falha total de toda a rede.  Em 2003, um estudo estimou que até 70% dos projetos de integração acabavam falhando devido às falhas nas primeiras soluções de intermediador.

Em uma tentativa de se livrar dos problemas causados por uma abordagem de EAI "hub and spoke" e intermediada, surgiu um novo modelo de EAI: o barramento.  Embora ela ainda usasse um componente central de encaminhamento para transmitir mensagens entre sistemas, a arquitetura de barramento buscava diminuir a carga de funcionalidade exigida de um só componente distribuindo algumas tarefas de integração a outras partes da rede.

Em seguida, esses componentes podem ser agrupados em várias configurações, por meio de arquivos de configuração, para lidar com qualquer cenário de integração da maneira mais eficiente possível e podem ser hospedados em qualquer lugar da infraestrutura ou duplicados para fins de escalabilidade entre grandes regiões geográficas.

Conforme a EAI baseada em barramento evoluiu, foram identificadas várias outras funcionalidades necessárias, como processamento de transações de segurança, processamento de erros e muito mais.  Em vez de exigir a codificação fixa desses recursos na lógica central de integração, como seria exigido por uma arquitetura de intermediador, a arquitetura de barramento permitiu que essas funções fossem incluídas em componentes separados.

Como resultado, surgiram soluções de integração leves e adaptadas com confiabilidade garantida e totalmente abstraídas da camada de aplicativo que seguem um padrão consistente e podem ser projetadas e configuradas com o mínimo de códigos adicionais, sem modificação dos sistemas que precisam ser integrados.

Essa versão madura do modelo de EAI baseado em barramento acabou sendo conhecida como barramento de serviço corporativo, ou ESB.

Atualmente, há vários produtos diferentes de ESB disponíveis no mercado.  Alguns, como o WebSphere Message Broker ou o TIBCO BusinessWorks, são produtos tradicionais de EAI que foram refatorados para oferecer funcionalidades semelhantes às do ESB, mas que ainda funcionam como intermediadores.

Outros, como Mule as an ESB da MuleSoft, foram criados do zero usando padrões abertos de mensagens e integração para implementar o modelo de ESB.

Apesar de suas diferenças, a maioria dos ESBs inclui todos ou a maioria dos seguintes principais recursos ou "serviços":

• Transparência da localização: uma forma de configurar centralmente os endpoints de mensagens para que o aplicativo de um consumidor não exija informações sobre um produto de mensagem para poder receber as mensagens
• Transformação: a capacidade do ESB de converter mensagens em um formato que é utilizável pelo aplicativo do consumidor.
• Conversão de protocolos: semelhante ao requisito de transformação, o ESB deve conseguir aceitar as mensagens enviadas em todos os principais protocolos e convertê-las no formato exigido pelo consumidor final.
• Encaminhamento: a capacidade de determinar os consumidores finais adequados com base em regras configuradas previamente e solicitações criadas dinamicamente.
• Aprimoramento: a capacidade de recuperar dados perdidos das mensagens recebidas, com base nos dados existentes de mensagem, e de anexá-los à mensagem antes da entrega ao destino final.
• Monitoramento/administração: o objetivo do ESB é tornar a integração em uma tarefa simples.  Sendo assim, um ESB deve oferecer um método fácil de monitorar o desempenho do sistema, um fluxo de mensagens por meio da arquitetura do ESB e uma forma simples de gerenciar o sistema a fim de entregar o valor proposto a uma infraestrutura.
• Segurança: a segurança do ESB envolve dois componentes principais – garantir que o ESB em si lide com as mensagens de maneira totalmente segura e negociar entre os sistemas de garantia de qualidade usados por todos os sistemas que serão integrados.

Esta é uma visão geral das vantagens oferecidas por uma abordagem de ESB para a integração de aplicativos:

• Leve: como um ESB é composto por muitos serviços interoperantes, e não por um só hub que contém todos os serviços possíveis, os ESBs podem ser leves ou pesados conforme a organização quiser que eles sejam, o que os torna a solução de integração mais eficiente disponível.
• Fácil de expandir: se uma organização sabe que precisará conectar aplicativos ou sistemas adicionais à sua arquitetura no futuro, um ESB permitirá que ela integre os sistemas imediatamente para que ela não precise se preocupar com o fato de um novo sistema funcionar ou não com a infraestrutura existente.  Quando o novo aplicativo estiver pronto, para fazer com que ele funcione com o restante da infraestrutura, basta conectá-lo ao barramento.
• Dimensionável e distribuível: ao contrário das arquiteturas de intermediador, a funcionalidade do ESB pode ser dispersa entre uma rede geograficamente distribuída, conforme necessário.  Além disso, como os componentes individuais são usados para oferecer cada recurso, é muito mais simples e econômico garantir alta disponibilidade e escalabilidade para partes essenciais da arquitetura ao usar uma solução de ESB.
• Compatível com SOA: os ESBs são criados com a arquitetura orientada por serviços em mente.  Isso significa que uma organização que deseja migrar para uma SOA pode fazer isso de modo incremental, continuando a usar os sistemas existentes enquanto conecta serviços reutilizáveis à medida que os implementa.
• Adoção incremental: à primeira vista, o número de recursos oferecido pelos melhores ESBs pode parecer intimidador.  No entanto, é melhor pensar no ESB como uma "plataforma" de integração, da qual você só precisa usar os componentes que atendam às suas atuais necessidades de integração.  O grande número de componentes modulares oferece uma flexibilidade inigualável que permite a adoção incremental de uma arquitetura de integração à medida que os recursos são disponibilizados e, ao mesmo tempo, garante que as necessidades inesperadas do futuro não impeçam o ROI.

Todas as soluções de integração têm pontos fortes e fracos que, muitas vezes, dependem do ambiente em que elas são implementadas.  Por isso, tomar decisões informadas sobre sua estratégia de EAI é essencial para o sucesso de sua iniciativa de integração.

Para que suas iniciativas de EAI e SOA tenham sucesso, você não precisa apenas da "melhor" tecnologia disponível; você precisa de fatos concretos sobre o cenário de uso pretendido do produto, o desempenho sob carga, a maturidade e um amplo entendimento dos desafios atuais e futuros de integração que sua organização deve vencer.

Antes de você tomar uma decisão sobre EAI, é importante ter uma boa ideia de como responderia a perguntas como estas:

• Quantos aplicativos preciso integrar?
• Precisarei incluir aplicativos adicionais no futuro?
• Quantos protocolos de comunicação precisarei usar?
• Minhas necessidades de integração incluem encaminhamento, bifurcação ou agregação?
• Qual a importância da escalabilidade para minha organização?
• Minha situação de integração requer mensagens assíncronas, publica/consome modelos de mensagens ou outros cenários complexos de mensagens com vários aplicativos?

Ross Mason, fundador da MuleSoft e arquiteto original do Mule as an ESB, escreveu um artigo intitulado "To ESB or Not To ESB" que apresenta uma boa introdução para as organizações que estão pensando em adotar uma abordagem de integração com ESB.  O artigo inclui uma versão expandida da checklist anterior para ajudar a determinar se o ESB é ou não uma boa opção para as necessidades de integração.