As melhores praticas para aplicações Java EE

Assuntos Gerais Notícias
#21

[quote=Fabio Kung]O problema é que o pooling inunda muito mais a rede (escala menos).

Por isso ele só é usado onde não tem como fazer publish-subscribe.[/quote]

Concordo plenamente.

Assíncrono é melhor do que síncrono.

Assíncrono contem síncrono.

Polling é menos performático que publish-subscribe, principalmente se vc faz muitas requisições por segundo para aumentar o tempo de resposta da sua mensagem assíncrona. (É, eu gostaria que o meu Outlook Express checasse por novas mensagens a cada segundo, mas o mínimo que ele checa é de um minuto em um minuto!)

Acho que se vc está num ambiente EJB, com um MOM como vc falou, etc e tal, então deve-se usar mensagens assíncronas. Por que não?

Mas se vc está num ambiente sem EJB ou sem application server, ou num ambiente sem MOM, etc e tal, vc pode fazer usando polling e conseguir o mesmo resultado, desde que vc não faça muitas requisiçoes por segundo e consiga escalar a coisa horizontalmente.

#22

Sergio, se você tem que escalar um sistema e precisa de tarefas assíncronas, usar pooling só vai fazer você morrer na praia, pq vai precisar de uma enorme tonelada de hardware adicional.

Não é simplesmente mais facil colocar um MOM na infra do sistema e ser feliz? Pooling é gambiarra por definição, construir a arquitetura de um sistema envolta de uma gambiarra é dar tiro nos pés e sair correndo.

Sistemas distribuidos eu considero que são necessários somente quando você tem uma demanda muito grande e não compensa mais fazer scale-in. Ao partir pro scale-out, fazer troca assíncrona de mensagens entre os componentes distribuídos é a melhor forma de operar.

Não estou dizendo para usar apenas trocas assíncronas, principalmente pq a maioria das linguagens main-stream não possuem resursos sufientes para fazer isso ser viavel de programar.

A questão não é “assíncrono é melhor que síncrono”, principalmente por ser muito perigosa e errada. Cada uma possui suas vantagens e desvantagens, o certo é usar cada uma de acordo com suas necessidades.

#23

Eu apenas quiz falar que assíncrono contém síncrono, mas acho que me expressei mal mesmo.

A web não é assíncrona, e as pessoas cagam pra isso.

Se vc tem um sistema que não está mais escalando então pooling é muito ruim, concordo.

O meu ponto é que comunicaçao assíncrona só é necessária em casos muito especiais.

Veja o GMAIL. Ele faz pooling para checar mensagens de tempos em tempo, e escala muito bem. Não acho que foi tiro no pé.

E o chat do messenger deles? Usa Keep-Alive, socket ou faz pooling?

Só gostaria de entender em que situaçoes mensagens assíncronas irão fazer sentido.

Quando a operação é muito demorada?

Quando vc precisa receber eventos de um outro sistema? Nesse caso porque não ser um serviço para esse outro sistema?

Estou apenas devagando e tentando aprender com quem tem mais experiencia nessa área…

#24

Sérgio, dá uma lida no artigo (e nas referências) que eu postei ali em cima, vale a pena!

#25

Valeu, tava escondido o link. Vou ler tudo com calma…

Como sempre comecei pelo fim, no caso a conclusão.

Gostei: :slight_smile: :slight_smile: :slight_smile:

#26

Sérgio, se assíncrono contém síncrono é pura retórica, em ambos os casos você pode expressar um em termos do outro.

Da mesma forma que você pode simular uma chamada síncrona com JMS, você pode fazer o mesmo com HTTP e ter troca assíncrona de mensagens.

Troca de mensagens é muito útil em cenários que você quer desacoplar quem envia de quem recebe. Seria muito ingênuo querer que toda troca de mensagens fosse feita de forma totalmente acomplada.

Um simples pode tranquilamente publicar uma mensagem em uma fila enquanto você tem vários consumidores operando independentemente sobre ela. Isso funciona muito bem, isso escala absurdamente bem. Quem já mexeu com sistemas financeiros sabe o quao importante é não fazer trocas síncronas.

Você diz que a internet é toda síncrona? Bom, se você usar email, vai descobrir que é um mecanísmo assíncrono de troca de mensagens, e quando descobrir um treco chamado mailing-list, vai descobrir a utilidade de ter o consumidor desacoplado do consumidor.

Além disso, o Gmail usa Comet style eventing, ou seja, em vez de pooling, mantem coneções abertas a espera de mensagens. Isso é uma forma de notificação assíncrona, implementada dentro dos limites do protocolo.

Cara, você já vez uma transferência, doc, ted, saque ou pagamento com cartão? Então, sabe aqueles serviços que os bancos oferecem de mandar 1 SMS quando ocorrer uma dessas operações? Você ganha um doce se adivinhar como são implementados.

Você deveria ler o EIP (Enterprise Integration Patterns) do Gregor Hohpe, lá em conta tudo isso que eu falei em grandes detalhes. http://www.enterpriseintegrationpatterns.com/

#27

Olá

Brilhante as intervenções do Louds (como sempre). Ainda há casos em que as comunicações devem ser síncronas.

