Архитектура промежуточного слоя. Агрегация сущностей. Репликация данных.

Архитектура промежуточного слоя.

С точки зрения архитектуры интеграционного решения можно выделить три базовых шаблона промежуточного слоя:

1. агрегация сущностей (Entity Aggregation);

2. интеграция процессов (Process Integration);

3. интеграция, ориентированная на портал (Portal Integration).

Основные характеристики базовых шаблонов представлены в табл. 3.2.

Агрегация сущностей.

Агрегация сущностей — наиболее доступный, а поэтому и наиболее распространенный вид интеграции.

Цель агрегации сущностей — обеспечить приложениям возможность эффективно использовать данные, распределенные между несколькими репозиториями. Для эффективной работы с данными приложениям необходимо иметь единое согласованное в масштабах организации (отрасли) представление ключевых сущностей (например, таких как «Клиент», «Заказ», «Счет», «Продукт» и т.п.).

Задача осложняется тем, что:

1. корпоративные системы, как правило, используют разные информационные модели для описания одной и той же сущности (например, сущность «сотрудник» по-разному представлена в бухгалтерской и кадровой системах);

2. зачастую существует семантический диссонанс между данными из разных систем. Один и тот же элемент данных из разных систем может представлять разную информацию (например, атрибут NumberOf'DaysRemaining для задачи проекта может содержать только рабочие дни в одном репозитории или включать выходные дни в другом);

3. даже при отсутствии семантических различий возможно несовпадение данных для одного и того же экземпляра сущности (например, адрес одного и того же клиента в системе оформления заказа и адрес в CRM-системе различаются);

4. репозитории могут содержать ошибочные данные;

5. при проведении синхронизации данных между несколькими репозиториями может быть нарушена ссылочная целостность;

6. приложение-потребитель может затребовать данные, хранящиеся в разных репозиториях.

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

Агрегация сущностей вне зависимости от конкретной реализации интеграционного решения включает два основных этапа:

1. определение единой в рамках предприятия модели данных, которая обеспечит унифицированное представление сущностей;

2. установление физических связей между компонентами интеграционного решения.

В разных репозиториях используются разные схемы данных для одной и той же сущности. Задача промежуточного слоя — гармонизировать различия между этими схемами. Промежуточный слой должен:

1. удовлетворять потребностям всех интегрируемых приложений;

2. определять каноническую схему данных для всех сущностей, используемых несколькими приложениями;

3. поддерживать трансформации схем каждого источника данных в каноническую схему данных.

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

Разработка унифицированной схемы данных — одна из наибольших трудностей, присущих данному стилю интеграции. Создание унифицированной (иногда говорят, «канонической») схемы данных (рис. 3.3), удовлетворяющей потребностям нескольких приложений, сопряжено со сложностями как технического, так и политического характера. Если применение такой схемы данных приводит к снижению производительности бизнес-критичного приложения, то руководство компании может настоять на пересмотре интеграционного решения.

Существуют два базовых архитектурных подхода к интеграции информации:

1. репликация данных;

2. федерация информации.

Репликация данных.

Под репликацией данных понимают процесс перемещения данных между двумя или более репозиториями (рис. 3.4).

Репликация — это ориентированная на обработку наборов данных технология преобразования, предназначенная для решения задач миграции, консолидации, создания хранилищ данных. Поскольку процесс перемещения данных подразумевает их извлечение из одного источника, загрузку в целевой репозиторий, а также возможное попутное преобразование, часто используется термин ETL (Extraction Transformation Load).

Технология репликации ориентирована на обработку очень больших объемов данных.

Основными достоинствами репликации являются:

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

2. хорошая масштабируемость решений;

3. наличие четкой методологии интеграции;

4. асинхронный обмен данными;

5. отсутствие необходимости изменений в интегрируемых информационных системах;

6. эффективный доступ к интегрируемым данным за счет отделения приемника от источника;

7. слабая связь между интегрируемыми системами;

8. возможность повторного использования объектов и преобразований (снижает затраты на разработку и поддержку);

9. относительно низкая стоимость;

10. наличие доступных инструментов (программного обеспечения класса middleware).