Очень часто сессионные компоненты без сохранения состояния могут использоваться для решения многих бизнес-задач.
Stateful не обязательно означает, что только удаленный сервер сохраняет состояние, хотя это, безусловно, один из вариантов. Удаленный клиент Swing может сначала отправить пакет данных в сессионный компонент с сохранением состояния, удержать заглушку и затем впоследствии отправить некоторые команды, которые работают с этими данными. Это избавляет клиента от необходимости отправлять одни и те же (большие объемы) данных каждый раз.
В случае удаленного использования это действительно несколько отражает использование HTTP-сеанса при использовании веб-клиентов (браузеров). Основное отличие состоит в том, что сеанс выполняется для каждого bean-компонента, в то время как в сеансе HTTP сеанс является областью, совместно используемой многими компонентами. Поскольку сеанс HTTP основан на файлах cookie, а файлы cookie являются глобальными для домена для всего браузера, сеанс HTTP не может напрямую поддерживать несколько сеансов от одного и того же клиента (например, для каждой вкладки или для каждого окна). Это тривиально с сессионными компонентами с состоянием.
Однако ...
Удаленные клиенты Swing, общающиеся с удаленными EJB, встречаются не так часто.
В контексте, который вы описали в своем вопросе, вы, как правило, будете использовать локальные EJB-компоненты, и вы будете хранить большинство состояний в сеансе HTTP (будьте осторожны с общим доступом!), А в наши дни в области просмотра или области диалога.
Итак, наконец, когда использовать сессионные компоненты с сохранением состояния в этом сценарии?
Одним из важных вариантов использования является extended persistence context в JPA. Обычно с менеджером сущности в области транзакции, когда сущность пересекает транзакционную границу вызова метода EJB, она будет отсоединена. Если вы хотите (оптимистично) заблокировать объект между взаимодействиями с пользователем, это нежелательно. Вы потеряете замок.
В расширенном контексте персистентности сущность остается присоединенной, и блокировки действительны, когда вы возвращаетесь из вызова к сессионному компоненту с сохранением состояния. Это очень полезно для функциональности предварительного просмотра, чтобы гарантировать, что никто не внес никаких изменений в сущность, когда у вас все в порядке после предварительного просмотра. Или даже для корзины покупок, в которой вы хотите убедиться, что в течение некоторого времени товар не может быть продан кому-либо еще в корзине.