Упаковка EJB в JavaEE 6 WAR против EAR

Ответ 1

Важной мотивацией для EJB beans в отдельном JAR является возрастное разделение бизнес-логики и логики представления.

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

Это то, что облегчает традиционный Java Enterprise Archive. EJB beans переходит в JAR файл, который представляет EJB module, в то время как связанные с сетью артефакты (Facelets, backing beans, код утилиты) входят в файл Web Archive (WAR), который представляет Web module. Обратите внимание, что WAR фактически не должен быть файлом. В так называемом взорванном формате это всего лишь каталоги.

Ключевым аспектом этого разделения является то, что эти два модуля изолированы через иерархию загрузчика классов. Web module имеет доступ к ресурсам (обычно beans) из EJB module, а EJB module может ссылаться на ресурсы (обычно библиотеки), определенные в общем зонде EAR. Другое направление невозможно. В частности, EJB module не может получить доступ к ресурсам, определенным в Web module.

Это принудительное исполнение является преднамеренным.

Бизнес-логика должна быть полностью независимой от любой технологии просмотра. Принудительная изоляция предотвращает случайное или непреднамеренное смещение разработчиков от этих проблем. Преимущества этого разделения заключаются в том, что бизнес-логику можно тривиально использовать среди других клиентов Java SE, клиентов веб-модулей, клиентов JAX-RS и т.д. Если в бизнес-логике случайно были зависимости JSF или Servlet, было бы очень сложно использовать ее от клиентов Java SE.

Сравните это с Facelets, не позволяя использовать скриптлеты. Это предотвращает очистку Facelets и позволяет им сосредоточиться только на компоновке компонентов и разметке. Другая аналогия связана с кодированием интерфейсов, который отделяет контракт от реализации.

Таким образом, наличие отдельного модуля EJB на самом деле является лучшей практикой. Однако...

Для небольших проектов, возможно, нет необходимости в этом разделении, и для начинающих программистов может быть сложно обернуть голову вокруг структуры того, что должно идти туда. Таким образом, удаление обязательного разделения упрощает работу неопытных разработчиков с Java EE. Это дает им нежное введение в Java EE, и позже, когда они получат представление о расслоении, они могут затем в любом случае ввести EJB module.

Ответ 2

До сих пор это то, что я получил.

EJB в WAR

профи:

• Упростить разработку и развертывание

• Вы можете использовать методы Session Bean как службу REST с аннотацией @Path. См. здесь

минусы:

• Поиск JNDI не поддерживается, поэтому я считаю, что вы не можете выполнять RMI из другого клиента приложения

• Как отметил арджан, в дизайне отсутствует модульность.

Ответ 3

Я думаю, что вам нужно иметь в виду, что EJB внутри WAR является частью EJB Lite, что является хорошим усилием, чтобы приложение работало с минимальными услугами, предоставляемыми контейнером EJB. Поскольку вам не всегда нужны все услуги, предоставляемые контейнером EJB.

Итак, если вы задаетесь вопросом о плюсах и минусах упаковки EJB в WAR или в EAR, тогда вы должны подумать о том, сколько услуг вам нужно.

НТН.

Ответ 4

В настоящее время я изучаю руководство для сертификации EJB 3.1 и должен проверять каждую его особенность. И все они доступны при использовании войны.

Это совсем другое EJB Lite из упаковки WAR.

Вы можете иметь некоторую логическую модульность, используя jjb jars, которые вы можете включить в свой веб-проект. Но все модули имеют одну и ту же среду (jndi), поэтому могут произойти некоторые столкновения имен. В проекте EAR каждый модуль имеет собственное пространство имен.

Ответ 5

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

Когда я работал над EJB в WAR, используя NetBeans 7.1.3, Glassfish 3.1.2.2 и JRebel для более быстрого развития, я понял, что JRebel работает только с перезагрузкой изменений, выполненных в модуле EJB, если он был развернут в пакете EAR. Если бы я сделал простой пакет WAR, загрузчик классов поступил бы совершенно странно на этапе разработки и вызвал множество случайных ошибок.

Во всяком случае военный пакет в обычном развертывании работал отлично как mentiod другими.

Также в пакете WAR изменения в строках NamedQuery не отображались после сохранения и компиляции. Если я упакован в EAR, разработка была плавной и быстрой. Конечно, это может быть ошибкой и в JRebel.