Здравствуйте, asminojka, Вы писали:
A>Добрый день !
A>Проектируется система для массового обслуживания пользователей, основная задача состоит в том, чтобы выполнить определенную задачу для большого числа пользователей, например, система может сделать рассылку сообщений по электронной почте, затем дожидаться от каждого пользователя ответа, потом , в зависимости от ответа перейти к след. шагу и т.д. Иными словами задача — это некоторый, общий для всех, алгоритм...
A>Алгоритм ( задачу) хотелось бы реализовать в виде некоего скрипта, который выполнялся бы независимо для каждого пользователя, однако возникает вопрос : можно ли сохранять контекст выполнения сценария для каждого пользователя в базе, например, или в файле, после выполенения очередного этапа ? какие средства для этого лучше использовать , чтобы можно было продолжить выполнения сценария с точки предыдущей остановки ?
A>Заранее спасибо за любые советы.
Это типичный workflow. Суть его в том, что существуют некоторые данные (задание, документ, или экземпляр процесса) существует описание последовательности действий над этими данными (обычно в в виде диаграмы состояний), и существует код (компонент) который способен выполнять заданную последовательность действий над экземплярами наших данных.
Есть много различных подходов к решению подобных задач.
Если алгоритм обработки всего один и он не меняется — жестко закодируйте его методом конечных автоматов. Задачи в виде данных (контекста) и текущего состояния храните в персистентном хранилище (БД или файле). Для обработки, по внешнему событию выбираете из хранилища задачу, скармливаете ее своему автомату, он переводит зазачу в следующее состояние выполняя очередной шаг и сохраняете измененную задач в хранилище. Это будет жесткое нерасширяемое решение. В тоже время оно будет простым и производительным.
Если у вас несколько алгоритмов и велика вероятность что они будут меняться, следует использовать более гибкую систему наподобие
Windows Workflow Foundation. Здесь также алгоритм описывается в виде графа процесса, состящего из действий и переходов. Но существует движок, который умеет исполнять эти процессы, и сохранять их состояние. А сами процессы (вернее действия) могут оперировать любыми данными. Ограничения в том, что новый процесс необходимо кодировать и компилировать.
Можно построить свой движок, на основе универсальной машины состояний, которая получает на вход описание диаграмы состояний и переходов (например в виде Xml), и текущую задачу, которую переводит в следующее состояние в соответствии с загруженной диаграмой, выполняя при этом заданное в диаграме действие.
Наконец самый общий и самый гибкий подход — это полнофункциональный workflow сервер на основе рекомендаций
Workflow Management Coalition (WfMC). Здесь процессы описываются при помощью формального Xml языка (XPDL, BPML). Они могут выполнять в виде операций вызовы функций различных систем и могут оперировать различными данными из разных систем. Отличие от предыдущих вариантов в том, что сами пользователи системы могут описывать новый процессы и изменять существующие (при помощи графических дизайнеров) и исполнять их. Это уже, своего рода, системы интеграции приложений на основе процессного подхода. Существуют много реализаций таких систем, например,
здесь
