Re: pull X push e java 1.4

[Edgard Pevidor de Miranda <PROTECTED>]

Falem pessoal,

 Um ponto que eu achei relevante para escolher o sistema pull 
foi o fato de que grande parte das vezes os clientes sao rodados
dentro de redes internas ou firewalls. Um exemplo bem perto de nós
é que nao poderíamos rodar "facilmente" um cliente
dentro da rede linux quando o servidor não faça parte da mesma rede
(pois o CORBA do cliente registra o objeto com um endereco interno
que o servidor nao consegue acessar (como 192.168.x.x), além do
firewall bloquear todas as portas, etc. Os firewalls costumam
bloquear quase sempre conexoes de fora para dentro, e nao de dentro para
fora.
 Outro ponto positivo ao sistema pull é de que, como em um futuro
próximo minha equipe pretende colocar o sistema de chat na internet (utilizando
JSP/Servlets), o browser teria que periodicamente dar o refresh na pagina 
dinamica, e vamos aproveitar este refresh para efetuar a chamada
de keep-alive e/ou pedir novas mensagens.

Falou!

 Edgard
 



Paulo Eduardo Azevedo Silveira wrote:
> oi pessoal, roberto, nelson e tiago
> 
> em primeiro lugar, quero deixar claro que nesse caso o PULL eh MUITO pior
> eficientemente do que o push, como o kon ja havia escrito no primeiro
> email, e eu repeti na hora de escrever o meu email (quote: "com certeza o
> pull (nesse caso) eh menos eficiente").
> 
> mas a minha opiniao eh que ele eh MUITO mais elegante, escalavel,
> cutomizavel, e muitos outros bons adjetivos.
> 
> para quem quer saber mais sobre MVC, leia na pagina dos proprios criadores
> do termo (sun) ...
> 
> http://java.sun.com/blueprints/patterns/j2ee_patterns/model_view_controller/index.html
> 
> e aqui tem um papo legal sobre pull vs push, voltado a web, mas vale em
> varios casos:
> 
> http://jakarta.apache.org/turbine/turbine-2/pullmodel.html
> 
> e aqui vai uma boa citacao (e engracada) sobre o pull deixar a coisa mais
> escalavel e customizavel que o push:
> 
> "Gone are the days where one would have a Java class that would be
> responsible for building the context up for the template. Instead, there
> would be a single base class that places the few objects into the context
> for every request and there is a documented API that the template designer
> can refer to in order to access the information that he/she needs to get
> at. Of course this information is only retrieved when requested and can
> also be managed in a cache for reuse. 
> 
> By moving to a "Pull" model, it becomes possible to more easily achieve
> complete independence from the Java engineers in order to not only change
> the look and feel (UI) of the site but also the information architecture
> (IA) layout and flow of the site. "
> 
> a fonte eh o link anterior, um pessoal do apache responsavel por um
> framework de servlets.
> 
> falou
> sao os meus 2 centavos.
> 
> paulo
> 
> 
> 
> 
> ---------
> "The software required Win95 or better, so I installed Linux."
> "Standards are good! Let us have a LOT of them!"
> Paulo Eduardo A. Silveira   <PROTECTED>
> UIN: 5142673   www.paulo.com.br
> 
> On Thu, 21 Mar 2002, Tiago wrote:
> 
> > Nelson Posse Lago mandou bem:
> > 
> > > Ah, mas quem disse que o servidor do chat tem que ser o seu controller?
> > 
> > exato... Uma coisa é push/pull entre os hosts, outra coisa é o que vc faz no
> > cliente depois que a msg chegou. Eu acho que no MVC, a coisa nao é nem push e nem
> > pull: o Model avisa o View que ele mudou, e o View relê os dados do Model.
> > 
> > Mas essa idéia também pode se aplicar à parte cliente/servidor: se todas as
> > mensagens (por mensagens eu incluo "Tiazinha entrou na sala" e coisas do tipo) sao
> > numeradas, o servidor pode avisar o cliente que há novas mensagens, e o cliente
> > "puxa" os dados novos. Isso sim geraria uma sobrecarga maior no servidor do que os
> > dois primeiros métodos, pq inclui duas mensagens.
> > 
> > Mas eu me pergunto: entre um pull e o próximo, qual a probabilidade de termos
> > novos dados? Gigantesca, no mínimo... no caso do chat, nao acho o pull um método
> > pior que o push... a menos que se considere que o servidor tem que guardar as
> > mensagens até todos os clientes puxarem. Hmmmm...
> > 
> > > > no pull, basta voce deixar acessivel, que o viewer pode "pullar" o que ele
> > > > precisa / o que ele quer.
> > >
> > > Hmmmm, isso nao parece bom; se a nada acontecer durante 1h, o viewer vai
> > > ficar "pullando" no mesmo lugar (sem trocadilhos...) totalmente `a toa.
> > > Agora, coloca 500 caras numa unica sala sem nenhum trafego e voce vai
> > > gerar um load bem grande no server (e na rede!) sem necessidade. Pior: a
> > > menos que voce "pulle" rapidinho (ja' disse *sem trocadilhos!*), vai
> > > sempre haver um certo atraso entre o envio de uma mensagem e o recebimento
> > > dela pelos outros.
> > 
> > Mas quando vc usa push, vc ainda tem que saber quem ainda tá conectado! O CORBA se
> > encarrega das conexoes, mas ele nao mantém sockets abertos pra cada cliente (ainda
> > bem!). Quando ele verifica? Quando for dar push? Daí vc fica 1h conectado, e "nada
> > acontece", e de repente vc manda "alo?" e lê:
> > 
> > "- Tiazinha saiu da sala"
> > "- Johhny16 saiu da sala"
> > "- ***Lili saiu da sala"
> > ... todo mundo saiu da sala.
> > 
> > esse problema acontece com todos os métodos, desde que os usuários usem modem. Mas
> > vc fica 1h sem saber que o problema aconteceu se vc usa push simples, sem nenhum
> > sistema de keep_alive.
> > 
> > > > nao acho o push uma boa pratica de programacao para escalabilidade do
> > > > VIEWER (cliente do chat) de um sistema
> > 
> > C queria deixar só "a tela" no cliente, né?? Dá pra fazer, mas... tem esses
> > "issues"...
> > 
> > Ia ser legal se desse pra gente misturar server de um com client de outro, mas ia
> > precisar de um padrao... acho que o professor quer que cada um crie suas IDLs,
> > né??
> > 
> > Tudo de bom!!
> > Tiago "eu sempre respondo, o que eu nao sei eu invento" Silveira
> > 
> > 
> 
>