《基于SOA的电信BSS统一接口平台设计与研究课件.ppt》由会员分享，可在线阅读，更多相关《基于SOA的电信BSS统一接口平台设计与研究课件.ppt（38页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、基于SOA的电信BSS统一接口平台设计与研究指导老师:曾庆光 教授 李仁发 教授 学生:张筱2009年5月答辩提纲研究背景与意义本论文组织结构主要研究工作 1、TUIPSOA总体设计。2、TUIPSOA服务划分。3、TUIPSOA数据交换。4、TUIPSOA性能优化与评价。结论与展望答辩提纲研究背景与意义本论文组织结构主要研究工作 1、TUIPSOA总体设计。2、TUIPSOA服务划分。3、TUIPSOA数据交换。4、TUIPSOA性能优化与评价。结论与展望研究背景与意义 电信业务支撑系统（BSS，Business Support System）内外部连接的系统与平台急剧增加，传统的企业应用集
2、成方式已不能适应电信业务迅速发展的现状和电信应用系统与平台不断增加的需要。研究背景与意义(续)1）数据源的各异性。目前中国电信的业务支撑系统采取的是数据独立分布的策略，即根据主题数据库来建立应用系统与平台，各系统数据分布自成体系。这样造成数据源的各异性，电信有OracleSybase InformixDB2 数据库，有的数据来源数据文件（XML、EXCEL、TXT）2）通信协议的差异性。电信建应用系统比较早，各个应用系统由于各种原因，接口的通信协议是不一样的，有TCP/IP 协议、FTP 协议、表接口（系统内部数据库）、Http 协议、UDP 协议、Soap 协议等甚至有的跟交换机通信（例如：
3、各种产品的开通），这样造成通信协议的复杂性,造成通信的困难。3）复用性太差。业务支撑系统是业务受理系统，有的包括流程管理系统，这样包括开通，传统的接口集成方式，只要新增一个系统或平台就与新的应用系统做接口，分别是取数据、转换数据、发送数据这些代码都是重复写。复用性不高，造成开发周期延长，BSS 增加业务困难，不利于电信业务的开展。4）扩展性不强。系统之间互连需要重新建立大量接口，传统的接口方式只能另起炉灶重新开发，信息共享带来了较大的困难，系统的灵活修改和功能扩展受到限制，当前中国电信正在向综合信息服务提供商进行转型，应用系统与平台增加非常快，如果集成方式扩展性太差，不能适应用电信的转型。5）
4、随着系统的增加，接口增加迅速，监控的问题越来越是问题。各业务系统相对独立，软件和硬件平台差别较大，系统之间接口相互独立，维护管理作量较大，接口监控不到位，这样影响电信用户的服务。答辩提纲研究背景与意义本论文组织结构主要研究工作 1、TUIPSOA总体设计。2、TUIPSOA服务划分。3、TUIPSOA数据交换。4、TUIPSOA性能优化与评价。结论与展望本论文组织结构答辩提纲研究背景与意义本论文组织结构主要研究工作 1、TUIPSOA总体设计。2、TUIPSOA服务划分。3、TUIPSOA数据交换。4、TUIPSOA性能优化与评价。结论与展望主要研究工作-TUIPSOA总体设计 主要研究工作-
5、TUIPSOA总体设计(TUIPSOA概念)电信面向服务统一接口平台（the Telecom Service-Oriented Unified Interface Platform）：是一个接口集成平台，是以电信接口为中心的SOA，它是为完成两个或多个应用系统按照某种协议（数据协议、通信协议、网络互联协议）进行相互通信的框架，即将电信系统中的不同功能单元（即服务）通过协议要求组织在一起的框架。TUIPSOA 是利用接口集成技术与面向服务架构来集成应用与平台，其特点如下：扩展性强、统一监控、内部服务通信标准一致、接口标准的统一、内外服务管理的统一、业务驱动、实时开通等特性，使多个企业应用系统及开
6、通平台之间实现无缝集成。主要研究工作-TUIPSOA总体设计(TUIPSOA各层功能)接入层：由于电信应用系统多、各个应用系统与平台的通信协议不一致、数据格式也不一致。平台采用适配器设计模式进行设计，各个适配器处理一种通信协议或一种数据格式，有关适配器分类在功能模块设计在讲述。采用适配器屏蔽接口平台及电信其他平台或遗留系统数据交互的差异性。组件层：将基础性功能封装成不同的组件形式。主要是平台内部的一些控制，如进程与线程池的一些控制、工作流执行引擎、身份验证、服务订阅、消息发布、数据映射等；为上层的服务提供颗粒度适中的组件。服务层：该层是系统中最重要的一层，平台所有核心服务都集中在这一层，该层利
7、用组件层的功能组件来构建平台对外所需要的不同功能的服务。所谓服务，指的是具有基于统一规范的服务接口、服务调度模式、完成特定功能的一个功能实体。服务层最为核心的两种服务是：消息服务和数据服务(数据共享服务、数据转发服务)。主要研究工作-TUIPSOA总体设计(TUIPSOA各层功能)业务层：该层主要是系统的些逻辑控制，例如：规则判断（流程匹配的判断）、工单执行的逻辑顺序判断、工单取单顺序的逻辑判断等，凡是平台控制顺序与匹配的都封装在这一层。企业服务总线组件：企业服务总线(Enterprise Service Bus，ESB)，本平台管理范围比较宽，主要分为内部服务总线与外部服务总线。外部服务总线
8、对的服务进行注册管理，提供服务查询。内部服务总线管理内部服务的功能，即消息服务的相关功能：如CRM 要开通一个普通电话、CRM 系统要通过平台向交换接口机发一条指令，这个指令的数据构造包括取数据服务，数据映射服务，数据组织形成指令的服务，这些服务都由内部服务总线来管理。在平台具体的设计过程中，服务流程在整个数据交换过程中提供服务，所以将内部服务总线及外部服务总线都划归服务层。服务日志管理与监控组件：该层主要提供日志服务和身份验证服务，为平台中的服务过程提供安全管理和服务质量保证(如：保证服务的健壮性)。其中还包括服务流程的日志的管理，容灾等方面的管理。答辩提纲研究背景与意义本论文组织结构主要研
9、究工作 1、TUIPSOA总体设计。2、TUIPSOA服务划分。3、TUIPSOA数据交换。4、TUIPSOA性能优化与评价。结论与展望主要研究工作-TUIPSOA服务划分(三户关系对象图)主要研究工作-TUIPSOA服务划分(服务划分)原子服务:是指不依赖其它服务，且可单独被调用的服务，是不能再分解成更细粒度的服务。提供技术层面的数据采集，存储，计算，传输，分发等功能，或将遗留系统封装为服务。查询服务:主要是指动态类查询，没有涉及到事务的数据库操作，调用这类通用查询服务的优点就是可以生成各种格式的数据字典。动态脚本服务:脚本语言目前应用比较广泛，在本平台中只支持Jython 脚本语言，这类服
10、务主要是对字符串的处理或构造字符串的操作，这类服务执行速度快,能够不改平台代码，加入一段脚本语言串放到配置表中或文本就可以执行.主要研究工作-TUIPSOA服务划分(服务划分)组件服务:不直接面向客户，这些服务是为接口平台的运行服务，是组成接口平台的基础，主要功能为负责平台业务服务之间的信息交互；业务服务之间的数据交换、服务调用与服务管理、数据映射；运算处理业务状况；数据库存储和管理各种业务服务的信息和服务流程的执行规则。主要研究工作-TUIPSOA服务划分(服务划分)组合服务:通过调用其它服务而完成自身提供功能的服务。组合服务是由原子服务或其它组合服务，按一定的规则组合而成的服务,也可以由服
11、务流程替代.业务服务:是为了实现某种意义上而设置的服务，如：将上述对象图中单个的对象设置成各种业务服务，这些服务查询通过定单号串联或通过三户三关系来关联。其作用是构造数据的源头.主要研究工作-TUIPSOA服务划分(内部服务调用)答辩提纲研究背景与意义本论文组织结构主要研究工作 1、TUIPSOA总体设计。2、TUIPSOA服务划分。3、TUIPSOA数据交换。4、TUIPSOA性能优化与评价。结论与展望主要研究工作-TUISOA数据交换(交换框架)主要研究工作-TUISOA数据交换(动态字典概念)以集合为基础，并高效地支持Get,Insert 和Delete 三种运算的抽象数据类型叫做字典。
12、动态字典是指以数据转换适配器主要通过包装层将各数据源的异构数据转换成业务对象，以适应互操作的需要。为帮助用户构造有意义的查询以及协助查询处理器进行查询分解和优化，各局部结点的包装层和全局结点都要有自己的数据目录。主要研究工作-TUISOA数据交换(动态字典与数据库)主要研究工作-TUISOA数据交换(动态字典映射成XML)主要研究工作-TUISOA数据交换(XML映射成动态字典)答辩提纲研究背景与意义本论文组织结构主要研究工作 1、TUIPSOA总体设计。2、TUIPSOA服务划分。3、TUIPSOA数据交换。4、TUIPSOA性能优化与评价。结论与展望主要研究工作-TUIPSOA性能优化与评
13、价(性能优化)选择先进的技术架构分布式组件架构SOA功能目的 面向功能 面向流程设计目的 为了实现需求 为 了适应变 化开发周期 长交互式和重用性开发，周期短以什么为中心以成本为中心 以 业务为 中心协调性 应用阻塞 服务协调耦合性 紧密耦合 敏捷的和松耦合的同异构性 同构技术 异构技 术面向目的 面向对象 面向消息实施细节 需深入了解 实施细节独立于 实 施细节分层架构风格与C2 架构风格 层次系统可取的优点：1）支持基于抽象程度递增的系统设计，使设计者可以把一个复杂的系统按递增的步骤进行分解。2）支持功能增强，因为每一层至多和相邻的上下层交互，因此功能的改变最多影响相邻的上下层。3）支持重
14、用。只要提供的服务接口定义不变，则一层的不同实现可以交换使用。这样，就可以定义一组标准的接口，而允许各种不同的实现方法。层次系统的不足之处：1）并不是每个系统都可以很容易地为分层的模式，甚至即使一个系统的逻辑结构层次化的，出于对系统性能的考虑，系统设计师不得不把一些低级或高级的功能综合起来。2）很难找到一个合适的、正确的层次抽象方法。C2 架构风格可概括为，通过连接件绑定在一起的按照组规则运作的并行构件网络。其特点如下：1）系统中的构件可实现应用需求，并能将任意复杂度的功能封装在一起。2）所有构件之间通信通过以连件件为中介的异步消息交换机制来实现的。3）构件相对独立，构件之间依赖性较少。系统不
15、存在某些构件将在同一地址空间内执行，或某些构件共享特定控制线程之类的相关性假设。主要研究工作-TUIPSOA性能优化与评价(性能优化)选择优秀的开发平台:Java 具有简单、解释执行、动态、安全、健壮、独立于硬件体系结构、可移植等特点，它通过丰富的类库支持包括分布式计算、多线程、网络等各种应用的开发，并支持通过第三方类库进行进一步的扩展，因而被各种应用领域广泛采用 算法级性能优化:1)选择高性能XML 解析器Dom4J 2)选择合适的数据结构 3)使用缓存 4)集合的紧凑存储 5)延迟装载 主要研究工作-TUIPSOA性能优化与评价(性能优化)语言级性能优化 1）让编译程序做优化 2）利用Ja
16、va 语言提高性能3）利用Jython 语言提高性能主要研究工作-TUIPSOA性能优化与评价(性能评价指标)1）接口并发工单数：是指在某一给定时间内，某个特定点上进行会话操作的接口工单数量。并发接口数公式如下：接口并发定单数=RPS+SBS+Asign Time，这里RPS 是指某个接口一秒钟的业务工单请求数，SBS 并发连接数（线程数），Asing Time 框架分配线程时间与处理框架相关事务的时间。2）响应时间：是指的是IOMS（Integrated Order Management System）发出请求工单到请求工单在接口平台得到响应直至对端系统返回消息给IOMS的整个过程所经历的时
17、间 主要研究工作-TUIPSOA性能优化与评价(性能评价指标)3)吞吐量：是指单位时间内系统处理的客户请求的数量，直接体现接口的性能承载能力。吞吐量用请求数/秒衡量。4)资源利用率：是指系统资源的使用程度，例如：服务器的CPU 利用率、内存利用率、磁盘利用率、网络带宽利用率等。主要研究工作-TUIPSOA性能优化与评价(实验结果与分析)TUIPSOA 软硬件配置。1）硬件配置：TUIPSOA 的数据库服务器：IBM P570，8CPU1.9GHz，16GB-MEM。TUIPSOA 的应用服务器配置：IBM P570，4CPU1.9GHz，16GB-MEM。2）软件配置：后台数据库为Oracle
18、9i，在Unix 操作上，TUIPSOA 启动接口接程个数为23 个进程（其中CRM 接口进程8 个、IOMS 接口进程6 个、定时启动进程1 个、停复机进程4 个、其他进程4 个），每个进程15 个线程（最优设置）。正式环境接口数据统计:本文统计了2009 年3 月的接口工单数为8487223，而2007 年3 月接口工单数为3330823（全省业务量），业务量增加将近3 倍多，只统计了CRM 与IMOS 两个系统的接口。另外，本文还统计了该月的峰值日（为每月的月底最后一天：主要是停复机工单与拆机单与峻工单非常多），2009 年3 月31 号的接口工单数为599339,而2007 年3 月3
19、1 号的接口工单数为188229（全省总数），其中计费接口的工单请求数是最多的，占1/3 左右。因此本文以我开发与设计的计费接口为代表说明接口平台的四个性能指标，31 号每个小时的业务工单数，传统接口处理方式为14 个进程，每个地级市一个进程；TUIPSOA 则是1 个进程15 个线程，全省共用一个进程。主要研究工作-TUIPSOA性能优化与评价(实验结果与分析)环节名称 时间请求数 TUIPSOA 点对点处理方式计费接口 2009-03-31 08 6742 6742 5658计费接口 2009-03-31 09 17165 17165 15023计费接口 2009-03-31 10 189
20、25 18925 14009计费接口 2009-03-31 11 18760 18760 11009计费接口 2009-03-31 12 13088 13088 13456计费接口 2009-03-31 13 9665 9665 10003计费接口 2009-03-31 14 16412 16412 15057计费接口 2009-03-31 15 18802 18802 16789计费接口 2009-03-31 16 17703 17703 16586计费接口 2009-03-31 17 12330 12330 16786计费接口 2009-03-31 18 39186 39086 19786
21、计费接口 2009-03-31 19 36292 36392 16986计费接口 2009-03-31 20 21371 21671 16786计费接口 2009-03-31 21 13873 13873 17786计费接口 2009-03-31 22 7672 7672 12786计费接口 2009-03-31 23 11382 11382 12986合计 281847 281847 281847分析:TUIPSOA 在平台面向全省工单，对于各个地市工单统一处理，内部实现逻辑判断来达到工单处理的先后。传统接口方式只能按地市来处理，会出现“饥饿”现象，如果某个大的地市工单请求数多，而某个地市工
22、单请求数小甚至没有，这样会导致某个进程空闲等待状态而另一个进程进入忙等待状态，从而限制处理数，从而影响吞吐量 最大请求数的峰值:最大值达到39186/小时，这时TUIPSOA 的处理速度39086/小时主要研究工作-TUIPSOA性能优化与评价(实验结果与分析)关键事务名称 查询指令数 事务指令数 TUIPSOA 点对点数据库连接 1 1 5 1000线程分配 1 0 5 0送客户资料 22 10 2500 2500合计 2510 3500送用户资料 64 25 7150 7150合计 7160 8150送销售品资料 40 11 4330 4330合计 4340 5330送帐户资料 20 10
23、 2300 2300合计 2310 3300TUIPSOA 比传统接口集成方式的响应时间短1s 多,TUIPSOA 的启动时间要比传统接口集成方式多，TUIPSOA 的装载一些静态数据。主要研究工作-TUIPSOA性能优化与评价(实验结果与分析)CPU 工具分页每秒钟次数的统计 显示的是实际内存和在使用中的内存显示的是实际内存和在使用中的内存：分页空间的大小和使用率 CPU 工具 CPU 工具 进程:NAME：可执行程序的名称；Process ID：进程的ID号；CPU Utilization：进程的CPU平均使用率，这个值指的是进程在生命周期中的平均使用率；Paging Space Used
24、：分配给进程的分页空间大小；Process Owner：拥有这个进程的用户名；Workload Management（WLM）Class：进程属于哪个WLM class。物理磁盘:Disk：物理磁盘的名称；Busy%：指明物理磁盘在活动状态的时间百分比；KBPS：在监控期间每秒钟读写的字节数（以K 为单位）；TPS：每秒钟物理磁盘的数据传输量。一次传输指的是一次I/O 请求；KB-Read：每秒钟从物理磁盘读出的K 字节数；KB-Write：每秒钟向物理磁盘写入的K 字节数。网络接口 主要研究工作-TUIPSOA性能优化与评价(性能比较)传统接口集成 开源SOA 产品 TUIPSOA发布/订阅
25、 无 主题树实现 内部服务订阅消息分发 端到端发送 端到端也有总线分发 接入层分发总线消息格式 无统一格式 消息方式 动态字典支持的协议 支持某种协议 支持Web 协议 支持各种协议内部转换 各种基本数据对象 XSLT Xpath 动态字典路由规则 不支持 不支持 支持流程路由动态路由 无 无 支持服务封装 无 XML 封装 多种方式封装接入层 支持某一接入 只支持Web 接入 支持各种接入服务划分 无 粗粒度服务，没有提供内部服务划分方式对外实现粗粒度服务，对内进行内部服务细分可扩展性 无 较弱 较好互操作性 无 一般 较好执行效率 慢 较快 快复用性 无 一般 好可靠性 无容错机制 依靠外
26、部系统发起 有容错机制互操作性 只适应特定的接口 支持Web 环境 支持多种环境占用内存大小 较大 较大 内存中缓存静态数据就会较大答辩提纲研究背景与意义本论文组织结构主要研究工作 1、TUIPSOA总体设计。2、TUIPSOA服务划分。3、TUIPSOA数据交换。4、TUIPSOA性能优化与评价。结论与展望结论与展望结论:1）根据电信BSS 各子系统的集成现状，借鉴面向服务架构与分层架构风格，提出了电信面向服务统一接口平台框架（TUIPSOA）。2）论文对TUIPSOA 进行了总体设计、服务划分与服务识别、服务接口、服务封装、数据交换做了比较细致的描述。3）最后对平台的性能优化与性能评价做详细的叙述，平台的设计与开发过程中都在考虑平台的性能为出发点。进一步研究方向:云计算与网格计算