Falando em Java 09 - O que você achou?

Eu posso até discordar fortemente de algumas opiniões do Kenobi, mas tenho que tirar o chapéu pro cara por duas coisas:

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

2) Por isso:

Kenobi wrote:Acredito que o ESB não é necessário à todos cenários, mas daí dizer que ele pode ser simplesmente substituído, acredito que se deve analisar cada caso.

Perfeito. Opinião sensata de qualquer bom arquiteto/desenvolvedor/tomador de decisão e serve para qualquer tecnologia/discussão.

Kenobi wrote:
Um exemplo está na definição de Throttling para um determinado serviço, ou seja, demandar processamento o quanto aquele aguenta, como se fosse uma torneira, fechando caso o processamento seja intenso demais para a soluçã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.

Kenobi wrote:
Outros estão em transformação de estrutura de dados, comportando engines de XSLT e Xquery. Definição de regras de SLA, regras de segurança de maneira centralizada, como SAML e por aí vai.

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

Kenobi wrote:
Acredito que o ESB não é necessário à todos cenários, mas daí dizer que ele pode ser simplesmente substituído, acredito que se deve analisar cada caso.

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.

Kenobi wrote:
Exatamente eu vi e isso é Coreografia e não Orquestração, pois o fluxo não pode ser interrompido e manter estado, disparar processamentos paralelos e juntar o processamento ao final. São alguns cenários como o pattern Split-Join que em processamento com grandes volumes, você precisa implementar.

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.

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.

Poxa perdi esse gde evento!

boaglio wrote:
Eu nem precisei ir ao evento, apenas seguia o Bregaida, o repórter Caelum

Hahahahahah boa hahahahah

Também botei no meu blog sobre algumas coisas do evento =)
http://javawora.blogspot.com/2009/05/falando-em-java-eu-fui.html
É sempre bom rever os amigos

This message was edited 1 time. Last update was at 28/05/2009 21:52:09

pcalcado wrote:
Throttling
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.

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.

pcalcado wrote:
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.

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.

pcalcado wrote:
SLA, dependendo do que você quer dizer, também é algo que qualquer aplicação web de grande porte já faz.

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.

pcalcado wrote:
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".

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

pcalcado wrote:
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.

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 ?

Kenobi wrote:
Exatamente eu vi e isso é Coreografia e não Orquestração, pois o fluxo não pode ser interrompido e manter estado, disparar processamentos paralelos e juntar o processamento ao final. São alguns cenários como o pattern Split-Join que em processamento com grandes volumes, você precisa implementar.

pcalcado wrote:
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.

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.

pcalcado wrote:
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.

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

Fabio Kung wrote:Eu posso até discordar fortemente de algumas opiniões do Kenobi, mas tenho que tirar o chapéu pro cara por duas coisas:

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

2) Por isso:

Kenobi wrote:Acredito que o ESB não é necessário à todos cenários, mas daí dizer que ele pode ser simplesmente substituído, acredito que se deve analisar cada caso.

Perfeito. Opinião sensata de qualquer bom arquiteto/desenvolvedor/tomador de decisão e serve para qualquer tecnologia/discussão.

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

le-silva wrote: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:

http://leandrosilva.com.br/2009/05/25/entao-falando-em-java

Ano que vem "é nóis" outra vez!

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.

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.

JavaGuru Membro desde: 31/01/2003 10:21:32 Mensagens: 255 Offline

Kenobi wrote:
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.

Não citei nomes.

Kenobi wrote:
Estou me referindo a qualquer tipode aplicação, inclusive aquelas que estão fora do protocolo HTTP.

Tá, mas eu (e muito provavelmente o Jim) estou falando de web services que rodam sobre HTTP.

Kenobi wrote:
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.

Como falei, qualquer aplicação web de grande porte (e boa parte das de médio) faz isso.

Kenobi wrote:
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.

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.

Kenobi wrote:
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.

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?

Kenobi wrote:
Ainda há outras áreas de cobertura como QoS - quality of service.

Exemplo...?

Kenobi wrote:
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).

E onde foi que eu disse que você preferia isso?

Kenobi wrote:
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.

Ok.

Kenobi wrote:
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 ?

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.

Kenobi wrote:

pcalcado wrote:
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.

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.

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?

Kenobi wrote:
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.

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.

Kenobi wrote:
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.

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.

This message was edited 1 time. Last update was at 29/05/2009 13:27:05

le-silva wrote:

Kenobi wrote:...

Não citei nomes.

Não precisava, pois fazia parte de um contexto.

JavaGuru Membro desde: 31/01/2003 10:21:32 Mensagens: 255 Offline

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:

Para ser um bom caçador de patos, você tem que atirar onde o pato vai estar, e não onde ele está no momento.

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.

JavaGuru Membro desde: 31/01/2003 10:21:32 Mensagens: 255 Offline

Kenobi wrote:

le-silva wrote:

Kenobi wrote:...

Não citei nomes.

Não precisava, pois fazia parte de um contexto.

Que nada, relaxa.

pcalcado wrote:
Tá, mas eu (e muito provavelmente o Jim) estou falando de web services que rodam sobre HTTP.

Por isso estava mencionando a importância da ferramenta no papel de integração.

Kenobi wrote:
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.

pcalcado wrote:
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.

Ok.

Kenobi wrote:
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.

pcalcado wrote:
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?

BuzzWords, AOP , Cpacity Plan é Buzz ? SOA para muitos também ... então fim da discussão, aliás REST está virando.

Kenobi wrote:
Ainda há outras áreas de cobertura como QoS - quality of service.

pcalcado wrote:
Exemplo...?

Estou 30 horas sem dormir, então vai um link, depois podemos entrar no assunto - http://en.wikipedia.org/wiki/Quality_of_service

Kenobi wrote:
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).

pcalcado wrote:
E onde foi que eu disse que você preferia isso?

Posso ter entendido errado, tom da conotação, aliás por texto às vezes a interpretação é outra.

Kenobi wrote:
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 ?

pcalcado wrote:
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.

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 ?

pcalcado wrote:
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?

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.

Kenobi wrote:
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.

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.

Kenobi wrote:
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.

pcalcado wrote:
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.

Acho que não consegui me expressar da maneira que queria, vou tentar reformular a pergunta, mas não estou conseguindo ...exausto !

Kenobi wrote:
BuzzWords, AOP , Cpacity Plan é Buzz ? SOA para muitos também ... então fim da discussão, aliás REST está virando.

Concordo. Mais que está virando, já é. O fato de HATEOAS ser raramente entendido e utilizado é prova viva.

Kenobi wrote:

Kenobi wrote:
Ainda há outras áreas de cobertura como QoS - quality of service.

pcalcado wrote:
Exemplo...?

Estou 30 horas sem dormir, então vai um link, depois podemos entrar no assunto - http://en.wikipedia.org/wiki/Quality_of_service

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.

Kenobi wrote:

Kenobi wrote:
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 ?

pcalcado wrote:
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.

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 ?

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.

Kenobi wrote:

pcalcado wrote:
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?

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.

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.

Ola a todos!

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-

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