click_f

Сами данные авторизации лучше хранить в файле конфигурации. Оттуда они должны доставаться контекстом приложения и подставляться в свойства класса-клиента API. Как-то так.

JNDI можно использовать для доступа к общим ресурсам, вроде соединений с БД, очередей сообщений, конфигурационных переменных. К примеру, можно в настройках сервера приложений создать соединение с БД, которое будет использоваться несколькими приложениями.
Однако, сейчас JNDI становится менее популярным инструментом, так как современные приложения разворачиваются в большинстве случае не в серверах приложений. Для распределённой конфигурации сейчас есть такие инструменты, как Spring Cloud Config, Apache Zookeeper, Consul и прочие.

Если кратко, то обычно, когда у вас есть какой-то сервер приложений, вы там создаете всякие ресурсы (data-source, jms, etc) средствами самого сервера, а не внутри своего приложения. А приложение уже получает ссылку на ресурс из JNDI по имени ресурса.

Мы используем рефлексию для работы с объектами во время выполнения программы.
Наша архитектура не всегда предоставляет доступ к объектам (в некоторых частях приложения нет фабрик, нет реестров объектов, нет синглтонов и пр.) либо не предоставляет интефейса для работы с ними. Но такая необходимость признак не очень хорошей архитектуры.
Если вы хотите тестировать не запуская программу, то рефлексия в принципе и не нужна, только если вы хотите залезть "голыми руками в трансформаторный щиток" и знаете что делаете. Архитектура компонент должна предоставлять вам необходимые интерфейсы для тестирования. Иначе у вас классическая проблема с "testability".
Такая проблема часто возникает когда сначала пишут приложение, а потом думают как бы его протестировать. Но уже поздно. И приходится рефакторить.

Основные отличия - гита от svn - распределенность и хорошая поддержка ветвлений в разработке (ветки).

SVN, конечно же, поддерживает ветки, но при сложных ветвлениях (ветки мержатся между собой) случаются неожиданные конфликты и т.п. Хотя, если у вас классическая схема - фича-ветка от мастера (транка) и обратный мердж в мастер (транк) - разница почти незаметна.

Про распределенность: у SVN центральный сервер, у гита - граф серверов, хотя 99% процентов разработчиков используют локальный репо + один удаленный, т.е. по сути - тот же центральный сервер. Зато, так как репа локальная, гит очень быстр в переключении веток.

Есть еще куча различий и, как плюсов, так и минусов у каждого ПО. Хотя сегодня SVN все реже и реже можно встретить, но в общем для многих рабочих групп его вполне достаточно для полноценной работы. С другой стороны - знать git тоже обязательно сегодня, ибо почти стандарт ;)

Если вот так на первый взгляд поискать "чем svn лучше"...

• работа с бинарными файлами, и быстрее и есть централизованные локи по репозиторию (что важно, ибо мердж бинарного файла обычно не очень эффективен);
  
• есть система управления доступом вплоть до веток;
  
• комит определенного юзера этим юзером и подписан, тогда как в гите аутентификация и поле автора не связаны никак (впрочем, последние две проблемы можно пофиксить хуками);
  
• порядок комитов явный, т.е. есть глобальный счетчик с номером у каждого комита, хотя, конечно, не так принципиально;
  
• частичный чекаут, т.е. начиная с любого узла SVN, удобно, если много мелких проектов - не нужно несколько репозиториев, просто один с папками проектов в корне
  

Но я бы не стал говорить, что svn нормальный, а git нет. Просто он другой и со своими тараканами. Сам долгое время работал на SVN, потом потихоньку перебрались на git в основном из-за подводных камней сложного ветвления.

best practices в таких случаях - не кастовать, а пользоваться полиморфизмом. Ведь декораторы нужны, чтобы что-то декорировать/абстрагировать, а не вытаскивать из них кишки конкретной реализации с помощью каста.

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

Что то я не вижу никакой связи между RxJava и JMS. Это сравнение правил дорожного движения со стандартами коробки передач.

RxJava - о событиях внутри приложения.
JMS - о событиях между приложениями (возможно даже на разных языках и платформах).

У меня был похожий случай.

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

Я сперва реализовал следующим образом:

1. Поднял WebSocket который слушали все клиенты.
2. Поднял демона, который опрашивал Rest и вытаскивал данные.
3. В случае новых данных демон сувал их в базу и через WebSocket отправлял широковещательное сообщение в виде JSON строки.
4. Со стороны клиента через JS вытаскивал данные с сокета и обновлял пользователю интерфейс.
5. Все пользователи имеют актуальные данные без перезагрузки страницы.

Как опрашивал Rest.
1. Создал табличку text + int.
2. В text хранил название таблицы интерфейса, в int - последний инкремент
3. Опрашивал с условием > int
4. Ложил в локальную базу.
5. Оповещал клиентов по WebSocket

Сечас немного по другому. В 1С есть подписка на события, при изменении или создании документа можно вызвать обработчика, в моем случае просто происходил HTTP запрос с передачей данных в post теле JSON сериализации.

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

Так как локальные данные запрашиваются через свой API, то я бы это реализовал по похожему принципу, как работает кеширование. По запросу данных из вашего API, происходит проверка на то, как давно данные обновлялись. Если давно (регулировка времени на своё усмотрение), то происходит запрос на сторонний сервис и данные в локальном хранилище обновляются и сохраняется время последнего обновления. Минус этого подхода в том, что первый запрос в некий промежуток времени будет обрабатываться дольше из-за всех операций.

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

Но для решения вашей проблемы нужно учитывать больше нюансов, это лишь общий ответ на основе информации в вопросе.

Напишите файловый сервер с возможностью загрузки файлов через ftp-клиент, через web-морду, через SOAP ( или REST), через мобильную приложуху с аутентификацией, базой юзеров, также можно в базе хранить какую-нибудь метоинформацию о файле. Например, может быть такой маленький личный фотоальбом с подписями(блог-постами, комментами etc.), фотки из которого доступно скачать и залить повсякому. Попробуете всё.
web и Java = Enterprise. Это приложения масштаба предприятия, т.е. они как-то автоматизируют его бизнес-процессы и документооборот, переносят его работу в web и электронный формат. Они также могут общаться с другими приложениями, системами. Отсюда пляшем. Вам нужно какое-то предприятие, у которого вся работа в оффлайн, всё плохо, бюрократия и ад. Придумайте сложный бизнес-процесс со сложными сущностями. Разный и изменяющийся во времени и пространстве уровень доступа. Интеграция с другими приложениями или гос.сервисами. Электронный банк, электронные платежи, электронная валюта. Наворотить можно много чего.
Начните с малого - какой-нибудь справочник-реестр с функциями CRUD - создать, прочитать, редактировать, удалить запись. Далее прикрутите систему прав и ролей пользователей(не все могут создавать, редактировать и тем более удалять). Добавьте работу с файлами - скачать, загрузить, экспорт в pdf и exel. Продолжайте накручивать своё приложение функционалом - личка и чат, доска объявлений, имитация отношений начальник - подчиненный (тайм-менеджмент, таск-менеджмент, сбор отчетов каких-нибудь по работе), уведомления (в почту, в системе, м.б. попробовать с смс), напишите другую маленькую систему и заобщайте их между собой по SOAP или REST(например, другая система может читать из справочника и что-нибудь туда писать). Берите какое-нибудь гипотетическое предприятие (склад, магазин, автосервис, школа, больница, завод и т.д.) и представьте, что ему надо свой документооборот перевести в электронный вид и максимально автоматизировать бизнес-процессы.
Из фреймворков - семейство Spring.

Можно. Достаточно добавить в конфигурацию Hibernate

<property name="hibernate.hbm2ddl.auto">create</property>