硕士学位论文-某行自助设备跨平台应用及监控系统硕士论文.doc

硕士学位论文某行自助设备跨平台应用及监控系统摘要随着信息与网络化的快速发展，银行自助服务也随之扩大起来。同时银行的需求也发生了改变，例如将不同品牌的自助设备上所运行的程序进行整合，用以减少开发和维护成本；将自助服务渠道整合成统一的体系机构；将自助渠道变为新的赢利中心；让自助服务更为灵活方便等。根据国内银行现有的软硬件环境，项目为某行量身定制的兼容C/S模式和B/S模式的XFS跨平台自助设备解决方案。该方案，既为银行现有设备的运行提供了实际保证，保护了银行的已有投资；又满足了将来对新采购设备的支持，符合银行的发展需要。自助设备跨平台方案是在Kalignite平台的基础上设计金融应用软件，其平台是KAL公司开发的自助设备中间件产品，为目前国际上最为成熟的自助设备中间件产品之一，采用XFS-SPI接口的方式与下层硬件设备模块进行交互，通过提供ActiveX控件的方式让上层应用访问设备，实现了自助应用的硬件设备无关性，同时还可以提供完整的自助服务应用开发和运行环境。 其中的监控系统是对设备进行实时状态监控，并对各种监控数据进行分析和处理，以方便用户可以了解系统的运行情况并加以控制，例如可以快速地在各种交易渠道上发布传统的和最新的产品和服务，满足业务部门的不断创新和银行对服务空间不断延伸的需求；平滑的扩展性可以满足日益增长的渠道交易。系统不仅可以提升银行自助设备的监控管理水平、未来运行效率和盈利能力，还可以降低经营成本等需求。关键词：跨平台、自助设备管理、监控系统 AbstractWith the rapid development of information and network technology, the banks self-service also will be expanded. Bank demand has also undergone a change, for example, a program running on a different brand of self-service equipment integration to reduce development and maintenance costs; self-service channel integration into a unified system of institutions; becomes the new self-service channels profit center; make more flexible and convenient self-service. The project is based on the existing hardware and software environment for domestic banks, a line tailor custom-compatible C / S mode and B / S mode XFS cross-platform solution for self-service equipment. The program, both for the running of the Bank of existing equipment to provide real guarantees to protect the banks existing investment; meet the development needs of the future in line with the banks support for new purchases of equipment, Self-service equipment cross-platform solution is designed on the basis of the Kalignite platform of financial application software platform developed KAL equipment middleware products, is one of the most mature international Self-service equipment middleware products XFS-SPI interface way with lower hardware module to interact with the upper application to access the device by way of ActiveX controls to achieve the independence of a self-service applications, hardware devices, and also can provide a complete self-service application development and runtime environment. The project monitoring system equipment, real-time status monitoring, and a variety of monitoring data analysis and processing to facilitate the user can understand the system operation and control, for example, can be quickly released on various trading channels traditional and the latest products and services to meet the needs of the business sector innovation and banks continue to extend the service space; smooth scalability to meet growing channel for transactions. The system can not only enhance the level of monitoring and management of the Bank self-service equipment can also reduce operating costs, future operating efficiency and profitability, demand. Keywords: cross-platform 、self-service equipment 、monitoring and control system48目录摘要IAbstractII目录11.绪论21.1.课题背景21.2.研究的意义21.3.论文组织结构32.相关标准和技术介绍52.1.CEN/XFS标准52.2.J2EE技术72.3.本章小结103.需求分析113.1.系统概述113.2.主要业务需求133.3.非功能需求153.4.本章小结174.系统详细设计184.1.系统架构设计184.2.数据库设计214.3.系统功能模块设计254.4.设备监控状态采集功能设计304.5.故障处理功能设计334.6.通讯接口设计374.7.本章小结385.结论与展望395.1.系统实现及效果395.2.存在问题435.3.系统展望435.4.本章小结44参考文献45致谢471. 绪论1.1. 课题背景ATM（Automatic Teller Machine，自动柜员机），是有计算机控制的持卡人自我服务型的银行自助设备。传统的银行自助设备一般都使用专用的设备模块，依靠独立的软件进行管理，例如读卡器、密码键盘、出钞模块等都是各自独立的。在早期的自助设备上，应用软件必须运行在专用的硬件架构上，硬件生产商在提供自助设备机器的同时，还需要提供自己的操作系统和功能丰富的应用程序。随着Intel处理器的普及，金融服务行业开始广泛采用最可靠、稳定、成熟的操作系统Windows NT，并应运而生基于Windows的应用对金融设备的访问规范WOSA/XFS（Windows开放服务体系结构/金融服务扩展标准）。设备厂商只需要将自己硬件的驱动程序按照该标准设计，最终就可以将其直接连接到符合这套标准的自助设备上。 根据某行发展的情况，在自助设备应用方面，存在着数量越来越多，分布也越来越广等趋势。目前存在着NCR、Diebold、Wincor、日立等多种品牌，在设备的型号上就更加多了。由于这些设备的应用软件都是由各自的厂家提供，人工管理也就越来越耗时，越来越费力，成本也越来越高，给软件的维护和新业务的开发带来了诸多的不利影响，因此能拥有一套高效自动的自助设备跨平台应用及监控系统软件就成了某行的迫切需要。本项目针对某行业务发展的具体需求，在广泛调研国际国内同行的最新发展动向基础上，搭建了基于WOSA /XFS标准的自助设备跨平台应用，并建立了配套的高效自助设备监控系统，为自助设备提供响应及时、高开机率和低故障率的后台维护。1.2. 研究的意义随着银行金融业务的迅猛发展，自助设备以其自动化、低成本、7*24服务模式等显著优势，已逐步成为与柜面网点同等重要的新型网点。目前，国外比较知名的银行自助设备厂商有NCR、HITACHI 、DIEBOLD、SIEMENS、FUJITSU等，国内也有广电运通、东信、紫金、御银等上十家厂商。设备种类已经从传统的ATM，发展出了CDM、CDS、ASM、自动售票机、自动充值机、圈存机等，远程视频、无线通信、生物识别、手机定位等技术也在自助设备得到了广泛的应用。由于自助设备不仅结构复杂，业务流程的控制也相当精密，而且自助设备供应商各自为营，很少考虑与别的厂家相兼容，如NCR有APTRA平台，Diebold有OPTinet平台，因此就造成了银行自助设备应用多平台、互不兼容的限制。而在银行自助渠道系统建设过程中，由于过去缺乏统一规划，普遍存在重交易、轻管理的情况，导致现有监控系统，大部分都是依赖于给自助设备终端程序添加接口进行监控，这样每个自助设备程序提供商就必须为监控系统修改程序，方法复杂，并且其扩展性也差。因此，在银行实现自助设备跨平台应用的最重要的意义在于：(1) 能够统一自助设备用户界面、统一流程处理，有利于提升银行企业形象；(2) 能够统一的ATMC软件，有利于降低银行维护成本；(3) 能够根据市场变化快速推出新式自助金融产品，有利于提升银行市场竞争力。同时实现银行自助设备跨平台应用后，通过统一的监控系统直接与跨平台系统应用层交互，避免了不同厂商设备的兼容性差的问题，有效地提高了产品的扩展性，达到自助设备统一业务定义、统一监控管理、统一配置管理、统一广告管理、统一报表管理的要求。1.3. 论文组织结构系统主要是为了某行统一自助设备平台而设计，对其自有的金融自助设备软件版本进行整合，实现统一管理和业务需求的快速响应。同时提供自助设备与POS的统一接入系统，提高分行对自助设备的管理，有效减少现金自助设备的运营成本，最大程度避免厂商自助设备应用软件对银行设备采购和新业务产品发布的限制，完全实现业务功能的快速开发和自动升级等需要，并实现对自助设备运行的监控和分析，提高其实际运营能力。论文分为五部分进行讨论：第一部分阐述了研究自助设备跨平台应用与监控系统的建设背景及意义。第二部分介绍了自助设备跨平台应用及监控系统所执行的标准和采用的技术。第三部分对某行自助设备跨平台应用及监控系统进行了需求分析。第四部分详述了某行自助设备跨平台应用及监控系统的设计和实现过程。第五部分总结分析了系统的应用效果和存在的问题。2. 相关标准和技术介绍2.1. CEN/XFS标准CEN/XFS标准原称为WOSA/XFS标准，XFS标准体系结构如图2-1所示。WOSA（Windows Open System Architecture），即Windows开放式系统体系结构，是微软发起的一个旨在围绕微软的软件体系架构进行应用开发而制定的一系列行业应用标准。1998年6月，微软公司将此标准移交给非赢利的CEN（欧洲标准化组织）继续维护和发展，此后此套标准也被称为CEN/XFS。同时CEN吸纳了一批金融领域的大公司，例如NCR，DIEBOLD，WINCOR，KAL，HITACHI等，组成一个跨国技术论坛组织，共同制订、修改和发展这套标准。经过多年的发展变迁，CEN/XFS标准已经成为了国际金融行业自助设备领域的事实标准，被国内外自助设备软硬件厂商所广泛采用，各大中型商业银行以CEN/XFS标准为基础的跨平台ATMC软件也正在推广实施中。图2-1 XFS标准体系结构图WOSA/XFS的诞生是随着全球信息技术的发展和个人电脑的发展而产生的，作为与个人电脑相似的银行金融外设行业(以ATM为例)，银行也同样希望能够像个人电脑一样购买多个厂商的产品，然后组装成一台ATM机。这样一来，银行的ATM机就不会受制于某一家厂商，银行只需要ATM厂商维护各自的设备，整机可以由某个厂商维护。为了处理金融行业的软件互连问题，微软公司、几个大的金融外设厂商和几个大的银行机构在一起讨论，最终定下来了一套软件技术规范。只要任何一个厂商自己硬件的软件驱动程序符合这套规范，那么它的硬件就可以无缝连接到其他同样符合这套规范的ATM机上，而不需要做任何的软件改动。同时WOSA也规定了硬件驱动程序和ATM上层控制流程的程序之间的接口规范，从而银行可以购买非厂商提供的ATMC上层程序。CEN/XFS标准的关键部分就是定义了一套标准的API(Application Programming Interface)，及相应的SPI(Service Provider Interface)和支持服务接口，为基于Windows的应用提供对金融设备的访问。使得一个使用API与特定的SP通信的应用在SP发生变化时，而不需要做任何修改。通过规定API、消息机制、SPI、支持函数、配置函数和调用机制，以及服务的分类，使得遵循标准的不同硬件厂商，都能够无缝的接入跨平台跨厂商软件解决方案中去。从CEN/XPS标准的体系架构可看出，Windows应用通过API接口与XFS Manager进行交互，并不直接访问SP，应用程序不会像以往那样固定使用某个厂商的硬件特性。不同厂商的SP通过标准的接口反映其硬件特性，基于CEN/XFS标准的跨平台软件就可以进行自动识别处理。同时，监控系统也可以方便的通过各厂商的SP接口，获取设备各个模块的硬件详细状态。基于CEN/XFS国际标准的监控代理在不需要改造ATMC(或改造量极小)的情况下即可准确获取设备状态信息，解蔽了底层硬件的差异性，提供品牌选择的灵活性。另外，相比以往的ATMC发送状态信息的方式，基于CEN/XFS的监控方式，也大幅度减轻了ATMC的运行压力。如读卡器类，一个应用与具体的读卡器无关，从一个供应商 A 的读卡器换到另一个供应商 B 的读卡器，无需改动任何应用程序。CEN/XFS 它包含这样一些接口：(1) 开放数据库连接（ODBC）作为标准数据库存取；(2) 消息应用编程接口(MAPI)作为消息服务的存取；(3) 通讯支持，包含 WINDOWS SNA,RPC 和 SOCKETS。本系统的自助设备跨平台应用就是采用了CEN/XFS标准，通过统一的API与XPS Manager后台的监控系统完成对自助设备状态的采集以及设备操作的控制，不仅屏蔽了各厂家自助设备的硬件特性，同时也减少了平台开发的复杂性。2.2. J2EE技术J2EE(Java 2 Platform, Enterprise Edition)是由SUN公司内部开发，并由各大IT厂商共同发起，获得业界广泛认可的一个工业标准。它利用了Java2平台的技术优势，提供了开发、部署和管理的整体解决方案，具有诸如编写一次到处运行，存取数据库的JDBC、API、CORBA支持等技术特色，还提供了对业务逻辑封装的EJB（Enterprise JavaBeans）组件技术、支持HTTP访问的Servlets和JSP，以及XML的全面支持，另外它还定义了关于事务管理的JTA和JTS接口，及保证消息传递的JMS服务等。2.2.1. J2EE的组成和特性J2EE主要由组件、容器和应用程序接口与服务等三部分组成。其中：组件主要用来处理业务逻辑和表示逻辑的功能；容器主要用来为组件提供运行或生存的环境功能；应用程序接口与服务则是为客户端提供访问Web层、Web层访问业务层以及业务层访问企业信息系统层的接口、协议和服务的功能。(1) J2EE组件J2EE组件是具有独立功能的软件单元，通过面向对象的编程方法将相关的类和文件封装成J2EE应用程序，再利用其接口与其他组件进行数据交互。J2EE组件包含丰富的应用程序接口，提供标准化的程序开发功能，能容易地用于个性化业务过程的开发。组件技术使得开发人员能集中精力于开发个性化的应用程序所需的组件，提高代码重复使用率，降低程序代码编写和测试工作量，提高效率。J2EE结构减少了传统开发应用程序所需的编码和测试代码的数量和工作量。同时还提供了能把标准化的组件部署成具体应用软件的模型，提高了企业的生产效率。J2EE规范定义了以下三个组件： 应用客户端程序和Applets是客户层组件； Java Servlet和JavaServer Pages(JSP)是 web层组件； Enterprise JavaBeans(EJB)是业务层组件。(2) J2EE容器J2EE容器提供了支持可扩展的、具有标准化功能的组件技术持久环境，一些在其他模型中需要专门技术才能实现的标准化功能可以在J2EE中自动执行。J2EEgip 提供了Java编程语言中用于组件技术的标准API，为部署于容器中的组件提供一个稳定、灵活的工作环境。以下四种容器可以利用J2EE应用组件来进行安装部署： EJB 容器：所有J2EE 应用程序中企业级bean 的执行由EJB容器进行管理，在J2EE 服务器上运行Enterprise bean 和它们的容器； Web 容器：所有J2EE 应用程序中的JSP页面和Servlet组件的执行由WEB容器来进行管理，在J2EE 服务器上运行Web 组件和它们的容器。 应用程序客户端容器：所有J2EE应用程序中应用程序客户端组件的执行由应用程序客户端容器进行管理，在J2EE服务器上运行应用程序客户端组件和它们的容器； Applet 容器：是运行在客户端机器上的web浏览器和 Java 插件的结合。(3) J2EE服务容器的设置定制了J2EE服务器所提供的内在支持，包括安全、事务管理、JNDI(Java Naming and Directory Interfke)寻址、远程连接等服务，下面只列出J2EE几种重要的服务： J2EE Security Model(安全模型) J2EE Transaction Management Model (事务管理模型) JNDI Lookup Server(寻址服务) J2EE Remote Client Connectivity Model( 远程连接模型) Life Cycle Management Model(生存周期管理模型) Database Connection Pooling Model(数据库连接池模型)2.2.2. J2EE体系结构J2EE应用按照逻辑功能的不同可以被分成不同的组件，这些组件可以在相同或不同的服务器上安装。根据应用组件在多层J2EE应用环境中所处的层次决定一个应用被安排在什么地方。J2EE体系结构如图2-2所示。图2-2 J2EE四层结构(1) 客户层(Client Tier)客户层主要用来实现向用户展示信息，并接受终端用户输入的信息，同时将接收到的数据向Web层或业务层进行传递。在一个基于Web的J2EE应用程序中，用户的浏览器是在客户层中运行的，浏览器会从Web服务器上下载在Web层中生成的静态HTML页面，而动态HTML页面则由JSP文件或Java Servlets生成。(2) Web层在Web层上使用Java Servlet和JSP技术接收从HTML端、Applet、XML文档采集的信息，并将其发送到业务层，再由Enterprise Beans对接收的数据进行处理，同时接收由业务层返回的处理结果，对客户层做出相应的响应，因此，Web层在一个在系统中起承上启下的作用。(3) 业务层也称EJB层，是由EJB组件组成，其作用主要是用来处理个性化的业务逻辑。一个Enterprise Beans从客户层或Web层接收数据，对数据进行处理，再将数据发送到企业信息系统层进行存储。(4) 企业信息系统层企业信息系统层是指提供企业信息系统运行的环境平台，包括企业基础业务系统、数据库系统等，存储企业需要的大量数据等。本系统选用环境为标准的J2EE体系架构，开发语言为JAVA/JSP，使用框架为Spring，数据访问为Hibernate/JDBC，开发工具为Eclipse。通过WEB SERVER来负责整个自助设备应用的运行，如页面切换，客户输入的响应，及交易报文的组织和收发等。2.3. 本章小结本章主要介绍某行自助设备跨平台应用及监控系统采用的相关标准和技术，主要包括 WOSA 及 CEN/XFS 标准、J2EE技术。首先CEN/XFS 标准是某行自助设备跨平台应用重要的标准依据，只有所有设备都支持该标准的前提下，整个系统才有实现的可能。而某行的监控系统有很强的实时性和分布式的要求，并需要进行跨平台部署，因此采用J2EE技术开发。3. 需求分析3.1. 系统概述3.1.1. 总体业务描述某行随着自身业务的不断发展，现在已经拥有了几千台ATM设备，并且因为市场的需求，该数目还将继续增长。根据业务的发展需要对全行的自助设备进行整合，提升对自助设备的管理水平，提高自助设备的使用效益，降低自助业务的管理成本，并建立对ATM等自助设备故障报修的快速反应机制。因此该行急需为管理、操作人员提供一套全新的自助设备跨平台应用及监控系统，方便银行对自助设备进行高效的管理和维护，从而在激烈的银行业竞争中占得先机。根据要求，系统需要以网络为依托，以银行前置账务系统为基础，向银行管理人员、设备操作人员和维护服务人员等提供符合安全标准的自助设备监控管理功能，统一完成远程监视、远程控制、版本分发、版本控制、故障处理等功能,实现集中监控远程的ATM，对远程ATM机器上的软件升级和软件维护。3.1.2. 自助设备运营管理模式某行的自助设备运营管理模式为总分行形式，自助设备管理机构层次如图3-1所示，从上至下涉及总行、分行等各级机构，自助设备分布在各个银行网点，由设备监控员负责设备日常维护工作，总行管理员和分行管理员实施逐级业务管理，其各个角色及职能如下描述：(1) 系统管理员：角色定义、参数设定、人员管理、设备管理、维护商管理；(2) 设备监控员：设备状态监控、设备远程管理、设备故障处理、业务报表；(3) 总行版本管理员：工程管理、版本管理、版本发布；(4) 总行版本审核员：版本审核；(5) 分行版本下发员：执行版本下发。图3-1 自助设备管理机构层次图3.1.3. 系统建设原则建设系统时要遵循规范化、标准化原则，使系统设计保证具有较高的可靠性，同时，为避免重复开发和投资，在该系统建设的过程中，需要遵循了以下实施原则：(1) 结构清晰要求系统整体结构清晰，平台化原则明确，平台内部也是模块化程度高，而平台之间及模块之间耦合程度均较低。系统为组件化设计，并将组件进行分级处理，以便根据实际需要选用。比如需要提供初始化读卡器设备的组件，可以不同的需要选用对某个设备进行初始化，也可以对所有设备进行初始化。此外通过配置参数化的方式来灵活的满足各种不同设备的差异，各分行不同的中间业务需求，及凭条格式等，尤其是对管理员部分功能，都可以通过参数化进行配置，使得可以满足不同分行日常管理的细微需求差别。(2) 基础坚实要求系统符合XFS3.0标准，并随着标准的发展而能不断发展，完全能够满足国际自助设备发展的趋势，现阶段需要完全包含本行所有的主要设备，并通过图形化工具保证业务功能的不断扩充和更新，完全可以满足银行未来业务发展的需要。(3) 互联互通系统可以稳定运行在Windows各种版本平台上，并支持包括XML、8583等多种报文格式，可以通过快速开发满足与银行其他平台的结合。(4) 稳定可靠需要采用了国际标准的开发语言和工具，如XML、VBScript、HTML等，使得系统在安全上具有极高的可靠性，整体性能经受了各种恶劣条件的考验。(5) 运行快捷要求系统发送命令给设备和系统对设备返回信息的处理迅速，必须在3秒范围内，不存在不同厂商设备上运行速度的差异。(6) 使用简便系统中客户交易画面和管理员维护画面都界面清晰，操作简单。其中客户进入的交易操作画面均为客户最经常使用的交易菜单，并且有详细的相关操作，安全防范及注意事项等提示；在管理员操作界面上，所有机型均为同样的操作界面，并且管理员日常清机和加钞操作安排在管理员最方便操作的位置，使得管理员可以用最少的时间完成日常工作，极大地减少了管理员的工作量。同时清机时可以在凭条上打印对账信息，在屏幕上显示对账信息，打印日志流水打印清晰紧凑等，都可以最大程度的降低银行清机对账和处理可疑交易的时间。(7) 体现个性可通过功能列表的方式，银行指定每台设备开放的所有业务功能，同时还可以指定每台设备对每种卡开放的所有业务功能，因此不同的客户在同样的设备上就可能会有不同的操作界面，同样的客户在不同的设备上也可能会有不同的操作界面，并提供诸如生日祝贺、还贷提醒、车贷促销及自助抽奖等不同的特色服务。3.2. 主要业务需求3.2.1. 设备故障处理业务银行ATM监控管理将所有需要跟踪的记录统称为CASE（事件），CASE中主要关于设备故障是由系统自动生成或手动生成包括设备缺纸、缺钞或者硬件故障等。故障处理是当系统检测到故障时，系统将CASE生成短信发送到设备监控员的手机上，并跟踪该CASE是否已经解决，如果没有，根据设置的CASE升级规则来发送上报短信，CASE处理流程如图3-2所示：图3-2 CASE处理流程图3.2.2. 版本控制业务版本控制功能主要接收版本文件和广告来的文件下发任务。版本文件下发控制的流程如图3-3所示，由总行版本管理员上传已经制作好的ATMC应用、病毒升级、SP升级版本文件，将这些制作成标准的ZIP文件上传到服务器，经过总行版本审核员进行审核后，就可以下发到分行，分行的版本下发员通过对目标ATM自助设备下达控制指令和更新控制，实现版本的文件下发和版本的更新。图片、视频广告主要是指ATMC端的交易等待和交易时的播放的广告，可以根据不同的时间、日期来设定播放不同的广告，同时广告内容也可以随意下发新的广告进行替换。对于图片和视频广告每次可以添加多个附件，对于不同的附件可以设定不同的播放时间区间，同时也可以设定播放日期为永久或临时，永久日期段为0000-00-00到9999-99-99日期段，而临时日期段为用户指定的日期段，一旦ATMC端系统日期不在这个区间内，则不播放该广告，当下次下发广告的时候会自动将该广告自动摘除。图3-3 版本下发控制流程图3.3. 非功能需求3.3.1. 时间特性要求根据系统设备规模角度，要求系统后台实时状态监控能力为3000台*4个报文/5分钟（状态报告、运行状态报告、故障报告、版本签到报文），以满足大规模自助设备监控需求；要求故障处理能力为3000台*2个Case生成/5分钟；后台报表处理能力为日报生成最大耗时小于30分钟，月报/季报生成最大耗时小于10分钟；版本下发能力为单台ATM设备下载100M文件最大耗时小于60分钟（网路速度达到100k/s的最低条件），多台ATM设备批量1000台*10m最大耗时10小时；业务管理网站需要支持500个以上web用户的并发访问，报表请求最大响应时间10s，文件下载最大响应时间10s，其他请求最大响应时间5s。3.3.2. 安全性要求1) 客户端安全：需要对客户端运行的相关文件都进行了加密处理，以防止被恶意篡改，一旦发现解密失败或者MAC校验不对，则会停止对外服务。2) 数据存储传输安全：需要对存储在本地的数据需采用了多次加密和MAC校验的方式进行验证，并需要封闭与交易无关的所有端口及相关服务等，保证系统数据存储和传输的安全。3) 客户信息安全：需要采用主密钥和工作密钥硬加密、隐蔽卡磁道信息、隐性输入密码的方式等，确保客户输入的原始密码串和卡磁道信息安全。4) 客户身份认证安全：需要完全支持明码小键盘、8字节单DES硬件加密小键盘、16字节3DES硬件加密小键盘，以保证客户身份认证的安全可靠。5) 提供客户交易的数据保密性，数据完整性以及交易的不可否认性6) ATM内控管理安全要求：至少需要设置清机管理员、厂商维护员、行内科技管理员三个角色，对各角色的操作进行必要密码保护，不能交叉操作。7) 提供B/S模式的安全服务验证技术，杜绝非法的WSAP SERVICE调用，确保系统不会因页面篡改、非法测试应用造成的现金风险。3.3.3. 可靠性要求系统要求必须具备高可靠性，提供7*24小时不间断运行服务，使系统在运行过程中不发生或极少发生故障。系统有任务处理模块，可以实时监控系统的运行，控制出问题的进程重新启动，并对相应的问题提供报警。在偶发事故或操作失误情况下，系统必须提供正确及时的错误提示，并能自我恢复，不应出现系统死锁或信息丢失的现象。而对于可能的停电、意外死机、网络故障等异常极端情况，要求有完善的处理机制，避免数据的丢失。3.3.4. 可维护性要求系统的所有程序都是模块化开发，可以灵活方便的增加、拆卸、组合功能模块，系统运行环境、运行参数可配置完成，并提供系统完善的技术和操作文档。系统的LOG分多个级别，可以由操作人员控制对系统运行记录的详细情况，方便对问题的查找。3.4. 本章小结本章对某行自助设备跨平台应用及监控系统进行了详细的需求分析。首先通过对整个某行自助设备运营的总体业务、管理模式进行了简要介绍，并阐述了系统建设的基本原则。同时，说明了自助设备跨平台应用及监控系统的设备监控、远程管理、故障处理、版本控制、业务报表和系统管理功能需求，详细分析了故障处理和版本下发的具体流程。最后，对系统时间特性、安全性、可靠性、可维护性等非功能需求进行简要描述。4. 系统详细设计4.1. 系统架构设计4.1.1. 网络架构设计本系统监控对象为自助设备，与监控范围内的ATM及ATMP、短信平台通过TCP/IP协议进行SOCKET通信，管理台及监控台通过HTTP协议登陆本系统，系统网络架构设计的指导思想：(1) 实用性，采用的网络技术和硬、软件产品要满足本项目信息传输和管理的需要，要考虑项目的具体特点和环境；(2) 共享性，通过网络，可以在不同的地方，利用不同的PC和通信设备进行信息的共享和数据的处理；(3) 可扩展性，指满足银行将来业务快速发展的需要，保护投资，以及将来系统升级的需要。系统服务部署在银行总部，通过内网完成自助终端之的网络通道连接，系统应用网络结构如图4-1所示。对于网络可靠性，要求骨干设备应具有很高的容错能力，配备冗余电源，所有的设备接口模块可以进行热插拔更换，网络设备和线路应有冗余考虑。(1) 数据库服务器：主要是存放自助终端的交易数据与状态数据、各种管理与系统配置数据、各类业务统计分析数据等。(2) 应用服务器：主要是负责系统后台程序处理，包括控制中心、数据采集、后台任务、数据库代理等功能。控制中心功能首先实现接收及解释自助设备的状态信息，跟踪和管理每个故障的生命周期，自动上报未按时解决的问题等故障自动跟踪处理功能。后台任务功能将采集的设备交易和状态数据，经分析整理后存储到应用数据库。(3) WEB服务器：主要是用来提供监控管理、远程分发管理和统计分析的操作入口和展现，实现业务管理。分行、支行、网点的监控管理员通过浏览器登录网站，实现监控管理、远程控制等操作。图4-1 系统网络架构图(4) 短信服务器：主要是包含SMS-Modem和SMS应用软件及SMS开发接口的短信网关，结合系统实现CASE通知、催办提醒等。(5) 版本服务器：主要是提供自助设备客户端发布的版本文件和广告文件上传、发布，控制自助终端自动下载更新系统版本、广告等信息。(6) ATMP:安装在ATM主机上的一个客户端代理小程序，接收来自远程管理服务器的远程管理与控制指令，与ATM进行交互，实现远程管理:根据远程管理指令实现关闭和重启ATMC服务，重新启动ATM机;负责在底层软件版本升级，广告媒体文件的更新。服务器运行的硬件环境：IBM P550小型机（64位硬件环境，8CPU，64G内存）作为数据库服务器和备份应用服务器，IBM P520小型机（64位硬件环境，4CPU，32G内存）为主应用服务器；，IBM DS4700磁盘阵列（容量2TB）作为系统存储设备，TS3100磁带库作为系统的备份系统。软件环境：AIX 64位UNIX服务器，WEB SPHERE应用服务器，DB2数据库。4.1.2. 软件架构设计自助设备跨平台应用及监控系统采用了三层架构，如图4-2所示，主要包括用户层、业务层和数据层。用户层提供人机界面，主要包括自助设备跨平台应用客户端（ATM）和浏览器用户客户端（IE），实现业务交互。业务层是系统的核心功能实现和提供的地方，包括设备监控、远程管理、故障处理、版本控制、业务报表、系统管理等功能。数据层是系统数据提供和保存的地方，包括关系数据库、数据文件、I/O 接口、数据存储等。图4-2 系统软件架构ATM与业务层采用TCP/IP协议进行通信，实现自助设备状态信息和运行数据的交互，完成客户的业务显示和交互。同时用户还可以通过浏览器发出请求，通过Web服务响应各种请求并传递事务处理给应用层进行逻辑处理，并由应用层对数据层进行数据存取和处理，获取所需数据后回传给客户端，最终显示在客户端的浏览器中。业务层接收从客户端采集的用户请求，将其转化为业务逻辑过程中能够理解的信息，同时根据指定的业务逻辑有序地向数据层发送数据请求，并将数据层返回的数据解释、组合成用户所需要的信息，返回到客户端，这是整个系统中业务逻辑实现和处理的核心。由于业务层将业务规则定义、数据访问服务、合法性判定等服务进行构件封装，客户端不需要直接访问数据库，这样使自助设备监控系统的开发人员可以把工作重心放在业务规则的定义上，使系统结构更加清晰。系统各层都具有独立的软硬件支撑、稳定结构、相互之间为低耦合关系，确保了系统架构的稳定、各平台的兼容和业务功能的可扩展性。4.2. 数据库设计4.2.1. 数据库设计要求系统数据库设计的目标是建立一个合适的数据模型，为提高自助设备跨平台应用及监控系统的开发效率和运行效果，针对某行具体的业务特点，因此在数据库设计上要做到：(1) 要求数据库层次分明，自下而上将数据信息逐层浓缩、归纳、合并，有效的控制数据冗余，提高数据共享程度和数据库性能；(2) 要求规范化结构化数据库设计，确保统一的数据格式和编码，并应尽量减少不同组件间所对应的数据库表之间的关联，确保各组件对应表之间的独立性；(3) 要求数据库数据应具有独立性，独立于应用层，使数据库的设计及其结构的变化不影响应用层，同时考虑数据库的扩展性，在增加新的功能需求时，不发生对整个数据库系统进行重新设计；(4) 要求保证数据库的一致性和完整性，应根据系统操作的类型、频度加以均衡考虑数据的规则和约束，合理建立公共数据库，应用数据库分层管理，注意并发存取数据时没有数据冲突。(5) 要求设计出的表要尽可能减少数据冗余，确保数据的准确性，有助于提高数据库的性能，同时应考虑为提高系统可靠性进行的数据备份机制。(6) 要求对数据库访问进行授权设计，确保数据访问的安全可靠。4.2.2. 数据库结构设计数据库的结构设计是将需求分析得到的用户需求转化为信息结构，是数据库设计的关键。概念结构是各种数据模型的共同基础，它比数据模型更独立于机器、更抽象，从而更加稳定。属性是实体所拥有的某一方面的特性。实体和实体之间的关系有一对一关系、多对多的关系、多对一的关系。系统中关键表的实体关系如图5-1所示：图4-3 实体关系图4.2.3. 数据库实现数据库设计过程中需要对时间效率、空间效率、维护代价和各种用户要求进行权衡，其结果可以产生多种方案，数据库设计人员需要对这些方案进行详实的评价，从中选择一个较优的方案作为数据库的物理结构。由于本系统的数据库表比较多，下面只列出版本控制中数据库表的实现：表4-1 作业信息(RVC_ JOBINFO)字段名称含义类型长度是否可以为空是否主键SerialNo作业编号char15NYDescription作业描述varchar200Ytype作业类型char1Ncycls作业周期char1NstartDate启动日期DateYstartTime启动时间dateTimeYstatus作业状态char1N表4-2 作业管理日志表(RVC_JOBMANAGER)字段名称含义类型长度是否可以为空是否主键operateId操作IDchar15NYjobSerialNo作业号char15Noperate操作内容char1Noperator操作人char20NoperateTime操作时间DataTimeNapprover批准人char20approveTime批准时间DateTime表4-3 任务信息表（RVC_TASKINFO）字段名称含义类型长度是否可以为空是否主键JobSerialNo作业编号Char15NYTaskSerialNo任务编号Char15NYDescription任务描述Varchar200ReferenceNo任务检索编号Char15NType任务类型Char1NStatus任务状态Char1NStatusDescripe状态原因描述char100StartTime启动时间DateTime表4-4 (版本更新)任务表(RVC_VERSIONTASKINFO)字段名称含义类型长度是否可以为空是否主键TaskSerialNo所属任务Char15NYTerminate终端号Char15Project工程名称Char15CurVersion当前版本Char10TargetVersion目标版本Char10Status当前状态Char1NoticeTimes通知次数IntYDownloadTimes下载次数IntYaverageFlow平均流量IntY表4-5 版本信息表（RVC_VERSIONINFO）字段名称含义类型长度是否可以为空是否主键ProjectID工程IDchar15NYSubVersion子版本号char10NYpreversion上一版本号Char 10Ncurrentstatus当前状态char10Ndate添加日期DateTime10Ntime添加时间DateTime10Nuseid添加人员char32N表4-6 版本包含文件信息表（RVC_VERSIONFILES）字段名称含义类型长度是否可以为空是否主键ProjectID工程IDchar15NYSubVersion子版本号char10NYFileSerialNo文件序号intNYFilePath上一版本号Char 10N表4-7 工程信息表(RVC_PROJECTINFO)字段名称含义类型长度是否可以为空是否主键ProjectID编号char15NYProjName工程名称char60NYTime添加日期char10NUseid添加人员char32N表4-8 版本控制记录信息表字段名称