Что такое EJB и что он делает?

Почему на самом деле использовать их? (Почему бы просто не придерживаться POJO?)

Если вам нужен компонент, который обращается к базе данных, или обращается к другим ресурсам подключения/ каталога, или доступен от нескольких клиентов, или предназначен в качестве службы SOA, EJBs сегодня обычно "больше, сильнее, быстрее (или, по крайней мере, более масштабируемым) и проще", чем POJOs. Они наиболее ценны для обслуживания большого количества пользователей через интернет или корпоративную сеть и несколько менее ценным для небольших приложений в отделе.

1. повторное использование/совместное использование логики в нескольких приложениях / клиентах с Свободной связью.
   EJBs можно упаковать в их собственных опарниках, раскрыть, и вызвать от серий мест. Они являются общими компонентами. Правда, POJOs можно (осторожно!) конструировал как библиотеки и упаковано как опарникы. Но EJBs поддерживает как локальный, так и удаленный доступ к сети-включая через локальный интерфейс java, прозрачный RMI, JMS async сообщение и SOAP / веб-служба REST, сохранение из зависимостей jar cut-and-paste с несколькими (несогласованными?) развертывания.
   Они очень полезны для создания SOA-сервисов. При использовании для локального доступа они POJOs (с добавлением бесплатных контейнерных услуг). Акт проектирования отдельного слоя EJB повышает экстренную внимательность для увеличивать заключение, свободное соединение и сцепление, и повышает чистый интерфейс( фасад), защищающ вызывающих абонентов от сложных обработки & данных модели.

2. масштабируемость и надежность Если вы применяете огромное количество запросов от различных вызывающих сообщений / процессов / threads, они сначала распределяются по доступным экземплярам EJB в пуле а потом встал в очередь. Это означает, что если количество входящих запросов в секунду больше, чем сервер может справиться, мы деградируем изящно - всегда есть некоторые запросы обрабатываются эффективно, а избыточные запросы выполняются для ожидания. Мы Не reach server "meltdown" - где все запросы испытывают ужасное время отклика одновременно, плюс сервер пытается получить доступ к большему количеству ресурсов, чем аппаратное & OS может обрабатывать и, следовательно, сбои. EJBs можно развернуть на отдельном уровне, который может быть кластерный - это дает надежность через переход с одного сервера на другой, плюс оборудование можно добавить к масштабу линейно.

3. Управление Параллелизмом. Контейнер обеспечивает автоматический доступ к экземплярам EJB безопасно (серийно) несколькими клиентами. Контейнер управляет пулом EJB, пулом потоков, очередь вызова и автоматически выполняет блокировку записи на уровне метода (по умолчанию) или чтение блокировки (через @Lock (чтение)). Это защищает данные от коррупции одновременные столкновения записи-записи и помогает последовательно считывать данные, предотвращая столкновения чтения и записи.
   Это в основном полезно для @ Singleton сеансовых бобов, где Боб манипулирует и общие состояние через звонящим клиентом. Это можно легко переключить вручную настройка или программное управление расширенными сценариями для параллельного выполнения кода и доступ к данным.

4. автоматическая обработка транзакций.
   Ничего не делайте, и все ваши методы EJB будут запущены в транзакции JTA. Если вы обращаетесь к базе данных с помощью JPA или JDBC, это автоматически участвует в транзакции. То же самое для вызовов JMS и JCA. Указывать @TransactionAttribute (someTransactionMode) перед методом, чтобы указать, если/как это конкретный метод участвует в транзакции JTA, переопределяя режим по умолчанию:"требуется".

