Предлагаю участникам осмыслить тему в следющем ключе: при рассмотрении задач интеграции в рамках копоративной системы (пока не будем замахиваться на "межпланетный конгресс", ОК ?) как правило, приходят к тому, что начинают интегрировать системы "каждую с каждой". Как передавать из Бухгалтерии в Склад, из клиент-банк в бухгалтерию и т.д. Понятно, что с ростом числа подсистем в корпоративной системе получится полное безобразие в виде сетевых связей. Т.е. напрашивается вывод, что каждая система должна складывать данные в некое общее "интеграционное хранилище". Где, по мере роста потребностей в интеграции, будут создаваться описания(словари) для каждого уникального объекта: понадобился (впервые) обмен платежными документами - описываем его в этом хранилище. Все последующие обращения за такого рода данными будут осуществляться к уже описанному однажды объекту в этом хранилище, не к приложению в котором данный объект возникает первично. Разделив такое хранилище на уровни (транспорт, трансформация данных, очереди и т.п.) можно получить универсальный "центр объмена" внутри КИС, который позволит уйти от сетевой модели. Как-то я даже схему нарисовал - распределения функций по уровням.

АБ
UDDI близок к описанному хранилищу. Только в нем описываются не объекты, а интерфейсы к каждой системе в формате WSDL. Для каждого интерфейса -- вход, выход, транспорт.
...
BPEL позволяет надстроить еще один уровень абстракции: специфицировать не только отдельные процедуры, но и цепочки вызовов с определенной внутренней логикой

Рассмотрим простую цепочку: оплата услуг оператора связи поступает из сторонней платежной системы (E-port, например или подобной), либо через собственную "карточную" систему он-лайн платежей. Полученный платеж должен поступить как в бухгалтерскую систему, так и в систему учета услуг (биллинг).
Наличие промежуточного хранилища данных при взаимодействии этих трех систем (система оплаты, бухгалтерия, биллинг) может дать, как минимум, следующие преимущества:
- устраняет связь "каждый с каждым", при изменении, к примеру, входного формата платежной системы, изменения потребуются только для "входящего" преобразования и интерфейса, две другие системы продолжают в это время пользоваться ранее описанными "исходящими" интерфейсами;
- аналогичное преимущество получаем при добавлении нового способа оплаты (например, к существующей внешней платежной системе добавили собственную систему он-лайн платежей) - просто добавляем еще один "входящий" интерфейс, помещающий входящие данные о платеже в ту-же очередь данных, биллинг и бухгалтерия продолжают получать данные через ранее описанные интерфейсы;
- ни одна из трех систем не зависит прямо от любой другой (но все зависят от "общей точки" - хранилища), что позволяет, например, вести обработку поступлений в каждой системе в соотвествии с ее требованиями об актуальности данных (или другими требованиями/ограниченями на операции внешнего обмена данными);
На мой взгляд, использование промежуточного хранилища выглядит, как минимум, оправданным. Тем более, что взаимодействующих систем может быть и больше трех.

Использование BPEL(BPMS) в подобных цепочках кажется мне, мягко говоря, излишним. Обработка каждого отдельного платежа не является выделенным шагом бизнес процесса, который имеет смысл постоянно отслеживать. В таких цепочках, контроль ведется на уровне сводных сумм (получили из системы "А" N1 документов на сумму X, разнесено N2 документов на сумму Y) и только в случае несхождения контрольных сумм пойдет подокументная выверка.

Против вебинтерфейсов возражений нет - ничто не мешает иметь, в том числе, и вебинтерфейсы как разновидность транспорта.