Взаимодействие клиент-сервер

 
 
 
Сообщения:167
У меня есть клиент (не веб) и сервер на ejb.
Я могу вызывать методы ejb.
Вопрос, как мне сделать чтобы сервер мог уведомлять клиент об обновлении данных?

I'l be back.
 
 
Сообщения:395
Как вариант - JMS. сервер может отправлять нотификации в очередь, которую читает клиент
 
 
Сообщения:167
Я уже пытаюсь со вчерашнего дня поднять jms. Как я понял клиент может принимать сообщения без сервера приложений (на стороне клиента).
Есть одно сомнение.
У меня должно быть много разных очередей и произвольное количество пользователей.

Если возможность создавать очереди точка-точка динамически?
Допустим появился новый клиент, он прошел авторизацию и подключился к приему jms. Как мне в случае многих клиентов организовать динамическую отправку по точка-точка?
Я так понимаю что в рамках одной только очереди точка-точка сообщение получит только последняя точка, тогда такой вариант не подходит.
Получается только вариант topic, но мне нужно чтобы другие клиенты не получали этих конфиденциальный сообщений.
Я же не могу динамически создавать соединения точка точка (без потери привязки к предыдущей точке)?
Может быть мои желания невозможны?

I'l be back.
Изменен:02 янв 2017 09:31
 
 
Сообщения:395
Может задача сформулирована не корректно? Какая-то экзотика получается...
Если про JMS, то очередей можно и много, но не динамически.
Если надо динамически, то либо topic, либо... Искать что-то другое? Рассылку по мылу не пробовали осмыслить?
Появился клиент, зарегистрировал свое мыло и вуаля... (по идее)
 
 
Сообщения:167
Topic мне пригодится, он выполняет часть задачи.
Но нужна также персональная обратная связь с клиентом для отправки ему конфиденциальных данных. Т.е. отфильтровать topic я не могу (и лишний траффик/нагрузка ни к чему).
Вполне нормальная задача. Мне нужно сообщить клиенту персональные данные, не думал что это будет проблемой.
Сейчас тестовый образец jms уже работает, вопрос пока по архитектуре остается не ясным.
Количество очередей точка-точка будет определяется количеством клиентов, а их может быть очень много. Не буду же я 100 тысяч точек генерить вручную?
Рассылка по email не такая быстрая как требуется.

Подумал. Можно шифровать данные topic чтобы их смог прочитать только тот, кому они адресованы, но это мегакостыль и не подходит. Очень бы хотелось по-человечески.

I'l be back.
Изменен:02 янв 2017 15:05
 
 
Сообщения:167
А я могу один Point to point использовать для разных отправителей и разных получателей одновременно?

Я имею ввиду:
A->(PP_NAME)->B
C->(PP_NAME)->D

I'l be back.
Изменен:02 янв 2017 15:46
 
 
Сообщения:167
Провел эксперимент, вообщем a->b, c->d перемешиваются на одном имени p2p.
Не понятно как теперь организовывать обновления данных в реальном времени.

I'l be back.
Изменен:02 янв 2017 16:09
 
 
Сообщения:167
Узнал про такую штуку, как events, но судя по всему это только для взаимодействия между ejb
https://dzone.com/articles/java-ee6-events-lightweight
А мне надо клиент-серверное.
Получается что можно на событиях сделать такое взаимодействие, если на стороне клиента тоже будет сервер приложений, который будет коннектиться к основному серверу.
Получается слишком сложно, хотелось бы более очевидное и простое решение

I'l be back.
Изменен:02 янв 2017 16:30
 
 
Сообщения:167
activemq позволяет создавать соединения динамически http://activemq.apache.org/how-do-i-create-new-destinations.html
но пока я не понял, возможно ли это в сервере приложений. Сейчас у меня wildfly 10

