posts - 193,  comments - 520,  trackbacks - 0
py工作流是国内比较好的工作流之一。大概看过它的一些文档,分析一下。
1、路由模型
 py支持的工作流模式其实并不多,只是支持1到7七种模式而已,其中比较重要的是模式6和模式7,即M选N分支和M选N聚合,看过它的实现,利用转移线条件来触发转移线,从而触发后续的节点。这样做比较简单,但是同时也存在很多问题,例如在路由非常复杂的情况下,例如多个分支节点的串联,以及并发路由存在多个节点时,这种做法实现起来就非常困难。另外,并发路由的工作流变量会存在相互冲突的情况,也包括业务数据的冲突。可以说py的路由模型还是很简单的,支持简单的业务可能没有问题,对于复杂的业务可能需要很多其他额外的办法。当然,很多国内的工作流甚至连模式6和模式7都支持不了,同时工作流的应用目前还具有很浓的“审批”的影子(貌似有人很讨厌审批这个说法),所以目前的路由模型应该满足需求了。
2、任意路由和回退
 没有看到任意路由和回退的复杂示例。关于任意路由,产品说明中说到可以在整个流程范围内任意自由路由,我觉得这个说法本来就是有问题的,并发路由的情况下,并发支线往主线上跳转,这种情况会有很多问题存在,其他并行的支线如何处理?或者说根本就没有考虑到这些复杂的情况?回退也是一样的道理,至于业务补偿的提出还是不错的,不过推给了用户自己设置回退动作。
3、关于WFMC和BPEL规范
 看看流程定义文件就知道了,它不支持任何规范。敢说国内工作流的流程定义就没有遵循规范的。
4、参与者的指定
 提供了组织机构、角色、个人这三种常见的参与者设置模式,还提供了流程启动者、活动执行者、从相关数据或从规则逻辑中获取参与者的模式。
5、工作的代理和代办
6、时间服务
 提供了四种时限。活动提醒、活动执行、流程提醒、流程执行。
7、业务开发
 感觉这是非常出彩的地方,在一个简单的示例中几乎不需要任何编码,比如一个简单的请假管理。看看它的流程定义文件,它几乎将整个业务表单都嵌入到流程定义里去了。这样做是否合适?我个人倾向于引擎与业务完全分开,通过反射或者某种映射将两者关联到一起。如果是用户自己开发已有的复杂业务,如何将工作流嵌入?至于studio也是非常出色的,具有开发调试的功能。调用接口非常的清晰。
总结一下:py工作流还是一个不错的工作流引擎,抛开它的宣传,感觉引擎的实现还是有些简单,或者说只是满足了目前的一些常见需求,至于所说的SOA和服务编排,我觉得目前还不现实。它的优势在于与其平台的完全融合,能够利用很多既有设施,可是这又何尝不是把双刃剑?另外,强大的市场宣传和良好的服务团队也是选择工作流时的重要考虑。

http://www.blogjava.net/ronghao 荣浩原创,转载请注明出处:)
posted on 2008-05-06 17:21 ronghao 阅读(2029) 评论(3)  编辑  收藏 所属分类: SOA、BPM

FeedBack:
# re: py工作流分析
2008-05-08 11:44 | 蓝色的天空
体现了中国的特色,解决实际问题就行。
他的成功之处在于提供了一整套解决方案,现在很多工作流产品是不会提供开发平台。这就是他的优秀之处。  回复  更多评论
  
# re: py工作流分析
2008-05-08 13:14 | j
py工作流是什么工作流。地址是多少  回复  更多评论
  
# re: py工作流分析
2008-05-10 11:14 | ronghao
@蓝色的天空
是的,我的看法和你相同。  回复  更多评论
  

只有注册用户登录后才能发表评论。


网站导航:
 
<2008年5月>
27282930123
45678910
11121314151617
18192021222324
25262728293031
1234567

关注工作流和企业业务流程改进。现就职于ThoughtWorks。新浪微博:http://weibo.com/ronghao100

常用链接

留言簿(38)

随笔分类

随笔档案

文章分类

文章档案

常去的网站

搜索

  •  

最新评论

阅读排行榜

评论排行榜