Сообщение:
я бы делал так, как уже раз 10 писал:
1. есть группа серверов, на которых живет приложение (есть реплики).
2. есть бизнес-процесс (далее б.п.), например, заявка (документ - хранимый образ б.п.)
3 у каждого документа есть сервер-хозяин (мастер-сервер), т.е. сервер на котором б.п. был запущен (документ-образ б.п. был создан)
4 на каждом сервере есть шедуленный агент(обработчик-толкатель-движок б.п., далее движок). Агент-движок работает , только со "своими" документами, т.е. с документами созданными на его сервере.
5 если допустимы локальные реплики приложения: документы без указанного мастер-сервера (т.е. документы созданные локально) обрабатывает единственный "центральный" (назначенный) сервер (после первой "обработки", он проставляет , например себя, или сервер приписки юзера, который его создал).
6 после создания документа пользователем, кроме агента-движка на сервере-хозяине, этот документ никто не редактирует.
7 любые комментарии, изменения состояния, классификации по этому б.п. оформляются отдельными документами (можно респонсами вешать, а можно просто поле с юнидом документа б.п. пропихивать). соответственно эти команды-месаджы обрабатывает тоже только движок на мастер-сервере этого б.п. ( он подтягивает в документ-образ нужную инфу, изменяет состояние б.п. и т.п.)
собственно, все.
авторы идеи: команда разработчиков Босс-Референта, образца 2002-2003 годов(точнее, не помню). Могу перечислить всех поименно, но страх кого-то забыть и этим обидеть, мешает это сделать. Реализовали ли эту идею в АйТи , после ухода, фактически, 90% команды в 2003 году - не знаю. Но у нас в компании она реализована и работает.
из плюсов такого построения приложения:
1. легкость сопровождения и развертывания
2. легкость изменений в б.п.(наращивание функционала, изменение флоу и т.д.), естественно при грамотной разработке движка.
3. принципиальное отсутствие конфликтных ситуаций
4. легкость "разбора полетов" (как б.п. попал в эту позу-состояние, кто виноват и т.д.)
5. как следствие пункта 4, фарш -таки можно немного провернуть назад.
5. прозрачность с доступом и управления им.
