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

Пытался узнать, чтоEJB бины, что это означает, что их экземпляры управляются в пуле, бла-бла. Действительно могуне получить хорошее управление ими.

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

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

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

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

Ответы на вопрос(4)

Решение Вопроса

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

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

Повторное использование / совместное использование логики в нескольких приложениях / клиентах с Loose Coupling.

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

Они очень полезны для создания сервисов SOA. При использовании для локального доступа они являются POJO (с добавлением бесплатных контейнерных сервисов). Создание отдельного слоя EJB способствует дополнительной заботе о максимизации инкапсуляции, слабой связи и когезии, а также способствует чистому интерфейсу (фасад), защищая абонентов от сложной обработки и модели данных.

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

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

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

Автоматическая обработка транзакций.

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

Очень простой доступ к ресурсам / зависимостям через внедрение.

Контейнер будет искать ресурсы и устанавливать ссылки на ресурсы как поля экземпляра в 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 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;    

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

Умное взаимодействие с JPA. По умолчанию EntityManager, внедренный, как указано выше, использует контекст персистентности в области транзакций. Это идеально подходит для сессионных компонентов без сохранения состояния. Когда вызывается метод EJB (без сохранения состояния), в новой транзакции создается новый контекст постоянства, все экземпляры объекта сущности, извлеченные / записанные в БД, видны только внутри этого вызова метода и изолированы от других методов. Но если этот метод вызывает другие EJB без сохранения состояния, контейнер распространяется и совместно использует один и тот же ПК для них, поэтому одни и те же объекты автоматически передаются согласованным образом через ПК в одной и той же транзакции.

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

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

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

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

непереносимые функции вендора.

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

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

Какие'не любить ?? :-) :-)

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

управление транзакциями: транзакция может быть запущена автоматически до вызова метода EJB и зафиксирована или откатана после возврата из этого метода. Этот транзакционный контекст распространяется на вызовы других EJB.управление безопасностью: можно проверить, что у вызывающей стороны есть необходимые роли для выполнения метода.внедрение зависимостей: в EJB могут быть внедрены другие EJB или ресурсы, такие как менеджер сущностей JPA, источник данных JDBC и т. д.параллелизм: контейнер гарантирует, что только один поток одновременно вызывает метод вашего экземпляра EJB.распределение: некоторые EJB могут вызываться удаленно, из другой JVM.аварийное переключение и распределение нагрузки: удаленные клиенты ваших EJB-компонентов могут автоматически перенаправлять свои вызовы на другой сервер, если это необходимо.управление ресурсами: бины с сохранением состояния могут автоматически пассивироваться на диск, чтобы ограничить потребление памяти вашим сервером.... Я, наверное, забыл некоторые моменты.
 user10798629 сент. 2015 г., 22:43
@JB Nizet В шаблоне MVC, где бы вы разместили EJB вообще? Я'Я бы сказал, что они принадлежат слою Model, хотя я знаю многих людей, которые говорят, что они контролеры. Если EJB содержит бизнес-логику (вы сказали, что она есть), то они 'Перемоделируем слой по определению.
 JB Nizet22 февр. 2015 г., 12:32
Основные принципы одинаковы. Spring взял идеи от EJBs и наоборот. Но API, реализация, способ развертывания и некоторые функции отличаются.
 jacktrades13 окт. 2012 г., 13:46
Когда вы ссылаетесь на транзакцию - вы ссылаетесь на настойчивость?
 MoienGK22 февр. 2015 г., 12:23
@JBNizet извините за комментирование старого потока, но НЕ EJB-фреймворки, такие как Spring, предоставляют такие сервисы, которые вы упомянули. я не понимаю разницу
 JB Nizet13 окт. 2012 г., 13:49
Да, но не только. Контейнеры EJB предоставляют распределенный менеджер транзакций JTA, поддерживающий несколько ресурсов в одной транзакции. Например, вы можете обновить некоторые данные в базе данных и отправить несколько сообщений JMS за одну транзакцию. Если что-то не получится, все будет отменено: обновления БД и отправленные сообщения.

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

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

Позволять'Рассмотрим сессионные бобы. Они бывают 3 видов:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ваш ответ на вопрос