互聯(lián)網(wǎng)協(xié)同運輸管理系統(tǒng)需求協(xié)同運輸管理系統(tǒng)需求v2.0

1、互聯(lián)網(wǎng)協(xié)同運輸管理系統(tǒng)需求分析說明書 v2.0v2.0目錄、項目背景 . 3 31 1、問題的提出 . 3 32 2、解決方法 . 5 53 3、項目可行性 . 6 64 4、開發(fā)內(nèi)容 . 8 8、系統(tǒng)整體架構(gòu) . 9 91 1、系統(tǒng)架構(gòu) . 9 92 2、關(guān)鍵技術(shù)解決 . 1212、開發(fā)功能 . 21211 1、運營支持系統(tǒng) . 21212 2、業(yè)務(wù)應(yīng)用系統(tǒng) . 24243 3、客戶服務(wù)系統(tǒng) . 3333互聯(lián)網(wǎng)協(xié)同運輸管理系統(tǒng)需求分析說明書 v2.0v2.0一、項目背景1、問題的提出中國經(jīng)濟連續(xù)二十幾年高速增長，GDPGDP也已經(jīng)翻了 2 2翻以上，20062006年更達(dá)到前所未有的2 0

2、9 4 0 7億元，其中全國社會物流總額達(dá) 59.659.6萬億元，物流業(yè)增加值為 1.411.41萬億 元，宏觀環(huán)境形勢喜人，物流產(chǎn)業(yè)蘊藏著巨大商機。伴隨中國經(jīng)濟高速增長的物流業(yè)，也于二十世紀(jì)九十年代在中華大地如火如荼地發(fā)展 起來，進入二十一世紀(jì)，物流業(yè)發(fā)展迎來了黃金時期，進入了發(fā)展加速時期。面對國內(nèi)物流大發(fā)展，仿佛中國已經(jīng)跨入現(xiàn)代物流先進國家行列，果真如此嗎？劃分 傳統(tǒng)物流與現(xiàn)代物流主要標(biāo)志是察看物流信息化程度，現(xiàn)代物流依托于現(xiàn)代經(jīng)濟，而現(xiàn)代 社會卻是信息社會，產(chǎn)業(yè)托起物流是定論，現(xiàn)代物流即建立在信息技術(shù)基礎(chǔ)上，傳統(tǒng)物流 即傳統(tǒng)貨運建立在信息化程度不高的前工業(yè)社會，所以信息化便成了傳統(tǒng)物流

3、與現(xiàn)代物流 的分界點?，F(xiàn)代經(jīng)濟社會物資流通目的為了產(chǎn)生增值及增值服務(wù)，根據(jù)客戶需求使得產(chǎn)品產(chǎn)生空 間上位移，從而使得產(chǎn)品得到增值。物流便應(yīng)運而生，依托于現(xiàn)代信息技術(shù)，物流除滿足 客戶需要獲取一定利潤報酬，物流還為客戶提供多功能、多角度增值服務(wù)，如信息、配送、 包裝、流通加工、產(chǎn)品回收再利用等，中國物流亦因此模式而生?，F(xiàn)代物流依托于信息技術(shù)，沒有高度發(fā)達(dá)的信息技術(shù)，就不能稱真正意義上的物流， 因為發(fā)達(dá)的信息技術(shù)依賴公司的管理水準(zhǔn)、公司理念，反映出公司的人員素質(zhì)，同時決定 公司服務(wù)水準(zhǔn)，最后便在物流集成上顯真功夫。橫覽中國物流企業(yè)，在20012001 年在冊物流企業(yè)有 6060 萬之眾，如今有百萬

4、之眾，都列為第三方物流，內(nèi)質(zhì)比較能稱上合格的第三方物流 企業(yè)為數(shù)不超百家，究其原因在于信息化深入程度決定物流企業(yè)服務(wù)水準(zhǔn)高低，從而將絕 大部分物流企業(yè)拒之于第三方物流企業(yè)門外，稱為準(zhǔn)第三方物流。中國的第三方物流企業(yè) 形態(tài)上像第三方，內(nèi)核上卻在從事傳統(tǒng)貨運、運輸、倉儲等低等業(yè)務(wù)，根本無法從事集成 工作，如VMIVMI、分貨架式配送、JITJIT或CRPCRP傳統(tǒng)物流公司無法做到。中國物流企業(yè)則表現(xiàn)為“散、亂、差、小、低”，即網(wǎng)點散、管理混亂、服務(wù)質(zhì)量差、規(guī)模小、服務(wù)層次低，因而當(dāng)下提供的物流服務(wù)比較有限，主要集中在分銷物流，擔(dān)負(fù)著 運輸、倉儲、配送三種功能，兼些在途包裝功能，屬于簡單、低級、無附

5、加值的服務(wù)，如 供應(yīng)物流、生產(chǎn)物流及目前國家大力加強環(huán)保即將形成市場的廢品回收再利用物流均無物 流企業(yè)涉獵其中，所以極大欠缺信息、流通加工、包裝、運輸倉儲配送一體化、咨詢服務(wù)、 物流集成等功能。誠然如此，然而社會物流需求未降反升，物流需求方不僅為農(nóng)產(chǎn)品、企業(yè)、商貿(mào)、政 府，目前更多跡象表明民間物流需求已形成巨大洪流，推動著物流業(yè)前行，很多快遞及物 流企業(yè)開始介入民間物流市場，瓜分這一市場。民間物流需方多是家庭、個體、個人，是弱勢群體，他們因貨量少、發(fā)貨頻次低、交 易額小等因素，使他們陌生供方市場，與供方市場隔離開來，經(jīng)常因很多物流企業(yè)不誠信 使他們吃啞巴虧，投訴無門。如何甄選合格供應(yīng)商、以公道

6、價格發(fā)貨、保證雙方交易安全 等等，便是民間物流需求方向業(yè)界、社會、政府發(fā)出最強烈的呼聲。再則，少部分物流企業(yè)有自己的信息系統(tǒng)，由于當(dāng)初開發(fā)時未考慮到今后擴展及與上下游客戶的對接，無法實現(xiàn)從ECR-EOS-QR-VMI-JIT/VMIECR-EOS-QR-VMI-JIT/VMI，通過EDIEDI進入企業(yè)ERPERP系統(tǒng)過程信息系統(tǒng)自動轉(zhuǎn)變，所以不能給上下游企業(yè)提供增值鏈上服務(wù)和附加值服務(wù)。同時國內(nèi)物流軟件品牌比較分散，技術(shù)上也缺乏標(biāo)準(zhǔn)化知道，軟件供應(yīng)商對于物流業(yè) 的了解還不很深入，造成供應(yīng)商重技術(shù)開發(fā)，輕業(yè)務(wù)應(yīng)用的偏向。不僅使好多功能束之高 閣，或不適用于物流企業(yè)，還使得不同物流軟件間很難實現(xiàn)數(shù)

7、據(jù)對接，更難言數(shù)據(jù)交互。所以說，面對這樣的客戶需求，為解決供應(yīng)鏈上的如何更加快速有效的將發(fā)貨人（供 應(yīng)商）的產(chǎn)品運到接受人，勢必對承運商（或第三方物流公司 ）提出了更高要求，若還是采用傳統(tǒng)的方法與手段，根本就不能滿足實際的需求了。那么，我們總結(jié)一下，傳統(tǒng)運輸存在哪些問題呢？（1 1）經(jīng)營分散和企業(yè)的集約化，規(guī)?；潭容^低（2 2）服務(wù)質(zhì)量問題較為嚴(yán)重（3 3）運輸組織與經(jīng)營技術(shù)以及理念落后（ 4 4）運輸裝備和設(shè)施落后（5 5）政策導(dǎo)向不明確和政府管理方式與手段不適應(yīng)發(fā)展的需要（ 6 6）信息技術(shù)手段落后，無法實現(xiàn)協(xié)同工作2、解決方法因此，傳統(tǒng)物流必須提升管理、更新觀念、轉(zhuǎn)變政府管理方式、形成

8、現(xiàn)代傳統(tǒng)運輸。 有鑒于此，新華物流網(wǎng)絡(luò)有限公司提出了基于下一代互聯(lián)網(wǎng)技術(shù)，第四方物流提供 ASPASP 平 臺技術(shù)軟件構(gòu)想，開發(fā)“物流電子商務(wù)及互聯(lián)網(wǎng)SCMSCM平臺”，簡稱“一網(wǎng)兩臺”，利用物流電子商務(wù)平臺給供需上方創(chuàng)造盈利機會，通過互聯(lián)網(wǎng)SCMSCM平臺實現(xiàn)物流服務(wù)，達(dá)到節(jié)能、增效目的?！耙痪W(wǎng)兩臺”中“一網(wǎng)”指新華物流網(wǎng)，“兩臺”指物流電子商務(wù)平臺和互聯(lián)網(wǎng)SCMSCM平臺 （ 即互聯(lián)網(wǎng)供應(yīng)鏈管理平臺 ） 。供需雙方通過物流電子商務(wù)發(fā)布各自商務(wù)訊息，尋找物 流合作伙伴，進行商務(wù)溝通，完成第一次商務(wù)后的現(xiàn)金交割（由第三方管理現(xiàn)金），實現(xiàn) 物流過程（即物體發(fā)生空間位移），給需方售后服務(wù)，及事后彼

9、此信用評判，服務(wù)完成后 費用轉(zhuǎn)移。其中亮點將目前流行的 KPIKPI 考核體系網(wǎng)絡(luò)化，用公共信息欄形式向所有物流供 需方公開，讓供需方信用度曝光于網(wǎng)絡(luò)公共平臺，讓民意監(jiān)督行業(yè)行風(fēng)，迫使供方和需方 改進工作，努力提高服務(wù)水平，從而促進整個行業(yè)的誠信度不斷提高。在多次完成合作任務(wù)后，供方和需方將慎重選擇那些誠信度高，能力強的企業(yè)作為自己的供方和客戶，不斷累積，做長合作鏈，完成甄選任務(wù)，進入結(jié)盟狀態(tài)的互聯(lián)網(wǎng)SCMSCM平臺。另外，在能確保供應(yīng)鏈長期穩(wěn)定和有效性假設(shè)前提后，建立供應(yīng)鏈模型，確立業(yè)務(wù)發(fā) 生模式，選擇業(yè)務(wù)功能，如 CRMCRM 、運輸管理、倉儲管理、配送管理、包裝、流通加工、裝 卸搬運和信

10、息功能，通過業(yè)務(wù)發(fā)生模式帶動控制模式的啟動，從而實現(xiàn)諸如ECRECR EOSEOSQRQRVMIVMI JIT/CRPJIT/CRP等諸多技術(shù)，滿足更多客戶要求?！耙痪W(wǎng)兩臺”優(yōu)點明顯： 通過平臺為物流供應(yīng)商提供費用低廉、功能強大、不斷升級版物流管理系統(tǒng)，解決 中小物流企業(yè)信息化程度低的問題。 通過伙伴的加入，消除面向單個企業(yè)物流管理軟件不能進行數(shù)據(jù)交互的障礙，順利 實施不同網(wǎng)點、不同物流企業(yè)間網(wǎng)絡(luò)協(xié)同，產(chǎn)生網(wǎng)絡(luò)化聯(lián)動，實現(xiàn)網(wǎng)絡(luò)化、規(guī)模化運作。 運用集成技術(shù)集成物流各系統(tǒng)，利用數(shù)據(jù)共享優(yōu)點順利實現(xiàn)各模塊間數(shù)據(jù)交互，使 得界面更加友好，工作量大為減輕。 強勢企業(yè)介入組建供應(yīng)鏈，不但能保持供應(yīng)鏈長期

11、穩(wěn)定，能平衡各方利益，還規(guī)模 化運作，推動產(chǎn)業(yè)鏈優(yōu)化，發(fā)揮強集聚效應(yīng)。 利用電子商務(wù)平臺，為供需方提供交流場所，整合資源，減少交易成本，社會效應(yīng) 明顯；通過第三方擔(dān)保使交易更加安全，保證供需方利益；誠信體系建立，推動企業(yè)加快 建立誠信步伐，也迫使各方提高管理水平和服務(wù)質(zhì)量，以確保企業(yè)信用。3、項目可行性新華物流網(wǎng)絡(luò)有限公司提出了基于下一代互聯(lián)網(wǎng)技術(shù)，第四方物流提供 ASPASP 平臺技術(shù) 軟件構(gòu)想， 開發(fā)“物流電子商務(wù)及互聯(lián)網(wǎng) SCMSCM 平臺” 是具有很強的現(xiàn)實意義與社會效益的。 在管理、技術(shù)、經(jīng)濟效益與社會效益方面都是可行的。1 1）、從物流管理角度看項目可行性我們已建立和掌握運輸?shù)淖罴?/p>

12、實踐， 最佳運輸實踐對于供應(yīng)鏈的無縫連接起到非常重要 的作用。 最佳運輸實踐主要指良好的運輸控制和集中運輸管理； 建立一個核心運輸計劃； 制 訂正確合同條款；撰寫運輸狀態(tài)報告并使訂單、運輸可視化； 不斷改進運作程序； 實施準(zhǔn)確 的貨物成本配置和成本報告；進行運輸成本分析等。電子商務(wù)平臺的成員之間對共同利益的理解將進一步提高， 保證一定的開放性， 進行信 息共享， 供應(yīng)鏈各方認(rèn)識到互聯(lián)網(wǎng)協(xié)同運輸管理是供應(yīng)鏈活動中的重要部分， 成員之間遇到 問題相互幫助，相互理解，工作努力并相互協(xié)調(diào)，進行合作；相互信任，利益共享等。2 2）、從信息技術(shù)角度看項目可行性互聯(lián)網(wǎng)協(xié)同運輸?shù)某晒﹄x不開先進的信息技術(shù)， 它

13、可以保證數(shù)據(jù)傳輸真實， 減少交易成 本和風(fēng)險。 信息技術(shù)是互聯(lián)網(wǎng)協(xié)同運輸管理的神經(jīng)系統(tǒng)， 對于提高運輸運作效率， 保證了資 金、物資和信息的高效有序流動和交互起著至關(guān)重要的作用。而互聯(lián)網(wǎng)技術(shù)、軟件技術(shù)、數(shù)據(jù)庫技術(shù)等已非常成熟，目前 WEB2.0WEB2.0 應(yīng)用已經(jīng)進入人 們的日常生活。開發(fā)基于互聯(lián)網(wǎng)的 SCMSCM 管理平臺，技術(shù)時機已經(jīng)成熟。3 3）、從社會效益與經(jīng)濟效益看項目可行性20062006年全國社會物流總額達(dá) 59.659.6萬億元，物流業(yè)增加值為 1.411.41 萬億元，從這里可以看 出，物流業(yè)的巨大商機。若是此電子商務(wù)平臺與 SCMSCM 管理平臺研發(fā)成功，必將是物流業(yè)的

14、一個典范， 他將對物流行業(yè)產(chǎn)生深遠(yuǎn)的影響， 因為在些平臺上可以實現(xiàn)多方協(xié)作， 資源共享， 改善服務(wù)質(zhì)量，規(guī)范管理，降低運輸成本，提升客戶滿意度等等好處，社會效益明顯。新華物流的“一網(wǎng)二臺”是一個電子商務(wù)平臺，也是一個 SCMSCM 管理平臺，若是運輸、 物流企業(yè)能體會到此網(wǎng)， 能給自己帶來管理上規(guī)范，服務(wù)能力的提升， 成本的下降，那么必 將帶來物流業(yè)管理的革命， 就會體會到使用此平臺帶來的各種好處， 那么， 新華物流網(wǎng)絡(luò)也 將在這個平臺租用中，收到可觀的經(jīng)濟效益?？梢院唵巫鰝€估算，若是全國的10%10%的物流公司能租用這個平臺，新華物流網(wǎng)絡(luò)公司將獲得豐厚的回報。4 4）、可能存在的主要障礙互聯(lián)

