1 總體設計
1.1 設計思路
卷煙零售客戶是煙草行業最寶貴的資源，在日常的服務過程中，信息溝通的準確性和及時性是工作的難點。因此，如何創新服務方式，提升服務水平便成為了落實精準服務，全面推進營銷工作上水平的思考方向。通過微平臺傳遞特色服務，提高信息溝通的準確性，達成新型客我關系。作為煙草商業企業，面對眾多經營能力各異，服務需求不同的零售客戶，僅僅通過常規的拜訪落實服務工作，客戶經理的服務水平與營銷效率難以得到提升，服務同步也就無從談起。
煙草公司、零售戶、消費者等眾多參與者構成了一個生態系統，我們相信在這個系統中，再小的個體也有服務需求，而龐大的個體數量讓服務具備個性化和差異化等特點。微平臺通過消除煙草公司和服務對象之間的溝通距離，進行實時的交流和反饋，從而滿足不斷增長和變化的服務需要，達到全面提升服務質量和水平的目的。微平臺基于以下幾點進行設計：
一、進行有價值的服務
零售戶和消費者是煙草行業最核心的資源，每個客戶都有著自己的需要，給客戶提供有價值的服務，才能夠真正的打動客戶，進而促成和諧雙贏的伙伴關系。微平臺通過收集和分析，制定相應的服務策略，服務模式由單一的服務內容向分類分層服務提升，實現服務從無目標、無重點、履行任務式的客戶拜訪向目的明確、重點突出的客戶提升式的服務轉變，提升客戶的滿意度和忠誠度。
二、消除地理上的限制
地理曾經是過去的一個商業上的一個重要因素，但從移動互聯網以來，所有的人都能夠卷入到一種跨越時空的一種交流里面。煙草公司很難和消費者直接對話，微平臺通過公眾賬號采集消費者的需求和回饋，從而收集市場信息和市場波動，這在過去是難以想象和實現的。
三、用戶價值第一底線
微平臺通過集結零售客戶和消費者，加深相互之間理解和信任，加強相互間的黏度和互動，通過“微會員”、“微點評”、“微留言”、“微活動”、“微客服”等“互聯網+”時代的溝通方式，保護和堅守用戶價值第一的底線。
綜上所述，微平臺通過不斷滿足卷煙經營的新需求，不斷滿足零售戶和消費者的服務需要，推行主動式的服務和覆蓋式的服務，打好“服務”這張牌。
1.2 設計原則
一、 全省統一設計原則
整體框架立足于全省系統，全省統一的企業號，各市公司建立或使用全省的服務號，微信服務平臺的實施采用一個全省統一的公眾號，通過本項目的功能開發，來實現省公司、地市公司和零售戶分層管理，分層使用。
二、 先試點、后推廣原則
本項目先在蚌埠煙草試點，成功后再向其它地市煙草公司推廣使用。項目前期以蚌埠煙草業務需求為主，并結合安徽省煙草公司的需求，通過實施及試運行后的完善，逐漸形成一套可推廣的微信服務平臺。
三、 需求全面規劃、分步實施原則
從需求規劃上充分考慮各個業務部門、各個服務主體的需求，全面覆蓋煙草工業、煙草商業、零售戶和消費者的需求點，及未來發展可能存在的需求。
在項目實施中，建設的全過程中應當在整體需求規劃的指導下進行，先期完成的項目內容在完成本部分功能要求的同時要為后期實施的項目留出必要的接口，保證項目的整體完整性。
按照短平快的要求，完成工商零消服務平臺的建設，投入使用。
四、 不斷探索、不斷優化原則
微信營銷和服務是一塊新的業務領域，系統建設和使用過程中會不斷的發現需要優化的內容，所以整個微信服務平臺的建設是一個不斷探索的過程，通過不斷的實踐，不斷的優化才能讓整個平臺發揮出應有的效果。
另外鑒于本項目與安徽現有項目的密切關聯的重要性，系統設計將重點在以下原則進行考慮：
1. 安全性
系統具有實時的數據備份功能，自我校驗和糾錯功能，可以保證數據的存儲及讀取的安全，以及數據交換的安全和一致性，并對網絡中傳輸的數據采取必要的加密措施。
2. 可靠性
系統要支持長時間、高負荷的運行，要求軟/硬件平臺、應用邏輯兩方面都穩定可靠，同時，系統架構的合理性也至關重要。
3. 實時性
系統能快速響應整個系統的請求動作，快速進行數據處理和運算。系統的最長響應時間不超過5秒，平均響應時間不超過2秒。
4. 擴展性
系統有很好的擴展功能，有良好的兼容性、可移植性，能夠通過功能擴展以適用業務發展的需要。
5. 先進性
系統設計應采用先進的、成熟的且可持續發展的技術方法，并充分體現先進的管理思想和理念，與實際相結合。
6. 合理性
在系統設計時，充分考慮系統的容量及功能的擴充，方便系統擴容及平滑升級。系統對運行環境(硬件設備、軟件操作系統等)具有較好的適應性，不依賴于某一特定型號計算機設備和固定版本的操作系統軟件。
7. 可行性
軟件系統的開發設計，應確保技術上的可行性，適合招標人的核心需要，滿足主要功能需求，適應需求變化時的系統的免代碼自定義和功能模塊加減、調整。
8. 規范性
遵循國家局、煙草行業及安徽煙草商業企業有關標準要求及業務管理規范，信息分類編碼標準化、信息接口標準化。
9. 整體性
整個系統充分考慮了與現有營銷系統、物流系統、專賣系統、人力資源系統等其他相關系統的接口問題。
10. 經濟性和冗余性
系統設計緊貼客戶需求，同時為可能的增值服務留有空間，具有良好的性價比。系統留有適度的冗余，既可滿足近期業務發展的需求，又不會過多增加系統負荷。
11. 操作簡便性
系統人機界面友好，操作簡便，可以使用快捷鍵完成部分操作。
12. 可管理性和可維護性
系統充分考慮了應具有的良好的可管理性和可維護性。
1.3 總體架構設計
總體架構分為展現層、應用層、支撐層、數據層四個層次：
1）展現層通過微信平臺提供的企業號、服務號實現工業企業、企業內部員工、消費者、零售戶訪問應用的通道。
2）在應用層主要分為前臺和后臺兩個部分，前臺主要是為“工”、“商”、“零”、“消”提供訪問的功能和應用。后臺主要用于管理微信的企業號和服務號，同時為零售戶提供O2O的應用。
3）支撐層是為微信的前臺應用提供支撐，與現有的系統實現無縫對接，可以通過微信的平臺與后臺直接進行交互。
4）數據層利用現有的安徽煙草的數據倉庫，利用支撐層為微信的前臺提供數據支撐。
1.4 技術架構設計
1、系統的總體結構采用B/S/D瀏覽器/服務/數據庫的三層結構，系統中采用B/S結構，遵循J2EE體系架構。內外部應用均按照J2EE規范，使用java、jsp、servlet等技術，實現系統所需管理功能。
2、系統采用面向服務的架構（SOA），符合Web Service標準的訪問接口，應用軟件要使系統模塊化、構件化，以適應管理、業務流程的變化和使用權限的再分配。
3、微信應用可通過通訊網絡、Internet或局域網方式與服務器端后臺進行信息交互。
1.5 用戶關系拓撲
工業通過微信提供的公眾號可以獲得經營信息，以及商業提供的消費信息。
商業通過承擔平臺運營成本和提供各種便捷服務，可以獲得，消費者的消費信息、采集到市場的數據，提供客戶滿意度，同時通過公眾號，實現品牌的網上營銷。
零售戶通過微信提供的公眾號，提供徽映e家的掃碼數據，商品展示和送貨服務，可以查詢到貨源信息、實現訂單跟蹤、取得訂貨服務、通過商品展示與銷售、獲得固定客源。
消費者通過微信提供的公眾號提供消費行為和個人信息，可以獲得便捷，方便查找周邊商店、在線選購商品，并可以預約送貨上門，在商品選購和參與活動同時還可以獲得積分，兌換想要的商品，同時還可以獲得商業企業和零售戶提供的其他服務。
1.6 技術路線
本系統在技術架構上將完全符合安徽煙草信息化建設的總體技術框架。與安徽煙草目前已建的統一門戶、營銷、物流、三項工作等信息系統采用相同的技術平臺,后臺與門戶系統進行有效集成和整合，保持技術的延續性和一致性，實現業務系統的統一身份管理、統一權限管理和統一界面管理，前端采用HTML5開發，支持各種智能手機。
1.6.1 遵循J2EE標準技術架構
J2EE 應用服務器（Application Server）采用目前國際最先進的開發理念、擁有許多適合基于Web 的應用系統需求的特點：
三層結構體系——最適合Internet/Intranet網絡環境，可以使系統有很強的可擴展性和可管理性。
分布式環境——可以保證系統的穩定性，同時擁有較高的性能。
面向對象的模塊化組件設計——可以提高開發速度，降低開發成本。
采用JAVA技術——完全跨平臺，適應Internet需要，并能得到大多數廠商支持，保護用戶投資。
為了降低成本，并加快企業應用程序的設計和開發，J2EE 平臺提供了一個基于組件的方法，來設計、開發、裝配及部署企業應用程序。J2EE 平臺提供了多層的分布式的應用模型、組件再用、一致化的安全模型以及靈活的事務控制。使用戶不僅可以比以前更快的速度向市場推出創造性的客戶解決方案，而且，平臺獨立的、基于組件的J2EE 解決方案不會被束縛在任何一個廠商的產品和API 上。
J2EE提供了一個企業級的計算模型和運行環境用于開發和部署多層體系結構的應用。
J2EE的應用模型圖
客戶層（Client Tier）
J2EE 應用可以是基于Web 的，也可以是不基于Web 的。
在基于Web 的J2EE 應用中，用戶的瀏覽器在客戶層中運行，并從一個Web服務器上下載WEB 層中的靜態HTML 頁面或由JSP 或servlets 生成的動態HTML 頁面。
在不基于Web 的J2EE 應用程序中，一個獨立的客戶程序，可以不運行在一個HTML 頁面中，而是運行在其它一些基于網絡系統（比如手持設備或汽車電話）中的applet 程序。在客戶層中運行，并在不經過Web 層的情況下訪問Enterprise Oraclens。該不基于Web 的客戶層可能也包括一個JavaOraclens 類來管理用戶輸入，并將該輸入發送到在企業層中運行的Enterprise Oraclen 類來處理。
Web 層
J2EE Web 組件可以由JSP 頁面、基于Web 的applets 以及顯示HTML 頁面的servlets 組成。
調用servlets 或者JSP 頁面的HTML 頁面在應用程序組裝時與Web 組件打包在一起。就像客戶層一樣，Web 層包括一個JavaOraclens 類來管理用戶輸入，并將輸入發送到在業務層中運行的Enterprise Oraclens 類來處理。
運行在客戶層的Web 組件依賴容器來支持諸如客戶請求和響應及Enterprise Oraclen查詢等。
業務層
作為解決或滿足某個特定業務領域（比如山西煙草、銀行、或零售業）需要的邏輯的業務代碼由運行在業務層的Enterprise Oraclens 來執行。一個Enterprise Oraclens 從客戶程序處接收數據，對數據進行處理（如果需要），再將數據發送到企業信息系統層存儲。一個Enterprise Oraclens 還從存儲中檢索數據，并將數據送回客戶程序。運行在業務層的Enterprise Oraclens依賴于容器來為諸如事務、生命期、狀態管理、多線程及資源存儲池等提供通常都是非常復雜的系統級代碼。
業務層經常被稱作Enterprise JavaOraclens （EJB ）層。業務層和Web 層一起構成了3 層J2EE應用的中間層，而其它兩層是客戶層和企業信息系統層。
企業信息系統層
企業信息系統層包括企業的各種業務系統和數據庫。
1.6.2 基于SOA進行設計
什么是SOA（Service Oriented Architecture，SOA）？許多銷售商、應用程序供應商、系統集成商、架構師、作者、分析公司和標準機構對SOA都提供了定義。SOA的定義是多種多樣的，實際上更多的是對SOA定義的補充，且眾多定義相互之間是不沖突的。面向服務代表在商業和IT環境下關于服務的一種思考方式，SOA擁有各種各樣的定義是因為定義通常要針對一個特定的對象，如給一個CEO解釋SOA與給一個程序員解釋SOA是不同的。SOA是一個范式、一種思考方式，SOA對于架構和設計是一個有價值的系統。SOA是一種幫助系統發展過程中保持可擴展性和靈活性的方法，也是解決業務與IT缺口的橋梁。
組件化整體架構的核心SOA。SOA的中心思想是模塊化與封裝這兩大原則，模塊化將復雜的大任務的分解成相對簡單的小步驟，封裝則將其內部的復雜性屏蔽代之以用清晰的接口。在這兩項原則指導下，開發人員只需關注應用中與其相關的部分而無須知道其他部分的細節，只要各個組件都遵守接口“契約（Contract）”，這些組件的開發、測試和修改都相對獨立，無須太多的協調，使得基于SOA的應用易于開發和維護。
SOA是一種應用架構思想，它著眼于日常的業務應用，并將它們劃分為單獨的業務功能和流程，即所謂的服務。SOA使用戶可以構建、署和整合這些服務，且無需依賴應用程序及其運行計算平臺，從而提高業務流程的靈活性。這種業務靈活性可使企業加快發展速度，降低總體擁有成本，改善對及時、準確信息的訪問。SOA有助于實現更多的資產重用、更輕松的管理和更快的開發與部署。在當今的業務環境中，變化是毫無疑問的，因此快速響應客戶需求、市場機遇和外部威脅的敏捷性比以往任何時候都更顯重要。
面向服務的SOA體系架構的特點：
1、以業務為中心
SOA更多關注于用戶業務，通過業務人員參與SOA系統的規劃、設計和管理，使得IT系統能在對業務的深刻理解的基礎上進行構建，實現IT系統與用戶業務的密切結合。在具體實施中，通過把完成實際業務流程中的一項任務所需的IT資源組織為服務進行封裝，從而達到以業務為核心，通過業務選擇技術，避免技術制約業務的問題。
2、靈活適應變化
IT系統圍繞用戶業務構建，用戶業務在實現層通過表現為一系列松散耦合的”服務“來實現，這些服務可以根據用戶需求隨需組合，使得IT系統對于業務的適應能力明顯提高。
3、重用IT資源，提升開發效率
SOA強調對”服務“的重用，對原有IT資源的重用度提升是SOA帶來的關鍵效果之一，大量具有高重用的服務資源，為快速構建新的業務功能和業務系統奠定基礎，使得IT系統的開發和軟件生產效率得到提升。同時，重用過程有利于保護用戶前期的信息化投資和IT資產積累，節省IT系統開發成本，實現用戶信息化的可持續性建設與發展。
4、更強調標準
SOA的實現強調基于統一的標準，SOA系統建立在大量的開放標準和協議之上，以實現系統及信息的互聯互通和互操作。因此，SOA系統從規劃到實施，標準都至關重要。
SOA使得應用系統的設計清晰化而且促進組件的重用。應用系統中所有的接口的定義與信息模型――包括數據及其語義、對象與過程模型――都高度一致。很多的企業應用由于缺乏同一的長遠的規劃，通常情況下很少共享數據，幾乎從不共享程序邏輯。但很多的服務具有通用性，而非某一應用獨有，一個通用服務架構（Common Service Architecture）能幫助企業在上述的原則下共享部分數據和程序邏輯。通用服務的概念是企業架構中的一個重要的有機部分，主要包括下面的通用服務：
1）通用應用服務：如通用的數據模型訪問，數據的轉換等等。
2）通用基礎設施服務：包括應用的管理與診斷、日志、安全、系統的操作與維護。
3）通用系統服務：包括對不同的操作系統、網絡平臺以及其它的系統層的功能提供與平臺獨立的接口。
1.6.2.1 分層架構
典型的企業SOA平臺連接許多企業應用資源，應用用戶，并且負責許多服務提供者和服務消費者。通過把服務劃分為相同服務的組來得到管理效果。一個普通服務組使后臺系統（BES）資源對于服務消費者可用。另一個普通服務組連接應用用戶或者前端系統（FES）到SOA平臺。
編排服務連接基本服務到復合服務。將服務分組的做法可以有效的利用SOA平臺每層統一的特點。適當領域的技術，開發模式，測試裝置，部署配置，系統管理制度等，能為每層具體開發。
分層架構是最靈活強大的實現方法。簡單來說，SOA的服務來自于由后臺系統（BES）直接封裝后提供的一組接口，也就是存取服務。
整合邏輯也將被看作一組服務，此服務有良好定義的已發布接口。這些服務是更高水平的服務，它利用更低水平的后臺系統（BES）存取服務。這些服務實現被稱作編排或協調的功能。
最后，在一個企業整合環境中，這些更高水平協調或更低水平存取服務的大多數用戶應用將不直接支持服務接口。因此，另一組服務被要求組織服務具體到每個服務用戶前端系統（FES）。
這給出了分成架構的基礎，如下圖所示：
SOA平臺層次圖
這個架構中有三層。每層有唯一一組技術需求和唯一的作用。
存取服務層負責發布一組BES（后臺系統）的接口作為一個標準的服務。
協調服務層重新分組服務來實現整合邏輯。
用戶服務負責使FES（前端系統）可以訪問其它兩層發布的服務，這些服務通常是FES（前端系統）不能直接進行調用的。
1.6.2.2 存取服務層
存取服務層提供由集成平臺其余部分執行的終端服務。這層的關鍵架構的中心是設計和管理服務的重用。設計和開發存取服務需要應用資源域的技術，適配器開發和設置技術和消息組模型技術。
存取服務層是被發布的服務來提供單一后臺系統（BES）的接口，主要目標是在平臺上實現最大化的重用。其它層通過控件或通過一個發布接口來存取這些服務。它最簡化的形式僅僅是一個通過控件來暴露的后臺系統（BES）。例如一個J2EE連接架構適配器（J2EE CA）數據庫適配器被安裝和設置來把一個特殊的系統和每個需要的SQL語句所產生的服務連接到一起。然后這能夠通過整合應用視圖控件來存儲。
1.6.2.3 協調服務層
協調服務層主要是完成傳遞新的服務的功能，這些新的服務是對存取服務層提供服務的一個重新組織。本層的主要架構特點是靈活性。協調服務層通過正確實現數據集中、流程定義、以及創建理想服務的Message Flow工具實現了這種靈活性。
在這層中需要實現各種的集成邏輯，并發布成為一個完整的服務。本層利用訪問存取層向前端系統（FES）提供有意義的服務。
任何利用多于一個EIS系統的服務都需要納入到這一層中來。對于通過worklist實現人為交互的服務也需要納入到本層中來。正如上文中對于訪問存取層的描述，一些協作層中的服務可能僅訪問一個后臺系統（BES）系統。如果這些服務需要完成功能包含集成的需求而不僅僅是來自單個后臺系統（BES）系統，他們也同樣應臺包含在協作服務層中。適用于本層的一個簡單原則：任何不屬于消費層或訪問存取層的服務都屬于協作服務層。
獨立的數據集成服務，如提供數據轉換、數據映射（包括主鍵映射）、數據依賴路由的服務需要駐留在協作層。
1.6.2.4 請求服務層
請求服務層的主要目的是負責平臺和應用服務請求者（例如前端系統（FES）系統）之間的連接，本層服務提供：
協議映射－映射為服務發布接口協議：JMS和Web Services。
Paradigm映射－同步到異步以及vice-versa。
數據映射－數據格式映射，聚集等。
服務請求者包括基于多種架構的應用，還有包括胖客戶端、消息系統、套接字協議等在內的遺留系統服務請求者。一般都需要協議解釋服務。對于支持諸如Portal，B2B服務，多渠道等平臺協議，paradigm和數據格式的請求者，可以與平臺直接接口。
例如一個請求層服務收到某個前端系統（FES）發出的事件，但是這個事件不具備足夠的信息來調用相應的協作層，請求服務層的服務將完成接收事件，并向前端系統（FES）查詢相關信息的功能。這是一個明顯的功能加強，這類場景適合于請求服務層。當然，如果這個強化的過程需要向一個獨立的系統進行查詢，則意味著通過一個集成過程后成為請求服務層的一個獨立服務。
1.6.2.5 端到端的視角
值得指出的一點是在審視從前端系統（FES）到后臺系統（BES）系統之間的端到端通信時，這些層次都不是強制必須實現的。正如前文所講述的，請求服務層僅當需要提供對SOA平臺的標準接口技術進行訪問時才是必要的。若一個前端系統（FES）本身支持SOA平臺的標準，那么前端系統（FES）就可以直接訪問其提供的服務，而跳過請求服務層。同樣的，對于一些簡單的集成需求，如查詢獨立系統中的可用數據就不需要進行服務的重組。當然，推薦的方式是永遠不要忽略訪問存取層，它保證了后臺系統（BES）提供的各種服務在整個平臺中保持一致性和靈活性。它還避免了跳過所有層次的設計場景的出現，因此可以保證滿足平臺管理原則。
端到端的視角
還有一點值得一提，在一個集成場景中，很多系統既是后臺系統（BES）又是前端系統（FES），當然也不排除一些純前端系統（如Portal）和固有后端系統（如數據庫）的存在。當進行雙向松耦合通信（如使用JMS）時，一個雙向的集成需求可以轉為實施兩個單向的通信。這是一個在相同業務流程中既作前端系統（FES）又做后臺系統（BES）系統的例子。
1.6.2.6 設計模式和分層
存取訪問層和請求訪問層中以基本的服務居多，而協作層中多為復合類型的服務。
作為一個一般的規律，服務最好以無狀態的方式展示以獲取最佳的性能，采用異步模式調用來保持與其客戶端的松耦合狀態。
無論如何，已經確證若訪問存取層的雙向服務是異步的，協作層服務將變為有狀態的。因此擁有無狀態、異步服務的期望是不能在所有層中得到滿足的。作為一種權衡考慮，對于雙向通信場景來說，在松耦合和性能之間最好的折中方式是在低層次的訪問存取層中盡可能實現同步服務（例如后臺系統（BES）系統中的服務都實現同步調用），而在較高層次的協作層中實現異步服務。
|
高層次的設計架構 |
更進一步的細節 |
|
雙向訪問存取層的服務應盡可能的使用同步方式。 |
這樣可以為協作層帶來最佳的性能。但是注意在峰值壓力下服務的響應時間應盡可能的快，且后臺系統（BES）應該有能力應對這些負荷。如果不能滿足上述要求，應該使用異步服務調用。 |
|
協作層服務服務通常應采用異步方式。 |
這樣可以最大限度的做到松耦合。 |
上述兩點可以保證包含一個請求服務層服務，一個協作層服務，以及多個訪問存取層服務的雙向調用典型場景的最佳性能。在這類情況中，只要后臺系統（BES）接口允許，所有的除請求服務層之外的服務都采取無狀態方式。
上表中第二條標準（異步協作層服務）在屏蔽后端系統實施更改方面有著突出的優勢，使后端的變化對協作服務層客戶端來說是透明的。無論是訪問存取層服務提供同步抑或異步接口，它都可以在協作層中保留一個異步接口。
有些場景很適合同步交互模式－ Portal對SOA平臺服務的訪問就是其中一種。通過以下的標準可以做出是否合適與上述場景的判斷：
要求端到端的響應時間。
對于請求者的最初響應取決于由目標后臺系統（BES）發出的響應。
目標后臺系統（BES）在峰值負荷下可以提供更快的響應。
目標后臺系統（BES）需要更高的可用性。
在這些場景中，建議以同步方式實現服務，但是要借助非同步模式來為協作層服務提供異步接口。因此，那些不需要高吞吐量的客戶端可以使用異步接口。
|
高層次的設計架構 |
更進一步的細節 |
|
為了更高的性能，盡可能使用同步服務。 |
一些用例的非功能需求需要更快的響應和更高的容量。 |
|
如果一個流程運行時間較長，需要進行它與客戶端維持長會話的相應配置。 |
流程的會話持續時間通過它的最大壽命（max-age）屬性進行配置，默認值是一天。 |
|
為同步協作層服務提供一個異步接口，提供更多的松耦合特性。 |
第二個接口的實現需要利用非異步模式。 |
在某些場景中，訪問存取層服務需要異步耦合方式，例如，需要訪問一個復合協作服務，而不是一個事務性、非XA的資源。在這種情況下，最佳的方式為保持訪問存取層服務的同步模式，且需要以非同步模式進行實施。
高層次設計架構 更進一步的細節
如果需要異步調用一個同步存取訪問層服務，保持服務的同步模式，但是以非同步方式實施。項目特定的需求不應阻礙訪問存取層服務的可重用性。
1.6.3 采用通用的MVC模式構建應用
在傳統的Web業務里，例如ASP，CGI等，通常開發者將業務邏輯，數據邏輯、展示邏輯等混雜在一起，在同一個頁面里既進行后臺數據庫的訪問和操作，同時還包含業務流程和頁面表示。這樣編寫出來的程序，既不利于程序員對業務代碼的調試，同時也不利于編輯人員進行交互頁面的設計。同時系統也不具備可擴展性，當要在現有業務上進行擴展的時候，通常無法借助于現有的資源和應用，而只能夠重新編寫，大大增加了投資，延長了系統上線的時間。
在如今的企業信息化應用系統的開發中，應該采用通行的MVC模式來構建應用。這種結構解決了前面所述的所有問題，可以完全地支持它的實現。MVC的邏輯圖如下：
MVC模式
通過這種方案，可以迅速地實現整個業務，其優勢和特點如下：
Model層由EJB組件來實現，EJB將具體的業務封裝在組件內部，具備安全、高性能、可重用等優秀的特征。
View層由JSP和HTML組成。這一層次的特點是能夠真實地展示和客戶交互的界面，具備可描繪的功能。同時能夠嵌套動態數據，可以進行動態頁面的展示。同時可以借助J2EE的標準以及相關產品方便地進行客戶端的個性化定制。根據每個客戶的需求來展示不同風格的界面。
Controller是非常重要的一層，這一層是連接View和Model的紐帶，同時也是將這兩層進行最大限度分離的工具。通常由Servlet來實現，Servlet和JSP雖然同樣都屬于頁面展示工具，但分屬兩層。主要在于JSP以腳本語言的形式存在，它的主要優勢是進行動態數據的Web展示，而Servlet是一個完整的Java程序，進行業務的調用和流程的處理是它的長處。
通過這種模型的建立，的應用系統具備了非常好的性能和可擴展性。將業務組件和展示頁面進行分離，并通過Controller來描述調用關系，一方面可以提高效率，另一方面也可以增加系統擴充的能力，使的系統可以適應最快速度的業務擴展。
1.6.4 采用SSH開發框架實現應用
典型的J2EE三層結構，分為表現層、中間層（業務邏輯層）和數據服務層。三層體系將業務規則、數據訪問及合法性校驗等工作放在中間層處理。客戶端不直接與數據庫交互，而是通過組件與中間層建立連接，再由中間層與數據庫交互。
表現層是傳統的JSP技術，自1999年問世以來，經過多年的發展，其廣泛的應用和穩定的表現，為其作為表現層技術打下了堅實的基礎。
中間層采用的是流行的Spring+Hibernate，為了將控制層與業務邏輯層分離，又細分為以下幾種。
Web層，就是MVC模式里面的“C”（controller），負責控制業務邏輯層與表現層的交互，調用業務邏輯層，并將業務數據返回給表現層作組織表現，該系統的MVC框架采用Struts。
Service層（就是業務邏輯層），負責實現業務邏輯。業務邏輯層以DAO層為基礎，通過對DAO組件的正面模式包裝，完成系統所要求的業務邏輯。
DAO層，負責與持久化對象交互。該層封裝了數據的增、刪、查、改的操作。
PO，持久化對象。通過實體關系映射工具將關系型數據庫的數據映射成對象，很方便地實現以面向對象方式操作數據庫，該系統采用Hibernate作為ORM框架。
Spring的作用貫穿了整個中間層，將Web層、Service層、DAO層及PO無縫整合，其數據服務層用來存放數據。
1.6.4.1 Hibernate
在傳統的程序結構中，只要有一點小的需求發生改變，將意味著放棄整個頁面。或者改寫。雖然前期的開發速度快，除非可以保證以后永遠不會改變應用的結構，否則不要采用這種結構。
采用Hibernate作為持久層技術的最大的好處在于：可以完全以面向對象的方式進行系統分析、系統設計。
1.6.4.2 Spring
DAO模式需要為每個DAO組件編寫DAO接口，同時至少提供一個實現類，根據不同需要，可能有多個實現類。可以用Spring容器代替DAO工廠。
通常情況下，引入接口就不可避免需要引入工廠來負責DAO組件的生成。Spring實現了兩種基本模式：單態模式和工廠模式。而使用Spring可以完全避免使用工廠模式，因為Spring就是個功能非常強大的工廠。因此，完全可以讓Spring充當DAO工廠。
由Spring充當DAO工廠時，無須程序員自己實現工廠模式，只需要將DAO組件配置在Spring容器中，由ApplicationContext負責管理DAO組件的創建即可。借助于Spring提供的依賴注入，其他組件甚至不用訪問工廠，一樣可以直接使用DAO實例。
1.6.4.3 Struts
Struts跟Tomcat、Turbine等諸多Apache項目一樣，是開源軟件，這是它的一大優點。使開發者能更深入的了解其內部實現機制。
除此之外，Struts的優點主要集中體現在兩個方面：Taglib和頁面導航。Taglib是Struts的標記庫，靈活動用，能大大提高開發效率。另外，就目前國內的JSP開發者而言，除了使用JSP自帶的常用標記外，很少開發自己的標記，或許Struts是一個很好的起點。
關于頁面導航，我認為那將是今后的一個發展方向，事實上，這樣做，使系統的脈絡更加清晰。通過一個配置文件，即可把握整個系統各部分之間的聯系，這對于后期的維護有著莫大的好處。尤其是當另一批開發者接手這個項目時，這種優勢體現得更加明顯。
1.6.4.4 SSH開發框架
軟件行業的技術更新很快，雖然軟件行業的發展不快，但小范圍的技術更新特別快。一旦由于客觀環境的變化，不得不更換技術時，如何保證系統的改變最小呢？答案還是選擇優秀的架構。而SSH開發框架正是這樣一種優秀的框架。
它可以讓開發人員減輕重新建立解決復雜問題方案的負擔和精力；它可以被擴展以進行內部的定制化；并且有強大的用戶社區來支持它。它的好處主要表現以下兩個方面：
1、 開發效率
軟件工程是個特殊的行業，不同于傳統的工業，例如電器、建筑及汽車等行業。這些行業的產品一旦開發出來，交付用戶使用后將很少需要后續的維護。但軟件行業不同，軟件產品的后期運行維護是個巨大的工程，單純從前期開發時間上考慮其開發效率是不理智的，也是不公平的。眾所周知，對于傳統的ASP和 PHP等腳本站點技術，將整個站點的業務邏輯和表現邏輯都混雜在ASP或PHP頁面里，從而導致頁面的可讀性相當差，可維護性非常低。即使需要簡單改變頁面的按鈕，也不得不打開頁面文件，冒著破壞系統的風險。但采用嚴格分層J2EE架構，則可完全避免這個問題。對表現層的修改即使發生錯誤，也絕對不會將錯誤擴展到業務邏輯層，更不會影響持久層。因此，采用J2EE分層架構，即使前期的開發效率稍微低一點，但也是值得的。
2、 需求的變更
一般來說，很少有軟件產品的需求從一開始就完全是固定的。客戶對軟件需求，是隨著軟件開發過程的深入，不斷明晰起來的。因此，常常遇到軟件開發到一定程度時，由于客戶對軟件需求發生了變化，使得軟件的實現不得不隨之改變。當軟件實現需要改變時，是否可以盡可能多地保留軟件的部分，盡可能少地改變軟件的實現，從而滿足客戶需求的變更？答案是——采用優秀的解耦架構。這種架構就是J2EE的分層架構，在優秀的分層架構里，控制層依賴于業務邏輯層，但絕不與任何具體的業務邏輯組件耦合，只與接口耦合；同樣，業務邏輯層依賴于DAO層，也不會與任何具體的DAO組件耦合，而是面向接口編程。采用這種方式的軟件實現，即使軟件的部分發生改變，其他部分也盡可能不要改變。
1.6.5 遵循組件化分層結構設計思想構建應用
組件化是企業信息化應用系統建設的一個整體趨勢。由于組件所具有預制性、封裝性、透明性、互操作性、通用性的特征，這使得“Write once，Run everywhere”成為技術上的可能。
組件化的整體架構一個最明顯的好處就是組件的開放只涉及到業務邏輯的開發和將業務邏輯的接口用標準的接口進行封裝，而那些重要和復雜的系統基礎服務（infrastructure service），如狀態管理（State Management）、交易（Transaction）、安全、資源池（Resource Pooling）等等。
采用組件技術可以實現靈活的接口定義、執行代碼運行時刻的聯編/載入以及通訊網絡協議，支持異構分布應用程序間的互操作性及獨立于平臺和編程語言的組件重用。
組件化的整體架構具有下面這些優勢：
1）多功能容器，對外部屏蔽了復雜度；
2）適合于大量并行開發；
3）“黑盒”組件的實現鼓勵了更多的靈活性；
4）可進行針對接口的測試；
5）封裝后的組件在可以在內部修改業務邏輯，而保持同樣的接口，形成一個屏蔽變化的“防火墻”；
6）在使用上有更好的一致性；
采用組件技術可以實現靈活的接口定義、執行代碼運行時刻的聯編/載入以及通訊網絡協議，支持異構分布應用程序間的互操作性及獨立于平臺和編程語言的組件重用。
以組件為基礎的應用架構大大簡化多層（Multi-tier）和Web應用的開發，利用應用服務器來避免應用客戶端和數據庫及其它企業信息系統（Enteprise Information System，EIS）的連接。客戶端使用高層（high-level）的與平臺獨立的調用方式通過應用服務器訪問數據庫及其它企業信息系統。這樣不僅屏蔽了企業內部IT架構的復雜性和異構性，也使得這樣開發的應用具有良好的可移植性。
系統分層模型
1.6.5.1 分層設計基本準則
1、不得跨層調用，每一層都只與直接相臨的層進行通信。
2、上面各層都建立在下層的基礎上，隱藏下層的信息并為上層提供服務。
3、各層要封裝自己的實現，向前一層提供訪問接口。
4、各層支持分布式的部署，即可部署于不同的容器實例中。
1.6.5.2 各層說明
客戶層
系統最終用戶的使用界面和設備。包括基于瀏覽器的瘦客戶端和基于GUI的胖客戶端應用。
1、盡量減少與后臺的交互。
2、界面符合用戶的使用習慣。
- 交互層
用戶和系統之間的交互管理，提供用戶層的展現邏輯和對應用層的訪問接口。也包括單點登錄、會話管理、用戶輸入的邏輯校驗等功能。
1、客戶層訪問的交互協議盡可能使用http/https。
2、是客戶層的統一接入點。
- 應用層
業務邏輯的接口，實現業務流程的控制，是業務領域層的服務接口。
1、可以使用類似Session的模式實現。
2、啟動事務控制。
3、公共的業務邏輯要集中處理。
- 業務領域層
根據業務需求進行抽象的業務對象模型，包括業務規則和邏輯處理的實現。
- 資源訪問層
對系統的各種資源和外部系統統一的訪問邏輯的實現。不作語義轉換，只實現純粹的資源訪問。
- 資源層（EIS）
各種信息系統資源，例如：RDBMS、文件系統、原有系統、消息服務、郵件服務、交易服務中間件等。
1.6.6 采用velocity模板引擎
Velocity是一個基于java的模板引擎（template engine）。它允許任何人僅僅簡單的使用模板語言（template language）來引用由java代碼定義的對象。當Velocity應用于web開發時，界面設計人員可以和java程序開發人員同步開發一個遵循MVC架構的web站點，也就是說，頁面設計人員可以只關注頁面的顯示效果，而由java程序開發人員關注業務邏輯編碼。Velocity將java代碼從web頁面中分離出來，這樣為web站點的長期維護提供了便利，同時也為我們在JSP和PHP之外又提供了一種可選的方案。 Velocity的能力遠不止web站點開發這個領域，例如，它可以從模板（template）產生SQL和PostScript、XML，它也可以被當作一個獨立工具來產生源代碼和報告，或者作為其他系統的集成組件使用。Velocity也可以為Turbine web開發架構提供模板服務（template service）。Velocity+Turbine提供一個模板服務的方式允許一個web應用以一個真正的MVC模型進行開發。
1.6.7 支持主流中間件及數據庫
本系統支持的中間件包括weblogic、webspere在內的等主流中間件，以及包括Oracele/DB2/SqlServer等在內的業界主流大型數據庫。