在application server下，比如常見的weblogic，glassfish，jboss等，由于javaee規(guī)范的要求，一般不容許直接啟動(dòng)線程。因此在常見的異步/并行任務(wù)執(zhí)行上，會(huì)遭遇到比普通javase程序更多的麻煩。
典型例子，在javase中，jdk1.5后就引入了java.util.concurrent包，提供Executor這個(gè)非常好用的框架，完美的滿足一下典型需求：
1. 同步變異步
請(qǐng)求進(jìn)來(lái)后，將請(qǐng)求封裝為task，交給Executor執(zhí)行，原線程可以立即返回
2. 并行執(zhí)行
請(qǐng)求進(jìn)來(lái)后，將請(qǐng)求拆分為若干個(gè)task，例如下發(fā)短信，有100個(gè)收件人就可以按照每個(gè)收件人一個(gè)task來(lái)執(zhí)行，這樣可以通過Executor來(lái)并行執(zhí)行這些請(qǐng)求，遠(yuǎn)比循環(huán)執(zhí)行要快的多。
3. 等待任務(wù)結(jié)束
有時(shí)有要求調(diào)用線程必須等待所有任務(wù)完成后再繼續(xù)運(yùn)行的需要，此外還有超時(shí)等細(xì)節(jié)設(shè)置要求。
而在application server，為了避開自己?jiǎn)?dòng)線程的弊端，只好通過其他的方式來(lái)完成類似的功能。
目前我們的項(xiàng)目開發(fā)中主要有三種實(shí)現(xiàn)方式：
1. jms queue
通過jms來(lái)實(shí)現(xiàn)異步和并發(fā)，然后自己通過編碼方式完成調(diào)用線程等待所有任務(wù)執(zhí)行成功。
這個(gè)方案比較通用，因?yàn)閖ms是javaee的標(biāo)準(zhǔn)，所有的application server上都支持。因此天然具有跨application server的能力。
缺點(diǎn)就比較多了，首先jms是需要實(shí)現(xiàn)串行化的，因此對(duì)task是有要求，不能串行化的類是不能傳遞的。另外串行化的性能損失比較大，造成性能和穩(wěn)定性問題，這個(gè)在大壓力下比較突出，基本我們目前在考慮放棄這個(gè)方案，而且逐步將原有的實(shí)現(xiàn)替換掉。
這個(gè)方案還有另外一個(gè)缺點(diǎn)，配置麻煩，維護(hù)困難：需要?jiǎng)?chuàng)建jsm queque, connection factory, MDB等，如果系統(tǒng)中使用的多了，配置起來(lái)很羅嗦，修改時(shí)容許出錯(cuò)。
2. commonj work manager
這個(gè)是weblogic和WebSphere上支持的一個(gè)很實(shí)用的解決方案，個(gè)人感覺使用上非常舒服，配置簡(jiǎn)單，只要在weblogic-ejb-jar.xml中間中簡(jiǎn)單配置：
< 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 > 使用時(shí)用jdni lookup到就可以使用了。功能和使用方式和executor框架很類似，同樣提供future，而且提供一個(gè)非常實(shí)用的waitAll()方法論支持等待任務(wù)完成。
這個(gè)方案的性能非常好，和jms相比提升極大，運(yùn)行也穩(wěn)定。缺點(diǎn)就是不是標(biāo)準(zhǔn)，只有weblogic和WebSphere執(zhí)行，在glassfish，jboss上無(wú)法使用。
3. JCA work manager
這個(gè)是JCA標(biāo)準(zhǔn)了，glassfish，jboss都支持的，和commonj work manager很像，但是，很遺憾的是沒有future的支持，而且也沒有類似的waitAll()方法，只能自己編碼實(shí)現(xiàn)。
spring為glassfish提供了一個(gè)工具類"org.springframework.jca.work.WorkManagerTaskExecutor"，簡(jiǎn)化了JCA work manager的使用。
JCA work manager的性能和穩(wěn)定性都還不錯(cuò)，對(duì)比jms要好的多。
JBOSS下的配置
jboss-web.xml
<?xml version="1.0" encoding="UTF-8"?>
<jboss-web>
<resource-ref id="ResourceRef_1163654014164">
<description>WorkManager</description>
<res-ref-name>jboss.jca:service=WorkManager</res-ref-name>
<res-type>org.jboss.resource.work.JBossWorkManager</res-type>
<res-auth>Container</res-auth>
<res-sharing-scope>Shareable</res-sharing-scope>
<jndi-name>WorkManager</jndi-name>
</resource-ref>
</jboss-web>
applicationContext.xml
<bean id="taskExecutor" class="org.springframework.jca.work.jboss.JBossWorkManagerTaskExecutor">
<property name="workManagerName" value="WorkManager"/>
<property name="resourceRef" value="true"/>
</bean>
從目前我們項(xiàng)目的使用經(jīng)驗(yàn)上看，jms是準(zhǔn)備要被淘汰的了(其實(shí)我是一直對(duì)jms不感冒的，尤其是在有性能要求的地方，想不出用jms的理由)。目前項(xiàng)目要求同時(shí)支持weblogic和glassfish，因此commonj work manager和JCA work manager剛好對(duì)應(yīng)于weblogic和glassfish平臺(tái)。實(shí)際使用中，是在這兩個(gè)work manager上封裝了一個(gè)通用的接口，然后再有commonj work manager和JCA work manager兩個(gè)實(shí)現(xiàn)，在運(yùn)行時(shí)通過判斷平臺(tái)來(lái)自動(dòng)選擇注入其中的一個(gè)。