JBpm的Tom Baeyens写的《工作流的现状》（中文）

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

the state of workflow

喜欢的话，顶一下。可化了我不少时间，：-）。。。。

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

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

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

TSS相关连接和讨论：
http://www.theserverside.com/news/thread.tss?thread_id=26073

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

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

这个主要是看产品针对的用户了 。
目前很多的产品都是从原先的oa发展和演变过来的，他针对的用户都是最终用户，那它当然是需要这样的易用性。但是扩展性会比较弱。
还有一些是专业的工作流提供商，他们的产品具有比较强的扩展性和通用性，那当然是需要非常灵活和方便的扩展方式。当然，对于用户（二次开发商或者最终用户）来说，尽量减少开发量，还是非常具有吸引力的，这个就是为什么很多工作流厂商都推这样的概念。
零开发的工作流产品应该来说是解决不了很多实际问题的，但是有的功能明显是工作流系统能够完成的，却偏要用户理解你一大堆的概念和接口才能使用的话，我认为也是不妥的。
主要是一个衡量的问题，哪个方面都不能太过于偏激。


使用图形界面类似Eclipse　插件等开发工具，可以提高简单的开发进程，但是想靠它解决所有问题是不可能的，图形界面只是纳入成熟有规律的部分。

我同意浆糊观点，看来手工配置和图形界面需要结合，但这样担心是否会对流程管理人员要求比较高？

JoinWorkflow是公司作的，还是开发团队做的呢？

Joinwork是开发团队建立的公司作的。 ：-）

呵呵，banq大哥说

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

如果数据库里面数据量比较大，使用EJB怎么办呢？象移动那种数据库，1个表就1KK条记录的，连hibernate都不建议使用在大数据量的数据库上面。

to cxj_2000
只是个人观点，这个结论是跳跃式，也是经验式，不同意者权当一家之言。

>数据库里面数据量比较大，使用EJB怎么办呢？
使用缓存，这是我一直强调的地方，这个帖子不适合讨论这个问题，留在其他地方再讨论，谢谢。

大量的数据放到缓存里也是个挑战，何况缓存的同步也是个棘手的问题。