ПРОЕКТИРОВАНИЕ КОМПОНЕНТА НА БАЗЕ AEM АГРЕГАЦИИ ДАННЫХ

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

AEM – это content management и experience management система, которая обладает большой гибкостью в управлением тем, что мы видим на сайте. Среди прочего, это редактирование контента: возможность разбиения функциональности на модули и управления ими без привлечения программистов и написания кода, создание back-end логики благодаря технологии OSGi, масштабирование и персонализация контента. [1]

Модуль – обычный для среды Java Jar-архив. В описании Jar-архива модуля кроме стандартного описания архива должна присутствовать информация, идентифицирующая модуль и его версию, а также сообщающая платформе OSGi о внутренней организации модуля и зависимостях модуля от других компонентов приложения. Также в описании Jar-архива может содержаться информация о сервисах, которые модуль предоставляет другим модулям.

OSGi – компонентная платформа для Java, оперирующая модулями. [2]

Фреймворк – программная платформа, определяющая структуру программной системы; программное обеспечение, облегчающее разработку и объединение разных компонентов большого программного проекта. [3]

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

Таким образом, процесс проектирования требует большей детализации, так как ошибки на раннем этапе могут повлечь за собой большое количество проблем в дальнейшем.

В данной статье будет рассмотрен процесс проектирование компонента агрегации данных на базе AEM.

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

• Protocol (обязательное поле);
• Host (обязательное поле);
• Port (необязательное поле);
• Endpoint (необязательное поле);
• Timeout Value (необязательное поле).

Набор полей может варьироваться от реализации к реализации, но в данном случае нам этого достаточно. Такая конфигурация будет являться OSGi сервисом, так как она понадобится далее для взаимодействия с другими компонентами разрабатываемого решения.

Далее требуется сервис, инкапсулирующий в себе функциональность для подключения к стороннему REST API. Для этого понадобится использование описанной ранее конфигурации. Реализация такого сервиса может иметь дополнительные зависимости на библиотеки, поставляющие HTTP Client специфичные классы. Например, можно воспользоваться  org.apache.httpcomponents:httpclient библиотекой, которая входит в стандартную поставку AEM.

Теперь требуется выделить отдельный сервис непосредственно для сбора самих данных. Такая реализация будет агрегировать вышеупомянутый сервис, с помощью которого можно получить сами данные посредствам HTTP запроса к стороннему REST API.

Именно в этом сервисе должна быть добавлена логика по обработке полученных данных, чтобы не допустить размазывание такой логики по различным участкам кода.

Данный сервис должен оперировать конкретной строгой структурой. В случае если потребуется преобразование полученного JSON в определенную Java модель, то можно воспользоваться ещё одной сторонней библиотекой – com.google.code.gson:gson. Она также входит в стандартную поставку AEM.

Следующий необходимым элементом архитектуры является сервис, взаимодействующий с репозиторием. В данном случае внутри такой реализации потребуется использование ResourceResolverFactory или SlingRepository сервиса, так как и их помощью можно взаимодействовать с JCR репозиторием.

Последним компонентом разрабатываемого решения будет Cron Job. В рамах использования Sling фреймворка, являющегося частью архитектуры AEM, можно использовать встроенный механизм, позволяющий регистрировать определенный компонент системы, если тот реализует интерфейс Runnable, а также содержит нужную конфигурацию, содержащую необходимую для расписания информацию. В таком случае фреймворк берет на себя ответственность за запуск метода run данной имплементации по сконфигурированному расписанию.

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

Также плюсом настоящей реализации является то, что на уровне отображения данных мы не привязаны к какому-то определенному сервису. Данные хранятся в JCR. С ними можно работать без использования классов данного решения. В конце концов, данный набор компонентов может находиться в изолированном бандле.

Однако мы также можем и переиспользовать имеющийся код. Например, мы можем преобразовывать данные из репозитория в модель, которая также использовалась для сохранения данных.

Рисунок 1. Диаграмма классов проектируемого решения

Выводы

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

Используемые в архитектуре AEM фреймворке также помогают клиентскому приложению решать поставленные задачи. Уровень работы с репозиторием доступен из коробки. Это решает часть проблем, которые связанны с надежностью, оптимальностью и безопасностью. Использование OSGi на уровне архитектуры AEM играет важную роль при проектировании собственных приложений на базе данной платформы. Разбитая на модули платформа позволяет повторно использовать уже имеющиеся программные модули, развертывать новые или расширять существующие. Также это помогает избежать проблемы, которые связаны с излишним количеством классов в classpath, так как данный механизм предоставляет возможность скрывать пакеты и выставлять в наружу только необходимые для других модулей. Добавляется возможность импортировать пакеты разных версий. Хоть это и не является серебряной пулей, но предоставляет решение определенных конфликтных ситуаций.

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

1. Habrahabr [Электронный ресурс]. URL: https://habrahabr.ru/company/epam_systems/blog/277041 (дата обращения: 21.04.2018).
2. OSGi Alliance Specifications [Электронный ресурс]. URL: http://www.osgi.org/Specifications (дата обращения: 21.04.2018).
3. Wikipedia [Электронный ресурс]. URL: https://ru.wikipedia.org/wiki/Фреймворк (дата обращения: 21.04.2018).