Спасибо за замечательное обсуждение. Я тоже, как и Шурик71 подозреваю, что проблема имеется, и она концептуальная. Вроде знаю 3 подхода к описанию процессов - алгоритмический, функциональный, и стейт-машина.
В современных языках это все реализовано. Для обслуживания алгоритмов используются:
- операторы ветвления и перехода
- циклы
- рекурсия
- стек, в котором сохраняется весь контекст нитки - цепочка вызовов и данные.
- объекты синхронизации ниток (семафоры-мониторы)
Нити выполнения в нормальных языках типа Java являются сериализуемыми, что позволяет нитке заснуть в базе данных, и проснуться по событию. Проблема - все жизненные ситуации надо описать отдельными ветками, а это не всегда возможно, да и дерево получится нечитаемое.
Для функционального подхода используют декларативные языки типа SQL или XSLT, которые интерпретируются неким "оптимизатором". Проблема - надо иметь оптимизатор, который на самом деле является шайтаном
Для стейт-машин существуют механизмы событий (асинхронных и синхронных), подписок, и собственно устройство синхронизации (типа тактового генератора, или прерывания таймера). Тут не надо описывать все возможные варианты, и даже предсказать поведене системы не всегда возможно. Больше соответствует нашей жизни, чем первые 2.
На этих механизмах стоит вся ИТ-индустрия. Но все это очень наукоемко и сложно для понимания, и бизнес хочет чего-нибудь попроще, и применительно к системе управления социумом. Вот и возникают всякие теории процессного менеджмента, а к ним - и инструменты автоматизации. Но на практике те БП, которые я видел в текстовом виде, больше напоминают помесь декларативного описания результата и таблицы состояний/реакций для каждого исполнителя. И описывать это все на алгоритмах - просто ужас.
Вроде в WSS подписки на события имеются, значит стейт-машину реализовать можно, но наш опыт пилотного проекта на MOSS пока не очень впечатляет - функционала Дизайнера не хватает, а БП, разработанные в Студии - не визуализируются. Кругом засада.