Я пытаюсь оценить репозитории контента (JSR283), например Jackrabbit и ModeShape, но я должен признаться, что я не понимаю, какая проблема решается на первом месте и даже если она хороший выбор для проекта. Какие примеры, по вашему мнению, являются наилучшим решением? Разве это не то же самое, что реляционные базы данных, кроме размера? Зачем? Дополнительные пункты для указания примеров реального мира.
Спасибо заранее.
Репозитории JCR отличаются от RDBMS, потому что репозиторий JCR:
Вы, безусловно, можете создавать все или некоторые из этих функций в своем приложении, но это, вероятно, будет дальше, чем ваша основная цель вашего приложения.
Какие приложения могут воспользоваться этими функциями? Системы управления контентом давно используют репозитории, и JCR (и Jackrabbit) действительно выросли из-за необходимости использования обычного стандартного API для доступа к различным хранилищам контента (см. JSR-170 и JSR-283).
Другим примером являются системы управления документами, которые управляют электронными файлами (которые часто являются изображениями бумажных документов) и обеспечивают поиск и запрос. В течение некоторого времени DMS использовали репозитории.
Системы управления артефактами могут использовать репозитории для управления цифровыми артефактами (часто файлы) вместе с дополнительной информацией (метаданные). JCR отлично работает здесь, потому что вы можете хранить метаданные в том же месте, что и файлы: те, которые понимают эти дополнительные свойства, могут их видеть, те, которые не заботятся, не должны их видеть. Я знаю Artifactory - это реализация репозитория Maven, использующая JCR. Существуют также хранилища для управления артефактами веб-сервисов, артефактами службы данных и тестовыми артефактами.
Но репозитории JCR не предназначены для управления файлами. JCR использует простое представление об иерархии узлов, где узлы могут содержать именованные свойства (с одним или несколькими значениями) и дочерние элементы. Допустимые свойства и дочерние элементы node полностью продиктованы типами node, которые могут быть изменены и смешаны по мере необходимости на основе node -by- node. JCR предопределяет некоторые встроенные типы node, которые обычно необходимы, например, те, которые используются для представления файлов и папок в репозитории. Вы можете повторно использовать эти встроенные типы, расширять их или писать самостоятельно. Многие люди выступают за использование миксинов почти как грани или аспекты, так что если node нужно взять грань, вы можете просто добавить mixin к node.
JCR был разработан, чтобы легко поддерживать импорт XML-содержимого в репозиторий, где каждый элемент сопоставляется с node, и каждый атрибут сопоставляется с атрибутом. И много материала представлено с помощью XML (или YAML или JSON), и все это легко может быть представлено и сохранено в репозитории JCR. В качестве примера рассмотрим репозиторий JCR, в котором хранится информация о конфигурации (которая обычно может храниться в нескольких файлах XML). JCR может изменять эту информацию, разрешать доступ к ней из нескольких процессов, включать запросы и поиск и уведомлять приложения (приложения), когда изменяется содержимое.
Существует несколько хороших обзоров JCR с подробностями и примерами. Вот некоторые из них: