ГОСТ Р ИСО/МЭК 17826-2015. Национальный стандарт Российской Федерации. Информационные технологии. Интерфейс управления облачными данными (CDMI)
Актуально на 01.11.2026.
Как цитировать: "ГОСТ Р ИСО/МЭК 17826-2015. Национальный стандарт Российской Федерации. Информационные технологии. Интерфейс управления облачными данными (CDMI)". ГОСТ Р ИСО/МЭК 17826-2015. https://bukva.ai/docs/gost-r-isomek-17826-2015
(утв. и введен в действие Приказом Росстандарта от 29.05.2015 № 467-ст)
Примечание
Документ введен в действие с 1 июня 2016 года.
Утвержден и введен в действие
Приказом Федерального агентства
по техническому регулированию
и метрологии
от 29 мая 2015 г. № 467-ст
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
ИНТЕРФЕЙС УПРАВЛЕНИЯ ОБЛАЧНЫМИ ДАННЫМИ (CDMI)
Information technology. Cloud Data Management Interface (CDMI)
ISO/IEC 17826:2012 Information technology Cloud Data Management Interface (CDMI) (IDT)
Предисловие
1 ПОДГОТОВЛЕН Обществом с ограниченной ответственностью «Информационно-аналитический вычислительный центр» (ООО «ИАВЦ») на основе собственного аутентичного перевода на русский язык международного стандарта, указанного в пункте 4
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 22 «Информационные технологии»
3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 29 мая 2015 г. № 467-ст
4 Настоящий стандарт идентичен международному стандарту ИСО/МЭК 17826:2012 «Информационные технологии. Интерфейс управления облачными данными (CDMI)» (ISO/IEC 17826:2012 «Information technology — Cloud Data Management Interface (CDMI)»).
При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты Российской Федерации, сведения о которых приведены в дополнительном приложении ДА
Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомления и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)
Введение
Настоящий стандарт CDMITM предназначен для использования разработчиками приложений, использующих облачное хранение данных. Он документирует доступ к облачному хранилищу и управление данными, хранящимися там.
Настоящий стандарт состоит из следующих разделов:
| 1 - Область применения | Определяет основные задачи данного документа |
|---|---|
| 2 - Нормативные ссылки | Перечисляет ссылки на нормативные документы, связанные с данным документом |
| 3 - Термины и определения | Устанавливает терминологию, используемую в данном документе |
| 4 - Соглашения | Определяет формат описания интерфейсов и типографические соглашения, принятые в данном документе |
| 5 - Обзор облачного хранения | Дает краткое описание облачного хранения и основные предпосылки, лежащие в основе настоящего стандарта как модели операций |
| 6 - Обычные операции | Дает пример ресурсов, к которым может быть предоставлен доступ, и представления, используемые для их изменения |
| 7 - Стандарт интерфейса | Описывает коды состояния HTTP, типы объектов интерфейса управления облачными данными (CDMI), ссылки на объекты и операции с объектами |
| 8 - Операции с ресурсами объекта данных | Определяет стандартные операции с ресурсами объектов данных |
| 9 - Операции с ресурсами вида объект — контейнер | Определяет стандартные операции с ресурсами объектов-контейнеров |
| 10 - Операции с ресурсами объекта-домена | Определяет стандартные операции с ресурсами объектов-доменов |
| 11 - Операции с ресурсами объекта передачи | Определяет стандартные операции с ресурсами объектов очередей |
| 12 - Операции с ресурсами объекта-опции | Определяет стандартные операции с ресурсами объектов-опций |
| 13 - Экспортируемые протоколы | Обсуждает возможные сценарии использования виртуальными машинами облачных вычислительных сред протоколов, экспортированных контейнерами CDMI. |
| 14 - Снимки состояния | Обсуждает доступ к снимкам состояния через контейнеры CDMI |
| 15 - Сериализация/десериализация | Обсуждает сериализацию и десериализацию, включая импорт и экспорт сериализованных данных в рамках CDMI |
| 16 - Метаданные | Определяет стандартные метаданные, используемые в интерфейсе |
| 17 - Управление отложенным удалением и удержанием | Описывает необязательные процедуры управления отложенным удалением, реализуемые в функциях системы управления |
| 18 - Спецификация условий запросов | Описывает структуру спецификации условий запросов в нотации JSON |
| 19 - Спецификация результатов | Описывает стандартизированные механизмы определения подмножеств содержимого объекта CDMI |
| 20 - Ведение журналов событий | Описывает функции ведения журналов событий CDMI для функций объектов, событий безопасности, событий управления данными и очередей |
| 21 - Очереди сообщений | Описывает, как клиенты CDMI могут эффективно обнаружить изменения системы |
| 22 - Очереди запросов | Описывает, как клиенты CDMI могут эффективно обнаружить, какое содержание соответствует заданному набору критериев запроса метаданных или критерию поиска по всем полям метаданных |
| Приложение A - (обязательное) Безопасность передачи | Определяет требования к обеспечению безопасной передачи данных по протоколу HTTP для передачи CDMI сообщений |
| Приложение ДА - (справочное) | Приложение ДА (справочное) Сведения о соответствии ссылочных международных стандартов национальным стандартам Российской Федерации |
| Библиография |
1. Область применения
Настоящий стандарт CDMITM описывает интерфейс доступа к облачному хранилищу и управления хранимой там информацией. Настоящий стандарт предназначен для разработчиков, использующих или внедряющих облачное хранение данных.
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) - http://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) - http://www.ietf.org/rfc/rfc2045.txt
RFC 2119 Ключевые слова для обозначения уровня требований в RFC (RFC 2119, Key Words for Use in RFCs to Indicate Requirement Levels) - http://tools.ietf.org/html/rfc2119
RFC 2246 Протокол TLS версии 1.0 (RFC 2246, The TLS Protocol Version 1.0) - http://www.ietf.org/rfc/rfc2246.txt
RFC 2578 Структура управляющей информации, версия 2 (RFC 2578, Structure of Management Information Version 2, SMIv2) - http://www.ietf.org/rfc/rfc2578.txt
RFC 2616 Протокол передачи гипертекста 1.1 (RFC 2616, Hypertext Transfer Protocol -- HTTP/1.1) - http://www.ietf.org/rfc/rfc2616.txt
RFC 2617 Аутентификация HTTP: Базовая аутентификация доступа и аутентификация доступа с использованием дайджеста (RFC 2617, HTTP Authentication: Basic and Digest Access Authentication) - http://www.ietf.org/rfc/rfc2617.txt
RFC 3280 Профиль инфраструктуры открытых ключей X.509 Интернета: сертификат и список отозванных сертификатов (RFC 3280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile) - http://www.ietf.org/rfc/rfc3280.txt
RFC 3530 Протокол сетевой файловой системы версии 4 (RFC 3530, Network File System (NFS) Version 4 Protocol) - http://www.ietf.org/rfc/rfc3530.txt
RFC 3720 Интерфейс для малых вычислительных систем в интернете (RFC 3720, Internet Small Computer Systems Interface, iSCSI) - http://www.ietf.org/rfc/rfc3720.txt
RFC 3986 Универсальный идентификатор ресурса: общий синтаксис (RFC 3986, Uniform Resource Identifier (URI): Generic Syntax) - http://www.ietf.org/rfc/rfc3986.txt
RFC 4346 Протокол безопасности транспортного уровня, версия 1.1 (RFC 4346, The Transport Layer Security (TLS) Protocol Version 1.1) - http://www.ietf.org/rfc/rfc4346.txt
RFC 4627 Тип медиа application/JSON для объектной нотации JavaScript (RFC 4627, The Application/JSON Media Type for JavaScript Object Notation (JSON)) - http://www.ietf.org/rfc/rfc4627.txt
RFC 4648 Кодировки данных Base16, Base32, и Base64 (RFC 4648, The Base16, Base32, and Base64 Data Encodings) http://www.ietf.org/rfc/rfc4648.txt
RFC 4918 Расширения HTTP для авторства и версионирования в сети Интернет (RFC 4918, HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)) - http://www.ietf.org/rfc/rfc4918.txt
RFC 5246 Протокол безопасности транспортного уровня, версия 1.2 (RFC 5246, The Transport Layer Security (TLS) Protocol Version 1.2) - http://www.ietf.org/rfc/rfc5246.txt
RFC 6208 Типы медиа для интерфейса управления облачными данными (RFC 6208, Cloud Data Management Interface (CDMI) Media Types) - http://www.ietf.org/rfc/rfc6208.txt
3. Термины и определения
В настоящем стандарте применены следующие термины с соответствующими определениями:
3.1 список управления доступом (Access Control List) ACL: Постоянный список, состоящий из записей управления доступом (Access Control Entries, ACE), который перечисляет права доступа принципалов (пользователей и групп) к ресурсам.
3.2 CDMITM: Интерфейс управления облачными данными.
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) IaaS: Предоставление по сети соответствующим образом сконфигурированного виртуального вычислительного окружения, основанное на запрошенном уровне услуг.
Примечание - Обычно IaaS является самообеспечивающейся или не требующей обеспечения и оплачивается в зависимости потребления.
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 основана на IaaS, является самообеспечивающейся или не требующей обеспечения и оплачивается в зависимости фактического использования.
3.20 POSIX: Интерфейс переносимой операционной системы (Portable Operating System Interface) (см. IEEE Std 1003.1).
3.21 частное облако (private cloud): Предоставление SaaS, PaaS, IaaS, и/или DaaS ограниченному числу пользователей, обычно принадлежащих к одной и той же организации.
Примечание - Частные облака создаются в целях безопасности.
3.22 общественное облако (public cloud): Предоставление SaaS, PaaS, IaaS, и/или 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 XAM: Расширяемый метод доступа (eXtensible Access Method) (см. INCITS 464-2010).
4. Соглашения
4.1. Формат интерфейса
Каждое описание интерфейса состоит из девяти компонентов, описанных в таблице 1.
4.2. Типографские соглашения
Все исходные тексты программ и сообщений показаны следующим шрифтом:
PUT /MyContainer/MyDataObject.txt HTTP/1.1
Accept: application/cdmi-object
Content-Type: application/cdmi-object
X-CDMI-Specification-Version: 1.0.2
«value» : «This is the Value of this Data Object»
4.3. Требования к телу сообщений запросов и ответов
В таблицах, представляющих тела запросов и ответов, колонка «Требования» содержит одно из трех значений:
- обязательное. Значение, описанное в данной строке, должно быть указано.
- условное. Если выполнены условия, указанные в ячейке «Описание» данной строки (слева от ячейки «Требования») то значение, описанное в данной строке, должно быть указано. В противном случае, оно может быть указано, если это не запрещено в Описании (в этом случае оно должно отсутствовать);
- необязательное. Значение, описанное в данной строке, может быть указано.
4.4. Требования к ключевым словам
В данном международном стандарте, ключевые слова, указанные в табл. 2, должны интерпретироваться как указано в RFC 2119.
5. Обзор облачного хранения
5.1. Введение
При обсуждении облачного хранения и стандартов важно различать ресурсы, предлагаемые как службы. Эти ресурсы открыты пользователям как функциональные интерфейсы (например, пути к данным) и управляются интерфейсами управления (например, пути управления). Настоящий стандарт представляет различные типы интерфейсов, которые входят в состав существующих реализаций, и указывает, как они взаимосвязаны. Настоящий стандарт определяет модель интерфейсов, которая может быть отражена на различные реализации, и модель, которая послужит основой для интерфейсов облачного хранения в будущем.
Другая важная концепция, заложенная в данном международном стандарте — метаданные. При управлении большими объемами данных с различными требованиями, метаданные — удобный механизм для выражения этих требований таким образом, что нижележащие службы данных могут обращаться с данными в соответствии с требованиями.
Привлекательность использования облачного хранения определяется рядом характеристик, общих с другими облачными службами: оплата по факту использования, кажущаяся неограниченной емкость (эластичность) и простота использования/управления. Поэтому важно, чтобы любой интерфейс облачного хранения поддерживал данные характеристики, тем самым обеспечивая реализацию множества сценариев использования.
5.2. Что такое облачное хранение?
Использование термина «облако» связано с тем, что эти новые модели произошли от графического представления архитектур, использующих облако как символ сети. Облако абстрактно обозначает связь любого компьютера сети с любым другим компьютером. В этой абстракции сетевое соединение в облаке не определяет, как именно оно устанавливается.
Облако абстрагирует сложность, предоставляя простую основу для построения новых функций. Обобщенная облачная модель расширяет эту основу посредством добавления набора ресурсов. Важная часть облачной модели — концепция пула ресурсов, который при необходимости создается из небольших фрагментов. Это стало возможным благодаря сравнительно недавней инновации — виртуализации.
Таким образом, облачное хранение есть предоставление по запросу виртуализированного хранилища. Для обозначения этого используется формальный термин «Хранение данных как служба» (Data storage as a Service, DaaS).
5.3. Хранение данных как служба
Абстрагирование хранения данных от набора интерфейсов служб и предоставление его по запросу допускает большое количество конкретных реализаций и сценариев работы. Единственный тип хранения, который исключается из данного определения — тот, который предоставляется на основе фиксированных приращений, а не основанный на запросах.
Важная часть реализации любой системы DaaS — поддержка унаследованных клиентов. Эта поддержка включена в действующие стандартные протоколы, такие как iSCSI (и другие) для блочного и CIFS/NFS или WebDAV для файлового и сетевого хранения, как показано на рисунке 1.
Различие между приобретением обычного устройства и облачного хранилища состоит не в функциональных интерфейсах, а в том, что в последнем случае хранилище предоставляется по запросу. Пользователь платит либо за то, чем фактически пользуется, либо за то, что запросил для использования. В случае блочного хранилища размер запрошенного объема измеряется в виртуальных томах или номерах логического устройства (LUN). В случае файловых протоколов, единицей измерения является файл. В любом случае, действительный объем хранилища может быть тонко зарезервирован и оплачен исходя из действительного использования. Для дальнейшего снижения фактически используемого объема могут использоваться такие службы данных, такие как сжатие или удаление дубликатов.
Управление таким хранилищем в случае стандартных интерфейсов хранения данных обычно осуществляется через API или (чаще) через пользовательский интерфейс администратора в браузере по выделенному каналу связи. Этот интерфейс по выделенному каналу связи может использоваться для запуска других служб данных (например, создания моментального снимка состояния или клонирования).
В рамках такой модели фактическое хранилище, доступ к которому реализуется посредством интерфейса по выделенному каналу связи, абстрагируется концепцией контейнера. Контейнер — не только полезная абстракция места хранения, он также служит для группировки хранимых данных и точкой управления для применения служб данных к такой группе.
Каждый объект данных создается, получается, обновляется и уничтожается как отдельный ресурс. В этом интерфейсе контейнер, если он используется, служит для удобства, группируя объекты данных. Ничто не препятствует создавать иерархические контейнеры, хотя каждая конкретная реализация может поддерживать лишь единственный уровень (см. рисунок 2).
5.4. Управление данными для облачного хранения
Многие из первых реализаций облачного хранилища фокусировались на хранении данных с минимальными гарантиями качества хранения и игнорировали большинство других типов служб данных. Однако, учитывая нужды корпоративных приложений, использующих облачное хранение, существует необходимость совершенствовать качество предоставления услуг и внедрять дополнительные службы данных.
Облачное хранение может потерять свои преимущества абстрактности и простоты, если появятся новые службы данных, требующие сложного управления. Клиенты облачных хранилищ, вероятно, будут не согласны тратить время на дополнительные операции (например, настраивать через специализированные интерфейсы резервное копирование по расписанию, разворачивать службу данных индивидуально для каждого элемента данных).
Поддержка метаданных в интерфейсе облачного хранилища и указание, как система хранения и ее метаданные интерпретируются для соблюдения требований к данным, могут сохранить простоту облачного хранения и при этом реализовать необходимые для корпоративных приложений функции.
Пользовательские метаданные сохраняются в облаке и могут использоваться для поиска объектов данных и контейнеров с использованием поисковых запросов по значениям метаданных. Схема метаданных может определяться конкретным приложением, доменом или пользователем. Подробнее о поддержке пользовательских метаданных см. 16.2.
Метаданные системы хранения формируются/интерпретируются реализацией облака и низкоуровневыми функциями хранилища (например, статистика изменения и доступа, управление доступом). Подробнее о поддержке метаданных системы хранения см. 16.3.
Метаданные системы данных интерпретируются реализацией облака как требования к данным, которые управляют операциями соответствующих служб данных. Это может относиться к объединению данных в контейнере или к индивидуальным объектам данных, если реализация поддерживает такую детализацию. Подробнее о поддержке метаданных системы данных см. 16.4.
5.5. Управление данными и контейнерами
Нет причины, по которой управление данными и контейнерами должно осуществляться различными интерфейсами.
Поэтому использование метаданных расширяется от применения к индивидуальным элементам данных на контейнеры данных. Таким образом, любые данные, помещенные в контейнер, наследуют метаданные системы данных контейнера, в который они помещаются. При создании нового контейнера внутри существующего контейнера, новый контейнер наследует настройки метаданных родительского контейнера. После создания элемента данных, отдельные метаданные системы данных могут быть перекрыты метаданными, заданными на уровне контейнера или индивидуального элемента данных.
Даже если предоставляемый интерфейс не поддерживает установку метаданных для индивидуальных элементов, метаданные могут быть настроены для контейнеров. В этом случае, интерфейс не предоставляет механизма для перекрывания метаданных, которые индивидуальный элемент наследует от родительского контейнера. Для интерфейсов, основанных на файлах, поддерживающих расширенные атрибуты (например, CIFS, NFSv4), эти атрибуты могут быть использованы для указания на то, что метаданные системы данных должны перекрыть метаданные контейнера.
5.6. Эталонная модель интерфейсов облачного хранения
Эта модель показывает множество типов интерфейсов облачного хранения, способных поддерживать как существующие, так и новые приложения. Все эти интерфейсы позволяют предоставлять хранилище данных из пула ресурсов по запросу. Емкость хранилища определяется емкостями пулов хранилищ, предоставляемых службами хранения.
Службы данных применяются к индивидуальным элементам данных в соответствии с метаданными системы данных. Метаданные определяют требования к данным на основании индивидуальных элементов или групп элементов (контейнеров).
5.7. Интерфейс управления облачными данными
Интерфейс управления облачными данными (CDMITM), показанный на рисунке 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
| Metadata Children | \ | 0..* / | \ | 0..* / | \ | 0..* / | Children | |||||||||||
| /\ | ||||||||||||||||||
| Контейнер | Объект данных | Объект-очередь | ||||||||||||||||
| Key/Value | Key/Value | Key/Value capabi | litiesURL | |||||||||||||||
| Metadata Children | Metadata Value | Metadata Value | ||||||||||||||||
| Объекты-домены | ||||||||||||||||||
| domainURI 1 | 0..* | |||||||||||||||||
| Сводка Членство | потомок | |||||||||||||||||
| Потомки | ||||||||||||||||||
Рисунок 4 — Модель объекта CDMI
В таблице 3 перечислены пять типов ресурсов. Содержание каждой конкретной операции зависит от типа ресурса.
| Тип ресурса | Описание | Ссылка |
|---|---|---|
| Объекты данных | Объекты данных служат для хранения значений и предоставляют функциональность аналогичную файлам в файловой системе. | См. раздел 8 |
| Объекты-контейнеры | Контейнер имеет неотрицательное количество дочерних объектов, но не хранит значений. Их функциональность аналогична папкам файловой системы. | См. раздел 9 |
| Объекты-домены | Домены выражают административные группы пользователей для их аутентификации и учета использования ресурсов. | См. раздел 10 |
| Объекты-очереди | Очереди хранят неотрицательное число значений, доступ к которым осуществляется по принципу «первый пришел — первый ушел». | См. раздел 11 |
| Объекты опций | Объекты опций описывают функциональность, реализованную сервером CDMI и используются клиентом для обнаружения поддерживаемой функциональности | См. раздел 12 |
Для операций хранения данных клиенту интерфейса достаточно информации о контейнерах и объектах данных. Реализации путей к данным должны поддерживать хотя бы один уровень контейнеров (см. 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.9. Метаданные CDMI
CDMI использует много видов метаданных, включая метаданные HTTP, метаданные системы данных, пользовательские метаданные и метаданные системы хранения.
Метаданные HTTP — это метаданные, связанные с использованием протокола HTTP (например, Content-Length, Content-Type и др.). Метаданные HTTP не связаны с данным международным стандартом, но их необходимо обсудить для объяснения, как CDMI использует стандарт HTTP.
Метаданные системы данных CDMI, пользовательские метаданные и метаданные системы хранения определятся в форме пар имя-значение. Метаданные системы данных, определенные производителем, должны начинаться с обращенного доменного имени производителя.
Метаданные системы данных — это метаданные, определяемые клиентом CDMI, они входят в состав объекта. Метаданные системы данных абстрактно определяют требования к данным, связанные со службами данных, предоставляемыми облачным хранилищем.
Пользовательские метаданные состоят из определенных клиентом строк, массивов и объектов в нотации JSON, сохраненных в поле метаданных. Пространство имен для пользовательских метаданных является самоуправляемым (например, использует обращенное имя домена), причем имена пользовательских метаданных не должны начинаться с префикса «cdmi_».
Метаданные системы хранения — это метаданные, сгенерированные службами хранения системы (например, время создания или размер) для предоставления необходимой информации клиенту CDMI.
Матрица создания и использования метаданных системы хранения приведена в табл 4.
Создание-использование метаданных системы хранения
| Тип метаданных | Созданные пользователем | Созданные системой |
|---|---|---|
| Используемые пользователем | Пользовательские метаданные | Метаданные системы хранения |
| Используемые системой | Метаданные системы данных | N/A |
5.10. ID объекта
Каждому объекту, хранимому в CDMI-совместимой системе, в момент создания ставится в соответствие глобально-уникальный идентификатор объекта (ID). ID объекта CDMI — это строка, на которую накладываются требования, обеспечивающие ее правильное создание и уникальность. Каждая реализация CDMI способна создавать уникальные идентификаторы, не конфликтуя с другими реализациями.
Каждая облачная система хранения должна предоставлять доступ к хранимым объектам по ID посредством добавления ID объекта к URI корневого контейнера. Если объект данных «MyDataObject.txt» имеет ID «00006FFD001001CCE3B2B4F602032653», следующая пара URI дает доступ к одному и тому же объекту данных:
http://cloud.example.com/root/cdmi_objectid/00006FFD001001CCE3B2B4F602032653
Если поддерживается работа с контейнерами, они также должны быть доступными по ID объекта. Если контейнер «MyContainer» имеет ID объекта «00006FFD0010AA33D8CEF9711E0835CA», следующие пары URI дают доступ к одному и тому же объекту данных:
http://cloud.example.com/cdmi_objectid/00006FFD0010AA33D8CEF9711E0835CA/
http://cloud.example.com/cdmi_objectid/00006FFD0010AA33D8CEF9711E0835CA/MyDataObject.txt
5.11. Формат идентификатора объекта CDMI
Каждая реализация должна создавать ID объекта, однозначно идентифицирующий объект. ID объекта должен быть глобально-уникальным и должен отвечать формату, определенному на рисунке 6. Исходный формат ID объекта — строка байт переменной длины (максимум 40 байт). Приложение обращается с объектом ID как с непрозрачной байтовой строкой. Тем не менее, формат ID объекта определен так, что его целостность может быть проверена и независимые реализации могут независимо создавать уникальные ID Объектов.
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | ... | 38 | 39 |
| Зарезервировано (ноль) | Номер организации | Зарезервировано (ноль) | Длина | CRC | Непрозрачные данные | ||||||||
Поля, показанные на рисунке 6, определены следующим образом:
Поле номера организации — это код, присвоенный организации, чья реализация создает ID объекта, в спецификации SNMP, в сетевом порядке байтов. См. RFC 2578 и http://www.iana.org/assignments/enterprise-numbers. Код 0 зарезервирован.
Байт со смещением 5 должен содержать длину ID в байтах.
Поле CRC должно содержать двухбайтовый (16-битный) CRC в сетевом порядке байтов. Это поле позволяет контролировать целостность ID объекта. Поле CRC должно заполняться выполнением алгоритма (см. [CRC]) по всем байтам ID объекта, определенным полем Длина, при обнуленном поле CRC. Вычисление CRC определяется набором параметров:
Эта функция возвращает 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 является обязательным механизмом передачи данных, а HTTP над TLS (то есть, HTTPS) является механизмом, используемым для безопасного взаимодействия между клиентами и сервером CDMI. Для обеспечения безопасности и совместимости, все реализации CDMI должны поддерживать протокол безопасности транспортного уровня (Transport Layer Security, TLS) как описано в приложении A, но его использование клиентами и сервером 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
Accept: application/cdmi-container
X-CDMI-Specification-Version: 1.0.2
Content-Type: application/cdmi-container
X-CDMI-Specification-Version: 1.0.2
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.
Разрешение относительного URI по корневому URI
Настоящий стандарт не накладывает ограничений на корневые и относительные URI. Все примеры, приведенные в таблицу 5, допустимы, используя корневой URI http://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 упорядочивает имена опций, которые использует клиентом для определения, может ли контейнер экспортироваться через различные протоколы. Следующие имена опций экспорта контейнера более недействительны:
6. Обычные операции
6.1. Обзор
Все примеры, приведенные в настоящем стандарте, не являются нормативными.
Данный раздел включает примеры следующих типизованных операций CDMI:
- определение опций провайдера облачного хранилища (см. 6.2),
- создание нового контейнера (см. 6.3),
- создание нового объекта данных (см. 6.4),
- получение списка содержимого контейнера (см. 6.5),
- чтение содержимого объекта данных (см. 6.6),
- чтение только значения объекта данных (см. 6.7),
- удаление объекта данных (см. 6.8).
6.2. Определение опций провайдера облачного хранения
Пример - Выполнение GET к URI, по которому сервер публикует перечень опций:
GET /cdmi_capabilities/ HTTP/1.1
Accept: application/cdmi-capability
X-CDMI-Specification-Version: 1.0.2
Будет получен следующий ответ.
Content-Type: application/cdmi-capability
X-CDMI-Specification-Version: 1.0.2
«objectType» : «application/cdmi-capability»,
«objectID» : «00007E7F0010CEC234AD9E3EBFE9531D»,
«objectName» : «cdmi_capabilities/»,
«parentID» : «00007E7F0010DCECC805FB6D195DDBCB»,
«cdmi_export_webdav» : «true»,
«cdmi_metadata_maxsize» : «4096»,
«cdmi_metadata_maxitems» : «1024»,
«cdmi_list_children» : «true»,
«cdmi_read_metadata» : «true»,
«cdmi_modify_metadata» : «true»,
«cdmi_create_container» : «true»,
«cdmi_delete_container» : «true»
6.3. Создание нового контейнера
Пример - Выполнение PUT с URI нового контейнера:
Accept: application/cdmi-container
Content-Type: application/cdmi-container
«objectType» : «application/cdmi-container»,
«capabilitiesURI» : «/cdmi_capabilities/container/»,
6.4. Создание объекта данных в контейнере
Пример - Выполнение PUT с URI нового объекта данных:
PUT /MyContainer/MyDataObject.txt HTTP/1.1
Accept: application/cdmi-object
Content-Type: application/cdmi-object
X-CDMI-Specification-Version: 1.0.2
Будет получен следующий ответ.
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»,
6.5. Список содержимого контейнера
Пример - Выполнение GET с URI контейнера:
X-CDMI-Specification-Version: 1.0.2
Будет получен следующий ответ.
Content-Type: application/cdmi-container
X-CDMI-Specification-Version: 1.0.2
«objectType» : «application/cdmi-container»,
«objectID» : «00007E7F00102E230ED82694DAA975D2»,
«objectName» : «MyContainer/»,
«parentID» : «00007E7F0010128E42D87EE34F5A6560»,
«domainURI» : «/cdmi_domains/MyDomain/»,
«capabilitiesURI» : «/cdmi_capabilities/container/»,
«completionStatus» : «Complete»,
6.6. Чтение содержимого объекта данных
Пример - GET по URI объекта данных:
GET /MyContainer/MyDataObject.txt HTTP/1.1
Accept: application/cdmi-object
X-CDMI-Specification-Version: 1.0.2
Будет получен следующий ответ.
Content-Type: application/cdmi-object
X-CDMI-Specification-Version: 1.0.2
«objectType»: «application/cdmi-object»,
«objectID»: «00007E7F0010BD1CB8FF1823CF05BEE4»,
«objectName»: «MyDataObject.txt»,
«parentID» : «00007E7F00102E230ED82694DAA975D2»,
«domainURI»: «/cdmi_domains/MyDomain/»,
«capabilitiesURI»: «/cdmi_capabilities/dataobject/»,
«completionStatus»: «Complete»,
«valuetransferencoding»: «utf-8»,
6.7. Чтение только значения объекта данных
Пример - Выполнение GET с URI объекта данных:
GET /MyContainer/MyDataObject.txt HTTP/1.1
Будет получен следующий ответ.
6.8. Удаление объекта данных
Пример - Выполнение DELETE с URI объекта данных:
DELETE /MyContainer/MyDataObject.txt HTTP/1.1
X-CDMI-Specification-Version: 1.0.2
Будет получен следующий ответ.
7. Стандарт интерфейса
7.1. Коды состояния HTTP
Коды состояния HTTP (см. таблицу 6) используются для передачи результата операций REST и выполнения базовой семантики HTTP с минимальной перегрузкой. Другие коды состояния HTTP не являются частью настоящего стандарта и сохраняют оригинальную семантику HTTP 1.1.
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
Accept: application/cdmi-object
X-CDMI-Specification-Version: 1.0.2
Будет получен следующий ответ.
Location: http://cloud.example.com/MyContainer/MyOtherDataObject.txt
Ссылки на ID объекта должны всегда переадресовывать на URI, завершающийся тем же ID, что и URI запроса.
Пример - Применение GET к URI объекта по ID, где URI — ссылка:
GET/cdmi_objectid/00006FFD0010AA33D8CEF9711E0835CA HTTP/1.1
Accept: application/cdmi-object
X-CDMI-Specification-Version: 1.0.2
Будет получен следующий ответ.
Location: http://archive.example.com/cdmi_objectid/00006FFD0010AA33D8CEF9711E0835CA
8. Операции с ресурсами объекта данных
8.1. Обзор
Объекты данных — основной компонент хранения в системе CDMITM, аналогичный файлам в файловой системе. Каждый объект данных состоит из набора определенных полей, включающих:
- единственное значение (value)
- опциональные метаданные, генерируемые системой облачного хранения и/или пользователем системы.
Объекты данных в CDMI могут адресоваться двумя способами:
- по имени (например, http://cloud.example.com/dataobject);
- по ID объекта (например, http://cloud.example.com/cdmi_objectid/0000706D0010B84FAD185C425D8B537E).
Каждый объект данных включает единственный, глобально-уникальный идентификатор объекта (ID), который остается неизменным на протяжении времени жизни объекта. Каждый объект данных имеет один или несколько адресов URI, позволяющих обращаться к объекту.
Каждый объект данных имеет родительский объект, от которого он наследует метаданные, которые не заданы явным образом для рассматриваемого объекта. Так, объект «budget.xls», хранящийся по следующему URI, наследует метаданные системы данных своего родительского контейнера «finance»:
http://cloud.example.com/finance/budget.xls
Для доступа к отдельным полям объекта данных необходимо указать имя поля после символа «?», добавляемого к URI объекта данных. Например, следующий URI возвращает значение поля value в сообщении-ответе:
http://cloud.example.com/dataobject?value
Кодировка данных, передаваемых из поля value объекта данных, определяется значением поля valuetransferencoding этого объекта.
Если кодировка значения установлена в «utf-8», данные в поле value объекта должны быть корректной строкой UTF-8, и должны передаваться в поле value как строка UTF-8.
Если кодировка значения установлена в «base64», данные в поле value объекта могут быть произвольной бинарной последовательностью и должны передаваться как строка в кодировке base 64.
Отдельный диапазон значения объекта может быть получен указанием диапазона байтов после имени поля. Например, следующий URI возвращает первые 1000 байт поля value:
http://cloud.example.com/dataobject?value:0-999
Так как диапазон байтов строки UTF-8 не всегда является корректной строкой UTF-8, ответ на запрос с обозначенными границами диапазона передается как строка в кодировке base 64. Аналогично, при изменении диапазона байтов значения поля объекта, содержимое поля должно передаваться как строка в кодировке base 64.
Диапазон байтов включает границы диапазона, как указано в п. 14.35.1 RFC 2616.
Допускается указание списка уникальных полей, разделенных символом «;», что позволяет обратиться к нескольким полям в одном запросе. Например, следующий URI возвращает поля value и metadata в сообщении-ответе:
http://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 Обзор
Для создания нового объекта данных следует выполнить запрос:
Создание нового объекта по ID, см. 9.9.
путь к облаку CDMI. неотрицательное число промежуточных уже существующих контейнеров, с наклонной чертой «/», разделяющей каждую пару контейнеров. имя создаваемого объекта данных.
После создания к объекту можно обращаться как
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.
| Заголовок | Тип | Описание | Требование |
|---|---|---|---|
| Accept | Строка заголовка | «application/cdmi-object» или допустимое значение в соответствии с 5.13.2 | Опционально |
| Content-Type | Строка заголовка | «application/cdmi-object» | Обязательно |
| X-CDMI-SpecificationVersion | Строка заголовка | Разделенный запятыми список версий, поддерживаемых клиентом, например, «1.0.2, 1.5, 2.0» | Обязательно |
| X-CDMI-Partial | Строка заголовка | «true» указывает на то, что новый объект является частью набора операций записи, и что его значение еще заполнено не полностью. Если присутствует X-CDMI-Partial, поле completionStatus в теле ответа будет выставлено в «Processing». | Опционально |
8.2.5 Тело сообщения-запроса
Поля запроса на создание объекта с использованием типа содержимого CDMI приведено в таблице 8.
| Имя поля | Тип | Описание | Требование |
| mimetype | Строка JSON | Тип данных MIME, содержащихся в поле value объекта данных Данное поле может добавляться при создании по значению, также при сериализации, десериализации, копировании или перемещении объекта данных. Данное поле должно храниться как часть объекта. Если данное поле не указано, ему должно быть присвоено значение «text/ plain». Это поле не должно добавляться при создании ссылки. Перед сохранением значение типа MIME должно быть преобразовано в нижний регистр. | Опционально |
| metadata | Объект JSON | Метаданные объекта данных Если данное поле включено при десериализации, сериализации, копировании или перемещении объекта данных, его значение заменяет метаданные из URI источника. Если данное поле не включается при десериализации, сериализации, копировании или перемещении объекта данных, должны использоваться метаданные URI источника. Если данное поле включается при создании нового объекта данных по передаваемому значению, значение данного поля должно быть использовано как метаданные. Если данное поле не включается при создании нового объекта данных по значению, данному полю должен быть присвоен пустой объект JSON (т.е. «{}»). Данное поле не должно включаться при создании ссылки. | Опционально |
| domainURI | Строка JSON | URI домена-владельца Если домен-владелец не совпадает с родительским доменом, пользователь должен иметь права cross_domain privilege (см. cdmi_member_privileges в таблице 64). |Если не указано иное, должен использоваться домен родительского контейнера. | Опционально |
| deserialize | Строка JSON | URI сериализованного объекта данных CDMI, который должен быть десериализован в создаваемый объект данных | Опционально a |
| serialize | Строка JSON | URI объекта CDMI, который должен быть сериализован в создаваемый объект данных | Опционально a |
| copy | Строка JSON | URI объекта данных или очереди CDMI, которые должны быть скопированы в создаваемый объект данных | Опционально a |
| move | Строка JSON | URI существующего локального или удаленного объекта данных CDMI (URI источника), который должен быть перенесен в URI, указанного в команде PUT. Содержимое объекта, включая ID, должно при перемещении сохраняться, а объект по URI источника должен быть удален после успешного создания нового объекта. Если недостаточно прав для чтения объекта данных по URI источника, записи объекта по URI назначения или удаления объекта данных по URI источника, или если любая из этих операций не завершена успешно, операция перемещения должна вернуть состояние ошибки 400 Bad Request, а исходный и новый объект должны остаться неизменными. | Опционально a |
| reference | Строка JSON | URI объекта данных CDMI, на который должна быть создана ссылка. Если при создании ссылки предоставляются какие-либо другие поля, сервер должен вернуть сообщение об ошибке HTTP 400 Bad Request. | Опционально a |
| deserializevalue | Строка JSON | Объект данных, сериализованный в соответствии с гл. 15 и кодированный с использованием правил base 64 (см. RFC 4648). | Опционально a |
| valuetransferencoding | Массив JSON строк JSON | Кодировка, использованная значения объекта данных. Определены два значения кодировки. «utf-8» указывает на то, что объект данных содержит корректную строку UTF-8, и должен передаваться как строка UTF-8 в поле value. «base64» указывает на то, что объект данных содержит произвольную бинарную последовательность и должен передаваться в поле value как строка в кодировке base 64. Задание содержимого поля value объекта данных иное, чем корректная строка в кодировке base 64, должно возвращать клиенту ошибку 400 Bad Request. Данное поле должно включаться лишь при создании объекта по значению. Если иное не указано клиентом, сервер должен установить значение поля valuetransferencoding равным «utf-8». Данное поле должно храниться как часть объекта. | Опционально |
| value | Строка JSON | Значение объекта данных Если данное поле не включено, ему должна быть присвоена пустая строка (т.е., «»). Если поле valuetransferencoding указывает на кодировку UTF-8, значение должно быть строкой UTF-8, сформированной по правилам JSON (RFC 4627). Если поле valuetransferencoding указывает на кодировку base 64, значение должно быть вначале кодировано в base 64 (RFC 4648). | Опционально a |
| a В каждой отдельной операции должно указываться лишь одно из этих полей. За исключением value, эти поля не должны храниться. Если имеется более одного такого поля, сервер должен вернуть сообщение об ошибке 400 Bad Request. | |||
8.2.6 Заголовки ответа
Заголовки HTTP ответов на создание объекта с использованием типа содержимого CDMI указаны в таблице 9.
8.2.7 Тело сообщения-ответа
Поля тела сообщения-ответа на создание объекта данных с использованием типа содержимого CDMI приведены в таблице 10.
| Имя поля | Тип | Описание | Требование |
|---|---|---|---|
| objectType | JSON String | «application/cdmi-object» | Обязательно |
| objectID | JSON String | ID объекта | Обязательно |
| objectName | JSON String | Имя объекта | Обязательно |
| parentURI | JSON String | URI родительского объекта Присоединение objectName к parentURI должно всегда давать корректный URI объекта. |
Обязательно |
| parentID | JSON String | ID родительского контейнера | Обязательно |
| domainURI | JSON String | URI домена-владельца | Обязательно |
| capabilitiesURI | JSON String | URI опций для объекта | Обязательно |
| completionStatus | JSON String | Строка, показывающая статус создания объекта данных. Принимает одно из следующих значений «Processing» указывает на то, что объект находится в процессе создания. «Completed» указывает на успешное создание объекта данных. Строка, начинающаяся с «Error» указывает на то, что при создании объекта возникла ошибка. |
Обязательно |
| percentComplete | JSON String | Если значение completionStatus равно «Processing», данное поле, при наличии, должно показывать процент выполнения операции создания объекта числовым значением от 0 до 100. Если значение completionStatus равно «Complete», данное поле, при наличии, должно иметь значение «100». Если значение completionStatus начинается с «Error», данное поле, при наличии, может содержать любое целое число от 0 до 100. |
Опционально |
| mimetype | JSON String | Тип MIME значения объекта данных | Обязательно |
| metadata | JSON Object | Метаданные объекта данных. Данное поле включает любые пользовательские метаданные или метаданные системы данных, указанные в соответствующем поле тела запроса на создание, наряду с метаданными системы хранения, созданными облачным хранилищем. См. детальное описание метаданных в разделе 16. | Обязательно |
8.2.8 Статус ответа
Коды состояния HTTP, возникающего при создании объекта данных с использованием типа содержимого CDMI, перечислены в таблице 11.
Коды состояния HTTP — создание объекта данных с использованием типа содержимого CDMI
8.2.9 Примеры
X-CDMI-Specification-Version: 1.0.2
«value» : «This is the Value of this Data Object»
Будет получен следующий ответ.
Content-Type: application/cdmi-object
«parentURI» : «/MyContainer/»,
«parentID» : «00007E7F00102E230ED82694DAA975D2»,
«domainURI» : «/cdmi_domains/MyDomain/»,
«capabilitiesURI» : «/cdmi_capabilities/dataobject/»,
«completionStatus» : «Complete»,
2 Применение PUT к URI контейнера: имя объекта данных и бинарное содержимое:
PUT /MyContainer/MyDataObject.txt HTTP/1.1
Accept: application/cdmi-object
Content-Type: application/cdmi-object
X-CDMI-Specification-Version: 1.0.2
«valuetransferencoding» : «base64»,
«value» : «VGhpcyBpcyB0aGUgVmFsdWUgb2YgdGhpcyBEYXRhlE9iamVjdA==»
Будет получен следующий ответ.
Content-Type: application/cdmi-object
X-CDMI-Specification-Version: 1.0.2
«objectType»: «application/cdmi-object»,
«objectID»: «0000706D0010374085EF1A5C7018D774»,
«objectName»: «MyDataObject.txt»,
«parentID» : «00007E7F00102E230ED82694DAA975D2»,
«domainURI»: «/cdmi_domains/MyDomain/»,
«capabilitiesURI»: «/cdmi_capabilities/dataobject/»,
«completionStatus»: «Complete»,
8.3. Создание объекта данных с использованием типа содержимого, отличного от CDMI
8.3.1 Обзор
неотрицательное число уже существующих промежуточных контейнеров, разделенных наклонной чертой (т.е., «/»);
После создания к объекту данных можно обращаться как
8.3.2 Опции
Следующие опции описывают поддерживаемые операции, которые можно выполнять при создании нового объекта данных:
- поддержка возможности создания нового объекта данных обозначается присутствием опции cdmi_create_dataobject в родительском контейнере.
8.3.3 Заголовки запроса
Заголовки HTTP запроса на создание объекта данных CDMI с использованием типа содержимого, отличного от CDMI, приведены в таблице 12.
Заголовки запроса — создание объекта данных CDMI
с использованием типа содержимого, отличного от CDMI
8.3.4 Тело сообщения-запроса
Тело сообщения-запроса содержит данные, которые должны храниться как значение объекта данных.
8.3.5 Заголовки ответа
8.3.6 Тело сообщения-ответа
Поля сообщения-ответа не определены.
8.3.7 Статус ответа
Коды состояний HTTP, возникающих при создании объекта данных с использованием содержимого, отличного от CDMI, описаны в таблице 13.
Коды состояния HTTP — создание объекта данных CDMI
с использованием типа содержимого, отличного от CDMI
8.3.8 Пример
PUT /MyContainer/MyDataObject.txt HTTP/1.1
Content-Type: text/plain;charset=utf-8
8.4. Чтение объекта данных с использованием типа содержимого CDMI
8.4.1 Обзор
Для чтения всех полей существующего объекта данных необходимо выполнить следующий запрос:
Для чтения одного или нескольких полей существующего объекта данных необходимо выполнить один из следующих запросов:
диапазон байтов значения объекта данных, которые необходимо вернуть в поле value. шаблон префикса: возвращаются все метаданные, начинающиеся с данного префикса.
К объекту можно также обратиться как
8.4.2 Опции
Следующие опции описывают поддерживаемые операции, которые можно выполнять при чтении существующего объекта данных:
- поддержка возможности чтения метаданных существующего объекта данных обозначена наличием опции cdmi_read_metadata у объекта;
- поддержка возможности чтения данных существующего объекта обозначена наличием опции cdmi_read_value у объекта;
- поддержка возможности чтения определенного диапазона байт значения объекта обозначена наличием опции cdmi_read_value_range у объекта.
8.4.3 Заголовки запроса
Заголовки HTTP запросов на чтение объекта данных CDMI, использующего тип содержимого CDMI, приведены в таблице 14.
с использованием типа содержимого CDMI
| Заголовок | Тип | Описание | Требование |
|---|---|---|---|
| Accept | Header String | "application/cdmi-object" или допустимой значение, см. 5.13.2 | Опционально |
| X-CDMI-SpecificationVersion | Header String | Список версий, поддерживаемых клиентом, разделенных запятыми, например, "1.0.2, 1.5, 2.0" | Обязательно |
8.4.4 Тело сообщения-запроса
Тело сообщения-запроса должно отсутствовать.
8.4.5 Заголовки ответа
Заголовки HTTP ответа на чтение объекта данных с использованием типа содержимого CDMI приведены в таблице 15.
8.4.6 Тело сообщения-ответа
Поля тела сообщения-ответа на запрос чтения объекта данных с использованием типа содержимого CDMI приведены в таблице 16.
Тело сообщения-ответа - чтение объекта данных CDMI с использованием типа содержимого CDMI
| Имя поля | Тип | Описание | Требование |
|---|---|---|---|
| objectType | Строка JSON | "application/cdmi-object" | Обязательно |
| objectID | Строка JSON | ID объекта | Обязательно |
| objectName | Строка JSON | Имя объекта: для объектов в контейнере должно быть возвращено поле objectName; для объектов не в контейнере (доступных только по ID), поле objectName не существует и не должно возвращаться. |
Условно |
| parentURI | Строка JSON | URI родительского объекта: для объектов в контейнере должно возвращаться поле parentURI; для объектов не в контейнере (доступных только по ID), поле parentURI не существует и не должно возвращаться. Добавление objectName к parentURI должно всегда давать корректный URI объекта. |
Условно |
| parentID | Строка JSON | ID родительского контейнера: для объектов в контейнере должно возвращаться поле parentID; для объектов не в контейнере (доступных только по ID), поле parentID не существует и не должно возвращаться. |
Условно |
| domainURI | Строка JSON | URI домена-владельца | Обязательно |
| capabilitiesURI | Строка JSON | URI опций для объекта | Обязательно |
| completionStatus | Строка JSON | Строка, указывающая, находится ли объект в процессе создания (а после создания - был ли он создан успешно или с ошибкой). Значение должно быть строкой "Processing" или "Complete" или строкой, начинающейся с "Error". |
Обязательно |
| percentComplete | Строка JSON | Если значение completionStatus равно "Processing", данное поле, при наличии, должно показывать процент выполнения операции создания объекта, числовым значением от 0 до 100. Если значение completionStatus равно "Complete", данное поле, при наличии, должно иметь значение "100". Если значение completionStatus начинается с "Error", данное поле, при наличии, может содержать любое целое число от 0 до 100. |
Опционально |
| mimetype | Строка JSON | Тип MIME значения объекта данных | Обязательно |
| metadata | Объект JSON | Метаданные объекта данных. Данное поле включает любые пользовательские метаданные или метаданные системы данных, указанные в соответствующем поле тела запроса при создании, наряду с метаданными системы хранения, созданными облачным хранилищем. См. детальное описание метаданных в разделе 16. | Обязательно |
| valuerange | Строка JSON | Диапазон байт объекта, которые следует вернуть в поле value Если запрошен определенный диапазон, значение поля должно соответствовать запрошенным байтам. Если запрос выходит за границы данных, в поле диапазона вывода должно быть указано, что возвращено меньшее число байтов. Если значение объекта содержит промежутки (из-за несмежных диапазонов PUT), значение диапазона должно указывать на интервал до первого промежутка в значении объекта. Метаданные хранилища cdmi_size должны всегда хранить полный размер объекта, с учетом пропусков, заполненных нулями. |
Обязательно |
| valuetransferencoding | Массив JSON строк JSON | Кодировка, использованная при передаче объекта данных. Определены два значения кодировки. - "utf-8" указывает на то, что объект данных содержит корректную строку UTF-8, и должен передаваться в поле value как строка UTF-8. - "base64" указывает на то, что объект данных содержит произвольную бинарную последовательность и должен передаваться в поле value как строка в кодировке base 64. |
Обязательно |
| value | Строка JSON | Значение объекта данных - Если поле valuetransferencoding указывает на кодировку UTF-8, поле value должно содержать строку UTF-8 согласно правилам JSON, описанным в RFC 4627. - |Если поле valuetransferencoding указывает на кодировку base 64, поле value должно содержать строку, закодированную base 64 (RFC 4648). - Поле value должно предоставляться только если поле completionStatus содержит "Complete". - При чтении значения, для промежутков данных возвращаются нули. |
Условно |
Если в запрос GET указаны отдельные поля, только эти поля возвращаются в теле ответа. Запрошенные опциональные поля, отсутствующие в объекте, в ответе опускаются.
8.4.7 Статус ответа
Коды состояний HTTP, возникающих при чтении из объекта данных с использованием типа содержимого CDMI, описаны в таблице 17.
Коды состояния HTTP - чтение объекта данных CDMI с использованием типа содержимого CDMI
8.4.8 Примеры
1 Применение GET к URI объекта данных для чтения всех полей объекта:
GET /MyContainer/MyDataObject.txt HTTP/1.1
Accept: application/cdmi-object
X-CDMI-Specification-Version: 1.0.2
X-CDMI-Specification-Version: 1.0.2
"objectType" : "application/cdmi-object",
"parentURI" : "/MyContainer/",
"parentID" : "00007E7F00102E230ED82694DAA975D2",
"capabilitiesURI" : "/cdmi_capabilities/dataobject/",
"completionStatus" : "Complete",
2 Применение GET к URI идентификатора объекта данных для чтения всех полей объекта по ID:
GET /cdmi_objectid/0000706D0010B84FAD185C425D8B537E
HTTP/1.1 Host: cloud.example.com
Accept: application/cdmi-object
X-CDMI-Specification-Version: 1.0.2
Будет получен следующий ответ.
X-CDMI-Specification-Version: 1.0.2
"objectName" : "MyDataObject.txt",
"parentURI" : "/MyContainer/",
"parentID" : "00007E7F00102E230ED82694DAA975D2",
"completionStatus" : "Complete",
3 Применение GET к URI объекта данных для чтения полей value и mimetype:
GET /MyContainer/MyDataObject.txt?value;mimetype HTTP/1.1
Accept: application/cdmi-object
X-CDMI-Specification-Version: 1.0.2
Content-Type: application/cdmi-object
X-CDMI-Specification-Version: 1.0.2
"value" : "This is the Value of this Data Object",
4 Применение GET к URI объекта данных для чтения первых 11 байт значения объекта:
GET /MyContainer/MyDataObject.txt?valuerange;value:0-10 HTTP/1.1
Accept: application/cdmi-object
X-CDMI-Specification-Version: 1.0.2
Будет получен следующий ответ.
Content-Type: application/cdmi-object
8.5. Чтение объекта данных с использованием типа содержимого, отличного от CDMI
8.5.1 Обзор
Для чтения значения существующего объекта данных, следует выполнить запрос:
К объекту возможно обратиться как
8.5.2 Опции
Следующие опции описывают поддерживаемые операции, которые можно выполнять при чтении из существующего объекта данных:
- поддержка возможности чтения значения из существующего объекта данных обозначена наличием опции cdmi_read_value в объекте. При чтении из байта, в который не было записано значение при создании или изменении объекта, должно возвращать нулевой байт.
- поддержка возможности чтения обозначенного диапазона байтов значения из существующего объекта данных обозначена наличием опции cdmi_read_value_range в объекте. При чтении из байта, в который не было записано значение при создании или изменении объекта, должно возвращать нулевой байт.
8.5.3 Заголовок запроса
Заголовок запроса HTTP на чтение объекта данных CDMI с использованием типа содержимого, отличного от CDMI, показан в таблице 18.
Заголовок запроса - чтение объекта данных CDMI с использованием типа содержимого, отличного от CDMI
| Заголовок | Тип | Описание | Требование |
|---|---|---|---|
| Range | Строка заголовка | Корректное описание диапазона (см. RFC 2616, п. 14.35.1) | Опционально |
8.5.4 Тело сообщения-запроса
Тело в сообщении должно отсутствовать.
8.5.5 Заголовки ответа
Заголовки HTTP ответа на чтение объекта данных CDMI с использованием типа содержимого, отличного от CDMI, показаны в таблице 19.
Заголовки ответа - чтение объекта данных CDMI с использованием типа содержимого, отличного от CDMI
8.5.6 Тело сообщения-ответа
К чтению объекта данных с использованием типа содержимого, отличного от CDMI, предъявляются следующие требования:
- тело сообщения-ответа является содержимым поля value объекта;
- в промежутках, возникающих из-за разрывов при записи, должны возвращаться нули.
8.5.7 Статус ответа
Коды состояний HTTP, возникающих при чтении из объекта данных с использованием типа содержимого, отличного от CDMI, описаны в таблице 20.
Коды состояний HTTP - чтение объекта данных CDMI с использованием типа содержимого, отличного от CDMI
8.5.8 Примеры
1 Применение GET к URI объекта данных для чтения значения объекта:
GET /MyContainer/MyDataObject.txt HTTP/1.1
Будет получен следующий ответ.
This is the Value of this Data Object
2 Применение GET к URI объекта данных для чтения первых 11 байт значения объекта данных:
GET /MyContainer/MyDataObject.txt HTTP/1.1
Будет получен следующий ответ.
8.6. Изменение объекта данных с использованием типа содержимого CDMI
8.6.1 Обзор
Для изменения некоторых или всех полей существующего объекта данных следует выполнить запрос:
Для изменения значения существующего объекта данных следует выполнить запрос:
Для добавления, изменения или удаления определенных метаданных существующего объекта данных следует выполнить запрос:
путь к облаку CDMI; неотрицательное число промежуточных контейнеров; имя объекта данных для изменения; диапазон байт объекта данных для изменения.
К объекту данных возможно обратиться также как
8.6.2 Опции
Следующие опции описывают поддерживаемые операции, которые можно выполнять при изменении существующего объекта данных:
- поддержка возможности изменения метаданных существующего объекта данных обозначена наличием опции cdmi_modify_metadata у объекта;
- поддержка возможности изменения значения и/или типа MIME существующего объекта данных обозначена наличием опции cdmi_modify_value у объекта;
- поддержка возможности изменения определенного диапазона байт значения существующего объекта данных обозначена наличием опции cdmi_modify_value_range у объекта.
8.6.3 Заголовки запроса
Заголовки HTTP запроса для изменения объекта данных CDMI с использованием типа содержимого CDMI перечислены в таблице 21.
8.6.4 Тело сообщения-запроса
Поля тела сообщения-запроса для изменения объекта данных CDMI с использованием типа содержимого CDMI перечислены в таблице 22.
| Имя поля | Тип | Описание | Требование |
| mimetype | Строка JSON | Тип MIME данных, содержащихся в поле value объекта данных. При наличии, заменяет существующий тип MIME. Данное поле может быть включено при изменении по значению, десериализации или копировании объекта данных. Данное поле должно храниться как часть объекта. Если данное поле не указано, имеющееся значение поля mimetype должно остаться неизменным. Данное поле не должно включаться при создании ссылки. Значение mimetype должно быть преобразовано к нижнему регистру перед сохранением. | Опционально |
| metadata | Объект JSON | Метаданные объекта данных. При наличии, новые метаданные заменяют имеющиеся. Если в URI указан отдельный пункт метаданных, остальные метаданные сохраняются. Детальное описание метаданных см. в разделе 16. | Опционально |
| domainURI | Строка JSON | URI домена-владельца В случае отличия от домена-родителя, пользователь должен иметь права cross_domain" (см. cdmi_member_privileges в таблице 64). Если не указано, сохраняется существующий домен. | Опционально |
| deserialize | Строка JSON | URI сериализованного объекта данных CDMI, который должен быть десериализован для изменения существующего объекта данных. ID сериализованного объекта должен соответствовать ID конечного объекта. | Опционально a |
| copy | Строка JSON | URI объекта данных или очереди CDMI, которые должны быть скопированы в существующий объект данных. | Опционально a |
| deserializevalue | Строка JSON | Сериализованный объект данных (см. гл. 15), кодированный по правилам base 64 (RFC 4648). ID сериализованного объекта данных должен соответствовать ID изменяемого объекта. | Опционально a |
| valuetransferencoding | Массив JSON строк JSON | Кодировка, использованная при передаче объекта данных. Определены два значения кодировки. - "utf-8" указывает на то, что объект данных содержит корректную строку UTF-8, и должен передаваться в поле value как строка UTF-8. - "base64" указывает на то, что объект данных содержит произвольную бинарную последовательность и должен передаваться в поле поля value строкой в кодировке base 64. Задание содержимого поля value объекта данных иное, чем корректная строка в кодировке base 64, должно возвращать клиенту ошибку 400 Bad Request. Данное поле должно включаться лишь при изменении объекта по значению. Если иное не указано клиентом, сервер должен установить значение поля valuetransferencoding равным "utf-8". Данное поле должно храниться как часть объекта. | Опционально |
| value | Строка JSON | Новые данные объекта. При наличии, значение поля заменяет существующее значение. Если поле valuetransferencoding указывает на кодировку UTF-8, значение должно быть строкой UTF-8, сформированной по правилам JSON (RFC 4627). Если поле valuetransferencoding указывает на кодировку base 64, значение должно быть вначале кодировано в base 64 (RFC 4648). Если в запросе указан диапазон, новые данные должны быть вставлены в указанный диапазон. Если при этом возникнут промежутки, они считаются заполненными нулями и должны учитываться при вычислении размера значения. При сохранении диапазона value должно содержать строку в кодировке base 64, и значение поля valuetransferencoding должно быть установлено в "base64". | Опционально |
| a В каждой данной операции должно указываться лишь одно из этих полей. За исключением value, эти поля не должны храниться. Если имеется более одного такого поля, сервер должен вернуть сообщение об ошибке 400 Bad Request. | |||
8.6.5 Заголовок ответа
Заголовок HTTP ответа на запрос изменения объекта данных CDMI с использованием типа содержимого CDMI указан в таблице 23.
| Заголовок | Тип | Описание | Требование |
|---|---|---|---|
| Location | Строка заголовка | Сервер должен вернуть URI, на который идет переадресация, если объект является ссылкой. | Условно |
8.6.6 Тело сообщения-ответа
Сообщение-ответ может содержать тело, соответствующее RFC 2616.
8.6.7 Статус ответа
Коды состояния HTTP возникающие при изменении объекта данных с использованием типа содержимого CDMI, перечислены в таблице 24.
Коды состояний HTTP - изменение CDMI объекта данных
с использованием типа содержимого CDMI (лист 1 из 2)
8.6.8 Примеры
1 Применение PUT к URI объекта данных для установления новых значений полей:
PUT /MyContainer/MyDataObject.txt HTTP/1.1
Content-Type: application/cdmi-object
X-CDMI-Specification-Version: 1.0.2
"value" : "This is the Value of this Data Object"
Будет получен следующий ответ.
2 Применение PUT к URI объекта данных для изменения типа MIME:
PUT /MyContainer/MyDataObject.txt?mimetype HTTP/1.1
Content-Type: application/cdmi-object
3 Применение PUT к URI объекта данных для изменения диапазона значения:
PUT /MyContainer/MyDataObject.txt?value:21-24 HTTP/1.1
Content-Type: application/cdmi-object
X-CDMI-Specification-Version: 1.0.2
Будет получен следующий ответ.
При изменении значения без указания кодировки передачи, клиент должен учитывать текущую кодировку передачи объекта. Если клиент посылает значение строкой UTF-8 для изменения существующего объекта со значением valuetransferencoding равным "base64", должна быть возвращена ошибка. Если клиент отсылает строку base 64 для изменения объекта с valuetransferencoding равным "utf-8", это не должно приводить к ошибке, но приводить к сохранению символьной последовательности без изменений как строки base 64 вместо перекодирования ожидаемых данных в кодировку base 64.
4 Применение PUT к URI объекта данных для замены метаданных:
PUT /MyContainer/MyDataObject.txt?metadata HTTP/1.1
Content-Type: application/cdmi-object
X-CDMI-Specification-Version: 1.0.2
Будет получен следующий ответ.
5 Применение PUT к URI объекта данных для добавления новых метаданных и сохранения существующих:
PUT /MyContainer/MyDataObject.txt?metadata:shape HTTP/1.1
Content-Type: application/cdmi-object
X-CDMI-Specification-Version: 1.0.2
Будет получен следующий ответ.
6 Применение PUT к URI объекта данных для замены лишь одного элемента метаданных новым значением:
PUT /MyContainer/MyDataObject.txt?metadata:colour HTTP/1.1
Content-Type: application/cdmi-object
X-CDMI-Specification-Version: 1.0.2
Будет получен следующий ответ.
8.7. Изменение объекта данных с использованием типа содержимого, отличного от CDMI
8.7.1 Обзор
Для изменения значения существующего объекта данных следует выполнить запрос:
путь к облаку CDMI. неотрицательное число промежуточных контейнеров. имя изменяемого объекта данных.
К объекту можно обратиться также как
8.7.2 Опции
Следующие опции описывают поддерживаемые операции, которые можно выполнять при изменении существующего объекта данных:
- поддержка возможности изменения значения существующего объекта и/или типа MIME обозначается присутствием опции cdmi_modify_value у объекта;
- поддержка возможности изменения выбранного диапазона байт значения объекта обозначается наличием cdmi_modify_value_range у объекта.
8.7.3 Заголовки запроса
Заголовки HTTP запроса на изменение объекта данных CDMI с использованием типа содержимого, отличного от CDMI, приведены в таблице 25.
Заголовки запроса - изменение объекта данных CDMI с использованием типа содержимого, отличного от CDMI
8.7.4 Тело сообщения-запроса
Тело сообщения-запроса на изменение данных содержит данные для сохранения в значение объекта.
8.7.5 Заголовок ответа
Заголовок ответа HTTP на изменение объекта данных CDMI с использованием типа содержимого, отличного от CDMI, приведен в таблице 26.
Заголовок ответа - изменение объекта данных CDMI
с использованием типа содержимого, отличного от CDMI
| Заголовок | Тип | Описание | Требование |
|---|---|---|---|
| Location | Строка заголовка | Сервер должен вернуть URI, на который происходит переадресация, если объект является ссылкой. | Условно |
8.7.6 Тело сообщения-ответа
Сообщение-ответ может содержать тело, соответствующее RFC 2616.
8.7.7 Статус запроса
Коды состояний HTTP, возникающих в ответ на изменение объекта данных CDMI с использованием типа содержимого, отличного от CDMI, приведены в таблице 27.
Коды состояния HTTP - изменение объекта данных CDMI с использованием типа содержимого, отличного от CDMI
8.7.8 Примеры
1 Применение PUT к URI объекта данных для изменения значения объекта данных:
PUT /MyContainer/MyDataObject.txt HTTP/1.1
This is the value of this data object
Будет получен следующий ответ.
2 Применение PUT к URI объекта данных для изменения четырех байтов в значении объекта данных:
PUT /MyContainer/MyDataObject.txt HTTP/1.1
8.8. Удаление объекта данных с использованием типа содержимого CDMI
8.8.1 Обзор
8.8.2 Опции
Следующие опции описывают поддерживаемые операции, которые можно выполнять при удалении существующего объекта данных:
- поддержка возможности удаления существующего объекта данных обозначается наличием опции cdmi_delete_dataobject у объекта.
8.8.3 Заголовок запроса
Заголовок HTTP запроса на удаление CDMI объекта с использованием типа содержимого CDMI приведен в таблице 28.
| Заголовок | Тип | Описание | Требование |
|---|---|---|---|
| X-CDMI-SpecificationVersion | Строка заголовка | Список версий, поддерживаемых клиентом, разделенных запятыми, например "1.0.2, 1.5, 2.0" | Обязательно |
8.8.4 Тело сообщения-запроса
Сообщение-запрос может содержать тело, соответствующее RFC 2616.
8.8.5 Заголовки ответа
8.8.6 Тело сообщения-ответа
Сообщение-ответ может содержать тело, соответствующее RFC 2616.
8.8.7 Статус запроса
В таблице 29 приведены коды состояний HTTP, возникающих при удалении CDMI объекта с использованием типа содержимого CDMI.
с использованием типа содержимого CDMI
8.8.8 Пример
Будет получен следующий ответ.
8.9. Удаление объекта данных с использованием типа содержимого, отличного от CDMI
8.9.1 Обзор
К объекту можно также обратиться как
8.9.2 Опции
Следующие опции описывают поддерживаемые операции, которые можно выполнять при удалении существующего объекта данных:
- поддержка возможности удаления существующего объекта данных обозначена наличием способности cdmi_delete_dataobject у объекта.
8.9.3 Заголовки запроса
8.9.4 Тело сообщения-запроса
8.9.5 Заголовки ответа
8.9.6 Тело сообщения-ответа
8.9.7 Статус запроса
Таблица 30 описывает коды состояний HTTP, возникающих при удалении CDMI объекта с использованием типа содержимого, отличного от CDMI
8.9.8 Пример
DELETE /MyContainer/MyDataObject.txt HTTP/1.1 Host: cloud.example.com
9. Операции с ресурсами вида объект-контейнер
9.1. Обзор
Объекты-контейнеры - основное средство группировки в CDMITM, аналогичные папкам файловой системы. Каждый объект-контейнер имеет неотрицательное число дочерних объектов и набор полей, включающих стандартизованные и произвольные метаданные. Эти метаданные генерируются облачным хранилищем или задаются пользователем. В модели CDMI контейнеры адресуются двумя способами:
- по имени (например, http://cloud.example.com/container/);
- по ID объекта (например, http://cloud.example.com/cdmi_objectid/0000706D0010B84FAD185C425D8B537E.
Каждый контейнер имеет единственный глобально-уникальный ID, который остается неизменным на протяжении жизненного цикла объекта. Каждый контейнер также может иметь один или несколько адресов URI, что позволяет адресовать контейнеры. Следуя соглашениям об иерархическом пути, URI контейнера должны состоять из одного или нескольких имен контейнеров, разделенных наклонной чертой ("/") и заканчиваться наклонной чертой ("/").
При запросе к ресурсу существующего контейнера, если завершающая наклонная черта в его URI опущена, сервер должен вернуть код состояния HTTP 301 Moved Permanently с заголовком Location, содержащим URI с завершающей наклонной чертой.
При выполнении запроса CDMI на создание нового ресурса контейнера, если опущена завершающая наклонная черта в URI, сервер должен вернуть код состояния HTTP 400 Bad Request.
Запросы вне модели CDMI на создание ресурса контейнера должны включать завершающую URI наклонную черту; в противном случае запрос будет распознан как запрос на создание объекта.
Вложенный контейнер имеет родительский объект-контейнер, должен быть включен в поле children контейнера-родителя и наследовать метаданные системы данных и список прав доступа родительского контейнера.
Данная модель позволяет устанавливать прямое соответствие между управляемым CDMI облачным хранилищем и файловыми системами (например, NFSv4 или WebDAV). Если объект-контейнер CDMI экспортируется в файловую систему, файловая система может предоставлять особые механизмы доступа к метаданным CDMI. При создании файлов и папок в файловой системе они становятся видимыми через интерфейс CDMI, служащий путем к данным. Соответствие между конструкциями файловой системы и объектами данных, контейнерами и метаданными CDMI находится за рамками настоящего стандарта.
Для получения отдельного поля объекта контейнера необходимо указать имя поля после знака "?" на конце URI объекта.
Указанием диапазона после названия поля children можно осуществлять доступ к диапазону поля children.
Диапазоны потомков определяются аналогично диапазону байт, согласно гл. 14.35.1 в RFC 2616. Клиент может определить количество потомков запросом поля childrenrange без запроса диапазона потомков.
Возможно указать список полей, разделенных ";", что позволяет обращаться к нескольким полям в одном запросе.
Если клиент поддерживает или использует поля десериализации, которые не определены в настоящем стандарте, эти поля должны храниться как часть объекта.
9.1.1 Метаданные контейнера
Могут быть предоставлены следующие опциональные метаданные системы данных (см. таблице 31).
Метаданные контейнера могут также включать произвольные пользовательские метаданные и метаданные системы данных как описано в разделе 16.
9.1.2 Зарезервированные имена метаданных контейнера
Настоящий стандарт определяет зарезервированные имена контейнеров, которые не должны использоваться при создании новых контейнеров. При попытке создать или контейнер с одним из этих имен сервер должен вернуть клиенту код HTTP 400 Bad Request.
Зарезервированы следующие имена контейнеров:
В последующих версиях настоящего стандарта могут быть добавлены новые зарезервированные имена, поэтому реализации сервера не должны допускать создания пользовательских контейнеров с именами, начинающимися с "cdmi_".
9.1.3 Адресация объекта-контейнера
Каждый контейнер может адресоваться одним или несколькими уникальными URI, и все операции должны выполняться через эти URI. Возможны случаи, когда объект-контейнер может доступен через несколько виртуальных путей. Например, http://cloud.example.com/users/snia/cdmi/ также доступен через http://snia.example.com/cdmi/. Конфликт записи через разные пути должен регулироваться аналогично обработке конфликта записи через один и тот же путь, по принципу возможной связности (см. 9.2).
9.1.4 Представления объекта-контейнера
Представления в данном разделе показаны с использованием нотации JSON. И клиенты, и серверы должны поддерживать UTF-8 представление JSON. В телах сообщений-запросов и ответов, поля JSON могут указываться и возвращаться в любом порядке, за исключением полей childrenrange и children, которые указываются последними и в данном порядке.
9.2. Создание объекта-контейнера с использованием типа содержимого CDMI
9.2.1 Обзор
неотрицательное число уже существующих объектов-контейнеров, разделенных одной наклонной чертой (т.е., "/"); имя нового создаваемого объекта-контейнера.
После создания, к контейнеру можно обращаться как
9.2.2 Отсроченное завершение создания
В ответ на запрос создания объекта-контейнера, сервер может вернуть код 202 Accepted, что указывает на то, что объект находится в процессе создания. Это полезно в случае длительных операций (например, десериализации исходного объекта данных для создания сложной иерархии объектов). Такой ответ означает, что:
- сервер должен вернуть заголовок Location, содержащий URI к создаваемому объекту со статусом HTTP 202 Accepted;
- статус 202 Accepted со стороны сервера удостоверяет, что были пройдены несколько проверок:
- пользователь авторизован для создания нового объекта-контейнера;
- пользователь авторизован для чтения любого исходного объекта, который необходимо переместить, скопировать, сериализовать или десериализовать;
- достаточно места для создания объекта-контейнера или, по крайней мере, достаточно места для создания URI к сообщению об ошибке.
Клиент может не иметь опции немедленно обратиться к созданному объекту, например, из-за задержек, вызванных использованием реализацией целостности в конечном итоге.
Для отслеживания процесса создания клиент выполняет операции GET к URI. В ответ сервер возвращает два поля в теле сообщения-ответа, которые описывают текущее состояние:
- обязательное текстовое поле completionStatus содержит "Processing", "Complete", либо строку сообщения об ошибке, начинающуюся с "Error";
- опциональное поле percentComplete содержит процент выполнения принятого запроса PUT (от 0 до 100). GET не возвращает объектов-потомков контейнера, если completionStatus не равно "Complete".
Если создание объекта завершается с ошибкой, создается URI, а поле completionStatus устанавливается равным сообщению об ошибке. Удаление URI после обработки ошибки возлагается на клиента.
9.2.3 Опции
Следующие опции описывают поддерживаемые операции при создании нового объекта:
- поддержка возможности создания нового объекта-контейнера обозначается наличием опции cdmi_create_container в родительском контейнере;
- если объект, создаваемый в родительском контейнере, является ссылкой, поддержка этой операции обозначается наличием опции cdmi_create_reference в родительском контейнере;
- если новый объект является копией существующего, поддержка копирования обозначается наличием опции cdmi_copy_container в родительском контейнере;
- если новый контейнер создается в результате перемещения, поддержка этой операции обозначается наличием опции cdmi_move_container у родительского контейнера;
- если новый объект создается в результате операции десериализации, поддержка этой операции обозначается наличием опции cdmi_deserialize_container в родительском контейнере.
9.2.4 Заголовки запроса
Заголовки HTTP запросов на создание объекта-контейнера CDMI с использованием типа содержимого CDMI приведены в таблице 32.
Заголовки запроса - создание объекта-контейнера с использованием типа содержимого CDMI
| Заголовок | Тип | Описание | Требование |
|---|---|---|---|
| Accept | Строка заголовка | "application/cdmi-container" или совместимое значение согласно 5.13.2 | Опционально |
| Content-Type | Строка заголовка | "application/cdmi-container" | Обязательно |
| X-CDMI-SpecificationVersion | Строка заголовка | Список версий, поддерживаемых клиентом, разделенных запятыми, например, "1.0.2, 1.5, 2.0" | Обязательно |
9.2.5 Тело сообщения-запроса
Поля тела сообщения-запроса на создание объекта-контейнера с использованием типа содержимого CDMI приведены в таблице 33.
Тело сообщения-запроса - создание объекта-контейнера с использованием типа содержимого CDMI (лист 1 из 2)
| Имя поля | Тип | Описание | Требование |
| metadata | Объект JSON | Метаданные объекта-контейнера Если данное поле включено при десериализации, сериализации, копировании или перемещении объекта-контейнера, то значение этого поля должно заменять метаданные URI источника. Если данное поле не включено при десериализации, сериализации, копировании или перемещении объекта-контейнера, то следует использовать метаданные URI источника. Если данное поле включено при создании нового объекта по значению, это поле должно быть использовано как метаданные. Если данное поле не включено при создании нового контейнера по значению, этому полю следует поставить в соответствие пустой объект JSON (т.е., "{}"). Данное поле не должно указываться при создании ссылки на объект-контейнер | Опционально |
| DomainURI | Строка JSON | URI домена-владельца В случае отличия от родительского домена, пользователь должен обладать правами cross_domain (см. cdmi_member_privileges в таблице 64). Если не указано, должен использоваться родительский домен | Опционально |
| exports | Объект JSON | Структура для каждого из возможных протоколов для данного объекта-контейнера (см. гл. 13). Данное поле не должно указываться при создании ссылки | Опционально |
| Deserialize | Строка JSON | URI сериализованного объекта данных CDMI, который должен быть десериализован при создании нового контейнера, включая всех потомков внутри исходного сериализованного объекта (см. гл. 15). При десериализации контейнера, ни один из экспортированных протоколов исходного сериализованного объекта не должен применяться к вновь создаваемому объекту(ам) | Опционально a |
| copy | Строка JSON | URI объекта-контейнера CDMI, который должен быть скопирован в новый объект-контейнер, включая всех потомков исходного объекта. При копировании объекта-контейнера, экспортированные протоколы не сохраняются в копии | Опционально a |
| move | Строка JSON | URI существующего локального или удаленного объекта-контейнера CDMI (URI источника), который должен быть перемещен, включая все объекты-потомки, в URI, указанный в команде PUT. Содержимое объекта-контейнера и всех потомков, включая ID объекта, должны при перемещении сохраняться (после успешного копирования). Если недостаточно прав для чтения объекта по URI источника, записи объекта по URI нового объекта, удаления объектов по URI источника или одна из этих операций завершается с ошибкой, сервер должен вернуть код результата 400 Bad Request, причем исходный и конечный объекты должны сохраниться неизменными | Опционально a |
| reference | Строка JSON | URI объекта-контейнера CDMI, на который должна быть сделана переадресация. Если при создании ссылки указаны другие поля, сервер должен вернуть код ошибки 400 Bad Request | Опционально a |
| deserializevalue | Строка JSON | Сериализованный объект-контейнер (см. гл. 15), кодированный с помощью base 64 (RFC 4648). ID сериализованного контейнера должен соответствовать ID контейнера-назначения | Опционально a |
| a Лишь одно из этих полей должно быть указано в любой из операций. За исключением поля value, данные поля не должны сохраняться. Если указано более чем одно из этих полей, сервер должен вернуть сообщение об ошибке 400 Bad Request | |||
9.2.6 Заголовки ответа
Заголовки HTTP ответа на создание объекта-контейнера CDMI с использованием типа содержимого CDMI указаны в таблице 34.
9.2.7 Тело сообщения-ответа
Поля тела сообщения-ответа на создание объекта-контейнера CDMI с использованием типа содержимого CDMI приведены в таблице 35.
Тело сообщения-ответа - создание объекта-контейнера с использованием типа содержимого CDMI
| Имя поля | Тип | Описание | Требование |
| objectType | Строка JSON | "application/cdmi-container" | Обязательно |
| objectID | Строка JSON | ID объекта | Обязательно |
| objectName | Строка JSON | Имя объекта | Обязательно |
| parentURI | Строка JSON | URI родительского объекта Добавление objectName к parentURI должно всегда давать корректный URI объекта. | Обязательно |
| parentID | Строка JSON | ID родительского объекта-контейнера | Обязательно |
| domainURI | Строка JSON | URI домена-владельца | Обязательно |
| capabilitiesURI | Строка JSON | URI опций объекта | Обязательно |
| CompletionStatus | Строка JSON | Строка, указывающая, находится ли объект в процессе создания, а после завершения операции - был ли он создан успешно или с ошибкой. Значение должно быть строкой "Processing", "Complete" или строкой, начинающейся с "Error". | Обязательно |
| percentComplete | Строка JSON | Если значение completionStatus равно "Processing", данное поле, при наличии, должно показывать процент выполнения операции создания объекта, числовым значением от 0 до 100. Если значение completionStatus равно "Complete", данное поле, при наличии, должно иметь значение "100". Если значение completionStatus начинается с "Error", данное поле, при наличии, может содержать любое целое число от 0 до 100. | Опционально |
| metadata | Объект JSON | Метаданные объекта-контейнера. Могут включать пользовательские метаданные и метаданные системы данных, указанные в теле запроса на создание (поле metadata) вместе с метаданными системы хранения, создаваемыми облачным хранилищем. Подробнее о метаданных см. 16. | Обязательно |
| exports | Объект JSON | Структура для каждого протокола, разрешенного для данного объекта-контейнера. См. гл. 13. | Опционально a |
| snapshots | Массив JSON | Один или несколько URI снимков состояния объектов-контейнеров. См. гл. 14. | Опционально a |
| childrenrange | Строка JSON | Потомки контейнера в виде диапазона. При запросе диапазона потомков выдается содержимое этого поля в виде диапазона. | Обязательно |
| children | Массив JSON | Имена объектов-потомков контейнера. Контейнеры-потомки начинаются символом "/". | Обязательно |
| a Возвращается только при наличии | |||
9.2.8 Статус запроса
В таблице 36 приведены коды состояния HTTP, возникающие при создании объекта-контейнера с использованием типа содержимого CDMI.
9.2.9 Пример
Пример - Применение PUT к URI объекта-контейнера: имя и метаданные:
Accept: application/cdmi-container
Content-Type: application/cdmi-container
X-CDMI-Specification-Version: 1.0.2
"identifier": "00007E7F00104BE66AB53A9572F9F51E",
"http://example.com/compute/0/",
"http://example.com/compute/1/"
Content-Type: application/cdmi-container
X-CDMI-Specification-Version: 1.0.2
"objectType" : "application/cdmi-container",
"capabilitiesURI" : "/cdmi_capabilities/container/",
"identifier" : "0000706D0010B84FAD185C425D8B537E",
9.3. Создание объекта-контейнера с использованием типа содержимого, отличного от CDMI
9.3.1 Обзор
неотрицательное число уже существующих объектов-контейнеров, имена которых разделены символами наклонной черты (т.е., "/"); имя создаваемого контейнера.
После создания к контейнеру можно обращаться как
Наличие завершающей наклонной черты в URI, по которому выполняется операция PUT, указывает на создание объекта-контейнера, в отличие от создания объекта данных.
9.3.2 Опции
- поддержка возможности создания нового объекта-контейнера обозначается наличием опции cdmi_create_container в родительском контейнере.
9.3.3 Заголовки запроса
9.3.4 Тело сообщения-запроса
Тело запроса должно отсутствовать.
9.3.5 Заголовки ответа
9.3.6 Тело сообщения-ответа
Сообщение-ответ может содержать тело, соответствующее RFC 2616.
9.3.7 Статус запроса
В таблице 37 приведены коды состояний HTTP, возникающих при создании объекта-контейнера с использованием типа содержимого, отличного от CDMI.
с использованием типа содержимого, отличного от CDMI
9.3.8 Пример
Пример - Применение PUT к URI имени объекта-контейнера:
Будет получен следующий ответ.
9.4. Чтение объекта-контейнера с использованием типа содержимого CDMI
9.4.1 Обзор
Для чтения одного или нескольких определенных полей существующего объекта-контейнера следует выполнить один из следующих запросов:
путь к облаку CDMI; неотрицательное число промежуточных объектов-контейнеров; имя контейнера для чтения; имя поля; числовой диапазон в списке потомков; строковый префикс, будут возвращены все метаданные, начинающиеся с данного префикса.
К контейнеру можно также обратиться как
9.4.2 Опции
Следующие опции описывают поддерживаемые операции при чтении существующего объекта-контейнера:
- поддержка возможности чтения метаданных существующего объекта-контейнера обозначается наличием опции cdmi_read_metadata в контейнере;
- поддержка возможности перечисление потомков существующего объекта-контейнера обозначается наличием опции cdmi_list_children в контейнере;
- поддержка возможности перечисления диапазона потомков существующего объекта-контейнера обозначается наличием опции cdmi_list_children_range в контейнере.
9.4.3 Заголовки запроса
Заголовки HTTP запроса на чтение из объекта-контейнера CDMI с использованием типа содержимого CDMI приведены в таблице 38.
Заголовки запроса - чтение из объекта-контейнера с использованием типа содержимого CDMI
| Заголовок | Тип | Описание | Требование |
|---|---|---|---|
| Accept | Строка заголовка | "application/cdmi-container" или совместимое значение согласно 5.13.2 | Опционально |
| X-CDMI-SpecificationVersion | Строка заголовка | Список версий, поддерживаемых клиентом, разделенных запятыми, например, "1.0.2, 1.5, 2.0" | Обязательно |
9.4.4 Тело сообщения-запроса
В запросе должно отсутствовать тело.
9.4.5 Заголовки ответа
Заголовки HTTP ответа для операции чтения объекта-контейнера CDMI с использованием типа содержимого CDMI приведены в таблице 39.
Заголовки ответа - чтение из объекта-контейнера с использованием типа содержимого CDMI
9.4.6 Тело сообщения-ответа
Поля тела сообщения-ответа для операции чтения объекта-контейнера CDMI с использованием типа содержимого CDMI приведены в таблице 40.
Тело сообщения-ответа - чтение объекта-контейнера с использованием типа содержимого CDMI (лист 1 из 2)
| Имя поля | Тип | Описание | Требование |
| objectType | Строка JSON | "application/cdmi-container" | Обязательно |
| objectID | Строка JSON | ID объекта | Обязательно |
| objectName | Строка JSON | Имя объекта Для объектов в контейнере следует вернуть поле ObjectName. Для объектов не в контейнере (доступных только по ID), поле objectName не существует и не должно передаваться в ответе | Условно |
| parentURI | Строка JSON | URI родительского объекта Для объектов в контейнере следует вернуть поле parentURI. Для объектов не в контейнере (доступных только по ID), поле parentURI не существует и не должно передаваться в ответе. Добавление objectName к parentURI должно всегда возвращать правильный URI объекта. | Условно |
| parentID | Строка JSON | ID объекта родительского контейнера Для объектов в контейнере следует вернуть поле parentID. Для объектов не в контейнере (доступных только по ID), поле parentID не существует и не должно передаваться в ответе | Условно |
| domainURI | Строка JSON | URI домена-владельца | Обязательно |
| capabilitiesURI | Строка JSON | URI опций объекта | Обязательно |
| completionStatus | Строка JSON | Строка, указывающая, находится ли объект в процессе создания, а после завершения операции - был ли он создан успешно или с ошибкой. Значение должно быть строкой "Processing", "Complete" или строкой, начинающейся с "Error" | Обязательно |
| percentComplete | Строка JSON | Если значение completionStatus равно "Processing", данное поле, при наличии, должно показывать процент выполнения операции создания объекта, числовым значением от 0 до 100. Если значение completionStatus равно "Complete", данное поле, при наличии, должно иметь значение "100". Если значение completionStatus начинается с "Error", данное поле, при наличии, может содержать любое целое число от 0 до 100 | Опционально |
| metadata | Объект JSON | Метаданные объекта-контейнера. Могут включать пользовательские метаданные и метаданные системы данных, указанные в теле запроса на создание (поле metadata) вместе с метаданными системы хранения, создаваемыми облачным хранилищем. Подробнее о метаданных см. гл. 16 | Обязательно |
| exports | Объект JSON | Структура каждого протокола, возможного для данного контейнера (см. гл. 13) | Опционально a |
| snapshots | Массив JSON | Массив URI снимков состояния объекта-контейнера | Опционально a |
| childrenrange | Строка JSON | Объекты-потомки контейнера в виде диапазона. При запросе диапазона потомков это поле показывает объекты-потомки в форме диапазона. | Обязательно |
| children | Массив JSON | Имена дочерних объектов контейнера. Имена дочерних объектов не должны содержать зарезервированных символов (см. RFC 3986), например, "%" в имени будет представлен как "%25". У дочерних объектов, являющихся контейнерами, имя должно заканчиваться символом "/". У дочерних объектов, являющихся ссылками, имя должно заканчиваться символом "?" | Обязательно |
| a Возвращается только при наличии | |||
Если в запросе GET указаны отдельные поля, в ответе должны быть возвращены только эти поля.
Опциональные запрошенные поля, отсутствующие в объекте, опускаются в ответе.
9.4.7 Статус запроса
Таблица 41 описывает коды состояний HTTP, возникающих при чтении из контейнера с использованием данных типа CDMI.
Коды состояний HTTP - чтение объекта-контейнера с использованием типа содержимого CDMI
9.4.8 Примеры
1 Применение GET к URI объекта-контейнера для чтения всех его полей:
Accept: application/cdmi-container
X-CDMI-Specification-Version: 1.0.2
Будет получен следующий ответ.
Content-Type: application/cdmi-container
X-CDMI-Specification-Version: 1.0.2
"objectType" : "application/cdmi-container",
"objectID" : "0000706D0010B84FAD185C425D8B537E",
"objectName" : "MyContainer/",
"parentID" : "00007E7F0010128E42D87EE34F5A6560",
"domainURI" : "/cdmi_domains/MyDomain/",
"capabilitiesURI" : "/cdmi_capabilities/container/",
"completionStatus" : "Complete",
"identifier": "00007E7F00104BE66AB53A9572F9F51E",
"http://example.com/compute/0/",
"http://example.com/compute/1/"
GET /MyContainer/?parentURI;children HTTP/1.1
X-CDMI-Specification-Version: 1.0.2
Будет получен следующий ответ.
Content-Type: application/cdmi-container
3 Применение GET к URI объекта-контейнера для чтения потомков 0..2 и диапазона потомков контейнера:
GET /MyContainer/?childrenrange;children:0-2 HTTP/1.1
Accept: application/cdmi-container
X-CDMI-Specification-Version: 1.0.2
Будет получен следующий ответ.
X-CDMI-Specification-Version: 1.0.2
9.5. Изменение объекта-контейнера с использованием типа содержимого CDMI
9.5.1 Обзор
Для изменения некоторых или всех полей существующего объекта-контейнера следует выполнить запрос:
Для добавления, обновления или удаления определенных элементов метаданных существующего объекта-контейнера следует выполнить запрос:
Объект-контейнер также доступен как
9.5.2 Отсроченное завершение снимка состояния
Если запрашивается создание снимка состояния (включением поля snap-shot в запрос, см. гл. 14), сервер может вернуть код состояния 202 Accepted. Этот ответ предполагает, что:
- достаточно места для создания снимка или, по крайней мере, достаточно места для создания URI сообщения об ошибке.
- Клиент может не получить немедленного доступа к снимку из-за задержек, связанных с использованием в реализации целостности в конечном итоге.
Клиент выполняет запросы GET к URI снимка для отслеживания состояния операции. В частности, сервер возвращает два поля в теле сообщения-ответа:
- текстовое поле completionStatus, содержащее "Processing", "Complete", или сообщение об ошибке, начинающееся с "Error";
- опциональное поле percentComplete, представляющее степень выполнения принятого запроса PUT числом от 0 до 100. Запрос GET не возвращает значения объекта, если completionStatus отлично от "Complete".
Если операция создания снимка завершается ошибкой, создается URI снимка с полем completionStatus, содержащим сообщение об ошибке. Удаление этого URI после обработки ошибки возложено на клиента.
9.5.3 Заголовки запроса
Следующие опции описывают поддерживаемые операции при изменении существующего объекта-контейнера:
- поддержка возможности изменения метаданных существующего объекта-контейнера обозначается наличием опции cdmi_modify_metadata в контейнере;
- поддержка возможности сохранения снимка состояния содержимого существующего объекта-контейнера обозначается наличием опции cdmi_snapshot capability в контейнере;
- поддержка возможности добавления экспортируемого протокола к существующему объекту-контейнеру обозначается наличием опции cdmi_export_
в контейнере.
9.5.4 Заголовки запроса
Заголовки запроса HTTP для изменения объекта-контейнера CDMI с использованием типа содержимого CDMI перечислены в таблице 42.
Заголовки запроса - изменение объекта-контейнера с использованием типа содержимого CDMI
9.5.5 Тело сообщения-запроса
Поля тела запроса операции изменения объекта-контейнера с использованием типа содержимого CDMI перечислены в таблице 43.
| Имя поля | Тип | Описание | Требование |
| metadata | Объект JSON | Метаданные для объекта-контейнера. Если присутствуют, указанные метаданные замещают существующие метаданные объекта. Если URI указывает на конкретные элементы метаданных, остальные элементы не должны меняться. Подробнее о метаданных см. раздел 16. | Опционально |
| domainURI | Строка JSON | URI домена-владельца В случае отличия от родительского домена, у пользователя должны быть права cross_domain (см. cdmi_member_privileges в таблице 64). Если не указано, следует использовать родительский домен. | Опционально |
| snapshot | Строка JSON | Имя создаваемого снимка состояния. Это не URL, а конечный компонент абсолютного URL, где будет находиться снимок после успешного завершения операции создания снимка состояния. Если снимок добавляется или изменяется, операция PUT возвращает результат лишь после того как снимок добавлен в список снимков. После создания к снимкам можно обращаться как к объектам-потомкам контейнера cdmi_snapshots, вложенного в контейнер, чье состояние снимается. При создании снимка с тем же именем, что у уже имеющегося снимка, существующий снимок будет заменен. | Опционально |
| deserialize | Строка JSON | URI сериализованного объекта-контейнера CDMI, который должен быть десериализован для изменения существующего объекта-контейнера. ID сериализованного объекта-контейнера должен совпадать с ID объекта-назначения. Если сериализованный объект-контейнер не имеет потомков, изменение применяется только к объекту-контейнеру, а любые имеющиеся потомки остаются как есть. Если сериализованный объект имеет потомков, тогда операции создания, добавления, изменения и удаления рекурсивно применяются к каждому потомку, в зависимости от различия между представленным сериализованным состоянием и текущим состоянием потомков. | Опционально a |
| copy | Строка JSON | URI объекта-контейнера CDMI, который должен быть скопирован в имеющийся объект-контейнер. Будет скопировано лишь непосредственное содержимое объекта, но не его потомков. | Опционально a |
| deserializevalue | Строка JSON | Сериализованный объект-контейнер (см. гл. 15), кодированный с помощью base 64 как описано в RFC 4648. ID сериализованного объекта-контейнера должно соответствовать ID контейнера-цели. В противном случае сервер должен вернуть состояние 400 Bad Request. Если сериализованный объект-контейнер не имеет потомков, изменение применяется только к объекту-контейнеру, а любые имеющиеся потомки остаются как есть. Если сериализованный объект имеет потомков, тогда операции создания, добавления, изменения и удаления рекурсивно применяются к каждому потомку, в зависимости от различия между представленным сериализованным состоянием и текущим состоянием потомков. | Опционально a |
| exports | JSON Object | Структура для каждого протокола, разрешенного для данного объекта-контейнера (см. гл. 13). Если экспортированный протокол добавляется или изменяется, операция PUT возвращается только после завершения операции экспорта. | Опционально |
| a Лишь одно из этих полей должно быть указано в любой из операций. За исключением поля value, данные поля не должны сохраняться. | |||
9.5.6 Заголовок ответа
Заголовок ответа HTTP на изменение объекта-контейнера CDMI с использованием типа содержимого CDMI приведен в таблице 44.
с использованием типа содержимого CDMI
| Заголовок | Тип | Описание | Требование |
|---|---|---|---|
| Location | Строка заголовка | Сервер должен вернуть URI, на который происходит переадресация, если объект является ссылкой. | Условно |
9.5.7 Тело сообщения-ответа
Сообщение-ответ может содержать тело, соответствующее RFC 2616.
9.5.8 Статус запроса
В таблица 45 приведены коды состояний HTTP, возникающих при изменении объекта-контейнера с использованием типа содержимого CDMI.
с использованием типа содержимого CDMI (лист 1 из 2)
9.5.9 Примеры
1 Применение PUT к URI объекта-контейнера для задания новых значений полей:
Content-Type: application/cdmi-container
X-CDMI-Specification-Version: 1.0.2
"identifier": "00007E7F00104BE66AB53A9572F9F51E",
"http://example.com/compute/0/",
"http://example.com/compute/1/"
2 Применение PUT к URI объекта-контейнера для установки нового значения экспортируемого протокола:
Content-Type: application/cdmi-container
X-CDMI-Specification-Version: 1.0.2
"identifier" : "0000706D0010B84FAD185C425D8B537E",
"permissions" : "00007E7F00104EB781F900791C70106C"
9.6. Удаление объекта-контейнера с использованием типа содержимого CDMI
9.6.1 Обзор
Для удаления существующего объекта-контейнера, включая все потомки и снимки состояния, следует выполнить запрос:
К объекту можно также обратиться как
9.6.2 Опции
Следующие опции описывают поддерживаемые операции при удалении существующего объекта-контейнера:
- поддержка возможности удаления существующего объекта-контейнера обозначается наличием опции cdmi_delete_container в контейнере.
9.6.3 Заголовок запроса
Заголовок запроса HTTP для удаления объекта-контейнера CDMI с использованием типа содержимого CDMI приведен в таблице 46.
| Заголовок | Тип | Описание | Требование |
|---|---|---|---|
| X-CDMI-SpecificationVersion | Строка заголовка | Список версий, поддерживаемых клиентом, разделенных запятыми, например, "1.0.2, 1.5, 2.0" | Обязательно |
9.6.4 Тело сообщения-запроса
Сообщение-запрос может содержать тело, соответствующее RFC 2616.
9.6.5 Заголовки ответа
Заголовки ответа могут быть указаны в соответствии с RFC 2616.
9.6.6 Тело сообщения-ответа
Сообщение-ответ может содержать тело, соответствующее RFC 2616.
9.6.7 Статус запроса
В таблице 47 приведены коды состояний HTTP, которые могут возникнуть при удалении объекта-контейнера с использованием типа содержимого CDMI.
Коды состояний HTTP - удаление объекта-контейнера с использованием типа содержимого CDMI
9.6.8 Пример
Пример - Применение DELETE к URI объекта-контейнера:
X-CDMI-Specification-Version: 1.0.2
Будет получен следующий ответ.
9.7. Удаление объекта-контейнера с использованием типа содержимого, отличного от CDMI
9.7.1 Обзор
Для удаления существующего объекта-контейнера, включая всех потомков и снимки состояния, следует выполнить запрос:
путь к облаку CDMI; неотрицательное количество промежуточных контейнеров; имя удаляемого объекта-контейнера.
К объекту можно также обратиться как
9.7.2 Опции
Следующие опции описывают поддерживаемые операции при удалении существующего объекта-контейнера:
- поддержка возможности удаления существующего объекта-контейнера обозначается наличием опции cdmi_delete_container в контейнере.
9.7.3 Заголовки запроса
Сообщение-запрос может содержать заголовки, соответствующие RFC 2616.
9.7.4 Тело сообщения-запроса
Сообщение-запрос может содержать тело, соответствующее RFC 2616.
9.7.5 Заголовки ответа
Сообщение-ответ может содержать заголовки, соответствующие RFC 2616.
9.7.6 Тело сообщения-ответа
Сообщение-ответ может содержать тело, соответствующее RFC 2616.
9.7.7 Статус запроса
В таблице 48 приведены коды состояний HTTP, которые могут возникнуть при удалении объекта-контейнера с использованием типа содержимого, отличного от CDMI.
Коды состояний HTTP - удаление объекта-контейнера
с использованием типа содержимого, отличного от CDMI
9.7.8 Пример
9.8. Создание (POST) нового объекта данных с использованием типа содержимого CDMI
9.8.1 Обзор
Для создания нового объекта данных в заданном контейнере, где имя объекта - идентификатор объекта, присвоенный сервером, следует выполнить запрос:
Для создания нового объекта данных в случае, когда объект не принадлежит контейнеру и доступен только по ID (см. 5.8), следует выполнить запрос:
путь к облаку CDMI; неотрицательное количество существующих промежуточных контейнеров, имена которых разделены одиночными наклонными чертами (т.е., "/").
После создания в "/cdmi_objectid/", к объекту данных можно обращаться как
После создания в контейнере, объект данных доступен как потомок контейнера с именем, присвоенным сервером; к нему также можно обратиться как
9.8.2 Отсроченное завершение создания
В ответ на запрос создания объекта данных сервер может вернуть код 202 Accepted, что указывает на то, что объект находится в процессе создания. Это полезно в случае длительных операций (например, копирования большого объема данных от URI источника). Такой ответ означает, что:
- Сервер должен вернуть заголовок Location, содержащий URI к создаваемому объекту вместе со статусом HTTP 202 Accepted.
- Статус 202 Accepted со стороны сервера удостоверяет, что были пройдены несколько проверок:
- пользователь авторизован для создания нового объекта данных;
- пользователь авторизован для чтения любого исходного объекта, который необходимо переместить, скопировать, сериализовать или десериализовать;
Клиент выполняет операции GET к URI для отслеживания процесса создания. В ответ сервер возвращает два поля в теле сообщения-ответа, которые описывают текущее состояние операции:
- обязательное текстовое поле completionStatus содержит "Processing", "Complete", либо строку сообщения об ошибке, начинающуюся с "Error;
- опциональное поле percentComplete содержит процент выполнения принятого запроса POST (от 0 до 100).
GET не возвращает значение объекта, если completionStatus не равно "Complete". Если создание объекта завершается с ошибкой, создается URI, а поле completionStatus устанавливается равным сообщению об ошибке. Удаление URI после обработки ошибки возлагается на клиента.
9.8.3 Опции
Следующие опции описывают поддерживаемые операции при создании нового объекта данных по ID в "/cdmi_objectid/":
- поддержка возможности создания нового объекта данных посредством этой операции обозначается наличием опции cdmi_post_dataobject_by_ID в системе;
- если объект, создаваемый в "/cdmi_objectid/", является ссылкой, поддержка этой операции обозначается присутствием опции cdmi_create_reference_by_ID в системе;
- если объект, создаваемый в "/cdmi_objectid/", является результатом операции копирования существующего объекта, поддержка этой операции обозначается присутствием опции cdmi_copy_dataobject_by_ID в системе;
- если объект, создаваемый в "/cdmi_objectid/", является результатом операции перемещения, поддержка этой операции обозначается присутствием опции cdmi_object_move_to_ID в системе;
- если объект, создаваемый в "/cdmi_objectid/", является результатом операции десериализации, поддержка этой операции обозначается присутствием опции cdmi_deserialize_dataobject_by_ID в системе;
- если объект, создаваемый в "/cdmi_objectid/", является результатом выполнения операции сериализации, поддержка этой операции обозначается присутствием следующих опций в системе:
Следующие опции описывают поддерживаемые операции при создании нового объекта данных по ID в контейнере:
- поддержка возможности создания нового объекта данных посредством этой операции обозначается наличием опций cdmi_post_dataobject в системе и cdmi_create_dataobject в контейнере;
- если объект, создаваемый таким образом, является ссылкой, поддержка этой операции обозначается присутствием опции cdmi_create_reference в родительском контейнере;
- если объект, создаваемый таким образом, является копией существующего объекта, поддержка этой операции обозначается присутствием опции cdmi_copy_dataobject в родительском контейнере;
- если объект, создаваемый таким образом, является результатом выполнения операции десериализации, поддержка этой операции обозначается присутствием опции cdmi_deserialize_dataobject в родительском контейнере;
- если объект, создаваемый таким образом, является результатом выполнения операции сериализации, поддержка этой операции обозначается присутствием следующих опций в родительском контейнере: "cdmi_serialize_dataobject", "cdmi_serialize_container", "cdmi_serialize_domain" или "cdmi_serialize_queue".
9.8.4 Заголовки запроса
Заголовки запроса HTTP на создание нового объекта CDMI с использованием типа содержимого CDMI приведены в таблице 49.
| Заголовок | Тип | Описание | Требование |
|---|---|---|---|
| Accept | Строка заголовка | "application/cdmi-container" или совместимое значение согласно 5.13.2 | Опционально |
| Content-Type | Строка заголовка | "application/cdmi-object" | Обязательно |
| X-CDMI-SpecificationVersion | Строка заголовка | Список версий, поддерживаемых клиентом, разделенных запятыми, например, "1.0.2, 1.5, 2.0" | Обязательно |
9.8.5 Тело сообщения-запроса
Поля тела сообщения-запроса на создание нового объекта данных с использованием типа содержимого CDMI перечислены в таблице 50.
| Имя поля | Тип | Описание | Требование |
| mimetype | Строка JSON | Тип MIME данных, содержащихся в поле value объекта данных Данное поле может добавляться при создании по значению или десериализации, копировании или перемещении объекта данных. Данное поле должно храниться как часть объекта. Если данное поле не указано, ему должно быть присвоено значение "text/plain". Это поле не должно добавляться при создании ссылки. Перед сохранением значение типа MIME должно быть преобразовано в нижний регистр. | Опционально |
| metadata | Объект JSON | Метаданные объекта данных Если данное поле включено при десериализации, сериализации, копировании или перемещении объекта данных, его значение заменяет метаданные из URI источника. Если данное поле не включается при десериализации, сериализации, копировании или перемещении объекта данных, должны использоваться метаданные URI источника. Если данное поле включается при создании нового объекта данных по передаваемому значению, значение этого поля должно быть использовано как метаданные. Если данное поле не включается при создании нового объекта данных по значению, данному полю должен быть присвоен пустой объект JSON (т.е. "{}"). Данное поле не должно включаться при ссылке на объект данных. | Опционально |
| domainURI | Строка JSON | URI домена-владельца Если домен-владелец не совпадает с родительским доменом, пользователь должен иметь права cross_domain privilege (см. cdmi_member_privileges в таблице 64). |Если не указано иное, должен использоваться корневой домен "/cdmi_domains/". | Опционально |
| deserialize | Строка JSON | URI сериализованного объекта данных CDMI, который должен быть десериализован при создании нового объекта данных | Опционально a |
| serialize | Строка JSON | URI объекта CDMI, который должен быть сериализован в новый объект данных | Опционально a |
| copy | Строка JSON | URI объекта данных или очереди CDMI, которые должны быть скопированы в новый объект данных | Опционально a |
| move | Строка JSON | URI объекта данных или очереди CDMI, которые должны быть скопированы в новый объект данных. Объект по URI источника должен быть удален после успешного завершения копирования. | Опционально a |
| reference | Строка JSON | URI объекта данных CDMI, который должен быть переадресован по ссылке. Если при создании ссылки предоставляются какие-либо другие поля, сервер должен вернуть сообщение об ошибке HTTP 400 Bad Request. | Опционально a |
| deserializevalue | Строка JSON | Объект данных, сериализованный как описано в гл. 15 и кодированный с использованием правил base 64 как описано в RFC 4648. | Опционально a |
| valuetransferencoding | Массив JSON строк JSON | Кодировка, использованная при передаче объекта данных. Определены два значения кодировки. - "utf-8" указывает на то, что объект данных содержит корректную строку UTF-8, и должен передаваться как строка UTF-8 в поле value. - "base64" указывает на то, что объект данных содержит произвольную бинарную последовательность и должен передаваться в поле value как строка в кодировке base 64. Передача в поле value объекта данных значения, не являющегося корректной строкой в кодировке base 64, должно возвращать клиенту ошибку 400 Bad Request. Данное поле должно включаться лишь при создании объекта по значению. Если иное не указано клиентом, сервер должен установить значение поля valuetransferencoding равным "utf-8". Данное поле должно храниться как часть объекта. | Опционально |
| value | Строка JSON | JSON-кодированное значение объекта данных Если данное поле не включено, ему должна быть присвоена пустая строка JSON (т.е., ""). Если поле valuetransferencoding указывает на кодировку UTF-8, значение должно быть строкой UTF-8, сформированной по правилам JSON как описано в RFC 4627. Если поле valuetransferencoding указывает на кодировку base 64, значение должно быть вначале кодировано в base 64 по правилам, описанным в RFC 4648. | Опционально a |
| a Лишь одно из этих полей должно быть указано в любой из операций. За исключением поля value, данные поля не должны сохраняться. Если указано более чем одно из этих полей, сервер должен вернуть сообщение об ошибке 400 Bad Request. | |||
9.8.6 Заголовки ответа
Заголовки HTTP ответов на создание объекта с использованием типа содержимого CDMI указаны в таблице 51.
Заголовки ответа - создание нового объекта данных с использованием типа содержимого CDMI
9.8.7 Тело сообщения-ответа
Поля тела сообщения-ответа на создание нового объекта данных CDMI с использованием типа содержимого CDMI приведены в таблице 52.
Тело сообщения-ответа - создание объекта данных с использованием типа содержимого CDMI
| Имя поля | Тип | Описание | Требование |
|---|---|---|---|
| objectType | Строка JSON | "application/cdmi-object" | Обязательно |
| objectID | Строка JSON | ID объекта | Обязательно |
| objectName | Строка JSON | Имя объекта Для объектов в контейнере должно быть возвращено поле objectName. Для объектов не в контейнере (доступных только по ID), поле objectName не существует и не должно возвращаться. |
Условно |
| parentURI | Строка JSON | URI родительского объекта Для объектов в контейнере должно быть возвращено поле parentURI. Для объектов не в контейнере (доступных только по ID), поле parentURI не существует и не должно передаваться в ответе. Присоединение objectName к parentURI должно всегда давать корректный URI объекта. |
Условно |
| parentID | Строка JSON | ID родительского контейнера Для объектов в контейнере должно быть возвращено поле parentID. Для объектов не в контейнере (доступных только по ID), поле parentID не существует и не должно возвращаться. |
Условно |
| domainURI | Строка JSON | URI домена-владельца | Обязательно |
| capabilitiesURI | Строка JSON | URI опций для объекта | Обязательно |
| completionStatus | Строка JSON | Строка, показывающая статус создания объекта данных, принимающая одно из следующих значений - "Processing" указывает на то, что объект находится в процессе создания. - "Completed" указывает на успешное создание объекта данных. - Строка, начинающаяся с "Error" указывает на то, что при создании объекта возникла ошибка. |
Обязательно |
| percentComplete | Строка JSON | Если значение completionStatus равно "Processing", данное поле, при наличии, должно показывать процент выполнения операции создания объекта как числовое значение от 0 до 100. Если значение completionStatus равно "Complete", данное поле, при наличии, должно иметь значение "100". Если значение completionStatus начинается с "Error", данное поле, при наличии, может содержать любое целое число от 0 до 100. |
Опционально |
| mimetype | Строка JSON | Тип MIME значения объекта данных | Обязательно |
| metadata | JSON Object | Метаданные объекта данных. Данное поле включает любые пользовательские метаданные или метаданные системы данных, указанные в соответствующем поле тела запроса на создание, наряду с метаданными системы хранения, созданными облачным хранилищем. См. детальное описание метаданных в гл. 16. | Обязательно |
9.8.8 Статус запроса
В таблице 53 приведены коды состояний HTTP, которые могут возникать при создании нового объекта с использованием типа содержимого CDMI.
Коды состояний HTTP - создание объекта данных с использованием типа содержимого CDMI
9.8.9 Примеры
1 Применение POST к URI объекта-контейнера: добавление содержимого объекта данных:
Accept: application/cdmi-object
Content-Type: application/cdmi-object
X-CDMI-Specification-Version: 1.0.2
"value" : "This is the Value of this Data Object"
Будет получен следующий ответ.
Content-Type: application/cdmi-object
X-CDMI-Specification-Version: 1.0.2
Location: http://cloud.example.com/MyContainer/0000706D0010B84FAD185C425D8B537E
"objectType" : "application/cdmi-object",
"objectID" : "0000706D0010B84FAD185C425D8B537E",
"objectName": "0000706D0010B84FAD185C425D8B537E",
"parentURI" : "/MyContainer/",
"parentID" : "0000706D0010B84FAD185C425D8B537E",
"domainURI" : "/cdmi_domains/MyDomain/",
"capabilitiesURI" : "/cdmi_capabilities/dataobject/",
"completionStatus" : "Complete",
2 Применение POST к URI ID объекта: добавление содержимого объекта данных:
Accept: application/cdmi-object
Content-Type: application/cdmi-object
X-CDMI-Specification-Version: 1.0.2
"domainURI": "/cdmi_domains/MyDomain/",
Будет получен следующий ответ.
Location: http://cloud.example.com/cdmi_objectid/0000706D0010B84FAD185C425D8B537E
"objectType": "application/cdmi-object",
"completionStatus": "Complete",
9.9. Создание (POST) нового объекта данных с использованием типа содержимого, отличного от CDMI
9.9.1 Обзор
Для создания нового объекта данных в заданном контейнере, где имя объекта - идентификатор объекта, присвоенный сервером, следует выполнить запрос:
путь к облаку CDMI; неотрицательное количество существующих промежуточных контейнеров, имена которых разделены одиночными наклонными чертами (т.е., "/").
После создания в контейнере объект данных доступен как потомок контейнера с именем, присвоенным сервером; к нему также можно обратиться как
9.9.2 Опции
Следующие опции описывают поддерживаемые операции при создании нового объекта данных:
- поддержка возможности создания новых объектов данных посредством данной операции обозначается наличием опций cdmi_post_dataobject и cdmi_create_dataobject в контейнере.
9.9.3 Заголовок запроса
Заголовок запроса HTTP на создание нового объекта CDMI с использованием типа содержимого, отличного от CDMI, приведен в таблице 54.
Заголовок запроса - создание нового объекта данных
с использованием типа содержимого, отличного от CDMI
9.9.4 Тело сообщения-запроса
Тело сообщения-запроса на создание объекта данных содержит данные, которые необходимо сохранить в создаваемом объекте.
9.9.5 Заголовок ответа
Заголовки HTTP ответов на создание объекта с использованием типа содержимого, отличного от CDMI, указаны в таблице 55.
с использованием типа содержимого, отличного от CDMI
9.9.6 Тело сообщения-ответа
9.9.7 Статус запроса
В таблице 56 приведены коды состояний HTTP, которые возникают при создании нового объекта данных с использованием содержимого, отличного от типа CDMI.
с использованием типа содержимого, отличного от типа CDMI
9.9.8 Примеры
1 Применение POST к URI объекта-контейнера: добавьте данные в новый объект:
Content-Type: text/plain;charset=utf-8
Location: http://cloud.example.com/MyContainer/0000706D0010B84FAD185C425D8B537E
2 Применение POST URI ID объекта: добавьте данные в новый объект:
Location: http://cloud.example.com/cdmi_objectid/0000706D0010B84FAD185C425D8B537E
9.10. Создание (POST) нового объекта-очереди с использованием типа содержимого CDMI
9.10.1 Обзор
Для создания нового объекта-очереди (см. раздел 11) в определенном контейнере, где имя очереди - идентификатор объекта, присвоенный сервером, следует выполнить запрос:
Для создания нового объекта-очереди, где объект не принадлежит контейнеру и доступен только по ID (см. 5.8), следует выполнить запрос:
неотрицательное количество существующих промежуточных контейнеров, имена которых разделены одиночными наклонными чертами (т.е., "/").
В случае создания в "/cdmi_objectid/" к объекту-очереди можно обращаться как
После создания в контейнере объект-очередь доступен как потомок контейнера с именем, присвоенным сервером; к нему также можно обратиться как
9.10.2 Отсроченное завершение создания
В ответ на запрос создания объекта-очереди сервер может вернуть код 202 Accepted, что указывает на то, что объект находится в процессе создания. Это полезно в случае длительных операций (например, копирования большого числа элементов очереди из URI источника). Такой ответ означает, что:
- сервер должен вернуть заголовок Location, содержащий URI к создаваемому объекту вместе со статусом HTTP 202 Accepted;
- статус 202 Accepted со стороны сервера удостоверяет, что были пройдены несколько проверок:
- пользователь авторизован для создания нового объекта;
- пользователь авторизован для чтения любого исходного объекта, который необходимо переместить, скопировать, сериализовать или десериализовать;
- достаточно места для создания объекта или, по крайней мере, достаточно места для создания URI к сообщению об ошибке.
Клиент может не иметь опции немедленно обратиться к созданному объекту, например, из-за задержек, вызванных использованием в реализации связности в конечном итоге;
Клиент выполняет операции GET к URI для отслеживания процесса создания. В ответ сервер возвращает два поля в теле сообщения-ответа, которые описывают состояние выполнения операции:
- обязательное текстовое поле completionStatus содержит "Processing", "Complete", либо строку сообщения об ошибке, начинающуюся с "Error";
- опциональное поле percentComplete содержит процент выполнения принятого запроса PUT (от 0 до 100).
GET не возвращает значение объекта, если completionStatus не равно "Complete". Если создание объекта завершается с ошибкой, создается URI, а поле completionStatus устанавливается равным сообщению об ошибке. Удаление URI после обработки ошибки возлагается на клиента.
9.10.3 Опции
Следующие опции описывают поддерживаемые операции при создании нового объекта-очереди по ID в "/cdmi_objectid/":
- поддержка возможности создания нового объекта-очереди посредством данной операции обозначается наличием опции cdmi_post_queue_by_ID в системе;
- если объект, создаваемый в "/cdmi_objectid/", является ссылкой, поддержка этой операции обозначается присутствием опции cdmi_create_reference_by_ID в системе;
- если очередь, создаваемая в "/cdmi_objectid/", является копией существующего объекта-очереди, поддержка этой операции обозначается присутствием опции cdmi_copy_queue_by_ID" в системе;
- если очередь, создаваемая в "/cdmi_objectid/", является результатом выполнения операции перемещения, поддержка этой операции обозначается присутствием опции cdmi_object_move_to_ID в системе;
- если очередь, создаваемая в "/cdmi_objectid/", является результатом выполнения операции десериализации, поддержка этой операции обозначается присутствием опции cdmi_deserialize_queue_by_ID в системе.
Следующие опции описывают поддерживаемые операции при создании нового объекта-очереди по ID в контейнере:
- поддержка возможности создания нового объекта-очереди посредством данной операции обозначается наличием опций the cdmi_post_queue и cdmi_create_queue у контейнера;
- если объект, создаваемый в родительском контейнере, является ссылкой, поддержка этой операции обозначается присутствием опции cdmi_create_reference в родительском контейнере;
- если новая очередь является копией существующей очереди, поддержка этой операции обозначается присутствием опции cdmi_copy_queue в родительском контейнере;
- если новая очередь является результатом выполнения операции перемещения, поддержка этой операции обозначается присутствием опции cdmi_move_queue в родительском контейнере;
- если новая очередь является результатом выполнения операции десериализации, поддержка этой операции обозначается присутствием опции cdmi_deserialize_queue в родительском контейнере.
9.10.4 Заголовки запроса
Заголовки запроса HTTP на создание новой очереди CDMI с использованием типа содержимого CDMI приведены в таблице 57.
с использованием типа содержимого CDMI
| Заголовок | Тип | Описание | Требование |
|---|---|---|---|
| Accept | Строка заголовка | "application/cdmi-container" или совместимое значение согласно 5.13.2 | Опционально |
| Content-Type | Строка заголовка | "application/cdmi-queue" | Обязательно |
| X-CDMI-Specification-Version | Строка заголовка | Список версий, поддерживаемых клиентом, разделенных запятыми, например "1.0.2, 1.5, 2.0" | Обязательно |
9.10.5 Тело сообщения-запроса
Поля тела сообщения-запроса на создание новой очереди с использованием типа содержимого CDMI перечислены в таблице 58.
| Имя поля | Тип | Описание | Требование |
| metadata | Объект JSON | Метаданные объекта-очереди Если данное поле включено при десериализации, сериализации, копировании или перемещении объекта-очереди, его значение заменяет метаданные из URI источника. Если данное поле не включается при десериализации, сериализации, копировании или перемещении объекта-очереди, должны использоваться метаданные URI источника. Если данное поле включается при создании нового объекта-очереди по передаваемому значению, значение этого поля должно быть использовано как метаданные. Если данное поле не включается при создании нового объекта-очереди по значению, данному полю должен быть присвоен пустой объект JSON (т.е. "{}"). Данное поле не должно включаться при ссылке на объект-очередь. | Опционально |
| domainURI | Строка JSON | URI домена-владельца Если домен-владелец не совпадает с родительским доменом, пользователь должен иметь права cross_domain privilege (см. cdmi_member_privileges в табл. 64). Если не указано иное, должен использоваться корневой домен "/cdmi_domains/". | Опционально |
| deserialize | Строка JSON | URI сериализованного объекта-очереди CDMI, который должен быть десериализован при создании нового объекта-очереди | Опционально a |
| copy | Строка JSON | URI объекта-очереди CDMI, который должен быть скопирован в новый объект-очередь | Опционально a |
| move | Строка JSON | URI объекта-очереди CDMI, который должен быть перенесен в URI, указанного в команде PUT. Объект по URI источника должен быть удален после успешного создания новой очереди. | Опционально a |
| reference | Строка JSON | URI объекта-очереди CDMI, который должен быть переадресован по ссылке. Если при создании ссылки предоставляются какие-либо другие поля, сервер должен вернуть сообщение об ошибке HTTP 400 Bad Request. | Опционально a |
| deserializevalue | Строка JSON | Объект-очередь, сериализованный как описано в гл. 15 и кодированный с использованием правил base 64 как описано в RFC 4648. | Опционально a |
| a Лишь одно из этих полей должно быть указано в любой из операций. За исключением поля value, данные поля не должны сохраняться. Если указано более чем одно из этих полей, сервер должен вернуть сообщение об ошибке 400 Bad Request. | |||
9.10.6 Заголовки ответа
Заголовки HTTP ответов на создание объекта-очереди с использованием типа содержимого CDMI указаны в таблице 59.
Заголовки ответа - создание нового объекта-очереди CDMI с использованием типа содержимого CDMI
9.10.7 Тело сообщения-ответа
Поля тела сообщения-ответа на создание нового объекта-очереди CDMI с использованием типа содержимого CDMI приведены таблице 60.
Тело сообщения-ответа - создание объекта-очереди с использованием типа содержимого CDMI (лист 1 из 2)
| Имя поля | Тип | Описание | Требование |
|---|---|---|---|
| objectType | Строка JSON | "application/cdmi-queue" | Обязательно |
| objectID | Строка JSON | ID объекта | Обязательно |
| objectName | Строка JSON | Имя объекта Для объектов в контейнере должно быть возвращено поле objectName. Для объектов не в контейнере (доступных только по ID), поле objectName не существует и не должно возвращаться. |
Условно |
| parentURI | Строка JSON | URI родительского объекта Для объектов в контейнере должно быть возвращено поле parentURI. Для объектов не в контейнере (доступных только по ID), поле parentURI не существует и не должно передаваться в ответе. Присоединение objectName к parentURI должно всегда давать корректный URI объекта. |
Условно |
| parentID | Строка JSON | ID родительского контейнера Для объектов в контейнере должно быть возвращено поле parentID. Для объектов не в контейнере (доступных только по ID), поле parentID не существует и не должно возвращаться. |
Условно |
| domainURI | Строка JSON | URI домена-владельца | Обязательно |
| capabilitiesURI | Строка JSON | URI опций для объекта | Обязательно |
| completionStatus | Строка JSON | Строка, указывающая, находится ли объект в процессе создания (а после создания - был ли он создан успешно или с ошибкой). Значение должно быть строкой "Processing", "Complete" или строкой, начинающейся с "Error". | Обязательно |
| percentComplete | Строка JSON | Если значение completionStatus равно "Processing", данное поле, при наличии, должно показывать процент выполнения операции создания объекта как числовое значение от 0 до 100. Если значение completionStatus равно "Complete", данное поле, при наличии, должно иметь значение "100". Если значение completionStatus начинается с "Error", данное поле, при наличии, может содержать любое целое число от 0 до 100. |
Опционально |
| metadata | Объект JSON | Метаданные объекта-очереди. Данное поле включает любые пользовательские метаданные или метаданные системы данных, указанные в соответствующем поле тела запроса на создание, наряду с метаданными системы хранения, созданными облачным хранилищем. См. детальное описание метаданных в разделе 16. | Обязательно |
| queueValues | Строка JSON | Диапазон индексов значений в очереди. Каждое значение в очереди должно иметь уникальный монотонно возрастающий целый положительный индекс, начиная с 0. Если очередь пустая, должна возвращаться пустая строка. Если очередь не пустая, должны быть возвращены минимальный и максимальный (в таком порядке) индекс значений в очереди, разделенные дефисом ("-") | Обязательно |
9.10.8 Статус запроса
В таблице 61 приведены коды состояний HTTP, возникающие при создании нового объекта-очереди с помощью типа содержимого CDMI.
9.10.9 Пример
Пример - Применение POST к URI контейнера: добавление объекта-очереди:
Content-Type: application/cdmi-queue
Accept: application/cdmi-queue
Content-Type: application/cdmi-queue
X-CDMI-Specification-Version: 1.0.2
Location: http://cloud.example.com/MyContainer/0000706D0010B84FAD185C425D8B537E
"objectName" : "0000706D0010B84FAD185C425D8B537E",
"domainURI" : "/cdmi_domains/MyDomain/",
10. Операции с ресурсами объекта-домена
10.1. Обзор
Объекты-домены отражают концепцию административного владения сохраненными данными в рамках системы хранения CDMITM. CDMI может включать иерархию доменов, которые предоставляют доступ к связанной с доменами информации в системе CDMI. Иерархия доменов представляет собой набор объектов CDMI, соответствующих доменам-родителям и доменам-потомкам, причем каждый домен соответствует логически организованной группе объектов, которые должны управляться совместно. В соответствии с облачной моделью хранения домен интегрирует информацию о принадлежащих к нему объектах и передает ее родительскому домену, упрощая операции учета и управления.
Объекты-домены создаются в контейнере the cdmi_domains, находящемся в корневом URI облачного хранилища. Если опция cdmi_create_domain присутствует в URI некоторого домена, облачное хранилище поддерживает создание доменов-потомков по этому URI. Если облачное хранилище поддерживает домены, должен присутствовать контейнер cdmi_domains.
Если клиент включает или передает поля десериализации, не описанные в настоящем стандарте, эти поля должны передаваться как часть объекта.
10.1.1 Метаданные объекта-домена
10.1.2 Сводка объекта-домена
Сводки объекта-домена содержат обобщенные метрики об использовании домена и оплаты. В случае поддержки данной функций, каждый домен должен содержать контейнер "cdmi_domain_summary". Подобно любому контейнеру, вложенный контейнер сводки домена может содержать список контроля доступа (Access Control List, ACL) (см. 16.1), который ограничивает доступ к этой информации.
Внутри контейнера-сводки каждого домена содержится набор объектов данных сводки, которые создаются системой облачного хранения. Контейнеры "yearly", "monthly" и "daily" этих объектов данных содержат объекты сводки, относящиеся к каждому году, месяцу и дате, соответственно. Эти контейнеры организованы в следующие структуры:
http://example.com/cdmi_domains/domain/
http://example.com/cdmi_domains/domain/cdmi_domain_summary/
http://example.com/cdmi_domains/domain/cdmi_domain_summary/cumulative
http://example.com/cdmi_domains/domain/cdmi_domain_summary/daily/
http://example.com/cdmi_domains/domain/cdmi_domain_summary/daily/2009-07-01
http://example.com/cdmi_domains/domain/cdmi_domain_summary/daily/2009-07-02
http://example.com/cdmi_domains/domain/cdmi_domain_summary/daily/2009-07-03
ttp://example.com/cdmi_domains/domain/cdmi_domain_summary/monthly/
http://example.com/cdmi_domains/domain/cdmi_domain_summary/monthly/2009-07
http://example.com/cdmi_domains/domain/cdmi_domain_summary/monthly/2009-08
http://example.com/cdmi_domains/domain/cdmi_domain_summary/monthly/2009-10
http://example.com/cdmi_domains/domain/cdmi_domain_summary/yearly/
http://example.com/cdmi_domains/domain/cdmi_domain_summary/yearly/2009
http://example.com/cdmi_domains/domain/cdmi_domain_summary/yearly/2010
Объект сводки "cumulative" покрывает весь промежуток времени, от создания домена до момента доступа к сводке "cumulative". Каждый объект данных ежедневного, ежемесячного и ежегодного уровня содержит сводки информации о домене, относящейся к соответствующему временному промежутку, ограниченного временем создания домена и временем доступа к сводке.
Если промежуток времени начинается раньше, чем был создан домен, информация сводки включает время, начиная со времени создания домена и заканчиваясь запрошенной датой окончания промежутка.
Пример - Если домен был создан в полдень 4 июля 2009 г., ежедневная сводка "2009-07-04" содержит информацию до полуночи этого дня, ежемесячная сводка "2009-07" содержит информацию от полудня 4 июля 2009 г. до полуночи 31 июля, а ежегодная сводка "2009" содержит информацию от полудня 4 июля до 31 декабря.
Если временной промежуток начинается позже времени создания домена и заканчивается раньше момента доступа сводке, объект сводки содержит полную информацию за данный промежуток времени.
Пример - Если домен был создан 4 июля 2009 г., то 10 июля ежедневная сводка "2009-07-06" объекта содержит информацию за полный день.
Если временной промежуток заканчивается позже текущего времени доступа, объект сводки данных о домене содержит частичную информацию от начала указанного периода времени (или времени создания домена) до момента доступа.
Пример - Если домен создан 4 июля 2009 г., то в полдень 10 июля ежедневная сводка "2009-07-10" содержит информацию от начала суток до полудня.
Информация, приведенная в таблице 63, должна присутствовать в каждом объекте сводки о домене, в представлении JSON.
"cdmi_summary_objecthours" : "382239734",
"cdmi_summary_puts" : "234234",
"cdmi_summary_gets" : "489432",
"cdmi_summary_bytehours" : "334895798347",
"cdmi_summary_writes" : "7218368343",
"cdmi_summary_reads" : "11283974933",
"cdmi_summary_charge" : "4289.23 USD"
Если указана стоимость услуг, она соответствует эксплуатационным расходам (не включая фиксированные тарифы) на выполненные операции и уже потраченные объемы хранения и передачи. Стоимость услуг указывается отдельно.
Сводка о домена может быть расширена производителями, включая дополнительные по сравнению с описанными в настоящем стандарте элементы метаданных или отчеты о домене. Имена дополнительных полей не должны начинаться с "cdmi_".
10.1.3 Пользователи объекта-домена
В окружении облачного хранилища, подобно тому, как программно создаются домены, с использованием таких интерфейсов могут заполняться учетные данные пользователей объекта-домена. Наличие доступа к управлению пользователями позволяет самостоятельную регистрацию, автоматическую подготовку к работе и другие продвинутые средства самообслуживания, либо напрямую через CDMI, либо через программные средства, интерфейс которых использует CDMI.
Опция членства в домене дает информацию (и позволяет описывать) о конечных пользователях и группах пользователей, которым разрешен доступ к домену через CDMI и другие протоколы доступа. Концепция членства в домене не предназначена для замены или вытеснения ACL (см. 16.1), но предоставляет единое унифицированное пространство для хранения информации о пользователях и правах доступа, которые используются ACL в контексте домена (см. описание модели в 10.1.4). Кроме того, это пространство также позволяет хранить схемы аутентификации для внешних провайдеров аутентификации, таких как LDAP и AD.
Если данная функциональность поддерживается реализацией, в каждом домене должен присутствовать контейнер с именем "cdmi_domain_members". Как другие домены, он может включать список контроля доступа (Access Control List, см. 16.1), который ограничивает доступ к этой информации.
В каждом таком контейнере присутствует набор объектов-пользователей, которые определяются через CDMI. Эти объекты организованы в следующую структуру:
http://example.com/cdmi_domains/domain/
http://example.com/cdmi_domains/domain/cdmi_domain_members/
http://example.com/cdmi_domains/domain/cdmi_domain_members/john_doe
http://example.com/cdmi_domains/domain/cdmi_domain_members/john_smith
Контейнер пользователей домена также может включать вложенные контейнеры, содержащие объекты данных. Эти объекты данных обрабатываются таким же образом, что и объекты данных в контейнере пользователей домена, и имя вложенных контейнеров не несет специального значения. Это позволяет определять различные отношения между правами безопасности различных групп и объектов и позволяет выделять группы с общими правами.
В таблице 64 приведены настройки домена, которые должны присутствовать для каждого объекта-пользователя домена.
Необходимые настройки для объектов-пользователей домена
В таблице 65 приведены настройки домена, которые должны присутствовать в каждом объекте делегирования пользователя домена.
Необходимые настройки объектов делегирования пользователя домена
"cdmi_member_credentials" : "p+5/oX1cmExfOlrUxhX1lw==",
2 Пример объекта делегирования пользователя домена:
"cdmi_member_enabled" : "true",
"cdmi_member_type" : "delegation",
10.1.4 Использование домена в управлении доступом
При выполнении транзакции с объектом CDMI связанный объект-домен (т.е., объект-домен, указанный в поле domainURI) определяет контекст аутентификации. Личность пользователя и его права, представленные как часть транзакции, сравниваются со списком пользователей домена для определения, авторизован ли пользователь в домене, и установления имени принципала. Если имя принципала установлено, оно сравнивается с ACL объекта для определения допустимости транзакции.
При обработке пользователей домена в первую очередь обрабатываются делегирования (в произвольном порядке), а затем записи пользователей (в произвольном порядке). Если имеется хотя бы одна подходящая запись и не найдено ни одной записи, которая блокирует пользователя, он считается членом домена.
Если изначально создается вложенный домен, контейнер членства содержит одну запись пользователя, которая является делегированием, устанавливающей URI делегирования равным URI родительского домена.
10.1.5 Представления объекта-домена
Представления в данном разделе показаны с использованием нотации JSON. И клиенты, и серверы должны поддерживать представление JSON в кодировке UTF-8. В телах сообщений-запросов и ответов поля JSON могут указываться и возвращаться в любом порядке, за исключением (при наличии) полей объекта-домена childrenrange и children, которые указываются последними и в данном порядке.
10.2. Создание объекта-домена с использованием типа содержимого CDMI
10.2.1 Обзор
Для создания нового объекта-домена следует выполнить запрос:
После создания к домену можно обращаться как
10.2.2 Опции
Следующие опции описывают поддерживаемые операции при создании нового домена:
- если новый объект-домен является копией существующего объекта-домена, поддержка этой операции обозначается наличием опции cdmi_copy_domain в домене-источнике;
- если новый домен получается в результате операции десериализации, поддержка этой операции обозначается наличием опции cdmi_deserialize_domain в родительском домене.
10.2.3 Заголовки запроса
Заголовки HTTP запросов на создание объекта-домена CDMI с использованием типа содержимого CDMI приведены в таблице 66.
| Заголовок | Тип | Описание | Требование |
|---|---|---|---|
| Accept | Строка заголовка | "application/cdmi-container" или совместимое значение согласно 5.13.2 | Опционально |
| Content-Type | Строка заголовка | "application/cdmi-domain" | Обязательно |
| X-CDMI-SpecificationVersion | Строка заголовка | Список версий, поддерживаемых клиентом, разделенных запятыми, например "1.0.2, 1.5, 2.0" | Обязательно |
10.2.4 Тело сообщения-запроса
Поля тела сообщения-запроса на создание объекта-домена с использованием типа содержимого CDMI приведены в таблице 67.
Тело сообщения-запроса - создание объекта-домена с использованием типа содержимого CDMI
| Имя поля | Тип | Описание | Требование |
| metadata | Объект JSON | Метаданные объекта-домена Если данное поле включено при десериализации, сериализации, копировании или перемещении объекта-домена, то значение этого поля должно заменять метаданные URI источника. Если данное поле не включено при десериализации, сериализации, копировании или перемещении объекта-домена то следует использовать метаданные URI источника. Если данное поле включено при создании нового объекта по значению, это поле должно быть использовано как метаданные. Если данное поле не включено при создании нового домена по значению, этому полю следует поставить в соответствие пустой объект JSON (т.е.,"{}"). | Опционально |
| copy | Строка JSON | URI объекта-домена CDMI, который должен быть скопирован в новый объект-домен, включая всех потомков и списки пользователей исходного домена | Опционально a |
| move | Строка JSON | URI существующего локального или удаленного объекта-домена CDMI (URI источника), который должен быть перемещен, включая все дочерние домены, в URI, указанный в команде PUT. Содержимое объекта-домена и всех поддоменов, включая ID объекта, должны при перемещении сохраняться. После успешного создания всех необходимых объектов, перемещаемый домен и вложенные домены по исходному URI должны быть удалены. Если недостаточно прав для чтения объектов по URI источника, записи объектов по URI нового объекта, удаления объектов по URI источника или одна из этих операций завершается с ошибкой, сервер должен вернуть код результата 400 Bad Request, причем исходный и конечный объекты должны сохраниться неизменными. | Опционально a |
| deserialize | Строка JSON | URI сериализованного объекта данных CDMI, который должен быть десериализован для создания нового домена, включая всех дочерних объектов исходного сериализованного объекта данных | Опционально a |
| deserializevalue | Строка JSON | Сериализованный объект-домен (см. гл. 15), кодированный с помощью base 64 как описано в RFC 4648. | Опционально a |
| a Лишь одно из этих полей должно быть указано в любой из операций. За исключением поля value, данные поля не должны сохраняться. Если указано более чем одно из этих полей, сервер должен вернуть сообщение об ошибке 400 Bad Request. | |||
10.2.5 Заголовки ответа
Заголовки HTTP ответа на создание объекта-домена CDMI с использованием типа содержимого CDMI указаны в таблице 68.
10.2.6 Тело сообщения-ответа
Поля тела сообщения-ответа на создание объекта-домена CDMI с использованием типа содержимого CDMI приведены в таблице 69.
| Имя поля | Тип | Описание | Требование |
|---|---|---|---|
| objectType | Строка JSON | "application/cdmi-domain" | Обязательно |
| objectID | Строка JSON | ID домена | Обязательно |
| objectName | Строка JSON | Имя объекта | Обязательно |
| parentURI | Строка JSON | URI родительского объекта Добавление objectName к parentURI должно всегда давать корректный URI объекта. | Обязательно |
| parentID | Строка JSON | ID родительского объекта-контейнера | Обязательно |
| domainURI | Строка JSON | URI домена-владельца. Владелец объекта-домена - всегда сам домен. | Обязательно |
| capabilitiesURI | Строка JSON | URI опций объекта | Обязательно |
| metadata | JSON Object | Метаданные объекта-домена. Могут включать пользовательские метаданные и метаданные системы данных, указанные в теле запроса на создание (поле metadata) вместе с метаданными системы хранения, создаваемыми облачным хранилищем. Подробнее о метаданных см. гл. 16. | Обязательно |
| childrenrange | Строка JSON | Вложенные домены, представленные как диапазон. При запросе диапазона вложенных доменов это поле показывает потомков, выраженных диапазоном. | Обязательно |
| children | Массив JSON | Имена доменов, вложенных в данный домен. Дочерние контейнеры завершаются символом "/". | Обязательно |
10.2.7 Статус запроса
В таблице 70 приведены коды состояний HTTP, возникающие при создании объекта-домена с использованием типа содержимого CDMI.
Коды состояний HTTP - создание объекта-домена с использованием типа содержимого CDMI
10.2.8 Пример
Пример - Применение PUT к URI домена: добавление имени домена и метаданных:
PUT /cdmi_domains/MyDomain/ HTTP/1.1
Accept: application/cdmi-domain
Content-Type: application/cdmi-domain X-CDMI-Specification-Version: 1.0.2
Будет получен следующий ответ.
Content-Type: application/cdmi-domain X-CDMI-Specification-Version: 1.0.2
"objectType" : "application/cdmi-domain",
"objectID" : "00007E7F00104BE66AB53A9572F9F51E",
"parentURI" : "/cdmi_domains/",
"parentID" : "00007E7F0010C058374D08B0AC7B3550",
"domainURI" : "/cdmi_domains/MyDomain/",
"capabilitiesURI" : "/cdmi_capabilities/domain/",
10.3. Чтение объекта-домена с использованием типа содержимого CDMI
10.3.1 Обзор
Для чтения всех полей существующего объекта-домена следует выполнить запрос:
Для чтения одного или нескольких выбранных полей из существующего объекта-домена следует выполнить один из следующих запросов:
К объекту можно также обратиться как
10.3.2 Опции
- поддержка возможности чтения метаданных существующего объекта-домена обозначается наличием опции cdmi_read_metadata в домене.
- поддержка возможности перечисления потомков существующего объекта-домена обозначается наличием опции cdmi_list_children в домене.
10.3.3 Заголовки запроса
Заголовки HTTP запроса на чтение из объекта-домена CDMI с использованием типа содержимого CDMI приведены в таблице 71.
| Заголовок | Тип | Описание | Требование |
|---|---|---|---|
| Accept | Строка заголовка | "application/cdmi-container" или совместимое значение согласно 5.13.2 | Опционально |
| X-CDMI-SpecificationVersion | Строка заголовка | Список версий, поддерживаемых клиентом, разделенных запятыми, например, "1.0.2, 1.5, 2.0" | Обязательно |
10.3.4 Тело сообщения-запроса
Тело сообщения должно отсутствовать в запросе.
10.3.5 Заголовки ответа
Заголовки HTTP ответа для чтения объекта-домена CDMI с использованием типа содержимого CDMI приведены в таблице 72.
с использованием типа содержимого CDMI
10.3.6 Тело сообщения-ответа
Поля тела сообщения-ответа для чтения объекта-домена CDMI с использованием типа содержимого CDMI приведены в таблице 73.
| Имя поля | Тип | Описание | Требование |
|---|---|---|---|
| objectType | Строка JSON | "application/cdmi-domain" | Обязательно |
| objectID | Строка JSON | ID объекта | Обязательно |
| objectName | Строка JSON | Имя объекта | Обязательно |
| parentURI | Строка JSON | URI родительского объекта | Обязательно |
| parentID | Строка JSON | ID объекта родительского контейнера | Обязательно |
| domainURI | Строка JSON | URI домена-владельца. Владелец объекта-домена - всегда сам домен. | Обязательно |
| capabilitiesURI | Строка JSON | URI опций объекта | Обязательно |
| metadata | Объект JSON | Метаданные объекта-домена. Могут включать пользовательские метаданные и метаданные системы данных, указанные в теле запроса на создание (поле metadata) вместе с метаданными системы хранения, создаваемыми облачным хранилищем. Подробнее о метаданных см. гл. 16. | Обязательно |
| childrenrange | Строка JSON | Вложенные домены, представленные как диапазон. При запросе диапазона вложенных доменов это поле показывает потомков, выраженных диапазоном. | Обязательно |
| children | Массив JSON | Имена доменов, вложенных в данный домен. Дочерние контейнеры завершаются символом "/". | Обязательно |
Опциональные запрошенные поля, отсутствующие в объекте, опускаются в ответе.
10.3.7 Статус запроса
В таблице 74 приведены коды состояний HTTP, которые могут возникать при чтении из объекта-домена с использованием типа содержимого CDMI.
10.3.8 Примеры
1 Применение GET к URI домена для чтения всех полей объекта:
GET /cdmi_domains/MyDomain/ HTTP/1.1
Accept: application/cdmi-domain X-CDMI-Specification-Version: 1.0.2
Content-Type: application/cdmi-domain X-CDMI-Specification-Version: 1.0.2
"objectType" : "application/cdmi-domain",
"objectID" : "00007E7F00104BE66AB53A9572F9F51E",
"parentURI" : "/cdmi_domains/",
"parentID" : "00007E7F0010C058374D08B0AC7B3550",
"domainURI" : "/cdmi_domains/MyDomain/",
"capabilitiesURI" : "/cdmi_capabilities/domain/",
2 Применение GET к URI объекта для чтения полей parentURI и children домена:
GET /MyDomain/?parentURI;children HTTP/1.1
Accept: application/cdmi-domain
X-CDMI-Specification-Version: 1.0.2
Будет получен следующий ответ.
Content-Type: application/cdmi-domain X-CDMI-Specification-Version: 1.0.2
"parentURI" : "/cdmi_domains/",
3 Применение GET к URI домена для чтения первых двух потомков домена:
GET /MyDomain/?childrenrange;children:0-1 HTTP/1.1
Accept: application/cdmi-domain X-CDMI-Specification-Version: 1.0.2
Будет получен следующий ответ.
Content-Type: application/cdmi-domain X-CDMI-Specification-Version: 1.0.2
10.4. Изменение объекта-домена с использованием типа содержимого CDMI
10.4.1 Обзор
Для изменения некоторых или всех полей существующего объекта-домена следует выполнить запрос:
Для добавления, обновления или удаления определенных элементов метаданных существующего объекта-домена следует выполнить запрос:
PUT
Объект-контейнер также доступен как
10.4.2 Опции
Следующие опции описывают поддерживаемые операции при изменении существующего домена:
- поддержка возможности изменения метаданных существующего объекта-домена обозначается наличием опции cdmi_modify_metadata в домене.
10.4.3 Заголовки запроса
Заголовки запроса HTTP для изменения объекта-домена CDMI с использованием типа содержимого CDMI перечислены в таблице 75.
10.4.4 Тело сообщения-запроса
Поля тела запроса на изменение объекта-домена с использованием типа содержимого CDMI перечислены в таблице 76.
Тело сообщения-запроса - изменение объекта-домена
с использованием типа содержимого CDMI (лист 1 из 2)
| Имя поля | Тип | Описание | Требование |
| metadata | Объект JSON | Метаданные для объекта-домена. Если присутствуют, указанные метаданные замещают существующие метаданные объекта. Если URI указывает на отдельные элементы метаданных, остальные элементы не должны меняться. Подробнее о метаданных см. гл. 16. | Опционально |
| copy | Строка JSON | URI объекта-домена CDMI, который должен быть скопирован в существующий объект-домен. Должны быть скопированы лишь метаданные и списки пользователей домена, но не дочерних доменов. | Опционально a |
| deserialize | Строка JSON | URI сериализованного объекта данных CDMI, который должен быть десериализован для изменения существующего домена. ID сериализованного домена должен совпадать с ID изменяемого домена. Если сериализованный домен не имеет потомков, изменение применяется только к объекту-домену и не затрагивает существующих потомков. Если сериализованный объект-домен имеет потомков, то операции создания, изменения и удаления должны рекурсивно применяться к каждому потомку, в зависимости от различий между предоставленным сериализованным состоянием и текущим состоянием потомков. | Опционально a |
| deserializevalue | Строка JSON | Сериализованный объект-домен (см. гл. 15), кодированный с помощью base 64 как описано в RFC 4648. ID сериализованного домена должен совпадать с ID домена-назначения. Если сериализованный домен не имеет потомков, изменение применяется только к объекту-домену и не затрагивает существующих потомков. Если сериализованный объект-домен имеет потомков, то операции создания, изменения и удаления должны рекурсивно применяться к каждому потомку, в зависимости от различий между предоставленным сериализованным состоянием и текущим состоянием потомков. | Опционально a |
| a Лишь одно из этих полей должно быть указано в любой из операций. За исключением поля value, данные поля не должны сохраняться. | |||
10.4.5 Заголовок ответа
Заголовок HTTP ответа на изменение объекта-домена CDMI с использованием типа содержимого CDMI указан в таблице 77.
с использованием типа содержимого CDMI
| Заголовок | Тип | Описание | Требование |
|---|---|---|---|
| Location | Строка заголовка | Сервер должен вернуть URI, на который происходит переадресация, если объект является ссылкой. | Условно |
10.4.6 Тело сообщения-ответа
10.4.7 Статус запроса
В таблице 78 приведены коды состояний HTTP, которые возникают при изменении объекта-домена с использованием типа содержимого CDMI.
10.4.8 Пример
PUT /cdmi_domains/myDomain/ HTTP/1.1
Будет получен следующий ответ.
10.5. Удаление объекта-домена с использованием типа содержимого CDMI
10.5.1 Обзор
Для удаления существующего домена и переноса всех связанных с ним объектов в другой домен (для сохранения доступа) следует выполнить запрос:
К объекту можно также обратиться как
10.5.2 Опции
Следующие опции описывают поддерживаемые операции при удалении существующего домена:
- поддержка возможности удаления существующего объекта-домена обозначается наличием опции cdmi_delete_domain в домене.
10.5.3 Заголовки запроса
Заголовки запроса HTTP на удаление объекта-домена CDMI с использованием типа содержимого CDMI приведены в таблице 79.
с использованием типа содержимого CDMI
| Заголовок | Тип | Описание | Требование |
|---|---|---|---|
| X-CDMI-SpecificationVersion | Строка заголовка | Список версий, поддерживаемых клиентом, разделенных запятыми, например "1.0.2, 1.5, 2.0" | Обязательно |
10.5.4 Тело сообщения-запроса
10.5.5 Заголовки ответа
10.5.6 Тело сообщения-ответа
Сообщение-ответ может содержать тело, соответствующее RFC 2616.
10.5.7 Статус запроса
В таблице 80 приведены коды состояний HTTP, которые могут возникнуть при удалении объекта-домена с использованием типа содержимого CDMI.
Коды состояний HTTP - удаление объекта-домена с использованием типа содержимого CDMI
10.5.8 Пример
Пример - Применение DELETE к URI домена:
DELETE /cdmi_domains/MyDomain/ HTTP/1.1
X-CDMI-Specification-Version: 1.0.2
Будет получен следующий ответ.
11. Операции с ресурсами объекта-очереди
11.1. Обзор
Объекты-очереди предоставляют доступ в порядке поступления (FIFO, "первый пришел - первый вышел") при сохранении и получении данных. Для добавления элемента в объект-очередь поставщик данных выполняется запрос POST, а получатель данных выполняет запрос GET для получения элементов из очереди, при этом одновременно полученные элементы удаляются из очереди. Очереди предоставляют простой механизм, позволяющий нескольким поставщикам данных надежно передавать данные одному получателю. Если данный механизм поддерживается облачным хранилищем, клиенты создают объекты очереди как описано в 9.10 и в данном разделе.
В модели CDMITM объекты-очереди могут адресоваться двумя способами:
- по имени (например, http://cloud.example.com/queueobject); and
- по ID объекта (например, http://cloud.example.com/cdmi_objectid/0000706D0010B84FAD185C425D8B537E).
Каждая очередь имеет единственный глобально-уникальный ID, который остается неизменным на протяжении жизненного цикла объекта. Каждый объект-очередь должен иметь один или несколько адресов URI для обеспечения доступа к объекту.
Очередь может иметь родительский объект. В этом случае, объект-очередь наследует те элементы метаданных системы данных, которые не заданы явным образом в самом объекте-очереди.
1 Объект-очередь "receipts.queue", сохраненный по нижеуказанному URI, наследует метаданные системы данных от родительского контейнера "finance":
http://cloud.example.com/finance/receipts.queue
Индивидуальные поля объекта-очереди могут быть доступны указанием имени поля после символа "?", следующего за URI объекта.
2 Следующий URI возвращает в теле сообщения-ответа в поле value элемент из головы очереди (элемент, дольше других находящийся в очереди):
http://cloud.example.com/queueobject?value
Кодировка данных, передаваемых в поле value объекта-очереди, определяется значением поля valuetransferencoding объекта-очереди:
- если valuetransferencoding равно "utf-8", данные, сохраняемые в очереди, должны быть корректной строкой UTF-8 и должны передаваться в поле value как строка UTF-8;
- если valuetransferencoding равно "base64", данные, сохраняемые в очереди, могут содержать произвольные бинарные последовательности и должны передаваться в поле value как строки в кодировке base 64.
Указание диапазона в запросе к полю value позволяет получить доступ к отдельным байтам объекта в очереди. Так, следующий URI возвращает первую тысячу байт элемента в голове очереди (элемента, дольше других находящегося в очереди):
http://cloud.example.com/queueobject?value:0-999
Так как диапазон байтов строки UTF-8 часто не является корректной строкой UTF-8, ответ на запрос диапазона должен всегда передаваться как строка в кодировке base 64.
Диапазоны байтов определяются как целые диапазоны, включающие границы (пункт 14.35.1 в RFC 2616).
Если клиент поддерживает или включает поля десериализации, которые не определены в настоящем стандарте, эти поля должны храниться как часть объекта.
11.1.1 Метаданные объекта-очереди
Метаданные объекта-очереди могут также включать произвольные элементы, созданные пользователем, и метаданные системы данных, как описано в разделе 16.
11.1.2 Адресация объекта-очереди
Каждый объект-очередь может адресоваться одним или несколькими URI, и все доступные операции должны выполняться через эти URI.
11.1.3 Представления объекта-очереди
Представления в данном разделе показаны с использованием нотации JSON. И клиенты, и серверы должны поддерживать представление JSON в кодировке UTF-8. В телах сообщений-запросов и ответов поля JSON могут указываться и возвращаться в любом порядке, за исключением (при наличии) полей valuerange и value, которые указываются последними и в данном порядке.
11.2. Создание объекта-очереди с использованием типа содержимого CDMI
11.2.1 Обзор
Для создания нового объекта-очереди следует выполнить запрос:
О создании объекта-очереди по ID, см. 9.10.
путь к облаку CDMI; неотрицательное число уже существующих промежуточных контейнеров, имена которых разделены одинарной наклонной чертой (т.е., "/"); Имя создаваемого объекта-очереди.
После создания, к объекту можно также обратиться как
Новые объекты-очереди должны быть пустыми, за исключением случаев, когда они создаются посредством копирования или перемещения существующей непустой очереди, либо в результате десериализации непустой сериализованной очереди.
11.2.2 Отсроченное завершение создания:
В ответ на запрос создания объекта-очереди, сервер может вернуть код 202 Accepted, что указывает на то, что объект находится в процессе создания. Это полезно в случае длительных операций (например, копировании объекта-очереди с большим количеством значений). Такой ответ означает, что:
- сервер должен вернуть заголовок Location, содержащий URI к создаваемому объекту вместе со статусом HTTP 202 Accepted;
- статус 202 Accepted со стороны сервера удостоверяет, что были пройдены несколько проверок:
- пользователь авторизован для создания нового объекта-контейнера;
- пользователь авторизован для чтения любого исходного объекта, который необходимо переместить, скопировать, сериализовать или десериализовать;
- достаточно места для создания объекта-контейнера или, по крайней мере, достаточно места для создания URI к сообщению об ошибке.
- клиент может не иметь опции немедленно обратиться к созданному объекту, например, из-за задержек, вызванных использованием в реализации связности в конечном итоге.
Клиент выполняет операции GET к URI для отслеживания процесса создания. В ответ сервер возвращает два поля в теле сообщения-ответа, которые описывают состояние выполнения операции:
- обязательное текстовое поле completionStatus содержит "Processing", "Complete", либо строку сообщения об ошибке, начинающуюся с "Error";
- опциональное поле percentComplete содержит процент выполнения принятого запроса PUT (от 0 до 100).
GET не возвращает объекты из очереди, если completionStatus не равно "Complete". Если создание объекта завершается с ошибкой, создается URI, а поле completionStatus устанавливается равным сообщению об ошибке. Удаление URI после обработки ошибки возлагается на клиента.
11.2.3 Опции
Следующие опции описывают поддерживаемые операции при создании нового объекта-очереди:
- поддержка возможности создания нового объекта-очереди обозначается наличием опции cdmi_create_queue в родительском контейнере;
- если очередь, создаваемая в родительском контейнере, является ссылкой, поддержка этой операции обозначается наличием опции cdmi_create_reference в родительском контейнере;
- если новая очередь является копией существующей, поддержка копирования обозначается наличием опции cdmi_copy_queue в родительском контейнере;
- если новая очередь создается в результате перемещения существующей очереди, поддержка этой операции обозначается наличием опции cdmi_move_queue в родительском контейнере;
- если новая очередь создается в результате операции десериализации, поддержка этой операции обозначается наличием опции cdmi_deserialize_queue в родительском контейнере.
11.2.4 Заголовки запроса
Заголовки HTTP запросов на создание объекта-очереди CDMI с использованием типа содержимого CDMI приведены в таблице 81.
Заголовки запроса - создание объекта-очереди с использованием типа содержимого CDMI
11.2.5 Тело сообщения-запроса
Поля тела сообщения-запроса на создание объекта-очереди с использованием типа содержимого CDMI приведены в таблице 82.
Тело сообщения-запроса - создание объекта-очереди
с использованием типа содержимого CDMI
| Имя поля | Тип | Описание | Требование |
| metadata | Объект JSON | Метаданные объекта-очереди Если данное поле включено при десериализации, сериализации, копировании или перемещении объекта-очереди, то значение этого поля должно заменять метаданные URI источника. Если данное поле не включено при десериализации, сериализации, копировании или перемещении объекта-очереди, то следует использовать метаданные URI источника. Если данное поле включено при создании нового объекта по значению, это поле должно быть использовано как метаданные. Если данное поле не включено при создании нового объекта по значению, этому полю следует поставить в соответствие пустой объект JSON (т.е.,"{}"). Данное поле не должно быть задано при создании ссылки на объект-очередь. | Опционально |
| domainURI | Строка JSON | URI домена-владельца В случае отличия от родительского домена, пользователь должен обладать правами cross_domain (см. cdmi_member_privileges в таблице 64). Если не указано, должен использоваться родительский домен. | Опционально |
| deserialize | Строка JSON | URI сериализованного объекта данных CDMI, который должен быть десериализован при создании новой очереди | Опционально a |
| copy | Строка JSON | URI объекта CDMI, который должен быть скопирован в новый объект-очередь | Опционально a |
| move | Строка JSON | URI существующего локального или удаленного объекта-очереди CDMI (URI источника), который должен быть перемещен в URI, указанный в команде PUT. Содержимое объекта-очереди, включая ID объекта, должны при перемещении сохраняться, а исходный объект должен быть уничтожен после успешного копирования. Если недостаточно прав для чтения объекта по URI источника, записи объекта по URI нового объекта, удаления объектов по URI источника или одна из этих операций завершается с ошибкой, сервер должен вернуть код результата 400 Bad Request, причем исходный и конечный объекты должны сохраниться неизменными. | Опционально a |
| reference | Строка JSON | URI объекта-очереди CDMI, на который должна быть сделана переадресация. Если при создании ссылки указаны другие поля, сервер должен вернуть код ошибки 400 Bad Request. | Опционально a |
| deserializevalue | Строка JSON | Сериализованный объект-очередь (см. гл. 15), кодированный с помощью base 64 как описано в RFC 4648. | Опционально a |
| a Лишь одно из этих полей должно быть указано в любой из операций. За исключением поля value, данные поля не должны сохраняться. Если указано более чем одно из этих полей, сервер должен вернуть сообщение об ошибке 400 Bad Request. | |||
11.2.6 Заголовки ответа
Заголовки HTTP ответа на создание объекта-очереди CDMI с использованием типа содержимого CDMI указаны в таблице 83.
11.2.7 Тело сообщения-ответа
Поля тела сообщения-ответа на создание объекта-очереди CDMI с использованием типа содержимого CDMI приведены в таблице 84.
Тело сообщения-ответа - создание объекта-очереди с использованием типа содержимого CDMI
| Имя поля | Тип | Описание | Требование |
|---|---|---|---|
| objectType | Строка JSON | "application/cdmi-queue" | Обязательно |
| objectID | Строка JSON | ID объекта | Обязательно |
| objectName | Строка JSON | Имя объекта | Обязательно |
| parentURI | Строка JSON | URI родительского объекта Добавление objectName к parentURI должно всегда давать корректный URI объекта. |
Обязательно |
| parentID | Строка JSON | ID родительского объекта-контейнера | Обязательно |
| Domain URI | Строка JSON | URI домена-владельца | Обязательно |
| CapabilitiesURI | Строка JSON | URI опций объекта | Обязательно |
| completionStatus | Строка JSON | Строка, указывающая, находится ли объект в процессе создания, а после создания - был ли он создан успешно или с ошибкой. Значение должно быть строкой "Processing", "Complete" или строкой, начинающейся с "Error". | Обязательно |
| percentComplete | Строка JSON | Если значение completionStatus равно "Processing", данное поле, при наличии, должно показывать процент выполнения операции создания объекта, числовым значением от 0 до 100. Если значение completionStatus равно "Complete", данное поле, при наличии, должно иметь значение "100". Если значение completionStatus начинается с "Error", данное поле, при наличии, может содержать любое целое число от 0 до 100. |
Опционально |
| metadata | Объект JSON | Метаданные объекта-очереди. Могут включать пользовательские метаданные и метаданные системы данных, указанные в теле запроса на создание (поле metadata) вместе с метаданными системы хранения, создаваемыми облачным хранилищем. Подробнее о метаданных см. раздел 16. | Обязательно |
| queueValues | Строка JSON | Диапазон индексов элементов в очереди. Каждый элемент в очереди должен иметь уникальный монотонно возрастающий целый положительный индекс, начиная с 0. Если очередь пустая, должна возвращаться пустая строка. Если очередь не пустая, должны быть возвращены минимальный и максимальный (в таком порядке) индекс значений в очереди, разделенные дефисом ("-") | Обязательно |
11.2.8 Статус запроса
В таблице 85 приведены коды состояний HTTP, которые возникают при создании объекта-очереди с использованием типа содержимого CDMI.
11.2.9 Пример
Accept: application/cdmi-queue
Content-Type: application/cdmi-queue X-CDMI-Specification-Version: 1.0.2
Будет получен следующий ответ.
Content-Type: application/cdmi-queue X-CDMI-Specification-Version: 1.0.2
"objectID" : "00007E7F00104BE66AB53A9572F9F51E",
"parentID" : "0000706D0010B84FAD185C425D8B537E",
"domainURI" : "/cdmi_domains/MyDomain/",
"capabilitiesURI" : "/cdmi_capabilities/queue/",
"completionStatus" : "Complete",
11.3. Чтение объекта-очереди с использованием типа содержимого CDMI
11.3.1 Обзор
Для чтения всех полей существующего объекта-очереди следует выполнить запрос:
Для чтения одного или нескольких определенных полей существующего объекта-контейнера следует выполнить один из следующих запросов:
Для чтения одного или нескольких элементов существующего объекта-очереди следует выполнить запрос:
диапазон байтов значения объекта-очереди, которые должны быть возвращены в поле value. При указании диапазона байтов полученное значение должно быть возвращено из элемента в голове очереди; соответствующий префикс, возвращающий все метаданные, начинающиеся с данного префикса; число элементов, которые должны быть извлечены из очереди. Если запрашивается больше значений, чем имеется в очереди, запрос должен обрабатываться так, как будто count равно числу элементов в очереди.
К объекту возможно также обратиться как
По умолчанию, чтение из объекта-очереди должно возвращать элемент из головы очереди при условии, что диапазон queueValues не пуст.
11.3.2 Опции
Следующие опции описывают поддерживаемые операции при чтении существующего объекта-очереди:
- поддержка возможности чтения метаданных существующего объекта-очереди обозначается наличием опции cdmi_read_metadata в очереди;
- поддержка возможности чтения значения в существующем объекте-очереди обозначается наличием опции cdmi_read_value в очереди.
11.3.3 Заголовки запроса
Заголовки HTTP запроса на чтение из объекта-очереди CDMI с использованием типа содержимого CDMI приведены в таблице 86.
Заголовки запроса - чтение из объекта-очереди с использованием типа содержимого CDMI
| Заголовок | Тип | Описание | Требование |
|---|---|---|---|
| Accept | Строка заголовка | "application/cdmi-container" или совместимое значение согласно 5.13.2 | Опционально |
| X-CDMI-SpecificationVersion | Строка заголовка | Список версий, поддерживаемых клиентом, разделенных запятыми, например "1.0.2, 1.5, 2.0" | Обязательно |
11.3.4 Тело сообщения-запроса
Не следует формировать тело сообщения-запроса.
11.3.5 Заголовки ответа
Заголовки HTTP ответа на чтение из объекта-очереди CDMI с использованием типа содержимого CDMI приведены в таблице 87.
Заголовки ответа - чтение из объекта-очереди с использованием типа содержимого CDMI
11.3.6 Тело сообщения-ответа
Поля тела сообщения-ответа для чтения объекта-очереди CDMI с использованием типа содержимого CDMI приведены в таблице 88.
Тело сообщения-ответа - чтение из объекта-очереди с использованием типа содержимого CDMI
| Имя поля | Тип | Описание | Требование |
|---|---|---|---|
| objectType | Строка JSON | "application/cdmi-queue" | Обязательно |
| objectID | Строка JSON | ID объекта | Обязательно |
| objectName | Строка JSON | Имя объекта Для объектов в контейнере следует вернуть поле objectName. Для объектов не в контейнере (доступных только по ID), поле objectName не существует и не должно передаваться в ответе |
Условно |
| parentURI | Строка JSON | URI родительского объекта Для объектов в контейнере следует вернуть поле parentURI. Для объектов не в контейнере (доступных только по ID), поле parentURI не существует и не должно передаваться в ответе. Добавление objectName к parentURI должно всегда возвращать правильный URI объекта |
Условно |
| parentID | Строка JSON | ID объекта родительского контейнера Для объектов в контейнере следует вернуть поле parentID. Для объектов не в контейнере (доступных только по ID), поле parentID не существует и не должно быть возвращено |
Условно |
| domainURI | Строка JSON | URI домена-владельца | Обязательно |
| capabilitiesURI | Строка JSON | URI опций объекта | Обязательно |
| completionStatus | Строка JSON | Строка, указывающая, находится ли объект в процессе создания, а после создания - был ли он создан успешно или с ошибкой. Значение должно быть строкой "Processing", "Complete" или строкой, начинающейся с "Error" | Обязательно |
| percentComplete | Строка JSON | Если значение completionStatus равно "Processing", данное поле, при наличии, должно показывать процент выполнения операции создания объекта, числовым значением от 0 до 100. Если значение completionStatus равно "Complete", данное поле, при наличии, должно иметь значение "100". Если значение completionStatus начинается с "Error", данное поле, при наличии, может содержать любое целое число от 0 до 100 |
Опционально |
| metadata | Объект JSON | Метаданные объекта-очереди. Могут включать пользовательские метаданные и метаданные системы данных, указанные в теле запроса на создание (поле metadata) вместе с метаданными системы хранения, создаваемыми облачным хранилищем. Подробнее о метаданных см. разделе 16 | Обязательно |
| queueValues | Строка JSON | Диапазон индексов элементов в очереди. Каждый элемент в очереди должен иметь уникальный монотонно возрастающий целый положительный индекс, начиная с 0. Если очередь пустая, должна возвращаться пустая строка. Если очередь не пустая, должны быть возвращены минимальный и максимальный (в таком порядке) индекс значений в очереди, разделенные дефисом ("-") | Обязательно |
| mimetype | Массив JSON строк JSON | Типы MIME для каждого из элементов очереди Возвращаются типы MIME элементов, каждый на соответствующей позиции массива JSON. Это поле должно возвращаться только если completionStatus равно "Complete" и в очереди находятся одно или несколько значений |
Опционально |
| valuerange | Массив JSON строк JSON | Диапазон байт элементов объекта-очереди, которые должен быть возвращены в поле value Возвращаются диапазоны значений элементов, каждый на соответствующей позиции в массиве JSON. При запросе определенного диапазона, запись в поле диапазона значений должна соответствовать запрошенным байтам Если запрос выходит за пределы значения, поле valuerange должно указывать на возвращенный меньший диапазон. Это поле должно возвращаться только если completionStatus равно "Complete", и в очереди находятся один или несколько значений |
Опционально |
| valuetransferencoding | Массив JSON строк JSON | Кодировки, использованные для отдельных объектов в очереди. Определены два значения кодировки. - "utf-8" указывает на то, что объект данных содержит корректную строку UTF-8, и должен передаваться как строка UTF-8 в поле value. - "base64" указывает на то, что объект данных содержит произвольную бинарную последовательность и должен передаваться как строка поля значения в кодировке base 64 Возвращаются кодировки каждое на соответствующей позиции в массиве JSON. Это поле должно возвращаться только если completionStatus равно "Complete" |
Опционально |
| value | Массив JSON строк JSON | Значения объектов в голове очереди Значения возвращаются в массиве JSON в порядке от старых к новым. Если поле valuetransferencoding указывает на кодировку UTF-8, значение должно быть строкой UTF-8, сформированной по правилам JSON как описано в RFC 4627. Если поле valuetransferencoding указывает на кодировку base 64, значение должно быть вначале кодировано в base 64 по правилам, описанным в RFC 4648. Это поле должно возвращаться только если completionStatus равно "Complete" |
Условно |
Если в запросе GET указаны отдельные поля, в теле ответа должны возвращаться только эти поля.
Опциональные запрошенные, но несуществующие поля опускаются в теле ответа.
11.3.7 Статус запроса
В таблице 89 приведены коды состояний HTTP, возникающих при чтении из объекта-очереди с использованием типа содержимого CDMI.
Коды состояний HTTP - чтение из объекта-очереди с использованием типа содержимого CDMI
11.3.8 Примеры
1 Применение GET к URI объекта-очереди для чтения всех полей объекта-очереди:
GET /MyContainer/MyQueue HTTP/1.1
Будет получен следующий ответ.
Content-Type: application/cdmi-queue
"objectID": "00007E7F00104BE66AB53A9572F9F51E",
"domainURI" : "/cdmi_domains/MyDomain/",
"completionStatus": "Complete",
2 Применение GET к URI объекта-очереди для чтения полей value и queueValues объекта-очереди:
X-CDMI-Specification-Version: 1.0.2
X-CDMI-Specification-Version: 1.0.2
3 Применение GET к URI объекта-очереди для чтения первых пяти байт значения объекта-очереди:
Будет получен следующий ответ:
Content-Type: application/cdmi-queue
4 Применение GET к URI объекта-очереди для чтения двух значений объекта-очереди:
X-CDMI-Specification-Version: 1.0.2
Content-Type: application/cdmi-queue
11.4. Изменение объекта-очереди с использованием типа содержимого CDMI
11.4.1 Обзор
Для изменения некоторых или всех полей существующего объекта-очереди (за исключением постановки в очередь) следует выполнить запрос:
Для добавления, обновления или удаления определенных элементов метаданных существующего объекта-очереди следует выполнить запрос:
Объект-очередь также доступен как
11.4.2 Опции
Следующие опции описывают поддерживаемые операции при изменении существующего объекта-очереди:
- поддержка возможности изменения метаданных существующего объекта-очереди обозначается наличием опции cdmi_modify_metadata в очереди.
11.4.3 Заголовки запроса
Заголовки запроса HTTP для изменения объекта-очереди CDMI с использованием типа содержимого CDMI перечислены в таблице 90.
11.4.4 Тело сообщения-запроса
Поля тела запроса на изменение объекта-очереди с использованием типа содержимого CDMI перечислены в таблице 91.
Тело сообщения-запроса - изменение объекта-очереди с использованием типа содержимого CDMI
| Имя поля | Тип | Описание | Требование |
| metadata | Объект JSON | Метаданные для объекта-очереди. Если присутствуют, указанные метаданные замещают существующие метаданные объекта. Если URI указывает на отдельные элементы метаданных, остальные элементы не должны меняться. Подробнее о метаданных см. раздел 16. | Опционально |
| domainURI | Строка JSON | URI домена-владельца - В случае отличия от родительского домена, пользователь должен обладать правами cross_domain (см. cdmi_member_privileges в табл. 64). - Если не указано, должен использоваться родительский домен. | Опционально |
| Deserialize | Строка JSON | URI сериализованного объекта-очереди CDMI, который должен быть десериализован для изменения существующего объекта-очереди. ID сериализованного объекта-очереди должен совпадать с ID объекта-назначения. Все элементы сериализованной очереди должны быть добавлены в изменяемую очередь. | Опционально a |
| copy | Строка JSON | URI объекта-очереди CDMI, который должен быть скопирован в имеющийся объект-очередь. Элементы очереди не копируются. Копирование элементов в очереди см. 11.6. | Опционально a |
| deserializevalue | Строка JSON | Сериализованный объект-очередь (см. раздел 15), кодированный с помощью base 64 как описано в RFC 4648. ID сериализованного объекта-очереди должно соответствовать ID очереди-цели. Все элементы сериализованной очереди должны быть добавлены в изменяемую очередь. | Опционально a |
| a Лишь одно из этих полей должно быть указано в любой из операций. За исключением поля value, данные поля не должны сохраняться. | |||
11.4.5 Заголовок ответа
Заголовок ответа HTTP на изменение объекта-очереди CDMI с использованием типа содержимого CDMI приведен в таблице 92.
Заголовок ответа - изменение объекта-очереди
с использованием типа содержимого CDMI
| Заголовок | Тип | Описание | Требование |
|---|---|---|---|
| Location | Строка заголовка | Сервер должен вернуть URI, на который происходит переадресация, если объект является ссылкой. | Условно |
11.4.6 Тело сообщения-ответа
Сообщение-ответ может содержать тело, соответствующее RFC 2616.
11.4.7 Статус запроса
В таблице 93 приведены коды состояний HTTP, которые возникают при изменении объекта-очереди с использованием типа содержимого CDMI.
11.4.8 Пример
Пример - Применение PUT к URI объекта-очереди для установки новых метаданных:
Будет получен следующий ответ.
11.5. Удаление объекта-очереди с использованием типа содержимого CDMI
11.5.1 Обзор
Для удаления существующего объекта-очереди, включая все элементы очереди, следует выполнить запрос:
К объекту можно также обратиться как
11.5.2 Опции
Следующие опции описывают поддерживаемые операции при удалении существующего объекта-очереди:
- поддержка возможности удаления существующего объекта-очереди обозначается наличием опции cdmi_delete_queue в очереди.
11.5.3 Заголовок запроса
Заголовок запроса HTTP для удаления объекта-очереди CDMI с использованием типа содержимого CDMI показан в таблице 94.
Заголовок запроса - удаление объекта-очереди
с использованием типа содержимого CDMI
| Заголовок | Тип | Описание | Требование |
|---|---|---|---|
| X-CDMI-SpecificationVersion | Строка заголовка | Список версий, поддерживаемых клиентом, разделенных запятыми, например "1.0.2, 1.5, 2.0" | Обязательно |
11.5.4 Тело сообщения-запроса
11.5.5 Заголовки ответа
11.5.6 Тело сообщения-ответа
Сообщение-ответ может содержать тело, соответствующее RFC 2616.
11.5.7 Статус запроса
В таблице 95 приведены коды состояний HTTP, возникающих при удалении объекта очереди с использованием типа содержимого CDMI.
Коды состояний HTTP - удаление объекта-очереди
с использованием типа содержимого CDMI
11.5.8 Пример
DELETE /MyContainer/MyQueue HTTP/1.1
X-CDMI-Specification-Version: 1.0.2
Будет получен следующий ответ.
11.6. Добавление элемента в очередь с использованием типа содержимого CDMI
11.6.1 Обзор
неотрицательное число существующих промежуточных контейнеров, имена которых разделены одинарной наклонной чертой ("/");
К объекту можно также адресоваться как
11.6.2 Опции
Следующие опции описывают поддерживаемые операции при добавлении нового элемента в существующую очередь:
- поддержка возможности изменения значения в существующем объекте-очереди обозначается наличием опции cdmi_modify_value в очереди.
11.6.3 Заголовки запроса
Заголовки HTTP запросов на добавление элементов в объект-очередь CDMI с использованием типа содержимого CDMI приведены в таблице 96.
Заголовки запроса - добавление нового элемента в очередь
с использованием типа содержимого CDMI
11.6.4 Тело сообщения-запроса
Поля тела сообщения-запроса добавление элементов в объект-очередь CDMI с использованием типа содержимого CDMI приведены в таблице 97.
Тело сообщения-запроса - добавление элементов в очередь
с использованием типа содержимого CDMI (лист 1 из 2)
| Имя поля | Тип | Описание | Требование |
| mimetype | Массив JSON строк JSON | Тип(ы) MIME для элементов, добавляемых в очередь. Данное поле должно храниться как часть объекта. Если это поле не указано, ему должно быть присвоено значение "text/plain". Должны быть представлены столько же элементов массива, сколько имеется элементов в поле value, причем типы должны соответствовать элементам на соответствующих позициях. Значение этого поля должно быть перед сохранением преобразовано в нижний регистр. | Опционально |
| copy | Строка JSON | URI обьекта-очереди или данных CDMI, который необходимо добавить в объект-очередь Если приведен URI объекта данных, то поля value, mimetype и valuetransferencoding объекта данных используются для создания нового элемента очереди, а объект данных атомарно уничтожается. Если задан URI объекта-очереди, то поля value, mimetype и valuetransferencoding указанного количества добавляемых элементов переносятся в очередь-назначение и атомарно удаляются из очереди-источника. | Опционально a |
| move | Строка JSON | URI объекта данных или очереди CDMI, из которых необходимо взять элементы для постановки в очередь. Исходные элементы удаляются после успешного добавления в очередь | Опционально a |
| valuetransferencoding | Массив JSON строк JSON | Кодировка(и), использованная(ые) при передаче элемента(ов) объекта-очереди. Определены два значения кодировки. - "utf-8" указывает на то, что объект данных содержит корректную строку UTF-8, и должен передаваться как строка UTF-8 в поле value. - "base64" указывает на то, что объект данных содержит произвольную бинарную последовательность и должен передаваться как строка поля значения в кодировке base 64. Попытка установить значение элемента иное, чем корректная строка в кодировке base 64, должно приводить к ошибке 400 Bad Request. Если значение поля не указано, оно должно быть установлено в "utf-8". Данное поле должно храниться как часть объекта. | Опционально |
| value | Массив JSON строк JSON | Элемент(ы) для добавления в очередь. Если соответствующее поле valuetransferencoding указывает на кодировку UTF-8, значение должно быть строкой UTF8 согласно правилам JSON, описанным в RFC 4627. Если соответствующее поле valuetransferencoding указывает на кодировку base 64 encoding, значение должно быть вначале перекодировано в base 64 как описано в RFC 4648. | Опционально a |
| a Лишь одно из этих полей должно быть указано в любой из операций. За исключением поля value, данные поля не должны сохраняться. Если указано более чем одно из этих полей, сервер должен вернуть сообщение об ошибке 400 Bad Request. | |||
11.6.5 Заголовки ответа
Сообщение-ответ может содержать заголовки, соответствующие RFC 2616.
11.6.6 Тело сообщения-ответа
Сообщение-ответ может содержать тело, соответствующее RFC 2616.
11.6.7 Статус запроса
В таблице 98 приведены коды состояний HTTP, которые могут возникнуть при добавлении элементов в очередь с использованием типа содержимого CDMI.
11.6.8 Примеры
1 Применение POST к URI объекта-очереди для добавления нового элемента:
POST /MyContainer/MyQueue HTTP/1.1
Content-Type: application/cdmi-queue X-CDMI-Specification-Version: 1.0.2
2 Применение POST к URI объекта-очереди для копирования существующего элемента:
POST /MyContainer/MyQueue HTTP/1.1
Content-Type: application/cdmi-object
X-CDMI-Specification-Version: 1.0.2
"copy" : "/MyContainer/MyDataObject"
3 Применение POST к URI объекта-очереди для переноса 20 значений из другого объекта-очереди:
Content-Type: application/cdmi-object
"move" : "/MyContainer/FirstQueue?values:20"
4 Применение POST к URI объекта-очереди для добавления двух новых элементов:
Content-Type: application/cdmi-object
Будет получен следующий ответ.
5 Применение POST к URI объекта-очереди для добавления двух новых значений, одного в кодировке base 64 и другого в кодировке utf-8:
Будет получен следующий ответ.
11.7. Удаление значения объекта-очереди с использованием типа содержимого CDMI
11.7.1 Обзор
Для удаления одного или нескольких элементов из головы очереди следует выполнить запрос:
путь к облаку CDMI; неотрицательное число промежуточных контейнеров; имя очереди, из которой удаляются элементы; число элементов, начиная с головы очереди, которые следует удалить из объекта-очереди. Если запрошено удаление большего количества элементов, чем есть в очереди, данное значение должно быть установлено равным количеству элементов в объекте-очереди.
К объекту можно также обратиться как
Суффикс "?value" на конце URI объекта-очереди должен быть добавлен, чтобы различать удаление элементов очереди от удаления объекта очереди (см. 11.5).
11.7.2 Опции
Следующие опции описывают поддерживаемые операции при удалении существующего значения объекта из очереди:
- поддержка возможности удаления значения из существующего объекта-очереди обозначается наличием опции cdmi_modify_value в очереди.
11.7.3 Заголовок запроса
Заголовок HTTP запросов на удаление элементов из объекта-очереди CDMI с использованием типа содержимого CDMI приведен в таблице 99.
Заголовок запроса - удаление элемента из объекта-очереди с использованием типа содержимого CDMI
| Заголовок | Тип | Описание | Требование |
|---|---|---|---|
| X-CDMI-SpecificationVersion | Строка заголовка | Список версий, поддерживаемых клиентом, разделенных запятыми, например "1.0.2, 1.5, 2.0" | Обязательно |
11.7.4 Тело сообщения-запроса
Сообщение-запрос может содержать тело, соответствующее RFC 2616.
11.7.5 Заголовки ответа
Сообщение-ответ может содержать заголовки, соответствующие RFC 2616.
11.7.6 Тело сообщения-ответа
Сообщение-ответ может содержать тело, соответствующее RFC 2616.
11.7.7 Статус запроса
В таблице 100 приведены коды состояний HTTP, которые могут возникнуть при удалении элементов из объекта-очереди с использованием типа содержимого CDMI.
Коды состояний HTTP - удаление элемента из объекта-очереди с использованием типа содержимого CDMI
11.7.8 Пример
Пример - Применение DELETE к URI объекта-очереди: удаление элемента для доступа к следующему элементу:
DELETE /MyContainer/MyQueue?value HTTP/1.1
X-CDMI-Specification-Version: 1.0.2
Будет получен следующий ответ.
12. Операции с ресурсами объекта-опции
12.1. Обзор
Объекты-опции позволяют клиенту CDMITM определять, какое подмножество настоящего стандарта реализуется провайдером CDMI.
Для каждого URI в системе облачного хранения набор взаимодействий, которые возможно осуществить для данного URI, описывается наличием именованных "опций". Каждая опция, присутствующая для данного URI показывает, какие функции предоставляет система по отношению к данному URI. Опции всегда статически заданы.
Опции могут отличаться от операций, допустимых согласно списку контроля доступа (Access Control List, ACL) (см. 16.1), соответствующего данному URI. Например, облако, реализующее только чтение, может не допускать доступ для записи к контейнеру или объекту, несмотря на разрешение данных операция в ACL.
Облачные клиенты могут использовать опции для определения, какие операции поддерживаются. Если по отношению к объекту CDMI запрашивается выполнение операции, для которой отсутствует соответствующая опция, должен быть возвращен код HTTP 400. Все CDMI-совместимые системы облачного хранения должны реализовывать чтение опций, но поддержка функциональности, обозначаемой этими опциями, не обязательна.
Каждый объект данных, контейнер, домен и очередь системы CDMI должны иметь поле capabilitiesURI, которое содержит корректный URI объекта-опции. В пределах объекта-опции имя каждой опции имеет определенное значение, согласованно понимаемое провайдером облачного хранения и потребителем услуги.
Опции, определенные в рамках настоящего стандарта, описаны начиная с 12.1.1. Опции, определенные поставщиком услуг, не описаны в данном стандарте; их имена не должны начинаться с "cdmi_".
Рисунок 7 показывает иерархию опций реализации и то, как capabilitiesURI связывают объекты данных и контейнеры в дерево опций.
Контейнер опций в дереве опций, с которым связан объект, определяется типом объекта и полей метаданных системы данных, присутствующих в данном объекте.
Пример - Опции контейнера без полей метаданных системы данных определяются набором опций "container".
Реализация CDMI может опционально связывать контейнер с набором опций "gold_container", если присутствует поле метаданных системы данных, и если оно установлено в определенное значение, например, если поле cdmi_data_redundancy равно "4". Это позволяет облачному провайдеру создавать профили полей метаданных системы данных и их значений.
Опции не имеют поля метаданных CDMI.
12.1.1 Общесистемные опции облачного хранения
В таблице 101 приведены общесистемные опции облачного хранилища. Эти опции содержатся в объекте опций, доступном через корневой URI (корневые опции).
| Имя опции | Тип | Определение |
|---|---|---|
| cdmi_domains | Строка JSON | Если существует и равна "true", означает, что облачная система хранения поддерживает домены. Если отсутствует, поле domainURI не должно присутствовать в теле сообщений-ответов; не должно быть URI cdmi_domains. |
| cdmi_export_cifs | Строка JSON | Если существует и равна "true", данная опция означает, что облачная система хранения поддерживает экспорты CIFS. |
| cdmi_dataobjects | Строка JSON | Если существует и равна "true", данная опция означает, что облачная система хранения поддерживает объекты данных. |
| cdmi_export_iscsi | Строка JSON | Если существует и равна "true", данная опция означает, что облачная система хранения поддерживает экспорты iSCSI. |
| cdmi_export_nfs | Строка JSON | Если существует и равна "true", данная опция означает, что облачная система хранения поддерживает экспорты по протоколу NFS. |
| cdmi_export_occi_iscsi | Строка JSON | Если существует и равна "true", данная опция означает, что облачная система хранения поддерживает экспорты OCCI/iSCSI. |
| cdmi_export_webdav | Строка JSON | Если существует и равна "true", данная опция означает, что облачная система хранения поддерживает экспорты WebDAV. |
| cdmi_metadata_maxitems | Строка JSON | Если присутствует, данная опция указывает максимальное количество определенных пользователем элементов метаданных. Если отсутствует, ограничений на количество элементов пользовательских метаданных нет. |
| cdmi_metadata_maxsize | Строка JSON | Если присутствует, данная опция указывает максимальный размер (в байтах) каждого элемента пользовательских метаданных на один объект. Если отсутствует, таких ограничений нет. |
| cdmi_metadata_maxtotalsize | Строка JSON | Если присутствует, данная опция указывает максимальный размер (в байтах) определенных пользователем метаданных, поддерживаемых облачной системой хранения. Если отсутствует, таких ограничений нет. |
| cdmi_notification | Строка JSON | Если существует и равна "true", данная опция означает, что облачная система хранения поддерживает очереди уведомлений. |
| cdmi_logging | Строка JSON | Если существует и равна "true", данная опция означает, что облачная система хранения поддерживает очереди журналов событий. |
| cdmi_query | Строка JSON | Если существует и равна "true", данная опция означает, что облачная система хранения поддерживает очереди запросов. |
| cdmi_query_regex | Строка JSON | Если существует и равна "true", данная опция означает, что облачная система хранения поддерживает запросы с регулярными выражениями. |
| cdmi_query_contains | Строка JSON | Если существует и равна "true", данная опция означает, что облачная система хранения поддерживает запросы с выражениями "contains". |
| cdmi_query_tags | Строка JSON | Если существует и равна "true", данная опция означает, что облачная система хранения поддерживает запросы с выражениями проверки на соответствие метке. |
| cdmi_query_value | Строка JSON | Если существует и равна "true", данная опция означает, что облачная система хранения поддерживает запросы поля значения. |
| cdmi_queues | Строка JSON | Если существует и равна "true", данная опция означает, что облачная система хранения поддерживает объекты-очереди. |
| cdmi_security_access_control | Строка JSON | Если существует и равна "true", данная опция означает, что облачная система хранения поддерживает ACL. Подробнее см. 12.1.3. |
| cdmi_security_audit | Строка JSON | Если существует и равна "true", данная опция означает, что облачная система хранения поддерживает журнал событий безопасности. Подробнее см. 20.3. |
| cdmi_security_data_integrity | Строка JSON | Если существует и равна "true", данная опция означает, что облачная система хранения поддерживает проверки целостности/подлинности данных. Подробнее см. 12.1.3. |
| cdmi_security_encryption | Строка JSON | Если существует и равна "true", данная опция означает, что облачная система хранения поддерживает фоновое шифрование данных. Подробнее см. 12.1.3. |
| cdmi_security_immutability | Строка JSON | Если существует и равна "true", данная опция означает, что облачная система хранения поддерживает неизменяемые данные и удержание данных. Подробнее см. 12.1.3. |
| cdmi_security_sanitization | Строка JSON | Если существует и равна "true", данная опция означает, что облачная система хранения поддерживает очистку данных/носителя. Подробнее см. 12.1.3. |
| cdmi_serialization_json | Строка JSON | Если существует и равна "true", данная опция означает, что облачная система хранения поддерживает JSON как формат сериализации. |
| cdmi_snapshots | Строка JSON | Если существует и равна "true", данная опция означает, что облачная система хранения поддерживает снимки состояния. |
| cdmi_references | Строка JSON | Если существует и равна "true", опция означает, что облачная система хранения поддерживает ссылки. |
| cdmi_object_move_from_local | Строка JSON | Если существует и равна "true", данная опция означает, что облачная система хранения поддерживает перемещение CDMI объектов в пределах той же системы хранения. |
| cdmi_object_move_from_remote | Строка JSON | Если существует и равна "true", данная опция означает, что облачная система хранения поддерживает перемещение CDMI объектов из других систем хранения CDMI. |
| cdmi_object_move_from_ID | Строка JSON | Если существует и равна "true", данная опция означает, что облачная система хранения поддерживает перемещение CDMI объектов без указания пути, по URI из /cdmi_оbjеctid/ в пределах той же системы хранения. Это добавляет путь, позволяя доступ к объекту и по ID, и по пути. |
| cdmi_object_move_to_ID | Строка JSON | Если существует и равна "true", данная опция означает, что облачная система хранения поддерживает перемещение CDMI объектов, для которых задан путь, в URI из /cdmi_objectid/ в пределах той же системы хранения. Это удаляет путь, позволяя обращаться к объекту лишь по ID. |
| cdmi_object_copy_from_local | Строка JSON | Если существует и равна "true", данная опция означает, что облачная система хранения поддерживает копирование CDMI объектов в пределах той же системы хранения. |
| cdmi_object_copy_from_remote | Строка JSON | Если существует и равна "true", данная опция означает, что облачная система хранения поддерживает копирование CDMI объектов из других систем хранения CDMI. |
| cdmi_object_access_by_ID | Строка JSON | Если существует и равна "true", данная опция означает, что объекты могут быть доступны для чтения, изменения и удаления через "/cdmi_objectid/". |
| cdmi_post_dataobject_by_ID | Строка JSON | Если существует и равна "true", данная опция означает, что система позволяет добавлять новый объект данных по ID посредством POST в "/cdmi_objectid/". |
| cdmi_post_queue_by_ID | Строка JSON | Если существует и равна "true", данная опция означает, что система позволяет добавлять новый объект-очередь по ID посредством POST в "/cdmi_objectid/". |
| cdmi_deserialize_dataobject_by_ID | Строка JSON | Если существует и равна "true", данная опция означает, что система позволяет десериализацию сериализованных данных при создании нового объекта данных по ID посредством POST в "/cdmi_objectid/". |
| cdmi_deserialize_queue_by_ID | Строка JSON | Если существует и равна "true", данная опция означает, что система позволяет десериализацию сериализованной очереди при создании нового объекта-очереди по ID посредством POST в "/cdmi_objectid/". |
| cdmi_serialize_dataobject_to_ID | Строка JSON | Если существует и равна "true", данная опция означает, что система позволяет сериализовать объекты данных при создании нового объекта данных по ID посредством POST в "/cdmi_objectid/". |
| cdmi_serialize_domain_to_ID | Строка JSON | Если существует и равна "true", данная опция означает, что система позволяет сериализовать объекты-домены при создании нового объекта данных по ID посредством POST в "/cdmi_objectid/". |
| cdmi_serialize_container_to_ID | Строка JSON | Если существует и равна "true", данная опция означает, что система позволяет the сериализовать объекты-контейнеры при создании нового объекта данных по ID посредством POST в "/cdmi_objectid/". |
| cdmi_serialize_queue_to_ID | Строка JSON | Если существует и равна "true", данная опция означает, что система позволяет сериализовать объекты-очереди при создании нового объекта данных по ID посредством POST в "/cdmi_objectid/". |
| cdmi_copy_dataobject_by_ID | Строка JSON | Если существует и равна "true", данная опция означает, что система позволяет копировать существующий объект данных при создании нового объекта данных по ID посредством POST в "/cdmi_objectid/". |
| cdmi_copy_queue_by_ID | Строка JSON | Если существует и равна "true", данная опция означает, что система позволяет копировать существующий объект-очередь при создании нового объекта-очереди по ID посредством POST в "/cdmi_objectid/". |
| cdmi_create_reference_by_ID | Строка JSON | Если существует и равна "true", данная опция означает, что система позволяет создавать новую ссылку по ID: ссылка-потомок может быть создана посредством POST в "/cdmi_objectid/". |
12.1.2 Опции метаданных системы хранения
В таблице 102 приведены опции метаданных системы хранения в облачном хранилище. Эти опции могут быть найдены среди опций для объектов-доменов, объектов-контейнеров, объектов-очередей. Подробное описание элементов метаданных системы хранения см. в 16.3.
Опции метаданных системы хранения
| Имя опции | Тип | Определение |
| cdmi_acl Строка JSON | ||
| Если существует и равна "true", данная опция означает, что облачная система хранения поддерживает ACL. Если реализация CDMI поддерживает ACL для управления доступом, общесистемная опция cdmi_security_access_control (см. таблицу 102 гл. 12.1.1) должна быть установлена в "true". В противном случае данная должна отсутствовать, что обозначает отсутствие поддержки управления доступом. | cdmi_size | Строка JSON |
| Если существует и равна "true", данная опция означает, что облачная система хранения должна создавать метаданные cdmi_size для каждого хранимого объекта. | cdmi_ctime | Строка JSON |
| Если существует и равна "true", данная опция означает, что облачная система хранения должна создавать метаданные cdmi_ctime для каждого хранимого объекта. | cdmi_atime | Строка JSON |
| Если существует и равна "true", данная опция означает, что облачная система хранения должна создавать метаданные cdmi_atime для каждого хранимого объекта. | cdmi_mtime | Строка JSON |
| Если существует и равна "true", данная опция означает, что облачная система хранения должна создавать метаданные cdmi_mtime для каждого хранимого объекта. | cdmi_acount | Строка JSON |
| Если существует и равна "true", данная опция означает, что облачная система хранения должна создавать метаданные cdmi_acount для каждого хранимого объекта. | cdmi_mcount | Строка JSON |
| Если существует и равна "true", данная опция означает, что облачная система хранения должна создавать метаданные cdmi_mcount для каждого хранимого объекта. | 12.1.3 Опции метаданных системы данных | |
Таблица 103 определяет опции, указывающие, какие элементы метаданных системы данных поддерживаются для объектов в облачном хранилище. Эти опции касаются объектов-доменов, объектов данных, объектов-контейнеров и объектов-очередей. Описание элементов метаданных системы данных см. в 16.4 (таблица 117).
Опции метаданных системы данных
| Имя опции | Тип | Определение |
|---|---|---|
| cdmi_assignedsize | Строка JSON | Если облачная система хранения поддерживает метаданные системы данных cdmi_assignedsize (см. 16.4), должна присутствовать опция cdmi_assignedsize, установленная в строковое значение "true". Если эта опция отсутствует или присутствует, но установлена в "false", метаданные системы данных cdmi_assignedsize не должны использоваться. |
| cdmi_data_redundancy | Строка JSON | Если облачная система хранения поддерживает метаданные систем данных cdmi_data_redundancy (см. 16.4), опция cdmi_data_redundancy должна присутствовать и быть установлена в положительное числовое значение, отражающее максимальное значение, поддерживаемое сервером. Если эта опция отсутствует или присутствует, но равна пустой строке "", метаданные системы данных cdmi_data_redundancy не должны использоваться. |
| cdmi_data_dispersion | Строка JSON | Если облачная система хранения поддерживает метаданные систем данных cdmi_data_dispersion (см. 16.4), должна присутствовать опция cdmi_data_dispersion, установленная в "true". Если эта опция отсутствует или присутствует, но установлена в "false", метаданные системы данных cdmi_data_dispersion не должны использоваться. |
| cdmi_data_retention | Строка JSON | Если облачная система хранения поддерживает метаданные систем данных cdmi_retention_id и cdmi_retention_period (см. 16.4), опция cdmi_data_retention должна присутствовать и быть установлена в "true". Если эта опция отсутствует или присутствует, но установлена в "false", метаданные системы данных cdmi_retention_id и cdmi_retention_period не должны использоваться. |
| cdmi_data_autodelete | Строка JSON | Если облачная система хранения поддерживает метаданные систем данных cdmi_data_autodelete (см. 16.4), опция cdmi_data_autodelete должна присутствовать и быть установлена в "true". Если эта опция отсутствует или присутствует, но установлена в "false", метаданные системы данных cdmi_data_autodelete не должны использоваться. |
| cdmi_data_holds | Строка JSON | Если облачная система хранения поддерживает метаданные систем данных cdmi_hold_id (см. 16.4), опция cdmi_data_holds должна присутствовать и быть установлена в "true". Если эта опция отсутствует или присутствует, но установлена в "false", метаданные системы данных, cdmi_data_holds не должны использоваться. Если а облачная система хранения поддерживает удержание для обеспечения неизменяемости данных, общесистемная опция cdmi_security_immutability (см. таблицу 101 в 12.1.1) должна присутствовать и быть установлена в "true". |
| cdmi_encryption | Массив JSON | Если облачная система хранения поддерживает метаданные систем данных cdmi_encryption (см. 16.4), опция cdmi_encryption должна присутствовать и быть установлена в одно из значений, описанных в метаданных системы данных cdmi_encryption (см. 16.4). Если эта опция отсутствует или присутствует, но установлена равной пустому массиву JSON, метаданные системы данных cdmi_encryption не должны использоваться. Если облачная система хранения поддерживает фоновое шифрование, системная опция cdmi_security_encryption (см. таблицу 101 в 12.1.1) должна присутствовать и быть установлена в "true". |
| cdmi_geographic_placement | Строка JSON | Если облачная система хранения поддерживает метаданные систем данных cdmi_geographic_placement (см. 16.4), опция cdmi_geographic_placement должна присутствовать и быть установлена в "true". Если эта опция отсутствует или присутствует, но установлена в "false", метаданные системы данных cdmi_geographic_placement не должны использоваться. |
| cdmi_immediate_redundancy | Строка JSON | Если облачная система хранения поддерживает метаданные систем данных cdmi_immediate_redundancy (см. 16.4), опция cdmi_immediate_redundancy должна присутствовать и быть установлена в положительную числовую строку, отражающую максимальное значение, поддерживаемое сервером. Если эта опция отсутствует или присутствует, но установлена в "", метаданные системы данных cdmi_immediate_redundancy не должны использоваться. |
| cdmi_infrastructure_redundancy | Строка JSON | Если облачная система хранения поддерживает метаданные систем данных cdmi_infrastructure_redundancy (см. 16.4), опция cdmi_infrastructure_redundancy должна присутствовать и быть установлена в положительное числовое значение, отражающее максимальное значение, поддерживаемое сервером. Если эта опция отсутствует или присутствует, но равна пустой строке "", метаданные системы данных cdmi_infrastructure_redundancy не должны использоваться. |
| cdmi_latency | Строка JSON | Если облачная система хранения поддерживает метаданные систем данных cdmi_latency (см. 16.4), опция cdmi_latency должна присутствовать и быть установлена в "true". Если эта опция отсутствует или присутствует, но установлена в "false", метаданные системы данных cdmi_latency не должны использоваться. |
| cdmi_RPO | Строка JSON | Если облачная система хранения поддерживает метаданные систем данных cdmi_RPO (см. 16.4), опция cdmi_RPO должна присутствовать и быть установлена в "true". Если эта опция отсутствует или присутствует, но установлена в "false", метаданные системы данных cdmi_RPO не должны использоваться. |
| cdmi_RTO | Строка JSON | Если облачная система хранения поддерживает метаданные систем данных cdmi_RTO (см. 16.4), опция cdmi_RTO должна присутствовать и быть установлена в "true". Если эта опция отсутствует или присутствует, но установлена в "false", метаданные системы данных cdmi_RTO не должны использоваться. |
| cdmi_sanitization_method | Массив JSON | Если облачная система хранения поддерживает метаданные систем данных cdmi_sanitization_method (см. 16.4), опция cdmi_sanitization_method должна присутствовать и быть установлена в одно из значений, описанных в метаданных системы данных cdmi_sanitization_method (см. 16.4). Если эта опция отсутствует или присутствует, но установлена равной пустому массиву JSON, метаданные системы данных cdmi_sanitization_method не должны использоваться. Если облачная система хранения поддерживает очистку данных, общесистемная опция cdmi_security_sanitization (см. таблицу 101 в 12.1.1) должна присутствовать и быть установлена в "true". |
| cdmi_throughput | Строка JSON | Если облачная система хранения поддерживает метаданные систем данных cdmi_throughput (см. 16.4), опция cdmi_throughput capability должна присутствовать и быть установлена в "true". Если эта опция отсутствует или присутствует, но установлена в "false", метаданные систем данных cdmi_throughput не должны использоваться. |
| cdmi_value_hash | Массив JSON | Если облачная система хранения поддерживает метаданные систем данных cdmi_value_hash (см. 16.4), опция cdmi_value_hash должна присутствовать и быть установлена в одно из значений, описанных в метаданных системы данных cdmi_value_hash (см. 16.4). Если эта опция отсутствует или присутствует, но установлена равной пустому массиву JSON, метаданные системы данных cdmi_value_hash не должны использоваться. Если облачная система хранения поддерживает хеширование значений, общесистемная опция cdmi_security_data_integrity (см. таблицу 101 в 12.1.1) должна присутствовать и быть установлена в "true". |
12.1.4 Опции объекта данных
В таблице 104 приведены опции объекта данных в системе облачного хранения.
12.1.5 Опции контейнеров
В таблице 105 приведены опции объекта-контейнера в системе облачного хранения.
12.1.6 Опции объекта-домена
В таблице 106 приведены опции объекта-домена в системе облачного хранения. (Все опции определяют действия, выполняемые посредством операций с типом содержимого CDMI).
12.1.7 Опции объекта-очереди
В таблице 107 приведены опции объекта-очереди в системе облачного хранения.
12.1.8 Представления опций объектов
Представления в данном разделе показаны с использованием нотации JSON. И клиенты, и серверы должны поддерживать UTF-8 представление JSON. В телах сообщений-запросов и ответов поля JSON могут указываться и возвращаться в любом порядке за исключением (при наличии) полей childrenrange и children, которые указываются последними и в данном порядке.
12.2. Чтение опций объекта с использованием типа содержимого CDMI
12.2.1 Обзор
Для чтения всех полей существующего объекта-опции следует выполнить запрос:
Для чтения одного или нескольких выбранных полей существующего объекта-опции следует выполнить один из запросов:
GET
путь к облаку CDMI; неотрицательное количество промежуточных контейнеров опций; имя объекта для чтения; имя поля; числовой диапазон в списке потомков.
Объект также должен быть доступен как
12.2.2 Опции
Следующие опции описывают поддерживаемые операции при чтении существующего объекта-опции:
12.2.3 Заголовки запроса
Заголовки HTTP запроса на чтение объекта-опции CDMI с использованием типа содержимого CDMI приведены в таблице 108.
Заголовки запроса - чтение объекта-опции с использованием типа содержимого CDMI
| Заголовок | Тип | Описание | Требование |
|---|---|---|---|
| Accept | Строка заголовка | "application/cdmi-container" или совместимое значение согласно 5.13.2 | Опционально |
| X-CDMI-SpecificationVersion | String Array | Список версий, поддерживаемых клиентом, разделенных запятыми, например "1.0.2, 1.5, 2.0" | Обязательно |
12.2.4 Тело сообщения-запроса
Тело в сообщении-запросе должно отсутствовать.
12.2.5 Заголовки ответа
Заголовки HTTP ответа для чтения объекта-опции CDMI с использованием типа содержимого CDMI приведены в таблице 109.
Заголовки ответа - чтение объекта-опции с использованием типа содержимого CDMI
12.2.6 Тело сообщения-ответа
Поля тела сообщения-ответа для чтения объекта-опции CDMI с использованием типа содержимого CDMI приведены в таблице 110.
Тело сообщения-ответа - чтение объекта-опции с использованием типа содержимого CDMI
Если в запросе GET указаны отдельные поля, в ответе следует возвращать только эти поля.
Опциональные запрошенные поля, отсутствующие в объекте, опускаются в ответе.
12.2.7 Статус запроса
В таблице 111 приведены коды состояний HTTP, возникающие при чтении объектов-опций с использованием типа содержимого CDMI.
Коды состояний HTTP - чтение объекта-опции с использованием типа содержимого CDMI
12.2.8 Примеры
1 Применение GET к URI корневого контейнера опций для чтения всех полей контейнера:
GET /cdmi_capabilities/ HTTP/1.1
Accept: application/cdmi-capability
X-CDMI-Specification-Version: 1.0.2
Будет получен следующий ответ.
Content-Type: application/cdmi-capability X-CDMI-Specification-Version: 1.0.2
"objectType" : "application/cdmi-capability",
"objectID" : "00007E7F00104BE66AB53A9572F9F51E",
"objectName" : "cdmi_capabilities/",
"parentID" : "00007E7F0010128E42D87EE34F5A6560",
"cdmi_metadata_maxsize" : "4096",
"cdmi_metadata_maxitems" : "1024"
2 Применение GET к URI корневого контейнера опций для чтения содержимого и потомков контейнера:
GET /cdmi_capabilities/?capabilities;children HTTP/1.1
Accept: application/cdmi-capability
X-CDMI-Specification-Version: 1.0.2
Будет получен следующий ответ.
Content-Type: application/cdmi-capability X-CDMI-Specification-Version: 1.0.2
"cdmi_metadata_maxsize" : "4096",
"cdmi_metadata_maxitems" : "1024"
3 Применение GET к URI корневого контейнера опций для чтения первых двух потомков контейнера:
GET /cdmi_capabilities/?childrenrange;children:0-1 HTTP/1.1
Accept: application/cdmi-capability
X-CDMI-Specification-Version: 1.0.2
Будет получен следующий ответ.
Content-Type: application/cdmi-capability X-CDMI-Specification-Version: 1.0.2
13. Экспортируемые протоколы
13.1. Обзор
Контейнеры CDMITM доступны не только через путь к данным, но также и через другие протоколы. Такой доступ особенно полезен для использования CDMI в качестве интерфейса хранения для облачных вычислительных сред (см. рисунок 8).
Рисунок 8 - CDMI и OCCI в интегрированной облачной вычислительной среде
Контейнеры CDMI, представленные различными протоколами, могут использоваться виртуальными машинами облачной вычислительной среды как виртуальные диски на каждом госте. Показанная на рисунке инфраструктура облачных вычислений реализует как интерфейс открытого облачного компьютера (Open Cloud Computer Interface, OCCI), так и интерфейс CDMI. Вместе с внутренним знанием сети и соответствия дисков, установленного менеджером виртуальных машин, эта инфраструктура может ассоциировать контейнеры CDMI с гостевыми OC посредством подходящего экспортируемого протокола.
Для поддержки экспортируемых протоколов и улучшения их функциональной совместимости с CDMI, модель CDMI предоставляет тип протокола экспорта, который содержит информацию, полученную через интерфейс OCCI. Кроме того, OCCI предоставляет тип хранения, который соответствует контейнеру CDMI, экспортируемому по особому протоколу OCCI. Клиент обоих интерфейсов выполняет операции, совмещающие обе архитектуры, включая следующие:
- Клиент создает контейнер CDMI через интерфейс CDMI и экспортирует его по протоколу OCCI. В результате возвращается objectID контейнера CDMI;
- Клиент создает виртуальную машину через интерфейс OCCI и присоединяет том хранения типа CDMI, используя objectID и тип протокола. В результате возвращается ID виртуальной машины OCCI;
- Клиент изменяет структуру протокола экспорта CDMI контейнера, включая в него ID виртуальной машины OCCI, что предоставляет виртуальной машине доступ к контейнеру;
- Клиент запускает виртуальную машину через интерфейс OCCI.
13.2. Структура экспортируемого протокола
Экспорт контейнера через протокол пути к данным, отличный от CDMI, осуществляется созданием и обновлением контейнера и предоставлением одной или нескольких структур экспортируемого протокола, для каждого такого протокола. В данном международном стандарте все такие протоколы называются "сторонними" протоколами. Реализация сторонних протоколов должна быть обозначена значениями "true" общесистемных опций, см. 12.1.1, имена которых должны всегда начинаться с "cdmi_export_".
Элементы структуры протокола экспорта включают:
- используемый протокол;
- идентификатор контейнера в соответствии со стандартом протокола;
- интернет-домен сервера имен протокола для обслуживаемого клиента;
- список тех, кто может монтировать этот контейнер по данному протоколу, определенный в соответствии со стандартом протокола или (опционально) посредством протокола установления соответствия имен (см. 13.2.1) с указанием пользователей или названий групп CDMI;
- обязательные параметры экспорта протокола;
- опциональные параметры экспорта протокола;
- параметры управления экспортом.
Настоящий стандарт определяет структуры экспорта в нотации JSON для нескольких широко известных сторонних протоколов. Доступ к контейнеру по нескольким протоколам одновременно зависит от функции установления соответствия имен пользователей и групп. Тем не менее, установление соответствия имен не является необходимым, если CDMI используется только для подготовки контейнера, с которым работает исключительно сторонний протокол.
Реализации, которые поддерживают аутентификацию и авторизацию доступа к объектам CDMI как через CDMI, так и через сторонние протоколы, нуждается в поддержке функции безопасности для объектов. Многочисленные соответствующие методы включают:
- определения и принятие схемы безопасности и отображения всех запросов в эту схему. Реализации CDMI, принимающие такую схему, должны использовать процедуру установления соответствия имен, так как:
a) оно проще для управления администраторами, чем прямое установление соответствия идентификаторов;
b) кроме того, желательно, чтобы различные реализации CDMI вели себя схожим образом в этом отношении.
Это означает, что для имени принципала входящего запроса устанавливается соответствующее имя принципала в домене безопасности, а затем полученный идентификаторов принципала используется для авторизации;
- каждый протокол может устанавливать собственную систему безопасности; это означает, что объект может быть доступен конкретному пользователю только через один из протоколов, но не через любой;
- использование схемы безопасности последнего протокола, который использовался для настройки разрешения доступа к объекту. Этот метод также требует установления соответствия между именем принципала входящего запроса и именем принципала из домена безопасности объекта. Как и в первом случае, сервер должен использовать процедуру установления соответствия имен для авторизации пользователя согласно списку ACL объекта.
CDMI не определяет, какой метод будет использован. Он, однако, определяет, как пользователи и группы должны быть отображаться между протоколами.
13.2.1 Установка соответствия имен между CDMI и другим протоколом
Если клиенту необходимо ограничить экспорт через сторонние протоколы, разрешив подключение лишь отдельным пользователям или группам, может быть необходимо передать информацию об установлении соответствия имен групп и пользователей на сервер. Такая информация также необходима для доступа к контейнеру по нескольким протоколам (например, CDMI, и NFS). Соответствие устанавливается следующим образом.
1 При создании общего доступа к контейнеру CDMI сервер должен использовать подходящий механизм, например вызов WmiClass.Create( ) оболочки Powershell в среде Windows или /etc/exports в среде Unix, для ограничения разрешенных подключений от других серверов в соответствии с инструкциями в строке "hosts" свойства "exports". Синтаксис строки hosts соответствует синтаксису /etc/exports в системе Linux, причем строка кодируется в строку JSON. Если сервер CDMI неспособен ограничить подключения согласно указаниям в строке hosts, должна возникать ошибка, но успех или отказ операции зависит от реализации.
2 При поступлении через сторонний протокол запроса, требующего использования имени принципала CDMI, необходимо запросить контроллер стороннего домена, к которому принадлежит сторонний сервер, какому имени принципала соответствует идентификатор пользователя, пришедший в запросе. Отказ в предоставлении имени принципала приведет к отказу в обработке запроса.
3 В списке соответствий имен пользователей для этого протокола необходимо найти запись с именем принципала, полученного от контроллера стороннего домена (подробнее об операции поиска см. 13.2.3). Если запись не найдена, запрос должен быть отклонен. Результат поиска может храниться в той же записи кеша, что и информация с предыдущего шага.
4 Имя принципала CDMI из первой подходящей записи из списка соответствия пользователей протокола используется для авторизации пользовательского запроса посредством механизма безопасности протокола, который отвечает за доступ к объекту.
13.2.1.1 Опции
Следующие опции описывают допустимые операции над существующим контейнером:
- общесистемная опция экспорта через некоторый протокол обозначается наличием опции cdmi_
_export в метаданных системного уровня (например, если "cdmi_nfs_export" равно "true", возможен экспорт контейнера через NFS). Если соответствующее значение равно "false" или не установлено, попытки экспорта контейнера через данный протокол должны быть неуспешными; - поддержка возможности экспорта существующего объекта-контейнера через некоторый сторонний протокол обозначается присутствием опции cdmi_
_export у данного контейнера. Значение опции по умолчанию (если не установлено) равно "true".
13.2.1.2 Домены
Доменное имя, соответствующее каждому экспорту, должно быть задано как строка JSON в дочернем элементе "domain" спецификации протокола экспорта. Если этот элемент отсутствует, доменное имя считается совпадающим с именем сервера, на котором функционирует реализация CDMI.
13.2.1.3 Кеширование
Обращение к контроллеру стороннего домена может быть довольно дорогим, особенно в случае протоколов без запоминания состояния (например, NFS v3), когда поиск теоретически необходим почти для каждой операции. Должна быть возможность кешировать результаты поиска. Рекомендуемое время жизни записи в кеша пользователей 30 мин. В реализациях следует использовать такое время или меньшее, если это возможно. Сервер должен сбрасывать этот кеш в случае изменения в метаданных экспорта, относящихся к данному протоколу. Клиент может запросить сброс кеша посредством чтения данных о соответствии имен пользователей для одного или нескольких протоколов и последующей записи без изменения. Сервер должен сбросить кеши соответствия имен пользователей при обработке запроса на перезапись (для всех протоколов, которых касается перезаписываемая информация).
Для авторизации от имени группы для операций посредством стороннего протокола должен выполняться аналогичный поиск. Для нахождения всех групп, к которым принадлежит данный пользователь, могут потребоваться более одного запроса (например, обычная ситуация, когда пользователь NFS является членом полудесятка групп). Кеш имен групп может использоваться для снижения стоимости таких поисков. Рекомендуемое время жизни кеша имен групп составляет 12 ч; в конкретных реализациях это время должно быть таким или менее, если возможно. Клиент может запросить сброс кеша посредством чтения данных о соответствии имен групп для одного или нескольких протоколов и последующей записи без изменения. Сервер должен сбросить кеши соответствия групп пользователей при обработке запроса на перезапись (для всех протоколов, которых касается перезаписываемая информация).
13.2.1.4 Группы
Установка соответствия имен групп для каждого стороннего протокола должна быть описана в поле groupname спецификации протокола экспорта; его синтаксис аналогичен синтаксису поля username. <1>
<1> Данная информация требуется только при экспорте контейнера.
13.2.1.5 Пример
Пример - PUT /MyContainer HTTP/1.1
Accept: application/cdmi-container
Content-Type: application/cdmi-container
X-CDMI-Specification-Version: 1.0
"hosts" : {"*.mycollege.edu", "derf.cs.myuni.edu" },
"domain" : "lab.mycollege.edu",
{"jimsmith", "<-->", "james.smith" }
{"admins", "<-", "Administrators"},
Будет получен следующий ответ.
Content-Type: application/cdmi-container
X-CDMI-Specification-Version: 1.0
"objectURI" : "/Containers/MyContainer/",
"objectID" : "00007E7F00100C435125A61B4C289455",
"domainURI" : "/cdmi_domains/MyDomain/",
"completionStatus" : "complete",
13.2.2 Пользователи-администраторы
По умолчанию, следующие пользователи эквивалентны и должны рассматриваться как суперпользователи или администраторы:
Серверы должны автоматически ставить этих пользователей в соответствие суперпользователю (root) соответствующего протокола, если иное не указано в списках соответствия имен пользователей.
Так как автоматическое установление имен не соответствует строгим стандартам безопасности, сервер должен перекрыть эти встроенные записи, соответствующие одному или нескольким суперпользователям.
Пример - Суперпользователь отображается в nobody, а всем прочим пользователям в домене NFS соответствует то же имя, что и в домене CDMI.
Content-Type: application/vnd.org.snia.cdmi.container+json X-CDMI-Specification-Version: 1.0
К сожалению, установки разрешений файловых протоколов, невозможно отобразить напрямую. Например, и NFSv4 ACL, и Windows ACL, и POSIX ACL, и параметры NFSv3 позволяют выражать условия безопасности, которые невозможно представить в трех других механизмах, за исключением NFSv3, в котором набор параметров безопасности наименьший. Таким образом, главная задача состоит в построении соответствия между CDMI ACL, где можно указать самые разные разрешения, и более ограниченными в этом смысле системами, например, NFSv3, для отображения пользователям.
Так как существует несколько различных возможностей установить соответствия между разрешениями/ACL и CDMI ACL, настоящий стандарт не устанавливает единой рекомендации. Тем не менее, конкретные способы установления соответствия имен пользователей и групп между доменами должны следовать механизму, описанному в 13.2.3.
13.2.3 Правила синтаксиса и проверки соответствия имен и групповых имен
Грамматика BNF для установления соответствия имен выглядит следующим образом:
protocol = "cdmi" | "nfs" | "cifs" | "ldap"
name = pattern | utf8_name | quoted_utf8_name
utf8_name = <допустимая последовательность utf8 символов, не включающая ",',,/,:,*,?>
mapping_operator = "<--" | "<-->" | "-->"
Запись соответствия имен состоит из пары имен, разделенных оператором направления. Так как большинство сред используют одинаковые имена пользователей и групп в административных доменах, наиболее распространен картирующий оператор " * <--> * ", который устанавливает соответствие каждого имени такому же имени стороннего протокола, и наоборот. Рекомендуется делать эту запись единственной записью списка соответствия по умолчанию и последней записью сложных списков соответствия.
CDMI специфицирует соответствие по шаблонам имен, но требуется лишь совпадение префикса. Символ " * " на конце символьной строки замещает произвольное число любых непробельных символов.
Проверка соответствия имен должна проводиться по порядку; если найдено соответствие, возвращается найденный результат, и другие проверки не проводятся.
Если соответствия не найдено, результат зависит от системы. Тем не менее, рекомендуется, чтобы серверы либо запрещали доступ, либо относили бы пользователя к "анонимному" ("anonymous") или его эквиваленту в целевом протоколе. Кроме того, рекомендуется создавать запись для специального пользователя "EVERYONE@".
13.3. Обнаружение и подключение контейнеров через сторонние протоколы
Клиентам требуется механизм обнаружения экспортированных контейнеров, которые можно использовать для подключения (mount). Это проводится посредством выполнения операции GET к дочернему элементу "exports" контейнера.
Для чтения всех экспортов для существующего объекта-контейнера следует выполнить запрос:
Для чтения отдельных экспортов для существующего объекта-контейнера следует выполнить запрос:
GET
имя пользователя CDMI, который подключает ресурс. Этот параметр необязателен, и по умолчанию равен имени владельца контейнера. Если параметр не пустой, серверы должны фильтровать список экспорта, чтобы включить только экспорты, которые могут быть выполнены пользователем с учетом ограничений протокола экспорта; опциональный параметр, указывающий на желание получить максимальную информацию об экспортах. Если присутствует, может иметь значения "true" или "false" (по умолчанию - "false"). Если равен "true", сервер должен вернуть дополнительную информацию о контейнере, которая содержится в его элементе "exports". Количество возвращаемой информации зависит от реализации, так как разработчики серверных решений вынуждены искать баланс между потребностями клиентов и требованиями безопасности.
13.4. Экспортный протокол NFS
Чтобы экспортировать контейнер через NFS, необходима информация о том, какая серверная реализация будет выполнять экспорт. Обычно эта информация содержится в файле /etc/exports или его эквиваленте на сервере. Администраторы должны иметь в виду, что в этот файл могут автоматически добавляться строки для каждого экспортируемого CDMI контейнера.
- "protocol". Запрошенный протокол может быть "NFSv3", "NFSv4", "NFSv4.1" или более поздняя версия NFS, описанная в основном стандарте IETF RFC. Версия 2 протокола NFS не поддерживается в модели CDMI;
- "exportdomain". Доменное имя сервера имен для обслуживаемого клиента. Обычно это домен LDAP организации, например, "iti.edu". Значение "." следует интерпретировать как имя DNS домена, занятого сервером CDMI;
- "mode". Может принимать одно из значений "ro", "rw", "root" или "rpc_gsssec". Указанный режим становится режимом экспорта по умолчанию. Узлы, требующие различного доступа, должны быть указаны в опциональных элементах структуры "rw_mode", "ro_mode" и "root_mode". Однако, режим "rpc_gsssec" перекрывает все другие режимы, и другие элементы, связанные с режимами доступа, и их содержимое будут в этом случае игнорироваться;
- "control". Управление экспортом контейнера, может принимать значения "immediate", "off", "on", или
(число). Серверы могут устанавливать значение в "on", а клиенты нет. Числовое значение ( ) указывает, что экспорт должен быть отключен через секунд, возможно, после отсылки сообщения клиентам, подключенным для экспорта. Если клиент указывает значение , но сервер не поддерживает отложенное отключение экспортов, данный параметр должен обрабатываться как равный "off".
- "domain_servers". Список имен серверов или IP адресов, которые функционируют как сервера имен для домена, указанного в "domain". Если приведено, это значение перекрывает имена, полученные от сервера CDMI другими программными средствами;
- "hosts". Список узлов, которые могут получить доступ к контейнеру в режиме, указанном в "mode". По умолчанию равно "*"; другие значения ограничивают возможности;
- "root_hosts". Список узлов, которые могут получить доступ к контейнеру в режиме суперпользователя. По умолчанию список пуст;
- "rw_hosts". Список узлов, которые могут получить доступ к контейнеру в режиме r/w. По умолчанию список пуст;
- "ro_hosts". Список узлов, которые могут получить доступ к контейнеру в режиме лишь r/o. По умолчанию список пуст;
- "mount_type". Одна из двух строк "hard" или "soft". Если сервер перестает отвечать, клиент с подключением "hard" зависает. Клиент с подключением "soft" при в этой ситуации генерирует сообщения об ошибке. Значение по умолчанию зависит от реализации;
- "recurse". Может быть "true" или "false", по умолчанию "true". Если "true", параметр указывает, клиент может переходить по подключениям (mount) в пределах структуры директорий CDMI (предположительно, созданным другими NFS операциями), и подключенная директория должна быть показана, как если бы она была частью экспортируемого CDMI контейнера. Параметр эквивалентен параметру "crossmnt" системы Linux.
Другие параметры NFS экспорта не описаны в протоколе CDMI, но могут включаться в структуру экспорта. Например, такими параметрами могут быть аналоги параметров из системы Linux, такие как "sync", "no_wdelay", "insecure_locks" и "no_acl", а также любые другие параметры, использованные данной серверной операционной системой. В таких случаях, параметры должны быть указаны в нотации JSON, в которой "true" и "false" используются как бинарные флаги, а для параметров другого типа используются строки или списки.
| Пример - {"exports" {"nfs" {... {"no_wdelay", "true"}, {"refer", "otherserver://path/leaf"}, ... } } } |
|---|
Управление экспортом осуществляется с участием единственного элемента с именем "control":
- значение "immediate" указывает серверу на то, что экспорт необходимо осуществить немедленно, перед завершением операции PUT. Серверы должны заменять значение в "on" и помещать это в ответ;
- значение "off" указывает серверу, что не следует начинать новый экспорт, а существующий экспорт должен быть отменен, с разрывом всех клиентских соединений;
- числовое значение
указывает, что сервер должен выждать секунд перед принудительным сбросом экспорта и разрывом клиентских соединений. Рекомендуется, чтобы сервер посылал предупредительное сообщение, позволяя клиентам выйти из соединения обычным путем, но зависит от реализации. Если экспорт был отменен, сервер должен также изменить значение параметра "control" на "off" в структуре экспорта.
Серверы должны поддерживать символы подстановки "*" и "?" в списках узлов (это стандартное поведение), так что **.cs.uscs.edu" соответствует всем серверам факультета cs.ucsc.edu.
Серверы могут поддерживать сетевые групповые имена в различных списках узлов. Эти списки, если поддерживаются, должны разрешаться в обычные списки имен узлов посредством запросов к серверу имен домена.
Серверы также могут поддерживать диапазоны IP адресов в различных списках узлов. Это должны быть IP адреса, построенные с использованием обычных подстановочных символов (например, "192.168.1.*" экспортирует на все машины домашней сети NetGear по умолчанию). Разработчики клиентской части должны иметь в виду, что "экспортирование" означает единственно то, что контейнер может быть экспортирован. Клиент должен также подключить экспортированный контейнер перед установкой соединения с сервером.
Пользователи, желающие использовать опциональные и зависящие от реализации настройки сами определяют от поставщика CDMI продукта, какие настройки допустимы и в каком формате. Серверы могут возвращать код 400 (Bad Request) если настройки экспорта не соответствуют допустимым настройкам сервера.
13.5. Экспортный протокол CIFS
Для экспорта контейнера посредством CIFS, необходима информация о том, какая серверная реализация будет выполнять экспорт. Местонахождение этой информации зависит от реализации. Сервер может автоматически добавлять или удалять строки из файла для каждого контейнера CDMI, который экспортируется или деэкспортируется.
Обязательные элементы протокола структуры для экспорта CIFS включают:
- "share_name". Имя, по которому экспортированный элемент обнаруживается в CIFS;
- "exportdomain". Домен сервера имен протокола для обслуживаемого клиента. Обычно это домен LDAP организации, например "iti.edu". Значение "." следует интерпретировать как DNS имя домена, занятого сервером CDMI;
- "mode". может быть "ro" или "rw";
- "control". Управление экспортом для контейнера. Может принимать значения "immediate", "off", или
(число). Серверы могут устанавливать значение в "on", но клиенты не могут. Семантика и требования к параметру в точности соответствуют таковым для NFS, см. "Управление экспортом", 13.4).
Поле "protocol" не специфицируется; модель CDMI предполагает, что осуществляется обычное согласование версии по протоколу SMB.
Опциональный параметр экспорта -- "comment", который часто используется для задания удобочитаемого имени экспортируемого ресурса для клиента.
Другие параметры CIFS экспорта не описаны в протоколе CDMI, но могут включаться в структуру экспорта. Например, такими параметрами могут быть параметры производителя "forcegroup", "umask", "caching", and "oplocks", а также любые другие параметры, использованные данной серверной операционной системой. В таких случаях, параметры должны быть указаны в нотации JSON, в которой "true" и "false" используются как бинарные флаги, а для параметров другого типа используются строки или списки.
| Пример - {"exports" {"cifs" {... {"caching", [{"manual", "document", "program"}], {"oplocks", "true"}, ... } }379 } |
|---|
Пользователи, желающие использовать опциональные и зависящие от реализации настройки, сами определяют от поставщика CDMI продукта, какие настройки допустимы и в каком формате. Серверы могут возвращать код 400 (Bad Request) если настройки экспорта не соответствуют допустимым настройкам сервера.
13.6. Экспортный протокол OCCI
CDMI определяет структуру протокола экспорта для стандарта OGF: Open Cloud Computing Interface (OCCI) следующим образом:
- Протокол: "OCCI/<стандарт протокола>" (например, OCCI/NFSv4).
- Идентификатор - ID объекта CDMI.
- Массив JSON из URI к вычислительным ресурсам OCCI должны иметь доступ к экспортированному контейнеру.
| Пример - Структура протокола экспорта OCCI в JSON: "OCCI/iSCSI": { "identifier": "00007E7F00104BE66AB53A9572F9F51E", "permissions": [ "http://example.com/compute/0/", "http://example.com/compute/1/" ] } |
|---|
Подробное описание структуры протокола экспорта OCCI приведено в 13.1. Так как в действительности управление сетями и доступом осуществляется невидимой для клиентов общей инфраструктурой, включающей и OCCI, и CDMI, обычная структура доступа не должна предоставляться.
13.7. Модификация экспорта iSCSI
CDMI определяет экспорт контейнера по протоколу iSCSI (см. RFC 3720). Каждый контейнер экспортируется как отдельное логическое устройство (Logical Unit) SCSI с номером логического устройства (Logical Unit Number, LUN). Один или несколько инициаторов iSCSI импортируют LUN из контроллера iSCSI, используя один или несколько сетевых порталов iSCSI (IP адресов).
Такой экспорт описывается наличием в контейнере структуры экспортного поля, которое указывает
- протокол экспорта ("Network/iSCSI");
- информацию о контроллере iSCSI (IP адрес или полное доменное имя, идентификатор контроллера и LUN);
- имя логического устройства;
- iSCSI инициаторы, которым предоставлен доступ.
Идентификатор контроллера может указываться в формате iqn, naa или eui, и должен иметь шестнадцатеричную метку группы портала.
13.7.1 Чтение контейнера
Возврат полной информации о структуре экспорта:
13.7.2 Создание и изменение контейнеров
Следующий код создает контейнер с iSCSI экспортом и изменяет существующий контейнер, добавляя новый iSCSI экспорт. Поддержка любой из этих операций обозначается наличием опции cdmi_export_iscsi в родительском или существующем контейнере.
| "exports" : { "Network/iSCSI": { "permissions": [ "iqn.2010-01.com.acme:host1", "iqn.2010-01.com.acme:host2" ] } } |
|---|
Для этих экспортных операций реализация CDMI выбирает IP порталы, iSCSI цель, номер логического устройства и его имя; эти параметры не выдаются. Указывается только список инициаторов, которые должны иметь доступ к экспортируемому контейнеру.
13.7.3 Изменение экспорта
Следующий код изменяет экспорт существующего контейнера. Поддержка этой операции обозначается наличием опции cdmi_export_iscsi в родительском контейнере существующего контейнера. Для данной операции указывается только список инициаторов, которые должны иметь доступ к экспортируемому контейнеру.
13.8. Экспортный протокол WebDAV
CDMI определяет экспорт контейнера по стандарту WebDAV следующим образом (см. RFC 4918):
- Протокол равен "Network/WebDAV".
- Путь точки подключения WebDAV в том виде, как передается клиентам (включая имя узла сервера).
- Список тех, кто имеет доступ к разделяемому объекту, определяется стандартными ACL CDMI для каждого ресурса, экспортированного через WebDAV.
Пример - Структура протокола экспорта WebDAV в JSON:
В этом примере значение "domain" в поле разрешений указывает, что имена пользователей должны ставиться в соответствие через членство в домене экспортируемого CDMI контейнера.
WebDAV поддерживает блокировку, но поддерживается ли блокировка доступа через CDMI, определяется реализацией, поэтому взаимодействие двух протоколов намеренно не описывается в настоящем стандарте.
14. Снимки состояния
Снимок состояния - моментальная копия контейнера и его содержимого, включая вложенные контейнеры, объекты данных и объекты-очереди. Клиент именует снимок в момент запроса снимка. Операция создания снимка создает новый контейнер, содержащий моментальную копию. Первое создание снимка добавляет вложенный контейнер cdmi_snapshots в исходный контейнер. Создаваемые затем моментальные снимки добавляются как потомки контейнера cdmi_snapshots. Снимок на рисунке 9 не содержит контейнер cdmi_snapshots и его содержимое.
Рисунок 9 - Структура снимка состояния контейнера
Операция создания снимка состояния запрашивается посредством операции обновлении контейнера (см. 9.5), в которой поле snapshot указывает на запрошенное имя снимка.
Доступ к снимку состояния осуществляется аналогично другим объектам CDMITM. Важное применение снимков состояния - откат состояния исходного контейнера к предыдущему состояние с использованием операции копирования CDMI объектов.
15. Сериализация/десериализация
15.1. Обзор
Зачастую требуется переместить большой объем данных между облаками, в облако или из него. Операции облачной сериализации, предоставляющие механизм нормализации данных в канонический, самоописывающий формат, включают:
Канонический формат сериализованных данных описывает, как данные должны представляться в виде потоке байтов. Если этот поток не изменяется во время передачи, данные могут быть восстановлены в системе назначения.
15.2. Экспорт сериализованных данных
Каноническая форма данных получается при создании нового объекта и указании, что источник данных - сериализация заданного объекта данных, контейнера или очереди CDMITM. Результат успешной сериализации - объект данных, содержащий сериализованные данные в поле value. Если контейнер включает блочный протокол экспорта, сериализованные данные могут включать содержимое контейнера поблочно, а также его метаданные.
Полученный в результате объект данных есть каноническое представление выбранного объекта данных, контейнера и потомков или очереди.
- Если в качестве источника указан объект данных, канонический формат должен включать все поля объекта данных, в том числе value, valuetransferencoding и поля метаданных.
- Если в качестве источника указана очередь, канонический формат должен включать все поля очереди, включая поля value и valuetransferencoding элементов очереди, вместе с метаданными самой очереди.
- Если в качестве источника указан контейнер, канонический формат должен рекурсивно включать все поля контейнера и его потомков. Если пользователь пытается сериализовать контейнер, и к отдельным потомкам данного контейнера у него нет разрешения на доступ, эти элементы не должны включаться в конечный сериализованный объект.
При выполнении сериализации, в результат должны включаться лишь те объекты, для которых у пользователя, инициирующего сериализацию, есть права на чтение.
15.3. Импорт сериализованных данных
Канонические данные могут быть десериализованы обратно в облако, создавая новый объект данных, контейнер или очередь; для этого следует указать, что источником данных для создания является десериализация заданного объекта, либо поместить сериализованные данные в кодировке base 64 в поле deserializevalue.
Объект назначения может как существовать заранее, так и создаваться заново. Если контейнер уже существует, операция обновления с сериализованным потомком должна обновить контейнер и всех его потомков. Если сериализованный контейнер не содержит потомков, только объект-контейнер будет обновлен. Объекты данных воссоздаются в соответствии с каноническим форматом, включая все метаданные и ID объекта.
- Если пользователь, который выполняет десериализацию сериализованных данных, имеет права "cross_domain" и не указал domainURI как часть операции десериализации, будет использовано исходное поле domainURI сериализованного объекта. Если некоторые из указанных domainURI некорректны в контексте системы хранения, в которой выполняется десериализация, вся операция десериализации должна быть отменена.
- Если пользователь, который выполняет десериализацию сериализованного объекта, указывает domainURI как часть операции десериализации, domainURI каждого десериализуемого объекта устанавливается в указанное значение. Чтобы указать domainURI, отличный от domainURI родителя, пользователь должен иметь права cross_domain. Если у пользователя нет таких прав, и указан domainURI, отличный от domainURI родителя, должен быть возвращен ответ 400 Bad Request.
- Если пользователь, который выполняет десериализацию сериализованного объекта, не указывает domainURI как часть операции десериализации и не имеет прав "cross_domain", десериализация должна быть успешной только если у всех объектов тот же domainURI, что у родительского объекта, на котором выполняется десериализация.
Операции десериализации должны восстанавливать все метаданные из указанного источника. Если в исходном сериализованном объекте были использованы расширения производителя через произвольные ключи и значения метаданных, эти произвольные требования должны быть восстановлены при десериализации. Однако произвольные метаданные (ключи и значения) могут быть интерпретированы как пользовательские метаданные (сохраняться, но не обрабатываться).
Такое сохранение позволяет перемещать между облаками данные произвольной конфигурации.
15.3.1 Канонический формат
Канонический формат должен представлять указанные объекты данных и контейнеры как если бы они существовали в системе хранения. Каждый объект должен представляться метаданными объекта, идентификаторами и потоком данных объекта данных. Поскольку метаданные наследуются от контейнеров более высокого уровня, все родительские метаданные должны быть представлены в канонической форме (существенно уплощая иерархию). Для сохранения текущих значений метаданных, относящихся к сериализуемому объекту, не перезаписанные метаданные включаются как из непосредственного родительского контейнера, так и от родительских контейнеров более высокого уровня.
Канонический формат должен обладать следующими свойствами:
- рекурсивное представление JSON для объекта данных, совместимое с остальной частью CDMI;
- метаданные пользователя и системы данных для каждого объекта данных/контейнера;
15.3.2 Пример канонического сериализованного формата JSON
"parentID": "00007E7F0010128E42D87EE34F5A6560",
"domainURI": "/cdmi_domains/MyDomain/",
"capabilitiesURI": "/cdmi_capabilities/container/",
"http://example.com/compute/1/"
"objectID" : "0000706D0010B84FAD185C425D8B537E",
"parentID" : "00007E7F00102E230ED82694DAA975D2",
"completionStatus" : "Complete",
"valuetransferencoding": "utf-8",
"parentURI" : "/MyContainer/",
"capabilitiesURI" : "/cdmi_capabilities/queue/",
При сериализации контейнеров в JSON массив children должен быть последним элементом канонического формата сериализации JSON для эффективной десериализации в потоковом режиме.
16. Метаданные
16.1. Управление доступом
Управление доступом предоставляет механизмы, позволяющие авторизовывать и либо разрешать, либо запрещать различные способы доступа к объектам и контейнерам. CDMITM использует известный механизм списков контроля доступа (Access Control List, ACL), определенный в стандарте NFSv4 (см. RFC 3530). ACL представляют собой списки записей, предоставляющих или запрещающих доступ, которые называются записи управления доступом (access control entry, ACE).
16.1.1 Структуры ACL и ACE
ACL представляет собой упорядоченный список ACE. Существуют два типа ACE в модели CDMI: ALLOW и DENY. Запись ALLOW разрешает некоторый тип доступа соответствующему принципалу (пользователю или группе пользователей, представленными идентификаторами); наоборот, запись DENY запрещает принципалу какой-то тип доступа. Например, DENY может запрещать запись метаданных или ACL в объект, но не запрещать любые другие формы доступа. Однако, если другая запись ACE ALLOW разрешает запись в объект, принципалу разрешено записывать данные объекта, но ничего больше.
ACE включают четыре поля: type, who, flags и access_mask, см. RFC 3530. Поля type, flags и access_mask должны быть либо строковым представлением целого беззнакового числа в шестнадцатеричной записи, либо списком строковых битовых масок из таблиц 112, 114 115, разделенных запятыми.
16.1.2 Типы ACE
В таблице 112 приведены типы ACE, согласно NFSv4.
Примечание - Строковые формы могут быть безопасно сокращены, так как они локальны для структуры ACE, в отличие от относительно глобальных констант.
Порядок ACE в ACL задается клиентом. Сервер не должен задавать какой-либо порядок, и должен хранить и анализировать записи ACE в порядке, заданном клиентом.
16.1.3 Поле Who
Особые идентификаторы "who" должны интерпретировать универсально, а не в контексте данного внешнего домена безопасности (см. таблицу 113). Некоторые из этих идентификаторов могут недоступны для клиентов, когда клиент CDMI получает доступ к серверу, но они могут быть значимыми, когда локальный процесс получает доступ к файлу. CDMI должен предоставить возможность показывать и изменять эти разрешения, даже если ни один из методов доступа на сервере не использует эти идентификаторы.
Чтобы избежать конфликта имен, специальные идентификаторы заканчиваются символом "@" без указания доменного имени.
16.1.4 Поле flags
CDMI позволяет организовывать вложенные контейнеры и передачу полномочий, когда объекты и вложенные контейнеры могут наследовать разрешения на доступ от родительских контейнеров. Однако недостаточно просто наследовать все разрешения от родителя, может быть необходимо, например иметь различные разрешения по умолчанию для потомков и вложенных контейнеров данного контейнера. Флаги, описанные в таблице 114, управляют этим поведением.
16.1.5 Битовые маски ACE
Поле mask в ACE содержит 32 бита. В таблице 115 приведены битовые маски ACE в CDMI; их значения взяты из IETF NFSv4 RFC 3530.
Реализации должны использовать корректную строковую форму для отображения разрешений, если тип объекта известен. Если тип объекта неизвестен, должна использоваться форма строки "object".
16.1.6 Обработка ACL
При оценке, предоставлены ли права доступа к объекту O для принципала P, сервер должен проследить логический ACL объекта (его ACL после обработки наследования от родительского контейнера) в порядке, указанном в списке, используя временную битовую маску разрешения m, изначально пустую (заполненную нулями).
- Если объект не содержит ACL, алгоритм завершается, и доступ запрещен всем пользователям и группам. Такое состояние не ожидается, так как реализации CDMI требуют наследования ACL по умолчанию от всех корневых контейнеров.
- ACE, не относящиеся к принципалу P, игнорируются.
- Если встреченная ACE запрещает доступ P для некоторых из битов маски, доступ запрещается и алгоритм завершается.
- Если встреченная ACE разрешает принципалу P доступ, маска разрешений m складывается по правилу XOR с маской разрешений из ACE. Если m достаточна для запрашиваемой операции, доступ разрешается, и алгоритм завершается.
- При достижении конца ACL, если доступ не был разрешен и не был прямо запрещен, доступ запрещается, и алгоритм завершается, если только объект O не является корневым контейнером. В этом случае сервер должен:
- разрешить доступ владельцу контейнера, ADMINISTRATOR@, либо любому члену группы ADMINUSERS@; и
- записать в лог событий произошедшее.
Если разрешение на операцию не было явно дано, даже ADMINISTRATOR@ и эквивалентные пользователи не могут получить доступ к объектам, отличным от корневого контейнера. Если администратору требуется доступ к объекту, следует обратиться к корневому контейнеру и изменить его наследуемые ACE, чтобы разрешить доступ к необходимому объекту. В результате создается запись в логе для отслеживания доступа.
Если создается корневой контейнер без указания ACL, сервер должен разместить для контейнера ACL, содержащий следующие ACEs:
Так как ACL является метаданными системы хранения, они сохраняются и предоставляются через поле metadata в запросе PUT или GET. Синтаксис ACL представлен ниже. Используются строковые константы из таблиц 112, 114, 115.
ACE = {acetype , identifier , aceflags , acemask}
acetype = uint_t | acetypeitem
aceflags = uint_t | aceflagsstring
acemask = uint_t | acemaskstring
acetypeitem = aceallowedtype |
aceallowedtype = "CDMI_ACE_ACCESS_ALLOWED_TYPE" | 0x0
acedeniedtype = "CDMI_ACE_ACCESS_DENIED_TYPE" | 0x01
aceaudittype = "CDMI_ACE_SYSTEM_AUDIT_TYPE" | 0x02
aceflagsstring = aceflagsitem [| aceflagsitem ...]
aceflagsitem = aceobinherititem |
aceobinherititem = "CDMI_ACE_OBJECT_INHERIT_ACE" | 0x01
acecontinherititem = "CDMI_ACE_CONTAINER_INHERIT_ACE" | 0x02
acenopropagateitem = "CDMI_ACE_NO_PROPAGATE_INHERIT_ACE" | 0x04
aceinheritonlyitem = "CDMI_ACE_INHERIT_ONLY_ACE" | 0x08
acemaskstring = acemaskitem [| acemaskitem ...]
acemaskitem = acereaditem | acewriteitem .|
aceappenditem | acereadmetaitem.|
acewritemetaitem | acedeleteitem.|
acedelselfitem | acereadaclitem.|
acewriteaclitem | aceexecuteitem.|
acereadattritem | acewriteattritem.|
acereaditem = "CDMI_ACE_READ_OBJECT" |
"CDMI_ACE_LIST_CONTAINER" | 0x01
acewriteitem = "CDMI_ACE_WRITE_OBJECT" |
aceappenditem = "CDMI_ACE_APPEND_DATA" |
"CDMI_ACE_ADD_SUBCONTAINER" | 0x04
acereadmetaitem = "CDMI_ACE_READ_METADATA" | 0x08
acewritemetaitem = "CDMI_ACE_WRITE_METADATA" | 0x10
acedeleteitem = "CDMI_ACE_DELETE_OBJECT" |
"CDMI_ACE_DELETE_SUBCONTAINER" | 0x40
acedelselfitem = "CDMI_ACE_DELETE" | 0x10000
acereadaclitem = "CDMI_ACE_READ_ACL" | 0x20000
acewriteaclitem = "CDMI_ACE_WRITE_ACL" | 0x40000
aceexecuteitem = "CDMI_ACE_EXECUTE" | 0x80000
acereadattritem = "CDMI_ACE_READ_ATTRIBUTES" | 0x00080
Если маски ACE показываются в числовом формате, они должны всегда быть шестнадцатеричными и начинаться с "0x". Этот формат позволяет как серверам, так и клиентам быстро определять, какая из двух форм использована для данной константы. Если маски представлены в строковой форме, они должны быть преобразованы в числовой формат и затем анализироваться с использованием стандартных побитовых операций.
Если при создании объекта ACL не указан и не наследуется от родительского контейнера (или родительский контейнер отсутствует), сервер должен разместить на объекте следующий ACL:
| "cdmi_acl": [ { "acetype": "ALLOW", " identifier": "OWNER@", "aceflags": "OBJECT_INHERIT, CONTAINER_INHERIT", "acemask": "ALL_PERMS" } ] |
|---|
16.1.7 Пример битовых выражений ACE
16.1.8 Канонический формат шестнадцатеричных параметров ACE
Битовые выражения ACE должны всегда вычисляться и приводиться к единственному шестнадцатеричному значению перед передачей в датаграмму протокола HTTP. Приложения или утилиты, отображающие их для пользователей, должны преобразовывать их в текстовое представление и принимать текстовый ввод от пользователя. Для этого следует использовать побитовые операторы "|" и "&".
Для разложения маски в строки следует использовать следующий алгоритм. Таблица масок и строковых эквивалентов должна поддерживаться в порядке от большего к меньшему:
0x001F07FF "ALL_PERMS" "ALL_PERMS"
0x0006006F "RW_ALL" "RW_ALL"
0x0000001F "RW" "RW" ...
0x00000002 "WRITE_OBJECT" "ADD_OBJECT"
0x00000001 "READ_OBJECT" "LIST_CONTAINER"
Например, для маски M следует повторять следующие шаги, пока не установится M == 0:
1 Выбрать наибольшую маску m из таблицы, такую что M & m == m.
2 Если объект является контейнером, выбрать строку из 3-й колонки, иначе выбрать строку из 2-й колонки.
3 Побитово вычесть m из M, т.е., M = M xor m.
В полном текстовом представлении выбранные строки соединяются символом «, », например, «ALL_PERMS, WRITE_OWNER». Строки должны появляться в порядке от большего значения к меньшему.
Такой же способ должен применяться для других наборов соответствий между шестнадцатеричными значениями и строками.
При правильном программировании этот алгоритм требует лишь одного (зачастую частичного) прохода через таблицу соответствий строк и чисел.
16.1.9 Представление ACL в нотации JSON
Флаги и маски ACE входят в 32-битный объект, который часто обрабатывается в виде шестнадцатеричного представления. Формат данных JSON не поддерживает шестнадцатеричные целые, поэтому все шестнадцатеричные целые должны в ACL модели CDMI быть представлены как закавыченные строки, начинающиеся с «0x».
ACL, содержащий одну или несколько ACE, в формате JSON представляется как:
ACE в таком ACL должны сравниваться в порядке появления.
Пример - ACL, внедренный в ответ на запрос GET:
Content-Type: application/cdmi-object
X-CDMI-Specification-Version: 1.0.2
«objectType» : «/application/cdmi-object»,
«objectID» : «0000706D0010734CE0BAEB29DD542B51»,
«objectName» : «MyDataItem.txt»,
«parentURI» : «/MyContainer/»,
«domainURI» : «/cdmi_domains/MyDomain/»,
«capabilitiesURI» : «/cdmi_capabilities/dataobject/»,
«completionStatus» : «Complete»,
16.2. Поддержка пользовательских метаданных
Все объекты CDMI должны поддерживать метаданные, позволяющие включение произвольных определенных пользователем элементов, но имя таких пользовательских метаданных не должно начинаться с префикса «cdmi_».
- Максимальное количество элементов пользовательских метаданных указано в опции «cdmi_metadata_maxitems».
- Максимальный размер каждого элемента пользовательских метаданных указан в опции «cdmi_metadata_maxsize».
16.3. Поддержка метаданных системы хранения
После создания объекта метаданные системы хранения, указанные в таблице 116, должны быть сгенерированы облачной системой хранения и немедленно сделаны доступными клиенту CDMI в виде метаданных, возвращаемых в ответ на операции создания или последующее использование.
| Имя элемента метаданных | Тип | Описание | Требование |
|---|---|---|---|
| cdmi_size | Строка JSON | Количество байтов, которые занимает объект. Этот элемент метаданных рассчитывается системой хранения, и все попытки изменить или установить его должны игнорироваться. | Опционально |
| cdmi_ctime | Строка JSON | Время создания объекта, в формате ISO-8601, как описано в 5.14. | Опционально |
| cdmi_atime | Строка JSON | Время доступа к объекту, в формате ISO-8601, как описано в 5.14. Доступ или изменение объекта-потомка не считается доступом к родительскому контейнеру (событие доступа/изменения не распространяется по дереву). | Опционально |
| cdmi_mtime | Строка JSON | Время последнего изменения объекта, в формате ISO-8601, как описано в 5.14. Изменение объекта-потомка не считается изменением родительского контейнера (событие изменения не распространяется по дереву). | Опционально |
| cdmi_acount | Строка JSON | Количество доступов к объекту со времени его создания. Доступом считаются все операции чтения, записи и перечисления. | Опционально |
| cdmi_mcount | Строка JSON | Количество изменений объекта со времени его создания. Изменением считаются все операции изменения значения или метаданных. Модификации метаданных в результате чтения (например, изменение atime) не считаются изменением объекта. | Опционально |
| cdmi_hash | Строка JSON | Хеш значения объекта, кодируемого по правилам base 16, описанным в RFC 4648. Этот элемент метаданных должен присутствовать, когда элемент cdmi_value_hash метаданных системы данных данного или родительского объекта указывает, что значение объекта должно хешироваться. | Опционально |
| cdmi_owner | Строка JSON | Имя принципала — владельца объекта. | Обязательно |
| cdmi_acl | Массив JSON объектов JSON | Стандартные метаданные ACL. Если не указаны при создании объекта, этот элемент заполняется системой. | Опционально |
16.4. Поддержка метаданных системы данных
Если указаны, метаданные системы данных указывают системе хранения, как осуществлять службы управления данными через интерфейс CDMI.
Метаданные системы данных, приведенные в таблице 117, наследуются от родительского объекта каждым потомком. Если наследник содержит метаданные системы данных, метаданные потомка должны перекрывать соответствующие элементы родительского объекта.
| Имя элемента метаданных | Тип | Описание | Требование |
|---|---|---|---|
| cdmi_data_redundancy | Строка JSON | Если данный элемент метаданных присутствует и установлен равным строковому представлению положительного числа, он показывает сколько полных копий запросил клиент. Дополнительные копии создаются в соответствии с установленным значением. Если данный элемент отсутствует или не установлен равным положительному числу, он не должен использоваться. | Опционально |
| cdmi_immediate_redundancy | Строка JSON | Если данный элемент метаданных присутствует и установлен равным «true», это означает, что клиент запрашивает, чтобы как минимум количество копий, установленных в cdmi_data_redundancy, содержали вновь записанное значение до завершения операции. Этот элемент обеспечивает запись на постоянный носитель нескольких копий данных для предотвращения их потери. Если данный элемент отсутствует или не равен «true», он не должен использоваться. Если заданное количество копий не может быть создано за время ожидания операции HTTP, транзакция должна завершиться, но элемент метаданных cdmi_immediate_redundancy_provided должен быть установлен в «false». |
Опционально |
| cdmi_assignedsize | Строка JSON | Если данный элемент метаданных присутствует и установлен равным строковому представлению положительного числа, он показывает, что клиент передает размер в байтах, необходимый для экспорта контейнера через другие протоколы (см. 9.1.1). Система не обязана резервировать этот объем, и он может быть выделен по механизму тонкого резервирования. Таким образом, запрошенное значение может быть больше, чем реальный объем использованного пространства. Если этот элемент отсутствует или не содержит положительное число, он не должен использоваться. Данный элемент применим только к контейнерам и не наследуется их дочерними объектами. |
Опционально |
| cdmi_infrastructure_redundancy | Строка JSON | Если данный элемент метаданных присутствует и установлен равным строковому представлению положительного числа, он указывает на то, что клиент запрашивает соответствующее число независимых инфраструктур хранения для поддержки нескольких копий данных. Данный элемент используется для того, чтобы копии, запрошенные в cdmi_data_redundancy, хранились на нескольких независимых устройствах. Если этот элемент отсутствует или не равен положительному числу, он не должен использоваться. | Опционально |
| cdmi_data_dispersion | Строка JSON | Если данный элемент метаданных присутствует и установлен равным строковому представлению положительного числа, он указывает на то, что клиент запрашивает минимальное расстояние (в км) между инфраструктурами, поддерживающими хранение копий (число копий равно cdmi_infrastructure_redundancy) данных. Этот элемент используется для повышения надежности хранения копий данных, предотвращая их потерю вследствие местных аварий. Если этот элемент отсутствует или не равен положительному числу, он не должен использоваться. | Опционально |
| cdmi_geographic_placement | Массив JSON строк JSON | Если данный элемент метаданных присутствует и соответствует некоторому количеству геополитических идентификаторов, это означает, что клиент накладывает ограничение на географические регионы, где может храниться объект. Каждый геополитический идентификатор должен быть либо строкой, содержащей корректный код страны/административного образования в соответствии со стандартом ISO 3166, показывающей, где разрешено хранение объекта, либо строкой, начинающейся с символа «!» перед кодом по стандарту ISO 3166 страны/административного образования, удаляющей страну/административное образование из предыдущего списка геополитических регионов. Данный список обрабатывается слева направо, обработка заканчивается, если кандидат-хранилище находится в списке как разрешенный или запрещенный регион, или административное образование в составе разрешенного или запрещенного региона. В дополнение к кодам ISO 3166, «*» указывает на все регионы. Если место-кандидат не соответствует ни одной из записей списка, оно рассматривается как запрещенное. Если данный элемент метаданных отсутствует, он не должен быть использован. Если данный элемент присутствует, но не содержит корректный идентификатор геополитического региона, операции создания, изменения или десериализации должны возвращать отказ с кодом ошибки HTTP 400 Bad Request. Если данный элемент присутствует и корректен, но нет доступных допустимых местоположений хранилищ, операции создания, изменения или десериализации должны возвращать отказ с кодом ошибки HTTP 403 Forbidden. |
Опционально |
| cdmi_retention_id | Строка JSON | Если данный элемент метаданных присутствует и установлен равным непустой строке, он показывает, что клиент запрашивает добавление данной строки к объекту в качестве метки, обозначающей, что объект подпадает под определенную политику отложенного удаления. Данный элемент метаданных не является обязательным для задания отложенного удаления объекта, но полезен, если требуется найти все объекты, подпадающие под определенную политику отложенного удаления. Если этот элемент отсутствует или является пустой строкой, он не должен использоваться. | Опционально |
| cdmi_retention_period | Строка JSON | Если данный элемент метаданных присутствует и содержит корректный временной интервал в соответствии с ISO 8601:2004 (см. 5.14), он показывает, что клиент запрашивает отложенное удаление данного объекта (см. 17.3). Если этот элемент метаданных отсутствует, он не должен использоваться. Если значение этого элемента не является корректным временным интервалом по ISO 8601:2004, операции создания, изменения или десериализации должны возвращать отказ с кодом ошибки 400 Bad Request. Если данный элемент метаданных обновляется, и новое окончание интервала раньше текущего окончания интервала, операция изменения должна возвращать отказ с кодом ошибки HTTP 403 Forbidden. |
Опционально |
| cdmi_retention_autodelete | Строка JSON | Если данный элемент метаданных присутствует и установлен равным «true», он показывает, что клиент запрашивает, чтобы объект, для которого установлено отложенное удаление, был удален после завершения срока хранения. Если этот элемент отсутствует или не равен «true», он не должен использоваться. | Опционально |
| cdmi_hold_id | Массив JSON строк JSON | Если данный элемент метаданных присутствует и не является пустым массивом, он показывает, что клиент запрашивает удержание объекта (см. 17.4). Каждая строка массива должна содержать уникальный идентификатор удержания, установленный пользователем. Если этот элемент отсутствует или является пустым JSON массивом, он не должен использоваться. Если данный элемент изменяется, и ранее присутствующая строка удержания удаляется или изменяется в результате, операция создания изменения должна возвращать отказ с кодом ошибки 403 Forbidden. (см. 17.4 касаемо снятия удержания) |
Опционально |
| cdmi_encryption | Строка JSON | Если данный элемент метаданных присутствует и не является пустой строкой, он показывает, что клиент запрашивает фоновое шифрование объекта. Шифрование подразумевает шифрование всех данных и метаданных объекта. Соответствующие значения алгоритма/режима/длины ключа указываются в опции cdmi_encryption. Если этот элемент отсутствует, он не должен использоваться. Если данный элемент присутствует, но не содержит корректной спецификации шифрования, система может проигнорировать данный элемент метаданных, вернув код ошибки HTTP 400 Bad Request, либо самостоятельно выбрать алгоритм/режим/длина ключа. Поддерживаемые алгоритмы шифрования выражаются строкой в форме ALGORITHM_MODE_KEYLENGTH, где: «ALGORITHM» алгоритм шифрования (например, «AES» или «3DES»). «MODE» режим шифрования (например, «XTS», «CBC» или «CTR»). «KEYLENGTH» длина ключа в битах (например, «128», «192», «256»). Для улучшения совместимости различных реализаций CDMI следующие обозначения должны быть использованы для наиболее распространенных параметров шифрования: «3DES_ECB_168» алгоритм TripleDES с тремя ключами, режим электронной кодовой книги (Electronic Code Book, ECB), ключ 168 бит; «3DES_CBC_168» алгоритм TripleDES с тремя ключами, режим сцепления блоков шифртекста (Cipher Block Chaining, CBC), ключ 168 бит; «AES_CBC_128» алгоритм AES, режим CBC, ключ 128 бит; «AES_CBC_256» алгоритм AES, режим CBC, ключ 256 бит; «AES_XTS_128» алгоритм AES, режим XTS, ключ 128 бит; «AES_XTS_256» алгоритм AES, режим XTS, ключ 256 бит. |
Опционально |
| cdmi_value_hash | Строка JSON | Если данный элемент метаданных присутствует и не является пустой строкой, он показывает, что клиент запрашивает вычисление системой хэш-кода объекта с использованием указанного алгоритма и длиной хэш-кода. Результат должен быть помещен в элемент cdmi_hash метаданных системы хранения. Используемые значения алгоритма/длины хэш-кода указаны в опции cdmi_value_hash. Если этот элемент отсутствует, он не должен использоваться. Если данный элемент присутствует, но не содержит корректной спецификации алгоритма хэширования, система может проигнорировать данный элемент метаданных, вернуть код ошибки HTTP 400 Bad Request, либо самостоятельно выбрать алгоритм и размер хэш-кода. Поддерживаемые алгоритмы хэширования выражаются строкой в форме ALGORITHM LENGTH, где: «ALGORITHM» алгоритм хэширования (например, «SHA»). «LENGTH» размер хэш-кода в байтах (например, «160», «256»). Для улучшения совместимости различных реализаций CDMI следующие обозначения должны быть использованы для наиболее распространенных параметров хэширования: «SHA160» для SHA-1, «SHA256» для SHA-2. |
Опционально |
| cdmi_latency | Строка JSON | Если данный элемент метаданных присутствует и установлен равным строковому представлению положительного числа, он показывает, что клиент запрашивает желаемое максимальное время до первого байта, в миллисекундах. Этот элемент устанавливает желаемую задержку, измеренную от края облака, и не включает задержки между клиентом и облаком. Например, этот элемент может совместимым образом определять, какой тип хранилища следует использовать. Если этот элемент отсутствует или не равен положительному числу, он не должен использоваться. | Опционально |
| cdmi_throughput | Строка JSON | Если данный элемент метаданных присутствует и установлен равным строковому представлению положительного числа, он показывает, что клиент запрашивает желаемую максимальную скорость получения данных, в байтах в секунду. Этот элемент устанавливает желаемую скорость, измеренную от края облака, и не учитывает пропускную способность между клиентом и облаком. Например, этот элемент может совместимым образом определять, какой тип соединения следует использовать. Если этот элемент отсутствует или не равен положительному числу, он не должен использоваться. | Опционально |
| cdmi_sanitization_method | Строка JSON | Если данный элемент метаданных присутствует и не является пустой строкой, он показывает, что клиент запрашивает использование системой определенного метода очистки для удаления данных, обеспечивающего невосстановимость данных после операций обновления или удаления. Поддерживаемый метод очистки указан в опции cdmi_sanitization_method. Если этот элемент отсутствует, он не должен использоваться. Если данный элемент присутствует, но не содержит корректного определения метода очистки, система может проигнорировать данный элемент метаданных, вернуть код ошибки HTTP 400 Bad Request, либо самостоятельно определить метод очистки. Поддерживаемые методы очистки выражаются системозависимыми строками. |
Опционально |
| cdmi_RPO | Строка JSON | Если данный элемент метаданных присутствует и установлен равным строковому представлению положительного числа, он показывает, что клиент запрашивает наибольшую продолжительность между изменением или созданием объекта и моментом, когда объект может быть восстановлен. Этот элемент метаданных используется для указания на желаемую частоту резервного копирования из первичной копии или копий во вторичную копию или копии. Это максимально приемлемый временной промежуток перед отказом или неисправностью, во время которого изменение данных может быть потеряно из-за восстановления. Если этот элемент отсутствует или не равен положительному числу, он не должен использоваться. | Опционально |
| cdmi_RTO | Строка JSON | Если данный элемент метаданных присутствует и установлен равным строковому представлению положительного числа, он показывает, что клиент запрашивает максимально допустимое время восстановления данных, в секундах. Этот элемент данных используется для задания приемлемого времени восстановления первичной копии или копий из вторичной копии или копий. Если этот элемент отсутствует или не равен положительному числу, он не должен использоваться. | Опционально |
16.5. Поддержка метаданных, предоставленных системой данных
Для каждого элемента метаданных в системе данных имеется текущее значение, которое реализация может получить в данный момент (см. таблицу 118).
Метаданные, предоставляемые системой данных
| Имя элемента метаданных | Тип | Описание | Требование |
|---|---|---|---|
| cdmi_data_redundancy_provided | Строка JSON | Содержит текущее число полных копий объекта | Опционально |
| cdmi_immediate_redundancy_provided | Строка JSON | Если присутствует и равно «true», указывает, что для объекта поддерживается резервное копирование | Опционально |
| cdmi_infrastructure_redundancy_provided | Строка JSON | Содержит текущее количество независимых инфраструктур хранения, поддерживающих данные. | Опционально |
| cdmi_data_dispersion_provided | Строка JSON | Содержит минимальное расстояние (км) между любыми двумя инфраструктурами, хранящими данные | Опционально |
| cdmi_geographic_placement_provided | Массив JSON строк JSON | Содержит идентификатор ISO-3166, указывающий на геополитический регион, в котором хранится объект | Опционально |
| cdmi_retention_period_provided | Строка JSON | Содержит временной интервал в соответствии с ISO 8601:2004 (см. 5.14), указывающий интервал отложенного удаления объекта | Опционально |
| cdmi_retention_autodelete_provided | Строка JSON | Содержит «true», если объект будет автоматически удален после окончания периода отложенного удаления | Опционально |
| cdmi_hold_id_provided | Массив JSON строк JSON | Содержит определенный пользователем идентификатор удержания, действующего в текущий момент | Опционально |
| cdmi_encryption_provided | Строка JSON | Содержит алгоритм, использованный для шифрования, режим работы и длину ключа. (Формат cdmi_encryption см. в табл. 117) | Опционально |
| cdmi_value_hash_provided | Строка JSON | Содержит алгоритм и длину хэш-кода объекта | Опционально |
| cdmi_latency_provided | Строка JSON | Содержит максимальное время до первого байта | Опционально |
| cdmi_throughput_provided | Строка JSON | Содержит максимальную скорость получения данных | Опционально |
| cdmi_sanitization_method_provided | Строка JSON | Содержит использованный метод очистки | Опционально |
| cdmi_RPO_provided | Строка JSON | Содержит продолжительность, в секундах, между обновлением и временем, когда обновление может быть восстановлено | Опционально |
| cdmi_RTO_provided | Строка JSON | Содержит продолжительность восстановления данных, в секундах | Опционально |
17. Управление отложенным удалением и удержанием
17.1. Введение
Облачная система хранения может опционально поддерживать средства управления отложенным удалением объектов в системе облачного хранилища. Реализация системы отложенного удаления и удержания обозначается присутствием соответствующих общесистемных опций.
Управление отложенным удалением включает политику отложенного удаления, определение политики удержания объектов для специальных целей (например, судебного оспаривания) и определение влияния правил удаления объектов на отложенное удаление и удержание. Удаление объекта CDMITM не есть опция управления отложенным удалением как такового, но общесистемная опция. В данном разделе, тем не менее, описаны последствия применения политики удержания и отложенного удаления к объекту.
Управление отложенным удалением может применяться к следующим объектам:
17.2. Управление отложенным удалением
В CDMI управление отложенным удалением, удержанием и удалением оказывает влияние на всех клиентов CDMI клиент, создающих или удаляющих объекты CDMI, а также как система хранения управляет объектами с момента создания и до момента удаления.
Управление отложенным удалением CDMI состоит из трех управляющих элементов: отложенное удаление, удержание и удаление:
- отложенное удаление CDMI использует временные критерии для определения периода времени, в течение которого запрещено удаление соответствующего объекта. При этом не разрешается и изменение объекта, даже после истечения периода удержания, за исключением случаев, перечисленных ниже;
- удержание CDMI запрещает удаление или изменение объекта, пока не сняты все удерживающие блокировки;
- CDMI система не должна допускать удаление CDMI объекта пока не истечет время отложенного удаления или выполняется удержание. Любые попытки удаления объекта должны возвращать ошибку;
- после завершения отложенного удаления и снятия удержания эти механизмы не должны оказывать влияния на возможность удаления объекта;
- после начала периода отложенного удаления или наложения удержания, изменение данных или метаданных объекта не допускается, за исключением метаданных подсистем отложенного удаления и удержания. Метаданные системы отложенного удаления могут добавляться и изменяться, расширяя период отложенного удаления, а метаданные системы удержания могут модифицироваться для добавления новых удержаний. Другие попытки изменения объекта должны вызывать ошибку.
17.3. Отложенное удаление CDMI
Отложенное удаление CDMI позволяет применять в каждый момент времени лишь одну политику отложенного удаления к каждому объекту.
Управление отложенным удалением использует временной критерий для определения периода, когда удаление объекта из CDMI системы запрещено. Критерий отложенного удаления в системе CDMI обозначается следующими метаданными системы данных:
- идентификатор критерия отложенного удаления, строка, полученная от клиента CDMI и идентифицирующая класс записи о постоянном хранении (cdmi_retention_id);
- начало периода отложенного удаления и его продолжительность (cdmi_retention_period).
Если клиент CDMI пытается удалить объект, облачная система хранения должна проверить, выполняется ли критерий отложенного удаления, и вернуть ошибку в случае, если удаление невозможно.
При копировании объекта, к которому применена политика отложенного удаления, свойства, связанные с отложенным удалением, не должны переноситься от источника к создаваемому объекту, и копия не попадает под действие политики отложенного удаления.
На рисунке 10 показано, как установить отложенное удаление по времени с помощью идентификатора отложенного удаления.
продолжительность 730 дней, нет удержаний
Рисунок 10 — Отложенное удаление объекта
Определенный код ошибки HTTP (403) должен возвращаться при попытке изменить или удалить объект, находящийся на постоянном хранении.
Облачная система хранения не должна препятствовать изменениям метаданных, расширяющим период отложенного удаления.
17.4. Удержание CDMI
Удержание CDMI устанавливает доступ к объекту только для чтения и запрещает его удаление. Облачная система хранение должна допускать множественные удержания для одного и того же объекта.
Если объект удерживается, облачная система хранения устанавливает доступ к объекту только для чтения и запрещает его удаление.
При копировании удерживаемого объекта, его свойства, связанные с удержанием, не должны копироваться в новый объект, и копия объекта на должна удерживаться.
Управление удержанием использует идентификатор удержания для определения периодов времени, в которые объект CDMI и его метаданные не могут быть изменены или удалены. Критерии удержания CDMI объекта должны указываться метаданными системы данных, в частности, предоставленным клиентом строковыми идентификаторами, которые определяют удержания и их порядок.
Клиент CDMI может поместить объект в удержание добавлением соответствующего идентификатора в элемент метаданных системы данных cdmi_hold_id. Когда объект удерживается, операции клиента CDMI, связанные с изменением объекта (успешные в обычном состоянии объекта) должны возвращать ошибку.
На рисунке 11 показано, как установка удержания на объект влияет на доступ к нему для изменения или удаления.
Рисунок 11 — Удержание объекта
На рисунке 12 показано совместное действие идентификаторов удержания и отложенного удаления. Значение метаданных системы данных не должно изменяться в период отложенного удаления; метаданные для идентификаторов удержания не запрещают удаление удержания.
Удаление удержания находится за рамками настоящего стандарта.
Пример: Отложенное удаление с 2010/04/28 на 730 дней; установлено удержание
Рисунок 12 — Удержание объекта при постоянном хранении
На рисунке 13 показано, как установка нескольких удержаний на объект влияет на доступ к нему для изменения или удаления.
Пример: Объект создан 2010/04/28. Удержание № 1 наложено 2011/01/01 и снято 2013/01/01. Удержание № 2 наложено 2012/03/01 и снято 2014/01/01.
Рисунок 13 — Объект с множественными удержаниями
Облачная система хранения должна поддерживать возможность чтения удерживаемого объекта, но запрещать его удаление, как явное, так и автоматическое.
Клиенты CDMI должны допускать отказы операций из-за удержания или изменение его состояния.
Отмена удержания находится за рамками настоящего стандарта и обычно производится при помощи отдельного механизма, определяемого реализацией.
Определенный код ошибки HTTP (403) должен возвращаться при попытке изменить или удалить объект, находящийся в состоянии удержания. Для приложений это должно означать ошибку.
17.5. Автоудаление CDMI
Удаление CDMI управляет облачным хранилищем в аспектах, касающихся удаления объектов. Облачная система хранения может автоматически удалить объект, как только для него исчезли блокирующие условия удержания или отложенного удаления (см. cdmi_retention_autodelete в таблице 117.)
Объекты CDMI должны автоматически удаляться системой после окончания времени отложенного удаления, если соответствующим образом установлен флаг cdmi_retention_autodelete. Этот флаг показывает системе, что доступ к объекту будет невозможен после выполнения критерия отложенного удаления.
Система должна обеспечить, что объект не доступен более через CDMI интерфейс. Если критерий отложенного удаления выполнен, но объект находится в состоянии удержания, система не должна прекращать доступ к объекту или удалять его. Если к объекту одновременно применяются отложенное удаление и удержание, обе блокировки должны быть сняты для автоматического удаления объекта.
17.6. Замечания о безопасности отложенного удаления
Точность и целостность значений начала отложенного удаления и его продолжительность зависят от точности и целостности таймера, использованного для их установки. Одинаково важны относительная точность и безопасность таймера, который определяет, закончился ли период отложенного удаления и часов, использованных для установки начала хранения. Относительная разница во времени между этими часами может привести к нежелательному поведению подсистем отложенного удаления и удаления.
Важно устанавливать системные часы по надежному источнику. Время слоя 1 непосредственно устанавливается по стандартным часам и находится на вершине иерархии серверов времени. Относительная разница времени между стандартными и системными часами и эталонными часами может приводить к нежелательному отметкам времени отложенного удаления и проблемам в обработке событий таймера.
Пример - Объект создан в облачном хранилище в момент времени 0 с периодом хранения 8 лет и включенным автоматическим удалением. В момент времени 1 год системные часы переведены вперед на 9 лет. Теперь, несмотря на то, что фактическое время существования объекта равно 1 году, он будет удален, так как выполнен соответствующий критерий.
Спецификация точности и целостности хранения времени находится за рамками настоящего стандарта. Тем не менее, необходимо отметить важность этих моментов для обеспечения правильности поведения системы.
18. Спецификация условий запросов
18.1. Введение
CDMITM предоставляет стандартизованный механизм для определения наборов объектов, обладающих определенными свойствами. Этот механизм известен как спецификация условий запросов (scope) CDMI. Спецификации условий запросов обычно используются для предоставления клиенту CDMI возможности определения интересующей группы объектов.
Каждый объект JSON в рамках спецификации условий запросов представляет набор условий, которые должны быть все истинными, чтобы объект считался соответствующим запросу (логическое отношение И). В случае запроса (query) соответствующий объект должен быть возвращен в результате запроса. Пустая спецификация условия должна рассматриваться как истинная. Для выражения логического отношения ИЛИ используются несколько объектов JSON; в этом случае объект, для которого хотя бы один из объектов JSON истинный, считается удовлетворяющим условию запроса.
Каждый объект JSON строится по тем же структурным принципам, что и объект CDMI. Для иллюстрации этой структуры рассмотрим результат запроса CDMI GET к объекту данных:
Content-Type: application/cdmi-object
X-CDMI-Specification-Version: 1.0.2
«objectType» : «application/cdmi-object»,
«objectID» : «00007E7F0010EB9092B29F6CD6AD6824»,
«objectName» : «MyDataObject.txt»,
«parentURI» : «/MyContainer/»,
«parentID» : «00007E7F00102E230ED82694DAA975D2»,
«domainURI» : «/cdmi_domains/MyDomain/»,
«capabilitiesURI» : «/cdmi_capabilities/dataobject/»,
«completionStatus» : «Complete»,
«valuerange» : «0-108262», «value» : «...»
18.2. Примеры
Каждое поле в объекте JSON спецификации условия запроса отражает условие, которое должно выполняться для соответствующего поля объекта.
1 Запрос на поиск всех объектов, принадлежащих домену /cdmi_domains/MyDomain/, структурирован следующим образом:
| [ { «domainURI» : «== /cdmi_domains/MyDomain/» } ] |
|---|
2 Для запроса всех объектов, принадлежащих домену /cdmi_domains/MyDomain/ И находящихся в контейнере MyContainer, спецификация условия запроса такова:
| [ { «parentURI» : «== /MyContainer/», «domainURI» : «== /cdmi_domains/MyDomain/» } ] |
|---|
3 Для запроса всех объектов, принадлежащих домену MyDomain ИЛИ находящихся в контейнере MyContainer, структура такова:
| [ { «parentURI» : «== /MyContainer/», }, { «domainURI» : «== /cdmi_domains/MyDomain/» } ] |
|---|
Запросы могут относиться к любым полям, возвращаемым в результате запроса GET системой облачного хранения данных.
4 Для запроса элементов метаданных, объект metadata включается в запрос, например -
Этот подход позволяет устанавливать соответствие с использованием произвольно вложенных структур метаданных.
Для запроса значения объекта, в запрос включается поле value. В запросах значения всегда представляются с использованием кодировки base 64.
Запрос на значение объекта опционален и обозначается присутствием опции cdmi_query_value.
18.3. Выражения для запросов
В таблице 119 приведены выражения для запросов.
Все поля объектов, которые не включены в спецификацию условий запроса, должны быть игнорированы при поисковом запросе.
Если в качестве константы для операторов равенства или неравенства для полей parentURI, domainURI и capabilitiesURI используется URI, возможно указывать URI по пути или по ID объекта, эти способы взаимозаменяемы.
1 В запросе на принадлежность объекта некоторому домену два типа запросов считаются эквивалентными:
«domainURI» : «== /cdmi_domains/MyDomain/»
«domainURI» : «== /cdmi_objectid/00007E7F001074C86AD256DA5C67180D/»
2 Аналогично, запрос на поиск объектов с заданным родительским контейнером может иметь две формы:
«parentURI» : «== /MyContainer/»
«parentURI» : «== /cdmi_objectid/0000706D0010B84FAD185C425D8B537E/»
Если в поисковом запросе используется ID объекта (поля objectID или parentID), ID объектов должны обрабатываться как регистронезависимые.
19. Спецификация результатов
19.1. Введение
CDMITM предоставляет стандартизованный механизм определения подмножеств содержимого объектов. Этот механизм известен как спецификация результатов CDMI. Спецификации результатов обычно используются для предоставления клиенту CDMI возможность определить, с каким подмножеством содержимого объекта CDMI он будет работать.
Каждый объект JSON в спецификации результатов представляется набором полей, которые возвращаются для каждого подходящего объекта.
Объект JSON результатов должен строиться аналогично структуре объектов CDMI. Для иллюстрации рассмотрим следующий результат запроса GET к объекту CDMI:
Content-Type: application/cdmi-object
X-CDMI-Specification-Version: 1.0.2
«objectType» : «application/cdmi-object»,
«objectID» : «00007E7F0010EB9092B29F6CD6AD6824»,
«objectName» : «MyDataObject.txt»,
«parentURI» : «/MyContainer/»,
«parentID» : «00007E7F00102E230ED82694DAA975D2»,
«domainURI» : «/cdmi_domains/MyDomain/»,
19.2. Примеры
Каждое поле JSON объекта спецификации результатов указывает, какое поле должно включаться в результат.
1 Данная спецификация результатов требует, чтобы в результате были возвращены поля метаданных objectID и cdmi_size:
2 Если объект подходит под запрос, результат ставится в очередь как:
«objectID» : «00007E7F0010EB9092B29F6CD6AD6824»,
Чаще всего клиент запрашивает в спецификации cdmi_results_specification либо objectID, либо objectName и parentURI, либо все три поля. Если запрашивается parentURI или objectName, это поле должно быть возвращено только для объектов, расположенных в контейнере.
3 Для запроса всех элементов метаданных каждого подходящего под запрос объекта, следует использовать такую спецификацию cdmi_results_specification:
«cdmi_results_specification» : {
4 Для запроса всех полей и всех элементов метаданных каждого подходящего под запрос объекта, следует использовать такую спецификацию cdmi_results_specification:
«cdmi_results_specification» : «»
Значение поля всегда возвращается в кодировке base 64, если включено в результат запроса. При этом поле valuetransferencoding указывает на ожидаемую кодировку, если запрос GET выполняется для чтения объекта.
20. Ведение журналов событий
20.1. Обзор
Ведение журналов событий в системе CDMITM делится на три функциональные области, различающиеся уровнем детализации. Они включают:
CDMI не определяет формат сообщений журналов событий. Предполагается, что это станет предметов стандартов ведения журналов событий в будущем.
Клиенты CDMI получить доступ к данным журналов событий посредством создания очереди журналов событий, которая определяет содержание сообщений о событиях, которые необходимо получить (см. 20.5). Если пользователь имеет достаточный уровень разрешений для создания очереди журнала событий, все сообщения журнала, на которые он подписан, будут ставиться в эту очередь, которая затем может быть доступна для обработки или архивного хранения.
Если определены несколько очередей журнала событий, каждая очередь получит запись о соответствующем событии. Если нет очередей, которые подписаны на то или иное событие или класс сообщений, такие сообщения могут не создаваться облачной системой хранения.
20.2. Ведение журналов событий объекта
Если ведение журналов событий поддерживается облачной системой хранения, все операции, производимые над объектами CDMI (объекты данных, контейнеры, домены, очереди и опции), должны быть сохранены во все определенные очереди журналов событий.
Сообщения журнала событий должны содержать минимум приведенной ниже информации в формате, определенном реализацией:
- время в формате ISO-8601 (см. 5.14);
- домен, в котором была выполнена операция;
- выполненная операция;
- URI объекта, над которым была проведена операция;
- информация о принципале, от имени которого была проведена операция;
- результат операции.
Операции, сохраненные в журнале событий, должны включать операции, проведенные экспортированной файловой системой.
20.3. Ведение журналов событий безопасности
Все события, связанные с безопасностью, включая установку сессии, аутентификацию и авторизацию, модификации доменов и делегирования, должны быть записаны в журналы событий безопасности. Ведение журналов событий безопасности включает управление пользователями и доменами, события, связанные с разрешениями (например, валидация списка отзыва сертификатов), и должно включать операции за пределами системы, влияющие на безопасность облачного хранилища (то есть изменения свойств безопасности домена CDMI через графический интерфейс администратора).
Если облачная система хранения поддерживает очереди типа cdmi_logging_queue и класс cdmi_logging_class из cdmi_security_logging (см. 20.5), это означает, что система поддерживает ведение журнала событий аудита. В свою очередь, общесистемная опция cdmi_security_audit (см. таблицу 101 в 12.1.3) должна быть установлена в «true». В противном случае cdmi_security_audit не должна присутствовать.
20.4. Ведение журналов событий управления данными
В дополнение к записи сообщений, относящихся непосредственно к изменению метаданных системы данных, в журнал событий должны включать все условия, при которых могут изменяться метаданные системы данных для объектов. Например, если клиент изменяет количество необходимых копий объекта, должно инициироваться событие, приводящее к появлению соответствующей записи в журнале событий. Аналогично, изменение системой текущего количества копий объекта также должно быть отражено в журнале событий.
Данный тип журналов событий также должен включать сообщения об удержаниях и отложенном удалении объектов.
20.5. Очереди журналов событий
Очереди журналов событий позволяют клиентам CDMI получать подробную информацию о событиях, связанных с работой системы облачного хранения. Так как данные в очереди являются хранимыми (persistent), от клиента не требуется поддерживать сессию. Если разные клиенты используют различные очереди журналов событий, каждый клиент действует независимо (например, анализирующее приложение получает информацию о действиях в определенном домене или над группой объектов с использованием специально сконфигурированной очереди).
Очереди журналов событий отличаются от очередей уведомлений (см. раздел 21) тем, что в первом случае предоставляется значительно более подробная информация, и ведение таких очередей ограничено небольшим подмножеством привилегированных клиентов.
Когда клиент запрашивает информацию журналов событий, он может вначале проверить, способна ли система предоставить такую информацию. Для этого необходимо проверить наличие опции cdmi_logging среди опций корневого контейнера. Если данная опция отсутствует, очередь журналов событий будет создана, но записи в нее добавляться не будут.
При создании очереди журналов событий должны быть предоставлены метаданные, описанные в таблице 120. Попытки изменения элементов метаданных, приведенных в этой таблице, должно возвращать ошибку HTTP 403 Forbidden. После создания очереди журналов событий, метаданные, приведенные в таблице, не могут быть изменены, за исключением cdmi_queue_type; последний элемент может быть только удален, показывая системе, что очередь журнала событий больше не будет принимать сообщения журнала и должна обрабатываться как обычный объект-очередь CDMI.
Необходимые метаданные для очереди журнала событий
| Имя метаданных | Тип | Описание | Требование |
|---|---|---|---|
| cdmi_queue_type | Строка JSON | Тип очереди показывает, как облачная система хранения должна обрабатывать объект-очередь. Для очереди журнала событий определен тип cdmi_logging_queue. | Обязательно |
| cdmi_logging_class | Массив JSON строк JSON | Содержит массив JSON, показывающий, сообщения каких журналов событий должны помещаться в очередь. Допустимые значения: - cdmi_object_logging — Получение сообщений об операциях с объектами; - cdmi_datasystem_logging — Получение сообщений об изменении метаданных системы данных; - cdmi_security_logging — Получение сообщений о событиях безопасности. Клиенты могут включать желаемые классы сообщений о событиях в массив cdmi_logging_class. Если необходимо получать сообщения всех типов, следует указать пустой массив JSON. |
Обязательно |
| cdmi_scope_specification | Массив JSON объектов JSON | Спецификация задачи условий запроса определяет набор объектов, сообщения о событиях для которых помещаются в очередь. Если необходим сбор журналов событий, относящихся ко всем объектам, следует использовать пустой JSON массив. Для ведения журналов событий безопасности, спецификация задачи игнорируется. Описание построения спецификации цели описано в разделе 18. | Обязательно |
1 Пример метаданных, связанных с очередью журналов событий:
Когда сообщения журнала извлекаются из очереди, содержимое каждого значения в очереди должно содержать объект JSON и иметь тип MIME «application/json». Этот объект JSON содержит одну или более строку/объект JSON, каждая из которых соответствует одному сообщению журнала.
Сообщения включаются в очереди журналов событий, только если пользователь, создавший очередь, имеет права доступа к объекту, с которым связано сообщение о событии (т.е., пользователь обладает подходящей записью ACE из 16.1.5).
2 Если очередь журналов событий была создана администратором, то все подходящие объекты, без ограничений, включаются в результат. Если очередь журналов событий создана пользователем «jdoe», то в результат будут включены лишь сообщения о событиях, относящиеся к объектам, к которым «jdoe» имеет доступ.
В таблице 121 приведены метаданные, созданные системой и дающие подробную информацию об очереди журналов событий.
Метаданные статуса ведения журналов событий
20.6. Замечания о безопасности при ведении журналов событий
Точность и целостность временных меток элементов журнала зависят от точности и целостности часов, использующихся для их установки. Точные временные метки важны для разрешения проблем, экспертного анализа распределенных атак, разрешения споров и доказательства транзакций, чувствительных к времени. В частности, устранение ошибок, безопасность, учет и аутентификация основываются на корреляции событий (т.е., точном знании порядка событий), и эти соображения безопасности зависят от хорошей синхронизации времени.
Спецификация точности и целостности временных меток находится за рамками настоящего стандарта; тем не менее, для демонстрации надежности временных меток их следует приводить к стандартному времени, и необходимо показать, что системное время не может быть произвольным образом изменено.
21. Очереди уведомлений
Облачная система хранения может опционально реализовывать функциональность уведомлений. Наличие этой функциональности обозначается присутствием соответствующих общесистемных опций и предполагает поддержку очередей CDMITM.
Очереди уведомлений позволяют CDMI клиентам эффективно обнаруживать, какие изменения происходят в системе. Так как очередь уведомлений является хранимой (persistent), не требуется, чтобы клиент постоянно поддерживал сессию. Если разными клиентами используются различные очереди уведомлений, каждый клиент действует независимо от остальных (например, приложение для управления хранением может использовать очередь уведомлений для поддержания своей базы данных без необходимости проводить полное сканирование контейнера для определения, какие объекты данных были добавлены, изменены или удалены).
Если клиент запрашивает получение уведомлений, в первую очередь он может проверить, способна ли система генерировать такие уведомления (проверка наличия опции cdmi_notification среди опций корневого контейнера). Если эта опция отсутствует, создание очереди уведомлений будет успешным, но никакие уведомления не будут добавляться в эту очередь.
Для создания очереди уведомлений клиент создает обычную очередь CDMI и добавляет метаданные, указывающие системе хранения, что данная очередь должна обрабатываться как очередь уведомлений. Эти метаданные также показывают системе, какие типы уведомлений должны генерироваться, и какая информация должна включаться в каждое уведомление.
После создания очереди уведомлений последующие подходящие события должны приводить к возникновению соответствующих уведомлений и добавлению их в очередь. Стандарт CDMI не требует специального упорядочения уведомлений, и клиент должен быть способен обрабатывать уведомления, поступившие вне очереди.
При создании очереди уведомлений необходимо предоставить метаданные, указанные в таблице 122. Попытки изменения метаданных, указанных в этой таблице, должны приводить к ошибке HTTP 403 Forbidden. После создания очереди уведомлений, элементы этих метаданных не должны меняться, за исключением cdmi_queue_type; последний элемент может быть только удален, показывая системе, что очередь уведомлений теперь не должна принимать уведомления и должна обрабатываться как обычная очередь CDMI.
| Имя метаданных | Тип | Описание | Требование |
|---|---|---|---|
| cdmi_queue_type | Строка JSON | Тип очереди определяет, как облачная система хранения обрабатывает объект-очередь. Для очереди уведомлений определен тип cdmi_notification_queue. | Обязательно |
| cdmi_notification_events | Массив JSON строк JSON | Содержит массив JSON, определяющий, какие события вызывают уведомления. Определены следующие значения: - cdmi_create_processing — Уведомление генерируется когда новый объект находится в процессе создания. - cdmi_create_complete — Уведомление генерируется, когда создан новый объект или когда состояние создаваемого объекта меняется из «Processing» в «Complete». - cdmi_read — Уведомление генерируется при чтении объекта. - cdmi_modify_processing — Уведомление генерируется при существующий объект, когда находится в процессе изменения. - cdmi_modify_complete — Уведомление генерируется, когда существующий объект был изменен или когда состояние изменяемого объекта меняется из «Processing» в «Complete». - cdmi_rename — Уведомление генерируется, когда объект переименован в ходе операции перемещения. - cdmi_copy — Уведомление генерируется, когда новый объект создан в результате копирования. - cdmi_reference — Уведомление генерируется при создании ссылки. - cdmi_delete — Уведомление генерируется при удалении объекта. - cdmi_export — Уведомление генерируется при экспорте контейнера. - cdmi_snapshot — Уведомление создается при создании снимка состояния контейнера. <события, зависящие от реализации> Клиенты могут включать необходимые типы событий в массив cdmi_notification_events. Если требуются уведомления всех типов, следует указать пустой массив JSON. |
Обязательно |
| cdmi_scope_specification | Массив JSON объектов JSON | Спецификация условий запроса определяет набор объектов, операции над которыми генерируют уведомления. Если уведомления требуются при операции над всеми объектами, следует указать пустой массив JSON. Создание спецификации условий запроса описано в разделе 18. |
Обязательно |
| cdmi_results_specification | Объект JSON | Содержит поля JSON, которые должны быть возвращены для каждого объекта, подходящего под спецификацию условий запроса. Создание спецификации результата описано в разделе 19. Дополнительно к полям, определенным в разделе 19, для уведомлений определены следующие поля: - cdmi_event — Указывает на событие, вызвавшее уведомление, в соответствии с полем cdmi_notification_events; - cdmi_event_result — Указывает на статус события, вызвавшего уведомление. Статус совпадает с возвращаемым статусом HTTP, т.е., 200 OK, 404 Not Found, и т.д.; - cdmi_event_time — Указывает время события, вызвавшего уведомление, в формате ISO-8601 (см. 5.14 и ISO 8601:2004); - cdmi_event_user — Указывает имя пользователя (имя ACL), который вызвал событие, сгенерировавшее уведомление. Если событие вызвано системой, это поле должно быть пустой строкой. |
Обязательно |
Пример - Метаданные, связанные с очередью уведомлений:
«cdmi_scope_specification» : [
«domainURI» : «== /cdmi_domains/MyDomain/»,
Если результаты уведомления хранятся в очереди уведомлений, каждый элемент очереди должен быть объектом JSON типа MIME «application/json». Этот объект JSON содержит значения, запрошенные согласно полю метаданных cdmi_results_specification очереди уведомлений.
Пример - JSON результата уведомления:
«cdmi_event_result» : «200 OK»,
«cdmi_event_time» : «2010-11-15T13:12:52.342324Z»,
«objectID» : «00007E7F0010EB9092B29F6CD6AD6824»,
Объекты должны включаться в уведомление лишь только если пользователь, создавший очередь уведомлений, обладает правами на чтение соответствующего объекта.
Если очередь уведомлений была создана администратором, то все подходящие объекты, без ограничений, включаются в результат. Если очередь уведомлений создана пользователем «jdoe», то в результат будут включены лишь уведомления-логи, относящиеся к объектам, к которым «jdoe» имеет доступ.
В таблице 123 приведены метаданные, созданные системой, показывающие подробности состояния очереди уведомлений.
Метаданные состояния уведомлений
22. Очереди запросов
22.1. Обзор
Облачная система хранения может опционально реализовывать функциональность запросов метаданных и/или полнотекстовых запросов. Наличие этой функциональности обозначается присутствием соответствующих общесистемных опций и предполагает поддержку очередей CDMITM.
Очереди запросов позволяют клиентам CDMI эффективно обнаруживать, какое содержимое соответствует заданным условиям поиска по метаданным или полному тексту. Клиенты создают или обновляют очередь запросов, указывая метаданные, которые определяют критерии соответствия (условия запросов), а также указывая результаты, которые должны быть возвращены для подходящих объектов (результат запроса). Реализация CDMI должна затем провести поиск по имеющемуся содержимому и сохранить результат поиска в очереди запросов. После нахождения результатов запроса, они добавляются в очередь, а когда поиск завершен, элемент метаданных cdmi_query_status очереди изменяется, чтобы указать на завершение поиска. Подходящие объекты, созданные или измененные за время отработки поискового запроса, могут включаться или не включаться в результат (например, как следствие связности в конечном итоге).
Если клиент запрашивает поиск по запросу, в первую очередь он должен проверить, способна ли система выполнять такой поиск (проверка наличия опции cdmi_query среди опций корневого контейнера). Если эта опция отсутствует, создание очереди запросов будет успешным, но никакие результаты не будут попадать в эту очередь.
При создании очереди сообщений необходимо предоставить метаданные, указанные в таблице 124. Попытки изменения метаданных, указанных в этой таблице, должны приводить к ошибке HTTP 403 Forbidden. После создания очереди сообщений элементы этих метаданных не должны меняться, за исключением cdmi_queue_type. Если значение cdmi_queue_type изменяется с «cdmi_query_queue», это изменение указывает системе, что обрабатывающийся поисковый запрос должен быть остановлен, очередь запросов более не принимает результатов запросов, и должна обрабатываться как обычный объект-очередь CDMI. Для начала нового поиска с использованием существующей очереди, значение cdmi_queue_type должно быть изменено обратно на «cdmi_query_queue». Настоящий стандарт не определяет механизма приостановки выполняющегося поиска и возобновления остановленного поиска.
Необходимые метаданные для очереди запросов
| Имя метаданных | Тип | Описание | Требование |
|---|---|---|---|
| cdmi_queue_type | Строка JSON | Показывает, как облачная система хранения должна обрабатывать очередь. Для очереди запросов определен тип cdmi_query_queue. | Обязательно |
| cdmi_scope_specification | Массив JSON объектов JSON | Спецификация условий запроса определяет, какие объекты включаются в результат запроса. Это эквивалентно оператору «WHERE» в языках типа SQL. Для запроса по всем объектам, следует указать пустой массив JSON. Конструирование спецификации условий запроса описано в гл. 18. | Обязательно |
| cdmi_results_specification | Объект JSON | Содержит JSON поля, которые должны быть возвращены для каждого объекта, подходящего под запрос. Это эквивалент оператора «SELECT» в языках типа SQL. Конструирование спецификации результатов описано в разделе 19. | Обязательно |
Пример - Метаданные, связанные с очередью запросов:
«cdmi_queue_type» : «cdmi_query_queue»,
«cdmi_scope_specification» : [
«domainURI» : «== /cdmi_domains/МуDomain/»,
«parentURI» : «starts /sandbox»,
«cdmi_results_specification» : {
Если результат хранится в очереди запросов, каждый элемент очереди должен быть объектом JSON типа MIME «application/json». Этот объект JSON содержит запрошенные значения согласно метаданным очереди запросов cdmi_results_specification.
Пример - Объект JSON с результатом запроса:
«objectID» : «00007E7F0010EB9092B29F6CD6AD6824»,
В таблице 125 приведены созданные системой метаданные, детально описывающие статус очереди запросов.
Объекты должны включаться в результат запроса, только если пользователь, создавший очередь запросов, обладает правами на чтение соответствующего объекта. Если очередь запросов была создана администратором, то все подходящие объекты, без ограничений, включаются в результат. Если очередь запросов создана пользователем «jdoe», то в результат будут включены лишь объекты, к которым «jdoe» имеет доступ.
22.2. Расширение запроса CDMI
Разработчик сервера CDMI может расширить запросы CDMI добавлением специальных выражений-проверок. Если разработчик добавляет в реализацию специальные элементы метаданных, эти поля также могут обрабатываться поисковым запросом с использованием базовой функциональности.
Разработчик сервера CDMI может расширить запросы CDMI, разрешив создавать специальные очереди запросов, отличающиеся по типу от cdmi_query_queue.
Во многих реализациях CDMITM протокол передачи гипертекста (Hypertext Transfer Protocol, HTTP) служит для передачи CDMI сообщений. В данном приложении описаны детали, связанные с обеспечением безопасности этого транспортного протокола.
A.2 Общие требования к реализациям HTTP
Требования безопасности к реализациям HTTP относятся и к клиентам, и к серверам CDMI. Клиент CDMI должен соответствовать требованиям безопасности, которые накладывает на клиентов использование HTTP. Следующие общие требования обеспечивают безопасность передачи при использовании HTTP:
- необходима реализация либо базовой аутентификации HTTP, либо дайджест-аутентификации HTTP;
- пользовательские идентификаторы и права доступа (пароли) должны использовать базовую аутентификацию HTTP ТОЛЬКО в сочетании с безопасностью транспортного уровня (Transport Layer Security, TLS);
- пользовательские идентификаторы и права доступа, использованные в одном из типов аутентификации HTTP (т.е., базовой или дайджест) никогда не должны затем использоваться с другим типом аутентификации HTTP. Чтобы не снижать целостность более сильной системы защиты, одни и те же пароли не должны использоваться в системах защиты разной силы;
- в CDMI следует использовать по меньшей мере TLS 1.0, а использование более новых версий TLS (например, v1.1 и v1.2) очень желательно. Использование TLS в системах CDMI опционально, но должно использоваться для защиты критических данных;
- хотя HTTP должен быть реализован всеми сущностями CDMI, его использование опционально.
Реализация использования HTTP над TLS (HTTPS) опциональна. К таким реализациям предъявляются следующие требования:
- Для обеспечения минимального уровня безопасности и совместимости различных реализаций следует поддерживать следующие системы шифрования:
- TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (обязательно для TLS 1.0),
- TLS_RSA_WITH_AES_128_CBC_SHA (обязательно для TLS 1.1/1.2), и
- TLS_RSA_WITH_NULL_SHA (для TLS без шифрования).
Примечание - Разработчики могут использовать дополнительные системы шифрования, но для них нет гарантии совместимости различных реализаций;
- Для связи клиентов и серверов необходимо использовать совместимый подход к безопасности. Правильно конфигурированные клиент и сервер не смогут сообщаться, если один из них использует порт 80, а другой — порт 443. Клиенты, которые не могут подключиться к CDMI серверу по протоколу HTTPS по порту TCP 443, должны воспользоваться HTTP портом 80, если это допускается их политикой безопасности;
- серверы могут ускорять поиск клиентом безопасного канала, отвечая контактам HTTP на TCP порт 80 статусом HTTP REDIRECT на подходящий HTTPS: URI (HTTP над TLS на порт TCP 443), чтобы избежать задержки после запроса клиентом по HTTP. В такой ситуации клиенты должны вести себя в соответствии с указанной переадресацией;
- все сертификаты, включая корневые сертификаты CA, используемые клиентом для проверки сертификата, должны быть заменяемыми;
- должны быть поддержка сертификатов в кодировках DER X.509, base 64 X.509 и формате PKCS#12;
- списки отозванных сертификатов (Certificate Revocation Lists) должны поддерживаться в форматах кодировок DER X.509 и base 64 X.509.
Примечание - Так как в области безопасности нет абсолютных правил, если указанные версии оказываются уязвимыми или некорректными, реализации CDMI как можно скорее должны переключиться на использование обновленной версии TLS и более сильное шифрование.
HTTP является обязательным механизмом передачи в данной версии CDMI. Важно отметить, что HTTP сам по себе не предоставляет никакой конфиденциальности или защиты целостности.
Клиенты CDMI сами обеспечивают аутентификацию пользователей на каждом сервере CDMI, к которому требуется доступ. Сервер CDMI действует как аутентификатор и получает права доступа пользователя через операции аутентификации HTTP.
IETF RFC 2616 и IETF RFC 2617 определяют требования к аутентификации HTTP, которая обычно начинается запросом HTTP от клиента, например,
Клиент HTTP должен затем ответить с использованием подходящей строки заголовка Authorization в следующем запросе. Формат строк заголовка WWW-Authenticate и Authorization зависит от типа необходимой аутентификации (базовой или дайджест). Если аутентификация пройдена успешно, HTTP сервер возвращает код 200 OK.
Базовая аутентификация включает отсылку имени пользователя и пароля в открытом виде, и должна поэтому использоваться только в защищенной сети или в сочетании с механизмом, обеспечивающим конфиденциальность, например, TLS (см. A.4). Дайджест-аутентификация отсылает безопасный хеш пользовательского имени и пароля (и другой необходимой информации, включая контрольное слово), так что пароль не показывается. Ответ 401 Unauthorized не должен включать выбор аутентификации.
Аутентификация клиента на сервере CDMI основана на сервисе аутентификации (локальном и/или внешнем). Могут поддерживаться различные схемы аутентификации, включая узловые, Kerberos, PKI и другие, рассмотрение сервисов аутентификации находится за рамками настоящего стандарта.
CDMI может также включать механизм для обеспечения безопасности передачи данных по HTTP, когда данные, пересылаемые между сервером и клиентом предварительно шифруются. Эта безопасность достигается передачей HTTP поверх TLS (т.е. HTTPS); URI безопасного соединения начинается с https:// вместо http://. Важно, что клиент CDMI взаимодействует с сервером CDMI по HTTPS через порт TCP 443 (порт TCP 80 используется для HTTP). Приложение A.5 описывает важные детали, связанные с TLS.
Если TLS используется для обеспечения безопасности HTTP, клиент и сервер обычно проводят аутентификацию объектов. Особенности этой процедуры зависят от использованной системы шифрования, которая указывает на алгоритм шифрования и алгоритм построения дайджеста для использования при TLS соединении. В широко распространенном сценарии в качестве основы однонаправленной аутентификации объекта используются сертификаты на стороне сервера, которым клиент доверяет. Допускается как отсутствие аутентификация (например, анонимная аутентификация), так и наоборот, может требоваться взаимная аутентификация клиента и сервера.
A.5 Безопасность уровня транспорта (TLS)
Серверы CDMI должны реализовать протокол TLS; однако, его использование клиентами опционально. TLS 1.0 должен быть реализован согласно RFC 2246, TLS 1.1 описан в RFC 4346, а TLS 1.2 — в RFC 5246.
Первичная задача протокола TLS — предоставить защиту информации и целостность данных при взаимодействии двух приложений. TLS позволяет клиент-серверным приложениям осуществлять обмен данными, избегая перехвата данных, несанкционированного вмешательства или подделки сообщений. TLS располагается поверх надежного протокола транспортного уровня (например, TCP) и используется для передачи сообщений различных протоколов более высокого уровня (например, HTTP).
TLS предоставляет аутентификацию оконечных точек и безопасный обмен данными в сети посредством использования криптографии. Обычно лишь сервер проходит аутентификацию, а клиент нет; таким образом, конечный пользователь (человек или приложение) уверен в том, с чем установлено соединение. Взаимная аутентификация требует, с малочисленными исключениями, предоставления клиентом цифрового сертификата.
TLS включает три основные фазы:
- согласование сторонами поддерживаемого алгоритма;
- обмен ключами и аутентификация;
- симметричное шифрование и аутентификация сообщений.
Во время первой фазы клиент и сервер обмениваются сведениями о поддерживаемых криптосистемах (см. A.5.1), определяя, какой шифр должен быть использован, схемы обмена ключами и алгоритмы аутентификации, а также алгоритмы аутентификации сообщений (MAC). Обмен ключами и аутентификация, как правило, представлены алгоритмами шифрования открытым ключом. MAC конструируются из алгоритмов криптографических хэш-функций.
TLS объединяет алгоритмы создание ключа, конфиденциальности, подписи и хэширования в криптосистему. Каждой криптосистеме ставится в соответствие 16-битное число, индекс криптосистемы.
Пример - Согласование ключей RSA, RSA подпись, конфиденциальность посредством Advanced Encryption Standard (AES) в режиме Cipher Block Chaining (CBC), и алгоритм хэширования Secure Hash Algorithm (SHA-1) соответствуют в TLS шестнадцатеричному числу {0x000F}.
TLS сессия всегда начинается клиентом, который начинает обмен пакетами шифрования, отсылая сообщение установления соединения, содержащее набор поддерживаемых криптосистем (в виде их индексов). Сервер отвечает сообщением, содержащим индекс криптосистемы, выбранной из списка клиента, или строкой «abort» как описано ниже. Хотя клиент должен упорядочить список по увеличению «силы» криптосистемы, сервер может выбрать ЛЮБУЮ из предложенных клиентом криптосистем. Таким образом, НЕ гарантируется, что при таком обмене будет выбрана самая надежная криптосистема. Если взаимно поддерживаемых криптосистем нет, соединение разрывается. Когда обмен согласований, использующих опциональные сертификаты открытых ключей и случайные данные для генерации ключа, используемого в криптографическом алгоритме, завершен, производится обмен специальными сообщениями для переключения соединения в защищенный режим.
Для обеспечения хотя бы минимального уровня безопасности и совместимости реализаций все клиенты и серверы CDMI должны поддерживать:
- криптосистему TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (индекс {0x0013}), обязательную криптосистему для TLS 1.0 (см. RFC 2246 раздел 9);
- криптосистему TLS_RSA_WITH_AES_128_CBC_SHA (индекс {0x002F}), обязательную для TLS 1.2;
- криптосистема TLS_RSA_WITH_NULL_SHA (индекс {0x0002}) должна поддерживаться CDMI клиентами и серверами для обеспечения аутентифицированного незашифрованного соединения. При использовании этой криптосистемы не следует использовать базовую аутентификацию HTTP;
- криптосистема TLS_RSA_WITH_AES_128_CBC_SHA256 (индекс {0х003C}) должна поддерживаться всеми реализациями с рекомендованным стандартом TLS 1.2 в рамках перехода к 112-битному шифрованию.
Разработчики вправе использовать дополнительные криптосистемы.
Клиенты и серверы CDMI могут быть атакованы с использованием фальшивого CDMI сервера для получения идентификатора и пароля пользователя или с использованием ненаблюдаемого прокси между клиентом и сервером CDMI. Наиболее эффективная контрмера против такой атаки — проверка клиентом сертификата сервера посредством TLS, в предположении, что фальшивый сервер не сможет получить правильный сертификат. В частности, это может быть реализовано настройкой клиента всегда использовать TLS при аутентификации HTTP и доверять лишь сертификатам от особого локального удостоверяющего центра.
При использовании с CDMI, TLS должен использовать сертификаты формата X.509 версии 3, которые удовлетворяют профилю, определенному в гл. 4 RFC 3280 (X.509v3 Certificate and CRL). Этот профиль сертификатов и списка отозванных сертификатов (CRL) определяет обязательные поля для включения в сертификат, а также опциональные поля и расширения, которые могут включаться в сертификат.
Серверные сертификаты должны поддерживаться всеми серверами CDMI, а клиентские сертификаты могут поддерживаться CDMI клиентами. Сервер предоставляет клиенту серверный сертификат, в свою очередь, клиент предоставляет серверу клиентский сертификат для аутентификации. Использование серверных сертификатов довольно обычно для публичных веб-серверов, предлагающих безопасное соединение через TLS, однако клиентские сертификаты используются достаточно редко, так как клиент обычно аутентифицируется другими способами.
Пример - Сайт электронной коммерции аутентифицирует клиента по номеру кредитной карты, пользовательскому имени/паролю, и т.д., когда происходит покупка. С этой точки зрения гораздо более критично, что сервер доказывает свою идентичность, и поэтому со стороны сервера используется серверный сертификат.
Такие сертификаты X.509 используют цифровую подпись для установления связи открытого ключа и идентичности. Такие подписи часто выпускаются удостоверяющими центрами (УЦ), связанными с внутренними или внешними инфраструктурами открытых ключей (PKI); однако, альтернативой может быть самоподписанный сертификат (сертификат, подписанный той же парой ключей, открытая часть которых находится в данных сертификата). Модели, связанные с этими двумя подходами, различны. В случае сертификатов PKI следует принимать во внимание иерархию доверия и доверенную третью сторону при валидации сертификата, что повышает безопасность ценой усложнения. Самоподписанные сертификаты могут использоваться в форме доверенной сети (решение о доверии находится в руках пользователей или администраторов), однако это считается менее безопасным, так как отсутствует центральный орган, который может проверить подлинность сертификата и отозвать его при необходимости. Тем не менее, даже такая пониженная безопасность в ряде случаев может быть адекватной мерой, а ее реализация гораздо проще.
В случае сертификатов PKI часто необходимо пройти по цепочке доверителей до корневого удостоверяющего центра. Такой корневой УЦ может быть внутренним УЦ, сертификат которого подписан УЦ более высокого уровня, или находиться на конце цепочки как УЦ наивысшего уровня. Последний является главной аттестационной организацией в данной схеме PKI, и его сертификат (корневой сертификат) может быть только самоподписанным. Установление якоря доверия на уровне корневого сертификата, особенно в случае коммерческих СА, может иметь нежелательные побочные эффекты, связанные с неявным доверием ко всем сертификатом, выпускаемым данным коммерческим СА. В идеале якорь должен располагаться на низшем практически доступном уровне.
Клиенты и серверы CDMI должны провести простейшую проверку пути, расширенную проверку пути и проверку CRL как описано в гл. 6 RFC 3280, для всех представленных сертификатов. Эти проверки включают (но не ограничены) следующими:
- построение сертификата корректно;
- подпись сертификата корректна;
- дата выдачи сертификата (срок действия не истек);
- сертификат не был отозван (только для сертификатов PKI);
- цепь сертификатов построена правильно (включая сертификат стороны, участвующей в коммуникации, и его выпускающий орган, вплоть до максимально достижимого уровня цепи, только для сертификатов PKI).
Если серверы и клиенты CDMI используют списки отозванных сертификатов, они должны использовать CRL X.509 версию 2, которая соответствует требованиям раздела 5 RFC 3280 (только для сертификатов PKI.)
Когда сертификаты PKI и самоподписанные сертификаты используются совместно в одном домене, важно понимать, что уровень безопасности понижается до уровня, который обеспечивают самоподписанные сертификаты. Самоподписанные сертификаты сами по себе лишь предлагают основу для обеспечения конфиденциальности и целостности при коммуникации. Единственная проверка идентичности самоподписанных сертификатов заключается в процессах их принятия, как описано ниже.
Все интерфейсы для конфигурирования сертификатов (в особенности импорт) должны поддерживать следующие форматы сертификатов:
- сертификат X.509 в кодировке DER. См. спецификацию и технические данные в ISO/IEC 9594-8:2008;
- сертификат X.509 в кодировке Base 64 (PEM). См. гл. 6.8 в RFC2045;
- PKCS#12. См. спецификацию и технические данные в PKS12.
Все программы проверки сертификатов должны поддерживать локальные списки отозванных сертификатов, при этом на каждый корневой сертификат должен приходиться по крайней мере один такой список. Необходима поддержка как кодировок DER и base 64, но она может осуществляться программной поддержкой одного из форматов и конвертацией в него другого формата. OCSP и другие средства мгновенной онлайн проверки сертификатов не обязательны, так как связь с выпускающим УЦ не может быть гарантирована.
A.5.2.3 Управление сертификатами
Все сертификаты и связанные с ними открытые ключи должны быть заменяемыми. Клиенты и серверы CDMI должны обладать одной из следующих возможностей:
- импорт внешним образом сгенерированного сертификата и открытого ключа;
- генерирование и установка нового самоподписанного сертификата с соответствующим открытым ключом.
При использовании клиентами и серверами CDMI сертификатов PKI все реализации должны включать поддержку возможности импорта, установки/хранения и удаления корневых сертификатов УЦ, а также поддержку множественных доверенных сертификатов УЦ. Сертификаты УЦ используются для проверки того, что данный сертификат подписан ключом приемлемого УЦ.
Все интерфейсы сертификатов должны поддерживать ограничения доступа, которые разрешают доступ лишь администраторам с соответствующими правами. Администратор должен иметь возможность заблокировать использование неопознанных сертификатов, см. A.5.2.1 и A.5.2.2.
Поддержка формата сертификата PKCS#7 опущена из списка требований. Этот формат в основном используется для онлайн взаимодействий с УЦ, эта функциональность не требуется от всех приложений CDMI, кроме того, существуют средства конвертации сертификатов PKCS#7 в и из других форматов.
A.5.2.4 Руководство по цифровым сертификатам для TLS
Для упрощения использования сертификатов, реализации CDMI должны включать конфигурируемые механизмы, позволяющие в любой момент форсировано использовать один из следующих взаимоисключающих режимов для работы с конечными сертификатами (т.е., сертификатами, не используемыми УЦ для подписи других сертификатов):
- не поддающиеся проверке (самоподписанные) сертификаты конечных систем, в случае использования, автоматически устанавливаются как доверенные; такие сертификаты должны определяться как корневые сертификаты, не принадлежащие УЦ, и не должны использоваться для проверки других сертификатов. Если для верификации узла используется непосредственно сертификат УЦ, он должен быть отклонен. Для клиентов CDMI следует реализовать при наличии технической возможности вариант этого режима, при котором запрашивается решение пользователя.
Примечание - Использование этого режима должно быть ограничено обучающим или подготовительным периодом, когда устанавливаются соединения с другими облачными системами, требующими безопасного соединения. Рекомендуется выход из этого режима по тайм-ауту;
- не поддающиеся проверке (самоподписанные) сертификаты конечных систем могут быть импортированы и установлены как доверенные вручную (подобно ручному импорту и установке корневого сертификата УЦ), но они не добавляются автоматически, когда встречаются впервые. Для ручного импорта и установки сертификата могут требоваться права администратора;
- этот режим работы считается нормальным. Все политики принятия сертификатов клиентами и серверами CDMI должны быть настраиваемыми. Настраиваемый механизм определяет, как данная реализация CDMI обрабатывает представленные сертификаты. В нормальном рабочем режиме серверы CDMI не должны принимать сертификаты от неизвестных удостоверяющих центров (т.е., когда корневые сертификаты УЦ не установлены).
Интерактивные клиенты должны предоставлять возможность запроса пользователя на принятие сертификата от неопознанной организации (т.е. соответствующий корневой сертификат УЦ не установлен в клиента), и принимать ответ, позволяющий использовать либо данный сертификат, либо все сертификаты от данного выпускающего УЦ. Серверы не должны поддерживать принятие нераспознанных сертификатов; ожидается, что ограниченное число СА будет приемлемо для клиентских сертификатов в каждом месте, где они используются.
Предварительная настройка для использования корневых сертификатов от широко известных УЦ опциональна, но она упрощает начальную настройку системы безопасности, основанной на сертификатах, так как разрешает принятие сертификатов от этих УЦ. Эти корневые сертификаты могут быть экспортированы из широко распространенных веб-браузеров.
СВЕДЕНИЯ О СООТВЕТСТВИИ ССЫЛОЧНЫХ МЕЖДУНАРОДНЫХ СТАНДАРТОВ НАЦИОНАЛЬНЫМ СТАНДАРТАМ РОССИЙСКОЙ ФЕДЕРАЦИИ
| Обозначение ссылочного международного стандарта | Степень соответствия | Обозначение и наименование соответствующего национального стандарта |
| ИСО 3166 | - | <*> |
| ИСО 4217:2008 | - | <*> |
| ИСО 8601:2004 | - | <*> |
| ИСО/МЭК 9594-8-94 | IDT | ГОСТ Р ИСО/МЭК 9594-8-98 «Информационная технология. Взаимосвязь открытых систем. Справочник. Часть 8. Основы аутентификации» |
| ИСО/МЭК 14776-414 | - | <*> |
| IEEE Std 1003.1, 2004 | - | <*> |
| <*> Соответствующий национальный стандарт отсутствует. До его утверждения рекомендуется использовать перевод на русский язык данного международного стандарта. Перевод данного международного стандарта находится в Федеральном информационном фонде технических регламентов и стандартов. Примечание — В настоящей таблице использовано следующее условное обозначение степени соответствия стандартов: - IDT — идентичные стандарты. | ||
Библиография
| [1] | [CRC], Williams, Ross, «A Painless Guide to CRC Error Detection Algorithms», Chapter 16, August 1993, http://www.repairfaq.org/filipg/LINK/F_crc_v3. html |
|---|---|
| [2] | [OCCI], «Open Cloud Computing Interface», Version 1.1, June 2011. Specification - http://occi-wg.org/about/specification/ |
| [3] | [PKS12], RSA Laboratories, PKCS #12: Personal Information Exchange Syntax, Version 1.0, June 1999. Specification and Technical Corrigendum - http://www.rsa.com/rsalabs/node.asp?id=2138 |
| [4] | [REST], «Representational State Transfer» - http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm |
| [5] | [RESTful Web], Richardson, Leonard and Sam Ruby, RESTful Web Services, O'Reilly, 2007. |
| [6] | [INCITS 464-2010], Information Technology — Information Management — Extensible Access Method (XAMTM) |