| Функция | EJB Lite | Полная версия EJB 3.2 |
|---|---|---|
| Сессионные EJB-компоненты (без сохранения состояния, с сохранением состояния, одиночные) | Да | Да |
| Представление без интерфейса | Да | Да |
| Локальный интерфейс | Да | Да |
| Перехватчики | Да | Да |
| Поддержка транзакций | Да | Да |
| Безопасность | Да | Да |
| Embeddable API | Да | Да |
| Асинхронные вызовы | Нет | Да |
| EJB-компоненты, управляемые сообщениями | Нет | Да |
| Удаленный интерфейс | Нет | Да |
| Веб-службы JAX-WS | Нет | Да |
| Веб-службы JAX-RS | Нет | Да |
| TimerService | Нет | Да |
| Интероперабельность RMI/IIOP | Нет | Да |
С самого начала спецификации EJB требовали наличия возможности использовать RMI/IIOP для экспорта EJB-компонентов и доступа к EJB-компонентам через сеть. Это требование сделало возможной интероперабельность между продуктами Java EE. Однако оно исчезло с выходом EJB 3.2 и может стать необязательным в будущих релизах, поскольку RMI/IIOP в значительной мере вытесняются современными веб-технологиями, обеспечивающими поддержку интероперабельности, к числу которых относятся, например, SOAP и REST.
Версия EJB 1.0 появилась еще в 1998 году, а релиз EJB 3.2 состоялся в 2013 году с выходом Java EE 7. На протяжении этих 15 лет спецификация EJB претерпела много изменений, однако по-прежнему следует своим продуманным принципам. От тяжеловесных компонентов до аннотированных POJO-объектов, от Entity Bean CMP до JPA EJB-компоненты переосмысливались, чтобы соответствовать требованиям разработчиков и современных архитектур.
Спецификация EJB 3.2 как никогда помогает избежать зависимости от продукции того или иного поставщика, предусматривая функции, которые ранее были нестандартными (например, нестандартные JNDI-имена или встроенные контейнеры). Сегодня версия EJB 3.2 стала намного более переносимой, чем те, что выходили в прошлом.
Вскоре после того, как был создан язык Java, индустрия ощутила необходимость в технологии, которая отвечала бы требованиям крупномасштабных приложений, задействуя технологию RMI или JTA. Возникла идея создания фреймворка для разработки распределенных и транзакционных бизнес-компонентов, а в итоге компания IBM первой приступила к созданию того, что в конечном счете стало известным под названием «EBJ-компоненты».
Версия EJB 1.0 поддерживала EJB-компоненты с сохранением состояния и без, а также предусматривала необязательную поддержку компонентов-сущностей EJB. Модель программирования задействовала домашние и удаленные интерфейсы в дополнение к сессионным EJB-компонентам как таковым. EJB-компоненты делались доступными с помощью интерфейса: он обеспечивал удаленный доступ с использованием аргументов, передаваемых по значению.
Версия EJB 1.1 сделала поддержку компонентов-сущностей EJB обязательной, а также представила XML-дескрипторы развертывания для сохранения метаданных (которые затем сериализовались как двоичные в файл). Эта версия обеспечила лучшую поддержку сборки и развертывания приложений, представив роли.
В 2001 году EJB 2.0 стала первой версией, которая была стандартизирована Java Community Process (как JSR 19). Она позволила решить проблему накладных расходов, связанных с передачей аргументов по значению, представив локальные интерфейсы. Клиент, работающий в контейнере, осуществлял бы доступ к EJB-компонентам с помощью их локального интерфейса (с использованием аргументов, передаваемых по ссылке). Эта версия представила EJB-компоненты, управляемые сообщениями, а компоненты-сущности EJB обрели поддержку связей и языка запросов (EJB QL).
Спустя два года версия EJB 2.1 (JSR 153) привнесла поддержку веб-служб, позволив вызывать сессионные EJB-компоненты с помощью SOAP/HTTP. Был создан инструмент TimerService, чтобы EJB-компоненты можно было вызывать в точно установленное время или через определенные промежутки времени.
