Что некоторые альтернативы к Модулю управления технологическим процессом?

NetBpm (порт .Net для JBpm)

Одним из вариантов является процесс на основе BPEL. Вы бы пошли по этому пути, если бы предполагали использовать будущие инструменты BPEL для этой работы. В противном случае BPEL представляет собой своего рода чрезмерно запутанный беспорядок (как и все подобные общие решения «все может подключиться»).

Что-то простое - понять, что рабочий процесс на самом деле часто связан с очередями, а не с рабочим процессом. То есть, это больше о том, чтобы положить что-то на чей-то стол, а не направлять поток работы в соответствии с жесткой схемой. В этом контексте то, что содержит очередь, которая представляет собой определенный этап работы, а затем гибко связывается с другими потенциальными фрагментами работы. Есть общий процесс, но есть исключения из него. Механизм правил может перемещать вещи между очередями в рамках общего процесса (и запускать внешние процессы по мере необходимости),

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

(Например, интерфейс на основе событий -> оркестровка на основе правил -> обработка конкретного (линейного) рабочего процесса.)

Вы могли бы сделать это строго как движок конечного автомата, который вы строите динамически на основе пользователя, культуры или чего-то еще. Вам нужно будет сохранить определенные автоматы в качестве состояния для длительных транзакций. Затем, когда пользователь вызывает состояние или предпринимает другое «действие» (в основном моделируемое как переход состояния), вы разрешаете переходам иметь вывод (машина Мили) или в новом состоянии (машина Мура).

Если вы посмотрите на это с высоты 30 000 футов, у вас есть два варианта:

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

В обоих случаях «правила» могут быть определены в рабочих процессах / оркестровках, механизме правил или коде.

Мы решили внедрить системы на основе следующих критериев:

• ] Относительно простые правила, реализованные непосредственно в коде
• Сложная логика в рабочем процессе. Чтобы мы могли показать это клиенту, спросите его, что они имели в виду, и знайте, что это нормально, поскольку то, на что они смотрят, - это то, что выполняется.
• Оркестровка pub / sub для перемещения вещей на основе набора правил

Я работаю с технологией MS, поэтому для типа системы, которую вы описываете , Я бы реализовал это в Sharepoint, в котором есть система управления документами и встроенные рабочие процессы для управления документами. Лицензия Sharepoint начального уровня Windows Sharepoint Services включена в операционную систему.

С точки зрения KISS рабочий процесс - это не что иное, как очереди, а механизм правил - это просто, если иначе - у нас есть система документов, для которой у нас есть рабочий процесс, подобный обработке. Мы рассмотрели рабочий процесс websphere, а также WLI от weblogic, но простой процесс с JMS (MDB, а также wake up consmers) с постоянным хранилищем работал у нас без каких-либо проблем. Думаю, вы здесь правильно выбрали - удачи!