Content Management Interoperability Services (CMIS) Version 1.1

cmis_logoНа фоне того, что количество различных материалов о СЭД и ECM, даже в русскоязычном сегменте сети превышает сотню в месяц, появление версии 1.1 протокола CMIS осталось практически незамеченным. Конечно, разве может сравниться новая версия протокола с очередным пресс-релизом об успешном внедрении или же журналистскими измышлениями о роли и месте. Тем не менее, рабочая группа OASIS CMIS проголосовала за принятие стандарта и 12 ноября опубликовала его CMIS 1.1 Committee Specification Возможно, некоторые эксперты по системам электронного документооборота поинтересуются тем, а что же такое CMIS и чем же интересна версия 1.1 этой спецификации.

На протяжении многих лет мы используем множество различных информационных системы для работы с документами. Такие системы умеют загружать файлы данных, отображать, а порой и редактировать эти файлы и даже позволяют пользователю скопировать файл на локальный диск рабочей станции или сохранить в мобильном устройстве. Единственное что не умеют делать эти системы, так это работать с общим хранилищем файлов. Т.е. каждая такая система всегда хранила файлы и связанные с ними метаданные немного по-своему. Для поставщиков решений это безусловное благо. Сохранив свои файлы в той или иной системе вы навсегда становитесь заложником разработчика этого ИТ решения. Но для пользователя рано или поздно такая ситуация становится огромной головной болью. Вроде бы файлы у вас все есть, вот они, лежат в информационной системе, но сделать с ними вы ничего не можете. Ну, разве что открывать по очереди и копировать на локальный диск или переносить в другую систему.

Изменить данную ситуацию был призван появившийся 1 мая 2010 года стандарт CMIS 1.0. Стандарт создавался очень долго, а после появления подвергся серьезной критике. Тем не менее, ведущие поставщики ECM решений реализовали поддержку этого стандарта в своих продуктах (чего нельзя сказать об отечественных поставщиках систем документооборота). Что же принесла версия 1.1 стандарта:

Во-первых, появилась еще одна «привязка». Работа с данными в CMIS 1.0 строилась поверх протоколов SOAP или AtomPub. В обоих случаях работать с репозиторием контента можно было только при помощи дополнительного клиентского ПО. Новая привязка Browser binding, появившаяся в версии 1.1, позволяет работать с документами непосредственно из веб-броузера. Это, пожалуй, самое интересное изменение. Большинство современных приложений (в частности мобильные приложения или облачные хранилища файлов типа Яндекс-Диск) предпочитали использовать более простой протокол WebDAV именно из-за сложности использования CMIS в веб-приложениях. Теперь это ограничение снято.

Менее заметные, но не менее важные изменения случились в модели данных CMIS. В версии 1.0 каждый документ имел один строго предопределенный тип. Тип документа задавал набор связанных с документом параметров. В версии 1.1 появилась возможность добавления к документу дополнительных типов(secondary type) и соответственно дополнительных свойств. Дополнительные типы могут меняться в ходе жизненного цикла документа. Другим интересным расширениям является появления объекта Item, предназначенного для хранения в репозиториии контента различных дополнительных объектов. Напомню, что в предыдущей версии репозиторий мог содержать только документы, папки, отношения между ними и списки контроля доступа. Теперь в репозитории могут храниться произвольные объекты, например комментарии пользователей, сценарии рабочих процессов и т.п. Ну и наконец, нельзя не отметить то, что в CMIS появились методы для программного определения новых типов объектов и задания их свойств.

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

Другие заметки по теме CMIS:

Content Management Interoperability Services (CMIS) Version 1.1: 8 комментариев

  1. А есть примеры CMIS в живых системах? Просто было бы интересно сравнить опыт. У меня от него осталось двоякое впечатление – идея очень красива, но с реализацией как-то негладко. В нашем случае (разработка на Alfresco) были два критичные момента, из-за которых в итоге отказались от CMIS в пользу “родных” API.

    1. Неполный мапинг сущностей – в CMIS отсутствует понятие аналогичное аспектам Alfresco. А отказываться от них совершенно не хочется – слишком уж удобно для сложных моделей. В CMIS 1.1 можно попробовать их реализовать через secondary types, но это надо еще исследовать.

    2. Дико неудобная работа из client-side браузерного кода на javascript. То есть в теории, конечно, все возможно, но при этом ни на один фреймворк он нормально не ложится.

    Хотя, конечно, направление развитие стандарта говорит о том, что им пробуют пользоваться. 🙂 Если дополнения совпадают с нашими проблемами – наверное, это не случайно. 🙂

    1. Про примеры использования CMIS – припасу вопрос для мегавендоров 🙂 Правда боюсь, что ответы не будут особо обнадеживающими. Я уже выслушал несколько разговоров о том, что мол не нужны вам эти API, испортите еще что-нибудь в хранилище 😉

  2. >>Сохранив свои файлы в той или иной системе вы навсегда становитесь заложником разработчика этого ИТ решения …Единственное что не умеют делать эти системы, так это работать с общим хранилищем файлов

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

    Такой подход позволяет:
    1) виртуально через web-интерфейс объединять различные файловые хранилища на разных дисках и даже территориально распределенных компьютерах, представляя их пользователю как одно виртуальное дерево папок,
    2) игнорировать сырые и неудобные в реализации “стандарты” (часто еще и конкурирующие между собой, что для стандартов недопустимо) и
    2) полностью интегрировать файловое хранилище системы в обычную структуру папок и файлов сервера, обеспечивая легкость резервного копирования и интеграции.

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

    1. Не знаю как насчет прозрачного web-интерфейс к файловой системе, но CMIS много ругали за игнорирование WebDAV. Check-In/check-out, работа с версиями, доступ к метаданным – это WebDAV. В принципе, для работы непосредственно с файлами этого было бы достаточно. В CMIS еще присутствует функционал SQL-like запросов по параметрам файлов контента, но это отдельная тема

  3. С технической точки зрения, тот же SOAP вполне годится для реализации доступа к документам из браузера. И даже с точки зрения соблюдения стандарта, осуществляется ли доступ к документу по протоколу SOAP из браузера или из standalone-приложения, — не имеет значения. Интро к разделу содержит фразу:

    “This binding is specifically designed to support applications running in a web browser but is not restricted to them”

    То есть, браузер в данном случае — не требование, а ссылка-пример на паттерны поведения и взаимодействия (браузерные приложения отличаются от десктопных и мобильных). Далее следует требование:

    “HTTP MUST be used as the protocol for service requests. HTTP GET MUST be used for reading content and HTTP POST MUST be used for creating, updating and deleting content.”

    И отсюда проистекают все следующие пункты (представление данных в JSON, доступ к сущностям по их URL, токен-аутентификация и прочее). Но раздел не обязывает разработчика идти в браузер, он всего лишь указывает, что если разработчик решился на создание браузерного решения, поддерживающего CMIS, то ему потребуется для full compliance соблюсти все требования стандарта.

    Так что, честно говоря, не знаю, самое ли это интересное изменение.

    Но, определённо, есть над чем подумать. Тот же Google Drive позволяет сторонним разработчикам seamlessly интегрироваться в себя, а пользователь просто создаёт те или иные документы и считает, что всё в порядке вещей. Навскидку, если среди всех Visio-подобных решений и аналогов CAD появится «создать документ, совместимый с вашей любимой ECM-системой», то это добавит ценность этой самой ECM-системе, при этом потребуется не очень много усилий разработчиков для обеспечения адекватной совместной работы двух указанных продуктов.

    В общем, как говорится, challenge accepted.

  4. Перечитал эту статью за 2 месяца на раз 10 )
    Максим, просьба ответить да или нет на такой вопрос:
    Правильно ли я понял, что если перед нами стоит задача создания, сохранения, обмена, открытия файлов по папкам, создания новых версий, то в таком случае нам WebDAV – хватит более чем?

    Переход на CMIS имеет смысл только в случае значительного усложнения системы, когда мы захотим хранить там бизнес процессы и как то получать к ним доступ?

    В таком случае смысл CMIS в рамках ACM на базе WP – теряется.
    Доступ к бизнес процессам мы можем легко получить через XML-RPC, а для доступа к файлам нам легко хватит WebDAV.

    Или я где то ошибся в понимании? 🙂

    1. Анатолий, я сейчас в отпуске. Вернусь напишу несколько мыслей относительно того, когда достаточно WebDAV, а когда нужен CMIS. Ну и нужен ли он вообще 🙂

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *