Введение

Это руководство посвящено идентификации bean-объектов сеанса. Дополнительное руководство о bean-объектах сеанса находится в разделе Руководство: bean-объект сеанса, а общее руководство об объектах EJB находится в разделе Руководство: Объект EJB.

Идентификация bean-объектов сеанса

Классы управления часто являются подходящими кандидатами для bean-объектов сеанса, потому что bean-объекты сеанса приспособлены для предоставления управляющей логики, особенно, когда эта управляющая логика включает в себя диалог с пользователем. Bean-объекты также часто служат фасадом для набора объектов на Уровне бизнеса (см. Шаблон фасада сеанса ниже). Также, начиная с J2EE 1.4, bean-объекты сеанса без сохранения состояния могут использоваться для реализации Web-служб.

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

Моделирование bean-объектов сеанса

Смотрите раздел Руководство: Идентификация объектов EJB.

Сравнение объектов с сохранением состояния и объектов без сохранения состояния

Существует два типа bean-объектов сеанса: с сохранением состояния и без сохранения состояния. При идентификации bean-объекта сеанса определяется его ответственность, в которую может входить поддержка состояния клиента между вызовами.

Bean-объекты сеанса с сохранением состояния хранят информацию о состоянии диалога между клиентом и контейнером объекта EJB. Экземпляр bean-объекта сеанса с сохранением состояния существует только во время диалога пользователя. Bean-объекты сеанса с сохранением состояния обычно выполняют служебные функции с помощью этих данных для клиента. Службы, предоставленные bean-объектом сеанса с сохранением состояния могут координировать взаимодействие других бизнес-объектов (bean-объектов сеанса и сущностных bean-объектов). Например, корзина для покупок, которая содержит объекты для покупки, может быть реализована с помощью bean-объекта сеанса с сохранением состояния, потому что она сохраняет информацию в процессе взаимодействия клиента с приложением. Поскольку bean-объекты сеанса с сохранением состояния выделяются для определенного клиента, они загружают больше системных ресурсов, чем bean-объекты сеанса без сохранения состояния, осуществляя сохранение состояния клиента. Контейнер управляет этими ресурсами обычно с помощью "пассивации" (записи на диск) bean-объектов сеанса с сохранением состояния и повторной активации их при необходимости.

Bean-объекты сеанса без сохранения состояния не хранят информацию о состоянии диалога между клиентом и контейнером объекта EJB. Выражение "без сохранения состояния" на самом деле означает состояние диалога клиента. Таким образом, bean-объект сеанса без сохранения состояния может содержать другие виды состояний, такие как соединение с базой данных, используемое всеми клиентами. Bean-объекты сеанса без сохранения состояния выполняют общие служебные функции, которые не используют данные о состоянии клиента из предыдущих вызовов, а вместо этого получают все соответствующие входные данные как параметры текущего вызова метода, или получают данные из других источников во время вызова (например, из сущностных bean-объектов или из базы данных через JDBC). Bean-объекты сеанса без сохранения состояния обычно извлекаются из готового пула и распаковываются по необходимости для управления входящими запросами. Так как все экземпляры эквивалентны, bean-объектам сеанса без сохранения состояния не нужно знать об их клиенте. Это может увеличить быстродействие и масштабируемость. Bean-объекты сеанса без сохранения состояния более эффективны, потому что экземпляр может совместно использоваться изолированными запросами, а не связываться с определенным сеансом.

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

Если bean-объект сеанса создается для реализации Web-службы, необходимо чтобы он был без сохранения состояния, как это определено в спецификации API JSR 1.3.

Различные подходы к проектированию состояния клиента описаны в разделе Руководство: Проектирование состояния для приложений J2EE.

Шаблон фасада сеанса

Обычно bean-объекты сеанса используются в качестве фасада, который инкапсулирует взаимодействия между объектами на Уровне бизнеса. Bean-объект сеанса служит для абстрагирования этой сложности и предоставляет более простой интерфейс для клиента. Этот шаблон подробно описан в разделе Шаблоны J2EE - Шаблон фасада сеанса ([ALU01]).

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

Конечная точка Web-служб

Как мы видели ранее, bean-объект сеанса без сохранения состояния может использоваться для реализации Web-службы. Такой bean-объект называется также Bean-объектом реализации службы и должен удовлетворять следующим требованиям:

• Он должен иметь конструктор типа public по умолчанию.
• Он должен реализовывать все методы, объявленные Интерфейсом конечной точки службы, а его бизнес-методы должны иметь тип public, а не final или static.
• Он должен быть без сохранения состояния.
• Класс должен иметь тип public, но не final, и не abstract.

Более подробная информация об использовании bean-объектов сеанса для реализации Web-служб находится в спецификациях EJB 2.1 и JSR 109.