SOA и сервисы данных

Тема «Cервисы данных» сегодня и нова, и актуальна. В начале текущего года появились отчеты нескольких аналитических компаний, в том числе Gartner, Forrester Research, Burton Group и других, утверждающие, что в сфере SOA наступивший 2008 год может стать годом платформ сервисов данных (Data Services Platform, DSP) и шин сервисов данных (Data Services Bus, DSB). С этим прогнозом нельзя не согласиться, но его сопровождают весьма странные утверждения. Например, такое: «Как поясняют в Burton, технологии DSP появились в 2005 году, но до сих пор находились в тени инфраструктурных решений для SOA, прежде всего корпоративных сервисных шин ESB. Теперь же настало время именно DSP выйти на первый план». О каком затенении может идти речь, если DSP предлагаются для поддержки функциональных моделей SOA? Иначе говоря, как части целого могут затенять друг друга? Скорее дело в том, что идея DSB родилась позже, поэтому сейчас к ней, как новинке, способствующей развитию SOA, привлечено больше внимания.

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

Эти сервисы иногда еще обозначают аббревиатурой DaaS (Data-as-a-Service), очень похожей на IaaS (Information-as-a-Service). Однако между этими явлениями есть колоссальное различие. Задачей внедрения DaaS, как определяют аналитики Forrester Research, является «всего лишь» упрощение доступа к потокам данных, поступающих в реальном времени наряду с данными, размещенными в базах, хранилищах и файлах с целью более совершенной бизнес-аналитики и принятия оперативных решений. То есть речь идет только о данных и никоим образом не об информации. Аналитики сходятся в том, что технологии DSP надо рассматривать как дополнение к хранилищам данных и традиционным средствам интеграции данных, стоящее над ними.

Почему корпоративная шина и шина данных должны существовать в паре? Очевидно, между компонентами любых информационных систем есть два типа взаимодействий — по управлению и по информации; так было на всех этапах развития ИТ, и сервисные архитектуры не исключение, но именно с их появлением вопрос о взаимодействии этих двух типов связей кристаллизовался или актуализировался. В традиционных монолитных системах разделение на связь по управлению и связь по информации формально не выделяется, эти две сущности сосуществуют по умолчанию. В случае SOA из-за слабой связанности компонентов эти две составляющие — и связь по управлению, и связь по данным — должны быть прописаны в явной форме. Однако почему-то о второй части этого утверждения поначалу забыли, скорее всего, из-за предшествующего опыта. Работа с данными началась в 70-е годы, когда компьютеры стали использовать преимущественно для обработки больших массивов, а не для счета. В результате сформировалось направление, которое стали называть вычислениями, ориентированными на данные (data-centric computing). Переход от счета к обработке данных привел к так называемой реляционной революции. Основное достоинство реляционных СУБД в том, что они позволили абстрагировать данные, поскольку освободили разработчиков от этой необходимости программировать операции с данными и позволили выйти на декларативный уровень запросов к СУБД. Одно из важнейших преимуществ СУБД состоит в том, что они скрыли в себе связи по данным между модулями сильносвязанных систем. Однако в чистом виде СУБД не годятся для слабосвязанных приложений, поэтому с переходом SOA требуется создать аналогичный инструмент, который позволил бы существлять аналогичный запросам SQL декларативный доступ к данным.

Возникающая при этом задача не менее сложна, чем создание СУБД, и из-за задержек с ее решением архитектуры SOA распространяются медленнее, чем предполагалось. В этом нет ничего удивительного; случилось так, что на ранних этапах становления SOA все внимание было сосредоточено на том, как обеспечить связь по управлению, то есть систему взаимодействия между модулями, будь то стек протоколов SOAP, WSDL, UDDI или протокол REST. И только после того, как эти проблемы управления оказались в основном решенными, выяснилось, что требуется поднять до соответствующего уровня абстракции и информационную обеспеченность модулей. К решению этой задачи приступили с опозданием, поэтому в SOA между управлением и данными существует определенное рассогласование или, другими словами, зазор. До тех пор пока он не будет устранен, разработчики будут вынуждены заниматься переводом форматов данных, устранением технических и семантических рассогласований, сборкой и интегрированием данных из различных подсистем.

Стандарты

Для преодоления описанного зазора между возможностями SOA и их информационной поддержкой OASIS (Organization for the Advancement of Structured Information Standards) предложила проект стандарта Content Assembly Mechanism (CAM), название которого можно перевести как «механизм сборки контента». Он создан для унификации процессов переноса данных с уровня принятия решений на уровень поддержки SOA данными (SOA data services layer). Напомним, OASIS — международный некоммерческий консорциум, сформированный в 1993 году с целью распространения стандартов SGML Open для языка Standard Generalized Markup Language. В 1998 году здесь была разработана его адаптированная версия, известная как XML. Работа над проектом стандарта продолжалась четыре года, действующая версия CAM 1.1 (docs.oasis-open.org/cam) была опубликована в июне 2007 года. Она была призвана дополнить такие разработки консорциума W3C, как XSD Schema, XSLT, Schematron и XMLBeans, в большей мере ориентированные на разработчиков. Стандарт CAM распространяется на открытые системы, построенные на основе языка XML. Такого рода системы используется в цикле, состоящем из описания бизнес-правил, их точного определения, проверки и затем составления необходимых документов по этим правилам из общего набора элементов данных и структур. Входящие в состав CAM набор правил и шаблоны для сборки документов позволяют описать бизнес-контекст, требования к содержанию, основные функции документа и то, как он должен распространяться. Основное предназначение спецификации OASIS CAM заключается в поддержке механизма для сборки контента, стоящего над XML, и схемы для описания обмена данными между компонентами бизнес-процессов. Внешне процессоры данных, построенные по стандарту CAM, представляют собой структуры XML, построенные в стиле WYSIWYG, плюс добавленные правила для выбора компонентов и контента. Состояние этих стандартов отстает от стека стандартов на Web-сервисы на несколько лет. Кроме того, OASIS, как организация, лишь координирующая разработку стандартов, имеет существенно меньший потенциал в области стандартов на сервисы, чем консорциум W3C, руководящий разработкой этого рода стандартов.

В самом консорциуме W3C, координирующем стандартизацию WWW, тоже недавно началась работа над стандартами сервисов данных, в том числе над проектом WSO2 Data Services Project, который имеет внутреннее название «кислород для разработчиков SOA». Этот проект ставит своей целью разработку унифицированных механизмов доступа к базам данных через API Web-сервисов.

Шина данных

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

Есть несколько подходов к решению этих задач. Пока наибольшее распространение получили не какие-то радикальные методы, а наиболее практичные, такие, в которых существующие технологии работы с корпоративными данными так или иначе адаптированы к SOA. В них данные интегрируются в общий пул, а сервисные модули сами обращаются к нему; в таком случае на модули возлагается ответственность за правильность выбора данных, доступ к ним и их сохранение. Хотя данное решение позволяет полноценно реализовать SOA, у него есть ряд недостатков. При выборе этого метода модули нагружаются не только их прямой функциональностью, связанной с выполнением бизнес-процессов, но они к тому же должны поддерживать валидность данных и каким-то образом участвовать в логике координированного доступа к данным. Эта дополнительная нагрузка приводит к тому, что между модулями возникают дополнительные связи, что противоречит главному достоинству SOA — слабой связанности. Есть решения, в которых отмеченные недостатки компенсируются тем, что для обеспечения функциональных модулей данными создаются специализированные модули поставщики данных, и таким образом поставка данных как бы уравнивается с остальными функциями. При видимых преимуществах у этого решения есть один существенный недостаток — высокая сложность реализации. Наиболее перспективным представляется новое решение — корпоративная шина данных (Enterprise Data Bus, EDB). Оно позволяет создать единую корпоративную архитектуру данных (Data Service Architecture, DSA). Чаще всего под DSA понимают введение дополнительного уровня в модель SOA; данный уровень стали называть «уровнем сервиса данных» (Data Service Level, DSL). Этот уровень обеспечивает абстракцию и интеграцию данных с точки зрения бизнес-сервисов. Подход, использующий DSL, обеспечивает целостный взгляд на корпоративные данные и интерфейс к данным, независимый от конкретных форм их хранения и представления.

При наличии в корпоративной системе двух шин (рис. 1) — ESB и DSB — принципиально меняется технология разработки, создание архитектуры DSA превращается в отдельный вид деятельности. Этим призваны заниматься специалисты, которых теперь называют архитекторами и разработчиками сервисов данных. Создание действующей системы сервисов данных можно представить в виде шагов.

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

Концепция DSB находится в процессе становления, и еще ни один производитель не готов предложить законченное коммерческое решение. Тем не менее частично принципы DSA реализованы в нескольких продуктах. Например, в универсальной сервисной архитектуре данных Universal Data Services Architecture, предложенной компанией Informatica; в продукте BEA AquaLogic Data Services Platform; в MetaMatrix Enterprise, принадлежащем ныне Red Hat; а также в DataXtend от компании Progress Software. 

MetaMatrix Enterprise от Red Hat

Компания MetaMatrix, созданная в 1998 году, в 2007 году была куплена Red Hat с целью решения задачи интеграции данных в решениях SOA, поддерживаемых программным обеспечением промежуточного слоя JBoss. Эта компания пользовалась большим авторитетом в сообществе Open Source, а ее продукты MetaMatrix Enterprise, MetaMatrix Dimension и MetaMatrix Query — широким признанием.

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

При существующих технологиях перевод данных из той формы, в которой они есть, в ту, которая требуется, занимает силы и время. Инструмент MetaMatrix помогает сделать это быстрее и затем реализовать поставку данных в виде сервисов. Чтобы им воспользоваться, необходимо передать в систему хранения дополняющие метаданные и схему преобразования данных из одного формата в другой. После этого следует установить соответствие между элементами данных, исключая дупликацию данных, разрешить различия в типах данных, интегрировать данные из различных систем, агрегировать данные, принадлежащие разным группам. С помощью MetaMatrix все это можно делать графическими средствами, не написав ни одной строки кода. Процесс проектирования связи приложений с данными носит декларативный характер, используются графические модели, меню и другие приемы работы в интерактивных средах. Метаданные определяют то, как манипулировать данными в процессе исполнения, ими задаются отношения между источниками данных, ограничения на изменения и другие свойства данных.

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

Средствами MetaMatrix Enterprise удается решить основную задачу, стоящую перед DSB, — обеспечить виртуализацию корпоративных данных. Работа с MetaMatrix Enterprise разделяется на две фазы: проектирование, исполнение (рис. 3). На первой фазе архитекторы данных и проектировщики, используя MetaMatrix Enterprise Designer, формируют контент для MetaMatrix Server, поддерживающий работу сервисной платформы.

Репозиторий MetaMatrix Repository хранит все метаданные в том числе те, которыми его снабжают архитекторы данных, те, которые можно получить от физических источников, и те, которые передают такие инструменты работы с данными, как CA Allfusion ERwin Data Modeler, Telelogic System Architect или IBM Rational Rose. В процессе исполнения MetaMatrix Enterprise Server получает доступ к самым разнообразным виртуализированным источникам данных с помощью метаданных. Это могут быть реляционные СУБД, XML-файлы, неструктурированные файлы, приложения типа Siebel, SAP, PeopleSoft и др. С точки зрения сервисов, потребителей данных, все эти источники унифицированы; сейчас для них существует два метода доступа, один по модели Web-сервисов по протоколу SOAP, второй — классический SQL. Предполагается, что в будущем появится возможность использовать язык запросов XQuery.

DataXtend SI

По своему составу продукт под полным названием Progress DataXtend Semantic Integrator аналогичен MetaMatrix Enterprise. Он состоит из инструментальной части DataXtend SI Designer, позволяющей осуществить полный дизайн среды, правил и самих сервисов данных. DataXtend SI Designer позволяет импортировать существующие схемы источников данных, использовать файлы XSD и WSDL, также использовать общую модель данных (Common Data Model, CDM), в которой представлена семантическая структура, являющаяся общей для множества источников данных и сервисов данных. Вторая часть — DataXtend SI Engine служит для поддержки процесса выполнения, она осуществляет передачу, конвертирование и валидацию данных.

BEA AquaLogic Data Services Platform

Платформа, ранее известная под образным названием Liquid Data, то есть «жидкие данные», обеспечивает в реальном времени предоставление данных в виде сервисов.

Платформа AquaLogic Data Services Platform, как и другие аналогичные ей продукты, предназначена для разработки сервисов данных и их поддержки в процессе выполнения. Подобно им, она также является промежуточным слоем, за исключением кэшированных данных, — она сама их не содержит, а обеспечивает доступ к физическим источникам. Платформа гарантирует доступ к данным в реальном времени. Подобно Web-сервисам в AquaLogic Data Services, сервисы данных имеют открытый API в форме нескольких функций доступа, последние возвращают запрашиваемому модулю данные, в этом и состоит их сервисная роль. Функции используют запросы на языке XQuery для получения, трансформации и агрегирования данных из внешних источников. Возвращаемые данные обычно представляются на XML. Благодаря такой схеме AquaLogic Data Services Platform избавляет потребителя данных от сложностей работы с распределенными источниками данных.

Итак, если аналитики правы, то в настоящее время наступает год сервисов данных.