Есть n-ое количество территориальных узлов связанных плохими каналами связи. У каждого узла есть своя операционная БД. Над ними стоит центральный узел, который их координирует, контролирует и получает информацию в общую БД. БД узлов часть информации получают сверху, часть из своей аппаратуры. Центральная БД не должна знать все происходящее в низовых БД(часть информации наверху ненужна, а каналы плохие). Если узлу нужна информация другого узла - он обращается к нему напрямую, минуя центральную базу.
Четкой структуры обмена нет. Данные могут быть нужны произвольные, частично расчетные или суммарные. Центральная база не принимает часть информации узлов в нормальном состоянии, но может ее запросить по требованию пользователя. Аналогично, узлы могут запрашивать обновление НСИ и произвольную информацию от других узлов.
Также требуется удаленное управление аппаратурой узлов синхронно с ситуацией на остальных.

Насколько я понял, мне нужно изучать распределенные приложения. А вот что именно, в какой последовательности? Посоветуйте, пожалуйста, литературу.

P.S. Пока нет понимания какие технологии нужны и что они из себя представляют. У меня большой опыт в клиент-сервере, но тут задачка явно далеко выходит за его рамки.

Это система, которую надо сделать. Задумка пока у начальства в очень общих чертах. Известно, что примерно также функционирует система РЖД, только у них она еще сложнее. Там существует несколько десятков тысяч низовых узлов(станции) , затем уровень отделения со своей БД/спецификой, уровень дороги, уровень министерства. Существует она лет 30 минимум, еще на советских технологиях впервые запущена.
Понятно, что Москва неспособна держать обмен всего пространства через себя или накапливать всю доступную информацию. Узлы должны быть способны запрашивать информацию у другого узла напрямую или с подсказкой из вышележащих уровней. Вышележащие узлы могут заказывать отчеты у нижележащих, чтобы потом свести их в единое целое.
Уровни станций/отделений не только работают с чистой информацией, но и могут выдавать команды управления автоматическим устройствам, что также надо фиксировать.

miksoftУ нас подобная схема работает без всяких распределенных приложений (хотя, конечно, количество узлов несравнимо меньше РЖД).
А вы не подскажете, какие конкретно технологии используете для выборочной репликации?

miksoft
Те репликации, которые используют стандартные механизмы СУБД (Oracle), реплицируют либо целиком таблицы, либо выборочно поля из таблицы. Фильтрации по записям нет.
Тот вид репликации, который выполнятется PL/SQL-процедурой, фактически выполняет запрос вида INSERT destination_table SELECT ... FROM sourse_table WHERE ... . Т.е. необходимые условия просто пишутся в секции WHERE.
Тогда штатная не устраивает. Количество информации крупного узла в сутки выражается в гигабайтах, но подавляющая часть вне узла никому ненужна. Да и остальная часть может быть обработана другим узлом и отброшена. Узел сообщает о возрастании нагрузки из-за наступления вечера, к ночи вечерние данные устаревают и отбрасываются из-за падения нагрузки. Город спит. На ночь свой обмен, с утра по новой.
mcureenab, спасибо. Почитаю.