Сеансовые компоненты подразделяются на две основные категории: компоненты с поддержкой состояний (stateful) и не имеющие состояний (stateless). Это различие определяет, может ли компонент сохранять так называемое диалоговое состояние.
Диалоговое состояние — это данные, описывающие сеанс связи, характеризующийся соединением конкретного клиента с объектом сеанса.
Если сеансовый компонент сохраняет это состояние, он дает клиенту возможность связываться с определенным объектом сеанса, прекращать работу на какой-то произвольный промежуток времени (секунды, минуты, часы, дни и т.д.), а затем возобновлять ее на том самом месте, где она была прервана, и с тем самым объектом сеанса. Эта возможность называется поддержкой состояний.
В противоположном случае, когда клиент работает с данным объектом сеанса и прерывает работу на любое время, немедленно после прерывания объект сеанса уничтожается и никаких данных о сеансе не сохраняется. Если клиент возвращается, создается новый объект сеанса и все начинается с начала. Так работает сеансовый компонент, не имеющий состояний.
Поскольку сеансовые компоненты, не имеющие состояний, требуют меньше системных ресурсов, они используются чаще, чем компоненты с поддержкой состояний. Но с ростом требований, которые клиенты предъявляют к сеансам, и расширением возможностей управления ресурсами, предоставляемых контейнерами EJB, целесообразным выглядит переход к поддержке состояний, что дает массу дополнительных преимуществ.
В большинстве случаев сеансовый компонент с поддержкой состояний имеет следующие отличительные черты.
· Он создается для использования только одним клиентом.
· Он вызывается по уникальному идентификатору.
· Он сохраняет состояние в продолжение разных методов и транзакций.
· Он сохраняет состояние посредством пассивации экземпляра.
· Он может выполнять синхронизацию сеанса.
Отличительные черты сеансового компонента, не имеющего состояний, следующие.
· Он создается для последовательного использования многими клиентами.
· Он не имеет уникального идентификатора и обычно выбирается из группы компонентов.
· Состояние в последовательных методах и транзакциях не сохраняется.
· Состояние при пассивации экземпляра не сохраняется.
· Он не может выполнять синхронизацию сеанса.
Эффективно моделировать диалоговое состояние сеансового компонента можно при помощи диаграмм состояний UML. Такое моделирование полезно для понимания всего хода событий в сеансе и упрощает проектирование логики компонента.
Пример такой диаграммы показан на рис. 12.5.
На этом рисунке изображено диалоговое состояние компонента TravelReservations, разновидности которого часто встречаются на Web-страницах заказа авиабилетов.
Процесс заказа авиабилетов состоит из нескольких этапов, включая задание предпочтений пользователя (требуемое число мест, желательное время вылета и/или прибытия, желательная авиакомпания, ценовой диапазон и т.д.). Затем пользователь указывает дату, исходный пункт (сегмент отправления) и пункт назначения (сегменент прибытия)
После ввода этих данных система представляет пользователю список рейсов в сегменте отправления и предлагает выбрать рейс. Процесс продолжается, пока пользователь не укажет подходящие рейсы и не потребует выписать билеты или не начнет выбор снова, задав другую дату. Сценарий успешного выбора, ведущий к оформлению билета, показан на рис. 12.6.
Как можно понять из диаграммы состояний и диаграммы последовательностей, моделирование диалогового состояния в диаграмме состояний позволяет легче разобраться в компоненте TravelReservations и легче реализовать его. Ясно, например, что пользователь может задавать предпочтения лишь до начала запроса на подходящие рейсы.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.