BlogJava-　　　　　　　　　　　　　礼物 ^_^ -文章分类-JBPM4

jBPM 4.0 解读分析

礼物 — Tue, 14 Jul 2009 05:15:00 GMT

jBPM 4.0 解读分析

by Jeff Yu(余昌)

Revision History
Revision 0.1	2009/06/29
增加了前3章的内容

1. jBPM 配置文件 (IOC)

2. jBPM PVM 架构

2.1. Environment
2.2. Service
2.3. Command and Command Service
2.4. PVM Models: ProcessDefinition, ActivityBehaviour, Transition, Event
2.5. API整体架构图

3. jBPM PVM Model(模型)解析

3.1. ActivityBehaviour(内部节点)
3.2. ExternalActivityBehaviour(外部节点)
3.3. 基本流程的实现
3.4. 事件机制 (Event and EventListener)

Bibliography

Abstract

这篇文章主要是介绍了jBPM 4.0的基础架构,以及通过一个简单的例子来让大家知道怎么应用jBPM. 为什么选择4.0版本呢?以后的主流版本应该是4.0版本的,所以直接写4.0版本的了.

1. jBPM 配置文件 (IOC)

Abstract

配置文件是jBPM里面很关键的一步,同时Configuration API可以看做是jBPM里的一个入口API,因为其他很多重要的Service,都是通过这个API,然后生成的,于是我们需要先看一下这个模块.

在默认情况下,jBPM包里有个jbpm.cfg.xml,这个就是他的配置文件,我们先看下它的内容.

这里,我们再继续看下jbpm.default.cfg.xml,看下配置文件到底是长啥样.

												
														
   
    
    
    
    
    
    
    
    
           
    
	...........

这个配置文件主要包含了"process-engine-context'和 'transaction-context'的配置.

我们知道,现在都是讲究Dependency Inject (Inversion of Control),那么,我们这里到底是哪个类来实现repository-service呢?那配置mail-session又是怎么实例化的呢? 我们先来看下jBPM的IOC实现机制.

首先是Context接口,你可以从这里存储,获得对象.它的接口很简单.

												  Object get(String key);
   T get(Class type);

  Object set(String key, Object value);

你看可以从Context中获取到组件,对于IOC容器来说，一般情况下都会提供一种加载的方式，比如从xml文件进行加载、从资源文件进行加载。

Jbpm4是通过WireParser来解析xml,然后创建并把对象存放在WireContext. WireContext这个类负责存放,提取对象,内部用一个Map来存储已经创建的对象实例,可以简单得把他看成是IOC的一个实现类. 从WireContext的javadoc,我们可以看出,他主要是跟WireDefinition, Descriptor打交道. WireContext里面包含了一个WireDefinition,而WireDefinition里面包含了一系列的Descriptor.每个Descriptor负责创建和初始化该对象. 比如我们可以看到IntegerDescriptor, FloatDescriptor, ObjectDescriptor等等. 我们来看下Descriptor的接口:

												
														
  /**
   * constructs the object.
   * @param wireContext {@link WireContext} in which the object is created. This is also the {@link WireContext} 
   * where the object will search for other object that may be needed during the initialization phase.
   * @return the constructed object.
   */
  Object construct(WireContext wireContext);

  /**
   *called by the WireContext to initialize the specified object.
   */
  void initialize(Object object, WireContext wireContext);

Descriptor对象的创建可以直接通过Java对象的实例化,比如(new IntegerDescriptor(..)),也可以通过xml的配置文件来实现.可以说我们更经常用xml来配置,所以就有了Binding的概念. Binding类最主要的任务就是把XML DOM 到Java对象的转换. Bindings是把Binding归类了一下而已. 以下是Binding的接口.

												
														
public interface Binding { 
  String getCategory();

  /** does this binding apply to the given element? */
  boolean matches(Element element);

  /** translates the given element into a domain model java object.
   * Use the parse to report problems. 
   */
  Object parse(Element element, Parse parse, Parser parser);
}

如果想看实现,我们可以看下IdentityServiceBinding, RepositoryServiceBinding等等.这里注意下,在jBPM的实现当中,WireDescriptorBinding是根据tagName来解析的. 所以,从jBPM的xml配置文件,到ProcessEngine对象的构建,是这样的一个流程.

												 jbpm.cfg.xml –>  jBPMConfigurationParser ->  Binding –>  Descriptor --> WireContext

或者更清楚的,我们可以看下下面这张图^[ ^1].

我们不妨也看下ConfigurationTest测试.

												
  public void testConfigurationServices() {
    ProcessEngine processEngine = new Configuration()
        .setXmlString(
            "" +
            "  " +
            "    " +
            "    " +
            "    " +
            "  " +
            ""
        )
        .buildProcessEngine();
    assertNotNull(processEngine);
    assertNotNull(processEngine.getExecutionService());
    assertNotNull(processEngine.getManagementService());
  }

Configuration 类是jBPM的入口,你可以从 Configuration类中创建ProcessEngine,而从ProcessEngine中获取到RepositoryService, ExecutionService, TaskService等等. Configuration类里有两个实现类,一个是JbpmConfiguration,这是默认的jBPM自带的Configuration解析器, 另外一个是SpringConfiguration,这个是jBPM和Spring的集成. 在这里,我们就只看下JbpmConfiguration的实现,在JbpmConfiguration类里,我们可以看到他是这么去调用Parser来解析xml的.

												
 protected void parse(StreamInput streamSource) {
   isConfigured = true;
   JbpmConfigurationParser.getInstance()
     .createParse()
     .pushObject(this)
     .setStreamSource(streamSource)
     .execute()
     .checkErrors("jbpm configuration " + streamSource);
 }

在这里,我们可以看到,jbpm的配置文件是有两个元素组成的,一个是process-engine-context,另外一个是transaction-context. 其中process-engine-context里面的元素是包括了对外发布的服务, 比如repository-service, execution-service等等. 而transaction-context则包括了他的内部真正实现,比如repository-service对应repository-session. 也可以简单的把repository-servie看做是API, repository-session看做是SPI. 这样做的好处是,SPI的实现,对API一点影响都没有,很大程度上提供了一个容易集成的特性.

说到这里,应该对jBPM的IOC介绍的差不多了.我自己在用JBoss IDM project^[2]来实现jBPM的Identity module时.需要增加如下的配置.

于是,我需要增加以下的类来完成对象的创建和实例化. JbossIdmIdentitySessionFactoryBinding,JbossIdmIdentitySessionFactoryDescriptor,JbossIdmIdentitySessionBinding, JbossIdmIdentitySessionDescriptor 然后,在jbpm.wire.bindings.xml里面注册我们新加的Binding. 从上面我们所说的,不难看出本身这个IOC的实现机制也是很简单的,而且也很容易扩展,如果说到时候和Spring, JBoss MC等IOC容器的集成也是很方便的.

2. jBPM PVM 架构

这里,我们看下jBPM-PVM概念和架构,这也是jBPM整个项目的核心所在.

PVM (Process Virtual Machine), 主要是想作为一个开发平台,在这个平台上,可以很方便的开发工作流,服务编制(orchestration),BPM等等.就比如说jPDL这套语法的内部实现就是基于PVM的.将来基于PVM可以开发一个符合WS-BPEL 2.0的模块. PVM可以简单的看成是一个状态机. 我们接下去看下jBPM里面的几个重要概念.

2.1. Environment

Environment 的概念,主要有以下的作用.

使process能在不同的环境下之行,比如可以在标准的Java, 企业级Java,Seam 或者 Spring 环境下运行.
他可以存放着不同的context对象,比如我们之前所看到的配置文件中的process-engine的Context, transaction的Context等.

在代码中,我们想获得其他的组件时,或者变量时,我们总是使用Environment的API, 我们可以看下它的API的几个重要方法.

														   	  public abstract  T get(Class type); 
	  /** searches an object based on type.  The search doesn take superclasses of the context elements 
	   * into account.
	   * @return the first object of the given type or null in case no such element was found.  
	   */
	  public abstract  T get(Class type, String[] searchOrder);

Environment 内部是使用Map来保存不同的Context对象, Environment对象的创建主要是有EnvironmentFactory来负责. Environment是被保存在ThreadLocal中,如果有多个Environment,那么是选择把Environment(s)放在一个堆栈中,然后再存放在ThreadLocal里.

2.2. Service

Service就是PVM对外发布的服务,包括RepositoryService(比如部署jpdl文件),ExecutionService(负责管理执行),TaskService,ManagementService等等.可以说这是给用户调用的API.比如我们看下他们的一些方法. RepositoryService接口的一些方法:

														public interface RepositoryService {
  NewDeployment createDeployment();
  ProcessDefinitionQuery createProcessDefinitionQuery();
  ...
}

ExecutionService的一些方法:

														public interface ExecutionService {
  ProcessInstance startProcessInstanceById(String processDefinitionId);
  ProcessInstance signalExecutionById(String executionId); 
  ...
}

ManagementService的接口:

														public interface ManagementService {
  void executeJob(long jobDbid);
  JobQuery createJobQuery();
}

2.3. Command and Command Service

Command 概念的引入,主要是想对所有的操作做一个封装. 可以说上面每个Service的方法的实现都是通过实现一个Command来操作,然后通过CommandService调用到后面具体的实现. 我们先来看下Command的接口.

														public interface Command extends Serializable {
  T execute(Environment environment) throws Exception;
}

很简单,很典型的Command模式.

我们接下来看CommandService接口,顾名思义,他主要是负责来执行Command(s)的操作.所以其他Service的实现都是通过CommandService来调用到后面的实现,可以把CommandService 看做一个桥梁的作用.看一下CommandService的接口.

														public interface CommandService {
  /**
   * @throws JbpmException if command throws an exception.
   */
   T execute(Command command);
}

CommandService 还有一个特性,就是可以配置Interceptor,比如事务就是在这一Service中来配置.看下CommandService的配置.

这里,在执行真正的CommandServiceImpl之前,会先之前retry-Interceptor,environment-interceptor等等.这里的Interceptor的顺序是跟配置的顺序一致的. 比如这样的配置,那就是retry-interceptor在environment-interceptor之前执行. 我们看下面这个图.

Tip

可以说CommandService是最适合处理横截面(cross-cutting)的问题,比如事务,安全等的. CommandService默认下是DefaultCommandService,如果是在使用ejb的情况下, 它的实现类就是EjbLocalCommandService和EjbRemoteCommandService类. 所以,这里是远程调用,还是本地调用,对用户而言,都是透明的.

retry-interceptor的主要作用当碰到StaleObjectException(也就是optimistic locking失败)时,过一定的时间后再尝试.
environment-interceptor的主要作用就是,保证command是在Environment范围内执行,也就是在执行command之前,openEnvironment,执行之后,closeEnvironment.
standard-transaction-interceptor的主要作用就是处理事务.
authorization-interceptor,主要是处理权限校验.

2.4. PVM Models: ProcessDefinition, ActivityBehaviour, Transition, Event

ProcessDefinition是一个定义好的工作流程. OpenProcessDefinition里面包含了启始的Activity. 流程的走向是通过Activity的流向来组成的. Transition就是用来连接Activity而后来构成一个流程的. 一个工作流的工作引擎,最基本的两个功能:一个是设计好当前的工作流程.第二个是有个东西需要来体现当前走到流程的哪一步,那么PVM中的Execution API就是这个作用. 至于最后一个Event,就是你可以定义一些事件,比如当流程进入到某一个Activity的时候,促发email. Event和Activity最大的区别在于Event本身不会构成对流程走向的改变.

