1
Доступно поисковых запросов: 1 из 2
Следующий пробный период начнётся: 09 февраля 2023 в 15:21
Снять ограничение

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

Модель и протокол интерфейса управления облачной инфраструктурой (CIMI). Интерфейс для управления облачной инфраструктурой
Действующий стандарт
Проверено:  01.02.2023

Информация

Название Модель и протокол интерфейса управления облачной инфраструктурой (CIMI). Интерфейс для управления облачной инфраструктурой
Название английское Cloud Infrastructure Management Interface (CIMI) Model and RESTful HTTP-based Protocol. An Interface for Managing Cloud Infrastructure
Дата актуализации текста 05.05.2017
Дата актуализации описания 01.01.2023
Дата издания 20.04.2017
Дата введения в действие 01.01.2018
Область и условия применения Настоящий стандарт распространяется на модель и протокол для административных взаимодействий между поставщиком службы облачных вычислений категории «Инфраструктура как услуга» (далее - служба IaaS) и потребителем службы IaaS. В стандарте представлены модели основных ресурсов службы IaaS (машины, хранилище и сеть) для обеспечения административного доступа потребителя к реализации службы IaaS и содействия переносимости между реализациями, соответствующими указанным в стандарте. Стандарт определяет протокол в стиле REST над Однако базовая модель не зависит от НТТР, поэтому существует возможность отобразить ее на другие протоколы
Опубликован Официальное издание. М.: Стандартинформ, 2017 год
Утверждён в Росстандарт

     
     ГОСТ Р ИСО/МЭК 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

Префикс

Пространства имен 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.com/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 для выделения подмножества запрашиваемого ресурса.

В сериализации 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") ограничен на основании типа значения и атрибута. Допустимыми операторами являются:

"or", "and"

: Булевское значение/атрибут;

'<', '<=', '=', '>=', ">', '!='

: Значение/атрибут целого типа или дата;

'=', '!='

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


Потребители могут включать несколько фильтров в один 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 = "http://schemas.dmtf.org/cimi/1">

<operation 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.

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

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 = "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.org/cimi/1/ResourceCreate",

"name": "myResourceName"?

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

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

"resourceTemplate": {

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

}

}

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

{"resourceURI": "http://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": "http://schemas.dmtf.org/cimi/1/MachineCreate",

"name": "myMachine123",

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

"machineTemplate": {

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

"networkInterfaces": [

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

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

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

"state": "ACTIVE"}

]

}

}

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

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

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

          

Пример

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

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

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

"machineTemplate": {
     "href": "http://example.com/MachineTemplates/72000",
     Credential": {"href": "http://example.com/myCredential"}
     "networkInterfaces": [

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

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

"network": {"href": "http://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 должен иметь следующий вид:

http://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": "http://example.com/MyResource",

"attribute": "value"

}

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

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

<MyResource xmlns = "http://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 - Структура, имеющая наименование

Наименование

summary

Атрибут

Тип

Описание

low

integer

Число произошедших событий с незначительной степенью важности

medium

integer

Число произошедших событий со средней степенью важности

high

integer

Число произошедших событий с высокой степенью важности

critical

integer

Число произошедших событий с критической степенью важности


Сериализация 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

Базовый URI

Относительный URI

Абсолютный URI

http://example.com/

p1/file

http://example.com/p1/file

http://example.com/c1/

p1/file

http://example.com/c1/p1/file

http://example.com/c1/c2/

p1/file

http://example.com/c1/c2/p1/file


При использовании относительных 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 = "http://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": "http://schemas.dmtf.org/cimi/1/MachineVolume",

"initialLocation": string,

"volume": {"href": string}

}

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

<MachineVolume xmlns = "http://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": "http://schemas.dmtf.org/cimi/1/MachineCreate"?

"name": string,?

"description": string,?

"properties": {string: string, +}, ?

"machineTemplate": {"href": string?}...

}

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

<MachineCreate xmlns = "http://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": "http://schemas.dmtf.org/cimi/1/Machine",

"id": string,

"name": string...

}

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

<Machine xmlns = "http://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 - Числовые эквиваленты для атрибутов

Единица измерения

Значение

Килобайт

10^3

Мегабайт

10^6

Гигабайт

10^9

Терабайт

10^12

Петабайт

10^15

Эксабайт

10^18

Зеттабайт

10^21

Йоттабайт

10^24

Кибибайт

2^10

Мебибайт

2^20

Гибибайт

2^30

Тебибайт

2^40

Пепибайт

2^50

Эксбибайт

2^60

Эебибайт

2^70

Йобибайт

2^80

     

     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 - Общие атрибуты

Атрибут

Тип

Описание

id

URI

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

Ограничения для основных и вторичных Ресурсов:

Поставщик: обязательная поддержка; неизменяемый.

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

name

string

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

Ограничения для основных Ресурсов:

Поставщик: обязательная поддержка; изменяемый.

Потребитель: необязательная поддержка; чтение-запись.

Ограничения для вторичных Ресурсов:

Поставщик: необязательная поддержка; изменяемый.

Потребитель: необязательная поддержка; чтение-запись

description

string

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

Ограничения для основных Ресурсов:

Поставщик: обязательная поддержка; изменяемый.

Потребитель: необязательная поддержка; чтение-запись.

Ограничения для вторичных Ресурсов:

Поставщик: необязательная поддержка; изменяемый.

Потребитель: необязательная поддержка; чтение-запись

created

dateTime

Метка времени, когда данный Ресурс был создан. Формат должен быть однозначным, а значение неизменяемым.

Ограничения для основных и вторичных Ресурсов:

Поставщик: необязательная поддержка; неизменяемый.

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

updated

dateTime

Момент времени последнего явного обновления атрибута Ресурса.

Примечание - Несмотря на то, что такие операции как "stop" неявно изменяют атрибут "state", они не изменяют атрибуту "updated"


Ограничения для основных и вторичных Ресурсов:

Поставщик: необязательная поддержка; изменяемый.

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

properties

map

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

Один и тот же ключ не должен использоваться более одного раза в рамках атрибута "properties".

Каждое свойство должно содержать следующие вложенные данные

Наименование

property

Данные

Тип

Описание

ключ

string

Наименование свойства.

Ограничения:

Поставщик: обязательная поддержка; изменяемый.

Потребитель: обязательная поддержка; чтение-запись

значение

string

Значение свойства.

Ограничения:

Поставщик: обязательная поддержка; изменяемый.

Потребитель: обязательная поддержка; чтение-запись

Ограничения для основных Ресурсов:

Поставщик: обязательная поддержка; изменяемый.

Потребитель: необязательная поддержка; чтение-запись.

Ограничения для вторичных Ресурсов:

Поставщик: необязательная поддержка; изменяемый.

Потребитель: необязательная поддержка; чтение-запись


Следующие псевдосхемы описывают сериализацию данных атрибутов в 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

Наименование

ResourceMetadata

Тип URI

http://schemas.dmtf.org/cimi/1/ResourceMetadata

Атрибут

Тип

Описание

id

URI

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

Ограничения:

Поставщик: обязательная поддержка; неизменяемый.

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

typeURI

URI

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

Ограничения:

Поставщик: обязательная поддержка; изменяемый.

Потребитель: обязательная поддержка; чтение-запись

name

String

Наименование описываемого типа Ресурса.

Ограничения:

Поставщик: обязательная поддержка; изменяемый.

Потребитель: обязательная поддержка; чтение-запись

attributes

attribute

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

Каждый атрибут должен содержать следующие вложенные данные

Наименование

Атрибут

Данные

Тип

Описание

name

string

Наименование атрибута.

Ограничения:

Поставщик: обязательная поддержка; изменяемый.

Потребитель: обязательная поддержка; чтение-запись

namespace

URI

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

Ограничения:

Поставщик: обязательная поддержка; изменяемый.

Потребитель: обязательная поддержка; чтение-запись

type

string

Тип данных атрибута. Не должен присутствовать при описании атрибута, определенного CIMI, но должен присутствовать при описании атрибута, определенного вне CIMI.

Ограничения:

Поставщик: обязательная поддержка; изменяемый.

Потребитель: обязательная поддержка; чтение-запись

required

Boolean

Указывает, требует ли данный Ресурс присутствия данного атрибута. Если он отсутствует, то подразумеваемое значение "false".

Ограничения:

Поставщик: обязательная поддержка; изменяемый.

Потребитель: обязательная поддержка; чтение-запись

value constraints

any

Данные, определенные типом, которые описывают любые ограничения на значения этого атрибута. Если они отсутствуют, то ограничений нет.

Примечание - Сериализация ограничений на значения должна быть определена типом атрибута (см. 5.11.1).


Ограничения:

Поставщик: обязательная поддержка; изменяемый.

Потребитель: обязательная поддержка; чтение-запись

Ограничения:

Поставщик: необязательная поддержка; изменяемый.

Потребитель: необязательная поддержка; чтение-запись

capabilities

capability

Ряд метаданных, определенных Поставщиком, которые могут применять функции, предоставленные этим Поставщиком.

Каждая возможность должна содержать следующие вложенные*
использоваться Потребителем для обнаружения возможности

capabilities

capability

Наименование

capbility

Данные

Тип

Описание

name

string

Наименование возможности.

Ограничения:

Поставщик: обязательная поддержка; изменяемый.

Потребитель: необязательная поддержка; чтение-запись

uri

URI

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

Ограничения:

Поставщик: обязательная поддержка; изменяемый.

Потребитель: обязательная поддержка; чтение-запись

description

string

Описание семантики возможности.

Ограничения:

Поставщик: обязательная поддержка; изменяемый.

Потребитель: необязательная поддержка; чтение-запись

value

any

Значение возможности. Конкретный тип зависит

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

