As melhores praticas para aplicações Java EE

This message was edited 1 time. Last update was at 13/11/2007 18:00:40

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

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á

saoj wrote:

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

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?

1. ...trava/espera pela resposta...
Não, processa requisições dos demais clientes pendurados em outras telas

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

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

saoj wrote:
A grande maioria dos projetos fará babysitting de banco de dados, e pra isso <framework simples X> + hibernate resolve muito bem.

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á

Paulo Silveira wrote:EJB3 == "framework simples". Falar que usar EJB3 é super complciado, vai levar anos, vai gastar muito dinheiro, etc, é ignorar por completo a nova especificação.

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

Luca wrote: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

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á

fabgp2001 wrote:
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

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?

Fabio Kung wrote:

louds wrote: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

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

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

What is classpath? Membro desde: 10/05/2008 10:20:53 Mensagens: 5 Offline

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

JavaChild Membro desde: 14/07/2006 18:09:33 Mensagens: 104 Offline

Paulo Silveira wrote:

saoj wrote:
A grande maioria dos projetos fará babysitting de banco de dados, e pra isso <framework simples X> + hibernate resolve muito bem.

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.

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.

GUJ Expert Membro desde: 18/02/2008 16:17:53 Mensagens: 3002 Offline

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

Já que desenterraram o tópico, vou aproveitar e perguntar:

Qual é a resposta que acharam?

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