Как структурировать систему Java EE? Как определяется термин «применение» и, следовательно, содержание EAR?

Я занимаюсь проектированием системы сборки и структуры каталогов для большой программной системы, разработанной с помощью Java EE 5. Система сборки будет реализована с использованием ant.

У нас есть несколько разных сервисов, которые сгруппированы по тематике. Каждая служба предлагает либо веб-службу, либо EJB-компоненты. Каждая служба работает на выделенном кластере серверов приложений. Таким образом, у нас есть несколько кластеров, и некоторые из этих кластеров можно логически сгруппировать по темам.

Я читал общие определения и примеры, но меня все еще смущает терминология Java EE:

  • Что такое приложение Java EE? Итак, каково содержимое файла EAR?
  • Что такое проект Java EE? (этот термин используется в Netbeans, а также в соглашениях о проектах руководств по проектам Java Blueprints для корпоративных приложений)

Должен ли я помещать все файлы EJB и WAR-module-package в один EAR, чтобы этот единственный EAR содержал нашу полную систему?

Или я могу поместить каждую группу сервисов в один EAR, несмотря на то, что эти сервисы сгруппированы только логически, но не технически?

Или я могу собрать отдельный EAR для каждой службы, т.е. чаще всего содержащий только один файл jar EJB, а иногда и EJB и файл WAR?

Или мне отказаться от концепции приложений и просто создать файлы EJB и WAR, чтобы у меня был ровно один файл развертывания для каждого кластера серверов приложений?

Думаю, мой главный вопрос: каковы преимущества упаковки файлов EAR?

Насколько я понимаю на данный момент, нужны только файлы EAR-EJB и WAR, а также концепция вложенного подпроекта в ant-build-system и структура каталогов нашего источника?

Изменить: Большое спасибо за ответы! Мне кажется, что запакованное в ухо приложение - это довольно атомарная подсистема. Итак, я предполагаю, что у меня будет вложенная структура подпроекта (только логическая, видимая только для системы сборки и в структуре каталогов исходного кода) и довольно большое количество EAR, каждый из которых содержит в основном только один ejb-jar и / или военный модуль и реализация единой службы (которая развернута в одном кластере серверов приложений).


deployment build-automation packaging jakarta-ee build-process
person SAL9000    schedule 03.01.2009    source источник
comment
Для систем сборки я рекомендую использовать Maven 2 вместо Ant, особенно если вы начинаете с нуля. Maven использует декларативный подход и имеет очень разумные значения по умолчанию для структуры проекта каталогов. Требуется небольшая кривая обучения, но она должна усредняться за время существования вашего проекта.   -  person Brian Matthews    schedule 03.01.2009
comment
Спасибо за подсказку maven! Я боюсь maven, так как будет много вещей, которые нужно будет сделать иначе, чем по умолчанию, и я обеспокоен тем, что maven будет не так легко изучить и использовать, как только мне придется изменить большую часть значений по умолчанию.   -  person SAL9000    schedule 03.01.2009
comment
В проекте такого размера я бы избегал maven как чумы. По моему опыту с обоими, муравей расстроит вас гораздо меньше, особенно в проекте такого размера. У вас будет немного больше работы, но ant будет служить вам лучше по мере масштабирования проекта. Просто проявляйте дисциплину и осторожность.   -  person sblundy    schedule 03.01.2009
comment
Если вам нужно управление зависимостями и артефактами, посмотрите на Ivy. Он взял хорошие идеи maven и перенес их в ant.   -  person sblundy    schedule 03.01.2009
comment
Maven сильно повзрослел с момента своего довольно ухабистого начала. Это все еще инструмент с очень сильной волей, и если вы думаете, что собираетесь бороться с ним, вам лучше где-нибудь еще. Я люблю maven, но считаю, что стандартизация - это король.   -  person krosenvold    schedule 03.01.2009

Ответы (3)


arrow_upward
1
arrow_downward

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

Я думаю, что наиболее важной технической ролью EAR является корень загрузчика классов в среде выполнения. Обычно это означает, что вы можете развертывать разные версии библиотек и свои классы в разных EAR. Это означает, что вы должны оставить путь к корневому классу контейнера довольно пустым (или как указано поставщиком контейнера), потому что он может позволить одному физическому контейнеру обслуживать несколько приложений с использованием возможно конфликтующих библиотек. Это отличная новость, если вы разрабатываете несколько разных приложений с использованием общей кодовой базы. Вы можете развернуть несколько проектов на одной и той же ферме серверов, не беспокоя друг друга.

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

person krosenvold    schedule 03.01.2009

arrow_upward
1
arrow_downward

Здесь много вопросов.

Проекты Java EE - это развертывания EAR или WAR, в которых используется технология Java EE. Если у вас есть WAR с JSP и JDBC-доступом к реляционной базе данных, это проект Java EE. Первоначально предполагалось, что файлы EAR были «корпоративными», а это означало EJB. EAR-файл может содержать EJB, WAR, JAR-файлы и всю энчиладу.

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

Так что хорошо подумайте о том, как вы упаковываете свои услуги. Это не полный ответ, ИМО. Вы должны посмотреть, что делают ваши сервисы и как их можно использовать вместе, чтобы решить, как они должны быть упакованы и развернуты.

person duffymo    schedule 03.01.2009

arrow_upward
0
arrow_downward

В игру вступают как логические, так и организационные соображения. Каждый EAR будет содержать все части, относящиеся к определенной возможности. Мы всегда можем предположить, что каждый EAR будет самодостаточным и может быть развернут в одном или нескольких контейнерах. Типичный подход, которого я всегда придерживался, состоит в том, чтобы каждый EAR содержал одну или несколько jar-файлов и войн. Каждая война или банка содержит какой-то ключевой компонент или набор связанных компонентов. EAR представляет собой корпоративное приложение, которое содержит компоненты и веб-приложения для этого приложения. Примером является система обработки платежей, в которой я участвовал. EAR содержал все необходимое для работы системы обработки платежей. Сюда входило полдюжины банок и 3 войны. Каждая банка представляет собой некую функциональность или логическую группу функций. Каждая война представляла собой веб-приложение. Пример состава баночки:

  • банка для основных функций
  • баночка для ejbs
  • банка для наших продвинутых элементов финансовой математики
  • контейнер для наших элементов безопасности и т. д. Наличие нескольких контейнеров было продиктовано тем фактом, что разные люди разрабатывали разные элементы, поэтому они работали в разных проектах Eclipse и комбинировали их все по мере необходимости. Нет никаких жестких правил, просто то, что работает для вашей команды и ситуации.
person Iggy    schedule 21.05.2011