我们先看下ActivityBehaviour的接口.

														public interface ActivityBehaviour extends Serializable {
  void execute(ActivityExecution execution) throws Exception;
}

就是到这个Activity,需要执行的操作都在execute方法里. 还有一种ActivityBehaviour,就是属于wait state,也就是会停留在这个节点上, 需要外部的一些触发,才会继续执行下去,这种情况,需要实现的接口就是ExternalActivityBehaviour, 接口如下.

														public interface ExternalActivityBehaviour extends ActivityBehaviour { 
  //handles an external trigger.  
  void signal(ActivityExecution execution, String signalName, Map parameters) throws Exception;
}

Wait State (也就是实现ExternalActivityBehaviour)的促发,是通过Transition来完成的,来看下Transition这个接口.

														public interface Transition extends ObservableElement {
  /** the activity from which this transition leaves. */
  Activity getSource();

  /** the activity in which this transition arrives. */ 
  Activity getDestination();
}

在pvm中,也包括了对event的支持,event的接口如下.

														public interface EventListener extends Serializable { 
  void notify(EventListenerExecution execution) throws Exception;
}

如我们之前所说的, ProcessDefinition是由Activity,Transition以及Event组成的,ProcessDefinition是由ProcessDefinitionBuilder 的API来创建.我们稍微看下这个API的使用.

																ClientProcessDefinition definition = ProcessDefinitionBuilder.startProcess("jeffProcess")
											 .startActivity("initial", new AutomaticActivity())
											 .initial()
											 .transition("first")
											 .endActivity()
											 .startActivity("first", new WaitStateActivity())
											 .transition("end", "endSignal")
											 .endActivity()
											 .startActivity("end", new AutomaticActivity())
											 .endActivity()
											 .endProcess();

Tip

这里,我们注意到返回的是ClientProcessDefinition,那么他和ProcessDefinition的区别在哪儿呢? ClientProcessDefinition是继承ProcessDefinition,他还包括了一些负责创建和启动ProcessInstance的方法. 类似的,你会发现有ClientProcessInstance和ProcessInstance接口,他们的区别也是ClientProcessInstance多了负责启动的start方法.

2.5. API整体架构图

我们最后从整体上来看下这些API之间的联系,我觉得Developer Guide上的这个图片很清楚的描述了他的架构思路. 这里需要注意的是,本身PVM内部的流程定义模型是POJO的,所以如果你只是想测试流程的正确性,你只需要直接使用Client的API,比如ClientProcessDefinition, ClientProcessInstance等的API. 不需要去调用RepositoryService, ProcessEngineService. 这些Service是针对你把ProcessDefinition在保存在数据库的情况下才需要用的.

3. jBPM PVM Model(模型)解析

这里,我们将利用PVM所提供的Model,来实现一个基本的工作流引擎.

3.1. ActivityBehaviour(内部节点)

正如我们之前所说的,ActivityBehaviour是整个流程的定义核心所在,我们再看下它的API.

														public interface ActivityBehaviour extends Serializable {    
  void execute(ActivityExecution execution) throws Exception;
}

当之行到ActivityBehaviour的时候,整个流程的走向完全是由他的execute()方法来决定. 比如你可以调用execution.end()来结束这个流程,或者调用execution.waitForSignal()进入一个等待状态. 我们接下去来实现一个很简单的ActivityBehaviour.

														public class Display implements ActivityBehaviour {
  String message;

  public Display(String message) {
    this.message = message;
  }

  public void execute(ActivityExecution execution) {
    System.out.println(message);
  }	  
}

隐式(implicit)的execute方法执行顺序

如果我们在execute()方法中,没有显示的调用execution中的方法,比如waitForSignal(),take(transition)等方法,那么默认的顺序是这样的.

如果当前的节点有默认的outgoing transition,那么就调用这个默认的transition.
如果当前的节点有父节点,那么就调用到父节点.
最后,如果都没有,那就调用execution.end()方法.

我们先用这个Display,来创建下面的process.

Figure 1. Display example process

														ClientProcessDefinition processDefinition = ProcessDefinitionBuilder.startProcess("helloworld")
							 .startActivity("a", new Display("Hello"))
							 .initial()
							 .transition("b")
							 .endActivity()
							 .startActivity("b", new Display("World"))
							 .endActivity()
							 .endProcess();

然后,你调用

														processDefinition.startProcessInstance();

就会得到如下的结果

														Hello
World

我们这个Display的节点就是采用的隐式execution执行方法.

Tip

细心的你会发现,我们在定义Process Defintion的时候,总是要在调用一个initial()方法. 这是设定当前这个节点为流程的启始节点.

3.2. ExternalActivityBehaviour(外部节点)

外部节点就是代表着,这个活动还需要系统外部的配合,比如说人工的配合才能使得这个流程继续下去.我们一般称这种的节点为 Wait State. 因为他需要一直等待,直至外部活动的促发,然后流程才继续. 这种的节点需要实现ExternalActivityBehaviour的API.

														public interface ExternalActivityBehaviour extends ActivityBehaviour { 
  //handles an external trigger.  
  void signal(ActivityExecution execution, String signalName, Map parameters) throws Exception;
}

跟内部节点类似,执行到ExternalActivityBehaviour的时候,也是执行它的execute()方法,但是一般来说,在外部活动的execute()方法中, 会调用execution.waitForSignal()方法,使得activity进入一个等待状态. 直到外部调用signal()方法来使得流程再次从等待状态变成激活.一般来说在signal()方法中,会调用execution.take(signalName)根据signalName(也就是transition name)去找到下一个节点,然后把整个流程走到下一个节点.

