思考:开源工作流在应用程序中的位置--80%

原创 2006年11月03日 13:35:00

我工作以来所经历的项目是依次如下

一、基本没有工作流概念,建一个流程表,一张大横表,每一个环节是一个字段,用一些标识代表状态,如0未完成、1已完成、x异常、c撤单...,程序员自己编码维护,而且绝大多数的情况都是业务逻辑、流程控制、数据库读写混在一起 。这主要适合流程单一、改动不大、用户数较少的系统,但是也带来了很多开发、测试、维护的问题。而且随着程序的逐渐庞大,这些问题也会愈演愈烈,最终的解决就是推倒重来,上2版。

二、后来的项目有一些改进,虽然同样没有采用工作流,但是对整个应用程序进行了合理的分层,如下:

view(视图层。仅仅与用户进行交互:接受用户输入请求、信息展现)
control(控制层。调用业务层方法、流程控制)
model1(模型层-业务逻辑层。所有的商务逻辑在此处实现。)
model2(模型层-持久化层。仅仅负责数据的持久化,就是将暂态的数据保存成定态的)

这就是经典的MVC模式,下层独立于上层,这样的好处是类似于模块化各个功能,便于拆卸。比如,模型层分为2层,这样我们可以在保持业务逻辑层代码不需要改变的情况下轻松的实现下层的切换,比如原来我们是持久化到mysql进行前期开发的,现在上线了要切换到oracle。甚至是我们不采用数据库了,采用xml来存储数据。

回到我们工作流的主题,MVC的工作流处理一般在"C",如用struts的action来实现,调用"M"将流程信息保存到自己建的数据表中,对于流程复杂多变的项目,这个自行设计的工作流是很有难度的。稍有不慎或者设计师偷点懒就会变成文章开头所说的混乱局面。为了避免这种情况有一种实用方法是,将C和M分得再开一点,在它们中间引入了业务代理接口层,C不直接调用M中的类,而是调用这个代理接口,代理接口定义了所有的业务处理方法,仅仅是定义,实现全部在M层实现。

同时还有另一个好处,我们可以在保持业务逻辑层不变的情况下随意的开发上面的client端,既可以是B/S也可以是C/S;或者在保证前端客户程序不变的情况下随意的更改后台实现,ejb/ormapping/jdbc+javabean。

上面的系统仅仅是将应用的各层进行了合理的划分,变相缓解了工作流编码的压力,但是我们还是要自行维护工作流数据与业务数据的关系,还是将工作流和业务关联的非常紧,甚至将工作流数据看作是业务数据的一部分。如何才能有效地将工作流数据和业务数据进行解耦呢?这才是我们问题的核心。

 三、前段时间看了开源工作流jbpm,它为我们做了很多事:

  • 设计好的工作流定义规范——我们只需要定义一个xml,里面包含相应的元素(如:分支节点、汇聚节点、判断节点、任务节点)就可以表示一个流程,甚至有一个ide工具,我们可以通过拖拉完成流程框架的定义。
  • 设计好的工作流持久化方案——我们只需要运行一个命令就可以在指定的数据库(包括oracle/mysql/mssqlserver/sybase等10余种数据库)中生成工作流表(大概25张表,你自己设计的工作流肯定没有那么全面)。编程的时候,我们不需要知道这些表,因为jbpm已将这些表映射成了对象,我们只需要操作java对象,所以这些表我们不需要修改。
  • 还有一些好的功能,比如:任务定时器,到指定时间任务自动执行;在一个xml中指明日历中那些是工作日期、哪些是工作时间;结合JMS实现异步工作流;结合Jboss rules实现规则引擎...

虽然他解决了很大一部分工作,但是我们还是要面对了很多挑战:

  •  如何应用到我们现有的应用层次中,保证各层之间低耦合。
  • 如何和我们现在的组织模型结合,完成任务的分派便捷性。
  • ...还有的要去实践中挖掘了。

 这里有我的一些想法,还不是很成熟:

jbpm是默认采用hibernate做持久化的,可以将jbpm的流程

工作流在企业信息化中的思考

从业务层面来讲:一个大的公司的业务流程角度看,公司在历年的积累中形成了相对稳定的业务流程,这些业务流程都是在手工状态下人工完成的,它们通常都有成文的规定或者有不成文的规则。从整个公司的角度和层次上来讲...
  • csdngeternal
  • csdngeternal
  • 2006-07-25 09:04:00
  • 883

思考:开源工作流在应用程序中的位置--80%

我工作以来所经历的项目是依次如下一、基本没有工作流概念,建一个流程表,一张大横表,每一个环节是一个字段,用一些标识代表状态,如0未完成、1已完成、x异常、c撤单...,程序员自己编码维护,而且绝大多数...
  • jeffen2006
  • jeffen2006
  • 2006-11-03 13:35:00
  • 1050

开源工作流比较

1.   大多数的工作流引擎并不能实现全部的接口,而且每个引擎的优点都分布在不同的接口上。如OBE的接口2实现的比较好,但没有实现接口4;Shark的接口5的实现是其它工作流引擎望尘莫及的。  Pro...
  • linjian19811027
  • linjian19811027
  • 2007-10-16 09:46:00
  • 1319

开源工作流的比较和描述

  • 2009年03月03日 10:48
  • 8KB
  • 下载

工作流软件如何在企业内部实行

很多公司也许习惯了用OFFICE办公软件,或者更准确的说是员工习惯了OFFICE办公软件,我们都知道一旦人有了习惯或者最初印象要改过来并不是一件容易的事情。这个上至高层下至普通职员都有这种情况发生。而...
  • teemlink
  • teemlink
  • 2010-03-25 16:51:00
  • 201

对工作流系统的思考

说起工作流,本人一般遇到两种场景:一种是某些人对工作流的向往之情非常强烈,他们的说法一般是“这个问题就应该用工作流来解决”,而他们却未必对工作流有详细的了解,只是对这种技术有道听途说式的理解;另一种是...
  • tsun7263
  • tsun7263
  • 2009-09-17 21:35:00
  • 789

VS下程序打包

第一步:打开开发环境VS2008,新建项目,选择其他项目类型,再选择"安装项目",输入名称及选择安装路径;   第二步:进入文件系统选项卡,选择应用程序文件夹,在中间的空白区域右键选择"添加文...
  • u012162153
  • u012162153
  • 2014-10-30 09:29:55
  • 1068

设置MFC对话框应用程序的位置

1,新建MFC基于对话框的应用程序StereoTool; 2,添加对话框消息WM_SHOWWINDOW的处理函数:void CStereoToolDlg::OnShowWindow (BOOL bS...
  • mylaf
  • mylaf
  • 2016-12-30 09:56:03
  • 328

关于工作流的思考

      司需要做saas的销售系统,有幸参与了公司的前期调研,在对需求进行整理的时候遇到了一些麻烦。因为领导提出了工作流的概念,以方便在销售业务过程中产生的问题实现无纸化的解决。      对于工...
  • xuelih2
  • xuelih2
  • 2009-12-09 13:55:00
  • 239

工作流技术发展趋势

先看几篇前辈牛人的文章:工作流之大局势 作者把wfmc派叫做保皇党,web service派叫做革命党~轻松幽默又清晰透彻。看好bpel是未来发展的方向。誰來一統BPM江湖 台湾的牛人,主推soa架构...
  • yethyeth
  • yethyeth
  • 2007-03-13 21:48:00
  • 1623
收藏助手
不良信息举报
您举报文章:思考:开源工作流在应用程序中的位置--80%
举报原因:
原因补充:

(最多只允许输入30个字)