Зачем использовать ухо вместо войны?
Я читал этот и этот, которые несколько связаны с моим вопросом. Но я наткнулся на эту статью, в которой говорится, что EJB могут быть упакованы в военный файл. Если это так, то почему существует потребность в ухе? Объяснение с примером будет высоко оценено.
Ответы
Ответ 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, и базы данных или устаревшие машины на задней панели. Трехъярусные приложения, которые работают таким образом, расширяют стандартную двухуровневую модель клиент-сервер, размещая многопоточный сервер приложений между клиентским приложением и внутренним хранилищем.
![Multitiered Applications]()
Поэтому обычно мы хотим иметь 2 или 3 разделенных слоя:
-EAR (E nterprise Application AR)
-EJB (E nterprise J ava B)
-WAR ( W eb AR chive)
а иногда JPA ( J ava P сопротивление A PI)
Надеюсь, вы найдете это полезным,
Спасибо.