Подтвердить что ты не робот

Лучшее решение для Java HTTP push (messaging)

Мы хотим перенаправить данные с сервера на клиенты, но можем использовать только HTTP (порт 80). Какое лучшее решение для обмена сообщениями? Одна из идей - Comet. Существуют ли другие идеи или рамки, которые предлагают, например, JMS через HTTP. (Да, ActiveMQ поддерживает его тоже, но waggly IMHO. И JXTA поддерживает его, но конфигурация сложна. Предпочтительно что-то простое.)

4b9b3361

ОТВЕТЫ

Ответ 1

Простейшим решением для многих, многих причин является использование подхода на основе кометы (как вы упомянули). Это означает, что клиенты (которым вы хотите "нажимать" сообщения) открывают долговечные HTTP-соединения. Эти подключения остаются открытыми до тех пор, пока не истечет время ожидания или вы отправите клиенту сообщение. Как только происходит, клиент открывает новое соединение.

Непосредственное подключение к клиентам может быть проблематичным по многим причинам: они могут быть за брандмауэрами, которые запрещают это, они могут быть за прокси-серверами и т.д.

Если ваши клиенты не являются настоящими серверами (в этом случае вы действительно являетесь клиентом), попросите их связаться с вами и отправить ответ на mimic push.

Ответ 2

Atmosphere и DWR представляют собой рамки с открытым исходным кодом, которые могут упростить комету на Java.

Ответ 3

Мы использовали COMET совместно с JMS, используя WAS Web 2.0 Feature Pack; на самом деле сервер подписал JMS и COMET-нажал сообщение в браузер. как разработчик, он "чувствовал", как браузер подписывался на JMS. Это "просто сработало", поэтому мы не смотрели дальше на альтернативы.

Я мог представить себе реалистичную реализацию JMS JavaScript в браузере, используя HTTP в качестве транспорта, но мой инстинкт заключается в том, что это будет очень тяжелый. Я не знаю таких реализаций.

Ответ 4

Альтернативный подход к тем, которые уже обсуждались (например, комета и т.д.), заключается в реализации опроса в клиенте. Недостатком этого подхода является то, что вы неизбежно задерживаете время сообщения/события и до тех пор, пока клиент не получит его. Если ваше приложение очень чувствительно к таким задержкам, опрос отключен.

Если допустима определенная величина задержки (как минимум, в несколько секунд), опрос меньше связан с протоколом HTTP. Он также более устойчив к временным сетевым проблемам, поскольку сервер по умолчанию представляет сообщения о очередях и не расстраивается, если клиент не доступен по расписанию.