Сеансовые (Session) компоненты EJB без состояния и с состоянием, их особенности и применение.

Сессионный бин представляет одного клиента внутри сервера J2EE и обеспечивает доступ (вызов) к методам сессионныхбинов. Как видно из его названия, сессионный бин подобен интерактивному сеансу. Бин сеанса не является совместно используемым, т.к. интерактивный сеанс может иметь только одного пользователя. Как и интерактивный сеанс, бин сеанса не сохраняется. (То есть, его данные не записываются в базу данных.) Когда клиент заканчивает работу, его бин сеанса тоже заканчивается, и он больше уже не связан с клиентом (пример реализации смотри приложение 1).

Типы сессионныхбинов:

· с состоянием

· без состояния.

Бины сеанса с состоянием

Состояние объекта состоит из значений переменных его экземпляра в конкретном уникальном сеансе взаимодействия между клиентом и бином. Поскольку клиент взаимодействует ("разговаривает") со своим бином, это состояние часто называют диалоговым состоянием.

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

Бины сеанса без состояния

Бины сеанса без состояния не поддерживают состояние диалога для определенного клиента. Переменные экземпляра бина могут содержать состояние, но только на время вызова метода. Когда метод заканчивается, состояние больше не удерживается.

За исключением времени выполнения метода, все экземпляры бина без состояния эквивалентны, что позволяет контейнеру EJB назначать экземпляр любому клиенту (из организуемого пула экземпляров).

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

Иногда контейнер EJB записывает бины сеанса с состоянием во вторичную память. Но бины сеанса без состояния никогда не записываются во вторичную память. Следовательно, бины без состояния могут обеспечить лучшую производительность, чем бины с состоянием.

Следует использовать бины сеанса при следующих обстоятельствах:

· В каждый момент времени только один клиент имеет доступ к экземпляру бина.

· Состояние бина не сохраняемое, он существует только в течение короткого периода времени (возможно, несколько часов).

Бины сеанса с состоянием применяются, если выполняются следующие условия:

Состояние бина представляет взаимодействие междубином и определенным клиентом.

Бину необходимо хранить информацию о клиенте между вызовами метода.

Бин служит промежуточным звеном между клиентом и другими компонентами приложения, давая клиенту упрощенное представление.

"За сценой" бин управляет рабочим потоком нескольких корпоративных бинов.

Для повышения производительности вам следует выбрать бин сеанса без состояния, если он имеет любую из следующих особенностей:

Состояние бина не содержит данных для определенного клиента.

В одном вызове метода бин выполняет общую задачу для всех клиентов. Например, вы можете использовать бин сеанса без состояния для отправки по электронной почте сообщения, которое подтверждает заказ сделанный "on-line".

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

 

Общие принципы развертывания сеансовых компонентов EJB. Пример текста дескриптора поставки.

 

Delpoyer отвечает за присутствие всей необходимой информации в Дескрипторе Поставки и за ее корректность. Его не интересует код компонентов - его задача обеспечить их функционирование в данной операционной среде, определить права доступа к Компонентам и правила выполнения транзакций (кроме случая, когда компоненты сами управляют транзакциями), обеспечить взаимодействие с конкретными СУБД, разместить компоненты в нужные Контейнера. Вообще, под процессом развертывания приложения понимается совокупность всех действий по настройке системы в конкретной операционной среде, после которых клиент может приступить к работе с ней.

Дескриптор развертывания (Deploymentdescriptor)

Дескриптор развертывания (иногда используются термины «установки» или «поставки» - в настоящий момент еще нет устоявшегося термина на русском языке)- необходим для настройки созданного компонента на работу в конкретной операционной среде. Необходимость в нем возникает из-за того, что спецификация EJB четко определяет несколько этапов, который проходит компонент от своего создания до доставки конечному пользователю с окончательной настройкой. Об этих этапах уже говорилось ранее. Наличие подобного «конвейера» требует передачи информации от одного этапа к другому. С каждым компонентом сопоставлен свой дескриптор.

Спецификация EJB 1.1 требует, чтобы Дескриптор Развертывания имел XML-формат. Поскольку XML является метаязыком, то для описания каждого конкретного класса документов нужно создать свой язык - в частности, определить набор используемых тегов и правила взаимоотношений между ними. Такой язык называется DocumentTypeDefinition (DTD).

Дескриптор Развертывания соответствует DTD, разработанному фирмой SunMicrosystems. Он содержит набор свойств, который описывает, как Контейнер будет выполнять процесс развертывания Компонента или приложения, и включает набор тегов и атрибутов, чьи значения определяют состояние свойств Компонента. В качестве примера приведем несколько тегов:

<session> - говорит о том, что Компонент является session-Компонентом (тег <entity> используется для обозначения Entity-Компонентов).

Внутри области тега <session> могут использоваться другие теги:

<ejb-class> - имя класса реализации.

<home> - имя home-интерфейса.

<remote> - имя remote-интерфейса.

<session-type> - показывает, является ли session-Компонент stateful- или stateless-Компонентом.

<transaction-type> - показывает, используется ли для Компонента CMT или BMT.

 

<?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>