5_基于MVC設計模式的銀行應用系統(tǒng).doc

第一章 引言 1.1銀行核心系統(tǒng)的現(xiàn)狀隨著Internet和電子商務的迅速發(fā)展，當今金融企業(yè)傳統(tǒng)的經(jīng)營模式正面臨巨大的挑戰(zhàn)。金融產(chǎn)品和服務渠道的多樣化，已經(jīng)成為金融企業(yè)核心競爭力的所在，成為各企業(yè)間競相比拼的內(nèi)容。傳統(tǒng)服務渠道邏輯分離的金融系統(tǒng)正在變得越來越過時，這種模式的系統(tǒng)每種服務渠道都各有一套自己的數(shù)據(jù)格式、通訊方式和應用邏輯，實現(xiàn)業(yè)務時的業(yè)務流程以及對銀行核心數(shù)據(jù)的訪問都是由渠道自己負責的，對于銀行業(yè)來講，銀行柜面業(yè)務有柜面業(yè)務的服務渠道，網(wǎng)上銀行有網(wǎng)上銀行的服務渠道，網(wǎng)上銀行的數(shù)據(jù)格式、交易流程與柜面業(yè)務的處理毫無關系。凡此種種，在迅猛發(fā)展的電子商務新的競爭環(huán)境下，構架新一代銀行的應用服務平臺實為大勢所趨。 1.2傳統(tǒng)系統(tǒng)存在的問題 可復用能力低，可維護性差：集中表現(xiàn)在不支持多種服務形式(例如銀行的柜面業(yè)務、網(wǎng)上銀行、自助銀行、電話銀行等等)共享相同的業(yè)務邏輯。一般來講，金融企業(yè)的同一種業(yè)務往往具有多種服務形式，而且，這些服務形式所涉及到的業(yè)務邏輯是類似的。比如銀行業(yè)的同樣一筆轉(zhuǎn)賬業(yè)務，在柜臺、網(wǎng)上銀行、ATM、或者電話銀行都能辦理，在這幾種轉(zhuǎn)賬的表現(xiàn)形式中，基本業(yè)務流程如查詢客戶資料、檢查密碼、檢查客戶余額、登記交易流水等是完全一樣的，但由于傳統(tǒng)的銀行系統(tǒng)中各種服務渠道邏輯上是分離的，以往的開發(fā)不得不針對柜臺、網(wǎng)上銀行、ATM、電話銀行分別開發(fā)各自的交易流程，而且不得不與各種不同的通訊方式打交道，帶來的不良后果就是系統(tǒng)的可復用能力低，可維護性差。(1)不能實現(xiàn)快速的新產(chǎn)品研發(fā)和推廣：傳統(tǒng)系統(tǒng)的升級和換代必將涉及到現(xiàn)有的各種服務渠道的改造，使得新產(chǎn)品研發(fā)和推廣周期較長。(2)不能有效對客戶行為進行分析：企業(yè)來說，有些客戶的行為能為企業(yè)帶來效益，有些卻不能。對客戶行為進行分析以獲取客戶資源信息是非常重要的。但服務渠道的分離卻使的客戶行為數(shù)據(jù)存儲分散而且格式各異，傳統(tǒng)系統(tǒng)在全面采集客戶數(shù)據(jù)上顯得十分不便。(3)增加新服務渠道的成本急速上升：IBM的一項研究項目表明，渠道分離的商業(yè)系統(tǒng)，隨著服務渠道的增加，系統(tǒng)需要的費用急速上升，尤其在銀行業(yè)，其特征十分明顯。1.3本項目的工作內(nèi)容解決以上問題勢必需要對傳統(tǒng)的金融系統(tǒng)進行改造。將金融系統(tǒng)的各種接入渠道視為不同的表現(xiàn)邏輯，將表現(xiàn)邏輯與核心的業(yè)務邏輯分開，提高系統(tǒng)的復用性是改造的重點。這就需要在表現(xiàn)邏輯和業(yè)務邏輯之間增加第二層，即應用服務器層(Application Server)，以實現(xiàn)表現(xiàn)邏輯和核心業(yè)務邏輯的隔離，并實現(xiàn)共享業(yè)務邏輯。以開放標準的角度衡量，以SUN公司為代表的J2EE企業(yè)級應用架構成了必然的選擇。正是在這樣的背景下，開始了對金融行業(yè)應用服務器開發(fā)框架的研究。整個系統(tǒng)的模型如圖所示：圖1.1 銀行核心應用框圖整個系統(tǒng)構架在應用服務器之上，從功能上分為了表現(xiàn)邏輯和業(yè)務邏輯兩大層面。 從整體上看，整個系統(tǒng)由三個層次的模塊構建而成。底層公用構件庫提供了系統(tǒng)的底層支撐環(huán)境，工具箱提供了可視化的開發(fā)、維護、發(fā)布等的集成環(huán)境，頂層的應用服務為實際應用系統(tǒng)的運行提供了支撐。交易引擎：一套成熟的金融企業(yè)應用系統(tǒng)，其中許多交易具有相似或相同的處理模式及流程。這些相同或相似的處理模式可以被提取出來作為公共對象，以便在開發(fā)新的相同或系統(tǒng)維護時重用。但是，不同的系統(tǒng)又各有特點，因此又不可能找到一種一勞永逸的方法將所有交易都加以相同的實現(xiàn)。為了最大程度的方便應用系統(tǒng)的開發(fā)，減輕開發(fā)人員的工作量，同時又不喪失應用系統(tǒng)應有的靈活性，需要一種能兼顧兩方面要求的基本系統(tǒng)，使得二次開發(fā)人員可以在基本系統(tǒng)上進行最小工作量的開發(fā)。 為滿足上述要求，必須遵循兩個原則：第一，系統(tǒng)中必須有足夠的通用組件供二次開發(fā)人員使用；第二，系統(tǒng)必須保證對特定交易實現(xiàn)的靈活性。平臺的最大特點是把業(yè)務邏輯處理部分獨立出來，使之和具體的協(xié)議無關，程序員幾乎可以把全部的注意力放在業(yè)務邏輯的實現(xiàn)上，同時降低了對程序員水平的要求，只要懂得基本的JAVA和SQL語言就以很好地并且規(guī)范地完成業(yè)務邏輯處理部分的工作。銀行接入引擎：它是實現(xiàn)接入渠道整合的重要功能部件，其基本功能是匯聚各式各樣的前端系統(tǒng)，抽取這些系統(tǒng)中傳輸來的業(yè)務數(shù)據(jù)，實現(xiàn)數(shù)據(jù)的格式變換，并將數(shù)據(jù)轉(zhuǎn)發(fā)給指定的處理單元。接入引擎隱藏了各種系統(tǒng)在表現(xiàn)邏輯上的差異，為實現(xiàn)商業(yè)核心業(yè)務邏輯與各種表現(xiàn)邏輯分離奠定了基礎。作為一個靈活的接入渠道整合平臺，就在盡量不改變現(xiàn)有應用程序應用邏輯的條件下實現(xiàn)不同類型應用系統(tǒng)的數(shù)據(jù)交換，不但完全滿足現(xiàn)有傳統(tǒng)業(yè)務的要求，也能適應電子商務發(fā)展的要求。本文共分為五個章節(jié)，本章從剖析傳統(tǒng)的銀行核心系統(tǒng)入手，分析了現(xiàn)有的系統(tǒng)對新應用開發(fā)的不足，簡介了本文的現(xiàn)實意義；第二章“MVC開發(fā)模式及J2EE框架”，簡單介紹了J2EE企業(yè)應用框架的規(guī)范及MVC開發(fā)模式的基本思想；第三章“銀行核心業(yè)務系統(tǒng)的實現(xiàn)”，論述了N層次模型的銀行核心系統(tǒng)框架下每層的角色及功能，并簡單介紹了整個項目的規(guī)劃，詳述了MVC模式的核心系統(tǒng)的實現(xiàn)方法；第四章“儲蓄業(yè)務系統(tǒng)”，以儲蓄業(yè)務系統(tǒng)為例，介紹了在以上的銀行核心系統(tǒng)框架下的具體應用開發(fā)的流程；最后一章“總結”將新舊系統(tǒng)進行了對比，搜集了用戶的反饋意見，對系統(tǒng)的不足之處進行了分析，并對未來的工作進行了展望，具體詳細內(nèi)容請閱相應章節(jié)。第二章 MVC開發(fā)模式及J2EE框架2.1 MVC開發(fā)模式模型視圖控制器（Model-View-Controller）是XeroxPARC在八十年代為編程語言Smalltalk80發(fā)明的一種軟件設計模式，至今已被廣泛使用。最近幾年被推薦為Sun公司J2EE平臺的設計模式，受到越來越多的開發(fā)者的歡迎。模型視圖控制器模式是一個有用的工具箱，它有很多好處，但也有一些缺點。2.1.1MVC如何工作MVC是一個設計模式，它強制性的使應用程序的輸入、處理和輸出分開。使用MVC應用程序被分成三個核心部件：模型、視圖、控制器。它們各自處理自己的任務。1、視圖視圖是用戶看到并與之交互的界面。對老式的Web應用程序來說，視圖就是由HTML元素組成的界面，在新式的Web應用程序中，HTML依舊在視圖中扮演著重要的角色，但一些新的技術已層出不窮，它們包括MacromediaFlash以及諸如XHTML，XML/XSL，WML等一些標識語言和Web services等。如何處理應用程序的界面變得越來越有挑戰(zhàn)性。MVC一個大的好處是它能為你的應用程序處理很多不同的視圖。在視圖中其實沒有真正的處理發(fā)生，不管這些數(shù)據(jù)是聯(lián)機存儲的還是一個雇員列表，作為視圖來講，它只是作為一種輸出數(shù)據(jù)并允許用戶操縱的方式。2、模型模型表示企業(yè)數(shù)據(jù)和業(yè)務規(guī)則。在MVC的三個部件中，模型擁有最多的處理任務。例如它可能用象EJBs這樣的構件對象來處理數(shù)據(jù)庫。被模型返回的數(shù)據(jù)是中立的，就是說模型與數(shù)據(jù)格式無關，這樣一個模型能為多個視圖提供數(shù)據(jù)。由于應用于模型的代碼只需寫一次就可以被多個視圖重用，所以減少了代碼的重復性。3、控制器控制器接受用戶的輸入并調(diào)用模型和視圖去完成用戶的需求。所以當單擊Web頁面中的超鏈接和發(fā)送HTML表單時，控制器本身不輸出任何東西和做任何處理。它只是接收請求并決定調(diào)用哪個模型構件去處理請求，然后用確定用哪個視圖來顯示模型處理返回的數(shù)據(jù)?，F(xiàn)在總結一下MVC的處理過程，首先控制器接收用戶的請求，并決定應該調(diào)用哪個模型來進行處理，然后模型用業(yè)務邏輯來處理用戶的請求并返回數(shù)據(jù)，最后控制器用相應的視圖格式化模型返回的數(shù)據(jù)，并通過表示層呈現(xiàn)給用戶。2.1.2為什么要使用 MVC大部分Web應用程序都是用像ASP，PHP這樣的過程化語言來創(chuàng)建的。它們將像數(shù)據(jù)庫查詢語句這樣的數(shù)據(jù)層代碼和像HTML這樣的表示層代碼混在一起。經(jīng)驗比較豐富的開發(fā)者會將數(shù)據(jù)從表示層分離開來，但這通常不是很容易做到的，它需要精心的計劃和不斷的嘗試。MVC從根本上強制性的將它們分開。盡管構造MVC應用程序需要一些額外的工作，但是它帶來的好處是無庸質(zhì)疑的。首先，最重要的一點是多個視圖能共享一個模型，現(xiàn)在需要用越來越多的方式來訪問你的應用程序。對此，其中一個解決之道是使用MVC，無論你的用戶想要Flash界面或是 WAP 界面；用一個模型就能處理它們。由于你已經(jīng)將數(shù)據(jù)和業(yè)務規(guī)則從表示層分開，所以你可以最大化的重用你的代碼了。由于模型返回的數(shù)據(jù)沒有進行格式化，所以同樣的構件能被不同界面使用。例如，很多數(shù)據(jù)可能用HTML來表示，但是它們也有可能要用Macromedia Flash和WAP來表示。模型也有狀態(tài)管理和數(shù)據(jù)持久性處理的功能，例如，基于會話的購物車和電子商務過程也能被Flash網(wǎng)站或者無線聯(lián)網(wǎng)的應用程序所重用。因為模型是自包含的，并且與控制器和視圖相分離，所以很容易改變你的應用程序的數(shù)據(jù)層和業(yè)務規(guī)則。如果你想把你的數(shù)據(jù)庫從MySQL移植到Oracle，或者改變你的基于RDBMS數(shù)據(jù)源到LDAP，只需改變你的模型即可。一旦你正確的實現(xiàn)了模型，不管你的數(shù)據(jù)來自數(shù)據(jù)庫或是LDAP服務器，視圖將會正確的顯示它們。由于運用MVC的應用程序的三個部件是相互對立，改變其中一個不會影響其它兩個，所以依據(jù)這種設計思想你能構造良好的松偶合的構件。另外，控制器的也提供了一個好處，就是可以使用控制器來聯(lián)接不同的模型和視圖去完成用戶的需求，這樣控制器可以為構造應用程序提供強有力的手段。給定一些可重用的模型和視圖，控制器可以根據(jù)用戶的需求選擇模型進行處理，然后選擇視圖將處理結果顯示給用戶。2.1.3MVC的缺點MVC的缺點是由于它沒有明確的定義，所以完全理解MVC并不是很容易。使用MVC需要精心的計劃，由于它的內(nèi)部原理比較復雜，所以需要花費一些時間去思考。需要花費相當可觀的時間去考慮如何將MVC運用到應用程序，由于模型和視圖要嚴格的分離，也給調(diào)試應用程序到來了一定的困難。每個構件在使用之前都需要經(jīng)過徹底的測試。一旦構件經(jīng)過了測試，就可以毫無顧忌的重用它們了。由于將一個應用程序分成了三個部件，所以使用MVC同時也意味著將要管理比以前更多的文件，這一點是顯而易見的。這樣好像工作量增加了，但是這比起它所能帶來的好處是不值一提。MVC并不適合小型甚至中等規(guī)模的應用程序，花費大量時間將MVC應用到規(guī)模并不是很大的應用程序通常會得不償失。2.2JAVA 2企業(yè)版應用框架2.2.1J2EE的概念目前，Java 2平臺有3個版本，它們是適用于小型設備和智能卡的Java 2平臺Micro版（Java 2 Platform Micro Edition，J2ME）、適用于桌面系統(tǒng)的Java 2平臺標準版（Java 2 Platform Standard Edition，J2SE）、適用于創(chuàng)建服務器應用程序和服務的Java 2平臺企業(yè)版（Java 2 Platform Enterprise Edition，J2EE）。J2EE是一種利用Java 2平臺來簡化企業(yè)解決方案的開發(fā)、部署和管理相關的復雜問題的體系結構。J2EE技術的基礎就是核心Java平臺或Java 2平臺的標準版，其最終目的就是成為一個能夠使企業(yè)開發(fā)者大幅縮短投放市場時間的體系結構。 J2EE體系結構提供中間層集成框架用來滿足無需太多費用而又需要高可用性、高可靠性以及可擴展性的應用的需求。通過提供統(tǒng)一的開發(fā)平臺，J2EE降低了開發(fā)多層應用的費用和復雜性，同時提供對現(xiàn)有應用程序集成強有力支持，完全支持Enterprise Java Beans，有良好的向?qū)еС执虬筒渴饝?，添加目錄支持，增強了安全機制，提高了性能。2.2.2J2EE的優(yōu)勢J2EE為搭建具有可伸縮性、靈活性、易維護性的商務系統(tǒng)提供了良好的機制:保留現(xiàn)存的IT資產(chǎn): 由于企業(yè)必須適應新的商業(yè)需求，利用已有的企業(yè)信息系統(tǒng)方面的投資，而不是重新制定全盤方案就變得很重要。這樣，一個以漸進的（而不是激進的，全盤否定的）方式建立在已有系統(tǒng)之上的服務器端平臺機制是公司所需求的。J2EE架構可以充分利用用戶原有的投資。高效的開發(fā): J2EE允許公司把一些通用的、很繁瑣的服務端任務交給中間件供應商去完成。這樣開發(fā)人員可以集中精力在如何創(chuàng)建商業(yè)邏輯上，相應地縮短了開發(fā)時間。高級中間件供應商提供以下這些復雜的中間件服務: 狀態(tài)管理服務 - 讓開發(fā)人員寫更少的代碼，不用關心如何管理狀態(tài)，這樣能夠更快地完成程序開發(fā)。 持續(xù)性服務 - 讓開發(fā)人員不用對數(shù)據(jù)訪問邏輯進行編碼就能編寫應用程序，能生成更輕巧，與數(shù)據(jù)庫無關的應用程序，這種應用程序更易于開發(fā)與維護。 分布式共享數(shù)據(jù)對象CACHE服務 - 讓開發(fā)人員編制高性能的系統(tǒng)，極大提高整體部署的伸縮性。 支持異構環(huán)境: J2EE能夠開發(fā)部署在異構環(huán)境中的可移植程序。基于J2EE的應用程序不依賴任何特定操作系統(tǒng)、中間件、硬件。因此設計合理的基于J2EE的程序只需開發(fā)一次就可部署到各種平臺。這在典型的異構企業(yè)計算環(huán)境中是十分關鍵的。J2EE標準也允許客戶訂購與J2EE兼容的第三方的現(xiàn)成的組件，把他們部署到異構環(huán)境中，節(jié)省了由自己制訂整個方案所需的費用。 可伸縮性: 企業(yè)必須要選擇一種服務器端平臺，這種平臺應能提供極佳的可伸縮性去滿足那些在他們系統(tǒng)上進行商業(yè)運作的大批新客戶?；贘2EE平臺的應用程序可被部署到各種操作系統(tǒng)上。例如可被部署到高端UNIX與大型機系統(tǒng)，J2EE領域的供應商提供了更為廣泛的負載平衡策略。能消除系統(tǒng)中的瓶頸，允許多臺服務器集成部署。穩(wěn)定的可用性: 一個服務器端平臺必須能全天候運轉(zhuǎn)以滿足公司客戶、合作伙伴的需要。因為INTERNET是全球化的、無處不在的，即使在夜間按計劃停機也可能造成嚴重損失。若是意外停機，那會有災難性后果。J2EE部署到可靠的操作環(huán)境中，他們支持長期的可用性。2.2.3J2EE 的四層模型J2EE使用多層的分布式應用模型，應用邏輯按功能劃分為組件，各個應用組件根據(jù)他們所在的層分布在不同的機器上。事實上，sun設計J2EE的初衷正是為了解決兩層模式(client/server)的弊端，在傳統(tǒng)模式中，客戶端擔當了過多的角色而顯得臃腫，在這種模式中，第一次部署的時候比較容易，但難于升級或改進，可伸展性也不理想，而且經(jīng)?；谀撤N專有的協(xié)議通常是某種數(shù)據(jù)庫協(xié)議。它使得重用業(yè)務邏輯和界面邏輯非常困難?，F(xiàn)在J2EE 的多層企業(yè)級應用模型將兩層化模型中的不同層面切分成許多層。一個多層化應用能夠為不同的每種服務提供一個獨立的層，以下是 J2EE 典型的四層結構:運行在客戶端機器上的客戶層組件運行在J2EE服務器上的Web層組件運行在J2EE服務器上的業(yè)務邏輯層組件 運行在EIS服務器上的企業(yè)信息系統(tǒng)(Enterprise information system)層軟件 圖2. 1 J2EE四層模型 2.2.4J2EE 的結構這種基于組件，具有平臺無關性的J2EE 結構使得J2EE 程序的編寫十分簡單，因為業(yè)務邏輯被封裝成可復用的組件，并且J2EE 服務器以容器的形式為所有的組件類型提供后臺服務. 因為不用自己開發(fā)這種服務, 所以可以集中精力解決手頭的業(yè)務問題。容器和服務容器設置定制了J2EE服務器所提供得內(nèi)在支持，包括安全，事務管理，JNDI(Java Naming and Directory Interface)尋址,遠程連接等服務，以下列出最重要的幾種服務：J2EE安全(Security)模型可以配置 web 組件或enterprise bean ,這樣只有被授權的用戶才能訪問系統(tǒng)資源。每一客戶屬于一個特別的角色，而每個角色只允許激活特定的方法。在enterprise bean的布置描述中聲明角色和可被激活的方法。由于這種聲明性的方法，你不必編寫加強安全性的規(guī)則。 J2EE 事務管理（Transaction Management）模型指定組成一個事務中所有方法間的關系，這樣一個事務中的所有方法被當成一個單一的單元。當客戶端激活一個enterprise bean中的方法，容器介入一管理事務。因有容器管理事務，在enterprise bean中不必對事務的邊界進行編碼。 JNDI 尋址(JNDI Lookup)服務向企業(yè)內(nèi)的多重名字和目錄服務提供了一個統(tǒng)一的接口,這樣應用程序組件可以訪問名字和目錄服務。J2EE遠程連接（Remote Client Connectivity）模型管理客戶端和enterprise bean間的低層交互. 當一個enterprise bean創(chuàng)建后, 一個客戶端可以調(diào)用它的方法就象它和客戶端位于同一虛擬機上一樣。生存周期管理（Life Cycle Management）模型管理enterprise bean的創(chuàng)建和移除,一個enterprise bean在其生存周期中將會歷經(jīng)幾種狀態(tài)。容器創(chuàng)建enterprise bean，并在可用實例池與活動狀態(tài)中移動他，而最終將其從容器中移除。即使可以調(diào)用enterprise bean的create及remove方法，容器也將會在后臺執(zhí)行這些任務。 數(shù)據(jù)庫連接池（Database Connection Pooling）模型是一個有價值的資源。獲取數(shù)據(jù)庫連接是一項耗時的工作，而且連接數(shù)非常有限。容器通過管理連接池來緩和這些問題。enterprise bean可從池中迅速獲取連接。在bean釋放連接之可為其他bean使用。 容器類型J2EE應用組件可以安裝部署到以下幾種容器中去:EJB 容器管理所有J2EE 應用程序中企業(yè)級bean 的執(zhí)行. enterprise bean 和它們的容器運行在J2EE 服務器上。Web 容器管理所有J2EE 應用程序中JSP頁面和Servlet組件的執(zhí)行. Web 組件和它們的容器運行在J2EE 服務器上。 應用程序客戶端容器管理所有J2EE應用程序中應用程序客戶端組件的執(zhí)行. 應用程序客戶端和它們的容器運行在J2EE 服務器上。Applet 容器是運行在客戶端機器上的web瀏覽器和 Java 插件的結合。圖2.2 J2EE容器第三章 銀行核心業(yè)務系統(tǒng)的實現(xiàn)3.1概念描述圖3.1 銀行核心系統(tǒng)應用模塊結構圖由于銀行業(yè)務不是本文描述的重點，在此只作如下簡單介紹。上圖以分層結構圖來描述銀行核心系統(tǒng)中各應用模塊的協(xié)作關系。最下一層為整個系統(tǒng)的基礎，提供了一個系統(tǒng)資源的共享池，包括交易平臺、全局數(shù)據(jù)（靜態(tài)數(shù)據(jù)、市場數(shù)據(jù)及應用系統(tǒng)注冊表）、各業(yè)務系統(tǒng)公用方法及接口；第二層是客戶管理層，作為客戶信息和信用風險的管理中心；第三層是銀行核心業(yè)務層，包括外匯、儲蓄、及匯款，這一層負責銀行及客戶雙方的資金往來交易并為下一層中的其他銀行業(yè)務提供基礎；第四層是銀行產(chǎn)品線業(yè)務層，這一層包括各種銀行營收來源的產(chǎn)品，這些產(chǎn)品可以向銀行客戶打包銷售，這樣就有了一個交叉的產(chǎn)品模塊來處理收費、利息及分紅的計算和處理；最上一層是企業(yè)資源配置（ERP）層，負責搜集所有業(yè)務系統(tǒng)的交易數(shù)據(jù)并為財務、管理及經(jīng)營策略提供依據(jù)。另外圖中有一個跨越各層的模塊，為交易渠道（CHANNEL），在本系統(tǒng)結構中，交易渠道是溝通系統(tǒng)用戶和系統(tǒng)核心的橋梁。3.2系統(tǒng)基礎架構圖 3.2 銀行核心系統(tǒng)基礎架構上圖給出了銀行核心系統(tǒng)基礎架構里的各邏輯組件。本節(jié)試圖詳細定義各組件的功能及他們之間的相互關系。圖中的基礎組件，按照各自的功能分為五層。每一層都負有獨自的責任并且可以與其他組件從邏輯上分開，每一層與其鄰近的層松散藕合在一起，以下將以從后到前的順序逐一列出。3.2.1資源層（Resource Tier）本層包含有所有的業(yè)務數(shù)據(jù)及一些已有的資源，如主機上的系統(tǒng)、跨行的業(yè)務系統(tǒng)、第三方的軟件系統(tǒng)及一些新的內(nèi)部系統(tǒng)如ERP/MIS等。應用系統(tǒng)遺產(chǎn)(Legacy Application Systems)此組件包含主機上已存在的銀行系統(tǒng)和連接第三方的系統(tǒng)，例如VISA/Master card等。此處的雙向箭頭表示新老系統(tǒng)存在著在線的信息交互。數(shù)據(jù)庫（Databases）在新系統(tǒng)里會使用關系型數(shù)據(jù)庫管理系統(tǒng)進行數(shù)據(jù)存儲。為了支持多語言，所有的數(shù)據(jù)將以雙字節(jié)編碼（Unicode）進行存儲。數(shù)據(jù)供給(Data Feed)數(shù)據(jù)供給是一個授信的數(shù)據(jù)來源渠道，由這里供應的數(shù)據(jù)不需要經(jīng)過復雜的驗證和轉(zhuǎn)換，例如匯率、利率、股價等等，然而，記錄數(shù)據(jù)供給的日志應該定期的檢查和審計。企業(yè)資源配置系統(tǒng)(Enterprise Resources Planning (ERP) System)這個組件包括財務系統(tǒng)、管理信息系統(tǒng)和管理報表系統(tǒng)等，可以采用第三方的產(chǎn)品來完成數(shù)據(jù)挖掘和財務管理功能。例如一個完善的ERP系統(tǒng)，并且有它自有的數(shù)據(jù)庫管理系統(tǒng)，通過導入銀行核心系統(tǒng)的交易數(shù)據(jù)來完成數(shù)據(jù)分析和報表生成工作。作業(yè)調(diào)度器(Job Scheduler)作業(yè)調(diào)度器初始化批次作業(yè)進入批次隊列中，這些作業(yè)有時間驅(qū)動和事件驅(qū)動兩種類型，并且支持單個的作業(yè)和作業(yè)流進入調(diào)度器中進行調(diào)度。經(jīng)過初始化后，它將持續(xù)檢查作業(yè)運行的狀態(tài)并且在發(fā)生錯誤的時候拋出異常。監(jiān)視器（Watchdog Console）監(jiān)視器是一個集中監(jiān)控系統(tǒng)，它收集所有系統(tǒng)組件的異常警報以保證每個組件持續(xù)健康穩(wěn)定地運行。它通過接收不同組件的信息（如作業(yè)異常信息、安全警報信息等）并觸發(fā)相應的警告消息在操作控制臺上，并且能根據(jù)事件的嚴重等級通過發(fā)郵件、呼叫等方式來通知相應的系統(tǒng)支持人員。3.2.2連接層(Integration Tier)連接層由各種連接業(yè)務邏輯層和后臺資源層的連接器組成，這一層中的組件由各種連接數(shù)據(jù)庫和其他第三方軟件的資源連接中間件組成，如JDBC、JMS、消息網(wǎng)關等。主機連接器（Host Integrator）主機連接器的主要功能就是保證在新的銀行核心系統(tǒng)與老系統(tǒng)之間安全穩(wěn)健地進行雙向通訊，另外，兩階段提交機制也是這個組件的一個需要實現(xiàn)的功能，以保證當有交易跨系統(tǒng)發(fā)生時的數(shù)據(jù)完整性與一致性。數(shù)據(jù)庫連接池(Database Connection Pool)數(shù)據(jù)庫連接池提供并且管理業(yè)務系統(tǒng)到數(shù)據(jù)庫的連接，使用連接池技術，可以實現(xiàn)系統(tǒng)使用可配置的數(shù)據(jù)庫用戶和加密的密碼連接數(shù)據(jù)庫，并且連接的個數(shù)和優(yōu)先次序也可根據(jù)系統(tǒng)的負荷進行動態(tài)地分配。它的另一好處就是避免了前臺用戶對數(shù)據(jù)庫的直接訪問，提高了系統(tǒng)數(shù)據(jù)的安全性。批次/報表服務器（Batch/Report Services）這個組件為批次作業(yè)和報表生成提供運行環(huán)境，與聯(lián)機交易環(huán)境各自獨立, 它產(chǎn)生并管理作業(yè)隊列。另外，它也負責向數(shù)據(jù)庫連接池申請對數(shù)據(jù)庫的連接，以保證系統(tǒng)數(shù)據(jù)的安全性。ERP連接器（ERP Integrator）這個組件為銀行核心系統(tǒng)向ERP系統(tǒng)傳送數(shù)據(jù)提供接口，如生成總賬科目和更新市場數(shù)據(jù)等。另外，如有必要，也可以提供向ERP系統(tǒng)獲取數(shù)據(jù)的接口。業(yè)務邏輯層(Business Logic Tier)所有客戶端或其他外部系統(tǒng)提交的交易的業(yè)務邏輯, 都在這一層, 以實現(xiàn)業(yè)務邏輯的可重用性而不管交易的來源, 這一層的對象由消息請求喚起, 并以消息對象的形式返回應答, 保證了業(yè)務邏輯層與客戶端的松散藕合。銀行核心業(yè)務對象（Core Banking Business Objects）這個組件代表了所有進行交易處理的業(yè)務邏輯對象。 交易管理器（Transaction Manager）這個組件的功能是為了實現(xiàn)所有交易的共有流程（如交易流水記錄、異?？刂啤?shù)據(jù)庫連接申請等）的集中控制和管理，為此，它將接收所有來自不同交易渠道的客戶端的交易請求，并且，這個組件可以作為一個交易流控制器來完全客戶端發(fā)起的聯(lián)動交易。3.2.3表示層（Presentation Tier）這一層提供安全控制，會話管理，生成交易請求消息并向不同的交易請求渠道返回格式化的交易輸出。服務器端的表示和語言服務器(Server Side Presentation & Languages Services)這個組件負責生成向所有電子通訊渠道發(fā)出的XML格式的表示內(nèi)容，這些渠道包括Internet、移動終端設備、內(nèi)部網(wǎng)絡、分行柜員終端等，企業(yè)門戶內(nèi)容的管理也在這一層進行，所有這些表示內(nèi)容都是支持多語言的，XML在實現(xiàn)多渠道支持上直到了關鍵作用。為了消除表示層的業(yè)務邏輯，所有收到的XML交易請求將被解析到標準的消息對象里并轉(zhuǎn)發(fā)到交易管理器，然后由收到的交易應答對象生成XML格式的回應。請求分派服務（Request Dispatch Service）這個組件是為了實現(xiàn)平衡負載而將交易請求根據(jù)分派機制分發(fā)給隨后的應用服務器。服務端加密服務器（Service Side e-Security Services）這個組件覆蓋了各種電子渠道上的安全管理問題，如身份識別、加密、亂碼、系統(tǒng)保護等。安全控制服務（Security Control Services）這個組件控制所有用戶對銀行核心系統(tǒng)的訪問，身份鑒定和操作授權是兩個主要的功能，用戶只能在經(jīng)過系統(tǒng)注冊的IP或設備上訪問預先設定的業(yè)務系統(tǒng)。安全數(shù)據(jù)庫（Security Database）一個獨立的數(shù)據(jù)庫來存儲系統(tǒng)安全信息以完成對用戶的身份鑒別和訪問授權。服務會話期管理（Service Session Management）這個組件屬于J2EE應用服務器的基本功能，它實現(xiàn)對用戶會話期的上下文管理以完成交易處理流程。通用通訊服務器（Common Communication Services）這個組件提供了一個通用的通訊協(xié)議以實現(xiàn)在非XML類型的交易渠道對銀行核心系統(tǒng)的訪問。3.2.4客戶層（Client Tier）客戶層表示所有交易渠道的用戶對銀行核心系統(tǒng)的訪問界面，例如互聯(lián)網(wǎng)瀏覽器、移動通訊終端、JAVA小應用程序、自動柜員機（ATM）、交互式語音應答系統(tǒng)（IVRS）、呼叫中心（Call Center）或其他的圖形用戶界面。XML是客戶端顯示的工業(yè)標準?？蛻舳穗娮蛹用芊諡樵诠镁W(wǎng)上對系統(tǒng)的訪問提供端到端的保護，如SSL。3.3項目規(guī)劃3.3.1項目團隊組織架構系統(tǒng)各小組角色和職責:圖 3.3 項目團隊組織架構圖APPLICATIONS ARCHITECTURE&DEVELOPMENT（應用系統(tǒng)架構及開發(fā)組）子系統(tǒng)角色和職責劃分：表 3.1 應用系統(tǒng)開發(fā)組職責對照表子系統(tǒng)任務描述主要職責整體系統(tǒng)框架制定系統(tǒng)框架及開發(fā)標準硬件配置組件整合系統(tǒng)開發(fā)標準系統(tǒng)核心部分-分行操作渠道Branch Operation Channel(SC BOC)為銀行內(nèi)部用戶提供應用系統(tǒng)操作界面用戶界面框架交易畫面流程數(shù)據(jù)類型檢查初步計算及檢驗控制金融機構客房端設備系統(tǒng)核心部分-交易管理器Transaction Manager(SC TXM)在前臺交易渠道和后臺應用系統(tǒng)之間建立標準的信息傳遞連接為不同的渠道提供連接器信息語義檢查用戶會話檢查交易信息分發(fā)異?？刂朴脩粜畔⑥D(zhuǎn)換系統(tǒng)核心部分-安全控制系統(tǒng)Security Control System(SC SCS)確保合法的交易請求被傳遞到應用系統(tǒng)進行處理用戶身份鑒定用戶資料管理用戶菜單生成用戶權限管理應用系統(tǒng)注冊交易渠道注冊用戶密碼/卡管理主管授權信息加密/解密系統(tǒng)核心部分-全局數(shù)據(jù)管理General Information(SC GIF)為應用系統(tǒng)提供共享數(shù)據(jù)和工具公用方法：如賬號生成和檢驗、柜員余額計算、計息公式、匯兌公式、日期計算等公用數(shù)據(jù)：如產(chǎn)品數(shù)據(jù)、市場匯率、貨幣、假日、系統(tǒng)參數(shù)等客戶信息CIF(CC CIF)客戶信息的管理和維護客戶、第三方機構和銀行信息記錄銀行內(nèi)部賬號客戶地址、合同管理黑名單管理客戶賬號會計系統(tǒng)Accounts (ACC)核心系統(tǒng)帳務處理記錄分戶帳利息、費用、稅金計算及記錄分行余額管理為會計科目平衡及報表提供源數(shù)據(jù)銀行產(chǎn)品-儲蓄、貸款、國際業(yè)務Bank products(DEP, LNS, BIS)銀行產(chǎn)品所屬交易管理交易檢驗交易記錄和處理交易流控制日終批處理Batch Day end Processing (BDE)實現(xiàn)統(tǒng)一的日終處理流程作業(yè)步驟管理日切處理數(shù)據(jù)庫清理及備份啟動日終處理總賬數(shù)據(jù)導入監(jiān)控日終處理狀態(tài)作業(yè)斷點重啟設備驅(qū)動Device Drivers (DDV)為輸出設備提供驅(qū)動打印機、讀寫卡器、密碼鍵盤、ATM驅(qū)動SMTP3.3.2業(yè)務需求范圍表 3.2 業(yè)務需求矩陣1Customer Information File (CIF)客戶信息1.1總體需求1.1.1提供方便的客戶信息訪問路徑1.1.2在一個界面能顯示客戶的各類賬戶信息1.1.3與其他模塊、系統(tǒng)關聯(lián)，實現(xiàn)信息互相調(diào)用1.1.4支持客戶關系管理2Deposit存款2.1總體要求2.1.1產(chǎn)品具有的能力：完成在線實時產(chǎn)品構建在產(chǎn)品層面提供參數(shù)驅(qū)動功能，根據(jù)授權人的要求方便設置賬戶完成計算功能更新賬戶余額支持賬戶盈利性管理控制輸入和掛賬記錄符合管理報表的要求保留并追溯各個賬戶及或客戶或組(根據(jù)資產(chǎn)類型)的全部信息且這些信息是集成的生成會計分錄以計入總賬支持不同的利率選項支持產(chǎn)品批量處理,如批量代發(fā)代扣2.1.2存款系統(tǒng)處理下列賬戶的存款業(yè)務：活期存款(可以使用支票或存折，可以設置透支功能)整存整取定期存款零存整取定期存款存本取息定期存款 定活兩便存款保證金存款 2.1.3Account handling 賬戶處理通存通兌存折便利2.1.4靈活的存款賬戶處理（允許在不同幣種的存款賬戶之間進行資金劃轉(zhuǎn)）3Loan貸款3.1.總體需求3.1.1系統(tǒng)能夠支持：3.1.2公司前景分析(企業(yè)類型,銷售總額,總資產(chǎn),盈利性等)3.1.3完整的貸款處理過程a. 記錄交易b. 運行計算c. 更新余額d. 生成支付通知e. 跟蹤應收帳款f. 控制輸入和掛賬記錄g. 在有效貸款管理要求層面維護數(shù)據(jù)h.滿足管理報表的需求i. 在整合基礎上維護和跟蹤單個貸款帳戶和/或客戶（群）的所有信息j. 生成入總帳的會計分錄k.利率多選項功能l. 構造新貸款產(chǎn)品的便利m. 支持多貨幣n.系統(tǒng)支持貸款處理全過程的自動工作流控制.o.系統(tǒng)支持生成用戶定義的各種類型報表3.1.4系統(tǒng)具有核銷處理的能力3.1.5自動計算貸款準備金3.1.6從其他第三方系統(tǒng)（如客戶信息系統(tǒng)、行業(yè)內(nèi)或區(qū)域內(nèi)個人征信系統(tǒng)等）接入數(shù)據(jù)的便捷性和相容性3.1.7系統(tǒng)對用戶指定的貸款具備批量,自動審批的功能.4General Ledger 總賬4.1總體需求4.1.1符合國際會計準則4.1.2系統(tǒng)需要建立總賬代碼表，并支持產(chǎn)生不同的會計報表.請具體說明總賬代碼結構的編制方法.4.1.3賬戶和交易的在線查詢，包括當期、上期和前一會計年度全行、各地區(qū)、各部門和各分支行的匯總、明細數(shù)據(jù)4.1.4支持建立多層次的賬戶結構表4.1.5支持收付實現(xiàn)制與權責發(fā)生制4.1.6支持對特定賬戶由用戶選擇年底結轉(zhuǎn)或順延4.1.7支持年末作損益結轉(zhuǎn)4.1.8支持多部門、多會計期間、多幣種的會計核算4.1.9與其他系統(tǒng)的接口5Remittance匯款5.1總體需求5.1.1匯款類型：5.1.1.1國內(nèi)匯入?yún)R款和匯出匯款5.1.1.2行內(nèi)匯入?yún)R款和匯出匯款5.1.1.3國際匯入?yún)R款和匯出匯款5.1.2匯款方式: 電匯 / 票匯 / 信匯3.6.Collection托收3.6.1.總體需求托收系統(tǒng)提供銀行將票據(jù)向其他銀行進行托收。托收系統(tǒng)應該是核心業(yè)務系統(tǒng)的一部分，所有的交易應該和其他系統(tǒng)遵循同樣的處理規(guī)則。業(yè)務范圍包括：3.6.1.1外幣票據(jù)包括:銀行本票、銀行匯票、銀行支票、私人支票、旅行支票、遠期支票、國庫券、國債或保付支票、到期債券和息票等3.6.1.2本幣票據(jù)包括:銀行本票（個人支票/企業(yè)支票）、銀行支票（含個人現(xiàn)金匯票）、遠期支票、銀行匯票、銀行承兌匯票、商業(yè)承兌匯票、托收承付、委托收款等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項目實施網(wǎng)絡拓撲圖 3.5 項目實施網(wǎng)絡拓撲圖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的核心模塊設計規(guī)格3.4.1聯(lián)機交易程序分布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 聯(lián)機交易軟件部署圖3.4.2交易視圖（View）HandlerTemplateTransactionMessage圖 3.8 交易視圖的實體關系圖為了統(tǒng)一交易畫面的風格及開發(fā)流程，所有交易畫面的設計及實現(xiàn)將由上圖中各實體來完成。其中交易（Transaction）與消息（Message）將在下一節(jié)“應用系統(tǒng)”注冊表中詳述。由上圖中可看出：每個交易包含多個不同交易畫面的模板（Template）；每個模板可對應一到多個負責交易畫面處理的處理器（Handler）；交易畫面模板(Template)所有交易的畫面將統(tǒng)一以HTML模板的形式實現(xiàn)，里面采用JAVASCRIPT來進行必要的客戶端數(shù)據(jù)檢驗及計算處理。畫面處理器(Handler)畫面處理器對應一個物理意義上的客戶端顯示處理程序，當用戶在畫面上提交交易后，畫面處理器負責接收交易數(shù)據(jù)及生成XML格式的交易請求信息并發(fā)到后臺的CONTROLLER進行交易處理。為了避免在表示層（Presentation Tier）對數(shù)據(jù)庫的訪問，交易、模板、處理器三者之間的關系將以XML配置文件的形式存放在服務器端的表示服務器(Server Side Presentation Services)上，此XML配置文件的每一個節(jié)點由以下數(shù)據(jù)元素組成：處理器標識符：用來唯一確定一個處理器；交易代號：表示此處理器將用于哪一個交易畫面處理；程序名：表示此處理器對應于哪一個物理程序（Class）；初始標記：表示此處理器是否是此交易的第一個處理器，當初始化一個交易時，將使用此交易代號下初始化標記為真的那一個處理器。模板文件名：表示此處理器將被哪一個交易畫面模板呼叫。應用系統(tǒng)注冊表(Controller)為了銀行核心系統(tǒng)內(nèi)部各應用系統(tǒng)的管理和定義各系統(tǒng)內(nèi)對象之間的接口關系，所有的應用系統(tǒng)必需將其本身及內(nèi)部的功能模塊在數(shù)據(jù)庫中進行注冊后才能生效，以下是本注冊機制中和實體之間的關系圖。ApplicationTransactionGroupChannelTransactionFunction ModelMessageChannelTransaction圖3.9 應用系統(tǒng)注冊表的實體關系圖由以上的實體關系圖可以得出以下關系：每一個交易渠道（CHANNEL）里可以進行的交易必須在渠道交易實體（Channel Transaction）里注冊；所有合法交易都必須在交易實體（Transaction）里注冊；每一個應用系統(tǒng)（Application）下包含多個交易組(Transaction Group)；每一個交易組可以包含多個子交易組；每一個交易可以有多個交易請求信息（Message），此交易請求由交易渠道接收；每一個應用系統(tǒng)下有多個處理模型（Function Model），每一個處理模型可被多個交易請求信息驅(qū)動，以此來實現(xiàn)處理模型的可重用性。應用系統(tǒng)（Application）一個應用系統(tǒng)由一個功能模型包組成，用來實現(xiàn)某一特定業(yè)務領域的應用需求，例如客戶信息系統(tǒng)（CIF）、儲蓄業(yè)務系統(tǒng)（Deposit）、國際業(yè)務等等，應用系統(tǒng)的數(shù)據(jù)實體由以下數(shù)據(jù)項組成：應用系統(tǒng)代碼：由三個字符組成，用來唯一標識一個應用系統(tǒng)模塊。應用系統(tǒng)名稱：用于客戶端的顯示或報表的打印。數(shù)據(jù)庫用戶名：記錄訪問此應用系統(tǒng)的數(shù)據(jù)庫用戶名。數(shù)據(jù)庫用戶密碼：加密存放以上數(shù)據(jù)庫用戶的訪問密碼。生效標記：用來標記此應用系統(tǒng)是否有效，對應于此標記，此應用系統(tǒng)下的所有功能模型也將相應地生效或失效。消息（Message）在此銀行核心系統(tǒng)內(nèi)，使用消息來驅(qū)動功能模型以完成不同的交易，每一個消息由以下部分組成：消息標識號：一個唯一的標識用來確定一條銀行核心系統(tǒng)內(nèi)的合法消息。所屬的交易代碼：用來表示此消息由何交易發(fā)出。消息序號：用來記錄當前消息在本交易中的次序。功能模型代號：用來表示此消