Имхо задача высосана из пальца.
Тут понимаешь стараешся объединять зоопарки в одну клетку, а некоторые люди специально их строят :).
Непротиворечивое разделение на модули очень трудно реализовать даже на логическом уровне, тем более на физическом.
Некоторые вопросы:
1. Общие справочники и кто и когда их будет заполнять (читай в какой базюльке), что делать при передаче функций ведения из одного отдела (читай базюльке) в другой.
2. Некоторые модули волевым решением очкастых аналитегов разведенные по разным базам в один прекрасный момент захотят слиться в орг.. тьфу жить в одной базе. Типичный пример - учет товарной себестоимости и складские операции. Что делать бум?
3. Архитектура должна поддерживать проверку на валидность, сквозную для нескольких модулей. К примеру при выпуске расходной накладной (простановке галке - "Грузить", Учете - кто на что горазд, тот так и называет) система должна слазить:
а. В модуль Финансы и спросить - скоко клиент на бобов должен? Можно грузить аль нет ишшо? Можно? Ну спасибо.
б. В складской модуль - если товары для меня? Есть? Давай млин резервируй! Чо? Для кого резервировать? Это не все равно? Нет? А почему? Нужно в резерв поставить? Ну давай это я - расходная накладная из модуля Продажи? Чо ждать пять минут? Почему? Нужно еще по 10 модулям слазить и кое че проверить.. мля жду. Не можешь зарезервировать - в модуле Товары нашелся документик который товар вот-вот спишет как потерянный ? А чо сразу то не сказал? А это ты - очередная заглушка которую потом честно поправят - ну превед превед, резервируй что можешь и скажи мне - пойду в Покупки.
с. Покупки - Эй народ мне тут товар нужно грузить через неделю, а на складе нет. Когда появицо? Через 10 минут приходить? А чо так долго? А ... и тебе тоже нужно слазить в финансы и посмотреть когда оплатили поставщику иль нет, потом в Логистику - посмотреть когда сможет доставить, потом куда? В продажи то зачем? Ааа.. посмотреть есть ли резервы от моих соседей? А может я сам? Что значит интерфейсов нет - не знаю что ли как? Ну ладно сам посмотри и доложи........ Чо - не получится чтоли зарезервировать? Ну ладно пойду ругнуть юзерю если еще домой не ушел.


Вощем резюме - в такой постановке не взлетит

ПолковникАга,

Грусно, слышать о вашем бардаке, сочуствую.

Вы про SOA что нить слышали? Про интеграцию несвязанных между собой систем посредством сервисов? Нет? Мне вас жаль.

Сам по себе порой слезки лью.
Про SOA краем уха все ж таки слышал. Использую мало-мало: ECOD, система мобильной торговли, интернет-магазин,с несколькими поставщиками есть взаимодействие. Мало конечно, недорос еще до уровня мегаSOAинтегратора.
Посему считаю, что строить систему посредством расленения целостного продукта на связанные посредством механизма обмена сообщениями модули - бред. Еще ни в одной реализации не видел абсолютно надежного механизма (про прозрачность в реализации для для разработчика вообще молчу) откатывания транзакций даже между двумя системами, куда может привести взаимодействие между десятком модулей, вызванное к примеру учетом счета - трудно даже представить.
Внимаю советам мудрого Полковника, да снизойдет на него благословение OASIS.

iscrafm
что такое SOA, как арихитектура?
1. все функции системы определены как самодостаточные сервисы, выполняющие ту или иную бизнес-задачу
2. все сервисы связываются между собой в момент исполнения
3. любой сервис для его потребителей - черный ящик, который принимает определенные параметры и реализует конкретный функционал, возможно возвращает конкретный результат
4. любой сервис можно использовать как автономно, так и в связке с другими сервисами, многократно
5. все сервисы "нанизываются" на единый каркас - шину, которая поддерживает их "горячую" замену при необходимости, простое внесение изменений в систему, легкое сопровождение.
6... и т.д. и т.п.

Это - архитектура. А BizTalk просто одна из реализаций принципов SOA, не более. BizTalk действительно ТС не нужен, зачем ему дополнительные головные боли. Но BizTalk и иже с ним - не синонимы SOA. Сама SOA, как архитектура, наоборот избавляет от головной боли.

Не приведете ли конкретный пример реализации системы чуть выше уровня "считаем продажи и склад"? Если каждый из сервисов будет крутиться на своей базе и общаться посредством SOAP через HTTP - дополнительный плюс SOA и Полковнику. Если опишите механизм, откатывающий транзакции в 20 базах при ошибке проведения в 21 (чур токо несложный и чтобы время блокировки ) - с меня бутылка 12 летнего коньяка или виски на выбор.
Могу облегчить жизнь и выкатить совсем несложную постановку:
Финансы - серверв и база в Германии. 5 баз (гы гы гы) и 100 сервисов.
Склад - сервер и база в Кукуево. 20 сервисов на одной базе.
Бухгалтерия, Продажи, покупки - сервер и база в Москве. 3 базы - покупки, продажи, финансы и куча сервисов.
Что делаем - учитываем расходную накладную и счет.
По условиям игры нужно провести реализацию в русской бухгалтерии и в буржуйских финансах.
Также нужно рассчитать себестоиомость продаж и провести по финансам и разумеется российской бухгалтерии. Разумеется нужно отразить продажу и в базе продаж. Правила игры таковы что баланс клиента проверяется в буржуйских финансах. Наличие товара - на складе в Кукуево. Да и еще себестоимость продаж в базе финансов должна разложиться по составляющим - прямая от поставщика, все виды товарных издержек (вводятся в базе Покупки) ну и до кучи добавим нетоварную в ввиде скажем...процентов представителю покупателя, которые лежат в модуле Продажи.
Улеглось в голове?
Продолжаем...
Поскольку у нас сервисы уж совсем черные ящики, то о логике поведения других сервисов, а тем более их реализации не имеют ни малейшего понятия. Вполне возможна ситуация множественных вызовов, продажи->финансы->продажи->склад->финансы.
Как поддерживать транзакционную целостность при условии минимального времени блокировки записей?
Как избежать бесконеченого цикла?
Как киллять зависшие сессии (в середине транзакции умер сервис в Кукуево) ?

Господа, мне кажется Вы пытаетесь написать мегауниверсальную распределенную базу данных

Vika VinnerАгаНе приведете ли конкретный пример реализации системы чуть выше уровня "считаем продажи и склад"? Если каждый из сервисов будет крутиться на своей базе и общаться посредством SOAP через HTTP - дополнительный плюс SOA и Полковнику. Если опишите механизм, откатывающий транзакции в 20 базах при ошибке проведения в 21 (чур токо несложный и чтобы время блокировки ) - с меня бутылка 12 летнего коньяка или виски на выбор.
Коллега - Ваша задачка как раз решается BizTalk сервером вполне успешно... Жаль что я не пью...
Действительно жаль :). Ткните плиз носом в реализацию на Бизтоке системы чуть выше уровня "продажи и склад". Ну хотя бы сравнимую с MS Dynamics NAV или My Sap.