ГОСТ Р ИСО/МЭК 17826-2015
15.3 Импорт сериализованных данных
Канонические данные могут быть десериализованы обратно в облако, создавая новый объект
данных, контейнер или очередь; для этого следует указать, что источником данных для создания явля
ется десериализация заданного объекта, либо поместить сериализованные данные в кодировке base 64
в поле deserializevalue.
Объект назначения может как существовать заранее, так и создаваться заново. Если контейнер
уже существует, операция обновления с сериализованным потомком должна обновить контейнер и
всех ого потомков. Если сериализованный контейнер не содержит потомков, только объект-контейнер
будет обновлен. Объекты данных воссоздаются в соответствии с каноническим форматом, включая все
метаданные и ID объекта.
• Если пользователь, который выполняет десериализацию сериализованных данных, имеет пра
ва «cross_domain» и не указал domainURI как часть операции десериализации, будет использовано
исходное поле domainURI сериализованного объекта. Если некоторые из указанных domainllRI некор
ректны в контексте системы хранения, в которой выполняется десериализация, вся операция десериа
лизации доложна быть отменена.
• Если пользователь, который выполняет десериализацию сериализованного объекта, указывает
domainURI как часть операции десериализации. domainURI каждого десериализуемого объекта уста
навливается в указанное значение. Чтобы указать domainURI. отличный от domainURI родителя, поль
зователь должен иметь права cross_domain. Если у пользователя нет таких прав, и указан domainURI,
отличный от domainURI родителя, должен быть возвращен ответ 400 Bad Request.
• Если пользователь, который выполняет десериализацию сериализованного объекта, не указы
вает domainURI как часть операции десериализации и не имеет прав «cross_domain», десериализация
должна быть успешной только если у всех объектов тот же domainURI. что у родительского объекта,
на котором выполняется десериализация.
Операции десериализации должны восстанавливать все метаданные из указанного источника.
Если в исходном сериализованном объекте были использованы расширения производителя через про
извольные ключи и значения метаданных, эти произвольные требования должны быть восстановлены
при десериализации. Однако произвольные метаданные (ключи и значения) могут быть
интерпретиро ваны как пользовательские метаданные (сохраняться, но не обрабатываться).
Такое сохранение позволяет перемещать между облаками данные произвольной конфигурации.
15.3.1 Канонический формат
Канонический формат должен представлять указанные объекты данных и контейнеры как если
бы они существовали в системе хранения. Каждый объект должен представляться метаданными объ
екта. идентификаторами и потоком данных объекта данных. Поскольку метаданные наследуются от
контейнеров более высокого уровня, все родительские метаданные должны быть представлены в ка
нонической форме (существенно уплощая иерархию). Для сохранения текущих значений метаданных,
относящихся к сериализуемому объекту, не перезаписанные метаданные включаются как из непосред
ственного родительского контейнера, так и от родительских контейнеров более высокого уровня.
Канонический формат должен обладать следующими свойствами.
- рекурсивное представление JSON для объектаданных, совместимое с остальной частью CDMI;
- метаданные пользователя и системы данных для каждого объекта данных/контейнера;
- содержимое потока данных для каждого объекта данных и очереди;
- двоичные данные представляются в форме строк JSON;
- типы значений данных совместимы с JSON представлениями CDMI.
15.3.2 Пример канонического сериализованного формата JSON
П р и м е р - Для сериализации выбраны объект данных и очередь в контейнере:
{
«objectType»: «application/cdmi-container»,
«objectID»: «00007E7F00102E230ED82694DAA975D2»,
«objectName»: «MyContainer/»,
«parentURI»: к/»,
«parentID»: •00007E7F0010128E42D87EE34F5A6560».
«domainURI»: «/cdmi_domains/MyDomain/»,
«capabilitiesUR!»: «/cdmi capabilities/container/»,
121