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

Ответ 1

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

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

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

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

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

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

• Очень простой доступ к ресурсам/зависимости через инъекцию.
  Контейнер будет искать ресурсы и задавать ссылки на ресурсы как поля экземпляра в EJB: такие как JDDI-соединения JDBC, JMS-соединения/темы/очереди, другие EJB, JTA Transactions, контексты сохранения сущностей JPA, менеджер сущностей JPA factory единиц сохранения и ресурсов адаптера JCA. например для установки ссылки на другой EJB и транзакцию JTA и диспетчер сущностей JPA и соединение JMS factory и очередь:

  @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
      }
  }
  

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

  @EJB MyAccountsBean accountsBean;    
  

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

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

• Управление жизненным циклом. Жизненный цикл EJB управляется контейнерами. По мере необходимости он создает экземпляры EJB, очищает и инициализирует сеанс состояния с состоянием bean, пассивит и активирует, и вызывает методы обратного вызова жизненного цикла, поэтому код 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 они обеспечивают максимальную промышленную прочность и простоту использования.

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

Ответ 2

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

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

Ответ 3

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

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

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

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

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

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

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

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

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

Ответ 4

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

• Сессия beans
• Сообщение, управляемое beans

Рассмотрим сеанс Beans. Они имеют 3 вида:

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

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

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

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

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