OSWorkflow源码分析

 OSWorkflow 的关键包组成：

-          com.opensymphony.workflow

-          com.opensymphony.workflow.config

-          com.opensymphony.workflow.loader

-          com.opensymphony.workflow.query

-          com.opensymphony.workflow.spi

这些包涵盖了OSWorkflow的使用、配置、流程定义、查询和运行时等方面内容。本节介绍这几个包，对于其他的包不涉及OSWorkflow的核心，在此不作介绍。

com.opensymphony.workflow

这个包负责与使用者的大部分交互，它定义了最常用的接口、类和异常。其中与用户使用密切相关的接口：Workflow、WorkflowContext、Validator、Register、FunctionProvider和Condition。

Workflow接口是一个Façade，通过与它交互，使用者几乎可以完全使用OSWorkflow的功能。包括：工作流使用和查询、工作流定义管理和设置工作流配置信息等。而Validator、Register、FunctionProvider和Condition提供用户自定义功能的机会，它们与用户具体定义的工作流相关，当用户定义的工作流被激活之后，这些接口的实现，也会在合适的时机被Workflow接口调用。

在这个包中，提供了关于Workflow的抽象实现：AbstractWorkflow，它也是OSWorkflow中其他工作流类的基类。这个类的实现特点是，将实际操作的方法转交给合适的类或接口，它只负责将多个有机的操作集中在一起，给用户呈现一个调用接口。如对于query方法的实现，就是直接将query的实际执行交给了WorkflowStore。这样做最大的好处是：分工明确，简化扩展。如果要改变Workflow的行为，除非是Workflow没有提供的功能（即方法），只需扩展（或实现）那些类（或接口）就可以了，而不需要从整个AbstractWorkflow开始扩展。如关于Workflow的持久化机制，OSWorkflow附带的实现类，基本都是实现WorkflowStore，而非Workflow。

AbstractWorkflow的关键方法简要说明：

1.         initialize，初始化工作流实例，并改变工作流实例的状态，将工作流实例的状态信息持久化。

2.         doAction，外部触发工作流实例进行状态改变，主要的算法：。

-          工作流实例的状态是否是actived。

-          如果是，那么获取指定的action（在全局和当前的step集合的action集合中）。

-          执行状态转换。

-          如果工作流实例没结束，检查工作流是否隐式结束，是的话则结束工作流实例。

在整个过程中，如果有异常流程实例状态信息就回滚。

3.         transitionWorkflow，执行工作流的状态改变，返回值如果是true表示工作流实例结束。这是AbstractWorkflow的核心方法，initialize和doAction都调用这个方法来改变工作流实例的状态。主要的算法：

-          如果action的validator个数>0，那么就执行那些validator。

-          如果有step，执行step的post-functions。（对于初始化，没有Step）

-          执行当前action的pre-functions

-          如果有满足条件的condition result，那么获取condition result（如果validator个数>0就执行、获取对应的pre和post functions）。

-          如果没有满足条件的condition result，那么获取unconditional result。（如果validator个数>0就执行、获取对应的pre和post functions）

-          执行result的pre function。

-          如果result中有split，那么执行split。获取split的result（如果validator个数>0就执行、获取对应的pre和post functions），并创建新步。执行split result的pre-functions，创建新步，执行split result的post-functions。

-          如果result中有join，那么在当前和历史步骤中查看符合定义的step。并在transientVars中把join steps加入，键值为"jn"。如果join的conditions为true，获取result（如果validator个数>0就执行、获取对应的pre和post functions），执行join result的pre-functions，结束其他join step，create new step和执行join result的post function。

-          如果result中不含split或join，创建新步。

-          执行result的post functions。

-          执行action的post functions。

-          如果是initialize的action，那么如果流程实例状态不是activated，就改变成activated。

-          如果action的finished属性为true，标记工作流显式结束，并返回true。

-          如果当前新步骤有auto action可用，执行它们。返回false。

