Структурные типы принципиально сходны с ранее рассматривавшимися AV-списками, но характерным свойством ASN.1 является то, что в конкретном представлении согласно правилам кодирования передаются типы данных - элементов структурного типа, а не их названия. Название элемента сохраняется на уровне спецификации. Это общий принцип, активно используемый во всех стандартных форматах. С некоторыми натяжками, можно нарушить этот принцип, за счёт трюка - активного использования неявного тегирования контекстно-специфичными типами; это имеет смысл в том случае, когда конкретный набор данных структуры обычно содержит малую часть от всего возможного состава полей структуры. Но в этом случае спецификация всё равно определяет твёрдый порядок таких полей. Оборотной стороной является то, что передача произвольного списка параметров с их названиями требует как минимум выделенной подструктуры (типа set).

И элементарные, и структурные типы делятся на 4 класса - universal (общий); специфичный для данного контекста (context-specific); для применения (application); частный (private). В общий класс входят представления числа, строки, даты, etc.; их достаточно для подавляющего большинства применений. Класс типов для применения расширяет общий класс тем, что нужно конкретному применению, причём понятие "применения" здесь ближе всего к понятию "общая задача". Например, в SNMP это IP-адрес, счётчики. Контекстно-специфичный тип имеет значение только в пределах определённой грамматической позиции (структура определённого типа); пространства таких типов в разных грамматических позициях не пересекаются. Контекстно-специфичные типы ближе всего к понятию названия элемента, выраженного числом (номером типа).

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

В качестве примера представим себе развитие формата данных "ответ на запрос". Пусть в начальной версии такого ответа предполагалось только наличие кода ошибки, взятого из errno C-среды Unix, и текста, который является расшифровкой этого кода стандартной функцией strerror(). В таком случае формат представляется следующим образом:

Response ::= SEQUENCE {
    ErrorCode                   INTEGER,
    ErrorDescription            IA5STRING OPTIONAL
}

Для случая отсутствия ошибки передаётся последовательность (sequence) из одного целого числа 0; в случае ошибки, число должно быть более 0, а текст обязан присутствовать. Пока не меняются качественные требования, данный формат устойчив; например, целое поле позволяет передавать числа практически сколь угодно большого размера, и даже код ошибки со значением около трёх триллионов будет передан без проблем; описание, аналогично, сможет "выдержать" даже гигабайтный текст.

Пример кодирования такого Response в BER, если ErrorCode == 198256, а ErrorDescription == "Bar impact":

30 11 02 03 03 06 70 16 0A 42 61 72 20 69 6D 70 61 63 74

Он состоит из:

• внешнего указания "sequence" ("30") с длиной содержимого 17 байт ("11");
• целого ("02") длиной 3 ("03") со значением 198256 ("03 06 70");
• IA5 (то есть ASCII) строки ("16") длиной 10 ("0A") значением "Bar impact" ("42 61 72 20 69 6D 70 61 63 74").

Полное представление вложенного данного "целое число" занимает 5 байт, строки - 12, в сумме получается 17 байт - длина sequence.

Далее мы не приводим детальную расшифровку представления в BER.

Потом требования поменялись, и нам надо расширить данную структуру следующими данными:

1. Код ошибки, сгенерированный приложением на основании своей логики, из своего пространства кодов ошибок. (Напоминаю, что разные версии Unix имеют разные значения для одноимённых кодов errno, поэтому идея передавать число, специфичное для конкретной машины, была изначально ошибочной.)
2. Уточнящий код для основного кода ошибки (не всегда присутствует).
3. Сообщение, описывающее код ошибки из первого пункта; необязательное.
4. Сообщение, описывающее уточняющий код.
5. Сопроводительный текст для диагностики.

Нарисуем предположительную схему получившегося:

Response ::= SEQUENCE {
    SysErrorCode                INTEGER,
    SysErrorDescription         IA5STRING OPTIONAL,
    MyErrorCode                 INTEGER OPTIONAL,
    MyErrorDescription          UTF8STRING OPTIONAL,
    MyErrorDetailCode           INTEGER OPTIONAL,
    MyErrorDetailDescription    UTF8STRING OPTIONAL,
    DiagnosticsText             UTF8STRING OPTIONAL
}

(обратите внимание на переименование первых двух полей - оно абсолютно ни на что не влияет, но полезно для уточнения их смысла.)

Это не пройдёт проверку компилятором описания ASN.1 хотя бы из-за двух последних пунктов: невозможно, разбирая содержимое, однозначно определить, какой из двух необязательных (optional) параметров присутствует. Также, встретив данное типа UTF8STRING, можно предположить, что это MyErrorDetailDescription (при пропущенном MyErrorDetailCode). Как такое лечится? Например, можно всем новым полям назначить теги:

Response ::= SEQUENCE {
    SysErrorCode                INTEGER,
    SysErrorDescription         IA5STRING OPTIONAL,
    MyErrorCode                 [0] INTEGER OPTIONAL,
    MyErrorDescription          [1] UTF8STRING OPTIONAL,
    MyErrorSubDetailCode        [2] INTEGER OPTIONAL,
    MyErrorSubDetailDescription [3] UTF8STRING OPTIONAL,
    DiagnosticsText             [4] UTF8STRING OPTIONAL
}

Такое тегирование - один из самых простых способов разрешить конфликты; при чтении, например, видя context-specific type 2, код разбора будет сразу понимать, что это MyErrorDetailCode (и его тип INTEGER), а 0 - MyErrorCode (с тем же типом); строковые данные тоже будут различаться тегом. Пропуск любого из элементов сохраняет однозначность разбора всей структуры. С другой стороны, этот вариант разрешает комбинации, которые с точки зрения здравого смысла должны быть запрещены: например, наличие MyErrorDescription при отсутствии MyErrorCode. Если это является существенным, можно переделать следующим образом:

ErrorDescription ::= SEQUENCE {
    Code                        INTEGER,
    TextComment                 UTF8STRING OPTIONAL
}

Response ::= SEQUENCE {
    SysErrorCode                INTEGER,
    SysErrorDescription         IA5STRING OPTIONAL,
    MyError                     ErrorDescription OPTIONAL,
    MyErrorSubDetail            [0] ErrorDescription OPTIONAL,
    DiagnosticsText             [1] UTF8STRING OPTIONAL
}

В этом варианте возможно появление MyError без MyErrorSubDetail, и наоборот; допустимо и наличие, и отсутствие обоих; наличие или отсутствие DiagnosticsText никак не связано с наличием предыдущих полей; для каждого описания ошибки может быть код без текста, но не текст без кода. Цена за это - бо́льшая вложенность структуры, и то, что нельзя будет добавить ещё одно поле типа ErrorDescription, не зависящее от наличия предыдущих полей, не выделяя ему свой контекстный тег. В таком варианте разрешено иметь MyErrorSubDetail без MyError; средствами представления структуры это не запрещается, что является некоторым недостатком такого построения. Если это важно, то надо было бы их выделить в отдельную подструктуру.

Осталось решить, что делать с первыми двумя полями, если не можем задать им разумные значения. Так как SysErrorCode (ErrorCode в первой версии) уже описано как существующее, совсем не передавать его нельзя, в отличие от SysErrorDescription (ErrorDescription в первой версии), которое можно опустить из-за того, что IA5STRING имеет другой код типа, чем UTF8STRING. Для совместимости с прежними реализациями можно в SysErrorCode или передавать заведомо ранее невозможное значение типа -1, или выбрать какой-то "универсальный" код из errno. Эта проблема показывает, что несовместимое изменение имеет определённые проблемы даже в случае таких форматных схем.

V.4. JSON и YAML.

Группа форматных схем, представителями которых являются JSON и YAML, моложе своих конкурентов (XML, ASN.1); она появилась как средство предельного и быстрого решения задачи по переносу данных в достаточно произвольной структуре между двумя сторонами, основанными на так называемых "скриптовых" языках - то есть интерпретируемых и с динамической типизацией. Но практика показала пригодность их использования и для множества других случаев.

Общий принцип построения такой схемы предельно прост. Элементом данных является число (целое или вещественное), строка, булевские значения (истина/ложь), специальное значение "ничего" ("null" в JSON), и два сложных типа данных - список и словарь (объект). В списке могут быть разнородные или однородные данные, это ничего не меняет в его конструкции. Словарь (объект) является набором пар ключ-значение, причём ключи уникальны в пределах словаря, и может быть ограничение (JSON), что ключ может быть только строкой. Нетрудно убедиться, что при всей простоте данного метода его достаточно для представления любых данных. В конкретных схемах могут быть непринципиальные расширения возможностей (которые на практике очень редко используются именно из-за выхода за пределы общего базиса).

