??????????????????????????????????????

使用Spring來創建一個簡單的工作流引擎?????????????????????

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

　　許多J2EE應用程序要求在一個和主機分離的上下文中執行處理過程。在許多情況下，這些后臺的進程執行多個任務，一些任務依賴于以前任務的狀態。由于這些處理任務之間存在相互依賴的關系，使用一套基于過程的方法調用常常不能滿足要求。開發人員能夠利用Spring來容易地將后臺進程分離成活動的集合。Spring容器連接這些活動，并將它們組織成簡單的工作流。

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

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

　　這篇文章簡短地從編程主題的角度介紹工作流。通過使用工作流的概念，spring被用來作為驅動工作流引擎的框架。然后，討論了生產部署選項。現在，讓我們從工作流的設計模式和相關背景信息來介紹簡單工作流的思想吧。

　　簡單工作流

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

　　UML（統一建模語言）活動圖通常被用來作為一個機制對工作流建模。圖1顯示了一個基本的使用標準UML活動圖對順序工作流過程的建模過程。

圖 1順序工作流模式

　　順序工作流是一個在J2EE中流行的標準工作流模式。J2EE應用程序在后臺線程中，通常需要一些順序發生的事件或者異步事件。圖2中的活動圖描述了一個簡單的工作流，用來通知感興趣的旅行者，他們感興趣的目的地的機票價格已經下降的事件。

圖 2.機票價格下降的簡單工作流

- 作者： macrochen 2005年12月11日, 星期日 22:28

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

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

　　考慮這個航線的例子，一個明顯的問題是：你怎么樣有效地將順序處理過程分解為單獨的活動？這個問題被spring巧妙的處理了。下面，讓我們快速地討論spring的反轉控制框架。

　　控制反轉

　　Spring通過使用spring容器來負責控制對象之間的依賴關系，使得我們不再對對象之間的依賴負責。 這種依賴關系的實現就是大家所知道的控制反轉（IoC）或依賴注射。參見Martin Fowler's "Inversion of Control Containers and the Dependency Injection Pattern"(martinfowler.com, 2004年2月)得到關于控制反轉和依賴注射的更加深入的討論。通過管理對象之間的依賴關系，spring就不需要那些只是為了使類能夠相互協作，而將對象粘合的代碼。

　　作為spring beans的工作流組件

　　在進一步討論之前，現在是簡要介紹spring中主要概念的恰當時候。接口ApplicationContext是從接口BeanFactory繼承的，它被用來作為在spring容器內實際的控制實體和容器。

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

　　回到我們的例子，在飛機票價下降的時候，一個SMTP發送例程的抽象就被裝配在工作流過程例子中的最后的活動（例子代碼可以在 Resources中得到）。由于是第5個活動，我們命名它為activity5。要發送消息，activity5就要求一個代理協作者和一個錯位處理句柄。

????? class="org.iocworkflow.test.sequence.ratedrop.SendMessage">
?????
???????? BR>?????
?????
????????
?????
?? /FONT>

　　將工作流組件實施成spring beans產生了兩個令人喜悅的結果，就是容易進行單元測試和很大程度上可重用能力。IoC容器的特點明顯地提供了有效的單元測試。使用像spring這樣的Ioc容器，在測試期間，協作者之間的依賴能夠容易的用假的替代者替代。在這個航線的例子中，能夠容易地從唯一的測試ApplicationContext中檢索出像activity5活動這樣的spring bean。用一個假的SMTP代理SMTP服務器，就有可能單獨地測試activity5。

　　第二個意外的結果，可重用能力是通過像XSL轉換這樣的工作流活動實現的。一個被抽象成工作流活動的XSL轉換現在能夠被任何處理XSL轉換的工作流所重用。

　　裝配工作流

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

Activity: 封裝了工作流中一個單步業務邏輯
ProcessContext:在工作流活動之間傳遞具有ProcessContext類型的對象。實現了這個接口的對象負責維護對象在工作流轉換中從一個活動轉換到另一個活動的狀態。
ErrorHandler: 提供錯誤處理的回調方法。
Processor: 描述一個作為主工作流線程的執行者的bean。

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

??
?????
????????
???????????
???????????
???????????
???????????
???????????
???????? BR>?????
?????
???????? BR>????? /property>
?????
???????? org.iocworkflow.test.sequence.ratedrop.RateDropContextBR>?????
?? /property>

　　SequenceProcessor類是一個對順序模式建模的具體子類。有5個活動被連接到工作流處理器，工作流處理器將順序執行這5個活動。

　　與大多數過程式后臺進程相比，工作流的解決方案真正的突出了高度強壯的錯誤處理。錯誤處理句柄可以單獨地處理每個活動。這種類型的句柄在單一活動級別提供了細致的錯誤處理。如果沒有單獨處理單個活動的錯誤處理句柄，那么全局工作流處理器的錯誤處理句柄將會處理出現的問題。例如，如果在工作流處理過程中的任意時刻，一個沒有被處理的錯誤出現了，那么它將會向外傳播，被使用defaultErrorHandler屬性裝配的ErrorHandler Bean處理。

　　更復雜的工作流框架將工作流轉換之間的狀態持久化存儲到數據庫中。在這篇文章中，我們僅僅對狀態轉換是自動完成的工作流感興趣。狀態信息僅僅在實際工作流運行時在ProcessContext中得到。在ProcessContext中，你僅僅能看到ProcessContext的接口的兩個方法：

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

　　用于航線例子工作流的具體的ProcessContext類是RateDropContext類。RateDropContext類封裝了用于執行航線費率降低工作流必須的數據。

　　到現在為止，經由缺省的ApplicationContext的作用，所有bean實例都已經成了單例。但是，對于每一個航線工作流的調用，我們必須創建一個新的RateDropContext類的實例。為了處理這種需求，需要配置SequenceProcessor，采用全限定類名作為processContextClass屬性的值。對于每個工作流的執行，SequenceProcessor使用指定的類名從spring檢索ProcessorContext類的一個新的實例。為了使這種機制能夠起作用，非單件的spring bean或者類型org.iocworkflow.test.sequence.simple.SimpleContext的原型必須存在于ApplicationContext中（完整的列表，參見rateDrop.xml）。

　　播種工作流

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

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);
?? }

　　大多數情況下，工作流需要一些初始化激活才能開始。開始一個處理過程有兩個選項：doActivities（ObjectseedData）方法或者無參數的doActivities（）。下面的代碼列表是包含在樣例代碼中為SequenceProcessor而實現的doActivities（）：

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;
????? }
?? }

　　在這個航空費用減少的例子中，工作流過程的種子數據包括航線信息和費率減少的信息。使用容易測試的航線工作流例子，通過doActivities（Object seedData）方法發出種子數據并激活一個單一的工作流過程是簡單的：

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

　　這些代碼是從包含在這篇文章中的測試例子中摘錄的。rateDropProcessor Bean是從ApplicationContext中檢索來的。rateDropProcessor實際上是裝配成SequenceProcessor的實例來處理順序執行。createSeedData（）方法實例化一個對象，這個對象封裝了初始化航線工作流所需要的所有種子數據。

　　Processor選項

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

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

　　啟動工作流

　　考慮到工作流過程常常需要異步執行的特點，使用分離的執行線程來啟動工作流就變得有意義了。對于工作流的異步啟動而言，有好幾個選項；我們主要集中在其中的兩個：積極地檢測(actively polling)一個隊列來啟動工作流，或者使用通過ESB（enterprise service bus, 企業服務總線）的事件驅動方式來啟動工作流，而Mule就是ESB的一個開源項目（關于Mule的更多信息，請參加"Event-Driven Services in SOA"（JavaWorld, 2005年1月）。

　　圖3和圖4描繪了兩種啟動策略。圖3中，積極檢測在工作流中第一個活動經常檢查資源的情形下發生，比如數據源或POP3郵件帳戶。如果圖3中的積極檢測發現有任務等待處理，那么啟動就會開始。

圖 3. 通過積極檢測來啟動工作流

　　另一方面，圖4表示了使用JMS（JAVA消息服務）的J2EE應用程序把事件放到隊列上的情形。一個通過ESB配置的事件監聽器收到圖4中的事件，并且開始工作流，這樣，啟動工作流過程。

圖 4. 通過ESB事件來啟動工作流

