Блог

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

Наша цель — иметь меньшие по размеру и более специализированные бизнес-модули, которые могут использоваться в любой комбинации многими различными веб-приложениями. Мы ожидаем, что таким образом приложения станут проще обслуживать по отдельности (по сравнению с монолитным приложением, которое сейчас имеет сильную связь).

Мы планируем организовать это следующим образом:

Где веб-приложения вызывают службы модулей на верхнем уровне для обработки бизнес-логики посредством вызовов методов (предполагаемым протоколом был RMI, но мы открыты для других вариантов).

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

Но мы также пытаемся настроить эти модули как приложения spring boot (используя Spring Boot JPA Starter), потому что это делает разработку намного удобнее.

Мой первоначальный план состоял в том, чтобы реализовать модули с Spring Boot и предоставить тонкий слой компонентов EJB в качестве прокси для spring beans с фактической реализацией сервиса. В компонентах EJB будут внедрены компоненты spring beans с использованием SpringBeanAutowiringInterceptor класса , как в документации spring v4.

Но поскольку этот вид интеграции был удален из spring v5, я не знаю, как действовать дальше.

Они также рассматривают «EJB как фактически устаревшую технологию в настоящее время», как указано в вопросе выше. Но для моего варианта использования я не могу найти достаточно хорошей альтернативы.

До сих пор я думал о следующих вариантах:

1. Использование пользовательского перехватчика, как предполагает проблема. Но это похоже на изобретение старого колеса, от которого отказались (если эта аналогия имеет какой-либо смысл).
2. Удаленное использование Spring является альтернативой, но заставить его работать с Wildfly JNDI для настройки RMI сложно, и попытка выглядит как повторная реализация удаленного использования EJB.
3. Интеграция Spring, я думаю, добавит слишком много сложности и накладных расходов для этой простой задачи.
4. Интеграция на основе сообщений (JMS, MQTT и т.д.) может не подходить из-за синхронного характера того, чего мы пытаемся достичь.
5. Вызовы REST API добавили бы много шаблонного кода (для сериализации и десериализации объектов в JSON, настройки конечных точек и так Далее), А также добавили бы некоторую ovehead из-за обработки HTTP.

Наши цели в этом порядке приоритета следующие:

1. Сделайте эту интеграцию как можно более надежной и отказоустойчивой.
2. Сделайте вызовы бизнес-логики с веб-уровня на уровень сервиса как можно более простыми.
3. Как можно меньше накладных расходов.

При всем сказанном, какой из упомянутых пяти вариантов (или, возможно, другой, который я не рассматривал) был бы лучшим способом и почему?