bosnic wrote:Prezado raf4ever,
recentemente eu terminei a tradução de um livro sobre SOA, do autor Nicolai M. Josuttis. Sem dúvida é um livro excelente e tenho certeza que fará muito sucesso no mercado brasileiro quando for lançado. Não estou fazendo aqui propaganda do livro, por isso não vou mencionar nem o título nem a editora, e mesmo que o fizesse, eu já ganhei meu dinheiro pela tradução, se o livro irá vender bem ou não, não terá efeito nenhum no meu bolso.
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.

Um grande abraço, Feliz Natal a todos.

Ivan Bosnic (bosnic.ivan at gmail.com)

Tecnoage wrote:Discordando de alguns pontos de vista: (Na verdade não acho que sejam pontos de vista, me parece mais informações que faltaram no resumo)

1- Nem sempre o maior benefício de SOA para as empresas é a integração. Na maioria das vezes o maior benefício é a agilidade na composição de distribuição dos serviços. Vide as ferramentas de BPMN que fazem "transformações automáticas" para fluxos BPEL, por exemplo. Tá certo que muito disso é socado goela abaixo pelos tool vendors.

Tecnoage wrote:
2- Outra grande funcionalidade e na minha opinião uma das mais interessantes funcionalidades do ESB, é a pseudo-centralização dos serviços, que proporciona mecanismos para realização de auditorias, controle dos fluxos de mensagens, verificação mais simples e centralizada de gargalos, etc.

Tecnoage wrote:
3- Segundo o que algém indagou sobre performance: Nao falei de performance pensando exatamente em ESBs, falei pensando emn SOA, devido ao overhead de processamento de xmls ( ou outro formato) de memória, e principalmente de I/O de arquivos texto em vez de streams. (embora para tudo isso exista algum paleativo)

Tecnoage wrote:
4- quanto à utilização do BAM, que alguém citou, uma curiosidade: Va verificou a quantidade de memória que o BAM precisa para funcionar??? hehehe

asaudate wrote:

Tecnoage wrote:Discordando de alguns pontos de vista: (Na verdade não acho que sejam pontos de vista, me parece mais informações que faltaram no resumo)

1- Nem sempre o maior benefício de SOA para as empresas é a integração. Na maioria das vezes o maior benefício é a agilidade na composição de distribuição dos serviços. Vide as ferramentas de BPMN que fazem "transformações automáticas" para fluxos BPEL, por exemplo. Tá certo que muito disso é socado goela abaixo pelos tool vendors.

Discordo. Composição de serviços torna as coisas mais lentas (é sempre mais lento usar ferramentas externas para compor serviços do que a própria linguagem em que estes são desenvolvidos. Ou seja, só se usa, mesmo, composição, quando os serviços são desenvolvidos em linguagens diferentes. O que caracteriza integração).

Tecnoage wrote:
2- Outra grande funcionalidade e na minha opinião uma das mais interessantes funcionalidades do ESB, é a pseudo-centralização dos serviços, que proporciona mecanismos para realização de auditorias, controle dos fluxos de mensagens, verificação mais simples e centralizada de gargalos, etc.

E o controle de SLA, e a aplicação de patterns de EAI, e o baixo acoplamento entre serviços...

Tecnoage wrote:
3- Segundo o que algém indagou sobre performance: Nao falei de performance pensando exatamente em ESBs, falei pensando emn SOA, devido ao overhead de processamento de xmls ( ou outro formato) de memória, e principalmente de I/O de arquivos texto em vez de streams. (embora para tudo isso exista algum paleativo)

Depende da ferramenta utilizada e da capacidade dela. Fazendo uma alusão, JMS também tem overhead entre serialização/desserialização de mensagens. No entanto, uma solução em JMS dá mais agilidade do que se deixar o processamento ser feito de forma assíncrona. No mundo SOA, existem soluções de CEP que só fazem agilizar o processamento. Quanto a I/O de arquivos, acho que você está equivocado. Em SOA, só existe tratamento de arquivos texto como forma de compatibilidade com as antigas práticas de EAI (onde era tudo assim).

Tecnoage wrote:
4- quanto à utilização do BAM, que alguém citou, uma curiosidade: Va verificou a quantidade de memória que o BAM precisa para funcionar??? hehehe

Concordo, às vezes, é uma quantidade absurda. Mas visibilidade compensa o preço de alguns pentes de memória, não?


[]´s!

Tecnoage wrote:
Quando à composição dos serviços. CONCORDO, e sua afirmativa não é contrária à minha, é complementar, talvez. Porém sabemos que em termos de qualquer arquitetura, quando reforçamos segurança, por exemplo, geralmente cai performance. É só um exemplo, a mesma coisa acontece com serviços, isso todo mundo sabe, suponho que ja se deva ler isso nas entrelinhas de algumas arquiteturas.

Tecnoage wrote:
Quanto à parte de performance, onde citei os arquivos texto. Sabemos que isso ocorre, e que deveria funcionar sempre assim, mas vá discutir com qualquer gerente de TI, depois de o pessoal da BEA/WEBLOGIC apresentarem os DBAdapters, TXTAdapters e QUALQUERCOISAADapters, para ver se eles têm a mesma opinião.

Tecnoage wrote:
Quanto à sua última afirmação, remete um pouco à primeira. Dessa mesma maneira, deve ser "pesado" composição de serviços Vs Overhead. Ou seja, NÃO existe arquitetura de Referência em se tratando de SOA, cada cliente é um cliente, cada projeto, um novo projeto... Pensando assim: " O que seria uns pentes de memória a mais perto de toda flexibilidade que SOA oferece à organização (pelo menos como é vendido pra mesma)...

Alto lá... o que eu quis dizer foi que deve-se EVITAR composição de serviços, pela lentidão de desenvolvimento (acho que me expressei mal, anteriormente).