2007年11月22日
作者:杨洪波
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文件解析方式是一样的.
posted @
2007-11-22 18:02 jbpm 阅读(746) |
评论 (0) |
编辑 收藏
作者:杨洪波
作者:杨洪波
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 );
}
posted @
2007-11-22 17:59 jbpm 阅读(469) |
评论 (0) |
编辑 收藏
2007年11月11日
摘要: 目前我看过采用JBPM的工作流有web-console (JBPM 3.2.1自带)、RUNA WFE、SMART,就这三个我做一个比较:
RUNA WFE
RUNA WFE是上面提到的三个中,唯一可以直接部署应用的,当然也有它的缺点,下面我会提到。这个框架采用的是Struts作为表示层,流程管理和组织架构管理都做的不错,良好的国际化,文档很全。如果只打算研究可以看下它的permission部分,它已经实现了对流程查看、启动、结束等的权限控制,JBPM自身在这部分基本还是TODO状态。
阅读全文
posted @
2007-11-11 16:24 jbpm 阅读(2010) |
评论 (0) |
编辑 收藏
摘要: 研究工作流及其相关技术的人一定知道这个组织——工作流管理联盟(简称WfMC,Workflow Management Coalition),其成立于1993年。作为工作流技术标准化的工业组织,WfMC提出的工作流系统参考模型(Reference Model)无疑为各家工作流软件厂商的系统设计规划提供了最权威的参考,乃至标准。下面就是这个参考模型:
阅读全文
posted @
2007-11-11 16:00 jbpm 阅读(978) |
评论 (0) |
编辑 收藏
2007年10月28日
作者:胡长城
目前主要列出了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上海分公司
|
进入中国最早的国外工作流产品,整个产品采用逻辑的组织结构图,工作流系统支持的功能也很强。其比较有特色的是其“事件条件表
|
posted @
2007-10-28 12:21 jbpm 阅读(2975) |
评论 (4) |
编辑 收藏
作者:胡长城
今天和同事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)影响的:这个事件会告知,当前的活动实例状态要从当前状态往下一个状态变迁。而活动实例并不知道下一个状态是什么,这完全是状态对象负责维护和告知的。
至此,我们可以看出来了,两种方式的不同:
第一种方式(基于活动实例),其外界事件是影响到活动实例,或者说在事件中显示的告知活动实例状态从什么变为什么。
第二种方式(基于实例状态),其外界事件是影响到活动实例状态对象,至于这个状态的下一个状态是什么,时间并不知道,完全由活动状态之间的关系来维护。
posted @
2007-10-28 12:12 jbpm 阅读(700) |
评论 (0) |
编辑 收藏
2007年10月15日
作者:tomkoo
以下例子中 采用了jbpm console 的几个实例用户
项目提交人 : ernie .
主管审批 : bert
会签 : ernie , bert , grover
老板审批 : grover
正常流程: 项目金额 >= 500W RMB
提交项目 --> 主管审批 --> 会签 --> 老板审批 --> 审批通过(结束)
正常流程: 项目金额 < 500W RMB
提交项目 --> 主管审批 --> 会签 --> 审批通过(结束)
其中主管审批, 会签, 老板审批 , 不通过, 全部退回给项目提交人修改.
会签中: 所有人全通过, 则通过. 任何一人不通过, 停止其他会签任务.退回给提交人.
流程定义如下:
- <?xml version="1.0" encoding="UTF-8"?>
-
- <process-definition xmlns="urn:jbpm.org:jpdl-3.1"
- name="tc_prj_approval">
-
- <swimlane name="initiator" />
-
-
- <swimlane name="requester">
- <assignment expression="user(ernie)" />
- </swimlane>
-
-
- <swimlane name="chief">
- <assignment expression="user(bert)" />
- </swimlane>
-
-
- <swimlane name="boss">
- <assignment expression="user(grover)" />
- </swimlane>
-
-
- <swimlane name="cosinger">
- <assignment class="net.chenj.jbpm.sample.CosingerAssiHandler">
- </assignment>
- </swimlane>
- <start-state name="start">
- <task name="tc_prj_newprj" swimlane="initiator"></task>
- <transition name="to_submit" to="tc_prj_submit"></transition>
- </start-state>
- <task-node name="tc_prj_submit">
- <task name="tc_prj_submit"></task>
- <transition name="to_chiefapprove" to="tc_prj_chiefapprove"></transition>
- </task-node>
- <task-node name="tc_prj_chiefapprove">
- <task name="tc_prj_chiefapprove"></task>
- <transition name="approve" to="tc_prj_countersign"></transition>
- <transition name="disapprove" to="tc_prj_submit"></transition>
- </task-node>
- <task-node name="tc_prj_countersign" signal="last-wait"
- create-tasks="false">
- <task name="tc_prj_countersign">
- <event type="task-end">
- <action
- class="net.chenj.jbpm.sample.TaskEndCountersign">
- </action>
- </event>
-
- </task>
-
- <event type="node-enter">
- <action name="createInstance"
- class="net.chenj.jbpm.sample.CreateTaskInstanceCountersign">
- </action>
- </event>
-
- <transition name="approve" to="amount_decision"></transition>
- <transition name="disapprove" to="tc_prj_submit"></transition>
- </task-node>
- <decision name="amount_decision">
- <transition name="to_bossapprove" to="tc_prj_bossapprove"></transition>
- <transition name="to_end" to="end1"></transition>
- </decision>
- <task-node name="tc_prj_bossapprove">
- <task name="tc_prj_bossapprove"></task>
- <transition name="approve" to="end1"></transition>
- <transition name="disapprove" to="tc_prj_submit">
- <condition>#{amount >= 500}</condition>
- </transition>
- </task-node>
- <end-state name="end1"></end-state>
- </process-definition>
-
会签swimlane class
- package net.chenj.jbpm.sample;
-
- import org.jbpm.graph.exe.*;
- import org.jbpm.taskmgmt.def.*;
- import org.jbpm.taskmgmt.exe.Assignable;
-
- public class CosingerAssiHandler implements AssignmentHandler {
-
- private static final long serialVersionUID = 1L;
-
- public void assign(Assignable assignable, ExecutionContext executionContext) {
-
- String[] a = { "ernie", "bert", "grover" };
- assignable.setPooledActors(a);
- }
-
- }
-
创建会签任务实现类
- package net.chenj.jbpm.sample;
-
- import org.jbpm.graph.def.ActionHandler;
- import org.jbpm.graph.exe.ExecutionContext;
- import org.jbpm.graph.exe.Token;
- import org.jbpm.graph.node.TaskNode;
- import org.jbpm.taskmgmt.def.Task;
- import org.jbpm.taskmgmt.exe.TaskMgmtInstance;
-
- public class CreateTaskInstanceCountersign implements ActionHandler {
-
- private static final long serialVersionUID = 1L;
-
- public void execute(ExecutionContext executionContext) throws Exception {
-
- Token token = executionContext.getToken();
- TaskMgmtInstance tmi = executionContext.getTaskMgmtInstance();
- TaskNode taskNode = (TaskNode) executionContext.getNode();
- Task task = taskNode.getTask("tc_prj_countersign");
-
- tmi.createTaskInstance(task, token).setActorId("ernie");
- tmi.createTaskInstance(task, token).setActorId("bert");
- tmi.createTaskInstance(task, token).setActorId("grover");
-
- }
-
- }
结束不通过时结束其他会签任务实现
- package net.chenj.jbpm.sample;
-
- import java.util.Collection;
- import java.util.Iterator;
- import org.jbpm.graph.def.ActionHandler;
- import org.jbpm.graph.exe.ExecutionContext;
- import org.jbpm.taskmgmt.exe.TaskInstance;
- import org.jbpm.taskmgmt.exe.TaskMgmtInstance;
-
- public class TaskEndCountersign implements ActionHandler {
-
- private static final long serialVersionUID = 1L;
-
- public void execute(ExecutionContext executionContext) throws Exception {
-
-
- boolean isDisapprove = Boolean.valueOf((String) executionContext
- .getVariable("isDisapprove"));
-
- if (isDisapprove) {
- TaskMgmtInstance tmi = executionContext.getTaskMgmtInstance();
- TaskInstance ti = executionContext.getTaskInstance();
- final String actorId = ti.getActorId();
- Collection c = tmi.getSignallingTasks(executionContext);
- for (Iterator it = c.iterator(); it.hasNext();) {
- TaskInstance task = (TaskInstance) it.next();
- if (!(actorId.equals(task.getActorId())) && (!task.hasEnded())) {
- task.end("disapprove");
- }
- }
- }
-
- }
-
- }
posted @
2007-10-15 17:34 jbpm 阅读(6215) |
评论 (0) |
编辑 收藏
作者:Ni Yue
前一段时间做的一个jbpm和shark的feature对比,今天整理笔记突然又看到这张记录纸了,so post here and drop the paper.作比较的时候Shark是1.0版本,而Jbpm是2.0版本(现在已经出到3.0了)
|
Shark
|
Jbpm
|
持久层 |
Shark自己的一个ORM的方案DODS,感觉不是很好 |
大名鼎鼎的 Hibernate(Jbpm2中使用的是Hibernate 2.1,Jbpm3种使用的是Hibernate3) |
灵活性 |
Shark给人的感觉就是庞大,需要独立的运行一个工作量引擎服务 |
相对更加灵活,和OSWorkflow有的一比,也可以作为嵌入式的工作流引擎 |
后台管理 |
其实这点和上面一点有点相对应了,灵活性差其实是由于提供的功能太多的缘故,Shark自带了一个管理程序,界面虽然差了一点,但是功能满全面的 |
Jbpm2中没有提供后台的管理,Jbpm3还没怎么用过,好像是有的,不知道具体功能如何 |
流程定义的图形设计器 |
Shark使用的WfMC定义的XPDL语言定义流程,有一个JaWE来图形化定义流程,不过XPDL是在是看起来很难懂 |
Jbpm2中没有流程图形定义器,不过Jbpm3中已经有了,是基于Eclipse的一个插件,可以使用它定义Jbpm使用的JPDL,而且不仅是插件形式,后面还会出stand alone的版本 |
表单定制 |
这个Shark可以借助XPDL来进行表单定制,没看太懂就是了 |
Jbpm2不支持,原来看了Jbpm的MailList里面说在考虑Jbpm3中会加入这方面的内容,现在似乎没有看到还 |
用户模型 |
好像必须采用Shark中的用户模型 |
灵活性的体现,任意的用户模型。Jbpm3.1的roadmap里面考虑自带一个简单的用户模型供使用 |
异构系统交互 |
Shark可以开CORBA的服务,这个方面的功能很强大 |
只能通过Java和异构系统的交互似乎,Java能做的Jbpm就行 |
学习成本 |
Shark使用的XPDL很难看懂… |
相对简单 |
文档 |
感觉是一片空白,给的那几个pdf都不顶什么用,用两三个小时就全部看完了,组织的不是很好而且。相对其他的方面,这个是最大的缺点了 |
挺全面的文档,一个chapter一个chapter的,看起来也方便 |
posted @
2007-10-15 15:09 jbpm 阅读(1078) |
评论 (0) |
编辑 收藏