Добрый день!
Стоит задача мигрировать с клиент-сервера (делфи+оракл) на Jаva EE. Опыт промышленной разработки с Java EE отсутствует.
В существующей системе подход к созданию объектов-сущностей примерно такой:
Существует обобщенный список видов зарегистрированных сущностей, около 200 шт., который хранится в виде таблицы БД. И существует общий список зарегистрированных действий (тоже в виде таблицы БД, около 2000 шт), которые система позволяет выполнять их пользователям над сущностями. При выполнении действия в истории действий над сущностями остается след: кто выполнял, во сколько, с какой рабочей станции и т.п. Поддерживается также историчность и версионность изменений.
Действия выполняются, как правило, в транзакции БД, и своим выполнением они изменяют состояние сущности. Такая модель понятна и пользователям, и разработчикам, и на практике реализация новой функциональности сводится к тому, что мы оговариваем какие новые виды сущностей (атрибуты, характеристики) и действий добавляются в систему, ну и оговариваем функциональность самих действий (когда можно выполнять, когда нельзя)

Простые объекты-сущности могут храниться в одной таблице БД, более сложные сущности могут быть размазаны по десятку таблиц БД. Это и какие-то графики, и тарифы, и ставки, и много-много всего.

Объектная реализация сущностей и действий над ними абстрактно выглядит следующим образом. Есть общие объекты-предки для сущности и действия, в которые помещена базовая функциональность по сохранению и зачитыванию сущности в\из БД.
Перечислю только основные процедуры в базой сущности:
- SaveEntity – сохраняет сущность в БД. В основном, в этой процедуре шлются инсерты и апдейты БД
- LoadEntity – загружает сущность из БД. Здесь в основном селекты.
- ShowEntityForm – показывает карточку сущности пользователю для редактирования
Основная процедура в базовом действии:
- ExecuteAction – исполняет действие в открытой транзакции БД. Как правило, здесь вызывается процедуры SaveEntity сущности, над которой исполняется действие.

Т.к. сущности могут быть сложные, то в системе возможно наследование от 1 до n-объектов.
Соответственно, в объектах-наследниках эти процедуры чтения и сохранения могут быть переопределены, но возможны вызовы унаследованных процедур в объектах-предках. Ситуации и сущности бывают самые разнообразные.

Теперь о том, что меня интересует. Умом я понимаю, что хорошо подходит для двухуровневых систем типа клиент-сервер, не всегда может подходить для многоуровневых распределенных систем.
Возможно ли в Java EE сохранить подход, который был использован годами в существующей системе (модель сущность-действие над сущностью, запись\чтение сущностей, множественное наследование сущностей и действий над ними), или здесь будет лучше пойти другим путем? Если другим, то каким именно?
Какой подход\технологии посоветуете здесь использовать?
Это первая часть. Во второй части мне придется решать вопрос отображения карточки сущности (формы для редактирования сущности) на экране пользователя. Стоит задача организовать работу пользователя через обычный браузер.
В существующей системе используется следующий подход. При выборе определенного пункта меню пользователю загружается картотека доступных ему по правам сущностей. Затем он выбирает нужную ему сущность в списке сущностей и производит какие-то действия. Либо вызывает карточку сущности для внесения необходимых изменений, или выполняет какое-то доступное действие.

От такого подхода хочу заранее отказаться, чтобы исключить лишнюю загрузку БД. Пользователь должен заранее знать внутренний или внешний идентификатор сущности, с которой он хочет работать. Если он не знает его, то только тогда ему предоставить форму для поиска, чтобы он мог её найти.
Собственно, как мне видится, в клиентской части придется решать несколько задач:
- загрузка карточки сущности, если пользователь знает внешний или внутренний номер сущности
- организация просмотра истории выполненных действий над сущностью
- организация формы поиска сущности по косвенным признакам (дата с, по, сумма с, по и т.д.).
Какие технологии посоветуете мне применить для указанных целей? Какой несложный сервер приложений лучше использовать для пилотного проекта?

Заранее спасибо.

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

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

Пока стоит задача сделать пилотный проект на Java EE.

