基于 FileNet P8 Content Engine 的 IBM InfoSphere Content Collector 电子邮件单实例模型分析

文档选项 未显示需要 JavaScript 的文档选项

级别： 初级

迟明群, 软件工程师, IBM

2009 年 11 月 05 日

IBM InfoSphere Content Collector 提供了邮件的单实例归档方案，可以最大程度的节省归档邮件的存储空间。本文介绍了基于 FileNet P8 Content Engine 存储库的单实例邮件归档模型，有利于读者深入了解 IBM InfoSphere Content Collector 的单实例归档机制。

IBM InfoSphere Content Collector 简介

IBM InfoShpere Content Collector 是继 IBM CommonStore 和 FileNet Email Manager 之后的新一代内容归档解决方案，它不仅可以对电子邮件进行归档管理，也可以处理文件系统。单从电子邮件方面，IBM InfoSphere Content Collector 同时支持了对 Lotus Notes 和 Microsoft Outlook 邮件的归档，以及后续的查询，显示，恢复，删除等邮件生命周期的管理操作。对于邮件的后端存储，IBM InfoShere Content Collector 也提供了两种产品的支持，即 IBM Content Manger（以下简称 CM）和 FileNet P8 Content Engine（以下简称 CE）。采用 IBM InfoSphere Content Collector 管理电子邮件，不仅可以释放邮件服务器上的空间，提高邮件服务器的性能，还可以保证客户满足法规遵从性的要求。在企业内部交流沟通中，发送电子邮件，往往要抄送多个人，这就产生多个重复的邮件拷贝 , 简单的邮件归档会将这些拷贝不加处理的统统存储。为了最大的节省存储空间，邮件归档时可以只存储一份邮件拷贝，用户在后续的查询，显示，恢复，删除中，所有的收件人可以共享这一份存储。这就需要邮件归档时后端存储库需采用单实例模型进行存储。对于后端存储库 CM，IBM InfoSphere Content Collector 直接借鉴了，在 IBM CommonStore 时期已经具备的单实例模型。但是对于 CE，以前并没有相应的模型，因此 IBM InfoSphere Content Collector 根据 P8CE 的特点，结合灵活的任务流程定制，开发了基于 CE 的电子邮件单实例模型。

回页首

基于 FileNet P8 CE 的单实例邮件模型

基 CE 的单实例邮件模型是由以下三部分组成：

• EmailInstance ( 简称 EI): 每一份邮件的拷贝都是一个 EI。两封看上去一样但内部隐含的某些属性不同的邮件拷贝，例如有两个收件人的邮件被认为是两个电子邮件实例，即两个 EI。他们将共享同一个 DEI。
• DistinctEmailInstance ( 简称 DEI): 两个看上去一样的邮件拷贝会共享同一个 DEI。DEI 的实例包括了这两个邮件拷贝中所有共同的数据，包括附件。而且它还会包括一个取值唯一的 Hash 值，这个 Hash 值可以用来区分 DEI 实例
• XML Instance for Text indexing ( 简称 XIT): 是用于邮件全文检索的 XML 模型，包括了邮件中的元数据，邮件内容和附件内容。XML 模型的结构组织必须与存储模型 (EI 和 DEI) 保持严格的一致性，以保证有效地全文检索。

为了加深理解，举例说明如下：用户 1 发信给用户 2，同时抄送给用户 3. 这样，用户 2 和用户 3 的邮箱里各有一封内容相同的信，但是这两封信邮件也有各自特有的属性，例如：邮件的 ID 和收件人邮箱 ID 等属性是不同的。我们认为这两封内容相同的信是同一个邮件 (DEI) 的两份拷贝（EI）. 如果归档时只存储一封邮件，不仅对用户体验没有影响，还可以节省 50% 的空间。对于一个企业，各级部门内部邮件抄送频繁，所以邮件的重复率极高，因此采用单实例邮件归档，能够节省的存储空间是相当可观的。

CE 单实例邮件的模型结构，如图 1 所示

