Как вести список Stateful Session Bean?

Question

Учитывая тот факт, что разрабатывается приложение Java EE, предназначенное для сервера чата, я столкнулся с некоторыми проблемами.

Клиенты должны иметь возможность подключаться с использованием различных соединителей, таких как HTTP, SOAP или AMF,Входящие запросы должны быть преобразованы в единые внутренние сообщения.Затем бины, управляемые сообщениями, вызывают бизнес-логику и возвращают результат запроса определенному соединителю.

Q1: это звучит разумно?

Мой вопрос заключается в том, как сохранить информацию о сеанседля каждого клиента.Это может включать данные соединения, временные метки, команды, которые должны быть доставлены и т. Д. Сессионные компоненты Stateful должны подойти для этого, потому что они нужны мне, пока клиент подключен.Однако проблема состоит в том, чтобы поддерживать список всех bean-компонентов, чтобы иметь возможность выбрать правильный сеанс для нового запроса.Я не могу связать ссылку SFSB с HttpSession (как рекомендовано в другом месте), потому что есть разные соединители, а не только клиенты HTTP.

Q2: Какой правильный подход для этого?Менеджер сеансов, который выполняет поиск JNDI для создания нового SFSB и добавляет его во внутренний список?

Q3: Как это будет работать в кластерной среде?Я вижу, что SFSB можно реплицировать на разные узлы, но как синхронизировать список диспетчера сеансов?

Q4: Вы бы порекомендовали сходство сессий в дополнение к балансировщику нагрузки?

Спасибо.

Answer 1

По вашему вопросу:

В3: Как это будет работать в кластерной среде? Я вижу, что SFSB могут реплицироваться на разные узлы, но как синхронизировать менеджер сеансов список

Я храню ссылки на Stateful Session Bean (SFSB) путем сериализации / десериализации их дескрипторов. Он отлично работает в кластерной среде, но когда узлы запускаются / останавливаются в кластере между вашими вызовами SFSB, тогда дескрипторы модифицируются после таких вызовов. И как только дескриптор модифицируется после вызова SFSB, его необходимо сериализовать еще раз для дальнейшего использования.

Я думаю, что вы можете рассмотреть мой подход к сериализации / десериализации дескрипторов SFSB.

Answer 2

Q1: наверное. Это зависит от ваших требований. Просто не переусердствуйте. Иди просто. И имейте в виду, что использование таких вещей, как управляемые сообщениями bean-компоненты, означает асинхронную обработку / ответы и возможность сбоя сообщений или перехода в системную исключительную ситуацию / очередь недоставленных сообщений.

Q2: Как правило, вы хотите искать бины Java EE через JNDI. Облегчает жизнь ИМО. Возможно, вам нужен сервлет, сессионный компонент без сохранения состояния или что-то еще впереди в качестве «контроллера»? Затем вы можете загрузить данные для bean-компонентов с состоянием из базы данных, когда вам нужны эти данные, и / или записать данные в базу данных, когда вам больше не нужен bean-компонент.

Q3: Зависит от того, как вы настраиваете кластер, а также от того, какой сервер приложений вы используете. Каждый сервер может по-разному реализовывать кластеризацию / отказоустойчивость / синхронизацию и т. Д. Я бы порекомендовал прочитать документацию к вашему серверу приложений, чтобы понять это. И / или опубликуйте, какой сервер приложений вы используете, чтобы другие на этом форуме могли что-то порекомендовать. Например, мы используем IBM WebSphere Application Server версии 7.0.0.7, Network Deployment Edition. Поэтому в нашем случае мы можем настроить репликацию bean / объектов между узлами кластера.

В4: Я полагаю, что ответ «да», если вы хотите оставаться подключенным к тому же узлу кластера для каждой последующей транзакции конечного пользователя. (По крайней мере, с точки зрения входа через HTTP-сервер). Я предполагаю, что если у вас не включена привязка к сеансу, вы можете переключиться на другой узел кластера, и может оказаться сложнее найти ваши данные (особенно если вы не реплицируете их между кластерами). Это может быть сделано, это просто может быть удар по производительности. Поэтому я предполагаю, что ответ здесь «да».