F2BPM工作流体系架构
为了能更好的了解F2工作流引擎的架构体系，花了些时间画了整个架构的体系图。F2工作流引擎遵循参考WFCM规范，目标是实现轻量级的工作流引擎，支持多种数据库及快速应用到任何基于.net管理系统，实现工作流审批、业务流（BPM）的智能性、灵活性、简单实用性，具有强大的扩张性、集成性、独立性、开放性和稳定性，实现了可视化的流程设计或优化，流程的定制完全是通过鼠标拖、拉、拽的方式来完成，常见的串行、并行、分支、聚合都可以非常方便快捷地实现，依托于工作流强大的自定义，管理员还可以随时根据企业的情况调整流程，真正做到企业流程的不断优化。图形化、可视化设计流程定义通过Web端纯JS流程设计器无需编程的“拖、拉”式图形用户流程设计环境，支持通用流程条件，多节点，多流向。
关于轻量级：易集成、真可嵌入式架构决定其是否为真正轻量级，所谓轻量级就是易用易集成，没有臃肿的第三方框架，大量使用第三方的框架会使使用者的门槛很高，大量的应用第三方框架不仅集成时非常困难，而且要解决各种版本冲突问题，最终导致自称轻量级的工作流却无法达到真正嵌入式集成或者要做嵌入式集成时要花费大量的时间和人力成本来解决种种版本冲突问题，百度搜索到的几乎都自称轻量级，但是决多数都是为了自称轻量级而叫轻量级，但实际应用还是依然是重型工作流，整合嵌入非常困难，各种DLL或Jar包冲突。
从我的理解，首先为什么要做到轻量级呢，原因就是你是要为别的系统服务的，做为工作流引擎是要面对各种业务系统，被业务系统集成整合进去的，由于这样的应用就决定了工作流引擎自身必须是一个非常纯净的代码环境。所以最极致轻量级的就是C#或Java的原生代码，整个引擎最多使用一种行业最常用的架构，比如Java的SpringMVC，.net的asp.net MVC，除此以外不使用任何第三个架构，这样你的引擎代码将十分纯洁，而且可以只编译成一个DLL或一个Jar包。这样不仅整合时没有任何冲突，而且也不会导致因为过多的引用使原来的业务系统环境就得更加杂锁复杂进而会导致将来的维护成本直线上升。
F2BPM工作流引擎的架构设计就是基于极致轻量级的设计，真正做到轻量级这个称呼。实务做好事情，比漂亮的宣传带来实实在在的成就。
上图：F2BPM工作流引擎微内核技术架构
上图：F2BPM流程引擎五大接口
l Web建模工具：也叫“流程设计器” 即基于浏览器纯JS流程设计器无需编程的“拖、拉”式图形用户流程设计器工具。
l 流程引擎：调度，推进工作流过程和活动。
l 任务管理器：维护活动，为外部系统调用参与者任务列表提供数据
l 组织模型:流程任务最终是应用到人，达到人机交互的效果，为流程运转提供参与者。
l 支持多数据库的ORM：工作流引擎需要应用到各个系统中去，需要有自己的ORM数据库访问层，同时支持多种数据库类型。
l 流程数据：即模型库数据，流程定义相关数据。
l 相关数据：即运动库数据，相关待办事项任务，活动实例等运动数据，流程上下文数据等。
l 流程实例：流程实例工单数据。
l 任务数据：待办工作项数据。
l 形参数据：外部Tools,Apps中规定的参数类型数据。
l 控制数据：迁移的前驱ID，后续活动ID，工作流对象状态等数据。
l 业务表单数据：工作任务活动界面的数据，即表单展现
l 外部组织模型数据：外部系统的用户组织角色数据
l 外部应用数据：外部数据执行所需要的数据
工作流：Workflow
工作流定义：WorkflowDefinition
活动Activity：活动即是步骤的意思。
参与者Actor：参与者是直接或间接参与执行工作的人、机器或组织单元。
任务Task：用户待办任务实例，是工作的最小单位，即工作项。
迁移：流转转向,即带剑头的线所表示。即Petri网中的变迁
SplitXOR：异或散发，即后续步骤只能选择一条分支。
SplitOR：或散发，即后续步骤可选择大于等于１的分支
JoinXOR：异或汇聚，即前继步骤只要有一条分支聚合就满足
JoinOR：聚合，根据规则需要聚合1条或多条分支
WorkFlowEnactmntService（工作流执行服务）这个组件就是我们平常说的工作流执行服务或工作流引擎包含了多个工作流机，主要功能是读取工作流定义、根据工作流定义驱动工作流的流转，分为三个阶段：
1、模型建立阶段：利用工作流建模工具设计，并把XPDL文件解析导入到模型库。
2、模型实例化阶段：模型库数据库导入到运动库，并做好状态初始化，并分配每个活动执行所需要的资源参数等。
3、模型执行阶段：根据运行库的状态，条件判定，推动流程状态的迁移，并完成相关任务，同时提供注程实例运转过程的监控跟跟踪。