15、網(wǎng)協(xié)同運輸管理在實際運作上可能會遇到困難， 并可能會經(jīng)常運作實施效果不理想 或運作失敗。 其主要的障礙包括傳統(tǒng)管理思想和體制的禁錮， 仍采用傳統(tǒng)的方法運作和進行 成本核算； 成員之間對供應(yīng)鏈的視野仍停留在自己一方， 而沒有從供應(yīng)鏈整體看待； 每次談 判過程要花大量時間和經(jīng)歷， 因此供應(yīng)鏈各方過于注重各自利益或?qū)ヂ?lián)網(wǎng)協(xié)同運輸管理的 預(yù)期期望過大，信息傳遞的不準(zhǔn)確等。總之，互聯(lián)網(wǎng)協(xié)同運輸管理無論從技術(shù)、 從管理、 從實踐角度都是可以實現(xiàn)的，作為供 應(yīng)鏈運輸管理中的一種嶄新的思想，若供應(yīng)鏈中的各方建立一種“共贏”的合作伙伴關(guān)系， 站在供應(yīng)鏈戰(zhàn)略的高度實施互聯(lián)網(wǎng)協(xié)同運輸管理的話， 一定能獲得成功。

16、我們相信這種能降 低整個供應(yīng)鏈成本的先進的管理思想與管理手段，一定也必將成為現(xiàn)代物流的主要管理手 段。4、開發(fā)內(nèi)容1 1）、本項目全部完成分四個階段 第一階段形成面向從事物流業(yè)的專業(yè)運輸公司、貨代公司及個體戶的 TMSTMS 系統(tǒng)（即互 聯(lián)網(wǎng)協(xié)同運輸管理系統(tǒng)） 。第二階段形成面向社會資源優(yōu)化配置的電子商務(wù)交易系統(tǒng)。 第三階段形成面向生產(chǎn)制造業(yè)、商貿(mào)企業(yè)以及從事物流的供應(yīng)商的供應(yīng)鏈管理系統(tǒng)。 第四階段將電子商務(wù)交易平臺與供應(yīng)鏈管理平臺結(jié)合，形成一網(wǎng)兩臺。2 2）、目前的開發(fā)工作 互聯(lián)網(wǎng)協(xié)同運輸管理系統(tǒng)應(yīng)涵蓋基本表單（統(tǒng)計臺帳） 、報表、訂單管理、車輛調(diào)度、 運價管理、 車輛在途跟蹤、 回單管理、

17、 賬款結(jié)算等運輸中全面涉及數(shù)據(jù)方面的工作和自有車 輛檔案管理及會員管理。3 3）、功能要約基本操作功能： 軟件實現(xiàn)的操作層面基本功能要求有基本數(shù)據(jù)錄入、 添加、 查詢、刪除、 修改、保存、打印、更新、統(tǒng)計。實現(xiàn)功能： 軟件實現(xiàn)運營，管理層面以及創(chuàng)新功能要求數(shù)據(jù)庫共享、硬件共享、數(shù)據(jù)獨 享，解決離線、 在線同步數(shù)據(jù)保存及傳輸問題， 嵌入交互式聊天工具， 網(wǎng)點互動的網(wǎng)絡(luò)協(xié)同， 及時通信及短信功能。二、系統(tǒng)整體架構(gòu)互聯(lián)網(wǎng)協(xié)同運輸管理系統(tǒng)為服務(wù)商提供對外業(yè)務(wù)服務(wù)、 對外業(yè)務(wù)管理、 對外業(yè)務(wù)監(jiān)控等 功能；為服務(wù)商提供面向其最終用戶的訪問基礎(chǔ)平臺：因此互聯(lián)網(wǎng)協(xié)同運輸管理系統(tǒng)需要提供以下服務(wù)：完善的用戶認(rèn)證

18、管理，保證系統(tǒng)的安全、可靠；負(fù)載均衡管理，有效保證運營效率；用戶管理 : : 對用戶的基本信息，用戶的業(yè)務(wù)訂購等進行管理；產(chǎn)品和服務(wù)管理 : : 提供業(yè)務(wù)申請、業(yè)務(wù)審批、業(yè)務(wù)開通、業(yè)務(wù)信息查詢等；計費結(jié)算 : : 提供計費、結(jié)算，方便業(yè)務(wù)的靈活開展；提供高安全性：實現(xiàn)信息交換與共享的同時保證各系統(tǒng)中的信息的安全；提供基于工作流的協(xié)同管理提供基于 WebWeb 的營業(yè)支撐與管理系統(tǒng)；良好的擴展性；數(shù)據(jù)管理、備份、維護? ? 提供離線版1、系統(tǒng)架構(gòu)保證互聯(lián)網(wǎng)協(xié)同運輸管理系統(tǒng)有效運營效率， 必須首先解決 用戶認(rèn)證 及 資源負(fù)載均 衡問題。從職責(zé)角度，1 1 臺服務(wù)器擔(dān)任平臺共享的 “用戶數(shù)據(jù)庫服務(wù)器

19、 （”即中心數(shù)據(jù)服務(wù)器） 負(fù)責(zé)存儲所有用戶的個人資料；而其它服務(wù)器則承擔(dān)了 “認(rèn)證服務(wù)器 ”、 “監(jiān)控服務(wù)器 ”、 “短信服務(wù)器 ”、 “即時通訊服務(wù)器 ”、“WEBWEB 應(yīng)用服務(wù)器 ”和“數(shù)據(jù)庫服務(wù)器 ”等 6 6類不同 的工作。所示圖如下：I臬黑參II數(shù)IE宜$L L J J掘海叩攵WEBJJJ h 即站份圖務(wù)器敕據(jù)葉IN拎駄I數(shù)據(jù)牌眼務(wù)黠業(yè)齊我這四步聲可ujifjfr序M線 恤問4務(wù)科黑資源監(jiān) 控過程金:“j內(nèi)祝陽確定觀列衣反匕)認(rèn)1畑股務(wù)眇“ 訓(xùn)EB服務(wù)牡務(wù)險迪 瘵壓蹤喪WhHlli4-2嫌解勿匹卻1即時通訊服芬住線 州It點網(wǎng)I雀號豪】 犠號覬則 驚司編號 +品*! ?： Tli.

20、2葩駅吟電務(wù)器3注* ”操作業(yè)務(wù)乘統(tǒng)E即也拎服務(wù)器”監(jiān)擰開豹鈿下底號分M如依 加務(wù)耀二、認(rèn)證腮務(wù)器所懶工件一、系統(tǒng)架構(gòu)WLBWLB 靜皿務(wù)監(jiān)分配即時通確定獨卅 金展務(wù)；S短信服務(wù)器中心數(shù)據(jù)岸監(jiān)控服務(wù)閹處配數(shù)強 gjg 2EHZZ 施迫妙f 時知口祚站客戶端扎、斷開連按時空剛覓覆 界、導(dǎo)戶端第押時間間庫後世isis強回收所誠工件値盤為：便慌電怕認(rèn)證服務(wù)器SWST;?l ?| ?號在錢明HJ掃我4)互聯(lián)網(wǎng)協(xié)同運輸管理系統(tǒng)主要有三種角色用戶平臺運營商：負(fù)責(zé)平臺的運營與維護，為服務(wù)實施商和最終客戶提供周到的服務(wù)。 服務(wù)實施商：負(fù)責(zé)服務(wù)實施的整體管理。最終客戶：提交服務(wù)請求并獲取需要的服務(wù)。說明：1 1

21、）、平臺運營商、服務(wù)實施商 （承運商或第三方物流公司 ） 、客戶，提交自己的帳號、密碼及 驗證碼，認(rèn)證服務(wù)器開始驗證該帳號、密碼、驗證碼的有效性，如果確認(rèn)信息無誤，則系統(tǒng) 進入資源分配服務(wù)。2 2）、資源分配服務(wù)器根據(jù)短信服務(wù)器群、即時通訊服務(wù)器群、 WEBWEB 服務(wù)器群、數(shù)據(jù)庫服務(wù) 器（包括數(shù)據(jù)庫帳號）的當(dāng)前資源占用情況或配置情況，分配指定服務(wù)器資源。3 3）、根據(jù) RBACRBAC 模型中所描述的，根據(jù)該帳號在業(yè)務(wù)系統(tǒng)中的角色與權(quán)限讀取相應(yīng)的功能 模塊。4 4）、一旦帳號退出業(yè)務(wù)系統(tǒng)，系統(tǒng)自動調(diào)用資源收回服務(wù)，釋放服務(wù)器資源。如果帳號沒有 正常退出或長時間沒有業(yè)務(wù)操作情況，系統(tǒng)也自動調(diào)用

