ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

ГОСТР

ИСО/МЭК 19831-

2017

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

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

(ISO/IEC 19831:2015, ЮТ)

Издание официальное

Москва

Стандартинформ

2017

Предисловие

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

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

3    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 22 февраля 2017 г. № 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 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

© Стандартинформ, 2017

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

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

Ор. Считается, что Ресурс удовлетворяет критериям поиска, если какое-либо из свойств в Ресурсах будет соответствовать указанному РгорЕхрг.

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

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

«ог», «and»    : Булевское значение/атрибут;

'<', '<=', '=', '>=', «>', '!='    :    Значение/атрибут целого типа или дата;

'=', '!='    : Строковое значение/атрибут.

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

Примеры

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

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

/Machines

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

/Machines/123

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

IMachines/123/disks

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

/Machines/123/Voiumes

Чтобы отфильтровать MachineCollection так, чтобы возвращались только экземпляры Machine с атрибутом "пате" равным "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) первого объекта Набора для включения в ответ, a "$last" указывает на порядковое положение (начиная с 1) последнего объекта Набора для включения в ответ. Потребители не обязаны использовать их одновременно. Если $first будет определен, a $last не будет, то подразумеваемым значением $last должно быть числовое значение последнего объекта в Наборе. С другой стороны, если $last будет определен, a $first не будет, то подразумеваемым значением $first должна быть 1.

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

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

7

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

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

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

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

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

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

? $select=name,state

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

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

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

?$select=name, description

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

?$select=count, operations

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

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

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

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

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

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

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

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

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

