什么是工作流引擎？用一句话来描述我觉得应该是：驱动任务按照预定义的业务规则在参与者之间进行流转，最终完成特定业务处理的功能组件。那么什么是工作流系统呢？我觉得应该是：建立在工作流引擎基础上的一系列的用户交互、监控、仿真、评估等功能组件的集合，也就是围绕引擎展开的与业务松耦合的辅助组件的组合。
下面先从引擎说起，按照上面的定义，引擎的关键点在于驱动、规则和参与者。驱动实际上是建立在特定流程模型上的，例如：发送、回退、跳转发送、跳转回退、发散、汇聚等。规则是建立在流程变量上的运行时流转路线定义，它可以是一段脚本或者是一条sql。参与者则是任务的实际处理者，可能是时间，可能是人还有可能是其它外部设备输入。
举个简单的例子，如下图的请假流程：
申请人提交请假事由，如果请假天数小于7天，那么经理直接审批结束即可，如果大于7天，那么经理审批后需要人力主管备案结束流程。在这个过程中，应该发到哪个环节是业务规则决定的，怎么发是引擎控制的，谁处理取决于环节参与者的设置。工作流的核心实际上就是上面这三部分的内容，当然上面仅仅是一个最简单的应用场景，实际业务场景可能比这要复杂的多，但是核心思想是这样的，无非是实现逻辑的复杂性高了些。在这三部分中，流程驱动模型的实现最为复杂，很多情况下无法实现所有的模型，往往根据产品的市场做一定的取舍，但是一些基础的模型是必须要支持的，如上面提到的六种。业务规则的处理需要实现业务规则引擎，因为业务规则的多样性和复杂性一般来说规则引擎需要支持业务扩展；同时需要做好业务数据和流程数据的转换，避免流程和业务的耦合。参与者相对于业务规则来说要简单些，毕竟是系统级的，但是要充分考虑到系统集成等因素的影响。
上面我们描述了工作流系统的核心，但是这对于一个完善可用的工作流系统来说是远远不够的，因而我们需要做一系列的扩展，达到更好的友好性和可用性。
根据wfmc的定义，我们需要必要的流程定制工具，即通过可视化的界面来编排流程中环节个数，环节之间的先后顺序，同时设置各个环节的参与者，环节之间流转的规则。当然，我们也可以通过手工编写流程脚本或者组装xml的方式来达到定制流程的目的，但前提是你可以说服用户，同时教会他们该如何做这件事。如果你面对的不是具有编程能力的开发人员，我觉得这似乎是一项艰巨而不可能完成的任务。对于定制工具来说，必须要提及的内容便是定制流程的数据表示，目前主要有三种国际规范，即xpdl，bpel，bpmn。具体使用哪一种需要权衡，或者可以以一种为基础进行相互转换。当然你可以自己定义格式，但是在企业应用集成的大环境下，这很难站住脚。
流程定义之后便是流程的运转，引擎按照规则将任务发送给参与者，如果参与者是人（参与者是时间或者外部输入的情况在此暂不讨论）那么必须提供任务处理入口，这便是任务列表。任务列表的实现一般是多样化的，因为它需要呈现给多样化的人看，这些人可能是不同级别的，可能是不同行业的，他们所处的环境不同，视角不同，关注点不同。例如，如果一个生产型企业申请营业执照，那么需要通过环保局和工商局的审批，但是这两个委办局关注的业务点肯定是不同的，环保局可能关注企业的环保设备型号、处理能力、排污标准等业务信息，而工商局可能关注其生产设备、生产条件、资质等业务信息。关注点不同，任务列表呈现的内容就不同。再例如，在环保局中，科长可能只关注科室下目前有多少正在处理的任务，都是什么类型的任务；而科员可能关注每一条任务的具体内容和状态。参与者层次不同，任务列表呈现的内容也不同。
流程定制工具、流程引擎、任务列表以及完善的工作流查询、操作api几部分构成了一个相对完善的工作流系统，能够满足大多数业务需要。但是随着流程系统的发展，越来越多的特性融入了进来，例如任务监控、流程仿真、统计分析等。流程监控能够让用户以更直观的方式查看流程、业务信息。仿真和统计分析则可以通过对流程制定各种监控指标，并以此指导用户优化流程，或者进行绩效考核。
