在application server下，比如常見的weblogic，glassfish，jboss等，由于javaee規范的要求，一般不容許直接啟動線程。因此在常見的異步/并行任務執行上，會遭遇到比普通javase程序更多的麻煩。
典型例子，在javase中，jdk1.5后就引入了java.util.concurrent包，提供Executor這個非常好用的框架，完美的滿足一下典型需求：
1. 同步變異步
請求進來后，將請求封裝為task，交給Executor執行，原線程可以立即返回
2. 并行執行
請求進來后，將請求拆分為若干個task，例如下發短信，有100個收件人就可以按照每個收件人一個task來執行，這樣可以通過Executor來并行執行這些請求，遠比循環執行要快的多。
3. 等待任務結束
有時有要求調用線程必須等待所有任務完成后再繼續運行的需要，此外還有超時等細節設置要求。
而在application server，為了避開自己啟動線程的弊端，只好通過其他的方式來完成類似的功能。
目前我們的項目開發中主要有三種實現方式：
1. jms queue
通過jms來實現異步和并發，然后自己通過編碼方式完成調用線程等待所有任務執行成功。
這個方案比較通用，因為jms是javaee的標準，所有的application server上都支持。因此天然具有跨application server的能力。
缺點就比較多了，首先jms是需要實現串行化的，因此對task是有要求，不能串行化的類是不能傳遞的。另外串行化的性能損失比較大，造成性能和穩定性問題，這個在大壓力下比較突出，基本我們目前在考慮放棄這個方案，而且逐步將原有的實現替換掉。
這個方案還有另外一個缺點，配置麻煩，維護困難：需要創建jsm queque, connection factory, MDB等，如果系統中使用的多了，配置起來很羅嗦，修改時容許出錯。
2. commonj work manager
這個是weblogic和WebSphere上支持的一個很實用的解決方案，個人感覺使用上非常舒服，配置簡單，只要在weblogic-ejb-jar.xml中間中簡單配置：
<work-manager>
<name>wm/taskDistributionWorkManager</name>
<min-threads-constraint>
<name>minthreads</name>
<count>1</count>
</min-threads-constraint>
<max-threads-constraint>
<name>maxthreads</name>
<count>100</count>
</max-threads-constraint>
</work-manager>
使用時用jdni lookup到就可以使用了。功能和使用方式和executor框架很類似，同樣提供future，而且提供一個非常實用的waitAll()方法論支持等待任務完成。
這個方案的性能非常好，和jms相比提升極大，運行也穩定。缺點就是不是標準，只有weblogic和WebSphere執行，在glassfish，jboss上無法使用。
3. JCA work manager
這個是JCA標準了，glassfish，jboss都支持的，和commonj work manager很像，但是，很遺憾的是沒有future的支持，而且也沒有類似的waitAll()方法，只能自己編碼實現。
spring為glassfish提供了一個工具類"org.springframework.jca.work.WorkManagerTaskExecutor"，簡化了JCA work manager的使用。
JCA work manager的性能和穩定性都還不錯，對比jms要好的多。
從目前我們項目的使用經驗上看，jms是準備要被淘汰的了(其實我是一直對jms不感冒的，尤其是在有性能要求的地方，想不出用jms的理由)。目前項目要求同時支持weblogic和glassfish，因此commonj work manager和JCA work manager剛好對應于weblogic和glassfish平臺。實際使用中，是在這兩個work manager上封裝了一個通用的接口，然后再有commonj work manager和JCA work manager兩個實現，在運行時通過判斷平臺來自動選擇注入其中的一個。