Интеграция СЭД, новый стандарт CMIS

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. Такая штука точно была бы полезна в некоторых проектах, в которых я участвовал.

Интересно, начнут ли ее реализовывать наши производители СЭД.

***

Ниже более подробна описана техническая часть. Для тех, кому это интересно.

Модель данных обычна для большинства современных СЭД. Объекты четырех базовых типов:

• запись о документе, характеризующаяся набором полей (реквизитов), и, возможно, тела документа (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

WS-Security: начинание благое, но безопасность SOA не обеспечивает

Source: http://www.itblogs.ru/blogs/borkus/archive/2007/08/19/ws-security.aspx

Одно из основных правил программирования говорит о том, что специализированное решение в своей узкой области как правило будет лучше обобщенного. Это свойство всегда проявляется при выработке стандартов – в них закладывается либо самая общая, либо «усредненная» модель. В первом случае стандарт получается очень сложным, во втором – открывается поле для всевозможных фирменных расширений, его «улучшающих».

Примерно так обстоит дело со стандартами в области безопасности SOA. В стеке WS-* запланирована очень глобальная модель безопасности, включающая почти десяток всяких спецификаций (WS-Security, WS-Secure Conversation, WS-Trust, WS-Federation, WS-Policy, а также XML Digital Signature, Security Tokens Profiles (для SAML, Kerberos,X.509) и т. п.

Благодаря этому возникает целый комплекс очевидных проблем для SOA:
1) Не все эти стандарты реализованы одинаково во всех продуктах, что делает разные компоненты SOA несовместимыми.
2) Так как общие стандарты разрабатываются медленно, открывается поле для "частных" расширений вендоров, которые еще более снижают совместимость.

Я бы не стал писать про это статью, но на днях натолкнулся на интересное выступление на эту тему специалиста в области безопасности Брэда Хилла (http://www.isecpartners.com/files/iSEC_HILL_AttackingXMLSecurity_bh07.pdf). В почти 200-страничной презентации обстоятельно показывается, почему стек WS-S -- пока не лучший способ для обеспечения безопасности для открытых в Интернете сервисов,B2B-сервисов и внутрикорпоративных web-сервисов.

Во первых, для любых внутрикорпоративных и B2B ИТ-систем характерна более высокая степень доверия к их пользователям, и проблемы безопасности как правило решаются "не внутрикорпоративными фаерволами, а организационными мероприятиями и [в случае B2B] адвокатами". Главное, что должна обеспечить общая инфраструктура безопасности -- это протоколирование всех действий и точную идентификацию пользователей, получивших доступ к конкретной системе. Это тезис, с которым сложно не согласиться.

Но для этих задач ЛУЧШЕ всего подходит стандартный SSL, при одновременном применении _клиентского_ и северного сертификатов. В самом деле, у него есть набор явных преимуществ:

1) Он решает как задачу безопасной аутентификации (по сертификату);
2) Он защищает трафик от пользователя к системе;
3) Что еще более важно -- он совершенно ОДИНАКОВО реализован во всех системах, в том числе старых -- пяти и даже более летней давности;
4) Он покрывает 99% процентов того, что нужно для решения реальных задач.

Модель же безопасности на уровне сообщений, примененная в WS-S, не дает в этом смысле никаких преимуществ, так как опять-таки в 99% случая все, что от нее требуется -- это аутентификация пользователей. Но он также неодинаково реализован на новых и старых системах, а применение агентов-посредников тоже не всегда удобно и эффективно. Также WS-S (в конечном итоге за счет XML Digital Signature) опирается на шифрование больших объемов данных открытыми ключами – очень ресурсоемкая операция по сравнению с симметричным шифрованием в SSL. Поэтому при использовании для интеграции внутрикорпоративных систем WS-Security оказывается менее адекватен, чем SSL.

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

WS-Security плох тем, что для его реализации используется работа многих слоев (от XML Encryption, XML Digital Signature, Security Tokens Profiles (SAML, Kerberos, X.509), WS-Trust, WS-Federation и т.п) -- слишком много точек для потенциальной атаки, слишком сложно заставить все это скоординировано работать.

Брэд Хилл показывает в своей презентации как можно эти уязвимости использовать, какие есть стандартные "дыры" в реализации этих спецификаций, например, в XML Парсере. Эти дыры можно было бы отключить настройками, но сегодняшние продукты таких настроек не предоставляют. И в любом случае получается слишком много предположений о квалификации среднего корпоративного разработчика.

Вместе с тем, стек WS-S создает ряд бизнес-возможностей, таких, как цифровые деньги, DRM-применения, распределенная аутентификация, и транзакции, в которых участвуют много сторон. Но так как последствия для безопасности от самостоятельного использования этих протоколов пока до конца не изучены, то WS-S рекомендуется применять не самостоятельно, а вместе с отлаженной базой SSL.

//Влад Боркус, www.konnasi.ru

Published 19 августа 2007 г. 23:09 by Vlad Borkus Edit
Filed under: SOA, Безопасность

Comments

Недоделанный стандарт XQuery

Source: http://www.itblogs.ru/blogs/borkus/archive/2007/08/15/_1D04350434043E04340435043B0430043D043D044B043904_-_4104420430043D043404300440044204_-XQuery.aspx

Прочитал на неделе IBM Red Book, посвященный работе с XML в СУБД DB2. Хотя качество этих книг в последнее время падает -- их пишут коллективы авторов, редактура слабая, что приводит к большому числу повторов, -- эти книги все еще интересны и познавательны.

DB2, как известно, очень хорошая СУБД. Я в нее «влюбился» еще лет десять назад просто за программы инсталляции и администрирования -- все было настолько удобно по сравнению с Oracle DB, что использовать Oracle больше не хотелось.

Однако, OracleDB всегда опережала DB2 по техническим новинкам -- сначала это было более совершенная поддержка журналов транзакций, потом большее быстродействие за счет кэширования результатов запросов, потом поддержка обектно-реляционных данных и т.п. Все это появлялось и в DB2, но спустя какое-то время. DB2 просто всегда оставалась надежной, производительной и промышленной платформой, но не лидер.

Пару лет назад в нее, также с некоторым опозданием, добавили поддержку XML.

Вокруг XML-СУБД было много шума в свое время, так как они существенно снижают нагрузку на разработчика приложений. И сейчас еще встречаются статьи на тему «как важно в SOA использовать «родную СУБД», а не гибридную»  и т.п. Но интерес к ним стих, так же, как когда-то спал интерес к объектным базам.

«Чисто» XML базы в существенной степени были вытеснены гибридными решениями на базе традиционных СУБД. Вначале гибриды были совсем примитивными (позволяли только хранить строку XML в поле BLOB), но потом обросли поддержкой специальных XML-полей в таблицах и стандарта XML-запросов Xquery.

По этому пути пошла и DB2. Она позволяет смешивать в запросах как SQL-поля, так и XQuery-поля, что дает возможность извлекать данные изнури XML-документов. Скажем, если сделать запрос на языке SQL-XML, то  можно делать выборку (SELECT) одновременно по полям таблицы и XML-иерархии, и выдавать результат в виде обычной SQL-таблицы. Или, наоборот, сделать запрос XQuery и получить результат в виде документа XML.

В этих процессах есть тонкости -- можно задавать довольно сложные преобразования данных, можно проверять помещаемый в базу XML на соответствие схемам, строить смешанные виды (с ними нужно быть осторожными, т.к. XML-столбцы не будут индексироваться) -- об этом собственно и книжка.

Но, что интересно, что вся красивая картинка рушится, когда надо записывать данные в XML. Записать можно только целый документ  -- стандарт XQuery 1.0 не поддерживает записи внутрь XML, только извлечение данных. Соответственно, гибридные СУБД предлагают некоторые обходные маневры -- в том числе DB2 имеет специальную хранимую процедуру -- но все равно это уже не стандартно, да и не очень эстетично.

 //Влад Боркус

Published 15 августа 2007 г. 3:15 by Vlad Borkus
Filed under: XML, СУБД, Базы Данных

Comments