4.         checkImplicitFinish，判断流程实例是否隐式结束。如果流程实例当前step集合的action集合大小为0，就把所有当前的step集合移入历史，并结束流程实例。

5.         createNewCurrentStep，创建新步。将result的old-status赋给当前步骤，结束当前步骤使之成为历史。用status作为新步的值，执行新步的pre functions。

6.         populateTransientMap，创建TransientMap。内容包括：context、entry、store、descriptor、actionId、currentSteps。同时根据register的类型，加载对应的register实现类，并调用相应的register的创建对象的方法，并将他放入map。key就是register的名字。

关于其他的方法，由于比较简单，请参见api docs或对应的源码文件。AbstractWorkflow是抽象基类，OSWorkflow提供了几个具体的子类：BasicWorkflow，OfbizWorkflow和WorkflowEJB。

WorkflowContext提供了Workflow的上下文环境，在2.7中，它只包含2个方法：getCaller获取工作流实例调用者的信息，用于权限判断；setRollbackOnly，回滚工作流状态信息。对应的实现：BasicWorkflowContext和EJBWorkflowContext。从BasicWorkflowContext可以看出，BasicWorkflow不具备事务的功能。

com.opensymphony.workflow.config

这个包与OSWorkflow的配置相关，定义了配置接口和一些基本实现。此处所说的配置是指，针对OSWrokflow的环境配置，这些配置项已经在Configuration接口中体现，如持久化机制、持久化属性集合等。而不是用户定义的工作流描述文件。在AbstractWorkflow中，获取配置信息，以及配置组件，都是使用Config接口来完成的。

在这个包中，3个java文件。其中Configuration定义了配置的接口，而DefaultConfiguration和SpringConfiguration是它的实现。对于这2个实现类，它们的基本思路都是：创建AbstractWorkflowFactory，然后将必要的操作（如获取WorkflowDescriptor）转发给这个factory实例。

在DefaultConfiguration中最关键的方法就是load，它主要目的就是加载配置文件，并初始化Factory。主要的算法：

-          打开配置文件，如果不指定配置文件，就使用osworkflow.xml。

-          如果在配置文件中没有指定factory，那么就使用默认的URLWorkflowFactory。

-          如果在配置文件中指定了factory，那么实例化它。并使用Factory的属性对它进行初始化。

SpringConfiguration，负责与spring的集成。关于与Spring的集成，请参见http://wiki.opensymphony.com/display/WF/2.3+Spring+framework。

com.opensymphony.workflow.loader

这个包与工作流定义密切相关，包含了与工作流定义中对应元素的java类，相关的factory类和一些工具类。

AbstractDescriptor是所有xml元素对应java类的基类，它的定义的方法比较简单：设置/获取ID，设置/获取父元素和是否有ID。这些都是xml元素对应java类所必需的。在这个包中，以Descriptor结尾的类，就是xml元素对应java类。这些java类都包含2个方法：writeXML，负责将类转换成为对应的xml描述；init，使用xml元素来初始化类。对于包含子元素的元素还实现了Validatable接口，实现validate方法，对元素进行验证有效性。注意：Descriptor类并不是和工作流定义的DTD一一对应的，如<pre-functions>和<post-functions>就没有具体的java类，而是直接作为集合包含在对应的使用类中。

AbstractWorkflowFactory是所有factroy基类，负责对于工作流定义的管理，以及工作流描述类（WorkflowDescriptor）的创建。Factory类对应的是配置文件中的<factory>。在OSWorkflow中，Factory的层次：AbstractWorkflowFactory（URLWorkflowFactory，XMLWorkflowFactory（JDBCWorkflowFactory））。

URLWorkflowFactory和XMLWorkflowFactory都不支持对于工作流定义的移除，而且都使用WorkflowLoader来加载指定的工作流定义。WorkflowLoader在加载的同时，分析工作流定义产生WorkflowDescriptor。

JDBCWorkflowFactory，顾名思义就是使用数据库来管理工作流定义，它支持移除工作流定义。对于它来说，这些实际就是简单的数据库CRUD操作。为了使用它，需要配置数据源属性，同时还需建立OS_WORKFLOWDEFS(WF_NAME, WF_DEFINITION)，后者将xml定义存入。对于加载工作流定义，JDBCWorkflowFactory也是使用WorkflowLoader。WorkflowLoader的职责只有一个，就是加载工作流定义，产生WorkflowDescriptor。

       关于其他类，请参见api doc和相关的源文件。

com.opensymphony.workflow.query

这个包定义OSWorkflow的查询描述，但并不执行查询操作。真正的查询操作实际是由WorkflowStore对查询描述进行转换，完成实际的查询操作。由于WorkflowQuery已经被Deprecated，在此只介绍其余的4个类。

Expression是查询表达式的基类，它有2个子类FieldExpression和NestedExpression。前者，定义条件操作（>、<、=、!=），查询域（与workflowstore相关），域的上下文（当前，历史，还是工作流实例）；后者，定义多个表达式的连接操作（and、or），组成一个大的表达式。WorkflowExpressionQuery查询表达式的容器，定义查询结果的order by和sort。

记住，这些类都只是查询的描述，而不执行查询操作。真正的查询是在WorkflowStore中完成的，这实际就是“算法与数据相分离”（查询算法和查询描述）的例子。

com.opensymphony.workflow.spi

这个包是比较底层的包，从名字spi可以推断出来。它定义了工作流的状态和状态持久化接口，以及一些基本实现。负责状态的接口是：Step，用来记录每个Step的状态；WorkflowEntry，用来记录Workflow实例的运行状态。Step的状态记录了流程实例的业务状态，即当前的实例处于整个业务流程的位置；而WorkflowEntry ，则仅仅是从流程实例控制的角度来看，记录了实例的运行状态。即是运行或挂起等，不具备业务含义。WorkflowStore是状态的持久化接口，负责状态（包括Step和WorkflowEntry）的持久化。

OSWorkflow对WorkStore提供一些缺省实现，都比较简单易于理解，在此就不做一一的介绍了。值得一提的是JDBCWorkflowStore，它是使用数据库来保存流程实例状态，对应的建表sql在目录src/etc/deployment/jdbc下。这个库有几个特点：

-          对于currentstep和historystep分别使用2个表来保存，当currentstep结束时，将它从currentstep中删除，在historystep中增加。一般都是使用（start，end）来进行区分是当前的（start不为null，end为null），还是历史的（start和end都不为null）。从程序来看，markFinished之后紧接着就马上调用了moveToHistory。因此，个人认为完全可以采用一个表的方式完成。

-          使用单独的表来记录step的先后顺序：OS_CURRENTSTEP_PREV和OS_HISTORYSTEP_PREV，而不是在step表中采用parent_id的形式。从使用上来看，采用单独的顺序表较为方便。但是采用这种方式之后，对于split和join，就无法清晰的看出父子step之间的关系。如step1 split出了那几步，或step1又是由哪几步join而来的。

对于如何配置使用这些WorkflowStore，请参见/src/test，这个目录中包含了相应的映射文件的例子。

总结

       OSWorkflow使用起来还是相对简单的，而且由于支持脚本使得在描述工作流定义时更加的方便和简单。Step - Action - Result结构，可以描述相当灵活的工作流定义。然而，由于目前的版本不支持子流程，对于一些流程描述，写起来会麻烦一些（不是不能描述）。从复用的角度来看，如果一个function（或validator等）一再出现，最好就写成java类，这样就不需要每个流程定义中都写了。

       OSWorkflow声明它并不是为了终端用户而写的，而是供编程人员使用的。虽然它也提供了gui designer，个人认为还是手写方便。另外，由于它定位为轻量级的Workflow框架，因此并不具备许多商业的Workflow的功能。如：流程监控、分析等。就其本身而言，它相当于是提供了一个工作流引擎，附带一个gui designer。