OSWorkflow概况

OSWorkflow概况

OSWorkflow

OSWorkflow概况

OSWorkflow是一个灵活的工作流引擎,可嵌入到企业应用程序中。它提供了许多的持久化API支持包括: EJB, Hibernate, JDBC和其它。OSWorkflow还可以与 Spring集成。

在商用和开源世界里,OSWorkflow 都不同于这些已有的工作流系统。最大不同在于 OSWorkflow 有着非常优秀的灵活性。

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核心概念

概念定义

步骤(Step) 一个 Step 描述的是工作流所处的位置。可能从一个 Step Transtion(流转)到另外一个 Step,或者也可以在同一个 Step 内流转(因为 Step 可以通 Status 来细分,形成多个State)。一个流程里面可以多个Step。

状态(Status) 工作流 Status 是用来描述工作流程中具体Step(步骤)状态的字符串。OSWorkflow 的有 Underway(进行中)、Queued(等候处理中)、Finished(完成)三种 Status。一个实际State(状态)真正是由两部分组成:State = (Step + Status) 。

流转(Transtion) 一个State到另一个State的转移。

动作(Action) Action 触发了发生在 Step 内或 Step 间的流转,或者说是基于 State 的流转。一个 step 里面可以有多个Action。Action 和Step 之间的关系是,Step 说明“在哪里”,Action 说明“去哪里”。 一个 Action 典型地由两部分组成:可以执行此Action(动作)的 Condition(条件),以及执行此动作后的 Result(结果)。

条件(Condition)类似于逻辑判断,可包含“AND”和“OR”逻辑。比如一个请假流程中的“本部门审批阶段”,该阶段利用“AND”逻辑,判断流程状态是否为等候处理中,以及审批者是否为本部门主管。

结果(Result) Result 代表执行Action(动作)后的结果,指向新的 Step 及其 Step Status,也可能进入 Split 或者 Join。Result 分为两种, Contidional-Result (有条件结果),只有条件为真时才使用该结果,和 Unconditional-Result(无条件结果),当条件不满足或没有条件时使用该结果。

分离/连接(Split/Join)流程的切分和融合。很简单的概念,Split 可以提供多个 Result(结果);Join 则判断多个 Current Step 的态提供一个 Result(结果)。

步骤、状态和动作(Step, Status, and Action)

工作流要描述步骤(Step)、步骤的状态(Status)、各个步骤之间的关系以及执行各个步骤的条件和权限,每个步骤中可以含有一个或多个动作(Action),动作将会使一个步骤的状态发生改变。

对于一个执行的工作流来讲,步骤的切换是不可避免的。一个工作流在某一时刻会有一个或多个当前步骤,每个当前步骤都有一个状态值,当前步骤的状态值组成了工作流实例的状态值。一旦完成了一个步骤,那么这个步骤将不再是当前步骤(而是切换到一个新的步骤),通常一个新的当前步骤将随之建立起来,以保证工作流继续执行。完成了的步骤的最终状态值是用Old-Status属性指定的,这个状态值的设定将发生在切换到其他步骤之前。Old-Status的值可以是任意的,但在一般情况下,我们设置为Finished。

切换本身是一个动作(Action)的执行结果。每个步骤可以含有多个动作,究竟要载入哪个动作是由最终用户、外部事件或者Tiggerd的自动调用决定的。随着动作的完成,一个特定的步骤切换也将发生。动作可以被限制在用户、用户组或当前状态。每一个动作都必须包含一个Unconditional Result和0个或多个Conditional Results。

所以,总体来说,一个工作流由多个步骤组成。每个步骤有一个当前状态(例如:Queued, Underway or Finished),一个步骤包含多个动作。每个步骤含有多个可以执行的动作。每个动作都有执行的条件,也有要执行的函数。动作包含有可以改变状态和当前工作流步骤的results。

结果、分支和连接(Results, Joins, and Splits)

无条件结果(Unconditional Result) 对于每一个动作来讲,必须存在一个Unconditional Result。一个result是一系列指令,这些指令将告诉OSWorkFlow下一个任务要做什么。这包括使工作流从一个状态切换到另一个状态。

有条件结果(Conditional Result) Conditional Result是Unconditional Result的一个扩展。它需要一个或多个Condition子标签。第一个为true的Conditional(使用AND或OR类型),会指明发生切换的步骤,这个切换步骤的发生是由于某个用户执行了某个动作的结果导致的。

三种不同的Results(conditional or unconditional) 一个新的、单一的步骤和状态的组合。一个分裂成两个或多个步骤和状态的组合。将这个和其他的切换组合成一个新的单一的步骤和状态的组合。每种不同的result对应了不同的xml描述,你可以阅读http://www.opensymphony.com/osworkflow/workflow_2_7.dtd,获取更多的信息。注意:通常,一个split或一个join不会再导致一个split 或 join的发生。

自动步骤(Auto actions)

有的时候,我们需要一些动作可以基于一些条件自动地执行。为了达到这个目的,你可以在action中加入auto="true"属性。流程将考察这个动作的条件和限制,如果条件符合,那么将执行这个动作。 Auto action是由当前的调用者执行的,所以将对该动作的调用者执行权限检查。

整合抽象实例(Integrating with Abstract Entities)

建议在你的核心实体中,例如"Document" 或 "Order",在内部创建一个新的属性:workflowId。这样,当新的"Document" 或 "Order"被创建的时候,它能够和一个workflow实例关联起来。那么,你的代码可以通过OSWorkflow API查找到这个workflow实例并且得到这个workflow的信息和动作。

工作流实例状态(Workflow Instance State)

有的时候,为整个workflow实例指定一个状态是很有帮助的,它独立于流程的执行步骤。OSWorkflow提供一些workflow实例中可以包含的"meta-states"。这些"meta-states"可以是CREATED, ACTIVATED, SUSPENDED, KILLED 和 COMPLETED。当一个工作流实例被创建的时候,它将处于CREATED状态。然后,只要一个动作被执行,它就会自动的变成ACTIVATED状态。如果调用者没有明确地改变实例的状态, 工作流将一直保持这个状态直到工作流结束。当工作流不可能再执行任何其他的动作的时候,工作流将自动的变成COMPLETED状态。

然而,当工作流处于ACTIVATED状态的时候,调用者可以终止或挂起这个工作流(设置工作流的状态为KILLED 或 SUSPENDED)。一个终止了的工作流将不能再执行任何动作,而且将永远保持着终止状态。一个被挂起了的工作流会被冻结,他也不能执行任何的动作,除非它的状态再变成ACTIVATED。

你可能感兴趣的:(OSWorkflow概况)