Jakarta Enterprise Beans - Jakarta Enterprise Beans

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

Технические характеристики

Спецификация EJB была первоначально разработана IBM в 1997 году, а затем принята 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 предоставляет стандартный способ реализации серверного (также называемого « back-end ») «бизнес-программного обеспечения», которое обычно встречается в корпоративных приложениях (в отличие от программного обеспечения « внешнего» интерфейса пользователя ). Такое программное обеспечение решает одни и те же типы проблем, и решения этих проблем часто повторно реализуются программистами. 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 и поддержке внедрения зависимостей для упрощения настройки и интеграции гетерогенных систем. Гэвин Кинг, создатель 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 содержит два основных типа bean-компонентов:

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

Сессионные бобы

Сессионные компоненты с отслеживанием состояния

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

Примеры

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

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

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

Примеры

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

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

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

Примеры

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

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

Бины, управляемые сообщениями, - это бизнес-объекты, выполнение которых запускается сообщениями, а не вызовами методов. Компонент, управляемый сообщениями, используется, среди прочего, для обеспечения упрощенной абстракции высокого уровня для спецификации JMS ( Java Message Service ) нижнего уровня . Он может подписаться на очереди сообщений JMS или темы сообщений, что обычно происходит через атрибут activateConfig аннотации @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 Пакет представляет собой интерфейс поставщика услуг, используемый только реализациями контейнера EJB.)

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

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

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

Сделки

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

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

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

События

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

Именование и службы каталогов

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

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

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

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

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

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

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

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

Сессионные компоненты без сохранения состояния и 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)
• Роли безопасности и разрешения
• Stateful или Stateless (для сессионных компонентов)

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

Начиная с EJB 3.0 ( JSR 220 ), дескриптор XML заменяется аннотациями Java, установленными в реализации Enterprise Bean (на уровне исходного кода), хотя по-прежнему можно использовать дескриптор XML вместо (или в дополнение к) аннотаций. Если XML-дескриптор и аннотации применяются к одному и тому же атрибуту внутри Enterprise Bean, определение XML переопределяет соответствующую аннотацию на уровне источника, хотя некоторые элементы XML также могут быть аддитивными (например, свойство-config-активации в 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.08.2019)

Jakarta Enterprise Beans 3.2 , как часть Jakarta EE 8, и, несмотря на то, что до сих пор используется аббревиатура EJB, этот набор API был официально переименован Eclipse Foundation в «Jakarta Enterprise Beans», чтобы не наступать на 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.12.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 может легко получить доступ к Web-сервису, используя новую ссылку на сервис.
• Служба таймера EJB (новинка): механизм на основе событий для вызова EJB в определенное время.
• Компоненты, управляемые сообщениями, принимают сообщения из источников, отличных от JMS .
• Добавлены места назначения сообщений (та же идея, что и ссылки EJB, ссылки на ресурсы и т.д.).
• Добавления языка запросов EJB (EJB-QL): ORDER BY, AVG, MIN, MAX, SUM, COUNT и MOD.
• Схема XML используется для указания дескрипторов развертывания, заменяет DTD

EJB 2.0, последний выпуск (22.08.2001)

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

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

EJB 1.1, последняя версия (1999-12-17)

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

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

Цели для выпуска 1.1:

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

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

Объявлено на JavaOne 1998 , третьей конференции Java-разработчиков Sun (24–27 марта). Цели выпуска 1.0:

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

Рекомендации

внешняя ссылка

• Официальный веб-сайт
• Документация Java EE 8 API Javadocs
• Документация Javadoc по API EJB 3.0
• Спецификация EJB 3.0
• Учебное пособие Sun по EJB 3.0
• EJB (3.0) Глоссарий
• EJB FAQ
• 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