Концепции облачного федеративного хранилища

Общепризнанным стандартом представления данных на транспортном уровне является XML. Если на транспортном уровне использовать XML-представление, то описание структуры хранимых данных становится синонимом файла определения синтаксиса XML-файла DTD (http://ru. wikipedia.org/wiki/DTD) или XML Schema (http://ru. wikipedia.org/wiki/XML_Schema). XML-схемы вытеснили DTD в силу их больших возможностей и универсальности. В этом случае схемы представления информации в XML файле становится некоторым аналогом таблицы в реляционной СУБД или класса объектов в объектно-ориентированных базах данных.

Таким образом, на основе подхода с использованием промежуточного представления передаваемых данных в формате документов на языке XML можно построить федеративное хранилище данных, которые делегируются в него отдельными держателями этих данных как на свободной, так и на коммерческой основе. В роли языка манипулирования данных в этом случае будет выступать язык XQuery, позволяющий выполнять запросы к наборам данных, представленных как документами XML, так и традиционными таблицами реляционных СУБД. В отличие от языка SQL язык XQuery позволяет создавать запросы к гетерогенным источникам данных, что делает его хорошим инструментом для работы с распределенными хранилищами, предоставляемыми различными провайдерами, входящими в федерацию.

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

Если ориентироваться на создание универсальной функционально полной системы хранения структурированных данных с использованием виртуальных схем на основе общепринятой идеологии использования XML на транспортном уровне, то для такого представления нужно разработать язык и систему интерпретации для создания произвольной схемы данных и её использования при передаче данных между абонентами корпоративного или федерального облака. Функциональная полнота системы предполагает наличие средств добавления и модификации документов авторизованными удаленными клиентами хранилища. Здесь возникают проблемы с вычисляемыми атрибутами документов, для которых в общем случае не существует алгоритма правильной декомпозиции на составляющие их значения полей первичных записей баз данных, расположенных, возможно, в разных узлах сети.

Нетривиальной представляется задача поддержки транзакций и уровней изоляции в такой распределенной системе хранения данных для формирования XML-документов при их добавлении и модификации.

Проблема администрирования хранилищ предполагает исследование стандартных задач развертывания, миграции, разграничения полномочий, резервного копирования и восстановления, балансировки загрузки, поддержания живучести на достаточном для клиентов уровне готовности системы за счет репликации копий данных, хорошо известных в облачных технологиях. Их проработка существенно зависит от арендуемой инфраструктуры облака и функциональных возможностей предоставляемых провайдерами виртуальных машин и их программного обеспечения в рамках IaaS. Для транспортировки данных между клиентами и серверами федеративного хранилища можно использовать протоколы передачи на основе SOAP и REST.

На рисунке 1 приведена укрупненная схема, иллюстрирующая прохождение запроса в федеративном хранилище.

Рисунок 1 — Укрупнённая схема функционирования хранилища Формирование заказа на передачу данных получателем предполагает работу пользователя с редактором, позволяющим сформулировать требования к запрашиваемым данным со стороны пользователя в виде шаблонов, содержащих перечень данных и их формат. Требования формируются на основе метаданных о всей номенклатуре данных облачных сервисов, хранимых в репозитории системы.

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

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

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

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

Проектирование шаблона для отправителя данных предполагает создание XML Schema для отправки данных по сети заказчику.

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

Проектирование шаблона для получателя затребованных данных предполагает распаковку данных протокола транспортного уровня и передачи их заказчику.

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

Наиболее общими возможностями располагают средства языков программирования, например, Java для обработки XML-документов [2]. Java-разработчику для создания XML-приложений доступны не менее шести расширений Java-платформы:

• а) Java API для обработки XML (JAXP — Java API for XML Processing);
• б) Java API для связи XML с Java (JAXB — Java API for XML/Java Binding):
• в) Долгосрочная персистенция JavaBean-компонентов;
• г) Java API для обмена сообщениями XML (JAXM — (JAXM — Java API for XML Messaging);
• д) Java API для удаленного вызова процедур XML (JAX RPC — Java API for XML RPC);
• е) Java API для реестра XML (JAXR — Java API for XML Registry).

Базовые инструменты для работы с документами JAXP предоставляет разработчику Java и технологии для обработки XML документов, которые зависят от JAXP. Среди них:

