5_基于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框架”，简单介绍了J2EE企业应用框架的规范及MVC开发模式的基本思想；第三章“银行核心业务系统的实现”，论述了N层次模型的银行核心系统框架下每层的角色及功能，并简单介绍了整个项目的规划，详述了MVC模式的核心系统的实现方法；第四章“储蓄业务系统”，以储蓄业务系统为例，介绍了在以上的银行核心系统框架下的具体应用开发的流程；最后一章“总结”将新旧系统进行了对比，搜集了用户的反馈意见，对系统的不足之处进行了分析，并对未来的工作进行了展望，具体详细内容请阅相应章节。第二章 MVC开发模式及J2EE框架2.1 MVC开发模式模型视图控制器（Model-View-Controller）是XeroxPARC在八十年代为编程语言Smalltalk80发明的一种软件设计模式，至今已被广泛使用。最近几年被推荐为Sun公司J2EE平台的设计模式，受到越来越多的开发者的欢迎。模型视图控制器模式是一个有用的工具箱，它有很多好处，但也有一些缺点。2.1.1MVC如何工作MVC是一个设计模式，它强制性的使应用程序的输入、处理和输出分开。使用MVC应用程序被分成三个核心部件：模型、视图、控制器。它们各自处理自己的任务。1、视图视图是用户看到并与之交互的界面。对老式的Web应用程序来说，视图就是由HTML元素组成的界面，在新式的Web应用程序中，HTML依旧在视图中扮演着重要的角色，但一些新的技术已层出不穷，它们包括MacromediaFlash以及诸如XHTML，XML/XSL，WML等一些标识语言和Web services等。如何处理应用程序的界面变得越来越有挑战性。MVC一个大的好处是它能为你的应用程序处理很多不同的视图。在视图中其实没有真正的处理发生，不管这些数据是联机存储的还是一个雇员列表，作为视图来讲，它只是作为一种输出数据并允许用户操纵的方式。2、模型模型表示企业数据和业务规则。在MVC的三个部件中，模型拥有最多的处理任务。例如它可能用象EJBs这样的构件对象来处理数据库。被模型返回的数据是中立的，就是说模型与数据格式无关，这样一个模型能为多个视图提供数据。由于应用于模型的代码只需写一次就可以被多个视图重用，所以减少了代码的重复性。3、控制器控制器接受用户的输入并调用模型和视图去完成用户的需求。所以当单击Web页面中的超链接和发送HTML表单时，控制器本身不输出任何东西和做任何处理。它只是接收请求并决定调用哪个模型构件去处理请求，然后用确定用哪个视图来显示模型处理返回的数据。现在总结一下MVC的处理过程，首先控制器接收用户的请求，并决定应该调用哪个模型来进行处理，然后模型用业务逻辑来处理用户的请求并返回数据，最后控制器用相应的视图格式化模型返回的数据，并通过表示层呈现给用户。2.1.2为什么要使用 MVC大部分Web应用程序都是用像ASP，PHP这样的过程化语言来创建的。它们将像数据库查询语句这样的数据层代码和像HTML这样的表示层代码混在一起。经验比较丰富的开发者会将数据从表示层分离开来，但这通常不是很容易做到的，它需要精心的计划和不断的尝试。MVC从根本上强制性的将它们分开。尽管构造MVC应用程序需要一些额外的工作，但是它带来的好处是无庸质疑的。首先，最重要的一点是多个视图能共享一个模型，现在需要用越来越多的方式来访问你的应用程序。对此，其中一个解决之道是使用MVC，无论你的用户想要Flash界面或是 WAP 界面；用一个模型就能处理它们。由于你已经将数据和业务规则从表示层分开，所以你可以最大化的重用你的代码了。由于模型返回的数据没有进行格式化，所以同样的构件能被不同界面使用。例如，很多数据可能用HTML来表示，但是它们也有可能要用Macromedia Flash和WAP来表示。模型也有状态管理和数据持久性处理的功能，例如，基于会话的购物车和电子商务过程也能被Flash网站或者无线联网的应用程序所重用。因为模型是自包含的，并且与控制器和视图相分离，所以很容易改变你的应用程序的数据层和业务规则。如果你想把你的数据库从MySQL移植到Oracle，或者改变你的基于RDBMS数据源到LDAP，只需改变你的模型即可。一旦你正确的实现了模型，不管你的数据来自数据库或是LDAP服务器，视图将会正确的显示它们。由于运用MVC的应用程序的三个部件是相互对立，改变其中一个不会影响其它两个，所以依据这种设计思想你能构造良好的松偶合的构件。另外，控制器的也提供了一个好处，就是可以使用控制器来联接不同的模型和视图去完成用户的需求，这样控制器可以为构造应用程序提供强有力的手段。给定一些可重用的模型和视图，控制器可以根据用户的需求选择模型进行处理，然后选择视图将处理结果显示给用户。2.1.3MVC的缺点MVC的缺点是由于它没有明确的定义，所以完全理解MVC并不是很容易。使用MVC需要精心的计划，由于它的内部原理比较复杂，所以需要花费一些时间去思考。需要花费相当可观的时间去考虑如何将MVC运用到应用程序，由于模型和视图要严格的分离，也给调试应用程序到来了一定的困难。每个构件在使用之前都需要经过彻底的测试。一旦构件经过了测试，就可以毫无顾忌的重用它们了。由于将一个应用程序分成了三个部件，所以使用MVC同时也意味着将要管理比以前更多的文件，这一点是显而易见的。这样好像工作量增加了，但是这比起它所能带来的好处是不值一提。MVC并不适合小型甚至中等规模的应用程序，花费大量时间将MVC应用到规模并不是很大的应用程序通常会得不偿失。2.2JAVA 2企业版应用框架2.2.1J2EE的概念目前，Java 2平台有3个版本，它们是适用于小型设备和智能卡的Java 2平台Micro版（Java 2 Platform Micro Edition，J2ME）、适用于桌面系统的Java 2平台标准版（Java 2 Platform Standard Edition，J2SE）、适用于创建服务器应用程序和服务的Java 2平台企业版（Java 2 Platform Enterprise Edition，J2EE）。J2EE是一种利用Java 2平台来简化企业解决方案的开发、部署和管理相关的复杂问题的体系结构。J2EE技术的基础就是核心Java平台或Java 2平台的标准版，其最终目的就是成为一个能够使企业开发者大幅缩短投放市场时间的体系结构。 J2EE体系结构提供中间层集成框架用来满足无需太多费用而又需要高可用性、高可靠性以及可扩展性的应用的需求。通过提供统一的开发平台，J2EE降低了开发多层应用的费用和复杂性，同时提供对现有应用程序集成强有力支持，完全支持Enterprise Java Beans，有良好的向导支持打包和部署应用，添加目录支持，增强了安全机制，提高了性能。2.2.2J2EE的优势J2EE为搭建具有可伸缩性、灵活性、易维护性的商务系统提供了良好的机制:保留现存的IT资产: 由于企业必须适应新的商业需求，利用已有的企业信息系统方面的投资，而不是重新制定全盘方案就变得很重要。这样，一个以渐进的（而不是激进的，全盘否定的）方式建立在已有系统之上的服务器端平台机制是公司所需求的。J2EE架构可以充分利用用户原有的投资。高效的开发: J2EE允许公司把一些通用的、很繁琐的服务端任务交给中间件供应商去完成。这样开发人员可以集中精力在如何创建商业逻辑上，相应地缩短了开发时间。高级中间件供应商提供以下这些复杂的中间件服务: 状态管理服务 - 让开发人员写更少的代码，不用关心如何管理状态，这样能够更快地完成程序开发。 持续性服务 - 让开发人员不用对数据访问逻辑进行编码就能编写应用程序，能生成更轻巧，与数据库无关的应用程序，这种应用程序更易于开发与维护。 分布式共享数据对象CACHE服务 - 让开发人员编制高性能的系统，极大提高整体部署的伸缩性。 支持异构环境: J2EE能够开发部署在异构环境中的可移植程序。基于J2EE的应用程序不依赖任何特定操作系统、中间件、硬件。因此设计合理的基于J2EE的程序只需开发一次就可部署到各种平台。这在典型的异构企业计算环境中是十分关键的。J2EE标准也允许客户订购与J2EE兼容的第三方的现成的组件，把他们部署到异构环境中，节省了由自己制订整个方案所需的费用。 可伸缩性: 企业必须要选择一种服务器端平台，这种平台应能提供极佳的可伸缩性去满足那些在他们系统上进行商业运作的大批新客户。基于J2EE平台的应用程序可被部署到各种操作系统上。例如可被部署到高端UNIX与大型机系统，J2EE领域的供应商提供了更为广泛的负载平衡策略。能消除系统中的瓶颈，允许多台服务器集成部署。稳定的可用性: 一个服务器端平台必须能全天候运转以满足公司客户、合作伙伴的需要。因为INTERNET是全球化的、无处不在的，即使在夜间按计划停机也可能造成严重损失。若是意外停机，那会有灾难性后果。J2EE部署到可靠的操作环境中，他们支持长期的可用性。2.2.3J2EE 的四层模型J2EE使用多层的分布式应用模型，应用逻辑按功能划分为组件，各个应用组件根据他们所在的层分布在不同的机器上。事实上，sun设计J2EE的初衷正是为了解决两层模式(client/server)的弊端，在传统模式中，客户端担当了过多的角色而显得臃肿，在这种模式中，第一次部署的时候比较容易，但难于升级或改进，可伸展性也不理想，而且经常基于某种专有的协议通常是某种数据库协议。它使得重用业务逻辑和界面逻辑非常困难。现在J2EE 的多层企业级应用模型将两层化模型中的不同层面切分成许多层。一个多层化应用能够为不同的每种服务提供一个独立的层，以下是 J2EE 典型的四层结构:运行在客户端机器上的客户层组件运行在J2EE服务器上的Web层组件运行在J2EE服务器上的业务逻辑层组件 运行在EIS服务器上的企业信息系统(Enterprise information system)层软件 图2. 1 J2EE四层模型 2.2.4J2EE 的结构这种基于组件，具有平台无关性的J2EE 结构使得J2EE 程序的编写十分简单，因为业务逻辑被封装成可复用的组件，并且J2EE 服务器以容器的形式为所有的组件类型提供后台服务. 因为不用自己开发这种服务, 所以可以集中精力解决手头的业务问题。容器和服务容器设置定制了J2EE服务器所提供得内在支持，包括安全，事务管理，JNDI(Java Naming and Directory Interface)寻址,远程连接等服务，以下列出最重要的几种服务：J2EE安全(Security)模型可以配置 web 组件或enterprise bean ,这样只有被授权的用户才能访问系统资源。每一客户属于一个特别的角色，而每个角色只允许激活特定的方法。在enterprise bean的布置描述中声明角色和可被激活的方法。由于这种声明性的方法，你不必编写加强安全性的规则。 J2EE 事务管理（Transaction Management）模型指定组成一个事务中所有方法间的关系，这样一个事务中的所有方法被当成一个单一的单元。当客户端激活一个enterprise bean中的方法，容器介入一管理事务。因有容器管理事务，在enterprise bean中不必对事务的边界进行编码。 JNDI 寻址(JNDI Lookup)服务向企业内的多重名字和目录服务提供了一个统一的接口,这样应用程序组件可以访问名字和目录服务。J2EE远程连接（Remote Client Connectivity）模型管理客户端和enterprise bean间的低层交互. 当一个enterprise bean创建后, 一个客户端可以调用它的方法就象它和客户端位于同一虚拟机上一样。生存周期管理（Life Cycle Management）模型管理enterprise bean的创建和移除,一个enterprise bean在其生存周期中将会历经几种状态。容器创建enterprise bean，并在可用实例池与活动状态中移动他，而最终将其从容器中移除。即使可以调用enterprise bean的create及remove方法，容器也将会在后台执行这些任务。 数据库连接池（Database Connection Pooling）模型是一个有价值的资源。获取数据库连接是一项耗时的工作，而且连接数非常有限。容器通过管理连接池来缓和这些问题。enterprise bean可从池中迅速获取连接。在bean释放连接之可为其他bean使用。 容器类型J2EE应用组件可以安装部署到以下几种容器中去:EJB 容器管理所有J2EE 应用程序中企业级bean 的执行. enterprise bean 和它们的容器运行在J2EE 服务器上。Web 容器管理所有J2EE 应用程序中JSP页面和Servlet组件的执行. Web 组件和它们的容器运行在J2EE 服务器上。 应用程序客户端容器管理所有J2EE应用程序中应用程序客户端组件的执行. 应用程序客户端和它们的容器运行在J2EE 服务器上。Applet 容器是运行在客户端机器上的web浏览器和 Java 插件的结合。图2.2 J2EE容器第三章 银行核心业务系统的实现3.1概念描述图3.1 银行核心系统应用模块结构图由于银行业务不是本文描述的重点，在此只作如下简单介绍。上图以分层结构图来描述银行核心系统中各应用模块的协作关系。最下一层为整个系统的基础，提供了一个系统资源的共享池，包括交易平台、全局数据（静态数据、市场数据及应用系统注册表）、各业务系统公用方法及接口；第二层是客户管理层，作为客户信息和信用风险的管理中心；第三层是银行核心业务层，包括外汇、储蓄、及汇款，这一层负责银行及客户双方的资金往来交易并为下一层中的其他银行业务提供基础；第四层是银行产品线业务层，这一层包括各种银行营收来源的产品，这些产品可以向银行客户打包销售，这样就有了一个交叉的产品模块来处理收费、利息及分红的计算和处理；最上一层是企业资源配置（ERP）层，负责搜集所有业务系统的交易数据并为财务、管理及经营策略提供依据。另外图中有一个跨越各层的模块，为交易渠道（CHANNEL），在本系统结构中，交易渠道是沟通系统用户和系统核心的桥梁。3.2系统基础架构图 3.2 银行核心系统基础架构上图给出了银行核心系统基础架构里的各逻辑组件。本节试图详细定义各组件的功能及他们之间的相互关系。图中的基础组件，按照各自的功能分为五层。每一层都负有独自的责任并且可以与其他组件从逻辑上分开，每一层与其邻近的层松散藕合在一起，以下将以从后到前的顺序逐一列出。3.2.1资源层（Resource Tier）本层包含有所有的业务数据及一些已有的资源，如主机上的系统、跨行的业务系统、第三方的软件系统及一些新的内部系统如ERP/MIS等。应用系统遗产(Legacy Application Systems)此组件包含主机上已存在的银行系统和连接第三方的系统，例如VISA/Master card等。此处的双向箭头表示新老系统存在着在线的信息交互。数据库（Databases）在新系统里会使用关系型数据库管理系统进行数据存储。为了支持多语言，所有的数据将以双字节编码（Unicode）进行存储。数据供给(Data Feed)数据供给是一个授信的数据来源渠道，由这里供应的数据不需要经过复杂的验证和转换，例如汇率、利率、股价等等，然而，记录数据供给的日志应该定期的检查和审计。企业资源配置系统(Enterprise Resources Planning (ERP) System)这个组件包括财务系统、管理信息系统和管理报表系统等，可以采用第三方的产品来完成数据挖掘和财务管理功能。例如一个完善的ERP系统，并且有它自有的数据库管理系统，通过导入银行核心系统的交易数据来完成数据分析和报表生成工作。作业调度器(Job Scheduler)作业调度器初始化批次作业进入批次队列中，这些作业有时间驱动和事件驱动两种类型，并且支持单个的作业和作业流进入调度器中进行调度。经过初始化后，它将持续检查作业运行的状态并且在发生错误的时候抛出异常。监视器（Watchdog Console）监视器是一个集中监控系统，它收集所有系统组件的异常警报以保证每个组件持续健康稳定地运行。它通过接收不同组件的信息（如作业异常信息、安全警报信息等）并触发相应的警告消息在操作控制台上，并且能根据事件的严重等级通过发邮件、呼叫等方式来通知相应的系统支持人员。3.2.2连接层(Integration Tier)连接层由各种连接业务逻辑层和后台资源层的连接器组成，这一层中的组件由各种连接数据库和其他第三方软件的资源连接中间件组成，如JDBC、JMS、消息网关等。主机连接器（Host Integrator）主机连接器的主要功能就是保证在新的银行核心系统与老系统之间安全稳健地进行双向通讯，另外，两阶段提交机制也是这个组件的一个需要实现的功能，以保证当有交易跨系统发生时的数据完整性与一致性。数据库连接池(Database Connection Pool)数据库连接池提供并且管理业务系统到数据库的连接，使用连接池技术，可以实现系统使用可配置的数据库用户和加密的密码连接数据库，并且连接的个数和优先次序也可根据系统的负荷进行动态地分配。它的另一好处就是避免了前台用户对数据库的直接访问，提高了系统数据的安全性。批次/报表服务器（Batch/Report Services）这个组件为批次作业和报表生成提供运行环境，与联机交易环境各自独立, 它产生并管理作业队列。另外，它也负责向数据库连接池申请对数据库的连接，以保证系统数据的安全性。ERP连接器（ERP Integrator）这个组件为银行核心系统向ERP系统传送数据提供接口，如生成总账科目和更新市场数据等。另外，如有必要，也可以提供向ERP系统获取数据的接口。业务逻辑层(Business Logic Tier)所有客户端或其他外部系统提交的交易的业务逻辑, 都在这一层, 以实现业务逻辑的可重用性而不管交易的来源, 这一层的对象由消息请求唤起, 并以消息对象的形式返回应答, 保证了业务逻辑层与客户端的松散藕合。银行核心业务对象（Core Banking Business Objects）这个组件代表了所有进行交易处理的业务逻辑对象。 交易管理器（Transaction Manager）这个组件的功能是为了实现所有交易的共有流程（如交易流水记录、异常控制、数据库连接申请等）的集中控制和管理，为此，它将接收所有来自不同交易渠道的客户端的交易请求，并且，这个组件可以作为一个交易流控制器来完全客户端发起的联动交易。3.2.3表示层（Presentation Tier）这一层提供安全控制，会话管理，生成交易请求消息并向不同的交易请求渠道返回格式化的交易输出。服务器端的表示和语言服务器(Server Side Presentation & Languages Services)这个组件负责生成向所有电子通讯渠道发出的XML格式的表示内容，这些渠道包括Internet、移动终端设备、内部网络、分行柜员终端等，企业门户内容的管理也在这一层进行，所有这些表示内容都是支持多语言的，XML在实现多渠道支持上直到了关键作用。为了消除表示层的业务逻辑，所有收到的XML交易请求将被解析到标准的消息对象里并转发到交易管理器，然后由收到的交易应答对象生成XML格式的回应。请求分派服务（Request Dispatch Service）这个组件是为了实现平衡负载而将交易请求根据分派机制分发给随后的应用服务器。服务端加密服务器（Service Side e-Security Services）这个组件覆盖了各种电子渠道上的安全管理问题，如身份识别、加密、乱码、系统保护等。安全控制服务（Security Control Services）这个组件控制所有用户对银行核心系统的访问，身份鉴定和操作授权是两个主要的功能，用户只能在经过系统注册的IP或设备上访问预先设定的业务系统。安全数据库（Security Database）一个独立的数据库来存储系统安全信息以完成对用户的身份鉴别和访问授权。服务会话期管理（Service Session Management）这个组件属于J2EE应用服务器的基本功能，它实现对用户会话期的上下文管理以完成交易处理流程。通用通讯服务器（Common Communication Services）这个组件提供了一个通用的通讯协议以实现在非XML类型的交易渠道对银行核心系统的访问。3.2.4客户层（Client Tier）客户层表示所有交易渠道的用户对银行核心系统的访问界面，例如互联网浏览器、移动通讯终端、JAVA小应用程序、自动柜员机（ATM）、交互式语音应答系统（IVRS）、呼叫中心（Call Center）或其他的图形用户界面。XML是客户端显示的工业标准。客户端电子加密服务为在公用网上对系统的访问提供端到端的保护，如SSL。3.3项目规划3.3.1项目团队组织架构系统各小组角色和职责:图 3.3 项目团队组织架构图APPLICATIONS ARCHITECTURE&DEVELOPMENT（应用系统架构及开发组）子系统角色和职责划分：表 3.1 应用系统开发组职责对照表子系统任务描述主要职责整体系统框架制定系统框架及开发标准硬件配置组件整合系统开发标准系统核心部分-分行操作渠道Branch Operation Channel(SC BOC)为银行内部用户提供应用系统操作界面用户界面框架交易画面流程数据类型检查初步计算及检验控制金融机构客房端设备系统核心部分-交易管理器Transaction Manager(SC TXM)在前台交易渠道和后台应用系统之间建立标准的信息传递连接为不同的渠道提供连接器信息语义检查用户会话检查交易信息分发异常控制用户信息转换系统核心部分-安全控制系统Security Control System(SC SCS)确保合法的交易请求被传递到应用系统进行处理用户身份鉴定用户资料管理用户菜单生成用户权限管理应用系统注册交易渠道注册用户密码/卡管理主管授权信息加密/解密系统核心部分-全局数据管理General Information(SC GIF)为应用系统提供共享数据和工具公用方法：如账号生成和检验、柜员余额计算、计息公式、汇兑公式、日期计算等公用数据：如产品数据、市场汇率、货币、假日、系统参数等客户信息CIF(CC CIF)客户信息的管理和维护客户、第三方机构和银行信息记录银行内部账号客户地址、合同管理黑名单管理客户账号会计系统Accounts (ACC)核心系统帐务处理记录分户帐利息、费用、税金计算及记录分行余额管理为会计科目平衡及报表提供源数据银行产品-储蓄、贷款、国际业务Bank products(DEP, LNS, BIS)银行产品所属交易管理交易检验交易记录和处理交易流控制日终批处理Batch Day end Processing (BDE)实现统一的日终处理流程作业步骤管理日切处理数据库清理及备份启动日终处理总账数据导入监控日终处理状态作业断点重启设备驱动Device Drivers (DDV)为输出设备提供驱动打印机、读写卡器、密码键盘、ATM驱动SMTP3.3.2业务需求范围表 3.2 业务需求矩阵1Customer Information File (CIF)客户信息1.1总体需求1.1.1提供方便的客户信息访问路径1.1.2在一个界面能显示客户的各类账户信息1.1.3与其他模块、系统关联，实现信息互相调用1.1.4支持客户关系管理2Deposit存款2.1总体要求2.1.1产品具有的能力：完成在线实时产品构建在产品层面提供参数驱动功能，根据授权人的要求方便设置账户完成计算功能更新账户余额支持账户盈利性管理控制输入和挂账记录符合管理报表的要求保留并追溯各个账户及或客户或组(根据资产类型)的全部信息且这些信息是集成的生成会计分录以计入总账支持不同的利率选项支持产品批量处理,如批量代发代扣2.1.2存款系统处理下列账户的存款业务：活期存款(可以使用支票或存折，可以设置透支功能)整存整取定期存款零存整取定期存款存本取息定期存款 定活两便存款保证金存款 2.1.3Account handling 账户处理通存通兑存折便利2.1.4灵活的存款账户处理（允许在不同币种的存款账户之间进行资金划转）3Loan贷款3.1.总体需求3.1.1系统能够支持：3.1.2公司前景分析(企业类型,销售总额,总资产,盈利性等)3.1.3完整的贷款处理过程a. 记录交易b. 运行计算c. 更新余额d. 生成支付通知e. 跟踪应收帐款f. 控制输入和挂账记录g. 在有效贷款管理要求层面维护数据h.满足管理报表的需求i. 在整合基础上维护和跟踪单个贷款帐户和/或客户（群）的所有信息j. 生成入总帐的会计分录k.利率多选项功能l. 构造新贷款产品的便利m. 支持多货币n.系统支持贷款处理全过程的自动工作流控制.o.系统支持生成用户定义的各种类型报表3.1.4系统具有核销处理的能力3.1.5自动计算贷款准备金3.1.6从其他第三方系统（如客户信息系统、行业内或区域内个人征信系统等）接入数据的便捷性和相容性3.1.7系统对用户指定的贷款具备批量,自动审批的功能.4General Ledger 总账4.1总体需求4.1.1符合国际会计准则4.1.2系统需要建立总账代码表，并支持产生不同的会计报表.请具体说明总账代码结构的编制方法.4.1.3账户和交易的在线查询，包括当期、上期和前一会计年度全行、各地区、各部门和各分支行的汇总、明细数据4.1.4支持建立多层次的账户结构表4.1.5支持收付实现制与权责发生制4.1.6支持对特定账户由用户选择年底结转或顺延4.1.7支持年末作损益结转4.1.8支持多部门、多会计期间、多币种的会计核算4.1.9与其他系统的接口5Remittance汇款5.1总体需求5.1.1汇款类型：5.1.1.1国内汇入汇款和汇出汇款5.1.1.2行内汇入汇款和汇出汇款5.1.1.3国际汇入汇款和汇出汇款5.1.2汇款方式: 电汇 / 票汇 / 信汇3.6.Collection托收3.6.1.总体需求托收系统提供银行将票据向其他银行进行托收。托收系统应该是核心业务系统的一部分，所有的交易应该和其他系统遵循同样的处理规则。业务范围包括：3.6.1.1外币票据包括:银行本票、银行汇票、银行支票、私人支票、旅行支票、远期支票、国库券、国债或保付支票、到期债券和息票等3.6.1.2本币票据包括:银行本票（个人支票/企业支票）、银行支票（含个人现金汇票）、远期支票、银行汇票、银行承兑汇票、商业承兑汇票、托收承付、委托收款等3.3.3项目总体计划Phase IPhase IIPhase IIIProjectsJan-01Jun-01Jul-01Apr-02May-02Jun-02Jul-02Aug-02Sep-02Nov-02Dec-02Jan-03Feb-03Mar-03Dec-03System CoreDesignDevelopUATCIFAnaysis& DesignDesignUATFXDevelopUATCredit & CollateralAnalysis & DesignDevelopUATAccountsAnalysis & DesignDevelopUATDepositsRequirementsAnalysis & DesignDevelopUATDevelopUATLoansRequirementsAnalysis & DesignDevelopUATDevelopUATBillsAnalysis & DesignDevelopUATGL MigrationAnalysis & DesignIST/UAT/ConversionDesignDevelopUATReportingAnalysis & DesignIST/UATDesignDevelopUAT图 3.4 项目整体计划3.3.4项目实施网络拓扑图 3.5 项目实施网络拓扑图Database Zone(Centralized)Web Server Zone(Group by region)Application Server Zone(Group by application)BatchServerBatchServerLoad BalancingWebServerWebServerWebServerWebServerWebServerWebServerApplicationServerApplicationServerApplicationServerApplicationServerApplicationServerApplicationServerHACMP /Parallel ModeDBServerDBServerBatch Server ZoneReportServerReportServer图 3.6 服务器布局图3.4基于MVC的核心模块设计规格3.4.1联机交易程序分布J2EE Web Server ContainerJ2EE EJB ContainerDB ServerSCSController(EJB)Style sheets(CSS)ConfigXML FileAppsConfigXML FileAppsConfigXML FileAppsScreens(HTML)1Activity JournalingDBConnector(Singleton)Get DBConnectionServiceBrokerWindowControlFrame(Serlvet)AppsScreensHandlerTXMConnectorTXNManager(EJB)FunctionModelPL/SQL/ DBConnectDB2XMLStringXMLStringJavaObjectErrorHandler(Singleton)Txn.Journal(Singleton)ClientBrowserLocalDeviceDriversTxn.JournalFileErrorLogFileApplet图 3.7 联机交易软件部署图3.4.2交易视图（View）HandlerTemplateTransactionMessage图 3.8 交易视图的实体关系图为了统一交易画面的风格及开发流程，所有交易画面的设计及实现将由上图中各实体来完成。其中交易（Transaction）与消息（Message）将在下一节“应用系统”注册表中详述。由上图中可看出：每个交易包含多个不同交易画面的模板（Template）；每个模板可对应一到多个负责交易画面处理的处理器（Handler）；交易画面模板(Template)所有交易的画面将统一以HTML模板的形式实现，里面采用JAVASCRIPT来进行必要的客户端数据检验及计算处理。画面处理器(Handler)画面处理器对应一个物理意义上的客户端显示处理程序，当用户在画面上提交交易后，画面处理器负责接收交易数据及生成XML格式的交易请求信息并发到后台的CONTROLLER进行交易处理。为了避免在表示层（Presentation Tier）对数据库的访问，交易、模板、处理器三者之间的关系将以XML配置文件的形式存放在服务器端的表示服务器(Server Side Presentation Services)上，此XML配置文件的每一个节点由以下数据元素组成：处理器标识符：用来唯一确定一个处理器；交易代号：表示此处理器将用于哪一个交易画面处理；程序名：表示此处理器对应于哪一个物理程序（Class）；初始标记：表示此处理器是否是此交易的第一个处理器，当初始化一个交易时，将使用此交易代号下初始化标记为真的那一个处理器。模板文件名：表示此处理器将被哪一个交易画面模板呼叫。应用系统注册表(Controller)为了银行核心系统内部各应用系统的管理和定义各系统内对象之间的接口关系，所有的应用系统必需将其本身及内部的功能模块在数据库中进行注册后才能生效，以下是本注册机制中和实体之间的关系图。ApplicationTransactionGroupChannelTransactionFunction ModelMessageChannelTransaction图3.9 应用系统注册表的实体关系图由以上的实体关系图可以得出以下关系：每一个交易渠道（CHANNEL）里可以进行的交易必须在渠道交易实体（Channel Transaction）里注册；所有合法交易都必须在交易实体（Transaction）里注册；每一个应用系统（Application）下包含多个交易组(Transaction Group)；每一个交易组可以包含多个子交易组；每一个交易可以有多个交易请求信息（Message），此交易请求由交易渠道接收；每一个应用系统下有多个处理模型（Function Model），每一个处理模型可被多个交易请求信息驱动，以此来实现处理模型的可重用性。应用系统（Application）一个应用系统由一个功能模型包组成，用来实现某一特定业务领域的应用需求，例如客户信息系统（CIF）、储蓄业务系统（Deposit）、国际业务等等，应用系统的数据实体由以下数据项组成：应用系统代码：由三个字符组成，用来唯一标识一个应用系统模块。应用系统名称：用于客户端的显示或报表的打印。数据库用户名：记录访问此应用系统的数据库用户名。数据库用户密码：加密存放以上数据库用户的访问密码。生效标记：用来标记此应用系统是否有效，对应于此标记，此应用系统下的所有功能模型也将相应地生效或失效。消息（Message）在此银行核心系统内，使用消息来驱动功能模型以完成不同的交易，每一个消息由以下部分组成：消息标识号：一个唯一的标识用来确定一条银行核心系统内的合法消息。所属的交易代码：用来表示此消息由何交易发出。消息序号：用来记录当前消息在本交易中的次序。功能模型代号：用来表示此消