BPM介绍继续（之前那篇有点长了）

继续 粘贴前人的一些 关于 workflow 的想法，现在看看很多当时的想法已经变成现实，但是对于我这个 流程引擎的新人还是有必要学习下的，争取尽快把自己的知识更新下，修改下自己当前使用的一个 引擎框架

流程引擎在上世纪70年代就在办公自动化领域展开，但最初是失败的，一方面由于当时计算机的普及程度不够，另外一方面“人们观察到这样一种现象，一个成功的组织往往会在适当的时候创造性的打破标准的办公流程；而工作流技术的引入使得人们只能死板的遵守固定的流程，最终导致办公效率低和人们对技术的反感。（from wiki http://zh.wikipedia.org/wiki/%E5%B7%A5%E4%BD%9C%E6%B5%81%E6%8A%80%E6%9C%AF）”

OSWorkflow 的 GUI Designer 确实很差，不过我们可以手工编写流程定义 XML 文件。如果要给最终用户用这个 Designer，项目组要对它做扩展才行。

试用了一把 OSWorkflow，个人感觉还是不错的，它的工作流模型比 WfMC 的简单，而且感觉更灵活一些。

我觉得工作流之所以在国内不流行，是因为原来 WfMC 定义的模型太死了，在实际应用中有人工干预流程的正向、反向、任意跳转的需求，但 WfMC 没有提供这方面的支持，一般的工作流引擎对这方面支持的也不好。基于 OSWorkflow 开发一个适合实际情况的工作流引擎是可行





工作流引擎我曾经负责了很长时间，做过两个，一个很土，很早以前用数据库触发器做的，很好实现，数据驱动的小型办公应用可以试试用这种方案，另一个在02年时和三个小伙一起做的，也不是很麻烦，把wfmc简化了做的，03年则用的是开源的工作流引擎。

符合wfmc的开源工作流引擎很多，光有工作流引擎，只能在开发时使用一下，想做成一个完整产品还需要很多东西。

一个业务应用，比如OA的审批流程，需要很多引擎来支持，比如组织机构、角色、规则、文档、表单、脚本等，如果再加上工具，那么跟做一个Notes也没有什么区别，所以工作流产品想做到业务人员轻轻拖拽就可以把一个应用从无到有配置出来，我认为是不太可能的，不可能一行代码都不写。

工作流应用比较麻烦的是表现和规则，表现处理我们一般称为Form引擎，主要包括：在Form上每个字段域要进行校验、操作方法、显示、权限等定义处理，Form的模板选择、操作方法、控制数据对象集、档案夹等定义处理；规则则要求工作流引擎能通过规则引擎或者脚本引擎来调用业务对象的方法或属性，并能用表达式进行处理，这跟编写程序没有什么区别。

还有一种类型的应用，更注重业务规则，表现形式不是很重要，比如在电子商务的应用中，购物车程序可以视作一个pipeline型工作流应用，每个活动的处理，都可能会和规则打交道，比如折扣规则，业务人员可以通过修改规则配置文件来及时调整折扣策略。

我个人看法是工作流引擎和设计配置工具想做到极度通用对一个公司而言难度较大，主要在于设计工具，很麻烦，光一个Form Designer就跟做一个Frontpage没多大区别，还有规则定义等。

工作流引擎有两种用法：

一种是将它纳入到公司的开发框架中，在某些业务领域使用工作流引擎，使产品或者项目有良好的架构和灵活性；

另一种就是做工作流应用产品，比如我们常见的工作流产品一般都是OA的公文流转应用，商务上叫工作流，是具体的业务应用模块。
根据产品的业务特点，先进行模块封装，比如OA中的流程审批，可以先把流程、活动、业务对象等基于工作流引擎进行预定义形成应用模板，然后基于业务模块编写配置程序，用户可以在此配置程序上进行配置，一般可以满足要求，如果用户的业务出入不大，但配置起来较麻烦，那么修改配置文件，实施工程师培训一段时间后就可以做，如果根本就是不同的业务，那只能二次开发，这时就是重新开发。

