O que é um ESB?

Basicamente, um Barramento de serviço corporativo (ESB) é uma arquitetura. Ele é um conjunto de regras e princípios para integrar vários aplicativos por meio de uma infraestrutura semelhante a um barramento. Os produtos de ESB permitem que os usuários criem esse tipo de arquitetura, mas variam na maneira como fazem isso e nos recursos que oferecem. O principal conceito da arquitetura de ESB é que você pode integrar diferentes aplicativos implementando um barramento de comunicação entre eles e, depois, permitir que todos os aplicativos se comuniquem com o barramento. Isso desvincula os sistemas uns dos outros, permitindo que eles se comuniquem sem dependência ou conhecimento de outros sistemas do barramento. O conceito de ESB surgiu da necessidade de abandonar a integração ponto a ponto, que se torna frágil e difícil de gerenciar com o passar do tempo. A integração ponto a ponto resulta na dispersão do código personalizado de integração entre os aplicativos, sem uma maneira central de fazer monitoramento nem solução de problemas. Muitas vezes, ele é chamado de "código espaguete" e não é dimensionado porque cria rígidas dependências entre os aplicativos.

Aumentar a agilidade organizacional reduzindo o tempo de lançamento de novas iniciativas no mercado é um dos motivos mais comuns pelos quais as empresas implementam um ESB como a base de sua infraestrutura de TI. Uma arquitetura de ESB facilita isso oferecendo um sistema simples, bem definido e "conectável" que possa ser muito bem dimensionado. Além disso, um ESB oferece uma forma de utilizar seus sistemas existentes e expô-los a novos aplicativos usando recursos de comunicação e transformação.

A arquitetura de ESB tem alguns princípios que permitem agilidade e escala de negócios. O foco principal é desvincular os sistemas uns dos outros e, ao mesmo tempo, permitir que eles se comuniquem de maneira consistente e gerenciável.

• O conceito de "barramento" desvincula os aplicativos uns dos outros. Geralmente, isso é feito usando um servidor de mensagens como JMS ou AMQP.
• Os dados que viajam no barramento têm um formato canônico e, quase sempre, são XML.
• Há um "adaptador" entre o aplicativo e o barramento que organiza os dados entre as duas partes.
• O adaptador é responsável por se comunicar com o aplicativo de back-end e transformar dados do formato de aplicativo no formato de barramento. Ele também pode realizar várias outras atividades, como encaminhamento de mensagens, gerenciamento de transações, segurança, monitoramento, processamento de erros etc.
• Geralmente, os ESBs não têm estado; o estado é integrado às mensagens que passam pelo barramento.
• O formato canônico de mensagem é o contrato entre sistemas. O formato canônico significa que há um formato consistente de mensagem viajando no barramento e que todos os aplicativos do barramento podem se comunicar entre si

Vamos analisar como uma arquitetura de ESB se associa aos nossos cinco princípios essenciais de integração:

• Orquestração: compor vários componentes detalhados existentes em um só serviço composto de ordem superior. Isso pode ser feito para alcançar o "detalhamento" adequado dos serviços e promover a reutilização e a capacidade de gerenciamento dos componentes subjacentes.
• Transformação: transformação de dados entre formatos canônicos de dados e formatos de dados específicos exigida por cada conector do ESB. Um exemplo disso seria a transformação entre os formatos CSV, Cobol copybook ou EDI em SOAP/XML ou JSON. Os formatos canônicos de dados podem simplificar bastante os requisitos de transformação associados a uma grande implementação de ESB em que há muitos consumidores e provedores, cada um com seus próprios formatos e definições de dados.
• Transmissão: negociação do protocolo de transmissão entre vários formatos (como HTTP, JMS, JDBC). Nota: a Mule trata os bancos de dados como outro "serviço", tornando o JDBC em outra transmissão (ou endpoint) em que os dados podem ser acessados.
• Mediação: oferecer várias interfaces a fim de: a) oferecer compatibilidade retroativa para várias versões de um serviço ou, alternativamente, b) permitir vários canais para a mesma implementação de componente subjacente. Esse segundo requisito pode envolver a oferta de várias interfaces para o mesmo componente: uma interface legada (arquivo simples) e uma compatível com os padrões (SOAP/XML).
• Consistência não funcional: para uma iniciativa comum de ESB, isso pode incluir consistência na forma como as políticas de monitoramento e segurança são aplicadas e implementadas. Além disso, os objetivos de escalabilidade e disponibilidade podem ser alcançados usando várias instâncias de um ESB para oferecer maior rendimento (escalabilidade) e eliminar os pontos únicos de falha (SPOFs), que é o principal objetivo dos sistemas altamente disponíveis.

