[中间业务系统] 经验分享:银行代理系统发展之路


银行代理系统(中间业务系统)的综合背景、发展历程、未来发展

本人有幸经历了银行业的代理业务产品开发各个阶段,从手工作坊似的低级阶段,到快速图形界面定制的高级阶段。并对多种代理业务平台有实际的使用经历和感受。根据本人在银行开发过程中的使用经验和心得,分析了银行代理业务平台的发展经历,以及平台构建技术,和以后的发展方向,对金融软件开发人员有借鉴作用。

一、银行代理系统综合背景

       银行代理业务经过近10年的发展,正日益成为各家银行增加利润、留住客户的主打形象产品。在此主要从技术上讨论代理业务平台,是如何适应银行代理业务产品发展的需要,从无到有、从简单到完备的发展历程。 

       首先明白一个概念,什么是代理业务?简单的说,就是银行系统利用自身的网点优势和客户资源,为第三方单位如电信、移动等代理收费、扣款等业务。此业务是在90年代中期随着银行系统数据集中、网点互联的发展而发展起来的,既方便了客户、又减少了第三方单位的经营成本,同时提升了银行的形象,也为银行带来了新的利润增长点。 

       对银行系统的软件开发人员来说,代理业务带来了新的技术要求和实施难度。最早出现的代理业务一般是话费代收,要求的功能很简单:话费查询、缴费、对帐等。从安全性和速度方面考虑,银行需要和委托单位建立专用的通讯信道,当时一般是申请电信的64kDDN专线。然后由银行方和委托方商量、确定双方的通讯协议以及报文接口,实际情况是,一个委托单位一般不会只和某一家银行签订这种代理协议,所以如果委托单位已经和其他银行开发了类似的代理系统,那么该委托单位从自身系统的维护和管理方便出发,是不会和其他银行另外开发一套新的通讯协议和报文接口的,后期参与进来的银行就只能使自己的系统适用他们已有的系统的需要了。在当时,对每一家委托单位,银行都要增加新的前置机、路由器等等硬件设备。 

       经过紧张的开发、调试、试运行,到最后成功上线,一个新的代理业务产品的成功推出总会激起新的委托单位的兴趣,从而导致越来越多的代理业务需求。考察那几年的银行信息部门的人员配置,我们会很容易发现一个有趣的现象,那就是所有银行都在那几年中逐步增加了代理业务开发部门的力量,代理业务开发人员得到越来越多的重用。慢慢的,这些软件开发人员积累了越来越多的有关代理业务的开发经验和教训,大家发现代理业务系统做了这么多,其实不同委托单位的系统是存在很多共同点的,开发人员开始感觉自己做了很多重复性劳动,既辛苦,又延长了系统的开发时间,于是大家开始寻找一种软件产品,能够支持任务繁重的代理业务开发的工具软件,结果发现还真有一些很有市场头脑的软件公司在做这个产品。 

       最开始出现的产品还不叫代理业务平台,只相当于一个兼容性较好的通用代理业务系统,是在对所有的代理业务子系统进行了共性分析后,把各子代理业务系统整合成一个大的综合系统,再把该系统分成通讯、业务逻辑控制、主控等几个功能模块,通过参数配置的办法体现出不同代理业务的特色来。相比以前的开发方法,现在能够明显的提高开发进度并保证产品质量。 