很简单的一个例子是,比如说一个申请审批的流程,员工递交一份申请上去,然后继续就进入一个wait state的状态,因为他需要经理的审批(也就是一个人工的活动),那么经理可以选择一个ok的signalName,使得整个流程进入到下一个节点,这里就好比如是结束的节点,又或者使得整个流程直接结束.

我们接下来实现一个简单的WaitState,实现ExternalActivityBehaviour的接口.

														public class WaitState implements ExternalActivityBehaviour {

  public void execute(ActivityExecution execution) {
    execution.waitForSignal();
  }

  public void signal(ActivityExecution execution, 
                     String signalName, 
                     Map parameters) {
    execution.take(signalName);
  }
}

一样的,我们来看一个简单的从a->b的流程.这次不同的是,a和b都是wait state.

Figure 2. The external activity example process

ProcessDefinition的定义

														ClientProcessDefinition pd = ProcessDefinitionBuilder.startProcess("helloworld")
							 .startActivity("a", new WaitState())
							 .initial()
							 .transition("b", "b-transition")
							 .endActivity()
							 .startActivity("b", new WaitState())
							 .endActivity()
							 .endProcess();

启动这个ProcessDefinition

														ClientProcessInstance instance = pd.startProcessInstance();
instance.isActive("a")

在启动之后,因为执行到a的时候,是一个wait state,所以,当前的流程活动应该是指向a. 如果要到b这个activity,那么就需要调用

														instance.signal("b-transition");
instance.isActive("b")

那么,你就会发现,经过我们调用signal方法,instance根据所提供的transitionName (b-transition),找到下一个节点,也就是b. 但因为b也是一个wait state,所以此刻,整个流程就停留在了b节点身上.

3.3. 基本流程的实现

接下来,我们基于前面两种节点的实现,来实现一个稍微比较正式的流程(loan process).

Figure 3. The loan process

ProcessDefinition的定义

															ClientProcessDefinition pd = ProcessDefinitionBuilder.startProcess("loanprocess")
								 .startActivity("submit loan request", new Display("submit a loan request"))
								 .initial()
								 .transition("evaluate", "evaluate-transition")
								 .endActivity()
								 .startActivity("evaluate", new WaitState())
								 .transition("wiremoney", "approve")
								 .transition("end", "reject")
								 .endActivity()
								 .startActivity("wiremoney", new Display("wire the money"))
								 .transition("archive")
								 .endActivity()
								 .startActivity("archive", new WaitState())
								 .transition("end", "done")
								 .endActivity()
								 .startActivity("end", new WaitState())
								 .endActivity()
								 .endProcess();

启动这个processInstance

														instance = pd.startProcessInstance();

启动这个processInstance后,它开始点在submit loan request这个节点,后面经过Display这个节点,默认走到了evaluate这个节点. 因为evaluate是个wait state,所以流程停在了evaluate.

Figure 4. Execution positioned in the 'evaluate' activity

现在呢, evaluate这个节点有两条支路,一个是approve,指向wiremoney节点;另外一个是reject,直接走向end. 假设我们选择approve这条支路.

														instance.signal("approve");

那么,我们就走向了wiremoney这个节点,因为wiremoney是个Display节点,所以它显示完后,默认的走向下一个节点,archive.

Figure 5. Execution positioned in 'archive' activity

同样的,因为archive节点是个wait state,所以需要再一次的signal,才能走到end这个节点.

														instance.signal("done");

这样的话,整个流程就会走向了end节点.

Figure 6. Execution positioned in the 'end' activity

3.4. 事件机制 (Event and EventListener)

事件的订阅可以通过实现EventListener来实现.

														public interface EventListener extends Serializable {
  void notify(EventListenerExecution execution) throws Exception;
}

Event概念的引入,主要是为了弥补分析员(Business Analyst)和开发人员(Developer)之间的不同需求. developer可以使用Event在一些节点上来做一些操作(比如说操作数据库),这样呢,也不会影响整个流程,所以分析员不用去关心这些具体的Event, 他们只需要看流程是否跟他们所期望的是一致的.

具体的Event是由ObservableElement和EventName来构成的.

														public interface EventListenerExecution extends OpenExecution {
void fire(String eventName, ObservableElement eventSource);
}

我们来实现一个简单的EventListener, 叫PrintLn

														public class PrintLn implements EventListener {

	String message;

	public PrintLn(String message) {
		this.message = message;
	}

	public void notify(EventListenerExecution execution) throws Exception {
		System.out.println(message);
	}
}

Figure 7. The PrintLn listener process

我们看下是怎么来定义一个具备有Events的ProcessDefinition:

														ClientProcessDefinition pd = ProcessDefinitionBuilder.startProcess("ab")
							 .startActivity("a", new Display("Testing Event"))
							 .initial()
							 .transition("b")
							 .startEvent(Event.END)
							 .listener(new PrintLn("leaving a"))
							 .listener(new PrintLn("second message while leaving a"))
							 .endEvent()
							 .startEvent(Event.TAKE)
							 .listener(new PrintLn("taking transition"))
							 .endEvent()
							 .endActivity()
							 .startActivity("b", new WaitState())
							 .startEvent(Event.START)
							 .listener(new PrintLn("entering b"))
							 .endEvent()
							 .endActivity()
							 .endProcess();

我们可以看到,一个事件可以有无穷多个的Listener(s).

至此,我们主要看了PVM里面内部Model的一些设计,一些核心的概念和API.

Bibliography

^[1]图来自于http://www.blogjava.net/RongHao/archive/2009/05/07/269465.html

^[2] http://www.jboss.org/jbossidentity

礼物 2009-07-14 13:15 发表评论

jBPM4的运行期环境

礼物 — Tue, 14 Jul 2009 05:13:00 GMT

