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

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

2)xml文件方式
static ProcessDefinition auctionProcess =
      JpdlXmlReader.parseFromResource("org/jbpm/tdd/auction.xml");
注意,必須在classes的org/jbpm/tdd/目錄下有一個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>");
這種方式的本質和xml文件解析方式是一樣的.

作者:楊洪波

作者:楊洪波

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

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

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

3.都實現(xiàn)了用一個單例實現(xiàn)多個單例
我在Shark學習系列的文章中討論過這個功能,jbpm是在JbpmConfiguration.java中實現(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.都使用了單例模式
我想這個是最基本的,一般的程序員寫解析程序都會這樣使用;要說明的是,AgileFlow
除了使用單例模式,還實現(xiàn)了配置文件的動態(tài)裝載,如果用戶修改了配置文件,它能夠在
運行中動態(tài)的獲取這些變化.
使用jbpm時,第一句話就要使用該模式:JbpmServiceFactory.getInstance()....

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

3.都實現(xiàn)了用一個單例實現(xiàn)多個單例
我在Shark學習系列的文章中討論過這個功能,jbpm是在JbpmConfiguration.java中實現(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,就這三個我做一個比較：

RUNA WFE

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

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

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

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

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

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

而我是從活動實例的角度來考慮，活動實例的狀態(tài)只是活動實例的一個屬性體，是因為什么行為，造成了什么狀態(tài)的結果。


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


先說說基于活動活動實例的角度的思路吧：



讓我下先來看看狀態(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}

}




對于活動實例來說，狀態(tài)只是其一個屬性而已：

public class BasicActivityInstance extends BasicAttributedEntity{

private int _state;

public void setState(int state) {

_state = state; }

}

或者也可以是

Public void setState(WMActivityInstanceState state)




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



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



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



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

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

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



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

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

作者:tomkoo
以下例子中 采用了jbpm console 的幾個實例用戶

項目提交人 : ernie .

主管審批 : bert

會簽 : ernie , bert , grover

老板審批 : grover

 

正常流程: 項目金額 >= 500W RMB

提交項目 --> 主管審批 --> 會簽 --> 老板審批 --> 審批通過(結束)

正常流程: 項目金額 < 500W RMB

提交項目 --> 主管審批 --> 會簽 --> 審批通過(結束)

其中主管審批, 會簽, 老板審批 , 不通過, 全部退回給項目提交人修改.

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

流程定義如下:

 

會簽swimlane class

創(chuàng)建會簽任務實現(xiàn)類

 

 

 

結束不通過時結束其他會簽任務實現(xiàn)