Собственно, сам процесс (SODA, синхронная отправка, асинхронная обработка) описан ниже. Кроме него, для каждого из известных типов документов, существует свой сервис, отвечающий за обработку этого типа документа (в пункте 6 эти сервисы обозваны абстрактным словом "сервис").

Что собственно интересует. Процесс я описал так, как себе его представляю, если в чем ошибся, рассмотрю все варианты :) Заранее благодарен за ответ.

1. Подсистема документооборота (проект)

1) Процедура web-интерфейса получает от отправителя версию документа. Начинается транзакция, в которой сохраняется принятая версия документа в таблицы, хранящие исходные версии документов. Идентификатор версии документа отправляется сервису диспетчера обработки документов. Отправителю возвращается подтверждение о приеме версии документа или сбое при приеме версии документа. Транзакция завершается.

2) Версия документа считается принятой, если она не противоречит следующим правилам:

Такой версии документа не существует или существует такая версия документа, содержимое которой в точности совпадает с полученной версией;

В случае существования точной копии отсылаемой версии, возвращается подтверждение о повторном приеме версии документа и её текущем статусе обработки. Сервису диспетчера обработки документов повторное сообщение при этом не отправляется;

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

В случае, когда ни одно из предыдущих условий не выполняется, отправителю возвращается сообщение о сбое приема версии. Копия ошибочной версии документа отправляется сервису уведомления администратора системы.

3) Диспетчер обработки документов начинает транзакцию. Из очереди извлекается сообщение, содержащее идентификатор версии документа. Версия отправляется сервису проверки подлинности документа. Диспетчер сохраняет состояние обработки версии документа в таблице состояний. Транзакция завершается.

4) Сервис проверки подлинности документа начинает транзакцию. Из очереди извлекается сообщение, содержащее документ, проверяет корректность подписи отправителя. Диспетчеру обработки документов отправляется сообщение об успехе (или сбое и причинах сбоя) проверки подписи. Транзакция завершается.

5) Диспетчер обработки потоков документов начинает транзакцию, извлекает из очереди сообщение об успехе или сбое проверки подписи документа.

В случае приема сообщения о сбое, диспетчер отмечает полученную версию документа как сбойную с указанием причины сбоя. При этом службе уведомления администратора системы отправляется сообщение об ошибке приема документа и транзакция завершается;

В случае успеха проверки подписи, диспетчер извлекает идентификатор типа документа и сверяет его с идентификатором, указанным в ранее сохраненном документе. При несовпадении типов документов или сбое, диспетчер отправляет самому себе сообщение о сбое с указанием причины сбоя и завершает транзакцию;

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

6) Сервис, которому отправил сообщение диспетчер обработки документов, выполняет действия по проверке версии документа. Сервис возвращает диспетчеру сообщение об успешном завершении (или сбое и причинах сбоя) проверки версии документа.

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

8) В случае получения сообщения о сбое, диспетчер отмечает полученную версию документа как сбойную с указанием причины сбоя. При этом службе уведомления администратора системы отправляется сообщение об ошибке приема документа и транзакция завершается.

BULK INSERTРоман, скажите мне как Художник Художнику - Вы рисовать умеете? каким нибудь средством моделирования пользуетесь?
Пользуюсь Visio 2003, но рисовать толком не умею :)
BULK INSERTв Визио, например, есть инструменты... да на крайняк в PowerPoint или PaintBrush можно было набросать эскизик...
было бы проще и понятнее...
Согласен, отдельные машины состояний, наборы классов и диаграмы взаимодействий рисуются просто - это я умею, но, боюсь, легкости понимая это вряд ли сильно добавит... особенно нарисованные мной :)
PS: Может посоветуете, где что почитать, посмотреть, что бы лучше развить умение рисовать соответствующие настоящему моменту схемы и диаграммы? Мастер-класс, скажем, может какой подскажете?
BULK INSERT
из контекста не ясно - что значит этот застенчивый эвфемизм "Версия документа считается принятой"
Я перечитав свой текст еще раз, уже вижу, что переписывать надо почти все :)

Коротко поясню ситуацию, откуда ноги растут...
Сейчас стоит система, в которой все сделано не по-людски.

