Уважаемые ALL,
хочу услышать мнение SQL-сообщества о SOA. Проблема достаточно известная, и в блогах можно найти инфу. Но пока, все что мне попадалось, пишут люди, далекие от баз и с умным видом изобретающие велосипеды.
Итак, для простоты, связка "customer-order-operator". В терминах "сервис ориентированной архитектуры", по крайней мере, как я ее понимаю, предполагается 3 независимых сервиса, каждый из которых работает со своей базой.
Как в терминах SOA сохранить целостность данных (удаление заказчика, деактивация оператора и т.д).
Или, может, по определению, подобная архитектура ПОДРАЗУМЕВАЕТ возможные потери целостности?
Если есть линки на обсуждене по теме с участием SQL guru - бросьте, не поленитесь.

Попробую свормулировать по другому.
Нет спора, для WEB-систем, а также для распределенных систем (с репликацией, в частности), СОА это подход. Вопрос лежит несколько в другой плоскости:
Должна ли база данных быть интегральной частью сервиса, или коллектив независимых сервисов общается с единой базой?
Сценарий в случае 2-х независимых сервисов "заказчик" и "заказ"
Один сервис удаляет заказчика, другой добавляет заказ. Понятно, что если база одна, то проблем нет. Либо не удалим заказчика, либо не добавим заказ.
А если система независима, как быть?
1. Использовать AK вместо PK и мириться с возможной потерей связи? При этом не будет понятия "используй OUTER JOIN вместо INNER JOIN", поскольку связывание заказа и заказчика происходит на клиенте?
2. Строить "map tables" на стороне "ко многим", то есть дуплицировать на стороне "заказ" ЧАСТЬ данных из "заказчика", генерить для нее локальный PK и хранить оригинальный PK как "ExrternalID", и использовать новый ключ как FK?
3. В принципе запретить удаления и изменения PK, использовать "logical delete" и мириться с частичными потерями. (То есть, украли номер визы, хозяин сообщил, визу пометили как краденную, но все транзакции на покупку пройдут, до тех пор, пока системы не будут синхронизированы)
4. Богу-богово, кесарю-кесарево? Или мухи - отдельно, котлеты - отдельно?
База данных не является частью сервиса, и точка.

Я понимаю, что реальная жизнь, она из компромиссов, но тем не менее...

Если у меня НЕ будет выбора, то я тоже буду использовать вместе 2 и 3 :-)
Но хотелось бы услышать аргументированные мнения за и против включения баз данных в арчитектуру сервиса.
Как правильно должен уживаться сабж?

Артем, Вы имели в виду
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/dngrfSOAChallenges-EntityAggregation.asp
этот линк?

У меня такое же мнение, но руководство видит проблему иначе. Можно повернуть это как извечный спор между разработчиком аппликаций и разработчиком баз. С моей точки зрения, веб сервис такой же клиент, как и другие, то есть я не вижу никакой разницы между client-server, 3tier и soa с точки зрения базы. У нас тоже распределенная система, о которой так вопят любители сервисов (несколько банков, разнесенных по планете и имеющие ОБЩИЙ портфель заказов), но я даже в этом случае не могу представить себе независимость данных - объединение идет горизонтальное (то есть по FK, BankID), а не по entities (customer, order, etc). Есть репликация, она используется - зачем весь этот огород городить?
ПыСы. Мы, похоже, в одной лодке, а я надеялся, что откликнется какой-нибудь сторонник soa, поддерживающий переход на эту систему именно с точки зрения баз данных.
ПыПыСы. Когда Вы вернетесь с совещания, видимо, я на него пойду, так что задержка возможна

То Темплар
Вот-Вот!!!!
По сути, Вы предлагаете 2PC между разделенными БД. И что я выиграл?
Праздник, оттого, что сказал шефу "А мы теперь работаем в SOA!!!", а на деле, где-то внизу, даже не в моем <SQL> коде,
BEGIN DISTRIBUTED TRANSACTION
....
И мне плевать на ресурсы, которые жрет MTC, SQL Server, чтобы поддерживать эту лабуду?
Не проще, если уж так, положить эту базу где-то "посередке"?

Templar
Сервис транзакций в этом случае позволяет интегрироваться на более высоком уровне абстракции, чем 2PC и, соответственно, охватить большую область применения (и сегмент рынка, соответственно).
А попроще можно? :-) Что такого я выигрываю в бизнесе за счет очевидного проигрыша в скорости и ресурсах?
Я работаю таки с банковскими системами, и мне проще расположить ВСЮ базу в головном банке, и пусть все сервисы туда ходят. Второй вариант - часть даты реплицируется, причем в TransactionalReplication, и, таким образом, не будет необходимость в удаленном доступе. А если уж надо отредактировать, то милости просим в базу хозяина через прокси (linked server)

С межсистемным взаимодействием у меня нет проблем. Это понятно и очевидно. Есть желание (не мое) писать СВОЮ систему как набор таких сервисов (с чем я, в принципе, согласен). И вопрос в том, должна ли быть база данных вынесена за пределы этих сервисов.

ModelR GaryС межсистемным взаимодействием у меня нет проблем. Это понятно и очевидно. Есть желание (не мое) писать СВОЮ систему как набор таких сервисов (с чем я, в принципе, согласен). И вопрос в том, должна ли быть база данных вынесена за пределы этих сервисов.
Свою систему чтобы обеспечить взаимодействие с ней других, заранее не известных систем, или все внутрисистемное взаимодействие? В последнем случае какова цель?

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

