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

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

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

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

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

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

Ответов: 1

0
16 мар 2019 12:58
Quote:
На нем я разобрался как настроить аутентификацию web-пользователей через JDBCRealm.
Ни разу в жизни не видел чтоб кто-то пользовался JAAS. Обычно за аутентификацию отвечает не сам AppServer, а приложение (с помощью spring security). Оно может хоть само аутентифицировать запрашивая у пользователя имя+пароль, либо редиректить на какой-нибудь сторонний AuthServer. Но я тоже не большой знаток JEE, если работает с JDBCRealm и это устраивает - пусть себе работает.
Quote:
Есть задача поддерживать помимо web-юзеров, пользователей использующих ОТДЕЛЬНОЕ (будь то javaSE, c++) клиентское приложение.
В таком случае сервер все равно должен как-то аутентифицировать - то ли клиент будет запрашивать имя+пароль и отправлять их на сервер, то ли с помощью возможностей в самой ОС типа Kerberos. Если нужен 1ый вариант, то аутентификация может быть такой же как и через браузер - т.е. создается HTTP сессия на сервере, SESSION ID отсылается клиенту и тот теперь с каждым запросом на сервер добавляет этот SESSION ID.
Quote:
Никогда не сталкивался с данной технологией, и по сути в ней не нуждался. Сейчас пытаюсь разобраться к чему она применима в сервере приложений.
Она нужна для асинхронного общения между клиентом и сервером. Т.е. клиент послал сообщение, а сервер вместо того чтоб ответить сразу - пошлет ответ отдельным запросом клиенту. Это общение намного сложней чем синхронное, поэтому если есть возможность выбора - лучше попробовать реализовать общение через HTTP & REST API.

Конечно с REST API нужно подумать как сервер будет общаться с клиентом (если это нужно). Тут либо websockets можно использовать, либо делать endpoint с событиями и каждый клиент раз в эдак 5-10 сек будет его поллить (если 5 сек это допустимо) - такой endpoint можно реализовать в формате Atom Syndicate Protocol или RSS. Если вдруг выберешь последнее - обязательно такие endpoint'ы нужно сделать кешируемыми, чтоб нагрузки на сервер не было большой.
Quote:
И кроме как задач обмена сообщениями внутри приложения, связи приложений внутри сервера и обмена с локальными приложениями сообщениями иного применения не нашел.
Т.е. для реализации подключения типа "Удаленный_КЛИЕНТ<->СЕРВЕР_Приложений" данная технология не подходит.

Чаще всего JMS используется для общения между двумя серверными приложениями. Но строго говоря - это все равно клиент-серверное общение, в сетевых протоколах клиент - это сторона которая запрашивает, а сервер - которая отвечает. Но ты явно имеешь в виду общение между desktop клиентом и сервером. Такое общение редко реализуется через JMS, но это возможно.
Quote:
нет стандартных средств для идентификации и аутентификации отправителя сообщения. Все методы и примеры которые я пробовал возвращали UserPrincipal = ANONIMOUS. У MQ очереди независимая(не имеющая отношения к Glassfish Server) система аутентификации клиента.
Вполне возможно что аутентификацию можно и пользовательскую настроить. Это конечно же нужно копаться в документации, может там плагины какие-то написать прийдется, не знаю.

Но аутентификацию с MS Broker'ом (для того чтоб клиент слал сообщение на сервер) и пользовательскую аутентификацию можно разделить. Пользователя можно аутентифицировать как описано выше, просто SESSION ID в таком случае нужно встраивать в сами MQ сообщения, а на стороне сервера их считывать. Это принципиально ничем не отличается от HTTP, только прийдется многое вручную делать.
Модераторы: Нет
Сейчас эту тему просматривают: Нет