22、資源收回服務(wù)，釋放服務(wù)器資源。2、關(guān)鍵技術(shù)解決（ 一 ） 從軟件角度看， 單數(shù)據(jù)源和多數(shù)據(jù)源的問題， 下面我們來看看實現(xiàn)方法和各 自的利弊（1 1）、單數(shù)據(jù)源A A 單庫多表型：數(shù)據(jù)庫服務(wù)器上有一個數(shù)據(jù)庫；1 1、對于每個用戶各自的信息都會有其單獨的表集合；例如：用戶 A A 的單據(jù)信息表為（ Table_ATable_A ），則用戶 B B 的單據(jù)信息表為 （Table_BTable_B ）；2 2、數(shù)據(jù)庫中會有相應(yīng)的公共表，來實現(xiàn)信息的共享；優(yōu)點：這樣的操作的優(yōu)點是每個用戶都有自己單獨的表，它們能共享數(shù)據(jù)源或連接池， 效率更高，提高數(shù)據(jù)的訪問速度 , , 能更好的結(jié)合離線公辦 , , 同時

23、數(shù)據(jù)安全方面也能相應(yīng)的增 強； 同時也可以通過共用的表來存放共享信息，和其他客戶（用戶）進行數(shù)據(jù)的通訊，從 而使得功能實現(xiàn)和資源得到更好的結(jié)合，使得系統(tǒng)在相同的條件下達(dá)到最大最好的功能；缺點：在編程實現(xiàn)的時候可能會相應(yīng)的復(fù)雜些；某個客戶在訪問他自己私有的信息時 , , 系統(tǒng)要從某個表取得相應(yīng)的信息 , , 來判斷他應(yīng)該來訪問哪個表；B B 單庫單表型：所有客戶的數(shù)據(jù)都存放在一個數(shù)據(jù)庫的同一套表中，在部分表中增加標(biāo)示字段， 表明該記錄是屬于哪個客戶的。 具體哪些表中要增加標(biāo)示字段當(dāng)然要看具體的 需求， 不過大部分表示實體對象的表中都需要加。在很多查詢條件中都需要包括這個標(biāo)示字段。即使是用戶自定義

24、的查詢，系統(tǒng)也需要在查詢條件中加入該字段；優(yōu)點：編程操作上相應(yīng)會簡單，系統(tǒng)不需要分析當(dāng)前用戶應(yīng)該要訪問哪個表 , , 在數(shù)據(jù)庫 源的管理上也會相應(yīng)的簡單些；缺點： 在數(shù)據(jù)庫的處理和數(shù)據(jù)安全方面不如”單庫多表型”； 按照這樣的設(shè)計 , , 很多數(shù) 據(jù)表都需要加入客戶表示字段，很多查詢都需要包括該字段，會比較麻煩。如果有遺漏，特 別是查詢條件中遺漏該字段， 就會造成一個客戶看到另一個客戶的數(shù)據(jù)。 另外， 需要在系統(tǒng) 的安全性方面做比較細(xì)致的設(shè)計。比如，某個功能通過在 URLURL中包含某個實體的關(guān)鍵字以查詢該實體的信息， 或?qū)υ搶嶓w進行操作。 在普通應(yīng)用中后臺只需要根據(jù)關(guān)鍵字查出該實體即 可。但是

25、在 WebWeb應(yīng)用中，就必須額外判定該實體是否屬于當(dāng)前登錄用戶，或者要在查詢中條件中加入客戶標(biāo)示；（2 2）、多數(shù)據(jù)源這個方法和”單庫多表型”的操作思想基本上是一致 , , 就是系統(tǒng)有多個庫，其中某個庫 是共用的，存放一些公用的信息；然后為每個客戶建立一個數(shù)據(jù)庫，來存放其獨立的信息；WEEWEE網(wǎng)站優(yōu)點：不同客戶的數(shù)據(jù)物理分離， 安全性比較好。 除了獲取數(shù)據(jù)庫連接部分的程序以外， 其它程序和普通應(yīng)用沒有兩樣。 不同客戶的數(shù)據(jù)可以放置在不同的數(shù)據(jù)庫服務(wù)器中， 分擔(dān)數(shù) 據(jù)庫服務(wù)器的負(fù)荷 , , 能提高數(shù)據(jù)的訪問速度。缺點： 在編程實現(xiàn)的時候可能會相應(yīng)的復(fù)雜些； 同時一個數(shù)據(jù)庫服務(wù)器上搭建很多數(shù)據(jù)

26、 庫會增加數(shù)據(jù)庫服務(wù)器的負(fù)擔(dān)， 降低其性能； 數(shù)據(jù)庫連接的利用效率不高。 在系統(tǒng)這邊來說， 則是數(shù)據(jù)源或連接池很多， 但每一個的利用效率都不高。 在數(shù)據(jù)庫服務(wù)器這邊仍然會有很多 連接， 因為每個數(shù)據(jù)源或連接池都需要保持一定數(shù)量的可用連接。這樣通過連接池共享數(shù)據(jù)庫連接而減少總連接數(shù)的好處被大大削弱了； 另外如果需要增加客戶時， 需要在應(yīng)用服務(wù)器 中配制新的數(shù)據(jù)源， 或者修改應(yīng)用自己的數(shù)據(jù)庫連接池配制。 某些情況下可能無法作到在應(yīng) 用不中斷的情況下使這些配制生效。結(jié)論：庫表散列是常用并且最有效的解決方案。 我們在應(yīng)用程序中安裝業(yè)務(wù)和應(yīng)用或者功能模 塊將數(shù)據(jù)庫進行分離， 不同的 模塊或用戶 對應(yīng)不同

27、的數(shù)據(jù)庫或者表， 再按照一定的策略對某 個頁面或者功能進行更小的數(shù)據(jù)庫散列，比如用戶表，按照用戶 IDID 進行表散列，這樣就能 夠低成本的提升系統(tǒng)的性能并且有很好的擴展性。 sohusohu 的論壇就是采用了這樣的架構(gòu)，將 論壇的用戶、設(shè)置、帖子等信息進行數(shù)據(jù)庫分離，然后對帖子、用戶按照板塊和 IDID 進行散 列數(shù)據(jù)庫和表， 最終可以在配置文件中進行簡單的配置便能讓系統(tǒng)隨時增加一臺低成本的數(shù) 據(jù)庫進來補充系統(tǒng)性能。（ 二 ） 對單條記錄的并發(fā)問題的處理方法。業(yè)務(wù)邏輯的實現(xiàn)過程中， 往往需要保證數(shù)據(jù)訪問的排他性。 如在金融系統(tǒng)的日終結(jié)算處 理中，我們希望針對某個 cut-offcut-off

28、 時間點的數(shù)據(jù)進行處理， 而不希望在結(jié)算進行過程中 （可 能是幾秒種，也可能是幾個小時） ，數(shù)據(jù)再發(fā)生變化。1 1）、并發(fā)概率現(xiàn)在市面上針對 PCPC機的軟件開發(fā)，主要以兩種結(jié)構(gòu)為主： 一種為C/SC/S結(jié)構(gòu)；一種為B/SB/S 結(jié)構(gòu)。而兩種結(jié)構(gòu)各有利弊，在這里就不詳細(xì)描述。這里主要就其使用方式進行說明一下， 兩種結(jié)構(gòu)都針對用戶進行實現(xiàn)的，用戶登陸后再根據(jù)其權(quán)限、角色進行相關(guān)的可執(zhí)行操作。WEBWEB程序的訪問量是相當(dāng)大的，這可能也是客戶主要考慮并發(fā)性的因素。下面就該問題進行 描述。用戶注冊并確定審核后， 即成為平臺的正式使用者， 用戶的注冊信息都將被保存， 并根 據(jù)注冊情況分配相應(yīng)的角色及權(quán)

