基于银保通系统的QoS实现研究(计算机安全)

基于银保通系统的QoS实现研究周磊1，张治元1,2（1.长沙通信职业技术学院计算机信息工程系，长沙410015；2.北京邮电大学信息与通信工程学院，北京100876）摘要：本文重点论述了银保通系统服务质量保证（QoS）的分析与实现。文中首先提出了银保通系统的的服务质量要求，接着对服务质量的安全性、可靠的消息传递、事务等三个方面进行了详细的分析，最后结合实际情况，一一设计出了可行的解决方案。系统建成投产后，本文中服务质量保证的设计很好地解决了银保通系统实际应用中出现的问题，保障了系统的稳定运行。关键词：QoS；安全性；可靠的消息传递；补偿事务中图分类号：TP393.08文献标识码：AResearchonQualityofServiceImplementationbasedonYingbaotongSystemZHOULei1，ZHANGZhi-yuan1,2（1.DepartmentofComputerandInformnationEngineering,ChangshaTelecommunicationsandTechnologyVocationalCollege,Changsha410015；2.SchoolofInformnationandTelecommunicationEngineering,BeijingUniversityofPostsandTelecommunications,Beijing100876）Abstract:ThispaperemphaticallydiscussestheanalysisandimplementationoftheQoSassuranceofYingbaotong.ItputforwardthedemandofYingbaotong'sQoSfirstly,carriesoutdetailedanalysisinthesecurityofQoS、reliablemessagingandtransactions,thendesignsviablesolutionsforeachproblemwithactualsituation.Aftercommissioning,thedesignsofQoSassuranceoperatewell,solverealproblemsintheoperationandensurethesecurityandstabilityofourbancassurancebusiness.KeyWords:QoS；Security；ReliableMessaging；TransactionCompensation1引言银保通系统[1]是为了在银行柜面完成各项与保险相关的业务而建立的交易系统，它实现了保险公司的核心业务系统与银行代理销售平台之间的自动数据交换，提高了保险公司银行代理保险销售业务的自动化程度。作为一个交易通信系统[2],[3],[4],[5]，银保通系统最核心的问题是如何安全、稳定、有效地保证通信服务的质量，这是设计银保通的核心任务。本文将重点讨论银保通系统在银保数据交换过程中，和通信相关的服务质量保证（QoS）问题。分析系统在安全性、可靠的消息传递[6]和事务性这三个方面的服务质量要求，并结合实际生产情况设计出适合银保通系统的服务质量保证解决方案，实现银行保险间交易业务的安全、可靠、一致。2银保通系统服务保证要求银保通系统作为银行、保险两大金融系统间的一个交易通道，基本的服务质量要求集中体现在安全、事务和可靠的消息传递三个方面。2.1安全性要求1）保证银行和保险公司间交互的信息是安全的，不能被泄漏和篡改。2）银行的身份是可以验证的、可信任的。3）不同银行交易内容是不同的，受交易权限控制的。2.2可靠的消息传递要求1）银行发出的一次投保申请消息，能确认保险公司收到，并且只收到一次。不能出现银行发出消息后，消息无法确认，或者同一个投保请求，保险公司接收到多次，进行了多次处理的情况。2）当因网络故障或对方系统出错的情况下，银行方的请求消息可以被保存并且待故障解决后再次提交；同样，保险方的响应消息在网络或对方故障解决后也可以再次响应给银行方。2.3事务要求银保的一笔投保交易，能让代理方银行的扣费、记帐动作和委托方保险公司生成保单的动作在一个事务中完成，要么都成功，要么都失败。不能出现银行扣费成功，而保险公司却没有生成保单的情况。3银保通系统服务保证——安全性的分析与实现3.1安全性分析通常可以在三个级别应用Web服务安全性[7]：1）平台/传输级（点对点）安全性；2）应用程序级（自定义）安全性；3）消息级（端对端）安全性。针对银保通系统，传输级和应用程序级安全可以保证保险和银行间交易的安全性，而且技术上也可以实现。消息级的安全，在互联网开放的环境下，过于沉重和复杂，而且技术上实现难度大，银行自身也没有支持这一级的安全性。故银保通系统，选择实现传输级和应用程序级的安全即可。3.2安全性的实现实现传输级安全，主要是要保证消息物理传输的完整性和机密性，严格控制传输通道和终结点配置。因此，保险和银行间的连接宜采用DDN专线的点对点传输方式。专线直接连接双方的路由器，安全性是基于端到端的信任，服务端只接收特定IP传来的请求消息，非法的IP包将被抛弃，防止消息中途被截获、篡改或者伪造；专线专用，该线路上除了指定业务外不存在其它业务或服务，从而保证了消息传递传输层的安全。实现应用程序级安全[8]，也就是在应用程序中实现自定义的安全功能，考虑对传输的XML消息进行加密。利用DES对称密钥加密算法，发送和接收方掌握同一个密钥，传输消息前，发送方先利用密钥对消息进行加密，再进行传输；接收方收到加密的消息后，用密钥进行解密获得消息明文，再进行后续处理。密钥每天自动更换，然后双方同步更新。图1显示了银保通系统基于传输级安全性和应用程序级安全性的安全模型。图1银保通系统安全模型4银保通系统服务保证——可靠的消息传递的分析与实现4.1可靠的消息传递的分析基于安全性的实现方案，对可靠的消息传递的支持需要进行分层，一层是在传输级添加对可靠性的支持，还有一层是放到应用程序中以软件的支持实现。如果放到传输级，优点是在应用程序中可以使软件专注于商业逻辑；但要求传输级路径上的每一个消息传递代理都支持同一个可靠的消息传递的策略，这不适宜于银保通系统使用的TCP/IP传输网络。因此，把可靠的消息传递放到应用程序中来实现较为适宜。把银行和保险的通信软件设计为支持可靠的消息传递，这种方式不依赖物理层，能够在所有的传输协议上支持可靠的消息传递。4.2银保通实现可靠的消息传递银行和保险核心系统通信属于同步通信，而且使用的TCP/IP传输网络，因此，设计一个简化的可靠的信息传递“协议”来发送请求并且接收来自被请求服务的应答，如图2。请求方的通信支持保存一个请求的副本，直到确信该请求已被响应方接收并且已经持久化。在响应方进行处理并提供所请求的服务应答后，通信支持保存了应答的一个副本，直到确信这个应答已经安全地返回到请求节点。基本通信流程如下：1）银行柜面发出请求；2）银行通信代理储存请求消息，然后再传送给银保通；3）银保通分析请求，然后把请求继续分发给保险核心系统；4）保险核心系统根据请求，进行业务处理；5）处理完返回响应给银保通；6）银保通收到响应，先把响应持久化储存，再把响应传回银行通信代理；7）银行通信代理把响应返回给银行柜面。图2银保间可靠的消息传递银行通信代理有一套超时机制，它发出请求后就等待保险方响应，如果在传递请求过程中请求丢失，银保通系统并不知道有请求丢失，那么银行通信代理程序在等待一定时间后中断连接，并通知柜面，由操作人员选择是否重发消息。如果消息是在保险方处理完毕后，传递响应的过程中丢失，则银行通信代理也会等待超时，这时候它会要求柜面重发请求，这个请求的唯一标识ID不变；当这个请求再次到达银保通系统时，银保通会根据请求ID判断此请求已经被处理过，则不再分发此请求给保险核心系统处理，直接调出持久化的响应，返回给银行方。可靠的消息传递还有一个优点，就是对于一个提供其它应用程序请求响应的服务提供方来说，可以应用事务逻辑来保护服务请求的处理过程，从而提升服务的伸缩性。在图2中的白色框就是银保通系统的事务边界。银行方接收请求并对其进行处理，然后把需要返回的响应持久化存储，所有这些都在一个事务中。因此，银行方在处理请求过程中的任何故障都将导致请求等待处理或者响应等待发出，但是没有存在疑问的状态。此外，服务方完成处理事务后，所有相关资源的锁定将被释放，不存在涉及网络延时的端到端的事务协作。5银保通系统服务保证——事务的分析与实现5.1事务与补偿事务分析Web服务的事务具有以下特性：1）长事务：由于商务逻辑或者用户交互，一个Web服务的事务逻辑可能持续较长的时间，跨越多个系统，这使得锁定资源策略不再适用。2）自治性：Web服务的提供者拥有对Web服务及其资源的控制权，第三方应用一般无法锁定它需要的资源。所谓补偿，就是是指在出现了某些错误或计划有所改变时所采取的补救行动。在长事务流程中，使用补偿，可以抛开全局事务锁机制去尽可能快的提交事务并继续执行主流程，如果之后某一点发生了错误，再去弥补之前完成的事务，这样做可以弥补这个事务的失败所造成的影响。5.2银保通补偿机制的实现银保业务中的委托、代理双方帐务的一致性问题，是银保通系统服务质量保证的最主要问题。在现实中，由于银行和保险双方系统的资源自治性，无法锁定跨企业的资源。同时，由于基础软件架构和中间件的差异，无法传递统一的事务上下文，也没有一个分布式事务管理器或协调器来协调两阶段的提交。除此之外，银保业务流程也是一个长事务流程，整个流程从发起到正常结束至少需要一天的时间。在整个流程完成前，许多单个的任务可能已经完成，如果随后发生的某个事件或错误而导致流程的取消，已经完成的任务需要被复原。这种情况下，无法使用简单的事务处理机制来实现回退，而需要补偿支持来完成这一任务。一笔银保业务，涉及银行方和保险方双方的数据库操作和记帐处理，如图3，（根据会计原理，缴费时一般须银行方先记帐，委托方后记帐）。图3银保正常交易数据库操作图银行和保险分别在各自系统中应用本地事务T1、T2来保证本系统内数据一致。为了保证双方帐务的一致性，不至于出现单边帐，银保业务在两种情况下需要补偿，一种是发生错误时，一种是客户改变计划时。根据需求的自治性，这两种情况分别要求银行和保险方都实现各自的补偿操作。为此，银行方实现了自动冲正，保险方提供了撤销服务。这两个补偿功能由银行的中间业务平台来决定调用，如表1。表1中间业务平台决定调用表银行方处理结果保险方处理结果下一步操作正常正常返回操作成功失败不发往保险方返回操作失败正常失败自动冲正银行方帐务，返回操作失败第一种情况，中间业务平台中，当银行方完成记帐，处理转交给保险方，如果发现保险方发生故障，中间业务平台就调用银行帐务的补偿操作——自动冲正。另外，通信的超时设置必须适当，如果规定时间内保险系统没有返回，也视为其操作失败。图4银保撤销交易操作图第二种情况，对于一笔已成功的交易，双方的系统都已记帐，如果客户改变了主意，要取消或更改交易，这时就需要银行方发起手工撤销交易。银行方先手工冲正自己的帐务数据，再调用保险方提供的撤销服务，完成对保险系统内业务数据和帐务数据的补偿，如图4。除此之外，银保通系统实现的可靠的消息传递，保证了调用补偿服务的成功，不存在银行调用保险补偿服务时，由于通信故障而导致无法对保险数据及帐务进行补偿的情况。通过银行方的自动冲正，和保险方的撤销服务实现了以补偿事务的机制来保证银保通交易的一致性和可靠性。6结束语作为一个交易通信系统，最核心的问题是如何安全、稳定、有效地保证通信服务的质量，这也是设计银保通的核心任务。本文重点论述了银保通系统服务保证的分析与实现。文中先提出了银保通系统的的服务质量要求，接着对服务质量的安全性，可靠的消息传递，事务这三个方面进行了详细的分析，然后结合实际情况，一一设计出了可行的解决方案。