Ограничения:

Поставщик: обязательная поддержка; изменяемый.

Потребитель: обязательная поддержка; чтение-запись

Ограничения:

Поставщик: необязательная поддержка; изменяемый.

Потребитель: необязательная поддержка; чтение-запись

actions

action [ ]

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

Примечание - данный атрибут вызывается "actions", чтобы не конфликтовать с собственным атрибутом "operations" Ресурса ResourceMetadata.


Каждая операция должна содержать следующие вложенные данные

Наименование

Данные

Тип

Описание

name

string

Наименование операции.

Ограничения:

Поставщик: обязательная поддержка; изменяемый.

Потребитель: обязательная поддержка; чтение-запись

uri

URI

URI, однозначно определяющий операцию на глобальном уровне.

Ограничения:

Поставщик: обязательная поддержка; изменяемый.

Потребитель: обязательная поддержка; чтение-запись

description

string

Описание семантики операции.

Ограничения:

Поставщик: обязательная поддержка; изменяемый.

Потребитель: необязательная поддержка; чтение-запись

method

string

Глагол для выполнения операции, зависящий от протокола

Ограничения:

Поставщик: обязательная поддержка; изменяемый.

Потребитель: обязательная поддержка; чтение-запись

Input Message

string

mimeType тела сообщения запроса; может зависеть от формата модели, выбранного Поставщиком.

Ограничения:

Поставщик: обязательная поддержка; изменяемый.

Потребитель: обязательная поддержка; чтение-запись

output-Message

string

mimeType тела сообщения-ответа; может зависеть от формата модели, выбранного Поставщиком.

Ограничения:

Поставщик: обязательная поддержка; изменяемый.

Потребитель: обязательная поддержка; чтение-запись

Ограничения:

Поставщик: необязательная поддержка; изменяемый.

Потребитель: необязательная поддержка; чтение-запись

________________

* Текст документа соответствует оригиналу. - Примечание изготовителя базы данных.     

          

При реализации или использовании ResourceMetadata Поставщики и Потребители должны использовать синтаксис и семантику его атрибутов в соответствии с таблицей 6, а также таблицами, описывающими встроенные Ресурсы или связанные Наборы. Потребитель и Поставщик должны сериализовать данный Ресурс в соответствии со следующим описанием. Следующие псевдосхемы описывают сериализацию Ресурса и в JSON и в XML (см. 1.3):

Тип медиа JSON: application/json

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

{ "resourceURI": "http://schemas.dmtf.org/cimi/1/ResourceMetadata",

"id": string,

"typeURI" : string,

"name": string,

"attributes": [

{ "name": string,

"namespace": string, ?

"type": string, ?

"required": boolean, ?

...value constraints...? } *

], ?

"capabilities": [

{ "name": string, ?

"uri": string,

"description": string, ?

"value": any } *

], ?

"actions" : [

{ "name": string,

"uri": string,

"description": string, ?

"method": string,

"inputMessage": string, ?

"outputMessage": string ?}, *

], ?

"operations": [

{ "rel": "edit", "href": string}, ?

{ "rel": "delete", "href": string}?

] ?

...

}

Тип медиа XML: application/xml:

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

<ResourceMetadata xmlns="http://schemas.dmtf.org/cimi/1">

<id>xs:anyURI</id>

<name>xs:string</name>

<typeURI> xs:anyURI </typeURI>

<attribute name="xs:string" namespace="xs:anyURI"? type="xs:string"

required="xs:boolean"? >

...value constraints...?

</attribute> *

<capability name="xs:string"? uri="xs:anyURI" description="xs:string"?>

xs.any*

</capability> *

<action name="xs:string" uri="xs:anyURI" description="xs:string"?

method="xs:string" inputMessage="xs:string"?

outputMessage="xs:string"? /> *

<operation rel="edit" href="xs:anyURI"/> ?

<operation rel="delete" href="xs:anyURI"/> ?

<xs:any>*

</ResourceMetadata>

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

5.11.1 Сериализация ограничений значения атрибута

Следующие примеры описывают значения, синтаксис и сериализацию значения "value constraints" (податрибут "attributes"), имеющего тип "any".

type ="string"

JSON должен иметь форму:

"values": [string, +] ?

XML должен иметь форму:

<value>xs:string</value> *

type="integer"

JSON должен иметь форму:

"values": [number, +], ?

"ranges": [ { "low": number, "high": number}, +] ?

XML должен иметь форму:

<value>xs: integer</value> *

<range low="xs:integer" high="xs:integer"/> *

Итоговое пространство значений атрибута "integer" - объединение всех значений и диапазонов.

type = "boolean"

JSON должен иметь форму:

"value": boolean?

XML должен иметь форму:

<value>xs:boolean</value> ?

Допускается только одно значение "value", которое будет указывать на то, какой из атрибутов требуется: "true" или "false".

5.11.1.1 Примеры

В следующем примере представлен образец документа метаданных для Ресурса VolumeConfiguration в XML, перечисляющий допустимые значения для атрибута "format" и содержащий развернутый строковый атрибут "Location":

<ResourceMetadata xmlns="http://schemas.dmtf.org/cimi/1">

<id> http://example.org/types/VC </id>

<typeURI> http://schemas.dmtf.org/cimi/1/VolumeConfiguration </typeURI>

<name> VolumeConfiguration </name>

<attribute name="format" type="string" required="false">

<value> ext4 </value>

<value> ntfs </value>

</attribute>

<attribute name="Location" namespace="http://example.org/" type="string"/>

</ResourceMetadata>

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

<ResourceMetadata xmlns="http://schemas.dmtf.org/cimi/1">

<id> http://example.org/types/VC </id>

<typeURI> http://schemas.dmtf.org/cimi/1/VolumeConfiguration </typeURI>

<name> VolumeConfiguration </name>

<attribute name="format" type="string" required="false">

<value> ext4 </value>

<value> ntfs </value>

</attribute>

<attribute name="Location" namespace="http://example.org/" type="string" required="true">

<value> NYC </value>

<value> LAX </value>

</attribute>

</ResourceMetadata>

В следующем примере указан тот же самый Ресурс VolumeConfiguration, сериализованный в JSON:

{ "resourceURI": "http://schemas.dmtf.org/cimi/1/VolumeConfiguration",

"id": "http://example.org/types/VC",

"typeURI": "http://schemas.dmtf.org/cimi/1/VolumeConfiguration",

"name": "VolumeConfiguration",

"attributes": [

{ "name": "format",

"type": "string",

"required": false,

"values": [ "ext4", "ntfs" ]

},

{ "name": "Location",

"namespace": "http://example.org",

"type": "string",

"required": true,

"values": [ "NYC", "LAX" ]

}

]

}

В следующем примере представлен Ресурс Volume, сериализованный в JSON, который обеспечивает действие сжатия данных. В данном примере возвращенный метод (POST) предназначен для протокола HTTPCIMI, однако при реализации другого протокола (например, SOAP), метод будет иным:

{ "resourceURI": "http://schemas.dmtf.org/cimi/1/VolumeConfiguration",

"id": "http://example.org/types/V",

"typeURI": "http://schemas.dmtf.org/cimi/1/Volume",

"name": "Volume",

"actions": [

{

"name": "compress",

"uri": "http://example.org/cimi/action/compress"

"description": "Compress the data stored in the Volume",

"method": "POST"

}

]

}

5.11.2 Возможности

URI возможностей, определенных в настоящем стандарте, приведены в таблице 7. Поставщики могут определить новые URI, причем рекомендуется, чтобы данные URI указывали на документы с описанием, по которому Потребители могут получить сведения о новой возможности. Графа "Наименование Ресурса" содержит наименование Ресурса, в чьем ресурсе ResourceMetadata может содержаться указанная возможность. Графа "Наименование возможности" содержит наименование указанной возможности, которое должно быть уникальным в рамках соответствующего Ресурса. URI каждой возможности создается путем конкатенации "Наименовании Ресурса", наклонной черты (/) и "Наименовании Возможности" к http://schemas.dmtf.org/cimi/1/capability/. Например возможность "InitialState" Ресурса Machine должна иметь URI: http://schemas.dmtf.org/cimi/1/capability/Machine/InitialState

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

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

- для возможностей булевского типа: то же, что и значение "false";

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

Таблица 7 - URI возможностей

Наименование ресурса

Наименование возможности

Описание

CloudEntryPoint

ExpandParameter

Если "true", Поставщик должен поддерживать параметр запроса $expand

CloudEntryPoint

FilterParameter

Если "true", Поставщик должен поддерживать параметр запроса $filter

CloudEntryPoint

FirstParameter

Если "true", Поставщик должен поддерживать оба параметра запроса: $first и $last

CloudEntryPoint

SelectParameter

Если "true", Поставщик должен поддерживать параметр запроса $select

CloudEntryPoint

FormatParameter

Если "true", Поставщик должен поддерживать параметр запроса $format

CloudEntryPoint

OrderByParameter

Если "true", Поставщик должен поддерживать параметр запроса $orderby

CloudEntryPoint

QueryPathNotation

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

CloudEntryPoint

MaxPropertyItems

Если установлено, Поставщик должен поддерживать атрибут "properties" с числом элементов, не превосходящим значение, определенное данной возможностью

System

SystemComponent-
TemplateByValue

Если "true", Поставщик должен поддерживать спецификацию включения ComponentTemplate по значению в SystemTemplates

Machine

DefauItInitialState

Если данная возможность установлена и не указано иное (например, атрибутом "initialState" ресурса MachineTemplate), Поставщик должен установить состояние нового экземпляра Machine равным значению данной возможности при условии, что значение совместимо с возможностью InitialStates

Machine

InitialStates

