基于工作流引擎的业务开发模式

大型电信级应用往往需要支撑大用户量的高并发处理请求，而且随着分布式架构概念的普及，越来越多的应用要求松耦合、灵活的部署架构。流程应用作为一种特定应用类型，涉及到了与业务功能部署模式，是部署在同一个Web应用内部，还是部署在两个逻辑分离的Web应用中。
总的来说有2种部署模式：
[list]
[*] 流程引擎嵌入部署
[*] 流程引擎独立部署
[/list]

嵌入式部署模式一般适用于独立的业务系统，IT系统建设中不需要有大量的流程应用，仅仅在局部采用流程的场景，而独立式部署模式适用于在IT系统规划中，流程作为一个独立的概念提出，并且作为基础平台引入的场景中，例如统一流程平台建设。

下面有个采取了流程引擎独立部署的应用，具体部署物理实例图如下：

[img]http://dl.iteye.com/upload/attachment/307474/d07e589e-1840-3334-8fe6-e2a5402a9ce7.jpg[/img]

业务系统和流程引擎分别部署为独立的群组，采用集群模式部署为独立的集群，业务系统和流程引擎可以分别横向扩充，满足未来集团业务增长需求
业务系统通过流程引擎提供的WAPI Client调用流程引擎提供的流程服务，实现业务和流程之间的交互，逻辑部署图如下所示

[img]http://dl.iteye.com/upload/attachment/307476/341aa7cf-d83e-3f70-af85-155dd1de17d3.jpg[/img]

业务系统和流程引擎分离部署后，业务模块所处的位置，有2种业务部署模式，不同的模式在程序员编码的习惯，数据一致性的处理上，负载均衡的考虑有所差异。

[img]http://dl.iteye.com/upload/attachment/307478/00a63587-823e-3250-93a3-0c28726af1bf.jpg[/img]

[size=x-large][color=red][b]业务前置模式[/b][/color][/size]
业务系统负责业务操作，业务端代码实现部署在业务端，流程负责流程状态流转，不参与业务数据操作，
业务系统响应用户请求，调用流程引擎，执行启动业务流程操作，同时流程引擎通过触发事件，调用Portal应用提供的服务，把生产的待办任务发送到Portal中，完成之后，控制权返回给业务系统，业务系统完成接下来的业务数据持久化操作并返回用户结果页面。

业务前置模式主要的优点：
[list]
[*]基本不改变用户的编程习惯，用户在架构设计上不需要做太多调整，容易适应和理解
[*]业务系统负责事务发起和提交，对于业务端的事务控制比较容易
[*]业务和流程的远程调用交互会比较少，在事务一致性上减少一些风险
[/list]

业务前置模式主要的缺点：
[list]
[*]流程引擎提供的事务扩展机制会比较少的使用，在一些特定的事件上不容易扩展
[*]业务系统和流程交互的时候，之间的数据交互只能通过流程相关数据完成，一些流程的实例数据可能需要通过接口
[/list]


[size=x-large][color=red][b]业务后置模式[/b][/color][/size]
主要由流程引擎控制整个完整的业务操作序列，业务端代码实现部署在业务端，但是由流程引擎触发业务端完成业务数据持久化操作，由流程引擎最终完成事务提交，业务系统响应用户请求，调用流程引擎，执行启动业务流程操作，同时流程引擎通过触发事件，回调业务系统提供的业务数据持久化服务，完成业务系统数据更新操作，并且调用Portal应用提供的服务，把生产的待办任务发送到Portal中，完成之后，提交事务，完成整个业务操作，然后返回业务系统，由业务系统返回用户结果页面

业务前置模式主要的优点：
[list]
[*]充分利用流程引擎提供的事务扩展机制，容易在在一些特定的事件上扩展。
[*]业务系统和流程交互的时候，之间的数据交互可以通过流程相关数据完成，也可以通过事件扩展时候的调用参数进行流程数据传递。
[/list]

业务前置模式主要的缺点：
[list]
[*]业务系统在架构设计上，复杂度会更高一些，开发人员在开发模式上需要更多掌握
[*]业务端需要做服务封装，提供流程引擎调用，在事务一致性考虑上，需要考虑实现幂等操作
[/list]

两种融合模式，在事务一致性上都需要有足够的考量，原则上尽量减少事务分段，比如可以通过合并业务操作，减少远程调用的次数，对于服务调用尽量在一次服务交互中完成，这在设计上需要有所考虑

就当前系统而言，主体采取业务前置的方式，即大部分业务逻辑放在web端，并调用流程引擎的api，采取这种模式基于如下2个考虑：
[list]
[*]和大部分程序的编程习惯相吻合，能采取spring等框架进行beans之间的关系管理以及声明式定义事务；
[*]另外是web服务器个数大于流程引擎服务器个数，能均衡业务处理压力。小部分的业务采取后置方式，比如需要触发的一些同步处理等。
[/list]


[size=x-large][color=red][b]业务系统和BPS交互[/b][/color][/size]
下图是业务系统和BPS流程引擎交互的一个总体概览图

[img]http://dl.iteye.com/upload/attachment/307480/5b8819e6-68f8-3b4c-89fe-48421207b32c.jpg[/img]

业务系统通过流程引擎提供的客户端，访问流程引擎提供的服务，完成流程的触发调用操作，业务系统和流程直接的数据交互通过流程引擎的相关数据区完成，流程引擎在驱动流程流转过程中，通过触发事件机制，完成和业务系统之间的交互（比如发送Portal待办）。
业务系统开发完成的活动环节表单和流程的交互，可以通过在流程设计时完成，对于人工参与的活动环节，流程提供了设置属性，可以指定具体的业务表单；用户通过任务待办列表触发相应的活动表单，执行相应的业务数据提交操作
业务系统和流程引擎之间需要建立数据关联，一般建议在业务系统的业务表中，添加流程数据（可以是流程ID，活动环节ID等），保证业务数据和流程数据的交互


[size=x-large][color=red][b]事务一致性[/b][/color][/size]
业务系统和流程引擎直接采用分布式部署模式，为了保证业务的一致性，在融合过程中，有两种开发模式可供采用：
业务事务控制
流程事务控制
下图是一张典型的业务和流程的调用关系图，从图中可以看到，在整个图中，业务和流程引擎的交互有两个地方涉及到事务完整性问题：


[img]http://dl.iteye.com/upload/attachment/307482/781246b7-a9b7-3f03-b667-58330e85db06.jpg[/img]

在上面两个环节，流程引擎的事务处理策略是一致的