Spiral group

_________________________________________________________________________________

 

< Раздел “Язык Java” > < Раздел “Технологии Java” > < Основная страница >

 

eXo platform v2. JCR.

 

 

Статья опубликована: 16.12.2006

Последнее изменение: 29.12.2006

Оригинал статьи, взятой за основу:

eXo platform v2, Portal, JCR, ECM, Groupware and Buisness Intelligence. Part 2

http://www.theserverside.com/tt/articles/article.tss?l=eXoPlatform2 

Январь 2006

 

 

 

Линейка продуктов eXo Platform в 2006 году

 

 

eXo JCR 1.1

 

Одна из первых сертифицированных JSR 170 реализаций репозитория контента The Java Content Repository (JCR) и одна из немногих полных реализаций, включая уровень 1,2 и все дополнительные возможности. Доступ к репозиторию можно осуществлять через различные клиентские API включая WebDAV / DeltaV, RMI, REST и FTP. eXo JCR  1.1 оптимизирована для работы с большими бинарными объектами (BLOB), включая видео и изображения.

 

eXo ECM 1.1

 

Enterprise Content Management (ECM) обеспечивает иерархическую организацию документов  хранимых в eXo JCR-JSR 170 (Java Content Repository)

Некоторые изменения и дополнения по сравнению с версией eXo ECM1.0:

— новую модель безопасности;

— поддержка фильтров при просмотре JCR воркспейса;

— цифровая подпись в стандарте DSIG;

— RSS сервис дополнен поддержкой Podcasts и Video Podcasts;

— каждый шаблон, вид или скрипт может теперь быть версионным;

— диалоговый шаблон дополнен Javascript редактором;

— в портлете просмотра контента обеспечена поддержка Groovy скрипта для публикации контента;

— улучшена эргономика инструментария администратора.

 

eXo Portlet Container

Портлет-контейнер (Portlet Container) является первой сертифицированной реализацией API спецификации портлетов (JSR 168). Данный модуль управляет жизненным циклом портлет-компонентов. Реализация снабжена возможностями кэширования и эффективнго мониторинга, обеспечивая тем самым отличную производительность. Портлет-контейнер также выпускается с веб-сервисом для удаленного портала Web Service for Remote Portal (WSRP).

 

eXo Portal

eXo портал (eXo Portal) основан на стандарте Java Server Faces (JSR-127). Он обеспечивает реальную архитектуру Model-View-Controller (MVC), позволяющую разработчикам работать с компонентами и событиями на уровне веб-слоя практически таким же способом, как со Swing компонентами. Портал взаимодействует с портлет-контейнером, получая содержимое портлета, и затем компонует Веб страницу.

 eXo Groupware

 

Комплект с форумом, сообщениями, общий календарь, вики, менеджер проекта и многое другое.

 

eXo Buisness Inteligence

 

The Business Intelligence продукт возможно наиболее неожиданный с нашей стороны, но также один из наиболее многообещающих. Он полагается на ObjectWeb проект SpagoBI и будет завершен, как глубоко интегрированный продукт с нашим ECM продуктом. BI внедрен с целю обеспечить ECM технологиями и инструментами, аналитическими отчетами и инструментальными панелям для людей принимающих решения. По умолчанию, анализируются данные eXo Portal, но существует возможность сделать тот же тип анализа  для многих различных типов информации, на которые ориентируются большая часть бизнес логики. Среди инструментов предлагаются статические или парамерические отчеты, инструментальные панели, проходка данных, многоразмерная навигация (OLAP).

 

 

 

eXo планирует вскоре представить новую операционную систему eXo Enterprise WebOS. В новом продукте все текущие возможности eXo Portal и eXo ECM будут присутствовать.

 

 

 

Java Content Repository (JCR)

 

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

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

Безусловно, JCR включает высокие уровни обслуживания, такие как управление версиями или блокировка, но его основное назначение сделать возможным операции чтения и записи упорядоченным способом. Таким как создание структурированного содержимого или даже структурированных содержимых. Эти особенности описаны в двух первых уровнях спецификации. Наша реализация поддерживает все функциональности уровня 1 и 2, а таже все опциональные особенности, включая поддержку JTA.

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

 

Уровень 1

 

Как показано на следующем рисунке (взятом  по ссылке на документацию реализации), уровень 1 сосредоточен на функциях чтения, которые включают XPath API для поиска, а также структурированное описание документов, благодаря определению типа узла (NodeType).

 

 

 

