專利名稱：：一種基于狀態(tài)變化的流程控制中消息訂閱和分發(fā)系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
：本發(fā)明涉及一種消息訂閱和分發(fā)系統(tǒng)，尤其是涉及一種基于狀態(tài)變化的流程控制中消息訂閱和分發(fā)系統(tǒng)。
背景技術(shù)：
：目前，常見的流程引擎主要表現(xiàn)為兩種形式一種是基于順序的，另一種是基于狀態(tài)的。基于狀態(tài)的流程控制，顧名思義，其核心是狀態(tài)。這里的狀態(tài)，既包括流程實例的狀態(tài)，又包括流程任務(wù)的狀態(tài)。它區(qū)別于基于順序的流程具體表現(xiàn)為不限制流程的流向，節(jié)點的處理順序完全依賴于節(jié)點的狀態(tài)變化，以及對狀態(tài)變化所作的配置。這些配置將決定節(jié)點狀態(tài)發(fā)生變化時的其他節(jié)點的后續(xù)動作。基于狀態(tài)的流程控制的定義部分主要包括流程定義、流程節(jié)點、流程實例和流程任務(wù)。流程定義是對流程引擎的一種工作模式的描述，其實體為一個XML,描述了流程需要經(jīng)歷哪些節(jié)點，并采用何種順序經(jīng)歷這些節(jié)點，以及其他一些完成該流程所必需的配置屬性。流程節(jié)點是流程定義的子對象，描述流程中每一個需要處理的部分。流程實例是對流程定義的一次對象化，即從流程開始到流程結(jié)束的一個獨立過程。流程任務(wù)是流程實例的子對象，是流程節(jié)點的一次對象化。圖1出示了基于狀態(tài)的流程運行示意圖，其中描述的節(jié)點流向箭頭不再具有約束作用，而起決定作用的是在流程定義中配置的節(jié)點狀態(tài)依賴關(guān)系，狀態(tài)依賴關(guān)系配置表如下表所示。<table>tableseeoriginaldocumentpage4</column></row><table>流程定義定義了流程引擎的基本工作模式，但是如果讓流程真正的運轉(zhuǎn)起來，需要外部應(yīng)用系統(tǒng)參與流程的處理過程，包括發(fā)起、執(zhí)行、中斷和關(guān)閉等。然而讓外部應(yīng)用系統(tǒng)參與流程的處理過程僅僅依靠對狀態(tài)的設(shè)置是不夠的，應(yīng)用系統(tǒng)必須及時地知悉流程當(dāng)前執(zhí)行到哪個節(jié)點、該節(jié)點的狀態(tài)如何、狀態(tài)何時變化以及流程的進(jìn)度等信息。當(dāng)前，應(yīng)用系統(tǒng)獲得流程狀態(tài)變化的信息主要通過輪詢方式或者回調(diào)方式。輪詢方式是應(yīng)用系統(tǒng)不斷地詢問流程的狀態(tài)是否發(fā)生變化，這種方式的效率較低。回調(diào)方式是流程引擎主動調(diào)用參與流程的應(yīng)用系統(tǒng)，通知流程狀態(tài)的變化情況，這種方式流程引擎與參與方的耦合性較大，如果調(diào)用阻塞或者失敗，會對流程的執(zhí)行產(chǎn)生影響。而且，流程的狀態(tài)一旦發(fā)生變化系統(tǒng)便會產(chǎn)生消息，而一些消息是無用的信息，從而造成了系統(tǒng)數(shù)據(jù)的冗余。
發(fā)明內(nèi)容針對現(xiàn)有技術(shù)中存在的缺陷，本發(fā)明的目的是提供一種基于狀態(tài)變化的流程控制中消息訂閱和分發(fā)系統(tǒng)，該系統(tǒng)能夠提高獲得流程狀態(tài)變化信息的效率，降低系統(tǒng)的數(shù)據(jù)冗余。為了實現(xiàn)上述目的，本發(fā)明采用的技術(shù)方案是一種基于狀態(tài)變化的流程控制中消息訂閱和分發(fā)系統(tǒng)，包括消息訂閱方、流程定義裝置、流程引擎裝置和數(shù)據(jù)庫。其中，所述的流程定義裝置包括訂閱符合同一流程定義的所有流程實例在執(zhí)行過程中產(chǎn)生的消息的靜態(tài)消息訂閱模塊。所述的流程引擎裝置包括用于訂閱任意一個流程實例在執(zhí)行過程中產(chǎn)生的消息的動態(tài)消息訂閱模塊、用于設(shè)置任務(wù)的狀態(tài)和產(chǎn)生消息的任務(wù)處理模塊以及用于將產(chǎn)生的消息分發(fā)給該消息的訂閱者的消息分發(fā)模塊。所述的流程定義裝置與數(shù)據(jù)庫連接，流程引擎裝置分別與消息訂閱方和數(shù)據(jù)庫連接。如上所述的基于狀態(tài)變化的流程控制中消息訂閱和分發(fā)系統(tǒng)，所述的靜態(tài)消息訂閱模塊包括用于訂閱整個流程的狀態(tài)發(fā)生變化時生成的消息的流程實例訂閱子模塊和用于訂閱一個流程中的節(jié)點所對應(yīng)的流程任務(wù)的狀態(tài)發(fā)生變化時生成的消息的流程任務(wù)訂閱子模塊。如上所述的基于狀態(tài)變化的流程控制中消息訂閱和分發(fā)系統(tǒng)，所述的動態(tài)消息訂閱模塊包括流程發(fā)起方訂閱子模塊和流程參與方訂閱子模塊；所述的流程發(fā)起方訂閱子模塊訂閱消息的過程為當(dāng)流程發(fā)起成功后，發(fā)起方得到該次流程實例的ID,然后利用該次流程實例的ID訂閱該次流程實例的所有消息；所述的流程參與方訂閱子模塊訂閱消息的過程為首先在流程定義中定義某個節(jié)點的消息訂閱方，當(dāng)流程執(zhí)行到該節(jié)點時，將產(chǎn)生的狀態(tài)變化消息發(fā)送到該節(jié)點的消息訂閱方，消息訂閱方從獲取的消息中得到此次流程實例的ID,然后再利用此次流程實例的ID訂閱該節(jié)點后流程執(zhí)行過程中生成的所有消息。如上所述的基于狀態(tài)變化的流程控制中消息訂閱和分發(fā)系統(tǒng)，所述的消息訂閱方通過流程引擎裝置提供接口與動態(tài)消息訂閱模塊進(jìn)行交互，所述的接口包括所有實例消息訂閱接口、具體實例消息訂閱接口、訂閱消息取消4^口和訂閱消息獲取接口。如上所述的基于狀態(tài)變化的流程控制中消息訂閱和分發(fā)系統(tǒng)，所述的任務(wù)處理模塊包括用于設(shè)置流程狀態(tài)的狀態(tài)設(shè)置器和用于產(chǎn)生消息的消息產(chǎn)生器，所述的消息產(chǎn)生器與消息分發(fā)4莫塊相連。如上所述的基于狀態(tài)變化的流程控制中消息訂閱和分發(fā)系統(tǒng)，所述的消息分發(fā)模塊分發(fā)消息的過程為首先將消息產(chǎn)生器產(chǎn)生的消息放入一個消息隊列中，所述的消息隊列存儲在數(shù)據(jù)庫中，消息訂閱方定期或不定期的從該消息隊列中獲取自己訂閱的消息。采用本發(fā)明所述的系統(tǒng)，參與流程的應(yīng)用系統(tǒng)通過訂閱消息的方式獲知流程的狀態(tài)發(fā)生變化的信息，提高了獲得流程狀態(tài)變化信息的效率，降低了系統(tǒng)的數(shù)據(jù)冗余。而且，消息的訂閱支持兩種方式，即可以預(yù)先進(jìn)行靜態(tài)訂閱，又可以在流程執(zhí)行過程中進(jìn)行動態(tài)訂閱。消息分發(fā)時采用消息隊列的形式，可以最大限度地降低系統(tǒng)壓力，使資源利用達(dá)到均衡。圖l是基于狀態(tài)的流程運行示意圖；圖2是本發(fā)明所述的系統(tǒng)結(jié)構(gòu)圖3是本發(fā)明具體實施方式中發(fā)起方動態(tài)訂閱消息的流程圖；圖4是本發(fā)明具體實施方式中參與方動態(tài)訂閱消息的流程圖；圖5是本發(fā)明具體實施方式中消息產(chǎn)生和分發(fā)的數(shù)據(jù)流圖。具體實施例方式下面結(jié)合具體實施方式和附圖對本發(fā)明進(jìn)行詳細(xì)描述。本發(fā)明所述的系統(tǒng)主要應(yīng)用于基于狀態(tài)變化的流程控制體系中，即流程驅(qū)動的主要動力為節(jié)點狀態(tài)的變化。參與流程處理過程的外部應(yīng)用系統(tǒng)或客戶程序等(以下通稱消息訂閱方)必須實時地知悉流程當(dāng)前執(zhí)行到哪個節(jié)點、該節(jié)點的狀態(tài)、狀態(tài)何時變化以及流程的進(jìn)度等信息。為此，本發(fā)明引入了消息的概念，消息訂閱方通過其訂閱的消息來了解上述的狀態(tài)信息。那么，消息如何訂閱以及分發(fā)便是本發(fā)明所要解決的問題。圖2出示了本發(fā)明所述的基于狀態(tài)變化的流程控制中消息訂閱和分發(fā)系統(tǒng)的結(jié)構(gòu)，包括消息訂閱方、流程定義裝置、流程引擎裝置和數(shù)據(jù)庫。其中，消息訂閱方包括客戶程序、應(yīng)用服務(wù)和應(yīng)用系統(tǒng)等，流程定義裝置包括訂閱符合同一流程定義的所有流程實例在執(zhí)行過程中產(chǎn)生的消息的靜態(tài)消息訂閱模塊，流程引擎裝置包括用于訂閱任意一個流程實例在執(zhí)行過程中產(chǎn)生的消息的動態(tài)消息訂閱模塊、用于設(shè)置任務(wù)的狀態(tài)和產(chǎn)生消息的任務(wù)處理模塊以及用于將產(chǎn)生的消息分發(fā)給該消息的訂閱者的消息分發(fā)模塊。流程定義裝置與數(shù)據(jù)庫連接，流程引擎裝置分別與消息訂閱方和數(shù)據(jù)庫連接。本發(fā)明所述的消息訂閱方式分為靜態(tài)訂閱和動態(tài)訂閱。所謂靜態(tài)訂閱是指在流程定義中定義了消息訂閱方，在每次應(yīng)用該流程定義的流程實例的執(zhí)行過程中產(chǎn)生的消息均發(fā)送給該消息訂閱方。所謂動態(tài)訂閱是指消息訂閱方能夠任意在任何一個流程實例中訂閱消息。靜態(tài)訂閱的實現(xiàn)是和流程定義分不開的，一個流程定義實際上就是具體流程實例的模板，在流程定義中描述的內(nèi)容將被應(yīng)用到所有使用該流程定義的流程實例中去。例如一個傳輸流程，如果在傳輸流程定義中定義了消息的接收者，那么每次應(yīng)用該定義的傳輸流程所產(chǎn)生的消息都會發(fā)送給該接收者。因此，靜態(tài)訂閱模塊設(shè)置在流程定義裝置中。在流程定義裝置定義流程的過程中，靜態(tài)訂閱模塊完成消息訂閱方訂閱消息的任務(wù)。靜態(tài)訂閱可以訂閱兩部分內(nèi)容流程實例的訂閱和流程任務(wù)的訂閱。所謂流程實例的訂閱是指訂閱整個流程的狀態(tài)發(fā)生變化時生成的消息。而流程任務(wù)的訂閱只指訂閱一個流程中某個節(jié)點所對應(yīng)的流程任務(wù)產(chǎn)生的消息。因此，靜態(tài)消息訂閱模塊包括用于訂閱整個流程的狀態(tài)發(fā)生變化時生成的消息的流程實例訂閱子模塊和用于訂閱一個流程中的節(jié)點所對應(yīng)的流程任務(wù)生成的消息的流程任務(wù)訂閱子模塊。流程實例的訂閱在流程定義中的描述如下<WorkflowDefine>〈WorkflowName〉i^禾呈名稱〈/WorkflowName〉<BeforeStatusChanged/><AfterStatusChanged><Listener><PostMessage〉〈Description〉通知XXX獲取實例的消息〈/Descripti(M^〈Receiver〉接收者1</Receiver><Lifecycle>0</Lifecycle></PostMessage></Listener></AfterStatusChanged><Actions〉</WorkflowDefine>流程任務(wù)的訂閱在流程定義中位于節(jié)點Action之下，其內(nèi)容如下:<Actions><Action>〈ActionlD〉任務(wù)ID〈/ActionlD〉〈ActionName〉任務(wù)名稱〈/ActionName〉<StatusChanges〉狀態(tài)變化依賴關(guān)系</StatusChanges><BeforeStatusChanged/><AfterStatusChanged><Listener><PostMessage>〈Description〉通知XX獲取任務(wù)的消息々Description〉〈Receiver〉接收者2〈/Receiver〉<Lifecycle>0</Lifecycle></PostMessage></Listener></AfterStatusChanged></Action〉<Actionleft="40"top="40">其他節(jié)點...</Actions>在上述的XML描述里，Receiver(接收者)可以有多個，即可以為一個消息配置多個消息訂閱方，消息產(chǎn)生器為每個消息訂閱方都產(chǎn)生一個消息。Lifecycle表示消息的生命期，由于消息是在消息隊列中"等待"消息訂閱方來獲取，因此如果超過生命期以后消息沒有被取走，則被視為"過期"作廢。另外，Listener節(jié)點也可以是多個，即可以為消息指定多組接收者，每組產(chǎn)生的消息生命期相同，但不同組之間可以不同。靜態(tài)消息訂閱模塊完成消息的訂閱后，將訂閱信息存入數(shù)據(jù)庫中，以便其他模塊查閱。動態(tài)訂閱與靜態(tài)訂閱不同，它更加靈活。消息訂閱方只選4奪它所關(guān)心的流程實例進(jìn)行訂閱，而不必要接收所有應(yīng)用同一流程定義的所有流程實例的消息，這一點是它與靜態(tài)訂閱的主要區(qū)別。動態(tài)訂閱也被分為兩種類型一種是流程發(fā)起方的訂閱，一種是流程參與方的訂閱。因此，動態(tài)消息訂閱模塊包括流程發(fā)起方訂閱子模塊和流程參與方訂閱子模塊。圖3出示了流程發(fā)起方訂閱子模塊的工作流程。對于發(fā)起方來說，流程發(fā)起成功后會得到該次流程實例的ID信息，借助流程實例的ID,流程發(fā)起方訂閱子才莫塊可以為消息訂閱方完成該實例中所有消息的動態(tài)訂閱。圖4出示了流程參與方訂閱子模塊的工作流程。對于流程的參與方來說，它們并不知道自己將參與的流程實例。因此它們的動態(tài)訂閱是從靜態(tài)訂閱開始的。例如，消息訂閱方B是"傳輸流程，，的一個參與者，在流程定義中定義了B為節(jié)點2的消息接收者。那么當(dāng)流程進(jìn)行到節(jié)點2的時候，會產(chǎn)生節(jié)點2的狀態(tài)變化的消息，B獲得該消息后，便能夠從該消息中獲取流程實例的ID信息。所以，B在"傳輸流程"的中間位置開始參與到流程中來，那么從這個時刻起流程參與方訂閱子模塊就可以為消息訂閱方完成該流程實例此后的所有消息的動態(tài)訂閱。動態(tài)訂閱的具體實現(xiàn)方式是消息訂閱方通過流程引擎裝置提供接口與動態(tài)消息訂閱模塊進(jìn)行交互，來實現(xiàn)消息的動態(tài)訂閱。與動態(tài)訂閱相關(guān)的接口包括所有實例消息訂閱接口、具體實例消息訂閱接口、取消消息訂閱接口和訂閱消息獲取接口。*訂閱所有實例的消息<table>tableseeoriginaldocumentpage10</column></row><table>圖5出示了消息產(chǎn)生和分發(fā)的數(shù)據(jù)流圖。在流程執(zhí)行過程中，當(dāng)流程的狀態(tài)發(fā)生變化時，消息產(chǎn)生器根據(jù)該狀態(tài)變化消息的訂閱情況為每一個消息訂閱方產(chǎn)生消息。產(chǎn)生消息的條件主要有兩個①是流程實例或流程任務(wù)的狀態(tài)發(fā)生了變化，②是該實例或任務(wù)已經(jīng)被消息訂閱方訂閱。條件①指明了消息的內(nèi)容，條件②則限定了消息的接收者，兩個條件缺一不可。消息產(chǎn)生器將產(chǎn)生的消息送入消息分發(fā)模塊，消息分發(fā)模塊再將消息分發(fā)給該消息的訂閱方。本實施方式中，消息分發(fā)是通過在數(shù)據(jù)庫中建立的一個消息隊列實現(xiàn)的。當(dāng)生成消息后，將該消息放入消息隊列中，消息訂閱方定期或不定期的從隊列中獲取屬于自己的消息。每個消息都具有生命期，如果超過生命期以后該消息還沒有被取走，則被視為過期作廢，將其從消息隊列中刪除。另外，消息的動態(tài)訂閱需要指定要訂閱的流程實例的ID,但是在動態(tài)訂閱的消息分發(fā)時，消息訂閱方并不需要指明要獲取的流程實例ID。消息訂閱方每次都將其當(dāng)前訂閱過的所有流程實例的消息一次性取回，這大大提高了消息傳送的效率并有效的降低了系統(tǒng)負(fù)荷。本發(fā)明所述的系統(tǒng)并不限于上述具體實施方式，本領(lǐng)域技術(shù)人員根據(jù)本發(fā)明的技術(shù)方案得出其他的實施方式，同樣屬于本發(fā)明的技術(shù)創(chuàng)新范圍。1權(quán)利要求1.一種基于狀態(tài)變化的流程控制中消息訂閱和分發(fā)系統(tǒng)，包括消息訂閱方、流程定義裝置、流程引擎裝置和數(shù)據(jù)庫，其特征在于所述的流程定義裝置包括訂閱符合同一流程定義的所有流程實例在執(zhí)行過程中產(chǎn)生的消息的靜態(tài)消息訂閱模塊，所述的流程引擎裝置包括用于訂閱任意一個流程實例在執(zhí)行過程中產(chǎn)生的消息的動態(tài)消息訂閱模塊、用于設(shè)置任務(wù)的狀態(tài)和產(chǎn)生消息的任務(wù)處理模塊以及用于將產(chǎn)生的消息分發(fā)給該消息的訂閱者的消息分發(fā)模塊；所述的流程定義裝置與數(shù)據(jù)庫連接，流程引擎裝置分別與消息訂閱方和數(shù)據(jù)庫連接。2.如權(quán)利要求1所述的基于狀態(tài)變化的流程控制中消息訂閱和分發(fā)系統(tǒng)，其特征在于所述的靜態(tài)消息訂閱模塊包括用于訂閱整個流程的狀態(tài)發(fā)生變化時生成的消息的流程實例訂閱子模塊和用于訂閱一個流程中的節(jié)點所對應(yīng)的流程任務(wù)的狀態(tài)發(fā)生變化時生成的消息的流程任務(wù)訂閱子模塊。3.如權(quán)利要求1所述的基于狀態(tài)變化的流程控制中消息訂閱和分發(fā)系統(tǒng)，其特征在于所述的動態(tài)消息訂閱模塊包括流程發(fā)起方訂閱子模塊和流程參與方訂閱子模塊；所述的流程發(fā)起方訂閱子模塊訂閱消息的過程為當(dāng)流程發(fā)起成功后，發(fā)起方得到該次流程實例的ID，然后利用該次流程實例的ID訂閱該次流程實例的所有消息；所述的流程參與方訂閱子模塊訂閱消息的過程為首先在流程定義中定義某個節(jié)點的消息訂閱方，當(dāng)流程執(zhí)行到該節(jié)點時，將產(chǎn)生的狀態(tài)變化消息發(fā)送到該節(jié)點的消息訂閱方，消息訂閱方從獲取的消息中得到此次流程實例的ID,然后再利用此次流程實例的ID訂閱該節(jié)點后流程執(zhí)行過程中生成的所有消息。4.如權(quán)利要求1所述的基于狀態(tài)變化的流程控制中消息訂閱和分發(fā)系統(tǒng)，其特征在于所述的消息訂閱方通過流程引擎裝置提供接口與動態(tài)消息訂閱模塊進(jìn)行交互，所述的接口包括所有實例消息訂閱接口、具體實例消息訂閱接口、訂閱消息取消接口和訂閱消息獲取接口。5.如權(quán)利要求1所述的基于狀態(tài)變化的流程控制中消息訂閱和分發(fā)系統(tǒng)，其特征在于所述的任務(wù)處理模塊包括用于設(shè)置流程狀態(tài)的狀態(tài)設(shè)置器和用于產(chǎn)生消息的消息產(chǎn)生器，所述的消息產(chǎn)生器與消息分發(fā)模塊相連。6.如權(quán)利要求5所述的基于狀態(tài)變化的流程控制中消息訂閱和分發(fā)系統(tǒng)，其特征在于，所述的消息分發(fā)模塊分發(fā)消息的過程為首先將消息產(chǎn)生器產(chǎn)生的消息放入存儲在數(shù)據(jù)庫中的一個消息隊列，消息訂閱方定期或不定期的從該消息隊列中獲取自己訂閱的消息；所述的消息具有生命期，如果超過生命期以后該消息還沒有被取走，則被視為過期作廢，將其從消息隊列中刪除。全文摘要本發(fā)明公開了一種消息訂閱和分發(fā)系統(tǒng)，尤其是公開了一種基于狀態(tài)變化的流程控制中消息訂閱和分發(fā)系統(tǒng)?，F(xiàn)有技術(shù)存在效率低和數(shù)據(jù)冗余等缺陷。本發(fā)明所述的系統(tǒng)，包括消息訂閱方、流程定義裝置、流程引擎裝置和數(shù)據(jù)庫。流程定義裝置包括訂閱符合同一流程定義的所有流程實例在執(zhí)行過程中產(chǎn)生的消息的靜態(tài)消息訂閱模塊。流程引擎裝置包括用于訂閱任意一個流程實例在執(zhí)行過程中產(chǎn)生的消息的動態(tài)消息訂閱模塊、用于設(shè)置任務(wù)的狀態(tài)和產(chǎn)生消息的任務(wù)處理模塊以及用于將產(chǎn)生的消息分發(fā)給該消息的訂閱者的消息分發(fā)模塊。流程定義裝置與數(shù)據(jù)庫連接，流程引擎裝置分別與消息訂閱方和數(shù)據(jù)庫連接。采用本發(fā)明所述的系統(tǒng)能夠提高效率和減少數(shù)據(jù)冗余。文檔編號H04L12/58GK101677303SQ20081022243公開日2010年3月24日申請日期2008年9月17日優(yōu)先權(quán)日2008年9月17日發(fā)明者偉孫,王弋珵申請人:新奧特(北京)視頻技術(shù)有限公司