利用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的教程中得到的，总结一下，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（结果）。
理解osworkflow工作流
什么是工作流：
就是工作流程的计算模型，即将工作流程中的工作如何前后组织在一起的逻辑和规则在计算机中以恰当的模型进行表示并对其实施计算。工作流要解决的主要问题是：为实现某个业务目标，在多个参与者之间，利用计算机，按某种预定规则自动传递文档、信息或者任务。
工作流的应用场景：
soa中的时序编排，oa系统中的审批流转。大部分管理流程中都可以用到工作流。
工作流与业务的关系
一、业务集成到工作流中：一种常见的做法是把所有的业务集成到工作流中，如果有个业务就定义个function，然后放进去。例如要生成spcode。
1、带来的好处：
业务与工作流完全集成，只需要找到工作流配置文件，以他为主线就能找到所有的业务。让代码的阅读维护更方便。
2、坏处：
并不是最好的理念，仍然需要一次次的读原来的代码，复用性差，可剥离性差（比如我不想用工作流了），替换性差（比如我想从osworkflow到jbpm），侵入性高。跟现在大家说的最多的soa冲突。
3、适用环境
小项目开发，灵活，重写难度不大
二、业务单独写，工作流后加入进去
用非工作流的代码实现所有的业务，再用工作流编排
1、带来的好处：
符合soa的原则，可以分组件，分服务，分应用，复用性好，一旦复用消耗小，并不需要了解内部代码。
2、坏处：
初期消耗大，业务划分难度大，需要频繁调整。
3、适用环境
越大型的项目越好，甚至可以在应用之间组织。在电子系统集成中最有用。
工作流引擎：
字面意思理解，工作流引擎就是工作流核心元素解决方案。
那工作流的核心是什么呢？
有权限的操作者触发流程在各种条件下的跳转。
关键的是权限，条件，跳转。
所以工作流引擎实现的就是：
根据角色、分工和条件的不同决定信息传递路由
使用工作流引擎带来的便利：
1、开发简化
2、稳定性
3、易维护
理解工作流：
一句话：其实软件设计上更多的是借鉴非软件知识，比如设计模式来源于建筑。哲学上也有大同理论。
说了好久的工作流，知道它的好处，知道它的坏处，知道应用场景，但工作流还是有点朦胧，想到设计工作流，理解工作流还是有点头疼。特别是在大的场景，比如说我要实现任意方式定义的流程。听到这个就头大。那如何解决这个问题呢？
越是这类问题，约容易从理论的高度来解决。那么我们来看osworkflow是基于什么实现的？有限状态机。当我们放到宏观，我们要解决所有问题的时候会感觉很棘手，任意流程。但放到微观呢。虽然我们最终是要解决整个的路由。但是我只要解决任意两个step之间的路由。所有的路由就解决了。这也是数学上的归纳法。
好了现在的问题已经变成如何解决两个step之间的路由了，从两个step之间的路由，再次缩减到，我只需要知道一个step可以到什么地方，那我就知道是否两个step之间存在路由。
那放到一个step上是否就是有限状态机了呢？没错。
step就是状态，action就是状态转换，但是osworkflow赋予了action太多的功能，变成了action中的result才是转换，而action变成了转换过程中一些列操作及转换的集合。
有限状态机：
你熟悉他吗，一定的，一定熟悉他，想想有多少程序是基于他实现的。比如rpg游戏中迷宫的任意路口，比如rpg游戏中的情节设定。如果你写一个游戏引擎，你会发现fsm离你有多近。即使你不写游戏引擎，你玩游戏吗，在rpg中是否用笔通过一个个的点再现过迷宫地图，是否通过一次次的通关找到各种隐藏情节，这就是状态机。
osworkflow的设计工具：
为什么osworkflow不提供设计工具呢，osworkflow开发者说，要灵活，这是程序员干的事情。但是uml本身也是程序员干的事情。再想想因为osworkflow基于有限状态机，而对于有限状态机这种如果用uml表现出来是困难的。总会出一些难以控制的地方，再来看看jbpm，因为jbpm是基于状态图的，来源于uml，所以更容易出设计工具。
本文转自：http://www.blogjava.net/dreamstone/archive/2009/08/19/291755.html
first OSWorkflow
first workflow as follow:
:)
