（计算机软件与理论专业论文）unix环境下银行中间业务系统研究.pdf

摘要 论文以“银行中间业务系统”的研发为背景，简要介绍了中间业务系统的基 本概念及特点，在国内外的发展现状、应用前景、构建中间业务系统的意义和作 者在项目中承担的主要开发任务。 中间业务系统采用了面向对象设计思想，核心处理应用了基于容器的交易调 度技术和基于变量池的数据交换技术，变量池数据以x m l 形式存储以利于扩展和 增强灵活性。中间业务系统采用内存引擎技术，将数据库建在内存中，以提高系 统运行效率。 本文较详细分析了中间业务系统的体系结构和主要特点，提出了一种实现方 式。 关键词：中间业务变量池内存引擎 a b s t r a c t b a s e do nt h ep m j e c t “m i d d l eb u s i n e s ss y s t e mf o rb a n k ”，也i sp a p e rp r o v i d e st h e d e 6 n i t i o n ，c h a m c t e r s ，d e v e l o p m e n t ，a 1 1 dp m m i s i n gm t u r eo fm i d d l eb u s i n e s s t h i s p 印e ra l s od i s c u s s e st h em e 锄i n go fd e v e l 叩i n gh o m e m a d em i d d l eb u s i n e s sa 1 1 dt h e r e s p o n s i b i l i t i e so f m e w r i t e ri nt h i sp r o j e c t m i d d l eb u s i n e s ss y s t e mi so fo b j e c t o e n t e dd e s i 印t r a n s a c t i o nd i s p a t c h e s b a s e do nc o n t a i na n dd a t ae x c h a n g e sb a s e do nv a r p o o lt h a ts t o i sd a t ab yae x t e n d e d w a yi nax m lt r e ea r eu s e di nt h ek c m e lo p e r a t i o no ft h em i d d l eb u s i n e s ss y s t e m s p e e di n f o r m a t i o ns w a p p i n g s e l e c te n g i n e ( s i s e ) t e c h n 0 1 0 9 yi s i n t r o d u c e dt o m i d d l eb u s i n e s ss y s t e m ，w h i c hi m p r o v e st h es y s t e me m c i e n t l yb yb u i l d i n gd a t a b a s ei n m e m o r y i nt h i sp a r a g r a p h ，a na n a l y s i so nt h es t m c t u r eo fm i d d i eb u s i n e s ss y s t e ms h o w s d e t a i l so f c h a r a c t e r i s t i c so f i ta n dw e 百v eaw a yt oa c h i e v em i d d l eb u s i n e s ss y s t e n k e y w o r d s ： m i d d l eb u s i n e s s v a i 。p o o i s i s e 创新- 眭声明 y 8 5 8 9 6 0 本人声明所呈交的论文是我个人在导师指导下进行的研究工作及取得的研究 成果。尽我所知，除了文中特别加以标注和致谢中所罗列的内容以外，论文中不 包含其他人已经发表或撰写过的研究成果；也不包含为获得西安电子科技大学或 其它教育机构的学位或证书而使用过的材料。与我一同工作的同志对本研究所做 的任何贡献均已在论文中做了明确的说明并表示了谢意。 申请学位论文与资料若有不实之处，本人承担切相关责任。 本人签名：益塾日期塑! ! ：堑 关于论文使用授权的说明 本人完全了解西安电子科技大学有关保留和使用学位论文的规定，即：研究 生在校攻读学位期间论文工作的知识产权单位属西安电子科技大学。本人保证毕 业离校后，发表论文或使用论文工作成果时署名单位仍然为西安电子科技大学。 学校有权保留送交论文的复印件，允许查阅和借阅论文：学校可以公布论文的全 部或部分内容，可以允许采用影印、缩印或其它复制手段保存论文。( 保密的论文 在解密后遵守此规定) 本学位论文属于保密在一年解密后适用本授权书。 本人签名： 导师签名： 节办 让 日期趋：主：墨 日期益磁。羔：互f 第一章绪论 第一章绪论 1 1 银行中间业务系统 本论文来源于交通银行总行“中间业务系统”的设计和开发。该项目主要面 向国内的银行系统主要针对交通银行的特点，拓展了银行业务，使得交通银行除 了传统的储蓄贷款业务外，还能够提供中间业务的增值服务。 1 - 1 1 银行中间业务系统定义 中间业务是指不构成商业银行表内资产、表内负债，形成银行非利息收入的 业务。因此，中间业务的范围相当广泛， 行为了把握新的利润增长点，吸引客户、 行业务发展的重心。 在银行核心系统相对稳定的情况下，银 稳定客户，发展中间业务将成为目前银 1 1 2 银行中间业务系统特点 银行的核心业务是针对个人客户的存款、取款等金融支付业务，这些业务都 是按照银行业务规范开展的。而银行在开展中间业务的服务的时候，除了为客户 提供方便的金融支付手段以外，还必须考虑为每种不同的业务提供符合该业务需 要的数据、凭证等详细内容，这些中间业务的详细内容可以说是干差万别，主要 体现在以下三个方面：首先是业务数据的差别，不同的应用当然会具有不同类型 的数据结构；其次在于交易界面的差别，不同的应用的系统调用界面必然会有不 同的内容；第三点是记账凭证的差别，不同的应用打印的交易凭证不论内容还是 格式都会有很大的差别。 为了开展这些中间业务，银行不得不在现有系统中进行添加，每开发一个新 业务就需要在现有的系统中增加一部分对应的处理程序，这样会造成多方面的问 题。 主机系统数据增加，加重数据库的负载。每种业务一般来说需要记录大量 的与银行核心业务数据无关的特定商业应用的数据，这会增大主机数据库的负载， 降低业务处理的效率： 商业应用不稳定，有可能对已经开办的业务造成影响。由于需要为每种业 务添加相应的处理，这样会影响目前已经投入运行的交易系统，有可能形成增加 一种业务，反而把正常运行的其它应用影响了，这对于一个覆盖的地域、业务种 2 u n 环境下银行中间业务系统研究 类、客户群体都极其庞大的综合业务系统来说是非常危险的； 应用开发周期长，无法及时响应业务需求。每种商业应用都需要开发该应 用的全部功能，这样会造成开发周期过长，无法及时完成的问题。 重复开发量大。中间业务之间还是具有许多共通之处，每次都进行开发会 造成大量的不必要的重复。 1 1 3 与国外银行中间业务系统的差距 虽然国内商业银行在中间业务上有了长足的进步，但与国外商业银行相比， 仍然存在着较大的差距。 在经营范围和品种上国外银行普遍采用混业经营，产品种类繁多、服务更新 迅速；而国内商业银行受限于相关的政策只能采用分业经营，集中于筹资功能较 强、日常操作简单的结算类、代理类业务。 在业务规模和收入水平上，国外银行非利差收入占总收入的5 0 - 8 0 之间；而 国内银行非利差收入占总收入的6 7 9 6 之间。 在服务手段上国外银行科技化程度高，支付网络非常发达；国内银行服务手 段落后，缺乏高效、快捷的支付系统，完善的支持系统。 1 2 论文主要工作 由于中间业务的特点决定了这类业务存在很大的差别，包括数据差别、流程 差别、系统调用界面凭证差别。目前银行在自助渠道建设上也有了长足的进步， 多种自助渠道已经可以进行核心业务交易，也有部分中间业务在部分渠道上开通， 但是往往都需要中间业务系统和渠道系统进行改造，这样对渠道业务的开展非常 不利。 本论文所做的工作就是设计实现银行中间业务系统，使之具有高度的扩展性 和兼容性，对业务进行统一部署、统一处理，满足大部分的银行业务需求，对于 业务中的特别处理通过快速编写客户化方法来处理，不影响整个中间业务系统的 处理流程。对不同渠道交易提供统一的服务，各种渠道的差异报文通过统一接口 接入中间业务系统处理。 1 3 论文组织 本文的章节安排如下：第一章绪论，介绍开发银行中间业务系统的背景，对 中间业务系统进行简要介绍。第二章为银行交易网络的概述，介绍了银行的网络 构成，银行网络中各部分系统的功能和作用，交易流程和中间业务系统在银行网 第一章绪论 络系统中的位置和主要职能。第三章为银行中间业务系统设计，描述了银行中间 业务系统的设计原则，包括通用性设计和数据一致性设计等。还描绘了中间业务 系统的总体架构、数据库设计和数据的输入输出方式。第四章为银行中间业务系 统的实现，介绍了核心系统的详细设计和实现、w i n d o w s 平台下的配置管理工具以 及交易过程中的出错处理机制。最后是对本文的概括和总结。 第二章银行交易网络概述 第二章银行交易网络概述 2 1 银行网络结构 目前，各商业银行的计算机交易系统建设已经达到相当完善的水平，辖内帐 务数据已经达到一定程度的集中。已经开通的服务渠道也相当完备，其中包括银 行网点、自助银行、a t m 、p o s 、c a l lc e n t e r 、网上银行、手机银行等等，并且还 在不断开发新的营销渠道。在金融服务产品方面，除了传统的存贷款、现金业务 和卡业务外，还为客户提供了包括银证转账、存折炒股、外汇买卖以及各种代收 代付业务在内的多种中间业务，金融服务渠道和产品的种类相当齐全，商业银行 一般性的计算机业务处理系统结构可以参见下图： 图2 ，l 银行网络系统 2 2 现有银行网络的不足 在提供先进的服务渠道和完善的服务产品的同时，现有的商业银行计算机处 理系统也存在着一定的不足，具体表现在： ( 1 ) 仓储式软件结构的局限性 在银行确立了核心帐务系统的地位后，前置机模式成为解决新业务或者新产 品的流行方式( 或主要方式) ，所谓前置机模式是指相对于核心帐务系统的主机而 言，即在进入到核心帐务系统处理之前，在另外一台机器( 可能是逻辑上的) 先 进行一定的预处理。 u n 环境下银行中间业务系统研究 前置机方式对于快速解决一些暂时性的问题有很好的效果和作用，但受限于 银行目前所普遍采用的仓储式软件结构，这种解决问题的方法会不断加深系统的 复杂性，用的越多结果就越糟糕。究其原因在于银行的各个系统之间采用直接连 接的紧耦合方式，一套系统紧紧依存与另外一套系统，应用系统上的越多或者说 实现的越多，各个系统之间的关系也就越难理清楚。 很多商业银行在实现一定区域内的数据集中时深深体会到这一点，真正耗费 时间的并不是实现一套全集中式的核心帐务系统，而是在于理顺各种外围业务处 理系统以及各种服务渠道，这种由系统之间紧密耦合而衍生出来的牵一发而动全 身的联动关系，最终将极大的限制银行现有系统的升级和扩充能力。 ( 2 ) 开发新产品的困难性 目前，以代理业务为主的中间业务正处于一个发展高潮，各家银行都看重这 个市场，纷纷推出了自己的中间业务处理系统，虽然如此，但各间银行在推出自 己的中间业务系统的过程中仍然感受到很多问题，具体以实现一种联机代理业务 所必须具备的三个过程来说： 确定系统调用界面，根据中间业务处理系统的不同，需要编写相应的程序 或者是进行配置处理。 编写与第三方的接口，实现与第三方的连接，在很多情况下，这意味着重 新编写一段程序甚至于新增一台前置机。 为了适应第三方系统的一些特殊性，需要对中间业务的服务处理程序进行 一定的修改。 以上三个过程是基于采用一个比较好的中间业务系统时所需要进行的处理， 更糟糕的情况下，甚至可能涉及到更多的改动或者是重新编写整个系统。 营销渠道能力不强 营销渠道的建设对于商业银行争夺零售客户有着至关重要的意义，因此各商 业银行不遗余力的扩展营销网点，拓展新的营销渠道。然而营销渠道的建设不仅 仅在于不断新增，更应该考虑不断开发已有营销渠道的能力，使之发挥最大的作 用。 从技术的角度上看，p o s 、c a l l c e m e r 、网上银行、手机银行等自助服务渠道 除了在办理现金业务上与银行网点、a t m 有一定的差别外，其余所有的银行转账 类业务应该都可以在这些渠道上进行办理。而现实的状况是，已经在上述营销渠 道上实现的银行产品和服务远远没有达到其本身的技术饱和能力，亟待于进一步 的深入开发。 由于自助设备的输入能力受到限制( 只能输入数字) ，当一笔业务需要输入除 数字外的其他信息时，就无法办理该项业务；另外，当客户在自助设备上办理业 务时需要输入的信息过多也是影响银行自助设备使用率的重要原因。中间业务由 第二章银行交易网络概述 于业务本身往往是基于第三方单位的，因此这种限制在中间业务产品上表现的尤 为突出。 ( 3 ) 繁复的服务模式 银行外延业务并没有一个标准的实现方式，同时业务自身的发展也是一种渐 进的过程，业务规范化程度与银行的传统的核心帐务系统无法相提并论，业务制 度往往也并不成熟，在具体实施时采用的又是步进式的处理方式，不象银行核心 业务的大集中f 2 】系统，将所有的核心帐务系统一次考虑到位并集中组织开发实施， 因此在实现时往往采用小而全的处理方式，即在一套系统中完成从业务处理到客 户信息、客户签约信息的全部处理，这种处理方式在客观上具有产品推出速度快 的效果，但发展到一定阶段，尤其当外围系统的数量越来越多时，其负面作用也 越来越明显，出现了大量的低水平的重复劳动。 由于客户资料这种关键信息却分散在各个业务系统的前置处理机上，各前置 业务处理系统之间的客户资料连一致性都难以保障更遑论数据共享了。此外，客 户为了享受银行不断推出的新产品和服务，不得不一次又一次的携带本人有效证 件到银行网点办理相关业务的签约手续，这对客户而言是一种极大的不方便对 银行而言，也意味着一种浪费，操作员不得不一次又一次的输入重复的信息，并 且每次输入数据的一致性很难得到有效保障。因此也就无法体现出以客户为中心 的服务模式。 ( 4 ) 难以管理 鉴于交易信息采集的困难性，直接导致银行管理人员无法从现有系统中得到 有效的统计数据和分析结果，无法知道通过银行网上银行系统缴纳电话费的客户 还在网上银行进行了那些交易，购买了银行提供的哪些产品。也无法准确知道银 行提供的销售渠道中哪一种最受欢迎、有无效益。也无法知道已知交易渠道上最 受欢迎的是哪些业务，因而管理人员也无法有效的总结工作，有针对性的开发新 业务和有效的客户群体，只能根据经验和感觉进行估计。 ( 5 ) 数据资源利用律低 在银行业，业务数据如果得不到开发利用就会形成浪费。银行业务数据量的 膨胀与数据资源的聚合为开发提供了基础，庞大的数据资源是银行不可多得的财 富。但是现有银行业务数据根本无法统一集中，更谈不上统计、分析、挖掘。 2 3 银行业务系统发展要求 综上所述银行现有系统的不足，使得银行对未来业务系统提出了更高的要求， 同时对现有系统也将采取逐步移植、逐步淘汰的方式处理。为了符合银行业务的 发展趋势，银行业务系统也需要具备如下要求： u n 环境下银行中问业务系统研究 ( 1 ) 规范性： 规范性包括业务规范、开发规范、术语规范和数据规范等几个方面。 开发规范：应用系统的开发要符合软件设计开发的标准和规范，在开发过程 中应当尽量符合相关国家标准，在没有可依据的国家标准的情况下，应采用事实 标准或主流的技术。 术语规范：在应用系统中使用到的行业术语等应符合国家标准或行业标准。 数据规范：数据的采集、存储、传输和访问应按统一规范进行。 业务规范：通过应用系统的开发，应当规范生产业务和日常管理行为，为应 用系统的应用推广创造条件。 ( 2 ) 成熟稳定性： 成熟性与高度的系统稳定性是产品应该而且必须具备的，成熟的产品才能更 加稳定，也只有系统的稳定性得到足够的保障以后，服务、生产、管理才能得到 保障。 ( 3 1 易用性： 软件用户界面设计应从生产人员的实际操作角度考虑，用户界面简洁直观， 风格规范统一，易于用户掌握，便于进行业务处理和日常维护。提供方便的软件 配置、管理和分发手段。 ( 4 ) 开放性： 遵循工业化标准，并具有开放式体系结构，支持符合标准的软件和硬件。应 用软件在结构设计中应必须具有充分的开放性，提供标准接口与外部系统相连。 能够和不同的主机进行数据交换，能够对不同格式的报文进行识别和转换。 ( 5 ) 易扩展性： 系统良好的可扩展性便于系统在不同运行环境、不同业务处理等情况下的按 需配置和移植，方便新应用、新功能的加入。应用软件尽量做到与平台无关。软 件结构应具备扩展能力，在设计中充分考虑未来业务功能的扩展。 ( 6 ) 安全可靠性： 采用高效、可靠的措施保证交易处理的正确性和一致性是对产品的基本要求， 保证数据记录在各数据表中的正确性和一致性。数据信息在系统中的采集、存储、 传输和处理应当保持完整和一致。 ( 7 ) 充分利用资源： 应用系统应当优化，降低对资源的要求，以尽可能地利用现有的设备及有限 的系统资源实现更多的业务功能。 ( 8 ) 高效性： 一般来说为了保证银行业务的顺利进行，都要求信息流的处理必须满足相应 的处理要求。具体来说，计算机处理过程必须达到业务处理规范所规定的时间要 第二章银行交易网络概述 9 求。这些都要求应用软件系统具有高效的处理能力。 ( 9 ) 模块化： 模块化的设计具有良好的可维护性和可扩充性。应用平台软件设计要求层次 化、模块化，做到层次清晰，模块合理，对其中的模块可灵活抽取替换，模块与 模块之间关系明确。 ( 1 0 ) 可维护性： 良好的可维护性也是产品发展的一个重要组成部分。当业务更新和升级时， 系统维护人员的更新环节和更新工作量要尽量少，系统出错时要有明确的错误提 示和详尽的错误日志文件，以供维护人员参考。当系统的部分业务模块进行更新 对，或部分业务模块出现问题，不能影响到其他模块的正常工作。 ( 1 1 ) 二次开发： 任何一个系统都不可能做到一层不变，系统二次开发的能力也是考核产品的 一个方面。二次开发要求可视化，参数化配置程度要高，尽量减少代码级开发工 作量。 ( 1 2 1 灵活性： 系统必须具备灵活性。系统业务流程的设计要灵活，满足业务流程创新的需 要，减少重复和交叉，以提高工作效率。系统应采用平台化建设方式，做到业务 管理、定制与系统监控、维护的相对分离。 ( 1 3 ) 前瞻性： 系统既要充分考虑未来业务的发展和管理的交化，方便新业务和新需求的扩 展和支持；又要充分考虑软件体系结构之间的衔接，满足未来银行金融业务发展 的需要。 2 4 银行中间业务系统 2 4 1 中间业务系统网络结构 中间业务系统处于渠道( 各种银行终端和银行柜面) 和银行帐务主机、企业 之间，紧密将以上三者联系起来，完成相应的银行业务。举例来说，中间业务系 统接收来自渠道的报文进行相应处理，其间与银行帐务主机和企业进行交互，比 如从银行帐务主机检验帐户有效性和进行扣帐，在企业记录帐户的缴费情况。其 逻辑示意图如下； u n 环境下银行中间业务系统研究 l i 锻打帐舔生艇 ii 企业 i ； 享 中瞄啦务装统 弓 豢递( 网上搬扦、电话搬恬、手机戳行，a t m ，p o s 蒋， 图2 2 中间业务系统应用逻辑图 中间业务系统既要适应银行业务的不断扩大，又要具有良好的扩充性，使得 银行的中间业务系统的网络结构在相当长的一段时间内不发生改变或较少发生改 变，因此中间业务系统的网络结构设计如下： 图2 3 中间业务系统网络结构图 中间业务系统由如下几部分组成：中间业务核心处理系统、网点控管系统、 网点管理系统、中间业务管理系统、中间业务监控系统。中间业务服务系统对于 渠道接入和企业接出部分仍然属于中间业务处理模块，通过配置的方式来完成报 文转换，通过编写通讯插件来完成数据交换。监控系统能够对中间业务交易按照 第二章银行交易网络概述 配置进行监控。 整个中间业务系统支持由各个渠道发起的交易，包括由第三方企业发起的。 为了使中间业务核心处理稳定可靠，不涉及过多的通讯协议、报文转换，因 此在与渠道、企业、主机通讯时都加载了接入平台。接入平台的功能就是屏蔽通 讯、报文的差异，使中间业务系统的处理保持一致。 其中由各个渠道发起的交易，可以通过接入平台进行报文转换，然后再到中 间业务系统处理，如果报文满足中间业务的要求( 目前中间业务系统默认是x m “5 1 报文) ，也可以不通过接入平台，直接与中间业务核心处理连接。 到银行主机进行记帐的交易，因为银行主机的接口相对稳定，因此，也可以 不使用接入平台，而由中间业务自身进行处理。 2 4 2 中间业务系统功能 中间业务系统功能除了应该满足现有以代收代付业务为主的中间业务需求， 还应该考虑更多不同形式的中间业务需求，因此，对中间业务系统的扩展性要求 很高。具体功能需求如下： 1 单笔的、批量的交易处理功能。 2 联机的、本地的交易处理功能。 3 用户界面、凭证定制功能。 4 业务配鼍功能，某些特殊业务可以方便使用客户化开发完成业务配置。 5 中间业务系统管理功能，包括报表、数据备份、数据清理等。 6 客户签约功能，可以帮助客户完成代缴费。 7 。中间业务中容易变化的几个环节尽量使用配置完成，包括交易输入接口、 企业数据交换接口、交易输出接口、凭证数据等等。 8 特殊业务处理能够方便的进行二次开发。 第三章银行中间业务系统设计 第三章银行中间业务系统设计 3 1 银行中间业务系统设计原则 中间业务系统的设计采用当今较先进的技术和方法，既反映当今水平，又具 有发展潜力。能保证整个系统的质量和安全，维护方便，经济合理。在蹩个系统 的设计中除了遵循统一的应用软件结构外，还重点体现了以下设计原则： 安全性原则：必须符合国家的安全标准和要求，以保护内部信息不被非法访 问；重要系统配有冗余，有良好的故障恢复能力。严格控制对数据和程序的访问 和修改。对网问传输重要数据加密并进行网络连接的身份验证。 适应性原则：系统自成体系，兼容性强，采用通用的应用协议，可接入多种 系统平台，充分考虑了金融部门和委托行业各种不同的运行环境。 可扩展原则：系统采用先进的技术，保证具有良好的功能扩充性。采用模块 化编程、参数化定义、交易事务化，提高系统的可操作性，维护方便。 易管理原则：系统提供了方便可行的管理措施和工具，使委托方和代理方的 工作更轻松。通过一套完整的前置机系统集中负责各种终端连接，更新该系统可 以管理、监控不同类型的终端及业务种类。 高效率原则：系统确保客户化工作的高效率，对原有系统的影响降到最低。 交易实时性高，在数据表使用，处理逻辑设计方面，保证中间业务的交易处理性 能，不能成为银行应用系统的瓶颈。 经济性原则：充分利用现有资源，兼顾未来业务发展的需要，尽可能降低造 价。 易用性原则：第三代以后的中间业务系统将越来越注重采用配置的方式来实 现应用，因此需要配置和可以配置的内容将越来越多，在这种情况下，易用性就 显得非常突出。中间业务系统的配置工具一律采用w i n d a w s 平台进行实现，整个 配置过程非常强调业务化，并且加入了方便的维护管理功能( 如配置版本管理) ， 强调以人为本，力图最大程度的表现系统人性化的一面。 3 2 银行中间业务系统结构 4 u n 环境下银行中间业务系统研究 银行中间业务系统逻辑上分为四层，从低层到高层依次是资源层、方法层、 原予层和应用层，层次结构见图3 1 。 图3 1 中间业务系统层次结构图 3 2 1 资源层 资源层存放了中间业务系统所需的所以数据资料，包括数据库数据、共享内 存数据和变量池数据。 数据库数据；具体存在于数据库表中的数据，数据库存在于存储器中，相对 来说对数据库的操作效率较差，所以多少情况下避免或减少对数据库的操作，代 之以从共享内存口】中提取数据，当在共享内存提取不到所要的数据是再从数据库中 提取，可有效降低对数据库的频繁访问，提高数据存取效率。 共享内存数据：为降低对数据库的访问频率，提高数据存取效率，在内存中 划分出一块独立空间，将数据库中频繁使用的表装入共享内存，当需要对数据库 中的表进行操作时，先从共享内存中提取，提取不到时再从数据库中提取，当对 于数据库表中的数据进行更新时，其实也是先更新共享内存中的数据，然后在必 要的时间更新到真正数据库中去。共享内存对用户透明，用户会认为是在对数据 库进行操作。 第三章银行中间业务系统设计 对于共享内存的操作使用了内存引擎技术，内存引擎的全称是：s d e e d 1 1 1 f o 肌a t i o ns w a p p i n g s e l e c te n g i n e ( s 1 s e ) 。主要的内容是通过特定算法组织用户 数据，满足应用系统对数据快速查找和交换的需要。 系统从数据库中提取出的一些常用的配置表，通过内存引擎对共享内存中的 数据进行操作，在需要用到数据时直接从内存引擎中提取。为了预防在交易过程 中，由于其他原因导致内存引擎d o w n 掉，系统也提供了相映的参数：旺直接 从内存引擎提取，1 一直接从数据库提取，2 一先从内存引擎提取，如果失败就从 数据库提取。 变量池数据：中间业务系统的变量池( m p 0 0 1 ) ，可以理解为在内存中划分的 一块空间，用以各种数据的交换，他是中间业务系统的数据载体。变量池的组织 结构就是一棵x m l 树形结构。其作用就是：接收数据、存放数据、交换数据和输 出数据。存储数据包括：核心记载数据、核心交换数据、临时交换数据、客户特 有数据。变量池的组织结构如下图： u n 环境下银行中间业务系统研究 图3 2 变量池组织结构 从图3 2 中，我们可以看出，中间业务系统变量池是一棵层次非常清晰的x m l 树形结构。在根结点下，可以按数据的用途分为：核心交换数据、核心记载数据、 第三章银行中阀业务系统设计 1 7 临时交换数据、客户特有数据。 核心交换数据：用于中间业务系统自身需要的临时交换数据。变量名规则： k + 变量名。 核心记载数据：用于中间业务记录流水时的数据。变量名规则：k r 变量名。 临时交换数据：用于中间业务处理时产生的临时数据交换。变量名规则：变 量名。 客户特有数据：用于中间业务第三方返回的特有数据。变量名规则：变量名。 kt r l i s t ：交易流水结点。该结点下存储了每一次交易的流水信息，其存储结 构和数据库中的表t t r l i s t 结构类似。任意一次交易过程中，k t r “s t 结点下的子 结点并不是全部都出现。这是因为任何一次交易有自己的特点，他可能是查询交 易，也可能是记帐交易，或者是管理交易，但不是任意都需要存放所有的流水信 息；该结点只允许存储一条流水信息。 kq u e r y l i s t ：查询流水返回的结果。他的结构和k 皿l i s t 结构完全一致。 该结点经常用于查询流水或是抹帐交易返回的信息。在这些交易中，系统将 查询的流水放入kq u e r y l i s t ，如果本交易需要记录流水信息，则将真正需要记录 的流水信息放入kt r l i s t 中。同kt r l i s t 结点一样，该结点只存放从数据库中查 询到的有值的结点：该结点只允许存放一条流水信息，如果是查询的多条流水信 息，则返回文件；查询到流水信息后，需要将部分信息同步到k j y l i s t 结点中。 kr e t c o d e ：响应码结点。其值为核心响应码或主机响应码或企业响应码或 渠道返回响应码。 中间业务系统的响应码和响应码说明组成了整个交易过程的正确或错误信 息，中间业务系统按响应码的类型可分为：核心响应码、主机响应码、企业响应 码以及渠道返回响应码四个类型。 核心响应码：指中间业务系统自身在处理中的一些信息的代码定义。 其命名规则是k “位响应码。例如：k0 0 0 0 ； 主机响应码：指银行主机返回给系统的代码。由于不同的银行有不同的响应 码，这就需要在管理工具中配置银行的响应码。 其命名规则是h + 主机响应码。例如：h0 0 0 1 ； 企业响应码：指第三方企业返回给中间业务系统的代码。由于不同的企业有 不同的响应码，这就需要在管理工具中配置联网企业的响应码。 其命名规则是b + 业务类型+ 企业响应码。例如；ec d0 0 0 1 。 企业响应码只有联网的第三方企业才有。 渠道返回响应码：指中间业务系统返回给渠道的响应码。对于一种特定的渠 道可能要求中间业务系统返回的信息不是响应码说明，雨只能是响应码。例如电 话银行渠道，对他来说，如果返回的信息是响应码，他无法解析，那么我们就应 u n d ( 环境下银行中间业务系统研究 该把中间业务系统的响应码按照渠道要求返回的响应码进行对照转换处理后返 回。同样，该响应码也需要在管理工具中配置。 中间业务系统还提供了一个系统默认的响应码：s s s s s s 。主要用于如果核心 响应码或主机响应码或企业响应码没有与渠道需要的响应码相对应，则应该设置 为默认的响应码：s s s s s s ， kp r i v a t e ：客户特有数据结点。该结点下存放了客户的一些特有信息。 kd e t a i l ：客户明细结点。该结点存放客户的明细。 kp r i v a i e 和kd e t a i l 通常用于联机查询交易，从第三方企业获取客户的信息 后，客户的明细信息( 例如：每月的欠费信息1 存放到kd e t a i l 结点，而其他的信息 ( 例如：客户名称，客户地址等) 存放到kp r i v a t e 结点下。 从图3 2 中可以看出，kd e t a i l 是kp v a t e 结点的子结点，他是和客户的特 有信息在同一层次。客户的明细信息可能不止一条记录，若是多条记录，则每一 条记录就是一个kd e t a i l ，有几条记录就有几个kd e t a i l 。 说明：如前所述，kt r l i s t 和kq u e r y l i s t 只是数据库流水表( t t r “s t ) 中的一 部分，如果加上kp 巾a t e 就是一条完整的流水信息了。在流水表( t t r l i s t ) 中我们 设定了4 个2 2 5 长度v a r c h a r 字段用于存放客户信息，如果还是不能存放，那么剩 余的信息将存放到扩展流水表( t e x t l i s t ) 中，同时应该将流水表( t n “s t ) 中的扩展 标志( f se x t f l a 曲字段的值置为1 ，以标明该条流水还有扩展流水；在扩展流水表 ( t e x t l i s t ) 中我们设定了7 个2 2 5 长度v a r c h 盯字段用于存放流水信息，那么若是一 条记录还是不能完全存放流水信息，则将存放至4 下一条记录，并将次记录的扩展 存储号( ne x t s e q ) 字段增加1 ，以标明该条记录是接着上一条记录的。 3 2 2 方法层 方法层包括所有对报文进行的操作方法，向下调用资源层获取相应的数据进 行操作，向上对原子层提供服务。所有报文和交易的处理必须通过方法层中的方 法进行操作，方法层中的方法都是以类的成员函数来实现的，具有良好的扩充性 和较强的二次开发能力。 3 2 3 原子层 原子层逻辑上位于方法层的上次，向下调用方法层的方法对交易报文进行处 理。原子层是按照业务需求按照交易类型和处理方式分类将业务的处理划分成若 干模块，每一个模块对应一类相对独立的操作集。每一个模块称为一个原予，每 一个原子实现中对应一个类的实现，类中的成员函数对于方法层中的一类方法， 第三章银行中间业务系统设计 1 9 对于方法层中方法的调用，就是对于原子层中原子的成员函数的调用。原子由容 器类对它的生成删除进行管理。 3 2 4 应用层 应用层即业务系统中的业务处理过程，它是由原子和方法构成的，多个原子 的多个方法按序排列便构成了业务的处理流程。应用层可以按照功能分为中间业 务核心服务和中间业务辅助服务。中间业务核心服务主要是业务的主要流程进行 控制的服务，中间业务辅助服务主要对应于一下服务性质的原子，比如说通信类、 报文转换类等。 3 3 核心业务流程设计 3 3 1 核心处理架构 中间业务核心处理是采用的交易流程定制、执行的处理模式，即对于任意业 务，在中间业务系统中都可以拆分成多个处理模块，也就是我们所说的原子方法， 然后在容器的调度下依次完成各原子方法的处理，最终完成整个业务的处理，这 其中各原子方法的数据交换都将由变量池来完成。 中间业务的交易流程( p r o c e s s ) ，也即我们通常所说的交易序列是由若干原子方 法组成，这些原子方法按先后的顺序排列，故而交易序列的执行也是按先后顺序。 需要指出的是：在图3 3 中，左手边有一个模块：核心调度模块，他是一种特殊的 原子方法，被称为原子方法0 ，该模块主要功能是通过编写系统内定的种类c 的脚本，可放在任意一个原子方法的前后，完成一定的处理数据的功能。 u 1 q 环境下银行中间业务系统研究 交易序7 4 l 一原予方法1 卜 。、_ 核心调度 多 u 原平方法2 卜 、一 横块( 容 冬 原千方法3 法i oj l变量池( 数据 器、脚奉) 交换区) p ，一 h 原原千方法4p n 原千方法。卜 ， 图3 3 中间业务系统核心处理架构 中间业务的原予方法( a t o mm e t h o d ) ，其定义为根据中间业务的业务特性和实 现原则划分的最小单元模块。从技术的角度讲，一个原予方法就是某一个类f c l a s s ) 的一个公有成员方法( p u b l i cm e t h o d ) ；目前中间业务有很多的原子方法，通过一定 的配置就能完成中间业务绝大部分的交易流程，当然，也有个别的交易流程比分 特殊，我们也提供了客户化类( c c u s f u n c ) ，用户可以在次类中编写自定义的原子方 法，以满足不同的需求；中间业务系统对现有的原子方法又进行了细化合并，也 就是说对某个交易流程系统提供了原子方法l ，原子方法2 ，原子方法3 等几种方 法，可供用户选择执行交易的流程，同时也提供了原子方法4 ，按一定的标准顺序 包含了前面3 种方法，此时就可以直接使用方法4 完成一个标准的交易流程。 3 3 2 核心交易流程 由于目前不同的银行使用不同的交易中间件，比较常见的中间件有：c i c s 【1 】， t u x e d 0 ，t c i n g 等，这就带来了不同中间件之间的差异，为此我们也针对不同 的中间件编写不同的主函数，自身的核心处理不变，其大体的处理流程如图3 4 ： 第三章银行中间业务系统设计 接收渠道报文 p 核心处理 p 发送渠道报文 图3 4 核心交易流程 3 4 数据结构设计 从业务逻辑上来分，中间业务系统的数据表结构主要可以进行如下分类：配 置类( 包括中间业务系统基础配置和业务配置) 、交易类( 包括正常交易流水和错误 交易冲正) 、管理类( 包括管理工具操作员、权限管理) 。 整个系统的设计目据是开发新业务以配置为主、开发为辅，因此，配置类表 在中间业务系统中占绝大多数。包括中间业务系统的各种状态、交易的配置、业 务的配置、报文转换的配置等等。虽然配置表较多，但是它们之间的关联清晰、 功能又彼此独立。特别是对某些扩展性要求较高的配置数据，例如交易序列、报 文转换等等，可能会随着中间业务系统的不断发展，添加越来越多的功能配置， 我们尽量采用可扩展的数据结构设计，使得将来因为需求的增加而导致的功能增 加时数据结构保持不变。 交易类的数据表中以流水表最为特殊，因为要支持各种中问业务的数据存储， 因此其兼容性、扩展性要求极高。因此数据结构也是按照这种原则设计的，可以 支持任何业务的数据储存，而且访问方便，同时与变量池配合协调。 管理类的数据表主要是工具需要的一些管理性的配置 3 5 出错处理 中间业务系统的错误主要有以下内容：预处理错、序列处理错、返回处理错。 预处理错主要是在交易预处理时发生错误，包括连接共享内存错：提取配置 错、报文解析错、交易检查错。 u n 环境下银行中间业务系统研究 序列处理错主要是交易序列中的方法在处理时出现错误。 返回处理错主要是交易序列执行完毕，生成返回交易信息时发生错误。 就中间业务系统对错误的处理策略来讲，错误可以分成如下几种：终止性错 误、忽略性错误、登记性错误。 终止性错误即交易需要终止。这种错误在预处理和序列处理中都会遇到一 般来说一旦预处理失败，交易应该终止；同样序列中某方法处理失败，往往也需 要终止交易。而在返回处理时一般不会有终止性错误，因为交易过程已经完毕， 返回处理不管是成功交易还是失败交易都是必要的。 忽略性错误这种错误主要在批量交易中常见，整个批量交易中，其中单笔处 理错误不会影响整个交易的进程。 登记性错误主要用在交易一致性控制上，交易处理错误，而且存在一致性问 题，这时就需要登记冲正信息。 中间业务系统中还有很多辅助手段来处理错误，比如重发机制，当方法执行 失败时，并不退出，而是继续重复执行；再比如特殊错误处理，当主机或企业返 回的错误是比较明确的没有记帐成功错误，也就不会影响交易一致性时，中问业 务系统将针对这些错误不作冲正信息登记，减少不必要的冲正。 第四章银行中间业务系统实现 4 1 核心交易流程 4 1 1 主程序流程 由核心交易流程设计，我们知道交易总体分为“接收渠道报文”、“核心处理” 和“发送渠道报文”三部分( 见图3 4 ) ，因此主程序也是从这三个方面来进行处 理。 作为主程序，根据不同的中间件处理接收和发送各渠道的报文。通过核心处 理调用： c c o n t 出n ：n r u n ( c h a r + i n o u f - p s z m s 吕c h 盯+ i n o u t _ p s z f 订e ，c h a r 4 i n _ p s 2 c h a l l n o ，i n ti k m c t r l ，i mi j c o n v 删a 曲 这里对参数做一详细说明： i n o u t _ p s z m s g ：交易报文。该字符串既是接收到的报文，也是核心处理后需要 发送的报文。 i n o u tp s z f i i e ；交易文件。该字符串既是接收到的文件名，也是核心处理后需 要发送的文件名。 i n _ p s z c h a l l n o ：交易渠道号。该参数指明了本次交易是从哪个渠道来的交易。 i n - i t r c 廿l ：交易控制。该参数指明了本次交易是什么交易类型，可选择的值 是：o 正常交易，1 冲正交易。 i n - j c o n v e r t f l a g ：转换报文标志。该参数指明了本次交易是否需要对接收到的 报文进行转换。可选的值是：o - 不转换，直接解析到变量池，1 需要转换。 在以前的中间业务核心程序入口，我们是将交易码作为本次交易的唯一标识， 但存在的问题就是，如果是同样的一个交易，从不同的渠道上来我们如果是按交 易码作为唯一标识，这就意味着我们在配置交易的时候就需要根据不同的渠道配 置不同的交易码，但实际上交易的本质是相同的，这就增加了我们重复的配置工 作。 现在，我们将其修改为“渠道号+ 交易报文中的某一个或几个字段”作为我们 的一个交易的唯一标识，我们将其称为渠道交易码。所谓“交易报文中的某一个 或几个字段”，就是说在接收的报文中。按用户配置去提取交易报文中的某一个或 几个指定的字段的值。例如：现在某一交易从网点发起( 假设网点的渠道号是o o ) ， 用户指定交易码( 假设该交易码是c d 0 0 0 1 ) 作为标识，那么我们的核心内部就会处 理为；0 0 c d 0 0 0 l ，那么核心就根据0 0 c d 0 0 0 1 去查找该交易对应的输入，输 理为：0 0 c d 0 l ，那么核心就根据0 0 c d 0 0 0 1 去查找该交易对应的输入，输 u n 环境下银行中间业务系统研究 出及错误报文配置。 既然核心的入口参数做了改动，那么不同的渠道怎么区分呢? 我们现在的办 法就是给不同的渠道编译不同主程序，将其作为不同渠道的服务，由中间件统一 去调用。 在r l r u n ( ) 方法中还有一个参数值得注意：i t o c o n v e n f l a g 。中间业务系统本 身的变量池是采用x m l 树形结构存储，如果前台用户界面( 网点界面) 发送的是 x m l 报文，此时只需要将报文直接解析到变量池中就行；如果前台界面是其他某 种报文，此时就必须进行报文的转换，也就是说参数i r l - i c o n v e r t f a l g 的值是l 。 下面是一个主程序的例子： e x a n d l e ： + 。+ + 。+ + + + + + + 。2 。+ + + + 。女# * 女r 女女， 说l 蝇：1 、假殴渠道号是o o 2 、咧子q 一的通讯函数只烛说明处珲的过稃 + + + + 。+ + + 。+ + + + + + 。+ + + + 。+ + + + + + 。， # i n c 上u d e ”e c d b s t r u c t h “ # i n c l u d e “c c o m m h ” # i n c l u d e “q tv l a u e h ， l r e t = 0 ： + p s z m s g ， s z f i l e n 刮n e 2 5 6 + p o c o n t a i n = n u l l ； 迎讯处理，接收报文 l r e t = r l c o m m ( p s z m s