Доступ

 

Главная точка входа в реализации JCR это объект Repository. Согласно реализации может быть несколько способов поиска объекта, но наиболее общий путь в изолированном окружении это использовать JNDI сервер, такой как в следующем коде:

 

InitialContext jndiContext = new InitialContext();

Repository repository = (Repository)jndiContext.lookup("repository");

 

С помощью eXo JCR, также возможно воздействовать на ваш сервис контейнера и на сервис просмотра (или встроенный, если ваш компонент также расположен в сервисе контейнере), используя следующий Java код:

 

PortalContainer container = PortalContainer.getInstance();

RepositoryService repositoryService = (RepositoryService) container.

getComponentInstanceOfType(RepositoryService.class);

Repository repository = repositoryService.getRepository()

 

Использование данного приема является более гибким. Затем, пользователю необходимо пройти аутентификацию с помощью логина и пароля на сервере для того, чтобы получить объект Session. Существует два основных пути логирования, один из которых заключается в создании объекта Credential с помощью кода:

 

Credentials credentials = new SimpleCredentials("exo", "exo".toCharArray());

Session jcrSession = repository.login(credentials, "production");

 

Или если вы запускаете реализацию eXo, которая, например, встроена в портал, вы можете тогда непосредственно логироваться следующим образом:

 

Session jcrSession = repository.login("production");

 

Несомненно, в случаях встроенности, реализация будет непосредственно воздейстовать  на сервисы безопасности и организации, которые полагаются на LDAP или DB хранилище, также как модули логирования JAAS. Дополнительно к этому, на данный момент может быть использована единственная подпись (SSO), так как версия 2 платформы поддерживает ее внутренне.

 

Структура документа: концепции NodeType и MixinType

 

Концепция NodeType возможно настолько сложна для понимания насколько мощна и полезна. Идея состоит в том, чтобы определить тип, который будет описывать структуру узлов, которые имеют этот тип. Это такой же тип взаимосвязи, который существует между классом и его экземпляром (исключая только то, что тип узла (NodeType) не может содержать бизнес логику (методы)).

Вы можете, например, создать тип узла (NodeType) с названием “exo:article”, который должен определять, что узел (Node) данного типа должен содержать такие проперти, как метаданные или реальное содержимое и, что должен быть тип его дочерних узлов  (например, узел с типом “exo:image”). Каждый узел, который бы создавался и имел бы тип exo:article тогда должен будет следовать ограничениям, которые определены типом узла (NodeType). Для данного случая, узел может содержать одну проперть для хранения имени, одну для хранения подзаголовка, одну для хранения содержимого статьи и коллекция дочерних узлов, которые будут содержать изображения или прикрепления.

Когда создается узел, то он связывается с типом (NodeType). Если не используется никакой специфической строки для определения типа, тогда реализация будет пытаться  решить, какой тип ограничивает узел, согласно его имени и имени его родителя. И если реализация не может принять решение, с каким типом его связать, то по умолчанию используется тип “nt:unstructured”.

 

Node newNode = parentNode.addNode(nodeName);

 

Или

 

Node newNode = parentNode.addNode(nodeName, “exo:article”);

 

Существует также концепция типа MixinType, которая позволяет узлу (Node) уменьшить ограничения. Если пользоваться аналогией, то тип MixinType можно сравнить с эквивалентом интерфейса, в то время как NodeType можно сравнить с эквивалентом класса. Поэтому мы могли определить тип MixinType "exo:published", который должен заставить любой узел данного типа определить две новые проперти для публикации: дата начала публикации и дата ее конца.

 

newNode.addMixin("exo:published");

newNode.setProperty(“exo:startPublication”, startCalendar);

newNode.setProperty(“exo:endPublication”, endCalendar);

newNode.save();

 

Если происходит сохранение и к этому моменту две проперти не были заполнены, то произойдет выброс исключения.

Как можно увидеть, тип MixinType является только дополнением к основному типу узла.

Помните, что eXo ECM определяет узлы “exo:article ”  "exo:published" как тип MixinType .

 

Экспорт

 

Любое приложение, которое поддерживает уровень 1 JCR, должны также поддерживать функцию экспорта, которая может быть действительно полезна с целью переносимости, так как любая экспортируемая часть иерархии содержимого будет экспортироваться как XML документ. Затем этот XML документ может быть импортирован в любые реализации, совместимые с JCR уровня 2.

Обычный вариант использования импорта состоит в том, чтобы загрузить благодаря веб приложению (которое, конечно же, может быть и портлетом) XML содержимое в вершину определенного пути узла. Следующий код является примером eXo ECM портлета, который позволяет просматривать любой воркспейс. Для каждого узла, который просматривается, можно импортировать или экспортировать поддерево. Следующий код показывает, как просто импортируется какое-либо содержимое, которое мы загрузили.

 

byte[] content = uiupload.getContent() ;

try

{

 session.importXML(node.getPath(), new ByteArrayInputStream(content),

                   ImportUUIDBehavior.IMPORT_UUID_CREATE_NEW) ;

} catch (Exception e)

{

 JCRExceptionManager.process(iprovider, e);

}

 

Компонент UIUpload является JSF, одно из назначений которого состоит в том, чтобы интерпретировать загрузку HTML поля внутри мнгоэлементной формы, извлекать и помещать в оболочку загруженный результат так, чтобы мы могли просто получить его методом uiupload.getContent().

JCR API имеет интерфейс ImportUUIDBehavior, который определяет как реализация должна вести себя, когда XML дерево содержит узлы с UUID’ами, которые конфликтуют с UUID’ами узлов, которые уже содержатся в репозитории. Ниже приведены четыре проперти, которые предназначены для этой ситуации.

 

public interface ImportUUIDBehavior

{

 public static final int IMPORT_UUID_CREATE_NEW = 0;

 public static final int IMPORT_UUID_COLLISION_REMOVE_EXISTING = 1;

 public static final int IMPORT_UUID_COLLISION_REPLACE_EXISTING = 2;

 public static final int IMPORT_UUID_COLLISION_THROW = 3;

}

 

Поиск

 

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

Чтобы создать запрос сначала нужно получить QueryManager из объекта Workspace, такой как в следующем коде:

 

QueryManager queryManager = session.getWorkspace().getQueryManager();

 

Затем, в случае XPath поиска мы можем использовать следующее выражение: “/jcr:root/path/of/your/node//*” , которое будет искать все свойства (items) для пути  /path/of/your/node/. Затем, мы создаем объект Query, передавая предыдущую формулировку и тип запроса (в данном случае используется тип Query.XPATH) в качестве аргументов метода createQuery() объекта QueryManager.

 

Query query = queryManager.createQuery(statement, Query.XPATH);

 

Объект Query может быть временно сохранен в самом JCR, если реализация поддерживает его. Например, eXo JCR имеет такую возможность, которая часто бывает полезна. На приведенном скриншоте ECM инструментария показано, что администратор может определить множество сложных предопределенных запросов, которые доступны для обычного пользователя, и он может их непосредственно использовать.

 

 

 

Следующий фрагмент кода сохраняет запрос Query по указанному пути.

 

query.storeAsNode(absPath);

 

Более того, JCR API определяет тип Query, который может быть визуализирован в ECM браузере.

 

 

 

Как только мы создали запрос (объект Query), то мы можем сразу запустить его, чтобы получить объект QueryResult и вызвать метод getNodes() и получить NodeIterator, как отображено в следующем фрагменте кода:

 

QueryResult queryResult = query.execute();

NodeIterator iterator = queryResul t.getNodes();

 

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

 

 

 

Уровень 2

 

Уровень 2 преимущественно описывает операции записи, тогда как уровень 1 описывал операции чтения, которые могут быть рассмотрены как функции экспорта.

 

 

Он также предоставляет понятия контроля доступа с 4 разрешениями (добавление узла, удаление узла, чтение узла, установку значения проперти) и некоторые методы безопасности.

На следующем рисунке показан экран безопасности в JCR браузер портлете, где вы можете просмотреть все разрешения, которые применяются к узлу. В этом особом случае мы имеем всех членов группы “/admin” (*:/admin), которые могут просматривать, добавлять дочерние узлы, устанавливать проперти или удалять пункт (item). Пользователь “exo” имеет те же разрешения.

 

 

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

 

 

