长久以来，系统互联互通似乎永远是一个热点话题，从第六届广州DDMN上我们开始谈论互联互通，直到今年第九届DDMN它依然是大家关注的话题。之前我们重点谈的是互联技术本身，也谈过在互联过程中标准的建设和规划，还谈到了业务整合过程中如SOA、ESB和EMB的概念，以及构建全台互联平台等话题。那么，这些实际上都是谈一种互联的技术和一种互联的架构。与以前不同的是，今天我们从电视台实际的需求出发，讨论在电视台不同的系统构建环境下，在不同的业务需求模式下，互联技术方案的选择。
互联架构与相关技术回顾
在广电总局制定的《电视台数字化网络化建设白皮书》中，给互联定义了一些相关的技术体系，系统互联包括网络、数据、信息、应用四个层次。
互联技术总体上分成三个方面的内容：首先是元数据和指令信息的交互。类似于我们日常打电话、发短信的方式，包括同步组件的调用模式、异步文件交互模式、基于消息中心完成多系统信息交互、通过ESB实现服务路由与中转、基于BPEL流程引擎的跨系统信息交互；其次是媒体数据文件交互，包括基于点对点的数据传输模式、通过EMB构建全台数据文件传输中心；第三是互联相关规范的建立，包括媒体文件格式规范、资源交互协议、服务的抽象与封装规范。
互联设计中的典型场景
针对目前电视台对互联的需求，我们总结了三种典型的需求场景，即现有系统改造、新建核心系统和全台系统设计，对于大多数用户来说，这三种典型的互联设计场景基本可以覆盖各种需求。
场景一：现有系统改造
举个例子，某电视台已经构建了一个媒资系统，也有一个传统的硬盘播出系统，考虑将两个系统的中间环节打通，实现资源共享，提高综合效率，是我们互联设计的初衷。
我们对这种场景进行分析，将一个现有的媒资系统或者一个现有的播出系统联通起来，更多考虑媒资备播的场景设计和播后节目归档需求场景设计；按传统的业务流程，总编室将相应的节目资源准备好，这个资源通常指的是介质，比如录像带等等，然后送到播出进行上载后完成硬盘播出。对于媒资和播出的互联来说，我们首先要打通的第一个关键环节，就是如何让媒资系统的资源能够有效地服务于播出，一旦播出后，媒资系统可以获得播出的相关信息。由媒资系统内部完成资源性质的转变，比如从一个备播节目，或者未播的成品节目，转化为已播的归档节目。
在设计中，还有几点要考虑的，就是需要尽量减小播出系统的改动量，同时还要考虑改造后播出系统的安全性，以及磁带模式备份，即文件化备播和传统介质上载播出相结合的方式。
场景范例：媒资与播出系统的互联改造
在这个图例上，淡黄色区域是改造过程中需要引入的一些环节，或者引入的一些软件和硬件设备。这里我们可以看到，工作模式实际上是播出占主导，播出根据节目单编排，在节目编排的时候可以通过媒资提供相应的资源查询组件，来进行媒资资源和播出待播节目素材的匹配，匹配完毕后，系统会向媒资系统发出相应的备播调度请求。
对媒资系统来说，实际上是内部对请求进行处理，处理之后将数据准备好，并通过新增的接口反馈相关信息，然后由播出系统将数据取走。在这个案例里，我们可以看到播出的核心架构实际上并没有发生改变，主要增加的是一个传输的执行端。
这个方案的设计要点主要体现在几个方面：首先我们要保持原有系统的功能、流程、业务的正常运转，也就是说这种改造不是一种颠覆性的重建，是关键环节的打通；另外，还要确保系统之间的耦合度足够松散，通常我们面对的是异构改造，因此选择技术方案的时候，要采用一种最小化的改造原则。
针对上面的这个改造案例，其实还有很多种方法和技术实现方案，时间关系，不能一一例举并分析，不过在这样的场景需求下，大的设计原则基本类似，方案选择的要点则主要集中在交互业务模型的设计上。
场景二：新建核心系统
许多电视台都提出过这样的需求：构建一个媒资系统，将台里的多个制播域连接起来，一方面媒资系统的构建是为了更好的服务于制作；另一方面，媒资的构建将制播域连通起来，比如说将苹果制作网、大洋制作网，可能还有其他公司的制作网。因此，在这种改造环境下，要求能够支持多种接入模式。
举例来说，如新建一个媒资系统，原来会有新闻制播区、综合节目制播区，可能还有收录系统、播出系统等等。那么这些业务系统相对来说是一个个独立的岛屿，我们考虑新建的媒资系统要面对全台提供一个资源存储管理平台。构建这个核心系统平台的同时，把已有的系统和这个核心系统平台关联起来，形成一个完整的业务链（制播存）。
场景范例：新建媒资系统完成与各制作域的互联设计
上图是一个场景方案结构范例。淡黄色区域为新构建的核心媒资存储平台以及原有各制作系统为实现接入进行的适配性改造。此方案中包含制作岛A和制作岛B，两个不同的制作系统会有相应的客户端和应用服务。当内部独立时，制作A或B自成一个系统进行运转。
此时构建一个媒资核心系统，支持各种各样的制作环境将它们通过统一的接入平台实现多系统互联。这个改造方案和第一个改造方案有明显的区别就是在方案中设计了一个互联平台。为什么我们会设计这个互联平台？实际上设计互联平台的主要目的是实现一个中转机制。在这个互联模式下，我们看出制作A与媒资系统互联交互模式，在互联平台里通过ESB和EMB实现媒体信息的交互中转。对于制作B而言，与制作A存在一定的区别，B系统相对来说是一个较为封闭的系统，难以实现制作A与媒资系统的互联模式，因此可以设计采用导入和导入工作站的方式实现与媒资系统的松散联通。整个信息的交互没有直接挂钩，即制作A是交互下的系统互联，制作B是一种单向方式的互联。
这种互联设计要点有五条，第一，分析全台资源存管需求，制定资源存储规范；第二，媒资系统基于SOA体系结构，面向全台各业务系统设计媒资服务体系；第三，设计多种互联模式，便于现有各种类型系统的接入与改造；第四，确保各制作系统完整，进行最小化改造；第五，充分考虑开放性和扩展性，便于后续扩展。
场景三：全台系统重新构架
第三个典型的场景是一个全台系统的重新构建。比如全台网的构建，或者新大楼的构建，那么这种设计需求，表面上来看似乎是整个重新规划，类似于一张白纸一样，但实际上我们要考虑的远远比一张白纸要复杂得多。因为任何一个电视台，目前的系统、流程的积累、管理模式等，所有这一切都是需要在全台网系统构建时考虑的一些问题。
这个范例也是目前行业内提出需求比较多的，即新建一个全台网系统，实现资源的业务整合。我们重点要考虑采集收录域、编辑制作域、存储归档域、播出控制域和生产管理域五个方面的整合规划。在设计要求上，按照新规划的工艺流程实现全台系统互联；建立全台互联的相关规范和标准；建立一个灵活、规范和可扩展的全台互联，也是这个系统下需要考虑的重点。
场景范例：CCTV新台全台互联架构模型
这个系统互联场景图是CCTV新台的全台互联架构的模型。内容比较全，所以看起来有些复杂。在上面的系统里包括新闻系统、综合制作的多个制作域、演播室、广告系统、审片系统和播出系统；下面是新规划的媒资系统，还有已有的资料馆系统；中间是ESB、EMB平台。可以看出，除了播出外，大部分系统都是直接通过EMB互联平台进行构建，对于播出系统的交互是通过与媒资系统之间建立备播数据的连通。
中央电视台现在老台的系统，包括现址的制作、播出系统，在中央电视台全台架构的模型之下，新址系统和现址系统是连通的，其他的各个制作域是通过现址SATA系统实现互联。整个新址的制作域与媒资