Falando em Java 09 - O que você achou?

leo.luz wrote:
Agora vc citou uma experiência interessante e que talvez possa agregar à discussão. Se vc trabalhou em um projeto que visava a utilização de um ESB, talvez possamos presumir que tratava-se de um projeto SOA. Entendo que seja antiética profissional expor as empresas que trabalhamos, mas o fato mencionado, em relação ao fracasso do projeto, na sua opinião, esteve relacionado puro e simplesmente pela escolha de ter-se utilizado uma solução de ESB ou esteve mais relacionado por questões relacionadas a essa afirmação:

O projeto falhou por inúmeras razões. A -extramente comum- politicagem que se gera ao redor de um ESB que serve de comunicação entre departamentos foi apenas uma delas.

leo.luz wrote:
Não quero ser mal entendido novamente, e o que estou querendo dizer é que o fracasso em um projeto SOA é causado predominantemente pelo fato de uma possível escolha em utilizar-se uma solução ESB ou está mais relacionado com o fato de que o termo SOA, até hoje, seja interpretado de n formas diferentes e que por sua vez as expectativas sejam muito divergentes ou até mesmo conflitantes? A técnologia é a grande vilã, ou são as pessoas envolvidas no projeto que de alguma forma não contribuíram para o sucesso?

Eu não atribui a falha do projeto ao uso de ESB. Já vi projetos de sucesso usando tecnologias inadequadas (EJBs, CORBA, JCA foram exemplos). O que eu disse ao kenobi é que cases não têm valor real. Este, por exemplo, falhou completamente mas foi premiado e é utilizado até hoje pelo fornecedor como estratégia de marketing. Os poucos que sabem o que aconteceu lá dentro não podem falar nada por terem assinado um NDA de trinta páginas.

DaviPiala wrote:
Shoes, sobre a questão dos cases, pra mim como pessoa não agrega em nada, mas os clientes sempre se preocupam em saber onde a empresa esteve, então acaba sendo uma pratica comum no mercado, hoje fiz uma apresentação e tive que falar dos cases anteriores.

Eu entendo sobre você utilizar um case como exemplo de como solucionou o problema X mas para mim, sinceramente, ter isso vindo da boca de um vendedor de soluções (ou de um consultor-como eu) ou de um blog é a mesma coisa: não confie na palavra do autor.

Um outro exemplo foi um projeto onde trabalhei e reduzimos um determinado processo de negócios de quinze dias para quatro horas. A empresa em questão estava a ponto de ser fechada pela proprietária mas quando os "CIO Journal" locais pegaram a notíca o preço da ação disparou. O que ninguém falou para os acionistas é que o processo chegou à durar apenas quatro horas mas por inconpetência do time continuou crescendo em tempo e hoje toma 20 dias. E falha uma de cada três vezes.

This message was edited 2 times. Last update was at 05/06/2009 16:08:52

pcalcado wrote:

Kenobi wrote:
Fazer infra-estrutura de integração, como o cenário BMF-Bovespa pós fusão - 650 sistemas aproximadamente, passando por processos, muitos protocolos e diferentes plataformas, se não utilizar algo como o barramento de serviços, o trabalho fica praticamente inviável.

Tenho que discordar. 90% dos clientes da ThoughtWorks são instituições financeiras (bancos, seguradoras, clearing houses, corretoras, etc.) e fusões e parcerias temporárias são extremamente comum neste setor -ainda mais com a crise. A arquitetura padrão que usamos segue exatamente o que o Jim falou sobre. E funciona.

Uma vantagem de ESB não seria a assincronicidade da coisa, isto é, permitir que o ecossistema escale via plug-and-play, ou seja, adicionar/remover novos serviços de forma totalmente transparente sem qualquer impacto em todo o resto? Além é claro de centralizar toda a zona como a segurança que o Kenobi falou.

Um sistema assíncrono dá um trabalho absurdo, mas o resultado para um sistema de missão crítica é uma robustez, um desacoplamento e uma escabilidade bossal.

No exemplo da fusão BMF-Bovespa, qual seria a solução alternativa a um ESB, comunicação direta e síncrona entre os diversos sistemas? Essa é com certeza a solução mais rápida e menos dolorosa, mas tenho minhas dúvidas se no longo prazo é a melhor. O problema é que tempo é dinheiro e numa fusão dessas a ansiedade para ver os sistemas se comunicando deve ser grande, ou não, o prazo é bastante extenso para tal?

This message was edited 1 time. Last update was at 05/06/2009 16:57:54