jBPM4的运行期环境

        万物生长靠太阳，儿童的生长离不开土壤、空气和水，当然，也离不开绿坝娘的调教。应用程序也是如此，离不开数据库连接、事务、日志、消息等，这些，共同构成了应用程序的运行期环境。
        理想中的环境是什么样子的哩。好吧，一句话，召之即来，挥之即去，当需要某个服务时，ok，打个响指，该服务就准备好被调用了，调用完毕后也不用费心费力地擦屁股，不必老是提心吊胆有好事者追问：你擦了吗，确定擦了？真的确定擦了？直接丢弃给环境降解处理，自然又环保，还有个好名声叫专注领域逻辑。

一、    运行期环境就是一个餐馆
1、    提供必要的服务
作为一个餐馆，必须有厨师做饭我吃，必须有桌子和椅子。作为运行期环境同样如此，我要发消息，你得提供我发消息的Service，我要获取节点任务，你得扔给我TaskService。

2、    提供获取这些服务的统一方式
好吧，我不会亲自到厨房告诉厨师我想吃什么（因为我担心这样一来我会吃不下去），我也不会亲自到收银台给钱。这些服务有一个统一的获取方式：服务员。我想吃什么和结账，告诉服务员即可。关键是这一方式要统一，要足够简单。Spring最懒，把服务给你全部注入了，当然你也可以握住BeanFactory的纤纤细手，一个一个的get。

3、    提供特定于我线程不安全的服务
我点了一盘鱼香肉丝，隔壁也点了一盘鱼香肉丝，结果服务员让我们吃同一盘鱼香肉丝。我立刻跳起来：靠，你们的服务不是线程安全的吗？！Hibernate 的Session正是属于这么一种情况，需要环境进行隔离，我的唯一职责就是吃饭！我的领域逻辑是如何优美的进餐！为此还要不断重构我吃饭的姿势哩。
好不容易吃完饭，付完款，正准备离场。服务员风度翩翩地走到我的身旁，我以为还有打折券供应，结果是：服务员小姐轻启朱唇：先生，麻烦您把吃剩的盘子清洗完毕。
崩溃！
像数据库连接的打开，关闭、事务的打开、提交等都属于运行期环境应该做的事情。

4、    其他的七七八八
杂事不少，例如统一的事件机制、权限拦截等等。

二、    jBPM4的运行期环境
好吧，先来看看如何建立jBPM4的运行期环境：

EnvironmentFactory environmentFactory = new DefaultEnvironmentFactory();



  Environment environment = environmentFactory.openEnvironment();
  try {

     everything available in this block

  } finally {
    environment.close();
  }

两个关键的类：EnvironmentFactory和Environment。

EnvironmentFactory是全局的，在整个应用程序中保持一个实例即可。

Environment则是每次方法调用则要new一个。

看看Environment的主要方法：

public abstract Object get(String name);
public abstract <T> T get(Class<T> type);

是的，environment为我们的代码提供所需要的服务类实例。

那么，如何获得environment？
继续看：

public static Environment getCurrent()；

static，我喜欢也。方便、快捷，不管是在地上、车上还是房顶上，随处都可调用。

那么，为什么Environment每次调用要new呢？
好吧，当你需要获取数据库Session的时候，是不是每次都要new呢。Environment提供的服务里包括了非线程安全的数据库操作服务。

三、 jBPM4运行期环境的实现

1、JbpmConfiguration
JbpmConfiguration是jBPM4里最重要的类，它是整个应用程序的入口。它实现了EnvironmentFactory接口。

JbpmConfiguration加载jBPM总的配置文件，还是大概扫一下这个配置文件：

      <jbpm-configuration xmlns="http://jbpm.org/xsd/cfg">

  <process-engine-context>

    <repository-service />
    <repository-cache />
    <execution-service />
    <history-service />
    <management-service />
    <identity-service />
    <task-service />

    <hibernate-configuration>
      <cfg resource="jbpm.hibernate.cfg.xml" />
    hibernate-configuration>

    <hibernate-session-factory />

  process-engine-context>

  <transaction-context>
    <repository-session />
    <pvm-db-session />
    <job-db-session />
    <task-db-session />
    <message-session />
    <timer-session />
    <history-session />
  transaction-context>

jbpm-configuration>

配置文件被分为了两部分，分别是：process-engine-context和transaction-context。
对应于两个IOC容器（WireContext）的配置文件。

作为EnvironmentFactory，JbpmConfiguration持有成品process-engine-context对应的IOC容器（全局的）实例，持有半成品transaction-context的WireDefinition。当调用openEnvironment方法时，JbpmConfiguration会new Environment，然后将process-engine-context IOC填充入environment，同时初始化transaction-context IOC，并将其也填充入environment。这样通过environment就可以获得所有所需要的服务，包括全局的和非线程安全的服务实例。也就是 environment透过IOC容器提供了查找各种服务的能力。

2、与线程绑定的environment
environment初始化之后,避免参数传递得一塌糊涂的方式就是将environment与线程绑定。看Environment的代码：

static ThreadLocal<Environment> currentEnvironment = new ThreadLocal<Environment>();

static ThreadLocal<Stack<Environment>> currentEnvironmentStack = new ThreadLocal<Stack<Environment>>();

是的，在openEnvironment时，有这么一行代码：

Environment.pushEnvironment(environment);

这样environment就与线程绑定了，可以通过Environment.getCurrent()任意调用了。

哪里有压迫，哪里就有放抗。
在environment.close()方法里：

Environment.popEnvironment();

OK，结束。

礼物 2009-07-14 13:13 发表评论

Jbpm4的IOC容器

礼物 — Mon, 13 Jul 2009 02:34:00 GMT

和Jbpm3一样，Jbpm4实现了自己的IOC容器。以现在的眼光看来，应用程序里一个IOC容器几乎是居家必备的，否则，又要平白多出一坨一坨的工厂类和单态类来。