Основная проблема - отсутствие абстракции "документ", как таковой. Соответственно, речь о версионности и ЭЦП не идет, а они нужны.
Дальше-больше... пользователи (примерно около 400 человек, большинство из них работают через модемный пул толщиной в 15 модемов) имеют доступ к набору (около тысячи) процедур, выполняющему сохранение предоставленной пользователем информации в некоторый набор таблиц, с одновременной ее проверкой на правильность реквизитов и бизнес-правил. После чего пользователь запускает еще некоторое количество процедур, которые собирают изменившиеся с момента последней синхронизации данные и возвращают ему обратно.
Минусов у того что сейчас есть, очень много.
Первый существунный минус - невозможно проверить, кто из пользователей накосячил, так как нет истории версий.
Второй - отсутствие ЭЦП, что является источником проблем в работе предприятия (специфика такова, что некоторые документы можно отправлять во внешние системы только с подписью создателя документа).
Третий минус - время выполнения обмена между сервером и клиентом, так как обработка получается синхронной.
Четвертый вытекает из третьего - модемный пул постоянно заполнен, так как приходится ждать. Иногда бывают простои до нескольких часов, что существенно влияет на нервозность в коллективе :(
Пятый минус - повторяемость одного и того же кода в большинстве процедур обработки, очень сильные связи между блоками, на которые, подумав, можно разделить систему.
Шестой минус является продолжением пятого: невозможно выделить некоторые блоки, что бы отдать их на откуп другим подразделениям предприятия.
В результате на обработке имеем шестнадцатиксеоновый HP с 10 Гб памяти... вот такой вот проблем. У партнеров (партнеров по несчастью, имеющих такую же систему) проблема еще больше - количество пользователй системы таково, что около двух лет назад им пришлось купить "супер-дом".

Теперь, что хочу сделать я.

Я хочу разбить всю систему на набор функциональных блоков, обозвав их сервисами и использовав концепцию SOA (в моем случае - SODA, так как сервер MS SQL 2005).
Основная мысль - разбить систему на две крупных части - подсистему документооборота и процессинговый центр. Это позволит пользователям, подключившись к подсистеме документооборота, быстро сбросить набор версий документов в обработку и получить обратно обработанные (с момента начала последнего обмена) документы. Унифицированный формат документа позволит единообразно вернуть пользователю все измененные документы одним селектом (select * from DocumentVersionStore where Timestamp > @UserLastUpdateTimestamp), не рыская по всем существующим в системе таблицам. Версионность же обеспечит минимум требований к производительности подсистемы документооборота, так как не будет обновлений данных (только insert новых версий).

Пока речь идет о документообороте. И здесь у меня следующие мысли:

Есть некий абстрактный документ, определенного типа, например, платежка в банк. Документ создается и изменяется пользователями. Нужно хранить все версии документа, начиная с момента создания этого документа. Кроме этого, пользователи должны иметь доступ к сохраненным версиям документа без дергания записей из таблиц системы проверки бизнес-правил.
Предполагается подсистему документооборота вынести на отдельный выделенный сервер. На других серверах будет установлена процессинговая подсистема, которая должна обрабатывать документы, которые ей передаются подсистемой документооборота. Процессинговая система, на основании истории документов (некоторых регистров, например, "остатки средств на банковском счете"), обработанных к моменту поступления в нее текущего документа (например, платежки), принимает решение о выполнении и отказе в выполнении той или иной операции (например, платежа за товары и услуги).

Дак вот - про документооборот.

Пользователь поштучно (или пакетом, через процедуру, разбирающую пакет на отдельные документы), скармливает документы (xml) некой процедуре ввода документа в систему. Процедура прикрепляет к документу информацию о соединении с пользователем (login) и отсылает этот пакет на обработку сервису документооборота. После скармливания всех документов, пользователю возвращается набор идентификаторов диалогов, через которые он может отслеживать процесс обработки документа. Пользователь отключается до следующего обмена.
В процессе скармливания документа, сервис документооборота проверяет, что документ в текущей редакции (версии) не изменил свой тип (например, платежное поручение не стало "вдруг" платежным требованием), сервис безопасности проверяет документ на целостность и подлинность (ЭЦП). Так же проверяется, что в настоящий момент не существует необработанной версии этого же документа, с целью минимизации возможных межпользовательских коллизий. После этого, в соответствии с типом документа, он отправляется диспетчером на обработку в соответствующий сервис процессингового центра или не отправляется и пользователь получает исключение.

BULK INSERT
из контекста не ясно - что значит этот застенчивый эвфемизм "Версия документа считается принятой"

Имеется ввиду, что версия документа принята в обработку (проверена на валидность и допущена к отправке процессинговой системе).

BULK INSERTтакже не понятно что значит "содержимое которой в точности совпадает с полученной версией" имеется в виду буквальный текст? а если документ содержит что-то еще помимо текста? а если документ вообще не текстовый?

Имеется ввиду полное побитное совпадение.

BULK INSERTв общем возьмите в руки карандаш и все нарисуйте
Опыта в рисовании очень мало - в основном, как писал выше, диаграмы классов, взаимодействия и стейтмашины. Как все это объединять вместе - не знаю даже :)

