名称	价格(万)	用户数量(位)
quickr 知识管理	8
联系我们：010-62981506

简介

IBM Lotus Quickr 是一款基于 Web 2.0 的团队协作软件，旨在通过变换文档共享的方式来实现更加高效的团队协作。IBM Lotus Quickr 团队协作软件能够改变工作组开展项目协作或共享日常内容（如文档和富媒体）的方式。Lotus Quickr 文档共享软件为企业防火墙内外的团队提供支持，使之可以更轻松地与客户、合作伙伴、供应商团队或内部部门和项目团队协作。
作为新一代的文档协作平台，Lotus Quickr V8.0 提供了功能强大的文档管理功能，同时为用户提供了一套完备的文档管理 API 以供用户定制和扩展，即 Content Public API，其中包括 WebService API 和 REST API 两部分。本文将介绍文档 Content Public API 相关的数据模型、操作接口，并举例介绍 Content Public API 的使用方法。

一、 Content Public API 在 Quickr 整套产品中的位置

Content Public API 是 Quickr 整套产品对外提供的统一文档操作接口。Lotus Quickr 8.0 包含两套产品，Quickr for Domino 和 Quickr for Portal；尽管两者功能类似，但是实现却有很大不同。Quickr for Domino 后台是基于 Domino Server，其文档存储是基于 NSF 的文档结构。Quickr for Portal 后台是基于 IBM WebSphere Portal Server，其文档存储是基于 JSR-170（JCR：Java Content Repository）的文档模型。然而，尽管两者有着迥然不同的存储模型，但是两套产品对外有着共同的文档操作接口，就是 Content Public API。共同的文档操作接口为用户屏蔽了数据存储的异构性，实现了对异构数据的透明访问。除了 Quickr for Domino 和 Quickr for Portal 之外，FileNet 也将会集成到 Quickr 套件的后续版本中来，同样 FileNet 也将遵循 Content Public API 的定义，对外提供统一的文档操作接口。 作为 Lotus Quickr 的一大特性，Lotus Quickr 为客户提供了一系列功能强大的连接器（Connectors），这些连接器可以以插件的形式被安装到常用的桌面应用软件中，实现基于这些软件对 Quickr 服务器的中文档数据的访问。Quickr 8.0 中提供了如下的连接器：Explorer 连接器，Sametime 连接器，Notes 连接器，Office 连接器；用户可以在 Quickr 首页中找到并下载连接器的安装套件。值得一提的是，这些连接器是基于 Quickr 的 Content Public API 来实现的，用户通过使用连接器就可以体会 Public API 提供的强大功能。除此之外，IBM 也鼓励商业伙伴或者客户基于 Content Public API 来开发更多的，与自己应用相集成的 Connector。在 Quickr 8.0 中，Content Public API 包括 WebService API 和 REST API 两部分，后续版本将提供更多的 API。

图 1. Content Public API 在 Quickr 中的位置

二、 Content Public API 的两大部分

Lotus Quickr 8.0 提供了两部分的 Content Public API：WebService API 和 REST API。两套 API 是相互独立的两部分，两套 API 都是基于目前流行的开放标准。
WebService 基于 W3 定义的 WSDL（WebService Definition Language）和 SOAP（Simple Object Access Protocol）协议。Quickr WebService 对外提供一个 WSDL 文档。WSDL 是一个自描述的 XML 文档，它包含了对 Quickr WebService 模型、接口、操作、消息的定义和描述。基于 WSDL，客户可以自己产生不同语言（VB, C#, C++, Java 等）的客户端来使用 Quickr WebService。Quickr 8.0 WebService 的 WSDL 文档中定义了三个服务（Port Types）: ContentService，DocumentService，LibraryService。
相对于 WebService，REST 是一个更加轻量级的架构。相比面向活动的 SOAP，资源是 REST 关注的中心。REST 适合于面向资源的服务，服务提供方维护一组资源，并公开一组基本操作来执行以下任务：检索资源、修改资源、创建新资源、删除资源。Quickr 中的 REST API 是完全遵循开放的 IETF 标准（ATOM）。ATOM 是用于发布条目（单个主题或者项）和提要（主题或项的集合）的文档格式标准。ATOM 文档的传输采用的开发的协议 APP（Atom Publish Protocol）。Quickr REST Service 提供针对 Quickr 中的文档库、文档、文件夹、视图、草稿、评论等资源的 Feed 发布、获取、添加、修改、删除等操作。

