【文章內(nèi)容簡介】 same time to improve the performance of the system with the cache structure, the design pattern of EJB, and the optimizing method of calculating authority data. The unified authority system is implemented by J2EE, EJB, XML, Web Services, Oracle, Weblogic etc. Keywords Authority System。 Unified。 J2EE。 Web Services。 UML 基于 Web Services 的統(tǒng)一權(quán)限系統(tǒng) 第 1 章 引言 第 6 頁 共 80 頁 第 1章 引 言 . 權(quán)限系統(tǒng)在信息系統(tǒng)中的地位 對于信息 管理 系統(tǒng)，不管大型的 企業(yè)級系統(tǒng) ，還是小型的 單機(jī) 系統(tǒng)，抽象出來， 都是 由兩個主要的引擎組成：一是管理系統(tǒng)權(quán)限的身份認(rèn)證引擎，解決“ 用戶在什么時(shí)間、什么范圍能做什么事情”，另一個是管理任務(wù)流程的工作流引擎，解決“按什么樣的步驟去做事情”。本文主要討論前者，采用 Web Services 技術(shù)，使權(quán)限系統(tǒng)從傳統(tǒng)的業(yè)務(wù)系統(tǒng)中獨(dú)立出來，形成“統(tǒng)一權(quán)限系統(tǒng)”，使多個不同的業(yè)務(wù)系統(tǒng)共享同一個權(quán)限系統(tǒng)，業(yè)務(wù)系統(tǒng)不必再關(guān)心權(quán)限方面的細(xì)節(jié)，從而可以將精力全部放到具體業(yè)務(wù)功能的開發(fā)上。 在任何的信息系統(tǒng)中，權(quán)限管理都處于核心的地位。 權(quán)限管理既要保障系統(tǒng)的安全，又要方便管理 和使用 。 如果將信息系統(tǒng)比作倉庫，各個業(yè)務(wù)系統(tǒng)比作倉庫中不同的房間，業(yè)務(wù)系統(tǒng)提供的功能比作 房間中存放的貨物，那么權(quán)限管理就是倉庫大門和每個房間門上的鎖，如果沒有鎖，倉庫就任人進(jìn)出自由，沒有安全可言；而 如果每個房間都 用了不 同的鎖，則鑰匙太多，開鎖太麻煩，讓人來去不便。如何為信息系統(tǒng)設(shè)計(jì) 一把稱心如意的“鎖”，既要保障倉庫的安全，又要讓人進(jìn)出方便自如？ —— 這就是本文要解決的問題。采用 Web Services 技術(shù)，打造“統(tǒng)一權(quán)限系統(tǒng)”這把鎖，當(dāng)所有的業(yè)務(wù)系統(tǒng)都使用同樣的新鎖（或改裝原來的鎖變?yōu)樾碌逆i），那么業(yè)務(wù)系統(tǒng)就不必再關(guān)心“鎖”的問題，從而可以將全部的精力放到具體業(yè)務(wù)功能 的開發(fā) 上。 . 研究 背景 上世紀(jì) 九十年代，幾乎所有券商的信息系統(tǒng)均采用外購的方式構(gòu)建，券商的IT 人員只負(fù)責(zé)維護(hù)，經(jīng)實(shí)踐證明，只有像證券交易系統(tǒng)這類不需要經(jīng)常變動的軟件運(yùn)行效果不錯外，其他日常信息系統(tǒng)（如 OA 系統(tǒng)，報(bào)表系統(tǒng)等）運(yùn)行的效果都非常的差。其主要原因是日常信息系統(tǒng)經(jīng)常要修改功能和增加新的模塊，這就要和軟件供應(yīng)商進(jìn)行溝通，經(jīng)常會因?yàn)闀r(shí)間和經(jīng)費(fèi)的原因放棄 了 一些很好的想法，系統(tǒng)也因此更新慢或長時(shí)間不更新，不能滿足日益增長的需求變化。作為一家 2021 年新成立的綜合類券商， 第一證券有限公司 在籌建的時(shí)候，高層領(lǐng)導(dǎo)就認(rèn)識到了自主研發(fā)的重要性，投入 了大量的資金和人力，組建自己的開發(fā)團(tuán)隊(duì)，負(fù)責(zé)全公司綜合信息系統(tǒng)的開發(fā)和維護(hù)，并提出了做到行業(yè)內(nèi)領(lǐng)先的目標(biāo)。 公司 雖然 處于起步階段， 信息系統(tǒng)一無所有，但領(lǐng)導(dǎo)對于信息系統(tǒng)建設(shè)的起點(diǎn)要求并不低，要力爭達(dá)到簡單方便的維護(hù)性，較強(qiáng)的擴(kuò)展性，較好的健壯性?；?Web Services 的統(tǒng)一權(quán)限系統(tǒng) 第 1 章 引言 第 7 頁 共 80 頁 而且公司今后的發(fā)展會越來越依靠信息系統(tǒng)，業(yè)務(wù)系統(tǒng)也會越來越多，比如 OA系統(tǒng)、 CRM 系統(tǒng)、 CRU 系統(tǒng)、稽核系統(tǒng)等等，這些系統(tǒng)中， 對 權(quán)限 控制 方面的 要求都非常高 ，特別是跟管理和財(cái)務(wù)掛鉤的 CRU 和 CRM 系統(tǒng)，所以要 花了大量精力在權(quán)限系統(tǒng)的設(shè)計(jì)和開發(fā)上，于是也就有了本文提出的統(tǒng) 一權(quán)限系統(tǒng)。 . 本論文的工作內(nèi)容 本 論文 提出了基于 Web Services 技術(shù)的統(tǒng)一權(quán)限系統(tǒng)架構(gòu)，采用這樣架構(gòu)，可以將權(quán)限系統(tǒng)從業(yè)務(wù)系統(tǒng)中獨(dú)立出來，多個不同的業(yè)務(wù)系統(tǒng)能夠共享一個權(quán)限系統(tǒng)，業(yè)務(wù)系統(tǒng)不必再關(guān)心權(quán)限方面的細(xì)節(jié)，從而可以將精力全部放到具體業(yè)務(wù)功能的開發(fā)上。而且將權(quán)限系統(tǒng)封裝成服務(wù)，為其他系統(tǒng)提供支持，成為 SOA 架構(gòu)的一個實(shí)用案例。 目前比較流行的權(quán)限系統(tǒng) 架 構(gòu)在開發(fā) 、 維護(hù) 、使用 中 或多或少 都存在 一些 問題，尤其是對于不同架構(gòu) 、不同部署環(huán)境的軟件 。 本文采用 Web Services 技術(shù)解決了這些問題，主要討論 了如何實(shí)現(xiàn)這樣的架構(gòu)，并分析了在設(shè)計(jì)和實(shí)現(xiàn)中遇到的問題，并給出了相應(yīng)的解決方案、 技術(shù)實(shí)現(xiàn)上，采用 J2EE 平臺， JSP、 Servlet、 EJB、 XML、 Web Services 技術(shù)， Oracle 數(shù)據(jù)庫， Weblogic 應(yīng)用服務(wù)器來實(shí)現(xiàn)該系統(tǒng)，開發(fā)過程中采用適當(dāng)?shù)脑O(shè)計(jì)模式來提高系統(tǒng)的完善性、健壯性、可擴(kuò)展性。 . 本文的章節(jié)安排 本文共分為 七 個章節(jié)，詳細(xì)地探討了 統(tǒng)一權(quán)限系統(tǒng)的設(shè)計(jì)和實(shí)現(xiàn)過程 。 本章從剖析現(xiàn)有的證券信息系統(tǒng)弊端入手，分析了現(xiàn)有系統(tǒng)對信息管理與渠道整合的不足，簡單介紹了本文的現(xiàn)實(shí)意義。 第二章 剖析了權(quán) 限系統(tǒng)的現(xiàn)狀，討論了其存在的不足之處 。 第三章 針對傳統(tǒng)權(quán)限系統(tǒng)存在的弊端，提出了統(tǒng)一權(quán)限系統(tǒng)架構(gòu)，并討論了新架構(gòu)的可行性 。 第四章 討論了 統(tǒng)一權(quán)限系統(tǒng)的 基本 設(shè)計(jì) ，其中詳細(xì)介紹了基于角色的權(quán)限分配和管理策略、權(quán)限的抽象模型等 。 第 五 章 討論了統(tǒng)一權(quán)限系統(tǒng)中核心模塊的設(shè)計(jì) ，以及重點(diǎn)技術(shù)難題的解決 。 第六 章 介紹了統(tǒng)一權(quán)限系統(tǒng)的技術(shù)架構(gòu)、實(shí)現(xiàn)的技術(shù)平臺、技術(shù)關(guān)鍵點(diǎn) ，并對系統(tǒng)的性能的優(yōu)化提出了幾個改進(jìn)方法 。 最后一章 總結(jié)了統(tǒng)一權(quán)限系統(tǒng)的所帶來的好處 ， 以及還存在的不足 ，并對未來的工作進(jìn)行了展望。 基于 Web Services 的統(tǒng)一權(quán)限系統(tǒng) 第 2 章 權(quán)限系統(tǒng)現(xiàn)狀分析 第 8 頁 共 80 頁 第 2章 權(quán)限系統(tǒng)現(xiàn)狀分析 . 傳統(tǒng)的 權(quán)限系統(tǒng) 架構(gòu) 目前的權(quán)限系統(tǒng)，大多數(shù)是采用代碼復(fù)用和數(shù)據(jù)庫結(jié)構(gòu)復(fù)用的方式集成到具體的業(yè)務(wù)系統(tǒng)中 [1]， 例 如某公司的信息系統(tǒng)有若干個子系統(tǒng)（ OA 系統(tǒng)、 CRM系統(tǒng)、稽核系統(tǒng)、財(cái)務(wù)系統(tǒng)等等），而這些系統(tǒng)可能部署在不同的服務(wù)器上，也有可能是完全不同的軟件架構(gòu)（有些是基于 B/S 結(jié)構(gòu)的 Web 項(xiàng)目，有些又是基于 C/S結(jié)構(gòu)的應(yīng)用程序等等），更可能部署在不同的平臺上（有些部署在 Windows平臺上，有些又部署在 Unix 平臺上），每個系統(tǒng)中均有一個代碼相同的權(quán)限管理模塊，來管理自己系統(tǒng)中用戶的權(quán)限，這些權(quán)限的數(shù)據(jù)可能是共享的（ 數(shù)據(jù)保存在各系統(tǒng)均能訪問的同一個數(shù)據(jù)庫中），或者根本就是獨(dú)享的（數(shù)據(jù)保存在自己的數(shù)據(jù)庫中）。 傳統(tǒng)的權(quán)限系統(tǒng)如圖 ： 圖 ： 傳統(tǒng)的權(quán)限系統(tǒng)部署 . 傳統(tǒng)的權(quán)限系統(tǒng)的不足之處 對于軟件產(chǎn)品開發(fā)公司，也會碰到同樣的問題，公司的多個不同產(chǎn)品，不管是開發(fā)過程，還是發(fā)布后，都得將權(quán)限系統(tǒng)集成到產(chǎn)品系統(tǒng)中。 這樣做有如下的不足之處： 基于 Web Services 的統(tǒng)一權(quán)限系統(tǒng) 第 2 章 權(quán)限系統(tǒng)現(xiàn)狀分析 第 9 頁 共 80 頁 . 不易 維護(hù) 這是采用代碼復(fù)用和數(shù)據(jù)庫結(jié)構(gòu)復(fù)用方式的普遍缺點(diǎn) ， 一旦權(quán)限系統(tǒng)做了修改或升級，維護(hù)成本 會 很高 。 因?yàn)闄?quán)限系統(tǒng)是采用代碼復(fù)用和數(shù)據(jù)庫結(jié)構(gòu)復(fù)用的方式實(shí)現(xiàn)的，所以一旦權(quán)限系統(tǒng)做 了修改或者升級，則需要更新所有系統(tǒng)中的權(quán)限管理代碼及數(shù)據(jù)庫結(jié)構(gòu)，而且要保證所有系統(tǒng)中已有的權(quán)限數(shù)據(jù)能平滑的過渡。這樣的維護(hù)工作量是難以想象的，而且需要人工干預(yù)，也無形中增加了系統(tǒng)復(fù)雜度 ， 對于開發(fā)人員和維護(hù)人員來說都是一件“痛苦”的事情。 . 不能支持不同 平臺和架構(gòu) 的 軟件 對于不同架構(gòu)、不同部署環(huán)境的軟件，必須開發(fā)不同的權(quán)限系統(tǒng) 。 例如 B/S架構(gòu)和 C/S 架構(gòu)的軟件的就必須開發(fā)不同的權(quán)限管理系統(tǒng)，部署在 Windows 下和 Unix 下的軟件有時(shí)候也要開發(fā)不同的權(quán)限管理系統(tǒng)。 . 不方便共享數(shù)據(jù) 權(quán)限系統(tǒng)中經(jīng)常要共享一些數(shù) 據(jù)：比如用戶信息、部門結(jié)構(gòu)，職位結(jié)構(gòu)等等數(shù)據(jù)，每個業(yè)務(wù)系統(tǒng)都需要用到這些數(shù)據(jù)。而權(quán)限的數(shù)據(jù)共享是基于數(shù)據(jù)庫級的，這就需開發(fā)額外的程序來管理系統(tǒng)中共享數(shù)據(jù)，業(yè)務(wù)系統(tǒng)只能使用這些數(shù)據(jù)，而不能更改這些數(shù)據(jù)。這也造成開發(fā)成本和維護(hù)成本的雙重增加。 . 系統(tǒng)安全性降低 由于數(shù)據(jù)是基于數(shù)據(jù)庫級別的共享，每個子系統(tǒng)都能直接訪問數(shù)據(jù)庫，所以在安全性比較差。 直觀，不 方便 權(quán)限的管理和維護(hù)不方便 ， 需要進(jìn)入到各個業(yè)務(wù)系統(tǒng)的權(quán)限管理模塊才能管理對應(yīng)的權(quán)限，操作復(fù)雜，且不直觀?；?Web Services 的統(tǒng)一權(quán)限系統(tǒng) 第 3 章 新的解決方案分析 第 10 頁 共 80 頁 第 3章 新的解決方案 分析 . 新的解決方案 由于 傳統(tǒng)的權(quán)限系 統(tǒng)存在 以上的不足， 所以 有理由要尋找更好的權(quán)限系統(tǒng)解決方案。 仔細(xì)分析 傳統(tǒng)權(quán)限系統(tǒng) 的不足，不難發(fā)現(xiàn)問題主要集中在 三 點(diǎn)： 要改變目前基于代碼和數(shù)據(jù)庫結(jié)構(gòu)復(fù)用的模式，使權(quán)限系統(tǒng)的修改和升級 盡量不要影響業(yè)務(wù)系統(tǒng) 。 要尋找更好的方式共享系統(tǒng)中公用的權(quán)限數(shù)據(jù)。 要能方便的管理整個系統(tǒng)中的用戶權(quán)限。 再仔細(xì)考慮一下權(quán)限系統(tǒng)的主要作用： 管理業(yè)務(wù)系統(tǒng)的權(quán)限，登記功能，并給用戶分配權(quán)限。 讓業(yè)務(wù)系統(tǒng)知道用戶在 哪些 范圍內(nèi)可以執(zhí)行哪些操作，以正確顯示用戶能看到的界面。 用戶能根據(jù)自己的權(quán)限情況，來管理自己 的權(quán)限（例如：如果用戶擁有授權(quán)權(quán)限，則他可以將自己的權(quán)限授權(quán)給其允許授權(quán)的對象）。 對比一下前面提到的權(quán)限系統(tǒng)的不足和主要作用， 本文 發(fā)現(xiàn)，可以將權(quán)限系統(tǒng)的大部分功能從業(yè)務(wù)系統(tǒng)中抽象出來，形成一個獨(dú)立的系統(tǒng)，“統(tǒng)一權(quán)限系統(tǒng)”，業(yè)務(wù)系統(tǒng)只保留權(quán)限查詢 和讀取系統(tǒng)共用數(shù)據(jù)的 功能。“統(tǒng)一權(quán)限系統(tǒng)”通過兩個方式向業(yè)務(wù)系統(tǒng)提供服務(wù)： 通過 Web Services 向子系統(tǒng)提供權(quán)限查詢服務(wù) 通過 Web頁面 服務(wù)向子系統(tǒng)提供權(quán)限管理服務(wù)（功能登記、權(quán)限授予、權(quán)限變更等等）。 統(tǒng)一 權(quán)限系統(tǒng)部署示意圖 如圖 所示 ： 基于 Web Services 的統(tǒng)一權(quán)限系統(tǒng) 第 3 章 新的解決方案分析 第 11 頁 共 80 頁 圖 ： 傳統(tǒng)的權(quán)限系統(tǒng)部署 . 可行性分析 異構(gòu)系統(tǒng)之間的通訊 也正是 Web Services 大展身手的領(lǐng)域， 經(jīng)過改進(jìn)的架構(gòu)可以 這樣的設(shè)計(jì)可以 很好的彌補(bǔ)傳統(tǒng)架構(gòu)的不足： 因?yàn)闄?quán)限是集中式管理，業(yè)務(wù)系統(tǒng)中只 需使用 Web Services 客戶端接口（ class jar 包） 來 查詢權(quán)限數(shù)據(jù) 及獲得系統(tǒng)共享的數(shù)據(jù)。 客戶端只是個接口，而具體的實(shí)現(xiàn)代碼是放在“統(tǒng)一權(quán)限系統(tǒng)”中的。 這些 Web Services 客戶端接口以包的形式引入到業(yè)務(wù)系統(tǒng)中使用。權(quán)限系統(tǒng)的修改和升級不會影響到業(yè)務(wù)系統(tǒng)，因?yàn)闃I(yè)務(wù)系統(tǒng)使用的只是 Web Services 客戶端接口 而已 ，這些接口一般是不會改變的， 只要保持客戶端接口 名字 不變，統(tǒng)一權(quán)限系統(tǒng)的修改和升級就不會影響到業(yè)務(wù)系統(tǒng)。 即使 接口名字 改變 了，也可通過方法重構(gòu)的方式修改接口包 ，業(yè)務(wù)系統(tǒng) 中 只需要重新引入新的包即可完成更新。 權(quán)限系統(tǒng)中的公用數(shù)據(jù)是通過 Web Services 服務(wù)進(jìn)行共享， 解決了基于數(shù)據(jù)庫級共享數(shù)據(jù)的不足。 對客戶端調(diào)用來說，不僅數(shù)據(jù)庫的結(jié)構(gòu)是透明的，而且可以通過調(diào)用接口來實(shí)現(xiàn)調(diào)用權(quán)限的限制。 用戶和 權(quán)限都是通過“統(tǒng)一權(quán)限系統(tǒng)”的 Web 頁面 統(tǒng)一管理， 并可實(shí)現(xiàn)用戶的單點(diǎn) 登陸 。 基于 Web Services 的統(tǒng)一權(quán)限系統(tǒng) 第 3 章 新的解決方案分析 第 12 頁 共 80 頁 Web Services 的最大的優(yōu)點(diǎn)就是 整合異構(gòu)系統(tǒng)間的數(shù)據(jù) 。只要是采用Web Services 標(biāo)準(zhǔn)的軟件，都可以來訪問 Web Services 服務(wù)，這就打破了 B/S，C/S的軟件架構(gòu)限制，也不存在 Windows 和 Unix的平臺限制了。 基于以上的分析，用 Web Services 來實(shí)現(xiàn)權(quán)限的統(tǒng)一管理是完全可行，而且是非常有必要的 [2]。 . 與 類似系統(tǒng)的比較 可能有人覺得本 文提出的 系統(tǒng)和現(xiàn)在比較流行的 一些 系統(tǒng)雷同或類似，其實(shí)并非如此。下面將做出討論。 . 與 單點(diǎn) 登陸 系統(tǒng)（ SSO） 的比較 在 信息系統(tǒng)的 建設(shè) 過 程中，多個應(yīng)用系統(tǒng) 一般是在不同的時(shí)期開發(fā)完成的。各應(yīng)用系統(tǒng)由于功能側(cè)重、設(shè)計(jì)方法和開發(fā)技術(shù)有所不同，也就形成了各自獨(dú)立 的用戶庫和用戶認(rèn)證體系。隨著系統(tǒng)的擴(kuò)充和發(fā)展， 每個應(yīng)用系統(tǒng)中 都有獨(dú)立的用戶賬號，當(dāng) 用戶 需要 使用網(wǎng)站的多個應(yīng)用系統(tǒng) 時(shí)，需要頻繁的在各個系統(tǒng)中進(jìn)行 登陸 ， 沒有一個整體的 用戶賬號 概念，進(jìn)入每一個應(yīng)用系統(tǒng)前都需要以該應(yīng)用系統(tǒng)的賬號來 登陸 ， 這 會 給用戶 帶來 非常 不方便的使用感受，用戶會想：既然我使用的是同一個 信息系統(tǒng)中 的應(yīng)用，為什么不能 經(jīng)過一 次 登陸 之后就 不必再經(jīng)過應(yīng)用系統(tǒng)認(rèn)證直接進(jìn)入應(yīng)用系統(tǒng)呢？ 這樣的困境尤其在 B/S 架構(gòu)的系 統(tǒng)中經(jīng)常會遇到。 單點(diǎn) 登陸 系統(tǒng) 的應(yīng)用 前題條件 是： ? 已經(jīng)存在多個系統(tǒng)； ? 用戶從一個系統(tǒng)訪問到另外一個系統(tǒng)時(shí)需要 登陸 后 才能