先讲讲JDBCWorkflowStore：

首先理解一下osworkflow的表结构，在你所下载的压缩包里有个src\etc\deployment\jdbc目录，在这个目录下面有常用的各种数据库的ddl。       这是osworkflow内置的表结构。基本上就是这个类来对osworkflow的这个内置表进行实际操作的。

这个类里的方法众多，而且基本就是对数据库的基本操作的各种各样的方法，当然这里结合了工作流的知识，如针对step的某些有意义数据库操作，大致情况就是这样的。

如query方法的具体的jdbc方式的实现就在这里的。  

MySQLWorkflowStore继承自JDBCWorkflowStore，另外重写了两个方法init和getNextStepSequence。在这里可以写针对自己需要用到的workflowstore，只要继承自JDBCWorkflow，并写重写必要的方法满足自己的实际需求即可。

在我的上一篇blog中持久化jdbcstore中的osworkflow.xml中有相应的对jdbcstore的存储范例。

com.opensymphony.workflow.spi.hibernate

**

这个包里主要是osworkflow提供对hibernate支持。

首先来看一下HibernateWorkflowStore类。

首先来看一下类注释：

/**

 * A workflow store backed by Hibernate for persistence. To use this with the standard

 * persistence factory, pass to the DefaultConfiguration.persistenceArgs the SessionFactory to

 * use:

 * <code>DefaultConfiguration.persistenceArgs.put("sessionFactory", DatabaseHelper.getSessionFactory());</code>

 * See the HibernateFunctionalWorkflowTestCase for more help.

 *  

 * @author $Author: hani $

 * @version $Revision: 1.18 $

 */

大致意思是说，以hibernate作为工作流的持久存储，为了使用标准的持久工厂即sessionfactory，在测试类HibernateFunctionalWorkflowTestCase里有较为完整的代码。其中借助的是DefaultConfiguration.persistenceArgs.put("sessionFactory", DatabaseHelper.getSessionFactory())。然后在DefaultConfiguration的getWorkflowStore获取workflowstore对象的时候，会调用store.init(getPersistenceArgs());实际执行的代码为：

sessionFactory = (SessionFactory) props.get("sessionFactory");

session = sessionFactory.openSession();

则可获得到session对象。

简单的可以理解为，put，然后store的init，最后get出就可以得到。而真正的创建sessionfactory是自己来完成，如上面是在DatabaseHelper类中的createHibernateSessionFactory方法创建出实际的sessionfactory。

从osworkflow自己带的测试类HibernateFunctionalWorkflowTestCase中的setup方法中可以看出

super.setUp();

        DatabaseHelper.createDatabase("");

        factory = DatabaseHelper.createHibernateSessionFactory();

        Configuration config = new DefaultConfiguration();

        config.load(getClass().getResource("/osworkflow-hibernate.xml"));

        workflow.setConfiguration(config);

        workflow.getConfiguration().getPersistenceArgs().put("sessionFactory", factory);

核心的实现方法在DatabaseHelper 类中的createHibernateSessionFactory方法。有兴趣的可以到这些测试代码中看一下具体是如何实现的。

其实大不可不必，如过你想要让HibernateWorkflowStore自己具有产生sessionfactory的功能，只要按照hibernate正常的生成办法写到HibernateWorkflowStore里就可以了。

我想如果要是想更方便的话可以通过在HibernateWorkflowStore内部生成HibernateWorkflowStore，既然osworkflow的作者不让在自己内部产生sessionfactory，她可能认为这个是用户自己的事，而不是osworkflow的事。那作为我们使用，我想可以更为方便点的修改它的源代码来达到这一目的。

private static SessionFactory sessionFactory;

  //~ Constructors ///////////////////////////////////////////////////////////
  static{
   try {
     sessionFactory = new Configuration().configure().buildSessionFactory();
   } catch (HibernateException ex) {
      throw new RuntimeException("Configuration problem: " + ex.getMessage(), ex);
    }
   }

二是在init中

  把sessionFactory = (SessionFactory) props.get("sessionFactory");注释

  编译,生成class,放到osworkflow-2.7.0.jar,取代原来的HibernateWorkflowStore.class

上面讲的都是hibernate的sessionfactory相关的东西。

其实每个方法如果需要解析的都会写出这么多内容的，而到底是应该掌握一个什么样的学习方法呢？我想我还是在思考。也许是看多了就眼明手亮了。

其实最让我觉得不爽的地方就是这个osworkflow的作者的代码里注释量基本为0。不知道是什么原因。

HibernateStep和HibernateHistoryStep和HibernateCurrentStep、HibernateWorkflowEntry基本没什么可说的，就是一些普通的get和set方法。

SpringHibernateWorkflowStore类：

Osworkflow支持以下的持久化：MemoryStore (default), SerializableStore, JDBCStore, OfbizStore, and EJBStore.

【环境】
WIN2000
Osworkflow 2.7.0
Tomat 5.0.25
Mysql 4.1.7-nt + mysql-connector-java-3.0.15-ga-bin.jar

以下是使用MYSQL来进行持久化，支持文档是OSWF的手册的1.4 Persistence Options.html。里面建议用的是HypersonicSQL.

【步骤一：】建库

在MYSQL里建立一个DB命名为osworkflow
执行压缩文件src/etc/deployment/jdbc里面的mysql.sql建表。

【步骤二：】在TOMCAT里建立一个Datasource,命名为jdbc/oswf

1)Tomcat的admin中的DataSource中配置一个DataSource jdbc/oswf
2)$CATALINA_HOME/conf/catalina/localhost/$appname.xml中配置一个resource link

【步骤三：】修改osworkflow.xml

<osworkflow>
<!--
    <persistence class="com.opensymphony.workflow.spi.memory.MemoryWorkflowStore"/>
-->
<persistence class="com.opensymphony.workflow.spi.jdbc.MySQLWorkflowStore">

 <property key="datasource" value="jdbc/oswf"/>
 <property key="entry.sequence"
                      value="SELECT max(id)+1 FROM OS_WFENTRY"/>
 <property key="entry.table" value="OS_WFENTRY"/>
 <property key="entry.id" value="ID"/>
 <property key="entry.name" value="NAME"/>
 <property key="entry.state" value="STATE"/>
 <property key="step.sequence"
                       value="SELECT max(ID)+1 FROM OS_STEPIDS"/>
                      
 <property key="step.sequence.increment"
     value="INSERT INTO OS_STEPIDS (ID) values (null)"/>
   <property key="step.sequence.retrieve"
     value="SELECT max(ID) FROM OS_STEPIDS"/>                      
     
 <property key="history.table" value="OS_HISTORYSTEP"/>
 <property key="current.table" value="OS_CURRENTSTEP"/>
 <property key="historyPrev.table" value="OS_HISTORYSTEP_PREV"/>
 <property key="currentPrev.table" value="OS_CURRENTSTEP_PREV"/>
 <property key="step.id" value="ID"/>
 <property key="step.entryId" value="ENTRY_ID"/>
 <property key="step.stepId" value="STEP_ID"/>
 <property key="step.actionId" value="ACTION_ID"/>
 <property key="step.owner" value="OWNER"/>
 <property key="step.caller" value="CALLER"/>
 <property key="step.startDate" value="START_DATE"/>
 <property key="step.finishDate" value="FINISH_DATE"/>
 <property key="step.dueDate" value="DUE_DATE"/>
 <property key="step.status" value="STATUS"/>
 <property key="step.previousId" value="PREVIOUS_ID"/>
