SOA e ESB

SOA e ESB

SOA – A primeira coisa que deve ser entendida sobre SOA (Arquitetura Orientada a Serviços) é que ela não é um produto, mas sim um paradigma – assim como programação orientada a objetos não é um produto, mas sim um paradigma. Muitas empresas tem vendido “soluções SOA prontas”, o que é bastante curioso já que vimos que SOA não é um produto. SOA é algo que se tem de implementar na prática, e, levando-se em consideração a realidade de cada organização. O máximo que tais empresas poderiam fornecer seria, algumas ferramentas, frameworks ou bibliotecas para facilitar a implementação de SOA. Outra coisa importantíssima sobre SOA, é entender o seu escopo: destina-se a grandes sistemas distribuídos que envolvam fornecedores e tecnologias heterogêneas. Se este não for o caso da sua organização, ela não precisa de SOA!

ESB - Enterprise Service Bus, ou barramento de serviços corporativos. Suponha a seguinte situação: uma empresa XPTO possui um sistema corporativo desenvolvido em Java, ela então adquire a empresa OTPX que por sua vez possui um sistema corporativo baseado na tecnologia .NET; o sistema de CRM da empresa XPTO passa a necessitar obter informações dos dois sistemas para poder fazer algum processo de atendimento ao cliente. Existem várias opções para se implementar esta interface: (a) conectar os dois sistemas diretamente; (b) desenvolver um pacote de classes que faça acesso aos dois sistemas; etc.. Com o passar do tempo você acabará com uma situação ingerenciável e caótica na integração dos sistemas. Para evitar isso, entra o papel de ESB, que neste caso seria um "negociador", uma "interface" para a qual você iria solicitar a execução de elementos intermediários que seriam responsáveis 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, e este se encarregaria de se conectar a 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 webservices, mas isso não é regra, existem outras formas de se realizar a mesma atividade. 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 webservices e que se conecta a vários backends usados pela empresa. Como websevices são um padrão de mercado, o seu sistema Java poderia se conectar a esse "ESB.NET" atráves dos webservices 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. A arquitetura
SOA não depende de uma solução ESB para ser montada, mas este quando utilizado pode se tornar o coração desta arquitetura, servindo como ponto de interconexão entre sistemas que usam tecnologias heterogêneas.


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).


Adaptação do texto de Ivan Bosnic (bosnic.ivan@gmail.com) postado no blog http://www.guj.com.br/java/77933-o-que-e-esb