Além do link para o EIP (meu livro mais bonito), recomendo também a leitura do Java Messaging do Eric Bruno para quem quer aprender JMS e um pouco de arquitetura de mensagens.

Só quero lembrar que no caso de sistemas distribuídos, o uso de uma arquitetura baseada em troca de mensagens via serviço de mensageria, WS, ESB, etc. deve ser sempre condiderada entre as alternativas viáveis. Muitos sistemas por aí NÃO avaliaram esta alternativa e agora dependem de fornecedor de máquina/fornecedor de servidor de aplicação na hora de aumentar a escalabilidade.

[]s
Luca

#28 
    Vide o SPB, que é implementado todo em cima de sistema de mensageria. Hoje mesmo trabalho em um sistema de integração bancária que trabalha em cima disso também.
#29

Vc leu errado: :slight_smile:

Mas sua resposta foi boa, obrigado. Mensagens assíncronas escala tão melhor que mensagens síncronsa que sempre que possivel é melhor fazer um sistema que se baseie nelas. (É isso?)

Só continuo achando que tirando sistemas financeiros, e outros por aí, esse caso é meio exceção e não regra.

Ou devemos para qualquer sistema corporativo usar mensagens assíncronas?

Sobre o gmail, onde podemos ler mais sobre essa comunicaçao assíncrona que vc diz que ele faz? Ele usa duas conexões? (uma para postar e outra para receber em keep-alive?)

#30

Não, possivelmente isso seria:
Quando você clica no botão para mandar um e-mail ele não efetivamente manda um e-mail para quem você mandou, antes, ele provavelmente coloca numa fila de tasks e existem n processos consumidores responsáveis por executas essas tasks :slight_smile:

#31 

Certo?

EDIT: Ou seja, vocês querem dizer "polling" e não "pooling", certo? Ou "pooling" é a versão aportuguesada de "polling"? E se for o caso, como é que se diz "pooling" (por. ex. connection pooling)? :D

Certo?

EDIT: Ou seja, vocês querem dizer “polling” e não “pooling”, certo? Ou “pooling” é a versão aportuguesada de “polling”? E se for o caso, como é que se diz “pooling” (por. ex. connection pooling)? :smiley:

#32

O GMail usa uma coneção só, que mantem aberta com o servidor esperando por alguma mensagem. Procura por “comet server” ou “comet style ajax” pra saber mais.

Serviços de mensageria devem ser usados somente quando necessário. Para isso o certo é ter alguém que entenda do assunto para estudar cada necessidade caso a caso, principalmente pq 90% dos desenvolvedores são incapazes de entender o conceito.

#33

Louds, não sei se esse seu post foi com o intuito de corrigir meu post…

Eu quiz dizer enviar uma mensagem e não receber.

#34

Olá

Conexão discada via interrurbano é dose! Vai ver que épor isto que eu não consigo entender o foco deste tópico.

Para mim sistemas baseados em mensagens não tem nada a ver com a camada de apresentação. Devo estar velho e burro porque não entendo o que AJAX tem a ver com JMS. De que se pretende tratar aqui? De camada de apresentação ou do back office?

Quem me conhece, como o Fábio, sabe do meu entusiasmo por sistemas baseados me mensagens para qualquer área e não apenas sistemas financeiros. Repito que talvez a maioria dos sistemas que usam EJBs poderiam ter usado JMS para suportar sistemas distribuídos (que raramente são realmente distribuídos). JMS é bem fácil de usar e os servidores de mensagens como JBoss ou ActiveMQ fornecem boas informações sobre o comportamento do sistema.

O Louds disse que os conceitos são difíceis. Para mim o problema é que os programadores estão viciados em RPC e este é o mal. O programador precisa abrir a cabeça e se livrar do conceito RPC.

[]s
Luca

#35

Lendo o post do Sérgio eu realmente comi bola, ele queria saber mais sobre o esquema de Ajax e não do envio de uso de fila :S

Na verdade estamo falando um pouco de cada coisa Luca :slight_smile:

#36

Estamos falando de sistemas assíncronos no geral.

Sobre o comet:

Bem interessante. Polling é realmente muito ruim perto disso. Peço desculpa por ter defendido esse ponto.

Um ponto interessante discutido no link acima é os diversos problemas no nível da rede/proxy/webserver para o comet.

Qual é o framework recomendado para usar comet? O GMail provavelmente fez o seu próprio, certo?

#37

Luca,

Seguindo sua defesa de uso de JMS para sistemas distribuídos, em vez de Stateless Session Beans (SLSB).

Imaginando que um processo depende da resposta da execução de um método do negócio para retornar a informação ao usuário na tela.

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?

#38

Sérgio, o maior problema de usar Comet é o número absurdo de coneções que ficar paradas no servidor, para resolver isso, só usando um httpd escalavel feito o yaws, ou então usando um feito especialmente para Comet. Se você fez as buscas no Google já sabe qual é.

Daniel, se tua aplicação precisa ser síncrona, não existe motivo para usar JMS. Ou melhor, existe um caso só que justifica, quanto o processamento do servidor é muito demorado, com JMS você trata muito mais facilmente timeouts e espera do cliente.

#39

Procurei (de olho aberto) mas não achei… :frowning:

O Yaws não suporta servlets (java), só ERLANG, certo?

#40

Sério, aqui apareceu:

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

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?