"name": {"href: string}

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

"лате": {

"href: string,

... атрибуты ресурса, на который указывает ссылка...

}

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

<namehref = "xs:anyURI"/>

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

<name href = "xs:anyURI">

... атрибуты ресурса, на который указывает ссылка...

</name>

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

Формат параметра запроса $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 появляется более одного раза, то второе и последующие его появления должны быть проигнорированы.

9

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

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

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

?$огбегЬу=наименованиеАтрибута/;а5с|;с/е5с/, ...

Выражение $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 по атрибуту "сри" в порядке убывания, а затем по атрибуту "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    Поддержка завершающего тега (ЕТад)

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

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

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 = "http://schemas.dmtf.0rg/cimi/l "> coperation rel="xs:anyURI" href ="xs:anyURI"/> *

</Resource>

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

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

{"operations": [

{"rel": "edit", "href: "<editURI>"}

]

}

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

<Resource xmlns="http://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.

11

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

НТТР/1.1 POST<addURI>

Host: <hostname>

Accept: application / (json|xml)

Content-Type: application / (json|xml)

Content-Length: <length>

<сериализация запроса создания нового ресурса>

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

Многие запросы create определены таким образом, чтобы передавать Шаблон нового Ресурса. Такие запросы create допускают, чтобы Шаблон передавался по ссылке или по значению. Например создание новой Machine может выглядеть следующим образом (в данном примере используется XML): <MachineCreate xmlns = "http://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": "http://schemas.dmtf.0rg/cimi/l/Res0urceCreate",

"name": "myResourceName"?

"description": "Мое описание ресурса"?

"properties": {"prop1name":"prop1value", +}?

"resourceTemplate": {

<в этом случае шаблон передан значением>

}

}

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

{"resourceURI": "http://schemas.dmtf.0rg/cimi/l/Res0urceCreate",

"name": "myResourceName"?

"description": "Мое описание ресурса"?

"properties": {"prop1name":"prop1value", +}?

"resourceTemplate": {"href': строка,

<в этом случае могут быть добавлены некоторые пары атрибут/значение шаблона для переопределения значения в шаблоне, на который указывает ссылка>

}

}

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

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

12

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

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

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

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

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

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

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

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

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

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

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

в сериализации ХМ1_для этого атрибута.

Примеры

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

{ "resourceURI": "http://schemas.dmtf.Org/cimi/1/MachineCreate",

"name": "myMachine123",

"description": "Машина, которая будет подключена к существующей сети",

"machineTemplate": {

<в этом случае шаблон передан по значению, т. е. парами атрибут/значение для Шаблона Machine-Template. Нижеприведенпримердля networklnterfaces>

"networklnterfaces": [

{ "addresses": [{"address": {"href": "http://example.com/addresses/addl"}},

{"address": {"href”: "http://example.com/addresses/add2"}}],

"network": {"href”: "http://example.com/networks/netl"},

"state": "ACTIVE"}

]

}

}

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

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

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

13

Пример

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

{ "resourceURI": "http://schemas.dmtf.Org/cimi/1/MachineCreate",

"name": "myMachine456",

"description": "Машина подключена к существующему тому",

"machineTemplate": {

"href": "http://exampie.com/MachineTempiates/72000",

Credential": {"href”: "http://exampie.com/myCredentiai"}

"networkinterfaces": [

{ "addresses": [{"address": {"href': "http://example.com/addresses/add4"}},

{"address": {"href": "http://example.com/addresses/add5"}}],

"network": {"href': "http://example.com/networks/netl"},

"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, чтобы уменьшить возможности ошибочного обновления атрибутов устаревшими данными.

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

Запрос 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 ОК

Content-Type: application / (json|xml)

Content-Length: <длина>

<сериализация обновленного ресурса>

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

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

Для обновления конкретных атрибутов Ресурса только верхнего уровня Потребитель может включать в представление Ресурса в теле запроса HTTP только измененные атрибуты. Для выполнения такого запроса URI для Ресурса должно включать в себя атрибуты, которые будут изменены как перечень значений параметров запроса, разделенных запятой, URI должен иметь следующий вид: http://example.com/resource?$select=attribute1,attribute2...

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

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

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

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

В соответствии с общей семантикойРиТ, определенной ранее, любой атрибут исходного (полного) Ресурса, включенный в запрос 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 удален.

15

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

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

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

DELETE<de/efel/R/>HTTP/1.1 НоэЬснаименование узла>

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

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

НТТР/1.1 200 ОК

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

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

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

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

НТТР/1.1 POSTcURI операции>

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 в ответном сообщении. Возвращаемый перечень атрибутов Ресурса определяется реализацией и основывается на том, сколько информации доступно в то время, пока генерируется ответное сообщение, но он должен быть совместим с представлением полного

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

Содержание

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

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

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

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

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

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

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

4.1    Введение .......................................................................4

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

4.3    Поддержка OVF.................................................................17

5    Модель............................................................................17

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

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

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

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

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

5.6    Единицы.......................................................................26

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

5.8    Операции ......................................................................27

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

5.10    Ресурсы ......................................................................27

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

5.12    Точка входа в облако............................................................39

5.13    Ресурс System и отношения.......................................................44

5.14    Ресурс Machine и отношения .....................................................66

5.15    Ресурсы Volume и отношения.....................................................98

5.16    Сетевые ресурсы и отношения...................................................109

5.17    Ресурсы мониторинга и отношения ...............................................138

6    Вопросы безопасности..............................................................165

Приложение А (обязательное) Поддержка OVF в CIMI......................................166

Приложение В (справочное) XML-схема .................................................167

Приложение С (справочное) История изменений..........................................168

Приложение ДА (справочное) Сведения о соответствии ссылочных международных стандартов

национальным стандартам..............................................169

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

Ресурса. При выполнении операции 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(CM. 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": "http://example.com/MyResource",

"attribute": "value"

}

17

Введение

Настоящий стандарт подготовлен Рабочей группой по управлению облачными вычислениями DMTF¹). Стандарт определяет логическую модель для менеджмента ресурсов в категории «Инфраструктура как услуга».

^ DMTF — некоммерческая ассоциация, объединяющая представителей промышленности для продвижения средств управления предприятиями и системами и обеспечения совместимости.

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

МОДЕЛЬ И ПРОТОКОЛ ИНТЕРФЕЙСА УПРАВЛЕНИЯ ОБЛАЧНОЙ ИНФРАСТРУКТУРОЙ (CIMI) Интерфейс для управления облачной инфраструктурой

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

cloud infrastructure

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

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 или более);

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

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

и «|»;

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

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

Наименования операций 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, T. Dierks and E. Rescorla, The Transport Layer Security (TLS) Protocol Version 1.2 (T. Диркси Э. Рескорла, Протокол безопасности транспортного уровня, Версия 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 г.)

2

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

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): Особый вид Ресурса, содержащий набор других Ресурсов и снабженный представлением и сериализацией в соответствии с настоящим стандартом и являющийся синонимом термина «набора С1М1».

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

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

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

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

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

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

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

4.1 Введение

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

4

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

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

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

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

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

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

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

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

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

Префикс Пространства имен XML Стандарт cimi http://schemas.dmtf.Org/cimi/1 Настоящий стандарт XS http://www.w3.org/2001/XMLSchema XML Схема, Часть 2 [18]

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

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

Демонстрационные URI, используемые в настоящем стандарте, не являются нормативными, и используемые шаблоны не должны интерпретироваться как руководство для реализаций. Например любой из следующих URI может использоваться Поставщиками для ссылки на конкретный Ресурс Machine: http://example.com/Machines/12345 http://example.com/Machines?id=12345 http://example.eom/12345 http://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 для выделения подмножества запрашиваемого ресурса.

5

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

Данный атрибут необязателен для его использования Потребителями. Если он присутствует, значение этого атрибута должно соответствовать атрибуту «typeURI» соответствующего Ресурса Re-sourceMetadata (см. 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 IntValue ::= /[0-9]+/

DateValue ::= ? в соответствии с определением XML Схемы ?

StringValue ::= "..." |'...'

BoolValue ::= 'true' | 'false'

PropExpr ::= 'property!' StringValue ']' Op StringValue

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

6