ГОСТ Р ИСО/МЭК 17826-2015 Информационные технологии. Интерфейс управления облачными данными (CDMI)

ГОСТ Р ИСО/МЭК 17826-2015

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информационные технологии

ИНТЕРФЕЙС УПРАВЛЕНИЯ ОБЛАЧНЫМИ ДАННЫМИ (CDMI)

Information technology. Cloud Data Management Interface (CDMI)

ОКС 35.040

Дата введения 2016-06-01

Предисловие

1 ПОДГОТОВЛЕН Обществом с ограниченной ответственностью "Информационно-аналитический вычислительный центр" (ООО "ИАВЦ") на основе собственного аутентичного перевода на русский язык международного стандарта, указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 22 "Информационные технологии"

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 29 мая 2015 г. N 467-ст

4 Настоящий стандарт идентичен международному стандарту ИСО/МЭК 17826:2012* "Информационные технологии. Интерфейс управления облачными данными (CDMI)" (ISO/IEC 17826:2012 "Information technology - Cloud Data Management Interface (CDMI)").
________________
* Доступ к международным и зарубежным документам, упомянутым здесь и далее по тексту, можно получить, перейдя по ссылке на сайт . - .


При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты Российской Федерации, сведения о которых приведены в дополнительном приложении ДА

5 ВВЕДЕН ВПЕРВЫЕ


Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомления и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

Введение

Введение

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

Настоящий стандарт состоит из следующих разделов:

1 Область применения

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

2 Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на следующие стандарты*. Предоставленные спецификации, не относящиеся к документам ИСО/МЭК, МЭК, ИСО и ITU, применимы лишь в контексте настоящего стандарта. Ссылка на эти документы не предоставляет им нового статуса в системе ИСО/МЭК. В частности, это не дает цитированным ссылкам статуса международного стандарта.
________________
* Таблицу соответствия национальных стандартов международным см. по ссылке. - .


ИСО 3166 Коды для представления названий стран и единиц их административно-территориального деления (части 1, 2 и 3) (ISO 3166, Codes for the representation of names of countries and their subdivisions)

ИСО 4217:2008 Коды для представления валют и фондов (ISO 4217:2008, Codes for the representation of currencies and funds)

ИСО 8601:2004 Элементы данных и форматы для обмена информацией. Обмен информацией. Представление дат и времени (ISO 8601:2004, Data elements and interchange formats - Information interchange - Representation of dates and times)

ИСО/МЭК 9594-8:2008 Информационные технологии. Взаимосвязь открытых систем. Директория. Часть 8. Структура сертификата на открытый ключ и атрибуты (ISO/IEC 9594-8:2008, Information technology - Open Systems Interconnection - The Directory: Publickey and attribute certificate frameworks)

ИСО/МЭК 14776-414 Информационные технологии. Интерфейс для малых вычислительных систем (SCSI). Часть 414. Структурная модель 4 (SAM-4) (ISO/IEC 14776-414, SCSI Architecture Model - 4 (SAM-4))

IEEE Std 1003.1, 2004, POSIX ERE Открытая группа, основные спецификации, Вып.6 (IEEE Std 1003.1, 2004, POSIX ERE, The Open Group, Base Specifications Issue 6) - //www.unix.org/version3/ieee_std.html

RFC 2045 Многоцелевые расширения почты для интернета (MIME) Часть 1. Формат тела письма в интернете (RFC 2045, Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies) - //www.ietf.org/rfc/rfc2045.txt

RFC 2119 Ключевые слова для обозначения уровня требований в RFC (RFC 2119, Key Words for Use in RFCs to Indicate Requirement Levels) - //tools.ietf.org/html/rfc2119

RFC 2246 Протокол TLS версии 1.0 (RFC 2246, The TLS Protocol Version 1.0) - //www.ietf.org/rfc/rfc2246.txt

RFC 2578 Структура управляющей информации, версия 2 (RFC 2578, Structure of Management Information Version 2, SMIv2) - //www.ietf.org/rfc/rfc2578.txt

RFC 2616 Протокол передачи гипертекста 1.1 (RFC 2616, Hypertext Transfer Protocol - HTTP/1.1) - //www.ietf.оrg/rfc/rfc2616.txt

RFC 2617 Аутентификация HTTP: Базовая аутентификация доступа и аутентификация доступа с использованием дайджеста (RFC 2617, HTTP Authentication: Basic and Digest Access Authentication) - //www.ietf.оrg/rfc/rfc2617.txt

RFC 3280 Профиль инфраструктуры открытых ключей Х.509 Интернета: сертификат и список отозванных сертификатов (RFC 3280, Internet Х.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile) - //www.ietf.org/rfc/rfc3280.txt

RFC 3530 Протокол сетевой файловой системы версии 4 (RFC 3530, Network File System (NFS) Version 4 Protocol) - //www.ietf.org/rfc/rfc3530.txt

RFC 3720 Интерфейс для малых вычислительных систем в интернете (RFC 3720, Internet Small Computer Systems Interface, iSCSI) - //www.ietf.org/rfc/rfc3720.txt

RFC 3986 Универсальный идентификатор ресурса: общий синтаксис (RFC 3986, Uniform Resource Identifier (URI): Generic Syntax) - //www.ietf.org/rfc/rfc3986.txt

RFC 4346 Протокол безопасности транспортного уровня, версия 1.1 (RFC 4346, The Transport Layer Security (TLS) Protocol Version 1.1) - //www.ietf.org/rfc/rfc4346.txt

RFC 4627 Тип медиа application/JSON для объектной нотации JavaScript (RFC 4627, The Application/JSON Media Type for JavaScript Object Notation (JSON)) - //www.ietf.org/rfc/rfc4627.txt

RFC 4648 Кодировки данных Base16, Base32, и Base64 (RFC 4648, The Base16, Base32, and Base64 Data Encodings) //www.ietf.org/rfc/rfc4648.txt

RFC 4918 Расширения HTTP для авторства и версионирования в сети Интернет (RFC 4918, HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)) - //www.ietf.org/rfc/rfc4918.txt

RFC 5246 Протокол безопасности транспортного уровня, версия 1.2 (RFC 5246, The Transport Layer Security (TLS) Protocol Version 1.2) - //www.ietf.org/rfc/rfc5246.txt

RFC 6208 Типы медиа для интерфейса управления облачными данными (RFC 6208, Cloud Data Management Interface (CDMI) Media Types) - //www.ietf.org/rfc/rfc6208.txt

3 Термины и определения

В настоящем стандарте применены следующие термины с соответствующими определениями:

3.1 список управления доступом (Access Control List) ACL: Постоянный список, состоящий из записей управления доступом (Access Control Entries, АСЕ), который перечисляет права доступа принципалов (пользователей и групп) к ресурсам.

3.2 CDMI: Интерфейс управления облачными данными.

3.3 CIFS: Единая файловая система для Интернета.

3.4 облачное хранение (cloud storage): См. "Хранение данных как служба".

3.5 CRC: Циклический избыточный код.

3.6 CRUD: Создать, получить, изменить, удалить (create, retrieve, update, delete).

3.7 хранение данных как служба (data storage as a Service) DaaS: Организация сетевых служб виртуализированного хранения и доступа к данным, основанная на требовании заданного уровня службы, что снимает границы масштабируемости; является самообеспечивающимся или не требующем обеспечения и оплачивается в зависимости потребления.

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

Примечание - Каждый объект CDMI принадлежит к единственному домену, и каждый домен содержит списки сопоставления имен пользователей и информацию об учетных записях.

3.9 целостность в конечном итоге (eventual consistency): Поведение транзактной системы, не предоставляющее гарантию связности в каждый момент времени, что улучшает доступность системы и ее устойчивость к распадению сети.

3.10 HTTP: Протокол передачи гипертекста.

3.11 инфраструктура как служба (Infrastructure as a Service) laaS: Предоставление по сети соответствующим образом сконфигурированного виртуального вычислительного окружения, основанное на запрошенном уровне услуг.

Примечание - Обычно laaS является самообеспечивающейся или не требующей обеспечения и оплачивается в зависимости потребления.*
________________
* Текст документа соответствует оригиналу. - .

3.12 iSCSI: Интерфейс для малых вычислительных систем в интернете (см. RFC 3720).

3.13 LUN: Номер логического устройства (см. ИСО/МЭК 14776-414).

3.14 MIME: Многоцелевые расширения для почты в интернете (см. RFC 2045)

3.15 NFS: Сетевая файловая система (см. RFC 3530).

3.16 объект (object): Сущность, имеющая идентификатор объекта (ID), уникальный URI, и обладающая состоянием.

Примечание - Существуют следующие типы объектов CDMI: объекты данных, контейнеры, опции, домены, очереди.

3.17 идентификатор объекта (object identifier): Глобально-уникальное значение, соотнесенное с объектом в момент его создания.

3.18 OCCI: Интерфейс открытых облачных вычислений (Open Cloud Computing Interface) (см. спецификацию OCCI).

3.19 платформа как служба PaaS (Platform as a Service): Предоставление по сети виртуализированной среды программирования, состоящей из развернутого стека приложения, основанного на виртуальной вычислительной среде.

Примечание - Обычно PaaS основана на laaS, является самообеспечивающейся или не требующей обеспечения и оплачивается в зависимости фактического использования.*
________________
* Текст документа соответствует оригиналу. - .

3.20 POSIX: Интерфейс переносимой операционной системы (Portable Operating System Interface) (см. IEEE Std 1003.1).

3.21 частное облако (private cloud): Предоставление SaaS, PaaS, laaS, и/или DaaS ограниченному числу пользователей, обычно принадлежащих к одной и той же организации.

Примечание - Частные облака создаются в целях безопасности.

3.22 общественное облако (public cloud): Предоставление SaaS, PaaS, laaS, и/или DaaS потенциально неограниченному количеству пользователей.

3.23 передача репрезентативного состояния (Representational State Transfer) REST: Особый набор принципов определения, адресации и взаимодействия с ресурсами, адресуемыми посредством URI (см. [REST]).

3.24 RPO: Целевая точка восстановления (recovery point objective).

3.25 RTO: Целевое время восстановления (recovery time objective).

3.26 уровень службы (service level): Целевые показатели производительности службы.

3.27 программы как служба (Software as a Service) SaaS: Предоставление по сети доступа к приложению по запросу.

3.28 тонкое резервирование (thin provisioning): Технология распределения физической емкости тома или файловой системы по мере записи данных приложением вместо предварительного резервирования.

3.29 универсальный идентификатор ресурса (Uniform Resource Identifier) URI: Короткая последовательность символов, идентифицирующая абстрактный или физический ресурс (см. RFC 3986).

3.30 виртуализация (virtualization): Представление ресурсов, как если бы они были физическими, тогда как на самом деле они отделены от базовых физических ресурсов.

3.31 WebDAV: Набор расширений и дополнений к протоколу HTTP, поддерживающих совместную работу пользователей над редактированием файлов и управление файлами на удаленных веб-серверах (см. RFC 4918).

3.32 ХАМ: Расширяемый метод доступа (eХtensible Access Method) (см. INCITS 464-2010).

4 Соглашения

4.1 Формат интерфейса

Каждое описание интерфейса состоит из девяти компонентов, описанных в таблице 1.


Таблица 1 - Формат интерфейса

4.2 Типографские соглашения

Все исходные тексты программ и сообщений показаны следующим шрифтом:

Пример -

PUT /MyContainer/MyDataObject.txt HTTP/1.1
Host: cloud.example.com
Accept: application/cdmi-object
Content-Type: application/cdmi-object
X-CDMI-Specification-Version: 1.0.2
{
"mimetype" : "text/plain",
"metadata" : {
},
"value" : "This is the Value of this Data Object"
}

4.3 Требования к телу сообщений запросов и ответов

В таблицах, представляющих тела запросов и ответов, колонка "Требования" содержит одно из трех значений:

- обязательное. Значение, описанное в данной строке, должно быть указано.

- условное. Если выполнены условия, указанные в ячейке "Описание" данной строки (слева от ячейки "Требования") то значение, описанное в данной строке, должно быть указано. В противном случае, оно может быть указано, если это не запрещено в Описании (в этом случае оно должно отсутствовать);

- необязательное. Значение, описанное в данной строке, может быть указано.

4.4 Требования к ключевым словам

В данном международном стандарте, ключевые слова, указанные в табл.2, должны интерпретироваться как указано в RFC 2119.


Таблица 2 - Требования к ключевым словам

5 Обзор облачного хранения

5.1 Введение

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

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

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

5.2 Что такое облачное хранение?

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

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

Таким образом, облачное хранение есть предоставление по запросу виртуализированного хранилища. Для обозначения этого используется формальный термин "Хранение данных как служба" (Data storage as a Service, DaaS).

5.3 Хранение данных как служба

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

Важная часть реализации любой системы DaaS - поддержка унаследованных клиентов. Эта поддержка включена в действующие стандартные протоколы, такие как iSCSI (и другие) для блочного и CIFS/NFS или WebDAV для файлового и сетевого хранения, как показано на рисунке 1.

Рисунок 1 - Существующие стандарты интерфейсов хранилищ данных

Рисунок 1 - Существующие стандарты интерфейсов хранилищ данных

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


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

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

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

Рисунок 2 - Интерфейсы хранилища для данных клиента объектного хранилища

Рисунок 2 - Интерфейсы хранилища для данных клиента объектного хранилища

5.4 Управление данными для облачного хранения

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

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

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

Пользовательские метаданные сохраняются в облаке и могут использоваться для поиска объектов данных и контейнеров с использованием поисковых запросов по значениям метаданных. Схема метаданных может определяться конкретным приложением, доменом или пользователем. Подробнее о поддержке пользовательских метаданных см. 16.2.

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

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

5.5 Управление данными и контейнерами

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

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

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

5.6 Эталонная модель интерфейсов облачного хранения

Эталонная модель облачного хранилища показана на рисунке 3.

Рисунок 3 - Эталонная модель облачного хранилища

Рисунок 3 - Эталонная модель облачного хранилища

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

Службы данных применяются к индивидуальным элементам данных в соответствии с метаданными системы данных. Метаданные определяют требования к данным на основании индивидуальных элементов или групп элементов (контейнеров).

5.7 Интерфейс управления облачными данными

Интерфейс управления облачными данными (CDMI), показанный на рисунке 3, может использоваться для создания, доступа, изменения или удаления объектов в облаке. Функции CDMI позволяют:

- клиентам определить набор опций, поддерживаемых реализацией облака;

- управлять контейнерами и данными в них;

- устанавливать метаданные для контейнеров и объектов данных в них.

Настоящий стандарт разделяет стандартные операции на два типа: использующие тип содержимого CDMI в теле HTTP и не использующие их. Несмотря на то, что многие данные доступны посредством операций обоих типов, предоставление и тех, и других операций позволяет взаимодействовать с провайдером CDMI как клиентам, поддерживающим CDMI, так и не поддерживающим CDMI.

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

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

Настоящий стандарт использует принципы REST в разработке интерфейса, насколько это возможно (см. [REST]).

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

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

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

Реализация облака может также поддерживать домены, позволяющие сопоставлять административные права владения хранимым объектам. Домены (наряду с другими возможностями) позволяют стандарту:

- определять соответствие пользовательских полномочий принципалами из списков контроля доступа (ACL);

- выдавать специальные привилегии, связанные с облаком;

- делегировать авторизацию пользователей внешней системе авторизации пользователей (например, LDAP или Active Directory).

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

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

Например, в 5.10, настоящий стандарт указывает, что "каждая облачная система хранения должна обеспечивать доступ к хранимым объектам по ID". Данное требование должно пониматься в контексте, что у функции доступа к ID объекта есть предусловие - наличие опции cdmi_object_access_by_ID.

5.8 Объектная модель для CDMI

Модель для CDMI показана на рисунке 4

Рисунок 4 - Модель объекта CDMI

Рисунок 4 - Модель объекта CDMI

В таблице 3 перечислены пять типов ресурсов. Содержание каждой конкретной операции зависит от типа ресурса.


Таблица 3 - Типы ресурсов в модели

Для операций хранения данных клиенту интерфейса достаточно информации о контейнерах и объектах данных. Реализации путей к данным должны поддерживать хотя бы один уровень контейнеров (см. 5.5). С использованием объектной модели CDMI (см. рисунок 4) клиент может отослать запрос PUT через CDMI (см. 5.6) с URI нового контейнера и создать новый контейнер с определенным именем. Метаданные контейнера опциональны и выражаются набором пар имя-значение. После создания контейнера клиент может отправить запрос PUT для создания объекта данных внутри нового контейнера. Последующий запрос GET выбирает объект данных, включая поле значения.

Определены также объекты очереди (см. рисунок 4) со специальными свойствами для упорядоченного, в дисциплине FIFO, создания и удаления значений. Подробнее см. в разделе 11.

CDMI определяет два пространства имен, которые могут использоваться для доступа к хранимым объектам: плоское пространство идентификаторов объектов и иерархическое пространство имен-путей. Поддержка доступа к объекту по ID выражается глобальной опцией cdmi_object_access_by_ID, а поддержка иерархических путей определяется опцией контейнера cdmi_create_dataobject, находящейся в корневом или вложенном контейнере.

Объекты создаются по ID выполнением команды HTTP POST с определенным URI, обозначаемым как /cdmi_objectid/ (см. 9.8). После создания клиенты могут объект командой PUT с указанием ID объекта, присвоенный сервером CDMI, используя /cdmi_objectid/ URI (см. 8.6)*. Этот URI используется также для извлечения и удаления объектов по ID.
___________________
* Текст документа соответствует оригиналу. - .


Объекты создаются по имени выполнением HTTP PUT с указанием URI пути (см. 8.2). После создания, объекты можно модифицировать, выполняя команды PUT с указанием пути к объекту, заданному клиентом (см. 8.6). То же самый URI используется для извлечения и удаления объектов*.
___________________
* Текст документа соответствует оригиналу. - .


CDMI определяет механизмы, позволяющие сопоставить путь в иерархическом пространстве объекту, имеющему лишь ID, а также позволяющие удалить путь, оставив только ID, у объекта, имеющего и путь, и ID. Это осуществляется с использованием модификатора перемещения для операций PUT или POST, как показано на рисунок 5.

Рисунок 5 - Диаграмма переходов объекта: добавление имени и удаление имени

Рисунок 5 - Диаграмма переходов объекта: добавление имени и удаление имени

5.9 Метаданные CDMI

CDMI использует много видов метаданных, включая метаданные HTTP, метаданные системы данных, пользовательские метаданные и метаданные системы хранения.

Метаданные HTTP - это метаданные, связанные с использованием протокола HTTP (например, Content-Length, Content-Type и др.). Метаданные HTTP не связаны с данным международным стандартом, но их необходимо обсудить для объяснения, как CDMI использует стандарт HTTP.

Метаданные системы данных CDMI, пользовательские метаданные и метаданные системы хранения определятся в форме пар имя-значение. Метаданные системы данных, определенные производителем, должны начинаться с обращенного доменного имени производителя.

Метаданные системы данных - это метаданные, определяемые клиентом CDMI, они входят в состав объекта. Метаданные системы данных абстрактно определяют требования к данным, связанные со службами данных, предоставляемыми облачным хранилищем.

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

Метаданные системы хранения - это метаданные, сгенерированные службами хранения системы (например, время создания или размер) для предоставления необходимой информации клиенту CDMI.

Матрица создания и использования метаданных системы хранения приведена в табл.4.


Таблица 4 - Создание-использование метаданных системы хранения

5.10 ID объекта

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

Каждая облачная система хранения должна предоставлять доступ к хранимым объектам по ID посредством добавления ID объекта к URI корневого контейнера. Если объект данных "MyDataObject.txt" имеет ID "00006FFD001001CCE3B2B4F602032653", следующая пара URI дает доступ к одному и тому же объекту данных:

//cloud.example.com/root/MyDataObject.txt

//cloud.example.com/root/cdmi_objectid/00006FFD001001CCE3B2B4F602032653

Если поддерживается работа с контейнерами, они также должны быть доступными по ID объекта. Если контейнер "MyContainer" имеет ID объекта "00006FFD0010AA33D8CEF9711E0835CA", следующие пары URI дают доступ к одному и тому же объекту данных:

//cloud.example.com/MyContainer/

//cloud.example.com/cdmi_objectid/00006FFD0010AA33D8CEF9711E0835CA/

//cloud.example.com/MyContainer/MyDataObject.txt

//cloud.example.com/cdmi_objectid/00006FFD0010AA33D8CEF9711E0835CA/MyDataObject.txt

5.11 Формат идентификатора объекта CDMI

Каждая реализация должна создавать ID объекта, однозначно идентифицирующий объект. ID объекта должен быть глобально-уникальным и должен отвечать формату, определенному на рисунке 6. Исходный формат ID объекта - строка байт переменной длины (максимум 40 байт). Приложение обращается с объектом ID как с непрозрачной байтовой строкой. Тем не менее, формат ID объекта определен так, что его целостность может быть проверена и независимые реализации могут независимо создавать уникальные ID Объектов.

Рисунок 6 - Формат ID объекта

Рисунок 6 - Формат ID объекта

Поля, показанные на рисунке 6, определены следующим образом:

- Зарезервированные байты должны быть нулевыми.

Поле номера организации - это код, присвоенный организации, чья реализация создает ID объекта, в спецификации SNMP, в сетевом порядке байтов. См. RFC 2578 и //www.iana.org/assignments/enterprise-numbers. Код 0 зарезервирован.

Байт со смещением 5 должен содержать длину ID в байтах.

Поле CRC должно содержать двухбайтовый (16-битный) CRC в сетевом порядке байтов. Это поле позволяет контролировать целостность ID объекта. Поле CRC должно заполняться выполнением алгоритма (см. [CRC]) по всем байтам ID объекта, определенным полем Длина, при обнуленном поле CRC. Вычисление CRC определяется набором параметров:

- Name : "CRC-16",

- Width : 16,

- Poly : 0x8005,

- Init : 0x0000,

- Refln : True,

- RefOut : True,

- XorOut : 0x0000, и

- Check : 0xBB3D.

Эта функция возвращает 16-битный CRC по полиному 0x8005, обращенным входом и обращенным результатом. Алгоритм вычисления CRC-16 определен в [CRC].

- Непрозрачные данные ID каждого объекта должны быть уникальными в пределах одного номера организации.

Исходный формат объекта ID - бинарный. При необходимости, например при включении в URI или строки JSON, текстовое представление ID объекта должно кодироваться на основе правил base 16, описанных в [RFC 4648] и не должно учитывать регистр.

5.12 Безопасность

В контексте CDMI безопасность относится к защитным мерам, применяемым при управлении и доступе к данным и хранилищу. В частности, система безопасности должна решать следующие задачи:

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

- предоставление механизма, позволяющего CDMI клиентам и серверам доказывать свою идентичность;

- предоставление механизма, позволяющего управлять разрешенными действиями CDMI клиента на CDMI сервере;

- предоставление механизма для записи действий, выполненных CDMI клиентом на CDMI сервере;

- предоставление механизмов защиты данных в фоновом режиме;

- предоставление механизмов контролируемого удаления данных;

- предоставление механизма для определения набора опций безопасности конкретной реализации.

Меры безопасности, включенные в CDMI, можно описать как:

- безопасная передача;

- аутентификация пользователей и сущностей;

- авторизация и контроль доступа;

- целостность данных;

- очистка данных и среды;

- удерживание данных;

- защита от вредоносных действий;

- шифрование данных в фоновом режиме;

- опции безопасности.

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

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

HTTP является обязательным механизмом передачи данных, a HTTP над TLS (то есть, HTTPS) является механизмом, используемым для безопасного взаимодействия между клиентами и сервером CDMI. Для обеспечения безопасности и совместимости, все реализации CDMI должны поддерживать протокол безопасности транспортного уровня (Transport Layer Security, TLS) как описано в приложении А, но его использование клиентами и сервером CDMI опционально.

5.13 Необходимая поддержка HTTP

5.13.1 Требования поддержки RFC 2616

Совместимая реализация CDMI должна также включать реализацию RFC2616 (см. [RFC 2616]) (т.е., HTTP 1.1). Перечисленные ниже примеры описывают некоторые части RFC 2616, которые должны поддерживаться, но этот список не является исчерпывающим.

5.13.2 Согласование типа содержимого

Для операций CDMI используются типы медиа CDMI объектов, определенные в [RFC 6208].

Клиент может опционально предоставлять заголовок HTTP Accept согласно 14.1 RFC 2616. Если клиент требует, чтобы в ответе содержался определенный тип медиа CDMI, соответствующий тип должен быть указан в заголовке Accept. Иначе, заголовок может содержать "*/*" или список типов, или быть опущен.

Если в сообщении-запросе присутствует тело, клиент должен включать заголовок Content-Type согласно пункту 14.17 RFC 2616. Если в таком случае клиент не предоставляет заголовок Content-Type содержимого или тип медиа в заголовке Content-Type не соответствует существующему типу ресурса, сервер должен вернуть код состояния HTTP 400 Bad Request.

Если в сообщении-ответе присутствует тело, сервер должен предоставить заголовок Content-Type.

Настоящий стандарт допускает дальнейшие согласования типа содержимого (например, в 9.3 отсутствие заголовка Content-Type несет особую информацию).

5.13.3 Поддержка диапазона

Сервер должен поддерживать заголовки HTTP Range и ответы с частичным содержимым (см. 14.16 RFC 2616).

5.13.4 Экранирование в URI

Ко всем строкам, использованным в URI, должно применяться экранирование зарезервированных символов знаком процента (%), определенное в RFC 3986. Это касается имен полей, предоставленных пользователем, имен метаданных, имен объектов, имен контейнеров и имен доменов, использованных в URI.

Имена и значения полей не должны экранироваться в телах сообщений запросов и ответов.

Пример - Клиент, получающий метаданные объекта "@user" из контейнера "@MyContainer", должен выполнить следующий запрос:

GET /%40MyContainer/?objectName;metadata:%40user HTTP/1.1
Host: cloud.example.com
Accept: application/cdmi-container
X-CDMI-Specification-Version: 1.0.2
В ответ должно быть получено:
НТТР/1.1 200 ОK
Content-Type: application/cdmi-container
X-CDMI-Specification-Version: 1.0.2
{
"objectName": "@MyContainer>,
"metadata": {
"@user": "test"
}
}

5.13.5 Использование URI

Формат и синтаксис URI определяются RFC 3986.

Каждый клиент CDMI должен поддерживать один или несколько корневых URI, чтобы каждый из них соответствовал корневому контейнеру сервера CDMI. Так как все URI контейнеров CDMI завершаются наклонной чертой, все корневые URI также завершаются наклонной чертой.

Все URI в данном международном* являются относительными (relative) URI, заданными относительно корневых URI, если не сказано иное. Таким образом, в качестве алгоритма разрешения URI используется алгоритм из пункта 5.2 RFC 3986.
___________________
* Текст документа соответствует оригиналу. - .


В таблице 5 приведено разрешение относительного URI по корневому URI.


Таблица 5 - Разрешение относительного URI по корневому URI

Настоящий стандарт не накладывает ограничений на корневые и относительные URI. Все примеры, приведенные в таблице 5, допустимы, используя корневой URI //cloud.example.com/ и возвращая ссылки на абсолютные пути, как показано во второй строке таблицу 5.

5.13.6 Зарезервированные символы

Имена объектов данных CDMI, контейнеров, очередей, доменов и объектов опций не могут содержать символы "/" и "?", так как они зарезервированы как разделители.

5.14 Представление времени

Если не указано иное, все значения даты/времени даются согласно расширенному представлению ИСО 8601:2004 (YYYY-MM-DDThh:mm:ss.ssssssZ). Должна быть указана полная точность, разделитель долей секунды "." (точка), должен быть включен индикатор пояса UTC Z UTC, и все отметки времени должны быть в часовом поясе UTC. Представление YYYY-MM-DDT24:00:00.000000Z не следует использовать, вместо этого следует использовать представление YYYY-MM-DDT00:00:00.000000Z.

Если не указано иное, все интервалы даты/времени должны быть в формате начальная дата/конечная дата в соответствии со стандартом ISO 8601:2004 (YYYY-MM-DDThh:mm:ss.ssssssZ/YYYY-MM-DDThh:mm:ss.ssssssZ). Конечная дата должна быть не раньше начальной даты. Должна быть указана полная точность, разделитель долей секунды "." (точка), должен быть включен индикатор пояса UTC Z UTC, и все отметки времени должны быть в часовом поясе UTC. Представление YYYY-MM-DDT24:00:00.000000Z не следует использовать, вместо этого следует использовать представление YYYY-MM-DDT00:00:00.000000Z.

5.15 Обратная совместимость

5.15.1 Кодировка значений для передачи

Стандарт CDMI версии 1.0.1 ввел концепцию кодировки значений для передачи, чтобы обеспечить опции хранения и получения произвольных бинарных данных через операции с типом содержимого CDMI. Объекты данных, созданные клиентами CDMI 1.0 посредством операций с типом содержимого CDMI, должны использовать кодировку "utf-8", а объекты, созданные другими операциями, должны использовать кодировку "base64".

Значения полей объектов данных в кодировке base64 не должны быть доступны клиентам CDMI 1.0 через операции с типом содержимого CDMI. Попытка чтения значения таких объектов должна возвращать таким клиентам пустой результат (" "). Клиенты CDMI 1.0 могут выявить такую ситуацию: в этом случае метаданные cdmi_size не равно 0, а значение поля пустое.

5.15.2 Опции экспорта контейнера

CDMI версии 1.0.2 упорядочивает имена опций, которые использует клиентом для определения, может ли контейнер экспортироваться через различные протоколы. Следующие имена опций экспорта контейнера более недействительны:

- cdmi_cifs_export,

- cdmi_nfs_export,

- cdmi_iscsi_export,

- cdmi_occi_export.

6 Обычные операции

6.1 Обзор

Все примеры, приведенные в настоящем стандарте, не являются нормативными.

Данный раздел включает примеры следующих типизованных операций СDMI:

- определение опций провайдера облачного хранилища (см. 6.2),

- создание нового контейнера (см. 6.3),

- создание нового объекта данных (см. 6.4),

- получение списка содержимого контейнера (см. 6.5),

- чтение содержимого объекта данных (см. 6.6),

- чтение только значения объекта данных (см. 6.7),

- удаление объекта данных (см. 6.8).

6.2 Определение опций провайдера облачного хранения

Пример - Выполнение GET к URI, по которому сервер публикует перечень опций:

GET /cdmi_capabilities/ HTTP/1.1
Host: cloud.example.com
Accept: application/cdmi-capability
X-CDMI-Specification-Version: 1.0.2
Будет получен следующий ответ.
HTTP/1.1 200 OK
Content-Type: application/cdmi-capability
X-CDMI-Specification-Version: 1.0.2
{
"objectType" : "application/cdmi-capability",
"objectID" : "00007E7F0010CEC234AD9E3EBFE9531D",
"objectName" : "cdmi_capabilities/",
"parentURI" : "/",
"parentID" : "00007E7F0010DCECC805FB6D195DDBCB",
"capabilities" : {
"cdmi_domains" : "true",
"cdmi_export_nfs" : "true",
"cdmi_export_webdav" : "true",
"cdmi_export_iscsi" : "true",
"cdmi_queues" : "true",
"cdmi_notification": "true",
"cdmi_query" : "true",
"cdmi_metadata_maxsize" : "4096",
"cdmi_metadata_maxitems" : "1024",
"cdmi_size": "true",
"cdmi_list_children" : "true",
"cdmi_read_metadata" : "true",
"cdmi_modify_metadata" : "true",
"cdmi_create_container" : "true",
"cdmi_delete_container" : "true"
},
"childrenrange" : "0-3",
"children" : [
"domain/",
"container/",
"dataobject/",
"queue/"
]
}

6.3 Создание нового контейнера

Пример - Выполнение PUT с URI нового контейнера:

PUT /MyContainer/HTTP/1.1
Host: cloud.exampie.com
Accept: application/cdmi-container
Content-Type: application/cdmi-container
X-CDMI-Specification-Version: 1.0.2
{
"metadata" : {
}
}
Будет получен следующий ответ.
HTTP/1.1 201 Created
Content-Type: application/cdmi-container
X-CDMI-Specification-Version: 1.0.2
{
"objectType" : "application/cdmi-container",
"objectID" : "00007E7F00102E230ED82694DAA975D2",
"objectName" : "MyContainer/",
"parentURI" : "/",
"parentID" : "00007E7F0010128E42D87EE34F5A6560",
"domainURI" : "/cdmi_domains/MyDomain/",
"capabilitiesURI" : "/cdmi_capabilities/container/",
"completionStatus" : "Complete",
"metadata" : {
"cdmi_size" : "0"
},
"childrenrange" :" ",
"children" : [

]
}

6.4 Создание объекта данных в контейнере

Пример - Выполнение PUT с URI нового объекта данных:
PUT /МуContainer/MyDataObject.txt HTTP/1.1
Host: cloud.example.com
Accept: application/cdmi-object
Content-Type: application/cdmi-object
X-CDMI-Specification-Version: 1.0.2
{
"mimetype" : "text/plain",
"metadata" : {
},
"value" : "Hello CDMI World!"
}
Будет получен следующий ответ.
HTTP/1.1 201 Created
Content-Type: application/cdmi-object
X-CDMI-Specification-Version: 1.0.2
{
"objectType" : "application/cdmi-object",
"objectID" : "00007E7F0010BD1CB8FF1823CF05BEE4",
"objectName" : "MyDataObject.txt",
"parentURI" : "/MyContainer/",
"parentID" : "00007E7F00102E230ED82694DAA975D2",
"domainURI" : "/cdmi_domains/MyDomain/",
"capabilitiesURI" : "/cdmi_capabilities/dataobject/",
"completionStatus" : "Complete",
"mimetype" : "text/plain",
"metadata": {
"cdmi_size" : "17"
}
}

6.5 Список содержимого контейнера

Пример - Выполнение GET с URI контейнера:

GET/MyContainer/ HTTP/1.1
Host: cloud.example.com
Accept: */*
X-CDMI-Specification-Version: 1.0.2
Будет получен следующий ответ.
HTTP/1.1 200 OK
Content-Type: application/cdmi-container
X-CDMI-Specification-Version: 1.0.2
{
"objectType" : "application/cdmi-container",
"objectID" : "00007E7F00102E230ED82694DAA975D2",
"objectName" : "MyContainer/",
"parentURI" : "/",
"parentID" : "00007E7F0010128E42D87EE34F5A6560",
"domainURI" : "/cdmi_domains/MyDomain/",
"capabilitiesURI" : "/cdmi_capabilities/container/",
"completionStatus" : "Complete",
"metadata" : {
"cdmi_size" : "83"
},
"childrenrange" : "0-0",
"children" : [
"MyDataObject.txt"
]
}

6.6 Чтение содержимого объекта данных

Пример - GET по URI объекта данных:

GET /МуContainer/MyDataObject.txt HTTP/1.1
Host: cloud.example.com
Accept: application/cdmi-object
X-CDMI-Specification-Version: 1.0.2
Будет получен следующий ответ.
HTTP/1.1 200 OK
Content-Type: application/cdmi-object
X-CDMI-Specification-Version: 1.0.2
{
"objectType": "application/cdmi-object",
"objectID": "00007E7F0010BD1CB8FF1823CF05BEE4",
"objectName": "MyDataObject.txt",
"parentURI": "/MyContainer/",
"parentID" : "00007E7F00102E230ED82694DAA975D2",
"domainURI": "/cdmi_domains/MyDomain/",
"capabilitiesURI": "/cdmi_capabilities/dataobject/",
"completionStatus": "Complete",
"mimetype": "text/plain",
"metadata": {
"cdmi_size": "17"
},
"valuetransferencoding": "utf-8",
"valuerange": "0-16",
"value": "Hello CDMI World!"
}

6.7 Чтение только значения объекта данных

Пример - Выполнение GET с URI объекта данных:

GET /MyContainer/MyDataObject.txt HTTP/1.1
Host: cloud.example.com
Будет получен следующий ответ.
НТТР/1.1 200 ОK
Content-Type: text/plain
Hello CDMI World!

6.8 Удаление объекта данных

Пример - Выполнение DELETE с URI объекта данных:

DELETE /MyContainer/MyDataObject.txt HTTP/1.1
Host: cloud.example.com
X-CDMI-Specification-Version: 1.0.2
Будет получен следующий ответ.
HTTP/1.1 204 No Content

7 Стандарт интерфейса

7.1 Коды состояния HTTP

Коды состояния HTTP (см. таблицу 6) используются для передачи результата операций REST и выполнения базовой семантики HTTP с минимальной перегрузкой. Другие коды состояния HTTP не являются частью настоящего стандарта и сохраняют оригинальную семантику HTTP 1.1.


Таблица 6 - Коды состояния HTTP

7.2 Ссылки на объект

Ссылки на объект - это URI в пространстве имен облачного хранилища, переадресующие на другой URI в том же или другом пространстве имен облачного хранилища. Ссылки подобны символическим ссылкам файловой системы. Облако не гарантирует, что URI, на который дана ссылка, будет корректен после создания ссылки.

Ссылки отображаются как дочерние элементы контейнера и отличаются от других объектов завершающим символом "?" в имени. Выполнение операции (за исключением создания или удаления) по URI ссылки приведет к переадресации HTTP 302 Found; поле заголовка Location будет содержать URI назначения, указанный в момент создания ссылки. URI назначения ссылки не должен меняться после создания ссылки.

Для продолжения операции после получении переадресации 302 Found клиент CDMI должен повторить запрос с использованием URI, содержащегося в заголовке Location.

Операция удаления по URI ссылки должна удалить ссылку. Ссылки не могут обновляться. Для обновления адреса назначения клиент должен вначале удалить имеющуюся ссылку, а затем создать новую с желаемым адресом назначения переадресации.

Пример - Применение GET к URI, где URI - ссылка:

GET /MyContainer/MyDataObject.txt HTTP/1.1
Host: cloud.example.com
Accept: application/cdmi-object
X-CDMI-Specification-Version: 1.0.2
Будет получен следующий ответ.
HTTP/1.1 302 Found
Location: //cloud.example.com/MyContainer/MyOtherDataObject.txt

Ссылки на ID объекта должны всегда переадресовывать на URI, завершающийся тем же ID, что и URI запроса.

Пример - Применение GET к URI объекта по ID, где URI - ссылка:

GET /cdmi_objectid/00006FFD0010AA33D8CEF9711E0835CA HTTP/1.1
Host: cloud.example.com
Accept: application/cdmi-object
X-CDMI-Specification-Version: 1.0.2
Будет получен следующий ответ.
HTTP/1.1 302 Found
Location: //archive.example.com/cdmi_objectid/00006FFD0010AA33D8CEF9711E0835CA

8 Операции с ресурсами объекта данных

8.1 Обзор

Объекты данных - основной компонент хранения в системе CDMI, аналогичный файлам в файловой системе. Каждый объект данных состоит из набора определенных полей, включающих:

- единственное значение (value)

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

Объекты данных в CDMI могут адресоваться двумя способами:

- по имени (например, //cloud.example.com/dataobject);

- по ID объекта (например, //cloud.example.com/cdmi_objectid/0000706D0010B84FAD185C425D8B537E).

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

Каждый объект данных имеет родительский объект, от которого он наследует метаданные, которые не заданы явным образом для рассматриваемого объекта. Так, объект "budget.xls", хранящийся по следующему URI, наследует метаданные системы данных своего родительского контейнера "finance":

//cloud.example.com/finance/budget.xls

Для доступа к отдельным полям объекта данных необходимо указать имя поля после символа "?", добавляемого к URI объекта данных. Например, следующий URI возвращает значение поля value в сообщении-ответе:

//cloud.example.com/dataobject?value

Кодировка данных, передаваемых из поля value объекта данных, определяется значением поля valuetransferencoding этого объекта.

Если кодировка значения установлена в "utf-8", данные в поле value объекта должны быть корректной строкой UTF-8, и должны передаваться в поле value как строка UTF-8.

Если кодировка значения установлена в "base64", данные в поле value объекта могут быть произвольной бинарной последовательностью и должны передаваться как строка в кодировке base 64.

Отдельный диапазон значения объекта может быть получен указанием диапазона байтов после имени поля. Например, следующий URI возвращает первые 1000 байт поля value:

//cloud.example.com/dataobject?value:0-999

Так как диапазон байтов строки UTF-8 не всегда является корректной строкой UTF-8, ответ на запрос с обозначенными границами диапазона передается как строка в кодировке base 64. Аналогично, при изменении диапазона байтов значения поля объекта, содержимое поля должно передаваться как строка в кодировке base 64.

Диапазон байтов включает границы диапазона, как указано в п.14.35.1 RFC 2616.

Допускается указание списка уникальных полей, разделенных символом ";", что позволяет обратиться к нескольким полям в одном запросе. Например, следующий URI возвращает поля value и metadata в сообщении-ответе:

//cloud.example.com/dataobject?value;metadata

Если клиент создает поля, не определенные в настоящем стандарте, или десериализует объект, содержащий поля, не описанные в данном международном стандарте, эти поля должны храниться как часть объекта, но не должны интерпретироваться.

8.1.1 Метаданные объекта данных

Метаданные объекта данных могут также включать произвольные метаданные, определенные пользователем, и метаданные системы данных, см. гл.16. Метаданные следует хранить как корректную строку UTF-8. Бинарные данные, сохраненные в пользовательских метаданных, должны быть вначале перекодированы таким образом, чтобы их можно было включить в корректную строку UTF-8; рекомендуется использовать кодировку base 64.

8.1.2 Согласованность объекта данных

Запись в объект данных является атомарной операцией.

Если клиент читает данные из объекта одновременно с операцией записи данных в тот же объект, чтение должно возвращать либо старое значение, либо новое, но не их смесь.

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

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

Записи в диапазон могут привести к промежутку в значении объекта, не содержащему записанных данных. Чтение из промежутка с отсутствующими данными должно выдавать нуль в каждом прочитанном байте.

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

8.1.3 Представления объекта данных

В данном разделе используется нотация JSON. И клиенты, и серверы должны поддерживать представление UTF-8 JSON. В теле сообщения-запроса и сообщения-ответа поля объекта JSON могут обозначаться или возвращаться в любом порядке, за исключением (в случае их наличия) полей valuerange и value объекта данных, которые должны появляться последними и в указанном порядке.

8.2 Создание объекта данных с использованием типа содержимого CDMI

8.2.1 Обзор

Для создания нового объекта данных следует выполнить запрос:

PUT <root URI>/<ContainerName>/<DataObjectName>

Создание нового объекта по ID, см. 9.9.

где:

- <root URI> путь к облаку CDMI.

- <ContainerName> неотрицательное число промежуточных уже существующих контейнеров, с наклонной чертой "/", разделяющей каждую пару контейнеров.

- <DataObjectName> имя создаваемого объекта данных.

После создания к объекту можно обращаться как <root URI>/cdmi_objectid/<objectlD>.

8.2.2 Отложенное завершение создания

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

- сервер вернет заголовок Location с URI создаваемого объекта вместе с кодом HTTP 202 Accepted;

- код 202 Accepted от сервера означает, что были пройдены следующие проверки:

- пользователь авторизован создавать объект;

- пользователь авторизован считывать любые источники, которые должны быть скопированы, перемещены, сериализованы или десериализованы

- доступно достаточно места для создания объекта, или, по крайней мере, достаточно места, чтобы создать URI и сообщение об ошибке.

- Клиент, возможно, не сможет немедленно обратиться к создаваемому объекту, например, из-за задержек вследствие использования в данной реализации целостности в конечном итоге.

Клиент выполняет операции GET по указанному URI для отслеживания хода выполнения операции. В ответ сервер возвращает два поля в теле сообщения-ответа, указывающие на состояние процесса:

- обязательное текстовое поле completionStatus содержит "Processing", "Complete", либо сообщение об ошибке, начинающееся с "Error";

- опциональное поле percentComplete, содержащее процент выполнения операции (от 0 до 100).

GET не должен возвращать никакого значения в объект, если его статус не completionStatus ="Complete". Если конечный результат операции создания - ошибка, то создается URI с полем completionStatus, содержащим сообщение об ошибке. Удаление URI после обнаружения ошибки - обязанность клиента.

8.2.3 Опции

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

- поддержка функции создания нового объекта данных обозначена наличием в родительском контейнере опции cdmi_create_dataobject;

- если создаваемый объект - ссылка в родительском контейнере, поддержка этой функции обозначена наличием в родительском контейнере опции cdmi_create_reference;

- если новый объект должен быть копией существующего объекта, поддержка этой функции обозначена наличием в родительском контейнере опции cdmi_copy_dataobject;

- если создаваемый объект - результат перемещения существующего объекта, поддержка этой функции обозначена наличием в родительском контейнере опции cdmi_move_dataobject;

- если создаваемый объект - результат операции десериализации исходного объекта, поддержка этой функции обозначена наличием в родительском контейнере опции cdmi_deserialize_dataobject;

- если новый объект - результат операции сериализации, поддержка этой функции обозначена присутствием в родительском контейнере опций cdmi_serialize_dataobject, cdmi_serialize_container, cdmi_serialize_domain или cdmi_serialize_queue.

8.2.4 Заголовки запроса

Заголовки запроса HTTP для создания объекта CDMI с типом содержимого CDMI приведены в таблице 7.


Таблица 7 - Заголовки запроса для создания объекта данных CDMI с типом содержимого CDMI

8.2.5 Тело сообщения-запроса

Поля запроса на создание объекта с использованием типа содержимого CDMI приведены в таблице 8.


Таблица 8 - Тело сообщения-запроса - создание объекта данных с использованием типа содержимого CDMI

___________________
* Текст документа соответствует оригиналу. - .

8.2.6 Заголовки ответа

Заголовки HTTP ответов на создание объекта с использованием типа содержимого CDMI указаны в таблице 9.


Таблица 9 - Заголовки ответа - создание объекта данных с использованием типа содержимого CDMI

8.2.7 Тело сообщения-ответа

Поля тела сообщения-ответа на создание объекта данных с использованием типа содержимого CDMI приведены в таблице 10.


Таблица 10 - Тело сообщения-ответа - создание объекта данных с использованием типа содержимого CDMI

8.2.8 Статус ответа

Коды состояния HTTP, возникающего при создании объекта данных с использованием типа содержимого CDMI, перечислены в таблице 11.


Таблица 11 - Коды состояния HTTP - создание объекта данных с использованием типа содержимого CDMI

8.2.9 Примеры

Примеры

1 Применение PUT к URI контейнера: имя объекта данных и текстовое содержимое:

PUT /MyContainer/MyDataObject.txt HTTP/1.1
Host: cloud.example.com
Accept: application/cdmi-object
Content-Type: application/cdmi-object
X-CDMI-Specification-Version: 1.0.2
{
"mimetype" : "text/plain",
"metadata" : {
},
"value" : "This is the Value of this Data Object"
}
Будет получен следующий ответ.
HTTP/1.1 201 Created
Content-Type: application/cdmi-object
X-CDMI-Specification-Version: 1.0.2
{
"objectType" : "application/cdmi-object",
"objectID" : "0000706D0010B84FAD185C425D8B537E",
"objectName" : "MyDataObject.txt",
"parentURI" : "/MyContainer/",
"parentID" : "00007E7F00102E230ED82694DAA975D2",
"domainURI" : "/cdmi_domains/MyDomain/",
"capabilitiesURI" : "/cdmi_capabilities/dataobject/",
"completionStatus" : "Complete",
"mimetype" : "text/plain",
"metadata" : {
"cdmi_size" : "37"
}
}

2 Применение PUT к URI контейнера: имя объекта данных и бинарное содержимое:

PUT /MyContainer/MyDataObject.txt HTTP/1.1
Host: cloud.example.com
Accept: application/cdmi-object
Content-Type: application/cdmi-object
X-CDMI-Specification-Version: 1.0.2
{
"mimetype" : "text/plain",
"metadata" : { },
"valuetransferencoding" : "base64",
"value" : "VGhpcyBpcyB0aGUgVmFsdWUgb2YgdGhpcyBEYXRhlE9iamVjdA=="
}
Будет получен следующий ответ.
HTTP/1.1 201 Created
Content-Type: application/cdmi-object
X-CDMI-Specification-Version: 1.0.2
{
"objectType": "application/cdmi-object",
"objectID": "0000706D0010374085EF1A5C7018D774",
"objectName": "MyDataObject.txt",
"parentURI": "/MyContainer/",
"parentID" : "00007E7F00102E230ED82694DAA975D2",
"domainURI": "/cdmi_domains/MyDomain/",
"capabilitiesURI": "/cdmi_capabilities/dataobject/",
"completionStatus": "Complete",
"mimetype": "text/plain",
"metadata": {
"cdmi_size": "37"
}
}

8.3 Создание объекта данных с использованием типа содержимого, отличного от CDMI

8.3.1 Обзор

Для создания объекта данных следует выполнить следующий запрос:

PUT <root URI>/<ContainerName>/<DataObjectName> 2

где:

- <root URI> путь к облаку CDMI;

- <ContainerName> неотрицательное число уже существующих промежуточных контейнеров, разделенных наклонной чертой (т.е., "/");

- <DataObjectName> имя создаваемого объекта данных.

После создания к объекту данных можно обращаться как <root URI>/cdmi_objectid/<objectlD>.

8.3.2 Опции

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

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

8.3.3 Заголовки запроса

Заголовки HTTP запроса на создание объекта данных CDMI с использованием типа содержимого, отличного от CDMI, приведены в таблице 12.


Таблица 12 - Заголовки запроса - создание объекта данных CDMI с использованием типа содержимого, отличного от CDMI