BlogJava-心情小站-随笔分类-JbpmSide

jBPM-Side流程设计器架构说明

ronghao — Sun, 20 Sep 2009 13:17:00 GMT

一、    代码主要结构
所谓流程设计器者，无怪乎读取xml文件，图形展现，操作图形元素，改变xml文件，回写，如此而已。

既然如此，设计器的流程结构就非常清晰：首先是xml框架解析xml文件为Model模型组件，然后Model模型组件被展现为Component视图组件；用户对Component视图组件进行操作，这些操作被同步的修改到Model模型组件；最后用户保存时，Model模型组件经过xml框架解析回xml文件，该文件被上传到服务器或本地覆盖原有的xml文件。

那么代码结构就很清晰了：xml框架、Model模型组件和Component视图组件。但是等等，Model与Component如何交互呢？这里就需要GEF框架嫁接起两者的联系。同时，一个流程设计器往往要同时编辑多个流程定义，相比具体的流程定义而言，设计器拥有一些全局的对象，这些全局对象包括系统菜单栏、工具条、整个设计器布局框架（ProcessDesigner）、设计器入口（ProcessEditor），还有就是负责保存全局属性和发布/订阅定制事件的TheModel对象。

二、    Component视图组件
很直接，Component视图组件指的是与用户打交道的、与流程定义相关的视图元素。注意这里的一个定语：与流程定义相关的，即不包括系统菜单、工具条这些东东。这些视图元素很简单，包括画图板、各种节点元素和连接线元素。

代码位于org.jbpmside.view.component和org.jbpmside.view.component.node下。主要类SurfaceComponent、NodeComponent和ConnectionComponent。看类名就很清晰这些类分别代表着什么组件：
•    SurfaceComponent代表画图板；
•    NodeComponent代表节点；
•    ConnectionComponent代表连接线；

org.jbpmside.view.component.node下的类就是NodeComponent类的子类，代表具体的单个节点类型了，包括开始节点、结束节点、Fork节点、Join节点等等。

Component视图组件使用了degrafa来渲染表现形式。

目前缺少一个属性弹出框组件，职责展现和修改节点/连接线属性。

三、    Model模型组件
Xml流程定义文件解析为本地Model模型组件，本地建模和jBPM4的PVM建模一致，代码位于org.jbpmside.model下，重要的类：
•    ProcessModel代表流程定义；
•    NodeModel代表节点定义；
•    ConnectionModel代表连接线定义；
剩下的就是具体节点类型的模型类，例如StartNode/EndNode/TaskNode等。

目前模型类还非常简单，因为前段时间主要关注Component视图组件部分，接下来很快会与jPDL规范完全同步，同时ProcessModel/NodeModel/ConnectionModel会进行重构，目标是与jBPM4模型完全一致。

最新的模型位于org.jbpmside.model.common下，对jpdl4的支持位于org.jbpmside.model.jpdl4下，未来需要将Component与Model的关联迁移至common包下。

四、    GEF框架
GEF框架嫁接Model与Component。

1、    IGraphicalEditor与IEditPart
IGraphicalEditor与IEditPart是GEF框架里最重要的两个接口：
•    IGraphicalEditor代表整个图形编辑器，IGraphicalEditor里最重要的方法：

function get graphicViewer():GraphicViewer;

返回当前的图形视图。在当前的设计里，设计器支持多个TabPane，每个流程定义会拥有一个单独的图形视图（即一个TabPane），这里的图形视图即指当前处于激活（编辑）状态的画图板；很显然IGraphicalEditor是一个全局类。

• IEditPart代表单个的图形编辑元素，很显然，这些元素是和Component组件一致的，IEditPart里最为重要的方法：

function get model():Object;

function set model(_model:Object):void;

Component组件继承于IEditPart，这样就瞬间将Component组件与Model关联起来。IEditPart重要的实现类包括GraphicViewer与GraphicEditPart。
GraphicViewer被SurfaceComponent继承；
GraphicEditPart被NodeComponent和ConnectionComponent继承。

2、 Tool
Flex应用程序是基于事件驱动的，用户对界面的操作即反映到各种鼠标和键盘事件上。在原先的设计里，由Component组件自己来处理各种原生事件，当需要其他组件协作时，通过TheModel发出应用定制事件。在GEF的设计里，Component组件的原生事件处理被委派到Tool类进行处理。Component组件只管理自身的图形渲染和变化。
例如SurfaceComponent处理鼠标点击事件代码：

public function mouseClickHandler(event:MouseEvent):void
        {
            … …
            this.tool.mouseClick(event, compX, compY);
        }

注意this.tool方法，这个方法同样是由GraphicViewer和GraphicEditPart分别引入的。注意有些时候组件的Tool是需要切换的，例如鼠标点击面板，通常会导致被选中的节点或连接线选中状态消失，但是当工具条选中一个节点时，这个鼠标事件会导致向面板增加相应的节点。这时需要ToolManager来进行Tool却换的管理，针对SurfaceComponent/NodeComponent/ConnectionComponent分别有SurfaceToolsManager/NodeToolsManager/ConnectionToolsManager来管理不同的Tool切换策略。需要注意的是ToolManager和Tool都是无状态的，全局唯一，所有视图组件共用。

3、    Command
视图组件的变化会导致Model组件的变化。Tool处理视图原生事件、调用CommandService执行各个Command具体操作视图组件和Model对象实现视图组件和Model组件的变化。

CommandService与SurfaceComponent进行一对一绑定。CommandService持有CommandStack，实现单个Tab编辑界面内Command的redo和undo。

具体操作视图组件和Model对象必须通过Command。

五、    TheModel全局类的用途
      TheModel全局唯一，职责如下：
•    负责应用所有定制事件的订阅/分发；
•    负责持有工具条和系统菜单属性；
•    负责持有剪贴板，实现各个画板之间的节点拷贝/剪切。

六、    ProcessDesigner与ProcessEditor
ProcessDesigner负责整个应用的布局，目前由三部分组成，系统菜单、工具条和TabNavigator（TabBar管理器），TabBar管理器负责添加和删除Tab，由Tab加载画板，这样实现对多流程定义同时编辑的支持（即多Tab）。

ProcessEditor是应用的入口，它持有ProcessDesigner，实现了IGraphicalEditor接口。目前其对graphicViewer（）方法的实现是返回当前激活状态Tab的画板。

同时，ProcessEditor负责统一监听工具条/键盘事件，并将这些事件处理委派给当前处于激活状态的Tab画板处理。

七、    Xml框架
位于org.jbpmside.xml下，使用E4X，使用binding对各种类型的节点进行解析，不集中在一个文件完成解析和转换，一个节点类型对应一个binding。使用代码如下：

   public function parse(xml:String):ProcessDefinition{
    var parser:Parser=new Parser();
    return parser.createParse().setString(xml).
          execute().getProcessDefinition() as ProcessDefinition;
}

测试代码位于test目录下，是目前唯一可以进行单元测试的部分。

八、    还需要完成的工作
1、    xml框架还需要大量的解析工作完成（以支持jpdl4）
2、    第一个版本为本地应用，需要增加对本地文件操作的支持
3、    模型迁移至org.jbpmside.model.common
4、    工具条使用flexlib重写，新的16位图标,节点属性弹出框
5、    Command目前只实现了对undo的支持，需要实现对redo的支持

ronghao 2009-09-20 21:17 发表评论

jBPM4与Spring的集成

ronghao — Mon, 22 Jun 2009 08:38:00 GMT

       现在流行抱大腿，不过对眼光的要求也高。要不就如高也，即使四眼，一样无用。对Java企业开发而言，Spring的腿则是一定要抱的。而所谓抱Spring的腿，无外乎三点：

一是通过Spring暴露出服务，将服务配置到Spring的IOC容器里；
二是在自己的运行环境里访问到Spring的IOC容器，能够轻松使用Spring容器里所配置的服务；
三是对于具有事务管理特性的项目来说，将事务管理与Spring的事务管理进行合并。

        下面分别讨论：

一、    通过Spring暴露服务
还记得在jBPM4的运行期环境里提到的JbpmConfiguration吗？它是整个jBPM4的入口，并且是整个应用独此一份的。通过它可以获取processEngine，并藉此获得工作流引擎所提供的各种服务：

ProcessEngine processEngine = new Configuration()
.buildProcessEngine();

RepositoryService repositoryService = processEngine.getRepositoryService();
ExecutionService executionService = processEngine.getExecutionService();
TaskService taskService = processEngine.getTaskService();
HistoryService historyService = processEngine.getHistoryService();
ManagementService managementService = processEngine.getManagementService();

通过Spring暴露这些服务，配置如下：

细心的你会发现，配置时使用了JbpmConfiguration 的子类SpringConfiguration。SpringConfiguration相比JbpmConfiguration有哪些增强呢，下面再讲。总之，现在，就可以使用Spring来获取或注入这些Jbpm4所提供的服务了。

二、在environment里加入SpringContext
jBPM4的environment（运行期环境）提供Engine IOC（process-engine-context）和Transaction IOC（transaction-context）。要想在运行期方便地访问到Spring里所配置的服务，最直接的方法就是在environment里加入Spring IOC（applicationContext）的引用。
SpringConfiguration即是对JbpmConfiguration增强了对Spring IOC的一个引用。

SpringConfiguration是如何做到的呢？简单，实现Spring的ApplicationContextAware接口，自动持有applicationContext，然后openEnvironment时将其加入environment。

environment.setContext(new SpringContext(applicationContext));

SpringContext是对applicationContext的简单封装。

那么什么从Engine IOC移民到Spring IOC了呢？是的，最重要的就是Hibernate Session Factory。

在jbpm.cfg.xml的process-engine-context里干掉：

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

    <hibernate-session-factory />

相关配置挪动至Spring配置文件。

三、事务
哪里有数据库操作，哪里就有事务。对于嵌入式工作流而言，最重要的集成就是事务的集成。这里先分析jBPM4的事务实现，然后再介绍集成入Spring的事务实现。

1、 Command模式
jBPM4的逻辑实现采用了Command模式。

采用Command模式后，jBPM4对CommandService构造拦截器（Interceptor）链，配置在jbpm.cfg.xml的process-engine-context里：

<command-service>
      <retry-interceptor />
      <environment-interceptor />
      <standard-transaction-interceptor />
    command-service>

2、原有的事务实现
jBPM4原有的事务通过StandardTransactionInterceptor实现，在CommandService执行Command之前打开事务（实际委派Hibernate的事务管理），完成后提交/回滚。

jBPM4的事务是基于Command的。

3、集成入Spring的事务实现
Spring的事务是基于服务调用的。

使jBPM4使用Spring提供的事务：

<command-service>
      <retry-interceptor />
      <environment-interceptor />
      <spring-transaction-interceptor current="true" />
command-service>

拦截器换用SpringTransactionInterceptor，SpringTransactionInterceptor从environment 提供的Spring IOC获取PlatformTransactionManager，使用事务模板回调Command，事务传播模式强制加入当前事务。

同时，对hibernate session的配置（jbpm.cfg.xml的transaction-context）强制从当前线程中获取：

<hibernate-session current="true"/>

并干掉原有的事务实现：

参考文档：
http://www.slideshare.net/guest8d4bce/spring-integration-with-jbpm4

ronghao 2009-06-22 16:38 发表评论

jBPM4的运行期环境

ronghao — Wed, 17 Jun 2009 10:15:00 GMT

        万物生长靠太阳，儿童的生长离不开土壤、空气和水，当然，也离不开绿坝娘的调教。应用程序也是如此，离不开数据库连接、事务、日志、消息等，这些，共同构成了应用程序的运行期环境。
        理想中的环境是什么样子的哩。好吧，一句话，召之即来，挥之即去，当需要某个服务时，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，结束。

ronghao 2009-06-17 18:15 发表评论

Jbpm4的IOC容器

ronghao — Thu, 07 May 2009 10:43: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提供数据库相关服务。

ronghao 2009-05-07 18:43 发表评论

JbpmSide介绍

ronghao — Mon, 30 Mar 2009 02:35:00 GMT

摘要: 在周末的openparty上，分享了关于JbpmSide介绍的session。主要介绍了这个项目的目标、功能规划、开发计划以及当前的进度。下面是可供下载的ppt。

JbpmSide仍然定位于一个完整的工作流解决方案。阅读全文

ronghao 2009-03-30 10:35 发表评论

JbpmSide流程设计器进度

ronghao — Thu, 26 Mar 2009 14:21:00 GMT

汇报一下设计器当前进度以及下一阶段主要的开发目标。
当前进度主要集中在图像处理方面：
    1、采用Riawave，完成了整个设计器图形处理的架构
    2、工作流节点的图形建模
    3、节点的拖拽以及连线
    4、节点、连线的剪贴、复制、删除操作，支持快捷键
    5、画板的缩放和Grid显示与否
采用的图形类库是Degrafa。
下一阶段（2-3周）会实现以下的功能：
    1、目前的连线是通过点击两个节点出现的，将支持单独的连线增加（两种形式：直线、曲线）
    2、增加不同节点对连线的约束，即开始节点只能出、任务节点单进单出等。
    3、采用flexlib实现新的设计器菜单（Tabpane形式），同时将图形模型工具条移到左侧垂直放置
    4、do/undo功能，将所有对画板的操作重构为Command模式
余下的功能包括：导出图片、打印等。
近阶段的主要任务是实现设计器的图形功能，不考虑XML的转换和建模。其中包括根据大家的反馈改变部分的现实细节。源代码将尽快放出。请关注JbpmSide。

ronghao 2009-03-26 22:21 发表评论