综合前置系统架构分析.docx

综合前置系统架构分析.docx

《综合前置系统架构分析.docx》由会员分享，可在线阅读，更多相关《综合前置系统架构分析.docx（17页珍藏版）》请在冰豆网上搜索。

综合前置系统架构分析

综合前置系统架构分析

摘要：

银行综合前置系统介于外围各业务子系统与银行业务核心系统之间，是银行各种交易渠道的汇总和整合。

它通过集中实现不同业务子系统间的协议转换、报文转换、交易路由、安全管理等功能，取代银行种类繁多的前置系统，以达到整合银行IT投资的软硬件资源，简化应用开发与维护目的。

一、系统综述

综合前置系统平台担负着与一系列终端渠道、各种主机系统和第三方系统间的信息处理工作。

主机：

指部署在总行数据核心生产系统主机，如账务系统主机，借记卡系统主机等。

渠道：

指银行客户在银行使用的各类交易手里终端系统，如柜台终端、自助取款机、电话银行等终端系统。

第三方：

指与银行业务有联系的外单位的信息系统，如人行、移动、券商等信息系统。

二、背景介绍

银行业务可以简单地划分为资产业务、负债业务和中间业务。

目前银行之间的竞争焦点是中间业务，中间业务是近年来在银行盈利的重心。

现代商业银行要扩张中间业务空间，开拓新兴服务手段，需要业务与技术密切结合。

随着服务品种的增多，服务范围的扩大，用以提供支持的技术系统也日益庞杂，银行技术人员的维护工作量也随之急剧上升。

由于竞争剧烈，导致商业银行的很多业务系统在缺乏统一规划的情形下匆匆上马，虽然能够满足一时之需，却使得整个系统架构日渐混乱，导致系统的可靠程度下降，维护和开发新业务的越来越复杂。

在银行的机房，经常可以看到各种前置系统（POS、ATM、金卡、呼叫中心、网上银行、银证通、各种代理业务）充斥其间，除了设备需要重复投入，还需要占用技术开发人员大量的精力进行维护和排除故障甚至需要进行辅助的业务，对新业务的开展是十分不利的。

在这种情况下，综合应用前置系统（GAPS即GeneralApplicationPreposedSystem，简称大前置系统）就应运而生了。

大前置系统是各种交易发起渠道集中、统一的中间接入系统，把各种终端设备的前置系统和外围系统与银行业务主机系统分离，在大前置上集中实现到相关的不同业务子系统的交易路由，是银行开展一般业务是交易发起终端和后台帐务主机间的枢纽控制主机。

以各类外围、外部系统的接入和业务交易（尤其是中间业务交易）处理为重点，建构一个稳定、安全、高性能的业务控制系统。

为实现业务发展需要，系统设计为一个开放式系统，具有高度的灵活性和扩充能力。

系统能够让业务开发人员使用系统提供的配置集成环境和统一开发环境，通过配置和开发的方式，进行业务功能的扩充。

同时系统为业务操作人员提供良好的人机交互界面，完成日常的业务操作和管理。

前置系统解决方案的发展经历了三个阶段。

1.单一功能堆砌的前置系统解决方案 

十余年来，各商业银行纷纷投入大量资金和资源，建设和发展信息系统和技术保障体系，并不断推出全新的业务种类和服务模式来满足持续发展的业务需要。

随着银行的服务品种、交付渠道和技术实现的不断增加，使得银行中对应的电脑应用系统也随之增多，由此便出现了这样一个情况：

 每一个应用系统单独对应后台业务、支付体系等支持系统，很多都配有前置处理机实现特有的业务处理、数据处理或者设备控制管理；银行机房中往往放置着大量不同业务的前置机系统。

第一代前置系统产品增加了系统维护人员的投入，造成银行设备和软件投资的浪费，各地、各个阶段重复开发现象严重，更加危险的是：

可能因应用系统的杂乱出现管理上的问题。

2.交换中心集成的前置系统解决方案 

随着交付渠道的发展，一个严重的问题摆在银行科技部门的面前，如何支持客户对多渠道服务的要求。

随之而来的是一个改良方案，前置系统的第二代产品：

交换中心解决方案。

交换中心解决方案从功能上实现了多渠道服务，但是造成的问题更为严重：

系统的可管理性更差，不但要管理原来的前置系统，还要管理交换中心。

系统的可维护性、性能都遭受到了新的挑战。

在银行推出新业务时，交换中心解决方案的开发比原来的方式还要复杂。

3.大前置解决方案 

大前置解决方案，也就是前置系统的第三代产品是对交换中心解决方案的发展。

它将现有的众多的服务交付渠道和业务前置应用在逻辑上合并成一个整体的系统，对各种不同种类的金融服务、交付渠道、前置业务系统和外围业务系统的共性加以提取和综合，辅以完善的管理功能，形成一套结构开放、适应各种后台核心业务系统、支持各类渠道、产品和业务的“热拔插”、方便升级、具有完备安全控制、容错、稳定、高效的前置解决方案。

