张 敏，赵 英，关俊玲，兰建龙

（1.四川大学 公共管理学院，四川 成都 610064；2.四川农业大学 商学院，四川 成都 611830）

信息时代的广播电视媒体对计算机技术应用提出越来越高的要求，处于核心业务支持地位的新闻制作、播出等管理系统必须能够对新业务和新技术提供支持，不断地扩展其业务服务形式，从业务上支持需求的多样性，更多地满足人们个性化的需求。新闻综合业务管理系统主要是立足于新闻网络制播的业务管理，涵盖了新闻前期的信息采集和通稿制作管理、业务管理和数据存储、流程监控等，简单来讲，它就是把新闻采集和通稿制作、新闻编播、新闻内容管理和新闻网络制播监控四大系统中需要交互的业务以及相关的公共的业务流程来进行统一的管理和调度，形成一个核心业务管理平台，同时其还要向各个系统提供相应的接口服务，从而来完成整个新闻节目从最初的资料收集到最终形成新闻播出的业务流程一体化管理。

当前的新闻业务管理系统，技术上沿用原有的J2EE架构的B/S模式，并在ESB总线的基础上，基于面向服务架构建立相互协作的工作平台相关核心组件，能够协助电视台用户全方位管理生产资源，并通过办公协同来提升业务便捷性，进而达到提高生产效率的目的。

1 新闻综合业务管理系统

现阶段的新闻业务管理系统基本上都是计算机服务商来提供，研究发现，目前面向服务的体系架构至少在60%的企业中被作为了其IT系统基本架构的方法[1-3]。而将面向服务体系架构（简称为SOA）的核心思想应用于新闻业务管理系统的系统构建过程的研究将具有十分重要的现实意义[4-5]。SOA在本质上支持将业务构件和技术构件转换成一组服务组合或可重用的业务任务，而不管是什么样的系统平台和编程语言来完成的，在需要时只须访问这些服务和任务并对来自各个地方的服务进行组合。

新闻业务管理系统作为一个以新闻生产管理为主体的业务管理平台，涵盖了新闻策划、人员组织、资源调度、流程监控、考核统计以及信息、安全等方面的管理业务[6-8]。基于面向服务的架构实现步骤和应该遵循的原则，新闻综合业务管理系统的基于面向服务架构的系统功能结构如图1所示。

2 新闻文稿管理业务

文稿管理是新闻综合业务管理系统众多功能模块之一，对于基于面向服务架构（SOA）的系统，它对架构思想的体现是十分全面的。新闻文稿的制作一般是从线索的汇聚开始，到信息挖掘、选题产生，然后再根据具体的内容生成文稿，最后进入编播的串联单这样一个流程。因为各个台新闻文稿的应用差异并不是很大，所以它的通用性比较强。文稿管理依照SOA服务的划分原则以及服务的低耦合、完整性等的要求，本身也可以被看作是一个组合服务，也可以被其他服务调用、组合来共同完成更复杂的业务功能。

2.1 文稿管理中的业务流程

中文稿创建、文稿编辑、文稿查询、文稿审批、文稿删除和查看处理记录构成了文稿管理主要的业务功能。其大致的业务流程如下：首先新建文稿（这里要进行新建权限的判断），如果有新建权限，则创建文稿并保存文稿，进行文稿提交；对于已提交的文稿，可以对其进行编辑、修改保存，重新提交，如果是编稿本人，则可以对自己保存提交的文稿进行修改编辑；对于已经确定的文稿，编稿本人可以查看自己的文稿或者是对其他有权限的文稿，同时可以将已经确定的文稿送审，等待审批；审批人拥有审批权限，可以根据不同级别的审批权限来进行多次审查；最后通过审批的文稿就被送入到串联单管理模块，审批不通过的则被打回，重新执行上述整个业务操作。至此，文稿管理的业务操作就完成了。

文稿管理业务流程图如图2所示。

2.2 文稿管理模块的服务分析

依照对文稿管理的业务分析，按照面向服务架构服务划分原则，对文稿管理模块进行服务划分。

首先，把该模块的业务功能封装成1-新建文稿、2-编辑文稿、3-查询文稿、4-删除文稿、5-审批文稿、6查看文稿处理记录等6个独立的粗粒度服务。

其次，进一步分析抽象，把新建、查询、编辑、删除和审批进行更细粒度的服务划分，把前4个封装为4个基本服务，而审批本身是个组合功能，所以继续细分为11-审批流程创建、12-审批流程数据定义、13-审批流程。这样以来，就可以实现多级审批的自定义配置。同时，由于还需要对整个文稿管理的操作进行监控，所以还应该有一个存储业务操作处理情况的服务。

至此，在进行整体系统开发时，不同的系统业务模块就可以采取传入不同的配置参数来动态组装基本服务的形式，完成其具体的业务流程功能；特别需要指出的是，为了适应业务个性化需求，在审批业务模块中，把审批流程单独分离出来，使其具体的实现细节和执行内容相分离，达到了灵活配置的效果。在调用审批服务时，不同的业务模块只需要传入自己的业务类型标识即可启动相应的审批服务，整个审批过程对用户来说都是透明的。

图3显示了文稿管理模块的服务关系网络。

在图3中，每个结点都代表一个服务，每条线表示当一个服务执行完以后要转向下一个服务所应该满足的条件和下一个服务需要的参数来源，同一个结点出来的射线所表示的条件是不会相交的。

完成了服务粗细粒度的划分，弄清了服务之间的关系，接下来就将这些服务进行发布和注册，使其成为可复用的SOA服务，以方便在需要的时候调用。当然，在发布服务之前，还应该进行一系列的检查来确保分析没有错误，发布的服务合乎服务标准。

2.3 文稿管理模块的服务发布与注册

这里选用Xfire进行相关服务的发布工作。因为它可以将服务首先描述为POJO接口，然后进行适当的配置，实现发布服务。以审批服务为例，主要作用是输入一个编辑完成的文稿进行多级审批，并将审批结果返回供其他的服务模块使用。

在Eclipse galio中创建一个Web服务项目，此时，在根目录下就会有一个名为WEB SERVICE的文件夹，在实现服务接口以及服务类后，还需要在这个文件夹的services.xml文件中进行配置，从而加入新发布的服务。

先用Java语言来描述这个服务接口，代码如下：

在进行参数处理时，采用的是使每个模块需要传递的参数以在后台管理中单独配置的形式存在，封装在相应的一个类文件中，例如文稿模块的参数信息封装在public class docMsgService extends AbstractMessagePipe-Adapter中，方便对其进行统一管理。

接下来，为这些服务接口创建实现类，并实现接口中定义的方法。现在服务的实现部分已经完成，接着就是在上文中提到的services.xml文件中进行相关信息配置，使发布的服务生效：

该配置文件中描述了服务的名称、命名空间、实现接口类等信息。到此，审批服务就发布成功了，通过网络即可访问到该服务，对其进行组合调用。对服务进行发布后，服务请求者就可以对服务进行访问了，并进行服务注册，把已经发布的服务在公共的或者私有的UDDI注册中心注册，从而供不同的使用者方便查询和发现服务。通过把服务注册到服务数据库中，服务请求者能方便地对现存的服务进行查找，并获得其相应的描述信息（WSDL），将服务进行注册也有利于服务的管理和编排。考虑到系统良好的扩展性以及高效性，引入了企业服务总线对服务的注册进行统一管理，加快了服务之间交互访问的速度，提高了工作效率。至此，服务发布和注册都已完毕，接下来在实际的操作过程中进行服务组合的测试。

2.4 文稿管理模块的服务测试

模块服务发布和注册完成后，还需要对整个模块的功能进行测试，以保证在实际的生产环境中各种业务需求得到满足，并把因为开发因素导致的故障可能性降到最低。图4为系统功能模块测试的基本流程。

以下为针对文稿管理模块服务接口进行的压力测试，包括新建、查询、提交、审批等业务接口，详细设计了测试方案与用例，并按用例逐个完成测试，而且在重要的业务接口中多次重复执行测试，以保存测试结果的准确性。本文中选用成熟的性能测试工具loadrunner9.0英文版作为压力机，通过并发进行接口数据传递，同时调整传递数据大小形成不同的压力，观察并记录响应时间和模拟用户数，同时监控服务接口服务器系统资源变化。

部分测试用例如下：

1）创建文稿用例。模拟100个用户，每5 s加载20个用户，通过集合点控制所有用户到达后并发执行接口数据传递，迭代3次，超时设置为300 s。

2）查询文稿用例。（1）模拟100个用户，每5 s加载20个用户，通过集合点控制所有用户到达后并发执行接口数据传递，迭代3次，超时设置为300 s，每个用户传递参数ScriptID不一样，共需300个docid号；（2）模拟100个用户，每5 s加载20个用户，通过集合点控制所有用户到达后并发执行接口数据传递，迭代3次，超时设置为300 s，传递参数PageSize设为200。

3）文稿合成提交用例。模拟100个用户，每5 s加载20个用户，通过集合点控制所有用户到达后并发执行接口数据传递，迭代3次，超时设置为300 s，每个用户传递参数ScriptID不一样，共需300个docid号。

从以上结果记录中可知，创建、提交业务模拟用户与成功用户之比100%，所有请求都成功，同时事务（发送参数与接收返回结果）平均响应时间也较低，100个并发用户执行都小于2.5 s，并接口服务器资源消耗较小，该部分的接口性能符合设计要求，完全满足用户需求。

查询业务接口中，业务接口模拟的用户成功执行，各种性能指标稳定、正常，按预定的结果返回，从目前测试的结果可知，该部分的接口也正确、稳定。但由于返回结果条数较少，没有更多的被测试数据，所以无法测试接口的极限值（最大返回条数）。但在测试查询文稿接口时，当接口服务器返回条数（用户数×返回条数）超过35 000条时就会报错，也就是说该接口的最大返回极限条数为35 000条。

2.5 文稿管理模块前端设计

基于面向服务架构的思想，业务功能的实现被划分成了几个部分：前端应用程序、服务总线、业务服务和后台服务。当后台服务和业务服务设计完毕之后，作为SOA架构中比较活跃的元素应用程序前端，则因为服务总线和统一接口定义语言的存在对进行非常灵活的设计，而且采用多种方式实现。

文稿管理模块GUI的实现界面可以分为前台管理界面和后台服务界面两部分。在前台管理服务中，通过将一些基本服务进行组合形成文稿编辑、查询等一系列工作，然后通过前台管理调用后台管理中的“审批”服务来完成文稿管理中的审批服务。具体的审批信息配置都是通过后台服务来完成的。发送请求时不必关心流程具体实现细节，而只需要关注是否返回审批结果即可。在本模块的开发中，采用面向服务的方式，很好的实现了执行内容和

4）文稿送审提交。模拟100个用户，每5 s加载20个用户，通过集合点控制所有用户到达后并发执行接口数据传递，迭代3次，超时设置为300 s，每个用户传递参数ScriptID不一样，共需300个docid号。

测试结果部分记录如表1所示。执行流程的分离，提高了系统对业务灵活性等的支持。

3 总结

表1 测试结果表

新闻业务管理系统作为一个综合管理平台，其系统的业务功能主要是依据这些相关的所要管理的子业务来确定。新闻文稿管理作为新闻业务重要的一环，在实现过程中充分体现了新闻业务管理系统的特点。本文采用面向服务架构（SOA）的思想实现新闻文稿管理功能，在对业务需求流程进行详细分析的基础上，对服务进行划分，发布和注册，并完成了模块功能的测试。通过制定统一的接口，实现各个业务之间的松散耦合、规范开放的互联互通，以提高新闻业务管理水平，对于整个新闻综合业务管理系统的实现具有积极的作用。

：

[1]王斌，田野，章云.广电企业业务流程的分析与优化[J].电视技术，2007，31（7）：59-61.

[2]冯细光，刘建勋.WEB服务测试技术综述[J].微计算机应用，2010，31（1）：21-26.

[3]郎大为.基于语义Web服务的服务组合与匹配算法研究[D].大连：大连理工大学，2006.

[4]李军.采用SOA的广电台内网应用集成技术设计与实践[J].现代电子技术，2008（2）：41-43.

[5]DANG G，CHENG Z，JIN S，et al.A service-oriented architecture for tele-immersion[C]//Proc.2005 IEEE International Conference on e-Technology，e-Commerce and e-Service.Hong Kong，China：IEEE Press，2005：646-649.

[6]刘大军.广播电视台综合业务网的功能与实现[J].广播与电视技术，2002，29（10）：119-121.

[7]孙林记，张洁霞，冒卫.全台网系统中的业务流程设计[J].广播电视信息，2009（1）：94-97.

[8]李友.基于Internet网的新闻交换和新闻异地采访[J].电视技术，2011，35（4）：26-27.