Джакарта Энтерпрайз Бинс

Не путать с JavaBeans .

Jakarta Enterprise Beans ( EJB ; ранее Enterprise JavaBeans ) — один из нескольких Java API для модульного построения корпоративного программного обеспечения . EJB — это серверный программный компонент , инкапсулирующий бизнес-логику приложения. EJB Веб-контейнер обеспечивает среду выполнения для программных компонентов, связанных с Интернетом, включая компьютерную безопасность , управление жизненным циклом сервлетов Java , обработку транзакций и другие веб-сервисы . Спецификация EJB является подмножеством спецификации Java EE .

Спецификация

Спецификация EJB была первоначально разработана в 1997 году компанией IBM , а затем принята Sun Microsystems (EJB 1.0 и 1.1) в 1999 году. и улучшен в рамках процесса сообщества Java как JSR 19 (EJB 2.0), JSR 153 (EJB 2.1), JSR 220 (EJB 3.0), JSR 318 (EJB 3.1) и JSR 345 (EJB 3.2).

Спецификация EJB предоставляет стандартный способ реализации серверного (также называемого « внутренним ») «бизнес-программного обеспечения», которое обычно встречается в корпоративных приложениях (в отличие от «внешнего» программного обеспечения пользовательского интерфейса ). Такое программное обеспечение решает одни и те же типы проблем, и программисты часто повторно реализуют решения этих проблем. Jakarta Enterprise Beans предназначен для решения таких распространенных проблем, как постоянство , целостность транзакций и безопасность , стандартным способом, предоставляя программистам возможность сосредоточиться на конкретных частях корпоративного программного обеспечения.

Общие обязанности

Спецификация EJB подробно описывает, как сервер приложений выполняет следующие обязанности:

• Обработка транзакций
• Интеграция со службами сохранения, предлагаемыми Jakarta Persistence (JPA).
• Управление параллелизмом
• Программирование, управляемое событиями, с использованием Jakarta Messaging (JMS) и Jakarta Connectors (JCA).
• Асинхронный вызов метода
• Планирование работы
• именования и Службы каталогов через интерфейс именования и каталогов Java (JNDI)
• Межпроцессное взаимодействие с использованием RMI-IIOP и веб-сервисов
• Безопасность ( JCE и JAAS )
• Развертывание программных компонентов на сервере приложений

Кроме того, спецификация Jakarta Enterprise Beans определяет роли, которые играют контейнер EJB и сами EJB, а также способы развертывания EJB в контейнере. Обратите внимание, что спецификация EJB не подробно описывает, как сервер приложений обеспечивает сохранение (задача, делегированная спецификации JPA), а вместо этого подробно описывает, как бизнес-логика может легко интегрироваться со службами сохранения, предлагаемыми сервером приложений.

История

Компании обнаружили, что использование EJB для инкапсуляции бизнес-логики приводит к снижению производительности. Это связано с тем, что исходная спецификация допускала только удаленный вызов методов через CORBA (и, возможно, другие протоколы), хотя подавляющее большинство бизнес-приложений фактически не требуют этой функции распределенных вычислений . Спецификация EJB 2.0 решила эту проблему, добавив концепцию локальных интерфейсов, которые могли вызываться напрямую без снижения производительности приложениями, которые не были распределены по нескольким серверам.

Спецификация EJB 3.0 ( JSR 220) отличалась от своих предшественников и следовала новой облегченной парадигме. EJB 3.0 демонстрирует влияние Spring в использовании простых объектов Java и поддержке внедрения зависимостей для упрощения настройки и интеграции гетерогенных систем. EJB 3.0 вместе с другой версией EJB можно интегрировать с MuleSoft -v4 с помощью сертифицированного MuleSoft соединителя PlektonLabs EJB Connector . Гэвин Кинг, создатель Hibernate , участвовал в процессе EJB 3.0 и является ярым сторонником этой технологии. Многие функции, изначально существовавшие в Hibernate, были включены в Java Persistence API , заменивший объектные компоненты в EJB 3.0. Спецификация EJB 3.0 в значительной степени опирается на использование аннотаций (функция, добавленная в язык Java с выпуском 5.0) и соглашений по конфигурации , позволяющих использовать гораздо менее подробный стиль кодирования. Соответственно, с практической точки зрения EJB 3.0 гораздо более легкий и представляет собой практически совершенно новый API, мало похожий на предыдущие спецификации EJB.

