chuk_and_gek,

Не сказал бы, что будет большая разница.

Capture, его управляющие таблицы и CD-таблицы лучше в этом случае размещать в DB2 for z/OS.
Apply и его управляющие таблицы - соответственно на целевом сервере (Windows).
На Windows каталогизируется (создается алиас) для БД в z/OS, это три команды (CATALOG TCPIP NODE, CATALOG DATABASE, CATALG DCS DATABASE).
Выполняется Bind пакетов apply с сервера windows на сервер в z/OS.
Далее все настраивается с Windows-сервера или через DB2 Replication Center, или скриптами через командную строку (asncmd).
Смысла делать Federated-узел не вижу, ИМХО лишнее звено.

PS: Очень рекомендую к использованию Q-репликации.
Плюсы:
- минимальные задержки по доставке данных.
- нет CD-таблиц.
- работает на "плохих" каналах.
- есть веб-интерфейс (IBM Q replication Dashboard) для мониторинга и управления.

Минусы:
- нужны знания по настройке IBM WebSphere MQ.

chuk_and_gek,

Сегодня еще раз внимательно прочитал заголовок темы.
Я его прочитал так, что есть желание использовать никнейм ДЛЯ репликации, поэтому мой первый ответ написан именно в этом ключе.
Однако, вопрос стоит об использовании никнеймов(federation) ВМЕСТО репликации.
Прошу прощения за невнимательность и дополняю свой ответ.

Репликации обеспечивают "почти" (+/- задержка на процесс репликации) синхронную копию данных на локальном сервере.
При этом все локальные запросы работают с локальными (реплицированными) таблицами.

Если использовать технологию "Federation", это дает возможность в локальной базе "видеть" таблицы "чужой" базы и использовать их в запросах. Однако, при этом фактически происходит выполнение запросов на удаленном сервере.
Т.е. если удаленный сервер загружен работой или недоступен, то и выполнение запросов к его таблицам будет затруднено или невозможно.

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

Выбор технологии для конкретного случая будет зависеть от потребностей приложения.