电信综合网络激活系统的设计与实现

/综合网络激活系统设计和实现TIME\@"yyyy年M月"2016年4月综合网络激活陕西项目组大唐软件技术股份有限公司CopyrightByCattSoft AllRightsReserved版本修订历史起止日期作者/修订人更改章节修改描述版本/状态2013/12/25张海强全部创建，依据现有文档整理而成。V0.1填写说明：起止日期：填写编写本文档的起止日期作者：填写文档的创建者或授权的修改人修改描述：请详细填写修改缘由和最近的修改章节摘要版本：描述修改生效后的版本号。一般建议表示为Vm.n形式。通过正式评审后版本号变为1.0，以后每修改一次n相应增加1，例如V1.1状态：描述本文档是正式文件还是草稿文件

文档编号编写人员编写时间修订时间

书目TOC\o"1-3"\h\z1.电信规范和技术应用 51.1电信规范 5系统目标 5在OSS总体架构中的定位 5重要概念 71.2技术应用 9运行平台 9开发语言 9数据库访问 9通信机制 102.系统总体架构设计 132.1系统介绍 132.2系统特点 14全业务的融合支撑 14丰富的网元/业务平台适配实力 15轻量级流程限制机制 16供应实时、非实时两种业务激活处理通道 16新系统功能改进 172.3系统架构设计 17业务流程分析 17前台界面设计 18后台服务设计 202.4前台功能介绍 23前台功能概述 23业务信息配置 24激活信息配置 24网元信息配置 26流程限制配置 26工单维护管理 27系统维护管理 28系统平安管理 283.系统主要模块详细设计和实现 293.1服务结构 29运行载体(进程或线程)和业务逻辑的分别 29服务架构设计 30日志处理 32异样处理 333.2取单服务(北向接口) 33异步交互流程 34工单消息构成 34工单消息类型 35工单消息结构 35静态数据定义 39取单服务设计 41取单服务时序图 423.3流程派发服务 43业务流程功能分析 43流程派发服务设计 44流程派发服务时序图 493.4工单处理服务 49业务流程功能分析 49工单处理服务设计 50工单处理服务时序图 563.5网元接口协议及实现(南向接口) 57叮嘱行交互协议及实现 58基于TCP/IP结构化消息协议及实现 71基于HHTP/SOAP协议及实现 823.6其他服务 86告警服务 86回单量统计服务 87定时工单服务 874.总结和展望 87应用和评价 874.2将来展望 88功能展望 88性能展望 88

电信规范和技术应用电信规范中国电信CTG_MBOSS规范(CTGMBOSSOSS2.8_自动激活系统_总体分册)规定了自动激活系统(综合网络激活)的系统目标和系统定位等，规范的提出为建设自动激活系统的相关厂商供应了重要依据。系统目标综合网络激活系统是连接服务层和资源层，完成服务信息在物理网络、业务平台上自动激活、查询、修改、测试、采集，能够完成移动、固网和综合业务的运营支撑系统。在服务开通支撑过程中，系统确保了一旦接收了激活工单，能够依据流程要求，将激活工单中客户业务在物理网络、业务平台上进行自动激活的处理；在网络上客户业务信息查询支撑过程中，自动激活系统确保一旦接收到查询请求，能够刚好的将客户相关信息反馈给请求者；在网络上客户信息修改的过程中，自动激活系统确保一旦接收到用户的修改请求，能够依据修改要求，对客户业务在物理网络、业务平台上进行修改处理；在服务保障支撑中，系统确保一旦接收到用户的测试请求，能够依据测试要求，对客户业务在物理网络、业务平台上进行测试处理；在客户业务信息数据管理的支撑过程中，自动激活系统确保一旦接收到采集请求，能够依据采集请求，对客户业务在物理网络、业务平台上进行采集处理。自动激活系统能够把客户业务在物理网络、业务平台上进行自动激活实现，为相关系统供应自动的查询、修改、测试和采集的服务实力，确保对物理网络、业务平台层有关客户业务信息自动处理实力进行封装。在OSS总体架构中的定位可以通过两种方式标示自动激活系统在OSS总体架构中的位置，一是自动激活系统在OSS总体架构中覆盖的功能范围，二是标示自动激活系统在OSS系统架构中的位置。图1-1自动激活系统在OSS系统架构中的位置如图1-1所示，综合网络激活位于资源层供应和保障域内，主要覆盖了网元接入、激活就绪、激活过程和激活管控。图1-2自动激活系统在网络管理域的位置如图1-2所示，在OSS系统架构中，自动激活系统位于服务及网络管理系统域，自动激活系统是OSS工具类系统之一。重要概念本节重点描述自动激活系统在规范中涉及到的重要概念，如图1-3所示。图1-3激活工单描述图激活工单：派发给自动激活系统的工单，简称激活工单。一个激活工单包含构成产品实例的业务资源实例。激活子工单：自动激活系统拆分后的工作任务工单。一个激活子工单包含对同一个网元施工的业务资源实例。指令：指能够被网元识别并执行的操作语言，它规定了网元能够完成的某一操作。一个业务资源可以包括多条指令，多个业务资源可以合并成一条指令。网元：供应某种通信业务或增值业务的功能实体。包括程控交换机、HLR、PPC、IVPN、SHLR、业务平台(彩铃平台、商务领航、ISMP等)、DSLAM等类型。北向接口：北向接口指发送和发送激活工单的相关接口协议。发送和接收激活工单的北向接口应用包括服务开通、CRM等。南向接口：南向接口指接收并发送指令的相关接口协议。南向接口的相关应用就是网元。

