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

• Асинхронные вызовы методов — начиная с EJB 3.1, теперь можно выполнять асинхронные вызовы без обмена сообщениями.

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

EJB-компоненты являются управляемыми объектами. Фактически они считаются управляемыми MBean-компонентами (Managed Beans). Когда клиент вызывает EJB-компонент, он не работает непосредственно с экземпляром этого EJB-компонента, а взаимодействует с прокси, что наблюдается в случае с экземпляром. Каждый раз, когда клиент вызывает метод в EJB-компоненте, этот вызов на самом деле идет через прокси и перехватывается контейнером, который обеспечивает службы от имени экземпляра EJB-компонента. Разумеется, все это абсолютно прозрачно для клиента. С момента своего создания и до уничтожения корпоративный EJB-компонент располагается в контейнере.

В приложении Java EE EJB-контейнер обычно взаимодействует с другими контейнерами — контейнером сервлетов (отвечающим за управление выполнением сервлетов и применением JSF-страниц), контейнером клиентского приложения (Application Client Container — ACC) (для управления автономными приложениями), а также с брокером сообщений (для отправки, постановки в очередь и получения сообщений), поставщиком постоянства и т. д.

Контейнеры обеспечивают для EJB-компонентов набор служб. С другой стороны, EJB-компоненты не могут создавать потоки или управлять ими, осуществлять доступ к файлам с использованием java.io, генерировать ServerSocket, загружать «родные» библиотеки или применять библиотеку AWT (Abstract Window Toolkit) либо API-интерфейсы Swing для взаимодействия с пользователем.

EJB Lite

Корпоративные EJB-компоненты стали доминирующей компонентной моделью в Java EE 7, будучи самым простым средством обработки транзакций, а также безопасной обработки бизнес-данных. Однако EJB 3.2 все еще определяет сложные технологии, которые сегодня используются в меньшей степени, например интероперабельность IIOP (Internet InterOrb Protocol — Межброкерный протокол для Интернета), а это означает, что любому новому поставщику, реализующему спецификацию EJB 3.2, придется реализовать и эти технологии. При знакомстве с EJB-компонентами разработчики также оказались бы отягощенными многими технологиями, которые они в ином случае никогда бы не использовали.

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

Таблица 7.1. Сравнение EJB Lite и полной версии EJB

Функция	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

Версия 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 стала намного более переносимой, чем те, что выходили в прошлом.

Краткая история спецификации EJB

Вскоре после того, как был создан язык Java, индустрия ощутила необходимость в технологии, которая отвечала бы требованиям крупномасштабных приложений, задействуя технологию RMI или JTA. Возникла идея создания фреймворка для разработки распределенных и транзакционных бизнес-компонентов, а в итоге компания IBM первой приступила к созданию того, что в конечном счете стало известным под названием «EBJ-компоненты».