摘要:   閱讀全文      摘要:   閱讀全文

作者:楊洪波
jbpm解析流程定義有三種方式:
1)par包
static ProcessDefinition auctionProcess =
      ProcessArchive.parse("org/jbpm/tdd/auction.par");
注意,必須在classes的org/jbpm/tdd/目錄下有一個(gè)auction.par文件

2)xml文件方式
static ProcessDefinition auctionProcess =
      JpdlXmlReader.parseFromResource("org/jbpm/tdd/auction.xml");
注意,必須在classes的org/jbpm/tdd/目錄下有一個(gè)auction.xml文件

3)文本方式
static ProcessDefinition auctionProcess = JpdlXmlReader.parse(
    "<process-definition>" +
    "  <start-state name='start'>" +
    "    <transition to='auction'/>" +
    "  </start-state>" +
    "  <state name='auction'>" +
    "    <transition to='end'/>" +
    "  </state>" +
    "  <end-state name='end'/>" +
    "</process-definition>");
這種方式的本質(zhì)和xml文件解析方式是一樣的.

作者:楊洪波

作者:楊洪波

shark和jbpm配置文件處理方式比較

1.都使用了單例模式
我想這個(gè)是最基本的,一般的程序員寫解析程序都會(huì)這樣使用;要說明的是,AgileFlow
除了使用單例模式,還實(shí)現(xiàn)了配置文件的動(dòng)態(tài)裝載,如果用戶修改了配置文件,它能夠在
運(yùn)行中動(dòng)態(tài)的獲取這些變化.
使用jbpm時(shí),第一句話就要使用該模式:JbpmServiceFactory.getInstance()....

2.都實(shí)現(xiàn)了缺省配置和定制配置
Shark中,缺省配置放在一個(gè)深層次的目錄中,定制配置放在config目錄,兩個(gè)配置
文件的內(nèi)容差不多;
jbpm中,缺省配置放在代碼中實(shí)現(xiàn),如下:
propertyClassNames = new HashMap();
propertyClassNames.put( "default", "org.jbpm.impl.DefaultServiceFactory" );
abbreviatedClassNames.put( "jbpm.service.factory", propertyClassNames );
定制配置放在config目錄中,為jbpm.properties
比較而言,jbpm的實(shí)現(xiàn)方式要好,理由如下:
1)缺省配置容易找到
2)定制配置很簡單,默認(rèn)是沒有配置的,比shark的要清爽很多

3.都實(shí)現(xiàn)了用一個(gè)單例實(shí)現(xiàn)多個(gè)單例
我在Shark學(xué)習(xí)系列的文章中討論過這個(gè)功能,jbpm是在JbpmConfiguration.java中實(shí)現(xiàn)的:
private void instantiateConfiguredObjects() {
    // instantiate configured objects
    this.fileMgr = (FileMgr) instantiate( "jbpm.file.mgr", FileMgr.class );
    this.idGenerator = (IdGenerator) instantiate( "jbpm.id.generator", IdGenerator.class );
    this.serviceFactory = (ServiceFactory) instantiate( "jbpm.service.factory", ServiceFactory.class );
}

1.都使用了單例模式
我想這個(gè)是最基本的,一般的程序員寫解析程序都會(huì)這樣使用;要說明的是,AgileFlow
除了使用單例模式,還實(shí)現(xiàn)了配置文件的動(dòng)態(tài)裝載,如果用戶修改了配置文件,它能夠在
運(yùn)行中動(dòng)態(tài)的獲取這些變化.
使用jbpm時(shí),第一句話就要使用該模式:JbpmServiceFactory.getInstance()....

2.都實(shí)現(xiàn)了缺省配置和定制配置
Shark中,缺省配置放在一個(gè)深層次的目錄中,定制配置放在config目錄,兩個(gè)配置
文件的內(nèi)容差不多;
jbpm中,缺省配置放在代碼中實(shí)現(xiàn),如下:
propertyClassNames = new HashMap();
propertyClassNames.put( "default", "org.jbpm.impl.DefaultServiceFactory" );
abbreviatedClassNames.put( "jbpm.service.factory", propertyClassNames );
定制配置放在config目錄中,為jbpm.properties
比較而言,jbpm的實(shí)現(xiàn)方式要好,理由如下:
1)缺省配置容易找到
2)定制配置很簡單,默認(rèn)是沒有配置的,比shark的要清爽很多

