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

Question

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

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

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

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

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

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

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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