JBpm的Tom Baeyens写的《工作流的现状》(中文)

04-09-07 dingh2000
TSS上发表的一篇关于工作流现状的文章,对工作流和BMP的相关概念、规范、开放源码项目和商业工具作了比较全面的介绍...

the state of workflow

喜欢的话,顶一下。可化了我不少时间,:-)。。。。

    

1
banq
2004-09-08 10:50
完全依赖数据库的时代已经过去,我们使用EJB实体Bean标准,将数据表抽象到内存中,割断了J2EE系统和具体数据库的耦合和配置,占系统主要负荷的数据表的操作计算也基本全部迁移到J2EE中间件服务器上运行,形成了一个可拓展的体系。

下面,我们需要对J2EE中间件业务逻辑进一步细分,提炼出通用的解决方案,工作流是下一步方向和工作重点。我们将迎来流程的可定制性和灵活的可拓展性。

正如文中开头将工作流和数据库比较一样:如果数据库系统( database systems)像受人尊敬的智者讲述的条理清晰的故事,那么工作流(workflow)就像一群乳臭未干的小子在大谈各自的“哲理”。

TSS相关连接和讨论:

http://www.theserverside.com/news/thread.tss?thread_id=26073

banq
2004-09-08 12:05
本篇文章谈到状态和动作,提倡不要提术语“活动(activity)",这会混淆概念,原因从状态模式中也可以得出,工作流中很大部分是状态机或状态模式。

状态模式见本站:http://www.jdon.com/designpatterns/designpattern_State.htm

在实践中如何将状态从活动概念中区分出来,变成动作驱动,可见本站另外一篇文章:

http://www.jdon.com/jive/article.jsp?forum=91&thread=10981

banq
2004-09-09 12:29
文中指出工作流一个圈套:

许多工作流管理系统的开发商想使你相信,通过使用他们的图形化流程开发工具,只要业务分析师就可以生成流程定义。这种幻想源于“编程很难”这样的事实。开发商的销售人员喜欢说“看,你不用写一行代码”。不用写代码是好事,可大部分开发商在这点上走的太远,忽略了在某些场合提供一种将代码集成到流程定义中的机制是很适合的。

所以,osworkflow开源也认为通过图形化开发工具开发流程是不现实的,因此它的工作流比较有特点,从而也使得它的系统绝对的灵活。

浆糊
2004-09-14 09:18
这个主要是看产品针对的用户了 。

目前很多的产品都是从原先的oa发展和演变过来的,他针对的用户都是最终用户,那它当然是需要这样的易用性。但是扩展性会比较弱。

还有一些是专业的工作流提供商,他们的产品具有比较强的扩展性和通用性,那当然是需要非常灵活和方便的扩展方式。当然,对于用户(二次开发商或者最终用户)来说,尽量减少开发量,还是非常具有吸引力的,这个就是为什么很多工作流厂商都推这样的概念。

零开发的工作流产品应该来说是解决不了很多实际问题的,但是有的功能明显是工作流系统能够完成的,却偏要用户理解你一大堆的概念和接口才能使用的话,我认为也是不妥的。

主要是一个衡量的问题,哪个方面都不能太过于偏激。

猜你喜欢
3Go 1 2 3 下一页