Изучаем Java EE 7 - [112]

Версия 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-компоненты можно было вызывать в точно установленное время или через определенные промежутки времени.

Между появлением EJB 2.1 и EJB 3.0 прошло три года, что позволило экспертной группе переделать всю конструкцию. Вышедшая в 2006 году спецификация EJB 3.0 (JSR 220) порвала отношения с предыдущими версиями, поскольку была сосредоточена на легкости использования, при этом EJB-компоненты больше напоминали POJO. Компоненты-сущности EJB были заменены совершенно новой спецификацией (JPA), а сессионным EJB-компонентам больше не требовались домашние или EJB-специфичные интерфейсы компонентов. Были представлены внедрение ресурсов, перехватчики и обратные вызовы жизненного цикла.

В 2009 году спецификация EJB 3.1 (JSR 318) сопровождала Java EE 6 и шла путем предыдущих версий, даже еще больше упрощая модель программирования. Версия 3.1 привнесла удивительное количество новых функций, например представление без интерфейса, встроенные контейнеры, одиночные EJB-компоненты, TimerService с более богатыми возможностями, асинхронность, переносимые JNDI-имена и EJB Lite.

Что нового в EJB 3.2

Спецификация EJB 3.2 (JSR 345) является менее претенциозной, чем предыдущий релиз. Чтобы упростить будущее принятие этой спецификации, экспертная группа Java EE 6 составила список функций, которые могут быть ликвидированы в дальнейшем. Фактически ни одна из приведенных далее функций не была исключена из EJB 3.1, однако все они стали необязательными в версии 3.2:

• компоненты-сущности EJB 2.x;

• клиентское представление компонентов-сущностей EJB 2.x;

• EJB QL (язык запросов для CMP);

• конечные точки веб-служб на основе JAX-RPC;

• клиентское представление веб-служб JAX-RPC.

Вот почему сама спецификация состоит из двух разных документов:

• «Основные контракты и требования EJB-компонентов» (EJB Core Contracts and Requirements) — основной документ, определяющий EJB-компоненты;

• «Необязательные функции EJB-компонентов» (EJB Optional Features) — документ, описывающий приведенные ранее функции, поддержка которых стала необязательной.

Спецификация EJB 3.2 включает следующие небольшие обновления и улучшения.

• Транзакции теперь могут использоваться MBean-компонентами (ранее только EJB-компоненты могли применять транзакции; подробнее об этом мы поговорим в главе 9).

• Могут добавляться методы обратного вызова жизненного цикла EJB-компонентов с сохранением состояния, чтобы сделать их транзакционными.

• Пассивизации EJB-компонентов с сохранением состояния теперь больше нет.

• Были упрощены правила определения всех локальных/удаленных представлений EJB-компонентов.

• Было снято ограничение на получение текущего загрузчика классов, кроме того, теперь разрешено использовать пакет java.io.

• Корректировки JMS 2.0.

• Встраиваемый контейнер реализует Autocloseable, чтобы соответствовать Java SE 7.

• RMI/IIOP отсутствуют в этом релизе. Это означает, что поддержка этих технологий может быть помечена как необязательная в Java EE 8. Удаленные вызовы можно осуществлять с помощью всего лишь RMI (без интероперабельности IIOP).

В табл. 7.2 приведены основные пакеты, определенные в EJB 3.2 на сегодняшний день.

Таблица 7.2. Основные EJB-пакеты

Пакет	Описание
javax.ejb	Классы и интерфейсы, которые определяют контракты между EJB-компонентом и его клиентами, а также между EJB-компонентом и контейнером
javax.ejb.embeddable	Классы для Embeddable API
javax.ejb.spi	Интерфейсы, реализуемые EJB-контейнером

Эталонная реализация

GlassFish — это проект сервера приложений с открытым исходным кодом под руководством компании Oracle для платформы Java EE. Корпорация Sun запустила этот проект в 2005 году, и он стал эталонной реализацией Java EE 5 в 2006 году. Сегодня GlassFish версии 4 включает эталонную реализацию для EJB 3.2. Внутренне этот продукт строится вокруг модульности (исходя из времени выполнения Apache Felix OSGi), что обеспечивает очень короткое время запуска и использование различных контейнеров приложений (разумеется, Java EE 7, а также Ruby, PHP и т. д.).