Queremos enviar datos de un servidor a clientes, pero solo podemos usar HTTP (puerto 80). ¿Cuál es la mejor solución para enviar mensajes? Una idea es Comet. ¿Hay otras ideas o marcos que ofrecen digamos JMS sobre HTTP? (Sí, ActiveMQ también lo soporta, pero waggly en mi humilde opinión. JXTA lo admite también, pero la configuración es complicada. Se prefiere algo simple)Mejor solución para Java HTTP push (mensajería)
La solución más simple por muchas razones es usar un enfoque basado en Comet (como mencionas). Esto significa que los clientes (a los que desea "enviar mensajes") abren conexiones HTTP de larga duración. Esas conexiones permanecen abiertas hasta que expire el tiempo de espera o le envía un mensaje al cliente. Tan pronto como sucede, el cliente abre una nueva conexión.
La conexión directa a los clientes puede ser problemática por muchas razones: pueden estar detrás de firewalls que no permiten eso, pueden estar detrás de proxies, etc.
A menos que sus clientes sean servidores reales (en cuyo caso usted es realmente el cliente), solicíteles que se comuniquen con usted y envíen una respuesta a mímica.
Utilizamos COMET junto con JMS usando WAS Web 2.0 Feature Pack; en efecto, el servidor se suscribió a JMS y COMET-empujó el mensaje al navegador. como desarrollador, "sintió" que el navegador se suscribía a JMS. Esto "simplemente funcionó", así que no buscamos alternativas.
Pude imaginar una implementación JMS de JavaScript puro en el navegador, usando HTTP como medio de transporte pero mi instinto es que esto sería muy pesado. No conozco tales implementaciones.
El enfoque alternativo a los ya discutidos (es decir, Comet, etc.) es implementar el sondeo en el cliente. La desventaja de ese enfoque es que inevitablemente tiene un retraso desde el momento del mensaje/evento y hasta que el cliente lo recibe. Si su aplicación es muy sensible a tales retrasos, la votación está terminada.
Si es aceptable una cierta cantidad de retraso (como mínimo en el orden de algunos segundos), el sondeo es un abuso menor del protocolo HTTP. También es más robusto contra problemas temporales de red ya que el servidor colas por defecto los mensajes y no se molestará si el cliente no está disponible en su horario.
Realmente no existe una gran diferencia entre el sondeo y las conexiones de larga duración. En ambos casos, usted initate una encuesta, y se devolverá de inmediato, o con un poco de retraso. Cuanto más larga sea la demora, menos conexiones habrá para abrir. En todos los casos, los problemas como las llamadas terminadas o no respondidas solo conducen a la próxima encuesta. Dentro de HTTP/1.1, la conexión (TCP) generalmente permanece abierta. – eckes
Atmosphere y DWR son marcos de código abierto que pueden hacer Comet fácil en Java.
Creé una aplicación de ejemplo usando Comet, Raphael, Bayeux, Java y Maven ejecutando PaaS Cloudbees y escribí una publicación en el blog sobre ella, espero que sea útil para alguien.
http://geeks.aretotally.in/thinking-in-reverse-not-taking-orders-from-yo
El enlace no funciona. –
¿Es eso correcto? Cuando llega el mensaje al navegador, ¿se abre una nueva conexión? – djna
El cliente debe estar programado para abrir una nueva conexión. Si no lo hace, el servidor no tiene forma de comunicarse con el cliente. – cletus
Lo siento. Tener problemas para entender El cliente ha abierto una conexión HTTP de larga duración. El servidor envía mensajes allá arriba, ¿no? A continuación, diga "Esas conexiones permanecen abiertas hasta que se agote el tiempo de espera o le envíe un mensaje al cliente. En cualquier momento, el cliente abre una nueva conexión". Parece que estamos abriendo una segunda conexión. ¿Por qué? El mensaje que acabamos de recibir contenía los datos que queremos, ¿no es así? – djna