EAR с несколькими войнами или войнами с удаленным EJB - PullRequest
0 голосов
/ 09 марта 2012

Я уже некоторое время пытаюсь понять это и решил спросить ваше мнение.

Я создаю несколько приложений, которые используют общий набор данных и операций. Каждое приложение имеет определенные данные, которые нужно добавить, но необходимо иметь «вид с высоты птичьего полета» над общими данными, предоставляемыми конкретными приложениями в форме, скажем, «базового» или «фиксированного» веб-приложения. Количество конкретных заявок составляет (потенциально) 20+, а некоторые из них являются только временными (скажем, 4-6 месяцев).

Когда я только начинал с этим проектом (и в Java EE), я создал EAR, поместил общие сущности JPA и EJB в проект EJB и добавил WAR по мере продвижения. Я использовал наследование, чтобы добавить конкретные данные для каждого приложения. Вскоре у меня возникли проблемы, потому что я не мог заставить наследование сущностей работать над различными EJB-проектами, поэтому я закончил с одним большим EJB-проектом, содержащим все сущности, и одной базой данных с именами таблиц с префиксом строки, идентифицирующей приложение: a ситуация мне не понравилась. Кроме того, чем крупнее проект, тем страннее становились сообщения об ошибках во время разработки, а необходимость удалять все сборки и дистрибутивы и перестраивать все с нуля становилась утомительной (NetBeans 7).

Таким образом, со временем я решил отказаться от EAR и наследования и переключился на отдельные WAR и использовать удаленный EJB для управления общими данными. Связывающее веб-приложение -> вид с высоты птичьего полета реализуется через локальный EJB-компонент, вызывающий удаленный EJB-компонент и добавляющий общие данные в локально определенные объекты, так что для всех намерений и целей, похоже, что общие данные являются частью локальной сущности. Я не совсем доволен этим, потому что по какой-то причине он кажется слишком неопределенным, и есть вопрос о дополнительном снижении производительности (что сейчас не так уж плохо, но может быть и вовремя).

Я мог бы пойти на комбинацию из двух (вернуться к EAR и переключить удаленный EJB на локальный, но не наследовать), но потом он вернулся к нестабильной среде разработки. Кроме того, одно небольшое изменение в одном из приложений означает развертывание всего . Почему-то я думаю, что это когда-нибудь приведет к неприятностям (например, сломает не 1, а более 20 приложений одновременно)

Как бы вы это сделали и почему? Есть ли у кого-нибудь опыт работы с проектами сопоставимого размера и как это происходило в процессе разработки (т. Е. Возникали ли какие-либо проблемы по мере роста проекта)?

Спасибо!

1 Ответ

0 голосов
/ 12 марта 2012

Мысли вслух ..

Не отказывайтесь от наследства.Используйте его, но вместо сущностных EJB-компонентов просто с POJO, упакованными в отдельный файл JAR.Разверните все ваши EJB-компоненты в отдельном (большом) EJB-проекте.
Пусть эти EJB-компоненты предоставляют RESTFul WS.

Webapps выполняет вызовы REST для EJB-проекта.Объекты EJB извлекают данные, заполняют POJO, преобразуют их в JSON (или XML) и отправляют в WebApp.

WebApp воссоздает POJO, используя сериализованный объект JSON, и использует его в WebApp.Эти POJO являются своего рода объектами передачи данных.

...