1、 WebService 数据模型

尽管 Quickr 的两套产品 Quickr for Portal 和 Quickr for Domino 后台分别基于不同的数据存储格式，但归根到底 Quickr Content Public API 是以 Quickr for Portal 的 JCR 结构为基础建立起来的。下面是 Content Public API 数据模型在 Quickr for Portal 中的数据模型关系。

图 2. Quickr for Portal 文档存储结构

•JSR170（JCR，Java Content Repository）被用来作为与所有内容对象交互的主要 API。
•IBM Content Model 定义了内容管理应用程序共有的元素（elements）、元数据（metadata）、集成模式（aggression patterns），Content Model 中的条目被分为两类 base type 和 metadata type。
•IBM Collaborative Content Model 则扩展了 IBM Content Model 来表示 Quickr 中文档管理相关的行为。Collaborative Model 中定义的规则，并没有限制或修改 Content Model 中的行为。
文档库（ClbLibrary）是 Content API 数据模型的基础。在 Quickr for Portal 中，文档库是一个树形结构。对应到 JCR 存储结构，一个文档库就是 JCR 树中的一棵子树。一个文档库包含三个固定容器：文档模板容器（ClbDocumentTemplateContainer），属性表容器（ClbPropertySheetTypeContainer），文档类型容器（ClbDocumentTypeContainer）。这些容器分别用来存储文档库中文件可能会使用到的文档模板、属性表、文档类型。容器中的元素为文档库一级共享的元素，同时文档库也可以共享父文档库容器中的元素。
文档库下面，用户就可以按照自己的需求建立文件和文件夹。在这里，文档有草稿的概念，草稿（ClbDraft）和文档（ClbDocument）是一对一的关系，一个文档有且仅有一个草稿。当文档被检出时候，对应的文档被锁住，产生草稿。当文档被检入时，草稿中的修改被合并到文档中，草稿被删除。

图 3. Quickr for Portal 文档库结构

2、 REST Feed文档格式

由于 REST 是面向资源的服务。Quickr 中的所有文档库、文档、草稿、文件夹、视图、评论都将对应一个唯一的 URL 来唯一标示。所有的资源的相关操作，都是通过这个唯一标识的 URL 来进行的。同时对于每个资源也存在另外一个 URL，它的作用是用来将该资源以 Feed 的形式发布出来以供 Feeds Reader 订阅。

图 4. REST Feed 文档格式

而 Quickr Server 上的所有文档库的 Feed URL 可以通过 http://主机名/dm/atom/introspection 获得。

三、 Content Public API 功能介绍

从功能来讲，Quickr WebService API 和 Quickr REST API 两部分功能有所交叉，但侧重点不同。下表列出了两套 API 针对数据对象分别可以进行哪些 CRUD（Create、Retrieve、Update、Delete）操作。

图 5. Content Public API 功能对比

通过 Content API 可以获得文档库的根节点，以及访问用户具有权限的所有文档库的列表。在 Quickr 中，是基于角色来进行用户管理的，其中预定义了四种基本的角色：管理者、编辑者、参与者、阅读者；除此之外，用户也可以根据自己的应用需求自定义角色。如果用户对某文档库拥有读（Read）以上的权限，那么就可以通过 API 能获得该文档库。关于用户的登陆，目前 Quickr 8.0 for Domino 已经支持匿名访问，而 Quickr 8.0 for Portal 还不支持匿名访问，将会在后续版本支持。
在 Quickr 的图形界面上有空间（Place）的概念，用户可以根据需求来创建团队空间。一个空间下面有一个或者多个文档库。然而在 API 的角度，空间是透明的。API 可以获得文档库，却无法知道该文档库属于那个空间。
APP 协议是一个轻量级的 Web 资源发布和编辑协议。由于 APP 协议本身更关注于文档的同步，所以 REST API 对文档附件的操作更有优势。由于性能的原因，WebService API 不支持对文档附件的上传和下载操作。目前对文档附件的操作只能通过 REST API 实现，由于底层 ClbComment 也是作为附件来存储的，所以对 Comment 的操作也只能通过 REST API 实现。
相比文档附件的操作，WebService 对文档相关属性的操作更加完备。对于 REST API 而言，属性对象 ClbDocumentType、ClbPropertySheetType、ClbViewTemplate 是透明的。对属性对象的操作只能通过 WebService API 来实现。