http://searchwebservices.techtarget.com.cn/tips/110/2127110.shtml

　　使用所提供樣例的代碼，讓我們更詳細的看看主動選擇啟動方式與事件驅動的啟動方式。

　　積極檢測

　　積極檢測是一種花費較少的啟動工作流過程的方案。SequenceProcessor足夠靈活，以使得能夠通過平滑的選擇工作來進行啟動過程。盡管并不令人滿意，在沒有時間進行事件驅動子系統的配置和部署的許多情景中，積極檢測是明智的選擇。

　　使用Spring的ScheduledTimerTask，檢測模式就能夠容易地裝配。缺點就是必須創建額外的活動來進行檢測。這個檢測活動必須被設計來訊問某些實體，如數據庫表，pop郵件帳戶，或者Web服務，然后決定新的工作是否等待參與到工作流中。

　　在所提供的例子中，PollingTestCase類實例化一個基于檢測的工作流過程。使用一個有著積極檢測處理過程與事件驅動的啟動過程的不同之處在于，spring支持doActivities（）方法的無參數版本。相反地，在事件驅動的啟動中，啟動處理過程的實體通過doActivities（Object seedData）方法提供了種子數據來啟動工作流。檢測方法的另一個缺點是：資源不一定能夠被重復地使用。依賴于應用程序環境，這種資源的消耗是不可接受的。

　　下面代碼例子演示了使用積極檢測來控制工作流啟動的一個活動：

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;
?? }
}

　　此外，包含在例子代碼的單元測試中的PollRates類提供了一個主動選舉啟動的可以運行的例子。PollRates模擬了對于航線費率下降的重復檢查。

　　通過ESB的事件驅動啟動工作流

　　理想地，一個包含了適當的種子數據的線程能夠異步地啟動工作流。這種情況的一個例子是收到從JAVA消息服務隊列的消息。一個監聽JMS隊列或者主題的客戶會收到通知，這個通知告知處理應該在onMessage（）方法中開始工作流。然后，通過使用Spring和doActivities（Object seedData）方法就能夠獲得工作流處理器Bean。

　　使用ESB，實際用于發送啟動事件的機制能夠恰當地從工作流處理器中分離出來。開源項目Mule ESB有緊湊地和Spring相集成的好處。任意傳送機制，比如JMS，JVM，或者POP3郵箱都能夠發起事件的傳播。

　　工作流的連續運行

　　工作流引擎后臺進程應該能夠沒有干擾地連續運行。對于正在運行的基于spring的工作流單一進程來說好，有幾個選項。一個有著main（）方法的簡單Java類就足夠演示與這篇文章伴隨著的單元測試中的例子了。一個更加可靠的用于部署的機制是嵌入工作流到某種形式的J2EE組件中。Spring很好地支持和J2EE兼容的web應用程序歸檔或者war文件的集成。基于Java管理附件（JMX）服務歸檔和JBoss應用服務器（更多信息，參見JBoss homepage）支持的sar文件是更加合適的可部署組件，這種更合適的可部署組件也能夠被用來將部署歸檔。在JBoss 4.0中，sar文件已經被大家所知道的deployer的格式所取代了。

　　例子代碼

　　打包成zip格式的例程代碼最好是用Apache Maven來使用它們。你能夠在主源代碼目錄src/java找到API。src/java目錄中有三個單元測試，包括：SimpleSequenceTestCase，RateDropTestCase和PoolingTestCase。要運行所有這些測試，在命令行shell中鍵入maven test，然后在編譯和運行之前，Maven將會下載所有必需的jar文件。實際的XSL轉換將會發生在兩個測試中，它們的結果被管道輸出到控制臺。鍵入maven test:ui來拉出圖形化的測試運行器，然后選擇你想要運行的測試，并且觀察控制臺的結果。

　　結論

　　在這篇文章中你已經通過設計模式看到了工作流過程種類，在這些模式中，我們主要集中介紹了順序模式。通過使用接口，我們來對基本工作流組件建模。通過裝配多個接口實現到Spring，實現一個順序工作流。最后還討論了啟動和部署工作流的不同選項。

