谈谈工作流引擎及面向服务编程

 工作流关键字解答
 
什么是工作流
　　工作流即Workflow。通过将工作活动分解定义良好的任务、角色、规则和过程来进行执行和监控，达到提高生产组织水平和工作效率的目的。    
 
什么是工作流引擎
　　工作流即WorkFlow Engine，是指workflow作为应用系统的一部分，并为之提供对各应用系统有决定作用的根据角色、分工和条件的不同决定信息。   
 
什么是工作流管理系统
　　工作流管理系统即Workflow Management System，简称WFMS，是定义、创建、执行工作流的系统。

相信很多人对于BizTalk Server 2004（简称BTS）都有一种误解，认为这是微软出品的工作流引擎。包括我在内，从没有进入MS以来，一直在围绕着BizTalk Server 2004做开发，而加入后，所做的大部分PoC都是基于BizTalk Server 2004的。当然，我做的都是一些外围开发，而不是一些核心性的BizTalk开发。

所谓的外围开发，就是为工作流做一些UI界面，以便驱动整个工作流能够进行下去。做得久了，经常会有一些疑问，我相信大部分做过BizTalk Server开发的人员都会遇到类似的疑问，因为在我与Partner的研发人员闲聊时，也遇到类似的困惑，那就是为什么有了BizTalk Server 2004这么好的工具，我们做工作流开发还这么累呢？？很多时候，为了完成一个简单的公文流转功能，我们用ASP.NET可能几行代码就搞定了，但加上了BizTalk Server 2004后，却发现工作量成倍的增加。

经过这一个月以来，与同事探讨，终于找到了一个原因。因为我们错了，BizTalk Server不是微软的工作流引擎。这话似乎有一点惊世骇俗，但我相信，我们的观点没有错误。

博客堂前段时间一直在探讨SOA（面向服务编程），其实在我看来，BizTalk Server 2004正是为了SOA而做准备的，它是为了整合各个System的Service，而建立的自动流程功能，同时，由于各个System的Service所传递的消息的Schema的不统一，所以BTS里面提供了Mapping的功能。在BizTalk Server 2004的文档中，其功能就列了两点：(1)EAI,企业应用整合;(2)B2B的消息传送。

这种EAI的Service整合，在流程运行时，没有人为因素的干扰，没有UI的驱动，非常适合BTS这种无角色流程引擎进行驱动（BizTalk Server还是有角色的，不过非常淡化）。而类似于OA这种公文工作流的引擎，则BTS根本不适合。

前段时间，非常有幸看到了ADOBE Workflow Server的介绍（本来也想去看看点击科技王志东老大的工作流系统，可是无缘），对此我更有感悟。ADOBE的这套东西，才是真正基于公文工作流的，我们可以比较它的流程图与BTS流程图的异同。BTS的流程图更像我们的软件逻辑图，在这个图中，你很难一眼就从中找到哪个点应该是一个UI，这个UI上应该有哪些单元。但ADOBE的流程图则不一样，它每个节点就是一个UI，在这个节点旁边可以罗列一些选项，比如“同意”、“不同意”、“退回秘书”之类的，然后从这些选项到它们应该到的下一个节点间连一点线。非常清晰的就把这个工作流的UI都给清晰化了。再配合ADOBE Form Server以及Form Designer，则能够很简单的做出来一个公文工作流系统。

且慢，难道微软真的没有工作流软件吗？非也非也。加入微软之前，也很有幸接触到了Teamplate的工作流产品，这是一个微软的全球合作伙伴，它的TeamPlate产品基本上把MS的所有Server都包含进来了，比如BizTalk Server 2004、SharePoint Portal Server 2003、Exchange Server 2003，那么这个工作流产品使用了BizTalk Server 2004的什么特性呢？原来使用的是HWS（工作流服务，Human Workflow Service）。

HWS，翻开BTS的随机文档，发现关于HWS的文档真的是非常珍贵，打印出来估计不到十页纸（估计其中大部分还是HWS的UI方面的，介绍哪个按钮做什么的）。估计没有人能够看得明白，但是再去MSDN Online上找一下，好多了，因为我们发现了BTS的SDK，在Sample里面还是一些料的，不过，我估计再没有人指引的情况下，没有几个人会对这东西能够上手。

HWS，实现的就是ADOBE Workflow Server所实现的东西，但是在目前，它缺少一个Workflow Desinger的设计工具，所以会造成它的曲高和寡的局面。你必须自己手动写代码去完成你的工作流设计，虽然在SDK里面有Step By Step的指导，但似乎还是很难（想想BizTalk Server 2004本身，本来设计流程就是画画那么简单，但MS还是怕很多人不会，还提供了一个免费的Visio插件，供大家做图玩）。

可能很多人读了上面的文章，会认为我在贬低BTS，其实不然。我觉得做BTS始终是MS的大智慧所在，它早在2000年就预示到了SOA的到来。只不过由于其流程图画得那么“好看”，导致大家有一些误解，从而杀鸡用坦克，既不顺手，还劳民伤财。在SOA服务来临之日，BTS更能突显其危力。我们想想Longhorn，那里面有一个Indigo。仔细思考一下，其实Indigo的很多功能似乎与BTS有交集，所以有理由相信，在未来，BTS下一版本又有新的面貌了，至于新貌如何，还请各位看倌拭目以待。

BTW:讲到SOA，想到前段时间博客堂对于SOA中传递消息的讨论，一派人认为SOA应该只传简单类型，一派人认为SOA可以传递复杂自定义对象，甚至包括DataSet在内。

 

工作流应用的关键需求 　　需要专业的工作流平台，集中在对灵活性、高效稳定性与开放性的要求。 　　灵活的工作流引擎支撑，体现在流程异常处理、流程在运行时按照任意路由流转以及流程同步等待等诸多方面，这些灵活的功能往往需要工作流引擎来提供，而不是由业务系统来实现；高效、稳定则是在高压力情况下具有良好的稳定性和可靠性；同时，作为工作流引擎，不可能满足所有应用的要求，因此要求工作流引擎提供基于引擎进行二次开发的能力。 　　需要专业的应用架构平台。 　　作为业务流程驱动的应用系统，除了需要有工作流平台的支撑之外，同时还必须有相应的应用架构平台来配合、支撑，提供一体化的业务逻辑开发、调试、部署、管理功能，并通过图形化的构件组装加快开发速度，提高系统稳定性。

普元EOS工作流的产品组成与功能 选择EOS workflow的理由 让流程开发和应用开发更好集成

SOA潮流下的BPM

在SOA和BPM联合发展的浪潮下，我们首先要明确的是，BPM与SOA的本质是截然不同的：SOA是一种架构方法；BPM则是一组流程协调管理理念。在BPM的四大应用场合中，每一个都和SOA有千丝万缕的关系。

工作流的微内核架构

基于流程引擎技术构建的应用系统越来越受到客户的追捧和认可，能否支持“流程可定制、可更改、可运行”也逐渐成为客户衡量应用系统的主要标准之一。本文将从“源”角度来探索，讲解微内核过程引擎的设计思路和架构。

BPM向SOA迁移

许多组织的应用程序和技术结构包含各种不同的内容。通常包含各种应用程序筒仓（silo），各种应用程序之间的信息共享十分困难，因为技术平台和数据模型各不相同。

独立还是兼并？ 　　 ——中国工作流软件市场现状与趋势 　　独立的工作流软件提供商还有生存空间吗？这既是一个摆在众多专业工作流软件提供商面前的战略问题，也可以说是当前工作流软件市场中最大的特点。

工作流引擎的三种定位 

应该由谁来负责定义和开发工作流的应用？一般有三种观点，也就是我们对工作流引擎的三种定位：

1）完全由实际的技术人员来负责定义和开发工作流的应用

   我认为这种观点等同于不需要工作流引擎，它只适合简单、变化少的工作流应用；如果业务逻辑和业务