saoj wrote:
Uma vantagem de ESB não seria a assincronicidade da coisa, isto é, permitir que o ecossistema escale via plug-and-play, ou seja, adicionar/remover novos serviços de forma totalmente transparente sem qualquer impacto em todo o resto? Além é claro de centralizar toda a zona como a segurança que o Kenobi falou.

Um sistema assíncrono dá um trabalho absurdo, mas o resultado para um sistema de missão crítica é uma robustez, um desacoplamento e uma escabilidade bossal.

No exemplo da fusão BMF-Bovespa, qual seria a solução alternativa a um ESB, comunicação direta e síncrona entre os diversos sistemas? Essa é com certeza a solução mais rápida e menos dolorosa, mas tenho minhas dúvidas se no longo prazo é a melhor. O problema é que tempo é dinheiro e numa fusão dessas a ansiedade para ver os sistemas se comunicando deve ser grande, ou não, o prazo é bastante extenso para tal?

Uma desvantagem de vincular ESBs dessa forma aos sistema criticos da empresa é que soluções de diferentes fornecedores não são compatíveis entre si portanto se uma solução não lhe atende mais tecnicamente, se o fornecedor resolver reajustar o valor das licencas inesperadamente ou por qualquer outro motivo precisar de trocar de fornecedor por o atual não lhe atende você se encontrará de mãos atadas.

Além disso, as qualidades que você menciona na verdade são características de sistemas baseado em eventos e não são exclusivo de soluções ESB. Ou seja, sistemas desse porte precisam de bons arquitetos para avaliar as reais necessidades do cliente e não soluções balas de prata.

This message was edited 1 time. Last update was at 05/06/2009 17:34:33

mochuara wrote:
Uma desvantagem de vincular ESBs dessa forma aos sistema criticos da empresa é que soluções de diferentes fornecedores não são compatíveis entre si portanto se uma solução não lhe atende mais tecnicamente, se o fornecedor resolver reajustar o valor das licencas inesperadamente ou por qualquer outro motivo precisar de trocar de fornecedor por o atual não lhe atende você se encontrará de mãos atadas.

Não entendi. ESB, assim como SOA, é exatamente para resolver esse problema de incompatibilidade entre sistemas. Não entendi o que o xx tem haver com as calças e aonde suas mãos vão ficar atadas aqui.

mochuara wrote:
Além disso, as qualidades que você menciona na verdade são características de sistemas baseado em eventos e não são exclusivo de soluções ESB. Ou seja, sistemas desse porte precisam de bons arquitetos para avaliar as reais necessidades do cliente e não soluções balas de prata.

Baseado em eventos? Acho que vc quiz dizer baseado em mensagens assíncronas...

Pelo que entendi ESB é baseado em mensagens assíncronas e a solução alternativa apresentada não. Mas posso estar enganado aqui...

This message was edited 1 time. Last update was at 05/06/2009 17:56:22

No exemplo da fusão BMF-Bovespa, qual seria a solução alternativa a um ESB, comunicação direta e síncrona entre os diversos sistemas? Essa é com certeza a solução mais rápida e menos dolorosa, mas tenho minhas dúvidas se no longo prazo é a melhor. O problema é que tempo é dinheiro e numa fusão dessas a ansiedade para ver os sistemas se comunicando deve ser grande, ou não, o prazo é bastante extenso para tal?

Sérgio, eu não consegui entender se vc está se referindo ao ESB como solução rápida e ruim no longo prazo?

Se for isso eu discordo, eu acho que no curto prazo o ESB parece que não serve pra nada, mas no longo com as manutenções do catalogo ele começa a dar o retorno.

mochuara wrote:
Uma desvantagem de vincular ESBs dessa forma aos sistema criticos da empresa é que soluções de diferentes fornecedores não são compatíveis entre si portanto se uma solução não lhe atende mais tecnicamente, se o fornecedor resolver reajustar o valor das licencas inesperadamente ou por qualquer outro motivo precisar de trocar de fornecedor por o atual não lhe atende você se encontrará de mãos atadas.

Os ESB são justamente pra dar um barramento de integração entre vários tipos de sistema indepente do Vendor, agora se vc está se referindo ao fato de ESB rodar sobre somente um determinado serviço de aplicação, isso está mudando pelo menos na Oracle, onde já estão prevendo a compatibilidade com Websphere e JBoss no Roadmap da 11G.

This message was edited 3 times. Last update was at 05/06/2009 18:08:59

DaviPiala wrote:

No exemplo da fusão BMF-Bovespa, qual seria a solução alternativa a um ESB, comunicação direta e síncrona entre os diversos sistemas? Essa é com certeza a solução mais rápida e menos dolorosa, mas tenho minhas dúvidas se no longo prazo é a melhor. O problema é que tempo é dinheiro e numa fusão dessas a ansiedade para ver os sistemas se comunicando deve ser grande, ou não, o prazo é bastante extenso para tal?