5. очень простой доступ к ресурсам / зависимостям через инъекцию.
   Контейнер будет искать ресурсы и устанавливать ссылки на ресурсы в качестве полей экземпляра в EJB: такие как JNDI хранятся соединения JDBC, соединения JMS / темы / очереди, другие Ejbs, транзакции JTA, сохранение диспетчера сущностей JPA контексты, менеджер сущностей JPA блоки персистентности фабрики, и ресурсы переходники JCA. например, настроить ссылку на другую транзакцию EJB & A JTA & менеджер сущностей JPA & фабрика соединений JMS и очередь:

   @Stateless
   public class MyAccountsBean {
   
       @EJB SomeOtherBeanClass someOtherBean;
       @Resource UserTransaction jtaTx;
       @PersistenceContext(unitName="AccountsPU") EntityManager em;
       @Resource QueueConnectionFactory accountsJMSfactory;
       @Resource Queue accountPaymentDestinationQueue;
   
       public List<Account> processAccounts(DepartmentId id) {
           // Use all of above instance variables with no additional setup.
           // They automatically partake in a (server coordinated) JTA transaction
       }
   }
   

   сервлет может вызвать этот компонент локально, просто объявив переменную экземпляра:

   @EJB MyAccountsBean accountsBean;    
   

   а затем просто вызывая его " методы по желанию.

6. умное взаимодействие с JPA. По умолчанию EntityManager вводится как выше используется персистентность области транзакций контекст. Это идеально подходит для безгосударственных сеансовых бобов. Когда метод EJB (без состояния) вызывается, в новой транзакции создается новый контекст персистентности, все экземпляры объектов сущности, извлеченные/записанные в БД, видны только внутри этого вызов метода и изолированы от других методов. Но если другие компоненты EJB без гражданства вызывается методом, контейнер распространяется и разделяет один и тот же ПК для них, так же лиц автоматически совместно используется последовательным образом через ПК в том же торговая операция.
   Если объявлен компонент сеанса @Stateful, равное интеллектуальное сродство с JPA достигается объявление entityManager расширенной областью: @PersistentContent (unitName="AccountsPU, type=EXTENDED). Это существует для жизни сеанс bean, через несколько вызовов bean и транзакций, кэширование копий в памяти объектов БД, ранее извлеченных / записанных, поэтому они не должны быть повторно проверено.

7. Управление Жизненным Циклом. Жизненный цикл EJBs управляется контейнером. При необходимости он создает экземпляры EJB, очищает и инициализирует сессионных Bean государства, passivates и активирует, и звонки методы обратного вызова жизненного цикла, поэтому код EJB может участвовать в операциях жизненного цикла для получение и освобождение ресурсов или выполнение других действий инициализации и завершения работы. Он также фиксирует все исключения, регистрирует их, откатывает транзакции по мере необходимости и создает новые исключения EJB или @ApplicationExceptions по мере необходимости.

8. Управление Безопасности. Управление доступом к EJBs на основе ролей можно настроить с помощью простой аннотации или XML установочный. Сервер автоматически передает аутентифицированные данные пользователя вместе с каждым вызов как контекст безопасности (вызывающий принципал и роль). Это гарантирует, что все RBAC правила соблюдаются автоматически, так что методы не могут быть незаконно называют не та роль. Это позволяет EJBs легкий доступ к деталям пользователя/роли для дополнительных программных проверочный. Он позволяет подключать дополнительную обработку безопасности (или даже инструменты IAM) к контейнер стандартным способом.

9. Стандартизация И Переносимости. Реализации EJB соответствуют стандартам Java EE и соглашениям о кодировании, повышая качество и легкость понимания и обслуживания. Он также повышает переносимость кода на новый серверы приложений поставщиков, обеспечивая поддержку одних и тех же стандартных функций и поведение, а также отговаривая разработчиков от случайного принятия проприетарных
   non-портативные характеристики поставщика.

10. Самое Интересное: Простота. Все вышеперечисленное можно сделать с помощью очень упрощенный код - либо используя настройки по умолчанию для EJBs в Java EE 6 или добавление нескольких аннотаций. Кодирование предпринимательство / промышленные характеристики прочности в вашем собственном POJOs будь путь более объемный, сложный и подверженный ошибкам. Однажды ты ... начните кодировать с EJBs, они довольно просты в разработке и дают отличный набор преимуществ "бесплатной езды".

в оригинальной спецификации EJB 10 лет назад EJBs были основной проблемой производительности. Они были раздуты, нуждались в большом количестве артефактов кода и конфигурации и обеспечивали около 2/3 преимуществ выше. Большинство веб-проектов фактически не использовали их. Но это значительно изменилось за 10 лет настройки, капитального ремонта, функционального улучшения и развития поток-подкладка. В Java EE 6 они обеспечивают максимальную промышленную прочность и простоту использования.

что не нравится?? :-) :-)