Сеансовые (Session) компоненты EJB без состояния и с состоянием, их особенности и применение
Сессионный бин представляет одного клиента внутри сервера J2EE и обеспечивает доступ (вызов) к методам сессионных бинов. Как видно из его названия, сессионный бин подобен интерактивному сеансу. Бин сеанса не является совместно используемым, т.к. интерактивный сеанс может иметь только одного пользователя. Как и интерактивный сеанс, бин сеанса не сохраняется. (То есть, его данные не записываются в базу данных.) Когда клиент заканчивает работу, его бин сеанса тоже заканчивается, и он больше уже не связан с клиентом .
Типы сессионных бинов:
· с состоянием
· без состояния.
Бины сеанса с состоянием
Состояние объекта состоит из значений переменных его экземпляра в конкретном уникальном сеансе взаимодействия между клиентом и бином. Поскольку клиент взаимодействует ("разговаривает") со своим бином, это состояние часто называют диалоговым состоянием.
Состояние сохраняется в течение всего сеанса взаимодействия между клиентом и бином. Если клиент удаляет бин или завершает работу, сеанс закрывается и состояние исчезает (для задач, где нет нужды сохранять состояния после завершения диалога с бином).
Бины сеанса без состояния
Бины сеанса без состояния не поддерживают состояние диалога для определенного клиента. Переменные экземпляра бина могут содержать состояние, но только на время вызова метода. Когда метод заканчивается, состояние больше не удерживается.
За исключением времени выполнения метода, все экземпляры бина без состояния эквивалентны, что позволяет контейнеру EJB назначать экземпляр любому клиенту (из организуемого пула экземпляров).
Поскольку бины сеанса без состояния поддерживают многих клиентов, они могут предложить лучшее масштабирование для приложений с большим числом клиентов. Обычно приложению для поддержки одинакового числа клиентов требуется меньше бинов без состояния, чем бинов с состоянием.
Иногда контейнер EJB записывает бины сеанса с состоянием во вторичную память. Но бины сеанса без состояния никогда не записываются во вторичную память. Следовательно, бины без состояния могут обеспечить лучшую производительность, чем бины с состоянием.
Следует использовать бины сеанса при следующих обстоятельствах:
· В каждый момент времени только один клиент имеет доступ к экземпляру бина.
· Состояние бина не сохраняемое, он существует только в течение короткого периода времени (возможно, несколько часов).
Бины сеанса с состоянием применяются, если выполняются следующие условия:
Состояние бина представляет взаимодействие между бином и определенным клиентом.
Бину необходимо хранить информацию о клиенте между вызовами метода.
Бин служит промежуточным звеном между клиентом и другими компонентами приложения, давая клиенту упрощенное представление.
"За сценой" бин управляет рабочим потоком нескольких корпоративных бинов.
Для повышения производительности вам следует выбрать бин сеанса без состояния, если он имеет любую из следующих особенностей:
Состояние бина не содержит данных для определенного клиента.
В одном вызове метода бин выполняет общую задачу для всех клиентов. Например, вы можете использовать бин сеанса без состояния для отправки по электронной почте сообщения, которое подтверждает заказ сделанный "on-line".
Бин выбирает из базы данных данные, предназначенные только для чтения, которые часто используются клиентами. Такой бин, например, может извлекать строки таблицы, представляющие товары, имеющиеся в продаже в этом месяце.
32. Общие принципы развертывание сеансовых компонентов EJB. Пример текста дескриптора поставки.
Вообще, под процессом развертывания приложения понимается совокупность всех действий по настройке системы в конкретной операционной среде, после которых клиент может приступить к работе с ней.
Дескриптор развертывания («установки» или «поставки»)- необходим для настройки созданного комп-та на работу в конкретной операционной среде. Необх-сть в нем возн. из-за того, что спецификация EJB четко определяет несколько этапов, к-й проходит компонент от своего создания до доставки конечному польз-лю с окончательной настройкой. Наличие подобного «конвейера» требует передачи инф-и от одного этапа к другому. С каждым компонентом сопоставлен свой дескриптор.
Спецификация EJB 1.1 требует, чтобы Дескриптор Развертывания имел XML-формат. Поскольку XML является метаязыком, то для описания каждого конкретного класса док-в нужно создать свой язык - в частности, опр-ть набор исп-х тегов и правила взаимоотношений между ними. Такой язык называется Document Type Definition (DTD).
Дескриптор Развертывания соотв-ет DTD и сод. набор св-в, к-й описывает, как Контейнер б. вып. процесс развертывания Компонента или приложения, и вкл. набор тегов и атрибутов, чьи значения опр-ют состояние свойств Компонента. В качестве пр-ра приведем несколько тегов:
<session> - говорит о том, что Компонент явл. session-Компонентом (тег <entity> исп. для обозн-я Entity-Компонентов).
Внутри области тега <session> могут исп-ся др. теги:
<ejb-class> - имя класса реализации.
<home> - имя home-интерфейса.
<remote> - имя remote-интерфейса.
<session-type> - показ., явл. ли session-Компонент stateful- или stateless-Комп-м.
<transaction-type> - показ., исп-тся ли для К-та CMT или BMT.
<trans-attribute> - задает знач-е атр-в транз-и для кажд. м-да.
<timeout> - значение тайм-аута для session-Компонента.
<?xml version="1.0" encoding="Cp1252"?>
<ejb-jar>
<description>Example</description>
<display-name></display-name>
<small-icon></small-icon>
<large-icon></large-icon>
<enterprise-beans>
<session>
<ejb-name>Sample</ejb-name>
<home> SampleHome</home>
<remote> Sample </remote>
<ejb-class> SampleBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
</session>
</enterprise-beans>
<ejb-client-jar></ejb-client-jar>
</ejb-jar>
33. Сущностные (Entity) компоненты, жизненный цикл, pool соединений. Общие принципы реализации. Особенности, методы Entity компонент их назначение и использование.
Entity комп-ты явл-ся объектным предст-ем записи в реляц. БД. Обычно 1 такой компонент сопост. с 1 записью в БД. Поск-ку данные одной записи д. б. доступны для неск-ких клиентов сразу, Entity Bean д. б. доступен для неск-ких клиентов и, след-но, не может иметь состояния, относящегося к конкретному клиенту. Каждому Entity-бину соответствует свой первичный ключ, по которому он может быть однозначно определен клиентом. Также Entity-бин имеет всегда какое-либо состояние (набор величин атрибутов, определяющих данный Entity-бин), к-е м. б. зафиксировано и сохранено, а затем и восстановлено.
Жизненный цикл. После того, как контейнер EJB создает экземпляр, он вызывает метод setEntityContext класса бина сущности. Метод setEntityContext передает контекст сущности бину.). После инсталляции бин сущности помещается в пул доступных экземпляров ("обобщенном" (pooled). Находясь в стадии пула, экземпляр никак ассоциируется с какой-либо конкретной "личностью" объекта EJB. Все экземпляры в пуле идентичны. Контейнер EJB назначает "личность" экземпляру, когда перемещает его в оперативную память. Существуют два пути из состояния пула к состоянию готовности. По первому пути клиент вызывает метод create, что заставляет контейнер EJB вызвать ejbCreate и ejbPostCreate. По второму пути контейнер EJB вызывает метод ejbActivate. Когда бин сущности находится в состоянии готовности, могут вызываться его бизнес-методы. Есть также два пути из состояния готовности в состояние пула. Во-первых, клиент может вызвать метод remove, что заставляет контейнер EJB вызвать метод ejbRemove. Во-вторых, контейнер EJB может вызвать метод ejbPassivate. В конце жизненного цикла контейнер EJB удаляет объекты из пула и вызывает метод unsetEntityContext.
Реализация бина.Здесь рассм. Entity-бина BookEJB. Он реализует набор пар get/set, к-е уст-ют/получают значения его полей. Также реализованы методы управления персистентностью:
а) ejbCreate(BookPK BookPK, :) Созд. Экз-ра бина в базе.
б) ejbRemove() Удал-е экз-ра бина в базе по первич. ключу.
в) Методы ejbLoad() и ejbStore().Им соответствуют методы selectRow и updateRow соотв-но в классе BookDAO. При указании типа транзакции required над бизнес-методом бина, перед заданием переменной и после её получения контейнер авт-ки выз-ет эти методы для чтения и соотв-но сохр-я сост-я бина из базы. Эти методы выз-тся именно в этой посл-сти.
г) BookPK BookPK ejbFindByPrimaryKey(BookPK BookPK) Нахождение экземпляра бина в базе.
д) getDBConnection Получ. соед-е к СУБД из пула соед-й EJB-конт-ра.
Базовым классом для класса entity-компонента является класс javax.ejb.EntityBean.
Кроме вышеперечисленный, интерфейс EntityBean содержит следующие методы:
setEntityContext() – устанавливает контекст компонента. Контейнер использует этот метод для передачи ссылки на интерфейс EntityContext экземпляру компонента. Этот интерфейс содержит методы, которые позволяют получить доступ к свойствам среды исполнения компонента;
unsetEntityContext() – вызывается контейнером перед тем, как происходит уничтожение текущего экземпляра entity-компонента;
ejbActivate() – уведомляет компонент о том, что он только что был активизирован;
ejbPassivate() – уведомляет компонент о том, что готовится его деактивация, то есть экземпляр будет отсоединен от конкретного entity-объекта (от конкретных данных в базе данных) и возвращен в пул доступных экземпляров;
Итого: каждый entity-бин должен обладать следующими характеристиками:
К еntity-бинам может обращаться одновременно большое количество пользователей.
Entity-бины могут участвовать в транзакциях.
Entity-бины представляют данные в структуре домена.
Entity-бины перманентны. Они существуют до тех пор, пока существуют данные в структуре домена.
Entity-бины не подвергаются влиянию системных сбоев. Клиент не теряет данные в результате сбоя или отключения сервера EJB. Entity-бины имеют постоянные объектные ссылки, которые содержат неизменяемый ключ данного бина.