要不要自建工作流引擎?

阅读数:3680 2009 年 7 月 17 日

话题:SOA架构

现在,越来越多的人意识到在解决方案中引入工作流的重要性。然而,在面临如何具体实现的时,自建亦或是使用(现有工作流)?争论仍在继续。在 Bernd Rücker 的新博文“工作流引擎?动手整一个……”中,他重拳出击,讨论了围绕在这个问题周围的一些常见误解。

在 Bernd 看来,支持开发“自产的”工作流引擎的典型论点包括以下几个方面:

  • 我们仅有非常基本的需求,简单的状态机。用工作流引擎是用大炮打蚊子。
  • 引擎应该是应用的一部分,而不是独立的。
  • 我们已经对工作流产品 X 做了评估,它并不适合我们的需求。

尽管乍一看这些论点似乎有道理,但是这些论点很少能为开发“自产的”工作流引擎而付出的努力和开销提供充分理由。

我们仅有非常基本的需求,而且,为此而学习新技术或(工作流的)实现而花费时间和努力是不值得的。结果很多实现一开始是基于简单的数据库表,在其中维持每一个流程的实例及其状态。但是,如果现在还需要支持以下方面的需求呢?

  • 存储实例变量的等待状态?
  • 超时处理?
  • 事件上报?
  • 决策网关?

Bernd 指出,根据他的经验,尽管工作流引擎的实现的确始于简单的需求,但随着时间的推移需求一定会不断增长,而且,到最后公司往往“陷入”维护和支持这个日益丰满的工作流系统。

引擎应该是应用的的一部分,因此我们不希望招惹对增加的硬件、软件、集成以及安装过程等的依赖(而这些是很多商业引擎的典型需求)。

Bernd 对这种场景的建议是考虑使用轻量级的 Java 工作流引擎,它们很容易集成到用户的产品中去。这样的工作流有 JBoss jBPM,Nova Bonita,Enhydra Shark 等,这些工作流一般都包含很多配置选项,使得它们可以非常容易地适配具体的应用需求。

我们已经评估过工作流产品 X,它不适合,这是最难应付的理由。Bernd 认为,问题在于,即使是轻量级的开源工作流引擎,也需要时间和精力才能得出合理的评价。对于一个工作流,如果没有足够的时间去检验它,得到的结论往往不充分的;而如果能够花足够的时间去了解技术的话,几乎没有哪个工作流不能提供所需的功能。Bernd 举了个例子,他的客户们无不发现,使用 jBPM 可以很容易地实现他们所需要的任何功能。问题在于要花时间去了解技术。

Bernd 以这样的方式总结他的博文:

请不要再自己开发了![这是项很昂贵的工作]。[理解一个引擎的] 学习曲线往往磨刀不负砍柴工!……[一旦你知道如何使用] 使用引擎的优势就不辩自明了。

今天的人们已经很少自己实现他们的数据库,O/R 映射工具或应用服务器了。为什么人们总是要想着自行开发工作流引擎呢?工作流引擎已经成为商品,而且,使用现有的实现总是比自开发省钱的多。

查看英文原文:Workflow Engine – To Build or Not to Build One?