iscrafm а как же работает? Чуть выше приведены принципы сервисов, они многое Вам объяснят, в том числе и эту, кажущуюся Вам нереальной, особенность. Особенно внимательно прочитайте о "черных ящиках", интерфейсах, "слабой связи".

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

Рассмотрим пример:
Один сервис реализует бизнес-процесс хранения товаров на складе, другой бизнес-процесс отгрузки товаров покупателю, третий бизнес-процесс приема товаров у поставщика.
К сожалению эти три сервиса были разработаны независимо и имеют место следующие обстоятельства:
1) Разработчики сервиса приема товаров у поставщика Они предусмотрели регистрацию количества товара в двух независимых единицах измерения (например катушках и метрах). К сожалению, со скоропортящимся товаром разработчики не сталкивались и ввода (и какой либо иной работы) со сроками годности не предусмотрели. Они предполагали что коды товаров симовольные длиной до 20 символов и не обязательно уникальные.
2) Разработчики сервиса хранения предусмотрели работу со скооропортящимся товаром и соответсвенно предусмотрели такой параметр как срок годности. Предусмотрели они и работу с несколькими единицами измерения. К сожалению они не предусмотрели что единицы могут быть независимыми, поэтому информация о количестве всегда приводится к количеству в базовой единице измерения. Также они предполагали, что коды товаров симольные, длинной строго 8 символов и обязательно уникальные.
3) Разработчики сервиса отгрузки товаров предусмотрели конроль наличия товара при отгрузке в двух независимых единицах измерения, а также исходили из предположения что коды товаров обязательно числовые, длиной до 20 разрядов и уникальные.

Ну и как легко это будет заставить работать вместе, независмо от того, с помощью каких именно интерфейсов эти три компонента должны взаимодействовать между собой? Как поможет общая шина обеспечить их совместную работу если они рассогласованы на уровне модели предметной области? Чем поможет концепция "черного ящика" - если один черный ящик не способен коорректно обрабатывать информацию постуающую от другого и в свою очередь выдать результат корректный с точки зрения следующего?

iscrafm
чуть выше есть краткое разъяснение по СОА. Интерфейс сервиса определяет требуемые ему параметры , выполняет свою работу и возвращает результат.


Что делать если у Вас не можете предоставить сервису требуемых им параметров потому что предыдущий в цепочке сервис такую информацию не подготовил вообще или полготовил некорректно? Если эти сервисы разработаны без согласования интерфейсов ДО начала их разработки (в крайнем случае в процессе) так оно и будет.
Сервисы по сравнению с другими методами интеграции ничего нового для решения этой проблемы не добавляют, а ведь именно она и является основной при интеграции/объединении в одно приложение независмо разработанных компонентов.

iscrafmskeptik,
на демагогию больше похож приведенный Вами пример, сорри.
Хотя в нем нет ничего не решаемого простым способом и он конечно же будет работать.

Я привел Вам конкреный пример, более того он хоть и не из жизни, но вполне "по мотивам". Жду от Вас конкретного ответа как Вы будете решать проблему "простым способом" не внося изменений в сами сервисы и чем Вам поможет в решении этой проблемы общая шина.
Итак простой способ "в студию".

iscrafmskeptik,
я уже устал, честно, клепать ролики.


Колхоз - дело добровольное (с) ;-) Впрочем ролик нагляден - спасибо.

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


Подход занятный, но не без недостатков. Очевидные минусы этого подхода:
1) В пакетном режиме это не работает, потому что "довводить параметры вручную" некому. Соответственно любых процессов, которые должны проистекать без непосредственного участия пользователя не работает.
2) Юзабилити близкая к никакой - причем чем больше параметров, тем все хуже. Посуществу получается пошаговый ввод данных а-ля мастер, только хрен вернешся к предыдушему шагу (во всяком случае без потери данных введенных на следующем), не гарантировано единство стиля интерфейса и т.д.
3) В значительной части случаев это будет означать многократный ввод одних и тех-же данных в разных формах, что с одной стороны нерационально, а с другой строны есть лазейки для ввода несогласованных данных. В приведенном мной примере с разными ограничениями на кодировку товара у разных сервисов в цепочке, это бы означало необходимость перебивать заново коды товаров (или по крайней мере их часть) на каждом этапе со всеми вытекающими. При действительно массовом вводе это смерный приговор сервисному Франкельштейну с наложенной в местах соединения шиной.
4) Усложняется создание сервисов - от них требуется очень серьезная проверка параметров, да еще интерфейс для их доопределения, да еще желательно с удобствами ... С одной стороны, это конечно в любом случае полезно, но с другой - это существенно повышает себестоимость написания сервисов ...

Кстати, на 1С платформе внешне похожую технологию внедрить можно - просто дергаете вызовы объектов из другой конфигурации по COM. То есть из технологичсеких соображений можно, а практически из экономических скорее всего не выйдет - потому как скорее всего не окупится, во всяком случае в кратко и среднесрочной перспективе.