29、限。用戶登錄后，可發(fā)布修改刪除的個人信息、發(fā)布修改刪除自己的公共信息等， 上的信息均是某個用戶進行發(fā)布的（不包括后臺管理信息） ，這些信息是不允許其他用戶進 行修改、刪除的。后臺管理用戶只可對記錄的非信息部分進行編輯操作，如審核、刪除等。2 2）、并發(fā)的可能情況：A A、 不同用戶對于同一條記錄的操作如：前臺用戶讀出并開始修改自己的發(fā)布信息但還沒有提交， 后臺的管理用戶覺得該條 被前臺用戶已經(jīng)打開的信息有問題而在后臺進行了審核刪除操作， 當(dāng)前臺用戶進行提交他的 修改時，將會獲得“您的該條信息已被刪除”相似的信息；如果前臺用戶對該條記錄進行修 改提交，而同時后臺管理用戶對該條記錄進行刪除提交，在

30、WEWE酮站上看是同時的， 但最終都將反應(yīng)到數(shù)據(jù)庫里，如果反應(yīng)到數(shù)據(jù)庫里有先后順序，一種情況是修改失敗、刪除成功， 一種情況是修改成功、 刪除成功； 如果反應(yīng)到數(shù)據(jù)庫里也是同時， 數(shù)據(jù)庫會根據(jù)其內(nèi)部的沖 突處理機制進行辨別誰先誰后，從而最終的結(jié)果將是一樣的剛才描述的兩種情況。這里說明一點： 對于前臺用戶發(fā)布的信息， 前臺用戶所編輯的字段與后臺用戶所編輯的 字段總是不一樣的，以保證用戶信息的自主性及權(quán)利。否則將影響網(wǎng)站的使用。B B、同用戶或者說具有相同某條記錄操作權(quán)限的用戶對于同一條記錄的操作女口：有一條記錄，某用戶A A在前臺打開該記錄并進行操作， 同時用戶B B在前臺亦打開該 記錄并進行操

31、作， 并同時進行提交。 當(dāng)然我們會在用戶的設(shè)置上進行一些處理， 但如果是業(yè) 務(wù)需要并一定會具有這種情況發(fā)生的時候。 與第一點具有相同的處理機制， 同樣在前臺是同 時提交的，反應(yīng)到數(shù)據(jù)庫里，如果有先后順序，將根據(jù)順序處理，處理的結(jié)果將被反應(yīng)至前 臺；如果數(shù)據(jù)庫里也是同時到達(dá)， 數(shù)據(jù)庫會根據(jù)其內(nèi)部機制進行辨別操作， 亦是同樣的結(jié)果。3 3）、可行的方案我們就需要通過一些機制來處理單條數(shù)據(jù)并發(fā)的問題， 即在某個操作過程中有些數(shù)據(jù)不 會被外界修改。這樣的機制，在這里，也就是所謂的“鎖” ，即給我們選定的目標(biāo)數(shù)據(jù)上鎖， 使其無法被其他程序修改。通常來講，鎖可以分為兩種：悲觀鎖 （PessimisticP

32、essimistic LockingLocking ）和 樂觀鎖 （OptimisticOptimistic LockingLocking） 。悲觀鎖 （Pessimistic Locking）悲觀鎖，正如其名，它指的是對數(shù)據(jù)被外界（包括本系統(tǒng)當(dāng)前的其他事務(wù)，以及來自外 部系統(tǒng)的事務(wù)處理） 修改持保守態(tài)度， 因此， 在整個數(shù)據(jù)處理過程中， 將數(shù)據(jù)處于鎖定狀態(tài)。 悲觀鎖的實現(xiàn)，往往依靠數(shù)據(jù)庫提供的鎖機制（也只有數(shù)據(jù)庫層提供的鎖機制才能真正保 證數(shù)據(jù)訪問的排他性， 否則， 即使在本系統(tǒng)中實現(xiàn)了加鎖機制， 也無法保證外部系統(tǒng)不會修 改數(shù)據(jù))。一個典型的倚賴數(shù)據(jù)庫的悲觀鎖調(diào)用：selectselect

33、 * * fromfrom accountaccount wherewhere name=Ericaname=Erica forfor updateupdate這條 sqlsql 語句鎖定了 accountaccount 表中所有符合檢索條件 (name=Erica)(name=Erica) 的記錄。 本次事務(wù)提交之前(事務(wù)提交時會釋放事務(wù)過程中的鎖) ，外界無法修改這些記錄，所有 的修改請求將等待直到事務(wù)提交或回滾。而在 OracleOracle 中有 forfor updateupdate nowaitnowait 關(guān)鍵字，當(dāng)發(fā)現(xiàn)數(shù)據(jù)被別的 sessionsession forfor up

34、dateupdate nowaitnowait 鎖定中的時候，就會迅速返回 ORA-00054ORA-00054 錯誤，內(nèi)容是資源正忙 , , 但指定以 NOWAITNOWAIT 方式獲取資源。所以在程序中我們可以采用 nowaitnowait 方式迅速判斷當(dāng)前數(shù)據(jù)是否被鎖定中， 如果鎖定中的話，就要采取相應(yīng)的業(yè)務(wù)措施進行處理。樂觀鎖 (Optimistic Locking)對悲觀鎖而言， 樂觀鎖機制采取了更加寬松的加鎖機制。 悲觀鎖大多數(shù)情況下依靠數(shù)據(jù) 庫的鎖機制實現(xiàn)， 以保證操作最大程度的獨占性。 但隨之而來的就是數(shù)據(jù)庫性能的大量開銷， 特別是對長事務(wù)而言， 這樣的開銷往往無法承受。 如一

35、個金融系統(tǒng)， 當(dāng)某個操作員讀取用戶 的數(shù)據(jù)，并在讀出的用戶數(shù)據(jù)的基礎(chǔ)上進行修改時(如更改用戶帳戶余額) ，如果采用悲觀 鎖機制， 也就意味著整個操作過程中 (從操作員讀出數(shù)據(jù)、 開始修改直至提交修改結(jié)果的全 過程， 甚至還包括操作員中途去煮咖啡的時間) ，數(shù)據(jù)庫記錄始終處于加鎖狀態(tài)， 可以想見， 如果面對幾百上千個并發(fā)， 這樣的情況將導(dǎo)致怎樣的后果。 樂觀鎖機制在一定程度上解決了 這個問題。樂觀鎖，大多是基于數(shù)據(jù)版本 (Version)(Version) 記錄機制實現(xiàn)。何謂數(shù)據(jù)版本？即為數(shù) 據(jù)增加一個版本標(biāo)識， 在基于數(shù)據(jù)庫表的版本解決方案中， 一般是通過為數(shù)據(jù)庫表增加一個 versionve

