Fire workflow Engine的结构如下图。
fireflow-总体结构图:
2009-6-25 21:56
如图所示，Fire Workflow把引擎的功能分解成很多的Service，这些Service都“挂接”在Engine的“总线”org.fireflow.engine.RuntimeContext上。下面逐一解释这些Service。
- IWorkflowSession
这是业务代码调用Engine API的入口，通过IWorkflowSession你可以创建IProcessInstance，获得相应的ITaskInstance，IWorkItem等等对象。
你可以将IWorkflowSession类比Jdbc中的connection。通过Connection可以获得Statement，ResultSet等等对象。
那么在系统中如何取得IWorkflowSession对象呢？Fire workflow 缺省情况下是通过Spring将各种Service组装（即注入）到RuntimeContext，所以首先要将FireflowContext.xml引入到你的系统中，这是一个spring 配置文件；然后通过类似如下代码获得IWorkflowSession。
RuntimeContext rtCtx = mySpringBeanFactory.getBean("runtimeContext");
IWorkflowSession workflowSession = rtCtx.getWorkflowSession();
- KernelManager
即内核管理器。Fire Workflow 的内核实际上是“工作流逻辑网”的执行机。工作流逻辑网的相关概念见《9_fireflow技术原理》，它是Petri Net改造后的新的网结构。
内核管理器的职责是根据流程定义文件创建和维护工作流逻辑网实例INetInstance。INetInstance在Petri Net定义的执行规则下一步一步驱动流程实例执行。
- IPersistenceService
存储服务。Fire Workflow缺省情况下使用hibernate进行数据库存取。如果你的系统不是使用hibernate，则重新实现该类，然后通过修改FireflowContext.xml配置，将你的存储服务实现类注入到RuntimeContext中。
- IDefinitionService
流程定义服务。该服务负责根据流程ID和版本号获得流程定义对象WorkflowDefinition。从该对象可以获得WorkflowProcess，即真正的流程定义。
Fire Workflow缺省提供两种实现，一种实现是org.fireflow.engine.definition.DefinitionService4FileSystem。该实现类从文件系统中获得流程定义对象，在开发阶段使用该类比较方便。该类从class path中读取流程定义文件，因此你在项目中设计流程时，推荐将流程定义文件置于/src或者其子目录中。DefinitionService4FileSystem忽略流程的版本，直接读取当前的流程定义文件。
另一个实现是org.fireflow.engine.definition.DefinitionService4DBMS。该实现类从数据库表T_FF_DF_WORKFLOWDEF中获得流程定义文件。因为表T_FF_DF_WORKFLOWDEF中保存了流程的版本号，因此该类在产品真正运行时使用。
在FireflowContext.xml修改相关的配置即可实现这两个类的切换。
- ICalendarService
日历服务。日历服务负责获取系统时间和计算TaskInstance的ExpiredDate。缺省实现中，系统时间是返回new Date()，也只考虑了周六、周日作为节假日的情况。你可以扩展该类获取数据库时间作为系统时间，增加节假日配置。
- IConditionResolver
转移条件解析器，用于计算转移条件中的EL表达式的值。
- ITaskInstanceManager
任务管理器，负责创建任务实例，缺省实现是BasicTaskInstanceManager。
- BeanFactory
在1.0中，增加了一个新的服务：bean factory。该服务负责创建各种javabean，例如：进行工单分派的时候，需要获得AssignmentHandler的实例；执行ToolTask的时候，需要获得ApplicationHandler的实例，等等。这些实例都是由bean factory创建的。在1.0中，这个bean factory的缺省实现是spring ioc容器，即，将创建bean的工作委派给了spring 。