Создание открытых сетей в реальном мире. Часть 3. Совместимость: проблемы со стандартами
В нашем последнем посте мы рассказали о совместимости, включая открытые стандарты. Продолжая эту тему, мы рассмотрим, как разработчики решений внедряют соответствие стандартам и возникающие при этом проблемы.
Введение
Требование к поставщикам (и внутренним системам) соблюдать открытые стандарты — это стратегия, используемая организациями для обеспечения функциональной совместимости. Предполагается, что компоненты, соответствующие открытым стандартам, будут совместимы.
В этой статье мы рассмотрим множество причин, по которым это предположение не всегда выполняется в реальных ситуациях. Этот анализ будет проведен с точки зрения программного обеспечения, поскольку, как правило, сетевое оборудование лучше справляется с взаимодействием компонентов, чем программное обеспечение. В этом посте также будут рассмотрены общие аспекты соответствия стандартам, а в следующем — конкретные аспекты API.
Реализация программного обеспечения и совместимость на основе что касается стандартов
Независимо от того, является ли стандарт “де-юре” или “де-факто”, существует три основных подхода к обеспечению соответствия программного обеспечения стандартам:
- Совместимость с эталонной реализацией
- Совместимость со справочным документом
- Совместимость с архитектурным шаблоном или руководством
Совместимость с эталонной реализацией
Этот подход состоит из двух частей:
- Стандарт — это контролирующие исходные данные для проектирования, т.е. соответствие требованиям переопределяет другие исходные данные для проектирования; и
- Проверка на соответствие “эталонной реализации” стандарта.
“Эталонная реализация” — это программный компонент, на соответствие которого выдана гарантия в соответствии со стандартом и который является известным эталоном для проверки разработанного компонента. Это также должно включать набор стандартных тестовых примеров, которые проверяют соответствие требованиям и/или выявляют проблемы.
Поставщики часто предоставляют результаты тестирования в качестве доказательства и характеристики уровня соответствия.
Преимущества такого подхода
Это максимально возможный уровень соответствия стандарту. Два компонента, прошедшие проверку на соответствие стандарту, будут совместимы на самом низком общем уровне, на который они оба прошли проверку.
Проблемы, связанные с этим подходом
Эталонная реализация должна существовать и быть доступной, однако это не всегда так. Эталонная реализация должна быть независимо разработана и сертифицирована, часто самим органом по стандартизации.
Совместимость со справочным документом
Этот подход аналогичен подходу к реализации ссылки. Во-первых, документированный стандарт является контролирующим элементом проектирования. Однако вторая часть (проверка соответствия стандарту) является необязательной и сильно варьируется. На самом базовом уровне соответствие может заключаться в том, что поставщик подтверждает соответствие компонентов стандарту. В качестве альтернативы соответствие требованиям может быть подтверждено путем сравнения разработанного компонента с документацией, и существует множество способов сделать это с различным уровнем точности и затрат.
Преимущества этого подхода
Основные преимущества этого подхода заключаются в том, что дизайн приведен в соответствие со стандартом, и на этом уровне он эквивалентен эталонному подходу к внедрению.
Проблемы, связанные с этим подходом
Проверка без эталонной реализации в значительной степени выполняется вручную и потенциально может быть интерпретирована. Этот тип проверки является очень дорогостоящим, что создает для поставщиков дополнительные затраты на частичную проверку, особенно при повторных обновлениях версий и улучшениях.
Совместимость с архитектурными шаблонами
В этом случае стандарт используется как один из входных данных для проектирования, но не как управляющий вход. Целью является не соответствие, а согласование. Продукт может использовать те же или аналогичные базовые технологии, которые определены в стандартах (например, интерфейсы REST), или те же базовые стандарты представления данных, такие как XML или JSON. Поставщик может использовать архитектуру компонентов, аналогичную стандартной (например, микросервисы).
Преимущества этого подхода
В лучшем случае, этот подход может обеспечить основу для будущего соответствия требованиям.
Проблемы, связанные с этим подходом
Как правило, поставщик разрабатывает свой продукт таким образом, чтобы он “не был несовместим” со стандартом, не беря на себя расходы по обеспечению полного соответствия.
Причины, по которым поставщики должны внедрять стандарты
Соблюдение стандартов требует больших затрат, независимо от используемого подхода. Таким образом, каждый поставщик будет использовать свой собственный подход, основанный на их собственной ситуации и контексте. Поставщик может:
- Полностью игнорировать проблему стандартов
- Намеренно, например, начинающий производитель, чьи ранние целевые клиенты не обращают на это внимания.
- Случайно, если они не знают о стандартах.
- Не видят конкурентного преимущества на своем рынке: не настолько, чтобы оправдать затраты на внедрение стандартов.
- Применяйте индивидуальный подход: другими словами, внедряйте стандартизацию, когда это необходимо.
- В своей дорожной карте для будущего внедрения они должны полностью соответствовать требованиям и просто хотят создать основу для дальнейшего развития.
Проблемы с соответствием требованиям
Существует широкий спектр реализаций, и результаты сильно различаются. Важно помнить, что заявление о “соответствии стандартам” может означать многое.
Начиная с намерения соответствовать требованиям (или, по крайней мере, заявлять о соответствии) и используя любую из вышеперечисленных стратегий, поставщик может по многим причинам не соответствовать требованиям:
- Частичная реализация, например, индивидуальное решение для одного клиента, который “продуцируется”;
- Дефекты в реализации, включая неправильное толкование стандарта;
- Преднамеренное расширение стандарта, включая реализацию дополнительных функциональных возможностей (“наше решение лучше стандарта”);
- Несовместимость базовых или связанных компонентов;
- Соответствие ограниченным подмножествам стандарта, например, наиболее часто используемым функциям;
- Некоторые поставщики могут неверно представлять соответствие, основываясь на незначительных связях: например, поставщик может заявлять о совместимости на веб-сайте. на основании того, что их API основаны на REST и не более того.
Заключение
Нельзя ничего утверждать о соответствии стандартам, кроме того, требования каждого поставщика должны быть подтверждены. Другая часть этой проблемы — совместимость интерфейсов прикладных программ (API). Мы рассмотрим это в следующем посте. Оставайтесь с нами.
Станьте более гибкими.
Получите индивидуальное решение, созданное специально для вас.
Узнайте больше
О создании реальных открытых сетей. Часть 3 – Совместимость: проблемы со стандартами впервые появились на Aptira.
Другие новости: