osworkflow的配置
该篇文档是osworkflow的第三篇，也是我撰写的三篇文档。在阅读osworkflow初始化之前有必要了解osworkflwo的一些基本配置。
首先，我们要知道osworkflow中需要配置的两个重要文件，这两个重要文件的配置是在使用XMLWorkflowFactory类来处理配置文件时一定要有的配置文件。
第一个是osworkflow.xml文件，当然，你不可以随意指定这个文件的名称，而且你必须放到classes的根目录或者META-INF目录下，来看看这个部分的编码：
//使用默认文件名
if (is == null) {
try {
is = classLoader.getResourceAsStream("osworkflow.xml");
} catch (Exception e) {
}
}
if (is == null) {
try {
is = classLoader.getResourceAsStream("/osworkflow.xml");
} catch (Exception e) {
}
}
if (is == null) {
try {
is = classLoader.getResourceAsStream("META-INF/osworkflow.xml");
} catch (Exception e) {
}
}
if (is == null) {
try {
is = classLoader.getResourceAsStream("/META-INF/osworkflow.xml");
} catch (Exception e) {
}
}
该代码来自DefaultConfiguration中的load(url)方法中，当然在这个代码所在的方法中，osworkflow.xml文件是可以指定路径和文件名称的，主要是在调用load的上层AstractWorkflow中却没有传递任何文件路径和名称参数的接口，其实这个地方完全可以改成使用一个参数来确定文件的路径和名称的，传递url到AstractWorkflow中去。
来看看这个文件的格式样例：
<osworkflow>
<!--
<persistence class="com.opensymphony.workflow.spi.memory.MemoryWorkflowStore"/>
-->
<persistence class="com.opensymphony.workflow.spi.jdbc.JDBCWorkflowStore">
<property key="datasource" value="jdbc/osworkflow"/>
<property key="entry.sequence"
value=" select isnull(max(ID),0)+1 from dbo.OS_WFENTRY"/>
<property key="step.sequence"
value="select sum(c1) + 1 from (select 1 as tb, count(*)
as c1 from os_currentstep union
select 2 as tb, count(*) as c1 from os_historystep) as TabelaFinal"/>
</persistence>
<factory class="com.opensymphony.workflow.loader.XMLWorkflowFactory">
<property key="resource" value="workflows.xml" />
<property key="reload" value="true"/>
</factory>
</osworkflow>
这个样例是使用jdbc来持久化流程实例的配置，
这里主要有两个关键结点：
<persistence>和<factory>
1、<persistence>元素中配置了一个class属性，在这里，它是一个持久化实现类的配置，那么里面的子元素都将针对这个class的配置进行特殊的配置，我这里是使用了JDCBWorkflowStore对象，在使用这个对象的前提下，只对三个<property>元素配置进行说明，一个是key属性是entry.sequence和step.sequence的两个<property>元素，这两个元素主要是因为不同是数据库需要配置不同的实现方式，还有就是datasource的数据源元素。
以下分别对这三个元素进行配置说明：
key值为datasource的<property>元素：这个元素的value属性配置的是一个jndi的数据源，我们一般需要在特定的容器中配置特定的jndi数据源，以下是tomcat的例子：
<Context path="/osworkflow" docBase="osworkflow"
debug="99" reloadable="true" crossContext="true" verbosity="DEBUG">
<!-- debug level is set to paranoid, to know what is happening,
turn it off once you do not need it -->
<Logger className="org.apache.catalina.logger.FileLogger"
prefix="OSWorkflow." suffix=".log" timestamp="true"/>
<Resource name="jdbc/osworkflow" auth="Container"
type="javax.sql.DataSource"/>
<ResourceParams name="jdbc/osworkflow">
<parameter>
<name>factory</name>
<value>org.apache.commons.dbcp.BasicDataSourceFactory</value>
</parameter>
<parameter>
<name>maxActive</name>
<value>100</value>
</parameter>
<parameter>
<name>maxIdle</name>
<value>30</value>
</parameter>
<parameter>
<name>maxWait</name>
<value>10000</value>
</parameter>
<parameter>
<name>username</name>
<value>sa</value>
</parameter>
<parameter>
<name>password</name>
<value></value>
</parameter>
<parameter>
<name>driverClassName</name>
<value>net.sourceforge.jtds.jdbc.Driver</value>
</parameter>
<parameter>
<name>url</name>
<value>jdbc:jtds:sqlserver://localhost:1433/osworkflow</value>
</parameter>
</ResourceParams>
</Context>
在这里，我不对数据源的配置进行细节说明，这里就是有一个很重要的地方需要指出：看这段数据源配置的最初，<Resource>元素中name属性如果配置错误(随意指定名称)，那么程序在运行中将发生很多不可以理解的异常，系统会不停的打出数据源找不到的异常，然而我曾经花了很长的一段时间来寻找一个问题的原因，找遍了很多的代码也不能找到问题的原因，直到我后来去研读PropertySet开源项目的时候才发现，原来在这个开源架构的一个内部配置文件中，数据源已经被配置成jdbc/DefaultDS，因此上面这段配置最终会发生异常，因此如果不想让系统打印出数据源异常，这个数据源的配置务必配置成jdbc/DefaultDS,或者修改PropertySet的配置文件，在示例代码中，我故意把数据源的配置保持在错误的状态，读者可以运行这个示例，看看控制台出现了什么错误。不过在接下来的部分，马上就会改回正确配置，以进行下一步的研究。
key值为entry.sequence的<property>元素：在osworkflow中需要我们自己来配置，通常系统中会使用这个配置获取实例存放的数据id。这个值可以不配置，但它只提供了一种数据库的生成语句，它将使用oracle支持的一个nextval(’序列号发生器名称’)，去获取。
key值为step.sequence的<property>元素：同样，这里是用来获取当前所在的step的步骤id。同样，它也提供一个默认值，支持类似oracle等db的序列号发生器。
还有其他的很多配置，如果不使用自己特定的物理表格和特别的实现，可以不提供配置。如下来看看部分源代码：
entrySequence = getInitProperty(props, "entry.sequence", "SELECT nextVal(’seq_os_wfentry’)");
stepSequence = getInitProperty(props, "step.sequence", "SELECT nextVal(’seq_os_currentsteps’)");
entryTable = getInitProperty(props, "entry.table", "OS_WFENTRY");
entryId = getInitProperty(props, "entry.id", "ID");
entryName = getInitProperty(props, "entry.name", "NAME");
entryState = getInitProperty(props, "entry.state", "STATE");
historyTable = getInitProperty(props, "history.table", "OS_HISTORYSTEP");
currentTable = getInitProperty(props, "current.table", "OS_CURRENTSTEP");
currentPrevTable = getInitProperty(props, "currentPrev.table", "OS_CURRENTSTEP_PREV");
historyPrevTable = getInitProperty(props, "historyPrev.table", "OS_HISTORYSTEP_PREV");
stepId = getInitProperty(props, "step.id", "ID");
stepEntryId = getInitProperty(props, "step.entryId", "ENTRY_ID");
stepStepId = getInitProperty(props, "step.stepId", "STEP_ID");
stepActionId = getInitProperty(props, "step.actionId", "ACTION_ID");
stepOwner = getInitProperty(props, "step.owner", "OWNER");
stepCaller = getInitProperty(props, "step.caller", "CALLER");
stepStartDate = getInitProperty(props, "step.startDate", "START_DATE");
stepFinishDate = getInitProperty(props, "step.finishDate", "FINISH_DATE");
stepDueDate = getInitProperty(props, "step.dueDate", "DUE_DATE");
stepStatus = getInitProperty(props, "step.status", "STATUS");
stepPreviousId = getInitProperty(props, "step.previousId", "PREVIOUS_ID");
以上这段代码出现在JDBCWorkflowStore的init方法中。它仅仅是读取了我们在DefaultConfiguration中解析配置文件后的map：persistenceArgs，后续我们会读这个类进行全面而细致的分析。
2、<factory> 这个元素主要是配置WorkflowFactory的地方，在这个工厂类中，我们完成了流程模型文件的基本信息的初始化，在实例项目中，使用了XMLWorkflowFactory来完成流程模型基本信息的初始化，以及对流程模型的获取删除等操作进行了代理。这个类也将在以后的章节中进行详细的分析。先来看看这个元素的配置：
这个元素的class属性指定了我们配置了完成模型基本信息初始化的工厂类。例子中使用的
是XMLWorkflowFactory类。
接下来的一个元素就是对模型资源文件的配置，这个资源文件存放了全部流程模型的路径等
信息。
<property key="resource" value="workflows.xml" />
这个元素其实也可以不配置，如果不配置的话，默认就是workflows.xml，而且默认路径就是
classes下，或者是META-INF下，因此如果你不配置这个属性，请务必使用默认名称和默认路
径。
这个元素的配置意义，其实很明了，模型将在一定的条件下被重新解析和载入。这个元素同样也
是可以不配置的，默认情况下就是false的
<property key="reload" value="true"/>
第二个是workflows.xml文件，这个文件就非常的简单了，只要把例子贴出来，应该不需要做什么解释了：
<workflows>
<workflow name="simple" type="resource" location="oswk/test/config/simple.xml"/>
</workflows>
这个地方唯一要注意的就是：type属性，该属性可以被配置为三种类型：url、file、resource。这三种类型代表了三种文件的读取方式，来看看源代码：
if ("URL".equals(type)) {
try {
url = new URL(location);
File file = new File(url.getFile());
if (file.exists()) {
lastModified = file.lastModified();
}
} catch (Exception ex) {
}
} else if ("file".equals(type)) {
try {
File file = new File(location);
url = file.toURL();
lastModified = file.lastModified();
} catch (Exception ex) {
}
} else {
url=Thread.currentThread().getContextClassLoader().getResource(location);
}
最后一个文件就是流程模型文件了
workflow模型文件。
首先我们来熟悉一下workflow的基本概念。
简单的讲，workflow就是一个自动化流程引擎，我们把企业业务流程抽象出来，让workflow engine来统一管理和执行、监控。按照WFMC的定义：
全部或者部分，由计算机支持或自动处理的业务过程。
在不使用workflow engine的传统企业应用系统中，我们可能会散乱和抽象一些直接编写流程控制代码在业务系统中，这样的一种模式基本上是目前应用系统的主流模式。也许良好的体系架构足够的优秀，它抽象了很高层的逻辑来适应企业应用在未来的变化。
在我们面对一个应用系统进行较高层的设计时，总是在考虑如何才能将系统各个层面的依赖尽量的降低。从企业业务的角度来看，我们可以抽象出两个比较高层的层面：一是流程，二是活动。那么流程，就像是一条或者多条交错贯穿的线索，它连接着业务中各个结点的变化，线索的分支、合并等。而活动就是各个结点上发生的事情，这些发生的事情决定了线索的走向和状态。
系统架构设计的其中一个很重要的目的就是将系统中的层面尽可能的划分清晰，尽可能的松散耦合。那么我们如何才能把流程和活动清晰的划分呢？如何让流程牵引活动的执行呢？而活动对于流程来说是透明的，流程永远不知道在它上面的活动做了什么，它只需要流程得以继续流转的信息。同样，活动也并不知道流程的存在，它只提供活动执行的结果和其他信息。
那么，现在就很明确了，workflow就是这样一个东西，它定义了一个流程，并控制了整个流程的运行，安排活动在流程内部被呼叫，以及被定义了执行的顺序。
因此从workflow的视角来看，一个完整的流程就是一个实体，而这个实体的开始、运行、结束都被定义在workflow管理的一个规则模型中。接下来，我要分析的就是oswolkflow的这个模型定义，这里要表现的模型文件格式是开放的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>
<step name="" id="1">
</step>
<step name="" id="4">
</step>
<step name="" id="5">
</step>
</steps>
</workflow>
这个样式提供了最基本的要素，我们通过initail-action来启动一个流程实例，然后在step里面定义活动来完成各个工作，查看dtd的定义
<!ELEMENT workflow (meta*, registers?, trigger-functions?, initial-actions, global-actions?, common-actions?, steps, splits?, joins?)>
根元素workflow中可以定义的子元素很多：
1、registers元素的作用是在外部调用流程实例的执行一些动作的时候，registers下的动作都将被调用，这个地方非常适合存放流程日志，来记录流程调用轨迹。可选，且只能有一个；
2、global-actions元素的作用其实从字面也可以很理解，就是一些全局的actions，它的存在是为了一些任何步骤都可能被执行的动作，它被放到了workflow根元素下面，在流程进入到任何step的时候，都可以执行这个元素下的actions。可选，且只能有一个；
3、trigger-functions元素的作用，这个元素是一个需要使用api执行的functions，适合系统外部被调用。可选，且只能有一个；
4、initial-actions元素的作用就更加的明确了，它就是一个流程实例被启动的时候需要执行的元素。必须
5、common-actions元素的作用，这个元素也被定义在全局的范围内，它的下面可以定义actions，被step内部的action以id的方式引用。可选，且只能有一个；
6、steps元素的作用基本算是最核心的元素了，每个流程的跳转都以这个元素为依据，这个里面我们会配置很多的actions来完各种动作。必须
7、splits我们在这个元素中配置需要并行执行的steps，完成了并行流程。可选，且只能有一个；
8、joins这个元素就是一个汇集了，我们可以把step中执行的action连接到这个元素，来完成多个actions执行完的其他处理，比如判断执行情况，来处理下一个step中的action。可选，且只能有一个。
转载请说明出处。该文档的版权属于http://zstzah.blog.bokee.net
----待续