规则比较复杂，则需要自己定制相应的应用逻辑，并且不灵活。
2）业务人员和技术人员结合
  工作流产品提供图形化的界面，供业务人员定义业务逻辑；技术人员需要完成具体的应用逻辑。
3）业务人员独立
  该观点认为，应该把信息系统的开发融入工作流引擎中，即工作流引擎完成所有功能。

就国内目前情况看，大部分的关键业务系统没有应用工作流思想，即第一观点，该观点已经被证明是不正确的；国外的开源软件都采用第二种观点，因为它不能预测到所有的用户的应用需求；国内部分公司采用第三种观点，但目前还没有一个比较好的解决方案。

工作流是业务流程的全部或部分自动化，在此过程中，文档、信息或任务按照一定的过程规则流转，实现组织成员间的协同工作，以达到业务的整体目标。
工作流管理系统是支持企业经营过程高效执行并监控其执行过程的计算机软件系统。
典型的WFMS至少由如下几个模块组成：业务流程建模定义工具、过程定义、工作流执行环境（引擎）、任务管理。当然还会包括应用和IT工具。

常用的工作流引擎有osworkflow,jbpm,shark。刚学习了一点osworkflow，现在转向jbpm，公司要求，没办法。

osworkflow，最大特点就是灵活，这个网上都说遍了。也就是说它提供了一个引挚，在此基础上你可以进行扩展，可以自已写一些条件、动作类，只是继承它的接口就行，不需要修改它的源代码。他只提供一个工作流控制框架给你，他也只专注于管理工作流自身的东西，对其他的东西不管，其他的功能对他来说都只是一个插件组件。所以你可以自己扩展里面的功能，例如用户管理模式，工作流本身不带用户模式，他公司的另外一个项目osuser，可以结合使用来管理用户权限，当然你可以不用osuer，自己建立自己的用户模式，其实就是建立自己的运行判断条件；支持多种插件式的持久化机制；他的数据表也很少，就三个……



下面是引用其他网页的话：

Shark的流程定义语言是XPDL，我们知道，XPDL的两个最重要的概念是Process和Activity。XPDL中的Activity是基于UML1.x中的活动图的概念。活动图天生的适于工作流程建模，它相对于状态图的一个最大的优点是容易做并发线程的分叉控制，这些并发线程可以同时执行也可以顺序执行；它还有一个优点是有泳道的概念，可以控制工作流引擎中的任务的产生。Shark的如来神掌是活动图。

Osworkflow的如来神掌又是什么呢？我们知道，它有个重要概念是State……呵呵，我们知道了，它的如来神掌是FSM。不知道FSM是什么东西？？那你读大学时肯定不是好学生；当然了，不知道也不打紧，你把他类似理解为状态图就可以了。Osworkflow中的State是由step和status联合表达的，一个State就是一个step中的某个status；而state的转换由action来驱动，类似状态图中的event,因为一个event对应一个action嘛。

Jbpm的如来神掌就没有上面的简单了，它结合应用了状态图+活动图+PetriNet的知识，而且，这里的活动图还是UML2.0版的。UML2.0的活动图中，节点不叫活动（Activity）而叫动作(action)，活动成了一个高层次的概念，它包含一个动作序列。一个活动图展现一系列的动作，这些动作组成了活动。Jbpm把action也改名了，称为state。Jbpm使用的状态图的概念有transition/event等，这个自己去看吧。Jbpm来内部实现中还采用了PetriNet的概念，如token,signal等。什么？又不知道PetriNet什么东东？那你大学是学计算机的吗？不是？那你可能是学文科的，学机械/电气/土木工程/交通运输等专业都有接触PetriNet的课程，如果没有学过，还是看看jbpm吧，反正我们也不搞理论，知道大致概念就行。
参考资料：http://blog.csdn.net/hongbo781202/archive/2005/02/28/304751.aspx