一、 Jbpm4 IOC容器介绍
IOC容器的目的是管理组件和实现组件之间的解耦。和Spring里的BeanFactory对应，Jbpm4里的接口是Context，具体实现则是 WireContext。Context实际在Jbpm4里有更多的含义，它与Environment一起，共同构成了代码运行的运行期环境。在这个环境里可以获取系统的组件，更为重要的是提供了数据库连接（session）和事务（这个稍后会讲）。

先来看看Context接口的核心方法：

Object get(String key);
<T> T get(Class<T> type);

很明显，提供两种从容器里获取组件的方法，一种是通过name，一种是通过type。

对于IOC容器来说，一般情况下都会提供一种加载的方式，比如从xml文件进行加载、从资源文件进行加载。Jbpm4透过WireParser具备从xml加载的能力。

此外，WireContext通过一个Map缓存初始化后的组件。

二、 Jbpm4 IOC容器实现
容器的实现有五个关键类和接口，分别是：WireParser、Binding、Descriptor、WireDefinition和WireContext。

WireParser读取xml文件，同时WireParser会加载一系列的Binding(默认从jbpm.wire.bindins.xml文件读取加载)。

Binding负责根据xml里元素的tag将xml元素转换为对应的Descriptor。

Descriptor负责初始化对象。它们被添加到WireDefinition。

WireDefinition被WireParser返回给WireContext。WireContext创建对象时会访问WireDefinition里的Descriptor，同时将初始化对象的任务委托给Descriptor自身。

需要注意的是：Jbpm4在初始化对象时有着四种策略，分别是：延迟创建和初始化、延迟创建和立刻初始化、立刻创建和延迟初始化、立刻创建和立刻初始化。

立刻创建：在WireContext创建完毕后对象就已经创建。
延迟创建：调用WireContext的get方法获取该对象时才创建该对象。
初始化：一般完成对象属性的注入等操作。

三、 Jbpm4 IOC容器在Jbpm4里的应用
IOC容器在Jbpm4里最重要的作用就是加载Jbpm的总的配置文件（默认是jbpm.cfg.xml），这也是整个Jbpm应用的起点。大概扫一下这个配置文件：

xml version="1.0" encoding="UTF-8"?>

<jbpm-configuration xmlns="http://jbpm.org/xsd/cfg">

  <process-engine-context>

    <repository-service />
    <repository-cache />
    <execution-service />
    <history-service />
    <management-service />
    <identity-service />
    <task-service />

    <hibernate-configuration>
      <cfg resource="jbpm.hibernate.cfg.xml" />
    hibernate-configuration>

    <hibernate-session-factory />

  process-engine-context>

  <transaction-context>
    <repository-session />
    <pvm-db-session />
    <job-db-session />
    <task-db-session />
    <message-session />
    <timer-session />
    <history-session />
  transaction-context>

jbpm-configuration>

可以看到配置文件被分为了两部分，分别是：process-engine-context和transaction-context。在实际应用中，它们分别对应着两个不同的WireContext:ProcessEngineContext和TransactionConext。 ProcessEngineContext覆盖了jbpm4里最重要的服务类，这些类是全局唯一的，当然，ProcessEngineContext也是独此一份。本是同根生，命运各不同。TransactionConext则是在每次openEnvironment时重新创建，因为其包含了数据库连接和事务。

贯穿于整个Jbpm4中，这两个Context被压到Environment里（Environment和线程绑定），在任何需要的地方都能提供一条龙的服务。于是，在很多领域类里，利用这些服务实现充血模型就是很顺理成章的一件事了。

总结: ProcessEngineContext给引擎领域模型提供全局的组件查找；TransactionConext提供数据库相关服务。

礼物 2009-07-13 10:34 发表评论

jBPM4任务管理：参与模式一瞥

礼物 — Mon, 13 Jul 2009 02:32:00 GMT

原文地址：http://www.jboss.org/feeds/post/jbpm_task_management_a_look_at_the_participation_model

jBPM 任务管理：参与模式一瞥
Posted on 2009-03-30 09:41:00.0 by Heiko Braun
Since 4.0.0 Beta1
重新回顾jBPM中的任务管理模型，引进了一个新的概念：任务参与。参与模型描述了identies（用户或组）和任务在实际完成中的参与类型：

示例1：用户和业务管理员参与
在此与这个模型非常适合的一个通常的案例是在一个实际执行任务的用户和一个业务管理员监控进展情况之间的区别。依赖于参与类型，某些规则将实际起作用，而其它的将确保任务在给定的约束内被执行（例如，优先级，预定日期等）。

示例2：具有不同的参与类型的任务利益相关者
另一个例子可能是利益相关者监控任务的实际输出，或者是在一个任务上互相协作的不同参与者之间的委托。在这个案例中，一个任务的发起人，一个候选人执行这个工作并且最终的与受者可能是不同的参与类型。

The TaskService API已经反映了那些变化：

				
						
								org.jbpm.TaskService{
						
						
								 
						
						
								
										[...]
						
						
								 
						
						
								
										/**
								
						
						
								
										   * retrieves a list of tasks for a user
								
						
						
								
										   * and a particular {@link org.jbpm.task.Participation} type
								
						
						
								
										   *
								
						
						
								
										   * @see org.jbpm.TaskQuery
								
						
						
								
										   */
								
						
						
								 
						
						
								
										
												List
										 findTasksByParticipation(String participation, UserRef user);
						
						
								 
						
						
								
										/**
								
						
						
								
										   * retrieves a list of tasks for a group
								
						
						
								
										   * and a particular {@link org.jbpm.task.Participation} type
								
						
						
								
										   *
								
						
						
								
										   * @see org.jbpm.TaskQuery 
								
						
						
								
										   */
								
						
						
								 
						
						
								
										
												List
										 findTasksByParticipation(String participation, GroupRef... groups);
						
						
								 
						
						
								
										}

