关于工作流引擎的问题！

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

最近接触了一下BEA的工作流，用workshop来设计，感觉思路大开，觉得和当初单纯看OSWorkflow时有了更多的想法，而且觉得如果能够很好的处理和规则系统的接口可以实现很丰富的功能，而不用大量的编码工作。

我也是看了BEA的那套解决方案之后，才顿悟原来工作流/业务流程管理就是SOA的灵魂。缺乏工作流引擎的SOA是死水一潭。

YES,先握个手，我觉得如果用process管理加上各种分布的control来控制，用SOAP来传输，可以把整个系统整合起来

没有吧，至少我不是这么光看着审批此类咚咚，只是公文审批比较典型OA中应用工作流的例子。
OpenSource和商业的工作流引擎有的已经做的通用性很强了，就看你如何应用和实施，自己实现就要考虑很多了，不过如果用的范围不大，用个OS的或者自己写一个专用的也比较好，过度设计有时候没必要阿

如果只是做个公文流转，的确不算难。如果做个通用的工作流的引擎，能够适应多数企业的业务，恐怕就不是一件容易的事情了。这个意义上的工作流，如果能做出来，恐怕一半以上的作企业应用的项目的公司都不用做了。

看看先，噢是初接触workflow，兴趣很浓。

看来大家大多数应用工作流都是作OA公文那块。Oracle最近有一个商业应用流程管理模块BPEL，主线就是用工作流处理各类商类运营中的状态与规则。实际生活中各个单元的运作都是按一定流程操作，可以将workflow的应用扩展到许多领域。

SOA、Web Services体系下的工作流/业务流，是基于企业应用的流程集成，相对而言是一种松耦合的集成，不会很复杂。
基于工作流机制和工作流引擎或者中间件的应用开发，和业务流程集成不是一回事。

hehe, 工作流和业务流程实际上是一回事情。SOA中用工作流引擎做集成，和基于工作流的开发类不类似，关键看粒度。
当然，开发工作流引擎和使用工作流引擎，那肯定是两回事情。