要不要自建工作流引擎？

现在，越来越多的人意识到在解决方案中引入工作流的重要性。然而，在面临如何具体实现的时，自建亦或是使用（现有工作流）？争论仍在继续。在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?