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

作者:楊洪波
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
除了使用單例模式,還實現了配置文件的動態裝載,如果用戶修改了配置文件,它能夠在
運行中動態的獲取這些變化.
使用jbpm時,第一句話就要使用該模式:JbpmServiceFactory.getInstance()....

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

3.都實現了用一個單例實現多個單例
我在Shark學習系列的文章中討論過這個功能,jbpm是在JbpmConfiguration.java中實現的:
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
除了使用單例模式,還實現了配置文件的動態裝載,如果用戶修改了配置文件,它能夠在
運行中動態的獲取這些變化.
使用jbpm時,第一句話就要使用該模式:JbpmServiceFactory.getInstance()....

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

3.都實現了用一個單例實現多個單例
我在Shark學習系列的文章中討論過這個功能,jbpm是在JbpmConfiguration.java中實現的:
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部分，它已經實現了對流程查看、啟動、結束等的權限控制，JBPM自身在這部分基本還是TODO狀態。

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

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

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

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

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

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


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


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



讓我下先來看看狀態類：

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}

}




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

public class BasicActivityInstance extends BasicAttributedEntity{

private int _state;

public void setState(int state) {

_state = state; }

}

或者也可以是

Public void setState(WMActivityInstanceState state)




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



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



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



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

   State模式的依據是狀態之間是有有向連接關系的，這有向連接關系其實就是狀態的轉換規則：A-B-C-D-A。

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



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

第一種方式（基于活動實例），其外界事件是影響到活動實例，或者說在事件中顯示的告知活動實例狀態從什么變為什么。

第二種方式（基于實例狀態），其外界事件是影響到活動實例狀態對象，至于這個狀態的下一個狀態是什么，時間并不知道，完全由活動狀態之間的關系來維護。