Java EE: создание и удаление слушателей сокетов динамически из модели предметной области

Question

Я создаю приложение Java EE, которое позволяет пользователям добавлять / удалять таблицы «socketinfo» (хранящиеся в базе данных) из веб-интерфейса.Если пользователь активирует «socketinfo» из веб-интерфейса, сервер приложений должен создать прослушиватель сокетов для входящих пакетов и обработать данные.Если пользователь отключает или удаляет «socketinfo», прослушиватель сокетов должен быть удален.Весь продукт должен содержаться в одном ухе и предпочтительно соответствовать требованиям.Некоторые подходы, которые я рассмотрел, но столкнулись с проблемами:

1. Создайте адаптер ресурсов JCA для сокетов и используйте MDB в качестве слушателей.Проблема, с которой я столкнулся, заключалась в том, что я не могу понять, как программно развернуть MDB для разных сокетов, когда пользователь добавляет их.

2. Создать ejb @ Singleton / @ Service, который управляет демономтемы с тщательной синхронизацией.Одиночный ejb может быть внедрен в бизнес-уровень, так что операции CRUD и манипулирование сокетами происходят в правильном рабочем процессе.Проблема здесь заключалась в том, что якобы создание потоков из EJB-компонентов считается плохой практикой и не соответствует спецификациям (даже если жизненный цикл синглтона правильно обрабатывается и имеются надлежащие механизмы синхронизации?).

3. Поместите потоки в модель предметной области (еще один синглтон?) И попросите EJB использовать эту модель.Это был худший из них, поскольку серверы приложений, как правило, имеют несколько загрузчиков классов, в целом меньше поддержки контейнеров, плюс это страдает от всего 2. страдает от.

Любая идея, как правильносправиться с этой ситуацией в Java EE?

РЕДАКТИРОВАТЬ: Расширение этого вопроса: если я решу подойти к этой проблеме, как предлагает ewernli в своем решении 3, что я получу, сделав это в JCA (с пользовательским интерфейсомдобавить внутренние темы), которые я бы не получил от (хорошо продуманного) синглтона?Хотя создание адаптера ресурсов не выглядит чудовищной задачей, оно не кажется тривиальным и может занять немного времени (а может быть, даже сложнее для других разработчиков).

Answer 1

Я уверен, что # 2 - лучшее решение (и оно также действительно). я не смотрел на спецификацию новых ejb-синглтонов, но я предполагаю, что потоки внутри них будут приемлемыми (учитывая, что в этих ejbs допустимо выполнять собственную синхронизацию). они были разработаны, чтобы упростить (то есть) развертывание служб типа управления, что вы могли сделать ранее с использованием JMX (хотя развертывание не было стандартизировано). в пределах MM JMX, безусловно, было бы приемлемо сделать ваше собственное управление потоками , так что я бы отнес это к синглтонским ejbs .

сделал быструю проверку спецификации ejb 3.1, и я предполагаю, что единственным допущением для Singleton является управление параллелизмом, без потоков и сокетов. отчасти глупо. Я думаю, что они не являются полноценной заменой MME JMX. Тем не менее, вы всегда можете использовать JMX Mbean, хотя развертывание является нестандартным. если вы используете jboss, то аннотация службы будет эквивалентна jMX mbean, в котором все должно быть разрешено (потоки, сокеты и т. д.).

Answer 2

Ваш анализ кажется обоснованным, и вы правы, когда говорите, что не можете динамически развернуть MDB для соответствия JCA.

Еще несколько дизайнерских идей:

• Вы могли бы написать JCA-соединитель, который возвращает SocketConnections (в духе JMS), который вы могли бы использовать для чтения из сокета. Чтобы продолжить аналогию с JMS, MDB представляет MessageListener, а то, что вы бы выставили, - MessageConsumer.

• Вы можете использовать периодический таймер для имитации потока. Вместо потока с циклом while у вас есть таймер, который перепланировал себя. Я использовал это для одного приложения, чтобы иметь фоновый процесс, и это работало нормально. Обратите внимание, что я также порождал потоки прямо из EJB-компонентов для выполнения некоторых параллельных вычислений в другом приложении, и это тоже хорошо работало. Но потоки с коротким сроком действия и бизнес-метод в компоненте будут ждать, пока все не будет завершено, так что это не является серьезным нарушением спецификации.

• Еще один дизайн - соединитель JCA обрабатывает потоки и т. Д. И доставляет все сообщения в MDB. MDB будет принимать данные вместе с информацией о «канале», которому соответствуют данные, например, Разъем порта. Это как мультиплексирование всего в одном MDB, которое затем демультиплексирует данные. Ваш коннектор может предоставить дополнительный API для управления созданием потоков и т. Д., И этот интерфейс может быть внедрен в ваш EJB (аналогично ConnectionFactory). Ваш коннектор может предоставить дополнительный API для управления созданием потоков и т. Д. Не совсем понятно, но я надеюсь, что вы поняли идею. Если я прав, соединитель JCA может обеспечить синхронную доставку данных в MDB, по крайней мере, для каждого сокета, чтобы MDB обрабатывал данные в правильном порядке.

Я бы пошел на # 3, , если позволяет время разработки .

EDIT

Этот выбор действительно частично является вопросом чистоты дизайна. Одна проблема с порожденными пользователями потоками состоит в том, что вы, очевидно, не можете использовать для них декларативные транзакции. Вы можете использовать UserTransaction для разграничения транзакций самостоятельно. Я не знаю, насколько хорошо вы можете использовать EntityManager также в такой теме. Если вы в основном обрабатываете данные и не используете много функций промежуточного программного обеспечения, вы можете порождать потоки самостоятельно. Смотрите другой мой ответ: Как EJB может распараллелить длинный процесс, интенсивно использующий процессор? . Другие вещи, которые приходят мне в голову (не знаю, проблематичны они или нет): менеджер безопасности может препятствовать созданию потока (?), А не создавать их, так как deamon threads может помешать приложению. сервер правильно выключен (?). Обратите внимание, что я порождаю темы из ServeletContextListener при запуске, и это работало просто замечательно. Этот прием часто используется, даже если он нарушает спецификацию. То же самое может стать правдой для "недавно" введенных синглтон-бинов. Так что, если у вас мало времени, вы, конечно, можете попробовать свое предложение с помощью одноэлементного компонента и посмотреть, что работает / не работает.