#java #architecture #xsd #backwards-compatibility
#Ява #архитектура #xsd #обратная совместимость
Вопрос:
Я работаю над приложением JavaEE, частью большой экосистемы, которое имеет особенно громоздкие ограничения.
Модель приложения основана на классах Java, созданных из xsds с использованием XJC. В деталях приложение взаимодействует с внешними системами с помощью API REST, которые используют тело XML, которое затем не привязывается к соответствующей внутренней модели класса с помощью JaxB и xsd. Эти XML-файлы фактически представляют структуру документа.
Проблема в том, что обновления на этих XSD происходят довольно часто, и приложение должно соответствовать им. Эти обновления включают добавление новых элементов, обновления, удаления и т.д. Поэтому классы восстанавливаются после каждого обновления. Приложение должно быть обратно совместимым, например, пользователь должен иметь возможность вносить исправления в xml-документ версии 1, хотя текущая версия 2 и т. Д.
Как можно устранить такое ограничение с точки зрения архитектуры? Мы добавили lt;modelVersiongt; тег в xmls, но у нас все еще есть проблемы с обратной совместимостью. Есть ли какой-либо способ эффективно исправить xml с устаревшей версией?
Поскольку мы зашли в тупик в моей команде, любая помощь была бы признательна.
Комментарии:
1. Навязывание вариаций инвариантных ограничений по своей сути проблематично. Управление версиями-это сложная, многогранная тема, которая в целом выходит далеко за рамки простого переполнения стека Q/A. Вам понадобятся тщательно продуманные упрощения, консультант по высокому штангенциркулю или, предпочтительно, последний, который проведет вас через первое, чтобы принять лучшие дизайнерские решения.