Именно эта идея и имеет место быть, то есть разделение баз по тематическим областям для высокоуровневой модульности. Можно сказать, что Вы цитируете нашего СТО.

Артем1
что же выгоднее (для потребителя системы), более надежно защищенная целостность данных (RI в базе) или система, которую можно достаточно быстро адаптировать под новые нужды и требования.

Похоже, заказчику более важно второе. Пишу и понимаю, что, видимо, стронники разделения, по крайней мере, в моем случае, правы. Плюсы начинают перешивать минусы. Но остаются вопросы, скорее, "на добивание".

Aion
Невижу здесь разницы - одна база или несколько. Только если система независима, сервис который принимает "заказ",
должен удостовериться, что есть такой "заказчик" и "проследить" чтобы этот "заказчик" никуда неизчез во время приема "заказа".
Если единая система - у Вас там будет relation между таблицами. Разница только в реализации.
Хотя не принять заказ это роскошь, а удалить заказчика - расточительство :-)

Согласен, пример надуман, но важен принцип. Какова реализация "вместо FK" в случае сервисов? Как защитить от удаления запись с "CustomerID", в то время, как начато добавление заказа, но еще не подтверждено?

Aion
Зачем нужни лишнии map-таблицы и "ExrternalID"? Хранит оригинал и все.

То есть? реплицировать всю таблицу? А где тогда модульность?
Или вместо JOIN по CustomerID сервис должен линковать дату сам?

Aion
Gary
В принципе запретить удаления и изменения PK, использовать "logical delete"

Ммм... здесь все зависит от Вашей бизнес-логике.
Удалять "заказчика" даже если он ничего незаказал не всегда целесообразно.
Так как бывает нужна "история жизни". Но разумного изменения PK я невижу. Чтож это за PK тогда?!

Пример с изменением PK надуман, смотри выше...
Хотя могу привести пример из своей практики. PK заказчика сегментный, из ID филиала и ID заказчика. Эта таблиза реплицируется, поэтому autoincrement не используется. В какой-то момент один из филиалов приказал долго жить, и нужно было "передать" всех клиентов новому филиалу. Выяснилось, что дешевле всего сгенерить новый ключ...

Aion
Gary
и мириться с частичными потерями. (То есть, украли номер визы, хозяин сообщил, визу пометили как краденную, но все транзакции на покупку пройдут, до тех пор, пока системы не будут синхронизированы)

Т.е. синхронизированны? А каким способом Вы это себе представляете?
Как пример, при блокировки карты, оператор посылает запрос на сервис CardBlockService, который в свою очеред должен сделает 2 действия:
1) UPDATE CUSTCARD SET IS_BLOCKED = 1... - заблокировали
2) Послали сообщение через BizTalk/WebSphere MQ/Sonic MQ - другой системе. (при асинхронном взаимодействии)
На "той" стороне: Прочитали сообщение и сделали соответствующие действия.


Вот как раз (1) и (2) я не понимаю. Ведь это
А. Асинхронно
Б. Не в одном transaction context
То есть, в классическом случае, после того, как (1) сделан commit, больше никаких транзакций по визе не пройдет, а в случае с SOA ичего не пройдет ПОСЛЕ ТОГО, КАК ПРИЙДЕТ уведомление.

Aion
А это уже далеко не INSERT INTO ORDERS...

Разумеется :-)
В моем случае это sp ~80KB + асинхронный вызов MQ в стороннюю систему.
И я полностью поддерживаю мысль об этом вызове как сервисе...

<offtop>
Ужажаемый Aion, во второй половине августа я планирую отдохнуть в Юрмале, но с радостью пообщаюсь на SQL-ные темы, в том числе и на эту... Мой мыл igor[псина]tradertools[точка]com, пишите.

AionВ итоге будет наподобие
start) update customer set status = 'прием заказа'
<прием заказа>
если здесь кто-то попытаеться удалить "заказчика", получить отказ ввиду 'приема заказа'
finish) update customer set status = 'заказ принят, статус inactive'
Это идея, несколько замедляет, но лечит мою паранойю.

AionЗачем все? Может и ничего и ненадо реплицировать.
Смотря что необходимо и что пытаетесь достигнут.
Приведу пример: У меня есть n-ое млн. кол-во заказов и мне нужно сделать оперативный
отчет и мониторить его: кто и сколько заказывает сегодня или сегодняшний топ-10.
Самое простое - реплицировать CUSTOMER (ID,NAME) в другую систему (читай - скорость)
С другой стороны - если мне надо будет добавить, например LAST_PAYMENT_DATE из CUSTOMER в этот репорт,
то только сервис будет "сливать" данные для этого репорта из двух источников (читай - достоверенность)
NAME - можно принебречь, а вот когда последний раз заплатили - нужен оригинал.
Безусловно. Какую-то часть даты, часто используемую, можно реплицировать, зарабатывая скорость, а другую получать "на лету".

AionНо варианты и для SOA есть...
http://www-128.ibm.com/developerworks/webservices/library/ws-introwsat/
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwebsrv/html/wsacoord.asp
Таже самая "симуляция классики" как и без SOA.
Но на приктике тогого я неделал.
А я, похоже, скоро займусь :-)
А линки в точку, буду учиться, большое спасибо.

Aion<offtop>
welcome ;-)
Наглость - второе счастье... А куда - адресок то не дали :-))))), даже электронный :-)))))))))))
UPDATE: пиво - ваше, оплата - моя :-))))