牛磊-OA項目總結(jié)談談你在OA項目中主要負責的模塊，并簡單的說一下它們的功能。答：我呢，在項目中主要負責了權(quán)限管理模塊，從初期的需求分析，到概念模型的設(shè)計都是我全權(quán)負責的，這個項目的權(quán)限是細化到操作的，這個是我覺得比較有分量的地方，以往我做過的一些權(quán)限都是限制在模塊層，所以它的概念模型的設(shè)計和認證就比較復雜一些，大體來講主要包括2個方面，一個是授權(quán)、另一個就是認證。授權(quán)：其實說明白點，我認為權(quán)限其實就是一種關(guān)聯(lián)，它的內(nèi)在關(guān)系是誰對某種資源進行某種操作，比如說某用戶擁有對某模塊進行某種操作的權(quán)限，實際上就是將用戶、操作的模塊、具體的操作關(guān)聯(lián)起來，這也就是我們經(jīng)常說的ACL訪問控制列表，當初設(shè)計ACL表的時候，我們跟用戶談的是基于CRUD操作的一些個限制，當我基于這個需求設(shè)計ACL表結(jié)構(gòu)時我的做法是將4種操作分別映射成C、R、U、D4個字段來表示這4個操作過程，但隨著項目的開發(fā)的深入，并不斷的和客戶進行交互之后，客戶提出需要加一些其他的限制，那么這個時候我就在考慮了，如果我還是將其他操作以單獨字段添加到ACL表中的話，就得去更改ACL表結(jié)構(gòu)，那么這個時候我就在尋求一種能一勞永逸解決這種問題的辦法，我首先想到的是抽出一個字段來表示所有操作，這樣做的話，如果后期再需要添加一些操作的話我就不用去更改ACL表結(jié)構(gòu)了，并能使我的認證操作更便捷、更統(tǒng)一化，它的關(guān)鍵是操作字段的類型選擇問題，起先想到用字符串來標識所有操作，這樣在認證的時候只要遍歷這個字符串就能夠得到相應的權(quán)限了，但這個項目對性能的要求是比較高的，而權(quán)限的認證又是隨時隨地的，也就是說權(quán)限的認證會頻繁發(fā)生，那么如果用字符串來表示操作的話，在認證時我們每次要將字符串轉(zhuǎn)化成字符數(shù)組，然后進行遍歷，拿到相應的操作位來確定權(quán)限，很明顯這樣在性能上并不是太好，所以我想到了位操作，我們都知道對位的操作要比對String類型操作效率快的多，而且int類型在計算機中是占32位的，所以我最后拿出的方案是用一個int類型的變量來代表所有的操作，這樣它能夠支持32種操作，對于一般的應用而言是足夠了，而且對于授權(quán)和認證我們可以通過簡單的按位或、按位與操作來解決。關(guān)于權(quán)限這塊,大家如果不理解前面的話也可以對照下面的例子來理解.一般的權(quán)限大多都是控制到模塊的,但控制到操作的大部分也是用如下方式:很明顯,同一個用戶對同一個模塊的限制有多少種就會有多少條記錄,那么遍歷的時候效率明顯不好,為了提高效率我們會這樣做(設(shè)計之初)這樣做解決了多條記錄的問題,但是不知道大家有沒有發(fā)現(xiàn),這樣是不便于擴展的,也就是說如果再要加一條限制的話我們可能要在ACL表再加入一字段來代表該限制,但是,一旦當數(shù)據(jù)庫表設(shè)計好了之后,一般是不允許再次更改的,因為要盡量設(shè)計出能夠通用的表,那么接下來我們是這樣做的.這樣做既解決了多條記錄的問題,又解決了擴展不易的問題,但這么做還存在一個問題,那就是認證和授權(quán)時候會相當麻煩,大家都知道權(quán)限的認證是即時的,也就是隨時隨地都需要認證的,那么認證操作肯定會非常頻繁,上面ACL表的permission字段的設(shè)計在認證時需要將其先轉(zhuǎn)化成字符數(shù)組,然后遍歷這個數(shù)組,拿到相應的操作符,并來判斷其有沒有這個權(quán)限,授權(quán)時也是相當麻煩的,你得根據(jù)一定的規(guī)則拼成類似于(X_X_X_X)這樣的字符串,很顯然從效率的角度去考慮這樣也不符合要求.最終的方案我們用int來表示權(quán)限,int占32位也就是說支持32個操作的擴展,而且這樣做,在認證和授權(quán)方面會非常的快速(位操作速度是非常快的),我們只需要通過簡單的按位或和按位與來完成授權(quán)和認證了.這就是權(quán)限這塊的東西了,你從最初的那么多個不足到最后的比較完美的實現(xiàn)不就是你遇到的困難和你最后的解決方案嗎?呵呵認證：整個項目的認證包括2個方面，一個是當用戶登陸時，需要拿到該用戶所有擁有讀取權(quán)限的模塊列表，另一個是當用戶對某個資源模塊進行某種操作之前需要認證其是否有該權(quán)限，對于本系統(tǒng)而言，是允許存在特權(quán)用戶的，也就是說，不僅能將角色賦予給用戶，而且也能將權(quán)限直接賦予給用戶。這樣在認證的時候就存在沖突問題，主要體現(xiàn)在2個方面。第一種沖突問題：當認證時該以用戶直接賦予的權(quán)限為準還是應該以該用戶擁有的角色所擁有的權(quán)限為準。比如說，直接賦予給用戶的權(quán)限表明用戶擁有對某模塊進行讀取操作的權(quán)限，而該用戶本身擁有的角色中卻不允許對該模塊進行讀取操作，那么我們進行認證的時候是該以用戶直接賦予的特權(quán)為準還是以用戶擁有的角色中的權(quán)限為準呢？記得很清楚，由于是我負責這個模塊，所以當初做需求時是跟著項目經(jīng)理一起做的，通過和客戶的溝通基本上確定了2種結(jié)論，一種是，有些客戶認為，既然是特權(quán)用戶，那么當然應該以特權(quán)用戶為準了.另一些客戶則認為，所謂特權(quán)用戶是在特殊的情況下賦予的權(quán)限，所以應該以通用的角色中的權(quán)限為準。解決方案：我不應該在程序中寫死就是以特權(quán)用戶為準，對于我現(xiàn)在要做的就是如何將這種靈活性留給客戶去操作，后來的解決辦法是在給某個特權(quán)用戶賦予特殊權(quán)限的時候有一個選擇，就是繼承和不繼承的選擇，也就是說，如果繼承，那么我們應該以角色中的權(quán)限為準，如果不繼承，那么就是以特權(quán)用戶特有的權(quán)限為準，這樣的話就能夠根據(jù)客戶操作時的意愿來確定以哪種權(quán)限為準了，很好的解決了這種沖突問題。第二種沖突問題：角色的沖突問題本系統(tǒng)是允許用戶擁有多個角色的，那么角色中的權(quán)限肯定也會存在沖突問題，當發(fā)生沖突的時候應該以哪個角色的權(quán)限為準的呢？這里面就有一個出發(fā)點的問題。舉一個很簡單的例子，對于總經(jīng)理角色和管理員角色而言，在對公文進行審批操作的時候我們理應以總經(jīng)理角色為準，但當對文件柜進行整理時我們就應該以管理員角色為準。解決方案：很明顯這種情況是不確定的，也就是說也需要做一個靈活的實現(xiàn)，而不是寫死在程序中，同樣站在客戶角度來考慮我們應該把這種靈活性的控制交給客戶來抉擇，所以在用戶和角色之間添加了一個優(yōu)先級概念，這樣當客戶給某一用戶賦予某個角色的時候就能夠根據(jù)實際情況來分配角色的優(yōu)先級，徹底的將靈活性交給了用戶。工作流模塊另外我也參與了工作流模塊的設(shè)計，在本系統(tǒng)中工作流的關(guān)鍵實際上就是公文的流轉(zhuǎn)，其實呢，很多軟件都說支持工作流，其實大部分是以一種硬編碼的形式將有限個流程寫死在程序中的，而本系統(tǒng)則真正做到了支持用戶自定義流程的功能。對于工作流引擎的實現(xiàn)，我認為它的關(guān)鍵就是在如何解析用戶自定義的流程，也就是能夠根據(jù)用戶自己定義的流程創(chuàng)建出相應的流程規(guī)則。本系統(tǒng)中的關(guān)鍵業(yè)務是體現(xiàn)在以下幾個方面??公文的創(chuàng)建（不太重要）公文的提交（將公文提交給下一個人）當用戶進行提交公文操作時能夠手動的選擇流程的走向，當公文創(chuàng)建開始到最后公文流轉(zhuǎn)結(jié)束，是將每一步的流程走向都交給客戶去選擇，而不是寫在程序中，我們做到了根據(jù)用戶選擇的流程走向選擇相應的流程進行流轉(zhuǎn)。?查詢待審公文列表當某個用戶登陸系統(tǒng)之后，能夠查詢到等待該用戶審批的所有公文列表?瀏覽審批歷史記錄用戶可以瀏覽審批過的公文信息其實每一步的實現(xiàn)也是一種關(guān)聯(lián)的體現(xiàn)，比如當創(chuàng)建公文的時候，需要將公文和創(chuàng)建者相關(guān)聯(lián)，當流程提交時需要建立公文和審批者之間的關(guān)聯(lián)，以便能夠?qū)崿F(xiàn)查詢待審公文列表的功能。應用JBPM實現(xiàn)以上業(yè)務首先進行流程定義，也就是通過流程設(shè)計器來定義流程，定義好流程之后，我們要進行部署也就是將流程實例保存在數(shù)據(jù)庫中???之后是創(chuàng)建公文接著是根據(jù)流程定義創(chuàng)建流程實例，并將公文和流程實例互相綁定。如何完成提交的呢？流程實例的創(chuàng)建需要某個特定的流程定義，而流程定義是某種流程規(guī)則的定義，而流程實例則是這種規(guī)則的體現(xiàn).JBPM中的關(guān)鍵主要是流程定義和流程實例的概念，另外一個就是關(guān)于怎么樣將JBPM和系統(tǒng)集成起來，那么在流程定義和流程執(zhí)行的概念中，需要區(qū)分流程定義和流程執(zhí)行的區(qū)別，定義呢，其實主要就是通過各種節(jié)點、線，實際上就相當于一個流程圖，把這個流程圖用對象模型表達出來，所謂定義其實就是把規(guī)則用某種語言，在JBPM中叫JPDL，用這種語言把它定義出來，它是一個XML，這種語言定義了一些XML中一些個元素，這些元素里面可以嵌套什么樣的元素，這些元素可以有什么樣的屬性等等等等類似這樣一些基本的規(guī)則，而流程執(zhí)行所面對的是一個流程實例的概念，一定要創(chuàng)建一個實例，通過這個實例來執(zhí)行流程，其實就是圖的執(zhí)行，我們可以通過signal從一個節(jié)點轉(zhuǎn)向到下一個節(jié)點，在創(chuàng)建一個流程實例的時候（根據(jù)流程定義創(chuàng)建相應的實例），某一個實例是按照相應的規(guī)則來創(chuàng)建的，在流程實例中包含了一些數(shù)據(jù)信息，這種數(shù)據(jù)信息當然就是流程實例變量，流轉(zhuǎn)從一個環(huán)節(jié)轉(zhuǎn)向另一個環(huán)節(jié)，通過在旁邊創(chuàng)建一個Token對象，通過Token的引用或者說一個指向發(fā)生改變，就叫做執(zhí)行，Token開始是指向起點的，調(diào)用signal就轉(zhuǎn)向到下一個節(jié)點，這樣就表示流程執(zhí)行到下一個節(jié)點了，在下一個節(jié)點該干一些什么事情，就是由節(jié)點本身來決定的，一步一步的往下走，如果找到那些比如說Fork節(jié)點，它就會在當前RootToken下面去創(chuàng)建多個子Token，通過各個子Token的signal來觸發(fā)流程往下走，這就是一個大概的流程走向。如果我們將JBPM集成到系統(tǒng)中應該去怎么做，總體來講應該有2個部分，第一個就是做一些準備工作，所謂的準備就是設(shè)計好流程，將流程部署到數(shù)據(jù)庫中去，第二個部分是做流轉(zhuǎn)，根據(jù)定義好的流程，創(chuàng)建出公文，然后將公文進行流轉(zhuǎn)，也就是從一個人手上流轉(zhuǎn)到另一個人手上，如何流轉(zhuǎn)呢？我們通過JBPM的流程實例來記錄一些信息，把這些信息從一個節(jié)點轉(zhuǎn)移到另一個節(jié)點。因此我們創(chuàng)建好流程實例之后就會將公文的ID保存在流程實例中，然后我們觸發(fā)JBPM的流程實例從一個節(jié)點轉(zhuǎn)到另一個節(jié)點，這樣就相當于將一個公文從一個人手上轉(zhuǎn)到另外一個人手上，那么在創(chuàng)建公文的同時，我們要將公文和流程實例互相的綁定在一起，這樣會更加容易使得我們開發(fā)起來更加方便一些，因為互相綁定之后，我們可以通過公文，可以得到這個公文對應的流程實例是什么，通過流程實例我們就可以得到這個公文現(xiàn)在所處的位置是什么，然后通過流程實例可以得到公文，這個是很顯然的，這些流程信息就是應該和流程實例綁定在一起，不能說流程實例里什么也沒有，那么就失去了流轉(zhuǎn)的意義了，所以應該把一些個有意義的信息放到流程實例中，這些有意義的信息可以是公文，也可以是一些別的信息，比如一些關(guān)鍵的變量（有條件的流轉(zhuǎn)等）。第二篇：OA項目總結(jié)4100字組織機構(gòu)管理模塊請描述一下你做的組織機構(gòu)管理模塊描述思路：1、組織機構(gòu)模塊的基本需求a)本模塊主要管理公司、子公司、部門、崗位、員工的信息b)公司下面可以創(chuàng)建子公司、部門c)部門下面可以創(chuàng)建子部門、崗位或員工d)崗位下面可以創(chuàng)建員工（即員工可以屬于某個崗位）e)公司、部門、崗位、員工形成一棵組織機構(gòu)樹，要求使用樹型方式來展現(xiàn)和管理2、組織機構(gòu)的總體設(shè)計思路a)公司、部門、崗位、員工可以看成同一種類型：Partyb)在Party上實現(xiàn)樹型結(jié)構(gòu)（父子關(guān)系）c)其它類型：公司、部門、崗位、員工均繼承Party（請畫出類圖）3、組織機構(gòu)的實現(xiàn)技巧a)利用jQuery的jsTree實現(xiàn)組織機構(gòu)樹b)利用jQuery的treeTable實現(xiàn)列表（AJAX、查詢、分頁）c)在組織機構(gòu)樹中顯示公司、部門、崗位的信息，點擊公司、部門、崗位，則可以顯示其詳細信息，及其下面的所有員工（利用hibernatefilter避免在樹上顯示員工信息）d)為了顯示某個公司或部門（包括其下級機構(gòu)）下面的所有員工，我們設(shè)計了一個sn，這個sn根據(jù)組織機構(gòu)的樹型結(jié)構(gòu)來取值，通過它便可以方便實現(xiàn)查詢需求。e)利用TreadLocal實現(xiàn)分頁參數(shù)的傳輸f)利用VO設(shè)計模式適應客戶端對數(shù)據(jù)格式的特殊要求4、我們這個設(shè)計的優(yōu)點在哪里a)通過樹的方式來管理，一目了然，層次清楚b)TheadLocal設(shè)計模式的運用大大降低了分頁查詢邏輯的封裝處理c)抽象出Party來，便于對所有的組織機構(gòu)實體進行統(tǒng)一的管理（比如方便我們后面的權(quán)限管理模塊把所有Party統(tǒng)一對待）5、我們這個設(shè)計的缺點在哪里a)沒有實現(xiàn)員工的調(diào)動管理（從一個部門調(diào)到另外一個部門），此功能在項目二期實現(xiàn)！b)員工不允許跨部門（即一個員工只能屬于一個部門，而不能同時屬于多個部門）c)在模型上沒有規(guī)定哪些類型的Party只能放在哪些類型的Party下面，比如，在一般的需求中，崗位下面肯定是不能掛一個公司的。我們針對這種需求，是通過具體的代碼邏輯來實現(xiàn)的，而沒有辦法在一個地方去統(tǒng)一定義這種規(guī)則。i.如果要實現(xiàn)這些邏輯的統(tǒng)一定義，可以參考“責任模式”！權(quán)限管理模塊請描述一下你做的權(quán)限管理模塊描述思路：1、權(quán)限管理的基本需求a)系統(tǒng)后臺有很多菜單項，同時各個頁面上也有很多功能按鈕，客戶要求我們的系統(tǒng)要能夠控制這些菜單項的訪問權(quán)限，也可以控制到具體每個功能按鈕的訪問權(quán)限b)客戶要求建立角色的概念（參考RBAC），能夠自由定制不同的角色，角色和用戶之間是多對多的。c)權(quán)限可以授予角色，然后把角色分配給用戶，這樣用戶就擁有了角色的權(quán)限d)權(quán)限也可以授予某個部門、某個崗位，這樣在這些部門或崗位下面的用戶就擁有了這些部門和崗位的權(quán)限e)客戶還要求權(quán)限也能直接授予用戶，這樣即使擁有相同的角色、相同的部門、相同的崗位，用戶的權(quán)限也可以是不同的f)這樣，用戶自身被授予的權(quán)限、用戶擁有的角色的權(quán)限、用戶所屬部門或崗位的權(quán)限這些要素聯(lián)合起來判斷，才能最終決定用戶的權(quán)限。g)因為用戶的權(quán)限可能從多個角色或部門、崗位中繼承下來，而這些角色、部門或崗位的授權(quán)極有可能會有沖突，比如一個角色的授權(quán)是允許訪問，而另外一個角色的授權(quán)是拒絕訪問，客戶要求，如果出現(xiàn)這種情況，就以拒絕為準，即不允許訪問。2、權(quán)限管理的總體設(shè)計思路a)因為權(quán)限可以被授予用戶、角色、部門、崗位等等，我們稱之為權(quán)限控制的“主體”，我們定義了一個接口Principal用來表示主體的概念，用戶、角色、部門、崗位等均實現(xiàn)這個接口b)我們要控制菜單項以及各種功能按鈕的訪問，我們稱這些菜單項和各種功能按鈕為權(quán)限控制的“資源”，定義了一個SysResource接口來表示資源的概念。c)菜單項是一種資源；而各種功能按鈕最終其實是要訪問后臺的某個類的某個方法，因此我們把Action類看成是一種資源（稱為“操作資源”），各種功能按鈕則對應了這個類里面的各種方法，我們把這些方法看成是這種資源的各種操作。d)我們定義了一個ACL用來表示哪些資源的哪些操作被授予了哪些主體，ACL中的主要屬性包括：主體類型（principalType）、主體ID(principalId)、資源類型(resourceType)、資源ID(resourceId)、操作狀態(tài)(aclState)，其中操作狀態(tài)是int類型，在Java中，一個int有32位（bit），我們定義資源的時候，把這個資源對應的操作映射到某一位上，規(guī)定在這一位上取1表示允許執(zhí)行那個操作，而取0表示不允許執(zhí)行那個操作。e)這樣，在授權(quán)的時候，我們直接改變相應操作的狀態(tài)位的取值即可；在認證的時候，直接判斷相應操作狀態(tài)位的取值3、權(quán)限管理的實現(xiàn)技巧a)在實現(xiàn)上，對于授權(quán)，我們界面上用jQuery和jQuery的插件jsTree來呈現(xiàn)菜單樹，在菜單樹的前面顯示一個CheckBox框，打勾表示允許，打叉表示拒絕；同時也做了一些右鍵點擊顯示上下文菜單，方便客戶執(zhí)行各種功能b)jsTree沒有打叉這種顯示方式，為了滿足我們的要求，所以對jsTree插件做了一些擴展（主要是修改它的js文件和css文件、圖片等），以便能支持更強大的顯示方式。c)因為我們把系統(tǒng)中的各種Action類及其方法，看成是各種資源及其操作，為了方便管理，我們利用Spring提供的API搜索具備某些特征的Action類及其方法（特定的命名及特定的注解），將這些信息插入數(shù)據(jù)庫，這樣便可以將其用于授權(quán)和認證。d)在認證的時候，我們實現(xiàn)了兩種方式的認證：i.第一是根據(jù)授權(quán)，能夠把沒有授權(quán)的菜單項屏蔽，也能夠把沒有授權(quán)的功能按鈕屏蔽；ii.第二，因為第一種認證方式會有一些安全性問題，比如客戶可以繞過功能按鈕，直接在瀏覽器輸入某個功能的地址，為了避免這種問題，我們在后臺也做了認證，根據(jù)當前請求的是哪個類的哪個方法，編寫攔截器，判斷當前登錄用戶是否具備這個權(quán)限，如果沒有這個權(quán)限，就不允許執(zhí)行這個操作！e)InitService和XMLf)自定義注解，利用Springde的API掃描類（大概說出一兩個類名）4、我們這個設(shè)計的優(yōu)點在哪里a)因為抽象出了主體和資源這兩個概念，核心的授權(quán)和認證代碼依賴于這兩個概念，而不是具體的哪個主體或資源。所以，能夠更靈活的支持主體和資源的擴展，比如假設(shè)以后客戶還想要給用戶分組，按照分組來給用戶授權(quán)，那么只需要實現(xiàn)一個新的主體類型即可，核心的授權(quán)和認證的代碼無需變化。b)權(quán)限控制的粒度更細，因為我們用一個int來表示操作的允許狀態(tài)，這就意味著，我們能支持在某個資源上的至多32種操作，在設(shè)計上無需做變化。一個資源上的操作一般不會超過32種操作，一般來說也就是添加、更新、刪除、查詢，以及在這個基礎(chǔ)上更加細分的一些操作而已，很少會超過32種操作。即使是極端情況，超過了32種操作，那么我們的核心設(shè)計也無需變動，無非就是把int換成一個long類型即可（支持64種操作）。c)我們還能支持細粒度的操作權(quán)限繼承關(guān)系：i.比如針對“公司管理”這種資源，假設(shè)它有六種操作：添加公司信息、刪除公司信息、更新公司信息、查詢公司信息、添加子公司、刪除子公司；我們可以把這些權(quán)限授予比如“張三”這個用戶。在授權(quán)的時候，我們可以細化到這種程度：1.明確規(guī)定：允許張三查詢公司信息、更新公司信息2.明確規(guī)定：不允許張三添加公司信息、刪除公司信息3.至于張三是否能執(zhí)行添加子公司和刪除子公司這些操作，我們可以不做明確規(guī)定，而是由其所擁有的角色，或其所屬的部門、崗位的權(quán)限來決定，這稱為“權(quán)限的繼承關(guān)系”，針對這種需求，在ACL中，我們設(shè)計了一個額外的屬性：aclTriState，用來表示某種操作的權(quán)限是否是繼承下來的。5、我們這個設(shè)計的缺點在哪里a)角色之間沒有考慮