以现实中都接触过很多次的生活经历来开始今天的话题。很久没有写信了，自己准备给家里写一封信，于是我就做在桌子旁边写信了，经过几天的酝酿构思，信很快就完成了。写完之后我就准备去寄信了，买了一个信封和几张邮票，把收信人以及收信人地址，寄信人，寄信人地址，邮编等信息都写好了，然后我就到邮局就寄信了。一个星期之后，家里来电话说收到信了。于是我的信经过很多途径终于完成了旅程。
在上面的描述中，我们可以得到下面一个概念：信件，信封信息，邮局，我，以及我家。邮局根据我提供的信封信息，把信件通过某种途径送到了我家里。这个就是整个时间的简单描述。其中邮局递送信件采用的是他自己根据行政划分以及经验建立起来的传递路径进行传递。
说道这里我们回头看看，工作流引擎的责任，用户提供流程定义XPDL（流程传递信息，以及流程处理的每个环节信息），流程业务处理信息，流程参与者信息，工作流引擎需要做的事情简单上说，只是接受用户指令，包括建立流程，派发工作项任务等等，然后引擎把工作项分发到指定的参与者，具体的每个参与者必须进行的业务操作是流程不感知的，流程只是知道那些人需要做事情，但是具体做什么业务并不知道（就像邮局不知道我的信件内容，他把信件送到我家就算完成任务了，我家人才知道具体的信件内容）。当然我们寄信的时候邮局还会给我们一个回执，用于查询信件状态。这个回执是我和邮局都可以使用的，根据编号，我可以查询信件状态，邮局也可以查询信件的传递情况。不过在工作流引擎中，这个编号变成了两个，一个给用户使用，代表引擎记录下的用户提供的事件编码（WOrkflowCase），一个是引擎内部使用的标志给事件的编码信息。这样用户随时都可以向引擎查询当前的事件处理状态了。
这个类比的重点，就是我们必须把引擎应该做的事情和应用系统开发人员应该做的事情独立分开，这样才使得引擎避免不必要的耦合，增加引擎的适应性。同时也抽象出来了引擎内部的三大数据集合：
（1）流程定义数据XPDL
（2）流程运行期数据RUNTIME
（3）流程派发采用的组织模型
之外，引擎还提供一些附加功能，比如调用外部应用程序接口（寄信时候是可以附加留言的），引擎将在适当时候调用这些外部应用程序。
当然从邮政系统类比中还可以类比出许多其他的工作流引擎界面，由于本次实现原因，我就不太多讲了