[quote=louds]
Dá para fazer o yaws chamar código Java, existe uma bridge erlang-java, mas qual o sentido de usar uma linguagem meia boca quando o ambiente suporta naturalmente algo melhor?[/quote]
Talvez para poder usar um milhão de coisas que foram feitas com a linguagem Java.
Como faço persistência com ERLANG?
Olá
Na prática a resposta assíncrona é super rápida. O usuário na tela nem percebe que as comunicações entre processos no servidor são assíncronas. Faça alguma experiências interligando 2 aplicações e veja como o JBoss ou o ActiveMQ responde rápido.
Vou fazer um parêntesis para contar uma historinha:
No início de 2002 um cara que trabalhava comigo ouviu de um cara da IBM que seria melhor desenvolver sistemas totalmente baseados em mensagens. Minha resposta na lata foi de que o funcionário da IBM queria vender MQSeries.
Mas em casa pensei melhor no assunto e percebi que ele tinha razão. Na época eu trabalhava com o banco postal que trocava mensagens ISO 8583 com o switcher que se comunicava com Osasco via sockets através de um monte de threads. O sistema poderia ter sido escrito baseado no MQSeries, que já fazia parte do projeto para outros fins. Com certeza a escalabilidade seria melhor e O TEMPO QUE SE PERDEU com o protocolo dos sockets possivelmente teria sido menor.
[]s
Luca
[quote=danieldestro]Com o processo síncrono (SLSB), o fluxo é sequencial. Você recebe a resposta e repassa à camada visual.
Do jeito assíncrono, como devo proceder? Esperar ser notificado do processamento do MDB e então mandar a resposta de volta?[/quote]
Eu enxergo exatamente isso. Com a diferença adicional de que na segunda alternativa o usuário não fica travado esperando resposta ou (num sisteminha mais bem feito) você economiza threads.
Claro, muitas vezes não vale a pena. Como já dito, não é para ser usado sempre.
ps.: Sami, você estava corretíssimo quanto à palavra polling. Corrigido!
AJAX entrou na discussão, pois também é um exemplo onde alguma “assíncronidade” (?) trouxe grandes benefícios.
[quote=louds]http://cometd.com/
www.lightstreamer.com
http://activemq.apache.org/ajax.html (dai vc usa Comet com JMS!)
E sobre o protocolo que todos usam, Bayeux:
http://svn.xantus.org/shortbus/trunk/bayeux/protocol.txt[/quote]
Louds, e quanto aos servidores com conectores baseados em io não-bloqueante como o jetty6, o glassfish e até o tomcat6 ?
Não resolvem justamente esse problema de precisar aguentar diversas conexões abertas por bastante tempo, já que não travam mais uma thread por conexão?
Edit: já achei um exemplo… http://tomcat.apache.org/tomcat-6.0-doc/aio.html
Não sei se entendi isso direito, mas se a coisa exige uma resposta sincrona, como o Daniel falou, então no lado do servidor ele manda uma mensagem assíncrona e trava/espera pela resposta. Recebida a resposta ele responde para o cliente.
Então para o cliente a coisa foi síncrona, mas no back-end foi assincrona.
É isso?
Dei uma lida lá no artigo que o Fábio sugeriu. Realmente muito bom. RMI, RPC e Corba nunca chegaram a lugar nenhum. Em termos de sistemas distribuídos, mensagens assíncronas parece ser a melhor, mais natural e mais performática maneira de fazer a comunicação.
Uma vantagem que eu consigo perceber agora de um sistema baseado em mensagens assíncronas é a facilidade que vc tem de plugar novos serviços/aplicativos ao redor dele. Não tenho idéia de como um servidor de mensagens JMS (é assim que se chama?) é implementado, mas imagino que qualquer cliente possa chegar a qualquer momento e dizer: "Ei, eu tb quero receber essas mensagens aí!"
Um approach interessante e altamente escalável utilizado por NASDAQ e outras bolsas que precisam processar 1 milhão de mensagens por segundo é Multicast UDP (com retransmissão de pacotes perdidos, catchup the stream e ordenação). Nesse ambiente as mensagens são broadcasteadas para quem quiser recebe-las, bastando para tal fazer um join no endereço e na porta. Some-se a isso NIO e um código nativo em C para dar um bind no DatagramChannel (suporte a multicast com nio talvez no Dolphin!) e tem-se um super processador de mensagens capaz de tratar muitas milhões de mensagens por segundo (o limitador passa ser o hardware do seu switch!). Nada simples, mais muitíssimo rápido e escalável, visto que vc pode ter 1000 máquinas independentes recebendo esses pacotes e realizando as mais distintas tarefas…
Para sistemas bossalmente parrudos que precisam processar muitas requisições ou mensagens por segundo, mensagens assíncronas são a única solução escalável. Problema é que esses sistemas são 1% dos projetos. A grande maioria dos projetos fará babysitting de banco de dados, e pra isso <framework simples X> + hibernate resolve muito bem.
Olá
[quote=saoj][quote=Luca]
Na prática a resposta assíncrona é super rápida. O usuário na tela nem percebe que as comunicações entre processos no servidor são assíncronas. Faça alguma experiências interligando 2 aplicações e veja como o JBoss ou o ActiveMQ responde rápido.
[/quote]
Não sei se entendi isso direito, mas se a coisa exige uma resposta sincrona, como o Daniel falou, então no lado do servidor ele manda uma mensagem assíncrona e trava/espera pela resposta. Recebida a resposta ele responde para o cliente.
Então para o cliente a coisa foi síncrona, mas no back-end foi assincrona.
É isso?
[/quote]
…trava/espera pela resposta…
Não, processa requisições dos demais clientes pendurados em outras telas
…Então para o cliente a coisa foi síncrona, mas no back-end foi assincrona…
Sim, o que defendo é avaliação da substituição do RPC usado pelos EJBs através de RMI por trocas de mensagens assíncronas.
…esses sistemas são 1% dos projetos…
Infelizmente o povo está acostumado com RPC porque muitos outros projetos poderiam se beneficiar de uma arquitetura de mensagens. Vou mais além: as mensagens podem representar eventos. Eu ainda acho que qualquer sisteminha de ponto de venda pode ficar mais fácil de se integrar se sua arquitetura for baseada em eventos (que na prática são mensagens)
[]s
Luca
O que voce ainda nao se deu conta é que EJB3 == “framework simples”. Falar que usar EJB3 é super complciado, vai levar anos, vai gastar muito dinheiro, etc, é ignorar por completo a nova especificação.
Olá
Eu que sempre fui cético quanto aos EJBs pré 3.0 (a menos quando envolvia transações distribuídas ou Message beans), concordo plenamente. Mas depois que andei estudando o que o Hibernate 3 faz a mais do que EJB3, fiquei na dúvida se não é melhor usar direto o Hibernate 3.
Pergunto: vale a pena usar as facilidades a mais do Hibernate 3 ao invés de se limitar ao que está atualmente no EJB3?
[]s
Luca
[quote=Luca]Eu que sempre fui cético quanto aos EJBs pré 3.0 (a menos quando envolvia transações distribuídas ou Message beans), concordo plenamente. Mas depois que andei estudando o que o Hibernate 3 faz a mais do que EJB3, fiquei na dúvida se não é melhor usar direto o Hibernate 3.
Pergunto: vale a pena usar as facilidades a mais do Hibernate 3 ao invés de se limitar ao que está atualmente no EJB3?
[]s
Luca[/quote]
Luca,
Tu poderia sitar o que o Hibernate 3 faz a mais? Eu me lembro de duas funcionalidades, que são a API Criteria e a parte de validação. As validações eu nem conto porque da pra rodar elas fora do Hibernate (vide VRaptor).
Fiquei curioso agora. 
]['s
Olá
[quote=fabgp2001]
Tu poderia sitar o que o Hibernate 3 faz a mais? Eu me lembro de duas funcionalidades, que são a API Criteria e a parte de validação. As validações eu nem conto porque da pra rodar elas fora do Hibernate (vide VRaptor).
Fiquei curioso agora.
]['s[/quote]
Com a minha conexão discada via interurbano fica difícil listar mas o livro Java persistence with Hibernate do Gavein King mostra algumas facilidades (extensões) que se podem aproveitar usando Hibernate. E ainda chama a atenção de que provavelmente o Hibernate evoluirá mais rapidamente do que a especificação.
Luca,
tentando exercitar o que foi dito aqui, se vc tivesse que desenvolver uma app para uns 3000 usuários(concorrentes, não simultâneos), por exemplo um sistema dentro de uma rede de Telemarketing, vc usaria JMS?
Vou complicar um pouco, digamos que 90% do tempo os usuarios usariam internamente(Intranet), mas outros 10% eles deveriam consultar gráficos de desempenho num servidor Web, considerando um servidor ideal(Parrudo, redundância, link 2X 100MBs Unmettered…), o que você usaria?
[quote=Fabio Kung][quote=louds]http://cometd.com/
www.lightstreamer.com
http://activemq.apache.org/ajax.html (dai vc usa Comet com JMS!)
E sobre o protocolo que todos usam, Bayeux:
http://svn.xantus.org/shortbus/trunk/bayeux/protocol.txt[/quote]
Louds, e quanto aos servidores com conectores baseados em io não-bloqueante como o jetty6, o glassfish e até o tomcat6 ?
Não resolvem justamente esse problema de precisar aguentar diversas conexões abertas por bastante tempo, já que não travam mais uma thread por conexão?
Edit: já achei um exemplo… http://tomcat.apache.org/tomcat-6.0-doc/aio.html[/quote]
É uma opção a se estudar, nunca usei ou falei com pessoas que usam. Minha única resalva é misturar um hub de mensageria, comet é uma forma de, com um servidor http de conteúdo dinâmico. A gambiarra que eles fazem para colocar NIO não-bloqueante funcionando com servlets é tão grande que não sei se realmente vale a pena misturar.
Sérgio, com erlang vc pode usar SQL normalmente, além disso existem um framework escrito pelo Yariv Sadan que implementa algo parecido com ActiveRecord, e, por último, existe o mnesia, que é uma banco de dados distribuido com suporte a operações soft-realtime.
Briga de Cachorro Grande, Mais vou procurar ajuda aqui.
Bom pessoal,
Possuo o seguinte cenário, Preciso capturar uma mensagem de um sistema de terceiro em minha aplicação e enviar para os meus clientes esta mensagem.
Qual é uma das melhores maneiras para atingir esta arquitetura?
Eu pensei no ActiveMQ, alguém conhece algo melhor.
Obrigado
[quote=Paulo Silveira][quote=saoj]
A grande maioria dos projetos fará babysitting de banco de dados, e pra isso <framework simples X> + hibernate resolve muito bem.
[/quote]
O que voce ainda nao se deu conta é que EJB3 == “framework simples”. Falar que usar EJB3 é super complciado, vai levar anos, vai gastar muito dinheiro, etc, é ignorar por completo a nova especificação.[/quote]
EJB 3.0 é bem mais “pesado” e engessado que o Spring, por exemplo. EJB 3.1 tenta correr atrás do tempo perdido, mas ao meu ver está uns 5 anos atrasado e ainda é pior em vários aspectos, como AOP e DI.
[quote=Ironlynx]Luca,
tentando exercitar o que foi dito aqui, se vc tivesse que desenvolver uma app para uns 3000 usuários(concorrentes, não simultâneos), por exemplo um sistema dentro de uma rede de Telemarketing, vc usaria JMS?
Vou complicar um pouco, digamos que 90% do tempo os usuarios usariam internamente(Intranet), mas outros 10% eles deveriam consultar gráficos de desempenho num servidor Web, considerando um servidor ideal(Parrudo, redundância, link 2X 100MBs Unmettered…), o que você usaria? [/quote]
Já que desenterraram o tópico, vou aproveitar e perguntar:
Qual é a resposta que acharam?