В eXo JCR, безопасность относится к сервису SecurityService и сервису OrganizationService (членство в группах) и его различные реализации (DB или LDAP) (основанном на JAAS и SSO). Поэтому, можно связать узел с пользователем или группой пользователей, которая имеет такое же членство в группе. Подобное связывание, которое осуществляется путем добавления типа MixinType к узлу exo:accessControllable, будет определять политику безопасности для всех дочерних узлов.

Мы также имеем расширенную поддержку API с некоторыми дополнительными интерфейсами, такими как:

 

public interface ExtendedNode extends Node

{

  void setPermissions(Map permissions)

                      throws RepositoryException, AccessControlException;

  AccessControlList getACL();

  void clearACL() throws RepositoryException, AccessControlException;

  void removePermission(String identity)

                        throws RepositoryException, AccessControlException;

  void setPermission(String identity, String[] permission)

                     throws RepositoryException, AccessControlException;

  void checkPermission(String actions)

                       throws AccessControlException, RepositoryException;

}

 

где AccessControlList является классом, который содержит информацию о владельце узла и карту (Map) разрешений, которые применяются к этому узлу из четырех описанных выше разрешений.

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

 

Уровень 3

 

То что мы называем уровнем 3, по сути являются теми функциями, которые не обязательны для уровня 1 или 2. Эти функции включают некоторые важные свойства, такие как блокирование и версионность, а также обычную модель наблюдения (Observation).

 

 

Модель наблюдения (Observation)

 

Модель наблюдения является важной, особенно для ECM контекста, где содержимое необходимо не только сохранять, но также и управлять им, перемещать, трансформировать.

Модель наблюдения позволит вам регистрировать объекты слушатели (listener objects), которые, например, могут быть запущены, когда добавляются узлы определенных типов в специальную позицию. В интерфейсе Event определено 5 типов событий, которые могут возбуждаться механизмом наблюдения: NODE_ADDED, NODE_REMOVED, PROPERTY_ADDED, PROPERTY_REMOVED, PROPERTY_CHANGED. Манипуляция производится с помощью ObservationListener объекта, как показано в следующем фрагменте кода:

 

ObservationManager obsManager = workspace.getObservationManager();

if (ActionServiceContainer.ADD_PHASE.equals(type))

{

 obsManager.addEventListener(listener, Event.NODE_ADDED, srcPath, true, null, null, true);

}

else

{

 obsManager.addEventListener(listener, Event.NODE_REMOVED, srcPath, true, null, null, true);

}

 

Последние четыре аргумента метода:

 

— Boolean isDeep указывает должны ли мы прослушивать узел, который добавлен или перемещен во всем поддереве.

— String[] uuid указывает, что событие будет запущено, если родительский узел данного узла, который мы добавляем или перемещаем имеет id в массиве.

— String[] nodetypes указывает, что событие будет запущено, если родительский узел данного узла, который мы добавляем или перемещаем,  имя типа узла расположено в массиве.

— boolean noLocal указывает, что  модификации, сделанные в течение текущей сессии не будут запускать событие.

 

Версионность

 

Версионная часть спецификации достаточно сложна и опирается на несколько концепций JCR API, также как MixinType или UUID. Его цель заключается в управлении графом версий, чтобы была возможность восстановить прежние версии, создание веток и их слияние. В обычном состоянии узел не версионирован, что можно увидеть на следующем скриншоте.

 

 

Однако его достаточно просто сделать версионным. Для этого необходимо добавить тип MixinType.

 

node.addMixin("mix:versionable");

 

Когда узел делается версионным впервые, то ему автоматически присваивается статус “check out” (выданный).

 

 

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

 

 

Любые модификации этого узла с изменениями могут быть сохранены, а затем зафиксированы. После фиксации узел примет статус “check in”. В этом случае создастся другая версия объекта.

На следующем скриншоте мы видим (зеленая стрелка) что документ price.doc (сохранен как узел nt:file) основная версия 2 и что ее статус принимает значение “check out”.

 

 

Запись и выдача узла являются также очень простыми задачами.

 

Version version = node.checkin();

 

и

 

node.checkout();

 

Если сам узел не версионный, а для него существует предок и если предок имеет статус “check in”, то никакие изменения по записи не будут позволяться для дочернего узла. Чтобы сделать возможным изменения по записи, необходимо сначала сделать “check out” предка (выдать узел предка).

