工作流引擎

备注：shark 和 jbpm都强迫你使用它的用户模型，怎样把企业现有的用户模型（包括组织结构）映射过来是很繁琐的事情

Shark, OsworkFlow ,Jbpm比较

Shark

Shark是体系和功能最为复杂的代表。它是一款遵循WfMC的XPDL标准开源工作流引擎，并且同时遵循OMG组织的WorkflowManagement Facility规范。XPDL的两个最重要的概念是Process和Activity。XPDL中的Activity是基于UML1.x中的活动图的概念。活动图天生的适于工作流程建模，它相对于状态图的一个最大的优点是容易做并发线程的分叉控制，这些并发线程可以同时执行也可以顺序执行；它还有一个优点是有泳道的概念，可以控制工作流引擎中的任务的产生。

在所有开源工作流引擎中，Shark的体系最为完备和复杂。其一直秉承着“模块化”的思想，所以比较容易扩展。但是自从被Together公司收购后，Shark的商业化色彩已经越来越浓，改称为Together Workflow Server，并仅以Community Edition的形式提供了部分开源代码供参考。

OSWorkflow

OSWorkflow是最轻量型的代表，也是一款非常灵活和低级别定位的工作流引擎的实现框架。低级别定位的意思是说，它不是定位在解决流程模型对象和运转场景，而是提供一套可维护调度的机制，供开发人员自主扩展。这个维护流程调度机制OSWorkflow选择的是基于行为（Action）的FSM理论，所以OSWorkflow更像是一个复杂而灵活的有限状态调度机。

Osworkflow有个重要概念是State，State是由step和status联合表达的，一个State就是一个step中的某个status；而state的转换由action来驱动，类似状态图中的event,因为一个event对应一个action

OSWorkflow在国内项目应用得较多，很多国内的简易审批流程项目都是基于其引擎二次开发而来。这主要是由于OSWorkflow是基于Action驱动的，而国内的客户也很容易接受这样的操作习惯。但OSWorkflow所依赖的FSM模型对于分支、聚合、子流程的支持度很低，这一点在实施过程中需要注意。

jBpm

Jbpm结合应用了状态图+活动图+PetriNet的知识，而且这里的活动图还是UML2.0版的。UML2.0的活动图中，节点不叫活动（Activity）而叫动作(action)，活动成了一个高层次的概念，它包含一个动作序列。一个活动图展现一系列的动作，这些动作组成了活动。Jbpm把action也改名了，称为state。Jbpm使用的状态图的概念有transition/event等。Jbpm来内部实现中还采用了PetriNet的概念，如token,signal等，jBpm对Token的应用很有特色，巧妙地利用Parent-Child Token的机制处理分支、父子流程等复杂应用场景。

jBpm是最适合扩展的代表，是在所有开源引擎中最适宜被商业化应用的一款。首先其流程建模模型是基于Activity Diagram（活动图）的，并在引擎构建上融入了FSM和PetriNet思想，所以其内核和根基比较牢固扎实。其次，自从被JBoss收购后，其3.x系列的结构更加趋于微内核，Plug-in思想也更加深入。其同时还提供了对BPEL扩展，存储支持JBossHibernate实现，集成了JBoss seam，规则引擎准备采用JBossrules，并准备集成JBoss Messaging。这样，不论从内核和外围应用，jBpm都具有了强劲的动力。

市场预测   

Jbpm3将在3月发布阿尔发版，jbpm3的最终版将支持bpel4ws的核心部分。所以，据估计Shark将在引领风骚数百天后，被jbpm3赶下第一宝座。但bpel4ws暂时不会和我们亲密接触了，估计在今年它是不会真正走进我们的生活的。

二、.NETFramework3中是不是也加了工作流支持？

（个人感觉WWF的流程定制方式接近于 程序设计流程，像一步步的写程序）

下面是有关的调研报告：

.net framework3中加入了WWF（Windows WorkflowFoundation），是帮助你在Windows平台上快速建立工作流应用程序的编程模型、引擎和工具，它为开发和执行各种基于工作流的应用程序提供了编程框架和工具。

Windows Workflow Foundation是一个帮助你开发基于Windows平台的工作流解决方案的可扩展的框架，允许你在.NET应用程序中嵌入工作流。WWF本身不是一个可执行的软件或程序，WWF主要是帮助你创建自己的工作流应用程序。作为将来Microsoft WinFX的一部分，WWF提供一组API和工具以支持基于工作流的应用程序的开发和执行。WWF为创建跨越不同应用程序的端到端解决方法提供了一个简单、统一的模型。

Windows Workflow Foundation是一个通用的工作流框架。基于WWF的解决方案由相互链接的.NET组件构成并运行在宿主程序中。就像你在一个特定的设计环境下创建ASP.NET页面一样，WWF也为你提供了一个良好的设计环境，在可视化设计器中，你可以创建特定的流程、在工作流组件中增加代码、定义商业过程，WWF提供了工作流引擎、.NET-managedAPI、运行时服务、与Visual Studio 2005集成的可视化编辑器和调试工具。你可以使用Windows Workflow Foundation创建和执行运行在客户端和服务器端的工作流，并且可以运行在所有的.NET应用程序中。

Windows WorkflowFoundation：支持基于工作流的应用程序

工作流是一个简单思路：按照特定顺序执行的一系列步骤。采用工作流技术后，逻辑与普通代码不会纠缠在一起，过程中的每一步骤都会明确定义，然后由工作流引擎执行。这样做的结果就是，过程执行清楚明确。

但是，提供通用的工作流技术之路却是困难重重。举例来说，如何使用一种方法来满足不同工作流应用程序的各种要求？WF 给出的答案是，从全局视角来看待工作流。WF 工作流只是一组由 WF 引擎执行的活动。一个活动就是一个类，它可以包含工作流创建者认为有必要的任何工作。活动可以在不同的工作流中重复使用，因此，在针对新问题创建自动化的解决方案时，过程将会更加容易。

提供通用工作流技术面临另一个困难是，面向人员工作流和面向系统工作流的传统分歧。通常来说，工作人员使用的工作流应用程序需要有较高的灵活性，能够进行实时更改。而一般由系统，也就是由软件使用的工作流应用程序则相对更加静态，但要求尽可能高效。WF 综合考虑了这两种不同的使用情况，不仅包括面向人员的功能（如更改运行中工作流的功能），同时还支持更多面向系统的操作。

通过 WF 的Windows 通用工作流技术，.NETFramework 3.0 为广大开发人员提供了一种非常有用的软件开发模式。随着面向流程的软件继续风行，工作流技术也会随之推广。

WWF的应用场景

WWF本身并不是一个业务平台，它只是为开发人员提供创建工作流软件的一个平台，也就是说WWF不是工作流应用平台，而是一个开发工作流应用的平台。使用这个开发平台可以开发具有以下特点的工作流平台

• 业务流程辅助办公软件

不同行业者有各自独立的业务流程，使用一些业务流程管理软件可以提高流程效率并降低出错率，比如审批类、办公类、采购类、MSI、电子商务、电子政务、电子法务、以及需要按一定的业务流程办公的所有领域的办公辅助系统中都可以使用工作流

• 软体内部工作的顺控制

很多时候，在不涉及业务的情况下，对软件的自身协调控制也有很复杂的流程，比如一个需要设置很多参数的软件安装向导、一个窗体内各控件间复杂的锁定关系、一个软件中多个窗体相互调用的顺序都可以用工作流实现

• 自动筛选查询类系统

比如招投标系统中的自动开标模块、考生录取系统中的自动投档模块、搜索引擎的自动分析模块，可以使用工作流管理这些模块的运算方案与运算路径

• 自动化控制中

在工控系统中，有时需要控一个的顺序对一系列的机器进行控制，可以使用工作流管理这些控制

WWF的特点

• 有状态的、持久化的、不间断运行的应用程序

WWF简化了创造有状态的，不间断运行的异步工作流应用程序的过程。WWF运行时引擎管理工作流的运行，为工作流的长期运行提供保障，并能抵抗机器的重启。WWF运行时服务提供了一系列的附加功能，例如WWF服务为能温和且正确的处理错误提供了事务和持久化。

• 工作流模型

WWF为开发人员提供了一个工作流模型，来描述应用程序所需要的处理过程。通过使用工作流模型所提供的流程控件、状态管理、事务和同步器，开发人员可以分离应用程序逻辑和业务逻辑，构造一个高层次的抽象，达到提高开发者效率的目的。

• 组件的重用

WWF为开发者提供了一系列的活动——活动是一种包含了工作单元的可配置逻辑结构。这种结构封装了开发者可能经常性用到的一些部件，这样就节省了开发者的时间。如果遇到一些特殊的需求或场景，WWF同样为开发自定义的活动提供了简单的方法。通过将工作流引擎载入进程，WWF可以使任何应用程序和服务容器运行工作流。

运行时服务组件被设计成可插件形式的，这个可使应用程序以最合适的方式来提供它们的服务。WWF还提供了一组运行时服务的默认实现，这些服务能满足大部分类型的应用程序。

另外，WWF还提供了对ASP.NET的out-of-the-box支持，让构造和运行能在IIS和ASP.NET环境的工作流变得简单。