3.都實(shí)現(xiàn)了用一個(gè)單例實(shí)現(xiàn)多個(gè)單例
我在Shark學(xué)習(xí)系列的文章中討論過這個(gè)功能,jbpm是在JbpmConfiguration.java中實(shí)現(xiàn)的:
private void instantiateConfiguredObjects() {
    // instantiate configured objects
    this.fileMgr = (FileMgr) instantiate( "jbpm.file.mgr", FileMgr.class );
    this.idGenerator = (IdGenerator) instantiate( "jbpm.id.generator", IdGenerator.class );
    this.serviceFactory = (ServiceFactory) instantiate( "jbpm.service.factory", ServiceFactory.class );
}

     摘要: 目前我看過采用JBPM的工作流有web-console (JBPM 3.2.1自帶）、RUNA WFE、SMART,就這三個(gè)我做一個(gè)比較：

RUNA WFE

RUNA WFE是上面提到的三個(gè)中，唯一可以直接部署應(yīng)用的，當(dāng)然也有它的缺點(diǎn)，下面我會(huì)提到。這個(gè)框架采用的是Struts作為表示層，流程管理和組織架構(gòu)管理都做的不錯(cuò)，良好的國際化，文檔很全。如果只打算研究可以看下它的permission部分，它已經(jīng)實(shí)現(xiàn)了對流程查看、啟動(dòng)、結(jié)束等的權(quán)限控制，JBPM自身在這部分基本還是TODO狀態(tài)。

  閱讀全文      摘要: 研究工作流及其相關(guān)技術(shù)的人一定知道這個(gè)組織——工作流管理聯(lián)盟（簡稱WfMC，Workflow Management Coalition），其成立于1993年。作為工作流技術(shù)標(biāo)準(zhǔn)化的工業(yè)組織，WfMC提出的工作流系統(tǒng)參考模型（Reference Model）無疑為各家工作流軟件廠商的系統(tǒng)設(shè)計(jì)規(guī)劃提供了最權(quán)威的參考，乃至標(biāo)準(zhǔn)。下面就是這個(gè)參考模型：

  閱讀全文

作者:胡長城
 
        目前主要列出了13家公司，這幾家主要是做workflow的。當(dāng)然，目前國內(nèi)做OA，做Platform（包含workflow）的公司很多，但是，在workflow方面非常專注的，比較少。
        還有很多公司沒有列出來，主要是個(gè)人感覺他們在workflow這一個(gè)方面并不是非常強(qiáng)勁（可能他們的product，platform很好），比如：BOS（金蝶），EOS（普元），GK-Workflow（北京點(diǎn)擊科技），iOffice.net（廣州紅帆），KA-2（北京科諾），OW4J（Oracle中國），UAP（用友），HotOA（上海華炎），ZoTn（中唐）。還有些小型的工作流產(chǎn)品公司，產(chǎn)品并不是非常有特色，也沒有列出來，比如：WiseFlow（上海維泰），aoflow（北京奧寶）

         目前我所知道的，在國內(nèi)比較有名的國外workflow/BPM 廠商，主要有三家：Ultimus（較早進(jìn)入中國），BusinessWare（北京麒麟，美國VITRIA）,2003年進(jìn)入中國； webMethods（2003年底在北京成立辦事處)
         以下的“★”表示可workflow參考度和可研究度，越多表示產(chǎn)品在workflow這一方面更有特點(diǎn)。注：BusinessWare只給了三個(gè)“★”，是表示其所定位在解決方案和項(xiàng)目實(shí)施，整個(gè)產(chǎn)品定位在Business Process Integration層次，有些超越目前國內(nèi)市場需求。