在重复电子邮件的情况下，有且只有一份 DEI，包含真实的邮件文件本身；有且只有一个 XIT，和多个 EI，每个邮件拷贝对应一个 EI。DEI 和 XIT 之间有相互的引用，通过 DEI 可以找到 XIT，通过 XIT 也可以找到 DEI。这样在对邮件进行检索时，首先找到 XIT，进而找到邮件本身。同时 DEI 包括了多个 EI 的引用。所以真正一份邮件的拷贝，是由一个 EI+DEI 构成的。这种设计是完全依据了 CE 数据结构特点。

在 CE 里，数据结构采用的是面向对象的概念

基本的数据结构是类，每个类包含若干个属性。用户可以增加属性和创建子类来扩展数据结构。CE 里的 Class 主要分为两大类：

1. Document Class：通常用来定义文档，它有 ContentElement 的属性，可以存储文档本身，可以进行文档的版本管理。偏属于面向对象中的实体类。
2. Custom Class：是一个更通用的 Class，可以通过自定义完成不同的任务，不负责存储文档。因此，它没有 ContentElement 属性，不会包含内容，也不会进行文档版本管理，只是包含一些一般的属性。它更偏向于面向对象中的控制类。

在单实例邮件数据模型的实现中，DEI 是一个 Document Class，要存储归档邮件本身。XIT 也是一个 Document Class，要把生成的用于检索的 XML 文件作为内容存储。而 EI 是一个 Custom Class，不存储任何内容文件，只是把每个邮件拷贝所特有的元数据存储到 Class 的属性中。

单就存储而言，DEI 和 EI 模型已经实现了单实例归档，但是从符合法规遵从性的角度，邮件必须可以被检索。作为归档邮件存储库的 FileNet P8 CE 采用 FileNet P8 Content Search Engine（以下简称 CSE）作为全文检索引擎。但是 CSE 创建的索引不能直接把邮件的元数据，邮件内容和附件全部包括在内。为了解决这一问题，IBM InfoSphere Content Collector 创建了一个用于检索的 xml 文件，这个文件包括了邮件的所有内容，包括元数据，邮件文本内容和附件等。CSE 将会对这一 xml 文件做索引，在搜索的时候，搜索引擎首先找到 xml 文件，在通过 xml 文件里 DEI 的 ID，找到真实的归档邮件，也就是由 DEI 和 EI 组成的邮件模型。在 CE 里，这个 XIT 文件需要持久化，而且必须和 DEI，EI 保持数据一致。这也就会消耗存储一定的空间，当然这种消耗远远小于归档所有重复邮件拷贝的方式。

在 IBM InfoSphere Content Collector 里单实例模型的具体实现，如表 1 所示：

IBM InfoSphere Content Collector 的 Initial Configuration Tool 会根据单实例模型在指定的 CE object store 里创建实际的模型，即创建实际的类和属性。由于 ICCMailSearch 类用于全文检索，object store 必须提前配置好全文检索功能。

回页首

归档流程分析

为了方便说明，下面通过一个具体应用场景分析重复邮件的归档流程。

场景：用户 1 发送一份邮件给用户 2 ，并抄送给用户 3 。这样，用户 2 和用户 3 的邮箱里各有一封同一邮件的拷贝。

为了分析单实例，在 IBM InfoSphere Content Collector 的 Configuration Manager 里，构建一个典型的基于单实例模型归档邮件的 Task Route, 如图 2 所示。IBM InfoSphere Content Collector 会根据 Task Route 的定义对邮件进行归档。

这个 Task Route 定义了邮件归档的流程。为了清晰地说明，采用了用户手动归档的方式。

1. 用户 2 首选发出指令对自己邮箱里的邮件拷贝进行归档，EC Collector E-Mail By User Selection 会轮询到这封邮件。
2. EC Extract Metadata 抽取邮件相关的元数据，并利用其中的元数据计算出这封邮件唯一的 Hash 值。
3. P8 4.x Create Document 会根据上面的 Hash 值到指定的 CE object store 里查找这封邮件是否已经被归档过，如果没有 , 会创建一个没有内容的 DEI 的对象。
4. 由于这封邮件是第一次归档，所以流程会根据 P8 4.x Create Document 的结果，走分支 1 No Duplicate Found。
5. EC Prepare E-mail For Archive 和 EC Finalize E-mail For Compliance 会将轮询到的这封邮件，生成符合 IBM InfoSphere Content Collector 归档条件的临时文件，这个文件的实际内容就是邮件的原始文件，比如说如果归档 Domino 上的邮件，首先得到后缀为 csn 的文件，再转成 IBM Content Collector 特有的 BRI 文件。
6. P8 4.x Create Content Elements 会将生成的邮件文件作为内容添加到 DEI 的对象里，此时 DEI 生成完毕。
7. 为了便于管理，将生成的 DEI 对象 link 到某个 Folder 下，通过 FileNet Enterprise Manager，很容易得查找到归档后的 DEI 对象。因此添加了 P8 4.x File Document In Folder。
8. P8 4.x Create Email Document Instance 生成 EI。
9. Extract Text 将邮件内容，元数据，附件内容抽取出文本。
10. P8 4.x Save Prepare Text as XIT 将文本构建成 XIT，用于文本检索，至此，XIT 生成。
11. 后面的 Tasks，是将归档的邮件信息，以存根的方式回写到邮件服务器里，这样用户 2，就可以得到归档的反馈。到此，用户 2 的邮件拷贝归档完毕。

当用户 3 归档邮件的时候，在流程走到 P8 4.x Create Document 的时候，IBM InfoSphere Content Collector 会查找到这封邮件已经被归档过了，归档流程会走分支 2 Duplicate Found。通过 P8 4.x Create Email Document Instance 生成第二个 EI。当经过 P8 4.x Save Prepare Text as XIT 的时候，会将 xml 的新信息进行更新，添加第二个 EI 的一些元数据，如归档用户的 ID。接下来同样将归档信息以存根的方式通知用户 3，自此，用户 3 的邮件拷贝归档完毕。这样算下来，一共生成了一个 DEI，两个 EI 和一个 XIT。一个最简单的多个重复拷贝邮件的归档就完成了。由于只是 2 个拷贝，所以看不出节省的空间。

下面通过系统测试中模拟的企业邮件模型对节省空间进行计算分析。

回页首

空间节省分析

假定企业现有的邮件数量 1000000 封，平均邮件大小 30KB, 邮件的重复率如表 2 所示：

在企业内部，一封邮件往往要抄送一个部门的人，假设这个部门有 100 人，将会生成 1 个 DEI，100 个 EI 和一个 XIT，XIT 包含的 xml 文件的大小相当于一封实际邮件的大小，这样实际节省了 98 封信所占的空间。以此算来，上述邮件模型所占存储空间如表 3 所示：

所以，采用单实例归档一共节省空间 30-10.266=19.734GB，相当于节省了 65.78% 的存储空间。而且，数据量越大，重复比例越高，存储空间的节省率越高。可见单实例邮件归档可以极大节省企业在存储介质上的开销。

回页首

案例分析

下通过用户体验式地方式，讲解 IBM InfoSphere Content Collector 是如何进行单实例归档的。

首先，user1 发送一封样本邮件给 user2 和 user3。样本邮件内容如图 3 所示，除了邮件文本内容，还包括一个 PDF 和一个 WORD 附件。这样 user2 和 user3 的邮箱里都会收到一封内容相同的邮件。

然后，user2 通过 IBM InfoSphere Content Collector 在 Lotus Notes 里定制的菜单进行邮件归档。归档后，邮件会被存储在 FileNet P8 Content Engine 的 object store 里，而邮件服务器会生成归档的邮件存根。在 user2 看来，归档后，邮件的内容及附件会被连接所取代，如图 4 所示，这些连接通过 IBM InfoSphere Content Collector 与后台存储库相连，用户可以点击这些连接查看邮件及附件的原貌。

打开 FileNet Content Engine 的管理工具，我们可以看到样本邮件已经根据单实例模型进行存储。如图 5 所示：