1. Если коротко, то писал её не лично я. Проекту больше 15 лет, работает у 10 крупных клиентов, около 100 человек на проекте (разработчики, тестировщики, аналитики).
Модули настраиваются так, что у одного заказчика он так работает, у другого этак (через настроечные параметры)
2. Что именно (из главного) вы не увидели в моем описании? Вам нужно больше информации об учетных объектах системы?
Пользователи регистрируют информацию о сущностях, выполняют регламентные действия над сущностями, формируют отчеты, сущности живут какое-то время, потом закрываются (сущности присваивается статус «закрыто»)

breathесли все запросы и/или хранимки в базе уже есть и устраивают то оставляйте их как есть

Тут 50*50
В системе хватает недостатков, что-то можно оставить как есть, что-то желательно переделать
breathнах все эти orm.

У меня тоже возникли сомнения, что будет немало вопросов с правильным маппингом
Проходил ранее с ODBC
На простых сущностях это более\менее сносно работает, а вот со сложными сущностями будет много танцев с бубнами. У меня тоже сложилось впечатление, что гораздо лучше, когда сам можешь слать параметризованные инсерты или апдейты

breathраз планируется javaee то всю бизнес логику, бины для работы с базой и тд.. помещаются в @stateless бины.

Вот это вот очень импонирует, чтобы сильно не привязываться к специфике конкретной БД

breathна чем делать клиента.. тоже много всего можно напридумать, смотя что уже есть в голове..

В голове пока только стандартные браузеры (IE, Mozilla, Opera) … а какие ещё варианты?
Ну кроме клиента на том же делфи

breathа вообще готов помочь, за взаимо помощь.. )

В ЛС

Petro123и ни одного в Java?

Ну вот представьте себе
Petro123Вы задаёте вопросы с нуля в Java про то как try обрабатывается.

Можно пояснить, что вы имели ввиду?
Вы по Try – except – обработку исключений? Или это такой тонкий юмор?

Petro123Какие ответы вы тут ожидаете, если вы прошлый проект 15 лет не писали и в Java с нуля?

Вы толи додумываете за меня, толи читаете только то, что вам хочется прочитать. Я нигде не утверждал, что 15 лет ничего не писал. Я говорил, что писал систему (её архитектуру) не я. Это не значит, что я не писал ничего вообще. Я веду в ней лишь несколько направлений (модулей), и сильно отклониться от общей архитектуры я не могу.
Petro123Java - это очень большая бласть знаний. Больше Delphi в сто раз.

Насколько я себе сейчас все представляю, вокруг джавы вертиться куча технологий (сервера приложений, веб-сервисы, фреймворки и пр.). В их разнообразии легко утонуть и самое сложное в них – разобраться что именно мне надо, понять, что лучше использовать в каждом конкретном случае.
Как язык программирования - все +- с прочими языками (с++, делфи и др.) … практически везде одно и тоже - типы, объекты, коллекции, функции, процедуры, операторы, циклы, наследование, переопределение, исключения, обработка исключений, логи и т.п.

breath
и вообще да, если сменили или добавили базу то написали новый бин который реализует по своему общий интерфейс IUserCardDB например, и инжектируете его куда нужно, все запросы или вызовы хранимок к новой базе в нем.

Вот это конечно ново и интересно для меня – под каждый вид БД свой промежуточный интерфейс\набор классов?

breath
остальное приложение работает с ним и не знает из какой реально базы берутся значения.
на текущем проекте при запуске клиентской части (делфи) пользователю дается ещё на выбор алиас БД (несколько значений в комбобоксе, подчитываются из реестра), с которой он может соединиться. Для обычного пользователя это не очень актуально, а вот для саппорта и разработки - очень даже. Связано со многими моментами (тестированием, запуском в промышленную эксплуатацию, переходами на новую версию). Вот этот момент ещё интересен (как обычно поступают в ЕЕ)

В данный момент в версию заказчику (новые доработки, устранение ошибок) передается набор dll и скриптов бд (альтеры, апдейты). Его саппорт сам решает, когда накатывать это на продуктовую базу , (и накатывать ли вообще) перед этим обычно сами ещё тестируют то, что им передали.
Интересно как обычно в ЕЕ поступают. Jar, ear, скрипты бд. Наверное, тоже по-разному бывает.

