Но если транзакция управляется контейнером, такой возможности нет, так как границы устанавливаются автоматически и скрыто от разработчика.
Один из возможных способов моделирования, пригодный для обоих типов транзакций, заключается в обозначении требований транзакции с помощью сообщений на диаграмме последовательностей, в которых указаны соответствующие стереотипы.
Технология сеансовых компонентов
Для клиента сеансовый компонент выглядит как объект, реализующий какую-то необходимую для него логику и обычно удовлетворяющий каким-то требованиям по выполнению транзакций или управлению состояниями. Любой данный объект сеанса доступен в каждый момент только одному клиенту; однако, как было показано выше, объекты сеансов могут использоваться повторно, если они не имеют состояний.
Местный интерфейс
Каждый сеансовый компонент должен иметь местный (Ноте) интерфейс. Это интерфейс, через который клиентская программа вызывает основные методы жизненного цикла компонента. В местном интерфейсе каждого сеансового компонента должен быть определен по крайней мере один метод — create<METOД>, создающий экземпляр объекта сеанса. Здесь <МЕТОД> — любое приемлемое имя метода с любым сочетанием параметров; create играет роль префикса.
Для сеансового компонента с поддержкой состояний можно определить любое количество методов create с любым допустимым количеством сочетаний параметров. Для сеансового компонента, не имеющего состояний, может существовать только один метод create без последующего имени и без параметров.
Для сеансовых компонентов обоих типов существуют также методы жизненного цикла remove. Они уже представлены в базовых интерфейсах EJB, поэтому заново определять их не нужно.
Ниже приведен код типичного местного интерфейса сеансового компонента.
Удаленный интерфейс
Каждый сеансовый компонент должен также иметь удаленный (Remote) интерфейс. Это интерфейс, через который клиентская программа вызывает все деловые методы, которые поддерживаются в сеансовом компоненте. Можно применять почти любые имена методов и параметры, но, конечно, рекомендуется избегать имен, которые уже имеют другое значение в классе реализации.
Удаленный интерфейс необходим в компонентах обоих типов, и требования к нему примерно одни и те же.
Ниже приведен код типичного удаленного интерфейса сеансового компонента.
Класс реализации
Дополнительно каждый сеансовый компонент имеет класс реализации или класс компонента. Этот класс включает код реализации всех методов, вызываемых в местном и удаленном интерфейсах, а также необходимых методов жизненного цикла компонента. Класс реализации должен содержать следующие методы.
· еjbCreate<METOД>. Для каждого метода create, вызываемом в местном интерфейсе, в классе реализации должен присутствовать соответствующий метод, который отличается только префиксом (еjbCreate вместо create). Параметры методов также должны совпадать, но возвращаемые типы различаются. Этот метод часто невелик по размеру и выполняет лишь несколько простых действий по инициализации EJB.
· ejbRemove. Этот метод не имеет параметров и вызывается при вызове одного изметодов интерфейса remove или когда контейнер EJB начинает операцию собственного удаления. В этом методе выполняются все необходимые действия по очистке EJB, противоположные действиям по инициализации.
· setSessionContext. Этот метод вызывается контейнером EJB для сохранения данных контекста сеанса в локальной переменной экземпляра. В большинстве случаев этот метод состоит лишь из одной строки, в которой происходит сохранение контекста.
· Деловые методы. Всем деловым методам, определенным в удаленном интерфейсе, должны соответствовать в классе компонента методы с такими же именами и параметрами. Эти методы содержат большую часть логики EJB. К ним относятся также методы доступа, например простые методы get и set.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.