Пример

Ниже показан базовый пример того, как EJB выглядит в коде:

@Stateless 
public class CustomerService { 
  

  private EntityManager entityManager; 
   
  public void addCustomer(Customer customer) { 
    entityManager.persist(customer); 
  } 
}

Вышеупомянутое определяет класс обслуживания для сохранения объекта Customer (через сопоставление O/R ). EJB заботится об управлении контекстом персистентности, а метод addCustomer() по умолчанию является транзакционным и потокобезопасным. Как показано, EJB фокусируется только на бизнес-логике и устойчивости и ничего не знает о каком-либо конкретном представлении.

Такой EJB может использоваться классом, например, на веб-уровне следующим образом:

@Named	
@RequestScoped
public class CustomerBacking {
   @EJB 
   private CustomerService customerService;

   public String addCustomer(Customer customer) {
      customerService.addCustomer(customer);
      context.addMessage(...); // abbreviated for brevity
      return "customer_overview";
   }
}

Вышеупомянутое определяет вспомогательный компонент JavaServer Faces (JSF), в который EJB внедряется с помощью @EJB аннотация. Его метод addCustomer обычно привязан к некоторому компоненту пользовательского интерфейса, например кнопке. В отличие от EJB, резервный компонент не содержит никакой бизнес-логики или кода сохранения, но делегирует такие задачи EJB. Вспомогательный компонент знает о конкретном представлении, о котором EJB ничего не знал.

Типы корпоративных компонентов

Контейнер EJB содержит два основных типа компонентов:

• Сессионные компоненты который может быть «с сохранением состояния», «без сохранения состояния» или «Singleton», и к нему можно получить доступ через локальный (та же JVM) или удаленный (другая JVM) интерфейс или напрямую без интерфейса, в этом случае применяется локальная семантика. Все сессионные компоненты поддерживают асинхронное выполнение. для всех представлений (локальный/удаленный/без интерфейса).
• Компоненты, управляемые сообщениями (MDB, также известные как компоненты сообщений). MDB также поддерживают асинхронное выполнение, но через парадигму обмена сообщениями.

Сессионные компоненты

Сессионные компоненты с сохранением состояния

См. также: Состояние диалога (Java EE).

Сессионные компоненты с сохранением состояния являются бизнес-объектами, имеющими состояние : то есть они отслеживают, с каким вызывающим клиентом они имеют дело на протяжении сеанса, а также историю его запросов, и, таким образом, доступ к экземпляру компонента строго ограничен только одним клиентом в течение его жизни. Если в любом случае предпринимается попытка одновременного доступа к одному bean-компоненту, контейнер сериализует эти запросы, но через @AccessTimeout аннотацию, контейнер может вместо этого выдать исключение. Состояние сеансовых bean-компонентов с сохранением состояния может автоматически сохраняться (пассивироваться) контейнером для освобождения памяти после того, как клиент не обращался к bean-компоненту в течение некоторого времени. Контекст расширенного персистентности JPA явно поддерживается сессионными компонентами с отслеживанием состояния.

Примеры

• Оформление заказа в интернет-магазине может обрабатываться сеансовым компонентом с сохранением состояния, который будет использовать свое состояние для отслеживания того, на каком этапе процесса оформления заказа находится покупатель, возможно, удерживая блокировки на товарах, которые покупатель покупает (с точки зрения архитектуры системы). , было бы менее идеально, чтобы клиент управлял этими блокировками).

Сессионные компоненты без сохранения состояния

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

Примеры

• Отправка электронного письма в службу поддержки клиентов может обрабатываться компонентом без сохранения состояния, поскольку это разовая операция, а не часть многоэтапного процесса.
• Пользователь веб-сайта, нажимающий на поле «Держать меня в курсе будущих обновлений», может вызвать вызов асинхронного метода сессионного компонента для добавления пользователя в список в базе данных компании (этот вызов является асинхронным, поскольку пользователь не нужно подождать, чтобы получить информацию об успехе или неудаче).
• Получение нескольких независимых фрагментов данных для веб-сайта, таких как список продуктов и история текущего пользователя, также может обрабатываться асинхронными методами сессионного компонента (эти вызовы являются асинхронными, поскольку они могут выполняться параллельно таким образом , что потенциально увеличивает производительность). В этом случае асинхронный метод вернет экземпляр Future .

