O que é um ESB e o que é bom para?

https://stackoverflow.com/questions/597397

11-09-2019
|

Pergunta

Em um trabalho anterior, houve muita conversa sobre "Enterprise Service Bus" (ESB). Eu li partes de um livro conceitual sobre isso, mas nunca entendi como você poderia implementar / integrá-lo em termos concretos. Eu estou familiarizado com serviços SOA / filas / diretório / etc. mas eu não entendo o que exatamente um ESB é.

É uma coisa concreta (serviço / servidor / broker / etc.) Que você acabou de ligar todos os seus aplicativos até lo de diferentes maneiras, ou é mais apenas uma forma conceitual para sistemas de design?

Qualquer explicações ou links para bons exemplos seria muito apreciada. Obrigado.

Solução

É um conceito bastante elevado nível de abstração. O conceito central é que o ESB fornece o middleware e interfaces que permitem às empresas conectar suas aplicações sem escrever código.

Isto poderia incluir a mediação para reconciliar incompatível protocolos, dados e interação.

A idéia de uma central de autocarros em que tudo passa dá oportunidade para camadas adicionais de abstração. Usando padrões da indústria para "plug" outras aplicações, os clientes, e tal para este autocarro faz com que ligação de novos serviços, fontes de dados, clientes com necessidades diferentes é relativamente fácil.

implementações reais

Quanto implementações reais, esse é o domínio de grandes empresas de apoio empresarial. Embora seja muito buzzwordy, o objetivo é um ideal que, em algum nível pequeno pode ser compreendido através da comparação com a internet:

Similaridade a Internet

Um ônibus grandes comunicações com amplamente diferentes usos e dados, mas todos rodando protocolos Padronizar.

Pode-se, na verdade, escrever um conector HTTP para FTP que permitiria que os navegadores para sites de acesso FTP sem invocar um cliente FTP (normalmente embutido no navegador agora).

Mashups

Mashups demonstrar uma implementação interessante - tomar alguns dados de rota de ônibus da autoridade de San Francisco, mapa do google, e locais sushi bar de yahoo com classificações e executar uma consulta simples que lhe dá o sushi bar mais próximo, ponderando-lo para que você estaria disposto a viajar um pouco mais para uma melhor bar.

Todos os completamente diferentes serviços, incompatível por si só, mas usando conectores padrão (Yahoo Pipes, por exemplo) podem ser puxados juntos em um coeso e útil todo.

-Adam

Outras dicas

Disclaimer: Eu trabalho para a IBM e consultar sobre WebSphere ESB, um produto IBM projetado para ESBs construir com. A seguir estão as minhas opiniões e não refletem necessariamente a posição da IBM.

Um ESB é coisas diferentes para pessoas diferentes, infelizmente.

Para mim, um ESB é um qualquer tecnologia que você pode inserir em uma SOA (Service-Oriented Architecture), permitindo que você conecte sistemas díspares. Muitas vezes realiza as funções de transformação protocolo, modificação mensagem, encaminhamento, logging, na qualidade de um gateway de segurança, e assim por diante. Por exemplo, você pode usar um ESB para expor um serviço antes só disponível como um serviço Web como um serviço JMS baseada também.

A este respeito, as implementações de ESB (ou para ser mais preciso, software vendido para ESBs construir com - como a que eu consultar sobre) são muitas vezes tecnologicamente semelhante ao que costumava ser conhecido como mensagens ou filas corretor, embora o propósito é um pouco diferente, porque (como as siglas implicar) é orientada em torno de serviços em vez de mover mensagens de um lugar para outro. Qual a importância da distinção é tecnologicamente é uma questão de opinião.

A minha experiência com ESB comercial é que é uma tecnologia exagerada e caro que cria tantos problemas quanto os que resolve. O ESB irá ligar novos sistemas e legados, as mensagens irão voar sobre o ônibus e tudo vai ser capaz de falar a todo o resto sem problemas. O lance em alguma resiliência, orquestração e você tem uma peça muito poderosa de software de aplicações empresariais.

O problema surge quando você tentar usá-los para o real, a sobrecarga de escrever para o ônibus, criando as estruturas de mensagens e assim por diante, pode sobrelevar os benefícios. Como um item de alto custo, o ESB é visto como a panaceia para todos os problemas de tecnologia que não é, muito tempo é gasto no ônibus e não sobre as aplicações / dados que estão sendo conectados. É frequentemente o caso que vários padrões concorrentes vão lutar pela supremacia na mesma organização que leva aos silos tecnologia clássico dominados que estes sistemas devem realmente ser de fixação.

IMHO é muito melhor usar criar um pequeno número de interfaces específicas, geralmente usando serviços web entre apenas aqueles sistema que precisa.

