Не нарушайте сообщения обратной совместимости в системе DDS
Я участвую в проекте, который использует ДДС в качестве протокола для общения и C ++ как язык. Как вы знаете, обмен сообщениями называется темами. Ну, иногда команда должна изменить определение темы, в результате чего другое программное обеспечение, которое зависит от этой темы, перестает работать, необходимо обновлять тему везде и перекомпилировать. Итак, мой вопрос: знаете ли вы, как не нарушить обратную совместимость? Я искал и нашел буфер протокола Google, они говорят это:
«Вы можете добавлять новые поля в форматы сообщений, не нарушая
обратная совместимость; старые двоичные файлы просто игнорируют новое поле, когда
разбор. Так что если у вас есть протокол связи, который использует протокол
буферы в качестве формата данных, вы можете расширить свой протокол без
приходится беспокоиться о нарушении существующего кода.
Любая другая идея?
Заранее спасибо.
Решение
Спецификация OMG Расширяемые и динамические типы тем для DDS (или DDS-XTypes для краткости) решает вашу проблему. Цитируется из этой спецификации:
Система типов поддерживает эволюцию типов, так что возможно
«Развивать тип», как описано выше, и сохранять совместимость
между компонентами, которые используют разные версии типа
Не все реализации DDS в настоящее время поддерживают XTypes, поэтому вам, возможно, придется прибегнуть к другому решению. Например, вы можете включить схему нумерации версий в название своей темы, чтобы избежать конфликтов между различными компонентами. Чтобы гарантировать, что каждый компонент получает нужные данные, которые ему необходимы, вы можете создать службу, отвечающую за пересылку между различными версиями разделов по мере необходимости. Этот сервис должен знать о различных версиях Тем и должен заботиться о заполнении значений по умолчанию и / или преобразовании между их различными типами. Является ли это жизнеспособным решением или нет, зависит, помимо прочего, от требований вашей системы.
Использование системы другого типа, например, буферов протоколов внутри DDS, не рекомендуется, если это просто для решения проблемы эволюции типов. По сути, вы будете передавать свои PB-сообщения как непрозрачные данные в промежуточное программное обеспечение DDS. Это означает, что вы также потеряете некоторые полезные функции инструментов, такие как динамическое обнаружение и отображение типов, потому что сообщения PB не понимаются промежуточным ПО DDS. Кроме того, ваши приложения станут более сложными, потому что они будут отвечать за вызов правильных методов PB de / serialization. Проще позволить DDS позаботиться обо всем этом.
Какой бы путь вы ни выбрали, рекомендуется тщательно управлять развитием модели данных. Если вы позволите кому-либо добавлять или удалять некоторые атрибуты по своему вкусу, ситуацию будет сложно быстро поддерживать.
Другие решения
Уровень поддержки протокольных буферов с DDS зависит от того, как он реализован. Например, с помощью Vortex компании PrismTech вы не теряете ни контент-осведомленность, ни динамическое обнаружение, ни отображение типов, поскольку и промежуточное программное обеспечение, и его инструменты действительно понимают сообщения PB. W.r.t. «заполнение» вашей темы на основе PB, которая соответствует стандарту PB и прозрачно сгенерирована компилятором protoc, поэтому можно утверждать, что если вы знакомы с protobuf (и, возможно, не с альтернативой OMG для IDL), то вы действительно можете извлечь выгоду от правильной интеграции DDS и GPB, которая сохраняет преимущества глобального пространства данных, но icw хорошо известная / популярная система типов (GPB)
Вы можете попробовать обернуть слой DDS в свой собственный уровень связи.
Определите набор типов DDS и профилей DDS, который охватывает все ваши потребности.
Затем каждая тема будет определена как один из тех типов, которые связаны с одним из этих профилей.
Например, у вас может быть тип для строк и двоичный тип.
Если вы используете один и тот же компилятор для всего своего программного обеспечения, вы даже можете безопасно скопировать структуру C в двоичный тип.
module atsevents {
valuetype DataType {
public string<128> mDataId;
public boolean mCustomField1;
public boolean mCustomField2;
};
valuetype StringDataType : DataType {
public string<128> mDataKey; //@key
public string<1024> mData;
};
valuetype BinaryDataType : DataType {
public string<128> mDataKey; //@key
public sequence<octet, 1024> mData;
public unsigned long mTypeHash;
}
}