Vogliamo inviare dati da un server ai client, ma è possibile utilizzare solo HTTP (porta 80). Qual è la migliore soluzione per la messaggistica? Un'idea è Comet. Ci sono altre idee o framework che offrono diciamo JMS su HTTP. (Sì, ActiveMQ supporta anche questo, ma WHO assomiglia e JXTA supporta anche questo, ma la configurazione è complicata.È preferibile qualcosa di semplice.)La soluzione migliore per Java HTTP push (messaggistica)
La soluzione più semplice per molti, molti motivi è usare un approccio basato su Comet (come Tu citi). Ciò significa che i client (a cui si desidera "spingere" i messaggi) aprono connessioni HTTP longevi. Quelle connessioni rimangono aperte fino a quando non scadono o si invia un messaggio al client. Non appena accade, il client apre una nuova connessione.
La connessione diretta ai client potrebbe essere problematica per molte ragioni: potrebbero essere dietro firewall che non consentono, potrebbero essere dietro a proxy e così via.
A meno che i client non siano server reali (nel qual caso sei davvero il cliente), chiedi loro di contattarti e invia una risposta a imitare push.
Abbiamo utilizzato COMET in combinazione con JMS utilizzando WAS Web 2.0 Feature Pack; in effetti il server ha fatto il JMS iscriversi e COMET-ha spinto il messaggio al browser. come sviluppatore "sentiva" come se il browser si stesse iscrivendo a JMS. Questo "ha funzionato", quindi non abbiamo cercato ulteriori alternative.
Potrei immaginare un'implementazione JMS JavaScript pura nel browser, utilizzando HTTP come trasporto ma il mio istinto è che questo sarebbe molto pesante. Non conosco tali implementazioni.
L'approccio alternativo a quelli già discussi (cioè Comet ecc.) Consiste nell'implementare il polling nel client. Lo svantaggio di questo approccio è che si ha inevitabilmente un ritardo dal momento del messaggio/evento e fino a quando il cliente lo riceve. Se la tua applicazione è molto sensibile a tali ritardi, il polling è fuori.
Se una certa quantità di ritardo (almeno nell'ordine di pochi secondi) è accettabile, il polling è meno di un abuso del protocollo HTTP. È anche più robusto contro i problemi di rete temporanei come il server per i messaggi di coda predefiniti e non si arrabbia se il client non è disponibile nella sua pianificazione.
Non c'è davvero alcuna grande differenza tra polling e connessioni a lunga durata. In entrambi i casi, si avvia un sondaggio, che ritorna immediatamente o con un certo ritardo. Più lungo è il ritardo, minori sono le connessioni che devi aprire. In tutti i casi problemi come le chiamate terminate o senza risposta sono solo portano al prossimo sondaggio. All'interno di HTTP/1.1 la connessione (TCP) rimane generalmente aperta. – eckes
Atmosphere e DWR sono entrambi framework open source che possono rendere Comet facile in Java.
Ho creato un'app di esempio utilizzando Comet, Raphael, Bayeux, Java e Maven che eseguono PaaS Cloudbees e ho scritto un post sul blog, sperando che possa essere utile a qualcuno.
http://geeks.aretotally.in/thinking-in-reverse-not-taking-orders-from-yo
Il collegamento non funziona. –
È giusto? Quando il messaggio arriva al browser viene aperta una nuova connessione? – djna
Il client deve essere programmato per aprire una nuova connessione. In caso contrario, il server non ha modo di comunicare con il client. – cletus
Mi dispiace. Problemi nella comprensione. Il client ha aperto una connessione HTTP di lunga durata. Il server invia messaggi lassù - giusto? Quindi si dice "Quelle connessioni rimangono aperte fino a quando non scadono o si invia un messaggio al client. Non appena accade il client apre una nuova connessione". Sembra che stiamo aprendo una seconda connessione. Perché? Il messaggio che abbiamo appena ricevuto conteneva i dati che vogliamo, no? – djna