É basicamente uma forma conceitual de projetar um sistema - as empresas de software tentam vender mais colando o adesivo 'ESB' nele e os gerentes gostam porque um ESB parece bom visto de um 'nível superior'.
Um ESB é basicamente um MOM (middleware orientado a mensagem) com um modelo de dados adicionado e gerenciamento de definição de estrutura. Você tem uma definição de dados comum para todos os aplicativos e adaptadores nesse barramento (pode ser XML com um XSD compartilhado). Qualquer coisa que conecte DEVE enviar sua informação de acordo com esta definição de dados. O ESB oferece suporte ao carregamento, compartilhamento e controle de versão dessa definição de dados comum. Ao conectar um novo componente a um ESB, você pode esperar mais 'compatibilidade' fora da caixa do que ao conectá-lo a um MOM. Cada componente desse barramento é conceitualmente tratado como um 'recurso' - portanto, há uma abstração adicional introduzida para separar o emissor do receptor.
Exemplo: digamos que você deseja conectar o aplicativo A com o aplicativo B em um middleware orientado a mensagem padrão, vamos pegar o JMS. Você conversa com seus colegas que trabalham no aplicativo B, concorda com um tópico, tipo de mensagem e campos e os envia (pseudo código): sendJms ("TRADE.MSFT", {MapMessage trader = "pete" price = 101,4 vol = 100})
Se você faz a mesma coisa em uma arquitetura orientada a serviços, você precisa
- instalar software adicional
- aprender muitos novos conceitos
- defina seu novo componente Java na interface do administrador do ESB
- implementar algumas interfaces que são controladas pelo ESB
- sendJms (getDestination (), {MapMessage trader = "pete" price = 101,4 vol = 100}) - observe que o destino é injetado do ESB
A primeira vez provavelmente é um pouco doloroso, mas acho que você pode se acostumar com isso, assim como você pode se acostumar com os EJBs ;-)
Você poderia dizer que um sistema MOM é 'não tipado' (estrutura dinâmica) enquanto um ESB é 'tipado' (estrutura estática). Os trade-offs de mensagens brutas vs. ESB são semelhantes a outras opções não digitadas / digitadas:
- REST vs. SOAP
- XML não validado x XML validado com um XSD
- Groovy vs. Java
- linguagem interpretada vs. linguagem compilada
Para projetos menores é bom fazer hash da funcionalidade rapidamente (por exemplo, código Groovy), mas para projetos maiores é bom ter um depurador (por exemplo, Java), ser avisado com antecedência quando as coisas quebram e ter um padrão para as pessoas antes de se comprometerem com o projeto.
Portanto, se o seu projeto sofre com muitas pessoas quebrando o sistema verificando as alterações não validadas - vá em direção a mais estrutura (ESB em vez de MOM). Se seus projetos sofrem por não realizar o suficiente a tempo, escolha a solução mais simples e sem tipo. Se for ambos - chame um consultor (brincadeira ;-)