Одноэлементные сессионные компоненты

Одноэлементные сессионные компоненты — это бизнес-объекты, имеющие глобальное общее состояние внутри JVM. Параллельный доступ к одному и единственному экземпляру компонента может контролироваться контейнером (параллелизм, управляемый контейнером, CMC) или самим компонентом (параллелизм, управляемый компонентом, BMC). CMC можно настроить с помощью @Lock аннотация, которая определяет, будет ли использоваться блокировка чтения или блокировка записи для вызова метода. Кроме того, Singleton Session Beans может явно запрашивать создание экземпляра при запуске EJB-контейнера, используя метод @Startup аннотация.

Примеры

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

Компоненты, управляемые сообщениями

Компоненты, управляемые сообщениями — это бизнес-объекты, выполнение которых запускается сообщениями, а не вызовами методов. Компонент, управляемый сообщениями, используется, среди прочего, для обеспечения простоты использования абстракции высокого уровня для спецификации JMS ( Java Message Service ) нижнего уровня. Он может подписаться на очереди сообщений JMS или темы сообщений, что обычно происходит через атрибут активацииConfig @MessageDriven аннотация. Они были добавлены в EJB, чтобы обеспечить обработку, управляемую событиями. В отличие от сессионных компонентов, MDB не имеет клиентского представления (локальное/удаленное/без интерфейса), т.е. е. клиенты не могут найти экземпляр MDB. MDB просто прослушивает любые входящие сообщения, например, в очереди или теме JMS, и автоматически обрабатывает их. Спецификация Java EE требует только поддержки JMS. но компоненты, управляемые сообщениями, могут поддерживать другие протоколы обмена сообщениями. Такие протоколы могут быть асинхронными, но могут быть и синхронными. Поскольку сеансовые компоненты также могут быть синхронными или асинхронными, основное различие между сеансовыми компонентами и компонентами, управляемыми сообщениями, заключается не в синхронности, а в разнице между (объектно-ориентированным) метода вызовом и обменом сообщениями .

Примеры

• Отправка обновления конфигурации на несколько узлов может осуществляться путем отправки JMS-сообщения в «тему сообщения» и может обрабатываться компонентом, управляемым сообщениями, прослушивающим эту тему (здесь используется парадигма сообщения, поскольку отправителю не нужно знать количество потребителей, их местоположение или даже их точный тип).
• Отправка задания в рабочий кластер может быть выполнена путем отправки сообщения JMS в «очередь сообщений», а также может быть обработана компонентом, управляемым сообщениями, но на этот раз прослушивание очереди (используется парадигма сообщений и очередь, поскольку отправителю не важно, какой работник выполнит задание, но ему нужна гарантия того, что задание будет выполнено только один раз).
• Обработка событий синхронизации из планировщика Quartz может обрабатываться компонентом, управляемым сообщениями; Quartz когда срабатывает триггер , MDB вызывается автоматически. Поскольку Java EE по умолчанию не знает о Quartz, JCA , и MDB будет помечен ссылкой на него. потребуется адаптер ресурсов

Исполнение

EJB развертываются в контейнере EJB, обычно на сервере приложений . Спецификация описывает, как EJB взаимодействует со своим контейнером и как клиентский код взаимодействует с комбинацией контейнер/EJB. Классы EJB, используемые приложениями, включены в javax.ejb упаковка. ( javax.ejb.spi package — это интерфейс поставщика услуг, используемый только реализациями контейнера EJB.)

Клиенты EJB не создают экземпляры этих bean-компонентов напрямую с помощью нового оператора Java, а вместо этого должны получать ссылку через контейнер EJB. Эта ссылка обычно является ссылкой не на сам компонент реализации, а на прокси , который динамически реализует либо локальный, либо удаленный бизнес-интерфейс, запрошенный клиентом, либо подтип фактического компонента. Затем прокси-сервер можно напрямую привести к интерфейсу или компоненту соответственно. Говорят, что клиент имеет «представление» в EJB, а локальный интерфейс, удаленный интерфейс и сам подтип компонента соответствуют локальному представлению, удаленному представлению и представлению без интерфейса.

Этот прокси-сервер необходим для того, чтобы дать EJB-контейнеру возможность прозрачно предоставлять сквозные ( АОП -подобные) услуги компоненту, такие как транзакции, безопасность, перехваты, инъекции и удаленное взаимодействие. Например, клиент вызывает метод на прокси-сервере, который сначала запускает транзакцию с помощью EJB-контейнера, а затем вызывает фактический метод компонента. Когда метод компонента возвращается, прокси-сервер завершает транзакцию (т. е. фиксируя ее или выполняя откат) и передает управление обратно клиенту.

Контейнер EJB отвечает за обеспечение того, чтобы клиентский код имел достаточные права доступа к EJB. Аспекты безопасности можно декларативно применять к EJB посредством аннотаций.

Транзакции

Контейнеры EJB должны поддерживать как транзакции ACID, управляемые контейнером, так и транзакции, управляемые компонентом.

Транзакции, управляемые контейнером (CMT), по умолчанию активны для вызовов сеансовых компонентов. То есть никакой явной настройки не требуется. Это поведение может быть декларативно настроено компонентом с помощью аннотаций, и при необходимости такая конфигурация может быть позже переопределена в дескрипторе развертывания. Настройка включает в себя отключение транзакций для всего компонента или отдельных методов или запрос альтернативных стратегий для распространения транзакций и запуска или присоединения к транзакции. Такие стратегии в основном касаются того, что должно произойти, если транзакция уже выполняется или еще не выполняется на момент вызова компонента. Поддерживаются следующие варианты:

Типы декларативного управления транзакциями

Тип	Объяснение
ОБЯЗАТЕЛЬНЫЙ	Если клиент не начал транзакцию, генерируется исключение. В противном случае используется транзакция клиента.
НЕОБХОДИМЫЙ	Если клиент начал транзакцию, она используется. В противном случае запускается новая транзакция. (это значение по умолчанию, если явный тип не указан)
REQUIRES_NEW	Если клиент начал транзакцию, она приостанавливается. Всегда начинается новая транзакция.
ПОДДЕРЖКИ	Если клиент начал транзакцию, она используется. В противном случае транзакция не используется.
НЕ_ПОДДЕРЖИВАЕТСЯ	Если клиент начал транзакцию, она приостанавливается. Новая транзакция не начинается.
НИКОГДА	Если клиент начал транзакцию, генерируется исключение. Новая транзакция не начинается.

В качестве альтернативы компонент может также объявить через аннотацию, что он хочет обрабатывать транзакции программно через JTA API. Этот режим работы называется транзакциями, управляемыми компонентом (BMT), поскольку транзакцию обрабатывает сам компонент, а не контейнер.

События

JMS ( служба сообщений Java ) используется для отправки сообщений от bean-компонентов клиентам, чтобы позволить клиентам получать асинхронные сообщения от этих bean-компонентов. MDB можно использовать для асинхронного получения сообщений от клиентов с помощью JMS Очередь или тема.

Службы именования и каталогов

В качестве альтернативы внедрению клиенты EJB могут получить ссылку на прокси-объект сессионного компонента (заглушку EJB) с помощью интерфейса именования и каталогов Java (JNDI) . Эту альтернативу можно использовать в случаях, когда внедрение недоступно, например, в неуправляемом коде или автономных удаленных клиентах Java SE, или когда необходимо программно определить, какой bean-компонент получить.

Имена JNDI для сессионных компонентов EJB назначаются контейнером EJB по следующей схеме:

Имена JNDI

Объем	Образец имени
Глобальный	java:global[/<имя-приложения>]/<имя-модуля>/<имя-компонента>[!<полное-имя-интерфейса>]
Приложение	java:app/<имя-модуля>/<имя-компонента>[!<полное-имя-интерфейса>]
Модуль	java:module/<имя-компонента>[!<полное-имя-интерфейса>]

(записи в квадратных скобках обозначают дополнительные детали)

Один bean-компонент может быть получен по любому имени, соответствующему приведенным выше шаблонам, в зависимости от «местоположения» клиента. Клиенты в том же модуле, что и требуемый компонент, могут использовать область действия модуля и более крупные области, клиенты в том же приложении, что и требуемый компонент, могут использовать область приложения и выше и т. д.

