构建开放的系统互联互通平台
引言
目前，随着IT技术以及数字化存储技术的不断发展，电视台各个业务系统从传统模式向数字化，网络化发展也越来越快，而针对目前电视台业务数字化网络化的总体解决方案，提出全程文件化目的是为了让电视台业务系统在效率，管理，资源共享与交换等方面更进一步。
从总体上看，业务系统的全程文件化主要体现在业务系统文件化和数据交换文件化两个部分。在业务系统中，目前的采、编、播、管、存等各个业务系统包括如：前期拍摄，传输、节目加工制作、全自动播出、电视台综合业务管理、媒体资产管理等等，而数据交换文件化则重点体现在跨系统的资源共享和各业务系统之间的数据交换。
全程文件化的主要障碍
1.1 目前常见的系统业务模型
上图是目前各个电视台在逐步从传统业务模式向数字化、文件化发展的很常见的业务处理模型。简单描述一下，就是节目制作人员前期拍摄生成相应的录像带，拍摄完成后到非线性制作系统进行非编制作并合成，输出最终完成的节目带后经过审批便入库管理，同时也可能直接送播出线进行播出，自动播出系统目前大多数系统还均采用重新上载的方式将经过审核的节目带数字化采集到硬盘系统，然后实现硬盘播出。而媒体资产管理系统也可以通过采集的方式对传统库房的节目带进行数字化存储及编目加工，再利用时则通过检索下载的方式输出录像带来重新利用。
1.2 传统模型的特点
根据上面的模型和描述我们可以总结出两个主要特点：
1. 各个业务系统从传统走向文件化，数字化，网络化
2. 系统之间交换的传统化，介质化
从目前电视台各个常规的业务系统而言，IT技术，网络化建设越发普及，包括非线性系统，硬盘播出系统以及媒体资产管理系统等等均能够完成系统内部的数字化文件化，对于前期拍摄而言，目前传统的录像带模式还属于主流，但随着半导体存储技术的成熟，P2类型的技术能够成为前期拍摄的主力。
但随着各个业务系统的数字化，网络化，文件化的建设，各个业务系统之间却仍然采用传统的介质交换模式，究其根本原因则不外乎方便，直接和灵活，且由于人在其中参与的成分较重，因此接口非常清晰，不用担心业务流程的改变，内容的改变，人员组织结构的改变等。
总体来说，目前电视台总体业务系统的数字化文件化建设完成了由单机到网络化建设，并逐步向全台一体化，数字化，全程文件化进行发展。
1.3 全程文件化的主要障碍
根据上面一个简单的业务模型的描述，我们也可以从中总结出针对实现整个业务系统互联互通，文件化交换的主要的一些技术障碍。
1. 业务流程多边
业务流程的变化虽然并不直接导致无法实现全程文件化的数据共享和交换，但由于传统交换人参与的成分较多，因此接口非常清晰，交换模式非常灵活，当业务模式发生改变后，对交换影响不大，而对于一个构建在IT技术的系统来说，接口更多的时候需要一些交换逻辑和交换的协议，因此当逻辑或协议发生改变时，多少会影响整个系统的正常运作，由此也表现出一个基于全程文件化系统对业务模型的灵活适配是一个非常重要的障碍点。
2. 元数据结构复杂且各系统不开放
第二个制约全程文件化的障碍关键在于元数据的交换，传统交换中将这个问题抛弃了，最多再给一张纸来写一些描述信息，但对于全程文件化的系统，元数据交换是系统数据交换的最关键点，而不同业务系统之间，不同公司开发的软件之间元数据结构是不开放的也是非常复杂的，如果在元数据层面无法达成交换的统一，则全程文件化是不现实的。而元数据又是每个业务系统最底层的内容和最核心的内容，因此通过相关的标准才能够实现系统之间的“盲连接”，即双方在未见面的情况下实现数据的互联互通。
3. 各业务系统的媒体数据格式不统一
在电视台的各个业务模型中，随着应用的不同，涉及的核心的媒体数据文件要求也不同，比如制作和播出对编码的码率及格式要求就完全不同。而目前关于视音频编解码以及文件的格式等等非常多，并随着IT技术的发展，类似的技术和格式还会更多，这些格式的不同在传统交换中是完全不存在的，如何实现全程的文件化，媒体格式的转换几乎是必须考虑的问题。
4. 其他的一些因素
除去上述的一些重点因素外，还包括例如系统数据交换带宽，效率；系统互联互通后的数据安全；用户的使用和业务习惯等等均会对实现全程文件化造成障碍，但总体来说，前三项问题是制约系统文件化交换的重点。
设计一个开放的系统互联互通平台
1.4 平台结构示意图
1.5 结构概述
上图是一个系统互联互通平台的模型，业务系统A，B，C分别代表各个业务系统，而最下方的物理存储层实际上也属于各个业务系统的一个组成部分，为了说明元数据交换以及媒体数据交换的不同路径将业务系统的物理存储单独画在结构图的下方。
中间部分则主要由三个重点地单元模块构成，其实每个模块又是一个相对独立的产品（或几个产品），这三个重点模块分别是：
交换服务引擎；
工作流引擎；
数据处理中心；
1.6 说明
1.6.1 交换服务引擎
交换服务引擎实际上设计为一个后台服务软件，并可以相应开发客户端管理和监控模块用于系统的配置和运行监控。该引擎的重点在于接收，转发，验证以及处理整个系统互联互通平台的交换任务，该引擎内部集成消息服务器，除能够完成在线的任务请求外，还可以实现离线的消息交换，确保系统的运行。
交换服务器引擎本身类似于一个基于服务的容器，包含若干接口来实现与外部系统的开放互联互通。主要包括与应用系统的插件接口规范，与数据处理平台的API接口，与工作流的标准接口等等。
除上面的一些重要设计模式外，交换引擎还内嵌一个离线消息服务器，该消息服务器可以采用第三方的软件和产品，由此便可以实现在系统数据交换中的无故障切换以及任务的离线保存等机制，使得整个交换系统更加安全可靠。
1.6.2 工作流引擎
工作流引擎在整个系统互联互通平台中并非是必不可少的服务引擎，但为了确保整个交换平台的开放性，业务逻辑的相对独立性，通过工作流引擎可以实现业务系统交换流程的分离，使得整个交换系统在组织结构改变，交换流程改变，交换方式改变以及新系统接入时，各个相关业务系统的修改会控制到最小，同时，由于业务流程逻辑的分离，也可尽量降低系统之间的逻辑耦合，提高系统的开放性。
对于工作流引擎来说，本系统规划的则通过基于工作流开发标准的引擎即可，既可以采用通用的工作流中间件，也可以采用自行开发的小规模引擎，但工作流标准中定义的接口规范必须一致，方能确保各个业务系统与工作流接口时可以实现系统的“盲接入”。
1.6.3 数据处理中心
数据处理中心是整个系统互联互通交换平台的针对媒体数据的处理及传输中心，在电视台的各个业务系统中，由于对媒体数据的使用要求不同，因此不可避免的会要求系统之间数据交换时进行相应的编解码转换，故事板打包等数据处理过程，数据处理中心主要的工作便是完成这些媒体数据的处理任务。例如通常我们了解的转码