Glassfish Server + Remote Client. Идеи, протоколы обмена, любая информация! И о применение JMS

Здравствуйте, форумчане!
Пришло то время, когда мне пришлось ввалиться в пучину jEE и... Глаза разбегаются, ничего не понятно. А на изучение каждой детали и действия в слепую попросту не хватает времени. Очень нужна помощь разбирающихся в платформе Java EE...

Вопрос 1. Про удаленные клиенты (будь то javaSE, c++) приложения.
Есть сервер приложений GlassFish (использую 5+).
На нем я разобрался как настроить аутентификацию web-пользователей через JDBCRealm.

Есть задача поддерживать помимо web-юзеров, пользователей использующих ОТДЕЛЬНОЕ (будь то javaSE, c++) клиентское приложение.
Каким средствами сервера можно подключить этих юзеров? И какие методы авторизации для них могут быть предоставлены?
Конечно можно было бы извратиться и создать свой собственный тип вылосыпеда, но наверняка имеется встроенное решение, которое более продуманно и лаконично.
Есть ли какие-либо идеи реализации у кого-нибудь?


Вопрос 2. Про JMS.
Никогда не сталкивался с данной технологией, и по сути в ней не нуждался. Сейчас пытаюсь разобраться к чему она применима в сервере приложений. И кроме как задач обмена сообщениями внутри приложения, связи приложений внутри сервера и обмена с локальными приложениями сообщениями иного применения не нашел.
Т.е. для реализации подключения типа "Удаленный_КЛИЕНТ<->СЕРВЕР_Приложений" данная технология не подходит. Мои причины так думать:
нет стандартных средств для идентификации и аутентификации отправителя сообщения. Все методы и примеры которые я пробовал возвращали UserPrincipal = ANONIMOUS. У MQ очереди независимая(не имеющая отношения к Glassfish Server) система аутентификации клиента.
Насколько мои представления относительно данной технологии верны, может ли кто пояснить в чем я заблуждаюсь?

Может кто что объяснить по моим вопросам? Может я что-то не так понимаю и намешал кашу у себя в голове)) Буду рад любой документации и ссылкам, любой информации и комментариям!!!

0

1. возьми спринг, там есть и секурити и ещё много чего
2. для взаимодействия с клиентами подходит рест

0

Спасибо, xoraxax!

Мне Glassfish\Payara кажутся более правильным выбором, как минимум для старта работы с EE. Это все таки эталонная реализация. И по Spring security я году так в 2016-17 слышал огромное число жалоб, в основном об ужасной документации и потери десятков рабочих часов программистами.

Restful не брал еще в расчет по ресурсозатратам. Это все-таки http. Хотелось бы еще каких-либо вариантов. Или их нет?)

0

1. все пользуются спрингом, всем норм, документация у спринга неплоха. Кроме всего прочего, я не слышал про какие то альтернативы (а вот ты про спринг слышал, хотя от Ява разработки, судя по всему далёк).
2. чем не устраивает http?

0

все пользуются спрингом, всем норм, документация у спринга неплоха. Кроме всего прочего, я не слышал про какие то альтернативы (а вот ты про спринг слышал, хотя от Ява разработки, судя по всему далёк)

Spring это фреймворк, Java EE - набор спецификаций, Glassfish\Payara\JBoss\Windfly - сервера приложений. Это какбы не сравниваемые вещи.

Поймите, у меня вопрос в выборе фреймворка или сервера приложений не стоит, свой выбор я сделал. Он мне кажется правильным. Меня полностью устраивает философия сервера приложений для грядущих целей. И если в дальнейшем что-то вынесу в пользу Spring, могу начать использовать и его. Предпочитаю технологии под задачи подбирать и совмещать при необходимости.

чем не устраивает http?

Почему сразу не устраивает, просто он затратный. Да, при небольшом количестве пользователей это не особо играет роли, но с ростом нагрузки полезной, появляется огромное количество флуда. Рассмотреть сперва альтернативы кажется разумным.

0

Сообщение от 0xd Предпочитаю технологии под задачи подбирать

даже интересно стало какая такая задача что нужно использовать всякие неповоротливые глассфиши?

Сообщение от 0xd Да, при небольшом количестве пользователей это не особо играет роли, но с ростом нагрузки полезной, появляется огромное количество флуда.

подозреваю что ты понятия не имеешь какое кол-во пользователей-клиентов можно поддерживать на http

Добавлено через 1 минуту

Сообщение от 0xd Это какбы не сравниваемые вещи.

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

0