Следующий скриншот отражает версионное дерево узла в eXo ECM JCR браузер портлете. Присваивание версионного номера работает в нашей реализации подобно присваиванию версионного номера SVN. Существует возможность восстановить, просмотреть или даже сравнить различия версий узла, который имеет тип nt:file (даже если он бинарный, его мим тип (MimeType) поддерживается сервисом DocumentService).

 

 

Вся информация о версии является доступной через объект VersionHistory, связанный с версионным узлом. Получить объект можно следующим образом:

 

VersionHistory vh = node.getVersionHistory();

 

Затем вы можете просмотреть любую версию с помощью таких методов как getRootVersion() или getBaseVersion().

 

Каждый версионный узел заносится в VersionHistory по пути /jcr:system/jcr:versionStorage. Каждый объект VersionHistory содержит все версии узла (точнее говоря множества соответствующих узлов) и каждый объект Version имеет указатель на своего предшественника или последователя и содержит состояние фиксации узла. Таким путем он строит граф версий, как видно на следующей картинке взятой из спецификации.

 

 

Блокирование

 

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

Что касается методов для версионности, узел можно сделать блокированным через назначенный тип MixinType.

 

if(!node.isNodeType("mix:lockable"))

{

 node.addMixin("mix:lockable");

 node.save();

}

node.lock(true, true);

 

где lock имеет следующую сигнатуру метода

 

lock(boolean isDeep, boolean isSessionScoped);

 

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

 

Дополнительные функции

 

Конфигурация контейнера и воркспейса

 

eXo JCR основана на той же архитектуре инверсии контроля (IoC) контейнера как и остальная часть платформы. Два контейнера верхнего уровня (которыми могут быт PortalContainer или изолированный StandaloneContainer) и внутренние (RepositoryContainer и WorkspaceContainer) являются подтипами ExoContainer.

Реализация eXo может быть сконфигурирована для использования несколькими репозиториями, и каждый репозиторий, согласно спецификации, может иметь несколько воркспейсов.

 

 

Ниже вы можете увидеть фрагмент конфигурации JCR сервиса отражающей свою архитектуру:

 

<repository-service default-repository="repository">

  <repositories>

    <repository name="repository" system-workspace="production" default-workspace="production">

      <security-domain>exo-domain</security-domain>

      <authentication-policy>org.exoplatform.services.jcr.impl.core.access.PortalAuthenticationPolicy</authentication-policy>

      <workspaces>

        <workspace name="production" auto-init-root-nodetype="nt:unstructured">

          <container class="org.exoplatform.services.jcr.impl.storage.jdbc.JDBCWorkspaceDataContainer">

            <properties>

              <property name="sourceName" value="jdbcjcr"/>

              <property name="multi-db" value="false"/>

            </properties>

            <value-storages>

              <value-storage class="org.exoplatform.services.jcr.impl.storage.value.fs.SimpleFileValueStorage">

                <properties>

                  <property name="path" value="../temp/values"/>

                </properties>

                <filters>

                  <filter property-type="Binary"/>

                </filters>

              </value-storage>

            </value-storages>

          </container>

          <cache enabled="true">

            <properties>

              <property name="maxSize" value="10000"/>

              <property name="liveTime" value="1800"/><!-- 30 min -->

            </properties>

          </cache>

          <query-handler class="org.exoplatform.services.jcr.impl.core.query.lucene.SearchIndex">

            <properties>

              <property name="indexDir" value="../temp/index"/>

            </properties>

          </query-handler>

        </workspace>

........

Как видно из примера, конфигурация репозиторий-сервиса является простой и самопоясняющей.

eXo JCR может быть сконфигурирован таким образом, чтобы использовать один или несколько репозиториев, которые могут быть вызваны методом getRepository(String repositoryName) или просто getRepository(), используя один из  механизмов: контейнер или JNDI, как описано выше.

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

Компоненты, которые необходимо конфигурировать находятся в файле exo-jcr-config.xml. В вышеприведенном примере XML видно, что существует репозиторий, названный “repository” с системным воркспейсом названный “production” который инициализируется во время загрузки с коневым узлом типа nt:unstructured. Этот воркспейс использует в качестве хранилища реляционную базу данных, основанную на типе хранилища:

 

org.exoplatform.services.jcr.impl.storage.rdb.container.SingleRDBWorkspaceContainerImpl

 

Существует также конфигурация для воркспейса Cache  Query Handler.

 

Регистрация типов узлов

 