I'l be back.
 
 
Сообщения:395
А какой будет сценарий использования?
JMS - штука асинхронная. Когда именно придет клиент и вычитает нотификации, отправленные сервером - неизвестно. А может и вовсе не придти - тогда сообщение вечно будет лежать в очереди? (а у Вас 100500 очередей планируется)
Далее, допустим сервер создал очередь для клиента. Как серверу оповестить об этом клиента (хотя бы имя очереди-то надо как-то сообщить...)
Далее, "разбор полетов" как будет проходить в случае если кто-то что-то не доотправил или не дополучил? Работа с инцидентами в случае 100500 очередей - это как делать?
Если обмен по мылу не достаточно оперативен, то предполагается, что клиент постоянно в сети? Может тогда на синхронное оповещение перейти? Что мешает серверу побыть клиентом, а клиенту - сервером?
Изменен:02 янв 2017 18:43
 
 
Сообщения:167
>А может и вовсе не придти - тогда сообщение вечно будет лежать в очереди?
В спецификации это решено через таймер актуальности.

>Далее, допустим сервер создал очередь для клиента. Как серверу оповестить об этом клиента (хотя бы имя очереди-то надо как-то сообщить...)
Этот вопрос разрешим в большинстве случаев. Т.к. клиент сам инициирует данное действие. Но если понадобиться, то было бы интересно как уведомить клиента, если это действие будет инициировано само по себе.

>Далее, "разбор полетов" как будет проходить в случае если кто-то что-то не доотправил или не дополучил?
Спецификация позволяет гарантировать факт доставки (автоматически или вручную).
UPD. Есть еще стойкая доставка (с гарантией однократной доставки) и нестойкая.

>Если обмен по мылу не достаточно оперативен, то предполагается, что клиент постоянно в сети?
В произвольный момент времени с произвольным временем и произвольным качеством связи (отдельный вопрос).

>Работа с инцидентами в случае 100500 очередей - это как делать?
Хороший вопрос, интересно как его решить.

>Может тогда на синхронное оповещение перейти? Что мешает серверу побыть клиентом, а клиенту - сервером?
Как вы это видите?

I'l be back.
Изменен:02 янв 2017 19:11
 
 
Сообщения:395
В случае неопределенного количества клиентов, которые могут быть в сети когда угодно и с каким угодно качеством связи... Я бы выбрал либо мыло, либо создал новый сервис типа "getNotifications...". А сами нотификации хранил бы в БД и выдавал пачкой по запросу. Самое пожалуй простое и необременительное решение.
Минус - все клиенты будут периодически запрашивать эти самые нотификации (вне зависимости есть таковые или нет), создавая бесполезную нагрузку. Но если этот сервис вынести на отдельную ноду, то уже не так печально (хотя какая-то костыльность все равно сквозит в таком подходе...)
P.S. Гарантировать доставку никто не может на 100%. Это в принципе невозможно.
 
 
Сообщения:167
>либо создал новый сервис типа "getNotifications..."
Логично

>Гарантировать доставку никто не может на 100%. Это в принципе невозможно.
интересно почему, если спецификация гарантирует.

Я тут подумал, не знаю насколько это реально. Что если через jndi узнавать имя какого-нибудь ejb, у него вызывать метод, который даст объект, который слушает что-то?

I'l be back.
Изменен:03 янв 2017 09:18
 
 
Сообщения:395
А чем этот способ будет лучше?
Если Ваш клиент периодически опрашивает сервер - лишняя нагрузка на канал.
Если сервер как-то оповещает клиента, то осталось только придумать, как этот "канал оповещения" организовать.

А про гарантированность доставки... Тут можно просто подумать о природе такой гарантии. Ваш MQ сохранит все сообщения и сможет их вернуть даже после сбоя (опять-таки, если диски целы остались :) ).
Но отправляя сообщение, MQ должен убедиться, что оно доставлено. Как? Клиент должен отправить ответное сообщение, что исходное сообщение прошло. Тогда MQ должен оповестить, что получил квиток о том, что клиент получил... Тогда клиент отправляет квиток, что он получили квиток, о том, что MQ получил... И так до бесконечности.
Просто когда говорят о гарантированности имеется в виду некая разумно-достаточная вероятность события.
 
 
Сообщения:139
В общем случае jms-listener на стороне клиента - это клиент в роли сервера. В ряде случаев это неприемлемо. Поэтому реализуется "почтовый ящик": клиент периодически вызывает сервер и получает набор событий, которые возникли с момента прошлого обращения. Очевидное и очень простое решение.

 
Модераторы:wedens
Сейчас эту тему просматривают:Нет