這段時(shí)間突然多了好多客戶演示，與單純的OA不同，這次客戶的項(xiàng)目涉及比較廣泛，有稅務(wù)有銀行甚至還有erp，都是業(yè)務(wù)系統(tǒng)。與OA相比，更多的業(yè)務(wù)操作加入到了流程當(dāng)中。這是個(gè)很好的現(xiàn)象，workflow的市場(chǎng)在持續(xù)增長(zhǎng)。用戶本身以前從來沒有用過工作流，都是從去年才開始逐漸關(guān)注。有流程的地方就應(yīng)該有工作流，這是用戶的一個(gè)認(rèn)知過程。工作流的使用在大眾化，并不再局限于OA和一些特定的領(lǐng)域，由此帶來的必然是工作流的競(jìng)爭(zhēng)加劇和價(jià)格的白菜化。
    對(duì)工作流廠商來說，我覺得現(xiàn)在是一個(gè)很好的機(jī)會(huì)。就工作流系統(tǒng)本身，各個(gè)廠家產(chǎn)品的功能應(yīng)該相差并不多，關(guān)鍵還在于產(chǎn)品的成熟度，如果聽到用戶抱怨他們成了你的測(cè)試部時(shí)，那你基本上就完了。在大的功能相差不大的情況下，剩下的就是用戶體驗(yàn)，如何盡可能的讓用戶開發(fā)方便，良好的可擴(kuò)展的接口固然不錯(cuò)，提供幾個(gè)典型的實(shí)現(xiàn)就更好了。甚至在對(duì)方也采用webwork、struts的情況下可以提供已封裝好的action,或者頁面組件。最后不得不提的是價(jià)格，對(duì)一個(gè)成熟的產(chǎn)品來說，實(shí)際上它的成本是接近于0的，但實(shí)際情況切是往往需要很多的技術(shù)支持，越是不成熟的產(chǎn)品它的成本必然越高。就功能上來說，門戶搭配工作項(xiàng)列表比單純的工作項(xiàng)列表要好很多。
    在workflow價(jià)格低廉的情況下，BPM無疑是一個(gè)新的利潤(rùn)點(diǎn)。workflow在大多情況下是一種嵌入式，BPM則是獨(dú)立部署。在用戶實(shí)際業(yè)務(wù)集成的需求下，BPM更多的是一種高端的產(chǎn)品出現(xiàn)。目前國(guó)內(nèi)真正意義上的BPM還是處于空白的狀態(tài)，有的也只是在workflow中加入一些統(tǒng)計(jì)和報(bào)表的功能，一種概念上的炒作。所以說現(xiàn)在BPM正當(dāng)時(shí)，對(duì)工作流廠家來說，BPM應(yīng)該是努力的方向。
    但是BPM對(duì)于很多研發(fā)團(tuán)隊(duì)只有幾個(gè)人的廠家來說是否又過于遙遠(yuǎn)呢？
一個(gè)朋友留言，提了一些關(guān)心的問題，這里說說自己的想法（不一定對(duì)）。
問題：數(shù)據(jù)范圍的控制：“事實(shí)上不是每個(gè)用戶都可以看到所有記錄的。以財(cái)務(wù)管理為例，部門經(jīng)理只能查看金額小于1W的數(shù)據(jù)；而總經(jīng)理則沒有限制”。象這樣要根據(jù)數(shù)據(jù)的某個(gè)字段對(duì)數(shù)據(jù)范圍進(jìn)行控制，應(yīng)該實(shí)現(xiàn)呢，是通過AOP動(dòng)態(tài)改變執(zhí)行的SQL嗎？這樣似乎不太可行，如果要執(zhí)行的SQL特別復(fù)雜，那動(dòng)態(tài)改變SQL 就更難了。現(xiàn)在的應(yīng)用中一般使用hibernate，這樣的話就變成了動(dòng)態(tài)改變HQL，也是難的。
回答：目前在我的代碼里就是通過AOP動(dòng)態(tài)改變執(zhí)行的SQL，改變HQL確實(shí)很困難，但是改變criteria就比較簡(jiǎn)單了。對(duì)于特別復(fù)雜的sql，我的建議是把這些SQL直接寫到你的業(yè)務(wù)程序里去，或者單獨(dú)配置出來，和ibatis比較類似。

問題：單條數(shù)據(jù)ACL權(quán)限：由于數(shù)據(jù)是不斷增加的，所以要對(duì)單條數(shù)據(jù)的ACL權(quán)限，不應(yīng)該是數(shù)據(jù)已存在，然后再對(duì)存在的數(shù)據(jù)授權(quán)，應(yīng)該是對(duì)某種規(guī)則進(jìn)行授權(quán)。以你舉的個(gè)人通訊錄為例，各人自己維護(hù)自己的通訊記錄，數(shù)據(jù)只對(duì)自己可見，要想實(shí)現(xiàn)對(duì)自己的數(shù)據(jù)的可再授權(quán)，應(yīng)該是對(duì)符合某個(gè)規(guī)則的數(shù)據(jù)進(jìn)行授權(quán)，也就是說 “要執(zhí)行授權(quán)操作的人就是數(shù)據(jù)的擁有者”這是個(gè)規(guī)則，那是不是應(yīng)該對(duì)這個(gè)規(guī)則授權(quán)呢。
回答：我理解的和你不一樣。我的理解是這樣的，實(shí)際中我把單條數(shù)據(jù)的權(quán)限劃分為擁有、瀏覽、修改、刪除四種權(quán)限，用戶擁有哪種權(quán)限就可以對(duì)數(shù)據(jù)進(jìn)行相應(yīng)哪種操作。“要執(zhí)行授權(quán)操作的人就是數(shù)據(jù)的擁有者”也可以理解為“要執(zhí)行授權(quán)操作的人就必須有該數(shù)據(jù)的擁有權(quán)限”，這可以理解為一種規(guī)則，但我更愿意把它理解為一種習(xí)慣，很顯然對(duì)習(xí)慣授權(quán)是沒有意義的。當(dāng)然這里是存在規(guī)則的，這種規(guī)則簡(jiǎn)單的說是這樣：當(dāng)我新增一條數(shù)據(jù)時(shí)，哪些人對(duì)該條數(shù)據(jù)擁有擁有的權(quán)限，哪些人對(duì)該條數(shù)據(jù)擁有瀏覽的權(quán)限，哪些人對(duì)該條數(shù)據(jù)擁有修改的權(quán)限，哪些人對(duì)該條數(shù)據(jù)擁有刪除的權(quán)限。權(quán)限相關(guān)記錄會(huì)在新增這條數(shù)據(jù)時(shí)根據(jù)該規(guī)則生成。在上面的例子里，這一規(guī)則體現(xiàn)在：各人自己維護(hù)自己的通訊記錄，數(shù)據(jù)只對(duì)自己可見。也就是說在用戶新增自己的通訊記錄時(shí)，系統(tǒng)同時(shí)往權(quán)限表里插入了該用戶對(duì)該記錄的一個(gè)擁有權(quán)限記錄。

問題：數(shù)據(jù)字段權(quán)限：要實(shí)現(xiàn)對(duì)某個(gè)字段的權(quán)限控制，那是不是應(yīng)該所有字段應(yīng)該有個(gè)默認(rèn)的操作呢，或者默認(rèn)就是只可以查看，要進(jìn)行修改的話就必須授權(quán)。但是通常整個(gè)應(yīng)用中的字段非常多，這樣是乎不太合理。那是不是可以做成所有字段默認(rèn)就是可以CRUD的，只有要控制的字段才進(jìn)行權(quán)限判斷。同樣，由于使用 Hibernate來進(jìn)行持久化，那對(duì)字段的控制是不是就變成了對(duì)類中屬性的控制。
回答：數(shù)據(jù)字段權(quán)限一直是一個(gè)很難辦的事情，實(shí)際上我很傾向于把這個(gè)問題推到頁面來解決。其實(shí)所有的權(quán)限控制最后都是要通過頁面來表現(xiàn)的。其實(shí)對(duì)字段來說，所需要的權(quán)限也很簡(jiǎn)單：可見/不可見,只讀/可修改。這樣的話，通過標(biāo)簽的形式來控制字段的顯示、只讀就顯得很自然。對(duì)字段的權(quán)限記錄可以放入到數(shù)據(jù)庫，或者xml中，與具體的pojo類沒有關(guān)系，當(dāng)渲染頁面的時(shí)候，由標(biāo)簽來讀取相關(guān)權(quán)限記錄并控制顯示。

問題：角色權(quán)限的繼承：角色權(quán)限的繼承通過規(guī)則來做，這個(gè)規(guī)則應(yīng)該怎么設(shè)計(jì)呢。
回答：這個(gè)問題其實(shí)是一個(gè)分離關(guān)注點(diǎn)的問題。你可以抽象出一個(gè)規(guī)則接口，這個(gè)接口定義了對(duì)部門、角色下的用戶而言，哪些權(quán)限是可以從部門角色繼承的，繼承幾級(jí)，哪些是不可以的。然后再具體實(shí)現(xiàn)。更靈活的方式是定義出一個(gè)配置文件，運(yùn)行時(shí)可以靈活修改。


平臺(tái)現(xiàn)在無疑已經(jīng)是一個(gè)用濫的概念。先來看看業(yè)務(wù)平臺(tái)的定義：是為企業(yè)提供的一個(gè)可快速開發(fā)的、穩(wěn)定的、成熟的業(yè)務(wù)基礎(chǔ)開發(fā)平臺(tái)。實(shí)際上在一個(gè)技術(shù)人員的眼里，平臺(tái)=類springside的開發(fā)框架+一套組織機(jī)構(gòu)+和組織機(jī)構(gòu)相適應(yīng)的一套權(quán)限系統(tǒng)+門戶+信息資源庫+工作流引擎+一些通用的業(yè)務(wù)模塊。因?yàn)橐恢弊鲫P(guān)于所謂業(yè)務(wù)平臺(tái)的開發(fā)，有過困惑也有思考，這里說說自己對(duì)于平臺(tái)的一些想法，也希望大家多多拍磚。我認(rèn)為一個(gè)好的業(yè)務(wù)平臺(tái)應(yīng)該做到下面的幾點(diǎn)：
1、業(yè)務(wù)性。
   這個(gè)問題我曾經(jīng)和胡長(zhǎng)城有過很長(zhǎng)時(shí)間的爭(zhēng)論。最后我得承認(rèn)胡兄的正確性：業(yè)務(wù)確實(shí)是一個(gè)平臺(tái)的根本。一個(gè)業(yè)務(wù)平臺(tái)如果不滿足業(yè)務(wù)的需求，那么它存在的意義就值得懷疑。一個(gè)很簡(jiǎn)單的例子，協(xié)同辦公中不可缺少的發(fā)文管理，正文需要用到電子簽章，業(yè)務(wù)中有這個(gè)需求，平臺(tái)不支持，那么這個(gè)平臺(tái)就不是個(gè)好的業(yè)務(wù)平臺(tái)。
2、易用性
   業(yè)務(wù)平臺(tái)不是面對(duì)最終用戶的，它需要做二次開發(fā)。這樣平臺(tái)對(duì)程序員的友好性就相當(dāng)重要，畢竟平臺(tái)的使用者還是程序員。
   基礎(chǔ)代碼生成是必要的，不管你采用何種方式，是根據(jù)已有表格來生成模型和相應(yīng)代碼還是先畫出模型再來生成表格和相應(yīng)代碼（所謂的MDA）。平臺(tái)的代碼結(jié)構(gòu)最好能夠和IDE有個(gè)良好的結(jié)合，因?yàn)轫?xiàng)目的開發(fā)往往是幾個(gè)程序員協(xié)作的過程，平臺(tái)對(duì)代碼開發(fā)的支持不可能做到IDE的水平。最好的方式是生成的代碼自動(dòng)在IDE里有著清晰的結(jié)構(gòu)，在IDE里編輯、測(cè)試自己的代碼，然后自動(dòng)發(fā)布到平臺(tái)相應(yīng)目錄中，啟動(dòng)平臺(tái)，代碼運(yùn)行成功。eclipse插件是個(gè)很好的選擇。
   良好的API的支持，開發(fā)中不可避免的會(huì)與平臺(tái)已有的組織機(jī)構(gòu)模型和權(quán)限系統(tǒng)交互，這樣良好的、封裝清晰的API支持就很重要。
   頁面組件的支持。往往有時(shí)候凌亂的WEB頁面最讓人頭疼。對(duì)常用的一些頁面元素可以用標(biāo)簽或是AJAX做進(jìn)一步的封裝。比如樹組件、彈出層組件、分頁組件等等。與這些相比，一些業(yè)務(wù)頁面組件的封裝也很重要。比如需要在頁面選擇用戶，直接封裝出一個(gè)用戶選擇組件，而不用開發(fā)人員在頁面用彈出層+用戶樹自己再去組裝。再比如說發(fā)文中的簽批意見，可以用AJAX直接封裝到頁面里，不用用戶自己調(diào)用相應(yīng)API。意思就是讓用戶開發(fā)盡量簡(jiǎn)單，把工作從代碼里盡量推到頁面上去。
3、模塊化。
   盡管這個(gè)或類似概念（比如說組件、構(gòu)件）一再被平臺(tái)廠家們提及，我對(duì)實(shí)際的實(shí)現(xiàn)一直報(bào)懷疑的態(tài)度。實(shí)際的實(shí)現(xiàn)往往是對(duì)模塊的一個(gè)模擬。這里的模塊實(shí)際上是對(duì)代碼做出的一種人為上的區(qū)分，所謂的模塊配置，更直接一點(diǎn)就是頁面URL的配置。與代碼行為無關(guān)，與運(yùn)行期管理更沒關(guān)。
4、可擴(kuò)展性
   這個(gè)暫且不說，很大的一個(gè)話題。
5、前瞻性。
   一個(gè)優(yōu)秀的平臺(tái)憑什么和別人不同，一個(gè)很重要的一點(diǎn)就是平臺(tái)的前瞻性。一句話，就是要有別人沒有的東西。個(gè)人非常看好未來對(duì)業(yè)務(wù)整合的需求，遺留的業(yè)務(wù)系統(tǒng)+國(guó)外大廠商的概念轟炸讓客戶開口就是業(yè)務(wù)整合、BPM。是時(shí)候不再忽悠而是做點(diǎn)實(shí)際的東西了。
可以說，業(yè)務(wù)性+易用性在現(xiàn)階段就是一個(gè)很好的平臺(tái)了。如果再有些前瞻性的東西（注意：不是口頭上！）這個(gè)平臺(tái)應(yīng)該說很優(yōu)秀了。至于模塊化、可擴(kuò)展性，想想，現(xiàn)在只能說忽悠了。
隨著近兩年來各企業(yè)/單位的基礎(chǔ)系統(tǒng)的建設(shè)，應(yīng)用集成的需求已經(jīng)越來越急切。個(gè)人認(rèn)為現(xiàn)在的應(yīng)用集成可以分為以下三種情況：
  一、門戶+單點(diǎn)登錄。這種情況最簡(jiǎn)單，說白了就是簡(jiǎn)單的頁面集成。各個(gè)系統(tǒng)通過門戶統(tǒng)一登錄，登錄完畢后在門戶上顯示各自的業(yè)務(wù)頁面，當(dāng)需要具體處理各項(xiàng)業(yè)務(wù)時(shí)跳轉(zhuǎn)到各自的業(yè)務(wù)系統(tǒng)里。當(dāng)然這里也有問題，僅僅B/S系統(tǒng)能做這種集成。這種情況也是實(shí)際項(xiàng)目中碰到最多的情況。
  二、數(shù)據(jù)集成。這個(gè)和第一種情況相比就復(fù)雜了很多。拿一個(gè)簡(jiǎn)單的情況來說，系統(tǒng)A和系統(tǒng)B里都有各自的一套組織機(jī)構(gòu)，現(xiàn)在我想做集成，只保留一套組織機(jī)構(gòu)然后做統(tǒng)一管理。需求合情合理，處理起來就麻煩了。模型設(shè)計(jì)相似還好一點(diǎn)，再簡(jiǎn)單一點(diǎn)可以做數(shù)據(jù)庫的同步。但這往往是開發(fā)人員的一廂情愿。寫適配器幾乎是必須的。模型的不同帶來的問題是最大的，系統(tǒng)A里有崗位這個(gè)對(duì)象，系統(tǒng)B里沒有，怎么辦？這種情況在實(shí)際項(xiàng)目中越來越多了，然后每一次都讓人特別的難受。
  三、業(yè)務(wù)集成。提到業(yè)務(wù)集成，不得不說說SOA。SCA讓業(yè)務(wù)集成看起來那么的順理成章，SDO又搞定了數(shù)據(jù)交換這個(gè)頭痛的問題。一切都是那么的美好（有點(diǎn)不太真實(shí)，嚯嚯）。因?yàn)樽罱鼘?duì)BPM關(guān)注比較多也準(zhǔn)備往這方面做一些嘗試，所以這里拿BPM舉例，好比一個(gè)公司錄人的流程，一開始我會(huì)調(diào)用原有的HR系統(tǒng)的業(yè)務(wù)服務(wù)錄入人員信息，然后我又會(huì)在下一個(gè)流程節(jié)點(diǎn)調(diào)用財(cái)務(wù)系統(tǒng)相應(yīng)的業(yè)務(wù)服務(wù)來計(jì)算新員工工資。可以這樣認(rèn)為，BPM是業(yè)務(wù)集成的最好的例子。這種情況在實(shí)際中用戶也越來越多的提出來，或者說提到了這個(gè)概念（和各大公司的宣傳有很大的關(guān)系）。個(gè)人也認(rèn)為這一塊應(yīng)該有很大的發(fā)展空間。麻煩的地方也在于數(shù)據(jù)或者說服務(wù)的調(diào)用交互。
除了第一種情況，剩下兩種情況都是很麻煩的。很多人都在說業(yè)務(wù)集成，但是數(shù)據(jù)集成是在任何有不止一套遺留系統(tǒng)時(shí)必須面對(duì)的問題。甚至我可以這么認(rèn)為，數(shù)據(jù)集成是最困難的，因?yàn)樗€沒有一個(gè)標(biāo)準(zhǔn)，也不會(huì)有標(biāo)準(zhǔn)了。
最新的1.2*版本開始支持jndi數(shù)據(jù)源，版本與1.*完全兼容。注意的是以前的jackrabbit-core-1.x.jar現(xiàn)在
需要jackrabbit-core.jar，jackrabbit-api.jar, jackrabbit-jcr-commons.jar三個(gè)包來替代；另外，其要求Lucene 的版本要2.0，下了個(gè)2.1不行。
然后就是改配置文件。
原先的配置

現(xiàn)在的配置：

還有就是：不要僅僅修改你總的那個(gè)配置文件，每個(gè)工作區(qū)間下的配置文件都要同時(shí)修改，卻記卻記啊！