Если данная возможность установлена и используется MachineTemplate с атрибутом "initialState", Потребитель должен использовать значение initialState из совокупности значений данной возможности

Machine

MachineConfig-
ByValue

Если "true", Поставщик должен поддерживать включение MachineConfiguration по значению, а MachineTemplateByValue также должно иметь значение "true"

Machine

MachineCredential-
ByValue

Если "true", Поставщик должен поддерживать включение Credential по значению в операциях create для Machine, а MachineTemplateByValue также должна иметь значение "true"

Machine

MachineImageBy-
Value

Если "true", Поставщик должен поддерживать включение MachineImage по значению в операциях create для Machine, а MachineTemplateByValue также должна иметь значение "true"

Machine

MachineVolume-TemplatesByValue

Если "true", Поставщик должен поддерживать включение VolumeTemplate по значению в операциях create для Machine, а MachineTemplateByValue также должна иметь значение "true"

Machine

MachineTemplateBy
Value

Если "true", Поставщик должен поддерживать включение MachineTemplate по значению в операциях create для Machine

Machine

MachineStopForce

Если "true", Поставщик должен поддерживать опцию "force" операций stop и restart для Machine

Machine

MachineStopForce
Default

Если "true", Поставщик должен принудительно останавливать экземпляры Machine (имитируя отключение питания), если нет иных указаний. В другом случае Поставщик должен использовать регламентные процедуры остановки

Machine

RestoreFromImage

Если "true", Поставщик должен поддерживать восстановление экземпляров Machine из MachineImage, не являющихся снимком состояния

Machine

UserData

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

Machine

MachineAvailability
Level

Если "true", Поставщик поддерживает понятие уровня готовности для Ресурса Machine. Уровень готовности и ограничения к его значениям доступны как атрибут расширения ResourceMetadata для Machine и MachineTemplate

Credential

CredentialTemplateBy-
Value

Если "true", Поставщик должен поддерживать включение CredentialTemplate по значению в операциях create для Credential

Volume

SharedVolume-
Support

Если "true", Поставщик должен поддерживать возможность совместного использования экземпляра Ресурса Volume несколькими экземплярами Machine

Volume

VolumeConfigBy-
Value

Если "true", Поставщик должен поддерживать включение VolumeConfiguration по значению в операциях create для Volume, а VolumeTemplateByValue должна иметь значение "true"

Volume

VolumeImageBy-
Value

Если "true", Поставщик должен поддерживать включение VolumeImage по значению в операциях create для Volume, а VolumeTemplateByValue должна иметь значение "true"

Volume

VolumeSnapshot

Если "true", Поставщик должен поддерживать создание нового VolumeImage, со ссылкой на существующий Volume

Volume

VolumeTemplateBy-
Value

Если "true", Поставщик должен поддерживать включение VolumeTemplate по значению в операциях create для Volume

Volume

VolumeAvailability Level

Если "true", Поставщик должен поддерживать понятие уровня готовности для Ресурса Volume. Уровень готовности и ограничения к его значениям доступны как атрибут расширения ResourceMetadata для Volume и VolumeTemplate

Network

NetworkConfigBy-
Value

Если "true", Поставщик должен поддерживать включение NetworkConfiguration по значению в операциях create для Network

Network

NetworkTemplate-
ByValue

Если "true", Поставщик должен поддерживать включение NetworkTemplate по значению в операциях create для Network

Network

DefauItInitialState

Если данная возможность установлена и не указано иное (например, атрибутом "initialState" Ресурса NetworkTemplate), Поставщик должен установить состояние нового экземпляра Network равным значению данной возможности при условии, что значение совместимо с возможностью InitialState

Network

InitialStates

Если данная возможность установлена и используется NetworkTemplate с атрибутом "initialState", то Потребитель должен использовать значение initialState из совокупности значений этой возможности

NetworkPort

NetworkPort-
ConfigByValue

Если "true", Поставщик должен поддерживать включение NetworkPortConfiguration по значению в операциях create для NetworkPort

NetworkPort

NetworkPort-
TemplateByValue

Если "true", Поставщик должен поддерживать включение NetworkPortTemplate по значению в операции create для NetworkPort

NetworkPort

DefauItInitialState

Если данная возможность установлена и не указано иное (например, атрибутом "initialState" Ресурса NetworkPortTemplate), Поставщик должен установить состояние нового экземпляра NetworkPort равным значению данной возможности при условии, что значение совместимо с возможностью InitialStates

NetworkPort

InitialStates

Если данная возможность установлена и используется NetworkPortTemplate с атрибутом "initialState", Потребитель, должен использовать значение initialState из совокупности значений этой возможности

ForwardingGroup

MixedNetwork

Если "true", Поставщик должен поддерживать ForwardingGroup, которые могут иметь как частные, так и общедоступные соединения одновременно. В противном случае у ForwardingGroup должны быть только либо частные, либо общедоступные соединения в одно и то же время

Job

JobRetention

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

Meter

MeterConfigByValue

Если "true", Поставщик должен поддерживать включение MeterConfiguration по значению в операциях create для Meter

Meter

MeterTemplate-
ByValue

Если "true", Поставщик должен поддерживать включение MeterTemplate по значению в операциях create для Meter

EventLog

Соединенный

Если "true", Поставщик должен удалить ресурсы EventLog, связанные с Ресурсами, если Ресурс удален


В следующих примерах показаны ResourceMetadata для Machine, предоставляющие информацию о некоторых возможностях:

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

{ "resourceURI": "http://schemas.dmtf.org/cimi/1/ResourceMetadata",

"id": "http://example.com/types/Machine",

"typeURI": "http://schemas.dmtf.org/cimi/1/Machine",

"name": "Machine",

"capabilities": [

{ "uri":

"http://schemas.dmtf.org/cimi/1/capability/Machine/MachineConfigByValue",

"value": true },

{ "uri":

"http://schemas.dmtf.org/cimi/1/capability/Machine/MachineImageByValue",

"value": true },

{ "uri":

"http://schemas.dmtf.org/cimi/1/capability/Machine/DefaultlnitialState",

"value": "STARTED" }

}

}

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

<ResourceMetadata xmlns="http://schemas.dmtf.org/cimi/1">

<id> http://example.org/types/Machine </id>

<typeURI> http://schemas.dmtf.org/cimi/1/Machine </typeURI>

<name> Machine </name>

<capability

uri="http://schemas.dmtf.org/cimi/1/capability/Machine/MachineConfigByValue">

true

</capability>

<capability

uri="http://schemas.dmtf.org/cimi/1/capability/Machine/MachineImageByValue">

true

</capability>

<capability

uri="http://schemas.dmtf.org/cimi/1/capability/Machine/DefaultlnitialState">

STARTED

</capability>

</ResourceMetadata>

5.11.3 Ресурс ResourceMetadataCollection

Ресурс ResourceMetadataCollection представляет собой Набор Ресурсов ResourceMetadata Поставщика и соответствует спецификации Набора, определенной в 5.5.12.

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


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

{ "resourceURI": "http://schemas.dmtf.org/cimi/1/ResourceMetadataCollection",

"id": string,

"count": number,

"resourceMetadatas": [

{ "resourceURI": "http://schemas.dmtf.org/cimi/1/ResourceMetadata",

"id": string,

... остальные атрибуты ResourceMetadata...

}, +

], ?

"operations": [ { "rel": "add", "href": string } ? ]

...

}

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

<Collection

resourceURI="http://schemas.dmtf.org/cimi/1/ResourceMetadataCollection"

xmlns="http://schemas.dmtf.org/cimi/1">

<id>xs:anyURI</id>

<count>xs:integer</count>

<ResourceMetadata>

<id>xs:anyURI</id>

... остальные атрибуты ResourceMetadata...

</ResourceMetadata> *

<operation rel="add" href="xs:anyURI"/> ?

<xs:any>*

</Collection>

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


Точка входа в облако (Ресурс CloudEntryPoint) представляет собой точку входа в облако, определенную моделью CIMI. Точка входа в облако реализует каталог Ресурсов, таких как System, SystemTemplate, Machine, MachineTemplate и т.д., которые могут запрашиваться и просматриваться Потребителем.

CloudEntryPoint и связи этого Ресурса с другими Ресурсами приведены на рисунке 1, который представлен в виде схемы отношений Ресурсов, при этом использование UML не является строгим и нормативным.


Рисунок 1 - Точка входа в облако


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

Таблица 8 - Атрибуты CloudEntryPoint

Наименование

CloudEntryPoint

Тип URI

http://www.dmf.org/cimi/CloudEntryPoint

Атрибут

Тип

Описание

baseURI

URI

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

Ограничения:

Поставщик: обязательная поддержка; неизменяемый.

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

Resource Metadata

collection
[Resource
Metadata]

Ссылка на Набор Ресурсов ResourceMetadata данной Точки входа в облако. Набор содержит описание Ресурсов, поддерживаемых Поставщиком. Если Ресурс не имеет метаданных, он не должен появляться в списке, например, он не имеет ограничений помимо определенных спецификацией CIMI, а также не имеет никаких атрибутов расширения.

Ограничения:

Поставщик: необязательная поддержка; изменяемый.

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

systems

collection [System]

Ссылка на SystemCollection данной Точки входа в облако.

Ограничения:

Поставщик: необязательная поддержка; изменяемый.

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

System Templates

collection
[System
Template]

Ссылка на SystemTemplateCollection данной Точки входа в облако.

Ограничения:

Поставщик: необязательная поддержка; изменяемый.

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

machines

collection [Machine]

Ссылка на MachineCollection данной Точки входа в облако.

Ограничения:

Поставщик: необязательная поддержка; изменяемый.

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

Machine Templates

collection [Machine Template]