編號
I00	★★★	AWF（北京炎黃盈動(dòng)）	嵌入式的工作流平臺，功能不是太完善，主要研發(fā)實(shí)力不足
I01	★★	DLFlo（上海東蘭）	2000就開始做工作流平臺，2002年推出了java版本。但整體來看，發(fā)展的不是很理想
I02	★★★★★	LiveFlow（上海東蘭）	和DLFlo定位差不多，都面向二次開發(fā)平臺。但是正個(gè)產(chǎn)品還是停留在“workflow”功能層次。—— 但是，吸收了DLFlo的很多經(jīng)驗(yàn)，所以其工作流平臺目前還是屬于國內(nèi)前列
I03	★★★	BusinessWare（北京麒麟遠(yuǎn)創(chuàng)）	主要方向是BPM和BPI（業(yè)務(wù)流程整合）。整個(gè)產(chǎn)品是一個(gè)“集成平臺”。
I04	★★	e-cology（上海泛微）	但從workflow這個(gè)層次來說，泛微沒有太多的特色。
I05	★★	eWay Platform（北京東方易維）	Eway的黃金時(shí)代已經(jīng)一去不復(fù)返了，自動(dòng)“馬毅”那個(gè)團(tuán)隊(duì)離開以后。工作流的一些理念當(dāng)時(shí)還是值得的，有些類似ofbiz。表單處里采用二次開發(fā)jsp頁面來處理。
I06	★★★	JKCFlow（四川金科成）	JFCFlow從早期的工作流產(chǎn)品轉(zhuǎn)移向“業(yè)務(wù)基礎(chǔ)軟件平臺”，但是整個(gè)產(chǎn)品平臺目前還只能算是，一個(gè)OA開發(fā)平臺。在workflow和model方面并不是非常的強(qiáng)
I07	★★★★	JoinWork（上海天際星）	Joinwork剛剛推出來，其開發(fā)者丁宏比較欣賞jBPM，joinwork很多思想也是參考了jBPM。但功能上稍微弱了點(diǎn)。但是其基于SWT的設(shè)計(jì)思想很值得借鑒。
I08	★★★★	Koof MetaLogic（北京世紀(jì)金政）	去年推出的workflow產(chǎn)品，專做工作流平臺，雖然主要定位于oa和電子政務(wù)平臺，但工作流這一快，還是有很多克參考的功能。
I09	★★★	RiseOffice（北京有生博大）	當(dāng)前版本riseoffice5.1，整個(gè)工作流產(chǎn)品基本上為“OA審批流程”量身定做。其表單處里和權(quán)限控制很有特色，以及審批歷程的處理。整個(gè)design端時(shí)采用web的，用的 addflow控件。
I10	★★★★★	SunFlow（杭州信雅達(dá)）	sunFlow這一兩年發(fā)展很迅速，大有趕超SynchroFlow 趨勢。 其產(chǎn)品最大的特色是采用基于域的聯(lián)邦系統(tǒng)架構(gòu)，對分布式管理、運(yùn)行支持較好。而且也是目前國內(nèi)為數(shù)不多的可以支持“仿真”的工作流系統(tǒng)。
I11	★★★★★	SynchroFlow（西安協(xié)同數(shù)碼）	基本上非常嚴(yán)格遵循了wfmc的規(guī)范，完全實(shí)現(xiàn)了interface1、interface2、interface3、interface5。 這一點(diǎn)上，SunFlow和SynchroFlow都有很多相像的地方，都遺留很多學(xué)院研究的特點(diǎn)（這兩個(gè)產(chǎn)品的最初原型都是在大學(xué)中誕生的）。
I12	★★★★★	Utimus（國內(nèi)） 上海敏照（增值代理商），上海永信（增值代理商） Ultimus上海分公司	進(jìn)入中國最早的國外工作流產(chǎn)品，整個(gè)產(chǎn)品采用邏輯的組織結(jié)構(gòu)圖，工作流系統(tǒng)支持的功能也很強(qiáng)。其比較有特色的是其“事件條件表

  作者:胡長城
今天和同事chelsea 就活動(dòng)實(shí)例狀態(tài)的實(shí)現(xiàn)思路上進(jìn)行了討論。我們兩個(gè)站在了兩個(gè)不同的角度來看待，這兩個(gè)不同的角度也正好眼下最為常見到的兩種實(shí)現(xiàn)思路：
helsea是從狀態(tài)角度來看待，當(dāng)然也完全是從state pattern的角度來思考：狀態(tài)在達(dá)到某個(gè)狀態(tài)的時(shí)候，會(huì)引起或必須引起活動(dòng)實(shí)例執(zhí)行什么操作。

而我是從活動(dòng)實(shí)例的角度來考慮，活動(dòng)實(shí)例的狀態(tài)只是活動(dòng)實(shí)例的一個(gè)屬性體，是因?yàn)槭裁葱袨椋斐闪耸裁礌顟B(tài)的結(jié)果。


 這兩種觀點(diǎn)，沒有誰對誰錯(cuò)，也沒有誰優(yōu)誰劣，兩者是站在不同的角度來分析同一個(gè)問題。其實(shí)這兩種模式在應(yīng)用中都是很普遍的，也都是能夠很好的解決問題的。不過在現(xiàn)有的workflow引擎實(shí)現(xiàn)中，基于活動(dòng)實(shí)例的角度是占絕大多數(shù)的，比如obe，shark等等。所以我受這個(gè)的影響也是比較深的。


先說說基于活動(dòng)活動(dòng)實(shí)例的角度的思路吧：



讓我下先來看看狀態(tài)類：

