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