以各类外围、外部系统的接入和业务交易（尤其是中间业务交易）处理为重点，建构一个稳定、安全、高性能的业务控制系统。

三、系统目标

（一）实现商业银行各种服务渠道与银行业务应用系统以及外围系统的互联；

（二）实现不同服务渠道共用业务逻辑的统一，形成各种渠道面向客户的一致服务；

（三）能够快速适应新产品或业务应用系统的推出；

（四）增强渠道统一管理，提升渠道系统的客户服务能力；

四、相关知识

（一）业务系统

进行业务交易的发起或处理的系统称为业务系统，各类前台、外围系统、帐务后台、外部单位的帐务系统或者综合应用前置系统都是业务系统。

业务系统根据对业务处理的不同可分为业务发起系统和应用处理系统，兼具发起和处理功能的综合应用系统可视为两种系统的合体。

（二）业务子系统

综合应用平台应用服务器中的业务子系统是指为某个外部业务系统服务所需要的在综合应用平台中对应建立的业务处理内部虚拟系统。

同一个业务子系统的交易，具有相同的交易特征码提取规范。

在业务子系统中，可以设定该系统的交易通讯数据的交易码和应用的提取流程，系统通过该流程为交易请求分配后续的交易应用归属，确定后续交易处理流程。

（三）业务应用

业务应用是业务的具体实现，包含了完成某类业务所需的交易、交易流程配置以及其他相关资源的配置信息。

业务应用可以互相进行调用。

一个外部系统的本地实现通常包含在一个业务应用实现中，对于需要和外部系统进行交易通讯的业务应用而言，可以把对应外部系统的应用视作该系统的一个本地虚拟实现。

（四）资源

综合前置系统中业务应用的可配置的元素称为资源，资源包括报文配置、XML结构定义、响应码配置、组件定义、交易流程配置等。

可以通过配置工具统一维护这些资源的定义和配置，在开发的组件程序中使用这些资源。

（五）流程

组件程序按照一定的规则有序组合，组合方式可以为顺序、循环、分支，及上述三种模式的多层嵌套。

交易的控制模块根据流程的配置，完成特定的交易或交易的部分功能。

（六）组件

完成某种特定功能的一段执行代码，应用服务流程控制子系统执行的流程由完成的不同功能的组件根据交易功能进行有序的组合构成。

组件可通过二次开发扩充。

根据组件实现方式的不同，组件可以是函数组件和程序组件（CICS下）。

其中，函数组件可以用静态或者动态调用的函数实现。

五、系统特点

（一）灵活、全面的配置

适应性强、配置灵活、方便能够较好地解决了综合应用平台面临的众多商户、众多接入和外联系统需求复杂的问题。

本次项目开发的目标系统需要实现这一特点，做到配置灵活、提高系统的可配置度，使配置开发过程快捷简单，同时对所有的可配置资源加以有效的控制和管理，做到活而不乱。

（二）简单、完整的管理

目标系统所要纳入的各类业务应用复杂，需要为提供一统一的的管理操作环境，提供日常维护操作、帐务处理、批量业务处理、查询服务等中心业务管理功能，并对所有的操作能进行有效跟踪和监控。

（三）稳定性

作为未来的数据处理中心的核心前置系统，系统的稳定性意义重大。

目标系统需要保证能为所有经过的交易提供稳定、不间断运行的保证。

（四）高性能

目标系统需要处理从前台柜面、银行周边、外部系统等各类方式发起的实时、非实时，单笔、批量交易，需要为银行提供高交易压力下的系统的处理能力，并保持交易处理的一致性。

（五）扩充性

为利于系统的升级、维护，应有良好的系统模块结构设计，使维护、升级等功能扩充的工作量、对原有系统的影响降低至最小。

解决好该问题能使系统升级、维护工作得到简化和标准化，使推广该系统的成本减到最小。

（六）安全性

系统的安全性包含两个方面。

一方面是由于系统和多家外部系统实现交易互联，由此带来系统的安全问题和联机交易数据的安全问题，需要建立相应的系统安全机制和通讯安全保障体系解决这一方面问题。

另一方面，系统的开发、使用过程中，必然涉及内部的开发人员、系统管理人员、一般操作人员，需要建立有效的系统用户授权和跟踪控制体系，避免由于人员的操作不当等引起的系统内部数据安全问题。

（七）二次开发能力

目标系统的设计为一个开放式系统，能够根据业务的发展，通过传统的开发手段，对系统的应用级功能的开发扩充，提高系统的适应能力。

（八）系统保障能力

任何系统都不能避免运行异常，目标系统作为业务核心之一，需要有对异常或故障事故的应对能力，在软件层实现系统故障保障功能，尽可能地减少故障带来的损失，提高系统的恢复能力和速度。

六、系统功能

1.强大的应用服务处理功能。

　　2.应用服务接入、报文转换、交易分发、流程控制、业务处理。

　3.丰富的业务应用管理功能

　　4.日常管理、中心查询、报表打印、批量发起以及系统业务监控。

