Estava lendo este post sobre o evento “Falando em Java 09” e percebi que as pessoas estao querendo mostrar quem sabe mais, eh triste ver isto, podiamos nos juntar e dividir/trocar ideias. Diga sim a PAZ.
Voltando ao assunto do topico, parabens ao pessoal da Caelum e terceiros que trabalharam neste evento que nao pude ir, meus parabens!
De fato existem profissionais que vão advogar não utilizar e outros vão (como eu) recomendar a cenários específicos. Vale à pena para quem está procurando mais informações sobre o assunto, ler -
[quote=pcalcado]
Não entendi o que este trecho agregou ao que já foi discutido antes. [/quote]
Shoes, acredito que o trecho colocado pelo Leo reflete o seu sentimento em relação ao Core Business da sua companhia não ser TI, então eles optaram em utilizar um produto que trouxesse benefício no time-to-marketing. Hoje estão com mais de 5 meses de projeto, acredito que a experiência que relatou é válida, no entanto, se quiser; posso trazer outros cases, já que trabalho diretamente envolvido com projetos SOA há algum tempo…
Como disse, TW não publica seus cases, fica difícil analisar ROI por exemplo de uma solução dessa, principal conta que alguns gestores como Leo devem fazer, antes de dar sinal verde à estratégia.
Interessante você ter achado isso no trecho que ele postou. O que eu li foi “ESB traz facilidades de integração para que você não precise escrever estes vocês mesmos” e isso já foi mais que discutido neste tópico, em outros tópicos e nos links que enviei.
[quote=Kenobi]
, no entanto, se quiser; posso trazer outros cases, já que trabalho diretamente envolvido com projetos SOA há algum tempo…
Como disse, TW não publica seus cases, fica difícil analisar ROI por exemplo de uma solução dessa, principal conta que alguns gestores como Leo devem fazer, antes de dar sinal verde à estratégia. [/quote]
Desculpe mas eu não levo a sério “análise” em “cases” deste tipo. Não apenas este tipo de coisa não traz toda a verdade bem como ninguém publica case de projeto que falha. Falo com experiência de quem trabalhou em um projeto utilizand ESB para uma grande mineiradora brasileira que ganhou três prêmios mesmo tendo sido cancelado por ser um fracasso grotesco. E olha que ele foi cancelado antes dos prêmios saírem. Mas quem liga? O que importa é o case publicado.
Aonde você quer chegar com isso? Acredito que como moderador desse fórum publico seja seu papel manter as pessoas dentro do tópico e não incentivá-las a fugir do mesmo. Pelo menos na minha época era assim. De qualquer forma obrigado pela sugestão literária… ou seja lá qual foi sua intenção com isso.
Realmente não deve ter agregado nada para você. Afinal sua santidade já sabe tudo… O trecho que postei foi direcionado para outras centenas de leitores que passarão por aqui. Talvez eles não tenham tempo para fazer uma pesquisa mais aprofundada e clicar em todos os links dessa thread. E talvez para eles ajude em alguma coisa.
Esclarecer por que usei o termo “falácia” anteiormente -algo que o deixou confuso como você mesmo disse.
[quote=leo.luz]
Realmente não deve ter agregado nada para você. Afinal sua santidade já sabe tudo… O trecho que postei foi direcionado para outras centenas de leitores que passarão por aqui. Talvez eles não tenham tempo para fazer uma pesquisa mais aprofundada e clicar em todos os links dessa thread. E talvez para eles ajude em alguma coisa.[/quote]
[quote=pcalcado]
Desculpe mas eu não levo a sério “análise” em “cases” deste tipo. Não apenas este tipo de coisa não traz toda a verdade bem como ninguém publica case de projeto que falha. Falo com experiência de quem trabalhou em um projeto utilizand ESB para uma grande mineiradora brasileira que ganhou três prêmios mesmo tendo sido cancelado por ser um fracasso grotesco. E olha que ele foi cancelado antes dos prêmios saírem. Mas quem liga? O que importa é o case publicado.[/quote]
Concordo com vc nesse ponto. Também já presenciei esse tipo de “encenação” e na maioria dos casos é puro marketing. O objetivo de um case publicado, na maioria das vezes, é comercial mesmo.
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:
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?
De qualquer forma não acredito que exista uma resposta para essas perguntas que seja verdadeira para 100% dos casos. Cabe a vc, tomador de decisão, olhar para sua corporação e entender qual é o seu cenário…
Nem toda solução demanda o uso de um ESB, mas não creio que seja uma minoria expressiva. Quando encaramos um projeto com um escopo pequeno ou na implantação de SOA não vemos as vantagens em termos um ESB, mas quem já trabalhou com legado de serviços sabe bem o quanto faz falta.
Existe uma pressão do player sobre a rede parceiros pra que as soluções abordem o maior numero de produtos sem considerar oq realmente é necessario.
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.
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.
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.
[quote=DaviPiala]
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.[/quote]
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.
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.
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.
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…
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.
[quote=mochuara]
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. [/quote]
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.
Sérgio, eu não consegui entender se vc está se referindo ao ESB como solução rápida e ruim no longo prazo?
[/quote]
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.
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.
[quote=mochuara]
porfavor não venham falar de ESB e disseminar mais fálacias do tipo “sistemas assincronos escalam, sincronos não”. Obrigado.[/quote]
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.