mad_nazgul3) Микросервисная архитектура. Для каждой единицы доменной модели свой микросервис. С выделенным слоем сервиса.

Вот и у меня похожие мысли были. Разбить систему на сервисы. Наверное, самое сложно будет – и не наплодить избыточных, и не сделать слишком крупных.

Alexey TominПлохая задача.
1. Бизнесу вообще непонятная. Пофиг на чём, лишь бы работало. Задача должна быть ясной. Например "улучшить масштабируемость", "мигрировать в web с клиентами на android/ios", "перейти на технологии, позволяющие нанимать умных людей, а не старых неудачников".

Бизнесу вообще все пофиг, его все устраивает. Ему важно лишь чтобы "все было хорошо" и работы поменьше.

Alexey Tomin2. Переходить с устаревшой в прошлом весе на технологию, устаревшую 5 лет назад это не самый хороший подход. Переходите на набор микросервисов без javaee вообще. Иначе через 5 лет будут те же проблемы- нанаять сможете только тех, кому лень меняться.
Потом устареет набор микросервисов и все по новому кругу. :)

Petro123Логика есть?
Выше написано что 15 лет вы ЭТУ систему не писали.

Ну вы и зануда редкая. Вот что я написал сразу:
Рева1. Если коротко, то писал её не лично я. Проекту больше 15 лет,
Персонально для вас уточню ещё раз и разжую: проекту больше 15 лет, начинали другие люди\разработчики. Я пришел на проект позже, сейчас веду в нем отдельное бизнес-направление (несколько модулей), отклониться от общей архитектуры невозможно. Ещё уточнения нужны?

Petro123Что вы знаете в Java? Есть у вас не Junior из ваших 100 человек?
Расскажу вам хохму. Около полгода назад я сдавал тест по джава из 16 вопросов. Так получилось, что его прицепили попутно к тесту по делфи и ораклу. Просто я заикнулся HR, что хотел бы её приобрести знания и опыт работы с джава. В тесте, в основном, были вопросы по языку программирования, с примерами кода и вариантами ответов. Так вот этот тест я выполнил на 81%, при том, что я до этого ни написал и строчки кода на джаве. Выехал чисто на аналогиях с другими языками и интуиции. Так что, вот такой я самоуверенный тип – и пусть кто-нибудь скажет, что у меня ничего не получится :)

Petro123Вы просто выбрали слишком быстрый старт вывалив в вопрос крупный проект.

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

Alexey TominНадо делать не так. Берётся небольшой кусок, который можно написать за пару месяцев. Да, это будет микросервис.
Пишется, потом в текущей системе меняете что-то, чтобы использовать новый кусок.
Так кусочек за кусочком переделываете всё с тем, чтобы в какой-то момент старая система стала одним из небольших кусочков новой.

Даже затрудняюсь себе представить, как это будет работать и как этот симбиоз должен выглядеть (старое + новое).
В текущей системе толстый клиент написан на Delphi, логин и авторизация пользователя, выбор БД. Клиент может работать только в ЛВС и только на платформе Windows. Есть варианты с терминальным доступом через www, но хотелось бы от него избавиться по ряду причин.
Новая цель – работа через браузер и из любой точки мира (с ноута, планшета и т.п.). Не быть сильно привязанным к конкретной БД. В существующей системе 50% переделать исходя из нового видения. Некоторые решения оказались удачными, а некоторые следует переделать или унифицировать.

Alexey TominПоследовательность кусочков выбрать можете только вы- лучше начитать с чего-то простого.

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

Petro123Рева,
Вы же не спросили: "Как в Java показать 2 строки из БД в IE? ).

Мне кажется, что это так малосущественно :) Ну есть способ 1, 2, 3 … сервлеты, jsp, фреймворки … день-два три и будешь хорошо знать. Написал пару классов\библиотек и используешь везде в проекте. Доработать, поменять базовый класс несложно.
Куда важней, как мне кажется, вопросы архитектуры, общей идеологии системы, которые потом на раз-два не поменяешь.