Должна ли бизнес-логика управляемого сообщениями передаваться в EJB-сеансный компонент

Question

Меня попросили исследовать некоторые из наших MDB и, где применимо, перенести логику в EJB.Мой вопрос: имеет ли значение, если вся логика в методе OnMessage или это вызовет метод EJB.Текущую логику не нужно вызывать напрямую, поэтому нет необходимости делать ее доступной через EJB.Будет ли MDB, звонящий в EJB, иметь какие-либо преимущества?

Answer 1

MDB может содержать ссылки на другой EJB, ресурсы соединения JMS и любые другие источники данных или ресурсы соединения с базой данных.Кроме этого, он не должен содержать никакого состояния (например, компонент без состояния, не содержащий состояния клиента).MDB не доступны напрямую клиентам, и интерфейс не открывается, mdbs асинхронно прослушивает сообщения от клиентов.

Итак, проверьте, сохраняют ли экземпляры MDB какие-либо данные или диалоговое состояние для конкретного клиента.Обычно контейнер должен иметь возможность назначать сообщение любому из mdbs, а также объединять экземпляры, так что потоки сообщений от нескольких клиентов могут обрабатываться одновременно.Таким образом, разделяя проблемы, как и для любого другого класса, здесь также будет иметь свои преимущества, MDB должен делать то, что он должен делать, перемещать бизнес-логику, связанную с обработкой сообщений, в другой экземпляр EJB (если требуются сервисы contianer).

Ценность разделения интересов упрощает разработку и обслуживание компьютерных программ.Когда проблемы хорошо разделены, отдельные разделы могут быть повторно использованы, а также разработаны и обновлены независимо.Особое значение имеет возможность впоследствии улучшать или модифицировать один раздел кода без необходимости знать детали других разделов и без необходимости вносить соответствующие изменения в эти разделы.

см. Вики Разделение интересов .Отдельный класс должен быть ejb, если вам требуются контейнерные сервисы, такие как транзакция.

Answer 2

Основным преимуществом переноса вашей логики в EJB является то, что это даст вам дополнительный контроль над границами транзакций.

Поскольку MDB по своей природе являются транзакционными, сбои могут привести к откату, после которого сообщение пересылаетсядоставлен.Иногда это именно то поведение, которое вам нужно, но не часто.

Если вы сконфигурировали метод обслуживания на вашем EJB, чтобы он запускал новую транзакцию (REQUIRES_NEW), то любые ошибки приводят к откату транзакции EJB, но не для MDB.

Затем метод onMessage может предпринять любое действие, необходимое для восстановления (или нет) в пределах его неповрежденной транзакции.

Answer 3

Существует разница между MDB и EJB-компонентом.MDB в основном используется для асинхронной обработки, когда некоторая система помещает сообщение в очередь, а затем сервер приложений выбирает экземпляр MDB из пула и обрабатывает это сообщение.В случае EJB это синхронный вызов, когда клиент должен ждать ответа сервера приложений.

Так что, если вы хотите перенести свой логин в MDB, проверьте, нужна ли асинхронная работа, которую выполнял этот MDBили нет вообще.

И вместо перемещения логики в EJB и вызова этого EJB вы можете создать внутренний класс обслуживания, который будет иметь бизнес-логику, и использовать этот сервис как из метода реализации MDB, так и из метода EJB.Таким образом, каким бы клиентом это ни понадобилось (асинхронно / синхронно), вы можете использовать ту же бизнес-логику.