Так как тут регулярно появляются треды про уйти в Ява из 1С, то для тестирования Ваших способностей для перехода на эту технологию предлагаю решить следующую студенческую лабораторку:

Дано: на стороне сервера запускается очень долгий процесс, который длится несколько минут.

Необходимо сделать так, чтобы чтобы клиент:
- Не ждал, пока завершится долгий процесс
- Имел возможность регулярно получатт статус работы от сервера для его отображения в прогрессбаре.

Конкретные вопросы на знание темы:
- Какую именно клиентскую (браузер) технологию нужно выбрать, чтобы получать фидбек от сервера и не иметь проблем с сертификатами ssl и брандмаурами.

- Сколько endpoint должен в правильном решении предоставлять Java сервер?

- Должны ли на сервере использовться треды (потоки)? какие и в каком количестве? Где и как они должны запускаться?  

- Каким образом эти потоки должны взаимодействовать друг с другом? По какой технологии? Ну или проще: какой паттерн имлементирует это взаимодействие?

- Должен ли клиент получить от сервера дополнительную информацию, чтобы потом узнавать статус прогресса? Если да, то какую? Почему?

- Как реализовать отмену операции на сервере?

Жесть конечно, а не лабораторка. Особенно доставляют вопросы типа "Должны ли". Сразу хочется спросить : кому должны ?

И какое отношение первый вопрос имеет к Java вообще непонятно. Или браузеры уже научились Java вместо JavaScript'а выполнять ?

(1) э... Если тебя называют Ява программистом, то изволь и бек, и фронт уметь. Это подразумевается автоматом.

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

Зы. Зы. Замените "должны ли" на "нужно ли"..

(1) - а клиент (браузер) и сервер будут как бы не взаимодействовать друг с другом?

(0) а вопрос-то твой в чем именно конкретно? Цель ветки какая?

(1) и да, я упустил самое главное - на этом ловят всех июней на собеседованиях:

Почему решение с периодическим опросом сервера (эй, дай мне свой статус, сколько процентов у тебя там выполнено) будет выкинуто Вашим заказчиком как не предназначенное для продакшена?

(2) Действительно. Это какие то дурачки придумали разделение на frontend и backend developer. А в жизни все должны быть fullstack developer. А javascript - это просто разновидность java. Ясно. Понятно.

(6) эта задача тривиальна с точки зрения фронта. Нетривиальна она с точки зрения бекенда.

(7) А что в беке нетривиального? жаба не 1с, она вебсокеты умеет...
Итого 2 потока - считающий и общающийся с клиентом(-ами).
Ну ладно, три. Основной, который управляет всем, считающий и общающийся.
В названиях технологий не подскажу, не силён

(8) так, вот. Ты попался. Вебсокеты с вероятностью 80% будут баниться копроративным брандмауером. Какой дугой, менее известный, но более предназначенный для решения задачи протокол нужно выбрать?

(9) Ну, я бы предложил snmp, но он тоже вряд ли пролезет через прокси...

(10) признайся, ты админ?

https://ru.m.wikipedia.org/wiki/Server-sent_events

О приемуществах SSE перед сокетами

https://stackoverflow.com/a/5326159/444079

(11) Я? Админ???
https://i.ytimg.com/vi/J1fEdcomYb4/hqdefault.jpg

(11)(12) Какая-то неизвестная технология, которая ещё не ушла в массы, поэтому не блокируется файрволами?
Если бек будет работать в корпприложении, то админы позаботятся о пробросе файрвола. Если же это некое левое приложение, то нечего с ним работать на рабочем месте, которое защищено этими самыми стенками.

(13) а зачем ты предложил дичь snmp?

(14) А зачем ты предложил какую-то дичь, о которой я раньше не слышал? Я предложил нормальный вариант. А не нечто, которое ещё и не всеми поддерживается.

Кроме того "SSE connections can only push data to the browser." (вторая ссылка)
Как ты по ним будешь передавать "cancel execution"?

И ещё

- SSE suffers from a limitation to the maximum number of open connections, which can be specially painful when opening various tabs as the limit is per browser and set to a very low number (6). The issue has been marked as "Won't fix" (!!!! - моё) in Chrome and Firefox

= Only WS can transmit both binary data and UTF-8, SSE is limited to UTF-8. (Thanks to Chado Nihi).

(15) пройди по ссылке, посмотри на кейсы. Ты в твитере получаешь уведомления от сервере не по вебсокетам, а по  SSE.

(18) Я в твиттере ничего не получаю ))
А смотреть кейсы? Зачем, если уже по первым предложениям видно, что это не подходит по условиям.

