skeptik
1) В пакетном режиме это не работает, потому что "довводить параметры вручную" некому. Соответственно любых процессов, которые должны проистекать без непосредственного участия пользователя не работает.
это работает и в пакетном режиме но если передатчик настроен на другую волну то требовать взаимопонимания просто нелогично никто никого не слышит насчет того что хочу то не знаю чего комментарии уже были извиняюсь за отсутствие знаков препинания но это тот самый случай когда они ни к чему.

skeptik2) Юзабилити близкая к никакой - причем чем больше параметров, тем все хуже. Посуществу получается пошаговый ввод данных а-ля мастер, только хрен вернешся к предыдушему шагу (во всяком случае без потери данных введенных на следующем), не гарантировано единство стиля интерфейса и т.д.
см.п1

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

skeptik
4) Усложняется создание сервисов - от них требуется очень серьезная проверка параметров, да еще интерфейс для их доопределения, да еще желательно с удобствами ... С одной стороны, это конечно в любом случае полезно, но с другой - это существенно повышает себестоимость написания сервисов ...
Проверка параметров требуется всегда не создавайте приложений которые работаю от балды создавайте разумные приложения.

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

p.s. знаки препинания расставьте самостоятельно чтобы не так было сложно я немного на предложения разделил хороший пример общения несогласованных сервисов.

ыiscrafmэто работает и в пакетном режиме
В приведенном примере и объяснении сервис недополучив параметры запрашивал из у пользователя через GUI. Где будут запрашиваться недостающие/некорректные параметры при отсутствии возможности обращения к пользователю?

нигде естественно!
Нет параметров, нет сервиса.
Нет мартини, нет вечеринки.
Нет денег, нет товара.
и т.д.

p.s. попробуйте где угодно, на чем угодно написать функцию с параметрами, чем сервис по сути и является, и вызывать ее без параметров. А потом возвращаемое значение у функции сделайте типа Boolean, а верните строку "TRUE". Это то, о чем идет речь почти две страницы и никак не дойдет.

skeptik,
на предыдущих страницах показано как "без существенных доработок" объединяется. Пойдем по спирали?

p.s. пустой треп просто достал.

skeptik- Вы утверждали что SOA (особенно в вашей реализации) позволяет легко связывать между собой [разработанные независимо] сервисы без их доработки, в отличии от архитектуры 1C, например.

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

skeptik,

то, что для вызова функции требуется передать ей необходимые параметры нет смысла обсуждать, это ясно и без обсуждений. А вот насчет "цены решения вопроса" Вам еще один небольшой пример... есть функция, которая решает определенную задачу и используется во многих модулях. Цена использования и поддержки показана в ролике (FLASH. ~200K).