技术应用运行平台综合网络激活系统的webserver和后台应用程序运行在Unix/Linux系统上。后台应用支持比较常见的Unix/Linux操作系统，包括：AIX、HPUnix、RedhatLinux和TurboLinux等。和Windows相比，Unix/Linux操作系统在运行过程中消耗系统资源较少。由于系统运行的操作系统平台不同，系统也不会感染病毒。虽然，Unix/Linux在易用性上不如Windows操作系统，但是由于系统的用户不是一般消费者，所以不必在易用性上耗费过多的资源。开发语言综合网络激活系统的后台应用接受C/C++编写，前台界面接受JAVA编写。综合网络激活系统属于电信OSS支持系统的一个子系统，所以相关开发人员均是从事过网管产品研发的工程师，由于历史缘由OSS支持系统的相关软件大部分接受C来编写，综合网络激活顺理成章的也接受了C/C++语言编写。和目前广为流行的JAVA语言相比，C/C++编写的程序具有更高的执行效率和稳定性，但是由于开发工具包有限，在开发过程中和JAVA相比具有确定的难度。由于目前大部分网元也是由C/C++语言实现的，所以在协议的实现上，接受C/C++语言也更具优势。数据库访问OCI(OracleCallInterface，参考文献：ORACLE应用编程手册)是ORACLE公司开发的一个应用程序开发工具，是一个通过OCI访问Oracle数据库的服务器，限制各类SQL语句的执行，进而创建应用程序的应用程序接口(API)。它支持SQL全部的数据定义、数据操作、查询、事务管理等操作，支持C和C++的数据类型，调用，语法和语义。它供应了一组可对Oracle数据库进行存取的接口子例程(函数)。OCI程序实质上就是用高级语言写的程序，其特点是内部含有对OCI子函数库的调用，通过在第三代程序设计语言(如C语言)中进行调用可达到存取ORACLE数据库的目的。可用oracle打开OCI文件。综合网络激活系统的数据库Oracle数据库连接部分是在OracleOCI(Oracle调用接口)基础上开发的，支持Oracle8i、9i、10g等数据库。依据Oracle公司的介绍：OCI是如此牢靠，以至于Oracle数据库中的每一条SQL语句都通过OCI来执行。当应用程序开发人员须要面对Oracle数据库服务器的最强大的接口时，他们将调用Oracle调用接口(OCI)。OCI供应了对全部Oracle数据库功能的最全面的访问。OCIAPI中包含了最新的性能、可伸缩性和平安性特性。接受OCI的最大好处就是：它是最切近Oracle底层的技术，因此，效率是最高的。同时，它是跨平台的。通信机制综合网络激活系统的通信机制主要接受TCP/IP协议中的面对连接的TCP协议。SOCKET是操作系统为上层应用供应的应用接口，在TCP/IP的四层协议中，SOCKET位于应用层和传输层之间。除了利用SOCKET通信外，综合网络激活系统还供应了基于SOAP的Web服务。简洁对象访问协议(SOAP，全写为SimpleObjectAccessProtocol)是一种标准化的通讯规范，主要用于Web服务(webservice)中。SOAP的出现是为了简化网页服务器(WebServer)在从XML数据库中提取资料时，无需花时间去格式化页面，并能够让不同应用程式之间透过通讯协定，以XML格式相互交换彼此的资料，使其和程式语言、平台和硬体无关。此标准由IBM、Microsoft、UserLand和DevelopMentor在1998年共同提出，并得到IBM、莲花(Lotus)和康柏(Compaq)等公司的支持，于2000年提交给全球资讯网联盟(WorldWideWebConsortium；W3C)，目前SOAP1.1版是业界共同的标准，属于其次代的XML协定(第一代具主要代表性的技术为XML-RPC以及WDDX)。用一个简洁的例子来说明SOAP运用过程，一个SOAP消息可以发送到一个具有WebService功能的Web站点，例如，一个含有房价信息的数据库，消息的参数中标明这是一个查询消息，此站点将返回一个XML格式的信息，其中包含了查询结果(价格，位置，特点，或者其他信息)。由于数据是用一种标准化的可分析的结构来传递的，所以可以干脆被第三方站点所利用。》SOAP封装(envelop)，封装定义了一个描述消息中的内容是什么，是谁发送的，谁应当接受并处理它以及如何处理它们的框架。》SOAP编码规则(encodingrules)，用于表示应用程序须要运用的数据类型的实例。》SOAPRPC表示(RPCrepresentation)，表示远程过程调用和应答的协定。》SOAP绑定(binding)，运用底层协议交换信息。一、SOAP消息实例Request消息：<soapenv:Envelopexmlns:soapenv=”:///soaplenvelope/”xmlns:xsd=””xmlns:xsi=””><soapenv:Body><req:echoxmlns:req=”://localhost:8080/axis2/services/MyService/”><req:category>classifieds</req:category></req:echo></soapenv:Body></soapenv:Envelope>Response消息：<soapenv:Envelopexmlns:soapenv=””xmlns:wsa=””></soapenv:Header></wsa:ReplyTo></wsa:Address>:///ws/2004/08/addressing/role/anonymous</wsa:Address></wsa:ReplyTo><wsa:Form><wsa:Address>://localhost:8080/axis2/services/Myservice</wsa:Address></wsa:From><wsa:MessageID>ECESB3FI87F29D28BC1/wsa:MessageID></soapenv:Header><soapenv:Body><req:echoxmlns:req=”://loealhost:8080/axis2/services/MyService/”><req:category>classifieds</req:category></req:echo></soapenv:Body></soapenv:Envelope>二、gSOAP介绍(参考文献：RobertvanEngelengSOAP2.7.15UserGuide2009年)gSOAP编译工具供应了一个SOAP/XML关于C/C++语言的实现，从而让C/C++语言开发web服务或客户端程序的工作变得轻松了很多。绝大多数的C++web服务工具包供应一组API函数类库来处理特定的SOAP数据结构，这样就使得用户必需变更程序结构来适应相关的类库。和之相反，gSOAP利用编译器技术供应了一组透亮化的SOAPAPI，并将和开发无关的SOAP实现微小环节相关的内容对用户隐藏起来。gSOAP的编译器能够自动的将用户定义的本地化的C或C++数据类型转变为符合XML语法的数据结构，反之亦然。这样，只用一组简洁的API就将用户从SOAP微小环节实现工作中解脱了出来，可以专注和应用程序逻辑的实现工作了。gSOAP编译器可以集成C/C++和Fortran代码(通过一个Fortran到C的接口)，嵌入式系统，其他SOAP程序供应的实时软件的资源和信息；可以跨越多个操作系统，语言环境以及在防火墙后的不同组织。gSOAP使编写web服务的工作最小化了。gSOAP编译器生成SOAP的代码来序列化或反序列化C/C++的数据结构。gSOAP包含一个WSDL生成器，用它来为你的web服务生成web服务的说明。gSOAP的说明器及导入器可以运用户不须要分析web服务的微小环节就可以实现一个客户端或服务端程序。下面是gSOAP的一些特点：》gSOAP编译器可以依据用户定义的C和C++数据结构自动生成符合SOAP的实例化代码。》gSOAP支持WSDL1.1，SOAP1.1，SOAP1.2，SOAPRPC编码方式以及literal/document方式。》gSOAP是少数完全支持SOAP1.1RPC编码功能的工具包，包括多维数组及动态类型。比如，一个包含一个基类参数的远程方法可以接收客户端传来的子类实例。子类实例通过动态绑定技术来保持一样性。》gSOAP支持MIME(SWA)和DIME附件包。》gSOAP是唯一支持DIME附件传输的工具包。它允许你在保证XML可用性的同时能够以最快的方式(流方式)传递近乎无大小限制的二进制数据。》gSOAP支持SOAP-over-UDP。》gSOAP支持Zlibdeflateandgzipcompression(for，TCP/IP，andXMLfilestorage)。》gSOAP支持SSL(S)。》gSOAP支持/1.0，/1.1保持连接，分块传输及基本验证。》gSOAP支持SOAP单向消息。》gSOAP包含一个WSDL生成器，便于web服务的发布。》gSOAP包含一个WSDL解析器(将WSDL转换为gSOAP头文件)，可以自动化用户客户端及服务端的开发。》生成可以单独运行的web服务及客户端程序。》因为只须要很少内存空间，所以可以运行在类似PalmOS，Symbian，PocketPC的小型设备中。》适用于以C或C++开发的web服务中。》跨平台：Windows，Unix，Linux，MacOSX，PoeketPC，PalmOS，Symbian等。》支持序列化程序中的本地化C/C++数据结构。》可以运用输入和输出缓冲区来提高效率，但是不用完全消息缓冲来确定消息的长度。取而代之的是一个三相序列化方法。这样，像64位编码的图像就可以在小内存设备(如PDA)中以DIME附件或其他方式传输。》支持C++单继承，动态绑定，重载，指针结构(列表、树、图、循环图，定长数组，动态数组，枚举，64位2进制编码及16进制编码)。》不须要重写现有的C/C++应用。但是，不能用unions，指针和空指针来作为远程方法调用参数的数据结构中元素。》三相编组：1)分析指针，引用，循环数据结构；2)确定消息长度；3)将数据序列化位SOAP1.1编码方式或用户定义的数据编码方式。》双相编组：1)SOAP说明及编码；2)分解“forward”指针(例如：分解SOAP中的href属性)。》完整可定制的SOAP错误处理机制。》可定制的SOAP消息头处理机制，可以用来保持状态信息。系统总体架构设计系统介绍大唐电信旗下大唐软件，凭借多年来对电信运营商的业务和运营发展变革的持续跟踪，参考国内外标准和运营商规范，结合在各类运营支撑系统规划、研发和工程实施过程中的阅历，逐步总结形成了大唐软件综合网络激活系统，系统架构如图2-1所示。系统的架构借鉴面对服务架构和组建化的系统设计，将系统中各个功能模块依据相互间关系封装成服务，系统服务依据不同的层次结构可以划分为：北向业务接口层、核心处理层和南向网元适配层，每层都包含一个或多个服务。北向业务接口层主要实现和CRM、服务开通等系统的对接，完成服务配置和查询工单的接收和工单竣工结果的反馈。系统供应SOAP、TCP/IP、数据库接口表以及文件等多种接口协议，满意不同上层业务系统的集成需求。另外，系统供应同步业务激活接口和异步业务激活接口两种不同的接口方式，满意不同业务实时性的激活处理要求。核心处理层完成工单业务信息向网元指令信息的转换以及工单处理过程的限制功能包括两级流程限制：(1)工单级流程限制完成将一个工单依据业务需求拆分为多个网元工单处理过程的限制；(2)业务级流程限制是实现一个业务须要在网元上用多条指令处理过程的限制。南向网元适配层主要实现对各专业网管系统和各专业网元设备的适配，完成指令的下发和指令结果信息的收集。系统全部的服务都是由服务限制总线完成服务的配置和调度，从而实现依据实际需求定制系统功能。另外，系统还供应对工单执行状态、核心服务运行状态和接口连通状态等服务监控和告警管理功能。图2-1综合网络激活系统架如图2-1所示，综合网络激活系统具有支持移动、固网等综合业务统一激活的实力，通过对业务参数、激活限制规则、网元指令和接口协议等多种灵敏的配置手段，最大限度地支持系统在业务部署和网络接入方面的扩展实力，能够实现对实时、非实时业务的融合支撑，满意用户不同SLA要求。系统特点全业务的融合支撑目前系统支持自动激活的业务种类包括：程控业务、移动业务、智能网业务、NGN业务、互联网业务以及增值业务等。随着市场需求的发展，3G业务的实施，用户的业务种类、业务品种层出不穷，对业务自动激活系统的业务扩展实力要求也就越来越高。大唐软件综合网络激活系统是以满意电信企业对业务扩展需求为动身点，供应对业务扩展的全面支持，同时，系统接受先进的设计实现技术，供应了不依靠于业务种类和业务产品的系统实现体系结构，最大程度地支持了业务的灵敏扩展。图2-2支撑的业务种类丰富的网元/业务平台适配实力系统能够接入包括固网网元和移动网元在内的6大类、20多种网元设备或平台，支持多种网元接口协议。系统引入适配器技术，能够实现对不同类型网元设备的快速接入。当出现新类型网元时，只需在原有系统架构基础上增加相应的适配器，保证系统的稳定性，支持了新网元的扩展需求。图2-3和图2-4是目前系统已经接入的网元类型。图2-3支持的网元接口协议图2-4成功接入的各类系统/设备轻量级流程限制机制支持和服务开通系统间大激活、小激活对接模式，产品具备工单拆分及轻量级流程限制实力。系统分两层实现了对工单处理简洁的流程限制功能，第一层是工单级流程限制，实现对业务工单到网元工单转换过程中的处理流程限制；其次层是业务级流程限制，实现对网元工单到操作指令的流程限制功能。通过轻量级的流程限制机制，既能满意各地网络激活过程的差异性、适应业务灵敏部署的要求，同时又较好解决了服务开通系统通过工作流引擎技术所带来执行效率慢的问题。供应实时、非实时两种业务激活处理通道系统能够依据上层业务系统对业务开通的SLA要求，分别供应实时和非实时两种不同的激活处理通道。对于实时激活处理通道，从接收工单信息，完成网络激活处理，最终反馈相应的处理结果，都接受了同步的处理过程，并且在处理过程中接受了工单信息先处理、后许久化的机制，保证业务激活的实时性；而对于非实时激活处理通道，则接受异步的处理过程，在处理过程中接受了工单信息先许久化、后处理的机制，同时在异样状况下供应人工维护台对失败工单进行人工处理，保证业务激活的牢靠性。通过两种不同的业务激活处理通道，可以满意将来业务多样性、特性化的用户需求，实现对自动激活服务的支撑。新系统功能改进目前，综合网络激活系统已经发展到第三代，新版本的系统在很多方面和老系统存在差异。老版本系统的前台界面接受C/S方式实现，新系统接受B/S结构实现。老系统后台接受C实现，新系统接受C++实现。在数据库的选择上新系统接受ORACLE数据库，不同于老系统的SYBASE。在功能上，新系统支撑省集中的部署模式、工单的流程限制等都是老系统不具备的，此外，新系统接入的业务和网元更加广泛。系统架构设计综合网络激活分为后台应用程序和前台界面两大部分。后台应用程序负责处理业务流程；前台应用负责配置数据的呈现，激活工单、激活子工单和网元工单状态的查询和维护。综合网络激活系统以数据库中的一组表格作为前台界面和后台应用的接口，后台应用程序依据数据库中各种表格的数据进行业务处理，前台页面集中呈现配置信息和工单处理过程中的信息和结果。业务流程分析综合网络激活的主要功能是将客户订购的服务信息在网络设备进行端到端配置的过程，实现客户服务到实际物理网络的映射。简洁来讲，综合网络激活的主要流程是接收上层应用发送的客户订购信息(激活工单)，将信息解析、转换为统一的消息结构(激活子工单和网元工单)，然后进行参数映射、工单拆分等处理，转换为指令并发送给网元或专业网管。最终将指令执行结果返回到上层应用的过程。综合网络激活系统的首要任务是从位于北向接口的上层应用接收消息。由于各地运营商的业务支撑系统的差异，所以每个地区综合网络激活系统的北向接口接收模块收到的消息格式和内容也不尽相同，但是，可以将北向接口发送的消息内容大致归纳为：产品信息、业务信息和业务参数等三类消息。产品信息主要代表所要开通的产品，通常包括：固网产品、智能网产品、NGN产品等等；业务信息主要包括：用户开机、用户拆机、用户停机/复机等；业务参数取决于业务信息，每个业务都带有的参数。三类信息的关系为：产品信息确定业务信息，业务信息确定了参数信息。依据以上的分析，综合网络激活北向接口接收的消息的协议格式和内容都有较大不同，假如不对消息格式进行规范，产品的可移植性会特殊差，简洁造成同一个产品不同的地区不兼容的现象，特殊不利于产品的维护和升级。为此系统从北向接口的上层应用接收到激活工单后，会将激活工单转换为激活子工单，每个地区综合网络激活产品的接收工单模块都不尽相同，但是它们的激活子工单结构的类型定义和库表结构都是相同的。在激活工单到激活子工单的转换过程中，系统会将激活工单中的产品信息、业务信息和业务参数信息处理、映射为激活子工单的对应三类信息。从用户的角度来看，电信网可以被看成是一个功能强大的分布式计算系统，然而，网络上不只一个功能强大的网元处理全部业务，不同功能的网元相互协作有机的构成了电信网络。所以，当系统要完成一项客户服务信息到物理网元上的配置时，经常会涉及到多个网元的操作，例如，开通一个移动用户，首先要对移动网元作操作，然后是短信中心，而后是智能网网元等等。如上所述，在完成激活工单到激活子工单的转换后，系统要做的下一工作是将激活子工单拆分成网元工单。一条激活子工单往往会对应一个或多个网元工单。每一条网元工单和某个网元和网元须要执行的指令(开机、停机或复机等等)对应，最终将转换后的指令发送给网元。在完成激活子工单到网元工单的拆分后，系统须要依据业务要求把网元工单转换成一系列指令集合。在转换过程中，须要将网元工单的对应操作和参数依据指令模版填写到指令中，最终发送给网元。指令发送完毕后，网元返回指令的执行结果，系统须要推断指令是否执行成功。当完成指令结果的推断后，流程最终须要把结果返回给北向接口的上层应用程序。返回结果的流程和激活工单、激活子工单、网元工单的流程是相反的，首先要对网元工单记录做成功和否的标记，然后依据网元工单的序列号找到激活子工单并做标记，最终是激活工单，系统最终依据激活工单的标记结果形成消息并发送给北向接口的上层应用。前台界面设计由于系统的WEB呈现层和后台服务之间是一种松耦合的关系，因此，对于综合网络激活系统的WEB界面可以进行独立考虑。依据目前WEB界面实现技术的趋势以及对系统后续研发支撑和维护的要求，综合网络激活系统的WEB界面还是接受三层的分层技术模型：表现层、业务层和许久层。须要留意的是：这里的三层模型只是属于系统整体技术框架中的WEB呈现层的技术设计，而和系统整体技术框架的业务层和许久化层不存在关联关系。WEB前台界面的技术框架接受三层的分层模型，须要对这个三层的技术模型的实现技术进行选型，参考目前的实现技术，主要以性能稳定和高性价比为参考指标，选择接受struts、spring、hibernate并辅以JDBC的技术实现。表现层接受struts，业务层接受spring，而许久层则接受hibernate和JDBC。这种技术实现模式是当前比较流行的轻量级J2EE企业应用开发模式，也符合综合网络激活系统研发的技术特点。图2-5前台整体架构图相对于前端业务支撑系统来说，综合网络激活系统作为运营支撑系统，是一个相对来说应用需求较为稳定的应用系统，在每个省市应用时，涉及到的本地化工作主要集中在设备接入层面，而并不会影响到系统的处理流程和其他相关系统功能；特殊是对于前台界面来说，系统应用时本地化开发主要集中在局部需求，而非重要的流程需求，因此，对于综合网络激活系统的WEB呈现层来说，系统界面功能需求的稳定性特殊高。因此，综合网络激活系统WEB界面选用轻量级的J2EE框架结构可以很好的满意系统界面得研发要求，从大的方面讲可以适用UNIX、Linux、Windows服务器，再从小的方面说由于在许久层运用了Hibernate所以很简洁适应常见的oracle、sybase、SQLServer数据库，同时由于不运用EJB等重量级技术，该技术实现可以部署在Tomcat、JBoss等容器下。WEB前端界面只是综合网络激活系统呈现给用户的UI部分，作为综合网络激活系统和用户的交互接口，可能会有确定量的变动，所以接受松耦合的方式便于修改。同时，前台界面接受当前流行的实现模式和实现技术：struts、spring、hibernate和JDBC技术，有广泛的技术资源，也便于系统设计开发和维护。综合网络激活系统WEB界面接受这种技术架构的优点：》对待变动的适应实力较强。在实现上接受松耦合的方式有利于局部上的修改，比如前端显示上须要变更，只须要相应的修改表现层代码即可。》有力于扩展和维护。由于接受当前流行的实现方式，资料以及人力资源比较丰富，对这种实现方式的探讨或很多，有一些很有借鉴意义。各层之间的分工明确便于阅读和修改代码。》能够比较好的保障开发效率和软件质量。Struts1.2、hibernate3.2、spring2.0都是成熟稳定的框架，运用框架对代码的质量有确定的保障，比如数据库连接的管理等等。框架之间结合的方式也比较固定，程序员之间的代码基本接近不会自由发挥的太出格，对企业开发很有好处。考虑到在运用综合网络激活系统界面得查询功能过程中，会涉及到大量的数据库访问，因此，接受这种技术架构，也存在一些缺点：》对数据库的访问性能上可能会有确定的问题。》可能有对象的装箱和拆箱，功能处理上有冗余。》代码量相对大一些，配置设置相对多一些。对于以上的一些缺点，可以通过在系统的详细设计和实现过程中，接受数据分页呈现等实现技术，可以在确定程度上予以避开。前台应用接受B/S结构，可以划分成三层结构。接受了三层结构的SSH(STRUTS、SPRING和HIBERNATE)架构可以确保前台界面的灵敏性对于一些应用也接受特殊处理，例如分级分页的方法，来规避大数据量访问造成的压力，提高性能。如图2-6所示。前台应用主要包括：信息的配置、系统管理、查询统计、告警维护、平安管理、服务监控、工单查询和工单维护等功能。图2-6前台界面结构图后台服务设计作为核心的系统后台服务，接受了C++技术，确保系统的性能效率在实现技术中更多的体现了多种技术手段，多方位提升系统处理性能和效率在技术的多层面，接受了先进的技术手段和设计思想来实现后台应用，借鉴了面对组件的设计实现方式，在系统框架结构中接受组件化的设计实现，系统整体的层次结构更加清楚，核心框架的作用更为重要，特殊是实时和非实时融合框架，确保系统的整体融合处理实力，通过核心框架的限制能够确保系统供应更灵敏平安的支撑实力从业务逻辑角度看，主要包括：异步工单接收、异步工单结果返回、同步工单接口、工单的翻译、指令的交互和网元的适配和管理等。后台应用程序由一组服务集合组成，依据各个地区运营商的要求可以灵敏的通过前台界面进行配置。后台的主要服务包括：取单服务、流程派发服务、工单处理服务、流程回单服务和回单服务等。取单服务主要负责接收北向接口的上层应用发送的激活工单，将激活工单转换成激活子工单；流程派发服务负责将激活子工单拆分成多条网元工单，并对网元工单执行依次进行限制；工单处理服务负责将网元工单映射成多条指令，发送指令到网元，并推断指令结果；流程回单服务负责依据网元工单的结果形成激活子工单；回单服务负责从激活子工单到激活工单的转换，并将处理结果最终发送给北向接口的上层应用。图2-7综合网络激活系统结构图图2-7是综合网络激活系统的系统结构图。综合网络激活系统依据功能进行划分，后台服务主要用于实现业务的激活处理，后台服务基本上完成了系统的主要业务功能。在综合网络激活系统后台服务中，从技术角度来看，系统的主要功能可以分为四个技术层面，这四个技术层面通过一个系统管理功能进行连接。这四个技术层面包括两个接口层：北向业务接口层和南向网元适配层；两个功能层：施工工单处理层网元工单处理层；通过系统服务限制管理功能实现后台服务的应用容器，将四个技术层面和服务监控及告警管理有机的整合在一起，实现系统后台的整体功能。这里须要特殊说明的是，系统后台服务的两个接口技术层面依据应用领域不同分别供应不同的技术型接口，北向业务接口层分别供应同步业务激活接口和异步业务激活接口；而南向网元适配层供应固定网络网元适配器和移动网络网元适配器。系统的架构借鉴面对服务架构和组建化的系统设计，将系统中各个功能模块依据相互间关系封装成服务，系统服务依据不同的层次结构可以划分为：接口层、逻辑处理层和适配层，每层都包含一个或多个服务。系统全部的服务都是由服务配置、服务调度总线完成服务的配置和调度，从而实现依据实际需求定制系统功能。上面通过对综合网络激活系统的功能层面进行技术模型的阐述，主要集中于用技术的眼光来看待系统的功能层次。对于系统的后台技术架构，系统还须要从技术实现的方式来分析综合网络激活系统后台服务的实现方式，从技术实现的角度来建立系统后台服务的技术模型。依据以前产品的实现和系统实现的技术选型，综合网络激活系统后台服务接受C++实现技术，在C++实现技术的基础上，须要供应以下的技术来完成系统后台服务的开发：》ORM、XML、DB、Socket、Tuxedo、Corba、File、SOAP。》适配器技术、协议库技术和限制器技术。》服务周期限制技术、进程、线程和服务设计。》进程间通信、线程间通信和消息中心。》正则表达式和模版替换。》状态自动机和触发器。将这些实现技术依据层次划分，综合网络激活系统后台服务技术实现的系统实现技术的结构图2-8所示：图2-8后台技术服务借鉴面对服务的体系结构和组件化设计技术作为系统框架设计参考，接受可定制的功能设计和面对对象的分析和设计技术作为系统设计的指导思想，利用成熟的系统开发过程完成系统的开发，使综合网络激活系统具有以下的技术优点。一、系统模型成熟通过多年对电子工单系统和统一工单系统地建设，在需求、技术和应用等方面的积累，能够确保系统的功能开发能够满意电信运营企业的应用需求。在此基础上建立的也是成熟的系统模型，充分体现了电信企业的应用需求，保证系统能够最大程度的满意电信企业建设要求。二、信息模型明确依据服务开通系统建设和企业信息化改造须要，综合网络激活通过对自身的信息模型建设来适应企业的应用需求，这里主要有以下两个概念：激活工单：服务开通系统供应的用户激活工单内容，激活工单是须要由一个或多个、一个专业或多个专业的激活子工单实现。激活子工单：描述专业网管系统或网元所能识别的业务信息的工单，此工单能够依据专业网管或网元协议干脆转换成业务自动施工所需的指令或信息。三、体系结构灵敏借鉴面对服务的体系结构和组件化系统框架技术给系统供应了最大的灵敏性保障，将系统各个功能模块封装成系统服务，通过服务配置、服务调度总线进行组合，实现对不同企业业务实现需求的支持。四、分层设计思想分层设计思想能够使系统内部的结构清楚，降低系统内部的祸合度，提升系统的灵敏性，最大程度地支持系统功能定制。五、适配器技术应用系统须要接入多种专业网管系统和网元，引入适配器技术，能够最大程度的屏蔽不同专业网管系统和网元之间的接口差异，为系统供应统一的业务自动激活的操作接口，支持了业务、专业网管系统和网元的扩展需求。六、业务功能实现系统实现了对激活工单的预处理功能，降低了服务开通系统对专业设备和系统的依靠，提高了业务扩展的灵敏性。七、流程限制设计系统分两层实现了对工单处理简洁的流程限制功能，第一层是激活工单处理流程的限制，实现对激活工单到激活子工单转换过程中的处理流程限制；其次层是激活子工单处理流程的限制，实现对激活子工单自动开通操作过程的流程限制功能。前台功能介绍前台功能概述前台界面接受B/S结构，负责配置后台服务的配置数据和激活工单、激活子工单等的查询。主要功能包括：业务信息配置、激活信息配置、映射关系配置、网元信息配置、流程限制配置、工单维护管理、系统维护管理、系统平安管理和服务告警管理。业务信息配置业务信息配置管理的功能包括：业务接入系统、登录信息配置、激活工单产品、用户业务编码、用户业务参数、激活工单操作类型、区域信息配置、用户优先级配置、用户类型等，如图2-9所示：图2-9业务信息配置图业务接入系统负责配置北向接口的上层应用的相关信息。例如上层应用的名称、IP地址和详细描述信息等。上层应用在接入综合网络激活的系统之前须要先登记主机的IP地址，综合网络激活将拒绝生疏未认证的连接请求。登陆信息配置负责北向接口的上层应用的用户名和密码的配置。激活工单产品记录了须要开通的产品，一般包括：固网产品、智能网产品和小灵通产品等等。用户业务编码记录了激活工单的业务信息。用户业务参数记录了激活工单的参数信息。激活工单操作类型系统测试的时候运用，北向接口的上层应用的测试的时候不须要走完全部的流程，当综合网络激活收到激活工单后，马上返回成功。区域信息配置记录了各个地市的区域编码。用户优先级配置记录了激活工单SLA。激活信息配置激活信息配置的功能包括：激活子工单产品、网元业务类型、网元业务编码、网元参数等，如图2-10所示：图2-10激活信息配置图激活子工单产品和激活工单产品含义相近，也包括：固网业务、智能网业务、小灵通业务等等。网元业务类型负责将激活工单子产品依据用户的要求进行分类，主要包括：小灵通、INAS-HLR业务类和CEP业务类等等。网元业务编码和用户业务编码含义相像，表示针对网元的操作。网元参数记录了和网元业务相关联的参数。映射关系配置映射关系配置的功能包括：用户业务编码映射、用户业务条件映射、用户参数编码映射、用户参数条件映射、扩展字段映射、参数编码拆分映射等。如图2-11所示：图2-11映射关系配置图用户业务编码映射负责将激活工单中的业务编码映射为综合网络激活内部定义的激活子工单的业务编码。用户业务条件映射的工作和用户业务编码映射的功能相像，所不同的是可以依据激活工单中的业务编码和业务参数相组合来映射成激活子工单的业务编码。用户参数编码映射负责将激活工单中的用户参数映射成激活子工单的用户参数。用户参数条件映射的功能和用户参数编码映射类似，所不同的是支持组合推断。扩展字段映射支持对扩展字段部分的推断并映射。网元信息配置网元信息配置的功能包括：网元指令树、逻辑网元、物理网元、网元错误码、网元特征码、业务合并、网元业务关系等。如图2-12所示：图2-12网元信息配置图网元指令树负责配置网元指令模版，替换指令参数等等。逻辑网元负责存储网元的类型，一种逻辑网元对应一个或多个物理网元。主要包括：固话网元、移动网元、智能网网元等等。物理网元是逻辑网元的实例，同一个逻辑网元的物理网元都有同一指令集。网元错误码定义了网元的错误类型，把网元难懂的错误信息替换成易读的文本信息。网元特征码负责推断网元指令结果是否正确。业务合并将相关的网元业务合并成同一个业务。网元业务关系将逻辑网元类型映射成网元业务类型。流程限制配置流程限制配置的功能包括：路由信息配置、派发规则配置、工位信息配置等。如图2-13所示：图2-13流程限制配置图路由信息配置负责将激活工单的业务类型映射到物理网元。派发规则配置将激活工单业务派发给某个工位。工位信息配置负责一个或多个物理网元。工单维护管理工单维护管理的功能包括：激活子工单查询、激活子工单维护、激活子工单统计、激活工单查询、工单导入模板管理、工单导入、定时工单等。如图2-14所示：图2-14工单维护管理图激活子工单查询负责查询施工中的子工单。激活子工单维护负责维护相关子工单及历史上的工单。激活子工单统计负责统计相关的激活子工单。激活工单查询负责查询北向接口上层应用发送的相关激活工单。工单导入模版管理负责导入上层应用的工单。定时工单负责定时下发激活工单。系统维护管理系统维护管理功能包括：系统数据字典管理、系统错误码管理、系统服务配置管理、系统部署管理、前台日志管理、后台日志管理、数据库管理、人员考核管理等。如图2-15所示：图2-15系统维护管理图系统数据字典管理保存了系统相关表格的定义和说明。系统错误码管理存储了相关错误的定义。系统服务配置管理负责配置服务启动时的相关信息。系统部署管理负责启动/停止综合网络激活的相关服务。前台日志管理记录了用户登录综合网络激活的相关信息。数据库管理记录了操作人员对数据库所做的相关操作。人员考核管理记录了相关人员的考核信息。系统平安管理系统平安管理的功能包括：用户管理、角色管理、权限管理、父维护区信息、维护局向管理、系统异样管理等。如图2-16所示：图2-16系统平安管理图用户管理负责添加删除运用综合网络激活的用户。角色管理负责创建综合网络激活用户的相关角色。权限管理负责添加删除综合网络激活的相关用户权限。系统主要模块详细设计和实现服务结构服务是综合网络激活系统的基本单位，综合网络激活系统功能的扩展都是通过添加服务实现的。每种服务都有着自己独特的功能，例如，取单服务是负责接收北向接口上层应用发送的激活工单的；流程限制服务负责激活子工单转换为网元工单并限制网元工单的执行依次；工单处理服务则是将网元工单转换为指令并执行指令取得返回结果。假如把综合网络激活系统比方成积木玩具，服务就像积木中的一块形态各异的木头，不同形态的几种服务的组合构成了一个积木拼图。通过服务的组合，系统实现了各种需求。面对服务的架构使系统的更加灵敏并易于扩展，而且也有很好的继承性。综合网络激活的服务架构主要有以下几个特点：》运行载体(进程或线程)和业务逻辑的分别。》支持运行时服务的启动和停止。》服务运行异样的告警信息。》支持服务异样停止后自动重新启动。运行载体(进程或线程)和业务逻辑的分别综合网络激活对服务的运行载体和业务逻辑进行了分别，相同业务逻辑可以依据要求以线程或进程的方式运行。考虑到用户主机性能的差异，以及对负载的不同需求，系统供应了一种服务支持进程或线程两种不同的运行方式，最大限度的满意用户对系统效率、实时性、负载和性能方面的要求。假如用户的服务器配置比较好，可以接受进程的方式来启动系统中的服务。和线程运行方式相比，进程运行方式处理效率更高，实时性能也更好一些。假如用户服务器资源有限或服务器中已经存在了很多应用程序，建议接受线程的启动方式，线程方式相对于进程方式有效的节约了系统的资源，但是，处理效率、实时性能也相对低一些。为了达到执行效率和系统负载的最佳组合，综合网络激活系统支持进程/线程混合运用的模式。通过这种方式，可以依据现场的状况，灵敏配置服务的启动方式，尽可能的利用最少的资源达到用户对处理效率的需求。如上所述，综合网络激活系统是由各种服务构建而成的。系统中服务种类众多，系统最少会启动7个服务，最多时达到了22个服务，系统中服务如此众多，假如不对服务进行管理，维护起来将特殊困难。依据上面的缘由，设计出一种服务(SvcContainer)，这个服务和详细的业务逻辑无关，主要负责启动、停止、监控其他服务，也就是对其他服务进行管理。维护人员可以依据业务逻辑，将业务上相关的一组服务进程配置成同一个SvcContainer服务进行管理。例如，系统一般把取单服务和回单服务分别作为独立的进程来单独启动，流程派发和流程回单作为同一进程的一组线程启动。这样做较好的解决了系统性能和有限资源的关系，同时业务上相关的服务运行于同一进程，维护起来比较清楚便利。图3-1是添加删除服务、设置服务属性的界面。图3-1添加、删除服务界面服务架构设计综合网络激活的每个服务都必需由CService类派生，CService类主要实现业务逻辑，CService可以由线程或进程方式运行，线程/进程运行方式都由CRunable类派生，CService和CRunable之间的关系如图3-2所示：图3-2服务架构关系图如图3-2所示，CProcessRunable和CThreadRunable分别是进程运行体和线程运行体。他们有共同的父类CRunable，当调用CRunable的run方法时，线程/进程将起先运行，同理调用stop方法将停止进程或线程的运行。当完成CService业务逻辑的编写后，系统只须要产生一个进程/线程运行体的实例，然后调用CRunable类的setService方法并传入CService的引用，服务就可以运行了。综合网络激活系统中每个服务都有一个唯一标示自己的服务编号。依据服务编号系统可以确定该服务都有那些祖先服务，此外，还可以依据服务编号得到局数据库中属于自己的配置信息。综合网络激活的服务的启动特殊灵敏，可以接受进程/线程方式启动。服务可以形成一系列的进程组，一个以进程方式启动的服务可以有一个或多个以线程方式启动的服务。INAS主进程启动后首先启动的是服务号为1001服务，它的父服务编码为1，1001的服务启动后，依据数据库中的配置信息会分别启动那些父服务编号为自己的服务，以此类推每种服务启动后，都会启动自己的子服务。此外，综合网络激活对服务编码有确定要求，例如，服务编码为1001002003的服务，它的父服务和祖先服务分别是1001002和1001。综合网络激活服务器的启动和停止都是通过服务编码为1001的服务完成的，1001服务启动后会打开一个端口监听WEB界面发送启动/停止服务的叮嘱，假如前台界面发送的是启动指令，根服务首先会推断此服务是否正在运行，而后启动此服务，假如发送的是停止信号，根服务会发送停止信号给相应的服务，由于停止服务的操作存在较大风险，只有部分版本的程序具有此种功能。服务编码为1001的服务除了完成启动/停止服务的工作外，还具有接收其他服务告警信息的功能。根服务启动后打开告警端口，接收其他服务发送的UDP告警消息，将消息解析入库，前台界面可以依据数据库中的告警消息，将异样代码/错误号等替换为详细的告警信息。值得一提的是，某些省如海南、湖北等还支持短信告警的功能。告警的接收等功能由根服务完成，告警的产生则由子服务自己产生，告警的产生必需依据数据库中订阅的告警信息和门限值来产生。综合网路激活系统中全部的服务都是根服务1001的子孙服务，所以当以进程方式启动的子服务异样停止的时候，根服务会接收到信号SIG_CHLD，根服务推断是否为异样停止，假如服务须要重新启动，根服务会接着尝试重新启动此服务。综上所述，综合网络激活的服务设计是其他服务设计的基础，系统中全部服务都必需由此种服务派生。此外，系统中的根服务也是系统中的核心，它担负着启动、初始化其他服务，监控其他服务的运行，管理其他服务等功能。但是，系统跟服务没有实现业务逻辑，根服务是为其他和业务逻辑相关服务供应支持的基础服务，就好比一个公司架构中的职能部门，他们虽然不干脆产生效益，但是为其他职能部门供应了办公、IT、社保等必要支持，同样是架构中必不行少的组成部分。日志处理对于任何实时系统，日志模块都是特殊重要的，开发人员、工程人员和维护人员须要通过系统输出的日志推断系统的运行状况，查找潜在的问题等等。综合网络激活的日志模块是特殊灵敏的，可以通过配置文件选择输出的格式、文件的命名或日志级别，而且可以选择输出到某个设备(标准输出、文件或其他设备等等)。综合网络激活的日志模块由CLoggerRepository、CLoggerFactory、CLogger、CAppender、CLogEvent、CLayout、CConsoleAppender、CFileAppender和CLevel类。CAppender、CFileAppender和CConsoleAppender负责把消息输出到不同的设备。CFileAppender和CConsoleAppender是CAppender的子类，CFileAppender负责把消息输出到文件，CConsoleAppender负责把消息输出到屏幕。CLoggerRepository是日志模块的容器类，存储着CLogger的实例。CLoggerFactory是日志模块的工厂类，负责产生各个不同类型的CAppender的子类。CLogEvent存储着要打印到设备的消息内容。CLayout负责消息输出的格式。CLevel负责保存了消息的级别。图3-3日志模块静态类图异样处理异样处理是程序开发的一个重要内容，异样处理的好坏关系到程序的健壮性和系统的稳定性。C++是一种纯面对对象的编程语言，其异样处理机制和面对过程通的编程语言有很多不同的地方，异样处理有力地增加了C++程序的健壮性和容错性。综合网络激活构建了自己的异样类家族，以便更好地运用C++异样处理机制。综合网络激活全部异样类都是从CException的子类。CException有两个方法，分别是errCode和what方法。errCode保存着错误代码，what打印出错误的缘由。除了CException类外，数据库中还有一个tSystemErrorInfo表，此表有两个字段分别是iErrCode和vcDesc，分别保存了错误代码和相应错误代码的详细描述信息。系统中每个类都有唯一的错误代码，出现错误的时候依据错误代码可以推断出错的类，以及错误的详细信息描述。取单服务(北向接口)综合网络激活的取单服务负责从服务开通、CRM等上层应用获得激活工单。取单服务接受的通信协议是多种多样的，有基于TCP的结构化消息、XML消息和Webservice消息，基于UDP的结构化消息，接受FTP户文件的方式和数据库接口表的方式。无论接受何种通信协议，最终必需将消息转换为激活子工单许久化到数据库中。本章节主要介绍基于TCP的XML消息和Webservice方式的取单服务，以及如何由激活工单最终转换为激活子工单的大致过程。异步交互流程业务工单的异步交互流程从服务开通系统向综合网络激活系统发送工单起先，综合网络激活系统在接收到工单后，向服务开通系统返回工单发送回执，以上两步完成了工单的发送工作。如服务开通系统在指定时间内未收到回执，服务开通系统将负责工单的重发。综合网络激活系统获得工单后，对工单进行解析、拆分和调度，并将工单通过网络配置接口在网元上激活并得到执行结果。对执行结果进行分析后，综合网络激活系统将经过分析的执行结果反馈给服务开通系统，服务开通系统接收到工单结果后返回回执，通过以上五步完成了服务开通系统和综合网络激活系统的异步交互。下图描述了业务工单的异步交互流程，目前绝大部分业务工单的交互流程都接受异步方式。如图3-4所示：图3-4激活工单消息交互流程工单消息构成》工单中包含公共信息、产品信息、资源服务信息。》工单间关联原则上在服务开通系统内限制，必要时可以扩展工单的关联关系。资源服务的依靠关系和执行依次由综合网络激活系统限制。》对于工单中存在会导致网元上用户己有数据丢失的资源服务实例(例如S1240交换机上，用户纳入虚拟网或改号等)，工单中应传送该用户已有的资源服务实例，动作为保持。》当做资源服务变更时相关的资源信息须要传送变更的新旧值。》工单中的属性相关名称信息节点为冗余字段，包体中不填写名称信息，应当可以正常激活。》需追单时服务开通系统负责生成原工单的反向工单，工单号和原工单号不同，工单类型为追单，并将原工单号作为关联工单号、关联关系为反向信息送给综合网络激活系统。综合网络激活系统只负责反向工单的执行(原工单未执行时，因是追单，必需将两张工单均不执行反馈给服务开通系统)，不负责反向工单的生成。工单消息类型》业务请求包：服务开通系统发送的开通或查询消息包。》消息确认包：异步通信时，综合网络激活系统或服务开通系统对接收到请求反馈消息包的应答消息，确认消息包是否成功接收。》业务反馈包：综合网络系统将请求包执行结果反馈给服务开通系统的消息包。工单消息结构工单包体分为两部分消息鉴权部分head和请求信息部分body。如图3-5所示。图3-5工单消息结构head业务工单包消息头部分信息：消息头主要定义消息的头部信息。定义消息流水号，消息产生时间，鉴权信息，消息类型等。如图3-6所示：图3-6工单头消息结构1.time：消息生成(或称发送)时间。2.login：鉴权认证登录ID。3.passwd：鉴权密码。4.to：消息目的地，可填写消息目的地系统ID。5.type：消息类型，参见静态数据消息类型列表取值。6.id：消息包唯一标识，由发送系统和消息流水号构成，确认包体中的反馈流水号(ackid)应当对应于请求包体中的流水号。7.from：消息来源，可填写消息来源的系统ID。body部分的定义，允许一次请求里面包含多个工单，也就是支持批量，但此时必需供应批量单的流水号和批量单个数。假如仅有一个工单，则批量单相关的参数bid、Count不能填写。如图3-7所示：图3-7工单消息结构体工单包体的组成层次结构。其中涉及到的元素主要有公用信息，产品信息，资源服务实例集，资源服务实例。如图3-8所示：图3-8工单属性结构公共信息中(public_info)包含工单标识、工单类型、工单间关联关系和区域代码信息，如图3-9所示：图3-9工单public_info结构1.wid：工单号，工单在综合网络激活系统的唯一标识。2.wtype：工单类型，值域{QRY，ACT，TST，PRG}，对应{query查询、activity激活、test测试、progress进度查询}。3.rela_info：工单关联信息，用于标识此工单和其它工单的关联关系。4.sla_info：SLA信息。5.cust_info：客户信息。每个工单实例可由多个产品实例构成(但其中只能由一个主产品)，每个产品实例可由多个资源服务实例构成。如图3-10所示：图3-10工单products结构业务反馈包是对请求执行结果的反馈。业务工单反馈信息包体中包含工单标识、执行结果编码、执行反馈信息、执行失败资源服务列表和反馈信息列表，如图3-11所示：图3-11工单body结构消息确认包体是请求包和反馈包接收结果的确认消息，主要由消息流水号、反馈消息流水号、反馈值编码、错误描述信息组成。如图3-12所示：图3-12工单msg结构静态数据定义全部静态数据编码统一接受小写字母，多个单词之间接受下划线连接。编码接受业界流行的描述进行编码，以提高可读性。返回值列表可依据实际状况灵敏扩充，如表3-1到3-4所示：表3-1资源服务动作类型列表表3-2消息类型列表表3-3工单类型列表表3-4返回值列表取单服务设计综合网络激活的取单服务主要完成从服务开通、CRM(客户管理系统)或计费等北向接口上层应用收取激活工单，而后将激活工单（上层服务器，福开系统）转换为激活子工单（网络激活系统，dispatch函数），最终将激活工单和激活子工单许久化到数据库。在实现过程中，取单必需从CControl派生，并重写init、run等方法实现自己的业务逻辑。图3-13取单服务静态类图图3-13是取单服务的静态类图。下面对所涉及的类进行详细说明。CSoapServerContainerControl会依据数据库中的最大连接数建立一个连接池，等待北向接口的外部应用发起连接请求，最终将连接的描述符发送给CAsyncRecvControl进行进一步处理。CAsyncRecvControl详细实现了和北向接口的上层应用通信和相关业务处理逻辑。CAsyneRecvControl首先调用INASProvisionSoapBindingProxy类接收外部应用发送的XML消息，将XML消息解析成CBATicket类，而后调用类CBTASwitcher将激活工单转换为激活子工单(在上文已经提到每个地区的接收的消息结构和激活工单都可能存在着差异，但是激活子工单都是相同的)，最终将接收的激活工单和激活子工单许久化到数据库中。INASprovisionSoapBindingService负责接收外部应用发送的XML消息，它由类soap派生而来，soap是gSoap框架依据wsdl自动生成的代码。它调用CSTDTicketSwitcher将接收的消息解析成CBATicket类。CBATicke类存储了激活工单以及激活子工单(CBSSService类和CActService类)。CBSSService存储了激活工单。CActService存储了转换后的激活子工单。CBTASwitcher将激活工单转换为激活子工单，并把以上两种工单许久化到数据库中。主要包括两种映射，分别是用户业务编码的映射和用户参数的编码映射。CSvcMapping是用户业务编码映射的接口，其他的用户业务编码映射都必需由此派生。CSvcCodeMapping类由CSvcMaPPing派生，负责将激活工单的用户业务编码依据数据库中的配置信息映射成激活子工单的用户业务编码。CSvcCondMapping类由CSvcMapping派生，和CSvcCodeMapping不同，它是依据维护人员配置的逻辑表达式将激活工单的业务编码映射为激活子工单的业务编码。CServiceConditionMapping类由CSvcMapping派生，负责依据XML消息中的用户业务ID字段将激活工单的业务编码映射为激活子工单的业务编码。CTicketHeadMapping类由CSvcMapping派生，依据XML消息头中的相关信息进行映射。CparaMapPing是用户业务参数映射的接口，其他的用户业务参数映射必需由此派生。CparaCondMapping类由CParaMapping派生，负责将激活工单的用户参数编码依据数据库中的配置信息映射成激活子工单的用户参数编码。CParaCondSplitMapping类由CparaMapping派生，依据维护人员配置的逻辑表达式将激活工单的参数编码映射为激活子工单的参数编码。CParaToHead类由CParaMapping派生，依据消息头的信息将激活工单的参数映射为激活子工单的业务参数。取单服务时序