Взаимные превращения JSON, YAML, XML

    JSON, YAML сейчас популярны, а XML технологии считаются пережитком прошлого.


    Попробуем использовать «ретро технологии» для работы с данными в формате JSON и YAML. И порассуждаем о причинах применять их в наши дни.

    Есть задача — логику трансформации данных вынести в конфигурацию приложения, желательно в декларативном стиле и унифицировано для разных форматов. Данные могут быть в различных текстовых форматах сериализации json, yaml, xml, java properties, ini file. Но при этом Data Lake слишком тяжелая артиллерия для этого. Помещать данные в документоориентированную или объектно-реляционную базу и пытаться выполнять запросы по загруженным туда данным тоже over engineering для первого этапа ETL трансформации.

    JsonPath повторяет подмножество XPath, но только к JSON формату. И написать декларативный запрос без программирования не выйдет — нет аналога XQuery. Как вариант — можно было бы использовать какую-либо embedded database в jvm с ее декларативным языком запросом, но это тема для отдельной публикации и исходная модель данных в json, yaml не реляционная.

    Подход к запросам данных из JSON/YAML


    XQuery можно выполнять над данными в Document Object Model. Как бы преобразовать данные из JSON/YAML в DOM объект… Можно воспользоваться camel-xmljson или json2xml. В этих библиотеках источник данных только json. Поэтому помчим на своем dom-transformation велосипеде. Эта библиотека умеет принимать на вход Map<String, Object> и превращать его в org.w3c.dom.Node, а так же есть обратное преобразование.

    Осталось научиться превращать JSON и YAML в Map<String, Object>. Например, это можно сделать с помощью класса com.fasterxml.jackson.databind.ObjectMapper из jackson.

    Превращаем JSON в Map:

    ObjectMapper mapper = new ObjectMapper();
    Map<String, Object> objectTree = mapper.readValue(yaml, new TypeReference<Map<String, Object>>() {});
    

    Превращаем YAML в Map:

    ObjectMapper mapper = new ObjectMapper(new YAMLFactory());
    Map<String, Object> objectTree = mapper.readValue(yaml, new TypeReference<Map<String, Object>>() {});
    

    Превращаем Map в Document Object Model, подключив к проекту библиотеку:

    
    DomTransformer toDom = new DomTransformer(new TypeAutoDetect()).transform(objectTree.size() == 1 ? objectTree : Collections.singletonMap("root", objectTree));
    Node document = toDom.translate(objectTree);
    

    Можно использовать любую реализацию XQuery для выполнения запросов. Мне нравится basex как до сих пор развивающийся open source проект. Подключаем к проекту зависимость org.basex:basex:jar:9.0 и выполняем декларативный запрос:

    
    String yaml = IOUtils.toString(TranslateTest.class.getResource("/pipeline.yml").toURI(), StandardCharsets.UTF_8);
    ObjectMapper mapper = new ObjectMapper(new YAMLFactory());
    Map<String, Object> objectGraph = mapper.readValue(yaml, new TypeReference<Map<String, Object>>() {});
    
    Node document = new DomTransformer(new TypeAutoDetect()).transform(
                            objectGraph.size() == 1 ? objectGraph : Collections.singletonMap("root", objectGraph));
    
    try(QueryProcessor proc = new QueryProcessor("declare variable $extDataset external; " +
            " $extDataset//*[text()='git-repo']", new Context())) {
        proc.bind("extDataset", document);
        Value queryResult = proc.value(); // execute the query
        queryResult.iter().forEach(System.out::println);
    }
    

    Результаты работы для данных из pipeline.yml



    Если же нужно преобразовать DOM/XML в JSON/YAML с помощью jackson, то transform(Node currentNode) может помочь в этом.

    Выводы


    С помощью XQuery можно выполнять запросы не только к XML данным. С чем этот язык запросов до сих пор успешно справляется и этот «старичок» еще поживет в java проектах по трансформации данных даже в форматах JSON и YAML.

    Конечно, слабоструктурированные данные это не только JSON, YAML и XML. И ставить точку в обработке всего на свете еще рано…



    Надеюсь, что подход из публикации поможет вам выполнять в приложении декларативные запросы по разнородным данным. Или же вы сталкивались с подобной задачей в JVM и у вас есть идеи лучше, делитесь в комментариях!

    26 апреля мы с коллегой проводим открытый java meetup в московском офисе. Будем рады гостям!
    Вы сможете отдохнуть после рабочего дня, узнать что-то новое, подискутировать, перекусить пиццой и пообщаться с разработчиками.

    Встреча пройдёт 26 апреля 2018 19:00-21:00 в московском офисе «Aligh Technology» по адресу Варшавское ш., 9, стр. 4. Регистрация по ссылке: Amazon Web Services и JVM для server side проектов.

    В программе три доклада.

    Эмуляция Amazon web services в JVM процессе: ускоряем разработку, тестирование и экономим деньги.

    Спикер: Игорь Сухоруков

    Как эффективно разрабатывать Big Data приложения на инфраструктуре Amazon Web Services‎. Постараемся чтобы локально разрабатывать решение было просто, а интеграционные тесты работали быстро и максимально дешево для нас. Помним об экономии, пока глава Amazon — Джефф Безос запускает ракеты в Blue Origin и гуляет с роботом SpotMini от Boston Dynamics. В докладе расскажу как получилось эмулировать S3 filesystem, Redshift data warehouse, SQS queues, PostgreSQL RDS service в JVM процессе на основе open source проектов. В рамках доклада также будет сравнение популярных Big Data решений для BI аналитики.

    Код для продакшена.

    Спикер: Юрий Геиниш

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

    Мельдоний для Groovy: витаем в «облаках» или погружаемся в «кровавый enterprise»

    Спикер: Игорь Сухоруков

    В «облаках» с Groovy на стероидах можно сделать больше и удобнее. Поговорим о динамической загрузке классов из maven артефактов и о том как удобно запускать скрипты в Amazon Web Services‎ и Docker контейнерах. Как выжить скриптам в изолированном корпоративном окружении. И конечно же похоливарим тему зачем нужен Groovy, когда есть Kotlin.

    Похожие публикации

    Средняя зарплата в IT

    120 000 ₽/мес.
    Средняя зарплата по всем IT-специализациям на основании 7 453 анкет, за 1-ое пол. 2021 года Узнать свою зарплату
    Реклама
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее

    Комментарии 11

      +1
      Нужно ещё больше парсинга. Парсинг должен жрать как можно больше ЦПУ. А ещё всё ч-з стримы, чтобы их тоже парсить. Весь этот популизм с JSON и CBOR и «зелёная» экономия, совсем не суровый энтерприйз. Как можно жить беза стэка из 10 парсеров?
        +1
        Когда волшебные единороги будут кушать радугу и на выходе будет один лишь эффективный, компактный бинарный формат, то жизнь разработчиков, в окружении бабочек, станет радостной и беззаботной. А пока приходится извлекать и трансформировать то, что выдают десятки разных приложений в их «родных» форматах.
          0
          XML в большинстве случаев можно проверить и десереализовать в объект более-менее стандартными инструментами. А для того, что я нередко вижу на YAML нужен каждый раз какой-то индивидуальный подход. Например, в docker-compose имена серверов — не значения (value), а ключи (key).
            0

            Можно подумать, в xml нельзя записать что-то в тело, а что-то в аттрибут тэга. Или вот есть ещё интерксный формат plist, основанный на xml.

              0
              Можно. Но в чем проблема-то?
                0

                Ну вот выше у человека проблема, что имя сервера в docker-compose.yml — ключ, а не значение. Неужели это большая проблема чем то, что я написал про xml?

                  0
                  Да. Известные мне десериализаторы не испытывают никаких проблем с чтением атрибутов элемента.

                  А вот в случае когда имя является ключом в json — то единственным вариантом становится десериализация в словарь или какой-нибудь JObject. В обоих случаях имя сервера оказывается «оторвано» от остальной информации о сервере.
                0
                «Тело» — надо понимать как содержимое? — аналогом в данном случае будет сам тэг, его имя.
                +1
                В смысле «более менее», jaxb уже сколько лет? и json-b уже подоспело, ух заживём!
            • НЛО прилетело и опубликовало эту надпись здесь
                0
                Все зависит от предприятия. Там где закупили у интеграторов Websphere и Weblogic на астрономические суммы и вложились в SOA, конечно YAML и JSON редкость.

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое