专利名称：Soa在外围系统访问核心支撑系统的实现方法
技术领域：
本发明是对软件架构概念面向服务的体系结构SOA (Service-Oriented Architecture)的一种具体实现，是一种理论架构的具体实现，为S0A在外围系统访问核心 支撑系统的实现方法。
背景技术：
统一接口平台用来处理电信行业外围系统对核心运营/支撑系统(B0SS/BSS/ 0SS)的接入和功能访问。外围接入系统包括客户服务自动台、网上营业厅、WAP网厅、短信 营业厅、掌上营业厅、掌中助理、空中写卡、缴费卡缴费系统、银行代缴费、SP系统、以及各种 代理商系统等等，外围系统的特点是建设时间跨度大、接入技术杂、接入量大、接入并发度
高、管理难度大。行业内原有的外围接入支撑方法是针对不同的外围系统、不同的接入技术在核心 功能域侧建设不同的适配系统。适配的接入技术包括各种自定义/行业Socket协议、各种 自定义/行业WebService接口规范、各种基于HTTP协议的自定义接口、Tuxedo接口等，由 于适配系统和适配技术不断增多，给渠道扩展、业务推广、系统维护都带来了很大难度，增 加了电信运营商的运营成本。随着电信技术/业务的不断发展、以及渠道的不断丰富，需要 能对外围系统的接入进行统一支撑和管理。
发明内容
本发明要解决的技术问题是在电信行业的信息处理中实现S0A，解决外围系统 到核心系统接入技术杂、接入量大、接入并发度高、管理难度大等问题。本发明的技术方案是S0A在外围系统访问核心支撑系统的实现方法，在外围系 统与支撑系统之间设置统一接口平台UIP，UIP包括5个基础组件和5个可独立运行的子系 统5个基础组件配置管理、连接管理、安全管理、线程管理、协议适配器；5个子系统接入子系统、JMS消息管理器、接出子系统、监控管理子系统、业务处 理子系统，子系统中使用基础组件；通过JMS消息管理器将外围系统接口调用过程划分为接入处理、消息管理、接出 处理三个过程的异步处理方式，每个过程只要处理一种协议接入过程实现外围系统和 JMS的消息转换和交换，接收/加工外部消息，交给JMS消息管理器，从JMS管理器获取应答 消息，返回给外围系统，由接入子系统负责；消息管理JMS消息管理器负责UIP的消息管理，具体包括消息接收、消息存放存 放于内存/文件/数据库、消息生命周期管理过期消息将被删除、消息优先级管理、消息队 列管理；接出过程实现JMS和核心支撑系统的消息转换和交换，从JMS消息管理器获取 /加工消息，访问核心系统功能，加工核心系统返回的消息，交给JMS消息管理器，由接出子系统负责；UIP内部流转的数据是JMS消息，提供基于WebService和Socket协议族的接口规 范。UIP的异步处理机制通过实现两方面的解耦处理外围系统接入请求1)外围系统接入协议和核心系统接口协议解耦；2)外围系统接入客户端数/请求量和核心系统允许并发数/处理能力解耦。接入子系统实现HTTP、Socket协议的Server功能，负责监听外围系统接入请求 和接收请求数据，并将外围系统发给UIP的SOAP消息包、Socket数据包转换成UIP标准消 息包；UIP标准消息包为由XML结构组织的数据包，UIP内流转的消息都采用UIP标准消息 包，也就是JMS消息都采用UIP标准消息包的形式，消息包包括包头和包体两部分包头部 分的字段名和字段数固定不变，包括UIP消息内部管理使用的信息和业务管理使用的基础 信息；包体部分是与具体功能接口相关的字段，不同的功能接口字段数量和字段名称不同， 报文体根据需要灵活定义。接出子系统实现通用客户端功能，UIP的协议适配器定义消息转换接口和通用客 户端接口，由协议插件实现所述接口，接出子系统通过不同的协议插件实现对不同核心支 撑系统的出访。UIP的监控管理子系统监控/管理接入子系统、JMS消息管理器、接出子系统中的 通用线程池、Socket连接池、J0LT连接池、JMS消息。优选使用ActiveMQ进行JMS消息管理。本发明在外围系统与支撑系统之间设置统一接口平台UIP(Uniform InterfacePlatform)，外围系统访问核心系统时，外围系统的接入协议可能是WebServie、 某种自定义Socket、HTTP等；核心系统提供的可能是Tuxedo、JDBC、自定义Socket、自定义 WebService, FTP等。以往核心系统的接口适配系统以同步方式解决外围系统和核心系统 在种协议和请求量的对接，不仅系统复用性差，并发性高接入量大时系统稳定性差。本发明 采用异步处理的方式，UIP通过消息JMS消息管理器将外围系统接口调用过程划分为接入 处理和接出处理，每个过程只要处理一种协议，与以往系统架构相比处理过程简洁高效，且 各过程只管理自己的连接，良好的动态伸缩性能保证外围接入并发高、请求量大的情况。本发明带来的有益效果及实现方式如下1)、降低核心功能域对外提供新接口功能的成本。只要实现UIP接出子系统对核心系统功能的访问，在UIP接入子系统只需注册和 发布该接口，外围系统即可基于UIP接入子系统支持的协议访问该功能。而UIP接出子系 统如果是基于已有接出协议访问核心系统，也只需要按照标准配置文件对核心系统功能进 行配置即可，不需要额外的编码工作；2)、降低支持新接入/接出协议的成本。UIP将接口协议实现和接口业务描述相剥离，通过“协议适配器”基础组件，我们只 需要开发相应协议的插件即可基于该协议实现UIP的接入或接出功能，即可基于该协议支 持已发布的接口功能；3)、提高外围系统访为核心系统时的稳定性。UIP通过消息管理器将传统的接口调用过程解耦为接入过程和接出过程，接入过程只负责处理接入协议、报文处理、连接管理等工作，接出过程只负责接出协议、报文处理、 连接管理等工作。实现接入协议、消息格式、连接管理的解耦。大大降低了系统的复杂度， 从而从基本架构上奠定了系统稳定的基础。UIP通过基础组件实现了系统动态伸缩性、运行 时的动态配置管理功能，提高了外围请求并发量、请求量突发激增时的系统稳定性；4)、降低维护成本。UIP基础组件和各运行子系统提供了监控/管理接口，通过UIP的监控/管理子系 统可方便监控系统各部分的运行状况，可快速诊断、定位问题。同时UIP提供运行时管理功 能，可动态调整系统参数、增加/减少运行单元，而不用中断系统运行，从而提高电信运营 商的运营支撑质量，降低运营成本；5)、提高对外围系统运营的统计分析功能，从而有效支撑了电信运营商的精细化 运营。UIP对外围系统的接口调用信息进行详细记录，内容包括接入渠道、接口名称、调用结 果(成功/失败)、接口调用时长、电话号码、用户品牌等。通过分析这些信息电信运营商可 以了解各外围系统的业务开展情况，进而对外围系统将来的发展情况进行规划，以更好的 支撑业务推广和发展；通过对电话客户的分析，可对不同属性的客户划分成客户群，进而制 定针对不同客户群的营销方案，提高运营质量。与现有的外围系统访问核心系统的方法相比，本发明的特点在1)、把接口调用拆分成接入、接出两个过程，将外围系统和核心系统解耦，降低系 统复杂度、提高系统稳定性。现有外围系统一般以同步方式实现对核心系统的访问，这种方式在外围系统并发 量、请求量突发增大的情况下，系统稳定性差；通过在外围系统和核心系统之间架构UIP， 将调用过程拆分成接入、接出两个过程，接入过程只处理外围系统的接入处理，接出过程只 处理对核心系统的功能访问，两者通过JMS消息管理器衔接起来。2)、提高了接口开发速度，降低项目实施周期，提高客户需求响应速度。以往外围系统访问核心系统时，往往针对不同的接入协议，在核心系统侧需要开 发不同的接口适配系统，这种方式不仅开发工作量大、开发周期长，而且系统的复用性差， 有时增加一个新接口就需要大量的开发工作；UIP实现了电信行业主要的协议和接口标 准，支持新的外围接入时只需要开发协议插件即可，提供新的接口功能时，只需要进行一些 配置工作，实现功能的注册、发布即可。3)、提高了外围系统访问核心系统的可监控、维护性。以往外围系统访问核心系统时，缺乏完善的监控手段，没有监控界面、日志信息， 更没有管理功能，维护难度较大，问题诊断/定位周期较长；UIP各基础组件和运行子系统 都提供了完善的监控/管理接口，提供日志信息、前台监控/管理界面等多种监控/管理手 段，从而大大降低了诊断/定位问题的时间。4)、实现对外围系统访问核心系统的统计分析功能。以往外围系统访问核心系统时只简单记录了接口调用日志，且分散在不同的数据 表中，没有提供相应的统计分析功能，电信运营商从核心系统的接口管理层面基本了解不 到各外围系统的运营情况。UIP以统一的格式记录了各外围系统对核心系统的访问情况古， 可进行多种纬度的统计/分析。
图1为本发明的结构示意图。图2是本发明UIP系统架构图。图3是本发明UIP工作流程图。图4是本发明协议适器解析协议消息流程图。图5是本发明协议适配器组装UIP标准消息流程图。
具体实施例方式本发明实现了外围接入系统和核心支撑系统的解耦，外围系统看到的只是一个统 一的服务提供者，不需要知道内部实现；本发明内部使用消息管理器JMS对接入过程和接 出过程进行解耦，JMS为JAVA消息服务(Java Message Service)，以异步方式实现外围系 统对核心支撑系统访问的处理过程，有效处理接入量大、并发高的外围接入请求；本发明使 用协议适配器对UIP消息处理过程和具体协议实现解耦，使UIP能更好的支持不同协议，适 应电信行业要求。如图1，本发明在外围系统与支撑系统之间设置统一接口平台UIP，UIP包括5个 基础组件和5个可独立运行的子系统5个基础组件配置管理、连接管理、安全管理、线程管理、协议适配器；5个子系统接入子系统、JMS消息管理器、接出子系统、监控管理子系统、业务处 理子系统，子系统中使用基础组件；通过JMS消息管理器将外围系统接口调用过程划分为接入处理、消息管理、接出 处理三个过程的异步处理方式，每个过程只要处理一种协议接入过程实现外围系统和JMS的消息转换和交换，接收/加工外部消息，交给 JMS消息管理器，从JMS管理器获取应答消息，返回给外围系统，由接入子系统负责；消息管理JMS消息管理器负责UIP的消息管理；具体包括消息接收、消息存放 存放于内存/文件/数据库、消息生命周期管理过期消息将被删除、消息优先级管理、消息 队列管理；接出过程实现JMS和核心支撑系统的消息转换和交换，从JMS消息管理器获取 /加工消息，访问核心系统功能，加工核心系统返回的消息，交给JMS消息管理器，由接出子 系统负责；UIP内部流转的数据是JMS消息，提供基于WebService和Socket协议族的接口规 范。UIP的异步处理机制通过实现两方面的解耦处理外围系统接入请求1)外围系统接入协议和核心系统接口协议解耦；2)外围系统接入客户端数/请求量和核心系统允许并发数/处理能力解耦。接入子系统实现HTTP、Socket协议的Server功能，负责监听外围系统接入请求和 接收请求数据，并将外围系统发给UIP的SOAP消息包、Socket数据包转换成UIP标准消息 包。UIP标准消息包为由XML结构组织的数据包，UIP内流转的消息都采用UIP标准消息 包，也就是JMS消息都采用UIP标准消息包的形式，消息包包括包头和包体两部分包头部 分的字段名和字段数固定不变，包括UIP消息内部管理使用的信息和业务管理使用的基础信息；包体部分是与具体功能接口相关的字段，不同的功能接口字段数量和字段名称不同， 报文体根据需要灵活定义。接出子系统实现通用客户端功能，UIP的协议适配器定义消息转换接口和通用客 户端接口，由协议插件实现所述接口，接出子系统通过不同的协议插件实现对不同核心支 撑系统的出访。UIP的监控管理子系统监控/管理接入子系统、JMS消息管理器、接出子系统中的 通用线程池、Socket连接池、JOLT连接池、JMS消息。这里说的“监控/管理”是UIP的监 控管理子系统的智能。接入子系统、JMS消息管理器、接出子系统三部分构成了 UIP的核心架构，UIP监控 管理子系统负责对这三个核心架构子系统中的连接池、线程池、JMS收发/积压情况等进行 监控和管理。这里说的监控和管理是对消息管理器的监控/管理，其中集成了 JMS消息管 理对JMS消息管理的部分功能，比如删除过期消息、生成一个消息发到某个消息队列等。本发明中，JMS消息管理器使用JMS规范的一种具体实现产品ActiveMQ进行消息 管理。下面结合附图具体说明本发明。图2是本发明UIP系统架构图，可分为三部分1)右侧“UIP自定义Socket”、“HTTP (WebService) ”代表外围系统接入；2)左侧“客服系统”、“核心运营支撑系统”、“DB”代表核心系统；3)中间描述UIP架构;UIP包括5个基础组件和5个可独立运行的子系统5个基础组件配置管理、连接管理、安全管理、线程管理、协议适配器5个子系统接入子系统、JMS消息管理器、接出子系统、监控管理子系统、业务处 理子系统，子系统中使用基础组件。图3是本发明UIP工作流程图，描述了一个调用过程中外围系统、UIP、核心系统三 者的工作过程，主要描述了 UIP内部工作过程。图2的顶部描述了 5个角色外围系统、UIP 接入子系统、ESBQMS消息管理器)、UIP接出子系统，核心系统，其中“UIP接入子系统”、 “UIP接出子系统”描述了接入处理、接出处理的处理过程，描述了在各自子系统内同步方式 和异步方式两种处理模式，其中红色部分为异步方式时由单独执行单元执行。接入子系统同步处理往JMS消息管理器发送消息后在对应的应答消息队列上等 待消息返回。消息的发送和接收以同步方式顺序执行完成；接入子系统异步处理往JMS消息管理器发送消息后该流程即结束，该过程一般 为多线程方式，另一流程专门守护应答队列，有消息即获取，然后找到与该消息对应的客户 端连接，将该消息返回给外围系统，该过程为单线程方式；接出子系统同步处理将请求消息发给核心系统后等待核心系统的应答返回；接出子系统异步处理将请求消息发给核心系统后该流程即结束，该过程一般为 多线程方式，由另一流程专门守护与核心系统的接收连接，该过程一般为单线程方式，接收 所有应答消息，经过处理后发往JMS消息管理器；图4是本发明协议适器解析协议消息流程图1).解析消息，获取接收到的消息的总长度(A长度)；
8
2).根据接口编码计算接口配置信息中所有字段的总长度(P长度)，校验A长度 和P长度是否相等，以验证消息长度是否合法；3).如果总长度不合法则异常结束，如果总长度合法则根据接口编码获取接口各 字段的配置信息，主要是字段值最大允许字节长度，对消息进行解析，并校验各字段数据的 合法性；4).如果有字段数据不合法则异常结束，如果消息正常解析完则将解析出的数据 存放到中间容器中，解析过程结束。图5是本发明协议适配器组装UIP标准消息流程图1).根据接口编码获取该接口的配置信息； 2).根据接口配置信息，将存放在中间容器中的数据封装成UIP标准消息。外围系统访问核心系统时实现S0A的过程可分为三个过程1)对核心系统功能的 组织；2)接口服务在UIP中的注册和发布；3)外围系统对所发布服务的访问。详细步骤如 下a.开发UIP接出子系统访问不同核心系统所需要的协议插件，实现核心系统消息 格式和标准UIP平台消息的相互转化，并实现UIP接出子系统和UIP JMS消息管理器基于 UIP标准格式消息的消息交互，从而实现UIP对核心系统功能的组织；UIP是开放式系统架 构，通过协议适配器可实现不同协议的插件。了解UIP结构后，本领域技术人员可设计自己 的协议技术规范和协议插件。b.开发UIP-WebService协议和UlP-Socket协议，本发明的一个协议的具体实施 例见后面的“UIP接口技术规范”，实现UIP发布服务的标准协议和服务接口规范；S0A — 般以WebService接口作为服务发布的标准接口，但考虑到电信行业特点，存在为数众多 的Socket协议和其他协议的外围系统，因此UIP除了提供UIP-WebService外还提供了 UlP-Socket，此外，还可开发针对其他协议的协议插件；c.在UIP接入子系统中，将UIP接出子系统中已组织的核心系统功能的输入/输 出业务要素配置成标准的接口配置文件，该标准的接口配置文件的内容以XML格式组织， UIP-WebService协议和UlP-Socket协议都可以解析；d.在UIP中注册已配置好的接口，将接口名称注册到接口功能参数表，状态字段 为未发布；e.在UIP中发布已注册好的接口，将接口功能参数表中的状态字段改为已发布状 态；此外，还可以在UIP中登记外围系统的信息，并对外围系统允许调用的接口分配该外围 系统，只有分配到该外围系统下的权限该外围系统才可以调用，以此实现安全性控制；f.将UIP接口规范(技术规范和业务规范)和接口服务发布地址公布给外围系 统，外围系统依据接口规范开发自己程序，调用UIP发布出来的接口服务。以UIP-WebService接口规范为例，描述外围系统通过UIP访问核心系统“余额查 询”功能的S0A具体实现过程1.外围系统将按照UIP-WebService组织好的“余额查询”消息发送给UIP接入子 系统；2. UIP接入子系统接收到该报文后，获取接口报文中的接口编码和外围系统编码， 校验该接口是否已发布，校验该外围系统是否有调用该接口的权限，如果校验通过，根据接口编码获取“余额查询”的接口配置信息，对接口报文的合法性进行校验，然后将消息封装 成JMS消息发往JMS消息管理器的特定消息队列，并在对应的应答队列等待应答消息返 回；3.接出子系统从JMS消息管理器的特定消息队列获取JMS消息，从中解析出“余 额查询”的UIP标准消息，根据“余额查询”的接口编码和UIP接出子系统对核心系统功能 的组织规则，使用对应的接出子系统使用的接出协议处理器将UIP标准消息转化成核心系 统要求的消息格式，发往核心系统，等待核心系统返回应答消息；4.接出子系统接收到核心系统返回的应答消息后，使用相同的接出协议处理器将 核心系统的消息格式转换成UIP标准消息，封装成JMS消息发往JMS消息管理的特定应答 消息队列；5接入子系统从JMS消息管理器的应答队列中获取JMS消息后，从中解析出UIP标 准消息，返回给外围系统。UIP接口技术规范包括基于HTTP协议的UIP WebService接口规范和基于TCP/IP 协议的UIP Socket技术规范，这两个规范彼此独立，分别用于规定基于HTTP协议和TCP/IP 协议接入UIP的接口标准。这两个接口规范有一定的共性，接口标准都分为包头和包体两部分，包头部分的 字段名和字段数固定不变，包括包信息说明和业务管理使用的基础信息；包体部分是与具 体功能接口相关的字段，不同的功能接口字段数量和字段名称不同，包体可根据需要灵活定义。UIP WebService接口规范使用XML结构组织包数据的接口标准。实际数据包中 每个字段都有对应的逻辑字段名称，可基于逻辑字段名解析出对应字段值。包数据一般采 用UTF-8编码。客户端与UIP之间采用短连接。UIP Socket接口规范由数据串组成的数据包，包头定长，包体变长，包体字段数 据间、记录数据间使用分隔符进行分隔。实际包中一般没有字段逻辑名，只有字段值。客户 端和UIP之间可采用长连接或短连接。WebService 接 口规范WSDL 文件WS接口描述文件内容如下所示< ？ xml version = " 1.0" encoding = 〃 UTF-8" ？ ><wsdl:definitions xmlns:soap = " http://schemas.xmlsoap.org/wsdl/ soap/"xmlns :tns = " http://www.linkage.com/UIP/"xmlns:wsdl = " http://schemas.xmlsoap.org/wsdl/"xmlns:xsd = " http://www.w3.org/2001/XMLSchema" name = 〃 UIP"targetNamespace = " http://www.linkage.com/UIP/" ><wsdl: types)<xsd:schema targetNamespace = " http://www.linkage.com/UIP/" ><xsd:element name = " businessCallRequest" ><xsd:complexType>
10
<xsd: sequence)<xsd: element name = “ svcCode “ type =〃 xsd: string/r /><xsd:element name =" requestMessage"type = /r xsd: string/r /></xsd: sequence)</xsd: complexType></xsd: element)</xsd: schema〉</wsdl: types)<wsdl :message name =〃 businessCallRequest 〃 ><wsdl :part element =" tns: businessCalIRequest “name = “ businessCallRequest" /></wsdl: message〉<wsdl:message name = “ businessCallResponse“ ><wsdl :part type =〃 xsd: string" name =〃 businessCallResponse “ /></wsdl: message〉<wsdl:portType name =" UIP" ><wsdl: operation name =〃 businessCal 1 〃 ><wsdl: input message =〃 tns: businessCal IRequest “ /><wsdl: output message =" tns: businessCalIResponse “ /></wsdl: operation〉</wsdl: portType>〈wsdl:binding name =" UIPS0AP" type = " tns:UIP" >〈soap:binding style =" document"transport =" http://schemas. xmlsoap. org/soap/http" />〈wsdl: operation name =〃 businessCall 〃 >〈soap: operation/)<wsdl: input)〈soap:body use = " literal" /></wsdl: input)〈wsdl: output〉〈soap:body use = " literal" />〈/wsdl: output〉〈/wsdl: operation〉〈/wsdl: binding〉〈wsdl: service name =〃 UIP〃 >〈wsdl :port binding =" tns:UIPS0AP" name = " UIPS0AP" >〈soap: address
location = “ http://130. 34. 4. 4:17001/uip_inws/ services/UIPSOAP" /></wsdl:port></wsdl:service)</wsdl:definitions)WebService 接口地址根据UIP实际部署环境确定。服务接口及接口方法说明服务入口UIP服务入口方法businessCallString businessCall(BusinessCallRequest businessCallRequest)请求参数businessCallRequest包括一个服务名称、服务输入参数，服务要求的 输入参数见UIP WebService报文结构。返回参数为一 XML结构字符串，参见UIP WebService报文结构。报文UIP WebService 报文结构 报文头说明 X_TRANS_C0DE :UIP对外提供的服务编码。
PR0VINCE_C0DE 省别编码。
IN_M0DE_C0DE 接入类型编码。
TRADE_EPARCHY_CODE 地州编码。填写实际地州编码(依各省具体情况而定) 或 “INTF”。
TRADE_CITY_CODE 业务区编码。
TRADE_DEPART_ID 部门编码。
TRADE_STAFF_ID 员工编码。
TRADE_DEPART_PASSWD 渠道密码。密文形式，建议使用MD5加密。
R0UTE_EPARCHY_C0DE 预留字段。填写为4个空格。
CHANNEL_TRADE_ID 外围系统生成的流水号，用来唯一代表该请求消息。流水 号中的合法字符为W 9]。
X_RESULTC0DE 服务调用结果编码。分为两种情况，0 成功；非0 失败(包括 系统错、业务错)。服务调用结果描述。
X_REC0RDNUM 结果记录数。报文体说明1.实际运行时如果字段名为SERIALNUMBER，则内存中FIELDNAME% >部分为 “<SERIALNUMBER> 13851802186</SERIALNUMBER>字段值一律使用 String 表示。2.目前只支持通过<FIELD>描述多条记录，绝大多数的业务数据都可以通过这种 方式来描述。Socket 接口 规范通讯协议采用TCP/IP标准协议。外围系统作为Socket Client,UIP作为Socket Server, Client向Server发送请求报文，Server向Client返回应答报文。请求报文由Client按照UIP Socket接口规范组织控制信息、业务信息形成的数 据包。应答报文由Server按照UIP Socket接口规范组织控制信息、业务信息形成的返 回数据包。报文统一采用UTF-8编码方式。报文UIP Socket 报文结构报文头定长，报文体变长。
报文头报文头组织规则报文头字段定长。不足位，右补空格。报文头字段说明 LENGTH:报文总长度。LENGTH =报文头长度(149字节)+报文体长度+包结束 符长度(1字节) VERSION :UIP Socekt 接 口 规范版本号。
CHANNEL_TRADE_ID 外围系统生成的流水号，用来唯一代表该请求消息。流水 号中的合法字符为W 9]。
X_TRANS_C0DE :UIP对外提供的服务编码。
PR0VINCE_C0DE 省别编码。
IN_M0DE_C0DE 接入类型编码。
TRADE_EPARCHY_CODE 地州编码。填写实际地州编码(依各省具体情况而定) 或 “INTF”。
TRADE_CITY_CODE 业务区编码。
TRADE_DEPART_ID 部门编码。
TRADE_STAFF_ID 员工编码。
TRADE_DEPART_PASSWD 渠道密码。密文形式，建议使用MD5加密。
R0UTE_EPARCHY_C0DE 预留字段。填写为4个空格。
CUR_N0 当前包编号。
T0TALNUM 总包数。
FLAG 请求/应答标识。如果是外围系统发给UIP的请求包，置0 ；如果是UIP返回给外围系统的应答包，置1。
RESULTC0DE 结果编码。请求包为8个空格，应答包为具体结果编码，0 成功， 非0 失败(包括系统错、业务错)。报文体报文体组织规则存在多条请求记录或返回记录的业务，一个报文可包括多条记录。一个报文总长度不超过20K，大于20K的业务数据应以多报文方式发送。如果调用成功报文体返回正常业务数据。如果调用失败报文体返回错误信息(错误编码存放在报文头“结果编码”字段)。 分割符字段分割符0x09 (TAB键)记录分割符0x0a (换行)包结束符0xla数据格式规则时间字段以14位数据表示(如20081121203621)费用字段以分为单位连接UIP支持外围系统以长连接、短连接两种方式请求平台服务。短连接Client (外围系统)每次请求Server (UIP)服务时首先建立到Server (UIP)的连 接，Server返回应答报文后关闭与Client之间的连接。长连接Client (外围系统)第一次请求Server (UIP)服务时建立到Server (UIP)的连接， Client后续请求Server服务时复用该连接。连接空闲超过指定时间(600秒)Client需要向Server发送心跳报文，以维持该 连接，Server收到心跳报文后向Client返回心跳应答报文。如果连接空闲时间超过(600 秒)，Server将关闭该连接。心跳报文的组织遵照UIP Socket接口规范，心跳命令字见附录。
1权利要求
SOA在外围系统访问核心支撑系统的实现方法，其特征是在外围系统与支撑系统之间设置统一接口平台UIP，UIP包括5个基础组件和5个可独立运行的子系统5个基础组件配置管理、连接管理、安全管理、线程管理、协议适配器；5个子系统接入子系统、JMS消息管理器、接出子系统、监控管理子系统、业务处理子系统，子系统中使用基础组件；通过JMS消息管理器将外围系统接口调用过程划分为接入处理、消息管理、接出处理三个过程的异步处理方式，每个过程只要处理一种协议接入过程实现外围系统和JMS的消息转换和交换，接收/加工外部消息，交给JMS消息管理器，从JMS管理器获取应答消息，返回给外围系统，由接入子系统负责；消息管理JMS消息管理器负责UIP的消息管理，具体包括消息接收、消息存放存放于内存/文件/数据库、消息生命周期管理过期消息将被删除、消息优先级管理、消息队列管理；接出过程实现JMS和核心支撑系统的消息转换和交换，从JMS消息管理器获取/加工消息，访问核心系统功能，加工核心系统返回的消息，交给JMS消息管理器，由接出子系统负责；UIP内部流转的数据是JMS消息，提供基于WebService和Socket协议族的接口规范。
2.根据权利要求1所述的SOA在外围系统访问核心支撑系统的实现方法，其特征是 UIP的异步处理机制通过实现两方面的解耦处理外围系统接入请求1)外围系统接入协议和核心系统接口协议解耦；2)外围系统接入客户端数/请求量和核心系统允许并发数/处理能力解耦。
3.根据权利要求1或2所述的SOA在外围系统访问核心支撑系统的实现方法，其特征 是接入子系统实现HTTP、S0cket协议的Server功能，负责监听外围系统接入请求和接收请 求数据，并将外围系统发给UIP的SOAP消息包、Socket数据包转换成UIP标准消息包；UIP 标准消息包为由XML结构组织的数据包，UIP内流转的消息都采用UIP标准消息包，也就是 JMS消息都采用UIP标准消息包的形式，消息包包括包头和包体两部分包头部分的字段名 和字段数固定不变，包括UIP消息内部管理使用的信息和业务管理使用的基础信息；包体 部分是与具体功能接口相关的字段，不同的功能接口字段数量和字段名称不同，报文体根 据需要灵活定义。
4.根据权利要求1或2所述的SOA在外围系统访问核心支撑系统的实现方法，其特征 是接出子系统实现通用客户端功能，UIP的协议适配器定义消息转换接口和通用客户端接 口，由协议插件实现所述接口，接出子系统通过不同的协议插件实现对不同核心支撑系统 的出访。
5.根据权利要求3所述的SOA在外围系统访问核心支撑系统的实现方法，其特征是接 出子系统实现通用客户端功能，UIP的协议适配器定义消息转换接口和通用客户端接口， 由协议插件实现所述接口，接出子系统通过不同的协议插件实现对不同核心支撑系统的出访。
6.根据权利要求1或2所述的SOA在外围系统访问核心支撑系统的实现方法，其特征 是UIP的监控管理子系统监控/管理接入子系统、JMS消息管理器、接出子系统中的通用线 程池、Socket连接池、JOLT连接池、JMS消息。
7.根据权利要求3所述的SOA在外围系统访问核心支撑系统的实现方法，其特征是 UIP的监控管理子系统监控/管理接入子系统、JMS消息管理器、接出子系统中的通用线程 池、Socket连接池、JOLT连接池、JMS消息。
8.根据权利要求4所述的SOA在外围系统访问核心支撑系统的实现方法，其特征是 UIP的监控管理子系统监控/管理接入子系统、JMS消息管理器、接出子系统中的通用线程 池、Socket连接池、JOLT连接池、JMS消息。
9.根据权利要求5所述的SOA在外围系统访问核心支撑系统的实现方法，其特征是 UIP的监控管理子系统监控/管理接入子系统、JMS消息管理器、接出子系统中的通用线程 池、Socket连接池、JOLT连接池、JMS消息。
10.根据权利要求1或2所述的SOA在外围系统访问核心支撑系统的实现方法，其特征 是使用ActiveMQ进行JMS消息管理。
全文摘要
SOA在外围系统访问核心支撑系统的实现方法，在外围系统与支撑系统之间设置统一接口平台UIP，UIP包括5个基础组件和5个可独立运行的子系统，将外围系统接口调用过程划分为接入处理、消息管理、接出处理三个过程的异步处理方式，每个过程只要处理一种协议。本发明降低了核心功能域对外提供新接口功能的成本，降低支持新接入/接出协议的成本，提高外围系统访为核心系统时的稳定性，降低维护成本，提高对外围系统运营的统计分析功能，从而有效支撑了电信运营商的精细化运营。
文档编号G06Q10/00GK101854348SQ20101014024
公开日2010年10月6日 申请日期2010年4月2日 优先权日2010年4月2日
发明者孙力斌, 张有根, 曹磊, 李华, 李晓东, 杭国民, 梁斌, 王红亮 申请人:南京联创科技集团股份有限公司