电视业务支撑平台（共7篇）
电视业务支撑平台 篇1
20世纪80年代，移动电话在中国出现，在随后的发展中，移动通信产业的发展远远超过了业界人士的预期。对近几年移动通信业务结构进行分析可以看出：电信基础主体业务呈下降趋势，而伴随着的是移动增值业务用户数量迅猛增长。截至2009年9月份，中国移动用户数量已经达到5.08亿，现在仍以每月净增568万的数量在增长。作为中国最大的移动通信运营商，中国移动通信集团在与国外运营商相比起步较晚的情况下，其GSM网和用户数量迅速窜升至全球第一。
随着移动电话用户数量的迅速增长，移动用户已经不再仅仅满足于随时随地的话音业务，适合市场需求的移动增值业务显示出了巨大的市场发展潜力。自从20世纪90年代移动增值业务在国内出现以来，经过运营商、内容提供商和服务提供商的不断努力，移动增值业务有了很大的发展。从最早的短信业务，到后来的中国移动的“移动梦网”品牌和中国联通的“联通无限”品牌，我国的移动数据增值业务在2.5G网络建成后，开始全面的启动，并已经获得了巨大的成功。据最新的数据显示,现在中国通过手机上网的网民已经达到2.33亿。随着3G时代的到来，用手机上网的网民数量还将以更快的速度增长，从而促进移动增值业务的发展，同时移动通信产业形态也渐渐由单纯的产品经济时代业态完成了向服务经济业态的进化，移动增值服务将取代单纯的移动通信产品，成为这一产业主要的利润来源，对人民的工作和生活发生深远的影响。
1 我国移动增值业务的发展
1.1 移动增值业务的分类
目前基础的移动增值业务主要有短信、彩信/彩E、WAP、JAVA/BREW以及IVR五大类，随着业务需求的进一步发展，将有更多的基于开放应用平台务架构的新业务出现，为移动增值服务业的发展注入新的活力。
1)短信是各类无线增值服务中发展最早，最为消费者认可，也相对最成熟的业务。但是，短信市场作为成熟市场，其成长空间已经有限，加之市场中各大小SP(SP是指移动互联网服务内容的直接提供者)竞争日趋白热化，以及短信作为信息承载方式容量过小的技术限制，可以预计，短信将不再是未来无线增值服务发展的热点，但是短信和其他业务能够组合起来的新业务能够提供更加贴近消费者需求的服务，相信这会是一个新的利润增长点。
2)彩信/彩E是多媒体信息服务，支持多媒体功能，能够传递功能全面的内容和信息，这些信息包括文字、图像、声音、数据等各种多媒体格式的信息。是近年来移动运营商着力推广的2.5G标志业务。由于其支持终端匮乏且价格高昂、服务资费居高不下且交互性弱，致使彩信/彩E业务的发展一直不温不火，远远无法达到业内人士的预期。
3)WAP的全称是Wireless Application Protocol，是指无线应用协议，是一项全球性的网络通信协议。WAP使移动Internet有了一个通行的标准。两年前中国移动推广WAP服务时由于网络接入速度慢和按时长计费且费率高而受到制约。但随着运营商3G网络的架设与商用，WAP接入的速率大大提高了，WAP业务面临着一次重新崛起的机会。现今，SP推出的WAP业务包括：在线游戏、信息浏览、视频片断下载、手机广告等。
4)Java/Brew都是供可以将下载应用程序运行在不同厂家设备上的环境，都采用基于开放应用平台的移动增值服务架构。在未来几年内，Java/Brew是未来无线数据服务的主流方向。
5)IVR，即无线语音业务增值服务，和目前大家熟知的固定电话声讯服务类似。手机用户拨打指定号码，获得所需信息或者参与互动式的服务。这是移动运营商由2002年开始启动的新业务。IVR业务行业管理规范、用户群庞大，市场前景广阔。现有的IVR业务包括彩铃、在线点歌、语音信息服务、语音游戏、多方会议、背景音乐通话以及聊天交友等。
1.2 我国移动增值业务的发展现状
目前，世界上各国运营商开展的移动增值业务以及采用的技术基本上有以下方面：基于Java或BREW的下载游戏类业务，基于WAP/Web的信息浏览和信息查询类业务，基于SMS/MMS的邮件多媒体消息传送类业务，以及基于各种定位技术的移动定位业务。从发展移动增值电信业务比较早、市场相对成熟的日本和韩国的经验来看，开展移动增值业务对整个ARPU(即每用户平均收入，用于衡量电信运营商业务收入利润的指标)值的拉动效应十分明显。
在我国，自从移动电话进入千家万户以来，移动增值业务也因方便、快捷而得到用户、企业和服务供应商的普遍欢迎。目前中国移动增值业务运营商主要有中国移动和中国联通两家。中国移动自2002年推出“移动梦网”以来，已经陆续推广了许多新业务，从最初的百宝箱、手机上网、彩信、彩铃到现在的手机钱包、手机影视、手机动画业务等;中国联通从2001年开始启动“中国联通无线数据综合业务系统工程”，目前基本上实现了全国联网，做到各分公司业务共享，打通了与各服务提供商(SP)的通道，实现了SP一点接入，全网服务的目的。其服务包括彩E、互动世界、掌中宽带、联通在信、神奇宝典、定位之星等。可见，我国的移动增值业务已经显示出了良好的发展前景。
2 移动增值业务的开发平台及相关技术
移动网络的承载接入能力很大程度影响着移动增值业务的发展，以前由于相关技术的不成熟，增值业务的发展受到限制，现在，随着3G网络的逐步引入和底层通信技术的进步和网络架构的成熟，移动增值业务中的通信需求得到了满足，移动增值业务将成为3G通讯时代最主要的利润增长点。
随着移动用户数量的增多和3G技术的引入，如何加快移动增值业务的快速发展已经成为了亟待解决的问题，而解决问题的关键是要降低消费价格和构建一个开放性的移动终端业务支撑平台。只有手机上网资费下调，广大的消费者既能买得起又用得起高性能的能畅游网络的中高端手机，同时网络上又存在丰富多彩的移动增值业务时，移动数据业务才能快速地发展起来。
2.1 移动增值业务平台的研究
传统的移动网络是两层体系，最底层是基础设施层(Infrastructure Layer，包括基站、路由、交换等)，其上一层是无线基础业务支撑层。随着移动增值服务的发展，在这两层的基础上，还将逐渐形成稳定的无线增值业务支撑层，该层将是面向应用的端到端的开放计算机平台架构。随着3G技术的引入，该架构将逐渐成熟，如开放的应用下载方式、丰富的表现形式等，将成为未来移动增值服务的主流形式。
架构基于开放应用平台的移动增值服务的目的是建立基于Internet、服务于特定应用领域的数据增值的开放式平台，是手机终端到服务端的解决方案。该架构中传统的基于单机应用的操作系统的概念得到了发展和延伸，使得应用程序能从开始就以网络应用概念为基础，使用嵌入端开放软件平台、手机端和服务端应用支撑平台和无线数据协议接口。
在设计基于开放应用平台的移动增值服务体系时可参考以下三点：
1)明确设计目标是为提供面向行业或特定细分市场的移动数据增值应用平台，使应用和服务开发商能够容易地在此平台上获得丰富而强大的增值服务功能。
2)采用基于Java、Brew或其他自定义的开放应用平台标准，屏蔽掉终端操作系统和服务接入端的平台异构性。
3)从商业运营角度出发，要能够有效支持运营商和开发商的智能管理和定制化、个性化服务。
如图1所示，只有做到从终端定制到业务平台的端到端的整合，才能实现为用户提供完美的增值业务使用体验。
业务平台和终端的融合，必须和手机生产商共同配合，从应用层到平台层进行深度定制，如图2所示。
2.2 移动增值应用体系架构及产品分析
移动增值服务体系的开放应用平台可分成信息型应用和事务型应用两类，通常用于架构复杂的企业级无线应用或特定市场细分领域。“信息型应用”是指将信息内容传递和发送给移动设备的应用，比如：股票证券、新闻娱乐报道、天气预报等，该类型的应用一般不需要移动用户与后台数据库进行频繁交互，主要面对消费型用户;而“事务型应用”需要用户与后台数据库的频繁交互，例如：移动股票交易、个人帐务信息管理及移动电子交易等。
与“信息型应用”相比，“事务型应用”对软件体系结构的要求更高，因为“事务型应用”需要在无线设备和企业后台信息系统间建立稳固的数据交换通道，以保证在无线设备上的业务处理数据被快速、准确和安全的送达后台处理系统，被后台处理系统正确的处理和高效地执行，确保关键业务数据不会丢失或被错误处理;而“信息型应用”如果在发送数据时失败，还允许移动用户通过重新发送请求获得数据的重传。通常企业和业务决策人会选择更好的“事务型应用”的解决方案，满足无线领域应用需求。对于企业级应用的软件系统架构，有两种方式可供选择，分别是浏览器访问方式和客户机/服务器方式。
1)浏览器访问方式：通过在无线设备上安装通用的WWW浏览器，后台服务器上安装例如微软的IIS(Internet Information Server)，使用脚本编辑语言(如JavaScript、ASP等)和ActiveX技术，实现用户界面，实现业务逻辑，完成对数据库的访问。
浏览器本身的主要用途是用于链接Internet的超文本信息，它的优势在于浏览器对于颜色、图形和信息的显示，因此，它是解决“信息型应用”的最佳选择，而较少用于解决“事务型应用”的需求。
“事务型应用”要求服务器完全控制客户端与服务器间的连接，而浏览器方式是由客户端控制连接的，而不由服务器控制，因此连接事务的完整执行就无法得到保证，基于这点，“事务型应用”的需求浏览器方式无法全部解决。比如，当用户还未完成某种连接事务时，此时用户又输入其它的URL地址，或是单击其它链接，这样都会导致某个正在执行的事务的异常中断，而因为服务器不负责连接，所以也就无法得知客户端的执行状态，从而导致服务器停止，留下未处理完的事务、数据库记录和相关的日志。一般来说，浏览器是为访问Internet设计的，所以浏览器对一般外围采集设备的输入是不支持的。
2)客户端/服务器方式(Client/Server)：客户机/服务器方式包括两种结构，分别是胖客户端方式和瘦客户端方式。
客户机/服务器方式，是指在客户端的移动设备上基于Windows CE、Linux、Symbian等操作系统平台编写的用户界面，通过中间件或中间层的解释，从而达到访问后台企业数据库信息系统、实现业务逻辑的方式。从广义上理解，终端仿真方式和浏览器方式属于瘦客户机/服务器方式的一种。
胖客户端方式，是指用户的业务逻辑、界面显示、数据库接口实现都在客户端的无线设备上完成，客户端直接访问企业后台数据库;而在瘦客户端方式中，服务器端负责定义输出(界面显示、提示声音等)和解释来自移动设备的输入，处理后台业务逻辑和对数据库的操作，客户端程序只负责显示图形用户界面和处理与后台应用系统的通讯。
胖客户端与瘦客户端各有利弊，胖客户端中，客户终端的无线设备承担更多的任务，服务器的负担相对较轻，但用户与后台系统的交互性差;瘦客户端中，终端设备的负担轻，与后台系统的交互性强，但当客户端的数量不断增多时，服务器端的承载就非常重。
目前移动增值业务发展正如火如荼，显示出了巨大的市场潜力，吸引了许多服务提供商跃跃欲试，跳入洪流，一个新的服务经济时代已经到来，未来的体验经济时代亦杏帘在望。究其本质，服务的核心存在形态是应用，高性价比的应用需要开放的软件系统平台承载，这将导致在未来的移动增值服务领域中，计算体系与通讯体系在无线网络环境下的完美统一。
3 基于Java/Brew平台的移动增值业务
3.1 Java技术在移动通信中的应用及其优势
早在1996年，Sun公司就推出了Java语言的三种版本，J2ME是其中的一种版本，它是专门为资源受限的小型消费性电子设备的应用程序开发而设计的Java平台，目前已经被广泛地用于手机、PDA个人数字助理、小汽车导航系统以及电视机顶盒等众多小型资源受限的设备中，有着非常好的发展前景。
J2ME的主要技术优势在于：其应用程序小巧且有良好的跨平台能力，能很好地运行在任何不同手机的不同的操作系统上;有着与J2EE后端的无缝结合能力，利用J2ME技术编写的应用程序可升级至J2SE和J2EE平台;保留了Java语言的优良特色，网络传递极为安全;现有的Java平台上广泛的开发工具，企业、开发人员能够为J2ME提供良好物质和人力支持。
无线Java技术解决了无线Java应用软件与手机底层软件的适配问题，同时促进了无线下载技术的发展与进步。网络服务器可以根据用户的要求将程序下载到用户的Java手机中，使用Java手机的用户可以在移动网络中浏览、搜索和下载各种Java应用程序，随时随地更新自己的手机功能。
采用无线Java技术后，应用程序编写者(CP)和服务提供商(SP)就无需关心手机中采用什么操作系统了，手机生产商也无需考虑由谁来提供增值业务。有了开放、统一的无线Java技术后，在CP、SP、手机制造商和移动运营商之间形成了一条统一、高效、完整的移动数据增值业务产业链，从而为用户提供灵活、个性化、内容和方式多样化的增值业务。
不仅如此，Java手机还是一款具有计算功能与处理功能的智能手机，而相比之下，WAP手机只是一个显示终端，其所有的计算、处理工作都必须在网络服务器中完成。
在移动通信技术中采用Java平台能够屏蔽手机终端自身系统平台的差异性，形成手机端的开放式平台，通过Java语言和Java库能够实现复杂逻辑和功能的业务。以前由于技术、设备等各方面因素，Java的业务盈利并不明显，但随着技术的成熟，Java作为未来的竞争力，是应该进行大量前期投入加以培植的业务方向。
3.2 Brew技术在移动通信中的应用及其优势
Brew是由美国高通公司发明的封闭技术，现在只能运行在高通公司所提供的CDMA芯片上。Brew是介于手机底层操作系统与应用之间的一个匹配软件平台，为上层应用提供对底层软硬件设备的调用与管理。
Brew的优势在于其二进制的运行环境可以高效地利用FLASH和SRAM，利用流媒体应用，其运行速度比Java要快，，但其安全性和保密性则逊于Java。
Java和Brew提供业务的目标是相似的，都是提供可以将下载的应用程序运行在不同厂家设备上的环境，编程者无须知道手机底层软件。Java的安全性较高，但运行速度受到一定的削减。Brew的速度快，但安全上的缺陷导致应用的提交、认证过程的复杂性。当前基于这两种技术的业务均已经商用，孰优孰劣还有待市场的评判。
随着3G技术的引入，基于Java/Brew开放应用平台的移动增值服务架构将更加成熟，采用Java/Brew的开放应用平台标准将会更加完善，在移动数据增值业务中发挥着越来越重要的作用。
4 总结
当前，在全球的移动增值业务呈现平稳快速发展的背景下，我国的增值业务将继续保持着强劲的增长势头，业务市场也渐渐走向成熟和规范。3G技术的商业运营将为移动增值业务的发展提供更广阔的平台，强有力地促进移动增值业务市场更加迅猛地发展。与此同时，移动通信运营商需要提供统一的业务开发接口和业务执行环境，屏蔽用户终端的差别，这样同样的业务就可以在不同品牌、不同操作系统的移动终端上运行;统一的业务开发接口又提供了电信级的API调用,可以让移动增值业务开发人员专注于业务的开发，而无需深入地了解底层的移动终端和移动网络技术。
面对未来，中国两大移动通信运营商需要综合各方面的因素加强对增值业务平台建设的认识，做到进行统一全面规划并分步建设与实施，以实现业务平台的平衡发展。
参考文献
[1]詹舒波,易文强.面向移动通信终端的业务支撑平台[J].北京邮电大学学报,2006,29(增):61-62.
[2]白云锋.无线增值业务平台研究与实现[D].天津:天津大学,2007:1-4.
[3]刘岩.我国移动增值服务的现状及趋势[J].中国数据通信,2006(15):1-11.
[4]刘东明.移动增值业务介绍及发展[J].电信网技术,2003(8):6-9.
[5]解绍词,何蔓微.移动增值业务发展现状及发展趋势分析[J].重庆工商大学学报:自然科学版,2008,25(5):548-549.
电视业务支撑平台 篇2
电信运营商传统以电信资源制胜的市场法则已不再适用, 随着互联网、移动互联网的兴起以及全业务时代的来临, 运营商管道化的趋势正在加剧。如何在新的市场环境下实现资源服务向业务服务的转型?目前运营商已意识到云计算所带来的机遇, 着手利用云计算建设企业内部信息化, 以提高运维、决策效率, 以及快速的市场反应能力。
业务支撑系统 (BOSS) 作为运营商庞大而复杂的系统资源平台, 规模每年都快速增长, 然而烟囱式的建设模式造成了平台资源无法共享、系统总体利用率偏低、系统资源配制不合理、维护难度大、成本高等系列问题, 所以为实现业务支撑系统的能力快速交付、灵活调优, 运营商业务支撑系统云平台建设便首当其冲。
稳定可靠是基本
目前国内三大运营商纷纷开始研究云计算在内部IT系统的运用:中国移动发布大云研究计划, 在IT支撑系统中试点使用云技术;中国电信启动云业务, 着手启动BI云化系统的改造工作;中国联通启动了云计算应用于IT支撑系统的试验工作等。
山西移动业务支撑系统副总经理王峰表示, 为更好地支撑业务发展, 业务支撑系统正向云计算模式、虚拟化模式转型。
另一方面, 对于运营商, 业务支撑系统占据着重要地位, 而同时云计算作为一项新技术, 还存在不小的挑战, 特别是如果贸然在核心业务系统中引入云计算技术会存在巨大的技术和业务风险。在王峰看来, 运营商业务支撑系统云平台建设需遵循三个原则——按需选型、平滑过渡、稳定可靠。
“相比于互联网公司, 电信运营商有更多样的应用场景, 应该根据不同系统的需求进行选择, 合适的就是最好的。”王峰说道。在云化改造的同时, “不能以牺牲性能和可靠性为代价”。
三架构层次改造思路
记者从山西移动处了解到, 山西移动按照业务支撑系统应用普遍采用的接入层、中间层 (应用层) 、核心层 (数据层) 的三层架构进行横向整合, 经过一年多时间的建设, 目前已初步完成云化改造, 正式上线。
在核心层 (BOSS/CRM核心数据库系统) , 包含了关键数据库, 并且应用复杂, 出于对稳定性、高性能、可靠性的考虑, 山西移动采取的仍是传统的异构平台, 对集中的数据库按照地域和功能进行拆分, 部署松耦合的应用架构, 并减轻单一节点失效的影响。所以在技术选型方面, 此层采用中高端小型机的动态分区模式, 使用专有CPU和IO满足系统对性能和可靠性的需求。
在中间层 (中间件、一般数据库及后台应用) , 针对分区数量大、种类多、系统变更快、负载变化快、单一区能力需求可控以及具有通用性和集中部署的特点, 山西移动在该层级实现了软硬件解耦, 使用虚拟化技术从技术资源、网络资源和存储资源三个方面, 全面提高资源共享度和交付灵活度。在该层主要采用中端小型机, 使用高级虚拟化模式, 在兼顾可靠性和高性能的同时, 提高分区的灵活度, 满足快速部署的需求。
在接入层 (Web Servie服务器和小应用系统) , 因小型应用数量大, 应用自身具备群集运行特点, 对单节点可靠性和性能要求不高, 所以采用了基于linux技术的虚拟化与x86服务器虚拟化方案的结合, 控制了成本, 并有效利用原有设备, 充分发挥了价格优势, 同时还开发基于SaaS层的应用云平台。
未来朝Saa S服务提升
据悉, 山西移动业务支撑系统基础架构云建设, 在业务支撑系统中间层采用了IBM PowerVM高级虚拟化软硬件解决方案, 在搭建云平台的同时, 还为不同业务系统安全区域服务提供虚拟化资源池, 实现了业务系统的横向整合。目前山西移动已部署了各类业务支撑系统中间件业务, 包括业务渠道中间件、后台应用、非核心数据库、接口系统等共计80余个业务分区。同时, 其业务支撑系统不仅系统资源利用率、系统敏捷性显著提升, 在动态扩展、资源按需使用的灵活性方面也得到了提高。
电视业务支撑平台 篇3
面对三网融合, 广电运营商将完成从有线电视运营商向有线电视综合信息网络运营商的转变, 在双向有线电视数字网的基础上开展综合业务, 随着业务量的不断增大, 广电企业的业务运营能力也面临巨大挑战, 运营支撑系统的良好运行成为广电运营商的重要后台支撑, 不管在功能还是性能方面都必须要满足日趋增长的业务类型和业务数量, 才能保证用户多样业务的顺畅体验。有线电视网络运营支撑系统测试研究旨在找出能够适用于广电业务的测试方法, 帮助有线运营商提高自身运营支撑系统质量。
1 有线电视网络业务运营支撑系统研究现状
全国有线电视运营商在运营支撑系统建设方面起步, 目前存在以下三个问题:缺乏客户资料的统一管理、各类业务管理系统比较封闭, 也比较分散、不能对系统统一进行管理。有线电视网络正在处于模拟电视到数字电视的过渡时代, 电视数字化和三网融合的推进给有线电视网络运营商带来机遇的同时也带来了挑战, 随着大数据量的处理和存储, 广电需要一个完善的、高可靠性、高可用性、高稳定性、高灵活性、高可扩展性、高兼容性以及高可管理性的、面向未来的综合业务运营支撑系统来替代原来比较分散的系统。目前, 各有线电视运营商正按计划、有步骤地进行数字电视的整体平移。除传统的模拟电视外, 还大量地开展了数字电视、互动电视等新型业务, 但这些业务总体可归为如下四类:模拟电视、数字电视、宽带业务、增值业务。随着数字电视用户的不断增长, 以及有线电视网络的升级改造, 增值业务成为有线电视运营商增加收益、拓展收益的主要部分。各地正在开展和研究的增值业务主要包括:电视短信、电视商务、电视政务、电视互动游戏、家庭银行、证券交易、彩票业务、IP电话、社区服务、交通服务等。随着用户数量的增长和数字电视增值业务的迅猛发展, 为提高管理水平、运营效率和服务水平, 增强企业竞争核心力, 建设多业务综合运营支撑系统成为广电系统的首要问题。
2 有线电视网络运营支撑系统系统功能架构
2.1 系统组成
NGB BOSS主要由业务支撑系统 (BSS) 、运营支撑系统 (OSS) 组成。BOSS从业务层面来看就是一个框架, 来承载业务系统、CRM系统和计费系统。实现统一框架中的纵向、横向管理。
2.2 业务支撑系统BSS
业务支撑系统包括客户管理系统、综合计费账务系统、合作伙伴管理系统、授权管理平台和用户认证平台。客户管理系统是以客户为中心, 提供面向客户的售前、售中、售后的服务和管理的综合系统, 它整合客服、营销、销售/ 订单等功能, 提供统一的客户视图与产品闭环管理。综合计费账务系统实现全业务详单的采集、计费和账务处理, 统一余额管理以及欠费管理。合作伙伴管理系统针对产业链上游的信息服务提供商和中游的网络设备供应商提供的服务进行管理, 实现与其他服务供应商、内容提供商、渠道商等合作伙伴之间根据结算规则完成收入分摊、业绩核对和监管的过程。授权管理平台主要为用户使用特定的服务产生合法的服务指令, 发送服务开通指令, 使得用户能够通过统一用户认证平台或业务系统的鉴权。用户认证平台为运营商的各类基础业务及增值业务使用用户提供统一的认证, 还提供针对用户所订购产品的鉴权。
现有BSS功能包括:市场营销、客户关系管理、产品管理、计费账务、渠道管理、客户服务、合作伙伴管理、预付费卡管理和统一认证、工单管理、统计报表、标准地址管理渠道佣金结算、合作伙伴结算、资源管理 (终端资源管理、网络器材管理、票据管理、地址管理) 、电子渠道 (网上营业厅、电视营业厅) 、销售管理、外呼管理、增值业务管理平台、社区经理管理、统一支付平台、统一授权、统一授权管理、综合结算、业务开通管理、集团业务管理、合同管理和政企业务管理。
2.3 运营支撑系统OSS
运营支撑系统包括服务开通系统、综合运维管理系统、网络监控管理系统和综合资源管理系统。服务开通系统实现在开通服务层面的管理功能, 承接客户关系管理系统中的订单, 与自动激活和施工调度共同建立端到端的开通能力, 并对网元进行集中统一的控制。综合运维管理系统全面管控各种运维信息, 为快速服务开通、快速故障定位和服务恢复以及高效日常维护管理提供支撑, 从而提高对市场业务的支持力度, 提高整体服务水平、服务质量及服务保障效率。网络监控管理系统实现获取资源层的告警数据、性能数据、流量数据和协议数据, 提供多专业网管数据采集、处理和呈现功能, 同时对告警信息进行跨专业关联分析, 进行故障分析定位, 将告警信息与客户信息和业务信息关联处理, 确定故障业务和客户影响范围, 设立性能阈值, 当超越门限时生成性能告警, 提供各种网管数据专题分析和呈现功能。综合资源管理系统对各专业网络的物理资源以及逻辑资源进行统一管理。将为服务保障类系统以及服务开通类系统提供资源数据支撑, 并保存用户与资源之间的对应关系, 同时为其他的系统提供资源信息或实现资源变更操作。
3 有线电视网络运营支撑系统测试需求分析
3.1 功能测试需求
3.1.1 业务支撑需求
在业务支撑方面, 主要面向客户, 对客户接触过程中产生的需求提供支持, 至少应满足如下需求:
1.实现营销、销售和服务的一体化, 支撑全业务的运营;
2.对营销计划、活动、营销绩效进行管理;
3.整合客户接触渠道, 提供销售商机支持和渠道管理能力;
4.展示所有自然人、家庭、商业单位、团体或者客户群体等客户的客户统一视图, 提供统一客户接触管理和客户Qo S/SLA管理;
5. 实现产品/ 销售品管理及其生命周期管理, 支持灵活的产品配置;
6. 实现合作伙伴管理, 支持其业务部署及结算;
7. 实现实时、集中、融合的计费, 支持预付费和后付费两种付费模式, 支持按次、按流量、包周期等计费策略;
8.实现统一的授权、认证和鉴权。
3.1.2运营支撑测试需求
在运营支撑方面, 主要面向服务和资源, 提供综合运行支持, 至少应满足如下需求:
1. 实现统一的资源展示, 优化资源配置, 进一步提供面向客户的服务与体验, 强化服务开通与服务保障能力;
2. 面向服务和资源, 提供综合运行支持, 支撑有线电视网络运营商各类产品的开通与快速故障定位, 支撑对网络性能参数和运维服务质量的实时监控、分析和管理。
3.1.3 公用共性测试需求
在公用共性需求方面, 顾名思义, 主要是将公用需求抽像出来, 供其它功能域调用, 至少应满足如下需求:
1. 操作权限管理, 包括组织结构管理、人员角色管理和权限管理等;
2. 公告信息管理, 主要是针对系统内部的信息发布、公告传递和使用说明等;
3. 日志管理, 包括系统日志 (备份) 的查询、系统日志的导出/ 转储、系统日志备份操作和系统日志的清理等;
4. 网络管理, 对BOSS系统自身的网络相关事务进行管理。
3.2 性能测试需求:
以某省运营支撑系统为例, 省分系统可服务用户规模为500 万户, 系统性能技术指标如下所示:
1. 省分系统可服务用户规模500 万户;
2. 系统在100 用户并发访问时, 系统页面响应时间不超过3~6 秒, 超时则为失效;
3. 测试过程中, 各应用程序的资源使用情况没有明显的变化;
4. 系统CPU在70%~80% 之间高压力下可持续工作4 小时以上;
5. 系统响应时间为1s时, 系统所能承受的最大并发访问用户的数量;
6. 数据库查询1000 条数据可以在10s内查询完毕。
4 有线电视网络运营支撑系统测试研究
4.1 功能测试研究
4.1.1 前期分析
运营支撑系统 (BOSS) 系统流程复杂、功能点多且关联性较强。如果按照一般应用软件的测试方法进行测试, 即使耗费很大的人力、物力进行测试, 保证大部分功能点都正确, 也不能保证正常地使用, 因为BOSS系统的业务流顺畅、集成性高是更重要的要求。针对这样的难点, BOSS系统的测试重点应该放在流程的正确集成上。
以某地BOSS系统为例, 对其基础业务进行基本功能和主要流程测试, 用例设计首先使用场景法, 对系统运行流程进行分析, 从宏观考虑用例应包括的哪些基本流和被选流, 其次在设计具体的数据流时以业务流为驱动, 结合等价类划分、边界值分析、因果图等方法进行具体数据的设计。
以系统中数字电视业务场景为例, 主要业务流程如图1所示。
营业员根据客户需要, 在客户的住宅地址上新装数字电视, 其中会用到之前已发放到营业厅的设备终端和票据, 营业员提交受理时可选择是否上门施工, 提交受理后系统后台对相应设备做服务开通。
根据上面的流程图和软件使用说明, 可以归纳出一个比较清晰的主、备选流关系图, 如图2 示以及个路径与触发条件的对照表, 如表1 所示。
场景分析: 遵循如图3 所示的路径, 可以确定不同的用例场景, 从基本流开始, 将基本流和备选流结合起来, 可以确定各种场景, 如表2 所示 (表中只是列出部分场景) 。
以上所讨论的为BOSS系统数字电视业务几个模块之间的业务流程图, 同时模块内部还有比较复杂的流程, 在实际测试中我们不可能对所有流程一一验证, 我们应该在所有的业务流程中, 选择一个可以尽量覆盖所有场景的业务流程。我们通过建立路径触发条件与场景关系表, 如表3。
表3 中并没有将所有路径出发条件组合和覆盖的场景关系全部列出, 通过分析可以看出第5 组条件组合所覆盖的场景最多, 应该按照这个组合来设计测试用例。
通过以上工作, 我们确定了在BOSS系统功能测试中“性价比”比较高的流程, 以及出发流程所需的基本条件, 这样我们功能测试所测的数据就能够覆盖尽量多的流程分支以及功能点。反之, 如果盲目地选择流程进行案例设计, 结果可能是重要的流程分支及功能点没有覆盖到, 或者虽然流程分支及功能点覆盖到了, 单进行了大量的重复性劳动, 造成不必要的浪费。
4.1.2 用例设计
1. 基础信息管理
以某省BOSS系统为例进行用例设计, 在BOSS系统中常常会出现基础信息录入的情况, 但由于基础信息多为数据以及文字管理, 因此该类测试不列举流程图, 采用等价类划分法和边界值法对用例进行设计。
以身份证号录入为例, 在此用例中我们采用等价类划分法对身份证号录入进行测试, 所谓等价类划分是把程序的输入域划分成多个部分, 然后从每个部分中选取具有代表性数据作为测试用例的输入值。每一类的代表性数据在测试中的作用等价于这一类中的其他所有等价值, 也就说, 如果某一类中的一个输入值发现了错误, 这一等价类中的其他输入值也能发现同样的错误;反之, 如果某一类中的一个输入值没有发现错误, 则认为这一类中的其他输入值也不存在错误。
身份证号的要求和特点:
1) 身份证号码为18位, 不能多也不能少;
2) 身份证号码中出生年份不正确;
3) 身份证号码中出生月份大于12;
4) 身份证号码中出生月份小于01;
5) 身份证号码中出生日小于01;
6) 身份证号码中出生日大于31 ;
7) 身份证号码中出生日期小于当前日期;
8) 身份证号码中闰年二月不能多余29天;
9) 身份证号码中平年二月不能大于28天。
列出等价类列表, 如表4所示。
客户资料身份证号码输入的测试用例如表5 所示。
这个测试用例已经覆盖了全部等价类, 但对具体输入数据的测试还不够完善, 这时我们将引入边界值分析法。
边界值分析法不是选择等价类的任意元素, 而是选择等价类边界构建测试用例, 是对等价类划分法的补充, 在设计测试用例时, 对边界附近的处理必须给予足够的重视, 为检验边界附近的处理专门设计测试用例, 可以有效地弥补等价类划分对具体用例数据设计上的不足。
2. 综合业务功能测试
针对BOSS系统中业务流程进行用例设计, 对输入数据的可用性校验可以用等价类划分和边界值分析法进行用例设计, 不再详述。以下以综合业务功能中的业务受理的新装功能为例, 设计相关测试用例。流程图如图3 所示。
以某省已经进行过的受理流程功能测试, 用例步骤及结果如表7 所示。
4.2 性能测试研究
为了不影响生产系统的在线运行, 运营商会搭建一套与生产系统配置、环境数据完全相同的测试系统, 以便于在新业务上线时, 可以在测试系统进行验证后再上线, 减少生产系统的出错几率, 性能测试也同样在测试系统进行, 但为了数据的准确性, 有些运营商也会选择在业务量相对较少的深夜时间对生产系统进行性能测试以得到相对真实的数据
4.2.1 系统概述
以某省已建好的BOSS系统为例, 系统的部署情况如图4所示。
4.2.2 测试需求分析
测试主要对系统进行两次性能测试, 第一次性能测试为性能检测以及故障定位;第二次性能测试为对调优之后的效果进行评估, 测试主要在局域网内进行, 通过监控资源的使用情况, 重点定位应用系统以及软、硬件支撑环境故障。
4.2.3 测试指标分析原理与方法
80 ~ 20 测试强度估算原理:
每个工作日中80% 的业务在20% 的时间内完成, 以某省营业厅客户端登录系统为例, 全省共50 万个客户端, 根据以往的统计结果, 每年的客户端增加量为10%, 考虑到3 年业务发展的需要, 测试需按现有业务量的约1.5 倍进行。
测试强度估算如下:
每天的总的请求数为:50×1.5=75 万次/ 天;
根据二八原则, 每个工作日8 小时即每天80% 的业务在1.6 小时完成, 则系统每秒的登录请求数为 (75×80%) / (8×20%×3600) =4.17 次/ 秒;
即BOSS系统服务器处理登录业务请求的能力应达到4.17次/ 秒。
4.2.4 测试案例分析要素
1. 任务分布方法
1) 交易任务种类;
2) 在一天的某些特定时刻系统都有哪些主要操作。
任务分布表如表8 所示, 并发用户数根据不同的系统统计情况不同有不同的总数比例。
从表8 可以得到如下信息:
1) 下午一点, 交易混合程度最高;
2) 上午九点和下午两点是登录高峰期;
3) 登录并发用户数最大支持300, 考虑业务扩充需求, 最大并发用户数取450 ;
4) 客户查询并发用户数最大支持200, 考虑业务扩充, 最大并发用户数取300 ;
5) 其余业务与以上两种业务计算模式相同。
2.交易混合情况
主要关注:
1) 系统日常业务主要有哪些操作, 高峰期主要有哪些操作;
2) 数据库操作有多少;
3) 如果任务失败, 那么商业风险有多少。
选择重点交易的指标为高吞吐量、高数据库I/O、高商业风险。
4.2.5测试案例制定
1.测试用例
测试的主要内容为:对系统实施并发性能测试的同时, 对应用服务器以及数据库服务器进行资源监控, 实时查看资源使用情况。
2. 测试范围:
1) 系统并发性能测试;
2) 系统可用资源监控。
4.2.6 测试环境、工具、数据准备
1. 测试环境的准备
测试环境会直接影响最终测试结果, 所有性能测试都是在一定软、硬件条件约束下的测试结果, 测试环境的些许变化都可能对最终测试结果造成影响。
1) 性能测试环境原则
(1) 如果是在BOSS的生产系统上进行测试, 要尽可能降低对已经上线业务的影响;
(2) 如果是在测试系统进行测试, 测试系统必须要达到服务器、数据库以及中间件的与生产系统相一致, 并且有一定的数据储备;
(3) 需要考虑测试工具的软件和硬件的配置要求;
(4) 配置与业务相关联的测试环境需求;
(5) 测试环境支持交互操作;
(6) 测试环境支持安装、备份及恢复的过程。
2) 测试环境配置
(1) 业务运行的操作系统的版本;
(2) 传输协议;
(3) 服务器及工作站机器;
(4) 测试工具配置。
2.测试工具准备
BOSS系统性能测试主要使用HP Load Runner进行测试。
3.测试数据准备
由于测试工具在进行性能测试时会模拟出大量用户同时访问的情况, 或者在进行客户查询时需要数据库中有大量的数据储备可供测试, 因此在测试开始之前, 要求生产系统和测试系统都需要有一定的数据储备才能保证性能测试的顺利进行。
4.3 可靠性测试研究
BOSS系统作为整个有线网络的运营支撑的核心系统, 稳定可靠性是有线运营商最为关心的问题, 一旦出现宕机或者数据丢失, 运营商的损失将无法估量, 在一些意外造成BOSS系统中数据库服务停止的情况下, 如何尽快地恢复服务也是必须考虑的问题。因此, 对应用服务器系统以及数据库系统7×24 小时不间断运行的能力、数据备份、容错、以及容灾等能力进行测试, 并确定BOSS系统可靠性测试点如下:
数据库备份:查看数据库系统是否支持多种完全备份方式, 是否支持多种完全还原方式, 是否支持对指定库进行增量备份以及联机备份, 同时考察系统备份恢复的时间。
故障恢复:当系统出现故障或者存储介质出现故障的情况下, BOSS系统是否可以提供相应的恢复机制。
运行稳定性:应用服务器系统以及数据库系统的长期稳定运行能力是最基本的要求, 因此有必要对应用服务器系统以及数据库系统进行不间断7×24 小时的测试。
数据库复制:数据库系统是否提供了数据库复制的机制。
4.4 安全性测试研究
随着网络环境的日趋复杂, 广电系统已经不是早前相对封闭的单向系统, 要实现所有业务的大融合, 运营支撑系统作为业务融合开展的后台支撑, 需要与很多系统进行业务对接, 在开放的同时也就带了广电关于广电网络安全性的思考, 一旦运营支撑系统出现问题, 会是一个相对严重的连锁反应, 波及到广电系统的各个环节, 而广电作为一个政治属性存在, 是不能允许这种情况发生的, 因此对于BOSS系统的安全性考虑应该上升到最重要的环节, 防止不良事件的发生。
对于BOSS系统的安全性测试方法主要分为以下四个方面:
1. 功能验证
功能验证主要对BOSS系统中涉及安全的软件功能进行验证, 例如:管理模块、权限管理模块以及认证系统等进行测试, 查看功能是否能够正确实现。
2. 漏洞扫描
安全漏洞扫描通常都是借助于漏洞扫描器完成, 是一种自动检测远程或本地主机安全性弱点的程序。通过使用漏洞扫描器, 系统管理员能够发现所维护信息系统存在的安全漏洞, 及时修补漏洞。
漏洞扫描器可以分为两种类型:主机漏洞扫描器和网络漏洞扫描器。
安全漏洞扫描是可以用于日常安全防护, 同时可以作为对软件产品或信息系统进行测试的手段, 可以在安全漏洞造成严重危害前, 发现漏洞并加以防范。
3. 模拟攻击试验
对于安全测试来说, 模拟攻击试验室一组特殊的黑盒测试案例, 以模拟攻击来验证BOSS系统的安全防护能力。
4. 侦听技术
侦听技术实际上是在数据通信或数据交互过程, 对数据进行截取分析的过程, 主要用户BOSS系统在传输过程中加密的验证。
5 结束语
本文通过对有线电视网络运营支撑系统的系统组成、系统需求进行分析, 提出一个包括了功能测试、性能测试、可靠性测试、安全性测试的一整套测试方法, 对有线电视运营商对运营支撑系统的测试具有参考意义。
参考文献
[1]唐月, 秦䶮龙.有线电视网络业务运营支撑系统总体架构研究[J].广播与电视技术, 2012 (2) :100-105.
[2]唐月, 秦䶮龙.NGB业务运营支撑系统总体架构和关键技术研究[J].广播与电视技术, 2012 (S1) :110-122.
电视业务支撑平台 篇4
随着有线电视数字化, 尤其是下一代广播电视网络 (NGB技术的发展和三网融合试点工作的开展, 有线电视网络逐步开展了IP电话、视频电话等一系列新业务。过去, 有线电视运营商没有一套完整的包含业务配置及开通、业务保障和业务计量功能的BOSS, 许多系统都是为了满足某单一业务而在短时间内开发完成的, 如HFC用户管理系统、DVB用户管理系统、GIS系统等, 各系统间的互联互通缺乏周密的考虑, 产生了很多“信息孤岛”, 不能高效满足多业务开通, 无法实现多业务捆绑销售, 用户计费分散, 无法统一营业、统一出账及统一客服, 无法进行各省之间的互联互通, 使计费、结算方式还是粗放型;对客户的服务基本还处于被动的状态, 没有从企业运营的角度上采取“以客户为中心”的理念主动地服务于客户。同时, 为维护相互独立的几套系统, 在有线电视运营商本来就存在计算机系统维护力量不足的情况下, 造成人力资源的浪费, 也无法使运营商在竞争中脱颖而出。在开放竞争的市场背景下, 数据的整合和共享、面向客户的运营模式成为发展方向, 业务运营支撑系统的搭建将为有线电视运营商各种传统业务及增值业务提供综合统一开放的支撑平台。
在此背景下, 广播电视规划院对国际、国内电信多个有线电视网络运营商的BOSS进行研究, 组织运营商和软件开发厂家开展有线电视网络运营支撑系统总体架构标准的制订, 已初步取得了成果, 将对今后有线电视网络运营商搭建BOSS提供指导意见, 规范其建设, 以便今后的管理和互联互通。
1 国外运营支撑技术现状
1.1 ITU-T TMN
电信管理网络 (TMN) 提供一个有组织的网络结构, 以取得各种类型的操作系统 (OS) 之间、操作系统与电信设备之间的互连。提出TMN体系结构的目的是支撑电信网和电信业务的规划、配置、安装、操作及组织。
TMN最主要的标准之一是ITU-T M.3010, 它是关于TMN的总体要求, 涉及总体原则、体系结构、逻辑分层结构及基本功能要求。M.3400是关于TMN管理功能的标准;M.3200系列是关于TMN的管理业务及各种电信网上的TMN管理业务标准;M.3020是TMN的接口规范定义方法;M.60.2是TMN的基本术语定义;M.3100系列是TMN的通用管理信息模型。
1.2 TOM和e TOM
电信运营图 (TOM) 是由电信管理论坛 (ITU-T分支) 提出的一种网络管理模型, 用来替代陈旧的TMN模型。TOM的目的是定义电信运营的基本业务处理框架模型及其业务处理过程之间的相互关系。
根据TMN的逻辑分层原则, 在TOM体系中, 对电信业务处理框架分成以下几个层次:客户界面管理层、客户服务层、业务开发与运营层、网络与系统管理层、网元管理层。包括:销售、订单处理、客户问题处理、客户QoS管理、发票与收费、业务规划与发展、业务配置、业务问题处理、业务质量管理、计费帐务处理、网络规划与发展、网络提供、网络资产管理、网络维护与恢复、网络数据管理等处理过程。
TOM定义了3个基本的面向客户的端到端 (end-toend) 的服务:业务实现、业务保障和业务计费, 分别负责及时和正确的处理客户订单、及时处理客户和网络的问题以及及时和正确的处理帐单和收费。
eTOM是TOM的增强型版本。eTOM对服务供应商所必需的业务流程作了完整描述, 并定义了关键元素以及各自间如何相互作用。eTOM已经被ITU-T建议采纳, 即M.3050建议。
1.3 下一代运营软件和系统
下一代运营软件和系统 (NGOSS) 是“电信管理论坛 (TMF) ”提出的新一代运营支撑体系。NGOSS从系统 (即插即用规则) 、过程 (企业事务过程模型) 、信息 (关联处理公用数据) 、产品四个方面保证运营支撑体系具备标准化、能够逐步演化、保证互连互操作 (开放) 、实现端到端的管理和高度自动化的特点。
NGOSS提出了基于组件的面向对象的分布式OSS解决方案, 它的功能封装、接口协议定义等组件开发方法被业界普遍认可。
NGOSS架构主要包括企业流程抽象、共享信息服务和利用正式可交易的合同进行接口定义, 软件的组件化发展对NGOSS架构的形成有着重要的影响。新一代的运营系统和软件具有以客户为中心、软件设计组件化、企业流程抽象化、共享信息服务、实行接口合同等特征。
2 国内运营支撑技术现状
2.1 三大电信运营商
中国三大电信运营商中国移动、中国电信和中国联通, 在业务运营支撑系统方面已经积累了一定的基础, 运营商从2002年以来纷纷加强各自的BOSS系统建设, 提高网络管理、客户服务以及计费系统的业务支撑能力。但是经历了2001~2002年和2008年两次大规模电信运营商重组, 导致三大运营商在BOSS系统的建设上进度不一。其中, 中国移动的BOSS系统体系升级最为迅速, 电信和联通次之。
中国电信的CTG-MBOSS信息化规范体系, 从企业的管理和运营模式、业务流程、信息数据和应用系统四个层面着眼, 从信息化技术体系和管控体系两方面着手, 用于实际指导中国电信各省公司核心支撑系统MBOSS的建设。CTG-MBOSS的功能和技术架构由管理支撑系统 (MSS) 、业务支撑系统 (BSS) 、运营支撑系统 (OSS) 、企业数据架构 (EDA) 和基础平台构成。
中国移动的BOSS系统具有两个突出的特征:首先它是一套系统, 体现了一体化的业务支撑;其次它是省集中的建设模式。BOSS系统的功能范围包含了数据采集、计费处理、网间结算、客户服务、业务管理、综合账务、系统监控、联机指令、BOSS网管和数据挖掘等各个方面。现行的BOSS 3.0具有两级系统、三层结构的特点。
中国联通的规范体系核心是“一个体系, 多个子系统”。它的“UNI-IT”信息化架构包含客户关系管理系统 (UNI-CRM) 、管理支持系统 (UNI-MSS) 和企业资源计划系统 (UNI-ERP) 三个重要的组成部分, 该架构通过在企业运营管理体系、客户及业务网络之间建立有机的联系, 有效地支持着联通运营过程中的决策、规划、营销、业务产品开发、销售、客户服务和收入实现。2006年的《企业信息化规划》, 涵盖了IT战略、IT总体架构、IT管控、BSS、OSS、MSS、数据以及容灾规划等各项内容。
综合来看, 三大电信运营企业都建成了各自的运营支撑系统, 覆盖企业管理、客户服务、业务支撑以及网络管理维护等企业运营的各个方面。尽管在系统名称、建设模式等方面存在差别, 但总的来看, 各电信运营企业支撑系统都包括业务支撑系统 (BSS) 、网管支撑系统 (OSS) 与管理支撑系统 (MSS) 三部分, 其组成特点可以归纳如下:
1.从系统的部署来看, 主要集中在集团与省公司, 其中, 集团公司系统主要具备面向全公司的企业管理、经营分析等功能;
2.省公司从以职能管理为主逐步转变为以生产管理为主, 具有了越来越多的生产职能, 在运营支撑系统建设中的作用更加突出;
3.市公司的生产管理职能有所削弱, 将主要负责市场的具体营销、客户支撑以及设备的现场维护等工作。
2.2 有线电视网络运营商
我国有线广播电视网络经过20多年的建设和改造, 已建成330多万公里有线电视干线光缆网, 遍布全国城乡, 全国有线电视用户数1.87亿, 已成为传达政令、传播先进文化、普及科学知识、提供信息服务的重要渠道。随着三网融合的试点及稳步推进, 有线电视网络将更加开放、承载更多业务, 如何适应三网融合的新形势, 既充分发挥有线电视网络的技术优势, 又能在确保广播电视安全传输的基础上, 提高有线电视运营和服务能力, 建立适应市场经济条件下新的运营支撑系统是一项重要任务。广电系统从2005年开始建设运营支撑系统, 替换以前的SMS系统, 从而实现广电系统的全业务支撑。从2007年开始在广电兴起了“BOSS运动”。目前, 运营商在运营支撑上的投资已占到总设备投资的10%15%, 今后的一段时间内, 运营支撑系统市场将会集中于客户服务、计费等系统建设与改造上, BOSS系统建设完成后, 网络运营商的业务支撑系统将会得到大大的提高。
目前广电运营支撑系统还不是很成熟, 没有一个统一的标准, 各系统提供商都是在不明确的道路中摸索前进。在数字电视整体整转的过程中, 随着数字电视业务的逐步深入, 原来的业务系统成为制约广播电视发展的瓶颈。首先, 各分系统的用户资料不统一, 各种业务数据无法同步更新;每个业务系统分散且完全独立, 用户资料无法共享。所以广电运营商对用户数据无法进行客观、真实、准确地分析, 无法根据用户需求制定出合理的新产品以及服务, 更无法为用户提供个性化、人性化的服务。各种业务系统的封闭、分散, 使得运营商进行业务拓展或差异化运营无法实施, 独立运行, 相互间没有任何信息共享, 用户也不能多业务结合办理, 运营商的管理难度也随之增大, 这样不仅不利于各种业务的开展和各种新产品的推出, 还不利于广电的内部管理和协调。
3 有线电视与电信运营支撑系统的区别
有线电视行业和电信行业在管理体制、业务结构和运营模式上存在很大差别, 主要体现在:
1.业务经营的对象不同:电信行业主要是提供的是通信链路, 有线电视行业提供的是链路+内容服务, 所以更为复杂。
2.用户的消费习惯及方式不同:电信用户对电信产品的消费在时间上多是自由的、地点多是不固定的、消费主体多是确定的, 消费内容单一;目前有线电视行业用户消费时间多是不自由的、地点多是固定的、消费主体多是不确定的, 消费内容更加丰富。
3.经营模式不同:电信行业业务支撑复杂性在于一些实时性话单的准确性难度大, 对计费提出很高要求, 而有线电视业务主要还是在对内容组合和安全播控上。
4.市场化及规范化程度不同:电信行业经过多年的实践, 并结合国际标准, 总结出符合电信行业业务运营特点的运营规范;有线电视网络运营极具地方特色, 不同省市管理流程和业务环境有区别, 各地的差异性非常巨大, 再加上全行业没有统一的运营规范指导, 导致业务运营支撑的难度更大。
电信的运营支撑系统经历过以产品为中心向以客户为中心的转变, 这种转变对有线电视行业颇具借鉴意义。从技术架构和应用架构来讲, 有线电视网络业务运营支撑系统可以借鉴电信系统的经验, 但鉴于业务类型、用户规模、投入、业务架构和数据架构的区别, 不可照搬复用。
4 有线电视网络业务运营支撑系统总体架构
党的十七届中央委员会第六次全体会议通过的《中共中央关于深化文化体制改革推动社会主义文化大发展大繁荣若干重大问题的决定》中指出“整合有线电视网络, 组建国家级广播电视网络公司。推进电信网络、广电网、互联网三网融合, 建设国家新媒体集成播控平台, 创新业务形态, 发挥各类信息网络设施的文化传播作用, 实现互联互通、有序运行。”
这段话不仅为国家级广播电视网络公司的筹建打了一支强心针, 还要求有线电视网络业务运营支撑系统的建设水平更上一个台阶。我们提出的有线电视网络业务运营支撑体系的两级结构正好顺应了这种发展趋势。
1.体系结构
有线电视网络业务运营支撑体系结构分为两级:中央级和省级, 结构图见图1。
省级系统提供业务支撑、运营支撑、管理支撑及决策分析支持等功能, 为省级运营商进行省内业务管理和业务运营提供支撑和保障, 也对省级运营商实体的管理和决策分析提供系统支撑。
中央级系统对中央提供上述四个方面的支撑, 为全网 (跨省或国际域) 业务管理和业务运营提供支撑和保障, 为中央实体的管理和决策分析提供系统支撑, 此外, 中央系统还作为省系统跨省业务的中央枢纽。中央系统对省级系统还有一定的管理职能, 即两级系统间具有管理接口, 主要包括数据和公文的上下传送, 对省级系统某些功能进行查看和调用等。
2.功能架构
有线电视网络业务运营支撑系统包括业务支撑、运营支撑、管理支撑和决策支持四个功能系统和一个公用功能系统。功能系统由各个功能子系统组成, 子系统由功能模块组成, 功能模块中包含功能点。公用功能系统可嵌入四个功能系统实现, 功能架构如图2所示。
业务支撑系统实现营销、销售、服务一体化, 支撑全业务的运营;对营销计划、活动、营销绩效进行管理;整合客户接触渠道, 提供销售商机支持和渠道管理能力;展示所有个人、家庭或单位客户的客户统一视图, 提供统一接触管理和客户QoS/SLA管理;实现产品目录/销售品管理和产品生命周期管理, 支持灵活的产品配置;实现合作伙伴管理, 支持其业务部署及结算;实现实时、集中、融合的计费能力, 支持预付费和后付费两种付费模式, 支持按次、按流量、包周期等计费策略。
运营支撑系统主要实现统一的资源视图, 优化资源配置, 进一步提供面向客户的服务与体验、强化服务开通与服务保障能力。以精确管理为手段, 从面向网络、面向产品、面向客户三个层面建设高效的运维体系。面向服务和资源, 提供综合运行支持, 支撑有线电视网络运营商各类产品的开通与快速定位故障, 对网络性能参数和运维服务质量的实时监控、分析和管理, 包括服务开通系统、综合运维管理系统、综合资源管理系统、网络监控管理系统。
管理支撑系统面向企业内控管理, 通过信息系统规范、固化日常工作流程, 实现财务核算、管理会计、财务辅助、人力管理、项目管理、物资管理、办公协同、审计管理等管理流程的高效贯通。
决策支持系统通过对业务支撑系统、运营支撑系统、管理支撑系统的运营数据进行挖掘与多维度分析, 为企业经营决策提供依据。功能包括:科学决策、KPI管理、数据分析、数据获取管理、运营数据仓储管理和企业数据仓储管理。
公用功能是系统提供的一组公用功能, 可以被其它功能域引用, 包括操作权限管理、公告信息管理管理和日志管理。
省级业务运营支撑系统包括上述全部5个系统, 支撑全省的业务与运营。
中央级业务运营支撑系统 (简称中央系统) 除承担总部实体的业务运营支撑, 还应充当各省级网络之间的调度、协调和统筹的角色, 作为全国省级业务运营支撑系统 (简称省级系统) 之间的跨省业务枢纽。此外, 中央系统对省级系统具有一定的管理职能, 包括数据收集、公文传递、系统查看、系统监测、重大事件告警等。
中央级业务支撑系统提供对中央全国性业务的支撑, 同时提供对各省级系统跨省业务的结算和数据交换等功能。中央级系统具有客户关系管理、合作伙伴管理、综合计费帐务等功能。
中央级运营支撑系统包括图2所示的服务开通、综合运维管理、综合资源管理、网络监控管理等系统, 侧重于对国家广播电视干线网络运营提供支撑, 对全国性或跨省业务提供相关支持, 对国家广播电视干线网络提供监控、维护、链路开通等功能。
中央级管理支撑系统是面向总部各种事务的管理信息系统, 包括协同办公支持系统、人力资源管理系统、财务系统、项目管理系统、采购与仓储物流系统、知识库管理系统等, 对总部的人力资源、财务、资产、项目以及无形资源等进行统一管理。中央级管理支撑系统与省级管理支撑系统之间还应进行公文、报表等管理文件和数据的传递。
中央级决策支持系统在综合分析中央级和省级运营数据的基础上, 进行决策分析, 为总体战略部署和高层决策提供支持。
中央级系统的枢纽功能由上述中央业务支撑系统和运营支撑系统来实现, 连接全国各省级系统以及其他系统, 使之相互连通, 实现数据互换, 以达到服务全网客户的目的。其主要功能包括实现省级系统跨省业务的实时转接, 支持跨域结算等省间结算功能, 为跨省订单及资源调度作转发处理等。
3.数据架构
数据架构是为了实现数据的标准化、一致性、准确性和可靠性, 充分发掘数据价值, 有效支撑信息数据管理和经营决策分析, 实现数据的统一管理和信息的透明共享而制定的规划体系。通过对业务模型的抽象, 规划业务支撑域、运营支撑域、管理支撑域、决策支持域统一规范的数据架构、数据定义, 数据分类、数据分布以及对数据统一管理, 将信息与业务流程进行链接, 建立有线电视网络运营商信息数据架构, 使各信息系统之间无缝地共享和交换数据。
数据分为市场营销、产品、客户、服务、资源、合作伙伴、企业管理、公共事务八个主题域:
市场营销域、产品域、客户域数据主要涉及业务支撑域, 这几类域数据主要描述了企业的市场营销策略、渠道、产品设计、产品定价、客户信息、客户关系、客户帐务等相关方面的重要信息。这些信息主要来源和服务的对象是企业的市场、销售、客户服务和管理等方面。
服务域与资源域主要涉及到运营支撑域, 描述了可以提供的各类服务信息以及对有线电视网络运营商非常重要的资源信息, 如基础网络资源信息、IT资源信息等。这类信息主要应用在有线电视网络运营商的规划、建设、运行维护和网络管理等方面。
合作伙伴域主要涉及到与有线电视网络运营商相关的各种供应商与合作伙伴领域。有线电视网络运营商的相关供应商和合作伙伴, 包括网络设备提供商、网络建设施工商、节目源提供商、IT服务商、业务代理商、合作营业渠道商等。这些合作对象的相关基本信息、合同订单信息、服务水平、往来帐务等信息都需要专门储存和维护。
企业管理域主要是涉及基础管理信息, 包括人力资源、财务、资产和工程等, 也包括与战略和决策支持相关的、较高层面的应用信息。
公共事务域是将信息数据中的一些基本、常用的信息进行归纳得到的信息域, 如地域、合同、参与人等。
4.软件架构
有线电视网络业务运营支撑系统应用软件分为接入层、业务逻辑层、数据层三层。接入层是有线电视网络业务运营支撑系统与外部进行数据交换的平台, 分为界面逻辑、图形用户接口和接入服务。业务逻辑层是系统业务处理的逻辑平台, 通过对数据核心层服务子层原子服务的调用访问业务数据, 实现不同的功能模块, 满足不同的业务需求。数据层是系统对业务数据进行统一组织、集中管理的平台, 为业务逻辑层提供规范、高效的数据服务, 实现业务数据的充分共享, 是系统的基础。
5.基础设施
按网络能力, 基础设施分为以下四个部分:有线电视网络业务运营支撑系统接口汇聚层设备负责与外部的其它系统、用户终端交互;核心交换层设备负责连接业务运营支撑系统内部其它各层的设备;系统层设备负责完成系统的主要业务功能;存储备份层设备负责存储业务系统数据。
从分区域的角度, 将系统层和存储备份层整合为核心生产区, 有线电视网络业务运营支撑系统按网络层次可划分以下为四类主要的区域:核心生产区、内部互联接口区、互联网接口区和核心交换区。
按系统功能, 基础设施由计算、存储、负载均衡、安全审计、网管监控、备份容灾、业务运营支撑网络和服务交换及接口构成。
5 结束语
由于各地有线电视运营商的网络运营、业务开展和资金情况不同, 各子系统和功能模块可不必一蹴而就, 可以分期进行布署。有线电视业务运营支撑系统是一个综合性、支持全业务的大型软硬件系统, 为规范有线电视网络运营商的运营支撑系统的建设, 使系统良好运转, 还需要制订一系列标准, 包括数据、接口、流程、集成等, 使各运营商的运营数据一致, 各个系统能够互联互通, 上传下达, 建立符合全业务运营要求的可管、可控、具备安全保障能力的技术管理系统和业务支撑系统。
参考文献
[1]陈龙, 张春红, 云亮等.电信运营支撑系统[M].北京:人民邮电出版社, 2007.
[2]赵勇.电信运营支撑系统的现状与发展趋势[J].通信世界, 2009, (1) :10-11.
[3]陈立华.BOSS系统及其在有线电视网络中的应用[J].北京:广播与电视技术, 2006, (7) :108-112.
电视业务支撑平台 篇5
近年来, 我国电子商务市场发展迅猛, 交易额年均增长超过30%, 网购市场年交易规模超过1000亿。此外, 随着传统企业大量涌入电子商务行业, 大型垂直电商向综合电商发展, 自营电商向平台和自营混合模式转型, 电商盈利模式趋于成熟。为适应这种新的经营环境, 应对来自全球竞争者的挑战, 企业除要选择适合自身发展的商业模式外, 更重要的是要制定一个明确且行之有效的电子商务平台品类管理和运营模式方案, 以提高企业的竞争力[1]。
2014年, 国网公司立足国际能源重点发展领域, 考虑分布式电源和电动汽车快速发展等新形势, 结合国家关于智慧城市、城镇化建设的有关精神, 联合社会资源, 建设智能电网创新示范工程, 推动能源生产方式和消费方式的加快转变。这对客户服务电子商城及电网企业为用户服务指明了方向。电子商城的研究和探索也成为国网公司构建特色鲜明、体验卓越、模式领先的综合电子商务生态网络的理论准备和技术支撑[2,3]。
电子商城是以“电”为主线, 以“节能”、“智能”为产品特色, 以智能家居、电工电气和电动车等产品在线销售和配套服务为主要经营内容, 面向个人及企业客户提供商品在线交易的网上商城[4]。文章基于国网公司客户服务电子商城的发展趋势和要求, 提出基于移动互联客户端的电子商务支持平台架构, 有利于方便快捷地与用户沟通, 保证产品和服务符合用户需要, 从而用于指导国网客户服务电子商城建设, 为电网开展多业务互动服务并结合电商运营提供理论依据、技术指导及实践依据。
2平台业务分析
2.1智能家居业务
国家电网公司近期提出“要加快提升电网互动能力, 建设智能家居平台, 让普通家庭能够通过智能电网实现用户能源管理、移动终端购电、综合信息服务、远程家电控制等, 全面提高百姓生活智能化水平”, 因此智能家居任务对智能电网的发展具有重要意义[5]。家居智能化系统, 能实现如下控制功能:灯光控制、窗帘控制、家电无线控制、综合安防、紧急求助、扩展控制。
2.1.1灯光控制
灯光控制包括场景控制, 即家居智能化控制系统可预先存储每一种场景, 比如:离家模式、在家模式、看电影模式等。需要时, 只用在控制键或触摸屏上点选, 就可快速、准确地调出所需的灯光场景, 而不必对每一路灯光进行控制, 更为简单方便。自动控制运用于地下室、楼梯等区域, 上述区域的灯光可实现人来开灯, 人走关灯, 节省电能, 方便使用。
2.1.2家电控制
家电控制则主要包括电视、音响控制即通过触摸屏 (无线或有线) 可对所有的影视设备实现开关、选台、音量大小等所有的功能控制, 并在触摸屏上制作出形象逼真的操作界面。还有集中空调控制即根据需要可在家里安装温度检测设备, 可根据自身的需要设定温度范围, 通过家居系统可控制集中空调的自动开关、定时开关、调温等。
2.2电动汽车业务
电动汽车一体化销售服务平台建设以电动汽车销售为基础, 文献[6]提出以车联网平台电动汽车行车服务为增值服务, 实现商品及服务资源、运营服务资源的最优化利用, 增加用户黏性, 形成规模效应, 提升商城和商户收益获取, 实现公司和商户的双赢。主要业务包括:
(1) 根据车联网服务平台业务范围, 以电动汽车基本行车服务业务为突破口, 吸引车联网后装车载终端设备商家入驻电子商城。
(2) 通过营销资源共享、客户行为引导、联合销售等方式提高商城和车联网服务平台的整合服务水平, 形成电动汽车与行车服务产品的一体化销售。
(3) 拓展业务内容及营销模式, 逐步扩充业务融合范围, 包括生活服务、安全驾驶和数据服务等, 逐步行程电动汽车一体化服务生态链。
(4) 完成电动汽车试驾预定、销售, 以及充电桩一体化服务平台的搭建, 通过电子商城与车联网服务平台的业务融合和深度集成, 为用户、企业和政府提供实时、高效、智能的多样化服务。
(5) 整合商城电动汽车 (含充电桩) 销售服务商户和车联网服务平台内容提供商的优势资源, 打通电动汽车销售和服务的信息流通环节, 实现业务、信息和资源的互联互通。
2.3分布式电源业务
随着分布式电源的不断发展以及电网的不断改革, 分布式电源的接入已经成为智能用电十分重要的一个环节[7]。其中以光伏发电作为代表, 发展光伏发电业务, 为家庭光伏发电系统的用户提供一个便捷的查询平台, 让用户能直观查看家中的光伏设备的发电量。业务主要包括光伏发电信息查看即显示累计光伏发电量, 近一周, 近一年, 近一月等发电信息, 并通过图表形式直观展示, 提示节约能源信息。以及光伏设备管理即使用手机客户端随时查看家庭分布式光伏设备的工作状态, 进行设备参数设置, 控制设备发电和并网。还可以展示光伏的最新资讯, 帮助用户及时了解国家及行业相关政策。
2.4综合信息服务
综合信息服务主要包括知识库系统即建立综合信息知识库系统, 完善即时通讯工具、在线客服应用、客服管理应用、受理工单流转应用, 使之打造成服务优良, 客户满意度高和管理规范的客户服务系统[8]。还包括网上电费缴纳即提供电费信息服务, 用户在商城提供的多业务支撑平台中即可完成电费缴纳, 并可以查询到完整的缴费历史对账记录, 核对缴费金额等信息。平台还能够发现电器待机、忘关电源等情况, 及时发送消息通知。
3多业务支撑平台架构研究
基于第二章提出的平台业务分析, 提出多业务支撑平台架构, 主要包括系统管理、接口管理、业务管理以及数据服务。平台业务及支撑平台架构如图1所示。
3.1系统管理
系统管理是指管理企业的信息技术系统。它包括收集要求、购买设备和软件、将其分发到使用的地方、配置它、使用改善措施和服务更新维护它、设置问题处理流程, 以及判断是否满足目的。多业务支撑平台的系统管理为商城管理人员提供地区管理、用户管理、供应商管理、渠道管理、采购管理、客服管理、会员管理、系统设置等系统功能管理。
3.2接口管理
为了扩充经营范围、拓宽经营渠道、增强盈利能力, 将与多个系统和平台集成接口。包括与其他电商的接口管理、与营销系统的接口管理、短信接口管理等。
与第三方商城的接口管理:在与第三方商城商品信息、订单信息等业务数据集成之前, 需要将双方的基础数据进行集成, 主要包括商品品类、商品品牌、地址、快递商等信息, 为后续业务数据的集成奠定基础, 保证国网商城与第三方商城的无缝集成。营销系统接口:充分利用国网资源突出商城特色, 赢得客户资源, 吸引用户注册, 商城需引入95598网站电费查询、充电桩安装进度查等服务, 通过电子商城与95598网站的集成, 打通电网内外部信息流, 形成电子商务生态圈。与第三方物流系统接口:与第三方物流服务商的仓储系统与配送系统集成, 实现仓储一体化物流服务, 提升商户体验。
3.3业务管理
业务管理是指经营过程中的生产、营业、投资、服务、劳动力和财务等各项业务按照经营目的执行有效的规范、控制、调整等管理活动[9]。多业务支撑系统平台业务管理主要包括营销管理、商品服务销售、财务管理、服务接入、客服管理、合作伙伴管理。
3.4数据服务
数据服务是一种软件服务, 它封装了企业相关的关键数据实体的操作。企业数据被存储在多个系统中, 要想与之交互需要多个接口或多种机制。此外, 数据服务还要给不同渠道 (分支机构、在线业务、呼叫中心) 和机制 (事件驱动、随需应变、批处理) 提供服务, 这也给数据服务带来了挑战。对于数据消费者, 要是没有一个抽象层将之与这种复杂性相隔离, 企业中数据源和数据消费者之间的集成将会以一种意大利面式的点对点集成而收场[10]。
数据服务还能够执行关键的治理职能———它们有助于度量指标的集中化、监视、版本管理、数据类型的重用, 以及执行数据可视化和访问规则[11]。
4平台架构设计
4.1总体架构
按照电子商城的建设规划, 通过扩大业务范围, 提升电子商城核心竞争力, 提高电子商城系统智能性、可用性、安全性和完整性, 必须放眼未来, 固本培元, 创新发展, 有效利用内部资源, 借鉴外部成熟技术, 开展国网客服电子商城系统经营模式拓展建设。系统架构设计遵从电子商务系统总体架构设计, 在原有架构设计的基础上, 围绕电子商城建设需求, 结合电商业务发展要求, 通过最新技术的应用, 完成本次系统的建设。系统总体架构设计如图2所示。
4.2业务架构
在业务架构设计方面, 对于平台型业务, 电子商城建设以业务流程规划与完善为驱动, 从市场营销管理、商品服务销售管理、智能家居平台、合作伙伴管理等业务域出发, 进一步建设和完善电子商城业务流程。同时, 开展自营业务分析, 从采购管理、仓储配送管理、销售管理、财务管理、客户关系管理、供应商关系管理6个业务域出发, 建设具备国家电网特色的自营电子商城。结合项目需求, 电子商城业务架构如图3所示。
4.3数据架构
系统根据自身业务架构特点, 分析、定义、规划数据架构, 从数据分布的角度分析、定义、规划数据架构, 以确保数据架构为业务需求提供全面、一致、完整的高质量数据。
根据应用功能视图定义的功能模块, 电子商城涉及SG-CIM中归纳的12个数据主题域中的财务数据、客户数据、电力市场数据、物资数据5个主题域, 电子商城系统与SG-CIM相关一级、二级主题域关系如图所示
4.4物理架构
客户服务电子商务系统先在总部部署, 与现有客户服务门户在同一区域。随着业务规模的发展, 未来还要考虑生产中心平台的扩展 (例如在数据中心外再扩建新的数据中心) 以及辅助接入节点 (如租用运营商CDN网络) 的部署, 以提高对日益增长的客户访问的响应, 改善客户的体验。
5结束语
文章通过对平台、客户端的需求分析, 对多业务支撑平台架构的详细研究, 提出基于移动互联客户端的电子商务支持平台架构, 形成可推广应用的电子商城多业务支撑平台建设方案, 避免盲目建设造成的浪费, 降低建设成本, 有利于方便快捷地与用户沟通, 丰富平台业务内容, 保证产品和服务符合用户需要, 提升用户满意度。指导国网客户服务电子商城建设, 为电网开展多业务互动服务并结合电商运营提供理论依据、技术指导及实践依据。
参考文献
[1]穆峰.电子商务的价值链和赢利模式研究[J].电子质量, 2001, 12:126-128.
[2]王斌, 林丹明.电子商务经营模式的演化与创新[J].汕头大学学报, 2005, 4:49-52+91.
[3]王双萍.电子商务经营模式与策略[J].中国商贸, 2011, 23:103-104.
[4]邓祥明.企业电子商务经营模式研究[J].科技广场, 2008, 9:131-133.
[5]张秋霞.智能用电大数据及其应用探讨[J].科技展望, 2014, 21:130-131.
[6]陈启鑫, 刘敦楠, 林今, 等.能源互联网的商业模式与市场机制 (一) [J].电网技术, 2015, 11:3050-3056.
[7]杨宏宇, 朱信颖, 颜玮玮.大数据在电网中应用的价值研究[J].数字技术与应用, 2014, 9:90.
[8]段秋利.综合信息服务提供商的商业模式研究[D].北京邮电大学, 2006.
[9]张建军.云安全管理平台业务管理研究与实现[D].北京邮电大学, 2015.
[10]韩琳.数据服务平台的服务发布和数据访问研究[D].华中科技大学, 2012.
电视业务支撑平台 篇6
随着国家电网公司业务的快速扩展,各个部门建设的系统中公共构件占用了大量的开发资源和重复性劳动。根据国网电科院“十二五”的发展规划,实现集团集约、高效、科学、精益和规范运转的研发体系平台的目标[3],需要建立以集成产品开发为理论基础的先进研发管理体系。构建统一的产品平台、技术平台和资源库,以促进技术共享,提升核心技术竞争力以及降低产品开发成本。
在整合开放技术优势和第三方产品基础上,项目组推出了开放的、可扩展的集成开发云平台,为用户提供了全新的信息化行业解决方案。该云应用平台是可被实例化的服务框架,基于业务抽象的应用构造服务,把复杂的代码开发转变为快捷的配置构造,支持软件设计与实现的复用技术。能够通过可视化界面为企业应用开发者提供一种全新的、高效的、集成的与构造式的开发环境,为业务场景的建设提供了有力的支撑和友好的用户体验。
1 系统概述
在智能信息化时代的背景下,国内外研究可定制开发、快速搭建系统的机构不断涌现。目前具有代表性的是IBM公司的Bluemix。Bluemix集合了Dev Ops和Iaas,通过结合敏捷开发和底层的基础架构,帮助用户及开发人员快速部署混合云环境。它主要围绕着Web应用服务、移动应用服务、数据库服务、大数据服务和开发支持构建相应的服务。Bluemix帮助开发人员使用平台提供的可组合服务的软件产品,构建面向云时代的企业级应用。
目前针对电力业务系统的构造器平台还没有成熟产品。经过调研分析,国家电网内部业务系统主要存在以下方面的问题:( 1) 各个业务系统通用的工具性构件,产生重复开发工作; ( 2)对于公共构件的使用,开发人员仍需要大量代码开发进行界面组织、属性配置和工作流设计; ( 3) 消息在业务间、公共构件间的消息传递没有统一的规范; ( 4) 外部市场的项目权限管理弱化了组织的分层概念[10]。
So Grid云应用平台以可视化的方式快速搭建业务应用系统,配置化实现构件属性的管理,向导化的方式完成应用的开发。通过选择系统框架和公共构件工具进行系统环境的搭建,使用相应的工具实现页面的定制化开发和业务应用的构造。
So Grid云应用平台提出“一群、一库、一容器”的构建思想,分别为服务构造群( CSG) 、构件库( CMP) 和运行时容器( RTC) 。三个子平台相互关联与依赖,其中服务构造群提供的各层构造服务的产出成果生成构件库中的各类构件、运行时容器的运行环境和运行与监控引擎。目前So Grid主要应用在Web应用系统的建设,未来将扩展到复杂事物处理等云应用产品系列。
2 So Grid平台设计
2. 1 总体架构
So Grid云应用平台作为Paa S( Platform as a Service) 上的服务模块,提供丰富的可重用构件的静态存储和管理库。用于面向云时代的企业级应用的开发、部署和运维云平台的搭建; 支持可扩充构造服务群,创造了全新的开发模式; 构件的运行时承载容器,提供动态运行、全面监控和优化策略。
服务构造群: 各业务构造器构造出的成果作为业务构件在构件库中进行管理; 同时构件库中的构件也应能够回馈到构造服务群中,进行业务的修改或基于技术层构造的改变而重新构造。服务构造群应用基础设施构造层和开发框架构造层的构造服务的成果描述运行时容器的运行支撑环境,以构件库中技术构件的形态存在; 同时业务构造层的监控构造服务基于业务的需求构造的监控服务业生成运行时容器的监控引擎。
结合国家电网的统一开发平台和基础框架的技术特点,So Grid云平台的整体框架结构设计如图1 所示。
2. 2 功能设计
So Grid云应用平台是为了支撑各项目中心业务场景的快速搭建工作,利用可视化界面进行构件重组的全新开发模式,节省了大量的设计开发工作。云应用平台开发业务系统的主要流程包括分析设计、应用构造、集成部署和运行监控四个步骤,系统构建的开发流程如图2 所示。
2. 2. 1 分析设计
软件生命周期中,需求分析是系统开发的关键阶段,需要对用户的业务活动进行分析,明确业务系统的功能需求和性能需求。设计阶段需要将复杂的业务系统进行模块划分与设计,建立模块间的接口和组织结构关系。
针对用户需求的动态变化问题,该平台的分析设计采用树形图构造方法,将分析设计转换为模块间可视化的调用关系和层次结构,树中的每一个节点代表一个模块,连线代表调用关系。开发人员可以根据需求变化动态地添加修改模块节点,具有高内聚低耦合的特点。
开发人员能够根据业务需求进行末尾功能节点页面的原型设计,可视化设计界面提供了展示页面模板的搭建和测试功能。控件货架中包括基本控件、布局控件、数据控件、表单控件和UAP控件等丰富的控件资源。通过可视化拖拽控件和页面属性配置实现页面的快速开发,同时开发人员可以更改源码进行个性化界面的定制开发。
2. 2. 2 应用构造
应用构造是系统搭建的核心阶段,包括系统构造和业务构造。构造服务群提供丰富的、可扩充的多种组件,开发人员可以选择框架和中间件,基于业务抽象的业务应用构造,把代码开发演变为组件的构造配置,适应于不同的业务场景的快速部署[1]。
(1)系统构造
系统构造为业务构造提供底层的基础支撑和集成封装接口,包括丰富的服务层构件和构造模型图。
目前组件货架分为应用基础服务层、开发框架服务层、业务构件服务层和监控服务层。应用基础服务层包括数据库构件、中间件和运行构件库; 开发框架服务层包括平台框架、JS框架、集成框架和引擎框架; 业务构件服务层提供了丰富的业务构件库和通用构件库[5,9]; 监控服务层包括客户端监控、系统监控、数据监控、网络监控和消息监控等多种监控。在系统构造过程中,可以通过点击或拖拽货架中需要的构件,自动配置到系统的构造模型图中。同时单击构造模型图中的构件图标能够取消相应的构件,系统构造完成后可以直接保存预览。
(2)业务构造
业务构造是基于系统构造的业务应用搭建,包括基础框架、页面构造、流程构造、监控构造和数据模型。
基础框架设计包括三分页框架、消息框架和权限框架。三分页框架通过可视化界面选择分页、样式、菜单和top设置项,以上每项提供了多种设计效果。消息框架和权限框架可以自定义配置属性,满足了不同用户的的场景设计需求。业务构造的原型界面设计如图3 所示。
页面构造设计分为数据访问模型、数据显示模型、展示页面模板和测试功能。数据访问模型和数据显示模型选择所属模块对应的数据模型,并且具有配置模型基本信息、选择数据表、列属性设置、条件设置与SQL语句自动生成功能。列信息界面可以进行数据库界面配置,包括基本信息配置、验证表达式、平台组件专有配置、uap平台公共组件配置和数据表单专有配置,以及添加删除新列信息。展示页面模板分为工具箱和模型设计界面。工具箱提供丰富的控件资源库和页面信息配置[2],模型设计界面利用可视化拖拽式和参数配置技术,完成业务应用系统界面的构造。构造成果按照平台技术规范生成描述文件和构件包一同保存到构件库中,构造包的业务场景信息与描述文件之间存在映射关联,同时构造器实现对构件库中构件包的修改及版本管理。
流程构造结合菜单和流程图构造界面展示业务功能模块的设计流程。设计或开发人员直接基于功能设计中的业务流程需求,实现在线流程的可视化设计。选择树形图的叶子节点可以查看或编辑对应业务模块的基本信息、流程状态等信息。如图4 是员工报销系统的流程设计界面。
监控构造设计将监控程序进行模块化封装,采用多元化的监控方式实现对业务系统的监控,可以搭建业务系统的多性能指标的监控。平台提供了服务端监控、系统监控、业务指标监控、网络监控和数据监控等多种服务,自定义设置阀值和告警功能等灵活的配置,为后期的运行提供保障。数据模型设计实现对所属模块的数据模型的选择,数据库中数据表结构、数据操作和数据表的约束依赖等配置。
2. 2. 3 集成部署
So Grid平台的集成部署介于构件库和运行时容器之间,可以实现独立物理部署和云部署两种方式。其中云部署不依赖特定的云平台,部署时的资源需求来源于构件库的构件包。构造完成的应用作为服务部署到云平台中,能够实现业务应用的多实例扩展,并采用适配器模式保证云平台间的可移植性。部署界面以矩阵方式展示可以部署的模块,点击所要部署的一个或多个模块节点,通过可视化界面定义待部署的项目模块的信息和节点性能的需求参数[8]。
集成部署优化了业务系统部署的功能,提高了部署的远程控制管理[7],促使部署适应于不同的应用场景,同时能够减少人工活动的参与以有效提高操作执行效率。
2. 2. 4 运行监控
监控系统主要对业务系统、服务器、数据库、中间件、消息和日志文件等多种监控功能,辅助开发或运维人员对系统进行全面高效的维护管理。So Grid平台的运行监控的是运行时容器的重要体现,来自构造服务群里监控构造服务的成果,提供了系统层、中间件及业务应用层全方位运行状态的监控,并提供安全策略进行可配置的在线控制调优。运行时监控可以作为独立服务,负责监控所有基于So Grid平台部署的应用系统。运行监控根据云平台提供的虚拟化资源的运行数据与云平台进行功能交互,运行监控的设计提高了业务系统的监管优化能力。
在云部署模式下,运行监控通过云平台的接口获取云计算提供的运行资源的状态数据。该接口采用资源监控适配器模式对应虚拟机或中间件等多种资源管理层,适应不同的云平台。平台的部署与监控架构设计如图5 所示。
运行监控通过图形化界面直观展现了系统的整体性能和各项指标曲线图。通过实现端到端的监控,对监控的业务逐级到代码调用层面,清晰定位到业务的性能瓶颈。运行监控是在统一集成环境中管理多个业务系统的状态和性能表现,多个业务模块使用同一个代理,与平台无关且支持面向对象。
3 平台特性与应用分析
3. 1 平台特性
So Grid构造平台是面向国网业务系统的软件产品线。通过结构化的基础框架,公共构件和开发流程等过程,支撑业务系统的快速搭建和配置的全面解决方案,提供可视化构件开发平台。通过事件驱动引擎和算数模型控制器,集成各种设计器和业务模板,利用可视化的方式拖拽构件、配置属性和工作流,完成业务场景应用系统。
So Grid云平台主要包括以下四种特性:
( 1) 丰富的构件库。提供了丰富的通用技术构件和业务服务构件,适合于不同业务场景的快速开发。通过基础服务配置和可视化构件复用,适应于不同用户群体的要求,实现了业务构件的可复用性和多种业务场景的变化需求。
( 2) 可视化开发。构件货架中展示了多种类别的丰富组件,开发人员通过直接拖拽组件并配置属性的方式快速、直观地完成业务场景的搭建。
( 3) 统一的开发规范。基于开发平台So Tower和SG-UAP,在统一的架构和规范下,为开发人员提供了分析设计、构造、部署和运行监控的统一手段,实现了业务构件的可复用性和资源共享,有效提高了开发效率和系统的稳定性[11]。
( 4) 全生命周期开发环境。提供面向企业级业务应用的集成开发环境,基于模板的向导机制完成共享资源的管理和部署,支持权限管理、组织机构管理和参数的动态配置功能。
3. 2 应用实例分析
So Grid构造平台已经应用到基建管理信息系统、员工报销系统、营销费控系统、人资管理系统、科技管理信息系统等,并且为系统项目组提供持续的技术支撑,为项目组解决了很多项目技术难题。支撑项目平均节省30% 人力成本,节省约70% 的开发工作,目前项目应用统计信息如表1 所示。
4 结语
本文通过整合各个业务中心的业务需求,研发支持快速构建、部署和管理的构造系统。So Grid平台包括分析设计、应用构造、集成部署、运行监控四个流程,有效支撑了国网公司的内部业务系统的搭建工作,减少了构件重复性工作,制定了统一的开发规范。随着框架服务的不断完善和技术改进,下一步的工作将建立基于多智能构件的知识复用模型,深入研究业务逻辑的构建模型和智能构件的活动配置[4],实现云计算和移动应用解决方案,增强业务构件的可扩展能力和构件服务平台对大数据的分布式处理,有效提高国网公司业务系统的建设水平。
参考文献
[1]Alan W B.Large-scale,component-based development[M].USA:Prentice Hall PTR,2000.
[2]陈宵,吴毅坚,彭鑫,等.采用构件组装技术协同开发Web应用的方法[J].计算机科学与探索,2013,7(2):114-125.
[3]国家电网公司.关于国家电网公司“大规划”体系建设方案的报告[R].北京:国家电网公司,2011.
[4]蒋伟进,许宇晖,张莲梅.基于MAS构件技术的复杂知识复用动态演化模型研究[J].系统工程理论与实践,2013,33(10):2663-2673.
[5]康知金,张宏国.基于构件组装的项目管理系统开发研究[J].计算机应用与软件,2010,27(2):184-187.
[6]李顺,王焘,宋云奎,等.面向OSGI框架的软件构件监控方法的设计与实现[J].计算机应用与软件,2014,31(4):1-6,58.
[7]乔亦民.基于构件的业务基础平台研究与设计[D].江苏:江苏大学,2013.
[8]丘昌程.云计算模式下主动服务架构的研究[D].武汉理工大学,2010.
[9]王祥宗,刘志,刘增良,等.基于规则的业务构件组装规约[J].计算机集成制造系统,2008,14(9):1774-1780.
[10]尹洪苓,曹占峰,王琰洁.规划计划管理业务应用支撑平台[J].计算机系统应用,2014,23(5):64-68.
电视业务支撑平台 篇7
关键词：固话,预付费,平台,搭建,安全,扩容
随着电信技术的发展和电信市场的成熟, 固话运营商在面对传统的后付费业务带来的营收款回款压力尤为突出, 近年来, 电信企业在业务收入快速增长的同时, 用户欠费也是逐年增多。有关资料显示, 中国电信行业固定电话拖欠费占电信行业营业额的7%;如果按照电信业务每年保守的7000亿营业额计算, 那么每年仅用户欠费就高达490亿。为了减轻回款压力, 某省电信运营企业计划对新开发的固话套餐业务在平台进行预付费处理。
下面就该业务平台提出相关的搭建思路
一、平台的逻辑结构
为了满足这一需求, 计划采取智能业务平台来实现, 核心软件功能是呼叫控制及资源管理。基础硬件设施是与电信业务网 (PSTN) 进行承载及信令连接的交换机等设备。整个系统分为业务运行环境、业务支撑环境和系统维护环境。其中业务运行环境, 包含交换、路由、计费、认证、应用流程等功能部件, 是业务实现的核心子系统, 主要完成路由计费策略设置、业务流程控制、主叫识别认证、实时计费、等功能, 是整个运行系统的核心。业务支撑环境包含计费路由管理、业务应用管理、结算账务管理、话务分析管理等。系统维护环境主要完成系统配置管理、系统用户及权限管理、数据备份管理、日志管理以及声光/短信报警等。
二、软件架构、硬件组成和运营管理
(一) 软件架构
1. 软件架构1+1冗余。整个软件系统包含业务支撑模块、业务运营模块、维护管理模块。每个模块的功能以服务的方式启动, 并且都可以启动一个冗余的服务。一旦主服务因故停止工作, 冗余服务会马上启动接替它的工作, 不会造成服务的停止, 保持业务正常、平稳运行。
2. 可迅速生成业务。能够提供灵活方便的开发环境 (中间件) , 让第三方能移植已有的业务或快速开发新业务, 而不需要接触复杂的交换系统底层开发。
3. 平台的运行环境支持UNIX;WINDOWS NT。
4. 软件主要应具有的功能模块。
包含 (1) 计费功能模块; (2) 路由功能模块; (3) 监控功能模块; (4) 测试功能模块; (5) 话单服务功能模块。
(二) 系统硬件组成
系统组成概述:该业务系统主要由前置交换单元、呼叫处理单元、数据处理单元、Web服务器组成。
1. 前置交换单元。
前置交换单元由电话网络接口、DSP服务资源和语音总线组成。它基于语音总线结构, 所有组件都为插板方式, 支持多节点配置, 具有很强的扩展能力。
2. 呼叫处理单元。
呼叫处理单元采用高性能控制主机, 运行呼叫处理软件, 提供呼叫控制、路由管理、服务管理、连接管理、资源管理等功能。
3. 数据处理单元。
数据处理单元为整个系统的运行数据, 包括系统数据、业务数据、运行日志, 提供集中的数据存储、备份、恢复和容灾手段。
4. Web管理服务器。
整个支撑系统包含了系统管理、操作员的管理, 业务的管理、代理商的管理、费率的管理等多种综合模式的管理。同时Web管理服务器有着很强的跨平台性, 根据用户的不同的需求, 支持Windows2000、Linux、Solaris等多种操作系统。 (下转160页) (上接158页)
(三) 运营管理
1. 业务模式。
用户开户方式为用户到营业厅 (或代理商营业厅) 登记。预付款方式可通过营业厅、代理商登录WEB系统进行缴费充值, 也可通过预售的充值卡充值。业务流程实现方式是对所有在平台登记过的电话号码, 需在局端交换机设置数据。
2. 业务功能。
包含 (1) 一个账号管多个号码。 (2) 余额报警。 (3) 计费方式:实现多费率动态设置, 多种计费方案。 (4) 月话费限额管理。 (5) 帐单功能。 (6) 权限管理。 (7) 业务统计和分析。 (8) 充值方式管理:A.可购买充值卡向账号进行充值。B.通过营业厅或代理商向账号充值。
三、系统安全
作为一个完整的系统, 网络安全是重点考虑的问题, 为此建议系统采用多重防护措施。1.层次的网络结构。每个系统网络结构采用多层分布式的方式建设而成, 整个系统采用硬件六层防护措施, 基本上保证了系统安全性和可靠性。2.独立的平台运行环境。基于网络安全的设置, 使系统平台处于一种独立的环境中运行。底层平台只是处理和PSTN交互的数据, 其他的数据全部在外围解决, 从而保证系统的正常、稳定运行。
四、系统扩容