假如你是一家制药企业的老总，刚刚完成一个为期5年耗资20亿美元的新药开发项目。你的未来，公司的未来，都要看这种新药能否快速地通过国家药品监督管理局的审批。新药的送审文件包含了成千上万个文档，分别来自多个研发实验室、诊所、商业系统等。任何一个文档的丢失、出错或是过时都会耽误审批时间，给公司造成上亿美元的损失。

又假如你刚刚被任命为一家综合性广告公司的CEO，该公司拥有一个广告部门、一个直接营销部门、一个公关部门、一个品牌战略部门。目前公司所处的市场不景气，你必须制定新的战略，带领公司在竞争激烈的环境中获得收入和增长。你的战略是建立在集成之上的。你想通过集成广告、品牌战略、公关、直接营销的一揽子方案来吸引新客户。这就要求将公司内的四个部门及相应的信息系统进行整合。一般这些信息系统都是各个部门自行开发的内容管理系统，保存着各部门的图像、视频、文档。

上面的这两个场景生动地展示了企业集成存储在不同内容存储器中的非结构化信息的需求。对于那个制药企业来说，它的信息有实验报告、药物的分子构成图、毒性报告、临床试验报告、配药程序等。对于那家广告公司来说，它的信息有演示材料、会议记录、高清晰图像、现场视频等多媒体内容。虽然大部分内容都是电子形式的，但实际上也只有一小部分可以通过数据库或内容管理软件进行管理；其他的都存储在共享磁盘上，或分散在员工的电脑上。

假如我们是这两家公司的CIO，我们应该怎样来解决这内容管理问题呢？有以下几种途径。

首先我们可以购买一个针对行业情况设计的企业内容管理（Enterprise Content Management，ECM）软件，并下达命令要求所有部门都将内容存储到这个系统中去。这就是人们常说的内容合并。这种方法的好处是十分明显的：那就是企业内只有单一的一个系统对内容进行配置、管理、学习。但这种方法也有自己的缺点：要将企业内所有的内容迁移到这个系统中来，这实际做起来很困难，也很花钱。内容合并的成本是很高的。它需要购买高端的硬件设备，聘请咨询顾问进行几个星期或几个月的内容清理工作，以将内容映射为单一的元数据模式。另外要找到这样一个能够处理好多种内容类型（如高清晰视频、CAD设计图）的系统也十分困难。最后，内容合并还可能成为一场无休止的战争。就算你完成了公司内部的迁移项目，但如果你们公司兼并了另一家公司，那么你就得再对新兼并进来的公司进行内容合并。而且很有可能公司所处的行业都转向另一个新的内容管理平台，这样就得再次进行内容迁移。

因此内容合并必须同实际的内容集成配合起来做。必须将一部分内容留在它目前所在的存储器中，然后直接由业务应用程序和流程通过一种合适的方式来访问它。有几种集成方法可以实现这一点。

最简单的方法是面向用户界面的集成。不同内容管理系统的用户界面可以在一个企业门户上注册，然后通过单个浏览器窗口对它们进行访问。门户软件通常能够实现用户单点登录和用户界面定制。如果所有的内容管理软件都有网络用户界面的话，那么就能轻松实施这个解决方法。

但不幸的是，面向用户界面的集成只能带来有限的收益。它提高了员工的工作效率，但却不能提供对公司所有内容的搜索，也无法对所有内容进行管理，无法保证内容的一致安全性。它也忽略了业务应用程序对企业内容的程序性访问要求。

面向应用程序接口（API）的集成是另一种候选方案。这种方法是将多个内容管理系统的元数据及内容访问API映射到一个单一的内容管理系统或内容集成平台上，它在某个内容管理平台/应用服务器平台占主导地位时比较有效。

如果公司大部分内容都存储在一个文件管理系统中，那么只需要开发一些接口将其他内容管理系统与该文件管理系统连接起来。同样的，如果公司所有的应用都在J2EE平台上运行，那么只需要为内容管理系统开发基于JSR 170的接口。业务应用程序可以通过这些接口来访问内容管理系统。许多内容管理系统都带有符合JSR 170的Java API，这在很大程度上能够简化面向API的集成。

面向API的集成方法能够帮助企业将新兼并的或较小的内容管理系统集成到占主导地位的内容平台中来。它允许内容平台的逐渐扩展。它还采用了所谓的平台锁定，如果你是根据Java API标准来开发接口的，那么访问.NET或C++编写的应用程序中的内容时就会出现问题。另外，如果公司选定了合适的内容集成平台，那么还必须保证工作流引擎足以负担公司内所有流程的编制。

最后一种方法是SOA，这是基于分布式服务和Web Services的集成。主要就是实现各个内容管理系统中内容和管理功能的可视化。这种方法通过一系列的XML API将各个内容系统连接起来，多种平台和编程语言都能够通过网络调用这些API。

内容系统的管理功能（如备份）可以通过SOAP集成，并发布在标准的UDDI目录中。这样，任何服务驱动的应用程序或业务流程都可以发现和使用这一管理功能了。在企业内实施信息生命周期管理也变成小事一桩了。

同样的，SOAP也能够集成各个内容系统的搜索功能，并发布在标准的UDDI目录中。然后就能直接开发搜索集成服务了。这样的服务能够动态识别目录中的搜索服务，然后并行调用这些服务对整个公司的内容进行搜索，最后将搜索结果整合起来。集成搜索服务能够用任何语言编写，而且能够在所有平台上运行，不管是J2EE还是.NET。

理想情况下，还必须使用XML集成个人的内容，为每项内容分配唯一标识，并将它们登记在内容目录中。目录可以用来对内容进行分类，还可以识别和发现存储在各个孤立系统中的内容。目录采用了内容和应用程序之间的松散耦合。应用程序在访问某项内容之前，可以先查看一下目录，然后动态获得最近的或最新的拷贝。最后，目录可以将低层内容元素抽取出来，组合成高层内容元素。这样就可以将分散在企业各个内容系统中内容元素组合起来，建立综合文档。

面向服务的内容集成是一种开放的、基于标准的方法。使用这种方法的内容集成方案能够使用Web Services标准中预定义的服务，如基于BPEL的流程编制、基于WS-Security的单点登录、基于WS-Eventing的分布式事件管理等。这样的解决方案还能够保证分散在公司内的非结构化信息能够为各种应用程序和流程所访问。

虽然这种方法有很多优点，但还无法推广使用。因为虽然基于标准的服务可视化已经实现了，但内容可视化标准还没有。虽然服务识别、服务组合有很多标准，但内容的识别、组合还没有统一的标准。所以现在实施面向服务的内容集成，还是需要使用一些接口来实现内容可视化和内容管理。

总结

企业内容集成是一项新的紧迫任务。如果你是一位正为内容集成烦恼的CIO，那么有几种方法可以解决你的烦恼：面向用户界面的集成，面向API的集成，和面向服务的集成。这几种方法都有自己的优缺点，必须仔细地对它们进行分析，选择适合自己企业的方法。