Каков лучший способ синхронизировать данные между отделенными системами?

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

5
задан JohnIdol 15 December 2008 в 20:06
поделиться

5 ответов

Эта проблема была решена EAI (Интеграция прикладных систем предприятия) поставщики как Tibco и webMethods (теперь часть Software AG). Я никогда не использовал Tibco прежде, но я использовал webMethods для решения подобных проблем, таким образом, я просто сфокусируюсь на webmethods. Например, на предприятии, данные о сотрудниках могли находиться и в Active Directory и в PeopleSoft. webMethods мог использоваться, чтобы гарантировать, что изменения, дополнения, удаляют в одной системе (приложение), будет отражен в другом в режиме реального времени. В некоторой другой организации данные о сотрудниках могли также быть в базе данных Oracle или SQL Server. Снова, не проблема. Эти инструменты EAI как webMethods могут говорить с большим разнообразием бэкендов. webMethods не ограничен единственным источником и единой целью, но потому что он имеет публикование - подписывают архитектуру, данные из единственного источника могут течь к нескольким заинтересованным целям, кто подписывается на особую информацию. Гарантируемая доставка и может, другие функции могут быть найдены в этих продуктах. Назад к примеру сотрудника, в конечном счете если Вы делаете его правильно, в любой момент времени, все системы и приложения на предприятии могут содержать ту же информацию о сотрудниках без любого несоответствия.

Таким образом вместо того, чтобы делать программирование в C# или Java, Вы будете делать программирование webMethods, которое очень похоже 4GL язык. Я называю это программированием, потому что существует все еще включенная логика, цикл, если затем еще, ответвление, переменные, пакеты, и т.д. но это очень процедурно-ориентировано, т.е. никакое понятие ООП вообще.

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

Недостаток является этим инструментом стоимостью большим количеством денег. Компании часто имеют долгосрочную стратегию прежде, чем вложить капитал в эти инструменты.

2
ответ дан 13 December 2019 в 19:38
поделиться

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

  1. OpenESB
  2. Мул
  3. Apache ServiceMix
  4. Camel Apache

Моим фаворитом является OpenESB, я знаю это лучше всего, это имеет полный IDE (Netbeans), дополнительную поддержку от крупного поставщика и огромной суммы дополнительных компонентов. Для его простоты и эффективности я затем люблю Camel Apache, но можно попробовать некоторых из тех и решить, какой работает лучше на Вас. Затем можно даже решить купить услуги по поддержке для всех тех.

4
ответ дан 13 December 2019 в 19:38
поделиться

Мы делаем в значительной степени точно вид-> B-> вещь, которую Вы описываете. Мы первоначально рассмотрели попытку иметь весь A, B, C etcs бывшие коллеги, но это было слишком твердо, таким образом, мы теперь определяем тот как ведущее устройство и другие ведомые устройства. Все еще достаточно легко получить материал от одного ведомого устройства до другого, но через ведущее устройство.

Это все сделано по веб-сервисам - наборы данных идут вверх и вниз от ведомого устройства до ведущего устройства и наоборот, и ведомое устройство выполняет экспорт на себе и называет импорт на ведущем устройстве. Это затем говорит ведущему устройству делать экспорт и выполняет импорт на себе.

Таким образом, код идентичен в каждой системе. Это - только ведомые устройства тот вызов домой.

Экспорт и процессы импорта говорят соответствующим бизнес-объектам делать весь свой список и сохранение материала, так как они уже знают, как инстанцировать и сохранить себя от DataRows.

Это не many-tens-of-transactions-per-second архитектура, но это работает и может достигнуть почти оперативной синхронизации.

Мы не изменили к лучшему уникальность Источника/Идентификатора, между прочим :)

2
ответ дан 13 December 2019 в 19:38
поделиться

Это чрезвычайно упрощено, если Вы присваиваете каждой информации GUID. Если необходимо отслеживать источник и другие идентификаторы, это прекрасно, но информация shuold всегда перемещается с ее присвоенным GUID.

Когда машина видит, что информация снова, будет видеть GUID и связывать его с существующими данными, и затем можно решить, что сделать. Но Вы уже знаете, что это - та же часть данных - просто лучше переместился.

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

Это - одна из больших причин, GUID были созданы.

- Adam

2
ответ дан 13 December 2019 в 19:38
поделиться

Если нет некоторое определенное ограничение в проектировании системы, предотвращающем это, я предложил бы факторизовать общую/с обеспечением совместного доступа информацию в отдельный DB, на который другие два могут или сослаться или просто копировать локально. Затем Вам не нужен ключ двойного элемента, ни любой разрабатывает хитрое изобретение ESB...

1
ответ дан 13 December 2019 в 19:38
поделиться
Другие вопросы по тегам:

Похожие вопросы: