ESB (barramento de serviço corporativo)

menu icon

ESB (barramento de serviço corporativo)

Neste guia, saiba mais sobre o ESB (um componente essencial da SOA), os benefícios que ele oferece e como ele se relaciona à arquitetura de microsserviços.

O que é um ESB (barramento de serviço corporativo)?

Um ESB, ou barramento de serviço corporativo, é um padrão pelo qual um componente de software centralizado realiza integrações a sistemas back-end (e conversões de modelos de dados, conectividade profunda, roteamento e solicitações) e disponibiliza essas integrações e conversões como interfaces de serviço para reutilização por novos aplicativos. O padrão ESB é geralmente implementado usando um tempo de execução de integração e um conjunto de ferramentas especialmente projetados que garantem a melhor produtividade possível.

ESB e SOA

Um ESB é um componente essencial da SOA, ou arquitetura orientada a serviços, uma arquitetura que surgiu no final da década de 1990. A SOA define uma maneira de tornar componentes de software reutilizáveis por meio de interfaces de serviço. Essas interfaces utilizam padrões de comunicação comuns de tal modo que eles podem ser rapidamente incorporados a novos aplicativos sem a necessidade de realizar uma integração sempre.

Cada serviço em uma SOA incorpora as integrações de código e de dados necessárias para realizar uma função de negócios completa e discreta (por exemplo, verificar o crédito de um cliente, calcular o pagamento mensal de um empréstimo ou processar um pedido de financiamento imobiliário). As interfaces de serviço fornecem acoplamento fraco, ou seja, elas podem ser solicitadas com pouco ou nenhum conhecimento sobre como a integração está sendo implementada nos bastidores. Os serviços são expostos usando protocolos de rede padrão, como SOAP (simple object access protocol)/HTTP ou JSON/HTTP, para enviar solicitações de leitura ou de alteração de dados. Os serviços são publicados de forma a possibilitar que os desenvolvedores os encontrem rapidamente e os reutilizem para montar novos aplicativos.

Esses serviços podem ser criados desde o início, mas por vezes são criados ao expor funções de sistemas legados de registro como interfaces de serviço. É assim que surge a demanda pelo ESB. Sistemas legados e sistemas de registro geralmente utilizam protocolos antigos e formatos de dados proprietários que precisam ser convertidos e integrados para funcionarem com os protocolos da rede SOA. O ESB realiza essas conversões e integrações durante execução. É possível implementar uma SOA sem um ESB, mas os proprietários dos aplicativos teriam que encontrar sua própria forma individualizada de expor as interfaces de serviço, o que dá muito trabalho (mesmo se as interfaces venham a ser reutilizáveis) e cria um desafio de manutenção significativo no futuro.

Para saber mais sobre a SOA e a função de um ESB dentro dela, acesse "Introdução à SOA (Arquitetura Orientada a Serviços). "

Benefícios

Em teoria, um ESB centralizado oferece o potencial de padronizar e simplificar radicalmente a comunicação e a integração de serviços em toda a empresa. Os custos de hardware e de software podem ser compartilhados, o provisionamento dos servidores precisa ser realizado apenas uma vez e uma única equipe de especialistas pode ser encarregada (e, se necessário, ser treinada) para desenvolver e manter as integrações.

Os desenvolvedores podem usar um único protocolo para 'conversar' com o ESB e emitir comandos que direcionam as interações entre os serviços, deixando que o ESB converta os comandos, faça roteamento das mensagens e transforme os dados conforme necessário para que os comandos sejam executados. Isso permitiria aos desenvolvedores passar menos tempo integrando e mais tempo configurando e aprimorando seus aplicativos. E a capacidade de reutilizar essas integrações de um projeto para o próximo ofereceu o potencial ainda maior de ganhos de produtividade e economia mais adiante.

Mas embora os ESBs tenham sido implementados com sucesso em algumas organizações, em muitas outras o ESB chegou a ser considerado um gargalo na implementação da SOA. Realizar mudanças ou melhorias em uma integração poderia desestabilizar outras. As atualizações no middleware do ESB impactaram as integrações existentes. Uma vez que o ESB era gerenciado centralmente, as equipes de aplicativos passaram a aguardar por suas integrações. À medida que o volume de integrações aumentou, a implementação de alta disponibilidade e de recuperação de desastres para os servidores ESB se tornaram mais caras. E como um projeto interempresarial, o ESB mostrou-se difícil de financiar, tornando esses desafios técnicos muito mais difíceis de serem resolvidos.

Por fim, os desafios e os custos de manter, atualizar e ajustar a escala de um ESB centralizado alcançaram maior proporção e o ESB, por vezes, retardou os ganhos de produtividade que ele e a SOA foram destinados a fornecer, frustrando as equipes das linhas de negócios que esperavam um ritmo mais acelerado de inovação.

Para uma visão mais aprofundada da ascensão e da queda do ESB, veja "O destino do ESB."

ESB vs. microsserviços

A arquitetura de microsserviços possibilita que as partes internas de um único aplicativo sejam fragmentadas em pequenas partes que podem ser alteradas, escaladas e administradas de forma independente. Os microsserviços surgiram e ganharam força com a ascensão da virtualização, da computação em cloud, das práticas de desenvolvimento Agile e do DevOps. Nesse contexto, os microsserviços oferecem:

  • Maior agilidade e produtividade para desenvolvedores ao permitir a eles incorporar novas tecnologias em uma parte de um aplicativo sem alterar ou atualizar o restante do aplicativo.
  • Escalabilidade mais simples e rentável ao possibilitar que qualquer componente possa ter a escala ajustada de maneira independente dos demais, para a resposta mais rápida possível às demandas de carga de trabalho e ao uso mais eficiente dos recursos de computação.
  • Maior resiliência, pois a falha de um componente não impacta os outros e cada microsserviço pode ser executado segundo seus próprios requisitos de disponibilidade, sem interferência nos outros componentes a um requisito de 'maior disponibilidade comum'.

A mesma granularidade que os microsserviços trazem ao design de aplicativos pode ser levada à integração, com benefícios semelhantes. Esta é a ideia por trás da integração ágil, a qual fragmenta o ESB em componentes de integração de baixa granularidade e descentralizados, sem interdependências, que as equipes de aplicativos individuais podem possuir e gerenciar de maneira autônoma.

Para obter mais detalhes sobre todos os aspectos dos microsserviços, acesse "Microsserviços: um guia completo", "SOA vs. microsserviços: qual é a diferença?" e assista ao vídeo de Dan Bettinger, "O que são microsserviços?”:

ESB e IBM Cloud

À medida que sua empresa migra a sua infraestrutura de TI em direção a uma abordagem de cloud híbrida , há uma grande probabilidade de que você estará transformando uma variedade de cargas de trabalho, incluindo aquelas com base em padrões SOA e ESB, em modelos de implementação mais leves e flexíveis. Essas transformações são apenas uma parte da modernização dos aplicativos  na jornada para a cloud de qualquer organização.  

Dê o próximo passo:

Comece a usar hoje mesmo com uma conta IBM Cloud.