摘要
　　 spring是支持控制反轉(zhuǎn)編程機(jī)制的一個(gè)相對新的框架。本文把spring作為簡單工作流引擎，將它用在了更加通用的地方。在對工作流簡單介紹之后，將要介紹在基本工作流場景中基于Spring的工作流API的使用。

　　 許多J2EE應(yīng)用程序要求在一個(gè)和主機(jī)分離的上下文中執(zhí)行處理過程。在許多情況下，這些后臺的進(jìn)程執(zhí)行多個(gè)任務(wù)，一些任務(wù)依賴于以前任務(wù)的狀態(tài)。由于這些處理任務(wù)之間存在相互依賴的關(guān)系，使用一套基于過程的方法調(diào)用常常不能滿足要求。開發(fā)人員能夠利用Spring來容易地將后臺進(jìn)程分離成活動(dòng)的集合。Spring容器連接這些活動(dòng)，并將它們組織成簡單的工作流。

　　 在本文中，簡單工作流被定義成不需要用戶干預(yù)，以一定順序執(zhí)行的任意活動(dòng)的集合。然而，我們并不建議將這種方式代替存在的工作流框架。在一些場景中，需要更多的用戶交互，例如基于用戶輸入而進(jìn)行的轉(zhuǎn)向，連接或傳輸，這時(shí)，比較好的方法是配用一個(gè)單獨(dú)的開源或者商業(yè)的工作流引擎。一個(gè)開源項(xiàng)目已經(jīng)成功地將更復(fù)雜的工作流設(shè)計(jì)集成到spring中。

　　 如果你手上的工作流任務(wù)是簡單的，那么，與功能完備的獨(dú)立工作流框架相比，簡單工作流的策略就會(huì)變得有意義，特別地，如果已經(jīng)使用了spring，這種快速實(shí)現(xiàn)可以保證時(shí)間不會(huì)變得更加漫長。此外，考慮到spring輕量級的控制反轉(zhuǎn)容器的特點(diǎn)，spring在資源負(fù)載上減少了資源負(fù)載。

　　 這篇文章簡短地從編程主題的角度介紹工作流。通過使用工作流的概念，spring被用來作為驅(qū)動(dòng)工作流引擎的框架。然后，討論了生產(chǎn)部署選項(xiàng)。現(xiàn)在，讓我們從工作流的設(shè)計(jì)模式和相關(guān)背景信息來介紹簡單工作流的思想吧。

簡單工作流
　　 工作流模型是一個(gè)早在70年代就有人開始研究的主題，許多開發(fā)者都試圖創(chuàng)建工作流模型規(guī)范。W.H.M. van der Aalst等人寫了《工作流模型》白皮書(2003年7月)，它成功地提煉出一組設(shè)計(jì)模式，這些設(shè)計(jì)模式準(zhǔn)確地將大多數(shù)通用的工作流場景建模。當(dāng)中，最普通的工作流模式是順序模式 (Sequence pattern)。順序工作流模式滿足了簡單工作流的設(shè)計(jì)原則，并且由一組順序執(zhí)行的活動(dòng)組成。

　　 UML（統(tǒng)一建模語言）活動(dòng)圖通常被用來作為一個(gè)機(jī)制對工作流建模。圖1顯示了一個(gè)基本的使用標(biāo)準(zhǔn)UML活動(dòng)圖對順序工作流過程的建模過程。

圖 1順序工作流模式

　　順序工作流是一個(gè)在J2EE中流行的標(biāo)準(zhǔn)工作流模式。J2EE應(yīng)用程序在后臺線程中，通常需要一些順序發(fā)生的事件或者異步事件。圖2中的活動(dòng)圖描述了一個(gè)簡單的工作流，用來通知感興趣的旅行者，他們感興趣的目的地的機(jī)票價(jià)格已經(jīng)下降的事件。

圖 2.機(jī)票價(jià)格下降的簡單工作流

　　圖1中的航線工作流負(fù)責(zé)創(chuàng)建和發(fā)送動(dòng)態(tài)的email通知。過程中的每一步表示了一個(gè)活動(dòng)(activity)。在工作流處于活動(dòng)之前，一些額外事件必須發(fā)生。在這個(gè)例子中，事件是飛行路線費(fèi)率的減少。

　　 讓我們來簡要的看一下航線工作流的業(yè)務(wù)邏輯。如果第一個(gè)活動(dòng)找不到對費(fèi)率減少通知感興趣的用戶，那么整個(gè)工作流就被取消。如果發(fā)現(xiàn)了感興趣的用戶，那么接下來的活動(dòng)繼續(xù)執(zhí)行。隨后，一個(gè)XSL（擴(kuò)展樣式表）轉(zhuǎn)換生成消息內(nèi)容，之后，記錄審計(jì)信息 (audit information)。最后，工作流試圖通過SMTP服務(wù)器發(fā)送這個(gè)消息。如果這個(gè)任務(wù)沒有錯(cuò)誤地完成，便在日志中記錄成功的信息，進(jìn)程結(jié)束。但是，如果在和SMTP服務(wù)器通訊時(shí)發(fā)生了錯(cuò)誤，一個(gè)特別的錯(cuò)誤處理例程將要管理這些錯(cuò)誤。錯(cuò)誤處理代碼將會(huì)試著去重新發(fā)送消息。

