活动可以实现循环，基于转移或活动组合。 循环可以包含等待状态。
为了支持多次自动循环执行，流程虚拟机 把执行的传播从尾部递归转换成while循环。
7.2. 子流程
TODO: 子流程
7.3. 默认执行行为
当一个Activity被用作活动行为， 它可以使用下面的方法从外部控制流程：
* waitForSignal()
* take(Transition)
* end(*)
* execute(Activity)
* createExecution(*)
当Activity实现用做活动行为， 没有调用任何下面的流程传播方法，然后 在活动执行时，执行会使用默认执行行为。
默认执行行为定义在下面：
* 如果当前活动有一个默认向外转移，选择它。
* 如果当前活动有一个父活动，回退到父活动。
* 否则，结束这个执行。
流程语言可以重写默认执行行为， 通过重写ExecutionImpl中的 proceed方法。
7.4. 功能活动
活动也可以用作事件监听器，被称作功能活动。 自动活动的例子是发送邮件，执行数据库更新， 生成pdf，计算平均数，等等。 所有这些都是自动活动，没有改变执行流向。 这里是这些活动如何实现：
public class FunctionalActivity implements Activity, EventListener {
public void execute(ActivityExecution execution) {
perform(execution);
}
public void notify(EventListenerExecution execution) {
perform(execution);
}
void perform(OpenExecution execution) {
...do functional work...
}
}
perform方法获得一个OpenExecution， 这是ActivityExecution和
EventListenerExecution的超类。 OpenExecution没有提供任何特定目的的方法，
但是依旧是当前状态，流程定义可以通过变量检验， 这包含了环境信息 对应流程执行。
这些方法其实都不能调用执行传播方法。 所以在perform方法完成后，执行会 执行默认的方式。
7.5. 执行和线程
这一章解释流程虚拟机如何通过客户端的线程， 把一个执行从一个等待状态带到另一个。
当一个客户调用一个执行的一个方法（比如signal方法）。 默认，流程虚拟机会使用线程执行流程
直到它到达一个等待状态。一旦下一个等待状态到达， 这个方法会返回，客户端的线程就会返回。 这是流程虚拟机操作的默认方式。
两个更多的异步执行可以补充默认行为： 异步继续 和异步命令服务。
下一个流程会展示基本理论。 它有三个等待状态和四个自动活动。
有很多顺序自动活动的流程。
图 7.1. 有很多顺序自动活动的流程。
这里是如何构建流程：
ClientProcessDefinition processDefinition = ProcessFactory.build("automatic")
.activity("wait 1").initial().behaviour(new WaitState())
.transition().to("automatic 1")
.activity("automatic 1").behaviour(new Display("one"))
.transition().to("wait 2")
.activity("wait 2").behaviour(new WaitState())
.transition().to("automatic 2")
.activity("automatic 2").behaviour(new Display("two"))
.transition().to("automatic 3")
.activity("automatic 3").behaviour(new Display("three"))
.transition().to("automatic 4")
.activity("automatic 4").behaviour(new Display("four"))
.transition().to("wait 3")
.activity("wait 3").behaviour(new WaitState())
.done();
让我们和你一起顺着流程的执行一起走。
ClientExecution execution = processDefinition.startProcessInstance();
启动一个新执行意味着初始活动被执行。 所以如果一个自动活动是初始活动，这意味着第一个未命名的向外转移会被立刻选择。 这些都发生在startProcessInstance调用的内部。
然而在这种情况下，初始活动是一个等待状态。 所以startProcessInstance方法会立刻返回， 执行会定位到初始活动'wait 1'。
一个新执行会被定为到'wait 1'。
图 7.2. 一个新执行会被定为到'wait 1'。
然后一个外部触发器会执行signal方法。
execution.signal();
像上面解释的介绍WaitState， signal会导致选择默认的转移。 转移会把执行移动到automatic 1活动，并执行它。
automatic 1中的Display活动的execute方法， 向控制台打印一行，它不会
调用execution.waitForSignal()。 因此，执行会通过选择automatic 1外部的默认转移进行执行。
在这种状态，signal方法一直阻塞着。另一个需要考虑的方式是执行方法， 像signal会使用客户端的线程
来拦截流程定义，直到到达一个等待状态。
然后执行到达wait 2， 执行WaitState活动。那个方法会调用 execution.waitForSignal()，这会导致signal方法返回。 线程会返回到调用signal方法 的客户端。
所以，当signal方法返回时，执行定义到wait 2。
一个signal会把执行从'initial'带到'wait 2'。
图 7.3. 一个signal会把执行从'initial'带到'wait 2'。
然后执行会等待一个外部触发器， 像是一个对象（更准确的是一个对象图）在内存中， 直到下一个外部触发器执行signal方法。
execution.signal();
第二个调用的signal会直接让执行进入wait 3， 在它返回之前。
第二个signal让执行进入'wait 3'。
图 7.4. 第二个signal让执行进入'wait 3'。
使用这个范例的好处是相同的流程定义可以在 客户执行模式中执行 （在内存内不使用持久化），就像在持久化执行模式， 依赖应用和环境。
当在持久化模式下执行一个流程，你如何绑定 流程执行到数据库的事务上。
持久化模式下的事务超时
图 7.5. 持久化模式下的事务超时
在大多情况下，计算工作是流程需要完成的一部分， 在外部触发器（红色部分）之后的部分，其实很少。
一般来说，处理流程执行和处理UI传递过来的请求 的事务不会超过一秒。 而业务流程中的等待状态可能超过几小时，几天甚至几年。
当等待状态启动后，线索就变得很清晰， 在等待状态启动之前，只有计算工作的完成包含在事务中。
考虑一下这种方式： "当到达审批时，所有的自动流程需要做的是什么， 在流程系统需要等待另一个外部触发器之前？"。
除非pdf需要被创建，或大邮件需要被发送， 大部分时候，它消耗的时间都是可以忽略的。 这就是为什么在默认的持久化执行模式下，
流程工作在客户端线程下执行。
这个原因也保证着流程同步路径的情况。 当一个执行的单独路径切分成流程同步路径， 流程花在计算上的时间是可忽略的。
所以为什么分支或切分活动实现是有意义的， 目标持久化模式产生的同步路径在同一个线程中按顺序执行。 基本上它们都只是在同一个事务中的计算工作。
因为分支或切分知道每个执行的同步路径会返回，所以这只能被完成， 当出现一个等待状态的时候。
因为这里有一个困难的概念需要掌握，我会再次使用其他词语来解释它。 从头再看一次在持久化执行模式下被流程执行创建出来的它。
如果在一个事务中，一个执行被给与一个外部触发器， 那导致执行切分成多个执行的同步路径。 然后执行在计算上的部分也可以忽略。
生成SQL的部分也可以忽略。 因为所有在同步分支上完成的功能，必须在同一个事务中完成， 这里一般没有指针在分支或切分实现，
在多个线程中产生执行的同步路径。
为了创建可执行流程，开发者需要确切知道什么是自动活动， 什么是等待状态，哪些线程会被分配给流程执行。 对于画业务流程的业务分析人员，事件就很简单了。 对于他们画的活动，他们通常只要知道这是一个人或是一个系统响应。 但是他们通常不知道如何转换线程和事务。
所以对于开发者，第一个任务是分析什么是流程控制的线程中需要执行的， 什么是外部的。 查找外部触发器是寻找一个流程中的等待状态的很好的开始， 就像动词和名词可以在构建UML类图中的元素的规则。
posted @
2009-06-26 12:03 卡宴 阅读(1144) |
评论 (0) |
编辑 收藏
5.5. 基本流程执行
在下一个例子里，我们会结合自动活动和等待状态。 这里例子构建了贷款审批流程，使用WaitState 和Display活动，我们刚刚创建的。 贷款流程的图形看起来像这样：
贷款流程
图 5.3. 贷款流程
使用Java构建流程图形是很乏味的事情， 因为你必须在局部变量中跟踪所有的引用。
为了解决这个问题，流程虚拟机提供了一个ProcessFactory。
ProcessFactory是一种领域特定语言（DSL），可以嵌入到Java中， 简化流程图形的结构。这个模型也叫做 流畅接口。
ClientProcessDefinition processDefinition = ProcessFactory.build("loan")
.activity("submit loan request").initial().behaviour(new Display("loan request submitted"))
.transition().to("evaluate")
.activity("evaluate").behaviour(new WaitState())
.transition("approve").to("wire money")
.transition("reject").to("end")
.activity("wire money").behaviour(new Display("wire the money"))
.transition().to("archive")
.activity("archive").behaviour(new WaitState())
.transition().to("end")
.activity("end").behaviour(new WaitState())
.done();
为了了解ProcessFactory的更多细节，可以参考 api文档。
ProcessFactory的另一种选择是创建一个XML语言和一个XML解析器，来表示流程。 XML解析器可以直接实例化
org.jbpm.pvm.internal.model包中的类。 这种方式一般都被流程语言选择使用。
初始化活动submit loan request和 wire the money活动是自动活动。 在这个例子中，wire the
money活动的 Display实现 使用Java API来把信息输出到控制台上。但是读取器可以想象一个可选的
Activity实现，使用支付流程库的Java API 来实现一个真实的自动支付。
上述流程的一个新执行可以像下面这样启动
ClientExecution execution = processDefinition.startProcessInstance();
当startExecution方法返回时， submit loan request活动会被执行， 执行会位于evaluate活动。
位于'evaluate'活动的执行
图 5.4. 位于'evaluate'活动的执行
现在，执行处在一个很有趣的点。这里有两个转移从evaluate指向外边。 一个转移叫approve 一个转移叫reject。像我们上面解释的， WaitState实现会根据执行的signal选择转移。 让我们像这样执行'approve' signal：
execution.signal("approve");
这个approve signal会导致执行选择approve转移 它会到达wire money活动。
在wire money活动中，信息会打印到控制台里。 因为Display没有调用execution.waitForSignal()，
也没有调用其他执行传播方法， 默认流程行为只会让执行继续， 使用向外的转移到达archive活动， 这也是一个WaitState。
位于'archive'活动的执行
图 5.5. 位于'archive'活动的执行
所以只有当archive到达时， signal("approve")会返回。
另一个signal就像这样：
execution.signal("approve");
将让执行最终到达结束状态。
位于'end'活动的执行
图 5.6. 位于'end'活动的执行
5.6. 事件
事件位于流程定义中， 一系列的EventListener可以进行注册。
public interface EventListener extends Serializable {
void notify(EventListenerExecution execution) throws Exception;
}
事件的目的是让开发者可以为流程添加程序逻辑， 不必改变流程图。 这是非常有价值的机制，可以促进业务分析人员和开发者之间的协作。
业务分析人员负责描述需求。 当他们使用流程图归档那些需求， 开发者可以获得这些图形，让它可执行化。
事件会非常方便，向一个流程中添加技术细节（比如一些数据库插入操作） 这些都是业务分析人员不感兴趣的东西。
最常用的事件是由执行自动触发的：
TODO: 在用户手册中解释事件
事件是由流程元素和事件名称结合而成。 用户和流程语言也可以出发事件， 使用编程的方式在流程中使用fire方法。
public interface Execution extends Serializable {
...
void fire(String eventName, ProcessElement eventSource);
...
}
可以把一系列的EventListeners分配给一个事件。 但是事件监听器不能控制执行的流向， 因为它们仅仅是监听已经执行了的执行。 这与活动处理活动的行为是不同的。 活动行为可以响应执行的传播。
我们会创建一个PrintLn事件监听器， 这与上面的Display活动是非常相似的。
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");
}
}
多个PrintLn监听器 会在流程中注册。
PrintLn监听器流程
图 5.7. PrintLn监听器流程
ClientProcessDefinition processDefinition = ProcessFactory.build()
.activity("a").initial().behaviour(new AutomaticActivity())
.event("end")
.listener(new PrintLn("leaving a"))
.listener(new PrintLn("second message while leaving a"))
.transition().to("b")
.listener(new PrintLn("taking transition"))
.activity("b").behaviour(new WaitState())
.event("start")
.listener(new PrintLn("entering b"))
.done();
第一个事件演示如何为相同的事件注册多个监听器。 它们会根据它们指定的顺序依次执行。
然后，在转椅上，这里的事件只有一种类型。 所以在那种情况下，事件类型不需要指定， 监听器可以直接添加到转移上。
一个监听器每次都会执行，当一个执行触发事件时，如果这个监听器被注册了。 执行会作为一个参数提供给活动接口， 除了控制流程传播的方法以外， 都可以被监听器使用。
5.7. 事件传播
事件会默认传播给最近的流程元素。 目的是允许监听器在流程定义或组合活动中 可以执行所有发生在流程元素中的事件。
比如这个功能允许为end事件在流程定义或一个组合活动中注册一个事件监听器。 这种动作会被执行，如果一个活动离开。
如果事件监听器被注册到一个组合活动中， 它也会被所有活动执行，当组合活动中出现了离开事件。
为了清楚地显示这个，我们会创建一个DisplaySource事件监听器， 这会把leaving信息和事件源 打印到控制台。
public class DisplaySource implements EventListener {
public void execute(EventListenerExecution execution) {
System.out.println("leaving "+execution.getEventSource());
}
}
注意事件监听器的目的不是可视化，这是为什么事件监听器本身 不应该显示在图形中。一个DisplaySource事件监听器 会作为end事件的监听器添加到组合活动中。
下一个流程展示了DisplaySource事件监听器如何 作为'end'事件的监听器注册到composite活动：
一个在组合活动中为end事件注册了不可见的事件监听器的流程。
图 5.8. 一个在组合活动中为end事件注册了不可见的事件监听器的流程。
TODO 更新代码片段
下一步，我们会启动一个执行。
ClientExecution execution = processDefinition.startProcessInstance();
在启动一个新执行后，执行将在a活动中 作为初始活动。没有活动离开，所以没有信息被记录下来。 下一个signal会给与执行， 导致它选择从a到b。
execution.signal();
当signal方法返回，执行会选择转移 然后end事件会被a活动触发。 那个组合活动会被传播到组合活动和流程定义中。 因为我们的DisplaySource 监听器放到 composite活动中， 它会接收事件，把下面的信息打印到控制台中：
leaving activity(a)
另一个
execution.signal();
会选择b到c的转移。那会触发两个活动离开事件。 一个在b活动，一个在组合活动。 所以下面的几行会添加到控制台输出中：
leaving activity(b)
leaving activity(composite)
事件传播建立在流程定义的继承组合结构中。 顶级元素总是流程定义。 流程定义包含一系列活动。每个活动可以是叶子活动或者可以是一个组合节点， 这意味着它包含了一系列内嵌活动。 内嵌活动可以被使用，比如超级状态或组合活动，在内嵌流程语言中，像BPEL。
所以事件模型在组合活动和上面的流程定义中的功能是相似的。 想象'Phase one'模型一个超级状态作为一个状态机。
然后事件传播允许在超级状态中注册所有事件。 这个主意是继承组合响应图形展示。 如果一个'e'元素画在另一个'p'元素中，
'p'是'e'的父节点。一个流程定义拥有一系列定义活动。 每个活动可以拥有一系列内嵌活动。 一个转移的父节点就是它的源头和目的的第一个父节点。
如果一个事件监听器对传播的事件没有兴趣， 可以在构建流程使用ProcessFactory的propagationDisabled()。 下一个流程是与上面相同的流程， 除了传播的事件会被事件监听器禁用。 图形还是一样。
注册到'end'事件的事件监听器被禁用的流程。
图 5.9. 注册到'end'事件的事件监听器被禁用的流程。
使用流程工厂构建流程：
TODO 更新代码
所以当第一个signal在流程中调用时，end事件 会再次触发在a活动上，但是现在在组合活动的事件监听器 不会被执行，因为传播的事件被禁用了。 禁用传播是单独的事件监听器的一个属性， 不会影响其他监听器。事件会一直被触发， 传播到整个父继承结构。
ClientExecution execution = processDefinition.startProcessInstance();
第一个signal会选择从a到b的流程。 没有信息会被打印到控制台。
execution.signal();
下一步，第二个signal会选择从b到c的转移。
execution.signal()
还是两个end事件被触发， 就像上面分别在b和composite活动中。 第一个事件是b活动上的 end事件。
那将被传播给composite活动。 所以事件监听器不会为这个事件执行，因为它已经禁用了传播。 但是事件监听器会在composite活动上
为end事件执行。 那是不传播的，但是直接在composite活动上触发。 所以事件监听器现在会被执行
一次，为组合活动，就像下面控制台里显示的那样：
leaving activity(composite)
jBPM4.0中文开发指南完整版
http://family168.com/tutorial/jbpm4devguide/html/index.html
posted @
2009-06-25 17:38 卡宴 阅读(944) |
评论 (0) |
编辑 收藏
这一章解释了流程定义的基础，流程虚拟机给予的功能 以及活动实现是如何构建的。 同时，客户端API被用来执行包含了那些活动实现的流程。
5.1. ActivityBehaviour
PVM库没有包含完整的流程结构。 作为替代的是，活动的运行时行为被委派给一个ActivityBehaviour。 换句话讲，ActivityBehaviour是一个接口， 它用来在纯java环境实现流程结构的运行时行为。
public interface ActivityBehaviour extends Serializable {
void execute(ActivityExecution execution) throws Exception;
}
当一个活动行为被调用时，它就处于执行传播的全部控制中。 换句话说，一个活动行为可以决定下一步应该执行什么执行。
比如，可以使用execution.take(Transition)获得一个转移，
或者使用execution.waitForSignal()进入等待阶段。 万一活动行为没有调用任何上述的执行传播方法， 执行将
按默认方式执行。
5.2. ActivityBehaviour实例
我们会启动一个非常原始的hello world例子。 一个Display活动会将一条信息打印到控制台：
public class Display implements ActivityBehaviour {
String message;
public Display(String message) {
this.message = message;
}
public void execute(ActivityExecution execution) {
System.out.println(message);
}
}
让我们使用这个活动构建我们第一个流程定义：
Display实例流程
图 5.1. Display实例流程
TODO add ProcessBuilder example code
现在我们可以像下面这样执行流程：
Execution execution = processDefinition.startExecution();
startExecution的调用会在控制台打印hello world：
hello
world
一个总是值得提醒的事情是活动可以使用属性进行配置。 在Display例子中，你可以看到message属性在两种使用方法中配置的不同。
通过配置属性，我们可以写出可复用的活动。 它们可以在以后每次使用在流程中都进行不同的配置。 这是一个基本的部分，
将流程语言构建在流程虚拟机之上。
其他需要解释的部分是 这个活动实现没有包含任何执行传播的功能。 当一个新流程实例启动时， 执行会定位到初始活动，那个活动会被执行。
Display.execute方法用来决定默认的执行传播。 具体的，这意味着活动自己 没有调用任何执行传播的方法。
那种情况下，默认的传播会执行。默认传播会选择第一个转移，如果这个转移存在的话。 如果没有，它会结束这个执行。
这揭示了为什么a活动和b活动都被执行， 而在b活动执行完执行会停止。
关于默认流程行为的更多细节可以 在第 7.3 节 “默认执行行为”找到。
5.3. ExternalActivityBehaviour
外部活动是负责流程执行由外部转移进来的活动， 外部的意思是来自流程系统的外部。 这意味着这个执行流程对于系统来说，这是一个等待状态。 这个执行会一直等待到外部触发器调用。
为了处理外部触发器，ExternalActivityBehaviour 为ActivityBehaviour添加了一个方法：
public interface ExternalActivity extends Activity {
void signal(Execution execution,
String signal,
Map<String, Object> parameters) throws Exception;
}
就像普通的活动，当一个执行到达一个活动， 外部活动行为的execute方法会被调用。
在外部活动中，execute方法会传递另一个系统的响应， 然后通过调用execution.waitForSignal() 进入等待状态。
比如在execute方法中，响应可能是由一个人传入， 通过在任务管理系统中创建一个任务入口， 然后等待到这个人完成这个任务。
一旦活动行为已经处于等待状态， 然后执行会等待到调用signal方法。 执行会委派signal给ExternalActivityBehaviour对象 分配给当前的活动。
所以活动的signal方法 会在等待期间，在执行获得一个外部触发器的时候调用。 signal方法中，响应会传递给后面的流程执行。 比如，当一个人完成了一个任务，任务管理系统 会在执行中调用signal方法。
一个signal可选择使用signal名字和一个参数map。 活动行为拦截signal和参数的最常用方式是 signal对应选择的外出转移， 参数作为执行中的变量。但那些只是例子， 它一直等到活动使用singal和它期望的参数。
5.4. ExternalActivity实例
这里是一个简单等待状态实现的第一个例子：
public class WaitState implements ExternalActivity {
public void execute(ActivityExecution execution) {
execution.waitForSignal();
}
public void signal(ActivityExecution execution,
String signalName,
Map<String, Object> parameters) {
execution.take(signalName);
}
}
execute方法调用execution.waitForSignal()。 execution.waitForSignal()的调用 会使流程执行进入等待状态， 直到一个外部触发器出现。
signal方法使用signal参数对应的转移名称 来选择转移。所以当一个执行获得一个外部触发器， signal名称被拦截，作为外部转移的名称， 执行会被传播到那个转移上。
这里是从a到b有一个转移的相同的流程。 这时候，两个活动的行为都是WaitState。
外部活动实例流程
图 5.2. 外部活动实例流程
ClientProcessDefinition processDefinition = ProcessFactory.build()
.activity("a").initial().behaviour(new WaitState())
.transition().to("b")
.activity("b").behaviour(new WaitState())
.done();
让我们为流程定义启动一个新流程实例：
ClientExecution execution = processDefinition.startProcessInstance();
启动这个流程会执行a中的WaitState活动。 WaitState.execute会调用
ActivityExecution.waitForSignal。
所以当processDefinition.startProcessInstance()返回， 执行会一直处在a活动。
assertEquals("a", execution.getActivityName());
然后我们提供了外部触发器， 通过调用signal方法。
execution.signal();
execution.signal()会委派给当前活动。 所以在这种情况下就是a活动里的
WaitState活动。WaitState.signal会调用 ActivityExecution.take(String
transitionName)。 当我们没有提供一个signal名称，第一个名字是null会被选中。
我们指定的a的唯一转移没有名字，所以会选中这个。 然后这个转移指向b。 当执行到达b活动， b活动中的WaitState活动会被执行。
就像我们上面看到的，执行会在b一直等待， 这时signal会返回， 离开的执行指向b活动。
assertEquals("b", execution.getActivityName());
jBPM4.0开发指南完整版
http://family168.com/tutorial/jbpm4devguide/html/index.html
posted @
2009-06-25 17:37 卡宴 阅读(954) |
评论 (0) |
编辑 收藏
第1个示例Pay是我们family168所做的例子中我最喜欢的一个，这是一个简易的信息统计查询工具，它甚至没有服务器端的代码，完全依靠JavaScript提供各种数据，在这个小系统中我们可以分类查看不同客户的信息，以及由这这些信息汇总的图形报表。
其中包月包年的用户情况的统计使用的是maven2中的cobertura里的效果，这样哪些vip已经过期，哪些vip快到期就一目了然，当然最重要的是视觉效果好。
首页效果如下图所示：
系统的最后一项功能是统计报表，我们可以按照用户类型和是否过期生成两种统计报表，报表图形并不是使用Ext
JS实现的，而是用svg画的，不过我们在显示报表页面的时候使用了iframe，这样做的好处是不用将所有代码都加载到首页中，虽然RIA宣扬one
page one application，但是使用iframe可以在一定程度上避免一次加载过多的资源文件，在实际中依然拥有适用的场景。
显示效果如下图所示：
第2个示例Tracker是一个简易的任务跟踪系统，它使用了最基本的ssh开发框架，通过嵌入式数据库hsqldb保存数据，依靠maven2管理项目流程。俨然已经是一个小而全的企业系统了。
Ext JS在系统中负责前台展示的部分，后台通过struts2结合json-lib与前台的Ext JS进行交互，在开发过程中，我们封装了JsonGrid和JsonTree这些基本组件，很大程度上减少了编码的数量，提高的开发效率。
系统界面如下：
系统左侧是以JsonTree为基础生成的树形菜单，显示了所有工程的信息，我们可以直接在左侧面板部分进行添加，修改，删除等操作。
进行详细配置和右键功能菜单效果如下图所示：
统计系统下载：
http://www.family168.com/demo/pay.rar
任务追踪系统下载：
http://www.family168.com/demo/tracker.rar
由于第2个示例是使用maven2构建的，所以不会使用maven2的朋友可以查看我们的maven2教程
http://family168.com/oa/maven2/html/index.html。如果想知道这2个示例的详细讲解，可以上我们的论坛
http://family168.com/bbsindex.asp?boardid=13查看。
posted @
2009-06-25 15:12 卡宴 阅读(1524) |
评论 (3) |
编辑 收藏
4.1. APIs
流程虚拟机包含4个集成的API，在不同的执行模式下， 覆盖完整的流程工作。 每个API都有特定的目的， 满足下面的架构。
流程虚拟机中的4个API
图 4.1. 流程虚拟机中的4个API
服务接口用在应用代码中，与流程虚拟机进行交互， 它将运行在支持事务的持久化模式下，后端基于数据库。 这是用户将PVM作为一个工作流引擎使用的最常用的方式。
如果不想使用持久化方式执行流程，可以直接使用客户端API来处理流程和执行对象。 客户端API对外暴露了核心模型对象的方法。
活动API用来实现活动在运行时的行为。 因此一个活动类型实际上是一个组件，核心是实现了ActivityBehaviour接口。 活动行为实现可以控制执行的流程。
事件监听器API用来编写java代码，它可以用来处理流程事件。 它比活动API类似， 唯一的差别是事件监听器不能控制执行的流程。
4.2. 活动API
活动API允许使用java实现运行时的活动行为。
public interface ActivityBehaviour extends Serializable {
void execute(ActivityExecution execution) throws Exception;
}
一个活动就是分配给活动的一些行为。 提供的执行就是到达这个活动的执行。 ActivityExecution接口 暴露了控制执行流程的方法。
public interface ActivityExecution extends OpenExecution {
void waitForSignal();
void take(String transitionName);
void execute(String activityName);
...
}
4.3. 事件监听API
事件监听API允许使用java开发监听器， 并在特定的流程事件发生时调用，像进入一个活动或离开一个活动。 它与活动API类似，
不同的是不能控制执行流程的传播。 比如，当一个执行选择了一个转移，一个对应的监听器会被激活， 但是因为这个转移已经被选择了，
执行的流程无法被事件监听器改变。
public interface EventListener extends Serializable {
void notify(EventListenerExecution execution) throws Exception;
}
4.4. 客户端API
客户端API是一套暴露了相关方法的接口， 它用来直接管理流程定义上的执行和执行对应。
最小的需求，客户端API和活动API需要使用活动创建 流程定义并执行它。
4.5. 环境
在持久化执行环境下，环境的第一目的 是让流程在不同的事务环境下执行， 比如Java标准版，Java企业版，SEAM和Spring。
PVM代码自身只通过自身定义的接口来调用事务资源。 比如，PVM自身拥有一些建立在hibernate会话，异步消息会话 和定时任务会话的接口方法。
环境允许为其配置真实的实现， 在请求的基础上实现服务的延迟加载， 为事务的持续获得服务对象。
一个环境工厂是静态的，一个环境工厂 提供应用中的所有线程。
EnvironmentFactory environmentFactory = new PvmEnvironmentFactory("environment.cfg.xml");
环境部分可以像这样 围绕在持久化流程操作周围：
Environment environment = environmentFactory.openEnvironment();
try {
... inside the environment block...
} finally {
environment.close();
}
PVM自身会从环境中获得所有事务资源和配置。 Activity实现 也可以做同样的事情。
org.jbpm.pvm.internal.cfg.JbpmConfiguration 这个类扮演着Configuration， ProcessEngine和EnvironmentFactory三个角色。
4.6. 命令
命令封装了将被运行在环境块中的操作。 命令的主要目的是获得逻辑。
public interface Command<T> extends Serializable {
T execute(Environment environment) throws Exception;
}
4.7. 服务
这里有三个主要服务：RepositoryService， ExecutionService和ManagementService。 通常来说，服务是会话外观，用来暴露PVM持久化应用的方法。 下一部分用例子展示 这些服务中的基本方法。
RepositoryService管理 流程定义的资源。
public interface RepositoryService {
Deployment createDeployment();
ProcessDefinitionQuery createProcessDefinitionQuery();
...
}
ExecutionService管理 运行时的执行。
public interface ExecutionService {
ProcessInstance startProcessInstanceById(String processDefinitionId);
ProcessInstance signalExecutionById(String executionId);
...
}
ManagementService包含了所有管理操作 来保持系统启动运行。
public interface ManagementService {
JobQuery createJobQuery();
void executeJob(long jobDbid);
...
}
所有这些方法都封装成Command。 这三个服务执行的方法 都委派给一个CommandService：
public interface CommandService {
<T> T execute(Command<T> command);
}
CommandService被配置到环境中。 一个CommandService链可以看做环绕在一个命令周围的一些拦截器。 这就是如何在不同的环境下 进行持久化和事务支持的核心机制。
默认的配置文件jbpm.default.cfg.xml 包含了下面的配置服务。
<jbpm-configuration>
<process-engine>
<repository-service />
<repository-cache />
<execution-service />
<history-service />
<management-service />
<identity-service />
<task-service />
文件 jbpm.tx.hibernate.cfg.xml包含了 下面的command service配置:
<jbpm-configuration>
<process-engine-context>
<command-service>
<retry-interceptor />
<environment-interceptor />
<standard-transaction-interceptor />
</command-service>
</process-engine-context>
...
这些服务，比如repository-service，execution-service
和management-service将按照类型找到配置好的command-service。
command-service标签符合默认的命令服务， 基本上什么也不做， 只是在提供给它的环境上执行命令。
配置的command-service结果， 在默认的命令执行期下面的三个拦截器链中。
CommandService拦截器
图 4.2. CommandService拦截器
retry拦截器是链中的第一个，它会被环境 当做CommandService.class暴露出来。 所以retry拦截器会分别提供给repository-service， execution-service和management-service这些服务。
retry-interceptor会获取hiberate的StaleObjectExceptions （因为乐观锁失败）并重新尝试执行命令。
environment-interceptor会把一个环境块 放到命令执行的周围。
standard-transaction-interceptor会初始化一个 StandardTransaction。hibernate会话/事务会被作为 标准事务的一个资源。
这个拦截器栈的不同配置也可以使用：
* 把执行委派到一个本地ejb命令服务， 这样可以启动一个内容管理的事务。
* 把执行委派到一个远程ejb命令服务， 这样命令实际执行在一个不同的JVM上。
* 把命令打包成一个异步消息， 这样命令会异步执行在一个不同的事务中。
完整版内容
http://family168.com/tutorial/jbpm4devguide/html/index.html
posted @
2009-06-24 08:54 卡宴 阅读(1401) |
评论 (0) |
编辑 收藏
jbpm.jar包含了一些默认配置文件， 它们可以导入到用户配置文件中。
这样，用户很容易选择包含或排除哪些功能。 而且这些配置信息也包含了实现， 所以用户可以只导入那些起作用的配置文件， 当我们发布的配置文件中出现了修改的时候。
配置文件可以导入到用户的jbpm.cfg.xml中：
jbpm.default.cfg.xml
jbpm.identity.cfg.xml
jbpm.jbossremote.cfg.xml
jbpm.jobexecutor.cfg.xml
jbpm.tx.hibernate.cfg.xml
jbpm.tx.jta.cfg.xml
jbpm.default.cfg.xml：包含了默认的配置， 比如服务，hibernate配置（来自jbpm.hibernate.cfg.xml中的配置）， hibernate会话工厂，业务日历等等。
一个标准的java配置看起来像是这样：
<?xml version="1.0" encoding="UTF-8"?>
<jbpm-configuration>
<import resource="jbpm.default.cfg.xml" />
<import resource="jbpm.tx.hibernate.cfg.xml" />
<import resource="jbpm.jpdl.cfg.xml" />
<import resource="jbpm.identity.cfg.xml" />
<import resource="jbpm.jobexecutor.cfg.xml" />
</jbpm-configuration>
在一个JTA环境中，使用jbpm.tx.jta.cfg.xml 替换jbpm.tx.hibernate.cfg.xml。
如果希望自定义这些配置中的任何部分，可以在jbpm.cfg.xml中 使用自定义的内容替换引用部分。
jbpm.jar也包含了下列hibernate映射配置文件：
jbpm.execution.hbm.xml
jbpm.history.hbm.xml
jbpm.identity.hbm.xml
jbpm.repository.hbm.xml
jbpm.task.hbm.xml
jbpm.jpdl.hbm.xml
所有这些将java领域模型映射到一个关系数据库中。
jbpm.jar还包含的其他配置文件：
jbpm.task.lifecycle.xml
jbpm.variable.types.xml
jbpm.wire.bindings.xml
jbpm.jpdl.activities.xml
jbpm.jpdl.eventlisteners.xml
如何从配置文件开始进行解析，参考
* 类 org.jbpm.pvm.internal.env.JbpmConfigurationParser
* 资源 modules/pvm/src/main/resources/jbpm.wire.bindings.xml
* 包 modules/pvm/src/main/java/org/jbpm/pvm/internal/wire/binding
完整版内容
http://family168.com/tutorial/jbpm4devguide/html/index.html
posted @
2009-06-24 08:50 卡宴 阅读(1314) |
评论 (0) |
编辑 收藏