夜郎 / workflow / jBPM4的架构 - 51CTO.COM

分享

   

jBPM4的架构 - 51CTO.COM

2009-11-25  夜郎
    本文介绍jBPM4的架构。jBPM4架构包括API,活动API,事件监听API,客户端API,环境,命令,服务等。

     

    4.1. APIs

    流程虚拟机包含4个集成的API,在不同的执行模式下, 覆盖完整的流程工作。 每个API都有特定的目的, 满足下面的架构。
    流程虚拟机中的4个API

    流程虚拟机中的4个API 

    图 4.1. 流程虚拟机中的4个API

    服务接口用在应用代码中,与流程虚拟机进行交互, 它将运行在支持事务的持久化模式下,后端基于数据库。 这是用户将PVM作为一个工作流引擎使用的最常用的方式。

    如果不想使用持久化方式执行流程,可以直接使用客户端API来处理流程和执行对象。 客户端API对外暴露了核心模型对象的方法。

    活动API用来实现活动在运行时的行为。 因此一个活动类型实际上是一个组件,核心是实现了ActivityBehaviour接口。 活动行为实现可以控制执行的流程。

    事件监听器API用来编写java代码,它可以用来处理流程事件。 它比活动API类似, 唯一的差别是事件监听器不能控制执行的流程。

    4.2. 活动API

    活动API允许使用java实现运行时的活动行为。

            
    1. public interface ActivityBehaviour extends Serializable {   
    2.   void execute(ActivityExecution execution) throws Exception;   

    一个活动就是分配给活动的一些行为。 提供的执行就是到达这个活动的执行。 ActivityExecution接口 暴露了控制执行流程的方法。

            
    1. public interface ActivityExecution extends OpenExecution {   
    2.  
    3.   void waitForSignal();   
    4.   void take(String transitionName);   
    5.   void execute(String activityName);   
    6.  
    7.   ...   
    8.  
    9. }   

    4.3. 事件监听API

    事件监听API允许使用java开发监听器, 并在特定的流程事件发生时调用,像进入一个活动或离开一个活动。 它与活动API类似, 不同的是不能控制执行流程的传播。 比如,当一个执行选择了一个转移,一个对应的监听器会被激活, 但是因为这个转移已经被选择了, 执行的流程无法被事件监听器改变。

            
    1. public interface EventListener extends Serializable {   
    2.  
    3.   void notify(EventListenerExecution execution) throws Exception;   
    4.  
    5. }   

    4.4. 客户端API

    客户端API是一套暴露了相关方法的接口, 它用来直接管理流程定义上的执行和执行对应。

    最小的需求,客户端API和活动API需要使用活动创建 流程定义并执行它。

    4.5. 环境

    在持久化执行环境下,环境的第一目的 是让流程在不同的事务环境下执行, 比如Java标准版,Java企业版,SEAM和Spring。

    PVM代码自身只通过自身定义的接口来调用事务资源。 比如,PVM自身拥有一些建立在hibernate会话,异步消息会话 和定时任务会话的接口方法。

    环境允许为其配置真实的实现, 在请求的基础上实现服务的延迟加载, 为事务的持续获得服务对象。

    一个环境工厂是静态的,一个环境工厂 提供应用中的所有线程。

            
    1. EnvironmentFactory environmentFactory = new PvmEnvironmentFactory("environment.cfg.xml");  

    环境部分可以像这样 围绕在持久化流程操作周围:

            
    1. Environment environment = environmentFactory.openEnvironment();   
    2. try {   
    3.  
    4.   ... inside the environment block...   
    5.  
    6. finally {   
    7.   environment.close();   
    8. }   

    PVM自身会从环境中获得所有事务资源和配置。 Activity实现 也可以做同样的事情。

    org.jbpm.pvm.internal.cfg.JbpmConfiguration 这个类扮演着Configuration, ProcessEngine和EnvironmentFactory三个角色。

    4.6. 命令

    命令封装了将被运行在环境块中的操作。 命令的主要目的是获得逻辑。

            
    1. public interface Command< T> extends Serializable {   
    2.  
    3.   T execute(Environment environment) throws Exception;   
    4.  
    5. }   

    4.7. 服务

    这里有三个主要服务:RepositoryService, ExecutionService和ManagementService。 通常来说,服务是会话外观,用来暴露PVM持久化应用的方法。 下一部分用例子展示 这些服务中的基本方法。

    RepositoryService管理 流程定义的资源。

            
    1. public interface RepositoryService {   
    2.  
    3.   Deployment createDeployment();   
    4.  
    5.   ProcessDefinitionQuery createProcessDefinitionQuery();   
    6.  
    7.   ...   
    8.  
    9. }   
    10.  
    11. ExecutionService管理 运行时的执行。   
    12.  
    13. public interface ExecutionService {   
    14.  
    15.   ProcessInstance startProcessInstanceById(String processDefinitionId);   
    16.  
    17.   ProcessInstance signalExecutionById(String executionId);   
    18.  
    19.   ...   
    20.  
    21. }   
    22.  
    23. ManagementService包含了所有管理操作 来保持系统启动运行。   
    24.  
    25. public interface ManagementService {   
    26.  
    27.   JobQuery createJobQuery();   
    28.  
    29.   void executeJob(long jobDbid);   
    30.  
    31.   ...   
    32.  
    33. }   

    所有这些方法都封装成Command。 这三个服务执行的方法 都委派给一个CommandService:

            
    1. public interface CommandService {   
    2.  
    3.   < T> T execute(Command< T> command);   
    4.  
    5. }   

    CommandService被配置到环境中。 一个CommandService链可以看做环绕在一个命令周围的一些拦截器。 这就是如何在不同的环境下 进行持久化和事务支持的核心机制。

    默认的配置文件jbpm.default.cfg.xml 包含了下面的配置服务。

            
    1. < jbpm-configuration>   
    2.  
    3.   < process-engine>   
    4.  
    5.     < repository-service />   
    6.     < repository-cache />   
    7.     < execution-service />   
    8.     < history-service />   
    9.     < management-service />   
    10.     < identity-service />   
    11.     < task-service />   

    文件 jbpm.tx.hibernate.cfg.xml包含了 下面的command service配置:

            
    1. < jbpm-configuration>   
    2.  
    3.   < process-engine-context>   
    4.     < command-service>   
    5.       < retry-interceptor />   
    6.       < environment-interceptor />   
    7.       < standard-transaction-interceptor />   
    8.     < /command-service>   
    9.   < /process-engine-context>   
    10.  
    11.   ...   

    这些服务,比如repository-service,execution-service 和management-service将按照类型找到配置好的command-service。 command-service标签符合默认的命令服务, 基本上什么也不做, 只是在提供给它的环境上执行命令。

    配置的command-service结果, 在默认的命令执行期下面的三个拦截器链中。
    CommandService拦截器

    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上。

    ◆把命令打包成一个异步消息, 这样命令会异步执行在一个不同的事务中。

    【编辑推荐】

    1. Liferay Portal中的jBPM配置
    2. 简单介绍jBPM与SSH的完整实例
    3. 使用JBPM工作流引擎测试的一个例子
    4. JBPM工作流引擎使用环境的搭建
    5. 浅谈jBPM下MySQL的配置

    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多
    喜欢该文的人也喜欢 更多

    ×
    ×

    ¥.00

    微信或支付宝扫码支付:

    开通即同意《个图VIP服务协议》

    全部>>