Упаковка EJB в JavaEE 6 WAR против EAR
Начинаем новый проект и хотели бы узнать плюсы и минусы упаковки EJB в WAR против EAR.
Будет ли JNDI все еще работать, когда EJB находятся в WAR? эффективность? так далее.?
Благодарю.
5 ответов
Важной мотивацией для размещения EJB-компонентов в отдельном JAR-файле является старое разделение бизнес-логики и логики представления.
Поскольку EJB должны концентрироваться исключительно на бизнес-логике, имеет смысл поместить их в отдельный модуль.
Это именно то, что облегчает традиционный Java Enterprise Archive. EJB-бины входят в JAR-файл, который представляет EJB moduleв то время как связанные с сетью артефакты (Facelets, бэк-бины, служебный код) попадают в файл веб-архива (WAR), который представляет Web module, Обратите внимание, что WAR на самом деле не должен быть файлом. В так называемом разобранном формате они являются просто каталогами.
Ключевым аспектом этого разделения является то, что эти два модуля изолированы через иерархию загрузчика классов. Web module имеет доступ к ресурсам (обычно бинам) из 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 тем не мение.
Пока это то, что я получил.
EJB в ВОЙНЕ
плюсы:
Проще разрабатывать и развертывать
Вы можете представить методы Session Bean как службу REST с аннотацией @Path. Смотрите здесь
минусы:
Поиск JNDI не поддерживается, поэтому я считаю, что вы не можете сделать RMI из другого клиента приложения
Как отметил Арджан, ему не хватает модульности в дизайне.
В настоящее время я изучаю руководство по сертификации EJB 3.1 и должен проверить все его возможности. И все доступны при использовании войны.
Это очень отличается от EJB Lite от упаковки WAR.
Вы можете иметь некоторую логическую модульность, используя ejb jar, которые вы можете включить в свой веб-проект. Но все модули используют одну и ту же среду (jndi), поэтому могут возникнуть конфликты имен. В проекте EAR каждый модуль имеет свое собственное пространство имен.
Я думаю, что вам нужно помнить, что EJB внутри WAR является частью EJB Lite, что является хорошей попыткой заставить приложение работать с минимальным количеством сервисов, предоставляемых EJB-контейнером. Потому что вам не всегда нужны все сервисы, предоставляемые EJB-контейнером.
Итак, если вы задаетесь вопросом о плюсах и минусах упаковки EJB в WAR или EAR, то вам следует подумать о том, сколько сервисов вам нужно.
НТН.
Я провел некоторый эксперимент на эту тему и очень удивился результату. Мой вывод никогда не был использовать EJB в WAR. Давайте оставим работу для контейнера EJB, поэтому, если кто-то хочет получить лучшую и безошибочную разработку, используйте вместо этого EAR.
Когда я работал с EJB в WAR, используя NetBeans 7.1.3, Glassfish 3.1.2.2 и JRebel для более быстрой разработки, я понял, что JRebel прекрасно работает только с перезагрузкой изменений, внесенных в модуль EJB, если он был развернут в пакете EAR. Если я сделал простой WAR-пакет, загрузчик классов вел себя совершенно странным образом на этапе разработки и вызвал много случайных ошибок.
Во всяком случае, военный пакет в нормальном развертывании отлично работал, как и многие другие.
Также в пакете WAR изменения в строках NamedQuery не появлялись после сохранения и компиляции. Если бы я упаковал в EAR, разработка была бы гладкой и быстрой. Конечно, это может быть ошибкой и в JRebel.