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

Я пытался узнать, что такое EJBbean-компоненты, что означает, что их экземпляры управляются в пуле, бла-бла. На самом деле не могу получить хорошее управление ими.

Можете ли вы объяснить мне, что они на самом деле (практически для программиста Java)? Что они делают? Каковы их цели? Зачем реально их использовать? (Почему бы просто не придерживаться POJO?) Возможно, пример приложения?

Пожалуйста, обратитесь только к обновленной информации, то есть EJB 3.1. Датированная информация о EJB может вводить в заблуждение.

Для начинающих учиться EJB, пожалуйста, обратите внимание:

EJB основаны на распределенных объектах , это относится к программным компонентам, работающим на нескольких машинах (виртуальных или физических), связанных сетью .

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

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

1. Повторное использование / совместное использование логики в нескольких приложениях / клиентах с помощью Loose Coupling.
   EJB-компоненты могут быть упакованы в свои собственные банки, развернуты и вызваны из множества мест. Они являются общими компонентами. Правда, POJO могут быть (осторожно!) Спроектированы как библиотеки и упакованы как банки. Но EJB поддерживают как локальный, так и удаленный доступ к сети, в том числе через локальный интерфейс java, прозрачный RMI, асинхронное сообщение JMS и веб-сервис SOAP / REST, сохраняя от вырезанных и вставленных зависимостей jar с несколькими (несовместимыми?) Развертываниями.
   Они очень полезны для создания сервисов SOA. При использовании для локального доступа они являются POJO (с добавлением бесплатных контейнерных сервисов). Процесс разработки отдельного слоя EJB способствует дополнительной заботе о максимизации инкапсуляции, слабой связи и связности, а также способствует чистому интерфейсу (фасад), защищая абонентов от сложных моделей обработки и данных.

2. Масштабируемость и надежность Если вы применяете огромное количество запросов от различных вызывающих сообщений / процессов / потоков, они сначала распределяются по доступным экземплярам EJB в пуле, а затем помещаются в очередь. Это означает, что если количество входящих запросов в секунду больше, чем может обработать сервер, мы постепенно снижаем производительность - всегда есть некоторые запросы, которые обрабатываются эффективно, и избыточные запросы выполняются для ожидания. Мы не достигаем «краха» сервера - когда ВСЕ запросы испытывают ужасное время отклика одновременно, плюс сервер пытается получить доступ к большему количеству ресурсов, чем может выдержать аппаратное обеспечение и ОС, и, следовательно, происходит сбой. EJB-компоненты могут быть развернуты на отдельном уровне, который можно кластеризовать - это обеспечивает надежность за счет переключения при отказе с одного сервера на другой, а также можно добавлять оборудование для линейного масштабирования.

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

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

5. Очень простой доступ к ресурсам / зависимостям через внедрение.
   Контейнер будет искать ресурсы и устанавливать ссылки на ресурсы как поля экземпляров в EJB: такие как JNDI-хранимые JDBC-соединения, JMS-соединения / темы / очереди, другие EJB-компоненты, JTA-транзакции, контексты персистентности менеджера сущностей JPA, единицы персистентности фабрики менеджера сущностей JPA и Ресурсы адаптера JCA. например, чтобы установить ссылку на другой EJB, транзакцию 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-компонентов кэширование в памяти копий сущностей БД, ранее извлеченных / записанных, поэтому их не нужно повторно извлекать.

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

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

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

10. Настоящий кикер: простота. Все вышеперечисленное может быть выполнено с очень упрощенным кодом - либо с использованием настроек по умолчанию для EJB в Java EE 6, либо путем добавления нескольких аннотаций. Кодирование / промышленные особенностей прочности предприятия в собственном POJOs будет путь более volumous, сложными и подверженные ошибкам. Как только вы начинаете программировать с EJB-компонентами, их довольно легко разрабатывать, и они дают большой набор преимуществ «бесплатной поездки».

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

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

EJB - это Java-компонент, содержащий бизнес-логику, который вы развертываете в контейнере и который использует технические услуги, предоставляемые контейнером, обычно декларативным способом благодаря аннотациям:

• управление транзакциями: транзакция может быть запущена автоматически до вызова метода EJB и зафиксирована или откатана после возврата этого метода. Этот транзакционный контекст распространяется на вызовы других EJB.
• управление безопасностью: можно проверить, что у вызывающей стороны есть необходимые роли для выполнения метода.
• внедрение зависимостей: в EJB могут быть внедрены другие EJB или ресурсы, такие как менеджер сущностей JPA, источник данных JDBC и т. д.
• параллелизм: контейнер гарантирует, что только один поток одновременно вызывает метод вашего экземпляра EJB.
• распределение: некоторые EJB могут вызываться удаленно, из другой JVM.
• аварийное переключение и распределение нагрузки: удаленные клиенты ваших EJB-компонентов могут автоматически перенаправлять свои вызовы на другой сервер при необходимости.
• управление ресурсами: бины с состоянием могут автоматически пассивироваться на диск, чтобы ограничить потребление памяти вашим сервером.
• ... Я, наверное, забыл некоторые моменты.

Надеюсь, что это из Oracle doc поможет кому-то, как я, понять тему EJB простым способом.

Что такое корпоративный бин? Написанный на языке программирования Java корпоративный компонент является компонентом на стороне сервера, который инкапсулирует бизнес-логику приложения. Бизнес-логика - это код, который выполняет цель приложения. Например, в приложении управления запасами корпоративные компоненты могут реализовывать бизнес-логику в методах, называемых checkInventoryLevel и orderProduct. С помощью этих методов клиенты могут получить доступ к службам инвентаризации, предоставляемым приложением.

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

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

В-третьих, поскольку корпоративные компоненты являются переносимыми компонентами, сборщик приложений может создавать новые приложения из существующих компонентов. Эти приложения могут работать на любом совместимом сервере Java EE при условии, что они используют стандартные API.

Когда использовать корпоративные bean-компоненты Вам следует рассмотреть возможность использования корпоративных bean-компонентов, если ваше приложение имеет любое из следующих требований:

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

Транзакции должны обеспечивать целостность данных. Корпоративные бины поддерживают транзакции, механизмы, которые управляют одновременным доступом к общим объектам.

Приложение будет иметь множество клиентов. Имея всего несколько строк кода, удаленные клиенты могут легко находить корпоративные компоненты. Эти клиенты могут быть худыми, разнообразными и многочисленными.

Меня больше всего интересует вопрос, как и где я могу их использовать. Чтобы понять это, нам нужно сначала посмотреть, какие типы EJB существуют. Есть 2 большие категории:

1. Сессионные бобы
2. Управляемые сообщениями компоненты

Давайте рассмотрим сессионные компоненты. Они бывают 3 видов:

1. С состоянием - эти компоненты поддерживают состояние и специфичны для клиента по нескольким запросам. Смотри это как сессия. Непосредственное использование, которое они могут использовать, - это магазинные тележки или сеансы другого типа (сеанс входа в систему и т. Д.)
2. Без сохранения состояния - это автономные компоненты, которые не сохраняют информацию между запросами, но являются уникальными для пользователя. Немедленное использование, которое приходит на ум - Классы обслуживания на уровне сервиса . Представь OrderService. Другое большое использование для них, чтобы выставить веб-сервисы. Опять же, это на уровне сервиса или полностью отдельно.
3. Singleton - это компоненты, которые существуют для каждого приложения и создаются один раз, и их можно многократно использовать / использовать несколько раз. Сразу же Configurationприходит на ум компонент - где вы можете хранить настройки уровня приложения и получать к ним доступ, когда они вам нужны из любого места.

Теперь остальные возможности или функции могут использоваться на разных уровнях в любых таких ситуациях:

• Безопасность - вы можете проверить разрешения с помощью аннотации к вызываемому методу. Это может произойти как на уровне службы, так и на контроллере, если вы этого хотите.
• Управление транзакциями - это очевидный кандидат на уровне Сервиса или на уровне Постоянства
• Инъекция зависимости - снова будет использоваться везде

В наше время широко используются так называемые микросервисы и сервис-ориентированные архитектуры. Вы можете упаковать некоторые компоненты бизнес-логики в EJB-компоненты и распределить их по всей организации для использования несколькими клиентами (здесь под клиентом я подразумеваю другие фоновые приложения).

И так далее. Теперь большим недостатком является то, что вы сильно зависите от EJB-контейнера и, хотя вы можете переключаться между двумя ссылочными реализациями, вы не сможете переключиться на что-то более легкое - например, Tomcat. Но почему вы хотите пожертвовать всеми преимуществами?