Главная
Блог разработчиков phpBB
 
+ 17 предустановленных модов
+ SEO-оптимизация форума
+ авторизация через соц. сети
+ защита от спама

Простая и масштабируемая подписка на события с WebSockets, STOMP, SockJS и Spring Framework 4.0

Anna | 5.06.2014 | нет комментариев

1-й промежуточный релиз Spring Framework 4.0 M1 предоставил поддержку SockJS на стороне сервера — лучшая и особенно полная альтернативная реализация WebSocket. Вам понадобится данный резервный вариант в браузерах, не поддерживающих WebSocket и в обстановках когда прокси препятствует их применению. Проще говоря, SockJS разрешает строить WebSocket-приложения теснее сегодня, которые, ко каждому прочему, умеют прозрачно переходить на резервные вероятности.

Но даже с резервными вариантами задачи остаются. Сокет — достаточно низкоуровневая абстракция и подавляющее множество веб-приложений сегодня не адаптированы для сокетов. Вот отчего протокол WebSocket определяет механизм под-протоколов, тот, что, по существу, разрешает (и поощряет) применение протоколов больше высокого яруса над WebSocket, подобно тому как мы используем HTTP поверх TCP.

2-й промежуточный релиз Spring Framework 4.0 M2 разрешает применять высокоуровневые протоколы обмена сообщениями поверх WebSocket. Для демонстрации этого, мы разберем пример приложения.

Приложение «Stock Portfolio»

Это тестовое приложение, доступное на Github, разрешает пользователям загружать портфель позиций, приобретать и продавать акции; рассылает котировки цен и отображает обновления позиций. Это довольно примитивное приложение. Тем не менее, оно покрывает ряд всеобщих задач, которые могут появиться в браузерных приложениях для обмена сообщениями.

Как именно мы реализуем приложение, сходственное этому? В HTTP и REST мы привыкли полагаться на URL-адреса и способы HTTP, выражающие что необходимо сделать. Но тут только сокет и куча сообщений. Как известить кому предуготовлено сообщение и что оно значит?

Браузер и сервер обязаны договориться об всеобщем формате сообщений, раньше чем эта семантика сумеет быть выражена. Существует несколько протоколов, которые могут подмогнуть. Мы предпочли STOMP в этом релизе, вследствие своей простоте и широкой поддержке.

Simple/Streaming Text-Oriented Messaging Protocol (STOMP)

STOMP — протокол обмена сообщениями, сделанный предельно простым. Основан на фреймах по примеру HTTP. Фрейм состоит из команды, необязательных заголовков и необязательного тела.

Скажем, приложение Stock Portfolio может рассылать котировки, заказчик пошлет фрейм SUBSCRIBE, где заголовок «destination» показывает на что определенно он подписывается:

SUBSCRIBE
id:sub-1
destination:/topic/price.stock.*

Как только котировки акций становятся доступными, сервер отправляет фрейм MESSAGE с соответствующим «destination» и идентификатором подписки, а также заголовок «content-type» и тело:

MESSAGE
subscription:sub-1
message-id:wm2si1tj-4
content-type: application/json
destination:/topic/stocks.PRICE.STOCK.NASDAQ.EMC

{"ticker":"EMC","price":24.19}

Дабы объединить это все в браузере мы используем stomp.js и заказчик SockJS:

var socket = new SockJS('/spring-websocket-portfolio/portfolio');
var client = Stomp.over(socket);

var onConnect = function() {
  client.subscribe("/topic/price.stock.*", function(message) {
      // обработка квоты
  });
};
client.connect('guest', 'guest', onConnect);

Это солидное движение! У нас есть формат стандартного сообщения и помощь на стороне заказчика.

Сейчас мы можем двигаться дальше — на сторону сервера.

Message-Broker

Message-broker — это нормальное серверное решение, где сообщения пересылаются между традиционными брокерами, такими как RabbitMQ, ActiveMQ и т.п. Множество, если не все, поддерживают STOMP over TCP, некоторые — WebSocket, но дальше всех продвинулся RabbitMQ, он, ко каждому прочему, работает и с SockJS.

Наша зодчество будет выглядеть дальнейшим образом:

Это верное и масштабируемое решение, но допустимо не самое оптимальное для рассматриваемой задачи. Message-broker обыкновенно применяется в рамках предприятия. Выставлять его напрямую в сеть не тянет на безукоризненное решение.

Если мы что-то усвоили из подхода REST, так это то, что не стоит раскрывать детали реализации нашей системы, устройство базы данных либо модель предметной области.

Помимо того, вы как Java-разработчик, возможно хотите настроить права доступа, валидации, добавить прикладную логику. В подходе с message-broker сервер приложений находится за брокером, что значительно отличается от того к чему привыкло множество веб-разработчиков.

Вот отчего знамениты библиотеки как бы socket.io. Она примитивна и она нацелена на спросы веб-приложений. С иной стороны мы не обязаны игнорировать вероятности message-broker в плане обработки сообщений, они в этом подлинно отменны — непростая дилемма. Возьмем лучшее от обоих.

Приложение Message-broker

Иной подход заключается в том, Дабы сделать приложение, обрабатывающее входящие сообщения и выступающее в качестве посредника между веб-заказчиками и брокером. Сообщения от заказчиков к брокеру дозволено отправлять через приложение, обратное сообщение также пройдет через приложение к заказчику. Это разрешает приложению определить тип сообщения и заголовок «destination», позже чего решить обрабатывать самосильно либо перенаправить брокеру.

Мы предпочли данный подход. Дабы проиллюстрировать его отменнее вот несколько сценариев.

Загрузка портфеля позиций

  • Заказчик запрашивает портфель позиций
  • Приложение обрабатывает запрос путем загрузки и возврата данных для подписки
  • Message-broker не участвует в этом взаимодействии

Подписка на котировки акций

  • Заказчик отправляет запрос на подписку
  • Приложение передает сообщение брокеру
  • Message-broker передает сообщение каждому подписанным заказчикам

Приобретение котировок акций

  • QuoteService посылает брокеру сообщение с котировками акций
  • Message-broker передает сообщение каждому подписанным заказчикам

Проведение сделки

  • Заказчик отправляет торговый запрос
  • Приложение не обрабатывает его, все сделки проходят через TradeService
  • Message-broker не участвует в этом взаимодействии

Приобретение обновления позиций

  • TradeService отправляет сообщение об обновлении позицию в очередь брокера
  • Message-broker отправляет обновление позиций заказчику
  • Отправка сообщений определенному пользователю рассматривается детально ниже

Сурово говоря, применение брокера сообщений не является непременным. Мы предлагаем «примитивную» альтернативу, работающую из коробки. Впрочем применение брокера сообщений рекомендуется для обеспечения масштабируемости и при развертывании с несколькими серверами приложений.

Фрагменты кода

Давайте разглядим некоторые примеры серверного и клиентского кода.

Это запрос портфеля позиций из portfolio.js:

stompClient.subscribe("/app/positions", function(message) {
  self.portfolio().loadPositions(JSON.parse(message.body));
});

На стороне сервера PortfolioController обнаруживает запрос и возвращает портфель позиций, показывая взаимодействие запрос-результат, которое дюже Зачастую применяется в веб-приложениях.

Источник: programmingmaster.ru

Оставить комментарий
Форум phpBB, русская поддержка форума phpBB
Рейтинг@Mail.ru 2008 - 2017 © BB3x.ru - русская поддержка форума phpBB