(19) еще раз по буквам:

SSE connections can only push data to the browser. Online stock quotes, or twitters updating timeline or feed are good examples of an application that could benefit from SSE.

...

However, it can be overkill for some types of application, and the backend could be easier to implement with a protocol such as SSE.

Furthermore SSE can be polyfilled into older browsers that do not support it natively using just JavaScript

Зачем тебе при передаче статуса бинарные данные? Ты же не чат со смайликами пишешь и не получаешь файл от сервера?

Зачем мне дополнителные траблы с корпоративным firewall?

Далее:
SSEs are sent over traditional HTTP. That means they do not require a special protocol or server implementation to get working. WebSockets on the other hand, require full-duplex connections and new Web Socket servers to handle the protocol.

Зачем мне использовать дополнительный протокол, писать и поднимать дополнительный веб сокет сервер? Я не онлайн игру пишу, а нотификатор.

(20) @ачем тебе при передаче статуса бинарные данные?@
Я не вижу полного ТЗ. Может, я оттуда диаграмму обработки данных буду отдавать?
"Зачем мне дополнителные траблы с корпоративным firewall?"
А зачем тебе за корпофайром использовать левые программы? Ты собираешься левачить на работе?

(21) я написал уже, сервер тупо должен отдавать число. Грубо говоря процент выполненной работы.

Кроме того, очень мощное приемущество SSE:
If you don’t need to send data to the server in “real-time” (e.g. voice/video chat, multiplayer games, …) go with Server-Sent Events. They are the standard HTTP way of pushing data (like notifications, messages or events) to clients. And they can be added just by implementing an additional endpoint in a controller, lowering the need to refactor the existing code base (in a well structured code base the “implementation cost” of both WS and SSE is the same), and making them somewhat faster to implement (and bring the feature to market).

https://blog.stanko.io/do-you-really-need-websockets-343aed40aa9b

(21) еще раз, типовая ситуация с вебсокетами: ты написал на этих модных сокетах ультрамодную полнодуплескную нотификацию (это когда прогрессбар дает фидбек серверу, ага), а потом раз и на площадке клиента эта фича не работает. И админы не хотят ничего исправлять.

Сегодня тебе передавать число. А для cancel открывать ещё один end-point.
А завтра... Смотреть нужно ширшее. Так что в реальной работе я ещё 10 раз подумаю, как и что. И на собеседовании, если что, смогу отбиться.

(23) Если клиент - это один из 10000 , то это не клиент. А если клиент - это корпорация на 10000 человек, 9000 из которых понадобится моя программа - админы или подвинутся или вылетят.

(24) да, действительно. Может в твою программку на Ява прийдется встроить онлайн realtime multiplayer игруху. С чатом на вебсокетах и няшными аватарками.

https://codeburst.io/polling-vs-sse-vs-websocket-how-to-choose-the-right-one-1859e4e13bd9

Здесь тоже SSE, а не вебсокеты

- Имел возможность регулярно получатт статус работы от сервера для его отображения в прогрессбаре.
- Как реализовать отмену операции на сервере?

Да все просто. В реальном продуктивном софте это нигде не реализовано, потому что цена реализации несоразмерна пользе. Лаба чисто лаба, оторванная от реальности. Понять, простить и не забивать голову.

З.Ы. SSE как панацея, а. Надо ж было такое выдумать.

А как быть с https://developer.mozilla.org/ru/docs/Web/API/Server-sent_events/Using_server-sent_events

Ни эджем и иксплорером не поддерживается?

(28) интересный у тебя взгляд на вещи

Я уже говорил выше - задача из жизни, которую также делают студенты.

К примеру из жизни:

https://wpvivid.com/wp-content/uploads/2019/08/backup-progress-bar.png

(29) открой для себя полифиллы.

Чувак прочитал статью про новую для себя феньку, решил порисоваться какой он крутой.
Ну а чё бы нет?

(32) мне, то есть, не одному это так представилось

(9) эээ.. а разве винсокеты не поверх http и https работают?

(20) ты кажется не понимаешь значения слова could, утверждая что Твиттер использует эту технологию.

(31) это которые твою супер супер технологию в тыкву превращают?

*супер-пупер ))

(35) ты так говоришь, как будто знаешь про все баги реализации

https://github.com/Yaffle/EventSource на IE 11 под win 7

(34) ты знаешь чем винсокет отличается от вебсокета?

Протокол WebSocket — это независимый протокол, основанный на протоколе TCP. Т.е. автоматом у тебя возникнут проблемы с firewall ами и прочими контроллирующими инстанциямм.

