摘要:   阅读全文      摘要:   阅读全文

作者:杨洪波
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”功能层次。—— 但是，吸收了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）影响的：这个事件会告知，当前的活动实例状态要从当前状态往下一个状态变迁。而活动实例并不知道下一个状态是什么，这完全是状态对象负责维护和告知的。



至此，我们可以看出来了，两种方式的不同：

第一种方式（基于活动实例），其外界事件是影响到活动实例，或者说在事件中显示的告知活动实例状态从什么变为什么。

第二种方式（基于实例状态），其外界事件是影响到活动实例状态对象，至于这个状态的下一个状态是什么，时间并不知道，完全由活动状态之间的关系来维护。