É basicamente uma forma conceitual para projetar um sistema -. Empresas de software tentar vender mais furando na etiqueta 'ESB' sobre ele e gestores como porque um ESB parece ser bom a partir de um 'alto nível'

Um ESB é basicamente um MOM (mensagem orientada middleware) com uma gestão adicionado definição do modelo de dados e da estrutura. Você tem uma definição comum de dados para todas as aplicações e adaptadores naquele ônibus (poderia ser XML com um XSD compartilhado). Qualquer coisa que se conecta deve enviá-lo de informações aderente a esta definição de dados. O ESB suporta o carregamento, partilha e controle de versão desta definição de dados comum. Ao conectar um novo componente para um ESB, você pode esperar mais 'compatibilidade' fora da caixa do que quando a ligar a um MOM. Cada componente naquele ônibus é conceitualmente tratado como um 'recurso' -. Por isso há uma abstração adicional introduzida ao remetente descolar do receptor

Exemplo: digamos que você deseja se conectar aplicação A com aplicação B em uma orientada mensagem de middleware padrão, vamos dar JMS. Você conversa com seus colegas trabalhando em aplicativo B, chegar a acordo sobre um tópico, tipo de mensagem e campos e enviá-lo (código pseudo): sendJms ( "TRADE.MSFT", {comerciante MapMessage = preço "pete" = 101,4 vol = 100})

Se você fizer a mesma coisa em uma arquitetura orientada a serviços, você precisa

instalar software additinal
aprender um monte de novos conceitos
definir o seu novo componente Java no administrador do ESB gui
implementar algumas interfaces que são controladas pela ESB
sendJms (getDestination (), {MapMessage comerciante = preço "pete" = 101,4 vol = 100}) - nota o destino é injetado a partir da ESB

A primeira vez é provavelmente um pouco doloroso, mas eu acho que você pode se acostumar com isso, assim como você pode se acostumar com EJB; -)

Pode-se dizer um sistema MOM é 'sem tipo' (estrutura dinâmica), enquanto um ESB é 'digitados' (estrutura estática). Os trade-offs de Messaging raw vs. ESB são semelhantes a outros / as escolhas digitadas sem tipo:

RESTO vs. SABÃO
XML XML vs. unvalidated validado com um XSD
Groovy vs Java
linguagem interpretada vs. linguagem compilada

Para projetos menores, é bom de hash a funcionalidade rapidamente (por exemplo, código Groovy), mas para projetos maiores, é bom ter um depurador (por exemplo, Java), para ser avisado com antecedência quando as coisas quebrar e ter um padrão para as pessoas antes cometem ao projeto.

Portanto, se seus sofre projeto de muitas pessoas quebrando o sistema de check-in alterações unvalidated - movimento no sentido de mais estrutura (ESB em vez de MOM). Se seus projetos sofre por não fazer as coisas feito o suficiente no tempo - escolher a solução mais simples, sem tipo. Se é tanto - obter um consultor (brincadeirinha; -)

Bem, isso depende de quem você perguntar ... Muitos diriam que é um pedaço de "Middleware" que conecta várias peças de "lógica de negócios" juntos para tomar a codificação de mensagens entre esses módulos. Eu acho que é uma definição geral o suficiente, mas eu tenho certeza que você já tenha chegado lá via Wikipedia e outros enfeites.

Aqueles que têm a grande ESB salvar o mundo vê-lo como ele é mais comumente apresentados, um hub para fazer tudo. A maioria ESB implementações esforço para encapsular todas as tarefas repetitivas que vemos em software de negócios. Isso significa que a maioria dos ESBs cuidar de transferência de dados, segurança, logging, tradução de protocolo, sistemas de eventos, a exposição api via serviços web, etc.

Eu acho que é tão claro quanto eu posso ser ... Espero que ajude.

Dê uma olhada na minha apresentação " estragado para a escolha - Como escolher o ESB direito ".

Eu explico quando usar um ESB, Suite Integração, ou apenas um Integration Framework (tais como Apache Camel). Eu também discutir as diferenças entre código aberto e ESBs proprietários.

Além de uma definição padrão que você pode começar a partir Wikipedia . Acho que é para ser uma ótima ferramenta para ligar um monte de sistemas legados através de múltiplas plataformas e tecnologias. É também uma boa ferramenta para a construção de fluxos de trabalho distribuídos e sistemas de gerenciamento de estado (como razão geral).

No entanto, é bastante caro, complexo e inconveniente para manter e ampliar o que o torna uma opção de tecnologia pobres como uma ferramenta de uso geral para escalar você aplicações.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow