1。把工作流引擎看作一个服务器，提供容器服务；
2。把任务节点放入任务容器内，以此实现任务节点的配置；
3。任务容器之间通过标准的方式进行通信；

那么，以上述方式来看待工作流引擎有什么好处呢？
好处是，这样一来，我们的思维就不再混乱，而且知道我们的主要精力应该放在思考如何进行任务的抽象（以便实现容器）和如何确定任务之间的通信方式上。

任务容器的抽象要点是：关注如何实现任务节点的配置，即任务节点之间如何进行挂接；此外，容器还要考虑任务之间的通信方式，这里我把通信方式特指为任务之间的数据交换方式。

任务节点之间的挂接策略有两种：
1。注册
向需要挂接的其他任务节点注册自己。比如在实际中有任务A和B，任务A之后到任务B：A向B注册自己，且注册的实现代码放在B中时。这是从主动者的角度思考的挂接策略，因为A是推动流程进入B的主动者，且该推动作用是用A来发起的（A主动向B注册）。
2。监听
向自身加入监听器，监听器由需要挂接到的任务节点实现。当A出现所需的事件时，B进入工作流的下一步。推动工作流的是B任务，但是却是由B引起的，所以这是从被动者的角度思考的挂接策略。

不管是注册的策略还是监听器的策略，都应该作为任务容器的一部分来实现，任务节点本身就可以集中精力来考虑自己的业务逻辑，不至于在交互上花费太多精力。Java中设计接口元素的本意就是用来实现策略，因此任务容器应该提供一套注册接口或者监听器接口以便实现挂接功能。

要实现任务节点通信方式的一致性，有两种方式：一是采用统一的数据格式，更进一步则是采用统一的数据分析策略。采用一致的数据分析策略包含了采用统一的数据格式。统一的数据格式在策略上是死板的，而一致的数据分析方式可以允许数据格式不一致，但是所有的数据都可以采用一致的数据分析策略得到一致的数据。至于如何制定一致的数据分析策略，就看设计者如何考虑了。Java的属性就是靠分析属性名得到的，它采取的就是分析策略的方式，这里面有很多好处。一致的分析策略可能比较难设计，但是有些情况下因为数据形式变化太大，很难为通信制定统一的数据格式，就有必要考虑分析策略的方式了。

dragon_jdh的观点给我很多启发，等我实践之后再回来和你们深入探讨吧。

工作流引擎运行原理
概念：
一、 工作流引擎：控制部署在其上的工作流的生命周期，产生相关的任务列表可以把他比喻成操作系统。
二、 工作流模型：即工作流的定义，以一个（.xpdl）文档的形式存在，可以把他比喻成应用程序的源代码。
三、 工作流实例：工作流模型在引擎上的一个部署，部署包括模型中生命的资源、变量的注册和绑定，可以比喻成一个部署好的应用。
四、 工作流进程：工作流的一次运行、一个任务，相应的，可以比作应用的一个进程（process）。
五、 活动：actionID,actionName, actionURI,parametersMap

六、 表单：一个数据结构，包含若干个字段，可以比作数据库的模式（表结构）
七、 报表：某一类表单按照一定的条件过滤筛选后的结果，可以比作数据库中的表和视图。
八、 表单和报表并不在工作流中流转（他只存在于报表服务器），它记录并知道自己属于哪个工作流；工作流引擎只与活动打交道，工作流引擎知道如何给活动传递参数，如何从活动取得结果，这样活动就能够在工作流与报表服务器之间传递相关数据了。
工作流运行机制：
因为工作流系统是一个典型的异步系统，适合采用基于消息的设计，J2EE为我们提供了JMS和MDB这两种有力的工具，这也给我们的设计定下了大的基调。
一、事件触发的工作流：
（用word画的简单流程图）…………

二、时间触发的工作流：（例如每周工作报告、季度考核报告）

我觉得不大可能吧，对于简单的流程，完全可以使用jsp/html完成，但是对于一些复杂的流程，比如有转办、流程的分化和会合操作，如何通过jsp/html完成；况且对于每一步的操作都需要请求服务器，这样的操作将会非常的慢；

我想应该是Interface2 吧。