--
PS: За ответ благодарю - заставили еще раз пересмотреть всю схему в деталях, думаю, пойдет на пользу :)

guest_20040621Какой цифрой ограничен бюджет проекта? По описанию как-то мрачновато все выглядит. Может, дешевле модемный пул радикально расширить и стойку серверов под кластер купить?
Бюджет проекта ограничен бюджетом IT-отдела (около полутора миллионов рублей в год) и возможными бонусами, совпадающими с суммой разницы в стоимости оборудования / обслуживания... но только по результатам внедрения. :)
Расширение пропускной способности модемного пула повлечет за собой увеличение нагрузки на сервер - даже боюсь заикаться перед начальством о "супер-доме"... партнеры получили его за счет гранта, которого у нас нет :)
Проблема на самом деле потихоньку решается путем переключения групп крупных пользователей на выделенные оптоволоконные линии, что кроме нашей задачи решает еще некоторый круг сопутствующих задач. Но прокладка оптоволокна на площади более 60 квадратных километров - дело дорогостоящее и не очень быстрое. Плюс, некоторые проблемы (качество связи в осенне-весенний период) для некоторых из пользователей удалось решить арендой выделенных GPRS-каналов и радио-ethernet каналов.
guest_20040621Imho на три: workflow + docflow + processing.
На самом деле - больше, так как есть еще собственная база у каждого клиента и приложение, которые однозначно придется переписывать.
guest_20040621останется только ЭЦП, что существенно проще, чем писать все заново. Расширение пула решает только две проблемы, остальные четыре остаются. Кроме ЭЦП остро стоит проблема версионности и разделения на несколько более мелких систем.

BULK INSERT тынц , например
Спасибо, гляну.

Что сразу бросилось в глаза: " разработанная на основе Рацио-нального унифицированного процесса создания программного обеспечения (Rational Unified Process - RUP) компа-нии IBM."

PS: Подумал - почему uml2 ?, решил сходить на просто www.uml.ru гыы...

guest_20040621> около полутора миллионов рублей в год

Imho маловато. Я бы предположил необходимость на порядок бОльшего ФОТ + отдельно затраты на оборудование.
ФОТ сюда не входит. Но из этой суммы на этот год уже некоторая часть забронирована на приобретение лицензий - с недавних пор начальство решило таки приобрести легальное ПО для всех пользователей, за что от меня им огромное мерси, так как одной проблемой стало меньше :)

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

guest_20040621Т. е. на самом деле задач чуть больше, чем перечислено в первом сообщении. ;) Ну, я про клиентское ПО пока молчу - с описанием модели серверной части определиться бы до конца. Предполагаю поставить у них (клиентов) MS SQL Server 2005 Express Edition - все, что ему надо делать - разобрать принятые документы в структуру, удобную для отображения программой, а после редактирования - собрать обратно. То есть та задача, которой сейчас занимается основной сервер.

guest_20040621imho есть смысл переписать все заново, а не конструировать костыли к работающей системе. Все в буквальном смысле слова, начиная с инфраструктуры. С одной стороны, интересная задача, с другой - в бюджет imho ну никак не вписывается.Именно это я пытаюсь сделать.