目前，我们封装了一些默认的参与类型，其中仅仅支持“候选人”模型，但是你可以期待这些将在不久的将来被扩展实现。

				
						
								org.jbpm.task.Participation{
						
						
								
										[...]
						
						
								
										
												String
										 CANDIDATE = "candidate";
						
						
								IdentityRef getIdentityRef();
						
						
								
										/** see constants for default participations */
								
						
						
								
										
												String
										 getType();
						
						
								
										}

敬请期待。

礼物 2009-07-13 10:32 发表评论

jBPM4管理控制台一瞥

礼物 — Mon, 13 Jul 2009 02:29:00 GMT

JBoss已经发布了jBPM4 Alpha1版本，而2008年12月，Red Hat发布公告，已经与google签署了团体共享协议，正式采用GWT作为JBoss中间件核心组成部分，而jBPM4也作为整个JBoss SOA治理体系的核心项目。Heiko Braun在JBoss SOA 治理项目的博客（http://jboss-overlord.blogspot.com/）上给出了基于GWT的jBPM4的管理控制台一瞥。下面是我的翻译：

新的 BPM 控制台已经发布了第一个里程碑，我很高兴利用这个机会介绍它最重要的改变及新特性。

流程定义管理

迁移到 GWT

越来越多的 JBoss 项目正在迁移到 GWT 。他们这么做的原因是：

Ø 如果你熟悉 Java 的开发并且不想成为下一代 web 开发的专家，那么 GWT 是一个比较好的选择。使用 GWT 你可以粘住 eclipse ，发动一个调试并且编写单元测试；

Ø 它有一套丰富的 UI 窗口部件，你可以立马使用。这种窗口部件通过自己的实现保证了一个统一的外观和感觉；

其它的比较好的成功的 GWT 实施的例子就是 Drools 控制台了。（ JBoss 开源的规则引擎）。

流程实例管理

GWT 已经非常的流行了，它允许通过项目来集成控制台。另一方面的影响就是，你可以轻松地开发一个完整的 GWT 应用，或者是一部分，并且同已经存在的 web 应用整合在一起。举例来说，这样可以允许用户将 BPM 控制台的任务管理功能嵌入到他们自己的内网应用中。

流程实例细节

BAM （业务活动监控）及 BI （商业智能）功能的改进

或许当前控制台的最大缺点就是缺少 BAM 和 BI 特性。

工作负载概览

改进 BAM 和 BI 不可能在一天内马上实现，但是你可以期待在早期的发布版本中看到第一个度量及状态监控，在我们实现一个功能齐全的 BAM 控制台的过程中，我们正尽力增加更多的零星的功能。因为这将与服务活动监控项目中的功能和技术发生重叠，感兴趣的读者可以关注一下 SAM 。

性能度量

如何迁移

首先，我们将基于 GWT 提供一个现存 jBPM 控制台的替代。它将仍然保持当前的功能特性，但是会增加 BI 功能。最初我们会平衡 jBPM3 的后端功能，然后逐渐地利用 SAM 的空间来丰富它，甚至最终完全代替它。

流程图形视图

继续关注。下次我们将要详细说明实现细节，包括： gchart ， gwt 和 gwt-ext 。

说明：此文英文链接：http://jboss-overlord.blogspot.com/2008/08/first-glimpse-at-new-bpm-console.html

礼物 2009-07-13 10:29 发表评论

jbpm3与jbpm4实现对比

礼物 — Mon, 13 Jul 2009 02:18:00 GMT

jBPM3 vs jBPM4

JBoss Goup 目前已经发布了 jBPM4 Alpha1 版本，在版本 4 中最大的变化就是引入 PVM （流程虚拟机）的概念，而引擎内部的调度算法中重要的 Token 机制，在新版中也去掉了，纵观整个代码，变化可以说非常的大，笔者接下来就试着来比较一下这种变化，让大家能有个直观的认识。当然 Jbpm4 在 JBoss 的官方网站上的 Road map 中，在今年的 7 月 1 号才会发布第一个正式版本，因此后续可能还会有变化。

1、流程定义对象的变化：

Jbpm3 流程定义对象关系图：

图一 jbpm3流程定义对象关系图

从上图我们可以看出这 jbpm3 中， GraphElement 是流程图中所有流程元素的父对象，而整个流程是由 ProcessDefinition 、 Node 、 Transition 三个主要对象构成；

图二 PVM实体对象关系图

从上图可以看出，由于 PVM 概念的引入，所以在 jbpm3 中的 Graph 包在 jbpm4 中被移除了。在 pvm 中，在设计期，所有节点元素的父类为 ProcessElementImpl ，流程的主要组成元素 Nodelmpl 、 TransitionImpl 、 ProcessDefinitionImpl 、 EventImpl 则都直接或间接继承自 ProcessElementImpl 。在运行期： jbpm4 把流程的运行期行为定义为执行行为（ ExecutionImpl ）及原子操作行为（ AtomicOperation ，其具体实现为 ExecuteNode 、 ProceedToDestination 、 TakeTranstion 、 MoveToParentNode 、 MoveToChildNode 、 signal ），其中 ExecutionImpl 是流程实例、活动实例、事件监听器的所有执行期行为的实现类。

图三 jpdl 运行期活动实体对象关系图

上图是 jbpm4 在运行期的活动实例对象关系图，从图中我们可以看出，在运行期， jbpm4 中定义了两个活动接口 Activity 和 ExternalActivity ，其中 ExternalActivity 继承自 Activity 。 Activity 是所有自动活动节点的父接口，其实现类为 JpdlActivity ，而 JpdlActivity 又衍生出了、 StartActivity 、 JoinActivity 、 ForkActivity 、 EndActivity 、 CreateTimerActivity 、 JavaActivity 、 EsbActivity 等实例活动对象。而 ExternalActivity 是具有等待状态的活动（ StateActivity ）父接口，像人工活动 TaskActivity 就是实现了此接口。

2、核心引擎的调度算法

Jbpm3 的核心调度算法是基于 Token 机制的，在运行期这个 Token 在 Node Instance 之间流转，依靠 Token 的触发来推进流程。具体的调度机制，可参加胡长城的文章（ http://blog.csdn.net/james999/archive/2007/09/02/1769592.aspx ）；其实这个 Token 来自于 Pertri-net ，感兴趣的读者可以去看 Pertri-net 中的 Token 及 Place 。

图四 jbpm3引擎调度图

Jbpm4 则去掉了 Token ，那么它的核心调度机制是怎样实现的呢？

图五 jbpm4流程启动序列图

图六 jbpm4 流程推进序列图

图五是在 jbpm4 中启动一个流程实例的执行序列图，图六是节点推进的执行序列图，从上面两个图中我们可以看到核心的调度是依据 Execution 的转移来实现的（ ExecutionImpl 可以是 ActivityExecution 、 ClientProcessInstance 、 EventListenerExecution 的实例）， Execution 实际上就是取代了 Jbpm3 中的 Token ， Execution 的转移实际上就是根据状态机的变迁（ ActivityExecution 、 ClientProcessInstance 、 EventListenerExecution 实例之间的切换）加上调用相应的原子操作： ExecuteNode 、 MoveToChildNode 、 MoveToParentNode 、 ProceedToDesitination 、 Signal 、 TakeTransition （详见 pvm/internal/model/op 包下的相关类）来实现的。所以 Execution 实例的集合及有向图实际上就是运行期的路径。

3、 Event-Action 机制的变化

在 jbpm3 中是基于 Event-Action 机制来实现事件与动作的触发的，但是在 jbpm4 中则采用观察者模式来触发事件的。所有用户自己定义的动作，全部要实现 EventListener 接口，这些动作作为监听者（就是事件 Event 的观察者 Observer ）注册到相应的流程定义对象上（ ProcessElement 或者 Node ），而事件 Event 则作为被观察的对象（实际上就是 Observerable ），实际上在 jbpm4 中专门定义出了一个对象 ObservableElementImpl ，流程定义中的 NodeImpl 、 TransitionImpl 、 ProcessDefinitionImpl 均继承自此对象，因此这些元素本身就可以作为 Observerable 而被观察者来监控。

4、客户端接口的变化

在 jbpm4 中对客户端的接口统一为 7 个服务接口： ProcessService 、 ExecutionService 、 CommandService 、 TaskService 、 ManagementService 、 HistoryService 、 IdentityService ，这 7 个接口可以从 ProcessEngine 接口中获得， jbpm4 在启动的过程中由 JbpmConfiguration 负责构建引擎。

Ø ProcessService- 流程定义的服务接口，包括对流程定义的部署、查询、删除操作；

Ø ExecutionService- 执行服务接口，包括启动流程、实例推进、设置变量等操作；

Ø CommandService-Command 模式的服务接口，实际上就是将客户端的请求全部封装在一个调用接口中，然后由这个接口去调用 Command 接口的众多实现（ StartExecutionCmd 、 SignalCmd 、 SetVariablesCmd 、 GetTimersCmd 、 DeployCmd 、 NewTaskCmd 、 SubmitTask 、 ExecuteJobCmd 等等，具体可参加 pvm/internal/cmd ， task/internal/cmd 包及其它包下实现 Command 接口的类），这是典型的 Command 模式的应用，感兴趣的读者可以去了解设计模式中的 Command 模式；

Ø TaskService- 人工活动的服务接口，包括对任务的创建、提交、查询、保存、删除等操作；

Ø ManagementService-web 管理控制台的服务接口，目前只有获得消息及计时器的接口实现；

Ø HistoryService- 目前有对历史库中的流程实例、活动实例进行查询、某个流程定义中的所有活动的平均持续时间、某个流程定义中的某个活动实例的转移的执行次数

Ø IdentityService- 用户、组、成员关系的相关操作方法

5、历史库的加入

jBPM3 中数据库设计一直是我比较诟病的地方，尤其是其实例数据库没有设计历史库的概念并按照办结状态将运行结束的实例数据归入历史库，在这种情况下它的实例数据库就会随着时间而无限膨胀，这就阻碍了它的真实应用，而在 jBPM4 的最新代码中（注意 Alpha1 还没有出现），历史库的相关功能代码竟然出现了！详见 ExecutionImpl 最新代码中的 fireHistoryEvent 方法及一系列的 historyXXX 方法。在 ActivityBehaviour 的 execute 方法中加入了 historyTaskStart 方法的调用、 signal 方法中加入了 historyTaskEnd 方法的调用，而以上 2 个方法在 ExecutionImpl 中都是以历史事件（ HistoryEvent 有 4 个实现子类 ProcessInstanceStart 、 ProcessInstanceEnd 、 ActivityStart 、 ActivityEnd 分别用作流程实例的创建结束期、活动实例的创建结束期的历史数据处理）的触发机制来实现的，也就是在整个流程实例执行的过程中，都加入了对将运行数据存入历史库的历史事件（ HistoryEvent ）的触发。这样实例列表的查询可以只查询历史库。不过这里很遗憾的是，这个事件没有同时清除运行库的数据，这样还是会造成运行库的无限膨胀问题。

礼物 2009-07-13 10:18 发表评论

BlogJava- 礼物 ^_^ -文章分类-JBPM4

jBPM 4.0 解读分析

jBPM4的运行期环境

Jbpm4的IOC容器

jBPM4任务管理：参与模式一瞥

jBPM4管理控制台一瞥

jbpm3与jbpm4实现对比

BlogJava-　　　　　　　　　　　　　礼物 ^_^ -文章分类-JBPM4