Упаковка EJB в JavaEE 6 WAR против EAR - PullRequest
Новая
       80

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

27 голосов
/ 14 декабря 2010

Начинаем новый проект и хотели бы узнать плюсы и минусы упаковки EJB в WAR против EAR.

Будет ли JNDI все еще работать, когда EJB находятся в WAR?эффективность?и т. д.

Спасибо.

Ответы [ 5 ]

54 голосов
/ 27 декабря 2010

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

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

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

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

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

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

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

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

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

6 голосов
/ 29 декабря 2010

Пока это то, что я получил.

EJB в WAR

плюсы:

  1. Проще разрабатывать и развертывать

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

минусы:

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

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

5 голосов
/ 25 декабря 2010

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

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

НТН.

4 голосов
/ 07 марта 2011

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

EJB Lite очень отличается от WAR-упаковки.

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

2 голосов
/ 10 января 2014

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

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

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

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

...