我们通常认为内容管理系统是针对内容的一个基础平台或是集成。在内容管理系统中，素材与元数据会被采集、处理、访问、交换及播放。因此，对于访问内容的应用系统，提供一定数量的接口界面和集成选项是非常重要的。另外，一个内容管理系统通常还要协同大量现有系统组件和管理遗留内容。因而，对于一个开放的、多样化的内容管理系统来说，能够集成或是连接其他系统、系统组件以及现有的内容是极其重要的。正如我们在第6章所讨论的那样，在系统结构中可以依靠设备管理和数据管理来实现这样的功能。然而，基于交互系统层面，还必须通过其他类型的集成来提高这种交互性。
具有丰富内容的组织机构，应该能支持所有与内容相关的过程与应用。众多的系统、应用程序与应用程序组件会在内容管理系统中交互。
最底层包含属于不同系统的管理部分。通用的内容管理系统模块被标记为浅灰色，第三方系统与一般构造部分被标记为深灰色。这个例子中的第三方系统的范围，从基于产品的支持与计划工具（例如演播室自动化系统、播出推介系统、播放时间销售、节目策划）的控制系统（例如新闻工作室系统与播出时间计划）到信息系统（权限管理系统与编目系统）。它们通过一个通信中间层和应用控制设备来实现连接。这个例子表明，在一个标准播放系统环境下的多样化系统必须被集成或是连接起来，这些系统中的一部分是现存数据库与信息系统，而本文所说的内容管理系统则通过接口与连接为此提供一个集成的平台。
将作为工作流程组成部分的其他系统与具有生存周期的内容相集成，是内容管理系统的一个基本特性。本例中所提到的其他系统有新闻工作室系统、自动化系统、媒体管理系统、制作系统、非线性编辑系统、权限管理系统和企业资源计划（Enterprise Resource Planning， ERP）系统等。内容管理系统与网站和电子商务的关系也变得越来越密切。内容管理系统可以作为一个中央资源存储库，为所有这些系统提供连接，或者在同等级别的情况下，为跨系统交互作用提供连接和工作流程的支持。通过这种集成，可以进行元数据与素材拷贝的简单交换，以及对紧密集成的第三方系统中的相关信息进行直接访问。
对于建制良好的富媒体组织（例如面向公众的档案馆与广播机构），在其遗留系统中的遗留内容与信息是特别重要的。现存的内容是系统运作的重要资源，因此用内容管理系统来整合或管理现存内容是非常必要的。对这样的组织，将现有的素材转换成新的格式并对所有现存的信息进行整合，是成功地导入内容管理系统的非常重要的先决条件。
对于实际的系统设计来说，系统集成是一项并行的工作。因此，集成过程应该和实际系统的设计与实施紧密相连。系统组件在后期集成是可能的，但是应该提前做好准备，并在最初的构架及实施计划中给以充分的考虑。
8.1集成原理
一般来看，集成就是不同（可能是互相独立）的系统或是系统组件之间的组合，以求获得更加综合广泛的功能。另外，集成也是指一个系统内各种信息的整合。通过集成，系统的总体功能可以得到提升。系统集成可以被定义为：
通过有效地连接和检测系统组件来合成它们的功能与技术特性，形成一个综合的、能共同操作的系统。集成的数据系统允许存在于不同系统中的数据跨越功能和系统的边界，实现相互间的共享和访问。
这个定义既强调了系统集成的过程，也强调了其结果。这一点非常重要，但是常常被忽略，因为以往只是规定了接口而没有定义不同的集成步骤。因此，这里强调有2个方面比较重要：（1）通过集成不同系统的组件全面提升功能和特性；（2）集成的过程。与以上定义不同的是，在内容管理系统与第三方系统集成的情况下，强调个别系统组件仍然可以保持其自主性是非常重要的。它们通常在独立的模式下工作，但是在集成的情况下，也能提供一个可以无缝操作的更为综合的特性设置。集成的本质也由系统的物理定位和它们之间的通信连接来决定。即使它们之间的通信发生故障，也必须保证每个系统仍然可以独立工作，这点是很重要的。
在内容管理系统中，由于跨越系统边界的数据共享经常发生，所以数据集成是非常重要的。这种情况尤其发生在部分信息与别的系统内容相关联的时候，例如权限的相关信息被保存在一个权限管理系统中，但是必须从内容管理系统中去访问。在数据集成的情形下，我们必须考虑到信息的时效性和更新的重要性。如果信息频繁地变化，那么就必须保证被集成的信息是最新的，并能对数据进行直接访问。另一方面，如果数据是相对静态的，并且暂时的不一致性可以被接受，那么对这样的数据，仍然可以在不同的系统间进行交换，并在每个系统里做冗余存储。
8.1.1集成的类型
系统间集成的类型与深度是依据功能、特性以及不同的集成系统间的共享数据设置而变化的。此外，系统内的某个组件的作用影响着集成的种类，例如，硬件服务器或存储系统与一个新闻编辑系统的自治软件工具相比而言，前者与内容管理系统的结合要更加紧密。为了选择正确的集成模式以解决某个具体问题，考虑诸如平台的从属性和某种解决方案的花费与限制等方面因素是很重要的。因此，虽然我们有许多可行的方法以针对不同系统组件的集成，但还是定义了3种集成的基本类型，即通过数据交换的集成、通过应用程序接口的集成以及与应用组件的集成。有时候在一个集成系统中可以包含多种集成模式，例如可以用一条信息来通知另一个系统组件在某个接口处获得数据。
8.1.1.1通过数据交换的集成
采用消息和数据交换的集成是一种松散的系统合成模式。本书中使用了一组交换协议以及KLV、MOS和SOAP数据编码的标准。在低层协议中，可以使用FTP、NFS、NDCP及VACP等协议。在不同系统之间，消息可以以各自的格式编码流通。此外，普通文档传输也属于这个群体。不仅可以使用请求/响应模式，也可以将信息推送给对方。
在这种模式下，可以交换素材和元数据。在数据交换集成中，可以实现不同系统之间对数据请求的要求，各种信息可以互相传递。系统间的素材交换，依赖于这些素材的类型与格式，例如，流媒体可以通过SDI/STDI或是使用数据网络中相应的流服务器与流协议实现其流动性。以标准通信协议进行的文件传输可以用于连续与非连续媒体的交换。在这种情形下，标准的文档格式（如第5章所阐述的）具有非常重要的作用。
8.1.1.2通过应用程序接口的集成
当使用应用程序接口的时候，系统间的集成程度相对较高。一个应用程序接口可以为其他程序或子程序提供一系列的功能，包括数据库访问客户端/服务器、对等交互和事项（务）处理等。通常来说有2种应用程序接口交互的主要模式，即远程过程调用（RPC）和标准查询语言（SQL）。远程过程调用与标准查询语言的使用提供了紧密的集成。在远程过程调用的情形下，程序间的交流即通过共享缓冲器的过程或任务。在应用程序间的数据共享，通过使用标准查询语言可以实现对普通数据库的访问，这是一个非过程数据访问。使用其他方法直接通过过滤程序访问数据库也是可能的。例如，基于XML的接口可用来保持实际数据库结构的明晰，但是仍然能提供对存储数据的直接和细节的访问。
为了较少地依赖平台，并在分布的环境标准中实现运行，可以采用通用对象请求代理体系结构（CORBA）或网络服务。
8.1.1.3应用组件的集成
基于组件的应用开发技术（如OCX、ActiveX和JavaBeans）允许将不同系统中的各种应用组件集成在同一个应用框架内。对于用户来说，这种应用仿佛没有任何可视的边界。在使用消息的前提下，参数与信息可以在不同的组件之间直接通过。在这种应用框架内，每个系统用它自己的应用模式来表现。
这种集成很有吸引力，因为对用户来说，看到的是一个无缝的应用界面，而无须考虑这些信息在它们各自不同的系统中是如何表现的。然而，当不同系统中的信息必须要进行预处理时，将会有一些限制。例如，链接到某个对象的内容涉及到知识产权，虽然可以使用ActiveX来提出要求，但如果你没有权限，将实现不了访问。
8.1.2集成过程
以上定义已经表明，系统集成是一个分步骤过程，其中不同的系统组件被连接测试以求最终形成一个综合的可共同操作的系统。通常来说，涉及内容生产和管理的系统集成并不是从零开始设计的，而是在已经存在一段时间的模块基础上进行的。对于一个内容管理系统而言，集成是它的本质，所以从开始设计时就要考虑可能用于集成的接口和界面。进而在集成过程中，对整个系统架构和被集成的系统组件的功能都要给予周密的考虑。内容管理系统的集成过程可以被划分为3个主要步骤：
1.需求研究与组件分析。
2.系统与接口设计。
3.实施、测试和安装。
对于每一个步骤，应该确定各阶段的交付条件和“里程碑”来监督集成过程。依据项目的不同，可能会采取不同的方法。以下的讨论只是给出了任务大纲和每一步集成过程可能的交付条件。
8.1.2.1需求研究与组件分析
在需求研究中，我们获得了用户的需求。在这个过程中，我们分析了现存的工作步骤，包括对以下内容的识别：系统的工作流和文档、工具以及支持它们的组件。用一个相关工作流和所涉及系统的描述来记录所有的分析。
同时进行的工作还有，对所有潜在的，可能成为大系统一部分的组件和系统的评估。这包括对它们的功能、特性、接口以及集成性能的分析。在给出一个特性和接口的列表时会说明每一种选择的可能性，在这一步，可以对不同可选组件进行排序，从而说明哪些组件对某项特殊任务是最适合的。
8.1.2.2系统与接口设计
在系统设计阶段，所有系统结构都已经确定了。输入的是用户的功能请求、技术与环境参数和限制，以及财政与预算限制等。在上个阶段列出的可选择的系统组件清单也要在这个阶段加以考虑。应该选择既能最大程度地满足用户和系统的需求，又能方便地对整个构架实现集成的组件。这个步骤的结果就是通过系统的整体结构确定了不同的系统组件以及系统间的信息流。
随着组件功能和接口的明确，接下来实际的集成任务就开始了。这个阶段要决定不同的组件之间使用何种集成模式。在这个部分，我们要考虑到独立组件和整体系统的性能。为保持系统的易管理性，重要的是不应该有太多不同的协议、编码方案以及API标准。针对每个集成类型，应该有1个（至多2个）主要的标准用来指导组件接口的实施。这也是针对不同组件选择时的标准。
在功能设计规范（Functional Design Specification， FDS）中，每个组件的性能都要有明确的定义。在整个系统内容中，该规范是关于特殊系统组件功能的参考文档。另外还要有接口设计规范（Interface Design Specification， IDS），它规定了一个组件所提供的接口的类型。这些文档和整个系统结构的信息流动图表详细规定了接口的种类和交换信息的类型。但是还需要顺序图表来补充，该图表能准确地陈述产生于不同系统组件之间的事件和交互作用的顺序。
8.1.2.3实施、检测和安装
每个组件的实施都要遵照整个系统的结构、功能设计说明书、接口设计说明书和顺序图表分别进行。起始测试是分开实施的，用来校验每个组件是否能正确运行。在成功完成这个步骤以后，针对每个组件进行交互性的测试。在发生错误的情况下，我们要记录下错误的原因并且针对相应组件进行调整。这可能需要反复进行，直到不同的组件之间达到稳定。但在一个设计良好的系统中，这种反复并不一定需要很多次。
最后，将所有不同的组件在整个系统的框架下进行安装。只有那时整个系统才可以被检测和评估。理论上应该有这样一个阶段，即所有的系统能在离线状态下（例如没有被连接到基础结构的任何生产部分）进行检测。然而在已经建立的运行中，这显得有些不大可能。在这种情况下，有必要采取一种迁移战略，即通过一种逐步的方式将不同的组件导入和连接在一起。在每一个迁移步骤中通过添加新的功能，可以看到所设置的组件间的交互作用有所改变。为了避免不必要的运行中断，在系统失败的情况下，旧的系统状态仍然可以重建是非常重要的。
