最初有SOA 已死的说法，而现在 Tom Baeyens，jBPM 的创始人又为目前的独立业务流程管理系统（BPMS）贴出了新的讣告，他称，独立的 BPMS 有两大问题：
- 构建成本高。这指得是购买软件并使之运行起来，以及让所有人员跟上技术的发展。
- BPM 系统与外界集成的成本高。Web 服务或者用于集成其他应用的具体适配器都会带来很高的门槛。
这表明，要想证明 BPM 的效用，就必须要实现需多复杂的业务流程，而这并非易事，原因之一是企业的 BPM 尚未成熟。所以，BPMS 的使用成为 BPM 集成的昂贵的切入点。
Baeyens 为该问题提出的解决方案是在其最常使用的场所提供一个业务流程平台。比如 jBPM：
自从 jBMP 诞生之日，我们就重点面向开发人员。我们向开发人员的双手送去了 BPM 和工作流的能力，我们是在开发者的世界里提供那些特性的。
jBPM 的框架即可用于构建嵌入在应用系统之中的业务流程或者将其扩展成全面的 BPMS。
它降低了使用 BPM 的门槛并且打开了 BPM 使用的新世界。由于使用简单，即便是很小的流程使用 BPM 系统也是值得的……通过开源发布与应用系统的可植入性，jBPM 显示出 BPM 可以扩展成为比任何其他独立的 BPM 产品在过去获得的更广泛的使用。
Baeyens 所提到的将 BPMS 作为应用实现之基础的另一个例子是企业内容管理（ECM）系统：
ECM 系统是一个很好的环境，在这里嵌入的 BPM 可以更少的投资收获果实。拿每月一开的例会来说，会议记录要供人参阅，而且只有在关键参会人批准之后才能被发送到更广泛的读者。你会为此建立 BPM 系统吗？我不认为你会这么做。但如果此项能力在 ECM 系统中提供了，那么就能立刻产生投资回报。此外，这也是我们的战略，即在通用的 BPM 职能之上不断进行扩展。
很难用“BPM 实现的切入点的成本已经降低了”反驳 Baeyens。jBPM 也的确是个很棒的框架。但真正的问题是 BPM 真的是开发者的工具吗？。诚然，将 BPM 用作高层开发语言的场景的确不少，然而 BPM 的真正力量，特别是当其与 SOA 联合使用时，是它打破应用系统边界并实现企业范围的业务流程的能力。而且，从这个角度看，真正的 BPMS 不仅仅是一个执行环境，而且还要有建模，仿真以及业务活动监控（BAM）的支持，这才是 BPM 的光彩之处。
注册/登录 InfoQ 发表评论