Например, рассмотренная выше в обсуждении ASN.1 структура ответа может получить такую конкретную реализацию (объект ответа):

{
    "ErrorCode": -1,
    "MyError": {"Code": 242, "Description": "Principal data not found"},
    "MyErrorSubDetail": {"Code": 11, "Description": "File not found"}
}

Сравним эти схемы (в качестве представителя возьмём JSON) с конкурентами. Для начала, сравним с XML.

Представление в JSON точно так же текстовое и опирается на имена атрибутов, но в среднем оно существенно экономнее за счёт отсутствия дублирования названий тегов.

JSON требует представления данных (строк, чисел) в каноническом виде, в отличие от XML, который позволяет в принципе любое представление; это можно обойти, представив всё в виде строк с собственным содержимым, но это уже явный хак.

Атрибуты объекта отсутствуют (впрочем, как и собственно его название), что требует иной организации данных в структурах. Для начала, в XML возможно различение содержимого по типу документа и по названию типа коренной структуры (если поступило <foo>...</foo> - один метод разбора, а если <foo2>...</foo2> - другой); для JSON это напрямую невозможно, а если требуется - надо самому делать что-то вроде {"foo":{...}}, но обычно такое не закладывается с самого начала. Далее, представим себе следующий объект XML:

<foo>
  <bar name="a">1</bar>
  <bar name="b">2</bar>
  <baz name="p">99</bar>
  <baz name="q">88</bar>
</foo>

[                       ## представляем как тройку - имя, атрибуты, вложенное
    "foo",
    {},                 ## атрибуты - отсутствуют
    [                   ## список подэлементов
        ["bar", {"name": "a"}, ["1"]],
        ["bar", {"name": "b"}, ["2"]],
        ["baz", {"name": "p"}, ["99"]],
        ["baz", {"name": "q"}, ["98"]]
    ]
]

но более естественной будет следующее (предполагая уникальность имён объектов типа bar и baz):

{
    "bar": {"a": 1, "b": 2},
    "baz": {"p": 99, "q": 88}
}

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

Наконец, представление в JSON напрямую отображается на внутренние структуры таких языков, как JavaScript/ECMAScript (откуда он и происходит), Perl, Python, Ruby и так далее, и обратно, в отличие от XML, которому требуется специальный кодер или декодер (парсер). Это и преимущество, и недостаток. Преимущество - значительно более простая работа с ним в типичных случаях. Недостаток - отсутствие валидации; тривиально как прочесть извне некорректную структуру, так и выдать её внешнему получателю. Валидация требует отдельного явного обработчика.

Теперь сравнение с ASN.1 и её стандартными форматами передачи:

Представление опирается на имена атрибутов, а не на типы. Соответственно, уже назначенное имя не переименуешь без изменения всего поддерживающего кода. С другой стороны, лежащее за конкретным именем содержимое может легко менять тип; для ASN.1 это возможно только при заранее предусмотренном явном тегировании (explicit tagging), а иначе изменение типа записи невозможно или крайне ограничено.

XXX TBC

V.5. Другие структурированные форматные схемы.

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

• Google Protocol Buffers
• bencode

V.6. Использовать ли структурированную форматную схему?

Можно определить следующее правило: если нет суровой необходимости экономии ресурсов на представление (объём), кодирование и декодирование (соответственно, затраты процессора на собственно работу с данными и работу с метаданными), но есть потенциальная возможность введения новых требований и расширения формата, является желательным использовать структурированной форматной схемы как основы форматов данных протокола. Желательность здесь происходит из того, что, с одной стороны, в этих схемах уже решена основная (часто и подавляющая) часть вопросов представления, с другой стороны, заведомая неограниченная расширяемость позволяет следовать постоянно меняющимся внешним требованиям. На сейчас XML является одним из наиболее распространённых промышленных стандартов представления данных и для передачи по сети, и для локального хранения, хотя это не означает, что именно его надо использовать по умолчанию для новых разработок; почти всегда, JSON лучше подходит для этого.

V.7. Место структурированных форматных схем в протоколах

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

Одним из типичных вариантов является, особенно в "enterprise" применениях, использование какого-то общедоступного протокола, как HTTP, для реализации транспортного слоя, и тел запроса и ответа, представленных как XML или JSON.

Copyright (C) 2010-2015 Valentin Nechayev. All rights reserved.
Разрешается полное или частичное копирование, цитирование. При полном или частичном копировании ссылка на оригинал обязательна.