2010-05-19 33 views
6

In un client Web RIA, creato con GWT, lo stato viene mantenuto nel client Web, mentre il server è (quasi) stateless (questa è la tecnica preferita per mantenere scalabile il sito).Come mantenere sincronizzati i client Web con stato, quando più client guardano gli stessi dati?

Tuttavia, se più utenti guardano gli stessi dati nel proprio browser e un utente cambia qualcosa, che viene inviato al server e archiviato nel database, gli altri utenti conservano ancora i vecchi dati nello stato del browser. Ad esempio, viene mostrato un albero e uno degli utenti aggiunge/rimuove un oggetto dall'albero.

Poiché ci può essere molto stato nel client, qual è la tecnica migliore per mantenere lo stato nei client sincronizzati? Ci sono dei framework java che si occupano di questo?

+0

checkout questa presentazione su OT e leggere di più su - http://docs.google.com/present/view?id=dggjrx3s_1573xdhxprd – Anurag

risposta

1

Solo modifiche push (delta), applicabile e in caso contrario - ri-sincronizzazione del client completamente. Questo è ciò che facciamo con i nostri client remoti (non solo GWT ma anche con Eclipse RCP). Inviamo contesti delta mentre i cambiamenti sono piccoli e locali, e sul cambiamento globale ci risincronizza. Ciò richiederà di progettare un protocollo diff sofisticato e spesso richiederà la riprogettazione del protocollo client remoto da zero.

0

Il più promettente HTTP push (Comet) biblioteca ho provato finora è il StreamHub Project:

StreamHub è un server altamente scalabile HTTP Comet e Reverse Ajax permettendo di spingere i dati in tempo reale ad un web browser senza richiedere alcun plug-in o modifiche alla politica di sicurezza . Utilizza una tecnica nota come Comet o Reverse Ajax per mantenere una connessione permanente aperta al browser.

Questo potrebbe essere ciò che stai cercando di mantenere aggiornati i tuoi clienti. Hanno anche un progetto GWT adapter.

+0

StreamHub è parziale un prodotto commerciale (versione base gratuita) e non hanno prezzi sul loro sito, che mi danno sempre un brutto presentimento, leggere costoso. –

0

Il supporto di Comet è disponibile anche in GWT utilizzando il progetto rocket-gwt (che offre anche una serie di altre funzioni interessanti, come raccolte leggere, trascinamento della selezione, ecc.) - La cometa è fornita dal pacchetto Remoting.

+0

Comet è solo la tecnica per comunicare "in tempo reale" tra client e server, ma non aiuta a mantenere sincronizzati più client. O mi sono perso qualcosa? –

+1

Se il server e i client hanno una vista "in tempo reale" l'uno dell'altro, quando il server riceve una notifica della modifica di un cliente, può pubblicare immediatamente tale modifica su tutti gli altri client. Per quanto riguarda le tecniche per cosa esattamente spingere, probabilmente avrei apportato modifiche incrementali a ciascun client, e ho anche un lavoro periodico per assicurarmi che tutto sia sincronizzato, come ogni 10 minuti viene inviata a tutti i clienti un'immagine più completa dello stato per assicurarsi che tutto sia ancora a posto. E assicurati che il tuo server possa notare ed essere resiliente alle modifiche apportate a un oggetto da due client, nel caso in cui le cose non vadano sincronizzate. –

0

Sto avendo lo stesso dilemma sulla mia applicazione flex.

Sembra che il modo migliore per risolvere questo problema sia mantenere un intervallo di alcuni secondi tra server e client e forzare il polling dello stato su ciascun client.

Ho fatto il seguente approccio, si noti che questo non risolve la situazione fuori sincrono, riduce solo significativamente la situazione possibile che si verifichi.

Ho sul lato server, una cache di ogni chiamata di raccolta. Ho sul lato client, per istanza di applicazione, una cache delle stesse collezioni.

L'istanza uno carica una serie di oggetti in una griglia. (Crea uno stato iniziale della raccolta con il server)

L'istanza due carica e apporta modifiche, inoltra i dati modificati al server, le informazioni di db sono persistenti e la cache del server viene ricostruita. (la cache del client mantiene anche la sua cache locale che non richiede di chiamare nuovamente la raccolta del server.

L'istanza uno non è sincronizzata. (sarà sincronizzato al successivo intervallo di polling) l'istanza due è sincronizzata perché è l'app responsabile delle modifiche.

Entrambe le istanze eseguono il polling del server di volta in volta, ad esempio un intervallo di 10 secondi per le modifiche. (Se la cache lato server ha subito modifiche, che porterà le nuove informazioni a tutti i clienti sulla chiamata successiva intervallo.)

Se non ci sono cambiamenti a livello lato server, senza informazioni viene inviato ad un cliente già registrato. (Ciò significa che non viene scambiato informazioni tra server e client, riducendo il carico.)

Se un terzo cliente entra, è stato è fresco ed effettuerà le chiamate necessarie per costruire la sua attuale della cache pure.

C'è un ritardo, ma sicuramente aiuta a propagare le modifiche al client.

Il problema è che il client consuma memoria aggiuntiva mantenendo lo stato della cache.

sto facendo questo in un per schermo situazione, una volta che lo schermo è fuori di vista, la cache del client viene reso nullo, una volta che sullo schermo è chiamato ancora una volta, locali la cache viene creata e il timer parte e inizia il polling.

Speranza che aiuta,

Ernani