　5.强大的应用配置开发集成功能

6.系统提供银行业务系统开发人员对大前置（GAPS）进行资源配置、交易开发、系统维护、业务和系统监控等功能的人机界面环境

　　7.系统综合测试平台

　　8.系统为业务开发提供了配置各类交易报文、自动生成和解析的环境。

七、系统架构设计与实现

（一）基本设计思想

综合应用前置系统GAPS，在资源层次模型（RLM）基础上进行扩展后建立各级资源对象，形成系统的资源管理树。

应用服务处理核心（ASPK）根据资源的配置实现交易逻辑的控制。

系统提供的应用配置集成开发环境（ACIDE）则由开发人员通过对该资源管理树的扩充更新，实现对ASPK的控制。

业务应用管理控制台（TAMC）由业务人员使用，提供用于系统的业务管理操作的界面环境。

（二）系统架构

（三）总体运行结构

（四）业务逻辑架构

（五）eRLM模型

在eRLM中与业务应用实现相关的实现要素为前置系统资源，诸如数据资源、报文结构、文件结构、组件、流程均被纳入到平台的资源管理中。

前置系统的资源分为以下层次：

数据资源层、控件资源层、组件资源层及应用服务流程。

数据资源层主要包括XML数据存储交换区和前置系统数据库。

XML数据存储交换区存在于业务处理进程内存之中，其中存放的数据是处于交易运行态的，是临时的、动态的；而数据库是存在于硬盘之中，其中存放着静态的永久数据。

两者均包括配置数据和业务数据。

控件资源层包括接口控件、凭单控件、响应码控件等。

利用系统应用开发配置集成环境，开发人员可以编辑任意的控件资源。

组件资源层包括对控件进行操作的组件和其它组件，是系统的执行码资源，组件可以通过对控件资源的操作实现业务数据的存取，也可以直接操作数据库资源，每一个组件完成某一特定的功能。

利用系统提供的组件生成工具，开发人员可以通过二次开发添加新的组件资源，或通过安装组件扩充包增加可用的组件资源。

组件通过执行顺序的组合形成特定交易应用服务处理流程。

（六）管理资源树

（七）流程原理

流程图由两种主要对象构成：

流程构件和运行线。

流程构件包括：

起始构件、结束构件和执行构件。

运行线连接构件中的连接点，体现流程的执行过程。

不同的连接线颜色代表的所连接的执行组件的接出点的流程状态。

一个执行组件可以有任意多的组件执行结果状态，但不同的结果状态对流程整体的影响只有三种：

无影响，强制成功和强制失败。

无影响的接出点连出的运行线为黑色，强制成功接出点连出的运行线为蓝色，强制失败接出点连出的运行线为红色。

（八）交易处理模式

1.直接处理

2.服务转发

3.交易路由

4.多方路由

5.多次交易

八、系统功能模块

（一）应用服务处理核心（ASPK）

ASPK是GAPS的业务功能提供核心。

ASPK包括三个子系统：

应用服务接入、分发、流程控制子系统。

主要流程：

发送到大前置平台的交易数据由SES根据不同的请求发送系统类型进行通讯接收，并将接收到的交易数据传递至SDS，SDS根据系统类型进行初步的数据报文分析，提取出交易识别码，并为该交易数据分配交易内部标识码，由SFS根据预先定制的该内部标识码，调用流程控制处理模块运行定义的流程，执行业务逻辑完成功能。

用户也可以自己开发自定义各处理模块执行相应的业务处理。

（二）业务应用管理控制台（TAMC）

业务应用管理控制台（TAMC）提供业务操控人员对大前置（GAPS）进行业务控制的人机界面环境。

TAMC一般安装在中心，由中心的业务操控人员进行日常管理、中心查询、报表打印、批量发起以及系统业务监控等功能。

TAMC通过TCP/IP方式和ASPK的业务管理交易接入通道进行交易通讯，和ASPK、大前置数据库构成三层结构。

TAMC的所有功能都通过交易方式实现。

ASPK上的管理交易处理系列组件是管理交易的真正运行部分。

TAMC除提供统一的业务管理交易功能菜单外，还提供对特殊管理交易进行功能扩充的接口。

TAMC的所有功能都是有统一的功能编号的，用以区分不同的功能模块，实现操作员的权限控制。

（三）应用配置集成开发环境（ACIDE）

应用配置集成开发环境（ACIDE）提供银行业务系统开发人员对大前置（GAPS）进行资源配置、交易开发、系统维护、业务和系统监控等功能的人机界面环境。

（四）前台字符终端人机界面环境（IFI）

银行网点柜面人员处理交易的终端操作界面环境。

（五）前端配置集成开发环境（IFCIDE）

通过前台配置工具（IFCIDE），银行业务系统开发人员可以对柜面前台的交易处理进行定制，包括输入输出字符界面、交易通讯接口、操作流程等。

IFI对IFCIDE配置的数据进行下载刷新后，就可以实现对前台交易逻辑的修订。