Рекомендация: Проектирование объектов EJB

Введение

Этот раздел посвящен проектированию объектов EJB. Дополнительная информация об объектах EJB, в частности, указания по их идентификации и моделированию, приведена в разделе Указания для рабочего продукта: объекты EJB.

В следующих разделах приведены конкретные указания по проектированию конкретных типов объектов EJB:

Сравнение локальных и удаленных интерфейсов

Локальные и удаленные интерфейсы описаны в разделе Концепция: обзор J2EE: объекты EJB.

Локальные интерфейсы эффективнее удаленных. Локальные интерфейсы необходимы, если есть конкретные клиенты, которые всегда являются локальными относительно EJB.

Более подробные сведения по этой теме приведены в указаниях по конкретным типам объектов EJB.

Передача параметров

Существенное влияние на производительность оказывают число удаленных вызовов и объем данных, передаваемых в каждом вызове. Одно из средств решения этой проблемы заключается в применении специальных вызовов, возвращающих все необходимые удаленному клиенту данные. Например, сеансовый объект EJB, выступающий в качестве фасада для набора связанных сущностных объектов EJB, может копировать данные из нескольких сущностных объектов EJB в сериализуемые объекты значений и возвращать эти данные за один удаленный вызов. Подробное описание приведено в параграфе Базовые шаблоны J2EE - шаблон объектов значений ([ALU01].

С другой стороны, необходимо следить за тем, чтобы интерфейсы носили как можно более общий характер, и избегать отправки слишком больших объемов ненужных данных.

Транзакции

Демаркация транзакций - это их инициализация, фиксация и прерывание. Проектировщик объектов EJB должен решить, какую демаркацию транзакций он будет реализовывать: управляемую объектами EJB или управляемую контейнером. Вы должны выбрать расположения границ транзакций в последовательностях операторов бизнес-логики, выполняемых приложением. Дополнительная информация приведена в разделе Задача: проектирование Use-Case, моделирование транзакций и в параграфе Управление транзакциями раздела Концепция: обзор J2EE.

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

Как правило, чем ниже уровень детализации транзакций, тем выше общая производительность. Предположим, что вы отправляете последовательность вызовов методов для объекта EJB (например, getX, getY и setZ). По умолчанию каждый метод выполняется в новой транзакции, что снижает производительность. Для того чтобы вызвать все методы в одной и той же транзакции, создайте другой метод, например метод processXYZ сеансового объекта EJB, и задайте атрибуты транзакции вызываемых методов равными значению Required, так чтобы они использовали существующую транзакцию (например, транзакцию вызывающего метода в сеансовом объекте EJB).

Защита

Основные концепции защиты EJB рассмотрены в разделе Концепция: обзор платформы J2EE - защита.

Требования к защите EJB задаются путем определения ролей защиты и прав доступа методов. Роли защиты и права доступа методов определяются в файле описания EJB. Отображение ролей защиты в конкретных пользователей или группы пользователей выполняется сервером (с помощью административных инструментов).

Роль защиты определяет набор схожих типов операций, группируемых под одним именем. Права доступа метода предоставляют конкретной роли защиты право вызывать метод. Например, рассмотрим сущностный объект EJB Сотрудник с методами setAddress, setSalary и т.п. Роли защиты Руководитель могут быть предоставлены права доступа к методам setAddress и setSalary, а роли защиты Сотрудник - только права доступа к методу setAddress.

В некоторых ситуациях обеспечивать соблюдение требований к защите приложения, используя декларативные права доступа методов из файла описания, невозможно. В таких случаях следует воспользоваться методами getCallerPrincipal и isCallerInRole интерфейса javax.ejb.EJBContext.

Служба таймеров

Начиная с версии J2EE 1.4 (точнее, EJB 2.1), сеансовые объекты EJB, не сохраняющие состояние, и управляемые сообщениями объекты EJB могут применять таймеры и планировать пакетные процессы с помощью службы таймеров EJB.

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

Служба таймеров реализуется контейнером EJB. Объект EJB получает доступ к этой службе через интерфейс EJBContext.

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

Сравнение прямого доступа и объектов EJB

Применение сущностных объектов EJB для работы с постоянными данными обеспечивает стандартный, функционально богатый механизм доступа к постоянным данным. Выбор между применением постоянного хранения, управляемого EJB, и постоянного хранения, управляемого контейнером, может быть скрыт от клиентов, что придает проекту некоторую гибкость. Объекты EJB могут воспользоваться транзакциями, управлением ресурсами, распределением нагрузки и другими функциями, предоставляемыми средой J2EE.

Однако в некоторых случаях может потребоваться прямой доступ к базе данных без использования сущностных объектов EJB. Например, если данные всегда запрашиваются только для чтения, причем одним и тем же клиентом, то прямой доступ к базе данных будет эффективнее.

Если вы обращаетесь к базе данных напрямую (например, из сеансового объекта EJB без сохранения состояния), инкапсулируйте весь доступ к базе данных в классе Data Access Object. Это обычный класс Java, скрывающий и инкапсулирующий базовый механизм хранения и изолирующий изменения при модификации интерфейса источника данных. См. параграф Базовые шаблоны J2EE - шаблон объектов доступа к данным ([ALU01].

Соединения с базами данных

В сущности, все контейнеры EJB поддерживают общий пул соединений, совместно используя набор уже созданных соединений между клиентами. Эти соединения назначаются объектам EJB по мере необходимости. Благодаря этому объект EJB получает соединение без затрат на его создание и инициализацию. После возврата соединения в пул оно используется вновь. Размер пула должен быть достаточным для поддержания такой системы повторного использования соединений.

В случае сущностных объектов EJB с постоянным хранением, управляемым контейнером, соединениями с базами данных и доступом к пулу таких соединений управляет контейнер.

В случае сущностных объектов EJB с постоянным хранением, управляемым EJB (а также сеансовых или управляемых сообщениями объектов EJB, обращающихся к базе данных), за кодирование процедуры соединения отвечает разработчик. Выполните следующие инструкции:

Изолируйте код доступа к базе данных в классе DAO.
Не вносите в код фактический URL базы данных. Вместо этого, укажите логическое имя, которое можно извлекать с помощью функции поиска JNDI. Это позволит использовать объект EJB во многих приложениях, возможно с различными именами баз данных.
В общем случае, применяйте пулы соединений и удерживайте соединение ровно столько времени, сколько необходимо. Например, сущностный объект EJB может подключиться, обновить строку в таблице и отключиться. Это позволит различным объектам EJB совместно работать с одним и тем же соединением. Спецификация JDBC предусматривает поддержку пулов соединений.