36、rsion 字段來實現(xiàn)。相讀取出數(shù)據(jù)時，將此版本號一同讀出，之后更新時，對此版本號加一。此時，將提交 數(shù)據(jù)的版本數(shù)據(jù)與數(shù)據(jù)庫表對應(yīng)記錄的當(dāng)前版本信息進行比對， 如果提交的數(shù)據(jù)版本號大于 數(shù)據(jù)庫表當(dāng)前版本號， 則予以更新， 否則認(rèn)為是過期數(shù)據(jù)。 對于上面修改用戶帳戶信息的例 子而言，假設(shè)數(shù)據(jù)庫中帳戶信息表中有一個 versionversion 字段，當(dāng)前值為 1 1 ；而當(dāng)前帳戶余額 字段( balancebalance )為 $100$100 。1 1 操作員 A A 此時將其讀出 ( version=1version=1 )，并從其帳戶余額中扣除 $50$50 ( $100-$50$100-

37、$50 )。2 2 在操作員 A A 操作的過程中， 操作員 B B 也讀入此用戶信息 ( version=1version=1 )，并從其帳 戶余額中扣除 $20$20 ( $100-$20$100-$20 )。3 3操作員 A A 完成了修改工作，將數(shù)據(jù)版本號加一( version=2version=2 )，連同帳戶扣除后余 額( balance=$50balance=$50 )，提交至數(shù)據(jù)庫更新， 此時由于提交數(shù)據(jù)版本大于數(shù)據(jù)庫記錄當(dāng)前版本， 數(shù)據(jù)被更新，數(shù)據(jù)庫記錄 versionversion 更新為 2 2 。4 4操作員 B B 完成了操作，也將版本號加一( version=2ve

38、rsion=2 )試圖向數(shù)據(jù)庫提交數(shù)據(jù) ( balance=$80balance=$80 )，但此時比對數(shù)據(jù)庫記錄版本時發(fā)現(xiàn)， 操作員 B B 提交的數(shù)據(jù)版本號為 2 2 ， 數(shù)據(jù)庫記錄當(dāng)前版本也為 2 2，不滿足 “ 提交版本必須大于記錄當(dāng)前版本才能執(zhí)行更新 “ 的 樂觀鎖策略， 因此， 操作員 B B 的提交被駁回。 這樣， 就避免了操作員 B B 用基于 version=1version=1 的舊數(shù)據(jù)修改的結(jié)果覆蓋操作員 A A 的操作結(jié)果的可能。 從上面的例子可以看出， 樂觀鎖機制 避免了長事務(wù)中的數(shù)據(jù)庫加鎖開銷 (操作員 A A 和操作員 B B 操作過程中， 都沒有對數(shù)據(jù)庫數(shù) 據(jù)加

39、鎖)，大大提升了大并發(fā)量下的系統(tǒng)整體性能表現(xiàn)。結(jié)論總之，介紹了數(shù)據(jù)庫的鎖定機制，究竟是悲觀鎖好還是樂觀鎖好，其實也是不一定的， 跟開發(fā)的技術(shù)、應(yīng)用的場景和具體的需求都有關(guān)系。在 OracleOracle 中悲觀鎖還是很不錯的，而 且從開始的時候就把數(shù)據(jù)鎖定。免除了后面的很多沖突處理。不過悲觀鎖需要保持一個 OracleOracle 連接，在我們常見的 B/SB/S 應(yīng)用中，特別是數(shù)據(jù)先取得，然后讓用戶再更新，再返回 提交這種流程來說， 悲觀鎖是不大可能的。 首先是因為 B/SB/S 應(yīng)用中，一般是利用一個連接池， 在兩次 HttpHttp RequestRequest 請求都是不同的數(shù)據(jù)庫 C

40、onnectionConnection 。而且也不能鎖定一個數(shù)據(jù)太長時 間，否則人人都這么鎖定，應(yīng)用很容易進入死鎖狀態(tài)，這個時候就要采用樂觀鎖了。( 三 ) 多用戶的角色及權(quán)限的實現(xiàn)方法。用戶的角色及權(quán)限的控制需要根據(jù)項目的實際情況和具體架構(gòu)來定， 在維護性、 靈活性、 完整性等 N N 多個方案之間比較權(quán)衡， 選擇符合的方案。 對于在企業(yè)環(huán)境中的訪問控制方法， 一般有三種：1 1、自主型訪問控制方法。目前在我國的大多數(shù)的信息系統(tǒng)中的訪問控制模塊中基本是 借助于自主型訪問控制方法中的訪問控制列表 (ACLS)(ACLS) 。2 2、強制型訪問控制方法。用于多層次安全級別的軍事應(yīng)用。3 3、基于

41、角色的訪問控制方法( RBACRBAC )。是目前公認(rèn)的解決大型企業(yè)的統(tǒng)一資源訪問控 制的有效方法。其顯著的兩大特征是：1.1.減小授權(quán)管理的復(fù)雜性，降低管理開銷。2.2.靈活地支持企業(yè)的安全策略，并對企業(yè)的變化有很大的伸縮性。根據(jù)本項目的特點，優(yōu)先選用基于角色的用戶訪問控制 (RBAC)(RBAC) 。訪問控制系統(tǒng)可以為 應(yīng)用系統(tǒng)建立一個高安全強度， 更易維護管理， 擴展能力極強的訪問控制環(huán)境， 并能夠有 效的控制管理的復(fù)雜性， 提供標(biāo)準(zhǔn)化和可以不斷延伸授權(quán)平臺。 訪問控制系統(tǒng)的體系結(jié)構(gòu)設(shè)計保證了用戶能按照應(yīng)用規(guī)模和數(shù)量快速地建立訪問控制體系。完全基于策略思想設(shè)計的權(quán)限管理控制系統(tǒng)作為構(gòu)建訪

42、問控制體系的基石，它能使用戶已建立的訪問控制體系不斷滿足演化的應(yīng)用權(quán)限需求，如支持新應(yīng)用、支持新的權(quán)限、增加用戶數(shù)量、增加用戶類型、 增加策略數(shù)量等。本系統(tǒng)在用戶訪問控制管理中將引入角色的概念，即在系統(tǒng)中提供若干個角色，每個角色的權(quán)限可以任意定制， 在每一個角色下可以包含若干個用戶，用戶只能夠使用本角色允許使用的系統(tǒng)功能，對用戶無權(quán)使用的系統(tǒng)功能可以設(shè)置其狀態(tài)為不可見或隱藏。管理員可以首先分配好各個角色的權(quán)限，然后將系統(tǒng)的用戶分配到各個不同角色中，即可以完成用戶權(quán)限的設(shè)定，而不用逐個的去設(shè)定用戶的使用權(quán)限。角色的概念在現(xiàn)實生活中經(jīng)常提到某人扮演了什么角色。在基于用戶角色的用戶權(quán)限管理中，角色與

43、實際的角色概念有所不同。 在這里角色可以看作是一組操作的集合，不同的角色具有不同的操作集，這些操作有系統(tǒng)管理員分配給角色。用戶的授權(quán)是通過授予用戶一個角色來實現(xiàn)的，即賦予用戶一個角色，一個用戶可以承擔(dān)不同的角色，從而實現(xiàn)授權(quán)的靈活性。只要某 用戶屬于某個角色那么他就具備這個角色的所有操作許可，即該角色所擁有的權(quán)限。 用戶與角色是多對多的關(guān)系。即一個用戶可以屬于多個角色之中，一個角色可以包括多個用戶。RBACRBAC模型構(gòu)件分析圖 RBACRBAC模型我們對該模型定義如下：U U，R R， P P, S S:用戶；角色，權(quán)限，會話；PAPA P*RP*R :權(quán)限分配，多對多的關(guān)系；UAUA U*

44、RU*R :用戶分配，多對多關(guān)系；User:S-U,User:S-U,每一個會話 s s對應(yīng)單一用戶 user(s)user(s)的映射;Roles:Roles:會話 s s 到角色集合 role(s)role(s) r|(user(s),r)r|(user(s),r) PAPA顯而易見：該模型由三個實體組成，分別是：用戶（U U）、角色（R R）、權(quán)限（P P）。其中用戶指自然人； 角色就是組織內(nèi)部一件工作的功能或工作的頭銜， 表示該角色成員所授予的職 責(zé)的許可，系統(tǒng)中擁有權(quán)限的用戶可以執(zhí)行相應(yīng)的操作。用戶與角色之間以及角色與權(quán)限之間用雙雙箭頭相連表示用戶角色分配UAUA 和角色權(quán)限分配 P

45、APA 關(guān)系都是多對多的關(guān)系， 即一個用戶可以擁有多個角色， 一個角色也可被多個用 戶所擁有。同樣的，一個角色擁有多個權(quán)限，一個權(quán)限能被多個角色所擁有。用戶建立會話 從而對資源進行存取，每個會話 S S 將一個用戶與他所對應(yīng)的角色集中的一部分建立映射關(guān) 系，這個角色會話子集稱為會話激活的角色集。于是，在這次會話中，用戶可以執(zhí)行的操作 就是該會話激活的角色集對應(yīng)的權(quán)限所允許的操作。RBACRBAC 特點及應(yīng)用優(yōu)勢RBACRBAC 幾大特點（ 1 1）訪問權(quán)限與角色相關(guān)聯(lián)，不同的角色有不同的權(quán)限。用戶以什么樣的角色對資源 進行訪問，決定了用戶擁有的權(quán)限以及可執(zhí)行何種操作。（ 2 2）角色繼承。角色

