Я бы подошел к этому так.

Мое молот для этого варианта использования будет Java Watch Service, Servlet, JMS-очередь и пакетная служба.

Во-первых, Watch Service - это Java 7, чтобы обрабатывать мониторинг файловой системы.

Я бы написал реализацию Watch Service, и я бы запускал ее в потоке.

Куда запускается нить?

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

Другим местом является асинхронный вызов Session Bean. Там ничего, что предлагает, не может быть долгоживущими призывами. Вы можете встать с @Singleton Session Bean, с @Startup, вызвать метод async из метода @PostConstruct и отпустить его. Затем, в @PreDestroy сигнализирует о длительном запуске метода, чтобы он мог полностью отключиться. Все это должно быть спецификацией, переносимой и, согласно Хойлу.

Третье место - вам ServletContextListener, который является до-Java EE 6, чтобы разместить привязку кода к жизненному циклу приложения. Здесь вы должны создать поток самостоятельно в контекстеInitialized метод, а затем оторвать его в методе contextDestroyed.

Создание потоков здесь "менее определено", но я делал это в течение многих лет и никогда не испытывал проблем.

Теперь, когда у вас есть ваш сервис, служба (IMHO) будет делать две вещи.

1) Будет понятно, когда в каталог поступит новый файл, и когда он это сделает, он будет MOVE (mv, переименовать) файл в параллельный "обрабатывающий" каталог. Причина в том, что это говорит о том, что файл переместился с входящего на обработку, что файл находится в процессе. Это очевидно из списка каталогов, независимо от того, что он делает. Помните, что система может идти по середине через файл.

2) После перемещения разместите имя файла и любые другие метаданные в очереди JMS и добавьте инструмент MDB в пакетное задание.

Зачем добавлять очередь JMS? Это приносит пару функций партии. Во-первых, это отличный способ получить материал "извне" в счастливый трансакционный контекст, который нравится EJB, внутри него. Во-вторых, он транзакционный. Вы можете, в зависимости от вашего случая использования ETL, иметь MDB непосредственно обрабатывать задание. И при этом вы просто не подтверждаете сообщение из очереди до завершения обработки (и файл удаляется или перемещается из каталога "обработка"). В идеальном мире очередь сообщений содержит сообщения, соответствующие файлам в каталоге обработки. Когда обработка завершена, метод возвращается, сообщение получает "commit", и все готово. Если система выйдет из строя, это автоматически перезапустится с самого начала (поскольку сообщение все еще находится в очереди и никогда не удалялось).

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

Но в любом случае, MDB - отличный шлюз в систему, поскольку каждый из них начинает свой собственный бит транзакционного контекста. В отличие от длинного потока сервлета или длинного асинхронного потока. В потоке сервлета есть сомнительный (если есть) транзакционный статус, длинный поточный поток наследует его состояние от метода @Startup и сохраняет его для жизни. Каждый раз MDB получает новый. Большая часть этого может быть изменена с помощью методов вызова с новыми транзакциями.

Но мне нравится демаркация MDB. Даже если все это задача состоит в создании записи Batch для имени файла, MDB является хорошим привратником.

И это в значительной степени.

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

Если вы используете метод @Startup, убедитесь, что вы вызываете свой метод async, введя другой экземпляр вашего сеансового компонента. В противном случае вызов будет локальным, а не асинхронным. Вы будете смотреть на него, задаваясь вопросом, почему ваш сервер висит и не запускается. Все аннотации EJB работают только при вызове через внедренный или просмотренный прокси.

Получайте удовольствие, делитесь и наслаждайтесь.

Добавления к вопросу:

Фактически нет никакой ценности, чтобы внешний процесс управлял службой часов. Один связанный с жизненным циклом сервера легче поддерживать. Приходят на ум две вещи. Если сервер не работает, файл будет просто складываться в файловой системе до тех пор, пока сервер не будет запущен заново, поэтому вы не потеряете данные. Если у вас есть внешняя услуга, вы либо отправляете сообщения на мертвый сервер, либо вам необходимо организовать и управлять сервером JMS отдельно от сервера приложений. В этом случае у вас теперь есть 3 процесса управления: Watch service, JMS Server и сервер приложений, а не только сервер приложений.

Я согласен с другим плакатом, который, если вы решите пойти с внешней службой, в любом случае, простое приложение Java SE публикует простые сообщения в службе REST JAX-RS на сервере или даже тривиальный сервлет очень много, МНОГО более просто поддерживать, этап и развертывание, чем клиент приложения. Если вы сделаете так, вы можете написать службу часов в чем-то совершенно другом.

Но поскольку сервер (якобы) имеет прямой доступ к файловой системе с файлом, на самом деле нет никакой мотивации, чтобы разорвать эту службу за пределами контейнера. Поместите весь комплект в EAR и получите его. Просто простое управление.