(Java Specification Request) JSR-170 не определяет механизма для регистрации типа узла, поэтому мы добавили регистрационные механизмы, раскрытые в интерфейсе ExtendedNodeTypeManager. который расширяет стандарт NodeTypeManager.

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

Определение типа узла XML это просто перевод специальных определений в XML. Например, nt:unstructured тип узла может быть определен как:

<nodeType name="nt:unstructured" isMixin="false" hasOrderableChildNodes="true" primaryItemName="">

        <supertypes>

            <supertype>nt:base</supertype>

        </supertypes>

        <propertyDefinitions>

              <propertyDefinition name="*" requiredType="undefined" autoCreated="false" 

                               mandatory="false" onParentVersion="COPY" 

                                 protected="false" multiple="true"/>

          <propertyDefinition name="*" requiredType="undefined" autoCreated="false" 

                                 mandatory="false" onParentVersion="COPY" 

                                 protected="false" multiple="false"/>

        </propertyDefinitions>

        <childNodeDefinitions>

          <childNodeDefinition name="*" defaultPrimaryType="nt:unstructured" 

                                  autoCreated="false" mandatory="false" onParentVersion="VERSION" 

                                  protected="false" sameNameSiblings="true">

              <requiredPrimaryTypes>

                    <requiredPrimaryType>nt:base</requiredPrimaryType>

              </requiredPrimaryTypes>

          </childNodeDefinition>

        </childNodeDefinitions>

    </nodeType>

 

Контейнер данных для воркспейса

 

(Java Content Repository) JCR API предлагает внешнюю часть для доступа к данным, скрывая механизм сохранения данных. Это может быть, к примеру, локальная или удаленная файловая система, реляционная база данных, база данных на основе XML и т.п.

Наша имплементация предлагает простой внутренний API для встраивания любого типа хранилища. Основные компоненты для встраивания являются WorkspaceDataContainer – абстрактная оболочка для источника данных, компоненты для сохранения данных NodeData и PropertyData.

Реализуя эти интерфейсы, eXo JCR может быть расширен другим типом хранилища данных. Все что вам необходимо – это указать воркспейс, чтобы использовать специфический контейнер данных, установить тип контейнера и некоторые специфические параметры контейнера, если необходимо, как в следующем примере:

<container class="org.exoplatform.services.jcr.impl.storage.rdb.container.SingleRDBWorkspaceContainerImpl">

        <properties>

            <property name="sourceName" value="default"/>

        </properties>

    </container>

Поддержка WebDAV

 

Протокол WebDAV позволяет вам использовать инструменты, чтобы соединяться с иерархическим содержимым серверов с помощью HTTP протокола. При этом можно добавлять или удалять документы по указанному пути на сервере.

Протокол DeltaV является расширением WebDAV, который позволяет также управлять версионностью документа, и который мы будем поддерживать в будущем.

В eXo JCR мы встраиваем WebDAV слой – основанный на коде, взятом из расширенных модулей относительно реализации. Воркспейс можно просмотреть, используя инструменты (это могут быть Windows папки или папки Mac, а также Java WebDAV клиент – DAVExplorer, который используется в следующих скриншотах).

Один из вариантов использования WebDAV состоит в том, что вы становитесь подобно писателю статей, который использует  Microsoft Word для создания и публикации своих документов. Благодаря WebDAV, для этих документов можно сделать загрузку в JCR. В то же время, некоторые операции, такие как проверка заполненных полей, могут быть запущены до какой-то публикации.

Когда производится доступ к WebDAV серверу, с помощью URL, пользователю будет предложено ввести свой логин и пароль. Они затем будут проверены, используя сервис Organization (который может быть реализован с помощью DB модуля или с помощью LDAP модуля) и пользователь JCR сессии будет создан с соответствующими разрешениями доступа JCR.

 

 

 

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

Следующий скриншот показывает путь /cms/home/users/ в черновом варианте воркспейса, который предварительно создан и сконфигурирован. Он используется в ECM продукте для того, чтобы динамически создавать JCR домашний каталог для всех новых пользователей.

 

 

 

 

Авторы:     Геннадий Азаренков (Gennady Azarenkov)     Бенджамин Местраллет (Benjamin Mestrallet)     Загребин Виктор Александрович

 

< Раздел “Язык Java” > < Раздел “Технологии Java” > < Основная страница >