什么是工作流引擎

什么是工作流引擎（Workflow Engine ） 2007-12-24 13:55 所谓工作流引擎是指 workflow作为应用系统的一部分，并为之提供对各应用系统有决定作 用的根据角色、分工和条件的不同决定信息传递路由、内容等级等核心解决方案。例如开发 一个系统最关键的部分不是系统的界面，也不是和数据库之间的信息交换，而是如何根据业 务逻辑开发出符合实际需要的程序逻辑并确保其稳定性、易维护性（模块化和结构化）和弹 性（容易根据实际业务逻辑的变化作出程序上的变动，例如决策权的改变、组织结构的变动 和由于业务方向的变化产生的全新业务逻辑等等）。 Workflow 引擎解决的就是这个问题： 如果应用程序缺乏强大的逻辑层，势必变得容易出错（信息的路由错误、死循环等等）。 就好比一辆汽车，外表做得再漂亮，如果发动机有问题就只是一个摆设。应用系统的弹性就 好比引擎转速方面的性能，加速到 100 公里需要 1 个小时（业务流程发生变动需要进行半 年的程序修改）还能叫好车吗？引擎动不动就熄火（程序因为逻辑的问题陷入死循环）的车 还敢开吗？ 工作流解决方案与传统管理软件的关系传统的管理软件注重解决企业应用层现存的问题（例 如提高企业的资源配置率或提高单一员工的生产效率）。例如：EXCEL 可以提高员工画表格 的效率、财务软件可以规范财务人员的工作并提高帐目查询的效率、CRM 可以规范客户管理 从而使客户资源掌握在公司手中而不是被一部分业务人员把持并提高客户响应时间、ERP 解 决的是如何配置企业资源：使企业的人力资源、财力资源和物资资源能够根据业务的需求实 现最大化配置。 workflow 关注的是如何缩短流程闲置时间，从而提高企业的业务处理能力 并使企业能够关注于真正对企业有意义的增值业务上。从建立企业神经系统的角度也许更能 理解两者的区别。传统软件不能解决工作流的问题，例如 ERP 关注的是企业的资源配置，但 不可能解决资源传输过程中的损耗和降低传输（流程）的成本；同样 workflow也不能完全 解决传统管理软件所能解决的问题，例如对生产管理的 MRP 系统所能解决的生产过程控制通 过 workflow很难实现。但一个好的传统软件如果希望能自动化地在整个企业中应用起来， 必须有一个强大的逻辑层，用以解决信息传递的逻辑判断和自动流转，这个时候就需要 workflow的平台。所以说： 1.workflow 和传统管理软件不是同一种软件，不具可比性； 2.workflow 对于已经有传统管理软件的企业的作用非常明显，可以籍此平台整合企业的各 种应用系统，使之成为一个完整的企业级应用，也就是通常所说的 EAI. 3. 具备 workflow 功能的管理软件（workflow 与传统管理软件的结合）对于传统管理软件有绝对的优势； 4.workflow可以根据企业的需要开发解决信息传递问题的流程以及帮助企业开发与现有应用 系统的接口 工作流自动化并不复杂因为下述几个原因，工作流自动化业界有“ 适合处理复杂业务流程“ 的名声。 1.常规工作流自动化软件包及其部署相当昂贵。通常，伴随产品的是长时期的咨询关系。所 以为了非常简单的业务流程购买和部署软件是被不被采纳的。这些软件通常只被用于复杂、 关键和控制成本相对较高而工作流自动化带来的效益明显的量产型工作流应用。因此经销商 和用户都会不自觉地关注于将复杂的业务问题自动化。 2. 处于类似原因，工作流研究人士 首先会关注解决了哪些复杂的业务流程问题。 而对于大多数案例而言，为解决简单工作流程问题部署自动化软件的成本显然是不经济的。 这里遵循一条简单的道理：走之前必须先会爬，跑之前必须先会走。 3. 最后一条原因，也 是“IT 业的尴尬“.总经理对 IT部门经理工作衡量的标准就是：能够解决复杂问题的能力。 自然，IT 经理就会不遗余力地解决那些复杂的问题，他们的方案通常也就复杂而且昂贵。 所有这些目前都在改变。针对桌面电脑的应用方案快速发展以及工作流解决方案的发展使解 决日常工作流程问题成为可能。费用不再昂贵，部署更为简便。事实上，企业越来越意识到 工作流的重要性，同时在部署复杂关键的流程自动化之前，愿意从一些简单的流程入手积累 经验。 工作流会成为操作系统的一部分吗？ 有人认为工作流会成为操作系统平台（例如 WINDOWS 平台）的一部分。我们的观点是，基于 下述几个原因，在可预见的未来，工作流不会成为操作系统的一部分： 1. 扩展表格、文字 处理程序和数据库存在了 20多年，成了家喻户晓的名词。这些技术被广泛理解和应用，也 相应形成了各自的标准和相关术语。然而因为很多原因，直到今天这些技术也没有成为操作 系统的一部分。最重要的原因之一是用户需要差异和选择的自由。相比较而言，工作流自动 化软件是较新的技术，也更有差异性、不易被广泛理解并且比这些技术更为先进。因为工作 流程的差异性和复杂性，工作流自动化的用户需要更多的选择空间。 2.财务软件包从电脑发明后就迅速普及了。这是实施、术语和规则被普遍接受的另一个领域。 然而至今也没有哪种操作系统吹嘘集成了多少财务软件的功能。而工作流自动化软件比财务 软件更为复杂和有差异性。 3. 操作系统提供商，例如微软和 Sun ，不会为了使其系统具备 工作流自动化的功能而大量改变他们现有的系统。他们有什么必要为工作流自动化软件投入 开发和支持的成本呢？ 4. 操作系统是为常规条件设计并使之最优化。正因如此，目前操作 系统的开发成本几乎都要上亿美元。业务流程十分复杂并充满了例外情况，如在操作系统中 内嵌工作流自动化程序会极大地增加开发成本和难度。因此，即便操作系统提供商决定做工 作流软件，也会是巨额投入开发一套新的操作系统，而不是将工作流嵌入。 事实上，今天的很多优秀的工作流解决方案集成了短信息、页面服务、目标管理、文件管理 和其他一些操作系统才提供的服务。 工作流自动化的主要成分工作流自动化如今成了管理的一句时髦话。市面上也有很多号称能 激活工作流的自动化产品。只要他们的应用程序支持基本的 E-mail功能，卖主就会随意地 把“ 激活工作流“ 作为标签贴在产品上。然而，这类产品和真正工作流自动化软件之间的差 别就如同写字版和 Word之间的差别。我们相信，应用程序只有具备了下列主要特征，才能 称其为工作流自动化解决方案： 能够画出工作流程图，当然以图形化界面设计的为佳；能为每个步骤设计电子表格；能将外 部应用程序结合为工作流自动化的一部分；能与电子表格及企业数据库相连接；能设计基于 复杂业务规则的条件型路由的工作流程图，最好无须编程；能根据功能、用户名称或上下级 关系按规则传递信息；能够监控工作流执行状况；能够对工作流进行调节；能够模拟并测试 工作流的行为；工作流的应用必须支持多用户并具高度可靠性；工作流的应用必须支持内部 网或英特网及跨多种平台。 网友讨论工作流应该是一个中间件而不应该是一个完整的系统。工作流应该整合到其他系统 中而不是单独使用。 工作流要完成的核心功能有流程设计，流程执行，流程和线程的调度，任务的分派与通知， 集成已有信息系统（很多人忘了）。 工作流应该提供对组织机构，用户，权限管理，流程，任务的管理能力，但是对这些管理能 力最基本实现方式是提供 API ，而不是一个管理系统，即使把这些管理作为一个管理系统来 实现（A ），也主要是用于演示，因为当工作流用于其它系统（B ），因为 B 需要一个统一 的管理界面，所以通常不会直接使用 A.而表单设计，报表之类根本就是外围功能，是二次开 发商的任务。 我基本赞同 wangtaoyy 的说法，再补充一点。我觉得工作流与其说是中间件，还不如说是一 个应用整合和集成的框架。类似在 j2ee规范下各产商开发的应用服务器，工作流也应当是 在 wfmc标准下开发出来的“ 容器“ ，只要是满足了标准的应用程序或组件都能够在这个“ 容器“ 中按照预定的规则被调度和执行。我认为理想情况下工作流系统不应该提供 API 作二 次开发，工作流的内部对基于工作流的应用程序应当是完全不透明的，工作流应当提供给开 发者的是一个类似于 J2EE那样的标准，一套编程模型和接口模型。开发者在这个模型下去 实现那些接口，开发出应用组件，再利用工作流提供的管理器进行“ 注册“.总而言之，对开 发者而言，工作流是黑箱，他需要做的事情是开发标准组件，在工作流提供的 UI管理工具 中配置业务流程，包括业务过程、资源、权限、时间、规则等等。 1. j2ee 应用服务器也是中间件的一种。 2. 工作流要做成 j2ee哪样的标准还是比较困难的， j2ee 重点在于提供开发全新系统的能 力，所以可以制定比较好的容器- 组件标准，而工作流的重点是整合已经存在的系统，要在 这些各式各样的老系统上强加标准是不现实的。 3.工作流应该提供 api ，因为其他系统中的一些事件可能会启动一个流程，或者触发其他与 流程相关的东西 工作流分为两种类型，一种是嵌入式的，另一种是非嵌入式的。这在 WFMC的文档中已经有 所介绍，大家可以找找看一下。按照工作流管理联盟的文档，大家说的都没有什么错误，只 是侧重点不同。wangtaoyy 的观点倾向于前者，而 coffeewoo 的观点倾向于后者。 我的看法并不是趋向于嵌入式工作流。我理解的工作流提供的 api 并不是一般软件包的 API ，而是一种服务方式的 API ，类似于操作系统中的系统调用。 我们在软件中大量使用了操作系统提供的系统调用 API ，但是操作系统并不是嵌入到我们软 件系统中的。我认为工作流系统与操作系统有很强的可比性，只是工作流层次更高。比如流 程设计相当于编程，模型相当于程序，流程实例相当于进程，流程分支相当于线程，操作系 统要对进程和线程进行调度，工作流引擎要对流程实例和分支进行调度，操作系统和工作流 系统都应该对内存进行管理避免耗尽系统内存，操作系统提供系统调用 API 而工作流引擎提 供工作流 API.何其相似。 从功能的角度看：工作流系统的本职工作就是管理和控制业务流程，例如：流程实例的启动、 停止；环节实例的启动、结束；任务的分配等等。从工作流系统的组成看：工作流系统应该 包括流程引擎、流程定义工具、运行管理工具、api 系统。工作流系统应该该不包括表单定 义、组织机构定义及其管理、权限管理、数据流管理等等。 工作流系统虽然不包括上述功能，但是工作流系统一定会和上述功能发生交互关系，所以好 的工作流产品并不是一个包办上述功能的产品，而是一个设计良好的能够和上述功能交互的 系统。从和其他系统的关系看待工作流：如果站在基础业务平台的角度，那么，工作流系统、 组织机构管理系统、表单自定义系统、权限管理系统、数据流管理系统、报表系统都是这个 基础业务平台的服务。业务功能系统在运行的过程中会调用这些服务，这些服务之间本身也 可能互相调用。例如：工作流服务和组织机构管理服务之间的关系就非常密切，尽管如此， 如果认为工作流系统一定包含组织机构管理系统应该是不正确的。在 oa系统中，表单自定 义好像比较重要，而且流程常常需要引用表单上的数据，但是表单自定义绝对不是工作流系 统的组成部分。