· ejbPassivate и ejbActivate. Эти методы, так как они унаследованы от интерфейса, всегда должны присутствовать в классах всех сеансовых компонентов, но их реализация необходима только для компонентов с поддержкой состояний. Они вызываются при пассивации или активизации экземпляра. Часто эти методы остаются пустыми, если не требуется какая-то специальная процедура инициализации или очистки перед пассивацией или активизацией EJB.
Класс сеансового компонента может содержать дополнительные методы, которые играют вспомогательную роль в поддержке других методов компонента. Обычно в класс сеансового компонента включаются также все переменные экземпляров, которые хранят информацию об объекте сеанса. Кроме того, в классе реализации хранится поле SessionContext. Пример класса реализации сеансового компонента приведен ниже.
Моделирование поведения интерфейса
Одна из проблем при компонентной разработке заключается в выяснении правильного способа использования компонента. Хотя возможности компонентов, например EJB, описываются их интерфейсами, в которых содержатся соответствующие методы, не каждое сочетание или последовательность вызова методов допустимы в программе.
Рассмотрим, например, удаленный интерфейс для сеансового компонента ShoppingCart, изображенный на рис. 12.8.
Теперь рассмотрим диаграмму последовательностей, показанную на рис. 12.9.
На диаграмме последовательностей показан порядок использования этого сеансового компонента. Но чтобы удостовериться, что компонент действительно можно использовать таким образом, следует прочитать документацию по компоненту или даже проиграть с просмотром кода компонента все возможные сценарии использования.
Существует простой способ узнать, как следует использовать компонент. Для этого надо смоделировать и продокументировать интерфейс с помощью диаграммы состояний. Такая диаграмма для удаленного интерфейса ShoppingCart показана на рис. 12.10.
Эта диаграмма состояний определяет все допустимые последовательности операций данного компонента. Если проверить по ней диаграмму последовательностей на рис. 12.9, легко убедиться, что она описывает допустимый сценарий. Также ясно, что если бы на диаграмме последовательностей сообщение addltem() появилось между сообщениями checkout() и confirmCheckout(), такой сценарий был бы недопустим в данной реализации ShoppingCart.
Жизненный цикл сеансового компонента
Жизненный цикл сеансового компонента включает все элементы, которые мы рассмотрели в данной главе. На рис. 12.11 показана диаграмма состояний жизненного цикла сеансового компонента с поддержкой состояний. Такой же цикл, но со значительными отличиями (и более простой) для сеансового компонента без состояний изображен на рис. 12.12.
Обычные сценарии сеансового компонента
Ниже приведен стандартный сценарий использования сеансового компонента.
1. Клиент вызывает метод javax. rmi. PortableRemoteOb ject. narrow(...) и по лучает ссылку на местный интерфейс.
2. С помощью ссылки на местный интерфейс клиент вызывает нужный метод create для объекта сеанса. Возвращается ссылка на удаленный интерфейс для данного сеанса.
3. Клиент вызывает любое количество деловых методов с использованием ссылки на удаленный интерфейс.
4. Клиент вызывает метод remove местного либо удаленного интерфейса.
Некоторые диаграммы последовательностей UML, изображающие обычные сценарии применения разных сеансовых компонентов, приводятся ниже. На рис. 12.13 показан простой сценарий для сеансового компонента без состояний. На рис. 12.14 показан более сложный сценарий, требуемый для компонента с поддержкой состояний. В обоих компонентах применяется демаркация транзакции с управлением от контейнера.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.