IBM Content Manager OnDemand 允许公司管理大量的印刷品，如报表、发票或结算表。Debbie Wagner（一位 CM OnDemand 软件工程师）描述了近来 OnDemand 中的一些变化，这些变化为管理和保护这些重要的资产提供了更大的灵活性。

简介
IBM Content Manager OnDemand是一个自动化的归档和检索系统，它可以存储诸如报表、对帐单、发票和图像文档之类的打印输出。打印输出在各种存储介质（包括硬盘、光盘和磁带）上进行处理和存储。从打印输出抽取索引值，并将它们存储在关系数据库中。在存储了打印输出和索引值之后，您可以使用任何 OnDemand 客户机程序检索文档。OnDemand 包含了 IBM DB2® Universal Database™（DB2 UDB），并且后者充当前者的数据库管理器。OnDemand 还包含了 Tivoli® Storage Manager（TSM），后者充当归档存储管理器。

OnDemand 的典型用途是存储和检索月结单，如信用卡对帐单。信用卡公司每个月都会生成几百万份信用卡对帐单。这些对帐单在 OnDemand 中处理并存储在 OnDemand 中。在对帐单发送后的几个月中，消费者可能会对出现在他或她的对帐单上的交易持有疑义。通过使用 OnDemand，客户服务代表可以迅速地检索到有疑问的对帐单，查看消费者收到的对帐单的原样副本，并且及时地为消费者提供帮助。

应用程序、应用程序组、文件夹、存储器集和打印机是一些对象，它们表示 OnDemand 如何存储、管理、检索、查看和打印报表和索引数据。通过定义用户和组，并且赋予他们满足某个组织的数据安全性策略所必需的权限级别，您可以控制和限制对报表和索引数据的访问。对象定义以表的形式存储在关系数据库中，它们与索引数据分离，并且可通过管理客户机程序访问。

OnDemand 提供了集中或分散系统管理的能力。 集中式环境意味着这样一类用户 — 系统管理员控制在系统上定义的 所有对象的创建和访问。相反， 分散式环境意味着划分系统管理员的任务，把划分的任务指派给其他用户。其他用户的职责各异，包括用户管理、组管理、应用程序组管理、文件夹管理，或者管理任务的任意组合。

重要事项：您应该在将对象添加到系统 之前决定使用集中式还是分散式环境。尽管该决定是可逆的，但是如果已经添加了大量的对象，那么从一种管理更改到另一种管理所需的工作量会是巨大的。本文描述了如何在 OnDemand 中进行系统管理，重点介绍了如何分散系统管理。我还描述了两个特殊的用于分散系统管理的模型：对象类型（Object Type）模型和对象所有者（Object Owner）模型。

针对现有 OnDemand 用户的背景知识
从 OnDemand 的第一个发行版开始，它就支持集中式系统管理和有限的分散式系统管理。如下两种用户类型支持对象类型模型：用户管理员（User Administrator）和应用程序组／文件夹管理员（Application Group／Folder Administrator）。在 OnDemand 的 V2.2.1.6 中，添加了 Create Users、Create Groups、Create Application Groups 和 Create Folder 许可权级别。许可权级别提供了支持本文描述的对象所有者模型的功能，有一点例外，OnDemand 系统上所有用户都可看见用户和组。

在 V2.2.1.10 中，进行了一项改动以支持完整的对象所有者模型。该变化的结果就是，列表（如许可权列表）中的用户和组不再可见，除非管理客户机程序的用户被赋予了查看用户或组的许可权，或者该用户创建了用户或组。这一变化对于能够在同一系统上保持数据和用户隔离至关重要。

基础知识
通常，OnDemand 系统的用户可归为四类：最终用户、报表管理员、用户管理员和系统管理员。

• 最终用户
  
  最终用户使用 Windows 客户机程序登录到 OnDemand 服务器，并且提交查询以检索要查看的文档。
  
  
• 报表管理员
  
  报表管理员负责确定将从报表中抽取什么信息并将其保存为索引，如何将数据装入、存储进 OnDemand 并在其中维护该数据，以及如何向最终用户表示搜索条件。该信息保存在 OnDemand 的下述位置：应用程序、应用程序组和文件夹。
  
  报表管理员还负责确定哪些最终用户可以访问已经被装入的报表数据。
  
  
• 用户管理员
  
  用户管理员仅限于将最终用户添加到系统，或者添加其他用户管理员。
  
  
• 系统管理员
  
  系统管理员具有系统上最高级别的权限，他主要负责授予其他用户执行各种任务和功能的许可权。系统管理员还负责定义组、系统打印机和定义数据归档策略的存储器集。

既然您知道了用户类别以及必须由各种用户执行的任务，那么现在必须决定系统管理应该是集中式还是分散式。换而言之，是否必须或有必要让一个用户控制对 OnDemand 系统的访问；或者是否必须或有必要在几个用户之间划分管理任务，以控制对 OnDemand 系统的访问，也就是分摊工作量？在安装 OnDemand 时，会自动添加一个系统管理员用户。在集中式环境中，该用户（称为“admin”）用于执行所有的管理任务（如添加最终用户、创建报表定义、装入数据、为最终用户提供报表访问等等）。除非其他管理员用户被添加到了系统中，否则“admin”用户是可以执行这些任务的唯一用户。

似乎对于 OnDemand 来说只有一个管理员意味着大量的工作。那么，何时应该考虑集中式环境呢？集中式系统管理在较小的 OnDemand 安装中可以很好地工作，“较小”意味着定义到系统的用户和报表的数量比较少。集中式环境也可能最适合于资源有限且只有一个人可以执行系统管理任务的环境。系统管理也可以被集中，但是由多个用户进行控制；每个用户都是系统管理员，并且可以执行所有系统管理任务。

分散式系统管理
随着对计算机数据提供更多保护和保密性需求的不断增加，对于许多公司而言，必须有一种更成熟的安全策略。OnDemand 通过允许灵活的分散式系统管理支持了该策略。由于 OnDemand 具备各种用户类型和权限级别，因此有许多种分散系统管理的方法；但是，对于大多数环境而言，这样的需求 — 由许多人（或多个组织）控制对特定数据的访问，或者控制对 OnDemand 系统特定对象的访问 — 决定了如何分散系统管理。下面描述了两个模型

• 对象类型模型
• 对象所有者模型

对象类型模型
图 1显示了对象类型模型。对象类型模型提供了对 OnDemand 系统特定对象进行访问的控制能力。例如，所有定义到系统的报表由报表管理员创建和维护。所有定义到系统的用户和用户组由用户管理员创建和维护。

图 1. 对象类型模型

在某些环境中，必须根据技能水平、安全性需求或相关的任务划分管理任务。对象类型模型是适合于该环境的解决方案。与创建和维护用户和用户组相比，创建和维护报表数据需要一套不同的技能。必须学习报表管理员技能的用户数量可以仅限于少量的用户。使用对象类型模型的另一个条件是管理任务是由一个用户或用户组执行的，不管这些任务是针对 OnDemand 还是针对其它系统的。添加和维护用户的任务也可以与创建和维护报表的任务分离，以便为数据提供额外的安全性。

实现对象类型模型

在对象类型模型中，系统管理员定义了两种新用户。

• 报表管理员，通过添加用户类型为“应用程序组／文件夹管理员（application group/folder administrator）”的用户可以将其定义到 OnDemand。
• 用户管理员，通过添加用户类型为“具有 Create Groups 权限的用户管理员（user administrator with Create Groups authority）”的用户可以将其定义到 OnDemand。

报表管理员确定将从报表中抽取什么信息并将其保存为索引，如何将数据装入、存储到 OnDemand 并在其中维护该数据，以及确定如何向最终用户表示搜索条件。该信息保存在 OnDemand 的应用程序、应用程序组和文件夹中。

报表管理员还确定哪些最终用户可以访问已经被装入的报表数据。推荐的并且也是最简单的完成该工作的方法就是授予最终用户组访问权，而不是将访问权授予个别最终用户。当其他最终用户需要访问报表数据时，报表管理员无须进行其它工作。当最终用户被添加到组中时，最终用户会自动获得对所有可由该组访问的报表的访问权。

用户管理员负责将最终用户添加到系统，并且负责创建需要访问相同报表数据的最终用户组。用户管理员还必须将报表管理员添加到需要访问报表数据的任何组。作为组成员，报表管理员可以看到应用程序组和文件夹的许可权列表中的组，并且可以授予组访问权。该步骤是必需的，因为报表管理员对最终用户或组无访问权，另外也无法在许可权列表中看到他们。 表 1显示了具有管理权的用户及分配给这些用户的任务。

表 1. 对象类型模型中的管理员角色

对象所有者模型
图 2显示了对象所有者模型。对象所有者模型提供了控制受限的用户组对特定报表访问权的能力。报表和用户由该用户组的管理员在系统上创建和维护。系统上存在着其它报表和用户，它们由不同的管理员维护。每组报表和用户都独立于其它组的报表和用户，并且任何其它组都不能访问它们。

图 2. 对象所有者模型

很多为其它公司提供服务（如开帐单；记帐；工资单、对帐单的处理和打印）的公司都需要保证各个公司数据的隐私和安全。换而言之，某个公司的客户服务代表或管理员应当无权访问其它公司的数据，即使该数据是在同一个 OnDemand 系统中维护的。对象所有者模型是适合于这类环境的一种解决方案。每个公司的数据以及需要访问这些数据的用户是由每个公司的管理员创建和维护的。

实现对象所有者模型

在对象所有者模型中，来自几个不同来源的报表数据驻留在同一个 OnDemand 系统上。数据的每个逻辑分组可以由不同的和唯一的一组用户访问。对于数据的每个逻辑分组，系统管理员定义了两种新用户：

• 用户管理员，他作为用户类型为“具有 Create Users 和 Create Groups 权限的用户（user with Create Users and Create Groups authority）”的用户定义到 OnDemand。以这种方式定义用户管理员，用户管理员只对那些他或她创建的最终用户和组具有权限。
  
  
• 报表管理员，他作为用户类型为“具有 Create Application Groups 和 Create Folders 权限的用户（user with Create Application Groups and Create Folders authority）”的用户定义到 OnDemand。报表管理员只对他或她创建的应用程序、应用程序组和文件夹具有权限。

系统管理员还必须授予用户管理员访问报表管理员的权利。否则，用户管理员将无法将报表管理员添加到他或她创建的任何组。再说一次，这是因为用户管理员不能创建报表管理员，并且只能访问他或她创建的那些用户。

两种模型中的用户管理员和报表管理员的职责是相同的。区别在于，在对象类型模型中，管理员对于系统上的所有用户或报表都有权限，而在对象所有者模型中，管理员只对他们创建的那些用户或报表具有权限。 表 2显示了具有管理权的用户及分配给这些用户的任务。

表 2. 对象所有者模型中的管理员角色

变体
上面描述的两种模型存在着许多不同的变体。例如，在对象所有者模型中，没有将报表管理员定义成能够定义应用程序组和文件夹的用户，而是将报表管理员的功能赋予两个用户 — 一个用户创建应用程序组，而另一个用户创建文件夹。选择合适的模型或变体是一项重要的决定，因此在规划过程的早期就要做好决定。稍后更改成另一种模型不是不可能的，但是，如果系统上定义了大量的对象，那么可能需要额外的工作。

推荐
下面是一些一般性原则，用于决定是集中还是分散系统管理，如果选择了分散管理，还要确定使用哪种模型。

提示和技巧

• 为允许多个用户管理相同的组，创建用户组并使该组成为需要由多个用户进行管理的任何组的组所有者。
  
  
• 如果将 Create Groups 权限与 Create Users 权限组合，或者将其添加给用户类型为用户管理员的用户，那么它就会得到最有效的使用。因为组的目的是为了赋予一组用户相同的许可权，如果创建组的用户无法访问任何用户，那么它就不是很有用。
  
  
• 对报表数据的访问权应当赋予一组最终用户，而不是个别最终用户。当新的最终用户需要访问报表数据时，只需将最终用户添加到适当的组。
  
  
• 要允许报表管理员查看应用程序组和文件夹的许可权列表中的组，始终将报表管理员添加到需要访问权的组。