</persistence>   

    <factory class="com.opensymphony.workflow.loader.XMLWorkflowFactory">
        <property key="resource" value="workflows.xml" />
    </factory>
</osworkflow>

【步骤四：】添加propertyset.xml文件到WEB-INF\classes下。

<propertysets>
    <propertyset name="jdbc"
      class="com.opensymphony.module.propertyset.database.JDBCPropertySet">
        <arg name="datasource" value="jdbc/oswf"/>
        <arg name="table.name" value="OS_PROPERTYENTRY"/>
        <arg name="col.globalKey" value="GLOBAL_KEY"/>

Osworkflow的韧性：

可以把osworkflow看做一个低层次的工作流实现。在其他工作流系统中像loops和conditions这样的情况可以以图形图标形式展现出来，在osworkflow中必须进行编码。就是说最起码的脚本语言必须来如此设定。所以并不希望非技术人员来修改工作流。尽管一些系统提供了GUI操作来完成简单的工作流编辑，但是这种做法并不是十全十美的，如当这样改变流程后，此工作流周边的应用往往被破坏。所以osworkflow始终认为最好的变更控制办法就是以开发人员（前提：熟知每个变化）来做这些操作。Osworkflow在2.5.0版本就开始支持图形操作（designer），2.6.0和2.7.0做了许多改进。打算在3.0中正式推出。所以现在在使用GUI操作时候还是需要进行一些适当的预防手段的。

Osworkflow内部使用的是有限状态机的概念（对于这部分理解不好的，可以参看UML中的状态图部分，就可以有个初步理解）。每个状态都是通过一个step ID和一个状态来共同描述的。一个变迁（从一个状态到另外一个状态）只有在一个action发生的前提下才会被触发。在一个工作流的生命周期中始终会有一个或多个活动的状态。简单的讲就是以工作流引擎和简单xml为基础来完成商务工作流过程处理。

先决知识准备部分：

Osworkflow包括：

Oscore 2.0.1+

Propertryset 1.2+

Jakarta commons-logging

Beanshell（可选）

BSF（可选）

EJB接口（并不是一定要在EJB container中）

Xml解析（在jdk1.4中并不是必须的）

Osworkflow 的api部分将会支持jdk1.3+。GUI designer部分需要1.4的JVM。

关于soap和工作调度：GLUE部分（我还没接触过，不敢乱讲，大家看原英文解释部分吧。）大致意思是说如果需要soap或者远程作业调度支持的，就需要下载GLUE专业库。另外还有就是Quartz来支持。如果在应用服务器上run Quartz，那么就经过适当配置就不再需要GLUE了，但是必须把作业调度的local参数设置为true。

运行例子：

简单的部署没有什么特别说。仅仅把osworkflow所带的例子拷贝到tomcat（举例）的webapps下就可以了。所带的这个例子不需要配置什么DB，当然也就做不了持久性处理（即所有的所有都没存储到实际数据库中。）当然这并不是实际应用当中所想见到的，这个例子的意义就在于简单的理解osworkflow。

对于进行持久数据存储的例子在英文原件中有，我就不复制粘贴过来了。大家自己去看就可以了。具体都是如何修改配置文件，如果tomcat的server.xml文件，以及必要的jar拷贝工作。这些实际应用的例子会在后继文档中也许会有阐述，如果特别简单就不多写这方面东西了。感觉上不会复杂。呵呵^_^

持久存储：

Osworkflow共提供了五种存储机制：memorystore（默认）自带的例子就是如此，SerializableStore,JDBCStore,ofbizstore,和EJBStore.如果上述这些都没满足您的要求，那就得自己来实现osworkflow的接口com.opensymphony.workflow.spi.workflows了。具体看api吧。本文只是入门篇，大致知道有这么一回事的。

不同的存储实现需要不同的配置设置工作。推荐大家看api（此部分）来完成配置。原文中给出了JDBC的配置例子：

请参看原文。

工作流定义部分：

Osworkflow 尽最大可能使用配置来保证灵活度。仅一个文件osworkflow.xml需要在classpath中。这个文件设置了持久存储的方法（jdbc,ejb,ofbiz），工作流工厂类被用来加载工作流定义内容。

默认的工厂是：com.opensymphony.workflow.loader.xmlworkflowfactory。从classpath中加载文件。

在测试的时候，更改工作流定义文件然后重新加载它，你可以通过一个reload参数来指定是否完成自动重载。如果想指定自己的工作流定义，需要继承com.opensymphony.workflow.loader.Abstractworkflowfactory。然后剩下的就是你自己的任务了。

com.opensymphony.workflow.loader.JDBCWorkflowFactory是一个选择工厂，他允许你存储工作流定义为数据库内容而不是在xml文件中。

一般配置如下：

osworkflow.xml: <osworkflow>  <persistence class="com.opensymphony.workflow.spi.jdbc.JDBCWorkflowStore">     <arg name="foo" value="bar"/>     ...  </persistence>  <factory class="com.opensymphony.workflow.loader.XMLWorkflowFactory">     <property key="resource" value="workflows.xml" />  </factory> </osworkflow>

workflows.xml: <workflows>  <workflow name="example" type="resource" location="example.xml"/> </workflows>

       既然说到工作流，那么肯定会涉及到“任务交给谁做”的问题。但是OSWorkflow压根就没有管这种需求，对于其来说，其提供了c和f，如果再有什么额外的需求和功能，那么就扩展condition或function。于是，你不得不扩展一些function类去处理“角色”“任务分配”“提交任务”等等诸如此类的操作。

       在我的标题中提到了workitem，这个概念几乎在其他工作流引擎都有所体现，但是对osworkflow来说，这是一个空白区域。至于workitem的含义，请参考wfmc的《Terminology & Glossary》。

       OSWorkflow引擎只负责了“流程的运转”，当然这个运转会根据你所定义的Action和condtion来判断。Funtion对osworkflow来说，只是step、action、result执行过程需要调用的功能，至于这个功能作什么，OSWorkflow并不关心，引擎只是负责提供几个参数接口。

       所有的Function实现类都必须实现这个FunctionProvider接口中execute方法，而且能够处理的信息，也全部来自这个方法中的三个参数：

      




       具体transienVars中包含哪些对象，请参考 FunctionProvider api doc。

       下面就说说如何利用Function进行任务的分配。

       个人建议你在Step的pre-function中做处理，配置如下：

看了这个配置形式，我想大家应该明白如何去处理。你可以在function中获取自己所定义的角色、根据角色获取人员、根据人员产生workitem······ 。你在function 所作的这一切操作对osworkflow engine来说都是透明的—— 你所产生的worklist所代表的含义只有你自己知道。

其中我为什么会附加了一个arg属性：actionID？这是因为我需要告诉每一个workitem在其应该处理哪一个动作。 因为外部程序都是通过Workflow.doAction(long, int, java.util.Map) 这个接口来激活流程的运转或改变实例的状态。

