Существуют ли механизмы рабочих процессов, не использующие BPMN и BPEL?

Механизмы рабочих процессов обычно играют активную роль в архитектуре предприятия. Они реализуют декларативную модель процесса, которая представляет собой ориентированный граф, состоящий из узлов, представляющих действия или задачи, и ребер, представляющих поток управления между этими ребрами. Такие ребра могут быть аннотированы условиями, позволяющими выразить условное ветвление/слияние. Существует несколько языков моделирования, таких как YAWL, XPDL, jPDL, BPEL и BPMN 2.0, которые основаны на этих абстрактных концепциях и некотором синтаксическом, визуальном и функциональном сахаре, но только последние являются официальными отраслевыми стандартами. Это важно, чтобы избежать привязки к поставщику, сделать модели взаимозаменяемыми (хотя бы до определенной степени), поддерживаемыми экспертами и разными инструментами. Во время выполнения экземпляры процесса создаются на основе модели процесса и выполняются в соответствии с потоком управления, определенным моделью. Таким образом, движок активно переходит от одного действия к другому и, таким образом, «организует» вашу бизнес-логику. Основное различие между BPMN 2.0 и BPEL заключается в том, что BPEL тесно связан с веб-сервисами, т. е. бизнес-функции, которые должны вызываться действиями, должны отображаться как веб-сервисы. Поэтому, если вы хотите оркестровать сервисы WS-*, это по-прежнему лучший выбор, поскольку в BPMN 2.0 отсутствуют четко определенные и стандартизированные привязки к конкретным реализациям сервисов. В любом случае, я бы настоятельно рекомендовал использовать один из стандартизированных языков, так как они широко распространены в отрасли и хорошо поддерживаются различными поставщиками и сообществами открытого исходного кода.

Я попытался объяснить это более подробно, потому что я не был полностью уверен в том, что вы подразумеваете под «облегчением, отслеживанием и управлением состоянием этих объектов». Это звучит немного так, как будто вас больше интересует пассивный мониторинг изменения состояния объекта, а не активный контроль изменений состояния с помощью механизма рабочего процесса. Если это предположение верно, то, возможно, вам больше подойдет абстрактный конечный автомат.

Взгляните на jBPM5, он предоставляет очень гибкое ядро, которое позволяет вам создавать на его основе свой собственный предметно-ориентированный язык. Сейчас предоставляется язык BPMN2, но вы можете легко добавить свой собственный. Ваше здоровье

Мы создаем продукт, который имеет путь миграции для BPMN 2.0, но не использует BPMN внутри. Мы считаем, что контрольные списки гораздо проще использовать в рабочих процессах в реальном времени, чем блок-схемы. Тем не менее, он по-прежнему имеет правила/триггеры/условия и многое другое — так что это инструмент, который эффективно моделирует процессы как «контрольные списки на стероидах»:

Ознакомьтесь с ним на http://tallyfy.com.