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

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

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

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


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

現(xiàn)在的配置：

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