Как сравнивать CDI и EJB? взаимодействовать?

CDI – речь идет об инъекции зависимостей. Это означает, что вы можете внедрять реализацию интерфейса в любом месте. Этот объект может быть любым, он не может быть связан с EJB. Вот пример того, как вводить случайный генератор с использованием CDI. В EJB ничего нет. Вы собираетесь использовать CDI, если хотите внедрить службы, отличные от EJB, различные реализации или алгоритмы (так что вам вообще не нужен EJB).
EJB, который вы понимаете, и, вероятно, вас смущает аннотация @EJB – это позволяет вам внедрить внедрение в вашу службу или что-то еще. Основная идея заключается в том, что class, в который вы вводите, должен управляться контейнером EJB. Кажется, что CDI действительно понимает, что такое EJB, поэтому на сервере, совместимом с Java EE 6, в вашем сервлете вы можете писать как

@EJB EJBService ejbService; 

а также

 @Inject EJBService ejbService; 

вот что может вас смутить, но это, наверное, единственное, что является мостом между EJB и CDI.

Когда мы говорим о CDI, вы можете вводить другие объекты в управляемые classы CDI (они должны быть созданы только с помощью CDI-систем).

Что еще CDI предлагает … Например, вы используете Struts 2 в качестве среды MVC (просто пример), и вы ограничены здесь, даже используя EJB 3.1 – вы не можете использовать аннотацию @EJB в действии Struts, она не управляется контейнер. Но когда вы добавляете плагин Struts2-CDI, вы можете написать там аннотацию @Inject для одной и той же вещи (поэтому больше не нужно искать JNDI). Таким образом, он усиливает мощность EJB. Но, как я уже упоминал ранее, что вы вводите с CDI – это не имеет значения, связано ли это с EJB или нет, и это его сила

PS. обновленная ссылка на пример

В настоящее время это действительно немного запутанно, поскольку в Java EE есть несколько компонентных моделей. Это CDI , EJB3 и JSF Managed Beans .

CDI – новый ребенок на блоке. Компоненты CDI содержат dependency injection , область scoping и event bus . CDI-бобы являются наиболее гибкими в отношении инъекций и скоринга. Шина событий очень легкая и очень хорошо подходит даже для самых простых веб-приложений. В дополнение к этому, CDI также предоставляет очень продвинутую функцию, называемую portable extensions , которая является своего рода подключаемым механизмом для поставщиков, который предоставляет дополнительные возможности Java EE, которые могут быть доступны для всех реализаций (Glassfish, JBoss AS, Websphere, и т.д).

Бобы EJB3 были дооснащены старой старой моделью EJB2 ^* и были первыми компонентами в Java EE, которыми управляют beans через аннотацию. Компоненты EJB3 include в себя dependency injection , declarative transactions , declarative security , pooling , concurrency control , asynchronous execution и remoting .

Инъекционная инъекция в EJB3-бобах не такая гибкая, как в CDI-компонентах, а EJB3-бобы не имеют понятия обзора. Тем не менее, компоненты EJB3 являются транзакционными и объединены по умолчанию ^** , двумя очень полезными вещами, которые CDI решил оставить в домене EJB3. Другие упомянутые элементы также недоступны в CDI. EJB3 не имеет собственной шины событий, но имеет особый тип компонента для прослушивания сообщений; управляемый сообщением bean-компонент. Это можно использовать для приема сообщений из системы обмена сообщениями Java или из любой другой системы с адаптером ресурсов JCA. Использование полномасштабного обмена сообщениями для простых событий намного более тяжелое, чем шина событий CDI, и EJB3 определяет только слушателя, а не API-производителя.

Управляемые бобы JSF существуют в Java EE с момента включения JSF. Они также содержат dependency injection и область scoping . JSF Managed Beans представила концепцию декларативного обзора. Первоначально области были довольно ограниченными и в той же версии Java EE, где EJB3-бобы уже могли быть объявлены через annotations, JSF Managed Beans все равно должен был быть объявлен в XML. Текущая версия JSF Managed Beans также, наконец, объявляется через аннотацию, а области расширены с помощью области просмотра и возможности создавать собственные области. Область просмотра, которая запоминает данные между запросами на одну и ту же страницу, является уникальной особенностью JSF Managed Beans.

Помимо области видимости, для JSF Managed Beans в Java EE 6 еще мало что осталось. Недостающая область обзора в CDI несчастлива, поскольку в противном случае CDI был бы идеальным супер-комплектом того, что предлагает JSF Managed Beans. Обновление : в Java EE 7 / JSF 2.2 добавлен CDI-совместимый @ViewScoped , что делает CDI действительно идеальным супер-набором. Обновление 2 : в JSF2.3 управляемые bean-компоненты JSF устарели в пользу управляемых бинов CDI.

С EJB3 и CDI ситуация не такая четкая. Модель компонента EJB3 и API предлагают множество услуг, которые CDI не предлагает, поэтому обычно EJB3 не может быть заменен CDI. С другой стороны, CDI может использоваться в сочетании с EJB3 – например, добавление поддержки области EJB.

Реза Рахман, член группы экспертов и разработчик реализации CDI под названием CanDI, часто намекала, что услуги, связанные с моделью компонентов EJB3, могут быть модифицированы как набор аннотаций CDI. Если это произойдет, все управляемые компоненты в Java EE могут стать компонентами CDI. Это не означает, что EJB3 исчезает или устаревает, но только его функциональность будет отображаться через CDI, а не через собственные annotations EJB, такие как @Stateless и @EJB.

Обновить

Дэвид Блевинс из TomEE и OpenEJB славы объясняет различия и сходства между CDI и EJB очень хорошо в своем блоге: CDI, когда выходить из EJB

_{* Хотя это всего лишь увеличение номера версии, бобы EJB3 были по большей части совершенно другим видом боба: простое pojo, которое становится «управляемым компонентом», применяя простую единую аннотацию, а также модель в EJB2, где супертяжелый и требуется слишком подробный дескриптор развертывания XML для каждого компонента, в дополнение к компоненту, который требуется для реализации различных чрезвычайно тяжелых и по большей части бессмысленных интерфейсов компонентов.}

_{** Сеансы состояния без состояния обычно объединяются, сеансовые бранды с состоянием обычно отсутствуют (но они могут быть). Таким образом, объединение обоих типов является необязательным, и спецификация EJB не дает ему никаких прав.}

Альберт Эйнштейн: If you can't explain it simply, you don't understand it well enough

Ejbs и CDI довольно просты в понимании.

EJBs:

1. Всегда будет аннотироваться квалификаторами области, например, @Stateless, @Stateful, @Request и т. Д.
2. Экземпляры Ejbs контролируются инфраструктурой Java EE и объединены. Обязанность структуры EE – предоставить экземпляры для потребителя.

@Stateless

  public class CarMaker(){ public void createCar(Specification specs){ Car car = new Car(specs); } } 

CarMaker аннотируется с конкретным масштабом Ejbs, поэтому Ejb

CDI:

1. Не полностью управляемые инфраструктурой EE, экземпляры должны создаваться сами.

2. Это всегда зависит. позвольте мне объяснить «зависимый» пример:

   class Specification { private String color; private String model; //- Getter and Setter }

Класс Specification – это CDI, поскольку он не аннотируется с областями Ejb, а также должен инициализироваться вашим кодом, а не EE. Следует отметить, что, поскольку мы не аннотировали class Specification , он по умолчанию @Dependent аннотацией @Dependent .

 @Dependent <- By default added class Specification { ... } 

Further reading: вам нужно больше изучать аннотацию области Ejbs и аннотацию области CDI, которая еще больше очистит концепцию