Хотелось бы узнать, может ли кто-нибудь разъяснить мне некоторые понятия, которые я до сих пор не собираюсь интегрировать в веб-приложения. До сих пор я работал с CometD и Activemq в проекте, который существует уже несколько лет, но для того, что я видел, есть другие варианты, намного более простые и поддерживаемые сообществом, но я все еще не получите всю картину доступных вариантов.Каковы доступные параметры при разработке развязанного, масштабируемого веб-приложения с перенесенными серверами событиями?
Так что, на мой взгляд, на данный момент наиболее распространенным способом получения событий, вызванных сервером, является использование веб-карт. Реализация является специфичной для сервера, а наиболее используемая - Jetty. Но поскольку для этого требуется браузер, совместимый с websocket, есть некоторые рамки, которые могут предоставлять веб-узлы и падать, чтобы отменить методы ajax, если это не вариант, например SockJS, который имеет реализацию для клиента и для серверной части. Исходя из этого, с весны 4 есть шаблоны, которые позволяют вам использовать SockJS за кулисами и просто предоставлять клиентскую реализацию кода с помощью SockJS и позволять программисту обрабатывать серверную сторону более простым способом.
Помимо этого, брокеры могут понимать протокол websocket, поэтому брокер может получать сообщение от веб-браузера, а затем отправлять сообщение напрямую. Существует также протокол STOMP, который также реализует брокеров, который позволяет системе отправлять/получать сообщения через websocket в/из веб-браузера. Один вопрос, который у меня есть об этом, - это протокол STOMP, который всегда используется брокером для отправки или получения сообщения или из веб-браузера? Или это всего лишь одна альтернатива? В чем разница, если это позже?
Еще один вариант, который я видел, - использование рамки, такой как верблюд. В этом случае веб-браузер будет разговаривать с компонентом websocket верблюда, и оттуда он может быть направлен непосредственно брокеру с помощью jms. Преимущество, которое я вижу в этом, - это возможность внедрения процессоров как часть маршрута от браузера к брокеру, что позволяет продолжить обработку безопасности и уменьшить трафик, который брокер должен будет обрабатывать в случае недопустимых/неавторизованных сообщений. Camel мог бы даже слушать сообщения с использованием компонента STOMP, что было бы еще одним вариантом маршрутизации.
Итак, до этого момента я не знаю, правильно ли я понимаю, или если я упускаю или неправильно понимаю что-то. Если все правильно, кажется, что использование такой структуры, как SockJS, является лучшим вариантом, доступным на данный момент. Использование Spring 4 для упрощения вещей - это вариант, но не очень необходимый. Если для проекта требуется интеграция различных систем с использованием брокера jms, реализация затем падает, чтобы использовать SockJS для отправки сообщений на серверную сторону, а затем просто направлять сообщения в правильную систему. Но на данный момент есть варианты, упомянутые ранее, как использование верблюда для маршрутизации сообщений или прямой отправки сообщений брокеру. Какой был бы лучший вариант или какие были бы различия? Если я добавлю проблему STOMP к проблеме, то что этот протокол дает мне, что я не могу обрабатывать только с помощью websockets или верблюда?
Надеюсь, я ясно дал понять. Я думаю, что эта тема включает в себя несколько технологий и рамок, и довольно сложно выразить все мои опасения, не доводя до конца многое.
Заранее спасибо.
Так для того, что я понимаю то, мои предположения о SockJS и весной были правы, но не другая часть о WebSocket и ТОПАЮТ. Чтобы использовать веб-узлы напрямую с брокером, вам нужно указать протокол (STOMP или MQTT), простые сетевые элементы не являются опцией. Итак, есть ли какая-либо польза в использовании этого вместо использования чего-то вроде верблюда для маршрутизации сообщений с канала websocket брокеру с помощью JMS? Нельзя ли перегрузить брокера, если он получает все эти сообщения без фильтрации? Как насчет безопасности? Как вы защищаете сообщение, поступающее непосредственно к брокеру? Благодарю. – Kilian