① Web 系統中用戶 許可權之間的關系 是一對多 還是 多對多 他們之間有聯系嗎
前言：
許可權往往是一個極其復雜的問題，但也可簡單表述為這樣的邏輯表達式：判斷「who對what(which)進行how的操作」的邏輯表達式是否為真。針對不同的應用，需要根據項目的實際情況和具體架構，在維護性、靈活性、完整性等n多個方案之間比較權衡，選擇符合的方案。
目標：
直觀，因為系統最終會由最終用戶來維護，許可權分配的直觀和容易理解，顯得比較重要，系統不辭勞苦的實現了組的繼承，除了功能的必須，更主要的就是因為它足夠直觀。
簡單，包括概念數量上的簡單和意義上的簡單還有功能上的簡單。想用一個許可權系統解決所有的許可權問題是不現實的。設計中將常常變化的「定製」特點比較強的部分判斷為業務邏輯，而將常常相同的「通用」特點比較強的部分判斷為許可權邏輯就是基於這樣的思路。
擴展，採用可繼承在擴展上的困難。的group概念在支持許可權以組方式定義的同時有效避免了重定義時
現狀：
對於在企業環境中的訪問控制方法，一般有三種：
1.自主型訪問控制方法。目前在我國的大多數的信息系統中的訪問控制模塊中基本是藉助於自主型訪問控制方法中的訪問控制列表(acls)。
2.強制型訪問控制方法。用於多層次安全級別的軍事應用。
3.基於角色的訪問控制方法（rbac）。是目前公認的解決大型企業的統一資源訪問控制的有效方法。其顯著的兩大特徵是：1.減小授權管理的復雜性，降低管理開銷。2.靈活地支持企業的安全策略，並對企業的變化有很大的伸縮性。
名詞：
粗粒度：表示類別級，即僅考慮對象的類別(the type of object)，不考慮對象的某個特
定實例。比如，用戶管理中，創建、刪除，對所有的用戶都一視同仁，並不區分操作的具體對象實例。
細粒度：表示實例級，即需要考慮具體對象的實例(the instance of object)，當然，細
粒度是在考慮粗粒度的對象類別之後才再考慮特定實例。比如，合同管理中，列表、刪除，需要區分該合同實例是否為當前用戶所創建。
原則：
許可權邏輯配合業務邏輯。即許可權系統以為業務邏輯提供服務為目標。相當多細粒度的許可權問題因其極其獨特而不具通用意義，它們也能被理解為是「業務邏輯」的一部分。比如，要求：「合同資源只能被它的創建者刪除，與創建者同組的用戶可以修改，所有的用戶能夠瀏覽」。這既可以認為是一個細粒度的許可權問題，也可以認為是一個業務邏輯問題。在這里它是業務邏輯問題，在整個許可權系統的架構設計之中不予過多考慮。當然，許可權系統的架構也必須要能支持這樣的控制判斷。或者說，系統提供足夠多但不是完全的控制能力。即，設計原則歸結為：「系統只提供粗粒度的許可權，細粒度的許可權被認為是業務邏輯的職責」。
需要再次強調的是，這里表述的許可權系統僅是一個「不完全」的許可權系統，即，它不提供所有關於許可權的問題的解決方法。它提供一個基礎，並解決那些具有「共性」的(或者說粗粒度的)部分。在這個基礎之上，根據「業務邏輯」的獨特許可權需求，編碼實現剩餘部分(或者說細粒度的)部分，才算完整。回到許可權的問題公式，通用的設計僅解決了who+what+how 的問題，其他的許可權問題留給業務邏輯解決。
概念：
who：許可權的擁用者或主體（principal、user、group、role、actor等等）
what：許可權針對的對象或資源（resource、class）。
how：具體的許可權（privilege, 正向授權與負向授權）。
role：是角色，擁有一定數量的許可權。
operator：操作。表明對what的how 操作。
說明：
user：與 role 相關，用戶僅僅是純粹的用戶，許可權是被分離出去了的。user是不能與 privilege 直接相關的，user 要擁有對某種資源的許可權，必須通過role去關聯。解決 who 的問題。
resource：就是系統的資源，比如部門新聞，文檔等各種可以被提供給用戶訪問的對象。資源可以反向包含自身，即樹狀結構，每一個資源節點可以與若干指定許可權類別相關可定義是否將其許可權應用於子節點。
privilege：是resource related的許可權。就是指，這個許可權是綁定在特定的資源實例上的。比如說部門新聞的發布許可權，叫做"部門新聞發布許可權"。這就表明，該privilege是一個發布許可權，而且是針對部門新聞這種資源的一種發布許可權。privilege是由creator在做開發時就確定的。許可權，包括系統定義許可權和用戶自定義許可權用戶自定義許可權之間可以指定排斥和包含關系(如：讀取，修改，管理三個許可權，管理 許可權 包含 前兩種許可權)。privilege 如"刪除" 是一個抽象的名詞，當它不與任何具體的 object 或 resource 綁定在一起時是沒有任何意義的。拿新聞發布來說，發布是一種許可權，但是只說發布它是毫無意義的。因為不知道發布可以操作的對象是什麼。只有當發布與新聞結合在一起時，才會產生真正的 privilege。這就是 privilege instance。許可權系統根據需求的不同可以延伸生很多不同的版本。
role：是粗粒度和細粒度(業務邏輯)的介面，一個基於粗粒度控制的許可權框架軟體，對外的介面應該是role，具體業務實現可以直接繼承或拓展豐富role的內容，role不是如同user或group的具體實體，它是介面概念，抽象的通稱。
group：用戶組，許可權分配的單位與載體。許可權不考慮分配給特定的用戶。組可以包括組(以實現許可權的繼承)。組可以包含用戶，組內用戶繼承組的許可權。group要實現繼承。即在創建時必須要指定該group的parent是什麼group。在粗粒度控制上，可以認為，只要某用戶直接或者間接的屬於某個group那麼它就具備這個group的所有操作許可。細粒度控制上，在業務邏輯的判斷中，user僅應關注其直接屬於的group，用來判斷是否「同組」 。group是可繼承的，對於一個分級的許可權實現，某個group通過「繼承」就已經直接獲得了其父group所擁有的所有「許可權集合」，對這個group而言，需要與許可權建立直接關聯的，僅是它比起其父group需要「擴展」的那部分許可權。子組繼承父組的所有許可權，規則來得更簡單，同時意味著管理更容易。為了更進一步實現許可權的繼承，最直接的就是在group上引入「父子關系」。
user與group是多對多的關系。即一個user可以屬於多個group之中，一個group可以包括多個user。子group與父group是多對一的關系。operator某種意義上類似於resource + privilege概念，但這里的resource僅包括resource type不表示resource instance。group 可以直接映射組織結構，role 可以直接映射組織結構中的業務角色，比較直觀，而且也足夠靈活。role對系統的貢獻實質上就是提供了一個比較粗顆粒的分配單位。
group與operator是多對多的關系。各概念的關系圖示如下：
解釋：
operator的定義包括了resource type和method概念。即，what和how的概念。之所以將what和how綁定在一起作為一個operator概念而不是分開建模再建立關聯，這是因為很多的how對於某what才有意義。比如，發布操作對新聞對象才有意義，對用戶對象則沒有意義。
how本身的意義也有所不同，具體來說，對於每一個what可以定義n種操作。比如，對於合同這類對象，可以定義創建操作、提交操作、檢查沖突操作等。可以認為，how概念對應於每一個商業方法。其中，與具體用戶身份相關的操作既可以定義在操作的業務邏輯之中，也可以定義在操作級別。比如，創建者的瀏覽視圖與普通用戶的瀏覽視圖要求內容不同。既可以在外部定義兩個操作方法，也可以在一個操作方法的內部根據具體邏輯進行處理。具體應用哪一種方式應依據實際情況進行處理。
這樣的架構，應能在易於理解和管理的情況下，滿足絕大部分粗粒度許可權控制的功能需要。但是除了粗粒度許可權，系統中必然還會包括無數對具體instance的細粒度許可權。這些問題，被留給業務邏輯來解決，這樣的考慮基於以下兩點：
一方面，細粒度的許可權判斷必須要在資源上建模許可權分配的支持信息才可能得以實現。比如，如果要求創建者和普通用戶看到不同的信息內容，那麼，資源本身應該有其創建者的信息。另一方面，細粒度的許可權常常具有相當大的業務邏輯相關性。對不同的業務邏輯，常常意味著完全不同的許可權判定原則和策略。相比之下，粗粒度的許可權更具通用性，將其實現為一個架構，更有重用價值；而將細粒度的許可權判斷實現為一個架構級別的東西就顯得繁瑣，而且不是那麼的有必要，用定製的代碼來實現就更簡潔，更靈活。
所以細粒度控制應該在底層解決，resource在實例化的時候，必需指定owner和groupprivilege在對resource進行操作時也必然會確定約束類型：究竟是ownerok還是groupok還是allok。group應和role嚴格分離user和group是多對多的關系，group只用於對用戶分類，不包含任何role的意義；role只授予user，而不是group。如果用戶需要還沒有的多種privilege的組合，必須新增role。privilege必須能夠訪問resource，同時帶user參數，這樣許可權控制就完備了。
思想：
許可權系統的核心由以下三部分構成：1.創造許可權，2.分配許可權，3.使用許可權，然後，系統各部分的主要參與者對照如下：1.創造許可權 - creator創造，2.分配許可權 - administrator 分配，3.使用許可權 - user：
1. creator 創造 privilege， creator 在設計和實現系統時會劃分，一個子系統或稱為模塊，應該有哪些許可權。這里完成的是 privilege 與 resource 的對象聲明，並沒有真正將 privilege 與具體resource 實例聯系在一起，形成operator。
2. administrator 指定 privilege 與 resource instance 的關聯。在這一步， 許可權真正與資源實例聯繫到了一起， 產生了operator（privilege instance）。administrator利用operator這個基本元素，來創造他理想中的許可權模型。如，創建角色，創建用戶組，給用戶組分配用戶，將用戶組與角色關聯等等...這些操作都是由 administrator 來完成的。
3. user 使用 administrator 分配給的許可權去使用各個子系統。administrator 是用戶，在他的心目中有一個比較適合他管理和維護的許可權模型。於是，程序員只要回答一個問題，就是什麼許可權可以訪問什麼資源，也就是前面說的 operator。程序員提供 operator 就意味著給系統穿上了盔甲。administrator 就可以按照他的意願來建立他所希望的許可權框架可以自行增加，刪除，管理resource和privilege之間關系。可以自行設定用戶user和角色role的對應關系。(如果將 creator看作是 basic 的發明者， administrator 就是 basic 的使用者，他可以做一些腳本式的編程) operator是這個系統中最關鍵的部分，它是一個紐帶，一個系在programmer，administrator，user之間的紐帶。
用一個功能模塊來舉例子。
一．建立角色功能並做分配：
1．如果現在要做一個員工管理的模塊(即resources)，這個模塊有三個功能，分別是：增加，修改，刪除。給這三個功能各自分配一個id，這個id叫做功能代號：
emp_addemp，emp_deleteemp，emp_updateemp。
2．建立一個角色(role)，把上面的功能代碼加到這個角色擁有的許可權中，並保存到資料庫中。角色包括系統管理員，測試人員等。
3．建立一個員工的賬號，並把一種或幾種角色賦給這個員工。比如說這個員工既可以是公司管理人員，也可以是測試人員等。這樣他登錄到系統中將會只看到他擁有許可權的那些模塊。
二．把身份信息加到session中。
登錄時，先到資料庫中查找是否存在這個員工，如果存在，再根據員工的sn查找員工的許可權信息，把員工所有的許可權信息都入到一個hashmap中，比如就把上面的emp_addemp等放到這個hashmap中。然後把hashmap保存在一個userinfobean中。最後把這個userinfobean放到session中，這樣在整個程序的運行過程中，系統隨時都可以取得這個用戶的身份信息。
三．根據用戶的許可權做出不同的顯示。
可以對比當前員工的許可權和給這個菜單分配的「功能id」判斷當前用戶是否有打開這個菜單的許可權。例如：如果保存員工許可權的hashmap中沒有這三個id的任何一個，那這個菜單就不會顯示，如果員工的hashmap中有任何一個id，那這個菜單都會顯示。
對於一個新聞系統(resouce)，假設它有這樣的功能(privilege)：查看，發布，刪除，修改；假設對於刪除，有"新聞系統管理者只能刪除一月前發布的，而超級管理員可刪除所有的這樣的限制，這屬於業務邏輯(business logic)，而不屬於用戶許可權范圍。也就是說許可權負責有沒有刪除的permission，至於能刪除哪些內容應該根據userrole or usergroup來決定(當然給userrole or usergroup分配許可權時就應該包含上面兩條業務邏輯)。
一個用戶可以擁有多種角色，但同一時刻用戶只能用一種角色進入系統。角色的劃分方法可以根據實際情況劃分，按部門或機構進行劃分的，至於角色擁有多少許可權，這就看系統管理員賦給他多少的許可權了。用戶—角色—許可權的關鍵是角色。用戶登錄時是以用戶和角色兩種屬性進行登錄的（因為一個用戶可以擁有多種角色，但同一時刻只能扮演一種角色），根據角色得到用戶的許可權，登錄後進行初始化。這其中的技巧是同一時刻某一用戶只能用一種角色進行登錄。
針對不同的「角色」動態的建立不同的組，每個項目建立一個單獨的group，對於新的項目，建立新的 group 即可。在許可權判斷部分，應在商業方法上予以控制。比如：不同用戶的「操作能力」是不同的(粗粒度的控制應能滿足要求)，不同用戶的「可視區域」是不同的(體現在對被操作的對象的許可權數據，是否允許當前用戶訪問，這需要對業務數據建模的時候考慮許可權控制需要)。
擴展性：
有了用戶/許可權管理的基本框架，who(user/group)的概念是不會經常需要擴展的。變化的可能是系統中引入新的 what (新的resource類型)或者新的how(新的操作方式)。那在三個基本概念中，僅在permission上進行擴展是不夠的。這樣的設計中permission實質上解決了how 的問題，即表示了「怎樣」的操作。那麼這個「怎樣」是在哪一個層次上的定義呢？將permission定義在「商業方法」級別比較合適。比如，發布、購買、取消。每一個商業方法可以意味著用戶進行的一個「動作」。定義在商業邏輯的層次上，一方面保證了數據訪問代碼的「純潔性」，另一方面在功能上也是「足夠」的。也就是說，對更低層次，能自由的訪問數據，對更高層次，也能比較精細的控制許可權。
確定了permission定義的合適層次，更進一步，能夠發現permission實際上還隱含了what的概念。也就是說，對於what的how操作才會是一個完整的operator。比如，「發布」操作，隱含了「信息」的「發布」概念，而對於「商品」而言發布操作是沒有意義的。同樣的，「購買」操作，隱含了「商品」的「購買」概念。這里的綁定還體現在大量通用的同名的操作上，比如，需要區分「商品的刪除」與「信息的刪除」這兩個同名為「刪除」的不同操作。
提供許可權系統的擴展能力是在operator (resource + permission)的概念上進行擴展。proxy 模式是一個非常合適的實現方式。實現大致如下：在業務邏輯層(ejb session facade [stateful sessionbean]中)，取得該商業方法的methodname，再根據classname和 methodname 檢索operator 數據，然後依據這個operator信息和stateful中保存的user信息判斷當前用戶是否具備該方法的操作許可權。
應用在 ejb 模式下，可以定義一個很明確的 business層次，而一個business 可能意味著不同的視圖，當多個視圖都對應於一個業務邏輯的時候，比如，swing client以及 jsp client 訪問的是同一個 ejb 實現的 business。在 business 層上應用許可權較能提供集中的控制能力。實際上，如果許可權系統提供了查詢能力，那麼會發現，在視圖層次已經可以不去理解許可權，它只需要根據查詢結果控制界面就可以了。
靈活性：
group和role，只是一種輔助實現的手段，不是必需的。如果系統的role很多，逐個授權違背了「簡單，方便」的目的，那就引入group，將許可權相同的role組成一個group進行集中授權。role也一樣，是某一類operator的集合，是為了簡化針對多個operator的操作。
role把具體的用戶和組從許可權中解放出來。一個用戶可以承擔不同的角色，從而實現授權的靈活性。當然，group也可以實現類似的功能。但實際業務中，group劃分多以行政組織結構或業務功能劃分；如果為了許可權管理強行將一個用戶加入不同的組，會導致管理的復雜性。
domain的應用。為了授權更靈活，可以將where或者scope抽象出來，稱之為domain，真正的授權是在domain的范圍內進行，具體的resource將分屬於不同的domain。比如：一個新聞機構有國內與國外兩大分支，兩大分支內又都有不同的資源（體育類、生活類、時事政治類）。假如所有國內新聞的許可權規則都是一樣的，所有國外新聞的許可權規則也相同。則可以建立兩個域，分別授權，然後只要將各類新聞與不同的域關聯，受域上的許可權控制，從而使之簡化。
許可權系統還應該考慮將功能性的授權與資源性的授權分開。很多系統都只有對系統中的數據（資源）的維護有許可權控制，但沒有對系統功能的許可權控制。
許可權系統最好是可以分層管理而不是集中管理。大多客戶希望不同的部門能且僅能管理其部門內部的事務，而不是什麼都需要一個集中的administrator或administrators組來管理。雖然你可以將不同部門的人都加入administrators組，但他們的許可權過大，可以管理整個系統資源而不是該部門資源。
正向授權與負向授權：正向授權在開始時假定主體沒有任何許可權，然後根據需要授予許可權，適合於許可權要求嚴格的系統。負向授權在開始時假定主體有所有許可權，然後將某些特殊許可權收回。
許可權計算策略：系統中user，group，role都可以授權，許可權可以有正負向之分，在計算用戶的凈許可權時定義一套策略。
系統中應該有一個集中管理許可權的accessservice，負責許可權的維護（業務管理員、安全管理模塊）與使用（最終用戶、各功能模塊），該accessservice在實現時要同時考慮一般許可權與特殊許可權。雖然在具體實現上可以有很多，比如用proxy模式，但應該使這些proxy依賴於accessservice。各模塊功能中調用accessservice來檢查是否有相應的許可權。所以說，許可權管理不是安全管理模塊自己一個人的事情，而是與系統各功能模塊都有關系。每個功能模塊的開發人員都應該熟悉安全管理模塊，當然，也要從業務上熟悉本模塊的安全規則。
技術實現：
1．表單式認證，這是常用的，但用戶到達一個不被授權訪問的資源時，web容器就發
出一個html頁面，要求輸入用戶名和密碼。
2．一個基於servlet sign in/sign out來集中處理所有的request，缺點是必須由應用程序自己來處理。
3．用filter防止用戶訪問一些未被授權的資源，filter會截取所有request/response，
然後放置一個驗證通過的標識在用戶的session中，然後filter每次依靠這個標識來決定是否放行response。
這個模式分為：
gatekeeper ：採取filter或統一servlet的方式。
authenticator： 在web中使用jaas自己來實現。
用戶資格存儲ldap或資料庫：
1. gatekeeper攔截檢查每個到達受保護的資源。首先檢查這個用戶是否有已經創建
好的login session，如果沒有，gatekeeper 檢查是否有一個全局的和authenticator相關的session？
2. 如果沒有全局的session，這個用戶被導向到authenticator的sign-on 頁面，
要求提供用戶名和密碼。
3. authenticator接受用戶名和密碼，通過用戶的資格系統驗證用戶。
4. 如果驗證成功，authenticator將創建一個全局login session，並且導向gatekeeper
來為這個用戶在他的web應用中創建一個login session。
5. authenticator和gatekeepers聯合分享cookie，或者使用tokens在query字元里
② 基於Web的合同管理系統
下面是中達咨詢給大家帶來關於Web的合同管理系統的相關內容，以供參考。
合同管理作為企業管理中的重要一環,對合同數據的准確性、數據傳輸的安全性和業務處理的規范性有很高的要求.也正因如此,合同管理工作中繁瑣的業務流程限制了管理人員工作效率的提高;另外,如何有效地利用龐大的合同歷史數據,為合同管理人員提供必要的決策支持也成為一磨亮旅項新的課題.
隨著我國企業信息化水平的提高,合同管理已逐步由傳統的手工作業轉化為計算機管理.初期的合同管理系統為文檔管理系統,實現合同生命周期的過程記載,而後發展為數字化合同模型,對合同實行元素化管理,形成了規范的數據結構,可方便進行數據統計、比鍵迅較和查詢分析.技術架構也由單機模式逐步向區域網環境下的客戶端/伺服器結構過渡.由於合同管理工作的嚴謹性瞎凳和不同企業、政府部門在合同業務的處理上存在的巨大差異,所採用的合同管理系統多是根據自身的實際情況定製而成.例如:某軍事單位針對其科研合同管理中具有高保密度的要求和嚴格的審批程序,開發了科研合同管理系統[1];江蘇電視台根據廣告合同業務量大和需要播出編排等特殊情況,開發了廣告合同管理系統[2]等.
上述系統採用的是基於C/S結構的合同管理系統.而針對一些公司企業規模大、部門地域分散的特點,筆者提出了基於Web的合同管理模式,以滿足企業對信息靈敏度、規范化管理和輔助決策分析的要求.
1大型企業跨地域合同管理的需求分析
軟體系統的設計與開發中,最重要是從用戶的專業領域中整理出需要計算機處理的需求.在企業規模大,部門地域分散的特定情況下,下屬單位可能根據自身實際情況形成內部獨立的合同管理工作模式,這對整個企業集團合同管理的標准化造成了困難;而且基礎數據存留在基層部門,將形成信息孤島現象,造成信息不準確,利用率低等問題,合同數據傳輸的滯後也會對企業決策層的決策產生影響.除此之外,軟體應用存在跨地域實施的特點使得軟體開發人員必須要考慮應採用何種技術架構來解決軟體系統與不同軟體平台之間的兼容性問題,以及日後的升級、維護等問題.
通過對某公司進行調研,可以總結該企業跨地域合同管理的需求如下:
1)實現信息處理的標准化和數據化,在集團企業內部建立標準的合同管理流程和內容規范;
2)建立統一的資料庫系統,實現全企業數據集中管理,避免信息孤島的出現;
3)在合同生命周期內,實現數據信息跟蹤管理,包括基本信息和履行信息的管理;
4)實現合同的歸檔管理,以及合同數據查詢、統計等處理功能;
5)提供標准報表、自定義報表等多種格式的報表處理功能;
6)對客戶信息進行管理,在合同簽署前為客戶的資質評估提供數據支持;
7)提供合同示範文本、相關法律法規和授權委託信息等資料的信息管理功能;
8)確保合同管理工作的規范性和安全性.
2基於Web的合同管理系統設計
2.1Web應用系統的特點
目前,很多企業的管理信息系統採用了C/S的系統結構,這類系統的優點是與大型資料庫的聯接緊密,數據處理速度快,系統安全性好.但應用C/S結構建設的管理信息系統專用性強,難以跨平台使用,開發周期長、生命周期短,系統維護和升級成本太高,系統只能在區域網的小范圍內實現信息集成和信息共享,其封閉性限制了系統對外部資源的利用[3].而且,如果需要提供Internet/Intranet上的數據服務,舊的管理信息系統必須要以新的軟體技術重新編寫,造成重復開發成本高.
隨著互聯網在世界范圍內的普及和信息技術的發展,基於Web的信息系統對傳統管理信息系統的體系結構產生了巨大的影響.與C/S結構相比,基於Web的管理信息系統具有如下優勢:
1)開放性:基於Web的管理信息系統可以做到開放式的、跨平台的應用;
2)易於維護和升級:採用分布式多層應用技術,大大節省了用於系統維護和升級的時間和費用,也改善了C/S結構的延展性問題;
3)標准化:基於Internet上的公開協議和技術標准(如TCP/IP,HTTP,XML,SOAP等)可實現應用系統在Internet/Intranet上的集成,具有良好的擴展性.對於操作人員來說,客戶端可使用標准化的瀏覽器軟體,用戶界面的操作簡單易學[3-4];
4)安全性:與傳統的C/S結構相比,基於Web的管理信息系統在客戶端與資料庫伺服器之間增加了Web層伺服器和其他的中間層伺服器,使客戶端和資料庫伺服器不直接相連,可有效地防止用戶的非法入侵[5].此外,中間層為系統提供了基本的安全保護,並支持軟體開發人員使用SSL(SecuritySocketLayer)對傳輸的資料進行加密解密.
2.2合同管理系統的技術架構
系統採用基於Web的技術架構體系,使用大型資料庫MSSQLServer,以Delphi作為應用程序開發工具.在開發過程中,嚴格遵循了面向對象(ObjectOriented)技術原則,採用組件式(ComponentBased)開發,注重產品的技術架構(TechnicalInfrastructure)的建立,運用了WebService技術,能夠有效的支持產品的進一步發展和第三方的集成應用.圖1為系統結構圖.
WebService使用了標準的輸出介面WSDL(WebServiceDescriptionLanguage)為Internet/Intranet上的客戶端提供服務,它不再注重以什麼技術來實現Web解決方案.WebService將Web應用中以程序設計為導向的概念轉換為以服務為導向的概念,其最有價值的地方就在於能夠成為不同組件模型和異構系統之間的膠水集成技術.筆者所討論的合同管理系統採用了WebService技術,為日後必然出現的企業內部和企業間的系統集成提供了技術保障.
2.3合同管理的內容
合同內容一般應包括:當事人的名稱和住所;標的;數量;質量;價格與報酬;履約期限、地點和方式;違約責任;解決爭議的方法[6].合同管理系統中所包含的合同基本信息元素最終要根據企業所在的行業背景和企業自身的實際情況來決定.
合同管理的業務處理中,根據企業的實際情況制定標准一致的合同編碼規則,內容的規范性為構造數字化的合同模型,實現元素級的合同管理提供了方便.所討論的合同管理系統包含了合同編號、合同名稱、合同分類(內部合同、關聯交易合同、外部合同)、專業類別(買賣合同、工程建設合同、承攬合同、技術合同、其它合同)、管理方式(授權、審查、審批、局本部)、自定義分類、甲方/乙方、甲方單位、乙方單位、合同金額、項目計劃金額、簽約時間、審查時間、計劃履行開始、計劃履行截止等42項合同基本信息.
系統還包括了合同項目履行信息的實時跟蹤和管理.合同項目的履行信息有:合同項目的收(支)情況、標的物交付進度、爭議處理情況、合同變更信息以及資料歸檔情況等.項目實際履行數據與合同規定條款的對比可幫助合同管理者對合同履行情況全面、准確的把握.
另外,示範文本、法律法規等輔助信息的便捷查詢有助於合同的規范性管理,系統對客戶信息的記錄和分析能夠在客戶資質評估方面為合同管理人員提供決策支持.
2.4合同管理系統的功能模型
2.4.1客戶端的主要功能
客戶端的Web頁面分為合同業務客戶頁面和業務管理員頁面.業務客戶的Web頁面實現了客戶在線填寫合同申請表、在線下載申請表和在線列印申請表的功能.
業務管理員的Web頁面主要包含5個模塊,各模塊的功能如圖2所示.
1)合同信息管理
合同信息管理包括了對合同基本信息和合同履行信息的管理,合同基本信息的數據項設置應根據企業不同的行業背景或者政府機構對合同管理系統的不同實施要求制定,並提供數據項的用戶自定義功能以拓展系統的實用性.對合同執行情況的跟蹤,包括了對合同履行進度、結算情況、變更內容、爭議解決辦法、合同履行完畢資料歸檔等情況的信息管理,並提供各項數據的對比分析功能.批量導入提供了傳統的Excel表格在指定格式下向資料庫的導入介面.系統提示根據系統管理員設置的提前天數,定期向用戶提示合同收付款和合同到期期限等信息.
2)報表處理
實現常規的報表運算和個性化的自定義報表處理功能.對於大型企業的合同管理工作,報表處理是一項十分麻煩的工作,基於Web的合同管理系統在統一管理合同數據信息的基礎上,可以提供便捷的報表運算和分析功能.
3)輔助信息
實現了客戶基本信息的管理,根據對客戶的歷史記錄和目前運營狀況的數據分析,提供對客戶資質的初步評估;實現對合同示範文本和相關法律法規的管理,以規范合同文本的錄入,方便用戶對法律法規及其相關規定的查詢.
4)系統管理
系統用戶的管理模塊負責對用戶的使用許可權進行設置,許可權分級管理對維護系統安全、正常的運行是非常必要的;擁有訪問許可權的用戶可以通過系統數據設置模塊,對合同管理的基礎數據項進行設置.
5)在線幫助
利用Internet技術快捷方便的為各級系統管理人員和用戶提供幫助信息.
2.4.2伺服器端的主要功能
系統的伺服器端負責接受和處理客戶端發出的請求,並以Web頁面的形式將處理結果返回給客戶端.合同管理系統採用了分布式多層應用的系統結構,伺服器端分為負責Web發布的Web伺服器,提供Internet/Intranet服務介面的WebService伺服器,存放主要的邏輯應用程序並提供事務管理功能的中間層伺服器,以及負責數據管理的資料庫伺服器.主要功能如下:
1)對登錄用戶進行身份驗證;
2)根據系統的分級許可權設定,限制用戶的使用許可權;
3)處理數據查詢、數據修改、報表處理等客戶端請求,返回Web頁面;
4)維護和管理系統資料庫;
5)運用中間層MTS(MicrosoftTransactionServer)所提供的交易管理服務,實現數據資料在操作過程中的完整性和一致性保護;
6)具備同時處理多個用戶請求的事務處理能力;
7)為數據傳輸和接收提供安全保障;
8)提供標準的服務介面WSDL,可以在Internet/Intranet上實現與其他應用系統的集成.
2.5基於Web的合同管理系統的安全性解決方案基於Internet的網路技術實現了各個終端跨地域的開放性互連和信息共享,但同時帶來了嚴重的安全性問題.運行在互聯網上的應用軟體系統,其安全性可能將受到如下幾種類型的威脅:數據被非法截獲、讀取和修改;未經授權的用戶訪問內部網路;用戶被冒名欺騙.合同信息屬於商業機密,因此基於Web的合同管理系統對系統的安全性有很高的要求[6],本系統採用了如下的安全性解決方案:
1)信息資源的第一層保護手段應是在內部網和互聯網的節點處設置防火牆,利用防火牆對網路和伺服器上的某些流量進行過濾和保護,監視在互聯網和內部網的數據交換過程中各類活動是否符合了站點的安全規定,這類活動包括電子郵件、文件傳輸、遠程登錄等[7].
2)互聯網環境下,數據的傳輸過程中很容易造成信息的泄漏,所以對瀏覽器和伺服器之間傳輸信息的加密是極有必要的.利用Internet的安全標准-安全套接層協議SSL(SecuritySocketLayer),可以對網路上傳輸的信息進行加密,實現客戶端瀏覽器和Web伺服器之間的信息以密文形式傳輸[8].
3)系統的用戶管理也是安全管理的重要組成部分,系統綜合運用了應用程序提供的基本安全控制功能,中間層MTS/COM+提供的組件、套件組件安全控制功能和資料庫伺服器所提供的資源安全控制功能,對用戶許可權進行了嚴格的管理和控制.
4結論
1)在合同管理計算機化之前,必須制定標準的工作流程和內容規范,實現全企業合同管理的標准化;
2)在企業規模較大、部門地域分散的情況下,為避免信息孤島的出現,必須建立企業級資料庫,應用Web技術設計合同管理軟體系統,保證數據的准確性和信息傳輸的實時性;
3)根據企業的實際情況構造軟體的功能模塊,系統共建立了17個子模塊;
4)建立完善的安全防範體系,確保合同管理工作的安全性.
更多關於工程/服務/采購類的標書代寫製作，提升中標率，您可以點擊底部官網客服免費咨詢：https://bid.lcyff.com/#/?source=bdzd