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

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

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


person John Donn    schedule 05.08.2016    source источник


Ответы (2)


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

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

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

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

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

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

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

person Spyros K    schedule 05.08.2016
comment
Я попытался продемонстрировать применимость EJB с отслеживанием состояния в наборе подходящих случаев EJB с отслеживанием состояния. Я использовал учебник EE в качестве справочника для подходящих случаев и приводил упрощенные примеры, основанные на личном опыте. Ваше разъяснение показывает, что вам больше интересно узнать, действительно ли эта концепция полезна на практике. Я бы сказал, что действительно EJB с отслеживанием состояния следует избегать, а EJB без сохранения состояния предпочтительнее из-за лучшей производительности и простоты. Другие так думают. stackoverflow.com/questions/2811312/ < / а> - person Spyros K; 05.08.2016

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

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

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

Был ли компонент с отслеживанием состояния необходимостью для решения такой проблемы? Нисколько.

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

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

С помощью bean-компонента с отслеживанием состояния мы просто получаем то, что нам нужно, эффективно и без дополнительных усилий.

person Aleksandr Erokhin    schedule 05.08.2016