基于工作流引擎的业务开发模式
大型电信级应用往往需要支撑大用户量的高并发处理请求，而且随着分布式架构概念的普及，越来越多的应用要求松耦合、灵活的部署架构。流程应用作为一种特定应用类型，涉及到了与业务功能部署模式，是部署在同一个Web应用内部，还是部署在两个逻辑分离的Web应用中。
总的来说有2种部署模式：
嵌入式部署模式一般适用于独立的业务系统，IT系统建设中不需要有大量的流程应用，仅仅在局部采用流程的场景，而独立式部署模式适用于在IT系统规划中，流程作为一个独立的概念提出，并且作为基础平台引入的场景中，例如统一流程平台建设。
下面有个采取了流程引擎独立部署的应用，具体部署物理实例图如下：
业务系统和流程引擎分别部署为独立的群组，采用集群模式部署为独立的集群，业务系统和流程引擎可以分别横向扩充，满足未来集团业务增长需求
业务系统通过流程引擎提供的WAPI Client调用流程引擎提供的流程服务，实现业务和流程之间的交互，逻辑部署图如下所示
业务系统和流程引擎分离部署后，业务模块所处的位置，有2种业务部署模式，不同的模式在程序员编码的习惯，数据一致性的处理上，负载均衡的考虑有所差异。
业务前置模式
业务系统负责业务操作，业务端代码实现部署在业务端，流程负责流程状态流转，不参与业务数据操作，
业务系统响应用户请求，调用流程引擎，执行启动业务流程操作，同时流程引擎通过触发事件，调用Portal应用提供的服务，把生产的待办任务发送到Portal中，完成之后，控制权返回给业务系统，业务系统完成接下来的业务数据持久化操作并返回用户结果页面。
业务前置模式主要的优点：
业务前置模式主要的缺点：
业务后置模式
主要由流程引擎控制整个完整的业务操作序列，业务端代码实现部署在业务端，但是由流程引擎触发业务端完成业务数据持久化操作，由流程引擎最终完成事务提交，业务系统响应用户请求，调用流程引擎，执行启动业务流程操作，同时流程引擎通过触发事件，回调业务系统提供的业务数据持久化服务，完成业务系统数据更新操作，并且调用Portal应用提供的服务，把生产的待办任务发送到Portal中，完成之后，提交事务，完成整个业务操作，然后返回业务系统，由业务系统返回用户结果页面
业务前置模式主要的优点：
业务前置模式主要的缺点：
两种融合模式，在事务一致性上都需要有足够的考量，原则上尽量减少事务分段，比如可以通过合并业务操作，减少远程调用的次数，对于服务调用尽量在一次服务交互中完成，这在设计上需要有所考虑
就当前系统而言，主体采取业务前置的方式，即大部分业务逻辑放在web端，并调用流程引擎的api，采取这种模式基于如下2个考虑：
业务系统和BPS交互
下图是业务系统和BPS流程引擎交互的一个总体概览图
业务系统通过流程引擎提供的客户端，访问流程引擎提供的服务，完成流程的触发调用操作，业务系统和流程直接的数据交互通过流程引擎的相关数据区完成，流程引擎在驱动流程流转过程中，通过触发事件机制，完成和业务系统之间的交互（比如发送Portal待办）。
业务系统开发完成的活动环节表单和流程的交互，可以通过在流程设计时完成，对于人工参与的活动环节，流程提供了设置属性，可以指定具体的业务表单；用户通过任务待办列表触发相应的活动表单，执行相应的业务数据提交操作
业务系统和流程引擎之间需要建立数据关联，一般建议在业务系统的业务表中，添加流程数据（可以是流程ID，活动环节ID等），保证业务数据和流程数据的交互
事务一致性
业务系统和流程引擎直接采用分布式部署模式，为了保证业务的一致性，在融合过程中，有两种开发模式可供采用：
业务事务控制
流程事务控制
下图是一张典型的业务和流程的调用关系图，从图中可以看到，在整个图中，业务和流程引擎的交互有两个地方涉及到事务完整性问题：
在上面两个环节，流程引擎的事务处理策略是一致的
总的来说有2种部署模式：
- 流程引擎嵌入部署
- 流程引擎独立部署
嵌入式部署模式一般适用于独立的业务系统，IT系统建设中不需要有大量的流程应用，仅仅在局部采用流程的场景，而独立式部署模式适用于在IT系统规划中，流程作为一个独立的概念提出，并且作为基础平台引入的场景中，例如统一流程平台建设。
下面有个采取了流程引擎独立部署的应用，具体部署物理实例图如下：
业务系统和流程引擎分别部署为独立的群组，采用集群模式部署为独立的集群，业务系统和流程引擎可以分别横向扩充，满足未来集团业务增长需求
业务系统通过流程引擎提供的WAPI Client调用流程引擎提供的流程服务，实现业务和流程之间的交互，逻辑部署图如下所示
业务系统和流程引擎分离部署后，业务模块所处的位置，有2种业务部署模式，不同的模式在程序员编码的习惯，数据一致性的处理上，负载均衡的考虑有所差异。
业务前置模式
业务系统负责业务操作，业务端代码实现部署在业务端，流程负责流程状态流转，不参与业务数据操作，
业务系统响应用户请求，调用流程引擎，执行启动业务流程操作，同时流程引擎通过触发事件，调用Portal应用提供的服务，把生产的待办任务发送到Portal中，完成之后，控制权返回给业务系统，业务系统完成接下来的业务数据持久化操作并返回用户结果页面。
业务前置模式主要的优点：
- 基本不改变用户的编程习惯，用户在架构设计上不需要做太多调整，容易适应和理解
- 业务系统负责事务发起和提交，对于业务端的事务控制比较容易
- 业务和流程的远程调用交互会比较少，在事务一致性上减少一些风险
业务前置模式主要的缺点：
- 流程引擎提供的事务扩展机制会比较少的使用，在一些特定的事件上不容易扩展
- 业务系统和流程交互的时候，之间的数据交互只能通过流程相关数据完成，一些流程的实例数据可能需要通过接口
业务后置模式
主要由流程引擎控制整个完整的业务操作序列，业务端代码实现部署在业务端，但是由流程引擎触发业务端完成业务数据持久化操作，由流程引擎最终完成事务提交，业务系统响应用户请求，调用流程引擎，执行启动业务流程操作，同时流程引擎通过触发事件，回调业务系统提供的业务数据持久化服务，完成业务系统数据更新操作，并且调用Portal应用提供的服务，把生产的待办任务发送到Portal中，完成之后，提交事务，完成整个业务操作，然后返回业务系统，由业务系统返回用户结果页面
业务前置模式主要的优点：
- 充分利用流程引擎提供的事务扩展机制，容易在在一些特定的事件上扩展。
- 业务系统和流程交互的时候，之间的数据交互可以通过流程相关数据完成，也可以通过事件扩展时候的调用参数进行流程数据传递。
业务前置模式主要的缺点：
- 业务系统在架构设计上，复杂度会更高一些，开发人员在开发模式上需要更多掌握
- 业务端需要做服务封装，提供流程引擎调用，在事务一致性考虑上，需要考虑实现幂等操作
两种融合模式，在事务一致性上都需要有足够的考量，原则上尽量减少事务分段，比如可以通过合并业务操作，减少远程调用的次数，对于服务调用尽量在一次服务交互中完成，这在设计上需要有所考虑
就当前系统而言，主体采取业务前置的方式，即大部分业务逻辑放在web端，并调用流程引擎的api，采取这种模式基于如下2个考虑：
- 和大部分程序的编程习惯相吻合，能采取spring等框架进行beans之间的关系管理以及声明式定义事务；
- 另外是web服务器个数大于流程引擎服务器个数，能均衡业务处理压力。小部分的业务采取后置方式，比如需要触发的一些同步处理等。
业务系统和BPS交互
下图是业务系统和BPS流程引擎交互的一个总体概览图
业务系统通过流程引擎提供的客户端，访问流程引擎提供的服务，完成流程的触发调用操作，业务系统和流程直接的数据交互通过流程引擎的相关数据区完成，流程引擎在驱动流程流转过程中，通过触发事件机制，完成和业务系统之间的交互（比如发送Portal待办）。
业务系统开发完成的活动环节表单和流程的交互，可以通过在流程设计时完成，对于人工参与的活动环节，流程提供了设置属性，可以指定具体的业务表单；用户通过任务待办列表触发相应的活动表单，执行相应的业务数据提交操作
业务系统和流程引擎之间需要建立数据关联，一般建议在业务系统的业务表中，添加流程数据（可以是流程ID，活动环节ID等），保证业务数据和流程数据的交互
事务一致性
业务系统和流程引擎直接采用分布式部署模式，为了保证业务的一致性，在融合过程中，有两种开发模式可供采用：
业务事务控制
流程事务控制
下图是一张典型的业务和流程的调用关系图，从图中可以看到，在整个图中，业务和流程引擎的交互有两个地方涉及到事务完整性问题：
在上面两个环节，流程引擎的事务处理策略是一致的