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

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

•     流程引擎嵌入部署
•     流程引擎独立部署

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

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



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



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



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

业务前置模式主要的优点：

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

业务前置模式主要的缺点：

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

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

业务前置模式主要的优点：

• 充分利用流程引擎提供的事务扩展机制，容易在在一些特定的事件上扩展。
• 业务系统和流程交互的时候，之间的数据交互可以通过流程相关数据完成，也可以通过事件扩展时候的调用参数进行流程数据传递。

业务前置模式主要的缺点：

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

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

    就当前系统而言，主体采取业务前置的方式，即大部分业务逻辑放在web端，并调用流程引擎的api，采取这种模式基于如下2个考虑：

• 和大部分程序的编程习惯相吻合，能采取spring等框架进行beans之间的关系管理以及声明式定义事务；
• 另外是web服务器个数大于流程引擎服务器个数，能均衡业务处理压力。小部分的业务采取后置方式，比如需要触发的一些同步处理等。

业务系统和BPS交互
下图是业务系统和BPS流程引擎交互的一个总体概览图



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



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




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

评论

10 楼 Alexyin_sc 2010-11-14  

timeson 写道

Alexyin_sc 写道

timeson 写道

bps 是流程引擎，只起到任务项的状态改变，并以此推进流程的执行
业务部分依然有业务系统去完成

有3个问题想问 ：
系统是用什么方式来描述任务项状态改变的？是用状态图或者状态机吗？
引擎控制任务项状态改变或者迁移的那部分逻辑是硬编码的吗？如果不是硬编码的，那么系统支持用户为相关的任务项定制自己所需要的状态图吗？因为实际中不同的任务项采取不同的驱动方式是完全可能的。比如，并行工程中经常提到的预提交。
如果系统允许客户定制任务的状态图，那么当同一过程中存在多个相异的任务项状态图时，系统的流程事务控制是如何实现的呢？

任务的转变是通过状态机来的
相对于人工活动，有3层对象需要联动：流程实例 －》 人工活动实例 －》 任务项
对于自动活动，有2层 ： 流程实例 －》 自动活动实例


附图，是3层对象的状态机变迁图

略

很高兴能有回应，嘿嘿~~~
不知道以下判断对不对：
（1）对于任务项、活动实例和流程实例，系统中分别都有且只有一种状态机来描述这些对象的状态迁移；
（2）由于（1）的原因，相关的流程控制逻辑已经用程序语言编译到应用中了，系统并不支持让用户来自定义任务项、活动实例或者流程实例的状态机。

如果是这样，那么对于一般OA型应用是能够满足的，但在其它领域（比如工程设计领域）应用时可能会遇到灵活性不足的问题。举个例子：一个设计活动a有两个前驱活动a1和a2，当a1或者a2其中一个完成时，a可以提前开始执行而不必等到a1和a2同时完成，而且在只有部分输入的情况下，a也可以提交处理结果（比如预设计方案）给后继活动a3审核。此时，a3可以对于接收的预处理结果提出反馈意见让a修改其预提交结果，但是要求a3此时不能提交任何处理结果给下一环节（比如后续是制造活动）。这样的提前执行可以持续到a1和a2都完成后，a才能最终提交其正式处理结果给a3审核，而a3也只能在此基础上提交正式的审核结果给后续活动。在此期间，由于a和a3都不必等到前驱活动都完成而提前进行了处理而使得整个过程的执行周期缩短，但a提前执行时的状态在楼主的状态机中是无法得到反映的。

实际中，允许多种描述对象行为的状态机存在于系统中是必要的，毕竟，状态机不外乎就是为系统用户提供了一种定性地描述过程、活动和任务项等被监控对象执行进度的途径。IT人员要做的不是规定具体的一种或者几种状态机，相反，而是应该在系统中提供让用户能根据需要定制状态机并在多种状态机共存时仍能驱动过程正确执行的机制。

个人意见，仅供参考。嘿嘿~~~

9 楼 timeson 2010-11-11  

Alexyin_sc 写道

timeson 写道

bps 是流程引擎，只起到任务项的状态改变，并以此推进流程的执行
业务部分依然有业务系统去完成

有3个问题想问 ：
系统是用什么方式来描述任务项状态改变的？是用状态图或者状态机吗？
引擎控制任务项状态改变或者迁移的那部分逻辑是硬编码的吗？如果不是硬编码的，那么系统支持用户为相关的任务项定制自己所需要的状态图吗？因为实际中不同的任务项采取不同的驱动方式是完全可能的。比如，并行工程中经常提到的预提交。
如果系统允许客户定制任务的状态图，那么当同一过程中存在多个相异的任务项状态图时，系统的流程事务控制是如何实现的呢？

任务的转变是通过状态机来的
相对于人工活动，有3层对象需要联动：流程实例 －》 人工活动实例 －》 任务项
对于自动活动，有2层 ： 流程实例 －》 自动活动实例


附图，是3层对象的状态机变迁图

8 楼 Alexyin_sc 2010-11-10  

timeson 写道

bps 是流程引擎，只起到任务项的状态改变，并以此推进流程的执行
业务部分依然有业务系统去完成

有3个问题想问 ：
系统是用什么方式来描述任务项状态改变的？是用状态图或者状态机吗？
引擎控制任务项状态改变或者迁移的那部分逻辑是硬编码的吗？如果不是硬编码的，那么系统支持用户为相关的任务项定制自己所需要的状态图吗？因为实际中不同的任务项采取不同的驱动方式是完全可能的。比如，并行工程中经常提到的预提交。
如果系统允许客户定制任务的状态图，那么当同一过程中存在多个相异的任务项状态图时，系统的流程事务控制是如何实现的呢？

7 楼 gengzg 2010-09-14  

最主要的一点：怎样把硬编码转换为转编码？至于怎样流转那是规则与业务的问题。

6 楼 timeson 2010-09-14  

bps 是流程引擎，只起到任务项的状态改变，并以此推进流程的执行
业务部分依然有业务系统去完成

5 楼 Aaronic 2010-09-14  

看了最后一个图，BPS流程服务器的作用是什么？
是为了流程控制吗？

4 楼 wangcunjiang 2010-09-14  

图文并茂，挺不错

3 楼 peterwei 2010-09-13  

我们原来的系统也用工作流，但是现在前台是用flex技术，和工作流整合，还是有不少麻烦，而且也不能很好的利用表单和工作流的整合。最后工作流方案被否掉。有用过flex整合工作流的，欢迎message我。

2 楼 labchy 2010-09-13  

一般的oa都是这样
lz画的够细致的

1 楼 webee 2010-09-13  

不错，此文对于业务系统加入工作流引擎的整合很有帮助！楼主可以接着搞点实例来讲解下，如同一个业务（假期申请）用两种方式实现的代码不同点。。。