Всё вместе¶
Ух, какую же большую кучу из разных технологий и идей мы свалили с начала статьи. Пора бы её разобрать и по коробкам разложить.
Итак,
Транспорт
- SSH,
- HTTP,
- HTTP/2
- SNMP тоже, конечно же, возможен, но не нужен.
Интерфейс
- CLI
- SNMP
- NETCONF
- RESTCONF
- gRPC
Формат данных
- Текст
- XML
- JSON
- Protocol Buffers
Способ описания спецификации - он же может называться схемой
- XSD
- JSON schema
- Protocol Buffers
- MIB
- Проприетарный способ, придуманный вендором и описанный в документации.
YANG-модели данных конфигурации
- OpenConfig
- Проприетарные модели
- IETF
- Проприетарная модель, придуманная вендором и неописанная в документации
Языки описания моделей
YANG
SMI/SMIng
Проприетарный язык, придуманный вендором и не описанный в документации
И ещё другими словами¶
- YANG - язык моделирования данных, но не сами модели,
- YANG-модели - конкретные модели, написанные на языке YANG, но ещё не сами данные и не их схема,
- OpenConfig - вендор-независимая YANG-модель данных конфигурации сетевого оборудования,
- Native-модели - вендорские проприетарные YANG-модели данных сетевой конфигурации,
- XML, JSON, Protobuf - синтаксис по представлению структур данных в виде, пригодном для передачи (например, строка), иными словами - сериализация,
- XML-схемы (XSD), JSON-схемы, proto-спецификации - репрезентация YANG-модели в соответствующем формате, схема
- NETCONF - протокол взаимодействия с сетевым железом, работающий поверх SSH. В качестве формата данных использует XML. Структура XML может быть основана на YANG-модели, но не обязательно,
- RESTCONF - аналог NETCONF, но работающий через HTTP. Данные представляются в JSON или XML на основе какой-либо YANG-модели,
- gRPC - фреймворк для межсервисного взаимодействия, которые реализует интерфейс, протокол, формат данных и спецификации (protocol buffers). Непосредственно к сетям отношения не имеет,
- Protobuf - он же protocol buffers - спецификация для gRPC, а так же формат передачи данных в нём,
- gNMI - протокол на основе gRPC для взаимодействия с сетевым оборудованием. Всегда основан на модели, представленной в формате protobuf-спецификации, но это не обязательно должна быть YANG-модель.
И чтобы окончательно разобраться в терминах, давайте разложим по полочкам: схема, спецификация, IDL.
Схема - это широкий термин. Это то, что описывает, как данные должны быть представлены и чему соответствовать: структура, иерархия, типы итд.
Думаю, что слова «схема» и «спецификация» мы можем считать синонимами.
Для каждого формата данных будет так же и свой формат написания схем.
Для XML - это XSD, для JSON - JSON-schema, для gRPC - protobuf.
А уже конкретный файл/текст, описывающий какие-либо данные - это и будет сама схема.
Соответственно данные можно провалидировать по схеме - убедиться, соответствуют ли они ей.
Из схемы/спецификации можно создать объекты языка программировани, чтобы было удобнее работать с ними.
То есть из XML-схемы создаём классы, например, питона, работаем с ними привычным образом, далее преобразуем в XML, который можно уже проверить на соответствие изначальной схеме. Или данные, полученные из какой-то внешней системы, можно проверить на такое соответствие, прежде чем начинать обрабатывать.
IDL - его назначение прямо следует из названия - язык определения интерфейса. Если схема описывает как данные выглядят вообще, то IDL определяет, как две системы должнц представлять данные, чтобы взаимодействовать друг с другом. То есть это уже контракт между ними, а схема - это инструмент, позволяющий этого добиться.
Таким образов в gRPC protobuf является и IDL и способом описания спецификацией. В случае NETCONF формат данных - это XML, способ описания спецификации - это XSD, а в качестве IDL выступает сам NETCONF - ведь именно он и определяет интерфейс.
Модель же определяет то, как будет выглядеть сама спецификация/схема. То есть это ещё более абстрактная конструкция. И нужна модель для того, чтобы на её основе была возможность создать как proto-спеку, так и JSON-схему, так и XSD.