`

电信系统架构方案

阅读更多
国内软件业曾有人对行业性软件进行划分,在几个较大的行业中,排行前几位的分别是:通信、电力、金融……

但从对技术的要求与和安全性的要求上来说,通信行业的计费和金融行业的交易都是并称的。因此在通信行业软件形成之初,计费就成为了通信行业的核心软件,能否有实力作计费软件成为在行业中是否具有实力的标志。于是也就形成了中国通信行业著名的“九七”工程!这是完成电信行业核心业务层面的信息化工程。

继“九七”工程之后,2001年,中国的各电信公司根据国外电信公司的信息化进程和经验,总结提出要建立中国电信公司的运营支撑系统,这个系统是基于“九七”工程外围的运营支撑业务构建起来的,如果说“九七”工程是心脏,那么运营支撑系统就是四肢!心脏是为了提供肌体的动力,四肢才可以通过各种形式来获取利益,使心脏能继续生存下去。运营支撑系统在中国电信集团公司被称为“OSS”系统,全称是“Operation Support System”,在中国移动通信集团称为“BOSS”系统,全称是“Business and Operation Support System”。

在电信集团提出构建运营支撑系统的同时,各电信分公司还在筹划构建符合自己特点的ERP系统,与此同时,基于运营支撑系统之外的各种行业业务系统也开始了开发与规划。

电信行业软件历程

一、九七工程

九七工程是中国通信行业软件最初的形象。实际上在实施九七工程的时候,中国的通信行业基本上还是一家垄断的状态,那就是中国电信!

九七工程主要解决了电信行业最迫切需要解决的交换、计费、帐务、经营等最关键的业务过程。这些业务要求实时性非常强、对准确性的要求也非常高,因为系统的每一个数据都关系到电信的直接收入。

一些国内的软件公司借着这股春风发展了起来,也有一些公司从此开始涉足软件行业。

从技术和行业的应用成熟度来说,当时进行这项工程的条件是不具备的,但是,这项工程的实施却是必须的。所以,在实施这个工程的过程中,不少系统都是多次返工,虽然达不到实际意义上的7×24,但是至少可以得到比其他方式更精确的数据信息,这也就是这项工程的一大意义了。因此,在此后,尽管1997 年早成为过去,但是九七工程这个名词却一直被沿用下来,以代表这个特殊的意义——中国电信行业的第一次信息化。

二、OSS/BOSS系统

2001年,中国移动开始规划“BOSS”系统,2002年各省移动公司分别制定了自己的“BOSS”系统的技术规范和业务规范,但是,离真正实施还有一段时间,因为中国移动还需要进行统一的规划。

在中国移动制定规范的同时,中国电信集团也不甘落后,也开始制定自己的“OSS”系统的规范和实施规划,并在其上海研究院进行相关的试验。不过,因为其工作量过大,按照初步的估计,一个省级电信公司要实现“OSS”系统的规划,至少需要五年,投入至少有3到5亿以上的资金。按照这样的估算,中国电信集团要实现全国的“OSS”规划至少就需要90亿以上的资金投入,所以,一直到现在,中国电信集团的“OSS”系统还仍然无法进入实施阶段。

其他的电信运营商,诸如中国联通、中国网通、中国铁通等公司也都在纷纷筹划自己的相关系统。

技术方案概述

一、B/S结构

随着软件技术和网络的发展,各种行业软件业几乎都在进行着B/S与C/S结构的争论和演化。虽然大家都认为B/S结构更先进一些,但是,在某些特定的行业和业务中,C/S结构的系统仍然有着非常重要的地位和不可替代的作用。

加上B/S结构产品的开发难度要远大于C/S结构的系统,调试和测试工作都要比C/S结构的产品复杂得多。在此条件下,基于成本和效益的各种方案对此有很大的影响。

经过长时间的研究和探讨,通信行业的产品在体系结构上基本达成一致:在业务操作实现领域采用B/S结构,在某些特殊的功能实现上适当地采用C/S结构。

二、多层结构选择的必然

提到体系架构的选择,电信行业的大多数业务对系统的实时性、稳定性要求都非常高,因此电信行业软件业就成了所有软件中开发难度最大的一种。

目前国际上流行的两种软件体系,都采用了多层体系来进行大中型系统和关键系统的构架。

电信行业项目的实施中,也大都采用了中间件进行整个体系的构架,在J2EE体系成型之前,大多数系统都采用C/C++进行开发,一些关键的业务实现则采用 Corba体系。随着Corba与J2EE的融合,两大对立阵营的.Net与J2EE逐渐成型,电信领域的大型系统大部分都采用了基于Java的多层体系架构。如图2所示:



Web服务器:在Web服务器上,部署的是系统的表现层,用户通过浏览器进行浏览和信息交换。

应用服务器:主要提供组件的生存支撑环境,提供业务逻辑搭建的基础。

三、体系架构的选择

目前流行的两大体系是.Net和J2EE。

由于微软的产品大都稳定性、可靠性较差,虽然上手非常容易,但这恰恰不能达到电信行业对于可靠性的基本要求,所以,从体系到产品,微软都被全部屏蔽于行业重点业务的实现之外。

J2EE体系得到了较多大型厂商的支持,同时融合了Corba对语言无关性的特征(虽然其真正的可用还需要一段时间)以及其他优势,目前已经得到了绝大多数电信公司的认可,在通信行业领域内的开发商和集成商也都纷纷附和。

四、语言的选择

对于语言的选择,新的电信行业软件做了非常慎重的考虑,既要保证效率和实时性,还要能提供足够强大的稳定性,在J2EE推出之前,包括国外的电信行业项目也大都采用C/C++开发,但是,因为C++本身所固有的问题——内存泄漏,所以,系统的稳定性总是很难得到保障。

Java出现后,由于Java自身对C++的补充,稳定性方面得到了极大的提高。但,同时也发生了一个问题:因为Java需要运行在Java虚拟机上,经过这样一次解析后,其运行效率和速度都受到了很大的影响,当进行大数据量查询和统计分析的时候,Java的速度问题就很明显了。因此,在一些特殊的功能实现方面,又需要使用C/C++来进行速度的提升。

五、最终决定

通过上面的描述,我们已经基本上把电信行业软件开发的体系架构表述清楚了。图3是笔者早先完成的一个基于J2EE架构的产品开发技术框架,仅供参考:



1 J2EE实现整体设计原则与思想

该系统的设计,采用了组件化的设计思想,同时根据项目的特点,对J2EE的实现架构进行了适当的改进,使之能更适应电信目前的要求和今后扩展的需要。

系统采用J2EE体系架构进行整体结构设计,这也是国际上流行的解决大型企业应用及关键性业务应用的优秀技术。

2 功能设计

通过J2EE技术框架实现电信行业系统的所有功能。

3 体系结构

该系统必须采用多层体系结构。建议采用如图3所示的六层体系进行架构。

4 构架特点

下面按照数据库层、数据管理层、事务处理层、会话处理层、逻辑控制层、前端表现层的顺序对以上各层功能和特点进行详细的描述:

(1)数据库层

选用某种数据库,提供数据存储服务,同时,还需要提供灾难备份和恢复功能。所以,目前,电信行业内部对数据库的基本要求如下:

①支持ANSI/ISO SQL-89、ANSI/ISO SQL-92标准;

②支持中文汉字内码,符合双字节编码;

③支持主流厂商的硬件平台及操作系统平台;

④数据库系统应具有良好的伸缩性;

⑤支持主流的网络协议(如:TCP/IP、IPX/SPX、NETBIOS及混合协议);

⑥具有良好的开放性,支持异种数据库的互访:

实现对文件数据和桌面数据库数据的访问;

实现对大型异种数据库的访问;

能够将原有异种数据库向本数据库无损失移植;

实现和高级语言互联的能力;

支持XA、ODBC 3.0、X/OpenCLI、JDBC等工业标准;

支持分布式事务及两阶段提交功能。

⑦具有支持并行操作所需的技术(如多服务器协同技术、事务处理的完整性控制技术等);

⑧支持网络上同构或异构数据库之间数据的冗余性复制;具有多种复制功能模块(如实时复制、定时复制、双向复制、多点方式下的N向复制、复制转发,复制范围可整表复制或表中部分行复制或修改单元复制);

⑨支持联机事务处理(OLTP),支持决策支持的建立,要求能够实现数据的快速装载、高效的并发处理和交互式查询;

⑩支持C2或以上级安全标准、多级安全控制;

支持数据库存储加密及相应冗余控制;

提供Web服务接口模块,对客户端输出协议支持HTTP2.0、SSL等;

支持联机存储和备份功能(如磁带方式、光盘方式);

应具有强的容错能力、错误恢复能力、错误记录及预警能力;

数据库、表大小等技术参数可灵活设置,支持对多媒体数据及大数据量处理的技术需求;

应可以避免数据库死锁的出现,一旦死锁能够自动解锁;

开发工具易使用、开发效率高、维护方便;

支持多种CASE工具。

上面对数据库的各个方面都提出了要求,在电信行业内部,目前对于中小型非关键业务项目采用MS SQL Server 2000的比较多,大型项目基本上都避开微软的体系和产品,而采用Oracle和DB2作为系统的数据库选择。

(2)数据管理层

这是整个系统中唯一进行数据访问、数据控制和数据安全校验的部分,是系统中唯一与数据库交互的部分,这也从另一个层面提高了数据安全性。

另外,由于有些电信行业系统的分布地域比较广,采用这种方式有利于分布式数据的有效管理,可提高数据的利用率和有效性。

优点:专用的数据管理层屏蔽了系统的其他部分对系统数据库的直接访问,增加了系统数据的隐蔽性,提高安全性和可管理性。

具体实现的时候,可尽量采用应用服务器所提供的功能,采用容器管理实体Bean(也就是CMP Entity Bean)来开发数据管理层,这样可以降低开发人员的开发工作量,提高效率,提高组件的可重用性。而且,当数据库发生变化的时候,不需要做大量的编码,通过应用服务器本身就可以直接对这种变化做出相应的反应。

注:对于CMP和BMP的使用的基本观点是这样:对于完全新建的系统,也就是说没有老系统的存在,或者可以忽略老系统的数据库设计方式可能对新系统的数据库设计造成的影响的时候,建议采用CMP的方式来开发Entity Bean,这样就可以完全采用OO的方式从需求开始到分析设计和编码实现都依托于OO的思想进行整体的规划,系统实现也会相对比较合理。而对于不符合上述情况的系统,一般在前端流程实现和业务逻辑实现中可以考虑采用OO的过程,在数据库管理层的实现中需要考虑与前端的配合外,数据库管理层的设计和数据库层的设计建议采用面向数据的过程进行规划,否则,不仅仅用户可能会对工期不满,开发团队也将面临着数据抽取与转换的难题。

(3)事务处理层

系统中进行事务处理的主要部分。这部分将根据具体的业务逻辑和实现进行业务控制和事务处理。在业务进行变化的时候,不影响系统的其他部分。

由于有些规则和制度会因为时间和各种情况有一定的变化,因此很多业务的具体处理流程和过程都需要修改,这样的修改如果放在其他部分,就有可能影响到很多其他业务的正常开展。

优点:经过仔细考虑后,笔者认为:针对所有具体的业务增加专用的事务处理层,进行专项业务的处理和控制。提高系统整体的可重用性,降低系统各部分之间的耦合度。

通过这种方式,可以随时随地地增加一项业务,减少一个环节,都不会对其他部分造成大影响,除非这项业务有一些固有的特殊的页面展示要求,否则都可以方便的达到上面的功能。

例如:在业务重组和旧制度废除、新制度发布的时候,可以先按照新制度定制好流程组件,在新制度发布生效的时候,将旧组件卸下,新组件安装即可。在现有的应用服务器上使用时,甚至服务都不需要中断,对于一个业务的更新,仅仅需要一两秒钟的时间就可以完成。

缺点:一定程度上,这对效率有所影响,但相对于Internet网络状况对系统性能的影响来看,这种架构模式对整个系统性能的影响仍然是很小的。

笔者建议:

①如果遇到大数据量查询时,建议越过这种架构模式,直接通过安全的SQL连接方式从数据库中尽快获取信息。

②对于大型的电子商务系统也可以借鉴这种体系架构,但对于仅仅在局域网内工作的系统,就可以对本架构进行简化,因为局域网内的安全性相对较高,所以,可以考虑简化以提高系统性能和运行效率。

(4)会话处理层

会话层,处理与前端展现的会话信息,提供交互的第一个处理界面,处理简单、稳定的事务。不处理复杂的事务和变化较频繁的事务。

优点:提供对前端发送过来的请求和各种数据信息的处理,当前端展现发生变化的时候,不会影响到后台的服务组件代码。

提供对简单事务的处理,这些事务一般是通用型的、基本上不发生变化的事务流程。如电信行业的批复流程、审核流程等等。

(5)逻辑控制层

系统进行控制的部分。这部分将提供系统整体的控制,处理各个部分之间的关系,启动各层间的操作和运行。同时它可以屏蔽前后两层(前端表现层和会话处理层)之间的联系,降低系统的耦合度。

优点:这是MVC中的控制层,在采用J2EE进行系统架构设计时,IBM非常推崇这种模式。在本系统的架构考虑中也认为采用这种模式是相当合适的,但同时考虑到这个系统的实际情况,本文对这种模式作了扩展,将模型层分成两个部分,也就是数据管理层和事务处理层,具体原因已经在这两个部分作了解释。

这种模式是把控制权和所有权进行分离,当具体业务和会话表现等部分发生变化的时候,开发人员不需要修改控制层的代码,使得整个系统中各个部分的权责更加明确,降低了维护的工作量。

(6)前端表现层

系统中提供数据展现的部分,属于整个系统的UI。这也是用户对整个系统最直接接触的部分。将提供报表展现、报表定制和录入、数据输入和输出、信息浏览发布等等……

优点:这是一个完全独立的表现层,如果设计的比较好,就可以做到:其样式、风格都可以由美工进行直接的修改和设计。这些设计不会影响到任何后台的事务,因此,甚至可以做到随时更换风格。

5  性能实现

(1) 安全性

关于安全性的描述,请参见系统和数据安全管理中的描述。

(2)可靠性

系统的可靠性将在具体的项目开发过程中体现出来。因为每一项业务的添加与减少都对系统整体的稳定性产生一定的影响。开发过程中,只要对设计进行严格的检验和测试就可以保证整个系统的可靠性。

(3)灵活性和扩展性

按照目前所规划的技术架构,开发者可以随时在上面进行各个功能层的组合和分离,也可以将各个功能层分布在各个不同的服务器上共同提供服务,因此整个系统无论是在物理结构上还是在逻辑结构上都具有很高的灵活性和扩展性。

对于业务组件,开发者/使用者可以对其进行业务分割和重组,以提高组件的利用率,对于今后其他系统的开发也具有技术积累的意义。

同时,这些业务组件可以根据业务状况的变化进行更新和替换。比如说:某一项新的制度发布生效前,开发者可以提前按照新的制度开发好完整的业务组件,在生效的那个时间点,将老组件取下,新组件安装到服务器上。这样也就不会因为制度的变化影响到各个业务或者办公流程的顺利开展。

(4)实用性

系统的技术架构是专门针对项目的一些特性对J2EE原有的体系架构进行修改和完善后设计出来的。它既可以应付复杂多变的业务流程,对于一般十分稳定的业务流程也不会出现多余的问题,且具有相当好的扩展性和灵活性。
分享到:
评论

相关推荐

    电信系统BMC方案建议书

    电信系统BMC方案建议书: 1 电信企业系统管理需求分析 3 2 BMC针对电信企业系统管理的解决方案 6 • BMC系统监控解决方案设计目标 6 • BMC监控解决方案设计方法 8 2.1.1 BMC PATROL体系结构 9 • BMC管理解决方案...

    电信帐务系统分布式方案思考.pdf

    为了应对这些挑战,本文提出了一个基于分布式系统架构的电信账务系统设计方案。 首先,我们来分析一下传统电信账务系统存在的问题。传统的电信运营商账务系统通常依赖于Unix系统和Oracle数据库,这样的系统虽然稳定...

    中国某电信综合结算系统总体方案.doc

    中国电信业务综合结算系统总体方案是中国某电信公司为了规范和优化结算业务流程而制定的总体方案。该方案的目的是为了建立一个统一、高效、安全的综合结算系统,以满足电信业务的需要。 1. 概述 中国电信业务综合...

    赛门铁克Symantec电信存储备份系统解决方案.doc

    该解决方案基于Symantec的备份软件和存储设备,提供了一个完整的解决方案,涵盖了备份需求分析、系统架构设计、备份策略规划、介质服务器负载均衡/切换、智能磁盘容量管理等方面。 章节1:综述 在电信行业中,数据...

    电信资源网格管理方案

    ### 电信资源网格管理方案详解 #### 一、电信资源网格管理方案概述 电信资源网格管理方案旨在通过优化电信网络的资源管理和市场营销策略,提高服务质量与运营效率。本方案从资源管理和市场营销两个角度出发,探讨...

    基于分布式技术的电信在线计费系统方案研究与设计.pdf

    因此,实施分布式计费系统需要深入理解业务需求,合理设计系统架构,选择合适的分布式技术,并建立完善的监控和运维体系。 总结来说,分布式技术在电信在线计费系统中的应用,是为了适应移动互联网时代下用户需求的...

    IBM EAI电信业务支撑系统的EAI架构规划及IBM解决方案

    本文主要探讨的是中国电信业务支撑系统中企业应用集成(Enterprise Application Integration, EAI)的架构规划,以及IBM提供的相应解决方案。EAI在电信行业中的应用旨在解决各业务系统之间的信息孤岛问题,实现高效...

    思科电信BOSS系统安全解决方案

    【思科电信BOSS系统安全解决方案】着重关注的是在新疆移动的业务运营支撑系统(BOSS系统)中如何确保网络安全和数据安全。BOSS系统涵盖了计费、结算、营业帐务和客户服务等关键业务,因此,系统的安全性至关重要,是...

    中国电信在线计费系统(OCS)总体技术方案V0.8.rar

    4.2.2. 新一代电信计费解决方案概述 19 4.2.3. 新一代计费方案对现网问题的解决 20 4.3. 新的计费解决方案的优势 21 5. 业务需求 23 5.1. 业务需求 23 5.2. 对OCS的计费功能需求 24 6. 体系结构 27 6.1. OCS体系结构...

    Linux或Unix平台电信级视频点播系统解决方案.doc

    视频点播系统架构是指视频点播系统的逻辑结构和物理结构,包括: (1)视频点播系统服务器:负责视频点播服务的服务器,包括视频点播服务器、 Cache服务器、Database服务器等。 (2)存储设备:负责存储视频内容的...

    电信行业CRM系统技术方案模版

    【电信行业CRM系统技术方案模版】 CRM(Customer Relationship Management,客户关系管理)系统是电信行业提升服务质量和运营效率的关键工具。本方案旨在为电信运营商提供一个全面的技术框架,以优化客户服务、销售...

    电信企业信息门户系统组网方案

    本文将围绕“电信企业信息门户系统组网方案”这一主题,详细介绍该类系统的组成结构、功能特点以及在网络设计方面的考量因素。 #### 电信企业门户系统的组成与功能 ##### 组成部分 电信企业门户系统主要由两大...

    电信客户服务中心系统解决方案.doc

    电信客户服务中心系统解决方案 概述 电信客户服务中心系统解决方案是为了满足电信运营商对客户服务的需求而设计的。该系统旨在为客户提供一站式的服务体验,提高客户满意度和忠诚度。系统的总体目标是提高客户服务...

    软件系统架构的方法论

    例如,在一个电信行业的系统架构中,可能会有CRM系统、营销分析系统、结算系统等多个子系统,每个子系统又可以进一步分解为更小的功能模块,如客户服务管理、账务管理和营销活动管理等。这样的分解有助于团队并行...

    电信行业信息化解决方案--财务综合管理信息化系统(doc 68).docx

    ### 电信行业信息化解决方案——财务综合管理信息化系统 #### 解决方案摘要与背景 本解决方案旨在针对电信行业的财务管理现状提供一套全面的信息化解决方案——财务综合管理信息化系统(Financial Information ...

    基于J2EE架构的电信运营计费系统的设计与实现

    多年来电信IP计费系统在实施及维护的基础上,吸收国外计费产品的先进理念与架构,结合国内各电信运营商实际生产管理需要,推出“理想完全自主开发及基于通用的商用软件包进行开发”两种成熟的电信计费系统解决方案,...

Global site tag (gtag.js) - Google Analytics