Предыдущее сообщение является точным с точки зрения модели, которая позволяет асинхронно помещать заказы или запросы в очередь, а затем получать их позже. Однако на самом деле это не относится к вопросу о длительных процессах.
Что касается очередей и тем, то преимущество постоянных очередей состоит в том, что если в очереди нет потребителей, то сообщения будут ожидать потребления, пока не будет подписчик. В теме необходимо создать постоянную подписку, чтобы убедиться, что не подключенный потребитель будет получать сообщения, отправленные в его отсутствие после повторного подключения.
Итак, как вы определяете длительный процесс? Для многоэтапного процесса вы обычно используете что-то вроде движка рабочего процесса. Есть такие опции, как инструмент BPM или что-то вроде «Рабочий процесс ОС». Вы также можете сделать домашнее решение, которое может выглядеть как в примере ниже
1) Должно быть какое-то определение рабочего процесса, определяющее этапы процесса. Это может быть файл свойств или файл XML.
2) Веб-приложение помещает сообщение в очередь или тему (публикацию / подписку) с указанием процесса, который должен быть выполнен (или у вас могут быть определенные места назначения для разных процессов).
3) Диспетчерский MDB выбирает «заказ» из очереди со статусом «NEW» и начинает обработку первого шага.
4) После завершения шага MDB помещает новое сообщение в очередь с указанием выполняемого процесса и либо следующего шага, который должен быть выполнен, либо последнего шага, который был выполнен (в зависимости от того, насколько детерминистическим вы хотите, чтобы процесс был)
5) MDB берет сообщение и видит, что процесс «IN_PROGRESS». Он либо определяет следующий шаг, который должен быть выполнен, либо считывает шаг, который должен быть выполнен следующим, из сообщения (либо значение заголовка JMS, либо внутри сообщения, возможно, в формате XML)
6) Шаги 4 и 5 повторяются до тех пор, пока экземпляр процесса не будет завершен
В этом случае вам потребуется внешнее представление информации о заказе и экземпляре процесса. Это позволит вам проверить статус запроса от вашего WebApp. Ваш заказ необходимо будет прочитать и сохранить с обновленным статусом после каждого шага в процессе, чтобы WebApp мог получить доступ к информации о статусе.
Ключевым компонентом этой архитектуры является диспетчер MDB, который прослушивает сообщения и выполняет следующий шаг процесса. Когда я работал с ОС Workflow, это был один ключевой элемент, который отсутствовал. Таким образом, вы можете контролировать количество потоков, выполняющих шаги процесса, контролируя количество MDB в пуле и потребителей в очереди. В этой архитектуре я бы рекомендовал очередь по теме для шагов рабочего процесса. Однако после каждого шага процесса вы можете опубликовать сообщение в теме для подписчиков, чтобы получить обновленную информацию о состоянии.
С технологиями Java EE6, включая JPA, вы можете легко создать XSD, сгенерировать модель данных домена POJO с помощью JAXB и использовать JPA для обеспечения устойчивости. Ранее в этом году мы провели веб-трансляцию, посвященную технологиям JEE6, которые в настоящее время поддерживаются в WebLogic. Вот повторы: http://www.oracle.com/technetwork/middleware/weblogic/learnmore/weblogic-javaee6-webcasts-358613.html.
Мне также все еще интересно поговорить с вами о вашей миграции на JBoss :) jeffrey.west@oracle.com