Sérgio, eu não consegui entender se vc está se referindo ao ESB como solução rápida e ruim no longo prazo?

ESB é interessante mas custoso, trabalhoso e demorado. No longo prazo, com algo tipo OpenESB (sem vendor lock-in) pode ser uma boa, se houver tempo para isso. Eu não entendi (sorry não fui nessa excelente palestra e cheguei atrasado nessa discussão aqui) qual foi a solução alternativa proposta: me parece que foi comunicação síncrona e direta entre as diversas partes? Se foi essa então estaríamos abrindo mão da comunicação assíncrona que tem várias vantagens para sistemas parrudos.

Eu estava querendo ir ao Evento pra conhecer o pessoal do GUJ, mas meu diretor me mandou pra BSB e fiquei lá por duas semanas

Não sei qual foi a alternativa apresentada pelo Jim.

This message was edited 1 time. Last update was at 05/06/2009 19:47:53

Esse tópico já esta ficando confuso. Enquanto ficam dando desculpa de que faltaram o evento (a apresentação está disponivel na internet!!) e não se dão ao trabalho de estudar o que é REST de verdade porfavor não venham falar de ESB e disseminar mais fálacias do tipo "sistemas assincronos escalam, sincronos não". Obrigado.

mochuara wrote:
porfavor não venham falar de ESB e disseminar mais fálacias do tipo "sistemas assincronos escalam, sincronos não". Obrigado.

Ok. Só que eu não falei isso. Falei que sistemas assíncronos escalam melhor do que sistemas síncronos. Decidir quando vale a pena investir no assíncrono é a nossa tarefa.

E a apresentação na Internet tem apenas os slides PowerPoint. Não ajudam muito a entender qual foi a alternativa sugerida.

This message was edited 1 time. Last update was at 05/06/2009 21:32:18

Eu vi a apresentação em ppt, mas mesmo assim não concordo e pronto, li todo o tópico e continuei com a minha antiga opinião.

Não vou postar mais nesse tópico.

Virtual Machine Man Membro desde: 23/10/2007 10:08:29 Mensagens: 684 Offline

pcalcado neste mesmo tópico wrote:Antes de mais nada existem apresentações do Jim Webber disponíveis online...

http://www.infoq.com/presentations/webber-guerilla-soa
http://www.infoq.com/presentations/soa-without-esb

Dei uma olhada nas palestras. Concordo com o que ele falou. Minha dúvida é apenas uma: ESB te dá comunicação assíncrona e por consequencia loose coupling e fault tolerance. Posso não ter captado alguma coisa, mas a solução proposta é aceitar o spagetti (ok) e fazer comunicação síncrona entre as partes (não sei).

Concordo que ESB é um monstro que devemos evitar, mas comunicação assíncrona muitas vezes é a solução mais prudente num grande sistema de missão crítica. Pelo menos no sistema que eu trabalhei não consigo imaginar qualquer outra coisa a não ser mensagens assíncronas.

Virtual Machine Man Membro desde: 23/10/2007 10:08:29 Mensagens: 684 Offline

saoj wrote:Dei uma olhada nas palestras. Concordo com o que ele falou. Minha dúvida é apenas uma: ESB te dá comunicação assíncrona e por consequencia loose coupling e fault tolerance. Posso não ter captado alguma coisa, mas a solução proposta é aceitar o spagetti (ok) e fazer comunicação síncrona entre as partes (não sei).

Concordo que ESB é um monstro que devemos evitar, mas comunicação assíncrona muitas vezes é a solução mais prudente num grande sistema de missão crítica. Pelo menos no sistema que eu trabalhei não consigo imaginar qualquer outra coisa a não ser mensagens assíncronas.

Entendo onde você quer chegar, mas acho que está indo pelo caminho errado. ESBs te dá todo tipo de comunicação, não só assíncrona. E comunicação assíncrona pode ser obtida através da modelagem de workflows assíncronos, mesmo que utilizando um protocolo sincrono como HTTP. Curiosamente achei a apresentação boa por lançar alguma luz justamente nessa questão de como usar a Web para situações assíncronas.

Mais informações sobre workflows em REST, modelando o sistema do starbucks:
http://www.infoq.com/articles/webber-rest-workflow

Só um adendo, como não vi ninguém postando aqui ainda, o pessoal da Locaweb gravou um vídeo com alguns relatos sobre as palestras:

http://vimeo.com/4894074

Notícias, artigos e o maior fórum brasileiro sobre Java