ГОСТ Р ИСО/МЭК 19831-2017 Модель и протокол интерфейса управления облачной инфраструктурой (CIMI). Интерфейс для управления облачной инфраструктурой

ГОСТ Р ИСО/МЭК 19831-2017

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

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

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

Cloud infrastructure management interface (CIMI) model and RESTful HTTP-based protocol. An interface for managing cloud infrastructure

ОКС 35.100.05

Дата введения 2018-01-01

Предисловие

Предисловие

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

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

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

4 Настоящий стандарт идентичен международному стандарту ИСО/МЭК 19831:2015* "Модель и протокол интерфейса управления облачной инфраструктурой (CIMI). Интерфейс для управления облачной инфраструктурой" (ISO/IEC 19831:2015 "Cloud Infrastructure Management Interface (CIMI) Model and RESTful HTTP-based Protocol - An Interface for Managing Cloud Infrastructure", IDT).
________________
* Доступ к международным и зарубежным документам, упомянутым здесь и далее по тексту, можно получить, перейдя по ссылке на сайт . - .


ИСО/МЭК 19831 разработан подкомитетом 38 "Платформы и сервисы для распределенных приложений" Совместного технического комитета JTC 1 "Информационные технологии" Международной организации по стандартизации (ISO) и Международной электротехнической комиссии (IEC).

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

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

6 Некоторые положения международного стандарта, указанного в пункте 4, могут являться объектом патентных прав. ИСО и МЭК не несут ответственности за идентификацию подобных патентных прав


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

Введение

Настоящий стандарт подготовлен Рабочей группой по управлению облачными вычислениями DMTF. Стандарт определяет логическую модель для менеджмента ресурсов в категории "Инфраструктура как услуга".
________________
DMTF - некоммерческая ассоциация, объединяющая представителей промышленности для продвижения средств управления предприятиями и системами и обеспечения совместимости.

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

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

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

1.1 Структура стандарта

В настоящем стандарте определены модель и протокол, основанный на RESTful HTTP.

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

1.2 Схема управления версиями стандарта

Схема управления версиями - согласно 6.3 DMTF DSP4004.

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

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

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

В тексте стандарта:

- основной текст набран шрифтом Arial;

- выделены существительные CIMI, такие как наименования ресурсов, атрибутов, операций;

- текст, обозначающий наименование или значение определенного понятия (например, атрибут "value constraints", графа "Наименование Ресурса", значение "false"), взят в кавычки. В таких случаях текст в кавычках всегда относится к понятию, экземпляром которого он является;

- наименования понятий CIMI, которые представляют собой общепринятые слова, но имеют конкретное значение в CIMI, набраны обычным шрифтом, но начинаются с прописной буквы, например Поставщик, Потребитель, Ресурс, Набор.

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

В таблицах, описывающих модель данных Ресурсов:

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

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

- имена, служащие заполнителями для фактических имен, которые могут меняться в каждом экземпляре модели, взяты в угловые скобки <> (например, <componentTemplate>).

При описании сериализации Ресурсов используется нотация псевдосхемы с применением следующих соглашений:

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

- к элементам добавляются символы для указания на количество элементов:

- "?" (0 или 1);

- "*" (0 или более);

- "+" (1 или более);

- вертикальный разделитель "|" обозначает альтернативу. Например "а|b" означает выбор между "а" и "b";

- круглые скобки "("и")" используются для указания области действия операторов "?", "*", "+" и "|";

- многоточие ("...") указывает на точки расширяемости.

Примечание - Отсутствие многоточия не означает, что не существует возможного расширения; скорее всего оно не представлено в явном виде (как правило, для краткости).


Наименования операций Create, Update, Delete, Read обозначают абстрактные операции, которые передают семантику соответствующих конкретных операций, таких как методы HTTP или URI операций CIMI.

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

В настоящем стандарте использованы нормативные ссылки на следующие стандарты*. Для датированных документов используются только указанные издания (включая любые исправления или версии обновления DMTF). Для недатированных документов используются самые последние издания (с учетом всех изменений) (включая любые исправления или версии обновления DMTF).
_______________
* Таблицу соответствия национальных стандартов международным см. по ссылке. - .


DMTF DSP0223, Generic Operations 1.0 (Общие операции 1.0)

DMTF DSP0243, Open Virtualization Format Specification 1.1 (Спецификация открытого формата виртуализации 1.1)

DMTF DSP1001, Management Profile Specification Usage Guide 1.1 (Руководство по использованию спецификации профиля менеджмента 1.1)

DMTF DSP4004, DMTF Release Process 2.4 (Процесс подготовки публикаций DMTF 2.4)

IANA HTTP Header Registry (Реестр заголовков HTTP)

IEC 80000-13:2008, International Organization for Standardization, Geneva, Switzerland, Quantities and units - Part 13: Information science and technology (Международная организация по стандартизации, Женева, Швейцария, Величины и единицы. Часть 13: Информатика и информационная технология)

IETF RFC2616, R. Fielding et al, Hypertext Transfer Protocol - HTTP/1.1, P.Филдинг и др. (Протокол передачи гипертекста - НТТР/1.1)

IETF RFC3986, T.Berners-Lee et al, Uniform Resource Identifiers (URI): Generic Syntax, Т.Бернерс-Ли и др. (Унифицированные идентификаторы ресурса (URI). Общий синтаксис)

IETF RFC4627, D. Crockford, The application/json Media Type for JavaScript Object Notation (JSON) (Д.Крокфорд, Тип медиа application/json для объектной нотации JavaScript (JSON)

IETF RFC5246, Т. Dierks and E. Rescorla, The Transport Layer Security (TLS) Protocol Version 1.2 (Т.Диркси, Э.Рескорла, Протокол безопасности транспортного уровня, Версия 1.2 (TLS)

ISO 8601:20044, International Organization for Standardization, Geneva, Switzerland, Data elements and interchange formats - Information interchange - Representation of dates and times (Международная организация по стандартизации, Женева, Швейцария, Элементы данных и форматы для обмена информацией. Обмен информацией. Представление дат и времени, март 2008 г.)

ISO/IEC 14977:1996, Roger S. Scowen, Extended BNF - A generic base standard. Software Engineering Standards Symposium 1993 (Информационная технология. Синтаксический метаязык. Расширенная форма Бэкуса-Наура (Extended BNF)

ISO/IEC Directives Part 2, Rules for the structure and drafting of International Standards (Директивы ИСО/МЭК. Часть 2. Правила построения и формулирования международных стандартов)

NIST 800-145, NIST Special Publication 800-145, Peter Mell and Timothy Grance, The NIST Definition of Cloud Computing (Питер Мелл и Тимоти Грэнс. Определение облачных вычислений, сентябрь 2011 г.)

NIST Special Publication 500-292, Fang Liu, Jin Tong, Jian Mao, Robert Bohn, John Messina, Lee Badger and Dawn Leaf, NIST Cloud Computing Reference Architecture, NIST 500-292 (Фан Лиу, Чжин Тонг, Цзянь Мао, Роберт Бон, Джон Мессина, Ли Бэджер и Дон Лиф, Эталонная архитектура облачных вычислений NIST, сентябрь 2011 г.)

Representational State Transfer, Roy Fielding, Doctoral dissertation, University of California, Architectural Styles and the Design of Network-based Software Architectures (Рой Филдинг, Стили архитектуры и проект сетевой программной архитектуры (глава 5), Докторская диссертация, Калифорнийский университет, 2000 г.)

XML Schema - Part 1, World Wide Web Consortium (W3C) Recommendation, H. Thompson, et al., Editors, XML Schema Part 1: Structures Second Edition (Рекомендация Консорциума World Wide Web (W3C), X.Томпсон, и др. (редакторы), XML-схема часть 1: Структуры (вторая редакция), 28 октября 2004 г.)

XML Schema - Part 2, World Wide Web Consortium (W3C) Recommendation, P. Biron, A.Malhotra, Editors, XML Schema Part 2: Data types (Second Edition) (Рекомендация Консорциума World Wide Web (W3C), П.Бирон, А.Мэлхотра (редакторы), XML-схема часть 2. Типы данных (вторая редакция), 28 октября 2004 г.)

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

В настоящем стандарте некоторые термины, определенные в данном разделе, помимо общепринятого смыслового значения также имеют иное значение.

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

Примечание - В [13], приложение Н определены дополнительные альтернативы, которые в случае их использования следует интерпретировать в общепринятом значении.


Термины "пункт", "подпункт", "абзац" и "приложение" следует интерпретировать, как описано в [13], раздел 5.

Термины "обязательный" и "справочный" в настоящем стандарте следует интерпретировать согласно [13], раздел 3. В настоящем стандарте пункты, подпункты или приложения, имеющие справочное значение, не содержат обязательных требований. Примечания и примеры всегда являются справочными элементами.

В настоящем стандарте применены термины по [4], [1] и [3], а также следующие термины с соответствующими определениями:

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

3.2 авторизация (Контроль Доступа) (authorization): Процесс проверки наличия разрешения у проверяемого принципала (человека, службы и т.д.) на выполнение определенных операций (например, чтение, обновление) на определенных Ресурсах.

3.3 облако (cloud): Синоним термина "облачные вычисления", определенного в разделе [14].

3.4 Потребитель Службы облачных вычислений (Cloud Service Consumer): Категория агентов, которая включает в себя Бизнес-менеджера Потребителя (утверждает деловые и финансовые расходы для использованных служб, счета на используемые реализации службы, устанавливает деловые отношения, устанавливает учетные записи, бюджет, условия и т.д.), Администратора службы Потребителя (запрашивает реализации службы и изменения в реализациях службы, закупает службы в рамках деловых отношений, создает Пользователей служб (включая политики), выделяет ресурсы, такие как компьютер и хранилище, готовит отчеты, такие как отчет об использовании и т.д.) и Пользователи службы (использует реализации службы, предоставленные Поставщиком службы облачных вычислений). Если данное действие или деятельность включат в себя более одного из вышеуказанных агентов, то используется термин "Потребитель". В случаях, когда различие между агентами данной категории существенно, используются уточненные термины.

Примечание - Термин "Потребитель Службы облачных вычислений" эквивалентен термину "Потребитель Облачных вычислений", определенному в эталонной архитектуре NIST [15].

3.5 Поставщик Службы облачных вычислений (Cloud Service Provider): Категория агентов, которая включает в себя Менеджера операций Службы (управляет технической инфраструктурой, необходимой для предоставления службы облачных вычислений, проводит мониторинг и измеряет производительность и использование в соответствии с Соглашением об уровне обслуживания, предоставляет отчеты по мониторингу и измерениям и т.д.), Бизнес-менеджера Службы (предлагает все типы служб, созданных разработчиками службы облачных вычислений, учитывает услуги, потенциально предложенные самими Поставщиками службы и предлагаемые от имени разработчиков службы облачных вычислений, формирует портфель деловых отношений, устанавливает учетные записи и условия для Потребителей и т.д.) и Менеджера перехода Службы (позволяет потребителю использовать службу облачных вычислений, включая первичное подключение, интеграцию и адаптацию процесса, определяет и создает службы на основе Шаблонов и Конфигураций, которые могут использоваться Потребителями и заноситься в каталог и т.д.). Если данное действие или деятельность могут включать в себя более одного из вышеуказанных агентов, то используется термин "Поставщик". В случаях, когда различие между агентами данной категории существенно, используются уточненные термины.

3.6 Набор (Collection): Особый вид Ресурса, содержащий набор других Ресурсов и снабженный представлением и сериализацией в соответствии с настоящим стандартом и являющийся синонимом термина "набора CIMI".

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

3.8 Инфраструктура как услуга; служба laaS (Infrastructure as a Service (laaS)): Модель службы облачных вычислений, определенная в [14, раздел 2].

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

3.10 целостность сообщения (message integrity): Свойство сообщения, позволяющее получателю этого сообщения определить, изменялось ли содержание сообщения после его создания.

3.11 Ресурс (Resource): Представление объекта, управляемого Поставщиком [Службы облачных вычислений], который обычно доступен Потребителю [Службы облачных вычислений] для доступа или операций с помощью интерфейса, описанного в настоящем стандарте, является синонимом термина "ресурс CIMI".

3.12 Шаблон (Template): Ресурс, представляющий собой совокупность метаданных и инструкций, используемых для создания экземпляра другого Ресурса (например, Machine Template используется для создания экземпляров Machine); может включать в себя другие Ресурсы метаданных, такие как другие Шаблоны, Конфигурации и Образы, например Machine Template ссылается на Machine Configuration и MachineImage является синонимом термина "шаблон CIMI".

4 Протокол, основанный на HTTP

4.1 Введение

Все операции основаны на Протоколе передачи гипертекста (HTTP), версия 1.1 [7]. Каждый запрос должен быть отправлен с помощью глаголов HTTP, например таких, как PUT, GET, DELETE, HEAD или POST, и включает в себя тело сообщения в формате JSON или XML. Каждый ответ использует стандартный код состояния HTTP, семантика которого интерпретируется в контексте конкретного выполненного запроса. У каждого Ресурса в модели есть тип MIME, который дополнительно контекстуализирует полезную нагрузку запросов и ответов.

Ресурсы в модели идентифицируются с помощью URI и представление каждого Ресурса должно содержать атрибут "ID" типа URI, который действует как "указатель на себя". Этот URI должен быть уникальным в рамках контекста реализации Поставщика. Разыменовывание (ссылка на указанный объект) (через HTTP GET) URI Ресурса приводит к представлению Ресурса, содержащего атрибуты и ссылки на связанные Ресурсы. Для того чтобы начать операцию, клиент должен знать URI главной точки входа Поставщика, также известной как Ресурс "Точка входа в облако". Тогда все остальные Ресурсы в пределах окружения должны поддаваться обнаружению путем итеративного перехода по ссылкам к связанным Ресурсам в пределах каждого полученного Ресурса.

4.1.1 Развитие протокола и ожидания клиентов

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

1 Клиенты должны знать, что схемы сериализации ответов в настоящем стандарте не являются полными. В частности, клиенты должны принимать ответы, содержащие смесь данных и представленных в настоящем стандарте сериализации, и должны игнорировать такие данные. Однако в соответствии с 4.2.1.3 клиенты должны включать неизвестные данные в запросы PUT для обновления Ресурсов.

2 Клиенты не должны иметь знаний об операциях, которые поддерживает сервер. Предполагают, что они обнаружат поддерживаемые (и допустимые) операции при обходе Ресурсов от Точки входа в облако. Сериализации обнаруженных Ресурсов указывают на то, какие операции поддерживаются сервером.

4.1.2 Пространства имен ХМL

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

Таблица 1 - Пространства имен XML

4.1.3 Пространство URI

Несмотря на то что URI, возвращенные Поставщиками, должны рассматриваться как непрозрачные для Потребителей. Потребители не должны знать конкретную структуру URI для Ресурсов, Потребители могут изменить URI, добавив некоторые четко определенные параметры запроса, которые поддерживаются Поставщиком, в соответствии с 4.1.6.

Демонстрационные URI, используемые в настоящем стандарте, не являются нормативными, и используемые шаблоны не должны интерпретироваться как руководство для реализаций. Например любой из следующих URI может использоваться Поставщиками для ссылки на конкретный Ресурс Machine:

//example.com/Machines/12345

//example.com/Machines?id=12345

//example.com/12345

//example.com/Cloud/resource?id=12345

4.1.4 Типы медиа

В настоящем стандарте представления Ресурсов и ответов закодированы в формате JSON в соответствии с [9], либо в XML. Если сериализация происходит в формате JSON, типом медиа для ресурсов CIMI должен быть "application/json". Если сериализация происходит в формате XML, типом медиа должен быть "application/xml".

В сериализации JSON представлений CIMI, отправленных Поставщиками, должен быть дополнительный атрибут корневого объекта, имеющий наименование "resourceURI" и содержащий уникальный URI, связанный с типом сериализуемого ресурса CIMI.

Данное требование применяется в том случае, даже если используется атрибут select для выделения подмножества запрашиваемого ресурса.

В сериализации XML представлений Набора, отправленного Поставщиками, должен присутствовать атрибут resourceURI, как показано на примере сериализации XML Наборов в 5.5.12.

Данный атрибут необязателен для его использования Потребителями. Если он присутствует, значение этого атрибута должно соответствовать атрибуту "typeURI" соответствующего Ресурса ResourceMetadata (см. 5.11), если ResourceMetadata поддерживается. Это значение также должно быть эквивалентно объемлющему элементу сериализации XML; другими словами, конкатенации пространства имен объемлющего элемента, знака "косая черта" ("/") и его localName.

У любого ресурса CIMI, реализованного Поставщиком, должны быть представления в JSON и XML. Клиентская реализация может таким образом использовать либо JSON, либо XML в запросах с любой реализацией сервера и может запросить определенную сериализацию, используя процедуру согласования содержания сервером (используя заголовок запроса Accept).

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

Для передачи метаданных сообщения в сообщениях запроса следует использовать общие заголовки, заголовки запроса и заголовки объекта в соответствии с [7]. Приложения, использующие сообщения, определенные в настоящем стандарте, должны использовать заголовки, соответствующие требованиям [7].

4.1.6 Параметры запроса

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

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

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

4.1.6.1 Фильтрация Наборов

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

? $filter=expression,

где "expression" - математическое выражение, обозначающее, как следует фильтровать атрибуты верхнего уровня Ресурсов в Наборе. Выражение определено следующей грамматикой EBNF:

Filter ::= AndExpr ( 'or' Filter )*;
AndExpr ::= Comp ( 'and' AndExpr )*
Comp ::= Attribute Op Value
| Value Op Attribute
| PropExpr
| '(' Filter ')'
Op ::='<' | '<=' | '=' | '>=' | '>' | '!='
Attribute ::= ? наименование атрибута ресурса ?
Value ::= IntValue | DateValue | StringValue | BoolValue
lntValue ::= /[0-9]+/
DateValue ::= ? в соответствии с определением XML Схемы ?
StringValue ::="..." | '...'
BoolValue ::='true' | 'false'
PropExpr ::='property[' StringValue ']' Op StringValue

PropExpr используется для нахождения Ресурсов, содержащих свойство с определенной комбинацией ключ/значение. Ключ - StringValue в квадратных скобках ([ ]), а значение - StringValue после Ор. Считается, что Ресурс удовлетворяет критериям поиска, если какое-либо из свойств в Ресурсах будет соответствовать указанному РгорЕхрг.

Каждый из них должен быть соответствующим образом закодирован в URL с использованием процентов.

Выбор оператора (включая "and" и "or") ограничен на основании типа значения и атрибута. Допустимыми операторами являются:

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

Примеры

В данных примерах используются следующие демонстрационные ссылки URI.

URI к MachineCollection Точки входа в облако следующее:

/Machines

URI экземпляра Machine:

/Machines/123

URI DiskCollection экземпляра Machine:

/Machines/123/disks

URI MachineVolumeCollection экземпляра Machine:

/Machines/123/Volumes

Чтобы отфильтровать MachineCollection так, чтобы возвращались только экземпляры Machine с атрибутом "name" равным "mine", используется следующий фильтр:

GET / Machines?$filter=name='mine'

Чтобы отфильтровать DiskCollection у экземпляра Machine так, чтобы были возвращены только экземпляры Disk с форматом "ntfs", используется следующий фильтр:

GET /Machines/123/disks?$filter=format='ntfs'

Если используется атрибут $filter, то атрибут "count" Набора должен содержать число Ресурсов, соответствующих выражению фильтра.

4.1.6.2 Подмножества Наборов

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

В настоящем стандарте определены два параметра запроса, которые при их использовании должны указывать на первое и последнее порядковые положения объектов в пределах возвращенного Набора. Параметры запроса должны иметь форму:

?$first=число
?$last=число,

где "$first" указывает на порядковое положение (начиная с 1) первого объекта Набора для включения в ответ, а "$last" указывает на порядковое положение (начиная с 1) последнего объекта Набора для включения в ответ. Потребители не обязаны использовать их одновременно. Если $first будет определен, а $last не будет, то подразумеваемым значением $last должно быть числовое значение последнего объекта в Наборе. С другой стороны, если $last будет определен, а $first не будет, то подразумеваемым значением $first должна быть 1.

Если любая часть диапазона, выраженного с помощью $first и $last, выйдет за пределы границ Набора, то будут возвращены только те Ресурсы Набора (если они имеются), которые содержатся в пределах этого диапазона. Если какая-либо часть или весь выраженный диапазон будут за пределами Набора, сообщение об ошибке не должно генерироваться.

Примечание - Если значение $first более $last, диапазон должен представлять собой пустой массив, поэтому никакие Ресурсы не будут возвращаться.


Если $first или $last определены и выражение фильтра (в соответствии с 4.1.6.1) также определено, то первым должно быть обработано выражение фильтра, а затем следует применять порядковые ограничения $first и $last.

4.1.6.3 Выделение подмножества Ресурса

Запрашивая представление Ресурса Потребители могут включать параметр запроса $select, чтобы определить подмножество Ресурса, с которыми будут взаимодействовать. Поставщики должны интерпретировать и обработать этот параметр запроса в соответствии с требованиями настоящего раздела. Данное подмножество должно иметь семантическую эквивалентность ссылки на другой Ресурс, атрибутами которого является подмножество исходного Ресурса в соответствии с именами атрибутов, перечисленными в параметре запроса $select. Формат параметра запроса $select:

? $select=наименование Атрибута...

Значение параметра запроса $select должно выглядеть как перечень наименований атрибутов верхнего уровня Ресурса, разделенных запятой, возможно включая строку "operations" в этом случае, необходимо выбрать операции, доступные Потребителю для этого Ресурса. Любое наименование атрибута, ошибочно появляющееся в списке, который не является частью Ресурса, должно быть проигнорировано Поставщиком. Наименование атрибута "*" эквивалентно определению всех атрибутов Ресурса, включая его операции. Если наименование атрибута явно появляется в URI более одного раза, его второе (и последующие появления) должны быть проигнорированы.

В URI параметр запроса $select может появиться несколько раз. Это семантически эквивалентно появлению всех имен атрибутов как значения единичного параметра запроса $select. Например:

?$select=name&$select=state

эквивалентно:

? $select=name,state

В целях сериализации порядок имен атрибутов в параметре запроса $select не имеет значения. Атрибуты сериализуются в соответствии с правилами/порядком сериализации, указанным в определении Ресурса.

Примечание - Как указано в 4.1.4, если представление Ресурса отправляется Поставщиком, оно должно всегда включать в себя атрибут resourceURI, даже если это не определено в параметре запроса $select.


Например чтобы ограничить подмножество перечня атрибутов объектов Machine, с которыми Потребитель собирается взаимодействовать, только атрибутами "name" и "description", используется следующий параметр запроса:

?$select=name,description

Информация о влиянии этого параметра запроса при обновлении Ресурса приведена в 4.2.1.3.1.

Если для Ресурса Набора в URI используется $select, то подмножества должны применяться к атрибутам самого Набора, как для любого другого Ресурса. Например, следующее определение подмножества Ресурса Набора приведёт к передаче только числа элементов и операций, доступных для данного Набора:

?$select=count,operations

Однако в случае Ресурсов Набора, если некоторый атрибут, указанный в списке $select, не является атрибутом верхнего уровня Ресурса Набора, а вместо этого является атрибутом объектов, которые являются элементами Набора, то подмножество должно относиться к каждому элементу Набора относительно этого атрибута. Например при получении DiskCollection следующий параметр запроса ?$select=name,capacity возвращает набор экземпляров Disk, связанных с некоторым экземпляром Machine, но каждый объект Набора содержит только атрибуты name и capacity, а также атрибуты operation или id.

Опционально реализация также может поддерживать альтернативную нотацию наименования атрибута <collectionName>/<attributeName> для выделения подмножества элементов в наборе. Например следующее подмножество из элементов Набора DiskCollection эквивалентно тому, которое было выполнено в предыдущем примере; кроме того, включается перечисление операций самого ресурса Набора (а не его элементов):

?$select=disks/name,disks/capacity,operations

Если поддерживается эта нотация (см. возможность "QueryPathNotation" в 5.11.2), она позволяет разрешать неоднозначности подмножеств, если одно и то же наименование атрибута можно найти как в самом Наборе, так и для каждого элемента в Наборе (это всегда верно для id и operations).

4.1.6.4 Разворачивание ссылок

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

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

Сериализация JSON:

"name": {"href": string}

должна быть расширена, и стать:

"name": {
"href": string,
... атрибуты ресурса, на который указывает ссылка...
}

Сериализация XML:

<namehref ="xs:anyURI"/>

должна быть расширена, и представлять собой:

<name href ="xs:anyURI">
... атрибуты ресурса, на который указывает ссылка...
</name>

Примечание - В случае XML вложенные элементы не должны содержать элемент-обертку Ресурса, на который ссылаются (например, <Machine> в случае ссылки на Ресурс Machine).


Формат параметра запроса $expand должен быть следующим:

? $expand=наименование Атрибута...

Значение параметра запроса $expand - перечень наименований атрибутов, разделенных запятой. Любое наименование атрибута, ошибочно появляющееся в списке, которое не является частью Ресурса или ссылкой, должно быть проигнорировано Поставщиком. Наименование атрибута "*" или полное отсутствие перечня наименований атрибутов эквивалентно перечислению всех атрибутов. Если наименование атрибута явно появляется в URI более одного раза, его второе (и последующие появления) должны быть проигнорированы.

Параметр запроса $expand может появиться в URI несколько раз. Это семантически эквивалентно появлению всех наименований атрибутов как значения единичного параметра запроса $expand.

Если запрашиваемым Ресурсом является Набор, то наименования атрибутов, перечисленные в $expand, должны применяться к атрибутам ресурсов, содержащихся в Наборе. Например определение ? $expand=volumes при запросе к MachineCollection имеет тот же самый итоговый эффект, что и применение семантики "расширения" к указанному атрибуту (в данном примере "Volumes") каждого Ресурса Machine в пределах Набора. При этом $expand действует на атрибуты Ресурсов в Наборе, а не на атрибуты самого Ресурса Набора.

4.1.6.5 Определение формата Ресурса

Для определения стиля кодирования ответа при запросе представления Ресурса используется заголовок HTTP Accept. Несмотря на то, что Потребителям рекомендуется использовать заголовок Accept, могут возникнуть ситуации, когда Потребители будут не в состоянии управлять значениями, определенными в данном заголовке. В этих случаях Потребители могут использовать параметр запроса $format, чтобы переопределить значения заголовка Accept. Поставщики должны интерпретировать и обрабатывать параметр запроса $format, в соответствии с требованиями настоящего раздела.

Параметр $format должен иметь форму ? $format=encoding, где "encoding" - требуемое представление ответа. Настоящий стандарт определяет два возможных значения: "json" и "xml". Поставщик может поддерживать также другие значения. Значение параметра запроса $format не зависит от регистра.

Если в сообщении запроса будут присутствовать заголовок Accept и параметр запроса $format, то значение $format является приоритетным. Если параметр запроса $format появляется более одного раза, то второе и последующие его появления должны быть проигнорированы.

4.1.6.6 Сортировка Наборов

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

Параметр $orderby должен иметь форму

?$orderby=наименованиеАтрибута[:asc|:desc], ...

Выражение $orderby может включать в себя несколько наименований атрибутов, разделенных запятой. Кроме того, каждое наименование атрибута может сразу сопровождаться двоеточием и ключевыми словами "asc" для обозначения порядка по возрастанию (значение по умолчанию) или "desc" для обозначения порядка по убыванию для данного атрибута. Если ни asc, ни desc не заданы, то порядок должен быть возрастающим.

Атрибуты, включенные в $orderby, должны иметь следующие типы в соответствии с 5.5: boolean, dateFormat, duration, integer или string.

Сортировка зависит от типа атрибута.

Следующие правила относятся к сортировке по возрастанию:

- boolean - значение "false" должно быть расположено перед значением "true";

- dateTime - более ранние значения дата/время должны быть расположены перед более поздними значениями дата/время;

- duration - более короткая продолжительность должна быть расположена перед более длительной продолжительностью;

- integer - меньшее целое число должно быть расположено перед большими целыми числами. Отрицательные целые числа должны быть расположены перед положительными целыми числами;

- string - порядок основан на порядке сортировки Unicode/UTF-8.

Порядок сортировки desc (по убыванию) должен быть противоположным указанному выше.

Примеры

Для сортировки набора результатов Ресурса MachinesCollection по атрибуту "created" в порядке убывания, используют следующее выражение:

GET / Machines?$orderby=created:desc

Для сортировки набора результатов Ресурса MachinesCollection по атрибуту "cpu" в порядке убывания, а затем по атрибуту "memory" в порядке возрастания, используют следующее выражение:

GET /Machines?$orderby=cpu:desc,memory:asc

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

В соответствии с [7] для передачи метаданных сообщения в ответных сообщениях в настоящем стандарте использованы заголовки общего назначения, заголовки ответа и заголовки объекта (entity), чтобы предоставить метаданные о сообщении. В приложениях, в которых использованы сообщения, определенные в настоящем стандарте, следует использовать заголовки, совместимые с Реестром заголовков HTTP [5].

4.1.6.8 Заголовок Job

Если сервер поддерживает Ресурс Job, то ответные сообщения должны включать в себя заголовок, определенный в настоящем стандарте, чтобы указать на URI задания, созданного для обработки связанного с ним сообщения запроса:

CIMI-Job-URI ="CIMI-Job-URI" ":" string

В тех случаях, когда во время обработки запроса происходит ошибка, Поставщик должен включить представление Ресурса Job, описывающего состояние неудавшейся операции. Представление Job должно быть включено даже в тех случаях, если Поставщик обычно не поддерживает Ресурсы Job, чтобы гарантировать, что Потребителям предоставлена достаточная информация согласованным способом относительно причины неудачи, независимо от того, поддерживает ли Поставщик Ресурсы Job. Если Ресурсы Job в целом не поддерживаются, то любая из ссылок в представлении Job (например, "id" или "href" для nestedJobs) должна быть представлена пустыми путями (т.е.""), и массив nestedJob должен быть развернут (см. 4.1.6.4), чтобы встроить представление псевдоподчиненных заданий Job.

4.1.6.9 Поддержка завершающего тега (ETag)

Заголовок ETag может быть предоставлен Поставщиком с каждым Ресурсом в соответствии с [7]. Если Поставщик действительно предоставляет заголовок ETag, то он должен также поддержать обработку заголовка If-Match от имени Потребителя.

4.2 Операции протокола

В настоящем подразделе определена совокупность общих операций HTTP, которые могут быть предоставлены Поставщиком. Его ядро составляют четыре основные операции CRUD - Create (Создать), Read (Читать), Update (Обновить) и Delete (Удалить). В рамках модели способ, которым они используются, является совместимым для всех Ресурсов, поэтому их использование определено один раз и должно унифицировано применяться. Некоторые Ресурсы поддерживают специализированные операции, которые не полностью подходят для стиля операций CRUD; такие операции тем не менее следуют общему высокоуровневому шаблону, но в каждой операции допускается вносить небольшие изменения, чтобы приспособить ее для определенных потребностей. Специфические особенности этих отдельных операций детально описаны в пункте, который определяет соответствующий Ресурс.

При необходимости некоторые представления Ресурса включают в себя атрибут "operations". Поставщики должны включать атрибут "operations", только в том случае, если указанные операции доступны для клиента этого конкретного Ресурса. Это означает, что при каждой сериализации Ресурса может возвращаться различная совокупность операций, что связано с многочисленными факторами (например, права авторизации клиентов, текущее состояние Ресурса и т.д.). Каждая операция должна включать в себя поля "rel" и "href". Поле "rel" должно однозначно определять наименование операции (например, "add", "edit"), в то время как поле "href" представляет собой URI, на который должно отправляться сообщение запрос операции.

Примечание - Поле URI "href" может отличаться от URI самого Ресурса.


Атрибут операций должен быть сериализован следующим образом:

Сериализация JSON:

{"operations": [
{"rel": "string", "href": "string"}, +
]
}

Сериализация XML:

<Resource xmlns ="//schemas.dmtf.org/cimi/1">
<operation rel="xs:anyURI" href ="xs:anyURI"/> *
</Resource>

Например операция "edit" выглядит следующим образом:

Сериализация JSON:

{"operations": [
{"rel": "edit", "href": "<editURI>"}
]
}

Сериализация XML:

<Resource xmlns="//schemas.dmtf.org/cimi/1">
<operation rel="edit" href ="<editURI>"/>
</Resource>

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

4.2.1 Общие операции CRUD

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

4.2.1.1 Создание нового Ресурса

Чтобы создать новый экземпляр типа Ресурса, на этот тип Ресурса отсылают запрос POSTHTTP к определенному "addURI". Во многих случаях ресурс Набора, который поддерживает или группирует все реализации этого типа Ресурса, включает операцию "add". Операция "add" ссылается на addURI, который должен использоваться.

Запрос POSTHTTP должен включать в себя:

- сериализацию CIMI запроса на создание нового Ресурса в теле HTTP;

- заголовок HTTPContent-Type;

- заголовок HTTPContent-Length.

Например запрос может быть следующим:

HTTP/1.1 POST<addURI>
Host: <hostname>
Accept: application / (json|xml)
Content-Type: application/(json|xml)
Content-Length: <length>
<сериализация запроса создания нового ресурса>

В данном примере есть заголовок Acceptc одним из типов медиа, поддерживаемых CIMI: application/json или application/xml. Если Поставщик принимает решение включить в ответ сериализацию, то данная сериализация должна иметь указанный тип медиа. Отсутствие заголовка Accept позволяет Поставщику включить в ответ сериализацию любого типа медиа. Если Ресурс будет содержат атрибут "state", то его значение должно быть "CREATING" в то время, когда Поставщик будет обрабатывать эту операцию.

Многие запросы create определены таким образом, чтобы передавать Шаблон нового Ресурса. Такие запросы create допускают, чтобы Шаблон передавался по ссылке или по значению. Например создание новой Machine может выглядеть следующим образом (в данном примере используется XML):

<MachineCreate xmlns ="//schemas.dmtf.org/cimi/1"> <name>
xs:string </наименование>?
<description> xs:string </description>?
<property key="xs:string"> xs:string </property> *
<MachineTemplate href ="xs:anyURI"?>
... атрибуты шаблона...?
</MachineTemplate>
</MachineCreate>

Примечание - В случае XML создание новой Machine требует наличия элемента обертки под названием MachineCreate в соответствии с правилами, определенными в 5.5.12.1.


Создание нового Ресурса осуществляется в соответствии с одним из двух сценариев сериализации (данный пример приведен в JSON):

(1) Создание ресурса путем передачи Шаблона по значению:

{"resourceURI": "//schemas.dmtf.org/cimi/1/ResourceCreate",
"name": "myResourceName"?
"description": "Мое описание ресурса"?
"properties": {"prop1name":"prop1value", +}?
"resourceTemplate": {
<в этом случае шаблон передан значением>
}
}

(2) Создание ресурса с передачей шаблона по ссылке:

{"resourceURI": "//schemas.dmtf.org/cimi/1/ResourceCreate",
"name": "myResourceName"?
"description": "Мое описание ресурса"?
"properties": {"prop1name":"prop1value", +}?
"resourceTemplate": {"href": строка,
<в этом случае могут быть добавлены некоторые пары атрибут/значение шаблона для переопределения значения в шаблоне, на который указывает ссылка>
}
}

В случае, если созданный Ресурс сам является Шаблоном, то применяется только первый сценарий создания - по значению. В сценариях (1) и (2) атрибут resourceURI определяет операцию, которую в общем случае можно идентифицировать как "ResourceCreate", например MachineCreate.

В сценариях (1) и (2) элемент, соответствующий Шаблону Ресурса (идентифицированному как "resourceTemplate", например MachineTemplate), определяет Шаблон, который будет использоваться либо по значению (1), либо по ссылке (2).

Прямая установка атрибутов в новом Ресурсе:

В запросе создания допускается установить значения некоторых атрибутов созданного Ресурса независимо от того, какие значения были заданы в экземпляре Шаблона, если использовался только этот экземпляр. В созданном Ресурсе могут быть установлены три общих атрибута: name (наименование), description (описание) и properties (свойства).

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

Определение или ссылка на Шаблон Ресурса:

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

В сценарии (2) дополнительные пары наименование атрибута/значение атрибута могут передаваться внутри элемента ResourceTemplate, который также содержит ссылку на внешний (существующий ранее) Шаблон, чтобы переопределить подобные атрибуты, определенные в Шаблоне:

- любой атрибут верхнего уровня составного или простого типа в Шаблоне, на который ссылается операция, должен быть переопределен путем присвоения ему пары наименование/значение в запросе create в элементе resourceTemplate и сразу под ним. Для атрибута верхнего уровня составного типа (например, массивы, Наборы, структуры), предоставленное составное значение должно также устанавливать все вложенные атрибуты, например элементы массива;

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

В сценарии (2) Потребители могут стереть любые атрибуты Шаблона, определяя либо

"attribute": null

для атрибута в сериализации JSON, либо

<attribute/>

в сериализации XML для этого атрибута.

Примеры

Пример сценария создания (1) с использованием MachineTemplate по значению (в JSON):

{ "resourceURI": "//schemas.dmtf.org/cimi/1/MachineCreate",
"name": "myMachine123",
"description": "Машина, которая будет подключена к существующей сети",
"machineTemplate": {
<в этом случае шаблон передан по значению, т.е. парами атрибут/значение для Шаблона MachineTemplate. Ниже приведен пример для networkInterfaces>
"networkInterfaces": [
{ "addresses": [{"address": {"href": "//example.com/addresses/add1"}},
{"address": {"href": "//example.com/addresses/add2"}}],
"network": {"href": "//example.com/networks/net1"},
"state": "ACTIVE"}
]
}
}

В данном примере:

Атрибуты name и description являются параметрами уровня экземпляра Ресурса, потому что они находятся вне элемента MachineTemplate (т.е. они устанавливают значения атрибута в новом созданном Ресурсе, а не в Шаблоне, используемом для создания такого Ресурса). Наименование нового экземпляра Machine - "myMachine123".

Этот экземпляр Machine подключен к существующей сети (экземпляр Network), обозначенному ссылкой (//example.com/networks/net1), указанной в составном атрибуте Шаблона.

Пример

Пример сценария создания (2) с использованием MachineTemplate по ссылке:

{ "resourceURI": "//schemas.dmtf.org/cimi/1/MachineCreate",
"name": "myMachine456",
"description": "Машина подключена к существующему тому",
"machineTemplate": {
"href": "//example.com/MachineTemplates/72000",
Credential": {"href": "//example.com/myCredential"}
"networkInterfaces": [
{ "addresses": [{"address": {"href": "//example.com/addresses/add4"}},
{"address": {"href": "//example.com/addresses/add5"}}],
"network": {"href": "//example.com/networks/net1"},
"state": "ACTIVE"}
]
}
}

В данном примере создана новая машина, названная "myMachine456", которая также связана с существующей сетью Network, как и в примере (1), но с иной совокупностью адресов Addresses. В настоящем примере во время создания присваиваются значения двум видам атрибутов:

- установка атрибута уровня экземпляра Ресурса: эти атрибуты должны быть незамедлительно обновлены в созданном Ресурсе, в данном случае name и description;

- переопределение атрибутов Шаблона: MachineTemplate, на который указывает ссылка, используется для создания Machine, но атрибут Credential в этом Шаблоне переопределен учетными данными, предоставленными в запросе создания, также как и массив networkInterfaces. В случае, если такие атрибуты не присутствовали в Шаблоне по ссылке, их добавляют (временно) только для создания этого экземпляра Machine.

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

Если ответ имеет код статуса 201, то ответ должен включать в себя:

- заголовок HTTP Location со ссылкой на новый Ресурс.

Если ответ на запрос включает в себя сериализацию нового Ресурса, то ответ должен дополнительно содержать:

- заголовок HTTP Content-Type;

- заголовок HTTP Content-Length.

Например ответ может быть следующим:

НТТР/1.1 201 CreatedLocation: <местоположение>
Content-Type: application/(json|xml)
Content-Length: <длина>
<сериализация нового ресурса>

4.2.1.3* Обновление ресурса
__________________
* Нумерация соответствует оригиналу. - .


Для обновления состояния Ресурса по адресу editURI, заданного для этого типа Ресурса, направляют запрос PUTHTTP, содержащий полное обновленное представление. Потребители должны включать в запрос PUT все непустые атрибуты Ресурса, включая те, которые они, возможно, не поддерживают или не понимают, которые возвращались в ответе GET. Это нужно для того, чтобы гарантировать, что клиент не изменяет (стирает) непреднамеренно данные в Ресурсе, исключив их из полного представления Ресурса.

Во многих случаях данный editURI совпадает с URI самого Ресурса. При получении представление Ресурса должно включать в себя операцию "edit", содержащую editURI, который должен использоваться, если запрашивающей стороне разрешено изменять Ресурс.

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

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

Запрос PUT HTTP должен включать в себя:

- сериализацию CIMI обновленного Ресурса в теле сообщения HTTP;

- заголовок HTTP Content-Type;

- заголовок HTTP Content-Length.

Например запрос может быть следующим:

PUT<editURI>HTTP/1.1
Host: <наименование узла>
Accept: application / (json|xml)
Content-Type: application / (json|xml)
Content-Length: <длина>
<сериализация запроса с целью обновить ресурс"

Если ответ будет включать в себя сериализацию обновленного Ресурса и иметь код статуса 200, то данный ответ должен включать в себя:

- заголовок HTTP Content-Type;

- заголовок HTTP Content-Length.

Например ответ может быть следующим:

НТТР/1.1 200 OK
Content-Type: application / (json|xml)
Content-Length: <длина>
<сериализация обновленного ресурса>

4.2.1.3.1 Частичное обновление Ресурса

В данном подпункте определено, как следует использовать параметр запроса $select (см. 4.1.6.3) для определения подмножества Ресурса с целью работы только на выбранной совокупности атрибутов верхнего уровня.

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

//example.com/resource?$select=attribute1,attribute2...

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

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


Любой атрибут, перечисленный в URI, но не включенный в запрос НТТР, должен быть переустановлен на значение, характерное для Ресурса (например, удален).

С точки зрения HTTP частично обновленный Ресурс является индивидуальным. Семантика обычного HTTPPUT сохраняется, что является полной заменой указанного Ресурса. С точки зрения Потребителя частичное обновление интерпретируется и выполняется Поставщиком Службы Облачных Вычислений, при этом изменяется некоторая часть Ресурса.

В соответствии с общей семантикой PUT, определенной ранее, любой атрибут исходного (полного) Ресурса, включенный в запрос HTTP, должен привести к ошибке, если этот атрибут не перечислен в параметре запроса $select (см. 5.4).

Примечание - Это происходит вследствие того, что такие атрибуты неизвестны частичному Ресурсу.

В следующем примере показано, как запрос обновляет только атрибуты name и description Machine:

PUT /Machines/myMachine?$select=name,description HTTP/1.1
Host: <наименование узла>
Accept: application/xml
Content-Type: application/xml
Content-Length: <длина>

<Machine>
<name> My New Machine </name>
</Machine>

Атрибут name установлен в "My New Machine", а атрибут description удален.

4.2.1.4 Удаление ресурса

Для удаления Ресурса передают запрос HTTPDELETE по адресу deleteURI, заданный для этого типа Ресурса. Во многих случаях deleteURI совпадает с URI самого Ресурса. При получении представление Ресурса должно включать в себя операцию delete, содержащую deleteURI, который должен использоваться, если запрашивающей стороне разрешено удалять Ресурс.

Например запрос может быть следующим:

DELETE<deleteUR/>HTTP/1.1
Host:<наименование узла>

Если Ресурс содержит атрибут state, то его значением должно быть "DELETING" в то время, когда Поставщик обрабатывает данную операцию.

Например ответ может быть следующим:

НТТР/1.1 200 ОK

4.2.1.5 Другие операции

Несмотря на то, что как правило модификация Ресурса в модели может осуществляться путем простой операции обновления (PUT) Ресурса по адресу editURI, иногда требуется более сложная совокупность действий. В этих случаях операции должны моделироваться как запросы POSTHTTP, направленные по адресам URI, определенным для Ресурса.

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

Запрос должен иметь следующий вид:

HTTP/1.1 POST<URI операции>
Host: <наименование узла>
Accept: application/(json|xml)
Content-Type: application/(json|xml)
Content-Length: <длина>
<сериализация запроса операции>

Форма ответа варьируется в зависимости от операции и определена самой операцией.

Примечание - Определение операции CREATE (см. 4.2.1.1) должно соответствовать этому шаблону.

4.2.1.6 Синхронные операции

Если Поставщик поддерживает Ресурс Job, то каждый входящий запрос PUT, DELETE, POST должен приводить к созданию Ресурса Job и абсолютная ссылка URI на этот Ресурс Job должна возвращаться обратно клиенту в заголовке CIMI-Job-URI в ответном сообщении HTTP:

CIMI-Job-URI: <uri-to-Job>

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

4.2.1.7 Асинхронные операции

В некоторых случаях выполнение операции, затребованной клиентом, может занять неопределенный промежуток времени для своего завершения. Например создание нового экземпляра Machine или запуск существующего экземпляра Machine могут занять относительно много времени до своего завершения. В таких случаях непрактично завершать эти операции в пределах таймаута запроса HTTP, поэтому Поставщик должен вернуть код ответа HTTP "202 Accepted".

Как и в случае с синхронными операциями, если Поставщик поддерживает Ресурс Job, он должен создать Ресурс Job для входящего запроса и вернуть ссылку на этот Ресурс Job обратно клиенту в заголовке CIMI-Job-URI в ответном сообщении HTTP. Кроме того, в случае, если кодом ответа является "202 Accepted", Поставщик может также вернуть в теле ответа HTTP любое из следующего:

- представление Ресурса Job, если такой был создан;

- частичное представление ответного сообщения, как если бы операция была синхронной. Например при создании нового экземпляра Machine ответное сообщение может включать в себя частичное представление нового экземпляра Machine в ответном сообщении. Возвращаемый перечень атрибутов Ресурса определяется реализацией и основывается на том, сколько информации доступно в то время, пока генерируется ответное сообщение, но он должен быть совместим с представлением полного Ресурса. При выполнении операции create Поставщик может также включать заголовок HTTP Location, содержащий ссылку на создаваемый Ресурс, если он известен;

- пустое тело ответа.

Примечание - Решение по поводу того, является ли какая-то конкретная операция синхронной или асинхронной, принимает сервер.

4.3 Поддержка OVF

В спецификации открытого формата виртуализации (OVF) по [2] описан открытый, безопасный, переносимый, эффективный и расширяемый формат для упаковки и распространения программного обеспечения, которое будет выполняться в виртуальных машинах. Поддержка OVF в CIMI позволяет использовать пакеты OVF для создания ресурсов менеджмента CIMI путем импорта пакета. Кроме того, ресурсы менеджмента CIMI могут быть экспортированы в пакет OVF. Фактическая поддержка пакета OVF обычно реализуется гипервизором, которым управляет поставщик CIMI. Импорт пакета OVF предоставляет доступ к набору конструкций и параметров, определяемых CIMI, без изменений исходного пакета OVF. Таким образом, ресурсы CIMI, созданные в результате импорта, формируют "представление" того, что сделано гипервизором. Однако другая (не имеющая отображение в CIMI) информация от пакета OVF может быть использована гипервизором при его импорте. Такая информация определяется реализацией и далее не рассматривается в настоящем стандарте.

Пакет OVF может поддерживать единичные виртуальные машины (далее - ВМ), соответствующие единичному экземпляру CIMI Machine или MachineTemplate (см. 5.14.1), либо может поддерживать сложную иерархию ВМ и связанных с ними ресурсов, соответствующих CIMISystem или SystemTemplate (см. 5.13.1), и связанных ресурсов менеджмента CIMI.

Описание поддержки OVF более подробно приведено в приложении А.

5 Модель

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

Описание модели CIMI приводится в виде таблицы. Прототипом послужило моделирование сущность - связь (Entity-Relationship), где каждый объект моделирует значительный облачный ресурс, для которого ожидаются независимый доступ и манипуляция. Отношения между ресурсами осуществляются с помощью механизма ссылок, основанного на уникальных идентификаторах, который, как ожидается, уже поддерживается окружающей средой реализации и протоколом (например, URI для HTTP).

Модель описывает сама себя и допускает запросы своих собственных метаданных, например для обнаружения поддерживаемых расширений. Также модель может быть расширена различными способами (см. 5.1).

Наряду с этой моделью определена сериализация ее объектов (как в XML, так и в JSON).

Альтернативное представление каждой главной группы ресурсов представлено в виде диаграммы UML.

5.1 Обертки Ресурсов

В данной модели сериализация экземпляров Ресурсов должна соответствовать ряду правил. Например сериализация Ресурса с именем MyResource должна соответствовать следующим правилам:

Сериализация JSON:

Ресурс сериализован как объект, обертывающий все его атрибуты, но без наименования обертки. Ресурс включает в себя resourceURI с URI типа сериализуемого Ресурса, например:

{"resourceURI": "//example.com/MyResource",
"attribute": "value"
}

Сериализация XML:

Ресурс сериализован как элемент с наименованием, соответствующим наименованию Ресурса; например:

<MyResource xmlns ="//example.com">
<attribute>value</attribute>
</MyResource>

5.2 Расширяемость

Модель CIMI определяет два типа механизмов расширяемости: один предназначен для использования Потребителями, а второй должен использоваться Поставщиками.

Первый тип механизма расширяемости позволяет Потребителю CIMI добавлять дополнительные данные к Ресурсу. У каждого Ресурса в модели CIMI есть атрибут с наименованием properties. При создании или обновлении Ресурса Потребители могут сохранять любую пару наименование/значение в атрибуте properties. Поставщики CIMI должны сохранять и возвращать эти значения Потребителю. От Поставщика не требуется понимать эти значения или предпринимать какие-либо действия на основании этих значений, так как они существуют только для удобства Потребителя. Поставщики не должны добавлять элементы к атрибуту properties.

Второй тип механизма расширяемости позволяет Поставщику определять свои расширения; в настоящем стандарте для этих целей включен Ресурс ResourceMetadata, который используют, чтобы:

- ввести ограничения на существующие атрибуты ресурса, определенные CIMI, (например, установить максимальное значение для атрибута "cpu" Ресурса MachineConfiguration);

- ввести новые атрибуты для определенных Ресурсов CIMI вместе с любыми ограничениями, связанными с ними (например, новый атрибут "location" для Ресурса Volume, который принимает значение, состоящее из определенной совокупности строк);

- ввести новые операции для любого из Ресурсов, определенных CIMI (например, определить новую операцию "compress" (сжать) для Ресурса Volume);

- указать определенные возможности или особенности любого Поставщика (например, отрезок времени, в течение которого Ресурс Job сохраняется после завершения задания Job).

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

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

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

5.3 Идентификаторы

Все идентификаторы (например, наименования Ресурсов, атрибуты, операции, названия параметров), приведенные в настоящем стандарте или определенные расширением, должны соответствовать следующим правилам:

- наименования идентификатора считают чувствительными к регистру;

- наименования идентификатора должны использовать только следующую совокупность символов:

- Прописной ASCII (от U+0041 до U+005A);

- Строчный ASCII (от U+061 до U+007A);

- Цифры (от U+0030 до U+0039);

- Нижнее подчеркивание (U+005F);

- число идентификатора не должны начинаться с Цифры (от U+0030 до U+0039).

Примечание - Эти правила не относятся к общему атрибуту "name", определенному в 5.10.1.

5.4 Ограничения атрибута

Каждый атрибут Ресурсов в модели CIMI дополнен рядом ограничений, которые дополнительно квалифицируют определяемый атрибут. Для каждого атрибута существует совокупность ограничений Поставщика и Потребителя, так как они могут различаться. Возможны следующие ограничения:

необязательная поддержка:

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

Непустые атрибуты, поддерживаемые Потребителем, поддерживающие запись ("чтение-запись" и "только для записи"), должны быть частью представления Ресурса, отправленного Потребителем Поставщику, включая запросы на создание.

Непустые атрибуты, поддерживаемые Поставщиками, должны быть частью представления Ресурса, отправленного Поставщиком Потребителю;

обязательная поддержка:

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

Непустые обязательные атрибуты, поддерживающие запись ("чтение-запись" и "только для записи"), должны быть частью представления Ресурса, отправленного Потребителями Поставщикам, включая запросы "создать".

Непустые обязательные атрибуты Поставщика должны быть частью представления Ресурса, отправленного Поставщиками Потребителю;

неизменяемый:

Это ограничение Поставщика означает, что атрибут, установленный однажды, не должен быть изменен в течение всего срока жизни Ресурса;

изменяемый:

Это ограничение Поставщика означает, что атрибут может быть изменен. Поставщики должны иметь возможность изменять эти атрибуты. Возможность изменения этих атрибутов Потребителями обозначается ограничениями: "только для чтения", "чтение-запись" и "только для записи";

только для чтения:

Это ограничение Потребителя означает, что атрибут может быть получен, но не может быть обновлен Потребителями. Атрибуты "только для чтения" не требуется включать в сериализации Ресурсов в запросах создания или обновления Ресурсов. Если данные атрибуты указаны в сообщении, они должны быть проигнорированы Поставщиком. Атрибуты вида "только для чтения" должны быть включены в сериализации Ресурсов, отправленных Поставщиками;

чтение-запись:

Это ограничение Потребителя означает, что атрибут может быть получен и/или обновлен Потребителями. Атрибуты "чтение-запись" должны быть включены в сериализации Ресурсов, отправленных Поставщикам и от них. Поставщики могут ограничить возможность обновлять эти атрибуты Потребителями и должны обозначить ограничение в ResourceMetadata;

только для записи:

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

5.5 Типы данных и их сериализация

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

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


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

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

5.5.1 boolean (логический тип)

Значение соответствует xs:boolean"XML-схема часть 2" [18], за исключением того, что допустимыми являются только два значения: либо "true", либо "false". Данное значение является чувствительным к регистру.

При сериализации в JSON значения должны иметь тип JSON: boolean.

При сериализации в XML значения должны иметь тип схемы XML: xs:boolean.

5.5.2 dateTime (дата и время)

Значение соответствует xs:dateTime "XML-схема часть 2" [18], является совместимым с DMTFDSP4004 [4] и ISO 8601 [11]. Метка времени должна содержать информацию о часовом поясе, т.е. содержать компоненты местного времени и смещения от UTC.

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

Например момент времени "понедельник, 25 мая 2012, в 1:30:15 PMEST" (Североамериканский восточный часовой пояс) представлен как:

2012-05-25Т13:30:15-05:00

При сериализации в JSON значения должны иметь тип JSON: string.

При сериализации в XML значения должны иметь тип схемы XML: xs:dateTime.

5.5.3 duration (продолжительность)

Значение соответствует xs:duration "XML-схема часть 2" [18]. Любые ограничения определенных диапазонов, допускаемые для любого конкретного атрибута, установлены в определении данного атрибута либо во время выполнения Поставщиком с помощью механизмов обнаружения метаданных, определенных данной спецификацией.

При сериализации в JSON значения должны иметь тип JSON: string.

При сериализации в XML значения должны иметь тип схемы XML: xs:duration.

5.5.4 integer (целое число)

Значение соответствует xs:integer "XML-схема часть 2" [18]. Любые ограничения определенных диапазонов, допускаемые для любого конкретного атрибута, установлены в определении данного атрибута либо во время выполнения Поставщиком с помощью механизмов обнаружения метаданных, определенных данной спецификацией.

При сериализации в JSON значения должны иметь тип JSON: number.

При сериализации в XML значения должны иметь тип схемы XML: xs:integer.

5.5.5 string (строка)

Значение соответствует xs:string "XML-схема часть 2" [18]. Любые ограничения к данному типу для любого конкретного атрибута установлены в определении этого атрибута либо Поставщиком во время выполнения с помощью механизмов обнаружения метаданных, определенных данной спецификацией.

При сериализации в JSON значения должны иметь тип JSON: string.

При сериализации в XML значения должны иметь тип схемы XML: xs:string.

При сериализации атрибута "строка" необходимо пропустить атрибут, значение которого равно пустой строке.

5.5.6 ref (ссылка)

Ссылка на другой Ресурс.

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

Как правило, значение ссылки для атрибута хранится во вложенном атрибуте, имеющем наименование "href" (в JSON и в XML).

Сериализация JSON:

В сериализации JSON "href" появляется как тип "строка" - string. Если атрибут будет иметь тип "ссылка", то наименование этого атрибута должно быть ключом, имеющим свойство "href" как вложенное значение. Например атрибут Ресурса "myVolume" типа "ссылка" сериализован как:

"myVolume": {"href": строка}

Сериализация XML:

В сериализации XML атрибут href появляется как тип "xs:anyURI". Если атрибут будет иметь тип "ссылка", то наименование этого атрибута должно появиться как наименование элемента XML с XML атрибутом href. Например атрибут Ресурса "myVolume" типа "ссылка" сериализован как:

<myVolumehref ="xs:anyURI"/>

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

Для JSON:

"myVolume": {"href": string,...}

для XML:

<myVolume href ="xs:anyURI">xs.any* </myVolume>

Однако для сокращения точки расширения исключены из сериализации Ресурсов.

5.5.7 map (отображение)

Атрибут map представляет собой "ключ/значение". В рамках атрибута каждый ключ должен использоваться только один раз. Ключи являются чувствительными к регистру.

Если значение атрибута типа "отображение" равно пустому отображению, то этот атрибут не должен быть представлен в сериализации.

5.5.8 structure (структура)

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

Вложенную структуру можно считать определением составного типа. Структуры могут иметь или не иметь наименований. Примеры структуры, имеющей наименование, приведены в таблице 2.

Таблица 2 - Структура, имеющая наименование

Сериализация JSON:

В JSON наименование структуры (т.е. типа, который она представляет) не появляется никогда. Другими словами, имеет ли структура наименование или нет, не имеет значения. Атрибут "SystemIncidents" типа summary (см. выше), сериализован следующим образом:

"systemIncidents": {
"low": number,
"medium": number,
"high": number,
"critical": number
}

Сериализация XML:

В XML наименование структуры (т.е. Наименование типа, который она представляет) не появляется никогда. Другими словами, имеет ли структура наименование или нет, не имеет значения. Предыдущий пример "SystemIncidents" сериализован так, чтобы атрибуты структуры стали атрибутами элемента-обертки XML<SystemIncidents>:

<systemIncidents low ="xs:integer" medium ="xs:integer" high ="xs:integer" critical ="xs:integer"/>

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

5.5.9 byte[] (массив байтов)

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

При сериализации в JSON значения должны иметь тип JSON: строка - string.

При сериализации в XML значения должны иметь тип схемы XML: xs:hexBinary.

5.5.10 URI

Формат и синтаксис атрибутов типа "URI" определены в RFC3986 [8].

Настоящий стандарт не устанавливает требований к использованию Поставщиками относительного или абсолютного URI в теле ответа HTTP.

Если URI определены как относительные URI, то они должны быть заданы относительно baseURI.

Алгоритм, используемый для преобразования относительного URI в абсолютный URI, должен соответствовать описанию, приведенному в 5.2 RFC3986 [8]. Преобразование относительного URI в абсолютный URI приведено в таблице 3.

Таблица 3 - Преобразование относительного URI в абсолютный URI

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

При сериализации в JSON значения должны иметь тип JSON: строка - string.

При сериализации в XML значения должны иметь тип схемы XML: xs:anyURI.

5.5.11 Массивы

Массив представляет собой упорядоченный перечень элементов одного и того же типа. Массив должен быть атрибутом Ресурса и быть доступен только как таковой (он не является отдельно адресуемым Ресурсом). Если Ресурс будет удален, то элементы его массивов также должны быть удалены. Однако в случае, если эти элементы являются ссылками на другие Ресурсы, то Ресурсы, на которые имеются ссылки, не будут затронуты (см. 5.7).

Атрибуты, являющиеся массивами, определены с помощью нотации itemType [], где itemType - наименование типа для каждого элемента массива. Если тип представляет собой структуру, а не просто тип данных, то рекомендуется в качестве соглашения в модели использовать множественное число в наименовании массива, которое характеризует каждый элемент. Например массив элементов имеет ли структура наименование "Volume" или ссылок на них может иметь наименование "Volumes".

Если атрибут будет иметь тип "массив ссылок" (ref[]) и, в более общем случае, массив атомарного типа, то определение в модели должно включать в себя поле "наименование элемента массива", которое может использоваться в его сериализации.

Сериализация JSON:

В рамках данной спецификации массивы в JSON сериализуются как значение некоторого свойства. Наименование свойства должно быть тем же самым, что и наименование атрибута для массива. Например атрибут "things" типа "thing[]" сериализуется следующим образом:

"things": [
{...}, + ] ?

Если элементы в массиве являются структурами, то наименование структуры не должно присутствовать в сериализации JSON.

При наличии массива ссылок, т.е. когда тип "ref" относится к каждому элементу массива, каждый элемент массива должен быть сериализован как свойство href. Например массив "things" типа "ref[]" будет преобразован в последовательную форму следующим образом:

"things": [
{"href": string}, +
]?

Примечание - При сериализации массивов совместимые реализации не должны содержать пустых массивов (т.е. массивов, которые не содержат дочерних свойств) в сериализации JSON. При этом дочерний элемент свойства "things" определен с "+", что означает необходимость наличия по меньшей мере одного дочернего элемента. Это требование гарантирует, что сериализация JSON минимизирована и содержит элемент "things" ("предметы") только в том случае, если в массиве присутствует "thing".

Сериализация XML:

При сериализации массивов в XML требуется, чтобы каждый элемент массива был представлен как отдельный элемент. Эти элементы должны быть последовательными и непрерывными в сериализации, и наименованием каждого элемента (наименованием тега) должно быть наименование типа элемента (наименование, которое появляется перед "[]" в типе массива). Например атрибут things ("предметы") должен быть сериализован как перечень элементов с наименованием thing ("предмет"), где "thing" - наименование структуры:

<thing>...
</thing> *

Для массива в XML нет ни одного внешнего оборачивающего элемента.

При наличии массива ссылок, т.е. когда тип "ref" относится к каждому элементу массива, массив сериализуется как перечень элементов XML без внешнего оборачивающего элемента. Наименование каждого элемента совпадает со значением "наименование элемента массива", указанном в определении атрибута. Например массив "things" типа "ref[]", где "наименование элемента массива" равно "thing", сериализуется следующим образом:

<thinghref ="xs:anyURI"/> +

5.5.12 Наборы

Как и массивы, Наборы представляют собой группы Ресурсов одного типа. В отличие от массивов Наборы являются самостоятельными Ресурсами, которые имеют свой собственный URI и к ним можно получить независимый доступ. Наборы также допускают оптимизированный и удобный сценарий взаимодействия, предоставляя специализированную совокупность операций, что позволяет избежать замены большого числа элементов при обновлении совокупности.

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

Атрибуты, которые являются Наборами, представлены как тип "collection[itemType]". Тип ресурса элементов Набора определен в скобках; например атрибут, который является Набором Ресурсов типа Machine, представлен как "collection[Machine]". Данные атрибуты сериализуются как ссылки на Ресурс Набора. Для краткости слово "ссылка" не используется в таблицах определения модели, несмотря на то, что все данные атрибуты являются ссылками: указывается тип "collection[itemType]".

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

- Наборы должны содержать атрибут id, который действует как "указатель на себя". Получение данных по этой ссылке должно возвратить Набор. В представлении XML каждый Набор должен быть обернут элементом <Collection>;

- Наборы должны содержать атрибут count, который содержит число Ресурсов в Наборе на момент, когда Набор был запрошен;

- Наборы должны содержать перечень Ресурсов, которые составляют Набор. Как и в случае массивов, при отсутствии Ресурсов в Наборе сериализация перечня должна быть опущена;

- аналогично Ресурсам в модели CIMI, каждый Ресурс в Наборе должен иметь атрибут id, который действует как "указатель на себя". Получение данных в этой ссылке должно возвратить этот единичный Ресурс, а не любой родительский Ресурс, такой как Набор или атрибут-массив;

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

Примечание - Отсутствие операции "add" в Наборе указывает, что в это время новые Ресурсы не разрешены;


- удаление Ресурсов из Набора производят с помощью операции "delete" самого Ресурса;

- если не определено иное, при удалении Набора также должны быть удалены все Ресурсы, которые составляют Набор, при этом не должны быть удалены сторонние Ресурсы, на которые ссылаются Ресурсы из Набора, подлежащие удалению;

- Наборы должны быть удалены, если владеющий ими Ресурс удален.

В Наборе присутствуют Ресурсы двух видов:

- Ресурсы инфраструктуры (перечисленные в Точке входа в облако или встроенные в объект, такие как disk в Machine);

- Промежуточный Ресурс, который содержит ссылку на ресурс инфраструктуры, имеющий наименование "целевой Ресурс".

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

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

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

Сериализация Наборов должна соответствовать следующему шаблону:

Сериализация JSON:

{"resourceURI": string,
"id": string,
"count": number,
"resourceSpecificGroupingName": /* наименование атрибута зависит от типа Ресурсов */
[
{"resourceURI": string,
"id": string,
"name": string, ?
"description": string, ?
"created": string, ?
"updated": string, ?
"properties": {string: string, +}, ?
... данные ресурса...
"operations": [
{"rel": "edit", "href": string},?
{"rel": "delete", "href": string}?
] ?
...
} +
], ?
"operations": [{"rel": "add", "href": string}?]...
}

Сериализация XML:

<Collection resourceURI ="xs:anyURI" xmlns ="//schemas.dmtf.org/cimi/1">
<id> xs:anyURI </id>
<count> xs:integer </count>
<!-- наименование атрибута зависит от типа Ресурсов -->
<ResourceSpecificElementName>
<id> xs:anyURI </id>
<name> xs:string </name>?
<description> xs:string </description>?
<created> xs:dateTime </created>?
<updated> xs:dateTime </updated>?
<property key="xs:string"> xs:string </property> *
... данные ресурса...
<operations rel="edit" href ="xs:anyURI"/>?
<operations rel="delete" href ="xs:anyURI"/>?
<xs:any> *
</ResourceSpecificElementName> *
<operations rel="add" href ="xs:anyURI"/>?
<xs:any> *
</Collection>

В данном примере атрибуты resourceURI должны содержать URI Набора или URI, определенный для Ресурса этого типа Набора, a resourceSpecificGroupingName и ResourceSpecificElementName следует заменить на наименование Ресурса, определенного для Набора, например Machine в JSON или Machine в XML.

5.5.12.1 Добавление элементов к Наборам

Вызов операции "add" Набора должен добавить к Набору новый Ресурс. Содержимое тела запроса должно быть либо представлением нового Ресурса, добавляемого к Набору, либо представлением Шаблона, связанного с новым создаваемым Ресурсом. В настоящем стандарте установлено, какие Ресурсы требуют использования Шаблона.

Например для добавления нового Volume к Набору Volume Ресурса Machine, запрос операции "add" должен быть сериализован следующим образом:

Сериализация JSON:

{"resourceURI": "//schemas.dmtf.org/cimi/1/MachineVolume",
"initialLocation": string,
"volume": {"href": string}
}

Сериализация XML:

<MachineVolume xmlns ="//schemas.dmtf.org/cimi/1">
<initialLocation> xs:string </initialLocation>
<volume href ="xs:string"/>
</MachineVolume>

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


При создании нового Ресурса, который требует использования Шаблона, операция "add" должна содержать:

- общие атрибуты в соответствии с 5.10.1;

- данные, определенные для Ресурса, необходимые для его создания. Эти данные должны представлять собой ссылку на Ресурс Шаблона, определенный для Ресурса, либо сам встроенный Ресурс Шаблона конкретного Ресурса;

- в случае XML - элемент обертки (получивший наименование по шаблону <ResourceNameCreate>).

Например для создания новый экземпляра Machine (что требует использования Шаблона) и добавления его к MachineCollection операция "добавить" MachineCollection должна быть сериализована следующим образом:

Сериализация JSON:

{"resourceURI": "//schemas.dmtf.org/cimi/1/MachineCreate"?
"name": string,?
"description": string,?
"properties": {string: string, +}, ?
"machineTemplate": {"href": string?}...
}

Сериализация XML:

<MachineCreate xmlns ="//schemas.dmtf.org/cimi/1">
<name> xs:string </name>?
<description> xs:string </ description >?
<property key="xs:string"> xs:string </property> *
<machineTemplate href ="xs:anyURI"?/>
<xs:any> *
</MachineCreate>

В MachineCollection добавляется новый экземпляр Machine:

Сериализация JSON:

{"resourceURI": "//schemas.dmtf.org/cimi/1/Machine",
"id": string,
"name": string...
}

Сериализация XML:

<Machine xmlns ="//schemas.dmtf.org/cimi/1">
<id> xs:anyURI </id>
<name> xs:string </name...
</Machine>

Обработка операции "add" должна соответствовать семантике, определенной в 4.2.1.1.

Независимо от того, используется ли Шаблон, операция "add" должна создать новый Ресурс и добавить его к Набору, и ссылка (URI) на новую запись будет возвращена в ответном сообщении в заголовке HTTPLocation.

5.5.13 Тип "any"

Некоторые атрибуты являются полиморфными и могут содержать различные типы данных, перечень которых указан в их описании. В таких случаях в модели представления тип атрибута должен быть обозначен "any".

5.5.14 Пустые значения атрибута

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

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

5.6 Единицы

Некоторые Ресурсы, определенные в данной спецификации, имеют атрибуты, описывающие количество чего-либо, принадлежащего Ресурсу или связанного с ним. Например Ресурс Machine имеет атрибут memory, который описывает "размер памяти, выделенной для этой машины". Допустимые единицы измерения этих атрибутов приведены в таблице 4. Их значения установлены в [6]. Их числовые эквиваленты приведены для удобства Пользователей.

Таблица 4 - Числовые эквиваленты для атрибутов

5.7 Семантика отношений

Ссылка между двумя экземплярами Ресурса имеет семантику простой "ассоциации". Если не указано иное, (а) на экземпляр могут быть ссылки из других экземпляров Ресурсов, т.е. будет "совместно использоваться", и (b) - экземпляр Ресурса, на который указывает ссылка, не будет затронут при удалении экземпляра Ресурса, который ссылается на него (т.е. операция Delete по умолчанию считается "shallowdelete").

Включение подресурса в другой Ресурс имеет семантику "агрегации" (или отношение целого к части в UML). Если не указано иное, (а) вложенный подресурс не может совместно использоваться несколькими экземплярами Ресурса и (b) - при удалении экземпляра Ресурса вложенные экземпляры подресурсов также удаляются.

5.8 Операции

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

Атрибут "Состояние" тех Ресурсов, которые имеют данный атрибут, должен изменять значение только в следующих случаях:

- операция выполнена на данном Ресурсе, и эта операция требует изменения состояния или

- произошла ошибка, в этом случае атрибут "Состояния" должен получить значение "ОШИБКА".

Например для операции "start" Ресурса Machine требуется, чтобы состояния STARTING и STARTED поддерживались Machine одновременно, поскольку Machine будет отсутствовать в состоянии STARTED только после вызова другой операции, если не произошла ошибка.

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

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

b) Новое состояние Ресурса. В этом случае также должна быть создана новая операция, которая приводит к этому состоянию. Другими словами, операция, определенная Поставщиками, должна выполняться прежде, чем может быть достигнуто состояние, определенное Поставщиками.

c) Новая операция, которая обеспечивает переходы между двумя состояниями, определенными Поставщиками.

5.9 Альтернативные форматы модели

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

Данная модель также доступна в формате CIM/MOF [CIMI-CIM].

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

5.10 Ресурсы

В настоящем подразделе приведены детали атрибутов Ресурсов, определенных моделью CIMI.

5.10.1 Общие атрибуты

За исключением Ресурсов ResourceMetadata и Ресурсов Набора (см. 5.5.12) у всех Ресурсов, описанных в настоящем стандарте, есть общие атрибуты, приведенные в таблице 5. Для основных и вторичных ресурсов CIMI существуют различные требования. Все Ресурсы, которые могут быть типами элемента для Наборов в CloudEntryPoint, являются основными ресурсами CIMI. Все остальные Ресурсы являются вторичными ресурсами CIMI. Исключением из этого правила является CloudEntryPoint, который считается основным Ресурсом.

Например Machine является основным ресурсом CIMI, поскольку CloudEntryPoint имеет Набор, у которого Machine является типом элементов. Однако, например, MachineVolume является вторичным ресурсом CIMI, поскольку у CloudEntryPoint нет Набора, у которого MachineVolume был бы типом элемента.

Таблица 5 - Общие атрибуты

Следующие псевдосхемы описывают сериализацию данных атрибутов в JSON и в XML:

Сериализация JSON:

"id": string,
"name": string, ?
"description": string, ?
"created": string, ?
"updated": string, ?
"properties": {string: string, +}, ?

Сериализация XML:

<id>xs:anyURI/ </id>
<name>xs:string</name> ?
<description>xs:string</description> ?
<created>xs:dateTime</created> ?
<updated>xs:dateTime</updated> ?
<property key="xs:string">xs:string</property> *

5.11 Метаданные Ресурса

Потребитель в соответствии с настоящим стандартом должен иметь возможность обнаружения метаданных, связанных с каждым поддерживаемым типом Ресурса. Это позволяет Потребителям узнавать ограничения, наложенные Поставщиками на определенные атрибуты CIMI, а также обнаруживать дополнительные атрибуты или операции, которые могут быть определены Поставщиком. Экземпляр ResourceMetadata содержит метаданные, описывающие определенный тип Ресурса, например Network или Machine, включая любые определенные Поставщиком возможности или особенности. Механизм доступа к метаданным определяется протоколом.

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


Метаданные каждого Ресурса должны содержать сведения, приведенные в таблице 6.

Таблица 6 - Атрибуты ResourceMetadata