现在，越来越多的人意识到在解决方案中引入工作流的重要性。然而，在面临如何具体实现的时，自建亦或是使用（现有工作流）？争论仍在继续。在 Bernd Rücker 的新博文“工作流引擎？动手整一个……”中，他重拳出击，讨论了围绕在这个问题周围的一些常见误解。
在 Bernd 看来，支持开发“自产的”工作流引擎的典型论点包括以下几个方面：
- 我们仅有非常基本的需求，简单的状态机。用工作流引擎是用大炮打蚊子。
- 引擎应该是应用的一部分，而不是独立的。
- 我们已经对工作流产品 X 做了评估，它并不适合我们的需求。
尽管乍一看这些论点似乎有道理，但是这些论点很少能为开发“自产的”工作流引擎而付出的努力和开销提供充分理由。
我们仅有非常基本的需求，而且，为此而学习新技术或（工作流的）实现而花费时间和努力是不值得的。结果很多实现一开始是基于简单的数据库表，在其中维持每一个流程的实例及其状态。但是，如果现在还需要支持以下方面的需求呢？
- 存储实例变量的等待状态？
- 超时处理？
- 事件上报？
- 决策网关？
Bernd 指出，根据他的经验，尽管工作流引擎的实现的确始于简单的需求，但随着时间的推移需求一定会不断增长，而且，到最后公司往往“陷入”维护和支持这个日益丰满的工作流系统。
引擎应该是应用的的一部分，因此我们不希望招惹对增加的硬件、软件、集成以及安装过程等的依赖（而这些是很多商业引擎的典型需求）。
Bernd 对这种场景的建议是考虑使用轻量级的 Java 工作流引擎，它们很容易集成到用户的产品中去。这样的工作流有 JBoss jBPM，Nova Bonita，Enhydra Shark 等，这些工作流一般都包含很多配置选项，使得它们可以非常容易地适配具体的应用需求。
我们已经评估过工作流产品 X，它不适合，这是最难应付的理由。Bernd 认为，问题在于，即使是轻量级的开源工作流引擎，也需要时间和精力才能得出合理的评价。对于一个工作流，如果没有足够的时间去检验它，得到的结论往往不充分的；而如果能够花足够的时间去了解技术的话，几乎没有哪个工作流不能提供所需的功能。Bernd 举了个例子，他的客户们无不发现，使用 jBPM 可以很容易地实现他们所需要的任何功能。问题在于要花时间去了解技术。
Bernd 以这样的方式总结他的博文：
请不要再自己开发了！[这是项很昂贵的工作]。[理解一个引擎的] 学习曲线往往磨刀不负砍柴工！……[一旦你知道如何使用] 使用引擎的优势就不辩自明了。
今天的人们已经很少自己实现他们的数据库，O/R 映射工具或应用服务器了。为什么人们总是要想着自行开发工作流引擎呢？工作流引擎已经成为商品，而且，使用现有的实现总是比自开发省钱的多。
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论