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.

Vika Vinner
на мой - дает, причем значительные. Увеличение скорости при одновременном снижении стоимости как разработки, так и последующего сопровождения - в разы. И это не взгляд или мнение со стороны, это - проза жизни.

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

Vika Vinner
Давайте иа попробую чуть чуть осветить мистерию BizTalk и SOA архитектуры. Представьте себе дорогу. По ней едут все - кто то на велосипеде, некоторые на мотоцикле, многие на машинах, есть еще грузовики и авторбусы, а вот еще и самолет приземлился - за неимением ВПП - прямо на шоссе Задача - как всю эту разношерстную массу двигающихся {пусть даже в одном направлении} объектов научить правилам движения? И тем более обеспечить связью друг с другом? Можно ограничить скорость и заставить всех ехать с одинаковой скоростью... Только для самолета будет трудновато перейти на скорость велосипеда... А велосипедисту крутить педали до 255 миль в час... Что делает Biztalk? Позволяет использовать дорогу как средство передачи сообщений. То есть самолет съезжающий с дороги может всем послать сообщение о повороте направо - и все его поймут. Даже те кто его никогда не видел... как то так...

Спасибо за аналогию. Не уверен что удачная, Бизток все же больше смахивает на поворотники.

Vika VinnerПоэтому я и сторонник монолитных решений. Но к сожалению такое случается нечасто. Камень с велосипеда в самолет недокинуть... это работа архитектора - четко понимать что делают каждая из конечных модулей системы. В Enterprise задачи различные - бизнесы сливаются (объединяются) разливаются - переоборудуются... и ввиду этого чаще всего приходится учить различные системы договариваться между собой. Вот здесь мы и переводим стрелки в BizTalk - ну или SOA как обще-потребительский термин. Я сама Системный Аналитик - это к тому что сама BizTalk использую как пользователь.

Ключевое слово "учить". Мера как понимаю вынужденная :). Зоопарк-с.. Стоимость обучения интеграции конечного продукта посредстов SOA в процентах к стоимости самого продукта можете озвучить, а также охватываемый интеграцией процент функционала?
Добровольно себе такой устроите?
На вопрос интегрируетесь Вы посредством средств разработки того же Siebal или Nav или же используете обращение к базе данных ответа так и не услышал :).

iscrafm
каким образом ткнуть, уточните.
вот несколько систем:




.. и сервисы и распределенных БД достаточно.
здесь описание процесса создания одной
уточните каким образом ткнуть. Или думаете все на ходу придумывается?.
Спасибо, с удовольствием прочитаю. Надеюсь технические детали в плане реализации распределенных транзакций при интенсивном обращении сервисов друг к другу также не обойдены стороной.

Vika Vinner
Коллега ... Вы от меня требуете невозможного.... Для представления нашей архитектуры даже в общем виде ... нужна будет отдельная база данных... А вот к стоимости пожалуй придется обратиться... Мы имеем дело с миллионами долларов оборота в час. Стоимость простоя системы исчисляется сотнями тысяч ... в минуту. Экономический коеффициент ROI на основе MS SQL Server 2008 составляет всего 3 года - общий бюджет порядка 150 млн в год. Все делается сейчас на MS платформе - ключевые серверы - MS BizTalk и MS SharePoint - количество пользователей OLTP - 30,000 .. OLAP - 1,000 Стоимость лицензий ... порядка 4 млн - стоимость хардвер порядка 10 млн. все остальное - работа.
Когда IBM приходил с WebSphere и DB2 - одни лицензии увеличились до 10 млн. А о разработке ... ну в общем много запросили...

Спасибо, примерно такое отношение к стоимости работы к лицензиям я и ожидал услышать. Срочно берите на работу айскрима - он Вам понизит стоимость владения на порядок :).

Немного офф - как то совместно с экспертами в области ряда программных продуктов ERP (каждый работал с несколькими системами) рисовали графики роста стоимости внедрения и поддержки в зависимости от сложности проекта. За меру сложности проекта взяли как ни странно количество таблиц в первой интерпретации и реализуемый функционал во второй, оценки субъективные приводились на основе реальных проектов и частично воплей - "А вот я в своей проге за час накидаю!!!". В забеге участвовали ряд самописок, 1С еще 7-мой версии, Axapta, Navision и SAP - решения вообщем-то монолитные. Не буду оглашать всех деталей, расскажу лишь об одном выводе с которым согласились практически все участники. Вывод вполне очевидный - по мере роста сложности проекта удобный редактор кода, используемый язык программирования, средства для автоматического рисования форм и отчетов - вся внешняя мишура уходит на второй план. На первое место парадигма построения информационной системы - это и технические ограничения, заложеные вендором - к примеру реализация доступа к данным таблицы только через методы соотвествующего класса (в той же Аксапте или Навижне к примеру), а также методология разработки продукта на платформе - это и реализация фунционала по модульной схеме с выставлением соотвествущих соотвествующих интерфейсов для общения с другими модулями и реализация учета документов по схеме документ-журнал-книга... Ну и ожидалось, стоимость сопровождения и развития дешевых (лицензии не требуются или достаточно дешевы) систем оказалась выше, нежели дорогих.

К чему я распинаюсь? Да все к тому, что разделение ЦЕЛОСТНОГО продукта (не ряда программных продуктов, в совокупности соотвляющих ИТ-инфраструктуру предприятия) на разные сервера и базы данных (см. первые посты ТС - модуль заведения клиентов и модуль продаж в разных базах) должно быть оправдано. Чем же можно оправдать?

Увеличится общее быстродействие?
Сомнительно. Думаю распределенные транзакции не добавят скорости в работе, если же без них можно обойтись - значит и продукт смело можно распилить на совершенно независимые составляющие.

Увеличиться общая отказоустойчивость?
X серверов падают в среднем в X раз чаще, нежели один.

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


Агу - здесь взрослые люди ведут разговор. Марш спать в постель.