Главная » Java, JavaBeans » Обзор Entity-Компонента EJB

0

Entity-Компонент является объектным представлением данных, находящихся в долговременном хранилище, таком, как базы данных, или данных, реализованных с помощью существующего приложения. Они предназначены для того, чтобы несколько клиентов использовали их одновременно, в отличие от Session-Компонентов, которые всегда взаимодействуют только с одним клиентом.

Entity-Компонент соответствует записи (либо набору записей) в таблице реляционной базы данных или единичному объекту в объектно- ориентированной базе данных. Например, в случае использования реляционных баз данных, каждый столбец записи в таблице соответствует полям Entity-Компонента. Каждая запись в таблице идентифицируется с помощью главного ключа – одного или нескольких столбцов, которые уникальным образом идентифицируют каждую запись. Точно также, каждый Entity-Компонент содержит главный ключ (primary key) для идентификации конкретного экземпляра Компонента.

Хотя несколько клиентов могут взаимодействовать с одним Компонентом одновременно, Контейнер EJB управляет этим взаимодействием таким образом, чтобы сохранить целостность информации в базе данных. Контейнер может управлять конкурентным доступом к одному Компоненту, например, с помощью выстраивания запросов клиентов в очередь так, чтобы только один запрос выполнялся в каждое конкретное время. Контейнер может также делегировать управление конкурентным доступом средствам управления базами данных (DBMS) – то есть Контейнер только создает экземпляры Компонентов для каждого клиента, а затем полностью полагается на DBMS. Реализация Контейнера EJB фирмы Inprise использует этот последний подход.

Так как Entity-Компонент обычно является представлением информации в базе данных, его цикл жизни совпадает с циклом жизни самих данных – Entity-Компонент существует в течение долгого времени, обычно гораздо дольше, чем клиентское приложение, которое его создало. Такие Компоненты существуют не только после завершения сеанса связи или клиентского приложения, они существуют дольше, чем серверный процесс, в контексте которого они выполняются. Подобно данным в базе данных, Entity-Компонент не разрушается в результате сбоя сервера с последующим его перезапуском.

В отличие от Session-Компонентов, с которыми сопоставлено значение тайм-аута (и для которых Контейнер удаляет экземпляр Компонента при завершении периода тайм-аута), к Entity-Компонетам не применимо понятие тайм-аута. Вне зависимости от того, как долго они остаются неактивными, Контейнер не удаляет их из хранилища. Контейнер удаляет только экземпляры Компонента из самого Контейнера.

Единственный способ удалить Entity-Компонент – сделать это явно. Это может быть сделано с помощью вызова метода remove (), который удаляет как экземпляр Компонента, так и сопоставленную с ним информацию из базы данных, или с помощью средств DBMS (или других существующих приложений, не имеющих отношения к EJB).

Управление сохранением состояния

Под сохранением (Persistence) понимается протокол передачи состояния Компонента между экземпляром Компонента и сопоставленной с ним базой данных. Работая с Entity-Компонентами, разработчик может выбрать способ реализации сохранения.

Разработчик Компонента может поместить код, необходимый для сохранения состояния, непосредственно в класс Компонента (или в любой другой класс, поставляемый вместе с Компонентом). Обычно это называется bean-managed persistence (BMP).

С другой стороны, разработчик Компонента может доверить управление сохранением его состояния Контейнеру EJB. Средства, входящие в состав Контейнера, определяют способ управления сохранением на стадии поставки. Это называется container-managed persistence (CMP).

Сохранение, управляемое Компонентом

Entity-Компонент с BMP содержит код, явно управляющий доступом к базе данных. Другими словами, разработчик Компонента помещает команды обращения к базе данных непосредственно в код Компонента или другие, связанные с ним, классы. Обычно эти вызовы используют

рве.

Операторы доступа к базе данных могут появиться как в коде бизнес- методов, так и в одном из следующих стандартных методов интерфейса – ejbCreate(), ejbRemove(), ejbLoad() и ejbStore() – или в одном из finder-методов ejbFind<methodname>, который объявлен в home- интерфейсе Компонента. (Методы интерфейса Entity-Компонента обсуждаются в разделе "Методы Entity-Компонента" на странице 7-9).

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

Несмотря на то, что существует много причин не использовать BMP, все же встречаются ситуации, когда это может оказаться полезным. Entity- Компоненты с BMP не требуют дополнительной поддержки со стороны Контейнеров EJB. Кроме того, они могут управлять ситуацией в стиле, который не доступен Контейнерам EJB.

Сохранение, управляемое Контейнером

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

Инструментальные средства Контейнера генерируют команды обращения к базам данных на этапе поставки Компонента, то есть тогда, когда Компонент помещается в Контейнер. Эти средства используют Дескриптор Поставки, чтобы определить имена полей объекта, для которых они должны генерировать команды взаимодействия с базами данных. Вместо того, чтобы помещать код обращения к базам данных непосредственно в Компонент (как это происходит в случае использования BMP), разработчик Компонента с СМР должен указать все необходимые поля в Дескрипторе Поставки. Контейнер содержит достаточно "разумные" средства, чтобы автоматически сопоставить поля Entity-Компонента с информацией в базе данных.

СМР имеет много преимуществ по сравнению с BMP. Ее проще использовать – разработчик Компонента сам не обращается к методам управления базами данных. Управление сохранением состояния может быть изменено без изменения и перекомпиляции исходного кода Компонента. Deployer или Application Assembler могут выполнить это

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

Тем не менее, с СМР сопоставлены некоторые ограничения. Существует потенциальная проблема, если поля различных Entity- Компонентов с СМР отображаются на одни и те же данные в базе данных (хотя в правильно написанных программах такой ситуации следует избегать). В случае, подобном этому, различные Entity- Компоненты могут видеть недостоверные данные, если они используются в одной и той же транзакции. Кроме того, при использовании СМР Контейнер может загрузить полное состояние Компонента до того, как вызван метод ejbLoad(). Это может привести к снижению производительности в том случае, если с Компонентом сопоставлено большое количество данных.

Источник: Руководство программиста Enterprise JavaBeans

По теме:

  • Комментарии