总体来说，利用osworkflow去实现一个完整的工作流例子，还是比较麻烦的。主要是要扩展和自己实现的太多。

在osworkflow中最最核心的东西就是工作流定义的xml文件。尽管它并不是一定要定义成xml文件。但是xml格式是一种标准的通用的格式。

这个xml文件为某一个给定的工作流进行描述steps、states，transitions，和functionality。下面阐述一下此xml的一般规则：

1、 一个工作流由多个steps组成

2、 对于每个step，可以包括多个actions。一个action可以被设置成自动运行或者需要通过人工交互才可以运行。

3、 每个action都要包括至少一个unconditional result和0或多个conditional results。

4、 如果设定了多个concitioanl results，所有当中的第一个将被执行，如果没有设定conditional results或者没有conditions满足，那么执行unconditional result

5、 一个result过后可能依旧停留在当前的step中，一个新的step，一个split，一个join。在所有的情形中，工作流的state跟着变化（例子工作流中的states分别为：Underway,Queued,和finished）

6、 如果一个result引起一个split，这个result会指定split的属性，以指向一个split元素。

7、 一个split可以有一个或者多个unconditional results，但是没有conditional results。Unconditional results。Unconditional results需要指定steps。

8、 一个propertyset是一个持久层数据的map，在全局应用中都是可用的。

9、 还有一种叫做transientVars的map，它只存活于一个工作流调用过程中的一定的生命周期，它将会对所有functions和conditions，包括所有的registers，user input，以及工作流上下文状态等起作用。

工作流概念：

下面开始理解osworkflow的核心概念：

对于step，status，actions部分就不多说明了，其实我觉得理解概念的最快方法应该是参照实例，即使我们不能用高高大大的词汇描绘出来，能自己理解是什么意思就可以了。

Unconditional result 和 conditional results

这里做以简单介绍，对于每个action，要求至少存在一个Unconditional result，一个result也就是通过一系列指示来告诉osworkflow下一步的任务是干什么。这种调用使得产生变迁进而从一个state到另外一个state。这种概念是在UML的状态机里有讲，希望了解状态机相关概念的可以到UML相关书籍中查看。

Conditional result是unconditional result的一种扩展。不同的地方在于他需要一些子元素：condition。用and 和 or来标志各个condition之间的关系。

Conditional 和unconditional 的最终result可以产生三种效应或者说是结果：

1、 一个新的step/status

2、 一个split，出现一或多个step/status

3、 一个join，一个新的step/status

普遍的，一个split或者join不能result出另外一个split或join。

一个step/status result可以按下面方式简单的设定：

<unconditional-result old-status="Finished" step="2"

                      status="Underway" owner="${someOwner}"/>  

从一个state split 到多个 states可以按以下方式达到：

<unconditional-result split="1"/>

...

<splits>

 <split id="1">

    <unconditional-result old-status="Finished" step="2" 

                          status="Underway" owner="${someOwner}"/>

    <unconditional-result old-status="Finished" step="2" 

                          status="Underway" owner="${someOtherOwner}"/>

 </split>

</splits>

Joins是比较复杂的用例。一个典型的join看起来大致如下：

<!-- for step id 6 ->

<unconditional-result join="1"/>

...

<!- for step id 8 ->

<unconditional-result join="1"/>

...

<joins>

 <join id="1">

    <join id="1">

    <conditions type="AND">

      <condition type="beanshell">

        <arg name="script">

          "Finished".equals(jn.getStep(6).getStatus() 

          && "Finished".equals(jn.getStep(8).getStatus())

        </arg>

      </condition>

    </conditions>

 </join>

 <unconditional-result old-status="Finished" status="Underway" 

                                 owner="test" step="2"/>

 </join>

</joins>

上面这段代码中最需要关心的就应该是jn。当join实际发生的时候，这个特殊的变量jn可以被用来建立表达式。本质上，可以很容易理解出这个段xml的意思就是：当step6和8都finish时候在此处进行join。

Functions部分：

Osworkflow用function来定义商业逻辑和一些需要定义执行的服务。用functions标签来表示。

两种functions（pre和post）

Pre 是在工作流进行某个变迁之前需要被执行的。一个比较好的例子：为了在result中state变更产生，而先建立caller。

Post是在之后执行的。如当某一个state改变后，发送一email到某处。

Functions可以在两个分别的地方被指定：steps和actions。

Trigger Functions

Validators

Registers

一个function：用来返回一个用以被其他普通对象能够容易访问得到的对象。尤其是指workflow 的实体类。返回的对象类型不闲典型的例子如：document，metadata，issue，task等。非常便利。

<registers>

       <register name="doc" class="com.acme.DocumentRegister"/>

</registers>

...

<results>

       <result condition="doc.priority == 1" step="1" status="Underway" 

                  owner="${someManager}"/>

       <unconditional-result step="1" status="Queued"/>

</results>

Conditions

变量

授权与限权

自动执行的action

设置auto=true

Common and global actions：

Common和globalactions的主要作用在于在工作流定义文件中能够避免代码重复。

基本思想就是简单。这两种actions是在最开始就进行说明的，在initial-actions元素后面。

这两处还不能完全理解好！

Common actions：在最开始定义好，可以在其他地方如此引用

<common-action id="100" />

例如一个“send mail”的action

Global actions：不同之处在于显式的被某一个step引用。它通常对所有的steps都是可用的。一个例子：“终止工作流”，在任何一步，都有可能终止工作流。

需要注意的是：这两种actions要具备唯一的ID，而不能和其他action的ID重复。

接下来主要讲解关于function的四种情况：

osworkflow中的function就是可以在变迁之前或者后进行执行的内容。

1、 基于java的functions

从classloader中加载java 类，通过jndi找会java类，远程ejbs，本地ejb。

这一类型的function必须实现接口：com.opensymphony.workflow.FunctionProvider，在这个接口中有一个方法execute。这个方法（execute）需要三个参数

可以自己去查api即可找到这三个参数，两个map一个propertyset

基于java的functions在以下类型是可用的。

（1）、class

对于一个class function，classloader必须能够知道你的function的类名。如下：

<function type="class">

      <arg name="class.name">com.acme.FooFunction</arg>

      <arg name="message">The message is ${message}</arg>

</function>

（2）、jndi

jndi function与 class想类似，当然必须已经确实存在于jndi树中，在这里，需要一个jndi.location来进行配置：

<function type="jndi">

      <arg name="jndi.location">java:/FooFunction</arg>

      <arg name="message">The message is ${message}</arg>

</function>

（3）、remote-ejb

这部分跳过

<function type="remote-ejb">

      <arg name="ejb.location">java:/comp/env/FooEJB</arg>

      <arg name="message">The message is ${message}</arg>

</function>

(4)、local-ejb

跳过

<function type="local-ejb">

      <arg name="ejb.location">java:/comp/env/FooEJB</arg>

      <arg name="message">The message is ${message}</arg>

</function>

2、 beanshell function

osworkflow支持beanshell，这是一种脚本语言。可以在http://www.beanshell.org/来查看beanshell的相关内容。

在这种情况下，需要将xml过程定义中的type设置成beanshell。另外还需要有个一个参数名字为script的参数，此参数值是实际需要被执行的。

例如：

<function type="beanshell">

      <arg name="script"> 

            System.out.println("Hello, World!");

      </arg>

</function>

三种变量：entry，context，store

entry：实现com.opensymphony.workflow.spi.WorkflowEntry并且表示工作流实例。

Context：com.opensymphony.workflow.WorkflowContext。允许beanshell functions回滚事务或者确定caller的name

Store：com.opensymphony.workflow.WorkflowStore。允许function访问工作流的持久存储层。

<function type="beanshell">

      <arg name="script"> 

            propertySet.setString("world", "Earth");

      </arg>

</function>

<function type="beanshell">

      <arg name="script"> 

            System.out.println("Hello, "+propertySet.getString("world"));

      </arg>

</function>

输出结果是“hello，earth”因为任何存储在propertyset中的变量将可以在整个工作流中被持久使用。

3、 BSF function(perlscript, vbscript, javascript)

除了上面说过的两种type的function。还有bsf类型的function。

BSF（bean scripting framework）是IBM的一个组织做的一个通用环境可以使用VBScript, Perlscript, Python, and JavaScript

<function type="bsf">

      <arg name="source">foo.pl</arg>

      <arg name="row">0</arg>

      <arg name="col">0</arg>

      <arg name="script">

            print $bsf->lookupBean("propertySet").getString("foo");

      </arg>

</function>

个人觉得这部分可以先跳过去，知道有这么一回事就可以了。

4、 Utility Function

可以到api的com.opensymphony.workflow.util这部分查看。下面只是列出一些主要的功能。相当于java.util里的东西。

主要用于创建动态的工作流定义，主要是包括一些实用功能，如caller、webworkexecutor、ejbinvoker、jmsmessage、mostrecentowner、schedulejob、unschdulejob、sendmail。

这部分碰到不懂就去查api是个好办法，这里就不去多写的。

validators:

与functions类似，osworkflow有下面几种不同形式的validators：java-based，beanshell，和bsf。Java-based的validators必须实现com.opensymphony.workflow.Validator接口（如果是remote-ejb，则需实现com.opensymphony.workflow.ValidatorRemote接口）。Java-based这种情况是通过抛出个InvalidInputException异常表明一个输入是不合法的，并且停止工作流action。

在beanshell和bsf中，有一点小小不同，即使异常可以在脚本中抛出，但是不能抵达到jre。所以在beanshell和bsf中用错误信息来完成。逻辑如下：

u       如果返回值是一个InvalidInputException对象，这个对象立刻抛出到client。

u       如果返回值是一个map，map被用做一个error/errormessage对。

u       如果返回值是一个String []，偶数字被做为key。奇数做为value来构造一个map

u       其他情况，把值转换成string并且作为一个普通的错误信息来添加。

Registers:

Register是一个在工作流定义文件中用来动态注册的运行时（块）

它也是和validators，functions差不多，都是能够以java-based，beanshell和bsf不同格式出现。

Conditions:

Conditions与osworkflow小小不相似之处在于：在bsf或者beanshell脚本中，有一个额外的对象叫做“jn”。这个jn来源于com.opensymphony.workflow.joinnodes。它的作用就是连接条件（join-conditions）。除此之外，condition必须有一个返回值（true or false）。

Condition必须被conditions包含成为其子元素。Conditions有一个属性type。可以为and或者or。And表示：所有condition元素必须都为true或者false。Or表示只要有一个condition元素为true。如果你需要更多复杂的condition逻辑。可以考虑实现condition或者conditionremote接口，beanshell，bsf。如果只有一个condition子元素的时候，conditions的type属性值可以省略。

在2.7中。可以嵌套conditions，这样可以让你实现更为复杂的商业逻辑。

下面是一个写标准的conditions

OSUserGroupCondition、StatusCondition、AllowOwnerOnlyCondition、DenyOwnerCondition

Soap支持，暂时略！因为暂时可能涉及不到！

Gui Designer部分略。

这篇指导资料的目的是介绍OSWorkflow的所有概念，指导你如何使用它，并且保证你逐步理解OSWorkflow的关键内容。

本指导资料假定你已经部署OSWorkflow的范例应用在你的container上。范例应用部署是使用基于内存的数据存储，这样你不需要担心如何配置其他持久化的例子。范例应用的目的是为了说明如何应用OSWorkflow，一旦你精通了OSWorkflow的流程定义描述符概念和要素，应该能通过阅读这些流程定义文件而了解实际的流程。

本指导资料目前有3部分：
1. 你的第一个工作流
2. 测试你的工作流
3. 更多的流程定义描述符概念

1. Your first workflow

创建描述符

首先，让我们来定义工作流。你可以使用任何名字来命名工作流。一个工作流对应一个XML格式的定义文件。让我们来开始新建一个“myworkflow.xml”的文件，这是样板文件：

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE workflow PUBLIC
"-//OpenSymphony Group//DTD OSWorkflow 2.7//EN"
"http://www.opensymphony.com/osworkflow/workflow_2_7.dtd">
<workflow>
<initial-actions>
...
</initial-actions>
<steps>
...
</steps>
</workflow>

首先是标准的XML头部，要注意的是OSWorkflow将会通过这些指定的DTD来验证XML内容的合法性。你可以使用绝大多数的XML编辑工具来编辑它，并且可以highlight相应的错误。

步骤和动作

接下来我们来定义初始化动作和步骤。首先需要理解的OSWorkflow重要概念是steps （步骤） 和 actions （动作）。一个步骤是工作流所处的位置，比如一个简单的工作流过程，它可能从一个步骤流转到另外一个步骤（或者有时候还是停留在一样的步骤）。举例来说，一个文档管理系统的流程，它的步骤名称可能有“First Draft - 草案初稿”，“Edit Stage -编辑阶段”，“At publisher - 出版商”等。

动作指定了可能发生在步骤内的转变，通常会导致步骤的变更。在我们的文件管理系统中，在“草案初稿”这个步骤可能有“start first draft - 开始草案初稿”和“complete first draft - 完成草案初稿”这样2个动作。

简单的说，步骤是“在哪里”，动作是“可以去哪里”。

初始化步骤是一种特殊类型的步骤，它用来启动工作流。在一个工作流程开始前，它是没有状态，不处在任何一个步骤，用户必须采取某些动作才能开始这个流程。这些特殊步骤被定义在 <initial-actions>。

在我们的例子里面，假定只有一个简单的初始化步骤：“Start Workflow”，它的定义在里面<initial-actions>：

<action id="1" name="Start Workflow">
<results>
<unconditional-result old-status="Finished" status="Queued" step="1"/>
</results>
</action>

这个动作是最简单的类型，只是简单地指明了下一个我们要去的步骤和状态。

工作流状态

工作流状态是一个用来描述工作流程中具体步骤状态的字符串。在我们的文档管理系统中，在“草案初稿”这个步骤可能有2个不同的状态：“Underway - 进行中”和“Queued - 等候处理中”

我们使用“Queued”指明这个条目已经被排入“First Draft”步骤的队列。比如说某人请求编写某篇文档，但是还没有指定作者，那么这个文档在“First Draft”步骤的状态就是“Queued”。“Underway”状态被用来指明一个作者已经挑选了一篇文档开始撰写，而且可能正在锁定这篇文档。

第一个步骤

让我们来看第一个步骤是怎样被定义在<steps>元素中的。我们有2个动作：第一个动作是保持当前步骤不变，只是改变了状态到“Underway”，第二个动作是移动到工作流的下一步骤。我们来添加如下的内容到<steps>元素：

<step id="1" name="First Draft">
<actions>
<action id="1" name="Start First Draft">
<results>
<unconditional-result old-status="Finished"
status="Underway" step="1"/>
</results>
</action>
<action id="2" name="Finish First Draft">
<results>
<unconditional-result old-status="Finished"
status="Queued" step="2"/>
</results>
</action>
</actions>
</step>
<step id="2" name="finished" />

这样我们就定义了2个动作，old-status属性是用来指明当前步骤完成以后的状态是什么，在大多数的应用中，通常用"Finished"表示。

上面定义的这2个动作是没有任何限制的。比如，一个用户可以调用action 2而不用先调用action 1。很明显的，我们如果没有开始撰写草稿，是不可能去完成一个草稿的。同样的，上面的定义也允许你开始撰写草稿多次，这也是毫无意义的。我们也没有做任何的处理去限制其他用户完成别人的草稿。这些都应该需要想办法避免。

让我们来一次解决这些问题。首先，我们需要指定只有工作流的状态为“Queued”的时候，一个caller （调用者）才能开始撰写草稿的动作。这样就可以阻止其他用户多次调用开始撰写草稿的动作。我们需要指定动作的约束，约束是由Condition（条件）组成。

条件

OSWorkflow 有很多有用的内置条件可以使用。在此相关的条件是“StatusCondition - 状态条件”。 条件也可以接受参数，参数的名称通常被定义在javadocs里（如果是使用Java Class实现的条件的话）。在这个例子里面，状态条件接受一个名为“status”的参数，指明了需要检查的状态条件。我们可以从下面的xml定义里面清楚的理解：

<action id="1" name="Start First Draft">
<restrict-to>
<conditions>
<condition type="class">
<arg name="class.name">
com.opensymphony.workflow.util.StatusCondition</arg>
<arg name="status">Queued</arg>
</condition>
</conditions>
</restrict-to>
<results>
<unconditional-result old-status="Finished" status="Underway" step="1"/>
</results>
</action>

希望对于条件的理解现在已经清楚了。上面的条件定义保证了动作1只能在当前状态为“Queued”的时候才能被调用，也就是说在初始化动作被调用以后。

函数

接下来，我们想在一个用户开始撰写草稿以后，设置他为“owner”。为了达到这样的目的，我们需要做2件事情：

1) 通过一个函数设置“caller”变量在当前的环境设置里。
2) 根据“caller”变量来设置“owner”属性。

