所谓工作流引擎是指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系统中，表单自定义好像比较重要，而且流程常常需要引用表单上的数据，但是表单自定义绝对不是工作流系统的组成部分。流程在运行的过程中可能跨多个数据库系统，任务在流转的过程中需要“携带”大量的业务数据，但是这些也不是工作流要做的事情，完成这些工作的系统我称之为“数据流管理系统”。总之：从功能的角度，所有的功能都是必要的，但是从技术的角度，这些功能不可以做到一个“铁板一块”的所谓的“工作流”里面去。从技术发展的趋势看：工作流系统很可能发展成为一个类似关系型数据库管理系统的专职的系统。我那个工作流东东还在改进中，希望作出一个设计合理的（决对不是强行coding出来的），工程实用的东西出来
就好比一辆汽车，外表做得再漂亮，如果发动机有问题就只是一个摆设。应用系统的弹性就好比引擎转速方面的性能，加速到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系统中，表单自定义好像比较重要，而且流程常常需要引用表单上的数据，但是表单自定义绝对不是工作流系统的组成部分。流程在运行的过程中可能跨多个数据库系统，任务在流转的过程中需要“携带”大量的业务数据，但是这些也不是工作流要做的事情，完成这些工作的系统我称之为“数据流管理系统”。总之：从功能的角度，所有的功能都是必要的，但是从技术的角度，这些功能不可以做到一个“铁板一块”的所谓的“工作流”里面去。从技术发展的趋势看：工作流系统很可能发展成为一个类似关系型数据库管理系统的专职的系统。我那个工作流东东还在改进中，希望作出一个设计合理的（决对不是强行coding出来的），工程实用的东西出来