raf4ever wrote: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

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)

Luiz_Gustavo wrote:

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)

Show!!!

fred.ruimdebola wrote:

Luiz_Gustavo wrote:

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)

Show!!!

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

Tecnoage wrote:

fred.ruimdebola wrote:

Luiz_Gustavo wrote:

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)

Show!!!

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

Quando vc fala em performance em tempo real acho discutível... Depende muito do caso...

fred.ruimdebola wrote:

Luiz_Gustavo wrote:

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)

Show!!!

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

Luca wrote: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