Master Data Management, EDA, ESB, SOA: собираем все вместе

Реализация повторно используемых интерфейсов предполагает, что мы будем хотя бы чуть-чуть абстрагироваться от конкретных задач и требований сегодняшнего дня. Иначе интерфейсы нам придется переделывать постоянно. Повторю пример из комментариев к сообщению Как сделать хороший API? При разработке программного интерфейса к каталогу книг методы

 

getBookAuthor(…) и getBookPublisher(…)

выглядят вполне уместно. Однако проходит время и заказчик понимает, что первоначально придуманных свойств недостаточно. Появляются требования по получению новых параметров, например ISDN. В какой-то момент разработчику это надоедает, и он разрабатывает функцию

getBookProperty(authorID,…)

Выглядит уже лучше. Правда затем в ассортименте виртуального магазина к книгам могут добавиться компакт-диски и другие товары, у которых и автора нет и ISDN, зато есть другие свойства. В результате неизбежного рефакторинга книжки должны превратиться а item-ы, а исходная функция в

getItemProperty(itemID, propertyID,…)

Преимущества такого подхода достаточно очевидны. Впрочем, в дополнение к преимуществам появляются и определенные сложности. Одна из них состоит в необходимости разработки дополнительных функций для получения списка item-ов и списка их свойств. Причем перечни свойств элементов различных типов может не совпадать. Описание структуры данных принято выносить в мета-данные (meta-data management). Т.е. у нас должен появиться справочник, в который мы будем вносить эти данные и программные интерфейсы для чтения этих справочников из приложений. Вот мы и добрались до управления основными данными (master data management, нормативно-справочная информация) о котором говорили в сообщении Интерес к управлению данными возвращается Это станет особенно актуальным если информацию получать мы будем из нескольких разнородных приложений с различными программными интерфейсами. Кстати именно в этом случае нам понадобится ESB и управляемая событиями архитектура (Even-driven architecture) Может показаться, что я противоречу своим более ранним сообщениям. Однако, если разобраться чуть глубже, то станет понятно почему это не так (см. рисунок)

В каждом из унаследованных приложений свои структуры данных и свои программные интерфейсы (в одном книжки, в другом компакт-диски ). В каждом, в лучшем случае, свои справочники свойств или же тривиальный хардкод, что встречается чаще. Первое что нужно сделать – научить приложения уведомлять MDM-систему обо всех изменениях в справочниках (Event Driven стиль). В крайнем случае, можно наладить ETL процесс, который будет регулярно сканировать базу данных на предмет выявления изменений и отражать их в MDM. Для того чтоб получить перечень свойств книг или перечень свойств компакт-дисков, очевидно, не следует вызывать API унаследованных приложений, а следует обратиться к MDM системе. (Подробнее см. Gregor Hohp Programming Without a Call Stack – Event-driven Architectures) И в завершении картинки у нас появляется сервисная шина предприятия (ESB), которая берет на себя функции преобразования запросов из getItemProperty() в реализованный унаследованным приложением getBookAuthor(), а так же маршрутизации запросов между приложениям. Кроме того, ESB окажется полезным и при чтении MDM, например, для сокрытия задержек обновления данных в MDM, кеширования запросов и т.д. Сам процесс обновления данных в MDM системе можно и даже нужно реализовать в ESB, т.к. это позволит нам реализовать достаточно эффективные стратегии управления данными. Не стану углубляться в подробности, т.к. описание данных стратегий потребует некоторого погружения в описание архитектуры Web. Интересующихся отсылаю к диссертации изобретателя стиля RESTful Роя Филдинга (краткое введение в тему RESTful и Enterprise 2.0)

