Мы хотим перенаправить данные с сервера на клиенты, но можем использовать только HTTP (порт 80). Какое лучшее решение для обмена сообщениями? Одна идея - Comet. Существуют ли другие идеи или рамки, которые предлагают, например, JMS через HTTP. (Да, ActiveMQ также поддерживает его, но waggly IMHO, а JXTA поддерживает его, но конфигурация сложна. Предпочтительно что-то простое.)Лучшее решение для Java HTTP push (messaging)
Простейшим решением по многим причинам является использование подхода на основе кометы (например, вы упоминаете). Это означает, что клиенты (которым вы хотите «нажимать» сообщения) открывают долговечные HTTP-соединения. Эти подключения остаются открытыми до тех пор, пока не истечет время ожидания или вы отправите клиенту сообщение. Как только происходит, клиент открывает новое соединение.
Непосредственное подключение к клиентам может быть проблематичным по многим причинам: они могут быть за брандмауэрами, которые запрещают это, они могут быть за прокси и так далее.
Если ваши клиенты не являются настоящими серверами (в этом случае вы действительно являетесь клиентом), попросите их связаться с вами и отправить ответ на mimic push.
Мы использовали COMET совместно с JMS, используя WAS Web 2.0 Feature Pack; на самом деле сервер подписал JMS и COMET-нажал сообщение в браузер. как разработчик, он «чувствовал», как браузер подписывался на JMS. Это «просто сработало», поэтому мы не смотрели дальше на альтернативы.
Я мог представить себе реализацию JavaScript JMS в браузере, используя HTTP в качестве транспорта, но мой инстинкт заключается в том, что это будет очень тяжелый. Я не знаю таких реализаций.
Альтернативный подход к тем, которые уже обсуждались (т. Е. Комета и т. Д.), Заключается в том, чтобы осуществлять опрос в клиенте. Недостатком этого подхода является то, что вы неизбежно задерживаете время сообщения/события и до тех пор, пока клиент не получит его. Если ваше приложение очень чувствительно к таким задержкам, опрос отключен.
Если допустима определенная величина задержки (как минимум, в несколько секунд), опрос является менее злоупотреблением протоколом HTTP. Он также более устойчив к временным сетевым проблемам, так как сервер по умолчанию сообщает о очередях и не расстраивается, если клиент недоступен в своем расписании.
Не существует большой разницы между опросами и долгоживущими соединениями. В обоих случаях вы инициируете опрос, и он будет возвращаться сразу или с некоторой задержкой. Чем дольше задержка, тем меньше подключений вы должны открыть. Во всех случаях такие вызовы, как завершенные или неотвеченные вызовы, просто приводят к следующему опросу. Внутри HTTP/1.1 соединение (TCP) обычно остается открытым. – eckes
Atmosphere и DWR - это рамки с открытым исходным кодом, которые могут сделать Comet простой в Java.
Я создал пример приложения, используя Comet, Raphael, Bayeux, Java и Maven, запустил PaaS Cloudbees и написал сообщение в блоге об этом, надеюсь, это будет полезно кому-то.
http://geeks.aretotally.in/thinking-in-reverse-not-taking-orders-from-yo
Ссылка не работает. –
Это правильно? Когда сообщение приходит в браузер, открывается новое соединение? – djna
Клиент должен быть запрограммирован на открытие нового соединения. Если сервер не поддерживает связь с клиентом. – cletus
Извините. Проблемы с пониманием. Клиент открыл долговременное HTTP-соединение. Сервер отправляет сообщения там - правильно? Затем вы говорите: «Эти подключения остаются открытыми до тех пор, пока не истечет время ожидания, или вы отправите клиенту сообщение. Как только произойдет, клиент открывает новое соединение». Похоже, мы открываем второе соединение. Зачем? Сообщение, которое мы только что получили, содержало нужные нам данные, не так ли? – djna