函数是OSWorkflow的一个功能强大的特性。函数基本上是一个在工作流程中的工作单位，他不会影响到流程本身。举例来说，你可能有一个“SendEmail”的函数，用来在某些特定的流程流转发生时来发送email提醒。

函数也可以用来添加变量到当前的环境设置里。变量是一个指定名称的对象，可以用来在工作流中被以后的函数或者脚本使用。

OSWorkflow提供了一些内置的常用函数。其中一个称为“Caller”，这个函数会获得当前调用工作流的用户，并把它放入一个名为“caller”的字符型变量中。

因为我们需要追踪是哪个用户开始了编写草稿，所以可以使用这个函数来修改我们的动作定义：

<action id="1" name="Start First Draft">
<pre-functions>
<function type="class">
<arg name="class.name">
com.opensymphony.workflow.util.Caller</arg>
</function>
</pre-functions>
<results>
<unconditional-result old-status="Finished"status="Underway"
step="1" owner="${caller}"/>
</results>
</action>

h3 组合起来
把这些概念都组合起来，这样我们就有了动作1：

<action id="1" name="Start First Draft">
<restrict-to>
<conditions>
<condition type="class">
<arg name="class.name">
com.opensymphony.workflow.util.StatusCondition
</arg>
<arg name="status">Queued</arg>
</condition>
</conditions>
</restrict-to>
<pre-functions>
<function type="class">
<arg name="class.name">
com.opensymphony.workflow.util.Caller
</arg>
</function>
</pre-functions>
<results>
<unconditional-result old-status="Finished"status="Underway"
step="1"  owner="${caller}"/>
</results>
</action>

我们使用类似想法来设置动作2：

<action id="2" name="Finish First Draft">
<restrict-to>
<conditions type="AND">
<condition type="class">
<arg name="class.name">
com.opensymphony.workflow.util.StatusCondition
</arg>
<arg name="status">Underway</arg>
</condition>
<condition type="class">
<arg name="class.name">
com.opensymphony.workflow.util.AllowOwnerOnlyCondition
</arg>
</condition>
</conditions>
</restrict-to>
<results>
<unconditional-result old-status="Finished" status="Queued" step="2"/>
</results>
</action>

在这里我们指定了一个新的条件：“allow owner only”。这样能够保证只有开始撰写这份草稿的用户才能完成它。而状态条件确保了只有在“Underway”状态下的流程才能调用“finish first draft”动作。

把他们组合在一起，我们就有了第一个流程定义：

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE workflow PUBLIC
"-//OpenSymphony Group//DTD OSWorkflow 2.7//EN"
"http://www.opensymphony.com/osworkflow/workflow_2_7.dtd">
<workflow>
<initial-actions>
<action id="1" name="Start Workflow">
<results>
<unconditional-result old-status="Finished"
status="Queued" step="1"/>
</results>
</action>
</initial-actions>
<steps>
<step id="1" name="First Draft">
<actions>
<action id="1" name="Start First Draft">
<restrict-to>
<conditions>
<condition type="class">
<arg name="class.name">
com.opensymphony.workflow.util.StatusCondition
</arg>
<arg name="status">Queued</arg>
</condition>
</conditions>
</restrict-to>
<pre-functions>
<function type="class">
<arg name="class.name">
com.opensymphony.workflow.util.Caller
</arg>
</function>
</pre-functions>
<results>
<unconditional-result old-status="Finished" status="Underway"
step="1"  owner="${caller}"/>
</results>
</action>
<action id="2" name="Finish First Draft">
<restrict-to>
<conditions type="AND">
<condition type="class">
<arg name="class.name">
com.opensymphony.workflow.util.StatusCondition
</arg>
<arg name="status">Underway</arg>
</condition>
<condition type="class">
<arg name="class.name">
com.opensymphony.workflow.util.
AllowOwnerOnlyCondition
</arg>
</condition>
</conditions>
</restrict-to>
<results>
<unconditional-result old-status="Finished"
status="Queued" step="2"/>
</results>
</action>
</actions>
</step>
<step id="2" name="finished" />
</steps>
</workflow>

现在这个工作流的定义已经完整了，让我们来测试和检查它的运行。

2. Testing your workflow

现在我们已经完成了一个完整的工作流定义，下一步是检验它是否按照我们预想的方式执行。

在一个快速开发环境中，最简单的方法就是写一个测试案例。通过测试案例调用工作流，根据校验结果和捕捉可能发生的错误，来保证流程定义的正确性。

我们假设你已经熟悉Junit和了解怎样编写测试案例。如果你对这些知识还不了解的话，可以去JUnit的网站查找、阅读相关文档。编写测试案例会成为你的一个非常有用的工具。

在开始载入流程定义、调用动作以前，我们需要配置OSWorkflow的数据存储方式和定义文件的位置等。

配置 osworkflow.xml

我们需要创建的第一个文件是 osworkflow.xml。子：

<osworkflow>
<persistence class="com.opensymphony.workflow.
spi.memory.MemoryWorkflowStore"/>
<factory class="com.opensymphony.workflow.loader.XMLWorkflowFactory">
<property key="resource" value="workflows.xml" />
</factory>
</osworkflow>

这个例子指明了我们准备使用内存 (MemoryWorkflowStore) 来保存流程数据。这样可以减少设置数据库的相关信息，减少出问题的可能性。用内存持久化对于测试来说是非常方便的。

Workflow factories

上面的配置文件还指明了我们工作流工厂（XMLWorkflowFactory），工作流工厂的主要功能是管理流程定义文件，包括读取定义文件和修改定义文件的功能。通过'resource'这个属性指明了采用通过从classpath中读取流程定义文件的方式，按照这个定义，接下来我们需要在classpath中创建一个名为workflows.xml的文件。

workflows.xml 的内容：

<workflows>
<workflow name="mytest" type="resource" location="myworkflow.xml"/>
</workflows>

我们把 myworkflow.xml 和workflows.xml放在同一目录，这样它就能够被工作流工厂读取了。

这样就完成了配置，接下来是初始化一个流程并调用它。

Initialising OSWorkflow

OSWorkflow 的调用模式相当简单：通过一个主要的接口来执行大部分操作。这个接口就是 Workflow interface，及其扩展 AbstractWorkflow 的实现，例如EJBWorkflow 和 SOAPWorkflow. 为了简单起见，我们使用最基本的一种： BasicWorkflow。

首先，我们来创建Workflow。在实际项目中，这个对象应该被放在一个全局的位置上以供重用，因为每次都创建一个新的Workflow对象是需要耗费比较昂贵的系统资源。在这里的例子，我们采用BasicWorkflow，它的构建器由一个当前调用者的用户名构成，当然我们很少看到单用户的工作流应用，可以参考其他的Workflow实现有不同的方式去获得当前调用者。

为了简单起见，我们采用BasicWorkflow来创建一个单一的用户模式，避免编写其他获取用户方法的麻烦。

这样我们来创建一个'testuser'调用的workflow:

Workflow workflow = new BasicWorkflow("testuser");

下一步是提供配置文件，在大多数情况下，只是简单的传递一个DefaultConfiguration实例：

DefaultConfiguration config = new DefaultConfiguration();
workflow.setConfiguration(config);

现在我们已经创建并且配置好了一个workflow，接下来就是开始调用它了。

启动和进行一个工作流程

首先我们需要调用initialize 方法来启动一个工作流程，这个方法有3个参数，workflow name （定义在workflows.xml里，通过workflow factory处理）, action ID （我们要调用的初始化动作的ID），和初始化变量。 因为在例子里面不需初始化变量，所以我们只是传递一个null，

long workflowId = workflow.initialize("mytest", 1, null);

我们现在已经有了一个工作流实例，返回的workflowId可以在后续的操作中来代表这个实例。这个参数会在Workflow interface的绝大部分方法中用到。

检验工作流

现在让我们来检验启动的工作流实例是否按照我们所预期的那样运行。根据流程定义，我们期望的当前步骤是第一步，而且应该可以执行第一个动作（开始编写草稿）。

Collection currentSteps = workflow.getCurrentSteps
(workflowId);
//校验只有一个当前步骤
assertEquals("Unexpected number of current steps",
1, currentSteps.size());
//校验这个步骤是1
Step currentStep = (Step)currentSteps.iterator().next();
assertEquals("Unexpected current step", 1,
currentStep.getStepId());
int[] availableActions =
workflow.getAvailableActions(workflowId);
//校验只有一个可执行的动作
assertEquals("Unexpected number of available actions", 1,
availableActions.length);
//校验这个步骤是1
assertEquals("Unexpected available action", 1, availableActions[0]);

执行动作

现在已经校验完了工作流实例正如我们所期望的到了第一个步骤，让我们来开始执行第一个动作：

workflow.doAction(workflowId, 1, null);

这是简单的调用第一个动作，工作流引擎根据指定的条件，改变状态到‘Underway’，并且保持在当前步骤。

现在我们可以类似地调用第2个动作，它所需要的条件已经都满足了。

在调用完第2个动作以后，根据流程定义就没有可用的动作了，getAvailableActions将会返回一个空数组。

Congratulations, 你已经完成了一个工作流定义并且成功地调用了它。下一节我们将会讲解osworkflow一些更深入的概念。

3. Further descriptor concepts

定义条件和函数

你也许已经注意到，到目前为止，我们定义的条件和函数类型都是“class”。这种类型的条件和函数接受一个参数：“class.name”，以此来指明一个实现FunctionProvider或Condition接口的完整类名。

在osworkflow里面也有一些其他内置的类型，包括beanshell，无状态的session bean，JNDI树上的函数等。我们在下面的例子里使用beanshell类型。

Property sets

我们可能需要在工作流的任意步骤持久化一些少量数据。在osworkflow里，这是通过OpenSymphony的PropertySet library来实现。一个PropertySet基本上是一个可以持久化的类型安全map，你可以添加任意的数据到propertyset（一个工作流实例对应一个propertyset），并在以后的流程中再读取这些数据。除非你特别指定操作，否则propertyset中的数据不会被清空或者被删除。任意的函数和条件都可以和propertyset交互，以beanshell script来说，可以在脚本上下文中用“propertyset”这个名字来获取。下面来看具体写法是怎么样的，让我们增加如下的代码在“Start First Draft”动作的pre-functions里面：

<function type="beanshell">
<arg name="script">propertySet.setString("foo", "bar")</arg>
</function>

这样我们就添加了一个持久化的属性“foo”，它的值是“bar”。这样在以后的流程中，我们就可以获得这个值了。

Transient Map 临时变量

另外一个和propertyset变量相对的概念是临时变量：“transientVars”。临时变量是一个简单的map，只是在当前的工作流调用的上下文内有效。它包括当前的工作流实例，工作流定义等对应值的引用。你可以通过FunctionProvider的javadoc来查看这个map有那些可用的key。

还记得我们在教程的第2部分传入的那个null吗？如果我们不传入null的话，那么这些输入数据将会被添加到临时变量的map里。

inputs 输入

每次调用workflow的动作时可以输入一个可选的map，可以在这个map里面包含供函数和条件使用的任何数据，它不会被持久化，只是一个简单的数据传递。

Validators 校验器

为了让工作流能够校验输入的数据，引入了校验器的概念。一个校验器和函数，条件的实现方式非常类似（比如，它可以是一个class，脚本，或者EJB）。在这个教程里面，我们将会定义一个校验器，在“finish first draft”这个步骤，校验用户输入的数据“working.title”不能超过30个字符。这个校验器看起来是这样的：

package com.mycompany.validators;
public class TitleValidator implements Validator
{
public void validate(Map transientVars, Map args,
PropertySet ps)
throws InvalidInputException, WorkflowException
{
String title =
(String)transientVars.get("working.title");
if(title == null)
throw new InvalidInputException("Missing working.title");
if(title.length() > 30)
throw new InvalidInputException("Working title too long");
}
}

然后通过在流程定义文件添加validators元素，就可以登记这个校验器了：

<validators>
<validator type="class">
<arg name="class.name">
com.mycompany.validators.TitleValidator
</arg>
</validator>
</validators>

这样，当我们执行动作2的时候，这个校验器将会被调用，并且检验我们的输入。这样在测试代码里面，如果加上：

Map inputs = new HashMap();
inputs.put("working.title",
"the quick brown fox jumped over the lazy dog," +
" thus making this a very long title");
workflow.doAction(workflowId, 2, inputs);

我们将会得到一个InvalidInputException，这个动作将不会被执行。减少输入的title字符，将会让这个动作成功执行。

我们已经介绍了输入和校验，下面来看看寄存器。

Registers 寄存器

寄存器是一个工作流的全局变量。和propertyset类似，它可以在工作流实例的任意地方被获取。和propertyset不同的是，它不是一个持久化的数据，而是每次调用时都需要重新计算的数据。

它可以被用在什么地方呢？在我们的文档管理系统里面，如果定义了一个“document”的寄存器，那么对于函数、条件、脚本来说就是非常有用的：可以用它来获得正在被编辑的文档。

寄存器地值会被放在临时变量（transientVars map）里，这样能够在任意地方获得它。

定义一个寄存器和函数、条件的一个重要区别是，它并不是依靠特定的调用（不用关心当前的步骤，或者是输入数据，它只是简单地暴露一些数据而已），所以它不用临时变量里的值。

寄存器必须实现Register接口，并且被定义在流程定义文件的头部，在初始化动作之前。

举例来说，我们将会使用一个osworkflow内置的寄存器:LogRegister。这个寄存器简单的添加一个“log”变量，能够让你使用Jakarta的commons-logging输出日志信息。它的好处是会在每条信息前添加工作流实例的ID。

<registers>
<register type="class" variable-name="log">
<arg name="class.name">
com.opensymphony.workflow.util.LogRegister
</arg>
<arg name="addInstanceId">true</arg>
<arg name="Category">workflow</arg>
</register>
</registers>

这样我们定义了一个可用的“log”变量，可以通过其他的pre－function的脚本里面使用它：

<function type="beanshell">
<arg name="script">transientVars.get("log").info("executing action 2")
</arg>
</function>

日志输出将会在前面添加工作流实例的ID

结论

这个教程的目的是希望可以阐明一些主要的osworkflow概念。你还可以通过API和流程定义格式去获取更多的信息。有一些更高级的特性没有在此提到，比如splits 分支、joins 连接, nested conditions 复合条件、auto stpes 自动步骤等等。你可以通过阅读手册来获得更进一步的理解。

    在商用和开源世界里，OSWorkflow 都不同于这些已有的工作流系统。最大不同在于 OSWorkflow 有着非常优秀的灵活性。在开始接触 OSWorkflow 时可能较难掌握（有人说不适合工作流新手入门），比如，OSWorkflow 不要求图形化工具来开发工作流，而推荐手工编写 xml 格式的工作流程描述符。它能为应用程序开发者提供集成，也能与现有的代码和数据库进行集成。这一切似乎给正在寻找快速“即插即用”工作流解决方案的人制造了麻烦，但研究发现，那些“即插即用”方案也不能在一个成熟的应用程序中提供足够的灵活性来实现所有需求。
   
OSWorkflow 优势

    OSWorkflow 给你绝对的灵活性。OSWorkflow 被认为是一种“低级别”工作流实现。与其他工作流系统能用图标表现“loops(回路)”和“conditions(条件)”相比，OSWorkflow 只是手工“编码(coded)”来实现的。但这并不能说实际的代码是需要完全手工编码的，脚本语言能胜任这种情形。OSWorkflow 不希望一个非技术用户修改工作流程，虽然一些其他工作流系统提供了简单的 GUI 用于工作流编辑，但像这样改变工作流，通常会破坏这些应用。所以，进行工作流调整的最佳人选是开发人员，他们知道该怎么改变。不过，在最新的版本中，OSWorkflow 也提供了 GUI 设计器来协助工作流的编辑。

    OSWorkflow 基于有限状态机概念。每个 state 由 step ID 和 status 联合表现（可简单理解为 step 及其 status 表示有限状态机的 state）。一个 state 到另一 state 的 transition 依赖于 action 的发生，在工作流生命期内有至少一个或多个活动的 state。这些简单概念展现了 OSWorkflow 引擎的核心思想，并允许一个简单 XML 文件解释工作流业务流程。

 Osworkflow是完全用java语言编写的开放源代码的工作流引擎，具有显著的灵活性及完全面向有技术背景的用户的特点。用户可以根据自身的需求利用这款开源软件设计简单或是复杂的工作流。通过使用，用户就可以把工作中心放在业务和规则的定义上，而不需通过硬编码的方式实现一个Petri网或是一个有穷自动机。用户可以以最小的代价把osworkflow整合到自己的程序中来。Osworkflow几乎提供了所有用户可能在实际流程定义中需要用到的工作流构成元素，如：环节（step）、条件（conditions）、循环（loops）、分支（spilts）、合并（joins）、角色（roles）等等。
     首先，在osworkflow中需要了解得最重要的概念是环节，每个工作流包含了多个环节，可  以把环节想象成工作流中每一个重要的活动。每个环节可以有一些诸如“已完成”、“正在处理”、“已添加至处理队列”、“未处理”等的状态，设计工作流的人可以根据需要自己定义状态。
    在每个环节，动作被用户指定为自动或手动地执行。每个动作执行后，都有一个结果（result）。结果决定了工作流的流转方向：可以停留在同一环节，跳转到另一环节，跳转到一个分支，或者汇集到一个合并等。
最后两个概念涉及用户对业务流程的并发执行，分支把工作流分解为两个并行的环节，合并则在用户满足一定条件后，把两个并行的环节合并成一个。
动作的执行代表了业务流程的执行，每个动作都有一组预处理功能（pre-functions）和一组后处理功能（post-functions）。其作用正如读者想象的那样，一个在动作触发之前执行，一个在动作触发之后执行。一个简单的例子是：可以在预处理功能中检验申请表格数据的正确性，而后在后处理贡功能中把经检验的数据保存至数据库。
    动作的执行结果可以是有条件的（conditional）或无条件的（unconditional）。对于有条件的结果，引擎将首先检查是否条件被满足，然后再交给工作流来处理。如果条件不满足的话，引擎将进一步判断下一个有条件结果是否得到满足，以此类推，直到系统最终执行到无条件结果进行处理。
    如果所有的条件结果都没有得到满足会如何呢？事实上，每个动作都强制要求具有唯一一个无条件结果。与此对应的，可以有多个有条件的结果。
    业务规则常常在最终结果中带有条件判断，比如，“如果申请来自于一个老客户，则流转到环节1”或者“如果当前系统的用户的角色是经理的话，直接流转道最后一个环节”。