　　 考慮這個(gè)航線的例子，一個(gè)明顯的問題是：你怎么樣有效地將順序處理過程分解為單獨(dú)的活動(dòng)？這個(gè)問題被spring巧妙的處理了。下面，讓我們快速地討論spring的反轉(zhuǎn)控制框架。
控制反轉(zhuǎn)
　　 Spring通過使用spring容器來負(fù)責(zé)控制對象之間的依賴關(guān)系，使得我們不再對對象之間的依賴負(fù)責(zé)。 這種依賴關(guān)系的實(shí)現(xiàn)就是大家所知道的控制反轉(zhuǎn)（IoC）或依賴注射。參見Martin Fowler's "Inversion of Control Containers and the Dependency Injection Pattern"(martinfowler.com, 2004年2月)得到關(guān)于控制反轉(zhuǎn)和依賴注射的更加深入的討論。通過管理對象之間的依賴關(guān)系，spring就不需要那些只是為了使類能夠相互協(xié)作，而將對象粘合的代碼。

作為spring beans的工作流組件
　　 在進(jìn)一步討論之前，現(xiàn)在是簡要介紹spring中主要概念的恰當(dāng)時(shí)候。接口ApplicationContext是從接口BeanFactory繼承的，它被用來作為在spring容器內(nèi)實(shí)際的控制實(shí)體和容器。

　　 ApplicationContext負(fù)責(zé)對一組作為spring beans的一組bean的初始化，配置和生命期管理。我們通過裝配在一個(gè)基于XML的配置文件中的spring beans來配置ApplicationContext。這個(gè)配置文件說明了spring beans互相協(xié)作的本質(zhì)特點(diǎn)。這樣，用spring的術(shù)語來說，與其他spring beans交互的spring beans就被叫著協(xié)作者（collaborators）。缺省情況下，spring beans是作為單例存在于ApplicationContext中的，但是，單例的屬性能夠被設(shè)置為false，從而有效地改變他們在spring中調(diào)用原型模式時(shí)的行為。

　　 回到我們的例子，在飛機(jī)票價(jià)下降的時(shí)候，一個(gè)SMTP發(fā)送例程的抽象就被裝配在工作流過程例子中的最后的活動(dòng)（例子代碼可以在 Resources中得到）。由于是第5個(gè)活動(dòng)，我們命名它為activity5。要發(fā)送消息，activity5就要求一個(gè)代理協(xié)作者和一個(gè)錯(cuò)位處理句柄。

<bean id="activity5" class="org.iocworkflow.test.sequence.ratedrop.SendMessage"> <property name="delegate"> <ref bean="smtpSenderDelegate"></ref> </property> <property name="errorHandler"> <ref bean="mailErrorHandler"/> </property> </bean>

裝配工作流
　　 在提供的API中（從Resources下載），spring控制了一些操作者以一種工作流的方式交互。關(guān)鍵接口如下：

　　 Activity: 封裝了工作流中一個(gè)單步業(yè)務(wù)邏輯

　　 ProcessContext:在工作流活動(dòng)之間傳遞具有ProcessContext類型的對象。實(shí)現(xiàn)了這個(gè)接口的對象負(fù)責(zé)維護(hù)對象在工作流轉(zhuǎn)換中從一個(gè)活動(dòng)轉(zhuǎn)換到另一個(gè)活動(dòng)的狀態(tài)。

　　 ErrorHandler: 提供錯(cuò)誤處理的回調(diào)方法。

　　 Processor: 描述一個(gè)作為主工作流線程的執(zhí)行者的bean。

　　 下面從例子源碼中摘錄的代碼是將航線例子裝配為簡單工作流過程的spring bean的配置。

<!-- Airline rate drop as a simple sequence workflow process -->
<bean id="rateDropProcessor" class="org.iocworkflow.SequenceProcessor" >
<property name="activities">
<list>
<ref bean="activity1"/><!--Build recipients-->
<ref bean="activity2"/><!--Construct DOM tree-->
<ref bean="activity3"/><!--Apply XSL Transform-->
<ref bean="activity4"/><!--Write Audit Data-->
<ref bean="activity5"/><!--Attempt to send message-->
</list>
</property>
<property name="defaultErrorHandler">
<ref bean="defaultErrorHandler"></ref>
</property>
<property name="processContextClass">
<value>org.iocworkflow.test.sequence.ratedrop.RateDropContext</value>
</property>
</bean>

public interface ProcessContext extends Serializable
{
public boolean stopProcess();
public void setSeedData(Object seedObject);
}

播種工作流
　　 既然我們知道怎樣使用spring來組裝一個(gè)簡單的工作流，就讓我們集中精力使用種子數(shù)據(jù)(seed data)示例工作流的過程。要明白怎樣開始工作流，看一看在實(shí)際接口Processor上表現(xiàn)的方法：

public interface Processor
{
public boolean supports(Activity activity);
public void doActivities();
public void doActivities(Object seedData);
public void setActivities(List activities);
public void setDefaultErrorHandler(ErrorHandler defaultErrorHandler);
}

public void doActivities(Object seedData)
{
//Retrieve injected by Spring
List activities = getActivities();
//Retrieve a new instance of the Workflow ProcessContext
ProcessContext context = createContext();
if (seedData != null)
context.setSeedData(seedData);
//Execute each activity in sequential order
for (Iterator it = activities.iterator(); it.hasNext();)
{
Activity activity = (Activity) it.next();
try {
context = activity.execute(context);
}
catch (Throwable th) {
//Determine if an error handler is available at the activity level
ErrorHandler errorHandler = activity.getErrorHandler();
if (errorHandler == null) {
getDefaultErrorHandler().handleError(context, th);
break;
}
else {
//Handle error using default handler
errorHandler.handleError(context, th);
}
}
//Ensure it's ok to continue the process
if (processShouldStop(context, activity))
break;
}
}

BaseProcessor processor = (BaseProcessor)context.getBean("rateDropProcessor");
processor.doActivities(createSeedData());

Processor選項(xiàng)
　　雖然包含在源代碼中的Processor具體的子類僅僅是SequenceProcessor，但是，許多Processor接口的實(shí)現(xiàn)也是可以想象得到的。可以開發(fā)其他工作流處理過程子類來控制不同的工作流類型，例如，另一種像并行切割模式那樣有著變化的執(zhí)行路徑的工作流。對于簡單工作流來說，因?yàn)榛顒?dòng)的順序是預(yù)先決定了的，所以SequenceProcessor是好的選擇。盡管沒有被包括進(jìn)來，對于使用基于spring的簡單工作流的實(shí)現(xiàn)來說，排他選擇模式是另一個(gè)好的選擇。當(dāng)使用排他選擇模式時(shí)，在每個(gè)活動(dòng)執(zhí)行之后，Processor具體類就會(huì)訊問ProcessorContext，接下來將要執(zhí)行哪一個(gè)活動(dòng)。

　　 注：有關(guān)并行切割，排他選擇和其他工作流模式的更多信息，請參看W.M.P. van der Aalst等人寫的《工作流模式》一書。

啟動(dòng)工作流
　　 考慮到工作流過程常常需要異步執(zhí)行的特點(diǎn)，使用分離的執(zhí)行線程來啟動(dòng)工作流就變得有意義了。對于工作流的異步啟動(dòng)而言，有好幾個(gè)選項(xiàng)；我們主要集中在其中的兩個(gè)：積極地檢測(actively polling)一個(gè)隊(duì)列來啟動(dòng)工作流，或者使用通過ESB（enterprise service bus, 企業(yè)服務(wù)總線）的事件驅(qū)動(dòng)方式來啟動(dòng)工作流，而Mule就是ESB的一個(gè)開源項(xiàng)目。

　　 圖3和圖4描繪了兩種啟動(dòng)策略。圖3中，積極檢測在工作流中第一個(gè)活動(dòng)經(jīng)常檢查資源的情形下發(fā)生，比如數(shù)據(jù)源或POP3郵件帳戶。如果圖3中的積極檢測發(fā)現(xiàn)有任務(wù)等待處理，那么啟動(dòng)就會(huì)開始。

圖 3. 通過積極檢測來啟動(dòng)工作流

　　另一方面，圖4表示了使用JMS（JAVA消息服務(wù)）的J2EE應(yīng)用程序把事件放到隊(duì)列上的情形。一個(gè)通過ESB配置的事件監(jiān)聽器收到圖4中的事件，并且開始工作流，這樣，啟動(dòng)工作流過程。

圖 4. 通過ESB事件來啟動(dòng)工作流

　　使用所提供樣例的代碼，讓我們更詳細(xì)的看看主動(dòng)選擇啟動(dòng)方式與事件驅(qū)動(dòng)的啟動(dòng)方式。

public class PollForWork implements Activity
{
public ProcessContext execute(ProcessContext context) throws Exception
{
//First check if work needs to be done
boolean workIsReady = lookIntoDatabaseForWork();
if (workIsReady)
{
//The Polling Action must also load any seed data
((MyContext) context).setSeedData(createSeedData());
}
else
{
//Nothing to do, terminate the workflow process for this iteration
((MyContext) context).setStopEntireProcess(true);
}
return context;
}
}