Benefícios de um enterprise service bus

Question

Onde posso encontrar alguma informação sobre os usos e benefícios de um enterprise service bus (ESB)?

Eu estou procurando informações sobre: ??

1. os tipos de problemas e ESB ajuda a resolver
2. as alternativas para um ESB - e as compensações em selecionando entre eles
3. o que você precisa fazer como um desenvolvedor para construir sistemas ESB compatível

Eu estou procurando um nível mais fino de detalhe do que apenas Wikipedia ou folhetos de marketing on-line de fornecedores. Idealmente, um exemplo de código ajudaria a esclarecer o que está envolvido em tirar proveito de um ESB. Informações de uma perspectiva .NET ou Java seria o mais útil.

Graças.

Answer 1

Eu sugiro Para ESB ou não ESB para começar, escrito pelo criador do Mule .

Answer 2

ESB são uma boa maneira de implementar Enterprise Integration .

tipos de problemas que um ESB ajuda a resolver

• Você tem um número de protocolos que você gostaria de normalizar a um único protocolo (por exemplo, FTP, e-mail, SOAP, XMPP, etc, para um sistema de mensagens) por exemplo ActiveMQ. Isso permite que você desacoplar a implementação de serviços a partir do protocolo.
• Você quer uma maneira consistente para ligar serviços para esta arquitetura para que eles possam ouvir as mensagens, mensagens de processo e gerar mensagens (Message terminais, Canal Adaptadores etc.).
• Você pode querer um recipiente conseguiu implantar esses vários componentes em (por exemplo ServiceMix, Mule)
• Você pode querer um número de componentes pré-construídos e adaptadores para vários protocolos (por exemplo ServiceMix, Mule e Camel tem um monte de componentes pré-construídos).
• Você pode exigir muito tempo correndo fluxos de trabalho. Business Process Management é muitas vezes algo que é fornecido ao lado de um ESB (plugs Apache ODE em um número de Open Source ESBs).

Alternativas para um ESB

As alternativas dependem realmente o problema que você está tentando resolver.

• Para fornecer serviços distribuídos, as pessoas costumam usar servidores de aplicativos que expõem serviços através de algum ponto para protocolo ponto RPC (como EJBs mais de RMI ou Web Services através de HTTP). Então, ao invés de colocar uma mensagem em um 'bus', um cliente chama diretamente de um servidor.
• Para responder a protocolos específicos, você pode simplesmente construir um cliente que responde a esse protocolo, por exemplo, escrevendo um aplicativo que escuta para e-mails usando JavaMail ou um que escuta XMPP usando Bater. Se o seu problema é limitado a um ou dois protocolos não pode valer a pena trazer um ESB completo.

O que você precisa fazer como um desenvolvedor para construir sistemas ESB compatíveis

Isso vai depender da ESB você selecionar, embora dado que a maioria dos bons são projetados para chamar em todos os tipos de protocolos, bem como POJOs de acolhimento, não há muito que você precisa fazer construir sistemas compatíveis ESB . Vale a pena tentar fazer o seu assíncrono código.

Por exemplo, Apache Camel tem provavelmente a configuração mais sucinta, aqui está um tutorial .

Answer 3

Três principais vantagens:

• Um ônibus fornece uma maneira para os pontos finais para conectar uns aos outros sem ter que falar diretamente uns aos outros. É simplifica as comunicações para os pontos finais como eles só têm de obedecer a uma interface de comunicação padrão, o ônibus. (Isso é com qualquer ônibus técnica, não apenas ESBs)
• Um ESB fornece um único local para obter algumas métricas-chave de ponto final:. Frequência, disponibilidade e desempenho
• Um ESB tende a fornecer mais do que uma interface de comunicação. No entanto, um desenvolvedor precisa apenas escolher o mais fácil de obter e receber os dados a partir do barramento.

No entanto, certifique-se aqueles que irá fornecer valor do negócio para sua situação. Ter um ESB é a adição de mais uma complexidade para a sua empresa. Idealmente, você não deve escolher este com base em algumas aplicações, mas toda a organização. Deve haver apenas um Produção de aglomerado ESB para a organização.

Alternativas:

• Apenas coisas conectar uns aos outros diretamente especialmente se os protocolos de comunicação são os mesmos. Isso é bom para clusters de aplicativos simples e não requer muito pensamento. No entanto, como o seu número de aplicações de crescer, mantendo as interconexões torna-se difícil.
• Outra alternativa é uma implementação MQ. Isto irá fornecer-lhe uma maneira de enviar dados ao redor sem ter interligações complexas, mas, em seguida, você é forçado a usar apenas um canal de comunicação. Felizmente para Java, eles têm o padrão JMS.