• а) SAX — простой API для XML;
• б) DOM — программный интерфейс API объектной модели документа (Document Object Model) от консорциума W3C;
• в) XSLT — язык преобразований каскадной таблицы стилей XML от консорциума W3C;
• г) XPath — язык XML Path от консорциума W3C;
• д) JDOM — API оптимизированной объектной модели документа от jdom.org.

Веб-сервисы есть приложения сервера и приложения клиента, которые связываются через протокол World Wide Web (WWW) HyperText Transfer Protocol (HTTP). На концептуальном уровне, сервис является программным компонентом, доступным через конечную точку сети (endpoint). Потребитель и поставщик сервиса используют сообщения, чтобы обмениваться вызовами запросов и получения ответной информацией в форме самодостаточных документов, которые предполагают лишь некоторые допущения о технологических возможностях получателя [3].

На техническом уровне, веб-сервисы могут быть реализованы разными способами: JAX-WS веб-сервисы «Big» и JAX-RS веб-сервисы «RESTful» .

JAX-WS технология Java EE обеспечивает функциональность для сервисов, использующие сообщения Extensible Markup Language (XML), которые используются стандартом Simple Object Access Protocol (SOAP), определяющим архитектуру и форматы сообщений на языке XML. В таких системах часто машиночитаемое описание сервисных операций предлагается записывать на языке Web Services Description Language (WSDL) — варианте языка XML для синтаксического определения интерфейсов.

JAX-RS веб-сервисы на базе REST (REpresentational State Transfer — «RESTful») являются коллекциями сервисов, идентифицируемых своими URI. Каждый документ или процесс моделируется веб-ресурсом со своим уникальным URI. Эти веб-ресурсы управляются действиями, которые могут быть специфицированы в заголовке HTTP. Не используются ни стандарт SOAP, ни WSDL, ни стандарты WS. Вместо них обмен сообщениями может производиться в разных форматах: XML, JSON, HTML и др. Часто клиентом является веб-браузер. Технология в силу возможностей используемых транспортных протоколов не обеспечивает защиту транспортируемой информации от несанкционированного доступа, что является важной особенностью RESTful. RESTfull хорошо подходит для основных и оперативных (на лету) сценариев интеграции. Веб-сервисы RESTful часто лучше интегрированы в HTTP, чем SOAP-ориентированные сервисы.

Средства JAX-RS в Java EE обеспечивают функциональное назначение для сервиса RESTful. Они не требуют XML сообщений или определений WSDL сервиса. Проект JAX-RS — промышленная готовая реализация для JSR 311: JAX-RS: Java API для RESTful Web Services. JAX-RS осуществляет поддержку аннотаций, определенных в JSR-311, облегчая разработчикам формирование веб-сервисов RESTful для Java и Java Virtual Machine (JVM).

Для работы с XML документами консорциумом W3C разработан язык запросов XQuery [4], [5], специально ориентированный на извлечение данных из сложных структур документов.

На рынке информационных технологий существует широкий набор свободных и коммерческих процессоров для обработки XQuery: Zorba (http://sourceforge.net/projects/zorba/), Xqilla (http://xqilla. sourceforge.net/ HomePage) и другие. Полный список продуктов этой серии можно посмотреть на http://www.w3.org/XML/Query/#implementations. Примером свободного ПО для обработки запросов является Xqilla — процессор XQuery написанный на языке С++ и вызываемый в интерпретаторе командной строки: xqilla [options] .

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

Рисунок 2 — Архитектура сервиса хранения Репозиторий содержит описание всех доступных данных хранилища, содержащее следующие сведения:

• а) внутренний идентификатор записи репозитория;
• б) внешнее имя блока данных для идентификации пользователями;
• в) метаданные — комментарий содержимого блока данных, полей, формата, правил доступа и др.;
• г) тип хранимых данных: SQL, ключ-значение, XML-документ, файл и т. д.;
• д) адрес хранения;
• е) протокол доступа;
• ж) порт доступа;
• з) Login/Password/уровень доступа пользователей (чтение, запись);
• и) текст запроса по умолчанию и его параметры;
• к) XML-схема представления результата запроса;
• л) место обработки запроса: локальный узел пользовательской БД или центральный сервер;
• м) конвертор результата в XML-документ;
• н) владелец ресурса;
• о) цена единицы ресурса;
• п) дата обновления ресурса;
• р) объем ресурса;
• с) обработчик запроса GET;
• т) обработчик запроса POST;
• у) прочие сведения.