(38) опечатался, имел ввиду вебсокеты конечно. И да они работают поверх http и https, дополнительных портов открывать не нужно

(40) откуда ты это вычитал? Вебсокеты работают поверх TCP.

Поверх Http работают push,comet и упомянутый выше как решение проблемы SSE.

(40) почитай основы: http://ru.m.wikipedia.org/wiki/Сокеты_Беркли

(41) да вот есть такой документ, который называется RFC 6455 https://tools.ietf.org/html/rfc6455, и там есть такая фраза "it is designed to work over HTTP ports 80 and 443"

(43)+ да, и, собственно, сам писал приложения с использованием вебсокетов

Э...

The WebSocket Protocol is an independent TCP-based protocol.  Its only relationship to HTTP is that its handshake is interpreted by HTTP servers as an Upgrade request.

Http юзается только для хендшейка.

Вот иллюстрация:

https://hpbn.co/assets/diagrams/1a8db2948eb2aad0dd47470c6c011a42.svg

И теперь самое главное: SSE being based on HTTP, it is more compliant with various elements of existing IT infrastructure (load balancers, firewalls, …)

Т.е. сам EventSource protocol (он зеленый) базируется на HTTP, что делает его проще.

Сам протокол вебсокетов не имеет никакого отношения к http.

Он работает на транспортном уровне, а не на прикладном.

up!

(5) Однако именно так работают некоторые промышленные очереди сообщений

(20) "Зачем тебе при передаче статуса бинарные данные?" // Бинарная передача вместо какого-нибудь человекочитаемого ЖСОН - тоже уже промышленный стандарт

(46) "базируется на HTTP, что делает его проще" // Переведи эту аббревиатуру и не натягивай сову на глобус

(46) Так потребуются хитрые настройки файрволлов для вебсокетов или нет ?

я бы сделал через json нафиг сокеты если речь о http сайтах

(2) с каких пор жава прогрмаммисты должны уметь фронт?

Поток глушить можно только из самого потока , тут аналогия с фоновым заданием - нужно в сам поток передать команду - корректно убиться.
Мне видится веб сервис который слушает и отдает команды , а точней если что принимает то присваивает значения переменным , которые видит так же выполняемый поток. На сервис запросили состояние , он отправил значение переменной Прогресс. Сервису дали запрос - прибить поток , сервис принял - изменил значение переменной. поток ее периодически опросил , получил команду и убился. Все так же как и в 1с

Если встает вопрос выбора протокола , то мне очень MQTT нравится. Он проходит кругом и весит мало

Внимательно перечитав ТЗ понял , что я не знаю честно говоря ответа на данный вопрос , так как не использовал эти технологии в своей жизни.

ОК, теперь я почти у цели: как ты отлаживал получение события на стороне клиента? У меня на короткое время получилось отловить event from server.

у меня хромиум, интеграция с vue

(53) - они обязаны уметь фронт. Их на работу не возьмут без фронта

(0) >> Какую именно клиентскую (браузер) технологию нужно выбрать

Рекомендую Google Chrome

(0) самый простой ответ полуhttp он же http пополам - http/2

(52) вы провалили собеседование

(50) э... HTTP это протокол прикладного уровня. Программироваие на этом уровне по определению должно быть проще, чем у вебсокетов.

(45)(46) ну и какое это отношение к настройке файрволов имеет? мы же за файрволы вроде говорили..

(64) нужен порт 443

(65) Так в чем задача? Обойти ограничения фаервола, если он блокирует 443 порт для браузера???
Если да, то хз как это сделать.
Если нет, то просто используй https для передачи запросов с клиента на сервер.

(0) Может через WebRTC всё это прокрутить?

А в чем проблема настроить правила на корпоративном файрволе, если это требуется для работы компании? По такой логике, файрвол вообще должен все блокировать и не фига в интернеты ходить там всякие.

(65)Если все повесить на 80 работать не будет?

(63) Я и говорю - не натягивай

а зачем ты не используешь а зачем ты не используешь?

ТСу нужно гербалайф какой-нибудь продавать. Так энергично продвигает SSE, что мне аж захотелось податься в веб и вот это всё

short pooling

топик стартер, ты задолбаешься отлаживать этот широко известный в узких кругах протокол

поллинг не так плох, как его малюют в интернетах. И он имеет одно неоспоримое преимущество: твои клиенты не будут ждать недели, пока ты будешь отлаживать это

http://skrinshoter.ru/s/260919/ArwAjFf4
не легка судьба явапрограммиста

я думал тут что полезное, а тут снова выпендреж...