Телефон: 8-800-350-22-65
WhatsApp: 8-800-350-22-65
Telegram: sibac
Прием заявок круглосуточно
График работы офиса: с 9.00 до 18.00 Нск (5.00 - 14.00 Мск)

Статья опубликована в рамках: XCI Международной научно-практической конференции «Научное сообщество студентов: МЕЖДИСЦИПЛИНАРНЫЕ ИССЛЕДОВАНИЯ» (Россия, г. Новосибирск, 20 апреля 2020 г.)

Наука: Информационные технологии

Скачать книгу(-и): Сборник статей конференции

Библиографическое описание:
Мякишев Д.С. РАЗРАБОТКА ГРУППЫ КОМПОНЕНТОВ НА БАЗЕ ПЛАТФОРМЫ AEM ДЛЯ ВАЛИДАЦИИ ЗАПРОСОВ В ФОРМАТЕ JSON // Научное сообщество студентов: МЕЖДИСЦИПЛИНАРНЫЕ ИССЛЕДОВАНИЯ: сб. ст. по мат. XCI междунар. студ. науч.-практ. конф. № 8(91). URL: https://sibac.info/archive/meghdis/8(91).pdf (дата обращения: 28.11.2024)
Проголосовать за статью
Конференция завершена
Эта статья набрала 0 голосов
Дипломы участников
У данной статьи нет
дипломов

РАЗРАБОТКА ГРУППЫ КОМПОНЕНТОВ НА БАЗЕ ПЛАТФОРМЫ AEM ДЛЯ ВАЛИДАЦИИ ЗАПРОСОВ В ФОРМАТЕ JSON

Мякишев Дмитрий Сергеевич

студент, кафедра информационных систем, Санкт-Петербургский национальный исследовательский университет информационных технологий механики и оптики,

РФ, г. Санкт-Петербург

Термины и определения:

В настоящей работе были применены следующие термины с соответствующими определениями:

AEM – CMS построенная на OSGi фреймворке, основанная на открытых стандартах, таких как Content Repository for Java API (JCR) и REST. [1]

Content management system (CMS) – информационная система, используемая для обеспечения и организации совместного процесса создания, редактирования и управления содержимым, иначе — контентом.

OSGi – динамичная модульная система, оперирующая небольшими, переиспользуемыми единицами, называемыми бандлами, которые могут быть развернуты внутри OSGi контейнера. [2]

Бандл – модуль OSGi платформы, который представляет из себя архив в формате JAR, содержащий скомпилированный на языке Java код, скрипты, контент для репозитория или конфигурационную информацию. Отличительной особенностью Бандлов является метаинформация, описанная в манифесте данного архива, который идентифицирует модуль и его версию, а также сообщающает платформе OSGi о внутренней организации модуля и зависимостях модуля от других компонентов приложения в соответствии с OSGi спецификацией. Также Бандл может предоставлять информацию о предоставляемых и используемых OSGi сервисов. [2]

JavaScript Object Notation (JSON) – открытый стандарт, определяющий формат файлов и формат обмена данных в виде легко читаемым человеком тексте, состоящий из пар атрибутов-значений или массива. [3]

JSON Schema – файл в формате JSON, который определяет ограничения (правила) для пар атрибутов-значений и массивов с помощью наборов ключевых атрибутов, определяемыми одной из версий JSON meta-schema Validation vocabulary, в соответствии с интерпретируемой схемы валидации. [4]

Валидация данных – процедура принятия решения, которая заканчивается принятием или отказом данных, как приемлемых. Процедура принятия решения, в основном, основывается на правилах, выражающих приемлемые комбинации значений. Правила применяются к данным. Если данные удовлетворяют правилам, это означает, что комбинация, выраженная правилами, не нарушена, и данные считаются действительными для конечного использования. [5]

На текущий момент единственным способом валидации данных в формате JSON в специфицированной манере является использование открытого стандарта JSON Schema. Именно файл в формате JSON будет задавать необходимый набор правил для реализации процедуры валидации данных.

В настоящее время не существует готового решения для валидации данных с использованием стандарта JSON Schema на платформе OSGi, поэтому необходимо предложить свой собственный способ по интеграции существующих решений на языке JAVA.

К сожалению, JSON Schema не специфицирует универсальный интерфейс, который должны имплементировать все существующие программные решения на языке JAVA. Следовательно, необходимо проанализировать существующие решения и составить наиболее универсальный интерфейс.

Существуют следующие библиотеки:

  • Everit Json Schema 1.11.1
  • Json schema validator 2.2.10
  • MedeiaJackson 1.1.0
  • MedeiaGson 1.1.0
  • Justify 0.13.0

Проанализировав данные решения становится понятно, что все существующие решения имеют общую идею с открытым стандартом 374. Данный стандарт описывает 2 способа обработки данных в формате , а именно:

  • The Streaming API
  • The Object Model API

Таким образом можно составить ключевой набор классов, основанных на валидации на уровне потоковых данных и на уровне объектных данных.

Данный набор классов представлен на рисунке 1.

 

Рисунок 1. Диаграмма классов для интеграции JSON Schema

На диаграмме используется следующие методы:

  • validate(jsonSchemaSource : JsonSchemaSource, dataToValidate InputDataSource)
  • validateAndSerialize(jsonSchemaSource : JsonSchemaSource, dataToValidate : InputDataSource, clazz : Class<T>) : T
  • validateAsStream(jsonSchemaSource :  JsonSchemaSource, dataToValidate : InputDataSource) : OutputStream

Таким образом возникает возможность одновременной сериализации данных и валидации.

Обратите внимание, что здесь используются следующие производные классы JsonSchemaSource, InputDataSource, JsonSchema. Использование данных классов является попыткой введения универсальных типов для описания источников получения схем валидации, их хранения и универсального источника данных для валидации.

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

Схемы валидации представлены в виде класса JsonSchema. Данный класс и является необходимым объектом, обладающим информации для определения набора правил для последующей валидации данных.

Источником данных является для валидации является класс InputDataSource. Существующие валидаторы обладают необходимой функциональностью для получения данных.

Тем не менее, любой существующий валидатор обязан предоставить реализацию для класса JsonSchemaValidator. В случае отсутствия необходимой функциональности для получения данных (например, неизвестный источник данных для валидатора) разработчик может обеспечить собственную реализации для конвертации таких данных в распознаваемые валидатором. Таким образом, реализация JsonSchemaValidator с использованием существующих интерфейсов является задачей написания адаптора.

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

Вывод

Таким образом был предложен способ для интеграции существующих решений для валидации данных в формате JSON в соответствии с спецификацией JSON Schema для OSGi платформы.

 

Cписок литературы:

  1. Adobe Experience Manager platform [Электронный ресурс]. URL: https://www.adobe.com/ru/experience-cloud/articles/adobe-experience-manager-platform.html (дата обращения: 31.12.2019).
  2. OSGi Alliance Specifications [Электронный ресурс]. URL: http://www.osgi.org/Specifications (дата обращения: 31.12.2019).
  3. The JSON Data Interchange Format [Электронный ресурс]. URL: https://www.ecma-international.org/publications/files/ECMA-ST-ARCH/ECMA-404%201st%20edition%20October%202013.pdf (дата обращения: 31.12.2019).
  4. JSON Schema: core definitions and terminology [Электронный ресурс]. URL: http://json-schema.org/draft-04/json-schema-core.html (дата обращения: 31.12.2019).
  5. Methodology for data validation 1.0 [Электронный ресурс]. URL: https://ec.europa.eu/eurostat/cros/system/files/methodology_for_data_validation_v1.0_rev-2016-06_final.pdf (дата обращения: 31.12.2019).
Проголосовать за статью
Конференция завершена
Эта статья набрала 0 голосов
Дипломы участников
У данной статьи нет
дипломов

Оставить комментарий

Форма обратной связи о взаимодействии с сайтом
CAPTCHA
Этот вопрос задается для того, чтобы выяснить, являетесь ли Вы человеком или представляете из себя автоматическую спам-рассылку.