В представленной работе рассматриваются основные технологии контент-менеджмент системы Adobe Experience Manager: их возможности и схема взаимодействия. Данные основываются на открытых источниках документации технологий Apache Foundation, а так же официальной документации Adobe Experience Manager.
Ключевые слова: контент-менеджмент система, apache foundation, репозиторий контента, модульное приложение, иерархическое хранилище данных
Введение
Adobe Experience Manager — это веб-ориентированная клиент-серверная система для построения, администрирования и развёртывания коммерческих веб-сайтов и связанных с ними сервисов. Она собирает в себе функционал уровня системы и уровня приложения в один цельный пакет.
К системному функционалу относятся:
– Сервер веб-приложений;
– Фреймворк веб-приложения;
– Репозиторий контента.
1. Компоненты AdobeExperienceManager
1.1 Сервер веб-приложений
AEM может быть развёрнут независимо (система включает в себя встроенный сервер Jetty), либо как веб-приложение в совокупности со сторонними серверами приложений (таких как WebLogic, WebSphere и так далее).
1.2 Фреймворк веб-приложения
Серверные модули, так называемые бандлы, содержат в себе бизнес-логику приложения. Взаимодействие между ними обеспечивает Apache Felix — реализация спецификации модульных приложений OSGi. AEM включает в себя так называемый Sling Web Application фреймворк, который упрощает написание контент-ориентированных RESTful веб-приложений.
1.3 Репозиторий контента
AEM включает в себя JCR — спецификацию типов иерархических баз данных, спроектированную специально для неструктурированных и частично-структурированных данных. Репозиторий хранит не только данные, отображаемые пользователю, но и код приложения, шаблоны и внутренние данные, используемые приложением. Главный принцип JCR, позволяющий понять суть этой технологии — everything is content (англ. — всё есть контент).
Построенный на базе этих технологий, AEM предлагает следующие возможности управления уровня приложения над:
– веб-сайтами;
– мобильными приложениями;
– цифровыми публикациями;
– цифровым контентом;
– социальными сообществами;
– электронной коммерцией.
Остановимся подробнее на возможностях JCR.
К преимуществам JCR от файловой системы можно отнести:
– иерархичность: к содержимому JCR репозитория можно получить доступ через путь. Это удобно для понимания, так как большинство веб-сайтов так же организованы иерархично.
– частично-структурированные данные: JCR может хранить структурированные документы, такие как XML, как файл, либо как подструктуру внутри дерева репозитория.
– контроль доступа и блокировка: JCR имеет возможность ограничивать доступ к различным частям содержимого репозитория определенным группам пользователей, основываясь на правилах и ACL, также поддерживает блокировку контента на изменение во избежание конфликтов.
Преимущества от баз данных включают в себя:
– использование запросов: JCR поддерживает выполнение запросов с использованием SQL-подобных языков;
– структурированные данные: JCR может может обеспечить соблюдение ограничений по отношению к структурам данных в соответствии со схемой;
– ссылочная целостность: может обеспечить целостность данных между элементами контента;
– транзакционность: взаимодействие с JCR может быть заключено в транзакцию и, при необходимости, произведён «откат» изменений.
В дополнение JCR предоставляет следующие сервисы, традиционно необходимые контент-ориентированным приложениям, которые ни файловые системы, ни базы данных, как правило не предоставляют:
– неструктурированные данные: JCR может поддерживать произвольные динамические структуры данных без ограничений схемы;
– полнотекстовый поиск: JCR поддерживает полнотекстовый поиск по содержимому;
– порядок сортировки: объекты внутри иерархии могут находиться в определённом порядке, если это необходимо;
– наблюдение: API клиента может регистрировать так называемых слушателей событий, для произведения каких-либо действий в зависимости от характера событий;
– версионирование: JCR поддерживает дополнительную версионную систему для репозитория контента.
1.4 Модель репозитория JCR и диспатчеризация
Внутри репозитория JCR контент организуется в одну или несколько так называемых рабочих областей (от англ. workspace), каждая из которых поддерживает иерархическую структуру ячеек и их свойств.
Структура начинается с корня, и распространяется далее по типу директорий файловой системы: каждая ячейка может иметь ноль или более ячеек-потомков и так же ноль или более свойств. Свойства не содержат потомков, но имеют значения. Значениями свойств являются непосредственно те данные, которые предполагается хранить. Ими могут быть различные типы, такие как: строки, даты, числа, бинарные данные и так далее. Примерная структура хранения данных в репозитории представлена на рисунке 1. Рисунок изображает содержимое рабочей области W0 в репозитории R.
Рис. 1. Схематичный пример репозитория
Серверная часть AEM написана на языке программирования Java и может выполнять на большинстве современных операционных систем, поддерживающих эту платформу. Взаимодействие клиента выполнено с помощью веб-браузера.
В терминологии AEM, экземпляром называется копия AEM, выполняющаяся на сервере. Установка AEM обычно включает в себя как минимум два экземпляра, запущенных на разных машинах, так называемые «Author» и «Publish» (важно отделять роль пользователей «Автор» и тип экземпляра «Author» — хоть они и используются в контексте окружения администратора контента, тем не менее обозначают разные понятия).
Рассмотрим подробнее введённые понятия. Экземпляром AEM, используемым для создания, загрузки, редактирования контента и администрирования сайта называется author-instance (англ. автор-экземпляр). Тогда экземпляром AEM, используемым для отображения опубликованного контента называется publish-instance (англ. публичный-экземпляр). Для удобства и более чёткой ясности понятий далее используются английские наименования экземпляров author и publish для обозначения автор-экземпляра и публичного-экземпляра.
Author окружение предоставляет множество возможностей для пользователя, такие как:
– генерация нового контента, либо редактирование уже созданного на странице;
– использование заранее определенных шаблонов для создания страниц;
– создание, редактирование и администрирование контента и публикаций;
– разработка кампаний и связанных с ними ресурсов;
– разработка и администрирование сайт социальных сообществ;
– перемещение, копирование или удаление страниц, контента, и т. д.;
– публикация (или снятие с публикации) страниц, контента, и т. д.
Когда контент готов к публикации, в дело вступает publish окружение. Здесь созданные страницы становятся доступны для аудитории посетителей, в соответствии с видом и возможностями интерфейса, который был задуман. Обычно, publish окружение находится внутри так называемой нейтральной зоны (Интернет), но уже не в зоне защиты корпоративной сети. На опубликованном веб-сайте пользователи, например, могут оставлять комментарии, либо общаться на форуме.
В виду большого количества использованной терминологии, зачастую, перекликающейся между собой, необходимо уточнить используемые понятия:
– Публикация/Снятие с публикации — это главные термины действий, которые делают контент публично доступным для посетителей на publish окружении (либо, наоборот, прекращают доступ к нему);
– Активация/Деактивация — эти термины синхронизированы с предыдущими, за той лишь разницей, что их применяют к конкретным действиям в интерфейсе администратора;
– Репликация/Реплицировать — эти технические термины используются для определения перемещения контента (страниц, файлов, кода, комментариев пользователей) с одного окружения на другое, другими словами производя публикацию или обратную публикацию контента.
В терминах установленного программного обеспечения author и publish экземпляры идентичны — их различия заключаются лишь в конфигурации.
Стоит так же упомянуть важный компонент окружения — dispatcher (здесь и далее — диспатчер). Диспатчер представляет собой статический веб-сервер (например Apache httpd) в связке с модулем диспатчера AEM. Его задача заключается в кешировании веб страниц полученных от publish экземпляра для того, чтобы повысить производительность. Так же диспатчер позволяет защитить сервер AEM от атак.
На рисунке 2 схематично изображён процесс взаимодействия author-, publish- и dispatcher-окружений.
Рис. 2. Схема процесса взаимодействия окружений AEM
Отдельно стоит рассмотреть несколько важных средств разработки для Adobe Experience Manager, которые входят в его состав.
1.5 CRXDELite
CRXDE Lite — это программа, встроенная в AEM, позволяющая проводить стандартные задачи разработки прямо в браузере. С помощью неё можно создавать проекты, создавать и редактировать файлы (например,.jsp и.java), папки, шаблоны, компоненты, диалоги, ячейки, свойства ячеек, бандлы и многое другое. Так же присутствует возможность контроля версий.
CRXDE Lite рекомендован в случаях, когда нет прямого доступа к серверу репозитория, когда происходит разработка компонентов, расширяющих так называемые out-of-the-box (стандартных, «идущих из коробки») и Java бандлов, а так же когда нет необходимости в таких помощников стандартных средств интегрированной разработки как режим отладки, подсветка синтаксиса и автозавершение кода.
1.6 Apache Felix
Веб-консоль построена на Apache Felix Web Management Console. Apache Felix — имплементация OSGi R4 Service Platform, сообществом разработчиков, которая включает в себя OSGi фреймворк и стандартные сервисы.
В данной консоли можно наблюдать развёрнутые модули (бандлы), например, newsfeed-services, а так же активировать (Activate), останавливать (Stop) и переустанавливать (Reinstall) их.
OSGi предоставляет стандартизированный примитив, который позволяет строить приложения из небольших, многоразовых и совместно используемых компонентов. Эти компоненты могут быть собраны в одно приложение, которое далее будет развёрнуто на сервере. Это позволяет легко управлять бандлами независимо.
1.7 Apache Jackrabbit
Apache Jackrabbit — прямая реализация API контент репозитория Java. Архитектура Jackrabbit состоит из слоя контент приложения, API и слоя реализации контент репозитория. Остановимся подробнее на каждом из них.
Контент приложения взаимодействуют с реализацией контент репозитория посредством JSR-170 API. Java-приложения могут использовать контент-репозиторий JSR-170 как замену property-файлам, XML конфигурации, некоторому функционалу баз данных. Использование контент репозитория позволяет приложению иметь дело со сколь угодно большим иерархическим пространством данных в мастшабируемом формате, получая преимущества репозитория, такие как: версионирование, запросы, транзакции или пространства имён, что делает репозиторий идеальным хранилищем данных для многих приложений.
Заключение
Рассмотренные технологии представляют собой базу контент-менеджмент системы Adobe Experience Manager. За годы использования сообществом разработчиков, технологии зарекомендовали себя как максимально более подходящие для конкретной контент-менеджмент системы. Основанные на стандартах и выпускаемые Apache Foundation, описанные фреймворки гарантируют высокую производительность и надёжность.
Литература:
- Schildt, H. Java: The Complete Reference [Текст] / Oracle Press, 2014. — 1274 c.
- Будилов, В. А. Интернет-программирование на Java [Текст] / БХВ-Петербург, 2014. — 522 с.
- Машнин, Т. С. Web-сервисы Java [Текст] / БХВ-Петербург, 2012. — 560 с.
- Richardson, L. RESTful Web APIs [Текст] / O'Reilly Media, 2013. — 406 с.
- Lunka, R. D. Adobe Experience Manager: Classroom in a Book: A Guide to CQ5 for Marketing Professionals [Текст] / Adobe Press, 2013. — 368 с.
- Closser, S. Adobe Experience Manager Quick-Reference Guide: Web Content Management [Текст] / Adobe Press, 2013. — 240 с.
- Adobe Corporation. Adobe Experience Manager Documentation [Электронныйресурс].
- URL: https://docs.adobe.com (Дата обращения: 29.05.2016).
- Adobe Corporation. Adobe Blogs — Experience Delivers [Электронныйресурс]. URL: http://blogs.adobe.com/experiencedelivers (Дата обращения: 29.05.2016).
- The Apache Software Foundation. Apache Felix Documentation [Электронныйресурс]. URL: http://felix.apache.org/documentation.html (Датаобращения: 29.05.2016).