　　這里所提出的簡單工作流技術肯定不是最終的和革命性的。但是，使用Spring來實現像工作流這樣的通用任務是一個通過使用IoC容器而獲得的效率的好的示例。由于減少了粘合性代碼的需要，Spring在保持面向對象的約束同時，減少面向對象操作麻煩的程度。

http://macrochen.blogdriver.com/macrochen/1088243.html

什么是工作流引擎（Workflow Engine ）- -

所謂工作流引擎是指workflow作為應用系統的一部分，并為之提供對各應用系統有決定作用的根據角色、分工和條件的不同決定信息傳遞路由、內容等級等核心解決方案。例如開發一個系統最關鍵的部分不是系統的界面，也不是和數據庫之間的信息交換，而是如何根據業務邏輯開發出符合實際需要的程序邏輯并確保其穩定性、易維護性（模塊化和結構化）和彈性（容易根據實際業務邏輯的變化作出程序上的變動，例如決策權的改變、組織結構的變動和由于業務方向的變化產生的全新業務邏輯等等）。 Workflow 引擎解決的就是這個問題：如果應用程序缺乏強大的邏輯層，勢必變得容易出錯（信息的路由錯誤、死循環等等）。

就好比一輛汽車，外表做得再漂亮，如果發動機有問題就只是一個擺設。應用系統的彈性就好比引擎轉速方面的性能，加速到100 公里需要1 個小時（業務流程發生變動需要進行半年的程序修改）還能叫好車嗎？引擎動不動就熄火（程序因為邏輯的問題陷入死循環）的車還敢開嗎？

工作流解決方案與傳統管理軟件的關系傳統的管理軟件注重解決企業應用層現存的問題（例如提高企業的資源配置率或提高單一員工的生產效率）。例如：EXCEL 可以提高員工畫表格的效率、財務軟件可以規范財務人員的工作并提高帳目查詢的效率、CRM 可以規范客戶管理從而使客戶資源掌握在公司手中而不是被一部分業務人員把持并提高客戶響應時間、ERP 解決的是如何配置企業資源：使企業的人力資源、財力資源和物資資源能夠根據業務的需求實現最大化配置。 workflow 關注的是如何縮短流程閑置時間，從而提高企業的業務處理能力并使企業能夠關注于真正對企業有意義的增值業務上。從建立企業神經系統的角度也許更能理解兩者的區別。傳統軟件不能解決工作流的問題，例如ERP 關注的是企業的資源配置，但不可能解決資源傳輸過程中的損耗和降低傳輸（流程）的成本；同樣workflow也不能完全解決傳統管理軟件所能解決的問題，例如對生產管理的MRP 系統所能解決的生產過程控制通過workflow很難實現。但一個好的傳統軟件如果希望能自動化地在整個企業中應用起來，必須有一個強大的邏輯層，用以解決信息傳遞的邏輯判斷和自動流轉，這個時候就需要workflow的平臺。所以說： 1.workflow 和傳統管理軟件不是同一種軟件，不具可比性； 2.workflow 對于已經有傳統管理軟件的企業的作用非常明顯，可以籍此平臺整合企業的各種應用系統，使之成為一個完整的企業級應用，也就是通常所說的EAI. 3. 具備workflow功能的管理軟件（workflow與傳統管理軟件的結合）對于傳統管理軟件有絕對的優勢；4.workflow可以根據企業的需要開發解決信息傳遞問題的流程以及幫助企業開發與現有應用系統的接口

工作流自動化并不復雜因為下述幾個原因，工作流自動化業界有" 適合處理復雜業務流程" 的名聲。

1.常規工作流自動化軟件包及其部署相當昂貴。通常，伴隨產品的是長時期的咨詢關系。所以為了非常簡單的業務流程購買和部署軟件是被不被采納的。這些軟件通常只被用于復雜、關鍵和控制成本相對較高而工作流自動化帶來的效益明顯的量產型工作流應用。因此經銷商和用戶都會不自覺地關注于將復雜的業務問題自動化。 2. 處于類似原因，工作流研究人士首先會關注解決了哪些復雜的業務流程問題。

而對于大多數案例而言，為解決簡單工作流程問題部署自動化軟件的成本顯然是不經濟的。這里遵循一條簡單的道理：走之前必須先會爬，跑之前必須先會走。 3. 最后一條原因，也是"IT 業的尷尬".總經理對IT部門經理工作衡量的標準就是：能夠解決復雜問題的能力。自然，IT經理就會不遺余力地解決那些復雜的問題，他們的方案通常也就復雜而且昂貴。