Há muitas plataformas de ESB por aí, de grandes fornecedores com produtos patenteados a fornecedores de nicho e código aberto. No papel, há muitas semelhanças. É necessário considerar alguns pontos ao escolher um ESB.

Mule é a plataforma de integração mais leve disponível, com uma distribuição totalmente carregada que contribui com 40 MB. Ela tem um projeto modular para que você possa remover os módulos indesejados caso precise reduzir o espaço ocupado. Nós também não consideramos o termo "leve" como algo relacionado apenas ao tamanho; ele envolve o custo de fazer mudanças nas integrações existentes e o volume de trabalho árduo necessário para fazer mudanças. O runtime da Mule oferece modularização e uma implementação incrivelmente rápida durante o uso, além de um modelo de configuração que facilita os novos pedidos e a adição/alteração de funcionalidades.

A maioria dos fornecedores pensa em um ESB como uma simples mediação entre sistemas e tem produtos diferentes para hospedar serviços de publicação e lógica de negócios. Nós consideramos isso uma complexidade desnecessária. A Mule oferece um contêiner de serviço leve e dimensionável para publicar serviços REST e SOAP. Como a Mule se integra intimamente à Spring, isso significa que os desenvolvedores também podem utilizar os recursos da Spring para implementar lógica de negócios.

A Mule usa ferramentas comuns com as quais todos os desenvolvedores Java são familiarizados, como Maven, Eclipse, JUnit e Spring. Ela usa um modelo de configuração XML (semelhante ao da Spring) para definir a lógica, e o código personalizado pode ser escrito em várias linguagens, como Java, Groovy, JavaScript, Ruby ou Python. Além disso, o Anypoint Studio ajuda os novos desenvolvedores a entrar no ritmo rapidamente com um ambiente de desenvolvimento gráfico.

A Mule foi projetada para dimensionamento horizontal no hardware genérico – não é necessário usar máquinas grandes, caras e rápidas. É possível integrar o runtime da Mule facilmente a um aplicativo. Ele também pode ser integrado ao seu servidor de aplicativos, como Tomcat, JBoss ou WAS, ou diretamente ao seu aplicativo. Algo ainda mais importante é o fato de a Mule oferecer suporte a JUnit para que ele possa ser integrado a um caso de teste de JUnit. Isso é algo muito poderoso, pois significa que é possível criar testes unitários reproduzíveis para integrações que serão executadas no notebook de um desenvolvedor e que poderão ser incorporadas a uma compilação contínua.

Um recurso avançado da Mule é que o contêiner é independente de mensagens. Isso significa que ele não força mensagens XML para os usuários. Embora o XML seja comum, há muitos cenários em que talvez você queira usar JSON, arquivos simples, Cobol Copybooks, anexos binários e de arquivo, fluxos e objetos Java. Nosso Data Mapper gráfico também não é exigente sobre os dados que podem ser associados. E, ainda mais, o streaming da Mule permite que os desenvolvedores processem mensagens grandes com eficiência.

Se você preferir deixar a arquitetura de aplicativos, a hospedagem e o monitoramento de sua integração para os especialistas em integração, o CloudHub™ é ideal para você. CloudHub é uma plataforma de integração como serviço (iPaaS) que deixa você pronto para iniciar as atividades em questão de minutos. Ele oferece uma plataforma flexível e com hospedagem múltipla para mais de 150 serviços de infraestrutura, SaaS e Mídia Social, além da capacidade de se conectar aos seus aplicativos on-premises. Os aplicativos do CloudHub são executados de modo independente na Mule, e vice-versa. Isso significa que, independentemente de você estar fazendo uma implementação on-premises ou na nuvem, não há novos conceitos para aprender e a experiência do desenvolvedor é a mesma. Não é necessário aprender uma nova maneira de fazer as coisas.

A maioria das organizações quer aumentar a agilidade reduzindo o tempo de lançamento de novas iniciativas no mercado. Os ESBs promovem esse objetivo implementando um sistema simples, bem definido e "conectável" que possa ser muito bem dimensionado. Aqui na MuleSoft, nós entendemos que uma arquitetura de ESB é exatamente isso: uma arquitetura e não simplesmente um produto que se pode comprar nas prateleiras. Ela abrange não só a infraestrutura, mas também o design de aplicativos.

Explore a Mule, a solução de ESB mais flexível do mundo e o mecanismo de runtime da Anypoint Platform, e aprenda como ela pode ajudar as organizações a criar uma arquitetura com base em agilidade e velocidade.