messaging - saúde - soap esb




Diferença entre um Message Broker e um ESB (4)

Eu tenho passado por diferentes perguntas / artigos em Message Brokers e ESBs (Even on stackoverflow). Ainda não é uma dica como o que é a diferença de demarcação CLEAR entre um Message Broker e um ESB? Agora aqui estou tentando comparar produtos, Websphere Broker e Mule ESB !!

Em primeiro lugar, é (qualquer versão) Webshere Broker um ESB? Nosso pessoal de produtos da IBM afirma que ele é um ESB (não estou surpreso com isso).

Minha informação limitada me diz que um Message Broker funciona em um modelo HUB-SPOKE. No entanto, o ESB funciona em uma arquitetura de barramento. Agora o que na terra é que isso quer dizer? Eu li que se o HUB falhar (indisponível eu acho), então o corretor falha completamente. Qual não é o caso de um ESB (Então esses caras dizem). O que eu não entendo aqui é "E se o ÔNIBUS" falhar?

Agora, o material usual sobre ESBs e Brokers é que eles fornecem roteamento, transformação, orquestração etc. Então, se ambos fornecem isso, então por que eu escolheria um sobre o outro.

Outra área de conflito é sobre a TRANSFORMAÇÃO. Os ESBs o facilitam de maneira diferente quando comparados aos Message Brokers? Eu realmente adoraria alguma ideia sobre isso.

Agora falando sobre dimensionamento HORIZONTAL. Quem supera o quem? Ou ambos são igualmente dimensionáveis ​​em termos de complexidade (ou quaisquer outros fatores). Claro custo, Webshpere Broker vai cobrar por cada caixa (muito menos cada cpu). Eu acredito, até mesmo o comercial MULE ESB não faz isso. Deixando de lado a parte do Custo, quais são as implicações do escalonamento de ESB e escalonamento do Message Broker. Eu sei que você pode escalar até o nível de serviço no ESB. Isso é possível em um corretor de mensagens?


A diferença entre um Message Broker e um ESB é principalmente a palavra 'bus'.

Para mim, um Message Broker é um processo (usualmente grande) que transforma dados de uma estrutura em outra estrutura ou modifica o conteúdo.

Um ESB é um middleware orientado a mensagens (MOM) mais serviços adicionais, um dos quais poderia ser um Message Broker. Portanto, um ESB pode incluir um Message Broker como um de seus componentes. Um Bus consiste em mais de um processo, caso contrário eu não o chamaria de 'bus'. A natureza de um barramento é que há vários componentes que atendem tarefas diferentes, cada um se comunicando em um MOM e aderindo a alguma forma de 'formato de dados comum'. Um barramento consistiria em: aplicativos enviando dados para o MOM, adaptadores de banco de dados, Message Brokers, pontes do MOM, etc.

A separação é um pouco gradual, mas a maior diferença entre uma arquitetura do Message Broker e um Barramento é a granularidade . Se sua tarefa é integrar os aplicativos A, B, .., Z e alguns bancos de dados, você pode fazer isso com um grande Message Broker conectando cada um e todos. Ou com um ESB onde vários componentes pequenos assumem apenas pequenas tarefas. Por exemplo, um adaptador se conecta a A, outro a B (mas eles não fazem transformação), então cada um envia suas coisas para um (ou mais) Message Broker, cada um dos quais deve ser mantido o mais simples possível - por exemplo, não ter que saber sobre o modelo de dados de 'A' ou 'B'. Um bom ESB deve ter uma definição de dados comum no barramento, abstraindo da "diferença" de aplicativos individuais.

TRANSFORMAÇÃO: um ESB não ajuda na transformação, a menos que venha com um Message Broker. Mas cada bom ESB deve incluir um Message Broker de qualquer maneira. O Message Broker deve ser o especialista do seu ônibus para transformações, mas nada mais.

Escala HORIZONTAL: se você tiver apenas 3 coisas para conectar (agora e sempre), provavelmente não vale a pena o esforço para obter um ESB completo. Um Message Broker tem a vantagem de ser apenas um grande processo. Você pode configurar tudo lá e ter um local central para todos os seus mapeamentos de dados, filtragem e roteamento.

Mas se você tiver 30 aplicativos para se conectar, um Message Broker provavelmente pararia de funcionar. É claro que você pode comprar mais instâncias, executar coisas redundantes etc., mas deve alterar sua estratégia para "localizar" tarefas. Cada adaptador de aplicativo (pode ser uma pequena instância do Message Broker cada) deve ser capaz de gerar e / ou receber um modelo de dados comum abstraído (por exemplo, XML com um XSD compartilhado). Também pode haver um Message Broker central para tarefas de transformação, mas essa instância não deve ter conhecimento do modelo de dados A ou B. Portanto, um ESB deve mover o processamento para o componente especialista, em vez de manter tudo em um local central.


Acabei de ler este artigo de Udi Dahan há alguns dias, o que pode lhe dar uma visão mais clara do que sinto ser uma diferença fundamental.

http://www.udidahan.com/2011/03/24/bus-and-broker-pubsub-differences

Citando:

A regra de que só pode haver um único publicador para um determinado tipo de evento é uma das coisas que diferencia os barramentos dos intermediários, embora ambos obviamente permitam que você tenha vários assinantes

...

Infelizmente, existem muitas tecnologias no estilo de corretor que estão sendo comercializadas sob o banner do Enterprise Service Bus. Embora alguns produtos tenham a capacidade de serem implantados de maneira centralizada e distribuída (às vezes chamada de modo “federado” ou “incorporado”), muitos não impõem a regra “endpoint de publicação única por tipo de evento”.

Sem essa restrição, é muito fácil cometer erros.

Espero que ajude.


Um Enterprise Service Bus fornece três valores-chave para o negócio:

  1. Roteamento baseado em contexto ou conteúdo de transações;
  2. Transformação de um domínio de mensagem ou transporte para outro domínio ou transporte de mensagem;
  3. conectividade de serviço muitos-para-muitos.

Os ESBs fornecem um baixo acoplamento de serviços, permitem que os serviços sejam reconstituídos em contextos de aplicativos totalmente diferentes do que quando os serviços foram visualizados ou desenvolvidos pela primeira vez e promovem a reutilização de aplicativos sem a necessidade de recodificar aplicativos. O WebSphere Message Broker (ou agora é chamado IBM Integration Bus) é um excelente exemplo de um Enterprise Service Bus. Para um exemplo de simplicidade de código que traz um grande poder em poucas linhas, você pode ver meu post aqui: http://soabus.org/viewtopic.php?f=3&t=13 . A construção fundamental dentro do tempo de execução do IIB é chamada de Árvore de Mensagens Lógicas (LMT). Tudo o que o desenvolvedor quer fazer é algum tipo de operação no LMT. ESQL é a linguagem mais eficiente que um desenvolvedor pode usar para executar essas operações no LMT, embora muitas outras linguagens sejam suportadas (por exemplo, Java, PHP, Python, etc.). Nenhum outro produto chega perto da eficiência e da facilidade de desenvolvimento do ESB. aplicativos que o IBM Integration Bus, pois 90% da codificação desses aplicativos é feita arrastando e soltando nós em um palete. Isso deixa apenas 10% da codificação a ser feita pelo desenvolvedor do Message Flow. A propósito, o WebSphere ESB foi descontinuado pela IBM e muitos dos produtos concorrentes para o IBM Integration Bus não viram nenhum novo desenvolvimento neles há vários anos. Uma lista de várias ofertas de produtos ESB pode ser vista em soabus.org.


Você pode usar um intermediário de transformação sem um barramento de serviço e vice-versa. Em termos de produtos específicos, não creio que alguém seja puramente um ou outro devido à maneira como cada um complementa o outro. Alguns produtos são mais fortes em uma área, outros são mais fortes em outra. Talvez seja necessário escolher uma opção com base na função que melhor cobre um problema individual.

Um corretor pode ter melhores "blocos lego" internos para construir uma cadeia de transformação do que um produto ESB. Um corretor pressionado ao serviço como um ESB pode ser esmagado sob carga e não ter uma boa escala, ou pode não ter registro e ferramentas robustos para lidar com os periódicos.

Alguns ESBs permitem que as atualizações do banco de dados sejam revertidas e as filas sejam repetidas em um aplicativo corrigido, uma vez que um erro flagrante na lógica tenha sido descoberto e corrigido. Eu não acho que a maioria dos corretores integre esse nível de suporte transacional. Para que isso funcione em todas as suas "transações", quase tem que ser eventos de negócios (uma venda, uma renovação, uma mudança de propriedade, etc.) em vez de algo como "atualizações de banco de dados" do RPCish.