移动电话综合业务管理系统的关键技术研究(1)
发布时间:2006-10-14 7:53:48   收集提供:gaoqian
移动电话综合业务管理系统的关键技术研究(1)(胡访宇、王培康、袁平波) 摘要 本文围绕移动电话综合业务管理系统的业务需求,着重讨论了应用软件体系结构 的设计以及移动计费和业务管理系统中部分关键技术,其中包括多层结构的实现技术, CBD和软件总线的应用,参数驱动的实现策略,重单检查处理方法,最后介绍了移动交 换机电子工单处理系统的实现。 关键词 移动电话 业务管理 计费 1前言 近年来我国移动通信事业发展速度令世人瞩目,随着移动电话用户数量的迅速增加 及市场竞争局面的出现,移动电话运营商迫切需要一个结构合理、功能完善协应灵活的 业务管理系统,为移动电话业务提供强有力的支撑。自1994年起,我们开始移动电话计 费、结算、营业、账务和客户服务等支撑系统的研发,并形成产品化的移动电话运营支 撑应用软件——“超越-2000移动电话业务综合管理系统”。本文将介绍我们在软件的 设计、开发、测试和维护等工作中的一些体会和认识,以便对读者有所借鉴。 2应用软件体系结构的设计与实现 2.1应用系统的体系结构选择 2.1.1目前的体系结构及缺陷 移动电话业务管理系统是典型的数据库应用程序,在逻辑上通常由两部分组成:一 是数据库访问链路,二是用户界面,这就是所谓的数据库应用程序的体系结构。而客户 机/服务器(C/S)模式由于具有许多优点已被广泛接受,该模式在电信营业、账务和 客户服务系统中应用尤为广泛。但是许多应用均采用传统的两层C/S结构(如许多地区 的电信97系统)。随着业务网的发展和系统规模的不断扩大,两层 C/S体系结构的不足 和缺点逐渐暴露出来。 在两层C/S体系结构下,所有的应用程序都是客户,客户通过数据库连接与数据库 服务器交换数据。一个服务器可以同时处理许多客户的请求,协调访问并且更新数据。 该模式主要具有以下缺点: ·客户机端不仅要完成用户界面(表单)处理,还要负责维护数据访问链路,导致 了客户机太“胖”。 ·数据库服务器不仅要负责数据逻辑的实现,而且还要负责客户端的连接处理和应 用逻辑(也称为业务规则)的实现,导致数据库服务器也太“胖”,并使数据库服务器 的处理性能受到影响。 ·客户机直接对数据库服务器进行访问,客户程序必须详细了解数据库的结构,各 种数据的存放位置,这既难以实现客户程序对数据库的透明访问,又使数据库系统直接 暴露在客户端,不利于数据库系统的安全。 2.1.2多层体系结构及优点 为克服两层C/S结构的缺点,多层的客户机/应用服务器/数据库服务器(C/S/S) 模式应运而生。在逻辑上,C/S/S结构中的客户程序、应用服务器和数据库服务器分布 在不同的机器上。在物理上,这些机器既可以在一个局域网内,也可以在Internet上, 应用服务器和数据库服务器既可以使用不同的主机,也可以共用一套主机。 多层体系结构最大的优势可以概括为三点,一是集中化的商业逻辑,另一个是客户 程序可以做得很“瘦”,再者是提高了系统的安全性。多层体系结构的优势具体如下: ·作为多层结构中的中间层,应用服务器集中实现了应用逻 辑,客户端的应用程序可以把重点放在显示数据和与用户 交互上,客户程序甚至都不需要知道数据存储在哪里。 ·在一个共享的中间层封装了商业规则。不同的客户程序 可以共享同一个中间层,而不必由每个客户程序单独实 现商业规则。 ·客户程序可以做得很“瘦”。因为很多复杂的工作由应用 服务器代劳,客户程序只需要关注用户界面本身。“瘦” 客户程序更容易发布。安装。配置和维护。 ·实现了分布式数据处理。把一个应用程序分布在几台机 器上运行,可以提高应用程序的性能,通过冗余配置还 可以保证不会因为局部故障导致整个应用程序崩溃。 ·有利于安全。可以把一些敏感的功能放在有严密防护措 施的层上,同时又不至于使用户界面变得复杂。例如,可 使用CORBA(公共对象请求代理结构)或MTS(微软事务 服务器)控制访问中间层,再让中间层去处理登录数据 库的细节。这一点也是许多对安全性较敏感的信息系 统,即使在客户端并不是很多时也采用多层结构的重要 原因。 “系统规模在多大时才需要采用C/S/S多层结构?”虽然关于这一问题目前还有争 议,但随着业务网的发展和应用环境的日趋复杂,在移动电话营业、账务和客户服务系 统中,多层C/S/S应用软件体系结构更加适合,这一点已是不争之事实。因此,今后在 进行移动电话业务管理系统应用软件研制和选型时,建议应优先考虑采用三层C/S/S应 用软件体系结构。 2.2 CBD技术与软件总线 2.2.1为什么要采用 CBD技术 移动电话业务管理系统在实际应用中的一个突出特点是其业务需求和业务规则的变 化较大和较快。由于业务网本身的快速发展和出于市场营销策略的需要、局数据、计费 原则和方式、结算方式和结算对象、营销模式、优惠模型和套餐服务种类、反欺诈举措 等等,均随时可能改变。虽然采用“参数驱动”方法可在一定程度上减少因业务需求改 变而对应用软件的调整,但是参数驱动也有许多局限性,例如,在系统设计和开发阶段 就把将来业务需求和业务规则所有的变更可能性都要考虑周全,这是不现实的,也是不 可能的。往往在业务需求进行较大的调整时,应用软件也必须进行相应的改动,包括改 写部分处理程序、增加新的功能模块、对模块重新进行配置等等。另一方面,应用软件 的改动又不允许对正常的业务活动产生影响,否则,运营商在进行经营决策时,必须考 虑业务管理系统是否能提供技术支持;如果不能,需要多长时间才能完成软件调整等诸 如此类的问题。这就是所谓“技术导向”型业务管理系统的弊端。如何能使应用软件可 根据业务需求的变化迅速进行调整,真正使业务管理系统从“技术导向”型转变为“业 务导向”型,采用CBD技术和软件总线是解决上述问题的一个利器。
 
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50