J2EE - реализация постоянно работающего компонента / демона - PullRequest
Новая
       23

J2EE - реализация постоянно работающего компонента / демона

2 голосов
/ 18 марта 2011

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

Схема работы выглядит примерно так:

  1. Электронный массив датчиков постоянно перенаправляет данные на виртуальный диск через USB
  2. Приложение-очиститель обрабатывает данные так быстро, какон может и загружает его в дб (область подготовки)
  3. Используя триггеры, дб выполняет вычисления над данными и сохраняет результаты в другой схеме (область данных)
  4. Клиентское веб-приложение может отображать обработанные данные в виде графиков /отчеты и т. д. по запросу

В идеале решение будет выглядеть следующим образом:

  1. Сервер базы данных - PostgreSQL
  2. Имеет веб-интерфейс администрирования, который может отслеживатьочиститель (т. е. записи, обрабатываемые за час или что-то в этом роде), и, если он реализован как отдельный демон, управляйте им.
  3. Приложения Flusher и Client, написанные на Java, в идеале с использованием J2EE

сейчаспроблема, которая продолжает беспокоить меня, и я не могу найти ответ: как приступить к написанию компонента flusher, то есть процесса, который постоянно выполняется в баckground в J2EE.

Поискивая в Интернете, в основном появились три возможности:

a) Напишите очиститель как компонент, управляемый сообщениями, и управляйте им из главного приложения с помощью JMS.Однако: мне не нравится идея постоянного запуска MDB, я даже не уверен, что это возможно

b) Напишите очиститель как EJB и управляйте им, используя службу таймера / планирования.Тем не менее: события на самом деле не рассчитаны по времени, просто нужно запускать их в бесконечном цикле, пока не будет сказано, что это не нужно, просто кажется неправильным использование технологии.

c) Напишите очиститель как отдельное Java-приложение, запустите егов качестве службы ОС (Linux или Windows) и управления с помощью сценариев запуска через ProcessBuilder, вызываемый из EJB.Для мониторинга его состояния используйте JMS.Тем не менее: это просто кажется мне слишком сложным решением, зависящим от платформы и, возможно, даже ненадежным, и поскольку EJB не должен порождать / управлять своими собственными потоками, что в принципе делает ProcessBuilder, это просто кажется неправильным.

По сути, ни один изони мне кажутся правильными, и я не могу понять, какое бы нам было правильное решение в мире Java / J2EE.

Спасибо, Томас

1 Ответ

2 голосов
/ 18 марта 2011

Я бы написал приложение "Flusher" как отдельный процесс Java. Возможно, используйте что-то вроде Java Service Wrapper , чтобы превратить его в сервис для вашей ОС. Я не очень хорошо знаком с вариантами взаимодействия с RAM-диском через Java, но вы либо собираетесь получить InputStream, который вы можете оставить открытым для жизни процесса и постоянно читать, либо вы собирается постоянно опрашивать изнутри цикла времени. Совершенно нормально сделать что-то вроде следующего: 

private volotile boolean stopFlag;

...

while(!stopFlag) {
  processNextInput();
}

Тогда у вас будет другой механизм в другом потоке, который может установить для StopFlag значение true, когда вы захотите завершить процесс.

Что касается мониторинга промывочной машины, то JMX кажется хорошим решением. Это именно то, для чего это было предназначено. Вы должны создать MBean, который предоставит любой статус или статистику, которую вы хотите, и тогда другие процессы смогут подключиться к этому MBean и запросить эти данные.

В таком случае «клиентское» приложение будет простым сервлет-приложением, которое создает отчеты по вашей базе данных и предоставляет симпатичную оболочку для MBean из вашего флешера. В качестве альтернативы вы можете просто контролировать сбрасыватель с помощью консоли JMX и даже не привлекать клиента к этому фрагменту системы.

Я не думаю, что EJB действительно имеют смысл для этой системы. Я несколько пристрастен к EJB, так что прими мой совет с недоверием, но для меня я не вижу необходимости в них в этом приложении.

...