Реальные сценарии использования EJB с состоянием

Question

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

Итак, не могли бы вы привести конкретные примеры, основанные на вашем опыте / опыте, как сессионные EJB-компоненты с сохранением состояния используются в современных (в отличие от 2003 года, например) приложениях?

Answer 1

Stateful EJB может сохранять свое состояние в базе данных, но Stateful EJB не обязательно нужно сохранять свое состояние в базе данных. Stateful EJB обязан хранить и запоминать состояние разговора с клиентом только на время "разговора".

Ниже вы можете найти некоторые реальные примеры, определенные в некоторых случаях, которые подходят для использования Stateful EJB в соответствии с Java EE 7 Tutorial: Сессионные компоненты Stateful подходят, если выполняется любое из следующих условий.

• Состояние бина представляет собой взаимодействие между бином и конкретным клиентом. Пример из реального мира: реализация EJB-транзакции в режиме онлайн с логином, действием, выходом из системы.

• Боб должен содержать информацию о клиенте через вызовы методов. Пример из реального мира: Stateful EJB может использоваться для реализации карты покупок. Данные могут быть сохранены или нет, например, для интернет-магазина, который не требует входа в систему, карта покупок может быть сброшена, если пользователь окончательно не заберет товары, которые он собрал.

• Бин является посредником между клиентом и другими компонентами приложения, предоставляя клиенту упрощенное представление. Stateful EJB может быть использован для реализации абстракции постоянства.

• За кулисами компонент управляет рабочим процессом нескольких корпоративных компонентов. Пример реального пустоты: Stateful EJB может использоваться для осуществления транзакции онлайн-бронирования каникул, где EJB моделирует агента, который бронирует билет на самолет, автомобиль и гостиницу у разных провайдеров, используя другие EJB, а затем возвращает результаты клиенту.

Приведенные выше примеры демонстрируют применимость концепции в некоторых примерах. Фактическое использование Stateful EJB-компонентов в реальной среде в настоящее время привело бы к более чистому дизайну, однако было бы неоптимальным, если бы учитывались производительность и сложность. Смотрите также Stateful EJB в веб-приложении?,

Answer 2

В настоящее время у нас есть пара Stateful EJB в одном из наших приложений, работающих на производстве. Так что, я полагаю, это можно рассматривать как пример из реальной жизни.

Эти EJB-компоненты используются для предоставления больших объемов данных клиентам путем разделения этих данных на куски и отправки этих кусков по требованию. Все это работает следующим образом:

• клиент готовит запрос, указывая фильтры, с которыми он хочет, чтобы данные просматривались;
• он отправляет этот запрос с использованием метода Stateful EJB;
• запрос обрабатывается на сервере и готовится набор результатов;
• в ответ на запрос клиент получает дескриптор набора результатов на стороне сервера;
• имея этот дескриптор, он теперь может получать порции данных, используя методы bean-компонентов Stateful.

Был ли компонент Stateful необходим в решении такой проблемы? Не за что.

Описанная функциональность может быть достигнута с помощью компонента без сохранения состояния. Но в этом случае у нас есть только два способа его реализации. Либо мы вынуждены подготавливать наборы результатов для запросов каждый раз, когда клиенту требуется следующая порция данных (поскольку у нас нет состояния), либо мы используем некоторое статическое хранилище и заботимся о безопасности и параллельном доступе самостоятельно. / Под безопасностью здесь я подразумеваю предотвращение ситуаций, в которых один клиент может получить доступ к результирующему набору другого, используя свой дескриптор /

Первый способ просто медленнее и менее эффективен по сравнению с реализацией на бинах Stateful. Второй способ более сложен и менее стабилен под нагрузкой из-за синхронизации.

С Stateful bean мы просто получаем то, что нам нужно, эффективно и без лишних усилий.