最后一个重要的概念是步骤状态（process state），在osworkflow中，当前步骤状态是所有当前环节状态的集合。读者可能会认为工作流在运行过程中只能有一个状态，但现实的情况是：因为对分支和合并的支持，引擎能够做到对环节的并发控制，因此工作流的当前状态就可能出现：“等待风险分析及已核查财务历史”的情况。
    激活动作的用户被顺理成章地称为触发者（caller），每个环节都有一个所有者（owner），以代表在当前环节中负责执行动作的角色或用户。
当用户在环节中运转流程的时候，已完成的环节被保存至历史表中（history），用户当前所处的环节成为当前环节（current steps）。
    最后，在osworkflow中并不存在其他工作流引擎中所包含的工作项（workitem）的概念。这是因为osworkflow是“十分底层”的工作流实现，怎样实现或定义工作项完全交由用户来决定。笔者认为工作项的概念太过抽象，用业务数据来称呼它或许更为贴切一些。
    Osworkflow 的文档中介绍了更多的构造元素，如寄存器（Registers），共用方法（common functions）等，但建议在建立好第一个工作流以后再去研究它们。它们是osworkflow基本元素外的高级特性，而我们前面所认识的元素则是osworkflow的根本所在。

OSWorkflow 核心概念
   
step（步骤）
    一个 step 是工作流所处的位置。可能从一个 step 流转到另外一个 step（或者有时候还是停留在一样的 step）。举例来说，一个 OA 系统的请假流程，它的 step 名称可能有“本部门审批阶段”，“办公室审批阶段”，“总经理审批阶段”等。
 
status（状态）
    工作流 status 是一个用来描述工作流程中具体步骤状态的字符串。OSWorkflow 的有 Underway（进行中）、Queued（等候处理中）、Finished（完成）三种 status。
 
action（动作）
    action 指定了可能发生在 step 内的转变，会导致 step 的变更。在 OA 系统中，“本部门审批阶段”可能有“拒绝”或“批准”两个 action。action 和 step 之间的关系是，step 说明“在哪里”，action 说明“可以去哪里”。 一个 action 典型地由两部分组成：可以执行此动作的 condition（条件），以及执行此动作的 result（结果）。
 
condition（条件）
    类似于逻辑判断，可包含“AND”和“OR”逻辑。比如一个请假流程中的“本部门审批阶段”，该阶段利用“AND”逻辑，判断流程状态是否为等候处理中，以及审批者是否为本部门主管。
   
result（结果）
    Result 代表指向新的 step 及其 step status，也可能进入 split 或者 join。Result 分为两种， contidional-result （有条件结果），只有条件为真时才使用该结果，和 unconditional-result（无条件结果），当条件不满足或没有条件时使用该结果。

split/join（分离/连接）
流程的切分和融合。很简单的概念，split 提供多个 result；join 则判断多个 current step 的状态，提供一个 result。

OSWorkflow 包用途分析及代码片断
   
com.opensymphony.workflow
    该包为整个 OSWorkflow 引擎提供核心接口。例如 com.opensymphony.workflow.Workflow 接口，可以说，实际开发中的大部分工作都是围绕该接口展开的，该接口有 BasicWorkflow、EJBWorkflow、OfbizWorkflow 三个实现类。

com.opensymphony.workflow.basic
    该包有两个类，BasicWorkflow 与 BasicWorkflowContext。BasicWorkflow 不支持事务，尽管依赖持久实现，事务也不能包裹它。BasicWorkflowContext 在实际开发中很少使用。

com.opensymphony.workflow.config
    该包有一个接口和两个该接口的实现类。在 OSWorkflow 2.7 以前，状态由多个地方的静态字段维护，这种方式很方便，但是有很多缺陷和约束。最主要的缺点是无法通过不同配置运行多个 OSWorkflow 实例。实现类 DefaultConfiguration 用于一般的配置文件载入。而 SpringConfiguration 则是让 Spring 容器管理配置信息。

com.opensymphony.workflow.ejb
    该包有两个接口 WorkflowHome 和 WorkflowRemote。该包的若干类中，最重要的是 EJBWorkflow，该类和 BasicWorkflow 的作用一样，是 OSWorkflow 的核心，并利用 EJB 容器管理事务，也作为工作流 session bean 的包装器。

com.opensymphony.workflow.loader
    该包有若干类，用得最多的是 XxxxDescriptor，如果在工作流引擎运行时需要了解指定的动作、步骤的状态、名字，等信息时，这些描述符会起到很大作用。

com.opensymphony.workflow.ofbiz
    OfbizWorkflow 和 BasicWorkflow 在很多方面非常相似，除了需要调用 ofbiz 的 TransactionUtil 来包装事务。

com.opensymphony.workflow.query
    该包主要为查询而设计，但不是所有的工作流存储都支持查询。通常，Hibernate 和 JDBC 都支持，而内存工作流存储不支持。值得注意的是 Hibernate 存储不支持混合型查询（例如，一个查询同时包含了 history step 上下文和 current step 上下文）。执行一个查询，需要创建 WorkflowExpressionQuery 实例，接着调用 Workflow 对象的 query 方法来得到最终查询结果。

com.opensymphony.workflow.spi
    该包可以说是 OSWorkflow 与持久层打交道的途径，如当前工作流的实体，其中包括：EJB、Hibernate、JDBC、Memory、Ofbiz、OJB、Prevayler。

com.opensymphony.workflow.util
该包是 OSWorkflow 的工具包，包括了对 BeanShell、BSF、EJB Local、EJB Remote、JNDI 的支持。

小 结

    由于本人所在公司希望在 OA 系统中引入工作流引擎，经过分析决定采用 OSWorkflow 引擎。利用 OSWorkflow，已经在系统中实现了请假条流程原型，该流程结合 OA 系统中已有的 RBAC 模型进行逐级审核。我个人认为要用 OSWorkflow 让某个流程跑起来似乎很麻烦，主要是需要扩展和自己实现的太多。
   
    另外，引用一段 Quake Wang 的原话：电子政务/OA 如果要使用workflow engine的话，shark，jbpm 之类的workflow engine有点杀鸡用牛刀的味道。shark 和 jbpm 都强迫你使用它的用户模型，怎样把企业现有的用户模型（包括组织结构）映射过来是很繁琐的事情，比如常见的 OA 应用中，申请者对应的部门负责人为下一个流程的人工参与者，使用 shark 或者 jbpm 都得绕一圈，通过现有的人力资源系统，获得用户，再对应过来。这还仅仅是一个简单的需求，更不用说国内企业千奇百怪的组织结构，以及各种特殊流程，用 wfmc 或者其他所谓的 workflow 通用标准去做不怎么标准的事情。吃力不讨好。用 osworkflow 这种基于状态机的 workflow engine 反而会轻松很多，而且它也没有强迫你使用它的用户模型。另外纠正一点：osworkflow 不仅仅支持简单的 BeanShell，还支持 java class，bsf，ejb。如果做电子政务/OA 的话，觉得目前 osworkflow 是最适用的 opensource workflow engine。