Разработать приложение для хранение тарифов и балансов пользователей в SQL БД с одним HTTP GET методом - получение

данных о пользователях (их тариф, баланс), т.е. выгрузка данных из БД.

Не использовать Spring Boot, схема БД с тестовыми данными в виде SQL скрипта. API должно уметь как JSON, так и XML.

II

Разработать второе приложение для кеширования балансов пользователей, полученных из приложения #1. Приложение должно

раз в N секунд опрашивать приложение #1, конвертировать XML результат в пару client_id/balance с помощью XSLT,

сохранять значение в кеш. Так же, раз в M секунд, приложение должно публиковать состояние кеша для пользователей,

баланс которых составляет < K в AMQP брокер.

В качестве кеша использовать Couchbase.

Дополнительно #1

Разработать Bash скрипт для развертывания двух приложений и инфраструктуры на Ubuntu 16.04.

Что кто скажет по данному вопросу?
вот сижу думаю брать-не брать

заказчик молчит пока- но на лабу не похоже - особенно часть с баш скриптом и деплой на убунту-это уже девопсовская фича- такое в институте не просят я специально спросил у наших студней

Больше похоже на то,что кто то на работе не справляется и отдал часть на аутсорс

Если трезво свои силы оценивать то скорей всего ты прав.
Если 1ю задачу ,которая жутчайшее легаси-я так понял ему чистый jdbc + servlet нужны со всеми вытекающими отсюда прелестями в виде 100500 xml конфигураций,веб дескприпторов и прочих прелестей,ковыряние с выпиленными ЕЕ модулями и попытки все это дело подружит с томкат и базой.
То 2я задача видется мне в рамказ этого задания практически не выполнимой - не зря он полез на биржу,так как это 100% не учебное задание

когда то твои родственники бегали с копьями за мамонтами и не знали что такое скрипты развертывания))

а разве эту задачу не решить с помощью сервлет+томкат? и реализовать там GET метод выгружающий базу
( кстати метод не один а два как минимум- он написал что апи должно отдавать как json так и xml)

обоснуй почему сервлет это не то ,что требуется в ТЗ?
сервлет с кошкой не справится?

Ну про томкат же нет ограничений,собственно как и про сам спринг ничего не сказано-тоесть можно будет задачку упростить

пс. про Content Negotiation не слышал -почитаю

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

они их руками пишут чтоли?)