Зачем использовать ухо вместо войны?

Ответ 1

Использование EAR или WAR зависит от сервера, который вы хотите развернуть, вашего приложения и ваших личных предпочтений. Из Java EE6 вы можете упаковать свои EJB вместе с другими сервлетами, jsps и т.д. В WAR файл (в итоге вы получаете веб-приложение, которое можно развернуть только на совместимом с java ee 6 сервером). Если вы упаковываете свое приложение старым способом с ejbs в отдельном пакете и отдельно для войны, вы можете использовать сервер java ee 5, если вы не использовали другие функции java ee6 в своем приложении, вы можете разделить развертывания своих EJB и WAR для четкого разделения вашего бизнес-уровня (EJB) и вашего представления (сервлеты, JSP и т.д.).

Ответ 2

Использование EAR обеспечивает чистое разделение между бизнесом (обычно безстоящим EJB beans, который предоставляет службы back-end/db и может в принципе использоваться не-веб-клиенты) и front-end (файлы xhtml, поддержка JSF beans и т.д.).

Я обычно следую приведенному ниже соглашению, для данного проекта, скажем, "foo":

• foo-ejb.jar имеет EJB beans
• foo-client.jar определяет интерфейс EJB beans ( "клиент" может быть неправильным, "foo-if.jar" или "foo-api.jar" может быть лучшие имена)
• foo-war.war имеет веб-ресурсы

Построение foo-war.war требует только foo-client.jar

Построение foo-ejb.jar требует только foo-client.jar.

Структура в EAR:

foo.ear
 |
 |-- foo-war.war
 |
 |-- foo-ejb.jar
 |
 \-- lib
      |---- foo-client.jar
      |
      \---- (other common jars)

Возможно, есть способ иметь такое же чистое разделение, когда ваш код развертывается как WAR, но выше, что я использую и, кажется, работает для меня (я открыт для предложений, конечно).

Ответ 3

Платформа Java EE использует распределенную многоуровневую модель приложения для корпоративных приложений. Логика приложения разделена на компоненты в соответствии с функцией, а компоненты приложения, составляющие приложение Java EE, устанавливаются на разных машинах в зависимости от уровня в многоуровневой среде Java EE, к которой принадлежит прикладной компонент.

Ниже приведено изображение двух многоуровневых приложений Java EE, разделенных на уровни, описанные в следующем списке. Части приложения Java EE, показанные на этом изображении, представлены в компонентах Java EE.

• Компоненты клиентского уровня запускаются на клиентской машине.

• Компоненты Web-уровня выполняются на сервере Java EE.

• Компоненты бизнес-уровня выполняются на сервере Java EE.

• Программное обеспечение информационной системы предприятия (EIS) работает на EIS
  сервер.

Хотя приложение Java EE может состоять из всех уровней, показанных на рисунке 1-1, многоуровневые приложения Java EE обычно рассматриваются как трехуровневые приложения, поскольку они распределены в трех местах: клиентских машинах, серверной машине Java EE, и базы данных или устаревшие машины на задней панели. Трехъярусные приложения, которые работают таким образом, расширяют стандартную двухуровневую модель клиент-сервер, размещая многопоточный сервер приложений между клиентским приложением и внутренним хранилищем.

Поэтому обычно мы хотим иметь 2 или 3 разделенных слоя:

-EAR (E nterprise Application AR)

-EJB (E nterprise J ava B)

-WAR ( W eb AR chive)

а иногда JPA ( J ava P сопротивление A PI)

Надеюсь, вы найдете это полезным, Спасибо.