CMIS научился различать политики хранения и права доступа к документам

Год назад, 10 сентября, была анонсирована спецификация Content Management Interoperability Services (CMIS) - стандарта, призванного сделать хранилища контента прозрачными для приложений, чтобы типичные операции, такие как размещение и извлечение контента, навигация и поиск по хранилищу могли выполняться стандартными сервисами, независимо от того, к какому именно хранилищу идет обращение. Тогда же, наравне с флагами и песнопением, высказывались сомнения, что удастся по-хорошему реализовать заявленную цель - значительно снизить тяжесть сопровождения мультивендорных, построенных на нескольких хранилищах, систем управления контентом (ECM). Попробуем оценить, что же изменилось с тех пор.

Изначально в модели данных CMIS предполагалось четыре базовых объекта:

• папки - в их обычном понимании, структура папок долнжа быть строго иерархической, без циклов;
• документы - тело документа + полный комплект метаданных, связанных с документом, включающий по необходимости реквизиты справочников, на которые он ссылается + версии;
• связи между объектами; 
• политики управления объектами.

При этом, все вопросы управления документами были вынесены в политики: предполагалось использовать их для таких задач, как управление доступом к объектам хранилища или определение порядка хранения документов.

Если с первыми тремя объектами в стандарте все более-менее понятно, то политики вызывали вопросы: CMIS о политиках знает только то, что их можно применять к объектам, а смысл политики полностью определяется хранилищем и непрозрачен для стандарта. Фактически, политики позволяют скрыть и протащить сквозь стандарт весь специфичный для данного хранилища функционал. Но подобный шаг сведет на нет сам смысл стандартизации - работать с такими политиками смогут, по сути, только заточенные именно под данное хранилище приложения.

Похоже, что близкие к озвученным соображения заставили разработчиков стандарта вывести из зоны риска хотя бы модель безопасности: теперь (в версии 0.63, над которой в данный момент ведется работа в OASIS) хранилище обязано декларировать, как оно относится к управлению доступом (скрывает, только публикует списки контроля доступа (ACL, Access Control List), публикует ACL и разрешает управлять доступом к объектам извне). Также в модель данных явно включены свойства для поддержки базовой модели безопасности (доступ на просмотр, изменение, полный доступ), которую допустимо по необходимости расширять.

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