2005年9月,农发行综合业务系统顺利上线运行,全系统的业务经营活动实现了数据大集中。同时随着业务经营范围的不断拓展,业务部门对增加科技支撑力度也提出了更高的要求。在新形势下,如何既快速高效、又安全平稳地满足业务部门的需求,是农发行科技部门面临的一个重要课题。笔者认为,在综合业务系统前端,开发部署一个通用的、稳定的、可扩展的通用报文交换平台是适应业务 发展 、满足业务需求变化和规避技术风险的一个有效举措。
通用报文交换平台(universal message exchanging plat)简称umep,是按照标准化的原则,为处理异步报文交换业务而设计的通用平台。在当前数据大集中的环境下,设计通用报文交换平台能有效的解决综合业务系统的通用性和扩展性问题,从而高效安全地满足业务变化的需求。本文将就农发行umep的分析与设计作一阐述。
一、平台的软件基础
umep选用tuxedo作为基础软件平台来进行设计和部署。tuxedo是bea公司的一个商品化的交易中间件软件产品,从软件最初推出至今已经经历了9个版本的升级变迁,广泛应用于 金融 、电信、邮政、航空等领域,是业内 历史 最久、应用最广的中间件产品。
农发行从 电子 联行系统开始,就引入了tuxedo中间件产品,直至在综合业务系统中更为全面地使用。在多年的开发维护工作中,农发行不仅积累了大量的经验,而且还培养了一批技术人才。WWw.133229.coM选用tuxedo作为umep的基础软件平台,做到核心系统相一致,不单单是为了减轻系统维护的工作量,降低系统故障的风险,更重要的是考虑到在其基础上设计出来的umep,可以具备较高的可靠性、通用性、安全性和可扩展性。
二、平台的总体设计
根据报文交换类业务的处理流程,umep在总体的逻辑结构上设计为三层:前置机接口层、通讯平台层和核心服务层。其结构图如下:
外接系统汇入的报文,由前置机通过外接系统提供的接口api(应用程序接口)获取后,发送至umep,再转发至核心服务进行业务处理。行内系统汇出的报文,由核心系统发送至umep,再转发到前置机,通过外接系统接口api发送给外接系统。前置机和umep的通信,以及umep与核心系统的通信,均是以tuxedo服务调用的方式进行的,并且使用tuxedo的事务管理功能,保证报文传送的准确性和唯一性。
三、前置机接口层的设计
在一个外接系统的前置机上,一般都会部署两套接口软件。一套是行内系统的接口软件,功能就是通过外接系统api进行报文的收发工作。另一套就是由外接系统提供的api接口。两者之间是调用与被调用的关系。
为了保证行内接口的通用性,我们把行内接口软件设计为两层结构,一层是稳定的,一层是不稳定的。
稳定的一层称之为umep client,由两个定时启动的守护进程uploadmsg和downloadmsg组成,分别实现报文接收和报文发送的功能。之所以称之为稳定的,是因为这两个守护进程可以在任何外接系统的前置机上使用,并不需要针对不同的外接系统重写代码,体现了行内接口的通用性。
不稳定的一层称之为branch interface api(简称bia),由一组api函数组成,以库文件的方式提供,被umepclient调用。之所以称之为不稳定的,是因为它是对外接系统提供的api接口函数的封装,需要针对不同的外接系统改写代码。bia被设计为10个api函数,分别处理非实时通讯和实时通讯两种情况:
bia不仅封装了外接系统的api函数,还有一个重要的工作就是负责报文格式的转换。不同的外接系统,其报文的描述格式各有不同。为了行内系统能够以同样的方式处理,就需要对报文用统一的格式进行重新描述,转换为行内系统使用的标准报文。同样,行内发出的标准报文也需要由经bia转换后,再发送给外接系统。这种将报文格式转换功能由通信平台实现改为由前置机实现的设计方式,不仅是实现umep通用性的需要,也是为了充分利用前置机的运算功能,减轻通讯平台的运算压力,使其集中资源处理报文转发的功能,提高平台的处理能力。
前置机接口层的系统结构如图:
在前置机端引入bia的设计模式的另一个优点是,可以最大限度地降低总行科技部门的开发工作量。一个新系统的接入,总行不再需要集中开发行内接口软件(全国性系统仍可由总行统一开发),只要由分行按照umep的报文标准和api标准,自行组织开发一套相应的bia,以库文件的方式提供给umep使用,然后就可以通过umep顺利接入核心系统。另外由于bia层的开发工作并不涉及到tuxedo技术,因此对于分行而言,也降低了技术开发的难度。同时,这样的分层设计也为分行特色业务的开展提供了技术上的便利条件。
umep client在部署之前,附带的bia是一个完全由空api函数编译后获得的库文件。部署到前置机以后,只要将这个文件替换为相应外接系统的bia库文件,即可完成系统对接功能。由此可见,umep client在前置机上的安装部署也是相对简单灵活的。此外,由于tuxedo的跨平台性,可以使得我们的umep client不仅可以部署在hpux/aix/sco unix/linux等unix或类unix平台上,而且可以运行在as400或windows平台上。换句话说,无论外接系统前置机采用的是什么样的操作系统平台,我们的umep client都可以正常部署使用。这也从一个侧面体现了umep的通用性。
四、通讯平台层的设计
umep通讯平台层的设计,使用了tuxedo服务程序和tuxedo客户端程序相结合的方式。两个tuxedo服务程序名为uploadmsgsvc和downloadmsgsvc,分别被前置机端umep client的up-loadmsg和downloadmsg进程调用,用于平台的报文接收和发送。两个tuxedo客户端程序名为uploadkernel和download-kernel,是两个定时启动的守护进程,分别负责上传平台报文至核心系统和下载核心系统报文至平台。其系统结构图如下:
在报文的下行过程中,通过平台上定时启动的downloadkernel进程,调用核心系统的相关服务,获取下传报文信息,再根据xml报文格式描述文件,转换为标准报文后写入数据库。平台服务downloadmsgsvc由前置机端的down-loadmsg进程定时调用。每次调用时,该服务从数据库中读取待发送的报文,返回给前置机。
行内标准报文的格式解析和打包是通过xml报文格式描述文件来完成的。不同外接系统所使用的报文集,都会用行内的标准格式重新加以定义,体现为一个xml描述文件。这个xml文件作为bia的一部分,由bia的开发者按照标准编写完成后,提供给umep平台使用。平台启动时,将装载所有外接系统的xml描述文件到共享内存中,供uploadkernel和downloadkernel处理标准报文解析和打包时使用。鉴于xml强大的扩展性和良好的易用性,这样的设计必然使我们的平台具备优秀的报文兼容性,同样也保证了umep的通用性。
五、核心服务层的设计
umep的核心服务层采用了面向服务的设计模式,每一种业务类型的处理都被细化为一个或多个核心服务来完成。每个核心服务只完成某一种特定的功能,服务与服务之间的耦合关系遵循“松散”的原则。这种“松散”的耦合关系,大大的增加了核心服务的可重用性,为业务的变更和扩展带来巨大的灵活性和便利性。
在核心服务的外围,部署了一类管理调度服务,称为txdispatcher。txdis-patcher不仅能够管理报文交换类交易的服务请求,而且可以管理联机实时交易的服务请求,并根据不同类型的交易,按照事先定义好的业务处理流程,调度相应的核心服务处理。
核心服务层的结构示意图如下:
在服务的调用者和核心服务之间引入txdispatcher管理服务层,使得核心业务系统对业务需求的变更或调整,具备快速投产的能力。因为在核心服务具有较高可重用性的基础之上,仅仅通过定制合理的业务处理流程,组合不同的核心服务,就有可能完成新业务功能的开发工作。
六、安全模块的设计
umep中安全模块的设计,仍然采用原有的pki证书模式。因为基于pki证书的安全技术是目前安全级别较高,并且是国家有关安全部门认可的一种加密认证技术。这种技术在业界被广泛使用,也是农发行综合业务系统目前正在使用的安全技术措施之一。
在使用pki证书的安全模式下,umep服务器和外接系统前置机均需要获得由总行ca中心签发的ic卡,作为自己合法身份的唯一标识。报文上行时,前置机使用自己的ic卡私钥对报文进行加密签名,然后上传umep服务器。umep服务器使用该前置机证书中的公钥解密并核验签名,确认报文的合法性。报文下行时,umep服务器使用自己的ic卡私钥,对下传报文加密签名后发送前置机。前置机收到报文后,使用umep服务器的证书公钥进行解密并核验签名,核验通过后再发送给外接系统。umep的安全体系结构如下图所示:
需要强调的是,在umep的设计过程中,通用性是整个平台的核心原则。只有具备了通用性能力的业务平台,才能最大程度的避免因业务变化带来的系统运行风险。
鉴于umep本身建构在基于服务的基础软件平台之上,并且核心服务采用了分布式结构的设计,因此在物理部署上umep能够支持异地多机集群方式部署,具有高度的可靠性和灵活的可扩展性。此外,多层结构的设计思想,也使得umep具备了良好的伸缩性,既可以部署在总行中心,也可以部署在省级分行,如有需要甚至可以部署在二级分行乃至网点。先进的pki证书安全技术,可以有效地阻止非法报文的进入和防范数据在传输过程中被非法篡改,保证了平台系统的安全性。
综上所述,umep是一个基于分布式服务设计的具备通用性、高可靠性、高扩展性、高安全性,并具有良好的伸缩性和跨平台能力的通用报文交换平台。
