activiti学习资料(Activiti Initiative)

Activiti Initiative  

言归正传吧，今天是第一篇blog，说说新的workflow Engine吧 -- Activiti。这是Tom Baeyens离开JBoss之后自己继续开发的一款BPM Engine。他为了表示这是从jBPM的延续，可能今年11月份正式发布版本时将会直接使用5.0这个版本号。

    因为工作的原因，被要求跟踪一下工作流的情况，正好赶上Activiti的Initiative，所以决定好好follow一下。小自我膨胀一下，花了大概两个礼拜的时间，注意，是整整两个礼拜，算上白天晚上的时间哦，大概看完了Activiti 60% -- 70% 的源码，一些知识跟大家分享一下，也希望自己提出建议的时候能听到JavaEyers的意见和指责，前进共勉。
    今天先做个简单介绍，看完世界杯后接着写。
    作为一个工作流引擎，WfMC(Workflow Management Coalition)有它自己标准的定义；但是做为一个User和Developer，知道标准固然好；更重要的，你必须知道你现在正在使用的这款产品(或者框架)的正确组件和典型特点。
    Activiti从jBPM继承而来，固然有着和jBPM相似的结构和组件；但是从我跟踪Activiti的User和Developer论坛情况来看，说实话，一些使用英语的老外好像都没搞清楚到底Activiti中目前有哪些组件，各个组件到底用来做什么。说实话，我觉得这个很重要，因为一个框架的整体蓝图，就好像打仗中的整体战略，会对你灵活而自主的执行战术产生很大的影响；知道了战略，你会在战术时知道Why or Why not，从而自信和自主的决定什么时候按照标准(框架提供的API/SPI)执行，什么时候该将在外而军令有所不受(需要Hack源代码，以扩展包的形式自定义你的特殊需求)。
    对于Activiti，它目前具有4个关键组件(截止到最新的5.0-alpha3版本)：
    1.流程引擎。
      作用：运行时核心组件，解析流程定义文件(.bpmn20.xml文件)，将其转化为纯粹的内存Java对象，以供运行时各个功能使用；
      表现为：jar包（activiti-engine-5.0.alpha3.jar）；
      使用：部署在应用服务器/Servlet容器的运行时类路径中(如：Tomcat的lib中)
      级别：最核心组件，建议所有扩展都另行打包，并且在你确实了解Activiti源码后进行
    2.管理员控制台（activiti-probe）
      作用：供系统管理员了解Activiti底层数据库目前的情况。
      表现为：war包（activiti-probe.war）
      使用：部署在应用服务器/Servlet容器的web应用目录下（如：Tomcat的webapps）
      级别：应用层的核心组件。但目前功能十分有限，如：不能监控流程执行的动态情况，无法知道流程目前执行到哪个节点，无法人为调整/干预流程的执行状态等；无法提供统计信息，或者基于统计，给出流程可优化信息等。无日志。
    3.用户控制台（activiti-explorer）
      作用：供普通用户真正使用Activiti流程引擎功能
      表现为：war包（activiti-explorer.war）
      使用：部署在应用服务器/Servlet容器的web应用目录下（如：Tomcat的webapps）
      级别：应用层核心组件。供用户可以开始、申请以及完成一个个工作流具体内容。目前支持流程中嵌入表单，表单中含有参数等。即：用户可以在此管理自己的To-Do List内容
    4.业务流程建模工具（activiti-modeler）
      作用：供业务人员通过图形界面建立需要的业务流程模型。
      表现为：war包（activiti-modeler.war）
      使用：部署在应用服务器/Servlet容器的web应用目录下（如：Tomcat的webapps）
      级别：应用层重要组件。可以供企业内所谓的业务分析员通过图形界面快速直接的建立自己的业务流程模型，以便后用。目前该组件由Signavio独立提供。
    直观效果：

         

    最后，将来会有一个组件叫做 activiti-cycle，是用来给所谓的技术人员、业务人员和终端用户协同工作用的。具体的截图可以看看这里：http://activiti.org/cycle.html

    说了这么多了，为什么会先明确组件的划分；如果用过Activiti或者jBPM的同学一定明白，这些BPM引擎的标准使用方法是通过自带的Ant脚本构建完成，如果你需要在你的特殊环境里灵活使用的话，一是建议好好看看Ant的那个构建脚本；二是你总得知道构建脚本中每个Target是干什么的吧。如果想知道脚本每步在干什么，你就得知道这些BPM Suite都含有哪些组件，那么才会明白脚本中每一步是把哪个组件拿来做什么部署或者使用了；这样你才会根据你的需求，大胆而自信的裁剪你自己需要的ant构建脚本，成功测试后来满足一下你那小小的虚荣心和成就感。 哈哈

    自我感觉：初次使用时最困惑的其实不是各个组件都表现为什么形式，被放在了运行时环境的什么地方，起了哪些作用；而是引擎相关文件（jPDL or Bpmn20）是如何被各个组件所感知的？！流程定义文件的部署到底干了什么，是一个怎样的过程，独立么？