А у нас основной вопрос репликации ("кто же папа?" :) ), по возможности, решается архитектурно, протоколом взаимодействия:

1. Пользователь ресурса --Я ХОЧУ--> Владелец ресурса
2. Пользователь ресурса <--Я ДАЮ/Я НЕ ДАЮ-- Владелец ресурса

Ну и естественно, владельцы по возможности локализованы около своих ресурсов. :)

---
iscrafm
ТРАНЗИТ связывается с провайдером соответствующего сервиса на удаленном App Server и общается с ним на том языке, который ему наиболее близок, без дополнительных преобразований. Если суть реплики заключается в обновлении БД, то зачем ее преобразовывать в XML-конвертик, отправлять, затем удаленный провайдер принимает конверт, преобразовывает в SQL и исполняет скрипт в своей СУБД. Просто лишние действия исключаются.
Это все, наверняка, и модульную расширяемую структуру имеет? Для какого-то нового типа адресатов в схеме обменов можно новый какой-то... плагин? развернуть?

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

2...
Ну не настолько драматично (бывают же ошибки кодирования и администрирования обменивающихся систем, на которые накладываются ошибки пользователя), но принцип, кажется понял: вообще таких ситуаций не допускать. Правильно понял?

А я вот как-то забыл кое кому ограничить доступ к определенной секции внутри реестра однородных документов. И этот кое-кто, при помощи пакетной обработки сменил статус как у доков нужной секции, так и у пары штук из ненужной. А та пара штук была недозаполнена. И пошла по схеме репликации... :)

Хотя, в общем, конечно, стараемся исключать простреливание ноги не только в приемнике, но и в источнике тоже.