Лучшая структура Java для веб-узлов на стороне сервера

Ответ 1

jWebSocket теперь включает в себя движок Jetty 8.0, включая SSL, и включает в себя множество приятных для использования функций. Он обеспечивает кросс-браузерные и кросс-платформенные совместимые клиенты, даже больше мобильных приложений, например. под Android, Symbian и BlackBerry. Сервер может быть легко расширен с помощью подключаемого модуля и уже включает в себя множество из них (например, для аутентификации/авторизации, JDBC, SMTP, XMPP/Jabber, RPC, Twitter, Filesharing, Chat и т.д.). Просто проверьте это... http://jwebsocket.org. Ждем ваших отзывов.

Отношения Alex

Ответ 2

Я бы пошел с проверенными серверами сервлетов Java: Jetty или Resin. Они были расширены для обработки WebSockets:

Jetty WebSockets

Resin WebSockets

Мой личный выбор - Jetty, поскольку он очень прост в использовании, и я использовал его как встроенный сервер в нескольких проектах.

На блоке также есть несколько новых детей, например Atmosphere и jWebSocket, но для серверов я предпочитаю проверенное решение. Jetty и Resin также являются родовыми серверами Servlet, поэтому вы можете использовать один продукт для всех ваших потребностей в обслуживании.

Ответ 3

PlayFramework! - это еще один очень хороший вариант.

Ответ 4

FYI, Атмосфера работает поверх смолы, GlassFish и Jetty. Атмосфера освобождает вас от застревания с одним сервером, предоставляя вам переносимость Websocket среди серверов Websocket. Он также предлагает клиентскую библиотеку, которая может выбрать лучший транспорт в случае, если веб-обозреватель не поддерживается браузером. Таким образом, вы не можете сравнивать Атмосферу с Jetty или Rsin

Ответ 5

Взгляните на Atmosphere. Вот статья о websocket и атмосфере.

Ответ 6

В то время как я очень сильно оцениваю реализации JWebsockets и Autobahn, я предпочитаю Atmosphere.

Ramp-Up:: Время разгона низкое. Франсуа Аркан прилагает много усилий для тестирования и примеров, помогая каждому достичь быстрых побед. (И я не знаю, почему он способен так быстро реагировать на любые архитектурные вопросы, которые я поднимаю. Впечатляет.)

Перспектива обслуживания:: Для меня удобство обслуживания является основополагающим, если программное обеспечение выходит за рамки основной версии версии 1.0.0. Проект поддерживается на верхнем уровне Maven-POM с правильно построенной иерархией. Это предотвращает несовместимость библиотек. Библиотеки ссылаются на правильный уровень. Это хорошо сделано.

Техническая/функциональная перспектива:: Он предлагает клиентскую библиотеку Java SE (wasync), которая может либо выполнять встроенную связь через websocket (onMessage), либо создавать аннотации Джерси REST (@Path). Впоследствии это делает его настолько простым, насколько это возможно, с сохранением открытого соединения для подписки и популярной парадигмы удаленных процедур (RPC). Это обычная попытка объединить эти две парадигмы. См. Также http://wamp.ws/, который подходит для того же подхода. Кроме того, библиотека предлагает установить свойства QoS, такие как надежность (например, в случае отсоединения клиента) и надежность (кэширование непоставленных сообщений). Это отлично подходит для профессионального программного обеспечения для использования.

Ответ 7

Возможно, вам стоит попробовать Bristleback Server? Используя Bristleback, вы можете выбирать из нескольких движков WebSockets, таких как Jetty, Netty и Tomcat. У вас может быть автономный сервер, а также веб-приложение, использующее WebSockets (Jetty и Tomcat 7). Bristleback использует Spring Framework. Если вы работаете с веб-фреймворками, такими как Struts, Stripes или Play!, вам будет очень легко начать. Конечно, у Bristleback есть своя клиентская библиотека JavaScript для еще более простой разработки.

Полное раскрытие информации: Я являюсь одним из соавторов сервера Bristleback Server.

Ответ 8

Я также добавил бы vert.x в список. Он может использовать серверные веб-узлы и SockJS (эмуляция веб-узлов, когда браузер их не поддерживает).

Обновление:
Undertow http://undertow.io также поддерживает веб-сайты.

Ответ 9

Следуйте моему блогу. Я буду готов к выпуску когда-нибудь в недалеком будущем. Легкий вес был подчеркнут во всем этом, но он также быстро. Я еще не знаю, насколько он будет расти до более высоких нагрузок. Но я некоторое время работаю над демо с относительно низкой нагрузкой и тем, что у меня работает. (Позже я испытаю более тяжелые нагрузки и убедитесь, что он может быть увеличен.)

http://highlevellogic.blogspot.com/2011/09/websocket-server-demonstration_26.html

Ответ 10

Если вы ищете инфраструктуру для управления сообщениями, группировку пользователей ( "комнаты" ) и синхронизацию данных ( "общие переменные" ), вам может потребоваться рассмотреть Union Platform:

http://www.unionplatform.com

[Полное раскрытие: я являюсь одним из соавторов Союза]

Ответ 11

Почему бы вам просто не написать свое приложение на открытом стандарте, например JMS, и позволить клиентам сидеть на шине JMS в качестве клиентов сообщений? Весь смысл веб-дескрипторов заключается в том, чтобы принести любой собственный TCP-протокол непосредственно клиенту, а не преобразовывать его с вашего конца на http-запрос/ответ.

Ваши службы заднего плана будут разговаривать с брокером JMS, таким как ActiveMQ, и ваши клиенты говорят AMQP в браузере через Javascript API, который выглядит так же, как JMS API в Java. Все, что вам нужно для этого - это шлюз websocket, например Kaazing имеет такой шлюз, все, что он делает, направляет ваш трафик JMS TCP на веб-клиентов через веб-узлы. Они также обеспечивают разветвление, так что вы не перегружаете свою JMS-шину, т.е. Вы просто используете несколько соединений с брокером, чтобы разгрузить миллионное соединение с клиентом браузера.

Суть в том, что вам не нужно привязываться к какой-либо конкретной платформе. Придерживайтесь стандартов, таким образом у вас есть 100% -ная свобода замены компонентов по мере изменения вашей среды.