Услуги по обмену данными?

Question

Изобразите организацию с множеством отделов и систем, многие из которых должны обмениваться данными. Например, один модуль/система отвечает за обновление данных клиента, но многие отделы/системы должны иметь возможность читать и связывать данные клиента с собственными данными. В такой ситуации, как вы оцениваете использование веб-сервисов для совместного использования этих основных бизнес-данных в нескольких системах?

Кажется, есть несколько моделей использования, чтобы рассмотреть:

1. Применение для поиска одной записи - не реальные проблемы здесь. При переключении с других механизмов (например, дублировании данных по нескольким базам данных и затем использовании запросов базы данных для извлечения) на веб-службы может быть небольшое ухудшение производительности, но это может быть приемлемо во многих случаях.
2. Приложение, отображающее таблицу данных, в которой источник данных для столбцов охватывает несколько баз данных. Например, показывая список имен клиентов вместе с их заказами. Если оба находятся в одном источнике данных, это легко развить, а производительность будет быстрой. Если имена клиентов вытаскиваются из базы данных CRM, а информация о заказе вытягивается с использованием веб-службы системы заказов, то разработка сложнее, потому что данные должны быть объединены, а выполнение замедляется, потому что средний уровень имеет две (или более) операции поиска данных, а затем должен пересекать более одного набора данных.
3. Приложение для поиска данных, в которых критерии поиска охватывают несколько систем. Если система не может присоединиться к элементам данных и указать все предикаты и порядок сортировки в одном запросе, это становится очень трудным для разработки и очень медленным для выполнения.

Обратите внимание, что каждая из этих моделей использования пытается использовать веб-службы для извлечения данных в рамках одной организации/сети. Могут ли быть созданы веб-службы в соответствии с каждой из этих моделей использования?

Answer 1

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

Архитектурные аспекты рассмотреть следующие вопросы:

• данных Архитектура (бизнес собственность, безопасность, управление и так далее).
• Качество данных - это подходящий уровень для потребляющих приложений?
• Как вы будете синхронизировать связанные данные (в связанных системах)?
• Случай использования: транзакция (OLTP) против аналитического (OLAP).

вещей необходимо учитывать при интеграции с другой системой:

• Что случай использования: TRANSACTIONAL (OLTP) или Analytical (OLAP)?
• Сколько запросов мы говорим и когда они происходят и т. Д.?
• Насколько сложными могут быть запросы, которые будут обслуживать эти запросы?
• Точно Насколько актуальны данные?

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

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

Предполагая, что вы делаете ETL данные в новый репозиторий, источник которого является авторитетным? Возможно, несколько приложений ETL-данных в центральный Data Mart или Data Warehouse, где эти данные интегрированы, и это становится «источником истины».

В заключение - работа с данными (как логически, так и физически) очень похожа на объектно-ориентированное программирование/проектирование: многие основные принципы (например, SOLID) легко применяются.