如果把Fireflow engin当作一个黑箱子，那么Fireflow engine需要关注如下几个方面的接口。

1、客户代码调用engine的接口（启动流程实例，签收任务，完成任务等等）

2、engine与用户管理系统的接口

3、engine与业务表单的接口

4、engine调用外部系统（engine调用外部代码）

5、engine与数据存储子系统的接口（engine与应用系统存储层接口），以及事务的一致性。

6、工作流数据与业务数据之间的接口



如果进一步打开这个“黑箱子”，Fireflow Engine还需要考虑如下问题

1、内核的实现，以及内核与Engine的其它逻辑的交互关系

2、转移条件的计算

3、等等。。。


下面将逐一讨论这些问题。本篇首先讨论第一个问题:客户代码调用fireflow engine的接口。


很显然，对于客户端而言，fireflow的操作越简单越好，涉及的对象约简单越好。在fireflow中，对业务流程的一般操作可以归结为：

1) 创建新流程实例

2) 相关岗位的操作员签收工单

3) 相关工作的操作员完成工单

客户端在调用中涉及的fireflow对象也很简单

1) 流程实例 ProcessInstance

2) 工单Workitem
3) 与工单相关的另一个概念就是任务实例TaskInstance，一个TaskInstance可以产生0到n个工单，例如：正常情况下，一个审批任务实例只产生一个Workitem；相关人员接受该Workitem后，可以“委派”给其他人完成该任务，从而产生一个新的Workitem，但是任务实例还是同一个。在会签的情况下，一个TaskInstance也可以产生多个Workitem。如果一个任务是Application类型的（调用其它程序完成），则不会产生WorkItem。

那么用什么样的一种模式实现上述功能呢，显然，facade模式是一个必然的选择。下图是fireflow对外调用接口的类图。

我们可以通过类比来理解这幅图。FireflowSession相当于JDBC中的connection，是Fireflow的入口。通过jdbc操作数据库首先需要获得connection；同样，操作fireflow，首先要创建一个FireflowSession实例。由于fireflow Engine是嵌入式的，那么创建fireflowSession比创建connection简单多了，就是一个new的过程。通过 FireflowSession可以获得其它的工作流对象，例如ProcessInstance,TaskInstance,WorkItem；就像通过 Connection获得Statement,resultSet一样。

那么FireflowSession到底起什么作用呢？仅仅是其它fireflow对象的factory吗？不是的。fireflowSession用到了Template模式，将一些通用的fireflow操作固化在里面，客户程序可以通过FireflowSessionCallBack扩展已有的功能。就像Spring中的大量的HibernateTemplate一样。