在工作流管理系統中，通常是先給業務流程建模，利用流程設計器，將業務的辦理過程用流程支持的節點方式表示出來。
業務建模之后，再確定每個節點上辦理的業務，辦理業務的過程，通常是以填寫完業務表單的方式來完成的。所以需要分析每個節點上填寫的表單內容，根據 表單內容建立業務表，表字段等。再將字段綁定到表單中錄入控件上，將表單錄入的數據保存到數據庫中，這樣業務表單模塊就完成了。
業務表單完成之后，再掛接到流程節點上。
另外可能需要再次完善一下流程節點的一些屬性，如增加每個節點的指定辦理人。
設置取業務表中的一些關鍵值用于流程中，如取報銷單中的報銷金額，請假單的請假天數，用于流程上下文中做條件使用。
最后，在業務表中，需要增加一個流程實例id字段，用于和業務流程關聯。在啟動業務流程的時候，需要將獲得的流程實例id寫入這個字段中，使得業務記錄能和流程實例關聯上。
通過上面這些步驟，就建立好了業務流程了，可以啟動流程實例，辦理業務了。業務的流轉就按照流程建模中定義好的順序辦理，不需要再在業務表 中增加狀態字段來控制業務的流轉了。業務的辦理過程變得有跡可循了，每個流程實例均可以列出運行的軌跡圖，或者列表出運行的軌跡。每個節點上辦理的業務也 能通過查詢業務表單再次展現。
上面我們說過，業務表是存儲辦理業務數據的數據庫表，一般來說，一個業務表只用于一種業務流程中，存儲同一類型的業務數據。當流程運行結束的時候， 這些業務數據就被封存，不能在流程的節點中再次被編輯和修改。(除非直接開庫修改數據，或者另外做一些模塊，直接修改業務數據)
但是，這些封存的業務數據，有可能會被再次啟用投入到另外一個業務流程中去使用，這種需求可能是需求肯定是有應用場景的，不管是分段的處理過程還是后期又做的一些業務補充等，都有可能發生。
如果一個業務表，需要再次用于另外一個業務流程當中，則我們只需要給業務表，再增加一個流程實例id字段，就可以了，再次新啟動的業務流程獲得的流 程實例id就寫入這個新的流程實例id字段。和以前的那個流程實例id不相關了。只是如果是編輯同一條業務記錄的話，就可能把上次的數據給修改了。這樣理 論上是可以支持n個業務流程。
總結一下，一個業務表用于一個業務流程中，用一個流程實例id字段和流程關聯，用于另外一個業務流程中，則再建一個流程實例id字段和流程實例關聯。
一個業務流程可能會涉及到多張業務表，一張業務表也可能涉及到多個業務流程。
現在各種MVC框架很多，各框架的優缺點網絡上也有很多的參考文章，但介紹各框架性能方面差別的文章卻不多，本人在項目開發中，感覺到采用了struts2框架的項目訪問速度，明顯不如原來采用了struts1框架的項目快，帶著這些疑惑，我對各類MVC框架的做了一個簡單的性能分析比較，其結果應該說是基本符合預期的，可供大家參考。
測試環境：
CPU：酷睿2 T5750，
內存：DDR2-667 2G，
Web容器：Tomcat6.0，最大線程數設置為1000，
操作系統：WinXP-sp3
測試步驟：
搭建6個Web工程，如下：
1.純JSP:不包含任何MVC框架，只有一個測試用的JSP頁面。
2.struts1：包含一個Action，不做任何邏輯處理，直接轉發到一個JSP頁面
3.struts2 JSP：不包含Action，只包含測試JSP頁面，直接訪問該頁面。
4.struts2 單例Action：采用Spring來管理Struts2的Action實例，并配置成單例模式。
5.struts2 多例Action：采用Spring來管理Struts2的Action實例，并配置成單例模式。
6.SpringMVC3：采用Spring來管理Controller實例，包含一個Controller，不做邏輯處理，收到請求后，直接返回到一個JSP頁面。
測試結果：
|
測試工程
|
請求數
|
并發數
|
總時間(s)
|
總時間(s)
|
總時間(s)
|
平均值(s)
|
Requests Per Second(每秒處理請求數)
|
|
JSP
|
2000
|
200
|
5.55
|
3.59
|
4.11
|
4.42
|
452.83
|
|
struts1
|
2000
|
200
|
6.77
|
3.83
|
7.00
|
5.86
|
341.03
|
|
struts2 JSP
|
2000
|
200
|
25.20
|
26.30
|
24.11
|
25.20
|
79.35
|
|
struts2 單例Action
|
2000
|
200
|
28.36
|
27.59
|
27.69
|
27.88
|
71.74
|
|
struts2 多例Action
|
2000
|
200
|
31.31
|
31.97
|
39.56
|
34.28
|
58.34
|
|
SpringMVC3
|
2000
|
200
|
7.16
|
7.50
|
4.27
|
6.31
|
317.09
|
說明：
以上測試雖不是非常的精確，但基本能說明一定的問題。每個JSP頁面和Action都不包含任何的業務邏輯代碼，只是請求轉發。每輪測試取三次總時間的平均值。所有工程的測試均全部完成并正常處理請求，沒有請求拒絕情況發生。
結論：
-
純JSP的性能應該最高，這不難理解，JSP被編譯成Servlet后，沒有任何多余的功能，收到請求后直接處理。（這也驗證一句經典的話：越原始效率就越高。）
-
struts1的性能是僅次于純JSP的，由于struts1采用單例Action模式，且本身的封裝相比struts2應該說簡單很多，雖然開發效率不如struts2，但已經過多年的實踐考驗，性能穩定高效。
-
相比來說struts2的性能就比較差了，這不難理解，struts2之所以開發方便，是由于采用值棧、OGNL表達式、攔截器等技術對請求參數的映射和返回結果進行了處理，另外還采用大量的標簽庫等，這些都無疑增加了處理的時間。因此降低了效率。在我們實際的項目中，我測試本地工程訪問每秒處理請求數只能達到35左右，應該說還有不少可優化的空間。
-
很多人認為struts2性能差是因為它的多例Action模式導致的，但我們采用spring管理struts2的Action，并設置按單例方式生成Action實例后，發現其性能有所提高，但并不是很明顯。由此可見，多例Action模式并不是struts2性能瓶頸所在。另外，我們在struts2中采用JSP方式訪問，發現其性能依舊和沒有采用任何MVC框架的純JSP之間存在好幾倍的差距，這又從另一個側面證實了我們剛才得出結論，struts2性能的瓶頸不在于它的多例Action模式。
-
SpringMVC3的性能略遜于struts1，但基本是同級別的，這讓人眼前一亮，springMVC有著不比struts2差的開發效率和解耦度，但性能卻是struts2的好幾倍，這讓我們灰常振奮，SpringMVC無疑又是項目開發的一個好的選擇。
Hadoop最近很火，到處都能看到，查了一下資料大概先了解一下其運行原理。
google在05年公開了Map/Reduce論文，MapReduce在處理巨量數據方面有明顯優勢。
google公司一個技術大牛jefffery Dean提出的這個算法，隨后很多小牛紛紛實現了Mapreduce,Hadoop是它的java實現，MapReduce概念直接推動了云計算概念的火爆。
沒有優秀算法云是沒法搞的。
這篇文章對Map/Reduce原理講的很清楚。
http://www.chinacloud.cn/download/Tech/MapReduceOverview.pdf
這個是Apache關系Hadoop的文檔，安裝、開發示例都有。
http://hadoop.apache.org/common/docs/r0.19.2/cn/mapred_tutorial.html
官方WIKI
http://wiki.apache.org/hadoop/Running_Hadoop_On_OS_X_10.5_64-bit_%28Single-Node_Cluster%29
最近看Jboss in action，里面提到Jboss的hot deploy功能，今天動手試了一下了一下，發現確實很好用。
首先使用eclipse的Automaticlly publish when resources change 功能 ，設置一個較短的時間，比如一秒，那么在編輯保存之后，eclipse會自動發布更新到jboss部署目錄。
在jboss中，可以使用Jmx Console，deploy，undeploy和redeploy。
例如：C:\Jboss\bin\twiddle invoke "jboss.system:service=MainDeployer" redeploy file://C:\Jboss\server\default\deploy\jbosstest.ear 。即完成對jbosstest.ear的重新部署。
在eclipse中可以把jmx命令行客戶端twiddle配置為外部工具。
這樣，每次修改后，點擊
即可重新部署應用程序。
所謂的熱部署（熱發布）（下面稱為“熱部署”），就是說，在web工程發布之后，不可避免的，會遇到修改BUG的問題。現在的熱部署就是為了解決這個問題，其功能就是說：在不停止web服務的同時，對jsp和java類進行修改，修改后的效果同時還能夠在頁面上顯示出來。節省了調試時間，提高了效率。不過，修改配置文件是個例外，如果對配置文件做修改，一定要重啟web服務。
常用的web服務器一般為tomcat和jboss，現一一做介紹。
1.tomcat熱部署
在tomcat中支持熱部署有兩種方式（在原理上來說，這兩種方式是一致的，只是放的位置不同）
a)在catalina_base\conf\catalina\localhost\中依照manager.xml定義一個xml文件，比如我的項目稱作sodoperation，我們就可以寫一個sodoperation.xml，內容如下：
<context path="/sodoperation" docBase="d:\myportal\sodoperation\src\webapp"/>
其中，path指的是你在tomcat中的項目名稱，就像manager一樣，docBase是指你的項目所在的web目錄。一直到歡迎頁面為止（也就是web-inf的前一個目錄）。但是一般來說，這個目錄中最好不要有中文，如果有的話，可以在文件開始加入
<?xml version='1.0" encoding='utf-8' ?>來試一下，即整個文件變為：
<?xml version='1.0" encoding='utf-8' ?>
<context path="/sodoperation" docBase="d:\myportal\sodoperation\src\webapp"/>
這樣就可以了，如果用這種廣告，同時使用myeclipse的部署的話，輕易不要remove，這樣會使文件都會被刪掉，不能持久。所以，建議使用第二種方法。
b)第二種方法和第一種方法在原理上是一致的，其區別就是位置的不同，這次在catalina_base\conf下的server.xml，在文件末加入：
<context path="/sodoperation" docBase="d:\myportal\sodoperation\src\webapp"/>
解釋和上面一樣，這種方法在啟動tomcat后，會在catalina_base\conf\catalina\localhost\中加入一個與第一種方法的文件。這樣保證，只要對server.xml不做修改，你可以隨便對新生成的文件刪除，對熱部署沒有任何問題
2.jboss熱部署
在jboss中做熱部署也有兩種方法，因為jobss集成了tomcat，也可以說這兩種方法是在jobss上的一個修改。
a)修改
/opt/jboss4.3/jboss-as/server/node1/deploy/jboss-web.deployer/context.xml
<Context cookies="true" crossContext="true" antiResourceLocking="true" antiJARLocking="true">
<Manager pathname=""/>
<InstanceListener>org.jboss.web.tomcat.security.RunAsListener</InstanceListener>
</Context>
加上
antiResourceLocking="true" antiJARLocking="true",重啟jboss,再用myeclipse Redeploy project的時候就不需要重啟,部署完了直接開瀏覽器預覽啦