46、之間可能有互相重疊的職責(zé)和權(quán)力，屬于不同角色的用戶可能需 要執(zhí)行一些相同的操作。 RBACRBAC 采用角色繼承的概念，如角色 2 2 繼承角色 1 1，那么管理員 在定義角色 2 2 時就可以只設(shè)定不同于角色 1 1 的屬性及訪問權(quán)限，避免了重復(fù)定義。（ 3 3）最小權(quán)限原則，即指用戶所擁有的權(quán)力不能超過他執(zhí)行工作時所需的權(quán)限。實現(xiàn) 最小特權(quán)原則， 需要分清用戶的工作職責(zé)， 確定完成該工作的最小權(quán)限集， 然后把用戶限制 在這個權(quán)限結(jié)合的范圍之內(nèi)。 一定的角色就確定了其工作職責(zé)， 而角色所能完成的事物蘊涵 了其完成工作所需的最小權(quán)限。 用戶要訪問信息首先必須具有相應(yīng)的角色，用戶無法饒過角色直接

47、訪問信息。（ 4 4）職責(zé)分離。一般職責(zé)分離有兩種方式：靜態(tài)和動態(tài)。（ 5 5）角色容量。在一個特定的時間段內(nèi)，有一些角色只能有一定人數(shù)的用戶占用。在 創(chuàng)建新的角色時應(yīng)該指定角色的容量。RBACRBAC 應(yīng)用優(yōu)勢最突出的優(yōu)點在于系統(tǒng)管理員能夠按照不同的安全政策劃分不同的角色，執(zhí)行特定的任務(wù)。一個系統(tǒng)建立起來后主要的管理工作即為授權(quán)或取消用戶的角色。用戶的職責(zé)變化時只需要改變角色即可改變其權(quán)限； 當(dāng)組織功能變化或演進時， 則只需刪除角色的舊功能， 增 加新功能，或定義新角色，而不必更新每一個用戶的權(quán)限設(shè)置。這極大的簡化了授權(quán)管理， 使對信息資源的訪問控制能更好地適應(yīng)特定單位的安全策略。RBACR

48、BAC 另一優(yōu)勢體現(xiàn)在為系統(tǒng)管理員提供了一種比較抽象的、 與企業(yè)通常業(yè)務(wù)管理性 類 似的訪問控制層次。通過定義、建立不同的角色、角色的繼承關(guān)系、角色之間的聯(lián)系以 及相 應(yīng)的限制、管理員可動態(tài)或靜態(tài)地規(guī)范用戶的行為。在本項目中， 各個功能模塊中的操作可以定義為各個獨立的權(quán)限集合中的元素， 于是各 個模塊其實就成了各自獨立的權(quán)限集合， 平臺超級管理員可以預(yù)先定義好包含不同權(quán)限集合 的用戶角色， 比如平臺超級管理員可以將平臺上公共信息平臺的添加、 刪除、 修改和查詢等 權(quán)限賦予平臺公共信息管理員這個角色； 而在平臺上租用應(yīng)用服務(wù)的公司的管理員用戶角色 就擁有對公司部門的訂制權(quán)限，下屬用戶帳號的管理操

49、作權(quán)限等等。系統(tǒng)中的各級管理員就可以將預(yù)先定義好的用戶角色再分配各自的下級用戶帳號， 比如 下訂單員工的帳號就賦予下訂單的系統(tǒng)角色，分管信息的帳號就分配以信息管理員的角色。 這里不同的帳號也可以分配相同的用戶角色以方便完成任務(wù)， 上級的管理員則是擁有下屬用 戶的所有角色權(quán)限。這樣通過基于角色的訪問控制（ RBACRBAC ）實現(xiàn)本平臺中多用戶角色權(quán)限 的訪問控制。一個安全的網(wǎng)絡(luò)需要可靠的訪問控制作保障。 在網(wǎng)絡(luò)規(guī)模變大、 用戶增多、 需求更復(fù)雜 的情況下， 傳統(tǒng)的訪問控制已經(jīng)不能滿足許多企業(yè)或組織的安全需要， 基于角色的訪問控制 （ RBACRBAC ）便明顯地顯示出其優(yōu)越性。基于角色的訪問控

50、制可以很好的解決資源庫項目的訪 問控制，為系統(tǒng)開發(fā)提供了一套有力的工具，還為用戶評估系統(tǒng)提供了標(biāo)準(zhǔn)。（ 四 ） 關(guān)于大型應(yīng)用平臺高并發(fā)量的技術(shù)處理。負(fù)載均衡將是大型網(wǎng)站解決高負(fù)荷訪問和大量并發(fā)請求采用的終極解決辦法。 負(fù)載均 衡技術(shù)發(fā)展了多年， 有很多專業(yè)的服務(wù)提供商和產(chǎn)品可以選擇， 根據(jù)我們接觸過的一些解決 方法，其中有兩個架構(gòu)可以選擇。硬件四層交換第四層交換使用第三層和第四層信息包的報頭信息， 根據(jù)應(yīng)用區(qū)間識別業(yè)務(wù)流， 將整個 區(qū)間段的業(yè)務(wù)流分配到合適的應(yīng)用服務(wù)器進行處理。 第四層交換功能就象是虛 IPIP ，指向 物理服務(wù)器。 這些業(yè)務(wù)在物理服務(wù)器基礎(chǔ)上， 需要復(fù)雜的載量平衡算法。 這種

51、硬件投入費用 很高因此我們不提倡。軟件交換知道了硬件四層交換機的原理， 軟件交換也就應(yīng)運而生， 它的解決方案實現(xiàn)的原理一致。 通過配置表及相關(guān)的服務(wù) （實時收集必要的信息） 選擇合適的服務(wù)器來處理業(yè)務(wù)， 同時提供 了靈活的配置和管理功能， 可以同時滿足多種應(yīng)用需求， 這對于平臺的擴展性及分布式的系統(tǒng)來說必不可少。 因此我們建議用軟件交換方式，并已設(shè)計相應(yīng)算法。（ 五 ） 互聯(lián)網(wǎng)協(xié)同運輸管理系統(tǒng)中主要解決以下幾種協(xié)同1 1、運單協(xié)同 ：“協(xié)同方”協(xié)同過來的“協(xié)同運單” ，自動轉(zhuǎn)入業(yè)務(wù)應(yīng)用系統(tǒng)中的“運單 管理”模塊。2 2、車輛跟蹤協(xié)同 ：協(xié)同給“協(xié)同方”的“協(xié)同運單”的跟蹤信息、貨損貨差情況，自

52、 動輸入業(yè)務(wù)應(yīng)用系統(tǒng)中的“車輛跟蹤”管理及“貨損貨差”管理模塊。3 3、財務(wù)結(jié)算協(xié)同 ：協(xié)同雙方發(fā)生的財務(wù)情況，自動輸入?yún)f(xié)同雙方“財務(wù)結(jié)算”管理模 塊。4 4、短信系統(tǒng)和即時通迅軟件為協(xié)同雙方的溝通進一步提供了方便。要協(xié)方 受協(xié)方三、開發(fā)功能在介紹功能之前，先說明以下幾點：a a、 數(shù)據(jù)還原（針對業(yè)務(wù)應(yīng)用平臺）在業(yè)務(wù)操作過程中，數(shù)據(jù)之間有一定的關(guān)鏈性。因此在數(shù)據(jù)還原功能上受一定的限制。如“運單管理”中的“運單協(xié)同”模塊，當(dāng)運單向協(xié)同方發(fā)出協(xié)同申請，如果協(xié)同方接受該 協(xié)同之后，則該運單不能進行還原操作。該功能直接體現(xiàn)在操作界面上。b b、 “查詢”子模塊在所有界面上有涉及到查詢功能的，我們統(tǒng)一調(diào)

