Имхо задача высосана из пальца.
Тут понимаешь стараешся объединять зоопарки в одну клетку, а некоторые люди специально их строят :).
Непротиворечивое разделение на модули очень трудно реализовать даже на логическом уровне, тем более на физическом.
Некоторые вопросы:
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.

iscrafmАга,
посмотрите как работает любая система бронирования авиабилетов и т.п. Учасников много, баз тоже. Транзакция - это цепочка вызовов определенных сервисов с определенными параметрами. Транзакция завершается, если все сервисы из этой цепочки выполнят свою функцию и отчитаются об этом.

Я тоже много примеров знаю:). Тот же вопрос - ткните в носом в реализацию на сервисах системы по функционалу сравнимой с MS Dynamics Nav или My Sap.

Повторюсь - разделение целостного продукта на модули, общающиеся посредством SOA на мой вгляд не дает никаких преимуществ.

ПолковникАга,
Я к сожалению конкретной реализацией похвастаться не могу у нас такой практики нет (слышал что IBS что то делал в этой области), но такие задачки от заказчиков сыпятся довольно часто. Не беремся потому что у нас спецов нет, а что бы своего вырастить нужно не меньше года, а то и больше. Есть ощущение, что задачи по интеграции различных систем будут востребованы в ближашее время.
Вы еще одно направление затронули - распределенные системы. Это не сервисно-ориентированные системы - эти системы в основном пишутся на java ee с сервером приложений типа weblogic и ему подобных, где за описанные вами транзакции отвечает менеджер транзакций, могут работать с гетерогенными источниками данных - базами данных разных производителей в одном мега приложении, за соединение с базой отвечает сервер приложений, вся логика ложится на сервер приложений, база только хранит данные.
Много есть интересных вещей, жаль что на все нет времени.

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

Vika VinnerКоллега, Вам знакомо слово Enterprise? Где SAP R/3 - это часть - может быть 30% всего навороченного? там же и PeopleSoft (HR) и Siebel (CRM), и вышеупомянутый Вами NAV... А в основе - самописная система на IBM / COBOL , продажи кстати писались на PowerBuilder 4.0 + SYBASE SQL Server v 90-x Я много бы могла вам порассказать о SOA - мы этим занимаемся без малого 10 лет. BizTalk внедряли еще 2002 - но боюсь ... места и времени не хватит...
С Enterprise к сожалению не знаком....
А Вам как все 10 лет пишется? Всем Biztalk с 2002 сам рулит иль все таки в каждой системе свои шлюзы рисуете с учетом особенностей архитектуры? Вам к Siebel и Nav изнутри удалось прикрутить распределенные транзакции? Боже - Вы девушка моей мечты! (прошу пошлить - обожаю Вику как трудовую единицу).
PS. По предыдущим постам понял что Вы все таки склоняетесь к классической архитектуре построения приложений, а вообще с удовольствием послушал бы про опыт реализации SOA.