public final class WMActivityInstanceState extends WMObjectState {

public static final int OPEN_NOTRUNNING_INT = 0;

public static final int OPEN_SUSPENDED_INT = 1;

}

或者也可以這么表示：

public enum WMActivityInstanceState{

NOTRUNNIN(0),

SUSPENDED(1);

private int code;

private WMActivityInstanceState(int code){this.code = code;}
public int getCode(){return this.code}

}




對于活動(dòng)實(shí)例來說，狀態(tài)只是其一個(gè)屬性而已：

public class BasicActivityInstance extends BasicAttributedEntity{

private int _state;

public void setState(int state) {

_state = state; }

}

或者也可以是

Public void setState(WMActivityInstanceState state)




所以，從活動(dòng)實(shí)例的角度來看，狀態(tài)之間的關(guān)系是平行的。你可以在執(zhí)行完一些初始化的操作之后，將活動(dòng)實(shí)例的狀態(tài)設(shè)置為Initialized：當(dāng)然這個(gè)操作你必須顯示的去設(shè)置活動(dòng)實(shí)例（當(dāng)然，你可以用一些Event去處理），比如調(diào)用活動(dòng)實(shí)例的setState方法。至于為什么調(diào)用這個(gè)方法，或者此時(shí)設(shè)置的狀態(tài)是對是錯(cuò)，活動(dòng)實(shí)例并不關(guān)心。



下面再來說說基于狀態(tài)角度的思路吧，這個(gè)思路大體可以說就是state pattern的應(yīng)用。



     說道這兒，您可以看看這篇文檔：從工作流狀態(tài)機(jī)實(shí)踐中總結(jié)狀態(tài)模式使用心得 。當(dāng)然如果您對state pattern不是很了解，那么建議你先看看這篇文檔：設(shè)計(jì)模式之state 。



    State模式的著眼點(diǎn)就是狀態(tài)，以狀態(tài)的變遷影響實(shí)例的行為和動(dòng)作。其實(shí)這就是兩個(gè)不同的抽象體：state和stateOwner，我們可以看到，活動(dòng)實(shí)例對象就表現(xiàn)為stateOwner。

   State模式的依據(jù)是狀態(tài)之間是有有向連接關(guān)系的，這有向連接關(guān)系其實(shí)就是狀態(tài)的轉(zhuǎn)換規(guī)則：A-B-C-D-A。

   激發(fā)狀態(tài)的變遷，是由外界的事件（Event）影響的：這個(gè)事件會(huì)告知，當(dāng)前的活動(dòng)實(shí)例狀態(tài)要從當(dāng)前狀態(tài)往下一個(gè)狀態(tài)變遷。而活動(dòng)實(shí)例并不知道下一個(gè)狀態(tài)是什么，這完全是狀態(tài)對象負(fù)責(zé)維護(hù)和告知的。



至此，我們可以看出來了，兩種方式的不同：

第一種方式（基于活動(dòng)實(shí)例），其外界事件是影響到活動(dòng)實(shí)例，或者說在事件中顯示的告知活動(dòng)實(shí)例狀態(tài)從什么變?yōu)槭裁础?br />
第二種方式（基于實(shí)例狀態(tài)），其外界事件是影響到活動(dòng)實(shí)例狀態(tài)對象，至于這個(gè)狀態(tài)的下一個(gè)狀態(tài)是什么，時(shí)間并不知道，完全由活動(dòng)狀態(tài)之間的關(guān)系來維護(hù)。

作者:tomkoo
以下例子中 采用了jbpm console 的幾個(gè)實(shí)例用戶

項(xiàng)目提交人 : ernie .

主管審批 : bert

會(huì)簽 : ernie , bert , grover

老板審批 : grover

 

正常流程: 項(xiàng)目金額 >= 500W RMB

提交項(xiàng)目 --> 主管審批 --> 會(huì)簽 --> 老板審批 --> 審批通過(結(jié)束)

正常流程: 項(xiàng)目金額 < 500W RMB

提交項(xiàng)目 --> 主管審批 --> 會(huì)簽 --> 審批通過(結(jié)束)

其中主管審批, 會(huì)簽, 老板審批 , 不通過, 全部退回給項(xiàng)目提交人修改.

會(huì)簽中: 所有人全通過, 則通過. 任何一人不通過, 停止其他會(huì)簽任務(wù).退回給提交人.

流程定義如下:

 

會(huì)簽swimlane class

創(chuàng)建會(huì)簽任務(wù)實(shí)現(xiàn)類

 

 

 

結(jié)束不通過時(shí)結(jié)束其他會(huì)簽任務(wù)實(shí)現(xiàn)