Eu posso até discordar fortemente de algumas opiniões do Kenobi, mas tenho que tirar o chapéu pro cara por duas coisas:
Seria muito mais fácil deixar as convicções de lado e concordar com a opinião de muita gente de peso da comunidade, que acredita na maré “rest sim, esbs pesados não”. Mesmo assim o Kenobi mantém a opinião contrária ao que parece ser a tendência. Ponto positivo pela personalidade forte e por não ser maria-vai-com-as-outras.
Por isso:
Perfeito. Opinião sensata de qualquer bom arquiteto/desenvolvedor/tomador de decisão e serve para qualquer tecnologia/discussão.
Isso pode ser feito facilmente em qualquer aplicação web. Na verdade a maioria dos grandes sites tem um mecanismo exatamente como este e não precisa de um ESB ou nada do tipo, apenas load-balancers.
Não sei exatamente o que você quer dizer por segurança centralizada já que isto é bem simples de fazer em qualquer aplicação HTTP. SLA, dependendo do que você quer dizer, também é algo que qualquer aplicação web de grande porte já faz.
Transformações de mensagens também são bem simples de serem feitas, basta você plugar seu engine favorito -e te garanto que o meu não é XSTL- na camada web do seu serviço e transformar no formato que você quer. Você pode criar um formato intermediário para tráfego, se for o caso, mas isso não requer um barramento “inteligente”.
Concordo. O ponto do Jim, creio, é que você quase sempre consegue os benefícios que o ESB teoricamente traria sem pagar o preço de ter um ESB (“não olhe dentro da caixa!”). O maior problema do ESB na minha experiência não é sequer técnico. Ele se torna um mecanismo político, qualquer mudança envolve tanto trabalho que as coisas que eram para ser baratas dada a flexibilidade da coisa ficam imposíveis de serem feitas. Neste contexto é muito parecido com usar um banco de dados relacional para integração.
Pode sim. O fluxo está parado até você disparar um comando para a URI de callback -o estado está mantina na URI. Você pode, inclusive, passar esta URI para outros processadores. Recentemente eu fiz exatamente isso em uma aplicação que era meio que uma mistura entre MapReduce e Amazon Mechanical Turk.
O que REST não tem é uma ferramenta para isso, você vai ter que fazer praticamente tudo manualmente.
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.
Estou me referindo a qualquer tipode aplicação, inclusive aquelas que estão fora do protocolo HTTP. Um dos maiores papéis do ESB é atuar como ferramenta de integração. Sei que temos JBI, JCA como adaptadores entre outras tecnologias, mas ele é um mecanismo que em muitos casos já vem com a implementação e facilita bastante a integração com aplicativos - Siebel, SAP, JDE e por aí vai…
Fazer Throttling é para serviços é completamente diferente das soluções convencionais de Load Balance. Não sei qual solução você se refere, mas é um mecanismo que auxilia muito em cenários de integração, quando o cliente tem uma previsão de troca de máquinas no futuro, então se pode projetar um serviço para um número X de requisições e à medida que se tem infra, você solta o processamento.
Não isso definitvamente não é simples. Pode ser do ponto de vista tecnológico mas não cultural e por isso não está implementado na grande maioria (90%) das empresas que andei visitando nos últimos meses. Essa é uma maneira simples e eficiente de conseguir que todos os serviços adotem a mesma política de segurança.
Como a Aplicação já faz ? Então você inseriu interesse ortogonal e aumentou o ciclo de desenvolvimento ? Como você extrai métricas para Capacity Plan ? Você pode criar uma camada com AOP em cima das suas implementações, mas se tiver processos BPEL , fazendo um WorkFlow por exemplo, seu framework de coleta vai ter “parte” das informações.
Ainda há outras áreas de cobertura como QoS - quality of service.
Primeiramente não disse que XSLT é meu favorito, até pq prefiro utilizar XQuery e aí você tem inúmeras opções de engines, o barramento vai lhe dar alguns padrões pré-prontos, como SWIFT para o mercado financeiro, editores visuais entre outros ( aí estou falando de produto específico, concordo que não tem muito haver com ESB, entretanto é bom lembrar que estão evoluindo e se um player adiociona uma característica boa, logo os outros o seguem).
Bom continuo achando que há cenários que o ESB não necessários e outros completamente. “Olhar dentro da caixa”, tem muito mais haver com modelagem coerente e não com produto. Se modelar errado, fracionar demais, não tiver controle sobre versão de serviços entre outros, vai virar uma zona. Assim como também se pode fazer inúmeras cagadas numa arquitetura REST.
Um ponto que fico na dúvida, é que REST não é governado por um modelo de interface, com contrato definido. Como fica uma solução que permeia diversos departamentos de uma companhia. Como os programadores “sabem” qual a versão correta do serviço a ser utilizada ? E se tiver mais de uma ?
O Exemplo continua sendo Coreografia, já que vai manter a requisição até chamar o próximo serviço. Agora manter estado de variáveis, chamando diversos serviços e consolidar no final ? Como se faz isso com REST ? Pode até dar, mas deve dar um trabalho danado, aí entra aquele conceito, “Ferramenta certa, para o problema certo” e aí que defendo o ESB para muitos cenários.
[quote=pcalcado]
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.[/quote]
Gostaria de ver papers de arquitetura da ThoughtWorks sobre como resolveram determinados problemas. Sei que empresas que “vendem” as soluções, possuem cases e matérias publicadas.
Principalmente nessa questão de integração com plataformas heterogêneas, como aplicações C-C++, Mainframe e por aí vai … fora os produtos de mercado, SAP, Siebel, EBS…
[quote=Fabio Kung]Eu posso até discordar fortemente de algumas opiniões do Kenobi, mas tenho que tirar o chapéu pro cara por duas coisas:
Seria muito mais fácil deixar as convicções de lado e concordar com a opinião de muita gente de peso da comunidade, que acredita na maré “rest sim, esbs pesados não”. Mesmo assim o Kenobi mantém a opinião contrária ao que parece ser a tendência. Ponto positivo pela personalidade forte e por não ser maria-vai-com-as-outras.
Por isso:
Perfeito. Opinião sensata de qualquer bom arquiteto/desenvolvedor/tomador de decisão e serve para qualquer tecnologia/discussão.[/quote]
Agradeço as citações e fico bastante lisonjeado com a declaração :-).
Sei que na comunidade, muitos seguem os Agilistas e empresas como TW. Entretanto há outra corrente no mercado corporativo, onde se dá até mais valor ao Processo de Negócio, do que a implementação. Muitas empresas não estão olhando como as coisas são feitas no nível mais baixo, estão optando por um modelo de desenvolvimento aderente ao negócio.
Estas muitas vezes possuem seus próprios processos errôneos e com algumas ferramentas ( técnicas) como BPA, conseguem enxergar melhor a cadeia de valor e vão descendo isso ao nível de BPM, BPEL, implementação dos contratos, serviços, KPís - indicadores de performance ( mas aqui me refiro muito mais à negócios), olhar gargalo do meu processo de negócio, por exemplo, um banco tem uma janela de tempo até às 17h para completar uma operação, onde se concentra a maior parte do problema.
Por fim, aliar os dois mundos, é uma tarefa árdua, ainda mais quando se quer manter boas práticas de desenvolvimento. Tento me manter aberto, olhar pra REST, JSON entre outras tecnologias como Grid de Dados, quando enxergo que vai empregar valor de verdade ao meu cliente. Fiquei com Hypermedia na cabeça e o que Jim falou sobre JMS x ATOM, realmente, Atom pode ser uma forte tendência de escolha nas minhas próximas aventuras
[quote=le-silva]Eu achei o evento muito show de bola e, como o saoj disse, a Caelum é uma empresa realmente muito séria e competente em materia de treinamento. Das que eu conheço, IMHO, é a melhor. (Já participei de 2 treinamentos e 1 workshop lá.)
Achei a apresentação do Jim sobre SOA muito interessante e totalmente descompromissada com vendors. (Mais uma vez, IMHO, o problema dos “consultores SOA” é rabo-preso - sem ofensas, só pra usar uma expressão popular - com vendors de “ferramentas para SOA”.)
Registrei minha opinião mais detalhada no meu blog:
PS: Eu sei que alguns podem discordar dos termos que eu use: “consultores SOA” e “ferramentas para SOA”. Mas por favor, não vamos começar uma discução aqui em cima desses termos. O tema aqui é outro. :)[/quote]
Leandro, sabes que trabalho diretamente para a Oracle, entretanto sou um cara bastante razoável e não defenderia a tecnologia e conceito se não acreditasse bastante. Posso até estar equivocado, mas minha motivação é técnica e ideológica, pois acredito verdadeiramente que muitas das tecnologias que “vendo” como você se referiu, trazem real benefício ao design da minha solução.
Tá, mas eu (e muito provavelmente o Jim) estou falando de web services que rodam sobre HTTP.
Como falei, qualquer aplicação web de grande porte (e boa parte das de médio) faz isso.
Eu estou falando de tecnologia aqui, como achei que tinha ficado claro. O único ponto em que falei de caráter social/político foi sobre a comparação entre ESB e bancos centralizados para integração.
Desculpe mas se você não reduzir o número de buzzwords por minuto fica difícil continuar este assunto. Eu sei que você é um desenvolvedor de sistemas competente e sabe que não só é extremamente simples fazer uma aplicação coletar este tipo de métrica bem como a implantação de um ESB com este recurso “de graça” é bastante complexa. Qual seu ponto?
Exemplo…?
E onde foi que eu disse que você preferia isso?
Ok.
Não é porque não existe um intermediário ou uma API RPC que não existe contrato. O contrato é geralmente veriicado a cada request e você pode utilizar o código HTTP correspondente quando este for quebrado.
Não tenho a menor idéia do que você quer dizer por “já que vai manter a requisição até chamar o próximo serviço”. “manter estado de variáveis, chamando diversos serviços e consolidar no final” é exatamente o que um MapReduce faz, que foi o exemplo citado. Pode elaborar seu ponto?
Eu também. Infelizmente somos péssimos em fazer este tipo de coisa por falha corporativa generalizada -e não estou sendo irônico. A melhor maneir aé aproveitar a oportunidade e conversar diretamente com um TWer, e eu não conheço ninguém melhor que o Jim para este assunto em específico.
[quote=Kenobi]
Sei que na comunidade, muitos seguem os Agilistas e empresas como TW. Entretanto há outra corrente no mercado corporativo, onde se dá até mais valor ao Processo de Negócio, do que a implementação.[/quote]
Isto é uma falácia e você está falando de uma empresa que não conhece. Para sua informação o ponto para TW é que na maioria das vezes a implementação É o processo de negócio. SOA para a maioria dos nossos projetos -e cada projeto é algo diferente aqui- é extremamente parecido com DDD.
Charles Geschke, fundador da Adobe Systems, em sua entrevista para o livro Startup, fala uma coisa bem interessante que acho que tem muito a ver com esta discussão:
Hoje, muitas empresas estão gastando suas balas em ferramentas e soluções “SOA” de caixinha, caríssimas, porque estão atirando onde os vendors - que há alguns anos gastam zilhões de dolares construindo estas ferramentas, sejam boas ou ruins, e agora precisam ganhar dinheiro com elas - estão apontando que está o pato. Fato é que estão se divertindo bastante quando as balas passam próximas ao pato, porque tem a falsa sensação de que estão na direção certa e que o próximo tiro será certeiro. (Alguns até acertam um ou outro tiro, não vou generalizar ao ponto de dizer que isso não acontece nunca. Mas será que estes acerto justificam o custo das balas?)
Por outro lado, há empresas que estão investindo suas balas em arquiteturas alternativas, simples, baratas, livres de vendor lock e amplamente validadas - afinal, a plataforma é a web e ela tá aí há muito tempo -, para “fazer” SOA. Estas são as empresas que estão atirando onde o pato ainda vai estar.
Eu prefiro atirar onde o pato vai estar. Ainda que algumas vezes, infelizmente, por conta de toda a cultura corporativa, eu tenha que atirar onde o pato está hoje.
Posso ter entendido errado, tom da conotação, aliás por texto às vezes a interpretação é outra.
Então quer dizer que a equipe terá que decobrir o se funciona ou não em tempo de execução ? E como sabe qual a versão do serviço - Governança, qual a estrutura de dados ( Modelo Canônico) que está valendo ?
Vou analisar novamente o pattern MapReduce e ver se encaixa no que estava dizendo. Entretanto ainda acho que é uma solução muito sofisticada para a maior parte dos programadores implementar, talvez seja possível, não tenho essa resposta agora.
Eu também. Infelizmente somos péssimos em fazer este tipo de coisa por falha corporativa generalizada -e não estou sendo irônico. A melhor maneir aé aproveitar a oportunidade e conversar diretamente com um TWer, e eu não conheço ninguém melhor que o Jim para este assunto em específico.
[quote=Kenobi]
Sei que na comunidade, muitos seguem os Agilistas e empresas como TW. Entretanto há outra corrente no mercado corporativo, onde se dá até mais valor ao Processo de Negócio, do que a implementação.[/quote]
[quote=pcalcado]
Isto é uma falácia e você está falando de uma empresa que não conhece. Para sua informação o ponto para TW é que na maioria das vezes a implementação É o processo de negócio. SOA para a maioria dos nossos projetos -e cada projeto é algo diferente aqui- é extremamente parecido com DDD.[/quote]
Acho que não consegui me expressar da maneira que queria, vou tentar reformular a pergunta, mas não estou conseguindo …exausto !
Concordo. Mais que está virando, já é. O fato de HATEOAS ser raramente entendido e utilizado é prova viva.
Acho que não fui claro: eu sei o que é QoS e pratico tanto em aplicações web normais (i.e. que falam com um browser) quanto em serviços RESTful (além de outros contextos, claro). Eu quero entender sua crítica ao modelo REST quanto à isto.
Não entendi. Por que ele teria que descobrir em tempo de execução? Por que não tem um WSDL?
Se você realmente quer um contrato bem definido e com validação automática (assim como DBC em OO isso na maioria das vezes é overkill IMO) qual o problema em usar schemas ou algo como relaxng? Lembre-se que REST não é RPC logo as necessidades de contrato são bem diferentes.
Acho que novamente não fui claro. O que eu disse não foi que você usa MapReduce para fazer este tipo de operação, o que eu tentei dizer foi que o serviço que eu implementei faz MapReduce e isso, creio, é um exemplo do que você disse que seria ausente num modelo RESTful.
Infelizmente não pude ir esse ano. Vida de recém casado é dureza. Nesse dia eu tava apertando torneira, instalando prateleiras, etc… Andei meio fora de sintonia nesses últimos 2 meses. Aos poucos estou voltando a ativa!
Porém tratei de correr atras para dar uma boa olhada nos slides e ainda peguei o feedback com o pessoal do meu time que esteve por la.
Achei muito interessante essa discussão em relação ao ESB. Mesmo por que o Kenobi (@scaphe) nos ministrou um treinamento no antigo ServiceBus da BEA atual OracleServiceBus no final de 2008. Agora estamos no meio do projeto de implantação, indo para um novo datacenter e o espaço do ESB está reservado.
Sei que estou caindo de pára-quedas na discussão e não pretendo tomar nenhum partido. De qualquer forma acho estranho denegrir a imagem do ESB com a argumentação de que é possível fazer tudo o que ele faz programaticamente. Não que eu duvide dessa afirmação, mas quanto tempo levaria para implementar as funcionalidades desejadas dentro do seu ambiente? Se sua empresa tem uma certa proximidade, facilidade e interesse de negociação com um grande player de mercado, ainda assim estaríamos “errados” em disponibilizar um ESB em nosso modelo arquitetural? Nunca acreditei que ele fosse a bala de prata e que com ele iremos resolver todos os nossos problemas arquiteturais, apenas acredito que ele resolva o que se propõe a fazer.
Agora sinceramente acho ridículo que uma legião passe a crucificar essa solução, por que uma pessoa de renome deu a entender que esse não é o melhor caminho. Como disse, não assisti a palestra, mas me pergunto: será que foi isso mesmo o que Jim Webber quis dizer? “Não usem ESB. Ele é o grande vilão!”. Foi realmente essa a moral da história? De fato não tenho certeza se foi isso mesmo, mas o que sei é que visão, coerência e bom senso devem ser os guias de qualquer pessoa quando o assunto é tomada de decisão!
Acho que você não entendeu bem a discussão. Este não é o ponto, a crítica não diz que se pode fazer “programaticamente” (seja lá o que você quer dizer com isso) mas sim que existem alternativas mais simples.
Ok, você acha que implementar isso num ESB é simples. Seria bem interessante você dar sua opinião após algum tempo de experiência real.
Desculpe mas ridículo é a sentença acima. Você pode dizer onde leu isso?
Antes de mais nada existem apresentações do Jim Webber disponíveis online caso você queira para de usar falácias e queira discutir argumentos:
Depois você poderia se dar ao trabalho de fazer uma pesquisa no Google para saber se o argumento contra o uso desemcabido de ESB é coisa apenas do Jim Webber:
Infelizmente não pude ir esse ano. Vida de recém casado é dureza. Nesse dia eu tava apertando torneira, instalando prateleiras, etc… Andei meio fora de sintonia nesses últimos 2 meses. Aos poucos estou voltando a ativa!
Porém tratei de correr atras para dar uma boa olhada nos slides e ainda peguei o feedback com o pessoal do meu time que esteve por la.
Achei muito interessante essa discussão em relação ao ESB. Mesmo por que o Kenobi (@scaphe) nos ministrou um treinamento no antigo ServiceBus da BEA atual OracleServiceBus no final de 2008. Agora estamos no meio do projeto de implantação, indo para um novo datacenter e o espaço do ESB está reservado.
Sei que estou caindo de pára-quedas na discussão e não pretendo tomar nenhum partido. De qualquer forma acho estranho denegrir a imagem do ESB com a argumentação de que é possível fazer tudo o que ele faz programaticamente. Não que eu duvide dessa afirmação, mas quanto tempo levaria para implementar as funcionalidades desejadas dentro do seu ambiente? Se sua empresa tem uma certa proximidade, facilidade e interesse de negociação com um grande player de mercado, ainda assim estaríamos “errados” em disponibilizar um ESB em nosso modelo arquitetural? Nunca acreditei que ele fosse a bala de prata e que com ele iremos resolver todos os nossos problemas arquiteturais, apenas acredito que ele resolva o que se propõe a fazer.
Agora sinceramente acho ridículo que uma legião passe a crucificar essa solução, por que uma pessoa de renome deu a entender que esse não é o melhor caminho. Como disse, não assisti a palestra, mas me pergunto: será que foi isso mesmo o que Jim Webber quis dizer? “Não usem ESB. Ele é o grande vilão!”. Foi realmente essa a moral da história? De fato não tenho certeza se foi isso mesmo, mas o que sei é que visão, coerência e bom senso devem ser os guias de qualquer pessoa quando o assunto é tomada de decisão!
Abraços!
-LeoLuz-[/quote]
Uma breve pesquisa neste fórum e na internet pode revelar que antes mesmo da palestra do Jim a discussão envolveu muito mais do que 1 pessoa criticando soluções ESB, ele apenas sintetiza tudo (numa brilhante apresentação por sinal!).
[quote=pcalcado][quote=leo.luz]
De qualquer forma acho estranho denegrir a imagem do ESB com a argumentação de que é possível fazer tudo o que ele faz programaticamente.
[/quote]
Acho que você não entendeu bem a discussão. Este não é o ponto, a crítica não diz que se pode fazer “programaticamente” (seja lá o que você quer dizer com isso) mas sim que existem alternativas mais simples.
[/quote]
Ok. Realmente devem existir alternativas mais simples. E o meu ponto também não foi esse. A minha questão é em relação ao tempo para disponibilizar a solução. Por mais simples que ela seja, isso demanda tempo. Se o core-business da sua empresa não é desenvolvimento de software, vale a pena investir esse tempo? É claro que há uma infinidade de cenários diferentes de uma corporação para outra e é acho inviável dizer que o que é bom para uma é bom para a outra.
[quote=pcalcado][quote=leo.luz]
Não que eu duvide dessa afirmação, mas quanto tempo levaria para implementar as funcionalidades desejadas dentro do seu ambiente? Se sua empresa tem uma certa proximidade, facilidade e interesse de negociação com um grande player de mercado, ainda assim estaríamos “errados” em disponibilizar um ESB em nosso modelo arquitetural?
[/quote]
Ok, você acha que implementar isso num ESB é simples. Seria bem interessante você dar sua opinião após algum tempo de experiência real.
[/quote]
Posso fazer isso. Sem problemas. Aliás vc me deu uma ótima idéia! :idea:
[quote=pcalcado][quote=leo.luz]
Agora sinceramente acho ridículo que uma legião passe a crucificar essa solução, por que uma pessoa de renome deu a entender que esse não é o melhor caminho.
[/quote]
Desculpe mas ridículo é a sentença acima. Você pode dizer onde leu isso?
Antes de mais nada existem apresentações do Jim Webber disponíveis online caso você queira para de usar falácias e queira discutir argumentos:
Depois você poderia se dar ao trabalho de fazer uma pesquisa no Google para saber se o argumento contra o uso desemcabido de ESB é coisa apenas do Jim Webber:
Por favor consulte a Rede Mundial de Computadores (a Internet) e leia sobre o assunto debatido antes de postar em um fórum público.
[/quote]
Ok… ok. Confesso que não fui muito feliz nessa minha sentença pois não deixei claro o que quis dizer. Estava me referindo ao fato de pessoas que escutam um profissional experiente e falam amém sem procurar entender a essência da mensagem de maneira geral. Não estava me referindo a alguém especificamente mas parece que vc se irritou… Disparou uma série de ironias e agressões contra a minha pessoa. Sinceramente não sei o que vc quis dizer com falácia. Caso vc não saiba está aqui a definição:
[i]falácia
s. f.
Acção!Ação de enganar com má intenção.
Engano, logro.
Sofisma ou engano que se faz com razões falsas ou mal deduzidas.
Fam. O ruído de vozes de muitas pessoas que falam.
Falatório.[/i]
Promover uma falácia não foi minha real intenção. Isso é coisa da sua cabeça.
Voltando ao tópico da discussão, quem trabalha comigo sabe que não defendo esse ou aquele vendor. Muito pelo contrario… Gosto de escutar e pesquisar as mais variadas opiniões sobre um determinado assunto para tirar minhas próprias conclusões. Não estou defendendo o ESB para 100% dos cenários (nem 20% deles) e tão pouco a Oracle, mas gostaria de citar um trecho do livro “The Definitive Guide to SOA - Oracle® Service Bus” que mostra a visão deles:
[quote]
Why Buy an Enterprise Service Bus?
We come across this question frequently. The truth is that an ESB contains no magic in it at all.
It?s possible to build your own ESB from scratch. In fact, one of the authors has done it twice
before joining Oracle. There?s nothing that the engineers at Oracle can write that you cannot
write yourself, given enough time, money, and training. This principle holds true for all soft-
ware. You don?t need to use Microsoft Word to write your documents; you could create your
own word processor. In the same way, HTML standards are publicly available, and you could
use your engineering time to develop your own web browser.
Naturally, few of us would ever consider writing our own word processor or web browser.
It?s a far better use of our time and money either to buy the software or to use an open source
version. This is especially true if your company isn?t a software company. If you work in an IT
shop for a company whose primary line of business isn?t software, you?ll recognize the fact
that building software from scratch is a difficult sell to your executive staff. There simply is no
return on investment for such development efforts. Your time and skills are better spent solv-
ing problems specific to your company.[/quote]
Não quero desmentir ninguém e tão pouco promover falácias. Apenas tenho uma opinião agora que é baseada em fundamentos e crenças e isso também não significa que amanhã ou depois eu não possa mudá-la/evoluí-la.
[/quote]
