Original: http://www.guj.com.br/posts/list/77933.java
Encontrei no forum uma explicação bastante clara sobre o assunto, leiam...
Pois bem. Primeira coisa que deve ser entendida sobre SOA (Arquitetura Orientada a Serviços) é que SOA não é um produto, ela é simplesmente um paradigma. Do mesmo jeito que programação orientada a objetos é um paradigma, e não um produto. Dito isso, outro ponto importante a ser levado em consideração é que SOA está na moda. Por isso você verá muitas empresas por aí (IBM, Oracle, BEA e outras) vendendo SOA, empurrando SOA para os seus clientes goela abaixo. Isso é uma enganação. SOA não é um produto e portanto não pode ser vendida. SOA é algo que você terá que implementar na prática, por si só, ou junto com a sua equipe de desenvolvimento. O que essas empresas podem lhe fornecer será no máximo algumas ferramentas, frameworks, bibliotecas para facilitar o seu trabalho.
Outro ponto importantíssimo é entender se você realmente precisa de SOA, ou seja, quando é que SOA se torna necessária de fato?
SOA é um paradigma para grandes sistemas distribuídos de proprietários e tecnologias diferentes! Se este não for o seu caso, você não precisa de SOA!
Voltando agora para a sua pergunta e levando em consideração as afirmações acima:
O que é um ESB (Enterprise Service Bus)?
Nada melhor para explicar um conceito "novo" do que através de um exemplo. Suponha a seguinte situação. Uma empresa X possui um sistema de grande porte desenvolvido em Java (JEE, EJB e outros). Essa empresa X adquire uma empresa Y que por sua vez utiliza tecnologia .NET. A empresa possui um sistema de CRM que necessita, por alguma motivo, obter informações dos dois sistemas para que possa fazer algum processo de atendimento ao cliente. Para fazer isso você teria várias opções, poderia conectar os dois sistemas diretamente, poderia desenvolver uma classe (ou todo um pacote de classes) que faça acesso aos dois sistemas.
Com tempo, à medida que surgissem outras necessidades de conectar esses dois sistemas, você acabaria por ter uma confusão geral de sistemas acessando outros sistemas. Um caos de verdade. Para evitar isso, entra o papel de ESB, que neste caso seria um "negociador", seria uma "interface" para a qual você iria solicitar a execução de alguns processos, consultas, etc. Ou seja, um elemento intermediário que seria responsável por conectar sistemas diferentes. O seu sistema Java nem tomaria conhecimento de que o outro sistema é feito em .NET ou em qualquer outra tecnologia, porque ele se comunicaria apenas com o ESB, o qual por sua vez teria o papel de se conectar a esses outros sistemas. Resumidamente, ESB seria uma abstração dessa interconexão de sistemas que usam tecnologias diferentes.
A maneira mais comum de se implementar um ESB hoje é através de Web Services, mas isso não é regra, existem outras formas de se realizar a mesma atividade. (ESB <> Web Services).
Se ainda não está claro o que é um ESB, vamos tentar entrar mais na parte prática da coisa, vamos imaginar o que poderia ser um ESB. Ele poderia muito bem ser um sistema "independente" desenvolvido em .NET que disponibiliza uma séria de Web Services e que se conecta a vários backends usados pela empresa. (Usei exemplo de .NET em um fórum Java de propósito, para destacar que SOA é independente de tecnologia usada). Como Web Sevices são um padrão (tudo bem que esse padrão ainda possui diversas coisas "não padronizadas", mas é possível seguindo boas práticas e alguns padrões já estabelecidos alcançar um resultado bom), o seu sistema Java poderia se conectar a esse "ESB.NET" atráves de Web Services e obter o resultado desejado.
Só para concluir e para ficar bem claro:
SOA é um paradigma e não um produto.
Se alguém chegar dizendo que tem uma solução SOA pronta para sua empresa, isso é mentira.
ESB é o coração de uma arquitetura SOA, é o ponto de interconexão entre sistemas que usam tecnologias diferentes.
SOA está na moda, cuidado ao adquirir "produtos prontos".
Web Services são apenas uma maneira dentre outras para implementar tal arquitetura (embora de longe a mais usada).
Espero ter esclarecido para você e para outros leitores deste fórum alguns conceitos de SOA.
Nenhum comentário:
Postar um comentário