|
|
|
Статус выполнения задачи на стороне клиента
|
|||
|---|---|---|---|
|
#18+
Есть приложение: клиентская часть - Swing, серверная часть J2EE на GlassFish. Клиент общается с сервером через Remote интерфейсы Stateless Session Beans. Stateful решили не использовать. Во время долгих задач на сервере (например, "обработай все банковские выписки"), хочется пользователю показывать ход выполнения задачи детально (в виде обновления прогресс бара и сообщений в статус баре). Посоветуйте, как лучше организовать коммуникацию клиента и сервера? Можно ли как-то посылать "push сообщения" от сервера к клиенту? Или лучше пусть клиент периодически опрашивает сервер "дай статус сообщение для меня"? Как шарить sessionId (кстати в тему пост: 15251622 )? Внедрять параметр sessionId во все методы интерфейсов нет большого желания. Заранее спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2013, 15:21:08 |
|
||
|
Статус выполнения задачи на стороне клиента
|
|||
|---|---|---|---|
|
#18+
Vladmir K, лучше не делать реайльный статус бар, а делать фейковый бесконечный. По многим причинам. Но, если надо, то опрашивать сервер (БД) на статус. Например, писать в таблу процент выполнения. Можно взять пример МТС, где вообще не парятся и "когда готово, тогда и готово". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2013, 15:30:02 |
|
||
|
Статус выполнения задачи на стороне клиента
|
|||
|---|---|---|---|
|
#18+
Petro123, ну, снова, привет. Сервер push уже в JEE и HTML5 добавили. А ты пишешь что лучше опрашивать по таймеру... Алё. 2014й год на пороге. Никто уже в здравом уме не опрашивает сервер по таймеру. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2013, 15:43:03 |
|
||
|
Статус выполнения задачи на стороне клиента
|
|||
|---|---|---|---|
|
#18+
Petro123Vladmir K, лучше не делать реайльный статус бар, а делать фейковый бесконечный. Это именно то, как есть сейчас. Лично меня, как юзера, всегда бесит когда процесс идет долго и не понятно работает он или уже завис. У нас данные сливаются с разных баз удаленных, поэтому время может затянуться. Дробить одну большую задачу на мелкие и воркфлоу переносить на клиента я тоже не хочу. Petro123По многим причинам. Если не сложно, по каким? Может мы не все камни видим? Petro123Но, если надо, то опрашивать сервер (БД) на статус. Например, писать в таблу процент выполнения. Можно взять пример МТС, где вообще не парятся и "когда готово, тогда и готово". В этом была моя вторая часть вопроса - как шарить между клиентом и сервером sessionID? А что такое "МТС"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2013, 15:44:11 |
|
||
|
Статус выполнения задачи на стороне клиента
|
|||
|---|---|---|---|
|
#18+
Vladmir KКлиент общается с сервером через Remote интерфейсы Stateless Session Beans. Причем о протоколе ни слова. Выходит RMI? Или нет? Vladmir KПосоветуйте, как лучше организовать коммуникацию клиента и сервера? Можно ли как-то посылать "push сообщения" от сервера к клиенту? Гуглить long polling и server push для используемого протокола. Vladmir KИли лучше пусть клиент периодически опрашивает сервер "дай статус сообщение для меня"? Зависит от различных факторов. Если нагрузка не важна. Если альтарнативные решения выходят слишком сложными, то да. Возможно остаётся только этот вариант, как простой и достаточно подходящий под требования. Vladmir KКак шарить sessionId (кстати в тему пост: 15251622 )? Внедрять параметр sessionId во все методы интерфейсов нет большого желания. Это какое имеет отношение к связке Swing-RMI-EJB? Вообще, традиционно, такое хранят в ThreadLocal через всякие "контексты". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2013, 15:48:42 |
|
||
|
Статус выполнения задачи на стороне клиента
|
|||
|---|---|---|---|
|
#18+
Вот, наткнулся, не хочу новую тему создвать. клиентская часть - Swing, серверная часть J2EE на GlassFish. Клиент общается с сервером через Remote интерфейсы Stateless Session Beans Вот тоже есть ЕЕ приложение, у него есть веб и десктоп клиенты. Какой оптимальный способ организации взаимодействия десктопного клиента с сервером? Как в этой теме, веб-сервисами или еще как-то? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2013, 15:56:00 |
|
||
|
Статус выполнения задачи на стороне клиента
|
|||
|---|---|---|---|
|
#18+
BlazkowiczНикто уже в здравом уме не опрашивает сервер по таймеру. уже привёл пример - МТС. Вообще ничего не опрашивает. Если появились "облака", канва и WebSockets в HTML5 это не значит, что есть показания их вкорячивать в проект. Есть линейка масштабирования проекта от "забить" до "позвонить когда кончу" ))) - пусть решает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2013, 16:01:15 |
|
||
|
Статус выполнения задачи на стороне клиента
|
|||
|---|---|---|---|
|
#18+
Vladmir KА что такое "МТС"? провайдер сотовой связи. Правда там веб проект. Но основа технологии Клиент-сервер - односторонняя связь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2013, 16:03:28 |
|
||
|
Статус выполнения задачи на стороне клиента
|
|||
|---|---|---|---|
|
#18+
javapeckerВот, наткнулся, не хочу новую тему создвать. клиентская часть - Swing, серверная часть J2EE на GlassFish. Клиент общается с сервером через Remote интерфейсы Stateless Session Beans Вот тоже есть ЕЕ приложение, у него есть веб и десктоп клиенты. Какой оптимальный способ организации взаимодействия десктопного клиента с сервером? Как в этой теме, веб-сервисами или еще как-то? По-моему без разницы. На сервисы можно повесить любой фасад и к нему обращаться по любому протоколу. Поэтому сложно сказать чем одно лучше другого. Важно понимать, что любая попытка объединить одно и другое, может в будущем выйти боком. Вот, например, мудрый архитектор решил обращаться на прямую к сервисам через JSON как с декстопа, так и с клиента. Вроде хорошо. Сервер не напрягается от того кто именно к нему обращается. Но с другой стороны, десктоп и web совсем не одно и тоже. Мы терям возможность использовать разные DTO для разных клиентов. Мы терям возможность прикрутить какой-нибудь protobuf и выиграть хороший перфоманс для десткопных клиентов. И т.п. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2013, 16:05:59 |
|
||
|
Статус выполнения задачи на стороне клиента
|
|||
|---|---|---|---|
|
#18+
Vladmir KЭто именно то, как есть сейчас. Лично меня, как юзера, всегда бесит когда процесс идет долго и не понятно работает он или уже завис. У нас данные сливаются с разных баз удаленных, поэтому время может затянуться. Дробить одну большую задачу на мелкие и воркфлоу переносить на клиента я тоже не хочу. Причины: - задачи именно нужно дробить чтобы показать проценты. У вас проще, т.к. уже разные БД разнесены. - Достаточно ЛОГИРОВАТЬ процесс пользователю и не делать никаких процентовок. - Производительность канала и слива данных может быть разной. Т.е. если есть лог: "Старт заливки из Урюпинска", то это тебя бесить не должно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2013, 16:09:37 |
|
||
|
Статус выполнения задачи на стороне клиента
|
|||
|---|---|---|---|
|
#18+
BlazkowiczПричем о протоколе ни слова. Выходит RMI? Или нет? RMI BlazkowiczVladmir KКак шарить sessionId (кстати в тему пост: 15251622 )? Внедрять параметр sessionId во все методы интерфейсов нет большого желания. Это какое имеет отношение к связке Swing-RMI-EJB? Никакого. Это имеет отношение к шаре sessionId. Потому что если userId, то проблем бы не было/ BlazkowiczГуглить long polling и server push для используемого протокола Пока только Сокеты намыли, но как-то... Petro123уже привёл пример - МТС Я уж думал какая-то новомодная технология... ;)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2013, 16:13:49 |
|
||
|
Статус выполнения задачи на стороне клиента
|
|||
|---|---|---|---|
|
#18+
Vladmir KЯ уж думал какая-то новомодная технология... ;)) я тоже думал, когда оставлял заявку))). Всё просто как 3 рубля. На ГосУслугах тоже самое. Но это - Веб! В десктопе можно сделать живее, только геморройнее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2013, 16:18:04 |
|
||
|
Статус выполнения задачи на стороне клиента
|
|||
|---|---|---|---|
|
#18+
Petro123- задачи именно нужно дробить чтобы показать проценты. Мне кажется это спорным. Зачем клиенту нужно знать, что сначала нужно Слить данные, потом их отвалидировать, потом создать недостающие транзакции, затем еще миллион шагов...., затем написать Готов. Логичнее будет, если сервер сам будет говорить клиенту, что он сделал, а что нет. Появляется новый клиент (мобильный или веб) - тоже переносить пошаговость на нового клиента? А если алгоритм меняется, править сразу всех клиентов? я в данном вопросе лентяй ;) Petro123Т.е. если есть лог: "Старт заливки из Урюпинска", то это тебя бесить не должно? Если предварительно я увижу, что данные Успешно слились из Пряникого, то да, будет бесить меньше! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2013, 16:21:04 |
|
||
|
Статус выполнения задачи на стороне клиента
|
|||
|---|---|---|---|
|
#18+
Petro123В десктопе можно сделать живее, только геморройнее. Поэтому и пишу здесь, чтоб было не так больно ж) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2013, 16:22:32 |
|
||
|
Статус выполнения задачи на стороне клиента
|
|||
|---|---|---|---|
|
#18+
Vladmir KЕсли предварительно я увижу, что данные Успешно слились из Пряникого, то да, будет бесить меньше! вооот))) У меня был клиент сервер, где хранимка не могла сказать наверх процент выполнения. (вернее сделать можно, но профи не рекомендуют). Я говорю про крупные части работы. Если они у тебя есть (как куски-файлы при заливке), то делай. .... Я бы делал без двухсторонней, т.к. нужен показ обычного лога. IMHO ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2013, 16:27:10 |
|
||
|
Статус выполнения задачи на стороне клиента
|
|||
|---|---|---|---|
|
#18+
Vladmir KПоявляется новый клиент (мобильный или веб) там всё равно всё переписать imho. В андроиде задача переходит в разряд "сервиса" Удачи ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2013, 16:30:15 |
|
||
|
Статус выполнения задачи на стороне клиента
|
|||
|---|---|---|---|
|
#18+
Vladmir KRMI В RMI вроде можно через Callback делать http://docs.oracle.com/cd/E13211_01/wle/rmi/callbak.htm ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2013, 16:32:49 |
|
||
|
Статус выполнения задачи на стороне клиента
|
|||
|---|---|---|---|
|
#18+
Petro123Я бы делал без двухсторонней, т.к. нужен показ обычного лога. IMHO К этому мы стали склоняться, но хочется избежать таймера. А так же проанализировать другие решения. Petro123там всё равно всё переписать imho. В андроиде задача переходит в разряд "сервиса" А зачем переписывать все потом, когда можно не все? ;) Но это уже совсем другой вопрос... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2013, 16:41:32 |
|
||
|
Статус выполнения задачи на стороне клиента
|
|||
|---|---|---|---|
|
#18+
на самом деле опрос по таймеру - самый ненапряжный вариант, хоть и не модный. Если операция затянется надолго, так, что пользователю захочется закрыть программу, а потом через некоторое время открыть ее снова и посмотреть статус - могут начаться проблемы. Да и базу опрашивать - тоже не всегда прокатит, например, если это длинная транзакция. Хотя, "обработай все банковские выписки" - скорее всего, не такая операция. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2013, 17:05:14 |
|
||
|
Статус выполнения задачи на стороне клиента
|
|||
|---|---|---|---|
|
#18+
ivanraЕсли операция затянется надолго, так, что пользователю захочется закрыть программу, а потом через некоторое время открыть ее снова и посмотреть статус - могут начаться проблемы. Это хорошее замечание. ivanraДа и базу опрашивать - тоже не всегда прокатит, например, если это длинная транзакция. Здесь решаемо. Например логировать через асинхронный метод (@Asynchronous) со своей транзакцией (@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW). Или вообще сообщения не персистить, а хранить в Map в Сингелтоне. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2013, 17:36:01 |
|
||
|
Статус выполнения задачи на стороне клиента
|
|||
|---|---|---|---|
|
#18+
Vladmir K, Можно JMS лог завести и читать его удаленно. Правда, "из пушки по воробьям" выходит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2013, 17:37:39 |
|
||
|
Статус выполнения задачи на стороне клиента
|
|||
|---|---|---|---|
|
#18+
BlazkowiczМожно JMS лог завести и читать его удаленно. Правда, "из пушки по воробьям" выходит. Про JMS думали. По мне так тоже самое, что и @Asynchronous в данном случае Пока почитаю про Callback, а заодно про ThreadLocal. Спасибо за ссылки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2013, 17:42:42 |
|
||
|
|

start [/forum/topic.php?fid=59&fpage=196&tid=2128038]: |
0ms |
get settings: |
8ms |
get forum list: |
19ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
89ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
55ms |
get tp. blocked users: |
2ms |
| others: | 232ms |
| total: | 428ms |

| 0 / 0 |
