市場部文件PAGEPAGE1附件二十九：產品方案技術白皮書一、背景概述 21、研發背景 22、產品定位 2二、產品方案功能介紹 21、設計理念 22、系統拓撲圖 23、系統構架描述 24、系統功能介紹 25、產品方案規格 2四、產品方案應用介紹 31、應用模式 32、應用流程 33、應用環境 3五、產品方案特性介紹 31、技術特性 32、應用特性 33、系統特性 3六、產品方案技術介紹 31、相關技術 32、技術指標 4七、產品方案測評數據 4八、實施運維方式說明 4九、售后服務方式說明 4一、背景概述1、研發背景介紹用戶需求背景、該產品所在行業信息化建設背景、產品所涉及的相關政策簡述等，以說明該產品的研發背景，以及滿足的客戶需求。2、產品定位為了滿足客戶以上需求，該產品具有什么功能，能夠解決什么問題。二、產品方案功能介紹1、設計理念該產品方案的設計思路。2、系統拓撲圖使用統一的圖標，制作系統拓撲圖。3、系統構架描述按照系統的構成，分類對系統進行描述。4、系統功能介紹詳細闡述系統的主要功能。5、產品方案規格產品方案不同的規格介紹，或者對產品方案技術規格的介紹。四、產品方案應用介紹1、應用模式該產品方案包括的應用模式類型，或者針對不同類型客戶的解決方案。2、應用流程該產品方案的應用流程。3、應用環境描述該產品所運行的應用環境。五、產品方案特性介紹1、技術特性主要是性能先進性、功能齊全性、系統兼容性、技術穩定性等。2、應用特性 主要是部署靈活性、可擴展性、管理方便性、易用性等。3、系統特性 對系統的主要特性進行描述，根據產品不同和競爭優勢的不同而不同。六、產品方案技術介紹1、相關技術主要應用技術的介紹，以及該技術的優勢。2、技術指標針對技術參數進行描述。七、產品方案測評數據產品方案主要測評數據，可以是內部測評數據，也可以是第三方的測評數據。八、實施運維方式說明該產品方案的實施運營方式，以及實施運營需要注意問題的說明。九、售后服務方式說明該產品方案的售后服務方式、服務標準、服務內容說明，以及不同服務方式的報價。服務業綜合業務管理系統系統架構說明書一、概要本說明書對服務業綜合業務管理系統的整體框架進行分塊說明，對系統的采用技術點的技術點進行闡述，通過視圖與描述展示整個系統框架的結構與層次。二、目標 構建服務業綜合業務管理系統J2EE應用的開發框架，注入Spring支撐，使用兼具靈活性與使用性的ibatis作為持久層，使所有系統能規范開發組件、提高開發效率，易于統一升級和維護。三、架構設計3.1、架構分析 1、服務業綜合業務管理系統采用B/S模式。B/S模式具有分布性特點，可以隨時隨地進行查詢、瀏覽等業務處理。其業務擴展簡單方便，通過增加網頁即可增加服務器功能。而且后期維護方面只需要改變網頁，即可實現所有用戶的同步更新 2、搭建輕量級J2EE框架—Spring框架。J2EE為搭建具有可伸縮性、靈活性、易維護性的系統提供了良好的機制。J2EE框架使得開發的產品更加高效，更加健壯，在伸縮性和穩定性上面也有著顯而易見的效果。而Spring是一個完美的框架“黏合劑”。它提供了一種管理對象的方法，可以把中間層對象有效地組織起來。他的分層結構可以增量引入項目。而非侵入性應用程序對SpringAPI的依賴可以減至最小限度。 3、使用兼具靈活性與實用性的ibatis作為系統的持久層。Ibatis是支持普通SQL查詢，存儲過程和高級映射的優秀持久層框架。Ibatis將代碼和sql語句分離，sql可以寫在xml中，結構清晰，靈活配置，對平臺支持性大幅度提高。3.2、設計思想 1、系統技術架構采用主流的MVC模式MVC思想將一個應用分成三個基本部分：Model（模型）、View（視圖）和Controller（控制器），這三個部分以最少的耦合協同工作，從而提高應用的可擴展性及可維護性。直接向數據庫發送請求并用HTML顯示,開發速度往往比較快,但由于數據頁面的分離不是很直接,因而很難體現出業務模型的樣子或者模型的重用性。產品設計彈性力度很小，很難滿足用戶的變化性需求。MVC要求對應用分層，雖然要花費額外的工作，但產品的結構清晰，產品的應用通過模型可以得到更好地體現。

首先，最重要的是應該有多個視圖對應一個模型的能力。在目前用戶需求的快速變化下，可能有多種方式訪問應用的要求。例如，訂單模型可能有本系統的訂單，也有網上訂單，或者其他系統的訂單，但對于訂單的處理都是一樣，也就是說訂單的處理是一致的。按MVC設計模式，一個訂單模型以及多個視圖即可解決問題。這樣減少了代碼的復制，即減少了代碼的維護量，一旦模型發生改變，也易于維護。其次，由于模型返回的數據不帶任何顯示格式，因而這些模型也可直接應用于接口的使用。

再次，由于一個應用被分離為三層，因此有時改變其中的一層就能滿足應用的改變。一個應用的業務流程或者業務規則的改變只需改動MVC的模型層。

控制層的概念也很有效，由于它把不同的模型和不同的視圖組合在一起完成不同的請求，因此，控制層可以說是包含了用戶請求權限的概念。

最后，它還有利于軟件工程化管理。由于不同的層各司其職，每一層不同的應用具有某些相同的特征，有利于通過工程化、工具化產生管理程序代碼。2、AOP權限控制以及運行日志AOP是AspectOrientedProgramming的縮寫，意思是面向方面編程，一種新興的編程技術。AOP實際是GoF設計模式的延續，設計模式孜孜不倦追求的是調用者和被調用者之間的解耦，AOP可以說也是這種目標的一種實現。它可以解決OOP和過程化方法不能夠很好解決的橫切（crosscut）問題，如：事務、安全、日志等橫切關注。當未來系統變得越來越復雜，橫切關注點就成為一個大問題的時候，AOP就可以很輕松的解決橫切關注點這個問題。AOP引進了ASPect，它將影響多個類的行為封裝到一個可重用模塊中，它對橫切關注點進行模塊化，從而消除了OOP引起的代碼混亂和分散問題，增強了系統的可維護性和代碼的重用性。3、擴展數據權限控制的RBAC基于角色的訪問控制（Role-BasedAccessControl）作為傳統訪問控制（自主訪問，強制訪問）的有前景的代替受到廣泛的關注。在RBAC中，權限與角色相關聯，用戶通過成為適當角色的成員而得到