53、用“復(fù)合查詢”子模塊，進行查詢條件的設(shè)置，提交“完成確定”按鈕進行查詢操作。c c、 功能菜單”調(diào)用在運營支持系統(tǒng)和業(yè)務(wù)應(yīng)用系統(tǒng)中， 操作人員的 “功能菜單” 根據(jù)該用戶的角色情況進 行配置與優(yōu)化。d d、 基本操作在運營支持系統(tǒng)和業(yè)務(wù)應(yīng)用系統(tǒng)中， 如果沒有特珠說明， 則提供的基本操作有： “添加”、 “修改”、 “刪除”、 “查詢”、 “部分導(dǎo)出” 、 “全部導(dǎo)出” 、 “還原”等操作功能。從使用平臺的三種角色出發(fā)，互聯(lián)網(wǎng)協(xié)同運輸管理系統(tǒng)主要有三個系統(tǒng)組成。1、運營支持系統(tǒng)（ 一 ） 、操作對象：運營支持系統(tǒng)的使用對象是平臺運營商。（ 二 ） 、功能模塊1 1、 用戶角色管理；根據(jù)運營商的業(yè)

54、務(wù)需求來劃分角色，并指定相應(yīng)的權(quán)限。 角色有：平臺管理角色 （最高角色 ）+ + 定義的角色。 操作功能： 基本操作。2 2、 用戶帳號權(quán)限管理；根據(jù)用戶在運營支持系統(tǒng)中所管理的業(yè)務(wù)，給定相應(yīng)的角色。 操作功能： 基本操作。3 3、 會員管理；會員在線注冊：用戶通過運營支持系統(tǒng)的在線申請，提交真實信息。會員審核： 運營商通過對這些信息的真實性情況進行調(diào)查， 如果確認(rèn)信息無誤， 則 開通使用。會員信息管理： 運營商對會員 （ 會員公司 ）的基本信息進行管理。 操作功能：“修改”、 “刪除”、“停用”、“查詢”、“部分導(dǎo)出” 、“全部導(dǎo)出” 、“還原”等操作。 會員業(yè)務(wù)查看： 運營商對會員 （ 會

55、員公司 ） 的業(yè)務(wù)情況進行查看。 對會員經(jīng)營情況的 查看過程與操作自己業(yè)務(wù)的情況一致， 主要區(qū)別是只能查看， 不能對其進行數(shù)據(jù)的 更新。會員密碼初始化： 運營商對會員的密碼進行初始化。 該工作主要在會員忘記了密碼 且需要我們初始化的情況下進行。 操作功能： 密碼初始化。會員子網(wǎng)點配置： 運營商根據(jù)會員 （會員公司 ）提交的申請， 對會員 （會員公司 ）的網(wǎng) 點情況進行配置，最終體現(xiàn)在運營商對會員的收費情況，另一方面是會員 （ 會員公 司 ） 對子網(wǎng)點經(jīng)營情況的查看。對子網(wǎng)點經(jīng)營情況的查看過程與操作自己業(yè)務(wù)的情 況一致，主要區(qū)別是只能查看，不能對其進行數(shù)據(jù)的更新。 操作功能： 基本操作。 會員業(yè)

56、務(wù)角色查看：運營商可以查看會員 （公司 ）業(yè)務(wù)角色配置情況。 業(yè)務(wù)帳號權(quán)限查看：運營商可以查看會員 （會員公司 ） 業(yè)務(wù)帳號的權(quán)限。 會員組管理： 運營商為了方便對會員 （會員公司 ）進行管理，根據(jù)一定的性質(zhì)對會員 （會員公司 ） 進行分類，方便分析與管理，如發(fā)短信。操作功能： 基本操作。4 4、短信管理；發(fā)送短信：運營商發(fā)送相關(guān)信息給會員 （ 會員公司 ） ，如交會員費用、系統(tǒng)升級等。 操作功能：“發(fā)送”。歷史短信：運營商可以查看單位短信發(fā)送情況，方便對短信費用的情況進行了解， 便于分析與管理。 操作功能：“查詢”、“部分導(dǎo)出”、“全部導(dǎo)出” 。 短信余額：運營商可以查看單位短信余額情況，便

57、于及時充值。5 5、即時通訊；好友管理： 好友管理是為即時通訊服務(wù)的。 提供了雙方及時交流的方便。 運營商的 好友來源于會員帳號及自己添加的會員 （ 會員公司 ）業(yè)務(wù)帳號。操作功能：基本操作。6 6、交流溝通系統(tǒng)；交流信息管理： 運營商可以管理會員或客戶提交的信息， 及時了解相關(guān)情況。 操作 功能： 基本操作?；貜?fù)信息：運營商可以根據(jù)會員或客戶提交的信息進行回復(fù)操作。 操作功能：“回 復(fù)”。審核發(fā)布： 運營商根據(jù)會員 （ 包括客戶 ） 提交的信息情況進行整理， 然后發(fā)布到會員 的業(yè)務(wù)應(yīng)用系統(tǒng)中，方便用戶查看。 操作功能：“發(fā)布”。欄目管理： 交流溝通系統(tǒng)根據(jù)實際運營中的情況開辟多個欄目， 方便

58、對信息的分類 管理。 操作功能： 基本操作。7 7、費用管理；費用提醒： 針對運營商主要有兩種費用的提醒。 第一種是會員費用到期提醒、 第二 種是短信費用預(yù)交提醒。 這兩種費用的提醒也分別在業(yè)務(wù)應(yīng)該系統(tǒng)及即時通訊中體 現(xiàn)（針對運營支持系統(tǒng)中的會員帳號） 。 操作功能： 查詢、部分導(dǎo)出、全部導(dǎo)出操 作。歷史費用：查看所有會員上交的會員費用及短信費用。 費用充值：指會員費用或短信預(yù)交費用的充值。 操作功能： 基本操作。 短信余額：查看會員短信余額情況，方便及時通知或進行充值。8 8、會員帳號；帳號信息：運營商帳號可以查看自己的帳號情況。 操作功能：“修改”、“還原”。 修改密碼：運營商帳號可以修改

59、自己的密碼。 操作功能：“修改”。9 9、基礎(chǔ)數(shù)據(jù)維護；默認(rèn)業(yè)務(wù)角色定義： 運營商定義默認(rèn)業(yè)務(wù)角色， 并指定相應(yīng)的權(quán)限， 會員可以根據(jù) 自己的業(yè)務(wù)需要重新調(diào)整角色。 操作功能： 基本操作。費用計算公式： 目前運營支持系統(tǒng)主要有兩種會員： 第一種是物流公司， 第二種社會車輛。 因 此會員費用也有所不同。一、如果會員在平臺上沒有子網(wǎng)點且是物流公司，則他的會員費用是一個基礎(chǔ)金額。二、如果會員在平臺上沒有子網(wǎng)點且是社會車輛，則他的會員費用也是一個基礎(chǔ)金額，但金額與物流公司所交金額是不一樣。三、如果該會員在平臺上有子網(wǎng)點，則他的會員費用為：會員費= =基礎(chǔ)金額 + +子網(wǎng)點數(shù) * *基數(shù)。操作功能：“修

60、改”、“還原”。1010、基礎(chǔ)數(shù)據(jù)維護；自動備份設(shè)置： 運營商通過定義策略或通過服務(wù)程序在指定的時間內(nèi)自動備份數(shù)據(jù)庫。數(shù)據(jù)庫備份： 運營商進入運營支持系統(tǒng)隨時對數(shù)據(jù)庫進行備份。操作功能：“備份”、“刪除”。數(shù)據(jù)庫還原： 如果運營平臺的數(shù)據(jù)庫遭到人為的破壞，運營商則通過“數(shù)據(jù)庫還原”功能， 把數(shù)據(jù)庫恢復(fù)到正確數(shù)據(jù)的某一時刻。操作功能：“還原數(shù)據(jù)庫”2、業(yè)務(wù)應(yīng)用系統(tǒng)（ 一 ） 、操作對象：業(yè)務(wù)應(yīng)該系統(tǒng)的使用對象是服務(wù)實施商（承運商或 第三方物流公司） 。（ 二 ） 、業(yè)務(wù)流程：調(diào)度計劃（粗舸戻貨時間及劉達(dá)時何粗的反酬單卷的時款方取押盤/餐收/預(yù)忖款等】）即賀順敵謂度計劃 調(diào)盛過程中原 妙歷列怕抖