Master Data Management, EDA, ESB, SOA: собираем все вместе: 21 комментарий

  1. думаю, задача ETL/Eventing-актуализация данных в MDM – в том числе может отдаваться в ESB, где обычно подобные возможности/адаптеры поддерживаются.

    1. Я думаю, что эту задачу лучше отдавать в ESB. Вообще, реализация сходного функционала в разных продуктах, в данном случае MDM и шина, навевает грустные мысли

  2. также, стоит обратить внимание на роль BI в подобной структуре – она ключевая именно в условиях интегрированной системы.
    Возможно нечто подобное: http://www.webpagescreenshot.info/img/316748-815201190705PM
    * выделяется отдельная ESB (или доп-роль вашей ESB), которая заведует ETL и обработкой событий от интегрированных систем (в том числе CEP), а также актуализацией данных в MDM. По поводу предложенного разделения ESB напрашивается пример: Inventory в oss/j можно считать MDM, которая представляет метаданные и данные компонентов поставляемых внутренними и внешними поставщиками, SLA/QoS-отношения с которыми, лучше контролировать отдельной подсистемой-шлюзом (ESB) , которая сможет также помочь в организации DMZ.
    * все запросы проходящие через ESB (особенно запросы/ответы изменений и события) журналируются в BI-подсистему, в её DWH/ODS.
    * данные DWH/ODS обрабатываются для DataMining, генерации отчётов и публикации их в DataMarts или OLAP, которые, в свою очередь, используются клиентскими приложениями.
    * для задач Business Activity Monitoring (BAM) поток данных для журналирования дублируется в систему BAM, где происходит их аггрегация, CEP, enriching и real-time визуализация каких-то KPI.

    —–
    Дополнительно (можно сказать некий оффтопик), интересны варианты обеспечения консистентности изменений в связанных системах (особенно унаследованных), особенно когда изменения – это многошаговые атомарные транзакции при интенсивных изменениях в них участвующих системах. Обычно здесь банально предлагается использовать какой-то Transaction Management, работающий поверх SOAP (типа WS-AtomicTransaction с 2х фазной фиксацией), что в реальности усложняет решение, когда одной ESB не обойтись… Поэтому стоит таким образом строить систему, чтобы была возможна оптимистическая блокировка связанных систем или ресурсов, ориентированность на клиента на основе версионности, WAL и т.п. Стоит заметить, что это сильно влияет на то, как на самом деле будет выглядеть картинка отражающая реальную систему:)
    fyi: http://arxiv.org/ftp/arxiv/papers/0909/0909.1788.pdf – освежает взгляд на обозначенную проблему.

    1. Боюсь эта проблема не решается в общем случае — см. теорему CAP. В каждом конкретном случае есть потребность в определённом уровне согласованности, от этого и нужно отталкиваться.

      1. собственно, в последней ссылке и есть введение в ту самую CAP – в стиле, “а нам действительно нужен этот самый ACID?”:).

        Однако, если всё решение строить не на RPC, а на асинхронных коммуникациях событий-топиков, идемпотентности их обработки, то вполне можно построить достаточно устойчивое по консистентности данных интегрированных систем решение, где, в основном, все составляющие CAP – сбалансированы (по аналогии с парадигмой наличия баланса в управлении проектами: время-ресурсы-содержание результата). Возьму смелость утверждать, что асинхронная модель коммуникаций позволяет решать обозначенные ранее проблемы и “в общем случае”.

          1. ну эта тактика обеспечивает только AP (типа Cassandra), в обсуждаемом же случае может быть интереснее CA (типа HBase)… – а лучше всётаки баланс, который я предложил поискать:)

            Думаю, это тема отдельного обсуждения… Моя цель была лишь обратить внимание на появление проблемы консистентности и её снижение за счёт событийности.

  3. Хороший материал, правильный подход в общем, но боюсь есть несколько подводных камней.

    Во-первых, справочник свойств это утопия. Большинство приложений, в тех случаях, когда справочные данные в них действительно используются, а не просто хранятся, не имеет никакого справочника. Вместо этого приложение имеет объектную модель или схему данных, где эти имена и семантика зацементированы — это их модель предметной области. Следовательно при подключении приложения к системе MDM возникает потребность в адаптере, который будет запрашивать getItemProperty(itemId, “author”) и делать book.setAuthor(…). Далее, адаптер не только специфичен для конкретного приложения, но и для определённого набора свойств, интересных этому приложению, поэтому справочники свойств никто запрашивать не станет, а будет опять-таки хардкод. Дальше всё ещё интереснее, ведь хардкод в наборе свойств означает зависимость от схемы справочных данных, которая однако не стоит на месте, а хочет развиваться — милости прошу, версионность контрактов.

    Во-вторых, нельзя полагаться исключительно на событийное обновление. Событийно-управляемый адаптер — штука дорогая. Проще и дешевле везде где позволяет специфика обновлять базу данных под приложением в пакетном режиме еженощно, а это уже не очень хорошо ложится на ESB и EDA, лучше традиционный ETL.

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

    И это всё только про состав полей. А ещё ведь нужно согласовать их семантику, а так же следить, чтобы последняя не оторвалась со временем от синтаксиса (“Мы раньше заводили юриков как физиков и указывали наименование и номер договора в полях Имя и Фамилия”).

    В общем, MDM это целая дисциплина, которую наскоком не взять. Впрочем, это справедливо и для большинства проблем enterprise IT. За это нам и платят деньги 🙂

    1. относительно событийного обновления хочу заметить, что сейчас основной тренд связан с достаточно реактивной работой ИТ близком к реальному времени, особенно, если бизнес-процессы выходят наружу предприятия (связываются с клиентами, поставщками, партнёрами и т.п.). Другими словами, в текущих условиях/требованиях развития предприятия уже нет времени ждать, пока ночью какой-то batch-ETL выкачает и обновит данные в БД – “все изменения должны проявляться сразу” в портале клиентов, они “сразу же” имеют возможность использовать эти данные и т.п. В качестве примеров: высокопосещаемые сайты-магазины, CRM и продажи, системы оперативного управления и т.п. Другой пример (из oss, saas etc), когда используется оплата по выработке ресурса продукта использующего ресурсы сторонних систем-поставщиков, а контроль QoS для использования затруднительно организовать – это может приводить к проблеме списания средств за использование в реальном времени, а не раз в сутки и т.п.

      1. Слава :
        относительно событийного обновления хочу заметить, что сейчас основной тренд связан с достаточно реактивной работой ИТ близком к реальному времени, особенно, если бизнес-процессы выходят наружу предприятия (связываются с клиентами, поставщками, партнёрами и т.п.). Другими словами, в текущих условиях/требованиях развития предприятия уже нет времени ждать, пока ночью какой-то batch-ETL выкачает и обновит данные в БД – «все изменения должны проявляться сразу» в портале клиентов, они «сразу же» имеют возможность использовать эти данные и т.п. В качестве примеров: высокопосещаемые сайты-магазины, CRM и продажи, системы оперативного управления и т.п. Другой пример (из oss, saas etc), когда используется оплата по выработке ресурса продукта использующего ресурсы сторонних систем-поставщиков, а контроль QoS для использования затруднительно организовать – это может приводить к проблеме списания средств за использование в реальном времени, а не раз в сутки и т.п.
        Другая проблема, что многие поставщики таковы, что объём всех данных за прошедшие сутки не получается за всю ночь забрать:) Особенно, если поставщик готов только полные логи выработок отдавать, без агрегации.

      2. Я не спорю, что это в идеальном мире все приложения обновляются в реальном времени. Критически важные приложения так и должны обновляться. Однако у меня в организации, например, около двух сотен приложений в совокупности. Если для каждой делать событийный адаптер-контроллер, это будет очень дорого как в разработке, так и в дальнейшей эксплуатации. К тому же некоторые системы используются, скажем, раз в неделю — нет смысла обновлять их в реальном времени.

        1. с тем, что мир не идеален – я и не спорил:) Переносите всё на промежуточный уровень ESB и т.п.

          Делать адаптацию в каждой подсистеме возможно и не имеет смысла… Как пример решения: на уровне платформы ориентируемся на событийность, а если подключаемая система испытывает трудности с публикациями событий или их приёмом – мы переводим из событий в RPC, ETL и др. (и обратно), как способна работать система. Т.е., даже если система только по ночам отдаёт логи – они прогоняются через ESB, которая переводит информацию в формат событий, публикует их, отрабатывает CEP. Т.е. концептуально, имеется некое событийное ядро, которое работает через адаптеры на ESB с разными источниками событий, публикации логов и др. – тем самым достигается нативная поддержка реального времени и agile-сть интеграции новых систем.

          1. Область для использования ETL, действительно, сжимается, а очередей растет. Например, Oracle AQ вполне зрелый механизм. ETL остается для систем, которые выгружают большие объемы данных по расписанию, например все звонки абонентов за последние X часов. Ну и еще отдельная тема стейджинговые таблицы

    2. Если подсистема играющая роль MDM обеспечивает спецификации и сущности по ним созданным (по паттерну Specification http://martinfowler.com/apsupp/spec.pdf, по-простому key-values:), а клиентские системы это “понимают” – то и логику работы с такими сущностями хардкодить не нужно, либо это будет некий простой код типа mashup, ориентированный на GUI. Собственно, подобный подход используется в oss и даже 1С.

      1. Не совсем понял как Specification тут поможет. Насколько я понимаю, это такая “объектифицированная” форма представления произвольного критерия, помогающая отбирать подмножество объектов. Как это связано со справочными данными и как клиентские системы могут это понимать?

        Замечу однако, что пары ключ-значение по сути то, что Максим в своём посте и предлагает: getItemProperty(…) принимает ключ в качестве параметры и возвращает значение. И проблему это не решает.

        1. 1. Спецификации могут помочь в создании абстракции поиска/фильтрации сущностей в MDM для клиентов, если сама MDM будет их поддерживать под нужные юзкейсы и актуализировать по мере появления новых данных в справочниках. Это позволит значительно сократить изменения на стороне клиентов при изменении в MDM. Если рассматривать связку через сервисы, то клиенты знают список критериев выборки, которые указывают при запросах.
          2. да, Максим указывал на KV, а я предлагаю дополнить ключи метаданными, которые настолько полны (в смысле документированы ключи), что возможно их отрендерить в GUI (типа user-friendly description) или легко понимать, как их отражать в предметную область клиента.
          3. ESB может на себя брать функции поддержки спецификации и трансформации элементов данных MDM или др. в формат данных клиента (в тот самый book) – почти прозрачно стыкуя предметные области, выполняя enriching данных и т.п. – когда клиент может на самом деле даже не знать, что за структура данных используется из MDM и это не потребует перепрограммирования при изменении и т.п., в том числе, если случайно параметр пропал.

          Хочу сказать, что подобный подход использовался для некого решения, которое прозрачно связывает поставщиков услуг и их потребителей (клиентов и реселеров), обеспечивая операционное обслуживание, CRM, fraud detection и биллинг таких связей. При этом сама система прозрачно работает именно с KV-представлением сущностей поставщиков, автоматически их отрисовывая в пользовательских GUI и используя в бизнес-логике. И самое главное: если поставщик меняет структуры своих данных – конечно сразу для клиентов новые структуры не доступны. Это возможно только после верификации изменений и возможно правки конфигурации в ESB.

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

            На счёт 3 хочу заметить, что принципиальной разницы между адаптером “в ESB” и адаптером “в приложении” нет — писать и поддерживать нужно и тот, и другой.

            И вообще, мы настолько далеко отошли от темы моего исходного комментария, что мне уже неудобно перед Максимом. Всё, на что я хотел обратить внимание, это то, что существет ряд проблем, которые в MDM не решаются простым “втыканием” всех в событийную шину. Право формат обмена комментариями не позволяет ни Вам, ни мне полностью раскрыть тему.

  4. Если я правильно понял статью Programming Without a Call Stack – Event-driven Architectures, то там предлагается такой подход: информация “размазывается” по приложениям (например, адреса) и приложение работает со своим собственным состоянием. Обновление справочника (тех же адресов) передается не из приложения в некий MDM, а наоборот в приложение. Т.е. при обработке какого-либо запроса (или события) приложение не лезет за справочником в некий MDM, а использует свое собственное состояние.

    Возникает вопрос, какова роль MDM при таком подходе и так ли уж он становится нужен?

  5. Очень хороший вопрос!

    Вообще, это не подход из статьи, так MDM и работает — все приложения сами по себе, имеют свои справочники, а MDM (точнее MDMS, мы уже о системе говорим) обеспечивает единую картинку для всех. Что предполагает движение информации в обе стороны, ведь справочники где-то должны обновляться, а делать это в ценрализованной MDMS не всегда удобно.

    Теперь по вопросу. Как справедливо отмечал Максим, это в первую очередь административная проблема: кто отвечает за ведение справочников, кто мониторит обновления, кто моделирует структуру справочников и пр. Это многим мешает правильно понять суть MDM. Техническая же составляющая вторична: это может быть EDA, ETL или какой-нибудь Data Grid — словом то, что проще и дешевле для каждого конкретного приложения.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *