Source: http://www.itblogs.ru/blogs/borkus/archive/2009/02/04/_18043D0442043504330440043004460438044F04_-_21042D0414042C00_-_3D043E0432044B043904_-_4104420430043D043404300440044204_-CMIS.aspx
Те, кто внедрял системы документооборота, знают, что со временем в большой компании таких систем накапливается изрядное количество. И очень часто было бы полезно иметь некоторый интеграционный зонтик, позволяющий одной системе передать (или получить) контент в другую (из другой). Или же иметь какой-то простой и стандартный способ работать с накопленным контентом из прикладных (не СЭД) программ.
Тем не менее полноценных стандартов для такой интеграции не было. И вот в конце года, первый кандидат на такое звание появился. Называется он Content Management Interoperability Services (CMIS), причем предложен он тяжеловесами на данном поле — EMC, Microsoft, IBM, а поддержан еще кучей других неслабых вендоров, включая Oralce, SAP, OpenText и т.п.
Стандарт задает общую модель данных и набор описаний веб-сервисов для доступа к данным, хранящимся в СЭД. При этом API выполняется в двух технологических вариантах веб-серсисов – SOAP и REST.
В настоящий момент имеется спецификация, проходящая стандартизацию в ISO и AIIM, а также референтные реализации основных вендоров. Предполагается, что стандартом она станет к середине года.
Разработка изначально не ориентирована на дублирование всех возможностей СЭД. Также беглый осмотр спецификации показывает, что даже из этого урезанного набора много вещей имеет статус «опционально». Более того, вопросы локалей как-то обойдены серьезным вниманием.
Тем не менее, даже основной функционал гораздо богаче того, что предлагают альтернативы сегодняшнего дня, например, WebDav. Такая штука точно была бы полезна в некоторых проектах, в которых я участвовал.
Интересно, начнут ли ее реализовывать наши производители СЭД.
***
Ниже более подробна описана техническая часть. Для тех, кому это интересно.
Модель данных обычна для большинства современных СЭД. Объекты четырех базовых типов:
На основе этих типов данных создаются производные типы и их подтипы. На основе типов формируются сами объекты, с их уникальными ID (или, опционально, http URI)
Базовые сервисы:
Поиск строится на базе язык запросов на базе подмножества SQL92, некоторыми ограничениями и расширениями. Например, расширения включают возможность полнотекствового поиска (по контенту), поиск в многозначных реквизитах (реквизитах в форме списков), ограничение поиска по папкам и деревьям папок.
Технически для преобразования запросов строится некий реляционное отображение хранилища документов, где каждый тип объектов представляет свою таблицу, а каждая запись — объект этого типа.
Подробности всего этого здесь:
http://xml.coverpages.org/cmis.html
Можно также зайти на страницу wikipedia — там есть ссылки на видео с забавным японцем, рассказывающим про CMIS:
http://en.wikipedia.org/wiki/Content_Management_Interoperability_Services
Спека доступна у IBM:
http://www-01.ibm.com/software/data/content-management/cm-interoperablity-services.html
Published 4 февраля 2009 г. 8:00 by Vlad Borkus
Filed under: Документооборот, ECM, СЭД, Стандарты
mgalimov said:Мы присматриваемся к нему: CRUD- и поисковые сервисы нужны, а тут, в принципе, уже готовые спецификации, на которые не так сложно перейти и поддержать. (К слову, очень элегантно решена задача политик :) И еще очень чувствуется рука Микрософта.)
Но вопрос в назначении CMIS и реальной полезности. Сейчас предполагается, что есть некое внешнее относительно всех ECM-систем приложение, которое само знает, что откуда взять, как обработать и куда сложить. Это удобно, скажем, для интеграции ERP (финансы, логистика) с архивами (первички, отчетности). Но будет ли при этом великое разнообразие ECM-систем в организации, такое, которое бы буквально потребовало поддержки единых стандартов?
И еще CIMS не решает задачу проталкивания документов из системы в систему, т.е. для обмена документами и реализации сквозных процессов, скажем, в холдинговых структурах, подходит плохо. С его помощью неудобно распространять приказы, обмениваться официальными письмами в электронном виде и т.п. Да, это не его функция, но в целом хотелось бы и в эту сторону подвижек от гигантов :)
февраля 4, 2009 9:06
Vlad Borkus said:
>Но будет ли при этом великое разнообразие ECM-систем в организации, такое, которое бы буквально потребовало поддержки единых стандартов?
Насчет "потребовало бы" не знаю, в конце концом можно ручками что-то свое написать. Но вот полезно - это точно. Скажем, в знакомой нам нефтяной компании, только в центральном аппарате штук пять систем. Накопились. Причем, живые. И были ситуации, где такой интерфейс возможно был бы кстати. Или вот тот же Directum ставить как зонтик к другим (накопленным) системам или архивам.
Или вот в Росэнергоатоме тот же Documentum решал задачу по интеграции СЭД под общим зонтиком. Ситуации встречаются, в общем, весьма часто.
>И еще CIMS не решает задачу проталкивания документов из системы в систему, т.е. для обмена документами и реализации сквозных процессов, скажем, в холдинговых структурах, подходит плохо
Как одна из целей интеграция разных организаций под зонтиком BPM, судя по презентациям, ставится.
Но вообще это стандарт технологический, не прикладной. Приказы и т.п. - это уже другой логический уровень. Это стандартная ситуация с интеграцией.
февраля 4, 2009 14:01
???????? ???????? ?????????????? : CMIS said:
PingBack from http://itblogs.ru/blogs/yurriakopov/archive/2009/02/04/cmis.…
Те, кто внедрял системы документооборота, знают, что со временем в большой компании таких систем накапливается изрядное количество. И очень часто было бы полезно иметь некоторый интеграционный зонтик, позволяющий одной системе передать (или получить) контент в другую (из другой). Или же иметь какой-то простой и стандартный способ работать с накопленным контентом из прикладных (не СЭД) программ.
Тем не менее полноценных стандартов для такой интеграции не было. И вот в конце года, первый кандидат на такое звание появился. Называется он Content Management Interoperability Services (CMIS), причем предложен он тяжеловесами на данном поле — EMC, Microsoft, IBM, а поддержан еще кучей других неслабых вендоров, включая Oralce, SAP, OpenText и т.п.
Стандарт задает общую модель данных и набор описаний веб-сервисов для доступа к данным, хранящимся в СЭД. При этом API выполняется в двух технологических вариантах веб-серсисов – SOAP и REST.
В настоящий момент имеется спецификация, проходящая стандартизацию в ISO и AIIM, а также референтные реализации основных вендоров. Предполагается, что стандартом она станет к середине года.
Разработка изначально не ориентирована на дублирование всех возможностей СЭД. Также беглый осмотр спецификации показывает, что даже из этого урезанного набора много вещей имеет статус «опционально». Более того, вопросы локалей как-то обойдены серьезным вниманием.
Тем не менее, даже основной функционал гораздо богаче того, что предлагают альтернативы сегодняшнего дня, например, WebDav. Такая штука точно была бы полезна в некоторых проектах, в которых я участвовал.
Интересно, начнут ли ее реализовывать наши производители СЭД.
***
Ниже более подробна описана техническая часть. Для тех, кому это интересно.
Модель данных обычна для большинства современных СЭД. Объекты четырех базовых типов:
- запись о документе, характеризующаяся набором полей (реквизитов), и, возможно, тела документа (content stream);
- папка с документами -- контейнер для других объектов. Опционально предусматривается, что документ может находиться в одной или нескольких папках, или вне папки. Папки могут быть вложены.
- объект «связь». Направленная ссылка с одного объект на другой, обладающая некоторым набором свойств.
- политика управления объектом. Некоторая запись в стандарте нижележащей СЭД, которая определяет права доступа (ACL), удержания или какие-либо правила обращения с объектами. Политику можно «прикреплять» к объектам, активизируя ее таким образом.
На основе этих типов данных создаются производные типы и их подтипы. На основе типов формируются сами объекты, с их уникальными ID (или, опционально, http URI)
Базовые сервисы:
- создание, получение, обновление, удаление объекта;
- поиск по объектам объектам и ссылкам (в том числе поиск документов, ссылающихся на данных).
- сервисы для подключения политик управления к объектам, отключения политик от объектов.
Поиск строится на базе язык запросов на базе подмножества SQL92, некоторыми ограничениями и расширениями. Например, расширения включают возможность полнотекствового поиска (по контенту), поиск в многозначных реквизитах (реквизитах в форме списков), ограничение поиска по папкам и деревьям папок.
Технически для преобразования запросов строится некий реляционное отображение хранилища документов, где каждый тип объектов представляет свою таблицу, а каждая запись — объект этого типа.
Подробности всего этого здесь:
http://xml.coverpages.org/cmis.html
Можно также зайти на страницу wikipedia — там есть ссылки на видео с забавным японцем, рассказывающим про CMIS:
http://en.wikipedia.org/wiki/Content_Management_Interoperability_Services
Спека доступна у IBM:
http://www-01.ibm.com/software/data/content-management/cm-interoperablity-services.html
Published 4 февраля 2009 г. 8:00 by Vlad Borkus
Filed under: Документооборот, ECM, СЭД, Стандарты
Comments
mgalimov said:Мы присматриваемся к нему: CRUD- и поисковые сервисы нужны, а тут, в принципе, уже готовые спецификации, на которые не так сложно перейти и поддержать. (К слову, очень элегантно решена задача политик :) И еще очень чувствуется рука Микрософта.)
Но вопрос в назначении CMIS и реальной полезности. Сейчас предполагается, что есть некое внешнее относительно всех ECM-систем приложение, которое само знает, что откуда взять, как обработать и куда сложить. Это удобно, скажем, для интеграции ERP (финансы, логистика) с архивами (первички, отчетности). Но будет ли при этом великое разнообразие ECM-систем в организации, такое, которое бы буквально потребовало поддержки единых стандартов?
И еще CIMS не решает задачу проталкивания документов из системы в систему, т.е. для обмена документами и реализации сквозных процессов, скажем, в холдинговых структурах, подходит плохо. С его помощью неудобно распространять приказы, обмениваться официальными письмами в электронном виде и т.п. Да, это не его функция, но в целом хотелось бы и в эту сторону подвижек от гигантов :)
февраля 4, 2009 9:06
Vlad Borkus said:
>Но будет ли при этом великое разнообразие ECM-систем в организации, такое, которое бы буквально потребовало поддержки единых стандартов?
Насчет "потребовало бы" не знаю, в конце концом можно ручками что-то свое написать. Но вот полезно - это точно. Скажем, в знакомой нам нефтяной компании, только в центральном аппарате штук пять систем. Накопились. Причем, живые. И были ситуации, где такой интерфейс возможно был бы кстати. Или вот тот же Directum ставить как зонтик к другим (накопленным) системам или архивам.
Или вот в Росэнергоатоме тот же Documentum решал задачу по интеграции СЭД под общим зонтиком. Ситуации встречаются, в общем, весьма часто.
>И еще CIMS не решает задачу проталкивания документов из системы в систему, т.е. для обмена документами и реализации сквозных процессов, скажем, в холдинговых структурах, подходит плохо
Как одна из целей интеграция разных организаций под зонтиком BPM, судя по презентациям, ставится.
Но вообще это стандарт технологический, не прикладной. Приказы и т.п. - это уже другой логический уровень. Это стандартная ситуация с интеграцией.
февраля 4, 2009 14:01
???????? ???????? ?????????????? : CMIS said:
PingBack from http://itblogs.ru/blogs/yurriakopov/archive/2009/02/04/cmis.…
Комментариев нет:
Отправить комментарий