RES: pull X push e java 1.4

["Roberto Pires de Carvalho" <PROTECTED>]

Olá,
 
Dadas as circunstâncias, acredito que a escolha entre pull e push deva levar em conta quais features se quer.
 
Por exemplo, se vc quer um cliente que recebe todas as mensagens enviadas para a sala ou para vc em particular, numa rede interna (sem proxy nem firewall), pode ser interessante usar o método push por ele diminuir o tráfego de dados e enviar as mensagens sempre no momento que chegarem. Esse modelo é eficiente e faz tudo o que a especificação do EP pede.
 
Jah se vc quiser um sistema que funcione em qualquer tipo de rede e quer deixar o cliente o mais "a vontade" possível, passa a ser interessante usar o pull, pois o servidor não tá nem aí pros clientes. Ele só cuida de receber as mensagens e guardá-las em algum lugar disponível pra quem quiser ver. Agora quando o cliente vai pegar as mensagens isso é um outro assunto. Talvez de tempos em tempos, ou talvez o servidor pudesse dizer que tem novas mensagens quando o cliente avisar que está vivo, sei lá.
 
Todos concordam, discordam?
 
t+

	-----Mensagem original----- 
	De: Paulo Eduardo Azevedo Silveira [mailto:PROTECTED] 
	Enviada: sex 22-mar-02 09:33 
	Para: Tiago 
	Cc: PROTECTED 
	Assunto: Re: pull X push e java 1.4
	
	

	oba
	
	Usando o exemplo que o tiago deu:
	
	> Mas no caso client/server, que a gente tem que pensar no EP, a coisa é mais como
	> o esquema de PropertyChange que os JavaBeans implementam. Quando uma msg nova
	> chega, o servidor deve informar aos listeners (no caso, todo mundo que tá
	> conectado) que há uma msg nova, de preferencia já mandando a msg pra eles.
	
	Imagine que voce entra no chat, e quer falar apenas com a Tiazinha, isso
	eh, ignorar por completo as outras mensagens. Usando push, voce teria de
	fazer isso client side, isto eh, voce recebe todas as mensagens
	(overload de msgs trocadas), apenas nao as mostra. No caso do pull,
	voce seleciona o que voce quer pedir ao servidor, no caso, apenas as
	msgs da Tiazinha.
	
	Voce ateh pode implementar isso no push, mas teria de ligar o cliente a um
	conjunto de pessoas, ao inves de uma sala. Mas ai o problema se repete
	recursivamente: faz de conta que voce soh quer as mensagens IMPARES da
	tiazinha.... voce simplesmente nao faz isso no PUSh, voce recebe TODAS
	(overload) e soh mostra as impares.
	
	O problema do push eh: ele eh TOTALMENTE dependente da implementacao do
	servidor, o pull nem tanto, voce ESCOLHE o que quer, e esse eh o lance
	legal do pull, apesar da eficiencia ser menor em casos que envolvem
	transacoes continuas.
	
	No push voce SEMPRE recebe todas as mensagens, querendo, ou nao
	querendo. Assim como o propertyChange do javaBean... pode ser que voce nao
	tenha o MENOR interesse para aquela mudanca, mas voce recebe o aviso,
	completamente desnecessario...
	
	>
	> Tem um ponto que o Nelson falou que nao dá pra negar: se a parte que conversa
	> com o servidor (e portanto, usa CORBA) é um módulo redondo, que expoe os dados
	
	Se le eh um modulo redondo, voce nao pode simplesmente falar para o
	cliente apenas escutar as mensagens da 'Tiazinha', que no PULL voce
	poderia, mesmo sendo um modulo redondo.
	
	Modulo redondo, para o push, significa AMARRAR suas opcoes. para o pull,
	continua tudo beleza.
	
	falou
	paulo
	
	
	
	
	> de forma limpa e com baixo acoplamento, vc pode ter uma infinidade de clientes
	> diferentes (customização?) mudando apenas a interface (texto, gráfica,
	> reconhecimento de voz, etc). Dá pra fazer ainda coisas interessantes como BOTs,
	> ICQ-forwarder, etc.
	>
	> Aquele abraco!!
	> Tiago "2 centavos?" Silveira
	>
	>