В настоящее время это действительно немного сбивает с толку, поскольку в Java EE теперь есть несколько компонентных моделей. Это управляемые объекты CDI , EJB3 и JSF .
CDI - новичок в этом квартале. КДИ бобы имеют dependency injection
, scoping
и event bus
. Компоненты CDI являются наиболее гибкими в отношении внедрения и определения объема. Шина событий очень легкая и очень хорошо подходит даже для самых простых веб-приложений. В дополнение к этому, CDI также предоставляет очень продвинутую функцию под названием portable extensions
, которая представляет собой своего рода механизм подключаемых модулей для поставщиков, обеспечивающий дополнительные функции для Java EE, которые могут быть доступны во всех реализациях (Glassfish, JBoss AS, Websphere и т. Д.) .
Компоненты EJB3 были модернизированы из старой устаревшей компонентной модели EJB2 * и были первыми компонентами в Java EE, которыми можно было управлять через аннотацию. EJB3 бобы имеют dependency injection
, declarative transactions
, declarative security
, pooling
, concurrency control
, asynchronous execution
и remoting
.
Внедрение зависимостей в bean-компонентах EJB3 не так гибко, как в bean-компонентах CDI, а EJB3-компоненты не имеют концепции области видимости. Однако bean-компоненты EJB3 являются транзакционными и по умолчанию объединяются в пулы ** , две очень полезные вещи, которые CDI решил оставить в домене EJB3. Остальные упомянутые элементы также недоступны в CDI. У EJB3 нет собственной шины событий, но есть специальный тип bean-компонента для прослушивания сообщений; управляемый сообщениями компонент. Его можно использовать для получения сообщений от системы обмена сообщениями Java или от любой другой системы, имеющей адаптер ресурсов JCA. Использование полнофункционального обмена сообщениями для простых событий намного сложнее, чем шина событий CDI, а EJB3 определяет только прослушиватель, а не API производителя.
Управляемые компоненты JSF существуют в Java EE с момента включения JSF. В них тоже есть особенность dependency injection
и scoping
. Управляемые компоненты JSF представили концепцию декларативной области действия. Первоначально возможности были довольно ограничены, и в той же версии Java EE, где компоненты EJB3 уже могли быть объявлены с помощью аннотаций, управляемые компоненты JSF по-прежнему должны были быть объявлены в XML. Текущая версия управляемых компонентов JSF также наконец объявляется с помощью аннотации, а области действия расширяются за счет области представления и возможности создавать настраиваемые области. Область представления, которая запоминает данные между запросами к одной и той же странице, является уникальной особенностью управляемых компонентов JSF.
Помимо области представления, для управляемых компонентов JSF в Java EE 6 еще очень мало возможностей. Отсутствие области представления в CDI вызывает сожаление, поскольку в противном случае CDI был бы идеальным суперсистемой того, что предлагают управляемые компоненты JSF. Обновление : в Java EE 7 / JSF 2.2 был добавлен CDI-совместимый @ViewScoped , что делает CDI действительно идеальным супер-набором. Обновление 2 : в JSF2.3 управляемые компоненты JSF устарели в пользу управляемых компонентов CDI.
С EJB3 и CDI ситуация не так однозначна. Компонентная модель и API EJB3 предлагают множество сервисов, которые не предлагает CDI, поэтому обычно EJB3 не может быть заменен CDI. С другой стороны, CDI можно использовать в сочетании с EJB3 - например, добавляя поддержку области действия к EJB.
Реза Рахман, член группы экспертов и разработчик реализации CDI под названием CanDI, часто намекал, что службы, связанные с компонентной моделью EJB3, могут быть модифицированы в виде набора аннотаций CDI. Если бы это произошло, все управляемые компоненты в Java EE могли бы стать компонентами CDI. Это не означает, что EJB3 исчезнет или станет устаревшим, просто его функциональность будет представлена через CDI, а не через собственные аннотации EJB, такие как @Stateless и @EJB.
Обновить
Дэвид Блевинс из TomEE и OpenEJB очень хорошо объясняет различия и сходства между CDI и EJB в своем блоге: CDI, когда выделять EJB
* Хотя это всего лишь приращение номера версии, EJB3 beans по большей части был совершенно другим типом bean: простой pojo, который становится «управляемым bean-компонентом» путем применения простой единственной аннотации, по сравнению с моделью в EJB2, где тяжелые и слишком подробный дескриптор развертывания XML требовался для каждого bean-компонента, в дополнение к bean-компоненту, который требовался для реализации различных чрезвычайно тяжелых и по большей части бессмысленных интерфейсов компонентов.
** Сессионные компоненты без сохранения состояния обычно объединяются в пулы, а сеансовые компоненты с сохранением состояния - нет (но могут быть). Таким образом, для обоих типов пул необязателен, и спецификация EJB в любом случае не требует этого.