二、银行代理系统业务功能

       下面我们就分析一下代理业务平台到底要实现哪些功能。事实上,代理业务平台要完成的功能主要就是通讯、业务逻辑控制、流程控制这三大块,虽然不同时期、不同软件公司的平台产品看起来形形色色,其主要功能却没有超过以上三项功能的范围。 

       其中通讯模块要解决的问题就是所有中间业务都会遇到的与渠道、后台、以及委托方交换信息的问题,一般来说,在某一个银行内部,代理业务平台与渠道、后台通讯,其通讯协议和报文接口协议是比较稳定、统一的,所以通讯模块中针对渠道和后台的子模块一般都是比较清楚、稳定的,所有代理业务都共用这几个相同的通讯模块,同银行系统的核心系统一样,几年之内都不会改变。但与第三方委托单位的通讯协议和报文接口就不一样了,基本上每一种代理业务都对应一种不同的通信协议和接口数据报文。 

       代理业务平台正是要在这不同的通讯协议和接口报文的情况下,为开发人员提供一个比较统一的对外通讯接口,使应用完全与通讯细节隔离,在平台的总控模块中体现出一致的调用接口,从而使业务逻辑控制模块可以完全关注业务方面的细节,使整个系统层次分明、结构稳定,不至于因为通讯方面的协议和报文接口的更改影响业务处理和流程控制。所以现在的代理业务平台一般都内置了常用的通讯协议模块,能够很方便的处理tcp/ip协议、cics协议等各种流行通讯协议,并提供对8583报文协议、字符流报文协议等报文接口协议的支持,当然,针对某些单位自定义的通讯协议和报文接口协议,软件公司也能在代理业务平台上很方便的构造出新的通讯子模块。 

       业务逻辑控制的概念也是在对代理业务平台的功能进行整理分析后提出来的,为了平台的软件结构层次清晰、功能稳定,把所有与业务控制有关的部分从系统中剥离出来,单独形成业务逻辑控制模块。不同的代理业务在平台上要调用不同的业务相关处理函数,要走不同的业务处理流程,访问不同的业务参数控制表,这些都要在业务逻辑控制模块中以参数的形式对不同的业务加以控制。例如查询话费交易,只要走委托方通讯,不要求访问后台,而缴费交易则不但要访问第三方,还要访问后台,特别是有的交易要求先访问第三方,另外的交易有可能要先访问后台再访问第三方,等等与交易有关的控制都放在业务逻辑控制模块中。 

       流程控制模块又可以理解为主控模块,主要完成对一个完整交易的流程控制,它根据业务逻辑控制确定的具体交易的流程,调用相应的通讯函数和业务处理函数,一步一步的完成整个业务流程,在流程某一步出现错误的情况下决定下一步该怎么走,是直接返回错误给前台,还是继续执行?要不要发起冲正?要对哪几个地方发起冲正?等等,它还要负责总个平台的初始化、启动以及停止。流程控制模块在一个平台中也是比较稳定的模块,不会随业务的增加或更改而有什么变化,不同公司、不同时期的平台,在流程控制模块上会有一定的变更,从而形成不同公司的平台特色。 

       从以上平台主要功能模块的分析我们可以看到,所有代理业务平台要实现的功能都是基本相同的,其中通讯模块和业务逻辑控制模块是根据不同的委托方和不同的代理业务而有所变化的,在实现上一般采用参数控制的办法,开发人员使用平台作为开发工具时,将主要针对不同的公司配置不同的通讯模块,然后根据不同的代理业务种类定制不同的业务逻辑控制,从而能够比较快速的实现新代理业务产品的开发和上线。至于流程控制模块,则体现了公司的平台产品的特色,尽管要实现的功能是一样的,但不同公司的平台产品往往体现了不同设计思想,当然也就形成了各公司不同的流程控制方式。 

三、银行代理系统发展历程

       既然所有的平台产品都只是为了以上的三个功能,那么各个时期的代理业务平台到底有什么不同的特点呢?我们知道,最先出来的平台产品,主要任务是减少开发人员的重复工作量,加快开发进度,所以当时的平台产品可以说完全是为这个目的而设计的,既没有考虑平台本身的易用性,也没有考虑一个平台产品兼容多种操作系统的问题。这种平台产品的代表有上海南天公司的“中间业务平台”,当时甚至都没有为此产品取一个名字,就叫“中间业务平台”。这一代产品使用几年之后,出现了新的产品,虽然要实现的功能没有多大变化,但是针对平台本身进行了优化,例如提高了报文接口定制的简便性,很多以前需要手工计算的数据现在尽量交给计算机自己处理,开发人员只要提供不同报文之间的最本质的区别的参数就可以了,另外还考虑了平台的兼容性,不但能够直接在银行常用的UNIX操作系统上使用,而且提供了windows操作系统上的版本。这也是由于各银行单位代理业务快速发展的需要,导致各种各样的平台产品争相出现,代理业务产品开发更加高效高质。这时期的代表产品有神码公司的smartagent,以及宇信鸿泰公司的fisp产品等。 

       这期间,很多平台产品更增加了对代理业务的数据统计、报表打印功能以及参数管理等功能,相当于增加了平台的一个新功能模块:管理模块。那么最新的平台产品又有什么新的特色呢?在维持原有功能和多系统兼容的情况下,有的平台提供了更为简便的开发环境,把总个平台的功能实现、参数定制都移植到了图形界面的windows环境下,开发人员可以在全图形界面下实现原来在unix机器上能实现的功能,这确实是一个很大的进步,虽然平台的本质功能没有什么改变,但这是软件公司对平台的功能有了更本质上的理解之后才实现的产品,对开发人员来说,可以摆脱全手工操作的unix平台,在图形界面上轻松自如的完成新代理业务的增加、修改,把生成的参数自动发布到unix运行机上,真是一种前所未有的感受。这种新平台的实例有北京先进数通公司的eSWITCH产品。另外,为了适应代理业务平台大批量、大并发交易的需要,在最新的平台设计上广泛使用了消息队列机制,实现了代理业务平台在较低系统配置情况下处理大量并发交易的处理能力。 

四、银行代理系统未来发展

      我个人认为,银行的代理业务应用正处于方兴未艾的时期,各软件公司为了争夺市场,一定会继续在代理业务平台的可用、易用、美观等各方面不断加以改进,以后在windows的图形界面下进行交易定制、流程定制、报文接口定制,甚至通讯底层函数的编码等等都是可以预见的,现在在windows环境下定制生成的结果文件基本还要手工干预才能在unix的生产机上运行,以后肯定会要实现完全由windows环境定制、生成、发布所有交易的功能。这实际上相当于给unix开发平台扩展了一个图形界面的外壳,使程序员充分利用了windows操作系统带来的大众化的友好、实用的人机互动界面。

转载自:http://www.bankitman.com/thread-20477-1-1.html

评论列表

暂无评论

需要先登录后才可以进行评论

登录 注册