脱离业务的工作流引擎，对于不是专门做中间件的公司而言，可能很难在市场上有所作为，除非有行业背景或者政府支持。




看来对工作流的研究都不少啊。做过两年的工作流，主要是为OA做的。OA大概是最容易联想到工作流的，因为公文流是个天然的流程处理。也是基于WfMC做的，但WfMC的规范里缺少对细节的描述，比如接口3，就是工作流与应用间的数据交互。虽然这与应用的关系极大，但规范缺少了实质的指导意义。
基于WfMC的模型，可以把工作流的架子搭起来，基本的流程控制没有问题，但对于实际业务中复杂多变的环境，比如OA中，随意更改或增加的活动（完全由人来确定，很难完全穷举），规范里对这方面的论述极少。但总的来讲，流程的控制还是比较容易实现的，流程控制的难点是实现会签这类并行的处理，用户甚至提出会签的每个流程都是不同的，而且可以不必全部完成，就可以继续处理。我考虑是用子流程来实现，但对状态的控制还是要求有同步点，即子流程必须全部结束。
个人认为，工作流的难点之一在于工作流和由它驱动的应用来如何交互数据，使得工作流能够以预定的方式来运转，完全自由的工作流实际就失去了工作流的意义，比如OA里的交办事项，一个一个传递下去，完全依据工作内容和人的判断来处理，这时程序就很难控制去做判断。有人就采取了自由流的做法，不定义流程，依据实际的行为发生来确定流程的实例。这个就不多讨论了。数据交互的问题，也影响到流程的定义，以及应用的对外接口。为了避免过于死板的流程，在定义时就能有足够的灵活性，尽量兼顾可能的流程控制。由于工作流面对的可能是不同的应用（当然，完全的通用工作流依我看是不可能的，或者说没有必要，因为工作流是为应用服务的），数据接口部分就可能比较通用一些，并且不能理解数据的含义（因为难以定义），只是机械地根据数据做判断。应用也需要根据这个接口，提供数据访问接口（应用的改造看来是不能避免了）。有用户跟我讨论过应用来驱动工作流，但我认为这样的话，应用本身会包含太多的流程的信息，使应用复杂化了，所以应用和工作流之间还是存在一个中间层，来隔离相互间的影响，但这个中间层的存在，使得客户化的工作不可避免。BEA的weblogic integration就是利用reflection,在定义时指定类和方法，来做工作流和应用的交互，这也是个办法，但对于行业应用而言，可以制定一个比较通用的数据接口标准。
我们也试图为多数的审批流程提供表单的定制，并确定了和工作流的接口，只做了个原型，就放弃了，因为没有找到合适的实现技术。不过，这方面的尝试还在继续。




最近接触了一下BEA的工作流，用workshop来设计，感觉思路大开，觉得和当初单纯看OSWorkflow时有了更多的想法，而且觉得如果能够很好的处理和规则系统的接口可以实现很丰富的功能，而不用大量的编码工作。
我也是看了BEA的那套解决方案之后，才顿悟原来工作流/业务流程管理就是SOA的灵魂。缺乏工作流引擎的SOA是死水一潭。
YES,先握个手，我觉得如果用process管理加上各种分布的control来控制，用SOAP来传输，可以把整个系统整合起来



我也是给oa做引擎的，不过在我看来，引擎根本不能称之为引擎，也许是我的用户要求问题吧。工作流应该是自动流转的，但是我们做的根本就不需要，全部是人工在选下一活动和处理人，我不清楚是不是所有的用户都是这样的要求，至少我现在做的就是这样，后来想想，我的工作流引擎最终被使用的意义仅仅是给选择处理人时设定了一个范围，也就是performer标签定义的那个id而已，其他的都是没意义的东西



说说我的看法：
我认为工作流引擎是实现业务流程管理的技术实现。不管他是基于什么标准的，无非engine, processes, and activities.但是现在的技术人员个个都是好汉，有标准也不遵循，这不，几个大公司BEA，IBM，M￥等现在为工作流引擎技术制定的BPEL标准吗？我认为这个是有前途的，不过现在网上的资料很少。
工作流引擎技术是为了实现业务流程的管理，经过近一周的学习和实践，我自己有如下的感觉：
1）、基于单个应用内的工作流引擎技术，比如OSWORKFLOW，当然他也支持RPC，但是我没有试过。
2）、基于多个不同应用内的工作流引擎技术，它的技术实现要依靠web service来进行实现，本人推荐的实现组合是：AXIS+J2EE+ACTIVEBPEL ，我的J2EE是STRUTS+SPRING+HIBERNATE　的MVC框架，使用SPIRNG和AXIS组合使用。业务流程由BPEL4WS生成，主要有两个文件.bpel和WSDL，由ACTIVEBPEL服务器分析并与AXIS服务交互。

我的示例正在调试当中，假如完工合一定给大家发一个示例上来。

如果有什么不同的看法，欢迎大家讨论
msn:[e-mail]



以偶的经验来看，1人开发一个基本的工作流引擎需要6个月，能够支持特复杂的流程再加6个月。加上设计器，监控器等GUI可能还要再加3个月。一般是拿开源的来改，比如我们用enhydra shark，它完全按照wfmc标准开发，而且做了很多模块的反射配置，方便拆卸，经典案例是把数据库管理由DODS改成Hibernate。

BPEL没用过，不予评论。

光有引擎没用，要考虑在什么地方调用引擎API(主要是业务逻辑处理完之后)，如何与表单、查询列表结合，组织结构，权限设置等等。

感觉目前工作流引擎产品的第一轮蛋糕已经分得差不多了(国内公司10+，国外公司4+，04年底的数据，相关数据所在论坛已关闭)，再做引擎开发可能要做好打价格战的准备。

可能接下来比较需要具备将工作流引擎和其他模块整合的技术。



结合实践我们多讨论一下基于企业应用的工作流技术，提提这方面的需求和功能看。我先说以下几点：
1. 人工步骤、自动步骤、定时步骤。
2. 同步分叉和选择分叉，多用户接收，多用户接收占用策略。
3. 聚合Or和聚合All。
4. 安全退回，安全终止
5. 接收者实现可配置，也可以由客户端程序自定义。
6. 接收者委托机制。
7. 工作日机制。



从技术可行上说说我的看法：
我现在使用的技术如下：
BPEL做业务流程建模，并依赖WEB　SERVICE发布服务，生成相应的服务代理　
WEB　SERVICE描述流程控制
使用MVC架构构建J2EE架构，在控制层引用业务流程的服务代理，并做事务处理。
可以参考如下框架：
优点：可以在多个异构应用间（伙伴）重组业务流程；
本人已经使用WebSphere做中间件服务器，以STRUTS（ACTION当中引用服务代理）+SPRING+HB,已经测试通过。认为是一个可行的技术实现，也是一个成熟、容易理解的操作，很快将会伴随着WEB服务的一起火热。
　


没有办法的事情
老外用流程规范业务
中国要流程迁就人和业务，能用就怪了

但是客户指定要工作流。。。。中国IT，嘿嘿



偶目前在修改OSWorkflow来适合公司的需要，在我看来选用工作流产品，需要考虑两个问题：
1。工作流在应用中的位置
2。工作流的表现形式

问题一：工作流在应用中的位置
1。以工作流为核心，是工作流"拉"应用
2。以工作流为模块，应用"推"工作流运转（你们的OA估计是这样的类型）

那么采用推、拉都要看具体的应用，如果你们的应用开发是后期采用工作流，这个时候工作流更像是一个模块，采用推的模式也许更适合一些；而OA这样的应用也许更应该以工作流为核心

问题二：工作流的表现形式
至于将工作流作为独立的应用、模块、服务或者其他什么类型，都仅仅只是工作流的表现形式而已，在确定了工作流的位置就可以考虑它的表现形式了。

评论

1 楼 comsci 2011-12-25  

看法和观点都不错。。。