Ссылка на MachineTemplateCollection данной Точки входа в облако.

Ограничения:

Поставщик: необязательная поддержка; изменяемый.

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

machineConfigs

collection [Machine Configuration]

Ссылка на MachineConfigurationCollection данной Точки входа в облако.

Ограничения:

Поставщик: необязательная поддержка; изменяемый.

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

machineImages

collection [Machine Image]

Ссылка на MachineImageCollection данной Точки входа в облако.

Ограничения:

Поставщик: необязательная поддержка; изменяемый.

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

credentials

collection [Credential]

Ссылка на CredentialCollection данной Точки входа в облако.

Ограничения:

Поставщик: необязательная поддержка; изменяемый.

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

Credential Templates

collection [Credential-
Template]

Ссылка на CredentialTemplateCollection данной Точки входа в облако.

Ограничения:

Поставщик: необязательная поддержка; изменяемый.

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

volumes

collection [Volume]

Ссылка на VolumeCollection данной Точки входа в облако.

Ограничения:

Поставщик: необязательная поддержка; изменяемый.

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

Volume Templates

collection [Volume
Template]

Ссылка на VolumeTemplateCollection данной Точки входа в облако.

Ограничения:

Поставщик: необязательная поддержка; изменяемый.

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

Volume Configs

collection
[Volume
Configuration]

Ссылка на VolumeConfigurationCollection данной Точки входа в облако

Ограничения:

Поставщик: необязательная поддержка; изменяемый.

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

volumeImages

collection [VolumeImage]

Ссылка на VolumeImageCollection данной Точки входа в облако.

Ограничения:

Поставщик: необязательная поддержка; изменяемый.

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

networks

collection [Network]

Ссылка на NetworkCollection данной Точки входа в облако.

Ограничения:

Поставщик: необязательная поддержка; изменяемый.

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

Network Templates

collection [Network Template]

Ссылка на NetworkTemplateCollection данной Точки входа в облако.

Ограничения:

Поставщик: необязательная поддержка; изменяемый.

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

Network Configs

collection [Network Configuration]

Ссылка на NetworkConfigurationCollection данной Точки входа в облако

Ограничения:

Поставщик: необязательная поддержка; изменяемый.

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

networkPorts

collection [NetworkPort]

Ссылка на NetworkPortCollection данной Точки входа в облако.

Ограничения:

Поставщик: необязательная поддержка; изменяемый.

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

networkPort
Templates

collection
[NetworkPort
Template]

Ссылка на NetworkPortTemplateCollection данной Точки входа в облако.

Ограничения:

Поставщик: необязательная поддержка; изменяемый.

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

networkPort
Configs

collection
[NetworkPort
Configuration]

Ссылка на NetworkPortConfigurationCollection данной Точки входа в облако.

Ограничения:

Поставщик: необязательная поддержка; изменяемый.

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

addresses

collection [Address]

Ссылка на AddressCollection данной Точки входа в облако.

Ограничения:

Поставщик: необязательная поддержка; изменяемый.

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

Address Templates

collection [Address Template]

Ссылка на AddressTemplateCollection данной Точки входа в облако.

Ограничения:

Поставщик: необязательная поддержка; изменяемый.

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

Forwarding Groups

collection
[Forwarding
Group]

Ссылка на ForwardingGroupCollection данной Точки входа в облако.

Ограничения:

Поставщик: необязательная поддержка; изменяемый.

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

forwardingGroup-Templates

collection [Forwarding Group Template]

Ссылка на ForwardingGroupTemplateCollection данной Точки входа в облако.

Ограничения:

Поставщик: необязательная поддержка; изменяемый.

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

jobs

collection [Job]

Ссылка на JobsCollection данной Точки входа в облако.

Ограничения:

Поставщик: необязательная поддержка; изменяемый.

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

meters

collection [Meter]

Ссылка на MeterCollection данной Точки входа в облако.

Ограничения:

Поставщик: необязательная поддержка; изменяемый.

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

meterTemplates

collection [Meter Template]

Ссылка на MeterTemplateCollection данной Точки входа в облако.

Ограничения:

Поставщик: необязательная поддержка; изменяемый.

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

meterConfigs

collection
[Meter
Configuration]

Ссылка на MeterConfigurationCollection данной Точки входа в облако.

Ограничения:

Поставщик: необязательная поддержка; изменяемый.

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

eventLogs

collection [EventLog]

Ссылка на EventLogCollection данной Точки входа в облако.

Ограничения:

Поставщик: необязательная поддержка; изменяемый.

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

eventLogTemplates

collection
[EventLog
Template]

Ссылка на EventLogTemplateCollection данной Точки входа в облако.

Ограничения:

Поставщик: необязательная поддержка; изменяемый.

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


Каждый из Наборов, указанных в таблице 8, определен в пунктах, определяющих связанные с ними ресурсы. Например Ресурс MachineCollection определен в 5.14.2 как часть Ресурсов, связанных с Machine.

Реализуя или используя CloudEntryPoint Поставщики и Потребители должны использовать синтаксис и семантику его атрибутов, согласно таблице 8, а также таблицам, описывающим встроенные Ресурсы или связанные Наборы. Потребитель и Поставщик должны сериализовать данный Ресурс в соответствии с описанием, приведенным далее. Сериализация Ресурса в JSON и в XML приведена в псевдосхемах (см. 1.3):

Тип медиа JSON: application/json

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

{ "resourceURI": "http://schemas.dmtf.org/cimi/1/CloudEntryPoint",

"id": string,

"name": string, ?

"description": string, ?

"created": string, ?

"updated": string, ?

"properties": { string: string, + },?

"baseURI": string,

"resourceMetadata": { "href": string }, ?

"systems": { "href": string }, ?

"systemTemplates": { "href": string }, ?

"machines": { "href": string }, ?

"machineTemplates": { "href": string }, ?

"machineConfigs": { "href": string }, ?

"machineImages": { "href": string }, ?

"credentials": { "href": string }, ?

"credentialTemplates": { "href": string }, ?

"volumes": { "href": string }, ?

"volumeTemplates": { "href": string }, ?

"volumeConfigs": { "href": string }, ?

"volumeImages": { "href": string }, ?

"networks": { "href": string }, ?

"networkTemplates": { "href": string }, ?

"networkConfigs": { "href": string }, ?

"networkPorts": { "href": string }, ?

"networkPortTemplates": { "href": string }, ?

"networkPortConfigs": { "href": string }, ?

"addresses": { "href": string }, ?

"addressTemplates": { "href": string }, ?

"forwardingGroups" { "href": string }, ?

"forwardingGroupTemplates" { "href": string }, ?

"jobs": { "href": string }, ?

"meters": { "href": string }, ?

"meterTemplates": { "href": string }, ?

"meterConfigs": { "href": string }, ?

"eventLogs": { "href": string }, ?

"eventLogTemplates": { "href": string }, ?

"operations": [

{ "rel": "edit", "href": string } ?

] ?

...

}

Тип медиа XML: application/xml

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

<CloudEntryPoint xmlns="http://schemas.dmtf.org/cimi/1">

<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</propety> *

<baseURI>xs:anyURI</baseURI>

<resourceMetadata href="xs:anyURI"/> ?

<Systems href="xs:anyURI"/> ?

<SystemTemplates href="xs:anyURI"/> ?

<Machines href="xs:anyURI"/> ?

<MachineTemplates href="xs:anyURI"/> ?

<MachineConfigs href="xs:anyURI"/> ?

<MachineImages href="xs:anyURI"/> ?

<Credentials href="xs:anyURI"/> ?

<CredentialTemplates href="xs:anyURI"/> ?

<Volumes href="xs:anyURI"/> ?

<VolumeTemplates href="xs:anyURI"/> ?

<VolumeConfigs href="xs:anyURI"/> ?

<VolumeImages href="xs:anyURI"/> ?

<networks href="xs:anyURI"/> ?

<networkTemplates href="xs:anyURI"/> ?

<networkConfigs href="xs:anyURI"/> ?

<networkPorts href="xs:anyURI"/> ?

<networkPortTemplates href="xs:anyURI"/> ?

<networkPortConfigs href="xs:anyURI"/> ?

<addresses href="xs:anyURI"/> ?

<addressTemplates href="xs:anyURI"/> ?

<forwardingGroups href="xs:anyURI"/> ?

<forwardingGroupTemplates href="xs:anyURI"/> ?

<jobs href="xs:anyURI"/> ?

<meters href="xs:anyURI"/> ?

<meterTemplates href="xs:anyURI"/> ?

<meterConfigs href="xs:anyURI"/> ?

<EventLogs href="xs:anyURI"/> ?

<EventLogTemplates href="xs:anyURI"/> ?

<operation rel="edit" href="xs:anyURI"/> ?

<xs:any>*

</CloudEntryPoint>

5.12.1 Операции

Данный Ресурс поддерживает операции Read и Update.

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


Ресурсы, составляющие ресурс System, и связи между ними, приведены на рисунке 2, который представлен в виде схемы отношений Ресурсов, при этом использование UML не является обязательным требованием.


Рисунок 2 - Ресурсы системы

5.13.1 System

System (Система) - реализованный Ресурс, который содержит один или более ресурсов Network (Сеть), Volume (Том), Machine (Машина) и т.д., которые могут связываться и соединяться друг с другом. Ресурс System может создаваться из интерпретации SystemTemplate. Допускается управлять Ресурсом System как единичным Ресурсом; также данный Ресурс формирует стек служб. Например система корзины в интернет-магазине состоит из машин для веб-серверов и базы данных, сетевых адресов для открытого доступа и томов для файлов базы данных. System может непосредственно предоставлять компонент, с которым взаимодействуют пользователи, либо предоставлять инфраструктурный компонент.

System имеет несколько атрибутов "верхнего уровня", которые являются Наборами ссылок на Ресурсы, принадлежащих System. Жизненный цикл Ресурсов, принадлежащих System, связан непосредственно с жизненным циклом System. В частности, если System будет удалена, то все находящиеся в ее ведении Ресурсы должны также быть удалены. Обычно операции c System переводятся в операции с ее Ресурсами.

Однако Ресурс, принадлежащий System, в свою очередь, может относиться к некоторым другим Ресурсам, не принадлежащим этой System. Например Machine в System может ссылаться на Volume, который не принадлежит данной System. Эти правила применяются следующим образом:

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

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

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

Ресурс не должен принадлежать более чем одной System ни в один момент времени, (если между этими System нет отношений принадлежности).

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


Описание атрибутов Системы приведено в таблице 9.

Таблица 9 - Атрибуты Системы

Наименование

Система (System)

Тип URI

http://schemas.dmtf.org/cimi/1/System

Атрибут

Тип

Описание

state

string

Рабочее состояние Системы.

Допустимыми значениями являются: см. 5.14.1.

CREATING: Система находится в процессе создания.

STARTING/STARTED/STOPPING/STOPPED/PAUSING/PAUSED/
SUSPENDING/SUSPENDED:
System должна находиться в одном из данных состояний, если все ресурсы Machine, на которые ссылается System, находятся в этом состоянии. Перечень доступных действий, основанных на состоянии Machine см. в 5.14.1. Такие транзитные состояния могут просто на то, что все Machine в System подвергаются тем же операциям (например, "start") без необходимости выполнения конкретной операции в System (например, операция "start" не выполняется на уровне System). Фактическая операция в System может быть прослежена при запросе объекта "job".

MIXED: System должна быть в этом состоянии, если нет никаких ссылок на Machine от данной System, либо Machine, на которые ссылается данная System, находятся в разных состояниях.

Разные состояния могут возникнуть, когда в System выполняются операции, приводящие к переходу состояний принадлежащих ей Ресурсов Machine к новому общему состоянию (например, STOPPED, STARTED), но они происходят с разной скоростью или последовательно одна за другой.

DELETING: System находится в процессе удаления.

ERROR: Поставщик обнаружил ошибку в System.

Операции, приводящие к возникновению указанных состояний, определены в 5.13.1.2.

Ограничения:

Поставщик: обязательная поддержка; изменяемый.

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

systems

Collection
[System
System]

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

Удаление элемента из этого перечня логически эквивалентно отсоединению System, на которую указывает ссылка, от данной System.

Примечание - Тип ресурса SystemSystem представляет собой связь между System и другой System (см. 5.13.1.1.1).


Ограничения:

Поставщик: необязательная поддержка; изменяемый.

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

machines

Collection
[System
Machine]

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

Примечание - Тип ресурса SystemMachine представляет собой связь между System и Machine (см. 5.13.1.1.2).


Ограничения:

Поставщик: необязательная поддержка; изменяемый.

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

credentials

Collection
[System
Credential]

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

Удаление элемента из этого перечня логически эквивалентно отсоединению Credential от данной System.

Примечание - Тип ресурса SystemCredential представляет собой связь между System и Credential (см. 5.13.1.1.3).


Ограничения:

Поставщик: необязательная поддержка; изменяемый.

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

volumes

Collection
[System
Volume]

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

Примечание - Тип ресурса SystemVolume представляет собой связь между System и Volume (см. 5.13.1.1.4).


Ограничения:

Поставщик: необязательная поддержка; изменяемый.

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

networks

Collection
[System
Network]

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

Примечание - Тип ресурса SystemNetwork представляет собой связь между System и Network (см. 5.13.1.1.5).


Ограничения:

Поставщик: необязательная поддержка; изменяемый.

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

network Ports

Collection [System Network Port]

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

Примечание - Тип ресурса SystemNetworkPort представляет собой связь между System и NetworkPort (см. 5.13.1.1.6).


Ограничения:

Поставщик: необязательная поддержка; изменяемый.

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

addresses

Collection
[System
Address]

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

Примечание - Тип ресурса SystemAddress представляет собой связь между System и Address (см. 5.13.1.1.7).


Ограничения:

Поставщик: необязательная поддержка; изменяемый.

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

forwarding Groups

Collection [System Forwarding Groups]

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

Примечание - Тип ресурса SystemForwardingGroup представляет собой связь между System и ForwardingGroup (см. 5.13.1.1.8).


Ограничения:

Поставщик: необязательная поддержка; изменяемый.

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

meters

Collection [Meter]

Ссылка на перечень Ресурсов Meter, которые используются для мониторинга данной System.

Примечание - данные Meter предназначены для System, а не для какого-либо отдельного компонента System.


Ограничения:

Поставщик: необязательная поддержка; изменяемый.

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

eventLog

ref

Ссылка на EventLog данной System.

Примечание - данный EventLog предназначен для System, а не для какого-либо отдельного компонента System.


Ограничения:

Поставщик: необязательная поддержка; изменяемый.

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


Реализуя или используя System Поставщики и Потребители должны использовать синтаксис и семантику атрибутов в соответствии с таблицей, приведенной выше, а также таблицами, описывающими встроенные Ресурсы или связанные Наборы. Потребитель и Поставщик должны сериализовать данный Ресурс в соответствии со следующим описанием. Следующие псевдосхемы (см. 1.3) описывают сериализация Ресурса и в JSON и в XML.

Тип медиа JSON: application/json

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

{ "resourceURI": "http://schemas.dmtf.org/cimi/1/System",

"id": string,

"name": string, ?

"description": string, ?

"created": string, ?

"updated": string, ?

"properties": { string: string, + }, ?

"state": string,

"systems": { "href": string }, ?

"machines": { "href": string }, ?

"credentials": { "href": string }, ?

"volumes": { "href": string }, ?

"networks": { "href": string }, ?

"networkPorts": { "href": string }, ?

"addresses": { "href": string }, ?

"forwardingGroups": { "href": string }, ?

"meters": { "href": string }, ?

"eventLog": { "href": string }, ?

"operations": [

{" rel": "edit", "href": string }, ?

{ "rel": "delete", "href": string }, ?

{ "rel": "http://schemas.dmtf.org/cimi/1/action/start", "href": string }, ?

{ "rel": "http://schemas.dmtf.org/cimi/1/action/stop", "href": string }, ?

{ "rel": "http://schemas.dmtf.org/cimi/1/action/restart", "href": string },

?

{ "rel": "http://schemas.dmtf.org/cimi/1/action/pause", "href": string }, ?

{ "rel": "http://schemas.dmtf.org/cimi/1/action/suspend", "href": string },

?

{ "rel": "http://schemas.dmtf.org/cimi/1/action/export", "href": string } ?

] ?

...

}

Тип медиа XML: application/xml

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

<System xmlns="http://schemas.dmtf.org/cimi/1">

<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> *

<state>xs:string</state>

<systems href="xs:anyURI"/> ?

<machines href="xs:anyURI"/> ?

<credentials href="xs:anyURI"/> ?

<olumes href="xs:anyURI"/> ?

<networks href="xs:anyURI"/> ?

<networkPorts href="xs:anyURI"/> ?

<addresses href="xs:anyURI"/> ?

<forwardingGroups href="xs:anyURI"/> ?

<meters href="xs:anyURI"/> ?

<eventLog href="xs:anyURI"/> ?

<operation rel="edit" href="xs:anyURI"/> ?

<operation rel="delete" href="xs:anyURI"/> ?

<operation rel="http://schemas.dmtf.org/cimi/1/action/start"

href="xs:anyURI"/> ?

<operation rel="http://schemas.dmtf.org/cimi/1/action/stop"

href="xs:anyURI"/> ?

<operation rel="http://schemas.dmtf.org/cimi/1/action/restart"

href="xs:anyURI"/> ?

<operation rel="http://schemas.dmtf.org/cimi/1/action/pause"

href="xs:anyURI"/> ?

<operation rel="http://schemas.dmtf.org/cimi/1/action/suspend"

href="xs:anyURI"/> ?

<operation rel="http://schemas.dmtf.org/cimi/1/action/export"

href="xs:anyURI"/>?

<xs:any>*

</System>

5.13.1.1 Наборы

В настоящем подпункте приведено описание Наборов Ресурсов, принадлежащих System.

5.13.1.1.1 Набор SystemSystem

Типом ресурса для каждого элемента данного Набора является SystemSystem, приведенный в таблице 10.

Таблица 10 - Атрибуты SystemSystem

Наименование

SystemSystem

Тип URI

http://schemas.dmtf.org/cimi/1/SystemSystem

Атрибут

Тип

Описание

system

ref

Ссылка на Ресурс System.

Ограничения:

Поставщик: обязательная поддержка; изменяемый.

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


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

{ "resourceURI": "http://schemas.dmtf.org/cimi/1/SystemSystemCollection",

"id": string,

"count": number,

"systemSystems": [

{ "resourceURI": "http://schemas.dmtf.org/cimi/1/SystemSystem",

"id": string,

"name": string, ?

"description": string, ?

"created": string, ?

"updated": string, ?

"properties": { string: string, + },?

"system": { "href": string },

"operations": [

{ "rel": "edit", "href": string }, ?

{ "rel": "delete", "href": string } ?

] ?

...

}, +

], ?

"operations": [ { "rel": "add", "href": string } ? ]

...

}

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

<Collection

resourceURI="http://schemas.dmtf.org/cimi/1/SystemSystemCollection"

xmlns="http://schemas.dmtf.org/cimi/1">

<id>xs:anyURI</id>

<count>xs:integer</count>

<SystemSystem>

<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> *

<system href="xs:anyURI"/>

