SPDY nao adiciona nada de novo ao HTTP. É só um encoding diferente:
[quote=Rodrigo Sasaki]Ué. Enterprise Service Bus em Hold?
Eu achava que isso era algo muito utilizado hoje em dia, e muito aceitado[/quote]
Bom as equipes do MuleEsb - http://www.mulesoft.org, RedHat que comprou há pouco a FuseSource - http://fusesource.com, Oracle dona do ESB mais usado em Teles e Bancos do Brasil - http://www.oracle.com/technetwork/middleware/service-bus/overview/index.html entre outros players + a consultoria SOA|EXPERT e a comunidade SOACLOUD - http://soacloud.com.br pensam ao contrário.
Não dá pra fazer integração Point-to-point, tradução de protocolos é necessário e há Patterns para isso - Enterprise Integration Patterns. A TW ainda não entendeu que o ESB é um framework que implementa tais padrões e hoje há diversas opções opensource, assim como o conceito está em constante evolução.
O mais engraçado é que recomendam o ApacheCamel, que é o Kernel do FuseESB, JBoss ESB, Service Mix etc. Acho que eles não entenderam muito bem a diferença entre uma coisa e a outra e principalmente, o papel do Pattern Message Bus, assim como o que os frameworks atuais oferecem como: Interceptadores, Segurança, Políticas e SLA, Monitoria etc.
Bom queria ver como fazem integração com SAP, Mainframe, EBS, Siebel etc. Deve ser um ninho de mafagafinho ou um jogo de palitinhos gigantesco 
PS: A grande influência veio do Jim Webber, Restafarian convicto ex-diretor e autor do Rest in Practice, que escreveu outros radares no passado. Ele jogou muito com a polêmica, de integrações através de Hypermedia, contudo há diferentes tipos de protocolos, necessidades de tratamento de estado, performance etc. Ele sabe do contra-ponto e deixa claro no seu próprio livro, o problema foi a TW ter comprado a “venda” do conceito como algo estratégico, tiro no pé.
Também acredito que por isso o Neo4j é recomendado, sem explicarem os cenários de utilização.
Realmente, muito estranho essa lista.
Scala só tem acumulado críticas, tanto de usuários inexperientes, quanto desenvolvedores de frameworks… ainda assim está em adopt?! :shock:
[quote=msato]Realmente, muito estranho essa lista.
Scala só tem acumulado críticas, tanto de usuários inexperientes, quanto desenvolvedores de frameworks… ainda assim está em adopt?! :shock: [/quote]
Você tem alguma fonte ou argumento pra embasar essa afirmação?
Se eu tivesse focado em cloud também ignoraria o que consultorias Oracle tem a dizer.
[quote=msato][quote=Kenobi]
Bom as equipes do MuleEsb - http://www.mulesoft.org, RedHat que comprou há pouco a FuseSource - http://fusesource.com, Oracle dona do ESB mais usado em Teles e Bancos do Brasil - http://www.oracle.com/technetwork/middleware/service-bus/overview/index.html entre outros players + a consultoria SOA|EXPERT e a comunidade SOACLOUD - http://soacloud.com.br pensam ao contrário.
Não dá pra fazer integração Point-to-point, tradução de protocolos é necessário e há Patterns para isso - Enterprise Integration Patterns. A TW ainda não entendeu que o ESB é um framework que implementa tais padrões e hoje há diversas opções opensource, assim como o conceito está em constante evolução.
O mais engraçado é que recomendam o ApacheCamel, que é o Kernel do FuseESB, JBoss ESB, Service Mix etc. Acho que eles não entenderam muito bem a diferença entre uma coisa e a outra e principalmente, o papel do Pattern Message Bus, assim como o que os frameworks atuais oferecem como: Interceptadores, Segurança, Políticas e SLA, Monitoria etc.
Bom queria ver como fazem integração com SAP, Mainframe, EBS, Siebel etc. Deve ser um ninho de mafagafinho ou um jogo de palitinhos gigantesco
PS: A grande influência veio do Jim Webber, Restafarian convicto ex-diretor e autor do Rest in Practice, que escreveu outros radares no passado. Ele jogou muito com a polêmica, de integrações através de Hypermedia, contudo há diferentes tipos de protocolos, necessidades de tratamento de estado, performance etc. Ele sabe do contra-ponto e deixa claro no seu próprio livro, o problema foi a TW ter comprado a “venda” do conceito como algo estratégico, tiro no pé.
Também acredito que por isso o Neo4j é recomendado, sem explicarem os cenários de utilização.
[/quote]
Se eu tivesse focado em cloud também ignoraria o que consultorias Oracle tem a dizer.
[/quote]
Eu também ignoro, até porque a Oracle vende um modelo da década de 70 “Mainframe-Colocation” e chama de private Cloud.
Só uma coisa, somos neutros à partners !!
[quote=bob_sponja]Apesar de ter coisas que não concordo na tal lista, gostei da colocação a respeito de frameworks component-based:
“As the industry shifted from desktop GUI development to the web, it seemed natural to port the most successful patterns and designs to the new paradigm. After 15 years
of trying, we feel that there are still no component-based frameworks that have successfully achieved this. We recommend not attempting to make web development into
something that it fundamentally is not. It is time to accept the page and request-based nature of the web, and focus on the frameworks that support - rather than work against -
these concepts.”
Ao tentar transformar a web em desktop, não se leva todo o poder de fogo do desktop, e ainda perde os benefícios da característica stateless do protocolo HTTP e do modelo request-response. E no contato com a galera que conheço que ama frameworks component-based, a maioria só ama porque escode o javascript deles, coisa que não são tão proficientes. Acho muito mais válido estudar as tecnologias envolvidas na web e tirar o melhor proveito de suas características.[/quote]
Tambem gostei dessa colocacao. Nao entendo porque a comunidade ainda abraça component-based.
SPDY nao adiciona nada de novo ao HTTP. É só um encoding diferente:
http://en.wikipedia.org/wiki/SPDY[/quote]
Então, cv, parte do que lí em duas matérias dizem, mais ou menos, que o SPDY está sendo considerado candidato a HTTP 2.0. Links:
Essa última, inclusive, deixa um pouco mais explícito que o SPDY pode ser um candidato em potencial para ajudar no desenvolvimento de aplicações orientadas a componentes já que (segundo a matéria), o SPDY “expande” o HTTP pipelining, eliminando a necessidade de ser uma fila FIFO. Dessa maneira, poderíamos enviar várias requisições (uma para cada componente) e ir atualizando a página à medida que recebemos respostas.
[]'a