网摘 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