安徽台全台互联方案的设计和标准协议的制定.docx
《安徽台全台互联方案的设计和标准协议的制定.docx》由会员分享，可在线阅读，更多相关《安徽台全台互联方案的设计和标准协议的制定.docx（26页珍藏版）》请在冰点文库上搜索。
安徽台全台互联方案的设计和标准协议的制定
安徽台全台互联方案的设计和标准协议的制定
一.前言
目前国内各电视台都拥有了一定数量的数字化制播系统，也有一些电视台建设了媒体资产管理系统，但大多属于独立运行或局部联通的状态，在2005年业内提出了电视台制播存管业务的全程文件化，这也是电视台数字化信息化建设的一个发展方向。
数字化提高节目制作质量，网络化提高节目制作效率；但目前业内网络化信息化的建设还存在很多问题，中央电视台宋宜纯副总工曾经用“小、多、专、独”四个字来形容目前行业内系统的建设状况，规模小、数量多、功能专、系统独立。
这四个字是非常形象的，系统整合也成为2006年业内技术人员面临的一个热点问题。
安徽电视台与大洋公司合作针对安徽台全台系统进行了规划和设计，其中异构的系统互联设计是针对系统整合的一个非常重要的技术内容。
异构系统互联互通的设计会涉及到网络架构，交互协议以及媒体数据资源格式等多种技术问题，本文将针对安徽台在实现异构互联设计方案以及交互协议这一热点话题展开讨论。
二.安徽台互联方案的设计和技术要点
1.异构互联设计的三个技术要点
系统互联方案设计需要解决的重点问题在于实现系统之间信息和数据的交互，通过对一些范例的分析，我们可以总结出异构系统互联设计的三个技术要点，分别是：
通讯技术、交互协议和数据对象。
（1）要点一：
系统互联的通讯技术方案
系统交互中，通讯技术方案是整个互联方案实现的基础，通讯技术方案必须能够支持包括元数据信息的交互，指令反馈信息的交互以及最终目标媒体数据的交互。
这个技术要点有些类似于人与人之间的交互手段——电话，短信，邮件，信件，包裹等等。
系统互联的通讯技术方案进一步细化又可以分为几个方面：
A.底层通讯技术的标准和协议
目前网络化技术为我们提供了各种底层的数据通讯模式以及各种标准，如RS232/422的串行通讯标准，TCP/IP的网络通讯标准，HTTP的超文本传输协议，FTP的文件传输协议，FC光纤传输协议等。
这些技术均可以用来实现系统之间的信息和数据的通讯。
B.通讯软件的实现
底层的通讯平台（如以太网，FC网，串口通讯网等）只是提供通讯链路支持，而具体数据传输需要由相应的通讯软件来完成。
这一层面也同样具有很多标准模型和接口规范，例如Socket连接，消息，Webservice等。
C.大对象数据文件的传输
目标数据传输同样需要基于通讯技术平台来实现，例如可以采用FTP服务器、以太网共享或基于SAN共享软件来实现大数据文件的传输。
（2）要点二：
系统交互协议语言
和人与人之间的交互一样，系统之间交互也要有系统能够理解并执行和处理的语言作为基础。
系统之间交互的语言我们称为协议语言，在一个简单的系统中，我们可以根据具体的需求来定义并实现。
交互协议在定义上主要应该包括两个方面的内容：
A.交互指令以及对指令的响应的定义。
这就类似于语言中的动词一样，系统交互的双方通过预先定义的指令和响应来进行交互，指令信息可以包括例如：
Insert（插入）、Delete（删除）、Update（更新）等，响应信息则可以包括例如：
Complete（完成）、Error（错误）、Ready（就绪）等。
B.数据以及相关信息的定义。
这就类似于语言中的名词一样，系统交互的双方用指令来交互彼此需要执行的功能，而用数据来描述针对完成这一指令所涉及的相关数据和参数信息。
（3）要点三：
系统交互的数据对象
数据对象是指系统在交互过程中最终的交互内容，这个数据对象可能是一个物理介质，可能是一组视音频文件，也可能是一些状态信息。
在电视台各业务系统之间进行数据交互时我们通常遇到的一个问题就是媒体数据文件的格式统一问题。
例如制作、媒资和播出三个系统之间在进行互联交互时，我们必须要考虑这三个系统的视音频文件格式以及视音频数据的编解码格式。
针对文件以及编解码格式的标准需要在系统互联的设计阶段考虑清楚，如果数据格式（包括文件格式和编解码格式两个方面）无法被对方识别，则需要在设计时增加数据转换接口，来实现对文件格式和编解码格式的转换。
而某些标准格式也是专门针对交换而制定的，例如MXF格式。
除视音频文件外，还有很多数据文件的格式目前无法形成有效的交换，例如故事板文件属于各公司的私有格式，对于这种情况，要么需要制定标准交换格式，各参与厂家都遵守，要么采用原始保存方式，由各自提交的厂家来实现对自己私有格式文件的解读。
在进行异构系统互联的设计中，以上总结的这三个技术要点是任何系统都无法回避的，本文将从通讯技术方案以及制定一个开放通用的系统互联协议两个要点来进行更为细致的论述，至于数据格式的问题，目前也有很多案例可供参考，我们将会在另外的文章中单独论述。
2.对信息交互和媒体数据交互的分析
在传统的IT领域，系统之间的交互通道往往信息和数据是一体的，这样系统的处理逻辑和网络架构都可以大大简化，而在广电领域，由于大对象媒体文件的存在，这种交互模式的处理效率和安全性存在很大的问题，因此系统在交互过程中，无论网络平台如何，媒体数据和元数据一定是通过不同的交互通道完成系统交互的，如下图所示：
下面我们分别就控制信息交互技术方案和媒体数据交互技术方案进行一个简单的论述。
（1）元数据信息和控制信息的交互
元数据和控制信息主要指系统间交互时的一些指令、响应、状态、描述元数据（如节目名称，代码，格式）等，这些信息最大的特点在于数据量小，属于结构化数据范畴。
目前这部分信息的交互从交互的模式上可以分为同步和异步两种交互模式：
同步交互：
有些类似于我们打电话，即请求和答复属于同步发生且双方都以阻塞方式进行通讯，如果一方没有就绪则通讯无法完成。
异步交互：
有些类似于我们发短信，即请求和答复属于异步发生，交互双方都以非阻塞方式进行通讯，任何一方都只和消息中心建立联系，一旦发送（或接收）完成，则立即可以进行其他的工作。
同步和异步两种通讯模式各有优缺点，就好比打电话和发短信。
同步方式最大的优点在于能够立即得到对方的响应，因此在一些同步性强，信息处理时间短的交互中较为常用，但同步方式对系统之间的关联度要求高，一旦对方系统出现问题，则交互无法成功。
异步方式最大的优点在于异步处理，因此可以使得系统之间的关联度很低，耦合度更加松散，尤其在一些需要长时间处理或人工干预的任务通知方面，异步通讯更具有优势。
但异步方式对一些要求立即响应的交互则不太适合。
从目前的各种技术手段和已经实现的案例来看，系统之间进行元数据和控制信息的交互有三种主流的技术实现手段：
A.基于TCP/IP通讯完成信息交互，如下图所示：
系统A和系统B通过底层的TCP/IP通讯模块进行信息的交互，所有通讯逻辑（收发逻辑）均通过软件实现，这种方式在系统内部的通讯以及紧密耦合的系统中常用，最大的特点在于这种通讯方式非常灵活，各种通讯控制逻辑完全由开发者掌控，无论同步或异步均可以实现。
但开发量较大，且AB两个系统耦合非常紧密，不同公司的产品难以实现。
B.基于消息（Message）的通讯交互，如下图所示：
系统A和系统B通过消息API与公共消息队列接口，用来发送和订阅消息，所有底层通讯逻辑通过调用第三方软件接口实现，公共消息队列类似于一个邮局，整个通讯模式属于异步通讯，最大的好处在于松散耦合，安全性较高。
C.基于Webservice的通讯交互，如下图所示：
Webservice的接口方式是目前IT行业系统整合采用的比较普遍的系统交互通讯技术方案，Webservice组件的调用也可以看作是远程同步调用，并通过HTTP协议和封装SOAP协议实现信息和元数据的交互。
Webservice属于典型的同步交互模式，基于HTTP协议可以穿越防火墙，安全性较高，但通讯效率稍低。
（2）媒体数据的交互
上面分析了元数据信息和控制信息的交互，而广电领域系统交互一个最大的特点就在于大对象媒体数据的交互，基于上面的分析，基本上我们不会考虑通过以上的三种方式来进行媒体数据文件的交互（即TCP/IP，消息和Webservice），而媒体数据交互目前业内比较流行的有两个方案。
A.SAN文件共享方式，如下图所示：
系统A，B，C三个SAN系统通过FC路由器联通，但考虑到安全因素，系统之间无法直接访问，但三个系统均可以向数据处理中心开放，因此系统之间的数据传输由这个数据处理中心承担。
SAN共享方式实现媒体数据交互最大的优点在于带宽高，但由于是FC互联，因此成本较高，且系统数据的安全性较差。
B.FTP文件传输模式，如下图所示
系统A和系统B通过FTP客户端/服务器进行以太网连接，并通过FTP协议实现大对象数据的交互，而系统内部则可以采用带宽较高的FC连接。
FTP模式最大的优点在于单网连接因此成本较低，而且系统的集成难度以及系统的数据安全性都会较高，但传输效率和带宽比SAN共享模式要低很多。
在本文中，针对安徽台的全台互联设计，重点就以上三个技术要点的前两点进行阐述和说明。
3.安徽台系统互联设计方案
（1）互联技术方案模型
根据安徽台全台工艺系统设计方案书，安徽台面向异构系统互联交换的技术架构采用消息+Webservice模式。
在各制作域、媒资以及播出域等各工艺系统之间的交互采用消息的异步通讯模式，而各工艺系统和节目综合信息管理系统的信息交互则采用Webservice的同步远程调用模式。
具体方案的逻辑模型如下图所示：
（2）方案说明
在上述的模型架构中，A系统、B系统分别表示电视台各制作域、媒资以及播出等核心业务系统，综合信息管理系统则主要承担节目的生产管理，并贯穿节目在生产过程的全流程监控和管理。
各核心业务系统在交互中，交互内容主要包括元数据信息，通知信息以及媒体数据文件（或与媒体数据文件相关的附属文件，如文稿，串联单等），每个核心业务系统均需要与负责节目生产管理的综合信息系统进行交互，交互的内容主要包括节目的信息和状态等元数据信息。
在上图所示的交互模型中，三种线型表示了三种不同的信息流，分别是：
A.蓝色细线：
基于消息的信息流，采用异步方式进行发送和接收，通过建立企业级消息中心（企业级信息服务总线ESB），可以实现发布，订阅，广播等多种信息交互模式。
B.黑色粗线：
基于HTTP协议的Webservice远程调用信息包，采用Webservice接口规范，通过应用服务器（基于HTTP协议）并符合SOAP协议实现的远程同步调用，通过此接口模式可以实现各业务子系统与节目生产管理系统之间的信息和状态的交互。
C.红色粗线：
基于大数据对象的FTP数据流，采用以太网络实现异构系统之间的大数据传输，并在传输过程中进行相应的转换和验证等操作。
（3）设计思路说明
安徽台全台系统是由若干个生产工艺子系统和一个综合信息管理系统构成，且整个全台系统为多厂家承担开发和集成，在信息和数据的交互需求上分析，各生产工艺子系统之间的交互大多需要进行媒体数据的传输和转换，而各工艺子系统与综合信息系统之间的交互主要是元数据和状态的交互。
因此我们在设计上也将系统互联交互分为这么两个层面。
A.对于各工艺子系统之间的交互：
这部分的互联交换是我们设计的一个重点，安徽台全台工艺子系统包括2个新闻网，1个后期制作网，1个收录中心，1个媒体资产管理系统，1个播出系统以及若干演播室和广告、电视剧制作子网构成，考虑到以下三个因素，我们在设计中采用基于消息+FTP的系统互联架构。
a.各工艺子系统的交互大多包含媒体数据的传输，因此从通讯的角度，异步处理模式更加通讯需求；
b.由于整个系统由多厂家产品互联，因此选择更加松散的通讯耦合方式是我们设计上首要考虑的问题；
c.基于消息中心的星形互联架构便于系统的扩展，同时通过定义互联协议标准，规范各厂家的接口，使得系统未来的扩展和升级更加规范和简便；
d.各工艺系统之间的媒体数据交互采用点对点的FTP架构是由于考虑单网互联的优势以及数据安全，而点对点的数据传输是基于效率的出发点设计的；
B.对于各工艺子系统与综合信息系统之间的交互：
安徽台的综合信息管理系统在设计中主要起到一个对整个节目生命周期的状态监控和管理，从节目的策划、选题、制作、审核、播出到节目的归档存储，因此综合信息管理系统几乎需要和每个工艺子系统进行接口，在设计中主要基于以下几个思路考虑：
a.各工艺子系统和综合信息管理系统之间的信息交互大多属于元数据和状态信息数据，这种需求同步的通讯模式更加适合；
b.整个综合信息管理系统在设计上基于SOA（面向服务的体系架构）架构设计，因此各种数据请求和提交封装为可重用的服务，这样，综合信息系统可以随着后续需求的明确而逐步完善。
c.从数据交互传输的安全性考虑，各工艺系统在一个安全级别，而综合信息系统由于需要和办公网甚至Internet联通，因此采用Webservice模式可以在工艺系统与综合信息系统之间安装防火墙，而无须为系统信息交互单独开辟通讯端口，系统信息安全得以保证；
（4）典型互联用例分析
A.抽象系统交互模型
根据实际的业务需求分析，安徽台全台系统包括收录，各节目制作域子系统，媒体资产管理，播出等，在系统信息和数据交互中可以抽象为两种交互模型，分别是：
数据推送模型和数据提取模型。
a.数据推送交互模型：
该模型特点在于发送方获取对方的数据请求后，首先向接收方发送资源请求信息，在获得反馈后采用推送的方式将数据以及元数据信息发送给接收方，发送方主动推送，接收方被动接受。
数据推送模型总结来说有如下技术要点：
•整个交互业务逻辑由发送方发起（SystemA）；
•数据传输方式发送方为Client，接收方为Server，即采用“Write”的方式；
•发送方可以根据目标参数进行相应的数据转换处理；
•接收方在接收到“验证申请”后，标志所有数据和元数据信息已经发送完毕；
具体的抽象交互模型如下图所示：
b.数据提取交互模型：
该模型特点在于发送方获取对方数据请求后，进行内部数据准备，并在准备就绪后，向接收方发送详细的资源参数信息，接受方获取后根据信息内容采用提取的模式获取媒体数据，发送方准备完成后告知接收方，由接收方主动提取。
数据提取模型主要有以下技术要点：
•整个交互逻辑依然由发送方发起（SystemA）；
•发送方（SystemA）在得到数据请求后（可以通过BS的检索来实现数据请求的提交），内部进行数据准备，并在数据准备就绪后，将所有数据信息以及传输资源参数信息发送给接收方（SystemB）；
•数据传输的实现发送方（SystemA）是被动的Server模式，而接收方（SystemB）则是Client模式，即数据的传输采用“Read”的方式；
•接收方可以根据数据传送请求信息获取数据源信息，并根据自己系统的情况来进行数据的转换及传输工作；
•接收方获取完成数据后，发送反馈信息给发送方；
具体抽象的业务模型如下图所示：
B.针对业务系统交互的典型设计范例
针对上面的这两个抽象的数据交互模型，我们通过收录中心与各业务系统的数据交互以及制作域各系统归档媒资这两个典型业务进行范例分析和说明。
a.收录中心与制作域以及媒资系统的交互
安徽台对收录系统的设计采用建立全台统一收录中心系统的设计思路，因此收录系统需要和各制作域子系统以及媒资系统均有较多的交互应用。
在本设计方案中，主要技术要点包括如下几点内容：
（a）收录系统提供内部编单软件，同时也能够提供基于BS的收录申请软件，各频道栏目的制作人员可以通过BS方式在网上提交收录请求；
（b）由于收录系统对所有其他各业务系统之间均属于单向（或单向为主，即收录To其他各业务子系统）的交互模式，因此在设计中，收录中心采用被动模式更为合理，在交互模型上属于第二种用例模型即数据提取模式；
（c）收录系统和其他各业务系统的数据传输均采用单网的FTP模式；
具体实现的逻辑模型如下图所示：
在上图的业务交互模型中，采用的“数据提取”用例模型，并形成系统的两个关键交互信息：
SL_Msg01和SL_Msg02。
（注意：
其他一些诸如进度通知等信息暂时忽略，这两个信息是系统交互的关键信息），下面分别分析这两个信息的组成。
•SL_Msg01
消息名称：
收录完成，请求提取数据的通知消息。
消息说明：
业务人员通过收录系统提供的BS收录申请软件提交收录请求，一旦被确认后，收录系统在完成该收录任务后，会根据收录申请向申请系统发送收录完成通知。
消息主要参数：
在这个通知消息中，主要应该包括：
申请者信息、收录对象资源ID、名称、格式，相关文件等资源信息，以及收录任务的完成信息，如时间，任务代码等。
•SL_Msg02
消息名称：
收录节目或素材传输完成后的反馈通知消息。
消息说明：
业务系统在获取收录系统发送的传输请求消息后，根据消息内容进行内部处理，并通过FTPClient获取收录的节目及素材，并在全部完成并验证后，生成反馈消息，发送给收录系统。
该消息是SL_Msg01的反馈信息。
消息主要参数：
在这个通知消息中，主要应该包括：
传输的资源对象标识信息，传输完成结果，如果有错误则需要发送详细的错误描述信息以及相应的时间戳。
b.各制作域系统归档媒资系统
安徽台全台系统的规划，媒资系统主要承担三个方面的工作，一是作为各个业务系统存储的二级存储库，可以对新闻、制作等系统提供节目和素材的存储支持；二是作为播出的成品节目存储库，直接支持文件化播出，减少磁带上载的模式；三是支持总编室业务，并可以支持电影电视剧类节目的简单制作以及上载。
针对设计思路，媒资系统在和各业务系统交互中主要包括了两个业务模型，一是各业务系统存储归档到媒资，包括素材和成品节目，二是各业务系统从媒资进行素材或节目的回调。
归档媒资系统的业务模型在设计中有如下的技术要点：
（a）各业务子系统完成素材和节目的制作加工过程，并主动发起“入库”请求；
（b）媒资系统收到入库申请后根据入库申请信息分配相应的存储资源并反馈给各业务子系统；
（c）各业务子系统采用FTPWrite的方式，将数据推送到媒资系统指定的存储资源中；
具体逻辑模型如下图所示：
在各业务系统归档媒资业务模型中，根据模型图示，我们可以提取4个系统交互中的信息包：
•RK_Msg01
消息名称：
成品节目/素材入库申请消息。
消息说明：
业务人员通过在完成节目制作后，可以将成品节目（素材也可以）提交入库媒资系统，在提交入库前，成品节目的政审，技审等验证工作由各业务子系统来完成，媒资系统收到请求后对请求进行检查并进行存储资源的分配。
消息主要参数：
在这个请求消息中，主要应该包括：
申请者信息、入库对象资源标识信息如节目ID、节目名称，所属栏目等，以及入库的一些操作信息，如时间，任务代码等。
•RK_Msg02/RK_Msg03
消息名称：
入库申请资源分配及反馈信息；
消息说明：
媒资系统收到Msg01（入库资源申请信息）后，根据入库申请中的资源标识，资源属性以及资源所属的频道栏目信息和申请方信息，进行存储资源的自动分配，并将分配好的资源信息填充到Msg01资源对象的数据结构中，如：
FTP路径，服务器，要求入库的文件格式信息等。
并将信息重新生成后，反馈给发送请求的各业务子系统。
消息主要参数：
在这个消息中，主要应该包括：
对申请的反馈状态，如通过或错误等，另外需要包括入库资源的分配信息，如FTP路径，服务器信息等。
如果入库不合法，则需要发送相应的错误信息。
•RK_Msg04
消息名称：
成品节目/素材入库完成，请求验证消息。
消息说明：
业务子系统发出资源请求消息并获得反馈后，根据反馈信息执行相应的数据传输和转换操作，完成后，生成详细的资源信息消息并发送给媒资系统，通知媒资数据传输完成，可以进行数据验证。
消息主要参数：
在这个请求消息中，主要应该包括：
入库对象资源的全部详细的元数据信息，如节目ID，名称，所有元数据信息，文件信息，格式信息等，以及入库传输的的一些操作信息，如时间，任务代码等。
•RK_Msg05
消息名称：
入库数据验证反馈信息；
消息说明：
媒资系统收到Msg04（入库数据验证信息）后，根据入库验证信息的详细内容，对接收到的数据进行验证（例如MD5验证），并根据验证结果，生成一个反馈信息发送给提交的业务系统。
消息主要参数：
在这个消息中，主要应该包括：
对申请的反馈状态，如通过或错误等。
如果入库验证不通过，则需要发送相应的错误信息。
（5）安徽台互联设计总结
结合上面的分析以及设计说明，安徽台基于全台互联的技术方案架构具有如下的几个特点：
A.建立消息中心为全台提供消息通讯服务并建立企业信息服务总线；
B.各生产工艺子系统之间采用异步的消息机制实现元数据信息和控制信息的交互；
C.各生产工艺子系统之间采用点对点的方式实现媒体数据的交互；
D.媒体数据传输采用以太网的单网架构，基于FTP模式；
E.通过制定统一的协议标准来实现各工艺子系统之间的信息交互，因此每个工艺子系统在对外交互的接口实现上必须符合安徽台互联交换协议规范；
F.节目综合信息管理系统在设计上采用SOA架构，并提供Webservice组件实现与各生产工艺系统的接口；
G.元数据+媒体数据交互采用异步通讯模式，状态等信息数据交互采用Webservice的远程同步调用接口模式；
三.安徽台互联交换协议
系统互联的设计除技术方案外，协议的制定非常重要。
协议本身的制定可以基于具体的业务需求由协议适用的双方进行约定，因此协议本身没有对错之分，任何协议只要能够满足互联双方的通讯和信息交换需求就都是正确的，但对于安徽台全台设计而言，针对每个子系统之间的交互均各自约定交互协议肯定是不现实的，而基于各工艺系统互联交互的特点制定一个统一的协议标准则是面向全台互联交换设计的目标。
1.协议的概念、目的和作用
2.概念、要素
系统互联协议通俗的理解类似于人与人之间沟通所使用的语言，协议只是计算机系统能够理解的语言。
简单的点对点系统交互的实现，可以根据交互的内容来制定最简单的协议。
我们通过一个人与人之间交互的句子来分析协议所需要包含的基本要素：
张三和李四分别是电视台的记者和库房管理员，张三需要A节目磁带，打电话通知李四说：
“李四，请你给我3月10日的A节目的播出磁带”。
从这个例子中，我们可以假设张三和李四分别为两个计算机系统，那么协议在定义上可以总结出一些基本要素：
（1）交互双方的标识信息，例如谁发送，谁接收等；
（2）对信息和数据的描述，例如节目名称，代码，时间信息等，也可以是对各种状态信息的描述；
（3）对请求动作指令的描述，对应上面的例子就是动词“给”。
3.制定标准协议的目的和作用
针对点对点的简单互联而言，可以根据交互的需求制定针对性的协议来实现两个系统的交互，当进行多系统异构互联的设计时，这种两两约定的方式就会存在很多问题：
（1）系统软件接口实现的复杂度大大增加，接口的定制开发程度很高，当多系统互联时会带
升级会员 