Крупные предприятия независимо от сферы деятельности имеют десятки, а иногда и сотни внедренных приложений. Данные порождаются в одних информационных системах, но используются повсеместно, а не только в точках порождения. Ручной ввод данных в каждое приложение, в котором они нужны, это довольно трудоемкое, дорогое, а главное - чреватое ошибками и снижающее качество данных решение. Требуется интеграция данных.
Одним из очевидных и наиболее популярных подходов к интеграции данных является их распространение путем передачи из базы данных одного приложения в базу данных другого. Tак как бизнес хочет видеть данные в каждом приложении, участвующем в бизнес-процессах компании, как можно быстрее, обмен информацией реализуется путем передачи небольших порций данных по очередям сообщений (синхронное распространение данных оставим вне рассмотрения, в последнее время оно не является мейнстримом, т.к. привносит с собой сильную связность между информационными системами). Поскольку современные решения класса Enterprise Service Bus (ESB) содержат удобнейшие зачастую декларативно настраиваемые адаптеры к большому количеству СУБД и провайдеров очередей сообщений (Message-oriented Middleware (MOM)), а также поставляются с визуальными редакторами, в разы ускоряющими разработку, то их и выбирают для решения вышеозначенной задачи. В итоге внедрение сервисной шины предприятия воспринимается как реализация асинхронного обмена данными между несколькими источниками, в большинстве своем представляющими собой реляционные базы данных тех или иных корпоративных приложений. Вариантом подхода является вставка данных не непосредственно в базу, а через некие сервисы, предоставляемые системой-приемником, что абстрагирует детали строения ее базы данных от разработчиков интеграции.
Описанный выше подход к интеграции обладает рядом недостатков.
Во-первых, сама по себе избыточность данных - каждое приложение имеет свою копию некоторого общего подмножества данных предприятия (например, основных данных: нормативно-справочная информация, клиенты, поставщики, сотрудники, продукты и услуги и т.д). Растут объемы баз данных каждой вовлеченной в интеграцию корпоративной информационной системы, соответственно требуются большие объемы систем хранения данных, растет время создания резервных копий и восстановления из них, соответственно размеру каждой базы данных замедляются операции с ней.
Во-вторых, избыточная утилизация серверов и загрузка каналов передачи данных. Поясню, что имею ввиду на примере. При обращении абонента с жалобой на недоступность той или иной услуги, первое, что нужно сделать оператору поддержки, - проверить, есть ли у него вообще необходимая сумма на счету. Для крупного телеком-оператора, обладающего клиентской базой в десятки миллионов абонентов, передача всей информации о начислениях и списаниях из биллинговых систем в систему управления отношениями с клиентом (CRM) просто забьет все каналы передачи информации между системами, а также потребует существенных процессорных мощностей на валидацию и трансформацию сообщений на серверах сервисной шины. При этом важен тот факт, что в CRM нужна не вся эта информация, т.к. далеко не каждый абонент будет вообще звонить в техническую поддержку, тем более делать это каждый день.
В-третьих, подход порождает проблему согласованности данных в разных системах. Асинхронный обмен сообщениями имеет две сложности:
2) Обеспечение правильного порядка сообщений;
1) Обеспечение обработки сообщений один и только один раз;
2) Обеспечение правильного порядка сообщений.
Обработка сообщений один и только один раз подразумевает, с одной стороны, не ноль, т.е. сообщение в принципе должно быть доставлено до приемника даже в случае сбоя на стороне интеграционного сервера. С этой задачей на сегодня справляется практически каждый провайдер очередей сообщений, поддерживающий персистентность. С другой стороны, данное требование подразумевает защиту от обработки одного и того же сообщения несколько раз, т.е. интеграционное решение должно гарантировать идемпотентность операций, что требует использования или механизма распределенных транзакций, или программных проверок на дублирование в коде адаптера к системе-приемнику или в самой системе.
Порядок сообщений становится важен, когда имеются зависимости между ними. Приведу пример: в системе-источнике заводят нового абонента и тут же назначают ему пакет услуг. Информация о создании абонента передается одним сообщением, т.к. это - одно событие в системе-источнике, а о назначении услуги абоненту - отдельным. Если сообщение о назначении услуги достигнет системы-приемника раньше, нежели сообщение с данными клиента, то возникнет проблема: как завести услугу на клиента, данных о котором в системе нет? Вопрос усугубляется тем, что провайдеры очередей сообщений как правило не гарантируют порядок передачи по очередям, а если бы и гарантировали, то чтение сообщений обычно производится в несколько потоков, соответственно зависимое сообщение может быть захвачено потоком-обработчиком раньше. Нельзя сказать, что данная проблема не решаема в принципе, но все варианты решения негативно влияют на производительность и снижают масштабируемость интеграционного механизма.
(сообщения передаются по очереди, никто не знает, какое достигнет приемника первым)
Шаблон подробнейшим образом описан в статье Information service patterns, Part 1: Data federation pattern (имеется перевод на русский язык). Обращаю внимание на описание шаблона в контексте сервисно-ориентированной архитектуры.
Общее описание подхода следующее: данные остаются в тех информационных системах, в которых они были порождены. Дублирование данных исключается. Решение, обеспечивающее федерализацию данных, соединяет информацию из разрозненных источников таким образом, чтобы доступ к ней можно было предоставить клиенту в виде сервиса. В настоящее время, в связи с бурным ростом популярности архитектурного стиля REST, это будут скорее всего RESTful-сервисы.
Подробный алгоритм выполнения извлечения данных из источников и их сопоставления приведен в процитированной статье. В контексте сервисно-ориентированной архитектуры потребитель передает запрос в заранее заданном формате серверу интеграции, который преобразует этот запрос в соответствующие запросы SQL или обращения к нереляционным источникам данных, в том числе и веб-сервисам. Далее выполняются шаги по разбиению, оптимизации и исполнению запроса. В контексте SOA отличается только заключительный этап. Сервер интеграции переводит результат традиционного подхода интеграции данных в ответ сервиса, а затем возвращает его потребителю через предварительно заданный интерфейс.
Часто использование федерализации данных рассматривается как первый шаг к внедрению сервисно-ориентированной архитектуры (SOA).
В статье приведен следующий пример: сервис getCustomerCreditCardData извлекает информацию о клиенте и его последних транзакциях по кредитной карте. При этом информация о клиентах хранится в программном обеспечении класса Master Data Management (MDM), например в некотором Customer Data Hub'е, а информация о транзакциях по картам - в АБС банка. Задача сервиса - извлечь информацию из хаба, затем извлечь нужную информацию из АБС, сопоставить записи и сформировать ответ, представленный в соответствующем формате. При этом, очень важно, сервис getCustomerCreditCardData допускает повторное использование со стороны нескольких потребителей.
Другим примером может служить определение достаточности средств на счету абонента и статуса подключенных услуг при его обращении в техническую поддержку. CRM не обязательно иметь данные о всех списаниях и начислениях, а также о статусах всех подключенных абоненту услуг в собственной базе данных. Если на предприятии при внедрении информационных систем придерживаются сервисно-ориентированной архитектуры, то будут реализованы сервисы, позволяющие извлечь список подключенных услуг с их статусами и состоянием счета абонента по запросу, при этом запрашивающая система - CRM - может не иметь никаких сведений о том, из одной информационной системы она получает эти данные или из нескольких, а также - из каких именно.
Поскольку ключевых, самых важных, бизнес-функций в корпорации ограниченное количество, а сервисы выделяются таким образом, чтобы обеспечить совместное использование этих бизнес-функций, то интерфейсы федерализации данных строятся на ограниченном количестве запросов к информации, которую необходимо предоставить потребителям. Такая ясная и ограниченная задача - это преимущество для разработчиков, поскольку им требуется меньше времени для разработки запросов к данным. Они могут просто выбрать соответствующий сервис из ограниченного количества возможных вариантов.
Рассмотрим бизнес-ситуации, при которых шаблон "федерализация данных" демонстрирует свою применимость.
При всех достоинствах шаблона "федерализация данных", построение интеграционного решения на его основе не всегда имеет смысл или в принципе возможно, к тому же оказывает заметное влияние на работу источников информации. Рассмотрим соображения, ограничивающие внедрение данного шаблона на предприятии.
Как мы рассмотрели в статье, привычный разработчикам интеграционных решений подход с распространением данных не лишен ряда существенных недостатков. Конечно, бывают ситуации, когда создание избыточности данных оправдано, но иногда за построением репликации данных с помощью очередей сообщений кроются, во-первых, непонимание разработчиками концепции SOA и, во-вторых, применение решений класса ESB не по назначению. Сервисные шины предприятия были придуманы для того, чтобы на них реализовывать сервисы, соответствующие описанным классиками принципам: стандартизированный контракт, слабая связность, абстракция от избыточных деталей, повторное использование, автономность, отсутствие состояния, обнаруживаемость и способность участвовать в композиции. Однако, поскольку инструментарий, поставляемый вместе с продуктами класса ESB, существенно упрощает разработку, то на их базе начали реализовывать асинхронное распространение данных. Некоторым свидетельством распространенности такого подхода являются обсуждения вида "зачем нужны Oracle Service Bus и IBM Integration Bus, если у нас есть Apache Camel и Spring Integration?" на форумах в сети Интернет.
Применение сервисно-ориентированного подхода с выделением слоя сервисов данных позволяет избавиться полностью или частично от необходимости дублировать данные в базах данных различных информационных систем. Шаблон "федерализация данных" является одним из вариантов решения задач интеграции с использованием сервисно-ориентированной архитектуры. Данные продолжают храниться по месту их порождения, однако являются доступными там, где они необходимы. При этом нивелируется проблема согласованности данных в распределенном IT-ландшафте предприятия, данные становятся доступными в реальном времени, при этом обеспечивается необходимый уровень гибкости - при развитии схемы данных не нужно решать проблемы изменения структуры хранения в различных информационных системах, обладающих репликами данных.
Однако построение интеграционного решения исключительно на базе шаблона "федерализация данных" не всегда возможно. Прежде всего доступ к данным не в собственной базе, а во внешней информационной системе будет требовать большего времени, увеличивается латентность, особенно если система-источник географически удалена. Снижается автономность работы приложений: в случае проблем со связью или временной неработоспособностью интеграционного решения или систем-источников информации, выполнение бизнес-функций вполне исправным приложением становится невозможным. Иногда разумным является не выбирать один из существующих подходов к интеграции данных, а комбинировать их, реализуя разные шаблоны при подключении, информационных систем, работающих в корпоративном центре и в географически распределенных филиалах компании, например.
Понравилось сообщение - подпишитесь на блог
Одним из очевидных и наиболее популярных подходов к интеграции данных является их распространение путем передачи из базы данных одного приложения в базу данных другого. Tак как бизнес хочет видеть данные в каждом приложении, участвующем в бизнес-процессах компании, как можно быстрее, обмен информацией реализуется путем передачи небольших порций данных по очередям сообщений (синхронное распространение данных оставим вне рассмотрения, в последнее время оно не является мейнстримом, т.к. привносит с собой сильную связность между информационными системами). Поскольку современные решения класса Enterprise Service Bus (ESB) содержат удобнейшие зачастую декларативно настраиваемые адаптеры к большому количеству СУБД и провайдеров очередей сообщений (Message-oriented Middleware (MOM)), а также поставляются с визуальными редакторами, в разы ускоряющими разработку, то их и выбирают для решения вышеозначенной задачи. В итоге внедрение сервисной шины предприятия воспринимается как реализация асинхронного обмена данными между несколькими источниками, в большинстве своем представляющими собой реляционные базы данных тех или иных корпоративных приложений. Вариантом подхода является вставка данных не непосредственно в базу, а через некие сервисы, предоставляемые системой-приемником, что абстрагирует детали строения ее базы данных от разработчиков интеграции.
- Недостатки распространения данных
- Федерализация данных
- Применимость шаблона "федерализация данных"
- Ограничения при внедрении шаблона "федерализация данных"
- Выводы
- Материалы
Недостатки распространения данных
Описанный выше подход к интеграции обладает рядом недостатков.
Во-первых, сама по себе избыточность данных - каждое приложение имеет свою копию некоторого общего подмножества данных предприятия (например, основных данных: нормативно-справочная информация, клиенты, поставщики, сотрудники, продукты и услуги и т.д). Растут объемы баз данных каждой вовлеченной в интеграцию корпоративной информационной системы, соответственно требуются большие объемы систем хранения данных, растет время создания резервных копий и восстановления из них, соответственно размеру каждой базы данных замедляются операции с ней.
Во-вторых, избыточная утилизация серверов и загрузка каналов передачи данных. Поясню, что имею ввиду на примере. При обращении абонента с жалобой на недоступность той или иной услуги, первое, что нужно сделать оператору поддержки, - проверить, есть ли у него вообще необходимая сумма на счету. Для крупного телеком-оператора, обладающего клиентской базой в десятки миллионов абонентов, передача всей информации о начислениях и списаниях из биллинговых систем в систему управления отношениями с клиентом (CRM) просто забьет все каналы передачи информации между системами, а также потребует существенных процессорных мощностей на валидацию и трансформацию сообщений на серверах сервисной шины. При этом важен тот факт, что в CRM нужна не вся эта информация, т.к. далеко не каждый абонент будет вообще звонить в техническую поддержку, тем более делать это каждый день.
В-третьих, подход порождает проблему согласованности данных в разных системах. Асинхронный обмен сообщениями имеет две сложности:
2) Обеспечение правильного порядка сообщений;
1) Обеспечение обработки сообщений один и только один раз;
2) Обеспечение правильного порядка сообщений.
Обработка сообщений один и только один раз подразумевает, с одной стороны, не ноль, т.е. сообщение в принципе должно быть доставлено до приемника даже в случае сбоя на стороне интеграционного сервера. С этой задачей на сегодня справляется практически каждый провайдер очередей сообщений, поддерживающий персистентность. С другой стороны, данное требование подразумевает защиту от обработки одного и того же сообщения несколько раз, т.е. интеграционное решение должно гарантировать идемпотентность операций, что требует использования или механизма распределенных транзакций, или программных проверок на дублирование в коде адаптера к системе-приемнику или в самой системе.
Порядок сообщений становится важен, когда имеются зависимости между ними. Приведу пример: в системе-источнике заводят нового абонента и тут же назначают ему пакет услуг. Информация о создании абонента передается одним сообщением, т.к. это - одно событие в системе-источнике, а о назначении услуги абоненту - отдельным. Если сообщение о назначении услуги достигнет системы-приемника раньше, нежели сообщение с данными клиента, то возникнет проблема: как завести услугу на клиента, данных о котором в системе нет? Вопрос усугубляется тем, что провайдеры очередей сообщений как правило не гарантируют порядок передачи по очередям, а если бы и гарантировали, то чтение сообщений обычно производится в несколько потоков, соответственно зависимое сообщение может быть захвачено потоком-обработчиком раньше. Нельзя сказать, что данная проблема не решаема в принципе, но все варианты решения негативно влияют на производительность и снижают масштабируемость интеграционного механизма.
(сообщения передаются по очереди, никто не знает, какое достигнет приемника первым)
Федерализация данных
Шаблон подробнейшим образом описан в статье Information service patterns, Part 1: Data federation pattern (имеется перевод на русский язык). Обращаю внимание на описание шаблона в контексте сервисно-ориентированной архитектуры.
Общее описание подхода следующее: данные остаются в тех информационных системах, в которых они были порождены. Дублирование данных исключается. Решение, обеспечивающее федерализацию данных, соединяет информацию из разрозненных источников таким образом, чтобы доступ к ней можно было предоставить клиенту в виде сервиса. В настоящее время, в связи с бурным ростом популярности архитектурного стиля REST, это будут скорее всего RESTful-сервисы.
Подробный алгоритм выполнения извлечения данных из источников и их сопоставления приведен в процитированной статье. В контексте сервисно-ориентированной архитектуры потребитель передает запрос в заранее заданном формате серверу интеграции, который преобразует этот запрос в соответствующие запросы SQL или обращения к нереляционным источникам данных, в том числе и веб-сервисам. Далее выполняются шаги по разбиению, оптимизации и исполнению запроса. В контексте SOA отличается только заключительный этап. Сервер интеграции переводит результат традиционного подхода интеграции данных в ответ сервиса, а затем возвращает его потребителю через предварительно заданный интерфейс.
Часто использование федерализации данных рассматривается как первый шаг к внедрению сервисно-ориентированной архитектуры (SOA).
В статье приведен следующий пример: сервис getCustomerCreditCardData извлекает информацию о клиенте и его последних транзакциях по кредитной карте. При этом информация о клиентах хранится в программном обеспечении класса Master Data Management (MDM), например в некотором Customer Data Hub'е, а информация о транзакциях по картам - в АБС банка. Задача сервиса - извлечь информацию из хаба, затем извлечь нужную информацию из АБС, сопоставить записи и сформировать ответ, представленный в соответствующем формате. При этом, очень важно, сервис getCustomerCreditCardData допускает повторное использование со стороны нескольких потребителей.
Другим примером может служить определение достаточности средств на счету абонента и статуса подключенных услуг при его обращении в техническую поддержку. CRM не обязательно иметь данные о всех списаниях и начислениях, а также о статусах всех подключенных абоненту услуг в собственной базе данных. Если на предприятии при внедрении информационных систем придерживаются сервисно-ориентированной архитектуры, то будут реализованы сервисы, позволяющие извлечь список подключенных услуг с их статусами и состоянием счета абонента по запросу, при этом запрашивающая система - CRM - может не иметь никаких сведений о том, из одной информационной системы она получает эти данные или из нескольких, а также - из каких именно.
Поскольку ключевых, самых важных, бизнес-функций в корпорации ограниченное количество, а сервисы выделяются таким образом, чтобы обеспечить совместное использование этих бизнес-функций, то интерфейсы федерализации данных строятся на ограниченном количестве запросов к информации, которую необходимо предоставить потребителям. Такая ясная и ограниченная задача - это преимущество для разработчиков, поскольку им требуется меньше времени для разработки запросов к данным. Они могут просто выбрать соответствующий сервис из ограниченного количества возможных вариантов.
Применимость шаблона "федерализация данных"
Рассмотрим бизнес-ситуации, при которых шаблон "федерализация данных" демонстрирует свою применимость.
- Рассматриваемый шаблон интеграции данных снимает необходимость в реализации механизмов асинхронного распространения, рассмотренных в первой части статьи. Соответственно нивелируются все рассмотренные недостатки подхода: избыточность данных, лишняя нагрузка на сервера и каналы обмена данными, проблема согласованности данных. Сокращается время реализации интеграционных проектов за счет отсутствия необходимости вмешательства в инфраструктуру управления данными.
- Перемещение и дублирование информации может быть запрещено по организационным мотивам, особенно если данные являются субъектом законодательства. Например, может быть запрещено объединение персональных данных из разных источников в тех или иных странах. Здесь также стоит отметить доверие к источнику данных, в частности - наличие определенных сертификатов. Правило может быть таким: данные в источнике пользуются доверием, а уже куда-то реплицированные из него - нет, т.к. невозможно или очень затруднительно гарантировать их неизменяемость в процессе копирования.
- Необходимо обеспечить доступ к данным из разных источников в реальном времени. Асинхронное распространение данных требует времени, при этом, если сообщений много или наблюдается некоторый пиковый период, то это время может быть существенным. К примеру, при заключении контракта с оператором связи, могут попросить подождать несколько часов до тех пор, пока услугами можно будет начать пользоваться. Нужно время пока информация о новом абоненте и подключенных ему услугах распространится по информационным системам компании. При федерализации данные доступны для потребителей сразу же после порождения.
- Гибкость при изменении интеграционных сценариев или появлении новых потребностей в интеграции. Приведу пример: расширение схемы данных, предположим, появление поля "партийность" в документах, удостоверяющих личность. При избыточности данных необходимо добавить это поле во все системы, в которых присутствует соответствующая информация, а также каким-то образом заполнить его для всех уже имеющихся записей. В случае федерализации данных, необходимо лишь обновить соответствующие сервисы доступа к информации. Интеграционное решение способно замаскировать изменения модели данных, которые могут быть сделаны в системах-источниках, не все изменения модели могут быть показаны потребителям сервисов данных до тех пор, пока те не станут готовы работать с новыми моделями.
Ограничения при внедрении шаблона "федерализация данных"
При всех достоинствах шаблона "федерализация данных", построение интеграционного решения на его основе не всегда имеет смысл или в принципе возможно, к тому же оказывает заметное влияние на работу источников информации. Рассмотрим соображения, ограничивающие внедрение данного шаблона на предприятии.
- Приложения должны быть адаптированы к использованию данного шаблона. Необходимо реализовать получение информации в приложениях не только из собственных баз данных, но и путем вызова сервисов федерализации данных. Для внедряемых информационных систем такая адаптация является частью процесса внедрения, осуществить же ее для унаследованных систем не всегда предоставляется возможным.
- Увеличение рабочей нагрузки на сервера источников данных из-за необходимости обрабатывать запросы от сервисов федерализации данных может привести к росту времени отклика как в ответ на эти запросы, так и в ответ на нормальную работу источников. В некоторых случаях выполнение системами-источниками своих бизнес-функций может стать затруднительным, что потребует дополнительных физических или виртуальных вычислительных мощностей.
- Ситуации, при которых приложениям необходима достаточно высокая степень автономности, не подходят для применения этого паттерна, т.к. доступность данных зависит от доступности всех серверов интеграции и систем-источников. При построении интеграционного решения на основе федерализации данных необходимо в первую очередь обеспечить достаточную пропускную способность и надежность каналов связи, а также высокую доступность и восстановление после сбоев для интеграционного решения и информационных систем предприятия, владеющих общими данными.
- Гранулярность извлекаемых из источников информации данных может существенно влиять на производительность интеграционного решения и время отклика. Если источники могут отдавать данные только большими объемами, к примеру исключительно все сотрудники организации без возможности наложить фильтр, то лишнее время будет тратиться как на передачу данных от источника до сервера интеграции, так и на сопоставление данных при построении композитного ответа.
Выводы
Как мы рассмотрели в статье, привычный разработчикам интеграционных решений подход с распространением данных не лишен ряда существенных недостатков. Конечно, бывают ситуации, когда создание избыточности данных оправдано, но иногда за построением репликации данных с помощью очередей сообщений кроются, во-первых, непонимание разработчиками концепции SOA и, во-вторых, применение решений класса ESB не по назначению. Сервисные шины предприятия были придуманы для того, чтобы на них реализовывать сервисы, соответствующие описанным классиками принципам: стандартизированный контракт, слабая связность, абстракция от избыточных деталей, повторное использование, автономность, отсутствие состояния, обнаруживаемость и способность участвовать в композиции. Однако, поскольку инструментарий, поставляемый вместе с продуктами класса ESB, существенно упрощает разработку, то на их базе начали реализовывать асинхронное распространение данных. Некоторым свидетельством распространенности такого подхода являются обсуждения вида "зачем нужны Oracle Service Bus и IBM Integration Bus, если у нас есть Apache Camel и Spring Integration?" на форумах в сети Интернет.
Применение сервисно-ориентированного подхода с выделением слоя сервисов данных позволяет избавиться полностью или частично от необходимости дублировать данные в базах данных различных информационных систем. Шаблон "федерализация данных" является одним из вариантов решения задач интеграции с использованием сервисно-ориентированной архитектуры. Данные продолжают храниться по месту их порождения, однако являются доступными там, где они необходимы. При этом нивелируется проблема согласованности данных в распределенном IT-ландшафте предприятия, данные становятся доступными в реальном времени, при этом обеспечивается необходимый уровень гибкости - при развитии схемы данных не нужно решать проблемы изменения структуры хранения в различных информационных системах, обладающих репликами данных.
Однако построение интеграционного решения исключительно на базе шаблона "федерализация данных" не всегда возможно. Прежде всего доступ к данным не в собственной базе, а во внешней информационной системе будет требовать большего времени, увеличивается латентность, особенно если система-источник географически удалена. Снижается автономность работы приложений: в случае проблем со связью или временной неработоспособностью интеграционного решения или систем-источников информации, выполнение бизнес-функций вполне исправным приложением становится невозможным. Иногда разумным является не выбирать один из существующих подходов к интеграции данных, а комбинировать их, реализуя разные шаблоны при подключении, информационных систем, работающих в корпоративном центре и в географически распределенных филиалах компании, например.
Материалы
- Information service patterns, Part 1: Data federation pattern
- Demystifying Data Federation for SOA
- "Универсальный сервис", почему заказчики так часто его хотят и почему его делать не нужно
Понравилось сообщение - подпишитесь на блог
Комментариев нет:
Отправить комментарий
Любой Ваш комментарий важен для меня, однако, помните, что действует предмодерация. Давайте уважать друг друга!