Praticidade:

afirmei as alternativas possíveis. Eles podem parecer ruim no início, mas isso não quer dizer que você não pode começar dessa forma. Eu as coisas pessoalmente gravação para falar com o controle remoto diretamente sem passar por um ESB para ter certeza que funciona sem se preocupar muito com problemas de integração.

Se você não tem um ESB, eu sugiro que você tente Mule para o desenvolvimento e WebSphere ESB para teste e produção. I tendem a usar dois produtos que supostamente seguem padrões para se certificar de que manter os vendedores honestos e para garantir que seus desenvolvedores estão em conformidade com normas que impedem fornecedor inadvertida lock-in.

No final, basta responder a seguinte pergunta:? É a hora de adicionar o pouco de complexidade para simplificar outras complexidades seu valor empresarial o custo no longo prazo

Answer 4

Além dos sites que já foram mencionados. Você deve ler este artigo sobre " não usar um ESB, a menos que seja absolutamente necessário ". Foi escrito pelo CTO da MuleSource, um dos mais popular fonte aberto ESB está disponível. Não é exatamente uma resposta à sua pergunta, mais de fazer um ponto para perguntar a si mesmo "Eu preciso de um ESB"?

Answer 5

Há um decente série de 3 porções em cima da IBM sobre ESB que é bastante conceito orientado e agnóstico fornecedor (na maior parte). Eu encontrei um monte de coisas boas sobre ESB picando em torno do local da IBM. Há também algumas informações decente e vídeos e outras coisas mais na BizTalk .

Answer 6

Confira este Hanselminutes de podcast . Ele responde a algumas perguntas que você deve realmente perguntar a si mesmo antes de implementar um barramento de serviço.

Answer 7

Um enterprise service bus (ESB) é uma arquitetura de software para middleware que fornece serviços fundamentais para arquiteturas mais complexas. Por exemplo, um ESB incorpora as características necessárias para implementar uma arquitectura orientada para serviços (SOA). Num sentido geral, um ESB pode ser pensado no lado do cliente como um mecanismo que gerencia o acesso a aplicações e serviços (especialmente versões legadas) para apresentar um único, simples e consistente interface para usuários finais via Web ou baseada em formulários front-ends.

Em essência, ESB faz para serviços distribuídos heterogêneos back-end e aplicativos e usuários heterogêneo front-end distribuídos e consumidores de informação que middleware é realmente suposto fazer: ocultar a complexidade, o acesso simplifica, permitirá aos desenvolvedores usar formas genéricas, canônicas de consulta , acesso e interação, lidar com os detalhes complexos no fundo. A chave para o apelo de ESB, e possivelmente também seu sucesso futuro, reside na sua capacidade para suportar serviço e aplicativo de integração gradual como impulsionado por requisitos de negócio, não como regido pela tecnologia disponível.

http://searchsoa.techtarget.com/definition/enterprise-service-bus

Enterprise Service Bus (Product)

WSO2 Enterprise Service Bus (ESB) 4.7.0 documentação! WSO2 ESB é um, 100% fonte rápido, leve aberto, e user-friendly ESB distribuído sob a v2.0 Apache Software License. WSO2 ESB permite que administradores e desenvolvedores de sistemas para roteamento convenientemente configure mensagem, mediação, transformação, extração de madeira, agendamento de tarefas, failover, balanceamento de carga e muito mais. Ele suporta os padrões de Integração Empresa mais comumente utilizados (PEI) e permite a comutação de transporte, eventing, mediação baseada em regras, e mediação baseada em prioridade para os requisitos de integração avançados. O tempo de execução ESB é projetado para ser completamente assíncrona, sem bloqueio, e streaming baseado no motor mediação Apache Synapse.

WSO2 ESB é desenvolvido em cima da plataforma WSO2 carbono revolucionário, um framework baseado em OSGi que fornece modularidade perfeita para o seu SOA via componentização. Ele inclui muitos recursos e componentes opcionais (add-ons) você pode instalar no ESB, e você pode facilmente remover recursos não necessários em seu ambiente, permitindo assim que você totalmente personalizar e adaptar WSO2 ESB para atender às suas necessidades de SOA exatas.

Arquitetura infra-estrutura de aplicação sobre as empresas podem ser inerentemente complexa, compreendendo centenas de aplicações com completamente diferentes semântica. Alguns desses aplicativos são construídos, alguns são adquiridos de terceiros, e alguns podem ser uma combinação de ambos e pode operar em ambientes de sistemas diferentes.

A integração entre essas aplicações heterogêneas é vital para a empresa. Diferentes serviços pode estar usando diferentes formatos de dados e protocolos de comunicação. locais físicos de serviços pode mudar arbitrariamente. Todas estas restrições significa que seus aplicativos ainda estão fortemente acoplados juntos. Um ESB pode ser usado para soltar esses acoplamentos entre diferentes serviços e consumidores de serviços.

WSO2 ESB é um ESB de pleno direito, pronto para empresas. Ele é construído sobre o projeto Apache Synapse, que é construído usando o projeto Apache Axis2. Todos os componentes são construídos como pacotes OSGi.

Answer 8

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.

Answer 9

lá é zero razão para usar um ESB. Não fazê-lo. complexidade desnecessária. Por que passar por um intermediário, quando você pode ir direto? O pessoal ESB irá dizer-lhe ponto a ponto é ruim, mas de alguma forma ponto a ponto de e para o ESB é bom.

Answer 10

A primeira pergunta que você precisa perguntar é porque você precisa de um ESB?

ESB é normalmente usado em SOA Evento arquiteturas distribuídas, que parecem ser uma buzzword quente hoje em dia. Antes de saltar para ESB deixe-me lembrá-lo de Fowler Primeira Lei de Martin de Sistemas de distribuição:

http://martinfowler.com/bliki/FirstLaw.html

"Minha Primeira Lei da Distribuído objeto de design:. Não distribua seus objetos (de P da EAA)

O capítulo relevante está disponível online. "

Quando você estiver construir um novo sistema, o aspecto mais importante é que é à prova de futuro, o que significa fácil escalabilidade e facilidade de manutenção. Se você construir seu sistema em torno do conceito de serviços soltos com contrato estático definido distribuídos em um ambiente de rede, você pode "esconder" a arquitetura que você deseja para esse serviço específico, porque as interfaces ainda estão lá.

ESB está perto relacionada com asyn sistemas de mensagens, por isso antes de começar a saltar para esse tipo de aplicação, saber que uma arquitetura não tem que ser homogênea, ou seja todos os serviços serem implementadas da mesma forma, NÃO FAZEM começar o maior erro que está distribuindo o seu sistema desde o início, você só deve distribuir como você precisa de escala, não antes da mão. O que você precisa ter certeza, porém, é que os seus serviços deve ser capaz de ser facilmente distribuído em caso de necessidade surgir, sem quebrar quaisquer contratos que significaria, alterações aos clientes desse serviço.

Como para os benefícios da ESB, eles são os mesmos que SOA, ESB acrescenta contexto de mensagens asyn (eventos) operações.

Answer 11

Primeiro deixe-me explicar SOA . É ele sobre a construção de uma arquitetura como um conjunto de módulos de software reutilizáveis ??expostos como “Serviços” com interfaces bem definidas. Os serviços de facilitar o acoplamento frouxo e abstrai os detalhes de implementação dos clientes.

SOA pode acabar-se confuso se cada componente chamado serviços diretamente. Por isso, tem os seguintes problemas comuns.

• Como você acha que os serviços são utilizados e quais não são?
• Como você encontra os clientes usando um serviço particular?
• Como você rola para fora atualizações a um serviço ou expor novas versões para os serviços existentes, sem interrupção?
• Como você suportar compatibilidade com versões anteriores para clientes mais antigos invocando interfaces de serviço mais velhos
• Como você executar o log, auditoria, fiscalização de segurança etc em todos os serviços para o tráfego interno / externo?

O ESB é a solução para questões acima. ESB ...

• Ajuda traz a fim
• Pode fazer cumprir rigorosamente as políticas corporativas
  • por exemplo. Segurança, estrangulamento, auditoria etc aplicado consistentemente
• virtualiza terminais de serviço
  • Facilitar versões, atualizações flexíveis, HA / Load Balancing etc.
• Execute o encaminhamento, mediação, transformação, etc

Alguns casos de uso de exemplo pode ser encontrado aqui . Note que eles são do site do desenvolvedor do AdroitLogic e estritamente juntamente com UltraESB, ESB do AdroitLogic.