_基于MVC设计模式的银行应用系统.doc

第一章 引　言 1.1银行核心系统的现状 随着Internet和电子商务的迅速发展，当今金融企业传统的经营模式正面临巨大的挑战。金融产品和服务渠道的多样化，已经成为金融企业核心竞争力的所在，成为各企业间竞相比拼的内容。传统服务渠道逻辑分离的金融系统正在变得越来越过时，这种模式的系统每种服务渠道都各有一套自己的数据格式、通讯方式和应用逻辑，实现业务时的业务流程以及对银行核心数据的访问都是由渠道自己负责的，对于银行业来讲，银行柜面业务有柜面业务的服务渠道，网上银行有网上银行的服务渠道，网上银行的数据格式、交易流程与柜面业务的处理毫无关系。凡此种种，在迅猛发展的电子商务新的竞争环境下，构架新一代银行的应用服务平台实为大势所趋。 1.2传统系统存在的问题 可复用能力低，可维护性差：集中表现在不支持多种服务形式(例如银行的柜面业务、网上银行、自助银行、电话银行等等)共享相同的业务逻辑。一般来讲，金融企业的同一种业务往往具有多种服务形式，而且，这些服务形式所涉及到的业务逻辑是类似的。比如银行业的同样一笔转账业务，在柜台、网上银行、ATM、或者电话银行都能办理，在这几种转账的表现形式中，基本业务流程如查询客户资料、检查密码、检查客户余额、登记交易流水等是完全一样的，但由于传统的银行系统中各种服务渠道逻辑上是分离的，以往的开发不得不针对柜台、网上银行、ATM、电话银行分别开发各自的交易流程，而且不得不与各种不同的通讯方式打交道，带来的不良后果就是系统的可复用能力低，可维护性差。 (1)不能实现快速的新产品研发和推广：传统系统的升级和换代必将涉及到现有的各种服务渠道的改造，使得新产品研发和推广周期较长。 (2)不能有效对客户行为进行分析：企业来说，有些客户的行为能为企业带来效益，有些却不能。对客户行为进行分析以获取客户资源信息是非常重要的。但服务渠道的分离却使的客户行为数据存储分散而且格式各异，传统系统在全面采集客户数据上显得十分不便。 (3)增加新服务渠道的成本急速上升：IBM的一项研究项目表明，渠道分离的商业系统，随着服务渠道的增加，系统需要的费用急速上升，尤其在银行业，其特征十分明显。 1.3本项目的工作内容 解决以上问题势必需要对传统的金融系统进行改造。将金融系统的各种接入渠道视为不同的表现逻辑，将表现逻辑与核心的业务逻辑分开，提高系统的复用性是改造的重点。这就需要在表现逻辑和业务逻辑之间增加第二层，即应用服务器层(Application Server)，以实现表现逻辑和核心业务逻辑的隔离，并实现共享业务逻辑。以开放标准的角度衡量，以SUN公司为代表的J2EE企业级应用架构成了必然的选择。 正是在这样的背景下，开始了对金融行业应用服务器开发框架的研究。整个系统的模型如图所示： 　　 图1.1 银行核心应用框图 整个系统构架在应用服务器之上，从功能上分为了表现逻辑和业务逻辑两大层面。 从整体上看，整个系统由三个层次的模块构建而成。底层公用构件库提供了系统的底层支撑环境，工具箱提供了可视化的开发、维护、发布等的集成环境，顶层的应用服务为实际应用系统的运行提供了支撑。 交易引擎：一套成熟的金融企业应用系统，其中许多交易具有相似或相同的处理模式及流程。这些相同或相似的处理模式可以被提取出来作为公共对象，以便在开发新的相同或系统维护时重用。但是，不同的系统又各有特点，因此又不可能找到一种一劳永逸的方法将所有交易都加以相同的实现。为了最大程度的方便应用系统的开发，减轻开发人员的工作量，同时又不丧失应用系统应有的灵活性，需要一种能兼顾两方面要求的基本系统，使得二次开发人员可以在基本系统上进行最小工作量的开发。 为满足上述要求，必须遵循两个原则：第一，系统中必须有足够的通用组件供二次开发人员使用；第二，系统必须保证对特定交易实现的灵活性。 平台的最大特点是把业务逻辑处理部分独立出来，使之和具体的协议无关，程序员几乎可以把全部的注意力放在业务逻辑的实现上，同时降低了对程序员水平的要求，只要懂得基本的JAVA和SQL语言就以很好地并且规范地完成业务逻辑处理部分的工作。 银行接入引擎：它是实现接入渠道整合的重要功能部件，其基本功能是汇聚各式各样的前端系统，抽取这些系统中传输来的业务数据，实现数据的格式变换，并将数据转发给指定的处理单元。接入引擎隐藏了各种系统在表现逻辑上的差异，为实现商业核心业务逻辑与各种表现逻辑分离奠定了基础。作为一个灵活的接入渠道整合平台，就在尽量不改变现有应用程序应用逻辑的条件下实现不同类型应用系统的数据交换，不但完全满足现有传统业务的要求，也能适应电子商务发展的要求。 本文共分为五个章节，本章从剖析传统的银行核心系统入手，分析了现有的系统对新应用开发的不足，简介了本文的现实意义；第二章“MVC开发模式及J2EE框架”，简