Например, код, выполняющийся в том же модуле, что и компонент CustomerService (как показано в примере, приведенном ранее в этой статье), может использовать следующий код для получения (локальной) ссылки на него:

CustomerServiceLocal customerService =
    (CustomerServiceLocal) new InitialContext().lookup("java:module/CustomerService");

Удаленное/распределенное выполнение

Для связи с клиентом, написанным на языке программирования Java, сеансовый компонент может предоставлять удаленное представление через интерфейс, помеченный с помощью @Remote. Это позволяет вызывать эти bean-компоненты из клиентов в других JVM , которые могут работать в других системах (с точки зрения EJB-контейнера любой код в другой JVM является удаленным).

Сеансовые bean-компоненты без сохранения состояния и Singleton также могут предоставлять «представление клиента веб-службы» для удаленной связи через WSDL и SOAP или простой XML. Это соответствует спецификациям JAX-RPC и JAX-WS . Однако поддержку JAX-RPC предлагается удалить в будущем. Для поддержки JAX-WS сессионный компонент помечается с помощью @WebServiceи методы, которые должны быть доступны удаленно с помощью @WebMethod.

Хотя спецификация EJB никоим образом не упоминает представление веб-служб RESTful и не имеет явной поддержки этой формы связи, спецификация JAX-RS явно поддерживает EJB. Следуя спецификации JAX-RS, сессионные компоненты без сохранения состояния и Singleton могут быть объявлены как корневые ресурсы через @Path аннотации и бизнес-методы EJB могут быть сопоставлены с методами ресурсов с помощью @GET, @PUT, @POST и @DELETE аннотации. Однако это не считается «представлением клиента веб-службы», которое используется исключительно для JAX-WS и JAX-RPC.

Связь через веб-сервисы типична для клиентов, не написанных на языке программирования Java, но также удобна для клиентов Java, у которых возникают проблемы с доступом к серверу EJB через брандмауэр. Кроме того, связь на основе веб-сервисов может использоваться клиентами Java для обхода загадочных и плохо определенных требований для так называемых «клиентских библиотек»; набор файлов jar, которые Java-клиент должен иметь в своем пути к классам для связи с удаленным сервером EJB. Эти клиентские библиотеки потенциально конфликтуют с библиотеками, которые у клиента уже могут быть (например, если сам клиент также является полноценным сервером Java EE), и такой конфликт считается очень трудным или невозможным разрешить.

Наследие

Домашние интерфейсы и необходимый бизнес-интерфейс

«Домашний интерфейс» перенаправляется сюда. Чтобы узнать о других значениях, см. Главный интерфейс (значения) .

В EJB 2.1 и более ранних версиях каждый EJB должен был предоставлять класс реализации Java и два интерфейса Java. Контейнер EJB создал экземпляры класса реализации Java для обеспечения реализации EJB. Интерфейсы Java использовались клиентским кодом EJB.

Требуемый дескриптор развертывания

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

Дескриптор развертывания — это XML- документ, содержащий запись для каждого развертываемого EJB. Этот XML-документ определяет следующую информацию для каждого EJB:

• Имя домашнего интерфейса
• Класс Java для Bean (бизнес-объект)
• Java-интерфейс для домашнего интерфейса
• Java-интерфейс для бизнес-объекта
• Постоянное хранилище (только для Entity Beans)
• Роли и разрешения безопасности
• С сохранением или без сохранения состояния (для сессионных компонентов)

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

Начиная с EJB 3.0 ( JSR 220 ), дескриптор XML заменяется аннотациями Java, установленными в реализации Enterprise Bean (на уровне исходного кода), хотя по-прежнему можно использовать дескриптор XML вместо аннотаций (или в дополнение к ним). Если дескриптор XML и аннотации применяются к одному и тому же атрибуту внутри Enterprise Bean, определение XML переопределяет соответствующую аннотацию исходного уровня, хотя некоторые элементы XML также могут быть аддитивными (например, свойство активации-конфигурации в XML с другое имя, чем уже определенное через @ActivationConfigProperty аннотация будет добавлена ​​вместо замены всех существующих свойств).

Варианты контейнеров

Начиная с EJB 3.1, спецификация EJB определяет два варианта контейнера EJB; полная версия и ограниченная версия. Ограниченная версия соответствует соответствующему подмножеству спецификации под названием EJB 3.1 Lite. и является частью веб-профиля Java EE 6 (который сам по себе является подмножеством полной спецификации Java EE 6).

EJB 3.1 Lite исключает поддержку следующих функций:

• Удаленные интерфейсы
• Совместимость RMI-IIOP
• Конечные точки веб-службы JAX-WS
• Служба таймера EJB ( @Schedule, @Timeout)
• Асинхронные вызовы сессионных компонентов ( @Asynchronous)
• Компоненты, управляемые сообщениями

EJB 3.2 Lite исключает меньше возможностей. В частности, это уже не исключает @Asynchronous и @Schedule/ @Timeout, но для @Schedule он не поддерживает атрибут «persistent», который поддерживает полная версия EJB 3.2. Полный список исключений для EJB 3.2 Lite:

• Удаленные интерфейсы
• Совместимость RMI-IIOP
• Конечные точки веб-службы JAX-WS
• Постоянные таймеры (атрибут «постоянный» на @Schedule)
• Компоненты, управляемые сообщениями

История версий

EJB 4.0, финальная версия (22 мая 2020 г.)

Jakarta Enterprise Beans 4.0 , как часть Jakarta EE 9, представляла собой выпуск инструментов, который в основном перемещал имена пакетов API с верхнего уровня. javax.ejb пакет на высшем уровне jakarta.ejb упаковка.

Другие изменения включали удаление устаревших API, перенос которых в новый пакет верхнего уровня было бессмысленно, а также удаление функций, которые зависели от функций, которые были удалены из Java или где-либо еще в Jakarta EE 9. Были удалены следующие API:

• методы, основанные на java.security.Identity который был удален из Java 14.
• методы, основанные на Jakarta XML RPC, для отражения удаления XML RPC с платформы Jakarta EE 9.
• устарел EJBContext.getEnvironment() метод.
• «Поддержка распределенного взаимодействия» отражает удаление CORBA из Java 11 и платформы Jakarta EE 9.

Другие незначительные изменения включают пометку группы API Enterprise Beans 2.x как «Необязательную» и создание Schedule аннотация повторяемая.

EJB 3.2.6, финальная версия (23 августа 2019 г.)

Jakarta Enterprise Beans 3.2 , как часть Jakarta EE 8, и, несмотря на то, что по-прежнему используется аббревиатура «EJB», этот набор API был официально переименован в «Jakarta Enterprise Beans» Eclipse Foundation, чтобы не наступать на Oracle «Java». "торговая марка.

EJB 3.2, финальная версия (28 мая 2013 г.)

JSR 345 . Enterprise JavaBeans 3.2 был относительно незначительной версией, которая в основном содержала разъяснения спецификаций и снимала некоторые ограничения, налагаемые спецификацией, но со временем оказалось, что она не служит никакой реальной цели. Некоторые существующие полноценные функции EJB также должны были присутствовать в EJB 3 lite, а функциональность, которую предлагалось сократить в EJB 3.1, действительно была сокращена (сделана необязательной).

Были добавлены следующие функции:

• Пассивацию сессионного компонента с состоянием можно деактивировать с помощью атрибута @Stateful аннотация (passivationCapable = false)
• TimerService может получать все активные таймеры в одном и том же модуле EJB (ранее можно было получать только таймеры для bean-компонента, в котором был вызван TimerService)
• Методы жизненного цикла (например, @PostConstruct) может быть транзакционным для сеансовых компонентов с состоянием, используя существующую @TransactionAttribute аннотация
• Автозакрываемый интерфейс, реализованный встраиваемым контейнером

EJB 3.1, финальная версия (10 декабря 2009 г.)

JSR 318 . Целью спецификации Enterprise JavaBeans 3.1 является дальнейшее упрощение архитектуры EJB за счет снижения ее сложности с точки зрения разработчика, а также добавления новых функций в ответ на потребности сообщества:

• Локальный вид без интерфейса (Вид без интерфейса)
• .war упаковка компонентов EJB
• EJB Lite: определение подмножества EJB
• Портативные глобальные JNDI EJB имена
• Синглтоны (Singleton Session Beans)
• События инициализации и завершения работы приложения
• Улучшения службы таймеров EJB
• Простая асинхронность ( @Asynchronous для сессионных компонентов)

EJB 3.0, финальная версия (11 мая 2006 г.)

JSR 220 — Основные изменения : В этом выпуске стало намного проще писать EJB, используя «аннотации», а не сложные «дескрипторы развертывания», используемые в версии 2.x. В этом выпуске также больше не требовалось использование домашнего и удаленного интерфейсов, а также файла ejb-jar.xml: они были заменены бизнес-интерфейсом и компонентом, реализующим этот интерфейс.

EJB 2.1, финальная версия (24 ноября 2003 г.)

JSR 153 — Основные изменения :

• Поддержка веб-сервисов (новинка): сессионные компоненты без сохранения состояния можно вызывать через SOAP / HTTP . Кроме того, EJB может легко получить доступ к веб-службе, используя новую ссылку на службу.
• Служба таймера EJB (новинка): основанный на событиях механизм вызова EJB в определенное время.
• Компоненты, управляемые сообщениями, принимают сообщения из источников, отличных от JMS .
• Добавлены адресаты сообщений (та же идея, что и ссылки EJB, ссылки на ресурсы и т. д.).
• Дополнения языка запросов EJB (EJB-QL): ORDER BY, AVG, MIN, MAX, SUM, COUNT и MOD.
• Схема XML используется для указания дескрипторов развертывания, заменяет DTD.

EJB 2.0, финальная версия (22 августа 2001 г.)

JSR 19 — Основные изменения : Общие цели :

• Стандартная архитектура компонентов для создания распределенных объектно-ориентированных бизнес-приложений на Java .
• Сделайте возможным создание распределенных приложений путем объединения компонентов, разработанных с использованием инструментов разных поставщиков .
• Упростите написание (корпоративных) приложений: разработчикам приложений не придется разбираться в деталях низкоуровневых транзакций и управления состоянием, многопоточности, пуле соединений и других сложных низкоуровневых API.
• Будет следовать философии Java «Напиши один раз, работай где угодно» . Корпоративный компонент можно разработать один раз, а затем развернуть на нескольких платформах без перекомпиляции или модификации исходного кода.
• Учитывайте аспекты разработки, развертывания и выполнения жизненного цикла корпоративного приложения.
• Определите контракты, которые позволят инструментам от нескольких поставщиков разрабатывать и развертывать компоненты, которые могут взаимодействовать во время выполнения.
• Быть совместимым с существующими серверными платформами. Поставщики смогут расширить свои существующие продукты для поддержки EJB.
• Быть совместимым с другими Java . API
• Обеспечьте взаимодействие между корпоративными компонентами Beans и компонентами Java EE, а также приложениями на языках программирования, отличными от Java.
• Быть совместимым с протоколами CORBA (RMI-IIOP).

EJB 1.1, окончательный выпуск (17 декабря 1999 г.)

Основные изменения :

• Дескрипторы развертывания XML
• Контексты JNDI по умолчанию
• RMI над IIOP
• Безопасность — на основе ролей, а не методов
• Поддержка Entity Bean — обязательная, а не необязательная

Цели версии 1.1:

• Обеспечьте лучшую поддержку сборки и развертывания приложений.
• Укажите более подробно обязанности отдельных ролей EJB.

EJB 1.0 (24 марта 1998 г.)

Анонсировано на JavaOne 1998 . Третья конференция Sun для разработчиков Java (24–27 марта) Цели версии 1.0:

• Определены отдельные «роли EJB», которые предполагается архитектурой компонента.
• Определен клиентский вид корпоративных компонентов.
• Определен взгляд разработчика корпоративных компонентов.
• Определены обязанности поставщика EJB-контейнера и поставщика сервера; вместе они составляют систему, поддерживающую развертывание и выполнение корпоративных компонентов.

Внешние ссылки

• Официальный сайт
• Документация по API Java EE 8
• Javaдокументация по API EJB 3.0
• Спецификация EJB 3.0
• Учебное пособие Sun по EJB 3.0
• EJB (3.0) Глоссарий
• Часто задаваемые вопросы по EJB
• JSR 345 (EJB 3.2)
• JSR 318 (EJB 3.1)
• JSR 220 (EJB 3.0)
• JSR 153 (EJB 2.1)
• JSR 19 (EJB 2.0)
• «Работа с компонентами, управляемыми сообщениями» из EJB3 в действии, второе издание
• Клиент вызывает EJB