Читаю в последнее время о messaging patterns, event-based interactions и немного запутался. К примеру, есть javaee и есть задача отсылать клиенту новые уведомления в браузер.
Читая о pub-sub (queses и topics), сложилось впечатление, что они больше подходят для java-to-java обмена сообщениями (по-крайней мере нигде не видел, что бы sub на javascript был написан). Почитал так же о long polling и websocket'ах, но сокеты - это ж не асинхронные request-reply (то есть сообщения обязательно нужно хранить в дб, а не в queues, как предлагает javaee). В общем, хотелось бы сообщение пушевать на все подписанные клиенты (а если они оффлайн, то доставить сообщение, когда зайдут), не сохраняя в дб. Наставьте пожалуйста на путь истинный, как такое решается в javaee.
По поводу уведомлений на клиент - а чем не нравится long poling? К тому же Servlet 3.0 (т.е. начиная с tomcat 7) поддерживает асинхронную доставку с сервера). Мы в проекте используем Spring MVC 3.2.3 и его DeferredResult - очень удобная штука, подробнее можете посмотреть здесь http://spring.io/blog/2012/05/16/spring-mvc-3-2-preview-chat-sample
т.е. ничего не мешает вам использовать pub/sub для серверсайд получения обновлений и последующей их асинхронной доставкой на клиент
Spring в текущем проекте не используем, поэтому хотелось бы обойтись более-менее стандартными средствами.
С асинхронной доставкой стало более понятно, спасибо. Появился еще один вопрос: что, если мне приходят уникальные сообщения для каждого пользователя? Не создавать же sub для каждого. Накидывать все в один sub и потом сортировать: если подходит для юзера забирать из queue, если нет, то оставлять там?
Spring предоставляет лишь удобную обертку, сам механизм построен на servlet 3.0 (не знаю используете ли вы его, можете почитать тут http://www.javacodegeeks.com/2013/08/async-servlet-feature-of-servlet-3.html).
В нашем проекте используется асинхронная доставка сообщений приходящих через jms, есть один jms лисенер получающий сообщения (допустим - userId, messageBody) и кладущий их в контейнер держущий deferedResult-ы от активных long-polling запросов (там же проставляется result и объект удаляется из структуры). Без спринга - вариант реализации - использование блокирующей очереди, напр. PriorityBlockingQueue poll() с указанием таймаута на получение (не советую ставить выше 60сек - стандартный http таймаут, мы обычно ставим 50).
Subscriber для каждого пользователя в каком то виде всё равно придется иметь, вам же нужен какой то способ выплюнуть куда то ответ с сервера
Простой
Средний
Средний