Системы класса Enterprise Content Management (ECM), по-русски – Управление неструктурированной информацией (контентом) предприятия – это стратегическое решение, которое включает в себя полный набор продуктов для управления жизненным циклом неструктурированной информации, (контента) представленной в различных форматах и типах. Системы ECM автоматизируют следующие функциональные области:

• Document Management (DM), по-русски – Управление документами;
• Records Managemen (RM)t, по-русски – Управление записями (жизненным циклом);
• Collaboration Management (CLBM), по-русски – Коллективная работа или Управление взаимодействием;
• Web Content Management (WCM), по-русски – Управление веб-контентом;
• Digital Asset Management (DAM), по-русски – Управление цифровыми активами.

С другой стороны можно выделить список основных задач ECM систем:

Любая выборка из этого списка может являться бизнес требованиями к внедрению определенной системы ECM. С другой стороны объединение указанных требований в группы дает одну из описанных выше функциональных областей.

Universal Content Management (UCM), по-русски – Универсальное управление неструктурированной информацией (контентом) – это ECM система (со всеми функциональным областями), построенная на единой унифицированной платформе. Основная идея UCM – совместить в одном решении (продукте) все задачи и требованиями систем ECM. Получаем формулу: UCM = ECM on a Unified Platform.

Чтобы не было путаницы, подчеркну еще раз:

1. ECM – это понятие, концепция, характеристика систем определенного класса;
2. UCM – это продукт, решение, конкретная реализация системы ECM, сделанная компанией Oracle (после покупки компании Stellent).

Архитектура решения Oracle Universal Content Management представлен ниже на рисунке:

В основе решения лежит сервер контента (Content Server), отмеченный на рисунке красным прямоугольником. Во-первых, он предоставляет базовые атомарные сервисы управления неструктурированной информацией, такие как регистрация, классификация, поиск, контроль доступа и т.д. Во-вторых, для того, чтобы предоставлять такие сервисы, серверу необходимо иметь 3 репозитария:

• Реляционная база данных – в табличном виде хранится системная информация, а также хранятся атрибуты, версии, пользователи, группы, роли, процессы, правилы и т.д. Официально поддерживаются следующие СУБД: Oracle, MS SQL, DB2, Sybase, Informix, Postgres, неофициально поддерживается любая СУБД, поддерживающая стандарт ANSI SQL 92 и имеющая JDBC интерфейс и драйвера (например: MySQL). Для СУБД Oracle реализована самая глубокая поддержка c учетом особенностей самой базы данных и особенностей расширения языка SQL в Oracle (хинты, дополнительные функции и операторы, оптимизационные планы);
• Поисковый индекс – хранятся поисковые индексы (атрибутивный и полнотекстовый) с учетом прав доступа. Официально поддерживаются СУБД (Oracle, MS SQL, DB2) и внешние приложения (Autonomy/Verity, FAST InStream). Наиболее продвинутая реализация достигается с помощью СУБД Oracle, в частности высокая производительность, частиное обновление индекса при изменениях и вставках, подсветка найденных участков текста ;
• Хранилище информации – имеет двухуровневую систему хранения: «подвал» (vault) – хранилище всех оригинальных (непреобразованных) версий файлов и «веб-макет» (web layout) – хранилище веб представлений последних актуальных версий файлов плюс дополнительные системные ресурсы (css, javascript, images…), необходимые для работы системы. Хранилище «веб-макет» монтируется к веб серверу как виртуальная папка. Работы системы осуществляется через веб страницы (как статические, так и динамические), находящиеся в хранилище «веб-макет». Доступ к файлам, хранящимся к «подвале» осуществляется только через сервисы сервера контента. Достук к веб образам файлов, хранящихся в «веб-макете» осуществляется напрямую через веб-сервер и иерархию папок. За счет этого достигается высокая скорость отклика системы и повышается эффективность работы. Кроме того, часть данных, хранящихся в реляционной базе данных для оптимизации публикуется в хранилище «веб-макет». Например: статические атрибутивные справочники публикуются в «веб-макете» в качестве готового списка для того, чтобы веб-формы не делали лишние запросы в СУБД. В качестве реализаци хранилища «подвал» может выступать СУБД Oracle (BLOB,SecureFiles), MS SQL, файловые системы, специальные устройства хранения (NetApp, EMC, HP), хранилище «веб-макет» – файловые системы, специальные устройства хранения. Файловые системы могут быть как локальные, так и сетевые: NAS, SAN.

Сервер контента – это 100% «чистое» Java SE приложение, не требующее наличия сервера приложений. Наибольшая эффективность и скорость работы сервера достигается на виртуальной Java машине JRockit, поставляемой компанией Oracle.

Для доступа к системе необходимо иметь веб-сервер, который как я уже писал настраивается на хранилище «веб-макет». Поддерживаются следующие веб-сервера: MS IIS, Apache, Sun One, IBM HTTP Server.

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

• Стандартные – установлены по умолчанию, реализуют самые базовые функции в системе (например: дерево папок);
• Функциональные – устанавливаемые вручную компоненты, реализующие определенные задачи (например: автоматическая категоризация контента);
• Специфические – также устанавливаемые вручную компоненты, реализующие некие специфические функции в системе (например: облака тегов);
• Компоненты третьих фирм;
• Собственные разработки.

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

Каждый компонент в системе может состоять из следующих сущностей:

• Статические страницы;
• Динамические страницы;
• Ресурсные таблицы (специальный формат сервера контента – HDA);
• Сервисы;
• Запросы;
• Переменные;
• Шаблоны;
• Ресурсные файлы (стили, картинки и т.д.).

Языки программирования:

• Idoc script – внутренний скриптовый язык программирования, на котором написан практически весь функционал системы. Простой и легкий, чем-то похож на PHP, VB.
• JavaScript;
• Java;
• VBScript;
• C/C++

Для интеграция с внешними системами такими как LDAP-каталоги, сетевые устройства хранения, сервер конвертации файлов и т.д. и обмена информацией между ними в системе существует механизм провайдеров:

• Входящие (incoming) – когда документы поступают из внешней системы, например при конвертации на сервер документов обратно возвращается web-представление оригинального документа;
• Исходящие (outgoing) – документы отправляются во внешние системе, например при распределенной архитектуре происходит репликация (настройка репликации метаданных происходит либо через механизм Replication Manager – утилита администрирования сервера контента или через механизм репликации СУБД);
• Файловое хранение (file store) – специальный провайдер для хранения файлов, представляет собой абстракцию, интерфейс, который может иметь различные реализации, например Database File Store – реализация хранения файлов в СУБД, File System Store – реализация хранение в файловой системе и т.д;
• LDAP – для интеграции с LDAP каталогами.

С помощью механизма провайдеров можно строить распределенные системы с несколькими серверами контента.

На рисунку ниже представлена архитектура с указанием провайдеров:

Модель безопасности в системе построена на основе следующих сущностей:

Права доступа (разрешения) для группы контента бывают:

• Read – можно искать, смотреть и печатать;

• Write – + можно публиковать, изменять и получать копии;

• Delete – + можно удалять ревизии;

• Admin – + можно публиковать чужой контент.

Модель безопасности может быть:

• На основе группы контента и роли как набора прав доступа к указанной группе;
• На основе учетных записей, позволяет настраивать иерархическую модель полномочий;
• На основе списков доступа (ACL), когда доступ к единице контента определяется для конкрентого пользователя;
• На основе правил (компонент NeedToKnow – NTK), позволяет программным образом определять доступ пользователей к группами и единицам контента.

Для иллюстрации описанных способов ниже представлена картинка:

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

Метки: ECM, Oracle, UCM