Есть ли альтернатива XML-схеме с поддержкой универсальных типов?

Question

Привет, У меня много проблем при реализации модельно-ориентированной архитектуры. Существует спецификация для информационной модели, которая использует универсальные типы и наследование. Он предназначен для реализации на разных языках на разных платформах (MS, * nix, OsX ..)

Проблема в том, что XML-схема рассматривается как первый инструмент для представления этой информационной модели. Предполагается, что все связано с XML. Однако XML-схема не поддерживает универсальные типы, которые соответствуют универсальным типам в Java, C # и т. Д. Стирание типов в реализации универсальных шаблонов Java также является другой большой проблемой, но с формализмом моделирования, который поддерживает универсальные шаблоны, я могу найти это.

Поэтому мне нужен вычислимый стандарт, который позволяет мне выражать эту информационную модель с использованием универсальных типов и наследования. В XML-схеме я не могу выразить универсальные типы, поэтому при переходе из [Спецификация информационной модели] - ~~~ -> [XML-схема] теряется информация, что вызывает много проблем.

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

Я чувствую себя в ловушке со всеми этими ограничениями. В настоящее время я вынужден использовать какую-то другую форму представления поверх XML-схемы, чтобы отслеживать универсальные типы, и это не очень хорошее решение.

Любые предложения приветствуются

С уважением Seref

Answer 1

Я чувствую, что вы, возможно, слишком много просите о своем уровне модели.

XML часто используется для задач интеграции, поскольку вы можете представлять и сериализовать структурированные данные в полустандартизированном виде. Однако для каждой подсистемы вам все равно придется решать проблемы, возникающие при (не) маршалинге ваших живых данных; почти всегда есть небольшое несоответствие.

Так что я думаю, что вы должны принять, что ваша каноническая модель данных (представленная в виде XML-типов и событий) не совпадает один-на-один с OO- или реляционной моделью каждой подсистемы или не охватывает все их детали, такие как использование обобщенных типов. Соединители (веб-службы SOAP, анализаторы файлов, ESB или любая другая инфраструктура, которую вы будете использовать) должны переводиться в / из вашей канонической модели. Каноническая модель данных должна быть «ведущей», достаточно детализированной, чтобы учитывать все бизнес-требования, и достаточно общей, чтобы оставить некоторую свободу действий для разных подсистем с разными внутренними представлениями.

Надеюсь, что это даст новое понимание и поможет вам найти правильное решение.

Answer 2

Почему вы не хотите придерживаться модели реляционных таблиц в качестве основы, если вы используете подход, основанный на моделях?Это звучит вполне разумно в этом случае.Если бы у вас была независимая от RDMS модель (в DDL, например, CREATE TABLE...), вы могли бы использовать инструменты любого языка для ее решения (генерировать исходный код и т. Д.).Я согласен, что наследование в DDL довольно громоздко, но все же возможно (например, см. эту статью )

Answer 3

Сереф, я согласен с тем, что схема XML на самом деле не подходит в качестве основы для информационного моделирования, если документы XML не являются единственным или основным способом представления информации, и даже в этом случае это зависит.

Я также согласен с @denisk, что реляционная модель, используемая для баз данных, кажется лучшей идеей.

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

Вы рассматриваете метамодели объекта (.NET или Java); они более выразительны, но они предназначены для представления данных в памяти, поэтому они подойдут, если это ваш основной способ представления информации, на основе которой происходит все остальное. Кроме того, как вы упоминаете, специфические для языка функции (например, обобщенные) будут привязывать вас к этому языку или создавать проблемы перевода. Если вы хотите пойти по этому пути, лучше использовать UML.

Лучший подход зависит от ваших требований. Какие проблемы вы можете решить с помощью дженериков? Какие предположения и сильные пожелания вы можете высказать в отношении того, как ваша информация хранится, сериализуется и доступна из кода приложения? Например. будет ли хранилище распределено или в центральной базе данных? Могут ли разные приложения, даже на разных языках, получать доступ к одной и той же информации, даже в одно и то же время? И т.д.

Answer 4

Я думаю, у вас есть ошибка категории в описании схемы XML как "не поддерживающей обобщений".Схема XML, естественно, не отображается на множество конструкций Java, C ++ или C #.У него есть типовая модель, которая сильно отличается.Отсутствие чего-либо, похожего на универсальный или параметризованный тип, является довольно незначительным моментом.

Общие библиотеки, которые навязывают отображение из XML-схемы в языки (JAX-B, xmlbeans, отображения Microsoft .NETработать, отказываясь иметь дело с некоторыми более ориентированными на документы частями XML-схемы, а затем довольно произвольно отображать остальные.Отсутствие обобщений - это не характеристика схемы XML, а характеристика этих слоев отображения.

Например, при использовании JAX-B ничто не мешает вам писать плагины для реализации некоторого соглашения для обобщений.Это не поможет вам с .NET.

Основная трудность здесь заключается в том, что XML-схема никогда не предназначалась как система кросс-языкового типа для произвольных структур данных.Он был предназначен для описания и ограничения содержимого документов XML.