样本邮件已经被生成 ICCMail Class 的一个实例，即 DEI 的一个实例。其中 ICCMailInstanceReference 属性可以连接到对应生成的 ICCMailInstance 的实例，即 EI 的实例，从图 5 我们可以看到，生成了一个 EI 的实例。对于 ICCMailSearchReference 的属性，它可以直接连接到 ICCMailSearch 的实例，即 XIT 的实例，如图 6 所示。XIT 实例的 Content Element 就是由样本邮件中抽取出来的所有内容构建成的 XML 文件。

XML 文件的内容如图 7 所示：

可以看到 XML 文件中不仅包括了归档时间，接收时间，收件人，发件人等普通属性，还包括邮件的标题，邮件文本内容和附件的内容，由于附件的内容篇幅太长，没有展开。此外还有两个重要的信息需要说明，第一个是 <icc_item_id>，这个 ID 本身就是邮件归档后对应 DEI 实例的 ID，正如前面所讲，当用户进行全文检索时，首先搜索到的是下面的 XML 文件，然后再通过 XML 文件里 <icc_item_id> 的内容，找到真正归档后的邮件。另一个是 <icc_mailbox_id>，即用户的邮箱 ID，通过这个 ID，可以对归档的邮件进行一定得权限管理。由于一个 FileNet P8 CE 的 object store 里会存储很多用户归档后的邮件，为了保证某个用户只能检索到自己归档的邮件，搜索引擎在检索时会根据 mailbox id 进行过滤。这样用户只能看到自己的邮件，而看不到其它用户的邮件，当然对于负责审计工作的高级用户而言，可以屏蔽此过滤条件，也就可以搜索所有用户的邮件了。

到此，user2 的归档流程就分析完了。

假如，user3 也想把自己邮箱里的那份样本邮件归档，通过 IBM InfoSphere Content Collector 的菜单归档后，归档引擎会检测到此邮件是一份重复邮件，因为 CE 的 object store 里已经归档了一封内容相同的邮件。这样，此邮件会被认作重复邮件进行归档处理。根据上面的 Task Route，重复的邮件会走右边的分支路径，根据邮件的单实例模型，重复的邮件会生产一个对应的 EI 实例，不会再次生成 DEI 的实例，而是会和早前归档的邮件共享 DEI，如图 8 所示：

所不同的是，此时 ICCMailInstanceReference 会有两个值，代表两个 EI 的实例。即归档了两封内容相同的邮件。与此同时，XIT 的内容会被更新，追加归档重复邮件的用户 ID，即 user3 的 ID，如图 9 所示：

这样，user3 在检索邮件时，也满足邮箱 ID 的过滤条件，所以 user3 也可以检索到此封邮件。由于 xml 文件包括了 user2 和 user3 的邮箱 ID，在搜索引擎看来，这封邮件同时隶属于 user2 和 user3。检索邮件时，搜索引擎只会将用户自己的邮箱 ID 作为过滤条件，所以多个用户之间没有操作上的冲突。

回页首

结束语

IBM InfoSphere Content Collector 的邮件单实例归档在不影响用户使用的前提下，做到的了最大空间的节省。有利于企业节省在存储设备上的开支，提高企业对海量邮件的管理品质。

参考资料

• 通过 developerWorks Information Management 专区：在这里可以学到更多关于 Information Management 的知识。还可以找到技术文档、how-to 文章、培训、下载、产品信息等。
  
  
• 通过 Information Management 专区 ECM 专题，了解更多有关 ECM 及 FileNet 的产品和技术资源。
  
  
• 参考 InfoSphere Content Collector for Email, 了解 Content Collector for Email 的详细内容。
  
  
• 参考 Content Collector 技术文档,检索 Content Collector 的技术文档。
  
  

• 使用可直接从 developerWorks 下载的 IBM 信息管理试用软件 构建您的开发项目。
  
  

• 参与 developerWorks blogs 并加入 developerWorks 社区。

关于作者

		迟明群，现为 IBM CDL 负责 IBM InfoSphere Content Collector 系统测试的软件工程师。2008 年毕业于北京邮电大学计算机应用专业，获硕士学位。

对本文的评价

太差！ (1) 需提高 (2) 一般；尚可 (3) 好文章 (4) 真棒！(5) 建议？