使用JBoss/jBPM编排长运行活动

jieforest

至此，图6中所实现的流程实现还需要一点修改就能满足我们的基本实现。首先，timing out节点可以决定继续等待，或则采取一个纠正动作，不过这两种情况的最终结果都是控制权转移到Starting pipeline节点上；另外，这个timing out节点还必须要知晓脚本是否正在运行（继续等待动作）还是不在运行（启动脚本）。该逻辑的最简单实现方式是引入流程变量（见列表3）：
String state = (String)executionContext.getVariable(processName);
if(state != null){
if("completed".equals(state)){
executionContext.leaveNode(completeTransition);
return;
}
else{
executionContext.leaveNode(waitTransition);
return;
}
}
executionContext.setVariable(processName, "started");
…………
列表3 执行路径选择
其次，在本例中，通过流程实例/令牌的的“盲”信令（signaling）来完成执行的做法是不成立的。原因有以下两个方面：
因为本例中的Running Pipeline状态有多个迁移（transition），REST API应该具备选择特定的迁移（transition）作为流程或令牌的信令结果的能力。
当回调处理器被调用时，图6中的例子无法保证流程正处于Running Pipeline状态。譬如，它可能正处于Timing out节点。这就意味着REST API应该具备只针对特定流程状态发出信令的能力。
我们可以对列表1中的REST API做些修改让它支持流程实例或令牌信令的上面所描述的两个参数（见列表4）
@POST
  @Path("instance/{id}/signal")
  public Response signalProcess(
      @PathParam("id") String id,
      @QueryParam("transition") String transition.
      @QueryParam("state") String state


  )
  ……………………
  @POST
  @Path("token/{id}/signal")
  public Response signalToken(
      @PathParam("id")String id,
      @QueryParam("transition") String transition,
      @QueryParam("state") String state
  )
  ……………………
列表4 扩展的REST API
由于可以使用jBPM的API获得特定流程实例的当前节点，并根据要求触发相应的迁移，因此扩展实现是相当直截了当的。

jieforest

脚本执行结果
支持脚本执行结果的实现也是相当直观的。通过简单地再引入一些流程变量就可以实现，这些变量可以通过回调处理器对其进行设置。

流程组件化
一个非常重要的例子是长运行活动本身就是一个jBMP流程。jPDL的目前版本（jPDL-3）没有显式提供多流程之间协作的支持。所以，流程设计 者经常把所需的功能都实现到一个大流程块中。这样的做法和创建很大的Java类一样存在一些弊端，如可读性和管理上的问题，以及重用的限制等。将流程分解 成多个流程9，并在运行时协作的做法在一定程度上可以减轻上述弊端。
JBoss SOA平台所提供的jBPM/ESB运行多流程之间的协作10， 它通过将这些流程包装成JBoss ESB服务，并使用jBMP ESB节点去调用它们。尽管这种方式没有问题，但需要在整体方案中引入JBoss ESB。如果ESB仅仅用于流程调用协作的话，理由难免有点牵强。一个更轻量的做法是通过程序的方式（使用一个流程节点）启动从属流程，然后使用jBPM REST服务器和回调处理器（上文描述的）实现主从流程间的协作。

总结
JBoss jBPM的简单性和扩展性使得它在实现jBPM本身不具备的附加功能时非常简单，这在很大程度上开拓了基于jBPM的解决方案的应用范围。

致谢
非常感谢NAVTEQ的同事们，特别是Catalin Capota，他参与了实现方案的讨论和原型设计。

justforregister

图呢

yellowweng

学习一下

justforregister

原帖由 yellowweng 于 2009-11-5 23:47 发表
学习一下

johnnyv_cn2

thanks