重庆建行数据集中方案.docx

目 录
1. 概述 4
2. 重庆建行系统现状 5
2.1. 现有系统说明 5
2.2. 建行湖北版城市综合业务网络系统 5
3. 系统改造目标 6
4. 数据集中 6
4.1. 数据集中——金融电子化的发展方向 6
4.2. 数据集中的特点 7
4.3. 数据集中的可行性 7
4.4. 实施数据集中的步骤 7
4.4.1. 数据转换目标 8
4.4.2. 数据转换工具设计 8
4.4.3. 系统的测试 8
4.4.4. 系统转换的安全性 9
4.4.5. 密钥管理问题 9
5. OLTP中间件连接方案 9
5.1. OLTP中间件的工作流程 9
5.2. 联机事务处理中间件应具备一下功能： 11
5.3. 中间件比较 11
5.3.1. CICS系统 11
5.3.2. TUXEDO平台 12
5.4. 中间件选择建议 13
5.5. CICS进程调度 13
5.6. CICS通讯管理 14
5.7. CICS的安全性 15
5.7.1. CICS资源的授权访问 15
5.7.2. CICS客户访问的安全性 16
5.7.3. CICS与INFORMIX数据库间的安全性 16
5.7.4. CICS通讯的安全性 16
5.8. CICS的故障恢复 17
5.9. 数据完整性 18
5.10. CICS应用程序设计接口 18
6. 关键问题的解决 19
6.1. 批处理程序优化 19
6.2. 中间业务 21
7. 金融产品开发平台 21
7.1. 会计核心组件 21
7.2. 凭证控制组件 22
7.3. 金融OLTP平台产品——ACE 22
7.3.1. 概述 22
7.3.2. ACE前台解决方案 23
7.3.3. ACE的原理 23
7.3.4. ACE的特点及其功能描述 24
7.3.5. 4GL语言 24
7.3.6. 强大的通讯功能 24
7.3.7. 设备服务器 25
7.3.8. 跨终端授权 27
7.3.9. 文件广播 27
7.3.10. 内嵌SQL语言 28
7.3.11. 完善的安全措施 28
7.3.12. 丰富的开发维护工具 28
7.3.13. ACE NT版 29
7.4. PowerLink自助设备管理控制平台 29
7.5. 中间业务综合开发平台PowerMid 32
7.6. 网络银行及其开发平台PowerNet 35
7.6.1. PowerNet的功能 36
7.6.2. PowerNet系统结构 36
7.6.3. PowerNet软件结构 37
7.6.4. PowerNet的安全性 38
7.6.5. PowerNet的特点 39
7.7. 电话银行及PowerTele 39
7.7.1. PowerTele的功能 40
7.7.2. PowerTele方案 40
7.7.3. 产品特点 43
7.7.4. 业务系统的关系 43
7.7.5. Call Center 43
7.8. 联想的PowerCall开发平台可以快速实现高质量Call Center系统。 44
7.8.1. PowerCall的功能 44
7.8.2. PowerCall方案 45
7.8.3. 产品特点 47
8. 项目管理及软件实施计划 47
8.1. LAS对项目管理的重视 47
8.2. 开发项目管理 48
8.2.1. 项目组织 48
8.2.2. 任务小组 50
8.2.3. 开发过程 50
8.2.4. 文档要求及管理 52
8.2.5. 公司对开发项目的监管 53
8.2.6. 人员评价 54
8.2.7. 项目评价 54
8.2.8. 对项目组的管理要求 54
8.3. 实施计划 55
8.4. LAS计划投入的开发人员 56
8.5. 合作双方的分工协作 56
8.6. 项目组的运作及管理规定 57
8.7. 合作期望 57

1. 概述
要成为重庆建行银行业务业务信息系统改造的合作伙伴，就必须对重庆建行信息系统所要达到的目标有一个全面的、正确的理解。长期以来，联想集成系统公司一直与中国金融界有广泛的合作，做为国内金融电子化的一支主力军，从1993年起，便积极参与国内银行业务的电子化建设，先后研制了各类软硬件组件和平台产品，尤其是在1996上半年，我公司首先在光大银行深圳分行成功地开发了“一柜通”业务系统，该系统全面实现了综合柜员制、大会计、客户信息管理、参数化设计等先进的设计思想，系统在客户机/服务器平台上运行。该系统的建成对国内银行业务的电子化建设产生了巨大影响，从1996年下半年至1997年，我公司先后分别与福建兴业银行、交通银行总行、中信实业银行总行、深圳市农村信用合作联社以及绍兴市商业银行等确立合作伙伴关系，共同开发银行综合业务系统，并最终都按期、按质、按量完成系统的开发和投产运行， 给用户带来了巨大的经济效益和社会效益。
1997年3月，天津建行为加快电子化步伐而开发的第二代储蓄通存通兑系统，他的开发由天津建行和联想集成系统有限公司进行合作，于1996年3月开始到1996年11月完成系统切换一次性转换上点213个储蓄网点，并安全运行至今。
天津建行储蓄系统完成了活期、定期等所有储种的通存通兑，并开发了代理、国库券、小额抵押等多种业务；天津建行储蓄系统同时实现了从微机系统到中小型机系统安全可靠的一次性大规模系统转换的成功范例。
1997年，我公司为建总行开发新一代柜面业务系统——端末系统。本项目历时两年，现在正在测试阶段后期，准备在上海建行第一次投入运行。届时，联想公司通建总行合作，准备在上海建行进行更大规模的系统一次切换工作，一次切换的营业网点达到400多个。
建总行对联想公司的工作基于充分肯定。并表示随后的新一代柜面业务系统（AS400版、UNIX版）的开发由联想公司参与完成。

2. 重庆建行系统现状
2.1. 现有系统说明
重庆建行的辖区为：重庆市、万县和涪陵。电脑中心也有三个，重庆市中心为上级中心，万县、涪陵作为下辖中心同重庆市中心相连。其中：
重庆市营业网点有200多个，自动柜员机（ATM）30多台，POS100多台，日交易量为7万多笔，高峰时期达到12万多笔。
万县营业网点有60多个，日交易量1万多笔。
涪陵营业网点有70多个，日交易量接近2万笔。
由于业务的发展，重庆市及涪陵、万县的通存通兑业务及往来业务不断增多，系统的清算对帐占用业务人员大量的时间。清算和通兑要求数据中心进一步合并，形成重庆市、涪陵和万县的统一数据中心。
2.2. 建行湖北版城市综合业务网络系统
重庆建行现运行的系统原版是建行湖北版城市综合业务网络系统。储蓄、信用卡系统运行在一台主机，对公系统运行在另一台主机。（涪陵、万县与重庆市类似）。本系统在重庆建行电子化道路中作了很大的贡献。但随着银行业务的发展，本系统在应用中暴露出许多问题，虽然重庆建行科技人员对它进行修改优化，但由于系统前期设计未考虑的几个因数，造成本系统维护困难。
1. 原系统支撑平台，通讯程序简单，功能较弱，性能较差，处理能力不高，由此引起系统死机，帐务不平。
2. 没有独立的交易管理层，交易完整性依赖应用程序。
3. 调度不合理，系统尖峰时刻运行进程较多，性能下降，处理速度变慢。极端情况造成恶性循环，引起系统崩溃。
4. 通讯功能简单，网点监控，核心调度，通讯流量监控，日志监控功能弱，甚至不具备这些功能。
5. 通讯软件与应用软件编译在一起，难以发展。更新应用要重新编译系统。
解决方法：引如通讯可靠，高效。进程管理调度功能强的监控交易中间件产品。保证系统大规模并发处理高效性和分布业务可靠性及数据的完整性。
3. 系统改造目标
鉴于以上原因，我们提出重庆建行业务系统改造方案。
方案的近期目标为建立数据集中——合并重庆、涪陵、万县数据中心为重庆市数据中心；增加中间件对在线业务的管理；更改现有系统批量业务（代收代扣业务）；优化批处理程序，使批处理高效优化。
方案的远期目标为与总行的新一代柜面业务系统接轨，数据集中，业务规范，统一会计制度，实现真正综合业务系统。
4. 数据集中
4.1. 数据集中——金融电子化的发展方向
数据集中是一个相对的概念，它是集中与分散、完全集中与分布集中相对照而言的。从我国金融电子化发展历程和发展趋势来看，数据集中可分为两个阶段，第一阶段是由微机单点发展到网络化集中处理，数据逐步由单点集中到二级分行处理中心。这一过程，各行都经过了十几年的发展，由电子化初期的微机单点运行发展到现在的城市综合业务网络，实现了主要业务省内甚至跨省联网，有的业务已全国联网。数据集中的第二阶段，是扩大联网范围，同时减少网络层次，数据集中到总行和一级分行的数据处理中心，而且一级分行的数据处理中心随着金融体制改革的不断深化，将向区域数据中心过渡。工商银行的大机延伸工程已开始进行这种数据集中，建设银行总行制定的计算机应用总体设计方案也确立了这一发展方向。
4.2. 数据集中的特点
数据集中的主旨在于共享主机资源，减少网络层次，提高效率，加强管理。与分散和分布式集中相比它有很大的优势：一是有利于业务的规范化，便于新业务、新应用系统的实施；二是有利于集中统一管理，集中监控，减少计算机犯罪的可能，防范风险；三是有利于加强系统维护和开发，提高系统安全性及可靠性；四是有利于节省设备投资，减少运行费用，减少人员开支，降低维护成本。数据的大规模集中也带来一些新问题：一是大规模集中的风险度增加，对系统备份及网络备份的要求提高；二是业务大规模集中处理使得业务处理中心的管理、维护更加复杂，对业务处理中心系统维护人员技术水平要求提高；三是由于联机交易系统的主要瓶颈在磁盘输入输出，因此如何提高磁盘系统的性能成为一个关键的问题，系统设计中，必须着重考虑磁盘系统的总线结构和布局，以及采用高性能的磁盘阵列；四是由于数据规模的大大提高，数据库的处理能力、性能、参数配置与以往系统均存在本质的差别，数据库管理的要求大大提高。
4.3. 数据集中的可行性
经过十多年的计算机应用，重庆建行行已实现了地市级的数据集中，为向更大规模的数据集中铺垫了道路。从当今信息技术的发展趋势来看，计算机主机系统的处理能力、扩展能力和伸缩能力已经取得了飞速的发展，使得数据的集中统一处理成为可能。目前主机系统较前几年价格低了许多，前几年一套主机的投资现在可以买到性能提高十几倍的设备。通讯事业迅速发展，DDN、帧中继等网络系统完全可以使银行建立一个高速、高效、高可用性的银行网络。同时，国内外银行采用大集中模式的成功实践，为银行实现大集中数据处理提供了许多可以借鉴的经验。
4.4. 实施数据集中的步骤
数据集中的实施是一个复杂的系统工程，它不仅仅涉及到计算机技术实现的问题，还涉及到业务部门在业务组织和管理方面的相应配合和调整，必须精心设计、组织、逐步实现。
数据转换目标
数据集中采用编制移植工具的方式完成。被移植中心（涪陵、万县）的各类帐务数据转换成文本文件。通过文件传送，送到重庆中心。重庆中心，将文本数据插入到系统中，并检查是否重复插入。万县、涪陵各营业网点从本地中心下载运行参数，更改本地中心下载参数，使之运行后台主机变为重庆市中心。整个移植工作，由移植工具在全部营业网点日终签退后进行，不影响被移植中心辖下营业网点次日正常业务。
数据转换工具设计
系统设计移植工具中包含了数据传输、数据转换，数据对帐等几部分。
数据传输将微机帐务数据传送到后台主机，严格保证了数据传输的可靠性和一致性。
数据转换实现了快速自动将传输数据转换重庆中心数据库中。
数据对帐是为了保证帐务数据的正确可靠转换进行的对帐过程，严格保证了转换数据帐务的正确性。
在系统设计中对数据转换量的大小和通讯量的大小进行了认真的计算和评估，保证数据传输在3小时以内完成。
系统的测试
由于涪陵、万县系统庞大的数据量，为了保证系统转换的可靠性，系统制定了严格的测试计划。
首先，程序设计阶段对不同数据量进行各种功能、压力测试。测试结果，限定时间解决后再测试。将对数据库表操作改为对文本文件进行操作，可大大缩短转换传输时间。
其次，在实施系统转换前进行了2次以上严格的通讯压力测试以解决相应的问题。同时注意由于意外造成通讯中断时可以从通讯断点开始继续传输，使得通讯效率提高。保证了系统转换在12小时内完成。
只有在实行了多次的严格测试后，才能够保证整个系统的一次成功。
系统转换的安全性
系统采用了多个方面的措施以保证系统转换的安全可靠性：
1）数据转换完采用数据对帐核对总分、总总平衡并打印出对帐报表保证转换后数据和原有帐务系统数据的一致性。
2）应用程序设计接收日志保证每一次传输的内容记录数成功记录数等都有所记录，并且保证数据传输数量长度的正确性及不会被漏传或多传。
密钥管理问题
对于移植中，分户帐密码，一般由系统密钥加密。对于按密码反算法可以还原密码明码的。编制工具对移植数据用户密码重新解密加密。使整个系统保持一套密钥。对于用户密码无法还原明码的，更改系统密码校验算法，使系统根据不同区域的帐号，调用不同的密钥校验密码，系统需要保持多套密钥。
5. OLTP中间件连接方案
5.1. OLTP中间件的工作流程
联机事务处理中间件主要面向布式事务处理的全局交易、异构环境的事务互操作以及提供丰富的开发工具，并最终走向面向对象方式，实现广泛的互联和控制。联机事务处理中间件包括资源管理子系统、事务管理子系统、通讯子系统等，一般是把数据库系统作为联机事务处理系统的资源管理系统。

应用系统
Application Program
事务管理
资源管理
通讯管理
资源管理
通讯管理
通讯管理
资源管理
中间件平台
交易请求

上图中,应用系统指为完成相应业务逻辑的应用程序组成的集合,在采用中间件技术的C/S三层架构中,应用程序的通讯管理和事务管理一般是利用中间件平台提供的接口编写的,这样就避免了应用系统对操作系统、数据库的依赖性，使应用系统有了良好的移植性。
源管理系统主要用来管理数据库系统和文件系统等资源，维护资源的一致性和安全性，即管理兵发事务对资源的安全存取。
事务管理模块负责管理系统中的所有事务，维护每一笔事务的状态，如活动、提交、创建失败、回退、核对、挂起等。事务管理系统接收事务开始请求并创建相应的事务标识号；在分布式事务处理采用两阶段提交时，事务管理器还将扮演两阶段提交中的协调者角色。
通讯管理模块用以提供系统需要的通信服务，如Client端与Server端的信息交互，本系统中的应用程序和其他应用系统的通信，多点提交事务中访问远程资源等。通讯的具体细节，如采用的通信线路、通信协议及码制等，都屏蔽在通讯管理模块中，由通讯管理模块提供统一的调用接口。
事务管理和通讯管理是由联机事务处理中间件完成的，而资源管理一般由数据库管理系统完成。
客户方发出一个交易请求时，由中间件的通讯管理模块接受请求，并进行数据接收处理，再移交给事务管理器。事务管理模块创建一个事务，并按应用流程处理和跟踪事务 。对于分布式事务，由事务管理器来处理和管理全局事务，并进行协调。
5.2. 联机事务处理中间件应具备一下功能：
l 提供强大的分布式联机事务处理能力
l 提供功能强大的应用运行环境
l 屏蔽硬件,网络和操作系统
l 支持模块化的开发，提供应用的可重用性
l 提供命名服务使服务器位置透明，可扩展性强
l 提供应用的负载均衡、高可用性和安全机制
l 提供强大的应用管理和监控机制
l 提供与其它应用系统的连接机制
l 提供交易管理的功能，保证交易的一致性
l 提供队列的管理和应用的优先级机制
l 灵活的消息传递
l 灵活的进程通讯
l 优化的资源和进程调度
l 优化的数据库连接
5.3. 中间件比较
l CICS系统
CICS是IBM公司开发的商业应用程序服务器，最初是在 IBM大型机上开发出来的，目前在IBM的ES/9000、RS/6000、AS/400，以及SCO UNIX、HP-UX等一些非IBM UNIX系统上都有相应的产品。
CICS具有关系型数据库管理系统所标榜的事务处理功能，一系列丰富的CICS功能和服务可以管理所有应用程序资源，为客户机／服务器提供强有力的支持，可以在平台之间相互操作并根据企业规模灵活扩展。
CICS提供通讯管理、事务管理、交易管理等功能，可以在局域网和广域网上通过分布和共享资源实现工作负荷均衡安排。
CICS作为IBM 的产品，支持3270等仿真功能，是IBM大型机上不可替代的产品。
l TUXEDO平台
TUXEDO 是BEA公司的中间件产品。BEA公司是专门制作中间件产品的独立软件供应商，在中间件软件市场上占有最大的份额。
TUXEDO是成熟、稳定、可靠的开放平台交易中间件产品，具备了所有交易中间件应具备的功能。另外，BEA Tuxedo拥有以下较为独特的功能：
提供7种客户机/服务器通讯方式，使应用开发灵活方便；
提供网络通讯压缩和加密机制，使通讯性能和安全性大大提高；
提供数据依赖路由机制，提高系统设计的灵活性；
提供3个层面的系统负载均衡机制，能最有效地运用系统资源；
提供3个层面的应用高可用性机制，保证应用的高可用性；
提供3个层面的应用安全机制，保证应用的安全性；
提供2个层面的优先级机制，使应用开发灵活方便；
支持XA协议，保证交易和数据的一致性；
提供3个层面的应用管理机制，使应用管理方便容易；
BEA Tuxedo还拥有一系列的周边产品，将其功能扩充；
BEA Jolt - 使基于Tuxedo的应用支持Internet前端；
BEA Connect - 将基于Tuxedo的应用和大型机应用无缝联接；
BEA Manager - 将基于Tuxedo的应用管理开放给SNMP；
BEA Builder - 基于Tuxedo的应用开发工具；
BEA Tuxedo是最开放的交易中间件，遵循／制定标准。
TUXEDO 支持70多个不同的硬件/操作系统平台，其中包括几乎所有的 UNIX，Windows NT, OS/400, VMX, OS/2, Windows95等等。
BEA Tuxedo支持几乎所有的关系数据库，并能通过XA协议和Oracle、 Informix、Sybase等流行数据库接口以保证交易的一致性。
BEA Tuxedo 遵循所有关键的应用接口标准和事务处理协议，如分布式事务处理模型DTP，事务定界标准TX，应用程序事务处理接口标准XATMI，以及和资源管理器(数据库)的接口标准XA等。BEA Tuxedo不仅遵循 标准， 而且目前的标准象XA，XATMI等大部分是基于BEA Tuxedo技术来制订的。同时，BEA是COBRA组织的核心会员，直接影响着面向对象技术的标准和发展方向。
5.4. 中间件选择建议
CICS最初是在IBM大型机上开发出来的，已经历了几十年的发展和完善有其特有的优势，是；同时，在由于银行界IBM的系统站主导地位，CICS和这些系统能做到无缝连接，这也是其他中间件无法相比的。
BEA公司专门致力于中间件软件开发，不依赖于任何系统和数据库，BEA TUXEDO产品使用最广，支持平台最多，功能强大而齐全，具有很好的扩展性和兼容性。
综上考虑，我们建议采用CICS系统，作为系统的OLPT中间件。
5.5. CICS进程调度
配置CICS时，需要为CICS区域指定应用服务器的最小数目和最大数目。事务调度程序将保证这一最小数目总是存在的，并且根据整个系统的工作负荷情况来动态地调整应用服务器的个数:当CICS启动后，事务调度程序启动最小数目个应用程序服务器，当业务量增大时，所有应用服务器都处于忙的状态，如果这时有新的事务请求时，调度程序将创建新的应用服务器，反之则杀掉空闲的应用服务器进程，保证应用服务器的个数在最大数目和最小数目之间。
CICS的事务调度程序担负着调度和分派要运行事务的责任。每个用户、设备和事务都有一个关联的优先级，当你提交了一个事务，调度程序将为它计算整个优先级，它可按照需求的急缓确定请求的优先级。在此之后，它分派事务请求到可用的应用程序服务器进行处理。
调度程序分别与应用程序服务器和CICS客户端进行通讯。作为整个工作负荷的控制器，调度程序同样控制在该区域内应用程序服务器的数目。
5.6. CICS通讯管理
用户通过CICS客户端软件与事务处理服务器进行交互，并获得事务处理服务。事务处理服务器可以相互通讯，也可以与资源管理器（诸如结构化文件服务器和 RDBM）或其他系统通讯以提供全部范围的服务。
在一个分布系统中，事务处理服务器管理用户和应用程序通讯的所有方面。它允许：
多个用户互不影响地访问事务处理服务器，并保证它们总是得到期望的响应。事务处理服务器保证数据送到期望的用户，并且可以被用户设备显示或被用户的应用程序处理。
在为商业应用程序提供最优的服务时提供跨服务器分布的事务处理服务器的功能。
事务处理服务器通过通讯机制共享数据、资源，因而可以提供一个更灵活的服务并更好地使用资源。
CICS客户端（用户工作站与其他设备）可以在任何地方用多种方式与事务处理服务器通讯。
其他系统（事务处理与非事务处理）充分利用事务处理服务器 ，并轮流被事务处理服务器使用。
在事务处理服务器环境中的通讯协议可以使用TCP/IP与SNA。为了提供网络透明的系统对系统的通讯，可以被使用远程过程调用（RPC）；例如，CICS 区域与 SFS 间的通讯，以及在一个 Encina 监控器单元中服务器之间的通讯。
每个事务处理服务器都可以和其他系统（客户与服务器）进行多个并行的通讯会话。事务处理服务器监控活动的所有会话，以便不使任何会话等待访问。
事务处理可以使用多种方法进行分离的事务处理服务器间的通讯。一个事务处理服务器可以：
将事务送到其他预先定义的或动态确定的事务处理服务器。
装运事务处理请求的功能到其它事务处理服务器。
链接应用程序到其他事务处理服务器上的程序。
在本地事务请求时启动远程事务处理服务器上的事务处理进行异步处理。
事务处理服务器也允许通讯使用：
在一个系统能通讯之前，它必须标识远程系统并与那个远程系统连接。远程系统必须为自己做广告，并提供可用的 联接信息 以便于连接。这由名称服务提供，也可由 DCE 单元的单元目录服务（CDS）提供，或在 CICS 环境中，由每个 CICS 区域提供。再次主要依靠 DCE 或使用由个别 CICS 区域提供的服务来保证系统间通讯的安全。
在 EBCDIC 中存储数据的系统可以与以 ASCII 形式存储数据的其他系统传送数据。例如，数据可以在 CICS for AIX 版（ASCII）区与 IBM 基于大型机的 CICS（EBCDIC）区之间传送。
5.7. CICS的安全性
对于防止非授权人员使用系统和保证用户仅访问他们应该使用的资源，保护一个商业信息系统是一项非常重要的需求。事务处理服务器保护系统、事务、数据、以及应用程序使用的其他资源。
下面主要分三个方面说明CICS的安全特性
l CICS资源的授权访问
授权访问可以检查用户是否有访问资源所需的权限。通过限制用户只访问特定的事务处理和其它资源，可以使你的事务处理服务器更加安全。该权限安全性基于特许用户的存取控制表 (ACL)。列表定义用户可以使用哪些事务处理和其它资源。
在 DCE 单元中，DCE RPC 用来限制仅认证的服务器访问资源管理器。要限制特定用户的访问，可以使用 CICS 权限安全性或 DCE ACL 的 ACL 管理器。
即使正在使用 DCE 安全性，也可以使用 CICS 的事务处理和资源安全性提供权限保证。这里提供的权限用于 CICS 自己的资源和任何 CICS 访问的资源。 CICS 权限安全性基于 CICS 用户预先定义的密钥、终端定义、运行时数据库中的其它资源定义。可以使用外部安全性管理器提供附加的或不同的权限安全性。
访问Encina 监视器单元中的资源由 DCE 的安全服务来控制。当一个事务处理请求访问一个资源，监控应用程序服务器和资源管理器与 DCE 安全性服务器协商验证权限。
l CICS客户访问的安全性
当一个CICS 客户连接至一个CICS 区域时，该区域需要客户提供一个缺省的用户标识符和口令 。如果该客户有服务器的文件记录细节，它就可以自动地提供这个缺省用户标识符和口令；否则，提示该客户程序的用户输入适当的的值。然后该服务器确认用户的合法性。
如果这个用户标识符的权限不足处理请求，该客户可以自动地发送一个新的用户标识符和口令(对于 ECI 请求)，或对于 EPI 和 3270 终端仿真请求，提示该客户程序用户输入一个新的用户标识符和口令。
l CICS与INFORMIX数据库间的安全性
在访问 INFORMIX数据库的 CICS 区域上，运行的所有事务处理访问该数据库使用相同的数据库用户标识符，因此有相同的权限作用于数据库中的资源。要为数据库存取提供更好的安全性，可以使用 CICS 安全性控制存取 CICS 区域 和指定资源，例如事务处理可以存取存储在数据库中的数据库和文件。
l CICS通讯的安全性
将系统连接在一起使那些系统的用户共享资源。然而非常重要的是，两个系统通讯时，保证这两个系统就是需要通讯的系统，资源仅能被有权限访问它们的用户共享。
在 DCE 单元中，CICS 和 Encina 可以使用已认证的 RPC 保护系统间的通讯。认证检查由 DCE 安全性服务执行。
CICS 内部通讯提供单一独立区域的 CICS 安全性扩展名以允许系统间请求的安全性检查。 CICS 内部通讯安全性检查由正接收请求的 CICS 区域 执行。
5.8. CICS的故障恢复
事务处理服务器保证商业系统和它的数据保持在一致的状态中。在一个应用程序的事件或系统故障中（例如，一个机器掉电和计算机关闭），事务处理服务器能自动地重新启动它自己（如果需要的话），并恢复出故障时未完成的工作，包括数据的更改。如果它不能提交一个任务的数据更改，事务处理服务器动态地 恢复更改到系统最后的同步点。
事务处理恢复服务是基于：
逻辑工作单元（LUW)和同步点
这些提供了事务处理作出的最新提交更改的记录。
事务记录：
当一个任务正在运行时，事务处理服务器记录了可恢复的数据的更改信息。记录信息表示出从上次同步点以来未提交的数据更改。
动态事务复原：
如果一个任务未完成，事务处理服务器使用记录信息和资源管理器记录的信息，使未提交的数据更改ROLL BACK，恢复可恢复的数据到以前的提交状态。
用户日志：
用户日志记录了事务处理服务器没有提供的恢复功能的信息，例如审计资料。
当要提交一个 LUW 时，此事务处理服务器要保证所有这个 LUW 中涉及的可覆盖服务器都提交它们的更新。如果一个或更多的服务器不能这样做（例如，如果同向资源管理器的通讯线路已中断），那么所有服务器必须逆序恢复它们的更新。为了完成上述操作，提交过程有两个阶段（称为二阶段提交）。　在第一个阶段，事务处理服务器轮流地要求每个参与者记录足够关于 LUW 的信息，以便事务处理服务器提交或逆序恢复更新。在第二个阶段，事务处理服务器检查所有的参与者是否都已成功地完成它们的更新。如果都已成功完成，它就提交更新：否则，它就逆序恢复改变并异常中止事务。
5.9. 数据完整性
数据完整性是与所有共享数据有关的问题。即使只有一个用户更新数据，就有读完整性的风险，因为在其它用户读此数据时它已是过时的。
如果许多用户能更新文件，就会有更大的数据完整性的风险。如果两个任务要更新相同的数据项，它们能互相干扰或覆盖一个任务的更改。事务处理服务器通过实施写完整性，以避免更新冲突和更新丢失。
通过串行化可维护写完整性。串行化的实现方法如下，一旦一任务要更新数据时对该数据加锁，且延迟其它任务对同一数据的更新，直至完成这一更新且释放锁为止。读完整性能用相同方法实现。
为了正常工作，加锁必须由一个程序实施，此程序控制了其它用户对加锁数据的存取。数据库管理器、存取法、事务处理管理器和操作系统都用锁定来防止用户之间的冲突。
LUW 提供当二个或多个数据项之间存在处理关系时必需的内部数据一致性。例如，单个LUW将用来在两银行帐户间传送钱并记录这一传送。LUW保证三个操作一起完成，从而两个帐户包含一致的数据，且该数据与传递记录相匹配。
5.10. CICS应用程序设计接口
CICS 提供一组公共的程序设计命令，用于从一个应用程序中请求 CICS 服务。该组命令就称为应用程序设计接口（API）。因为对于所有的 CICS 系列成员，API 是公共的，所以 CICS 应用程序可从一个平台移植到另一个平台。
编写一个 CICS 程序与编写其它程序极其相似。可以使用 COBOL、C 或 C++ 来编写 CICS 应用程序。大多数的处理逻辑是用标准的语言语句来表达的，但是对于某些功能需要使用 CICS 命令。
应用程序与CICS的连接方式如下所示：

初始化环境
初始化ECI调用参数
给ECI参数赋值
ECI调用
根据返回值的不同
进行相应的处理
连接CICS
接收数据

进行交易处理

返回CICS调用

Client
Server

在前端应用程序主要采用ECI调用，首先对调用的参数域进行赋值，其中包括通讯缓冲区CommArea的指定。对通讯数据的加密或加压都可以对此缓冲区中的数据进行操作来完成。在后端，CICS根据前端ECI调用中指定的交易程序名调用相应的交易程序，交易程序从缓冲区中读出数据后进行处理，最后返回，这样就完成了一个简单交易。
6. 关键问题的解决
6.1. 批处理程序优化
批处理工作量的分析与效率的关键影响因素
批处理是高度集中的大数据是处理。其中包括两方面
· 大量的数值计算
· 大量的数据库读写操作（Select、Update等）
而其中绝大部分时间是在数据库读写操作上（比数值计算长几个量级）。
数据库操作中占时间大部分的是多表连接的复杂SQL操作，此时占用时间极大。因此必须仔细考虑算法。
例：储蓄活期计息、笨算法的例子：
假设我们设计储蓄活期计息的算法如下：
1.取活期分户帐的一条记录
2.计算利息
调用公用核心
3.1取分录表中分录，生成记帐用电子传票。
3.2根据帐号中科目代号，读科目表找到其存储的分户帐
3.3记帐：
3.3.1扫描活期分户帐，找到记帐的分户记录
3.3.2更改余额
3.3.3写回活期分户记录
3.3.4扫描内部帐文件，找到“利息支出”
3.3.5更改余额
3.3.6写回内部帐记录
设：·有活期户20万户，活期帐号长度15位。
则算法复杂度为：
第1步需进行20万次
第3.3步需扫描分户帐，一次完全的Select操作，即要对分户帐号进行20万次比较。
总共需：20万×20万=400亿次 字符串比较（15位）
这是一个O2复杂度，可以看到它庞大的计算量。
同时，大表的读写会导致大量的硬盘I/O操作，会进一步降低效率。
因此，批处理设计的关键在于优化算法，降低算法复杂度。
例：优化的储蓄活期计息算法
1.扫描活期分户帐
1.1取一条记录
1.2计算利息
1.3产生电子传票
1.4更改分户余额
1.5计对方科目（活期利息支出）的发生额
2.扫描内部帐文件
2.1取出“活期利息支出”帐户
2.2将第一步累计的发生额加入科目余额
2.3写回内部帐文件
无疑，优化的算法复杂度为线性。比第一个算法快得太多。
②利用实时生成统计文件，减少批处理的数据统计量。
实时生成统计文件，利用联机记帐时的“空隙”，可以大量减少批处理时的数据统计量。
6.2. 中间业务
一般联机业务要求实施处理，在一定时间返回结果，否则，系统超时出错。对于中间业务如代发工资，其帐务处理类似于批量做储蓄转帐存款交易。提交以后，占用系统资源多，造成系统尖峰时刻，对联机交易影响大。如果简单把它作为联机交易，在联机交易控制时限，不能完成事项处理。联想公司通用开发平台ACE有一项功能驱动器——虚拟柜员交易。可对中间业务批量交易进行控制。其操作方式是：批量业务提交以后，系统返回提交成功。柜员继续做其他业务。后台联机控制工具监控系统，当联机事务不多时，启动批量业务，批量业务完成后，回在提交柜员终端上提示批量交易完成，柜员是否下载批量业务结果，柜员确认后，批量业务结果下载。
7. 金融产品开发平台
7.1. 会计核心组件
会计核心组件实现系统的会计功能，在大会计、本外币联动、面向业务编程设计思想的指导下，向交易程序提供统一的帐务处理编程接口，实现会计分录的自动分解、分户帐余额、积数更新、明细帐和各类登记薄登记、产生会计记帐凭证等。
核心组件要求根据业务系统的交易情况填写会计分录表，依据交易过程的划分模式及交易定义会计分录的产生规则，核心组件依据送入接口的交易要素读取会计分录表并产生相应的会计分录和其它的帐务数据。
7.2. 凭证控制组件
从凭证的入库到最终核销，每一张凭证在系统中都要经历多种状态，存放于不同的地方，其责任人（拥有者）也各不相同，凭证控制组件向交易程序提供一组函数调用，以完成凭证管理的基本功能，包括合法性校验、出入库、上缴、领用、调拔等功能。给交易程序的编写提供强大的支持。
7.3. 金融OLTP平台产品——ACE
l 概述
联想金融平台ACE(原名LXBS)是一个面向金融OLTP系统、优秀的开发运行平台。1993年由中国银行提出需求，联想公司历时一年开发成功，并在1994年北京市计算机产品展览会上荣获金奖。
93年以来，ACE依靠其先进的技术、良好的开发环境、强大的功能，在金融行业获得巨大成功，先后被数十家银行采用，成功的运行在数千个网点上，是目前国内装机量最大的金融平台。典型的客户有：交通银行总行、建设银行总行、农业银行总行、中信实业银行总行、深圳农信社、上海农信社等。经过几年在金融领域的不断的自我完善，终于在1998年实现了ACE UNIX版的产品化，并在8月举行了产品发布会。

l ACE前台解决方案

TCP/IP
HOST
前置机
（UNIX）
终端
M
M
终端
Windows
R
M
M
R
Windows

说明：R代表Router, M代表Modem。
前台由UNIX做网点服务器，在该服务器上挂接终端和图形应用（Windows系统），完成应用。终端和图形既支持本地也支持远程。

l ACE的原理
ACE提供了一套完整的、功能强大的第四代语言，并提供了此语言的编译器和解释器，程序员用这种语言编写前台的应用程序，并用编译器将程序编译成中间代码，再由ACE解释程序来解释执行。
l ACE的特点及其功能描述
ACE不仅是一个前台产品，更采用了前后台一体化等先进的开发维护一整套技术和工程实施方案。 ACE由ACE解释器、编译器、交互式