Методология построения корпоративных информационных систем на основе технологии EJB

Сессионный бин по функциональности очень похож на обычный класс, от которого вы можете порождать объекты и использовать. Отличительной чертой является способ создания объекта. Как уже говорилось выше существуют Home-интерфейс, который является точкой входа в ваш бин. В нем вы определяете метод create, через который можно создавать сессионные бины на стороне сервера. Вообще сессионные бины предназначены быть представителем клиента на стороне сервера или быть его функциональным расширением, другими словами они нужны в течении сессии работы клиента, а потом их уничтожают. Сессионный бин показан на рис. 12.

Вы можете объявить бизнес методы бина в Remote-интерфейсе(Test) и реализовать их в Implementation бина (TestBean). Другими словами из клиента вы будете вызывать методы Remote-интерфейса, а контейнер будет передавать управлению на реализацию бина сопоставленную с вашим обращением. Есть такое понятие как исполнитель, который сопоставляется бину и обеспечивает его функциональные возможности. Это понятие было введено, так как бин является больше абстракцией, которую нужно поддерживать реализацией. Контейнер управляет пулом исполнителей бинов и решает, какому из исполнителей передать управления. Таким образом, обеспечивается равномерное распределение нагрузки между исполнителями.

Сессионные бины бывают двух видов: Stateless and Stateful. Другими словами бины могут не помнить свое состояние и помнить.

Бывает ситуации, когда Вам не нужно, что бы бин помнил свое состояния между двумя вызовами методов, т.е. вы не складываете информацию в бин методами set и в последующем не пытаетесь ее запросить методами get. Указав, что ваш бин является Stateless вы даете возможность контейнеру лучше использовать ресурсы вычислительной машины при обработки запросов к такой разновидности сессионного бинов.

Бывает ситуации, когда Вам нужно, что бы бин помнил свое состояния между двумя вызовами методов, т.е. вы складываете информацию в бин методами set и в последующем пытаетесь ее запросить методами get. Указав, что ваш бин является Stateful вы обязываете контейнер производить сериализацию на исполнителе, когда серверу не хватает ресурсов для обработки запросов пользователей и контейнер решает сопоставить не занятого исполнителя с запросом пользователя, то ему необходимо сначала сериализировать его состояние. А если попроще, то давайте представим две центрифуги. В каждой из них лежит грязное белье пользователя. Две центрифуги и два пользователя. Предположим что оба пользователя включили режим стирки. Стирка закончилась в первой центрифуге. Первый пользователь пока еще размышляет включить ему режим отжима или так свое белье забрать. В этот момент приходит третий пользователь, а центрифуги всего две. Подходит владелец прачечной и вытаскивает не отжатое белье первого пользователя и помещает белье третьего и запускает центрифугу. После стирки белья третьего пользователя, отжимается белье второго, а потом и третьего пользователя. Выходит что центрифуги две, а пользователя три. Для того, что бы это работало нужно доставать и обратно класть белье, этот процесс называется сериализацией. Или говоря научным языком в случае, когда исполнителей не хватает, то контейнер просто сериализирует состояние одного из исполнителей, передает управление на него, а когда настоящий владелец сериализированного исполнителя пытается на нем вызвать бизнес метод, контейнер производит сериализацию состояния другого исполнителя и восстанавливает состояние сериализированного бина. Сериализация состояния бина происходит обычно на винчестер.

Разберем жизненный цикл Stateless сессионного бина. Жизненный цикл изображен на рис. 13.

Жизненный цикл сессионного бина не помнящего своего состояния довольно прост. Всего два возможных состояния это когда еще ejbObject не существует и когда он создан и помещен в пул. Контейнер не ставит строго соответствия между конкретным клиентом который вызывает бизнес метод и конкретным исполнителем. Обычно для обработки бизнес метода берется тот исполнитель, который "не занят".

Разберем жизненный цикл в Stateful сессионного бина. Жизненный цикл изображен на рис. 14.

Жизненный цикл сессионного бина помнящего своего состояния несколько посложнее. В принципе он похож на предыдущей, только с одним расширением, т.к. необходимо строго сопоставлять клиента с его сессионным бином вводится понятие активизации и пассивизации бина. Во время сопоставления клиента с его сессионным бином необходимо провести активацию, т.е. реализуя метод ejbActivate вы можете в нем определить открытия например сетевых соединений, которые использует бин и когда контейнер решает воспользоваться этим бином что бы обслужить другого пользователя, то происходит сначала пассивизация, которую вы можете реализовать в методе ejbPassivate например закрытия тех соединений которые вы открыли, а потом и активация соответственно. Метод ejbActivate вызывается сразу после сериализации, а метода ejbPassivate до сериализации.