Pessoal,
estou estudando sobre SOA e até pensando em fazer a prova da IBM sobre o assunto.
Mas não consigo entender o que é um ESB na prática,apesar dos vários materiais a respeito que tenha lido.Alguém tem
uma explicação simples que possa me dar?
Grato
[quote=raf4ever]Pessoal,
estou estudando sobre SOA e até pensando em fazer a prova da IBM sobre o assunto.
Mas não consigo entender o que é um ESB na prática,apesar dos vários materiais a respeito que tenha lido.Alguém tem
uma explicação simples que possa me dar?
Grato[/quote]
Cara,
nunca tinha ouvido falar em ESB. Li a Mundo Java deste mês e hoje jah entendo o que é, na teoria e na prática. Pode ser um caminho pra vc…
Mas de fato, o que vc não entendeu?
[]'s
Fiz uma pesquisa pequena na faculdade sobre esse assunto…Bem na me aprofundei bastante mas ESB é uma linguagem para programação de webservces(acredito que é isso)… e como vc esta interessado em fazer a certificação, aconselho vc a ler a revista portalBPM, http://www.portalbpm.com.br/, é uma revista nova no mercado, bimestral e muito boa…
at
ESB - Enterprise Service Bus não é uma linguagem de programação para Webservices. Imagine ESB como um Hub utilizado em sua rede de computadores tradicional, mas com muitas outras caracteristicas.
Ele permite customizações no serviço de mensagens, isto é ele é um Mediador. Como ele você é capaz de fazer validações e roteamento de mensagens baseado no conteúdo da mensagem por exemplo. Uma outra caracteristica, você pode ter um produtor produzindo mensagens em um formato e ter um consumidor consumindo em outro formato. o ESB faz essa conversão pra você.
ESB permita um baixo acoplamento entre sistema visto que um sistema de origem não precisa conhecer o sistema de destino. Ele também faz controles de acesso de sistemas externos e permite configurar segurança das mensagens por exemplo, usando encriptação.
Bom a ideia inicial é mais ou menos essa!
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)
Pessoal,
acho que ficou bem clara a explicação a respeito de SOA(que eu já sabia do que se tratava) e principalmente ESB,que sempre foi meu principal
ponto de dúvida a respeito desse novo paradigma.
Abraço a todos,
Rafael Roque
[quote=bosnic]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)[/quote]
Show!!!
[quote=Luiz_Gustavo][quote=bosnic]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)[/quote]
Show!!![/quote]
Mto bom mesmo, mas ainda seguem algumas dúvidas:
01 - Do ponto de vista do reaproveitamento de funcionalidades, performance em tempo real e da delegação de responsabilidades, SOA é interessante, certo?
Exemplo: Tenho em meu sistema 5 sistemas desktop e uns 5 formularios de web que precisam enviar informações para entregar um pedido… seria certo dizer que colocar isto como serviço seria melhor que uma jar (acessar via serviço ao invés de importar classes)? Ainda mais… poderia delegar um desenvolvedor ou um time apenas para este processo e cobrar eles com relação a KPIs? (chefe: - o processo tah ferrando em 5 segundos todas requisições de logística… trabaaaalhem!!!) Ainda essas KPI’s com um BAM poderiam dar aos Gerentes e Diretores de uma empresa dados em tempo real de requisições a um serviço…
Imagino que com jar talvez isso seja possível, mas levaria tempo pra kct pra fazer algo que com SOA seria muito mais simples… mas tá certo que pra implantar SOA, é um parto :D. Porém analisar o negócio em tempo real… acho muito difícil na arquitetura tradicional… Tendo em vista que no SOA, é só monitorar as requisições e respostas no ESB e gerar uns gráficos chiques em tempo real…
02 - Do ponto de vista do ESB… ele pode ter alguns serviços vistos por “fora” (entenda aqui exposto a web)?ele pode parsear informações que vão aos webservices?
Exemplo: O cliente gostaria que informações dos servidores fossem baixadas em tempo real via AJAX. Então para isto, ele faz um httpRequest direto ao ESB. O ESB parseia o retorno e manda um JSON ou um XML.
[quote=fred.ruimdebola][quote=Luiz_Gustavo][quote=bosnic]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)[/quote]
Show!!![/quote]
Mto bom mesmo, mas ainda seguem algumas dúvidas:
01 - Do ponto de vista do reaproveitamento de funcionalidades, performance em tempo real e da delegação de responsabilidades, SOA é interessante, certo?
Exemplo: Tenho em meu sistema 5 sistemas desktop e uns 5 formularios de web que precisam enviar informações para entregar um pedido… seria certo dizer que colocar isto como serviço seria melhor que uma jar (acessar via serviço ao invés de importar classes)? Ainda mais… poderia delegar um desenvolvedor ou um time apenas para este processo e cobrar eles com relação a KPIs? (chefe: - o processo tah ferrando em 5 segundos todas requisições de logística… trabaaaalhem!!!) Ainda essas KPI’s com um BAM poderiam dar aos Gerentes e Diretores de uma empresa dados em tempo real de requisições a um serviço…
Imagino que com jar talvez isso seja possível, mas levaria tempo pra kct pra fazer algo que com SOA seria muito mais simples… mas tá certo que pra implantar SOA, é um parto :D. Porém analisar o negócio em tempo real… acho muito difícil na arquitetura tradicional… Tendo em vista que no SOA, é só monitorar as requisições e respostas no ESB e gerar uns gráficos chiques em tempo real…
02 - Do ponto de vista do ESB… ele pode ter alguns serviços vistos por “fora” (entenda aqui exposto a web)?ele pode parsear informações que vão aos webservices?
Exemplo: O cliente gostaria que informações dos servidores fossem baixadas em tempo real via AJAX. Então para isto, ele faz um httpRequest direto ao ESB. O ESB parseia o retorno e manda um JSON ou um XML.
[/quote]
Quando vc fala em performance em tempo real acho discutível… Depende muito do caso…
[quote=Tecnoage][quote=fred.ruimdebola][quote=Luiz_Gustavo][quote=bosnic]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)[/quote]
Show!!![/quote]
Mto bom mesmo, mas ainda seguem algumas dúvidas:
01 - Do ponto de vista do reaproveitamento de funcionalidades, performance em tempo real e da delegação de responsabilidades, SOA é interessante, certo?
Exemplo: Tenho em meu sistema 5 sistemas desktop e uns 5 formularios de web que precisam enviar informações para entregar um pedido… seria certo dizer que colocar isto como serviço seria melhor que uma jar (acessar via serviço ao invés de importar classes)? Ainda mais… poderia delegar um desenvolvedor ou um time apenas para este processo e cobrar eles com relação a KPIs? (chefe: - o processo tah ferrando em 5 segundos todas requisições de logística… trabaaaalhem!!!) Ainda essas KPI’s com um BAM poderiam dar aos Gerentes e Diretores de uma empresa dados em tempo real de requisições a um serviço…
Imagino que com jar talvez isso seja possível, mas levaria tempo pra kct pra fazer algo que com SOA seria muito mais simples… mas tá certo que pra implantar SOA, é um parto :D. Porém analisar o negócio em tempo real… acho muito difícil na arquitetura tradicional… Tendo em vista que no SOA, é só monitorar as requisições e respostas no ESB e gerar uns gráficos chiques em tempo real…
02 - Do ponto de vista do ESB… ele pode ter alguns serviços vistos por “fora” (entenda aqui exposto a web)?ele pode parsear informações que vão aos webservices?
Exemplo: O cliente gostaria que informações dos servidores fossem baixadas em tempo real via AJAX. Então para isto, ele faz um httpRequest direto ao ESB. O ESB parseia o retorno e manda um JSON ou um XML.
[/quote]
Quando vc fala em performance em tempo real acho discutível… Depende muito do caso…[/quote]
Porque discutível?
(ainda to meio no discurso de venda do SOA… não cheguei a trabalhar na prática com isto… acredito que a maioria não… fiz alguns testes com BAM e vi isto funcionando… )
[quote=fred.ruimdebola][quote=Luiz_Gustavo][quote=bosnic]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)[/quote]
Show!!![/quote]
Mto bom mesmo, mas ainda seguem algumas dúvidas:
01 - Do ponto de vista do reaproveitamento de funcionalidades, performance em tempo real e da delegação de responsabilidades, SOA é interessante, certo?
Exemplo: Tenho em meu sistema 5 sistemas desktop e uns 5 formularios de web que precisam enviar informações para entregar um pedido… seria certo dizer que colocar isto como serviço seria melhor que uma jar (acessar via serviço ao invés de importar classes)? Ainda mais… poderia delegar um desenvolvedor ou um time apenas para este processo e cobrar eles com relação a KPIs? (chefe: - o processo tah ferrando em 5 segundos todas requisições de logística… trabaaaalhem!!!) Ainda essas KPI’s com um BAM poderiam dar aos Gerentes e Diretores de uma empresa dados em tempo real de requisições a um serviço…
Imagino que com jar talvez isso seja possível, mas levaria tempo pra kct pra fazer algo que com SOA seria muito mais simples… mas tá certo que pra implantar SOA, é um parto :D. Porém analisar o negócio em tempo real… acho muito difícil na arquitetura tradicional… Tendo em vista que no SOA, é só monitorar as requisições e respostas no ESB e gerar uns gráficos chiques em tempo real…
02 - Do ponto de vista do ESB… ele pode ter alguns serviços vistos por “fora” (entenda aqui exposto a web)?ele pode parsear informações que vão aos webservices?
Exemplo: O cliente gostaria que informações dos servidores fossem baixadas em tempo real via AJAX. Então para isto, ele faz um httpRequest direto ao ESB. O ESB parseia o retorno e manda um JSON ou um XML.
[/quote]
fred.ruimdebola,
Não entendi muito bem o primeiro ponto levantado por você.
Em relação sua segunda pergunda. Sim. Você consegue fazer uma integração com um site ou algo assim. Se utilizar AJAX fica melhor ainda, pois ae você aciona um WS do seu ESB que tem por objetivo trazer os seus dados.
O bom do conceito de ESB (JBI também entra nessa) é que caso você queira utilizar um protocolo específico, nada impede que você crie um componente para isso.
A grande saca do ESB na minha opinião é que ele tende a quebrar o “emaranhado” de programas de integração, pois sem a utilização de uma camada como essa, você tera que desenvolver “N-1” programas para integrar seus sistemas, sendo q N é a quantidade de sistemas que você tem.
A especificação dele, sendo bem grosseiro, é algo como o conceito de um Switch de rede, onde você controla o destino (roteamento) dos pacotes de rede.
Caso tenha interesse em estudar ESB, aconselho a ler algo sobre JBI também.
Trabalho com o Apache ServiceMix ( http://servicemix.apache.org/ ), ele é um dos ESB`s de mercado desenvolvidos em Java. Outro deles é o Open-ESB.
O que é mais importante você lembra é que SOA, ESB, JBI são conceitos, paradigmas assim como Orientação a Objeto e não produtos. O principal é verificar se estas tecnologias e conceitos valem ou não ser empregados no seu caso, afinal, construir, migrar, customizar um produto com esses conceitos para sua necessidade tomam tempo, não só de estudo do conceito mas como de desenvolvimento/adaptação. Ai entra no caso de querer “usar uma bazuca para matar uma formiga”… hehehe…
Ats,
Endrigo Antonini
muito boa explicação Ivan, parabéns!
Uma outra solução do mercado para SOA é da IBM que possui um servidor que também tem dentro dele um ESB
lá no trabalho dentro em breve vou ter que mexer com essas ferramentas…
Olá
O que é show, mas show mesmo é a apresentação Does My Bus Look Big in This?
Meninos, não usem ESBs só porque a IBM diz que é bom. O uso de um ESB tem lá sua utilidade mas pensem muito bem antes basear sua arquitetura no uso de um deles. A maioria dos big vendors tem fortes interesses para convencer as empresas a usá-los. Procurem ler opiniões isentas e estudar casos de uso independentes dos big vendors (que enfiam em tudo quanto é canto)
[]s
Luca
[quote=Luca]Olá
O que é show, mas show mesmo é a apresentação Does My Bus Look Big in This?
Meninos, não usem ESBs só porque a IBM diz que é bom. O uso de um ESB tem lá sua utilidade mas pensem muito bem antes basear sua arquitetura no uso de um deles. A maioria dos big vendors tem fortes interesses para convencer as empresas a usá-los. Procurem ler opiniões isentas e estudar casos de uso independentes dos big vendors (que enfiam em tudo quanto é canto)
[]s
Luca[/quote]
Concordo com o que o colega Luca comentou… Eh de extrema importancia que voce adote um ESB por indentificar a necessidade da utilizacao e nao apenas por que o fornecedor quer que voce use-o… Cada caso tem que ser analisado levando em conta todos os fatores possiveis e imaginaveis… As vezes a utilizacao de um ESB apenas ira dificultar o seu trabalho pois tem muito recurso que nao sera utilizado ou falta de conhecimento da ferramenta mesmo…
A hora que eu chegar na empresa amanha eu dou uma olhada no video, mas pelo titulo parece ser bem interessante…
Ats,
Endrigo Antonini
Olá
Reli minha mensagem e me pareceu que alguém poderia pensar que eu não gostei do texto do Ivan Bosnic quando disse que show mesmo é a apresentação do Jim Webber & Martin Fowler.
Que fique claro 2 coisas:
O texto do Bosnic está ótimo
A apresentação que indiquei é realmente um show. Assistam e vejam uma performance de 2 artistas na arte de apresentar idéias. Mesmo achando que eles misturaram assuntos sem outra necessidade senão fazer marketing da TW e foram um tanto radicais, a apresentação é ótima.
[]s
Luca
[quote=bosnic]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)[/quote]
Muito boa explicação.
" ESB é o coração de uma arquitetura SOA, é o ponto de interconexão entre sistemas que usam tecnologias diferentes. "
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.
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.
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)
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
[quote=Tecnoage]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.
[/quote]
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).
E o controle de SLA, e a aplicação de patterns de EAI, e o baixo acoplamento entre serviços… 
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).
[quote=Tecnoage]
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[/quote]
Concordo, às vezes, é uma quantidade absurda. Mas visibilidade compensa o preço de alguns pentes de memória, não? 
[]´s!
[quote=asaudate][quote=Tecnoage]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.
[/quote]
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).
E o controle de SLA, e a aplicação de patterns de EAI, e o baixo acoplamento entre serviços…
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).
[quote=Tecnoage]
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[/quote]
Concordo, às vezes, é uma quantidade absurda. Mas visibilidade compensa o preço de alguns pentes de memória, não?
[]´s![/quote]
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.
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.
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).
Sim, mas as pessoas devem ser instruídas em relação às melhores práticas, não ? Normalmente, as pessoas tendem a utilizar o mundo que elas já conhecem, que é o de EAI via texto (ou BD ou XYZ). No entanto, numa filosofia SOA sabemos que a melhor coisa a se fazer é integração via serviços, certo?
Eu trabalho com ferramentas Oracle (que comprou a BEA e levou o Weblogic, Aqualogic e tudo o mais). Logo, tenho à minha disposição todos estes adapters. Mesmo assim, instruímos o cliente a deixar disponível a integração tanto com arquivos texto quanto com serviços, pois acreditamos que ainda existe, sim, quem prefira fazer integração com arquivos de texto, mas a tendência é que isso diminua e as pessoas façam com serviços (em geral, gerentes e pessoas ligadas à administração de TI têm certa resistência a tecnologias relativamente novas, como SOA).
[quote=Tecnoage]
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)…[/quote]
Eu não falei a respeito de composição de serviços, falei de BAM. Normalmente, os benefícios do BAM não chegam nem perto do custo de alguns pentes de memória (1 ou 2, não um datacenter inteiro). E a flexibilidade de SOA é uma tendência a médio e longo prazo, não no curto prazo. Afinal, insisto… SOA é uma arquitetura de integração. Sistemas que estão em fase de desenvolvimento, expondo e consumindo serviços, tendem a ser apenas SOA-Ready, e não SOA.
[]´s