В общем, нужен совет.
Ситуация следующая - есть организация, в ней типичные последствия лоскутной автоматизации - около десятка разных баз (включая 1с), единого механизма обмена данными нету - для каждого случая свой. Данные в базах перекрываются и дублируются, но при этом поручится за их непротиворичивость не получается. Избавиться от зоопарка быстро тоже не представляется возможным.
Сейчас в голове крутится мысль создать очередную мега систему аля "читаю-из-dbf-sql-xml-и-пишу-туда-же" с плагинами, присобачить туда же шедулер и хоть как-то упорядочить обмен. Вопрос: а не сталкивался ли кто с такой ситуацией, и, если сталкивался, то как решил? Есть ли готовые приложения для обмена между разнородными системами?

WJПредпочитаю идти в ногу со временем и не рисовать очередную громоздилку. Покупаете (или берете бесплатную) BPMS и решаете сразу обе проблемы: интеграцию зоопарка и упорядочивание работы. А именно: описываете бизнес-процессы (это к упорядочиванию), затем на шаги процесса вешаете формы - композитные приложения, в которых связываете данные разных систем, причем и читаете, и пишете. А куда пишете - можно в существующие приложения (т.е. все работает как раньше, только управляется "из центра"), а можете создать новую БД, в которой храните сводные данные. При этом пользователи на местах имеют единый интерфейс для доступа к разным приложениям, и, по сути дела, вообще не имеют понятия, с какими системами в какой момент работают. К примеру, из CRM системы берете данные заказчика, выставляете ему счет, а все бухгалтерские проводки формируются в учетной бухгалтерской системе. Ну и, усложняя схему, в производственной системе размещаете заказ на производство - и т.д.
На сегодняшний день такой подход уже мало кого удивляет, это наезженная схема. Так что ничего нового...

Что-то мне подсказывает, что навешивать на весь зоопарк веб сервисы чревато весьма
неприятныии последствиями (имел кое-какой опыт), а кроме того что делать, если
софтина, котороая уже хрен его знает сколько лет работает оперирует DBF файлами?
Писать собственный компонент к JBI для доступа к DBF? Или дописывать в каждую софтину
поддержку веб сервисов? Кстати никогда не сталкивались с разными отображением
сложных типов или с их разным описанием в WSDL/XSD? Про скорость и безопасность я
лучше вообще промолчу (как там с массовым внедрением WS-Federation?).
SOA красиво выглядит только на презентациях, а так это редкая задница (особенно если
не выполняется исходный постулат - "все legacy системы предоставляют сервисы").
По хорошему, под SOA, существующую систему надо не адаптировать, а заново
переделывать, а это слишком радикальный вариант. Так что BPMS это не панацея - все
эти красивые диаграмки бизнес процессов ведь надо будет как-то приземлять, а на
нижнем уровне будет тот же зоопарк с избыточными и противоречивыми данными.
Хотя поковыряться на досуге можно...

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

АБservicemix не примеряли?

Неа - OpenESB

АБ Шо делать дальше? АБservicemix не примеряли?
Неа - OpenESB Ну и...?


См. выше. Сервисы и СОА это не волшебная палочка - помимо косяков и велосипедов
самой парадигмы, всю эту красоту придется как-то
приземлять - а там зоопарк, потому и думаю как от него если и не избавиться, то
хотя бы собрать рядышком какую-нибудь сводную БД и в будущем завязываться уже
на нее.

АБ Шо делать дальше?См. выше. Не понял: OpenESB не имеет коннекторов к БД?


Разумеется имеет - есть JBI компоненты, можно заделать свой сервис для работы с БД. Проблема не в этом - она ниже уровнем, в зоопарке различных систем, именно поэтому хочу найти готовый или написать свой агрегатор данных с плагинами, который бы выковыривал данные из разных истчников и сводил в одну базу. Вот и интересуюсь - делал ли кто-нибудь что-то подобное?

АБПолучается похоже на MDM?


Что за зверь? А то гугл постоянно ссылки на какие-то банки выдает....