Изучаем Java EE 7

EJB-компоненты, управляемые сообщениями (Message-Driven Beans — MDB), применяются для интеграции с внешними системами путем получения асинхронных сообщений с использованием JMS. Хотя EJB-компоненты, управляемые сообщениями, являются частью спецификации EJB, я рассматриваю их отдельно (в главе 13), поскольку соответствующая компонентная модель главным образом применяется для интеграции с промежуточным программным обеспечением, ориентированным на обработку сообщений (Message-Oriented Middleware — MOM). EJB-компоненты, управляемые сообщениями, обычно делегируют бизнес-логику сессионным EJB-компонентам.

EJB-компоненты также используются в качестве конечных точек веб-служб. В главах 14 и 15 демонстрируются веб-службы SOAP и RESTful, которые могут быть либо простыми Java-объектами, развернутыми в веб-контейнере, либо сессионными EJB-компонентами, развернутыми в EJB-контейнере.

Примечание

Для совместимости спецификация EJB 3.1 все еще включала Entity CMP. Эта постоянная компонентная модель была удалена и теперь стала необязательной в EJB 3.2. Технология JPA предпочтительна для отображения и выполнения запросов к реляционным базам данных. В этой книге не рассматривается Entity CMP.

Процесс и встроенный контейнер

С самого момента их изобретения (EJB 1.0) EJB-компоненты надлежало выполнять в контейнере, функционирующем на виртуальной машине Java. Подумайте о GlassFish, JBoss, Weblogic и т. д., и вы вспомните, что сначала нужно запустить сервер приложений, а затем производить развертывание и приступать к использованию своих EJB-компонентов. Этот внутрипроцессный контейнер подходит для среды производства, где сервер работает непрерывно. Однако подобный подход отнимает много времени в среде разработки, где вам часто требуется выполнять такие операции с контейнером, как запуск, развертывание, отладка и остановка. Другая проблема с серверами, работающими в разных процессах, заключается в том, что возможности тестирования ограниченны. Либо вы будете имитировать все контейнерные службы для модульного тестирования, либо вам потребуется произвести развертывание своего EJB-компонента на реальном сервере для осуществления интеграционного тестирования. Для решения этих проблем некоторые реализации серверов приложений предусматривают встроенные контейнеры, однако они зависят от реализации. Начиная с EJB 3.1 экспертная группа стандартизировала встроенные контейнеры, которые являются переносимыми между серверами.

Идея встроенного контейнера заключается в том, чтобы иметь возможность выполнять EJB-приложения в среде Java SE, позволяя клиентам применять для работы одну и ту же виртуальную машину Java и загрузчик классов. Это обеспечивает лучшую поддержку интеграционного тестирования, автономной обработки (например, пакетной обработки) и использования EJB-компонентов в настольных приложениях. API-интерфейс, связанный со встраиваемыми контейнерами, обеспечивает ту же самую управляемую среду, что и контейнер времени выполнения Java EE, и включает те же самые службы. Теперь вы можете задействовать встроенный контейнер на той же самой виртуальной машине Java, на которой функционирует ваша интегрированная среда разработки, и выполнять отладку своих EJB-компонентов без необходимости какой-либо разработки для отделения сервера приложений.

Службы, обеспечиваемые контейнером

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

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

• Внедрение зависимостей — контейнер может внедрять некоторые ресурсы в EJB-компонент (пункты назначения и фабрики JMS, другие EJB-компоненты, источники данных, переменные среды и т. д.), а также любые POJO благодаря CDI.

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

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