所有這些目前都在改變。針對桌面電腦的應用方案快速發展以及工作流解決方案的發展使解決日常工作流程問題成為可能。費用不再昂貴，部署更為簡便。事實上，企業越來越意識到工作流的重要性，同時在部署復雜關鍵的流程自動化之前，愿意從一些簡單的流程入手積累經驗。

工作流會成為操作系統的一部分嗎？

有人認為工作流會成為操作系統平臺（例如WINDOWS 平臺）的一部分。我們的觀點是，基于下述幾個原因，在可預見的未來，工作流不會成為操作系統的一部分： 1. 擴展表格、文字處理程序和數據庫存在了20多年，成了家喻戶曉的名詞。這些技術被廣泛理解和應用，也相應形成了各自的標準和相關術語。然而因為很多原因，直到今天這些技術也沒有成為操作系統的一部分。最重要的原因之一是用戶需要差異和選擇的自由。相比較而言，工作流自動化軟件是較新的技術，也更有差異性、不易被廣泛理解并且比這些技術更為先進。因為工作流程的差異性和復雜性，工作流自動化的用戶需要更多的選擇空間。

2.財務軟件包從電腦發明后就迅速普及了。這是實施、術語和規則被普遍接受的另一個領域。然而至今也沒有哪種操作系統吹噓集成了多少財務軟件的功能。而工作流自動化軟件比財務軟件更為復雜和有差異性。 3. 操作系統提供商，例如微軟和Sun ，不會為了使其系統具備工作流自動化的功能而大量改變他們現有的系統。他們有什么必要為工作流自動化軟件投入開發和支持的成本呢？ 4. 操作系統是為常規條件設計并使之最優化。正因如此，目前操作系統的開發成本幾乎都要上億美元。業務流程十分復雜并充滿了例外情況，如在操作系統中內嵌工作流自動化程序會極大地增加開發成本和難度。因此，即便操作系統提供商決定做工作流軟件，也會是巨額投入開發一套新的操作系統，而不是將工作流嵌入。

事實上，今天的很多優秀的工作流解決方案集成了短信息、頁面服務、目標管理、文件管理和其他一些操作系統才提供的服務。

工作流自動化的主要成分工作流自動化如今成了管理的一句時髦話。市面上也有很多號稱能激活工作流的自動化產品。只要他們的應用程序支持基本的E-mail功能，賣主就會隨意地把" 激活工作流" 作為標簽貼在產品上。然而，這類產品和真正工作流自動化軟件之間的差別就如同寫字版和Word之間的差別。我們相信，應用程序只有具備了下列主要特征，才能稱其為工作流自動化解決方案：

能夠畫出工作流程圖，當然以圖形化界面設計的為佳；能為每個步驟設計電子表格；能將外部應用程序結合為工作流自動化的一部分；能與電子表格及企業數據庫相連接；能設計基于復雜業務規則的條件型路由的工作流程圖，最好無須編程；能根據功能、用戶名稱或上下級關系按規則傳遞信息；能夠監控工作流執行狀況；能夠對工作流進行調節；能夠模擬并測試工作流的行為；工作流的應用必須支持多用戶并具高度可靠性；工作流的應用必須支持內部網或英特網及跨多種平臺。

網友討論工作流應該是一個中間件而不應該是一個完整的系統。工作流應該整合到其他系統中而不是單獨使用。

工作流要完成的核心功能有流程設計，流程執行，流程和線程的調度，任務的分派與通知，集成已有信息系統（很多人忘了）。

工作流應該提供對組織機構，用戶，權限管理，流程，任務的管理能力，但是對這些管理能力最基本實現方式是提供API ，而不是一個管理系統，即使把這些管理作為一個管理系統來實現（A ），也主要是用于演示，因為當工作流用于其它系統（B ），因為B 需要一個統一的管理界面，所以通常不會直接使用A.而表單設計，報表之類根本就是外圍功能，是二次開發商的任務。

我基本贊同wangtaoyy 的說法，再補充一點。我覺得工作流與其說是中間件，還不如說是一個應用整合和集成的框架。類似在j2ee規范下各產商開發的應用服務器，工作流也應當是在wfmc標準下開發出來的" 容器" ，只要是滿足了標準的應用程序或組件都能夠在這個" 容器" 中按照預定的規則被調度和執行。我認為理想情況下工作流系統不應該提供API 作二次開發，工作流的內部對基于工作流的應用程序應當是完全不透明的，工作流應當提供給開發者的是一個類似于J2EE那樣的標準，一套編程模型和接口模型。開發者在這個模型下去實現那些接口，開發出應用組件，再利用工作流提供的管理器進行" 注冊".總而言之，對開發者而言，工作流是黑箱，他需要做的事情是開發標準組件，在工作流提供的UI管理工具中配置業務流程，包括業務過程、資源、權限、時間、規則等等。

1. j2ee 應用服務器也是中間件的一種。
2. 工作流要做成j2ee哪樣的標準還是比較困難的， j2ee 重點在于提供開發全新系統的能力，所以可以制定比較好的容器- 組件標準，而工作流的重點是整合已經存在的系統，要在這些各式各樣的老系統上強加標準是不現實的。
3.工作流應該提供api ，因為其他系統中的一些事件可能會啟動一個流程，或者觸發其他與流程相關的東西

工作流分為兩種類型，一種是嵌入式的，另一種是非嵌入式的。這在WFMC的文檔中已經有所介紹，大家可以找找看一下。按照工作流管理聯盟的文檔，大家說的都沒有什么錯誤，只是側重點不同。wangtaoyy 的觀點傾向于前者，而coffeewoo 的觀點傾向于后者。

我的看法并不是趨向于嵌入式工作流。我理解的工作流提供的api 并不是一般軟件包的API ，而是一種服務方式的API ，類似于操作系統中的系統調用。

我們在軟件中大量使用了操作系統提供的系統調用API ，但是操作系統并不是嵌入到我們軟件系統中的。我認為工作流系統與操作系統有很強的可比性，只是工作流層次更高。比如流程設計相當于編程，模型相當于程序，流程實例相當于進程，流程分支相當于線程，操作系統要對進程和線程進行調度，工作流引擎要對流程實例和分支進行調度，操作系統和工作流系統都應該對內存進行管理避免耗盡系統內存，操作系統提供系統調用API 而工作流引擎提供工作流API.何其相似。

從功能的角度看：工作流系統的本職工作就是管理和控制業務流程，例如：流程實例的啟動、停止；環節實例的啟動、結束；任務的分配等等。從工作流系統的組成看：工作流系統應該包括流程引擎、流程定義工具、運行管理工具、api 系統。工作流系統應該該不包括表單定義、組織機構定義及其管理、權限管理、數據流管理等等。

工作流系統雖然不包括上述功能，但是工作流系統一定會和上述功能發生交互關系，所以好的工作流產品并不是一個包辦上述功能的產品，而是一個設計良好的能夠和上述功能交互的系統。從和其他系統的關系看待工作流：如果站在基礎業務平臺的角度，那么，工作流系統、組織機構管理系統、表單自定義系統、權限管理系統、數據流管理系統、報表系統都是這個基礎業務平臺的服務。業務功能系統在運行的過程中會調用這些服務，這些服務之間本身也可能互相調用。例如：工作流服務和組織機構管理服務之間的關系就非常密切，盡管如此，如果認為工作流系統一定包含組織機構管理系統應該是不正確的。在oa系統中，表單自定義好像比較重要，而且流程常常需要引用表單上的數據，但是表單自定義絕對不是工作流系統的組成部分。流程在運行的過程中可能跨多個數據庫系統，任務在流轉的過程中需要“攜帶”大量的業務數據，但是這些也不是工作流要做的事情，完成這些工作的系統我稱之為“數據流管理系統”。總之：從功能的角度，所有的功能都是必要的，但是從技術的角度，這些功能不可以做到一個“鐵板一塊”的所謂的“工作流”里面去。從技術發展的趨勢看：工作流系統很可能發展成為一個類似關系型數據庫管理系統的專職的系統。我那個工作流東東還在改進中，希望作出一個設計合理的（決對不是強行coding出來的），工程實用的東西出來