<operation rel="edit" href="xs:anyURI"/> ?

<operation rel="delete" href="xs:anyURI"/> ?

<xs:any>*

</SystemSystem> *

<operation rel="add" href="xs:anyURI"/> ?

<xs:any>*

</Collection>

5.13.1.1.2 Набор SystemMachine

Типом ресурса для каждого элемента данного Набора является SystemMachine, приведенный в таблице 11.

Таблица 11 - Атрибуты SystemMachine

Наименование

SystemMachine

Тип URI

http://schemas.dmtf.org/cimi/1/SystemMachine

Атрибут

Тип

Описание

machine

ref

Ссылка на Ресурс Machine.

Ограничения:

Поставщик: обязательная поддержка; изменяемый.

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


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

{ "resourceURI": "http://schemas.dmtf.org/cimi/1/SystemMachineCollection",

"id": string,

"count": number,

"systemMachines": [

{ "resourceURI": "http://schemas.dmtf.org/cimi/1/SystemMachine",

"id": string,

"name": string, ?

"description": string, ?

"created": string, ?

"updated": string, ?

"properties": { string: string, + }, ?

"machine": { "href": string },

"operations": [

{ "rel": "edit", "href": string }, ?

{ "rel": "delete", "href": string } ?

] ?

...

}, +

], ?

"operations": [ { "rel": "add", "href": string } ? ]

...

}

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

<Collection

resourceURI="http://schemas.dmtf.org/cimi/1/SystemMachineCollection"

xmlns="http://schemas.dmtf.org/cimi/1">

<id>xs:anyURI</id>

<соunt>xs:integer</count>

<SystemMachine>

<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</propetiy> *

<Machine href="xs:anyURI"/>

<operation rel="edit" href="xs:anyURI"/> ?

<operation rel="delete" href="xs:anyURI"/> ?

<xs:any>*

</SystemMachine> *

<operation rel="add" href="xs:anyURI"/> ?

<xs:any>*

</Collection>

5.13.1.1.3 Набор SystemCredential

Типом Ресурса для каждого элемента данного Набора является SystemCredential, приведенный в таблице 12.

Таблица 12 - Атрибуты SystemCredential

Наименование

SystemCredential

Тип URI

http://schemas.dmtf.org/cimi/1/SystemCredential

Атрибут

Тип

Описание

credentials

ref

Ссылка на Pecypc Credential.

Ограничения:

Поставщик: обязательная поддержка; изменяемый.

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


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

{ "resourceURI": "http://schemas.dmtf.org/cimi/1/SystemCredentialCollection",

"id": string,

"count": number,

"systemCredentials": [

{ "resourceURI": "http://schemas.dmtf.org/cimi/1/SystemCredential",

"id": string,

"name": string, ?

"description": string, ?

"created": string, ?

"updated": string, ?

"properties": { string: string, + }, ?

"credential": { "href": string },

"operations": [

{ "rel": "edit", "href": string }, ?

{ "rel": "delete", "href": string } ?

] ?

...

}, +

], ?

"operations": [ { "rel": "add", "href": string } ?]

...

}

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

<Collection

resourceURI="http://schemas.dmtf.org/cimi/1/SystemCredentialCollection"

xmlns="http://schemas.dmtf.org/cimi/1">

<id>xs:anyURI</id>

<count>xs:integer</count>

<SystemCredential>

<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> *

<credential href="xs:anyURI"/>

<operation rel="edit" href="xs:anyURI"/> ?

<operation rel="delete" href="xs:anyURI"/> ?

<xs:any>*

</SystemCredential> *

<operation rel="add" href="xs:anyURI"/> ?

<xs:any>*

</Collection>

5.13.1.1.4 Набор SystemVolume

Типом ресурса для каждого элемента данного Набора является SystemVolume, приведенный в таблице 13.

Таблица 13 - Атрибуты SystemVolume

Наименование

SystemVolume

Тип URI

http://schemas.dmtf.org/cimi/1/SystemVolume

Атрибут

Тип

Описание

volume

ref

Ссылка на Ресурс Volume.

Ограничения:

Поставщик: обязательная поддержка; изменяемый.

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


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

{ "resourceURI": "http://schemas.dmtf.org/cimi/1/SystemVolumeCollection",

"id": string,

"count": number,

"systemVolumes": [

{ "resourceURI": "http://schemas.dmtf.org/cimi/1/SystemVolume",

"id": string,

"name": string, ?

"description": string, ?

"created": string, ?

"updated": string, ?

"properties": { string: string, + }, ?

"Volume": {"href": string},

"operations": [

{ "rel": "edit", "href": string }, ?

{ "rel": "delete", "href": string } ?

] ?

...

}, +

], ?

"operations": [ { "rel": "add", "href": string } ? ]

...

}

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

<Collection

resourceURI="http://schemas.dmtf.org/cimi/1/SystemVolumeCollection"

xmlns="http://schemas.dmtf.org/cimi/1">

<id>xs:anyURI</id>

<соunt>xs:integer</count>

<systemVolume>

<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> *

<volume href="xs:anyURI"/>

<operation rel="edit" href="xs:anyURI"/> ?

<operation rel="delete" href="xs:anyURI"/> ?

<xs:any>*

</systemVolume> *

<operation rel="add" href="xs:anyURI"/> ?

<xs:any>*

</Collection>

5.13.1.1.5 Набор SystemNetwork

Типом ресурса для каждого элемента данного Набора является SystemNetwork, приведенный в таблице 14.

Таблица 14 - Атрибуты SystemNetwork

Наименование

SystemNetwork

Тип URI

http://schemas.dmtf.org/cimi/1/SystemNetwork

Атрибут

Тип

Описание

network

ref

Ссылка на Ресурс Network.

Ограничения:

Поставщик: обязательная поддержка; изменяемый.

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


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

{ "resourceURI":

"http://schemas.dmtf.org/cimi/1/SystemNetworkCollection",

"id": string,

"count": number,

"systemNetworks": [

{ "resourceURI": "http://schemas.dmtf.org/cimi/1/SystemNetwork",

"id": string,

"name": string, ?

"description": string, ?

"created": string, ?

"updated": string, ?

"properties": { string: string, + }, ?

"network": { "href": string },

"operations": [

{ "rel": "edit", "href": string }, ?

{ "rel": "delete", "href": string }?

] ?

...

}, +

], ?

"operations": [ { "rel": "add", "href": string } ? ]

...

}

5.13.1.1.6 Набор SystemNetworkPort

Типом ресурса для каждого элемента данного Набора является SystemNetworkPort, приведенный в таблице 15.

Таблица 15 - Атрибуты SystemNetworkPort

Наименование

SystemNetworkPort

Тип URI

http://schemas.dmtf.org/cimi/1/SystemNetworkPort

Атрибут

Тип

Описание

networkPort

ref

Ссылка на Ресурс NetworkPort.

Ограничения:

Поставщик: обязательная поддержка; изменяемый.

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


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

{ "resourceURI": "http://schemas.dmtf.org/cimi/1/SystemNetworkPortCollection",

"id": string,

"count": number,

"systemNetworkPorts": [

{ "resourceURI": "http://schemas.dmtf.org/cimi/1/SystemNetworkPort",

"id": string,

"name": string, ?

"description": string, ?

"created": string, ?

"updated": string, ?

"properties": { string: string, + }, ?

"networkPort": { "href": string },

"operations": [

{ "rel": "edit", "href": string }, ?

{ "rel": "delete", "href": string } ?

] ?

...

}, +

], ?

"operations": [ { "rel": "add", "href": string } ? ]

...

}

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

<Collection

resourceURI="http://schemas.dmtf.org/cimi/1/SystemNetworkPortCollection"

xmlns="http://schemas.dmtf.org/cimi/1">

<id>xs:anyURI</id>

<count>xs:integer</count>

<SystemNetworkPort>

<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> *

<networkPort href="xs:anyURI"/>

<operation rel="edit" href="xs:anyURI"/> ?

<operation rel="delete" href="xs:anyURI"/> ?

<xs:any>*

</SystemNetworkPort> *

<operation rel="add" href="xs:anyURI"/> ?

<xs:any>*

</Collection>

5.13.1.1.7 Набор SystemAddress

Типом ресурса для каждого элемента данного Набора является SystemAddress, приведенный в таблице 16.

Таблица 16 - Атрибуты SystemAddress

Наименование

SystemAddress

Тип URI

http://schemas.dmtf.org/cimi/1/SystemAddress

Атрибут

Тип

Описание

address

ref

Ссылка на Ресурс Address.

Ограничения:

Поставщик: обязательная поддержка; изменяемый.

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


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

{ "resourceURI": "http://schemas.dmtf.org/cimi/1/SystemAddressCollection",

"id": string,

"count": number,

"systemAddresses": [

{ "resourceURI": "http://schemas.dmtf.org/cimi/1/SystemAddress",

"id": string,

"name": string, ?

"description": string, ?

"created": string, ?

"updated": string, ?

"properties": { string: string, + }, ?

"address": { "href": string },

"operations": [

{ "rel": "edit", "href": string }, ?

{ "rel": "delete", "href": string } ?

] ?

,,,

}, +

], ?

"operations": [ { "rel": "add", "href": string } ? ]

...

}

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

<Collection

resourceURI="http://schemas.dmtf.org/cimi/1/SystemAddressCollection"

xmlns="http://schemas.dmtf.org/cimi/1">

<id>xs:anyURI</id>

<count>xs:integer</count>

<SystemAddress>

<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> *

<address href="xs:anyURI"/>

<operation rel="edit" href="xs:anyURI"/> ?

<operation rel="delete" href="xs:anyURI"/> ?

<xs:any>*

</SystemAddress> *

<operation rel="add" href="xs:anyURI"/> ?

<xs:any>*

</Collection>

5.13.1.1.8 Набор SystemForwardingGroup

Типом ресурса для каждого элемента данного Набора является SystemForwardingGroup, приведенный в таблице 17.

Таблица 17 - Атрибуты SystemForwardingGroup

Name

SystemForwardingGroup

Тип URI

http://schemas.dmtf.org/cimi/1/SystemForwardingGroup

Атрибут

Тип

Описание

forwardingGroup

ref

Ссылка на Ресурс ForwardingGroup.

Ограничения:

Поставщик: обязательная поддержка; изменяемый.

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


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

{ "resourceURI":

"http://schemas.dmtf.org/cimi/1/SystemForwardingGroupCollection",

"id": string,

"count", number,

"systemForwardingGroups": [

{ "resourceURI": "http://schemas.dmtf.org/cimi/1/SystemForwardingGroup",

"id": string,

"name": string, ?

"description": string, ?

"created": string, ?

"updated": string, ?

"properties": { string: string, + }, ?

"forwardingGroup": { "href": string },

"operations": [

{ "rel": "edit", "href": string }, ?

{ "rel": "delete", "href": string } ?

] ?

...

}, +

], ?

"operations": [ { "rel": "add", "href": string } ? ]

...

}

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

<Collection

resourceURI="http://schemas.dmtf.org/cimi/1/SystemForwardingGroupCollection"

xmlns="http://schemas.dmtf.org/cimi/1">

<id>xs:anyURI</id>

<count>xs:integer</count>

<SystemForwardingGroup>

<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> *

<forwardingGroup href="xs:anyURI"/>

<operation rel="edit" href="xs:anyURI"/> ?

<operation rel="delete" href="xs:anyURI"/> ?

<xs:any>*

</SystemForwardingGroup> *

<operation rel="add" href="xs:anyURI"/> ?

<xs:any>*

</Collection>

5.13.1.1.9 Набор SystemMeter

Типом ресурса для каждого элемента данного Набора является Meter, описание которого приведено в 5.17.3.

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

{ "resourceURI": "http://schemas.dmtf.org/cimi/1/SystemMeterCollection",

"id": string,

"count": number,

"meters": [

{ "resourceURI": "http://schemas.dmtf.org/cimi/1/Meter",

"id": string,

... остальные атрибуты Meter...

}, +

], ?

"operations": [ { "rel": "add", "href": string } ? ]

...

}

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

<Collection

resourceURI="http://schemas.dmtf.org/cimi/1/SystemMeterCollection"

xmlns="http://schemas.dmtf.org/cimi/1">

<id>xs:anyURI</id>

<count>xs:integer</count>

<Meter>

<id>xs:anyURI</id>

... остальные атрибуты Meter...

</Meter> *

<operation rel="add" href="xs:anyURI"/> ?

<xs:any>*

</Collection>

5.13.1.2 Операции

Ресурс System поддерживает операции Read, Update и Delete. Операция Create поддерживается через Ресурс SystemCollection.

Кроме того, определены следующие специальные операции:

start/stop/restart/pause/suspend

/link@rel: http://schemas.dmtf.org/cimi/1/action/xxx

    где "ххх" является операцией start, stop, restart, pause или suspend.


Данная операция должна рекурсивно выполнять требуемую операцию для каждого компонента System (Machine или вложенные System).

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


export

/link@rel: http://schemas.dmtf.org/cimi/1/action/export

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

Входные параметры:

1) "format": тип string - необязательный;

2) указывает на тип медиа экспортируемых данных. Если не задан, то значением по умолчанию должно быть "application/ovf";

3) "destination": тип URI - необязательный.

Указывает на местоположение экспортируемых данных. Если данный параметр отсутствует, то в ответе заголовок HTTP Location должен содержать URL экспортированных данных. На основании конкретного протокола, определенного в URI, Потребитель, возможно, должен указать в поле "properties" дополнительную информацию (например, учетные данные). В случае HTTP следует использовать PUT для того, чтобы разместить данные в указанном местоположении.

Выходные параметры: нет.

Протокол HTTP

Чтобы экспортировать System в URI http://schemas.dmtf.org/cimi/1/action/export Ресурса System направляется запрос POST, где запрос HTTP должен быть представлен следующим образом:

Тип медиа JSON: application/json

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

{ "action": "http://schemas.dmtf.org/cimi/1/action/export",

"format": string, ?

"destination": string, ?

"properties": { string: string, + } ?

...

}

Тип медиа XML: application/xml

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

<Action xmlns="http://schemas.dmtf.org/cimi/1">

<action> http://schemas.dmtf.org/cimi/1/action/export </action>

<format>xs:string</format> ?

<destination> xs:anyURI</destination> ?

<property key="xs:string"> xs:string </property> *

<xs:any>*

</Action>

5.13.2 Ресурс SystemCollection

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

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

{ "resourceURI": "http://schemas.dmtf.org/cimi/1/SystemCollection",

"id": string,

"count", number,

"systems": [

{ "resourceURI": "http://schemas.dmtf.org/cimi/1/System",

"id": string,

... остальные атрибуты System...

}, +

], ?

"operations": [

{ "rel": "add", "href": string }, ?

{ "rel": "http://schemas.dmtf.org/cimi/1/action/import", "href": string } ?

]

...

}

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

<Collection

resourceURI="http://schemas.dmtf.org/cimi/1/SystemCollection"

xmlns="http://schemas.dmtf.org/cimi/1">

<id>xs:anyURI</id>

<count>xs:integer</count>

<System>

<id>xs:anyURI</id>

... остальные атрибуты System...

</System> *

<operation rel="add" href="xs:anyURI"/> ?

<operation rel="http://schemas.dmtf.org/cimi/1/action/import"

href="xs:anyURI"/> ?

<xs:any>*

</Collection>

5.13.2.1 Операции

Примечание - Операция "add" требует использования SystemTemplate (см. 4.2.1.1).


Ресурсы, созданные во время процесса создания System, должны "принадлежать" созданному Ресурсу System (см. 5.13.1). Например, если componentDescriptor ссылается на шаблон MachineTemplate, который содержит ссылку на VolumeTemplate, то в результате к атрибуту System.machine будет добавлена ссылка на новый экземпляр Machine, а к атрибуту System.volume будет добавлен новый экземпляр Volume. Однако если этот MachineTemplate ссылается на существующий атрибут Volume, то этот Volume не должен добавляться к атрибутам верхнего уровня экземпляра System.

Кроме этого определены следующие специальные операции:

import
     /link@rel
: http://schemas.dmtf.org/cimi/1/action/import

Данная операция должна импортировать System. Помимо создания System также могут быть созданы экземпляры Machine, Volume, Network и, возможно, рекурсивно другие экземпляры System и их компоненты в соответствии с записями дескриптора импорта. Более подробная информация об этом процессе приведена в приложении А.

Входные параметры:

1) "source": тип URI - обязательный.

Указывает местоположение, откуда получают импортированные данные. На основании конкретного протокола, определенного в URI, Потребитель, возможно, должен предоставить дополнительную информацию (например, учетные данные) в поле "properties".

Выходные параметры: нет.

Протокол HTTP

Чтобы импортировать System отправляется запрос POST в URI "http://schemas.dmtf.org/cimi/1/action/import" Ресурса SystemCollection, где запрос HTTP должен быть представлен следующим образом:

Тип медиа JSON: application/json

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

{ "action": "http://schemas.dmtf.org/cimi/1/action/import",

"source": string, ?

"properties": { string: string, + } ?

...

}

Тип медиа XML: application/xml

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

<Action xmlns="http://schemas.dmtf.org/cimi/1">

<action> http://schemas.dmtf.org/cimi/1/action/import</action>

<source>xs:anyURI</source> ?

<property key="xs:string">xs:string</property> *

<xs:any>*

</Action>

5.13.3 Ресурс SystemTemplate

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

SystemTemplate может содержать в дескрипторах ссылки на компоненты, используемые для выражения связей между компонентами итоговой Системы. Составная ссылка использует атрибут "name" целевого компонента (на который указывает ссылка). Например <Volumehref = "#newVolume"/> может ссылаться на Volume, названный newVolume. Наименование ссылки #newVolume заменяется фактическим URL Ресурса в созданном экземпляре System.

SystemTemplate не должен содержать два дескриптора компонента одинакового типа, которые могут привести к одинаковому непустому значению для атрибута "name" итоговых компонентов. Попытка создать или обновить SystemTemplate, который не удовлетворяет этому правилу, приводит к ошибке. Описание атрибутов SystemTemplate приведено в таблице 18.

Таблица 18 - Атрибуты SystemTemplate

Наиме-
нование

SystemTemplate

Тип URI

http://schemas.dmtf.org/cimi/1/SystemTemplate

Атрибут

Тип

Описание

Component Descriptors

Component
Descriptor  [ ]

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

Наименование

component Descriptor

Данные

Тип

Описание

name

string

Значение атрибута "name", связанного с компонентом экземпляра System, созданным из данного дескриптора компонента.

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


Ограничения:

Поставщик: обязательная поддержка; изменяемый.

Потребитель: необязательная поддержка; чтение-запись

description

string

Значение атрибута "description", связанного с компонентом экземпляра System, созданным из данного дескриптора компонента.

Ограничения:

Поставщик: обязательная поддержка; изменяемый.

Потребитель: необязательная поддержка; чтение-запись

properties

map

Пары ключ/значение, которые связаны с компонентом экземпляра System, созданным из данного дескриптора компонента.

Ограничения:

Поставщик: обязательная поддержка; изменяемый.

Потребитель: необязательная поддержка; чтение-запись

type

URI

TypeURI компонента, который создан из данного дескриптора компонента, например для Machine:

http://schemas.dmtf.org/cimi/1/Machine

Ограничения:

Поставщик: обязательная поддержка; изменяемый.

Потребитель: обязательная поддержка; чтение-запись

component Template

any

Ссылка на Шаблон компонента или непосредственно вложенный Шаблон? (т.е. значение Шаблона).

Следует обратить внимание на то, что точное наименование данного атрибута может варьироваться в зависимости от типа создаваемого Ресурса, создаваемого, например MachineTemplate для Machine.

Данный атрибут должен содержать:

- шаблон, который предоставлен вложением. Такой встроенный Шаблон может содержать ссылки на компоненты, каждая из которых должна разрешаться как URI компонента с тем же наименованием однажды созданного из данного SystemTemplate; либо ссылку на внешний определенный Шаблон. Для некоторых атрибутов внутри элемента componentTemplate могут быть определены пары наименование/значение, чтобы переопределить подобные атрибуты в Шаблоне, на который указывает ссылка (см. 4.2.1.1). В следующем примере показано, как можно добавлять к внешнему Шаблону ссылки на компоненты.

Пример (JSON):

"machineTemplate": {
"href":
"
http://example.com/MachineTemplates/72000",
"credential": { "href": "#MyCredential" }
}


Атрибут "credential" предполагает, что есть другой элемент componentDescriptor "MyCredential" типа "Credential" в SystemTemplate. Он должен установить или переопределить подобный атрибут в MachineTemplate, на который указывает ссылка, когда тот будет использоваться для создания компонента Machine.

Ограничения:

Поставщик: обязательная поддержка; изменяемый.

Потребитель: обязательная поддержка; чтение-запись

quantity

Integer

Число экземпляров компонентов, которые будут созданы из данного дескриптора компонентов. По умолчанию это число равно 1. Если значение равно 2 или больше, фактическое наименование, присвоенное каждому экземпляру, получается конкатенацией параметра "name" и порядковым номером (например, если name="myMachine" и quantity=3, то имена будут: myMachine1, myMachine2, myMachine3).

Ограничения:

Поставщик: необязательная поддержка; изменяемый.

Потребитель: необязательная поддержка; чтение-запись

Ограничения:

Поставщик: обязательная поддержка; изменяемый.

Потребитель: обязательная поддержка; чтение-запись

meter Templates

Meter Templates [ ]

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

Примечание - Могут быть заданы атрибуты MeterTemplate, а не указана ссылка на существующий Ресурс MeterTemplate

meter Templates

Meter Templates [ ]

Ограничения:

Поставщик: необязательная поддержка; изменяемый.

Потребитель: необязательная поддержка; чтение-запись

eventLog-
Template

ref

Ссылка на EventLogTemplate, которая должна использоваться для создания и подключения нового экземпляра EventLog к создаваемой System.

Примечание - Могут быть заданы атрибуты EventLogTemplate, а не указана ссылка на существующий Ресурс EventLogTemplate.


Ограничения:

Поставщик: необязательная поддержка; изменяемый.

Потребитель: необязательная поддержка; чтение-запись

import Image

ref

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

Ограничения:

Поставщик: необязательная поддержка; изменяемый.

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


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

JSON тип медиа: application/json

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

{ "resourceURI": "http://schemas.dmtf.org/cimi/1/SystemTemplate",

"id": string,

"name": string, ?

"description": string, ?

"created": string, ?

"updated": string, ?

"properties": { string: string, + }, ?

"componentDescriptors": [

{ "name": string, ?

"description": string, ?

"properties": { string: string, + }, ?

"type": string,

"componentTemplate": {

"href": string, ?

... атрибуты ComponentTemplate... ?

},

"quantity": number ?

}, +

], ?

"meterTemplates": [

{ "href": string, ?

... атрибуты MeterTemplate... ?

}, *

], ?

"eventLogTemplate": {

"href": string, ?

... атрибуты EventLogTemplate... ?

}, ?

"importImage": { "href": string }, ?

"operations": [

{ "rel": "edit", "href": string }, ?

{ "rel": "delete", "href": string }, ?

{ "rel": "http://schemas.dmtf.org/cimi/1/action/export", "href": string } ?

] ?

...

}

Тип медиа XML: application/xml

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

<SystemTemplate xmlns="http://schemas.dmtf.org/cimi/1">

<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> *

<componentDescriptor>

<name>xs:string</name> ?

<description>xs:string</description> ?

<property key="xs:string">xs:string</property> *

<type>xs:anyURI</type>

<componentTemplate href="xs:anyURI"? >

... атрибуты ComponentTemplate... ?

</componentTemplate> *

<quantity>xs:integer</quantity>

</componentDescriptor> *

<meterTemplate href="xs:anyURI"? >

... атрибуты MeterTemplate... ?

</meterTemplate> *

<eventLogTemplate href="xs:anyURI"? >

... атрибуты EventLogTemplate... ?

</eventLogTemplate> ?

<importImage href="xs:anyURI"? >

<operation rel="edit" href="xs:anyURI"/> ?

<operation rel="delete" href="xs:anyURI"/> ?

<operation rel="http://schemas.dmtf.org/cimi/1/action/export"

href="xs:anyURI"/> ?

<xs:any>*

</systemTemplate>

5.13.3.1 Операции

Данный Ресурс поддерживает операции Read, Update и Delete. Операция Create поддерживается через Ресурс SystemTemplateCollection.

Кроме того, определены следующие специальные операции:

export

/link@rel: http://schemas.dmtf.org/cimi/1/action/export

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

Входные параметры:

1) "format": тип string - необязательный;

2) указывает на Тип медиа экспортируемых данных. Если не задан, то значением по умолчанию должно быть "application/ovf";

3) "destination": тип URI - необязательный.

Указывает на местоположение экспортируемых данных. Если данный параметр отсутствует, то в ответе заголовок HTTP Location должен содержать URL экспортированных данных. На основании конкретного протокола, определенного в URI, Потребитель должен указать в поле "properties" дополнительную информацию (например, учетные данные). В случае HTTP следует использовать PUT с целью размещения данных в указанном местоположении.

Выходные параметры: Нет.

Протокол HTTP

Чтобы экспортировать SystemTemplate, в URI http://schemas.dmtf.org/cimi/1/action/export Ресурса SystemTemplate направляется запрос POST, где запрос HTTP должен быть представлен следующим образом:

Тип медиа JSON: application/json

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

{ "action": "http://schemas.dmtf.org/cimi/1/action/export",

"format": string, ?

"destination": string, ?

"properties": { string: string, + } ?

...

}

Тип медиа XML: application/xml

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

<Action xmlns="http://schemas.dmtf.org/cimi/1">

<action> http://schemas.dmtf.org/cimi/1/action/export </action>

<format>xs:string</format> ?

<destination> xs:anyURI </destination> ?

<property key="xs:string"> xs:string </property> *

<xs:any>*

</Action>

5.13.4 Ресурс SystemTemplateCollection

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

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

{ "resourceURI": "http://schemas.dmtf.org/cimi/1/SystemTemplateCollection",

"id": string,

"count": number,

"systemTemplates": [

{ "resourceURI": "http://schemas.dmtf.org/cimi/1/SystemTemplate",

"id": string,

... остальные атрибуты SystemTemplate...

}, +

], ?

"operations": [

{ "rel": "add", "href": string }, ?

{ "rel": "http://schemas.dmtf.org/cimi/1/action/import", "href": string } ?

]

...

}

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

<Collection

resourceURI="http://schemas.dmtf.org/cimi/1/SystemTemplateCollection"

xmlns="http://schemas.dmtf.org/cimi/1">

<id>xs:anyURI</id>

<count>xs:integer</count>

<SystemTemplate>

<id>xs:anyURI</id>

... остальные атрибуты System...

</SystemTemplate> *

<operation rel="add" href="xs:anyURI"/> ?

<operation rel="http://schemas.dmtf.org/cimi/1/action/import"

href="xs:anyURI"/> ?

<xs:any>*

</Collection>

5.13.4.1 Операции

Определены следующие специальные операции:

import

/link@rel: http://schemas.dmtf.org/cimi/1/action/import

Данная операция должна импортировать SystemTemplate. Помимо создания SystemTemplate также могут быть созданы экземпляры MachineTemplate, VolumeTemplate и NetworkTemplate, и, возможно, рекурсивно другие экземпляры SystemTemplate и их компоненты в соответствии с записями дескриптора импорта. Дополнительная информация об этом процессе приведена в приложении А.

Входные параметры:

1) "source": тип URI - обязательный

Указывает на местоположение, откуда поступают импортированные данные. На основании конкретного протокола, определенного в URI, Потребитель должен предоставить дополнительную информацию (например, учетные данные) в поле "properties".

Выходные параметры: нет.

Протокол HTTP

Чтобы импортировать SystemTemplate, в URIhttp://schemas.dmtf.org/cimi/1/action/import Ресурса SystemTemplateCollection передают запрос POST, где запрос HTTP должен быть представлен следующим образом:

Тип медиа JSON: application/json

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

{ "action": "http://schemas.dmtf.org/cimi/1/action/import",

"source": string, ?

"properties": { string: string, + } ?

...

}

Тип медиа XML: application/xml

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

<Action xmlns="http://schemas.dmtf.org/cimi/1">

<action> http://schemas.dmtf.org/cimi/1/action/import</action>

<source>xs:anyURI</source> ?

<property key="xs:string">xs:string</property> *

<xs:any>*

</Action>

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


Ресурсы, используемые при конструировании Machine, и отношения между ними приведены на рисунке 3, который представлен в виде схемы отношений Ресурсов, при этом использование UML не является строгим и нормативным.