对接口编程，为变化而设计，是面向对象编程的基本原则。工作流软件产品中的流程引擎的实现，主要是采用面向对象的设计原理。
工作流引擎负责对业务流程的抽象，对业务流程建模，以及业务流程的流转。在流程引擎中会设计一些基本的赋予一定意义的节点，组合这些节点给业务流程建模。
流程引擎负责解释这些节点，并通过面向对象的编程方式，每个节点对应一个类，节点的属性和方法均在类里面有所体现，表现为类的属性和方法。当流程实例运行时，在流程引擎中建立这些类对象的实例，实例化为业务流程的每个具体节点。
我们都知道，每个业务流程在运行时，都会有这样或者那样的特殊要求，例如，当财务经理审批通过报销单后，需要给报销申请人发送一个电子邮件，通知报销申请人，报销申请通过了；当一个保理结算模式的支付方的银行账户发生变化时，需要记录变化的轨迹。等等这些都可能是针对每个具体的业务流程有自己的特殊要求。在流程引擎中是不可预见的，或者说是具体的业务处理过程，和流程引擎无关。
为了适应这些变化，为变化而设计，我们设计了接口，每个业务流程中有特殊的业务处理过程，就写一个业务实现类，并实现这个接口。在业务实现类中写自己的业务处理过程。并将这些业务处理类挂接到流程的节点上，使得到达节点或者离开节点，会触发执行这些业务处理过程。流程引擎就负责解释这些节点，并调用这些节点上挂接的具体的业务处理类。当没有特殊需要的时候，即没有挂接业务处理类，则不处理。就象传统编程工具中控件的点击事件，变化事件，按键事件等一样。
在工作流软件产品中，事件分为两类：
前置事件：
当流程实例到达一个节点的时候，触发前置事件。
后置事件：
当流程实例离开一个节点的时候，触发后置事件。
在eworkflow工作流软件产品中，前置事件后置事件等在下面这些节点中都有体现：
步骤节点：步骤表示一个业务环节，当流程实例到达这个节点的时候，会触发他的前置事件。
动作节点：动作节点表示一个业务环节中需要处理的事情，如提交填写的报销单，执行审批通过等。执行一个动作，先触发动作中的前置事件，再执行流程的动作，再触发动作中的后置事件。
动作结果连线：执行完动作后，根据动作结果导向下一步，当动作执行完成后，先触发动作结果中的前置事件，再执行动作结果，再触发动作结果中的后置事件。
流程实例的流转，通过执行一个动作，动作结果导向另外一个步骤，这样来达到流程的一次流转。在流程的一次流转中，会涉及到流程的多个节点，步骤，动作，动作结果，分支，合并 等等。
在一次流转中的各个节点的前置事件，后置事件，节点的办理顺序如下；
步骤的后置函数－》动作的前置函数－》完成本步骤的任务－》检查动作结果中的条件（不成立则无条件结果）－》动作结果的前置－》 创建新的当前步骤（执行新步骤的前置函数）－》 动作结果的后置－》 动作的后置函数
流程实例的一次流转，节点中业务过程的办理，通过动作挂接的业务表单来实现，通常在工作流软件产品中都会集成一个可视化的可自定义的表单工具，通过表单工具可视化的制作业务表单。
在业务数据填写完成后，通过表单工具提交到表单引擎，表单引擎也设计了一序列的接口事件。表单的提交，就有前置事件和后置事件。
前置事件：
表单数据提交之前自动触发的一序列函数，或者自定义的处理过程。
后置事件：
表单数据提交之后自动触发的一序列函数，或者自定义的处理过程。
无论是工作流引擎还是表单引擎，在处理前置后置事件的时候，均需要将一些流程上下文或表单上下文的信息传递到事件中，使得业务处理类事件中，能方便的获得环境的上下文信息，例如，当前的执行人，流程的实例id，表单的业务记录id，甚至当前的数据库连接，使得业务处理类的数据库操作和流程或表单的处理过程是在同一个事务中。这点很重要，业务处理过程事件中，不能单独的去重新获得这些信息。否则这种业务处理过程剥离了流程处理过程，就没有意义了。
相信在不断的完善流程引擎表单引擎等的过程中，这些事件的设计和处理会变得更加完善和精确........
