ZapThink的分析师Jason Bloomberg声称基于云的业务流程管理（BPM）软件将会给那些传统的、不能很方便地迁移到云交付模式的BPM引擎带来颠覆性影响。Bloomberg这篇文章并没有描述基于云的BPM所呈现的价值，而是着眼于他的一个断言——任何云BPM引擎想要正常工作，基于REST的服务都是必不可少的。但是，来自ebizQ的Michael Poulin对此有不同看法，他质疑这种无状态的RESTful服务是否真的必不可少。

　　BPM被认为是一种准则，以改进企业业绩为目标，对业务流程进行构建、管理并优化。商用BPM软件解决方案通常会提供一个平台对基于流程的应用和业务规则进行建模，还会包含一个运行时引擎执行这些应用。虽然目前有些人质疑是否BPM本身就是一个失败，但Bloomberg还是看到了BPM的价值，只是惋惜其发展空间被那些中间件厂商们所干扰。

　　厂商都喜欢BPM，这是因为流程引擎对其中间件堆栈而言，是一个自然的附加软件。协调多个应用也就意味着产生多种集成，那么为此就需要中间件。诸如此类种种吧。不管我们喊多少口号说跨平台的服务组装可以实现厂商独立的流程，但大部分厂商还是都推出了各自专有的一套工具包。

　　Bloomberg认为，如果这些厂商觉得他们可以方便地将其产品转换到云上，那么由于其带状态的架构设计，他们将会事与愿违。

　　这里讲的东西会比较有意思。为了达到云为分布式应用带来的可伸缩性优势，应用层必须是无状态的。云可能需要产生额外的实例来处理加载，并且任何特殊实例都可能崩溃。但由于云是高度可用且分区容忍的，这样的崩溃一定不能影响运行由云实例支持的流程。

　　这样一来，就没有办法让传统的BPM引擎在云上正常运行。毕竟，BPM引擎存在的价值在于维护流程状态，但你不牺牲伸缩性在云实例上就做不到！换句话说，大厂商们所投入的用以构建以SOA平台为中心的BPM引擎上的全部人力物力现在都白费了。云已经改变了BPM的规则。

　　Bloomberg认为，基于云的BPM解决方案必须用（在客户端和服务器端传递的）消息来维护流程状态。这可以通过使用REST超媒体方面的特点并删除客户端与运行BPM引擎服务端之间的所有耦合做到。

　　一旦你仔细想想会发现这个观点的强大是显而易见的，因为W3本身就是这样一种运行时工作流的原型样例。你可以想象这样一种工作流：任意一系列的点击链接，然后加载Web页面，最终——你所见到的那些页面往往是不同服务器上所提供的各种不同的资源。你看不到一个重量级的、统一的流程引擎。

　　以【面向超媒体的架构】为基础的BPM是一种潜在的颠覆性技术，而它也正面临技术革新的窘境。

　　虽然对Bloomberg上述观点表示赞赏，但Poulin提出了他的四段论，对无状态性是基于云的BPM解决方案的关键这一断言提出了异议。Poulin对消息中过度的状态传输持保留态度。

　　由此可见，如果一个服务以流程的方式实现，那么它可以自由管理其自身状态，可以是有状态的或是无状态的（如果你把服务看成是一个服务工厂，并且你可以按需要来初始化服务，那么你的限制就只会在硬件资源上，而不是服务状态）。在2008年就有关于在消息交互中携带流程状态信息的想法，但仍然保持服务的无状态性给很多那些通过服务接口来发送以兆计算消息字节的人很痛苦的失败教训。

　　我没有看到云伸缩性和运行在云中应用的无状态性之间有任何关联。

　　一个基于云的BPM解决方案能否在没有统一引擎支持、仅仅依赖超链接以及客户端管理状态下成功？Poulin通过一个理论认证表达了他的顾虑。

　　好吧，假设我们不做流程处理，而只用链接。比如，我们使用HTTP的GET和PUT方法启动一个流程，这符合“无需流程引擎！”的说法：当流程被触发，一个链接指向规则引擎，并期望返回一个下一步该做什么的说明。那这个说明返回何处呢？规则的请求者是“无状态的”流程，执行响应客户端请求；那么，该说明可能只会返回客户端（记住，流程可能并不维护其状态），并且在这种情况下，返回的说明字节数要足够短，以满足GET/PUT方法的要求。接下来，客户端再调用同一个流程（可能不同实例），并把说明传递回（到云中？）“流程”继续执行，以此类推。如果你能够这样就把它推销出去并做成生意，拜托，告诉我一下，让我们来庆祝这桩生意是多么的愚蠢。

　　Bloomberg说他的方法对某些人来讲可能有点激进，他反驳说许多基于云的公司都已经在按这种新模式运行。尽管如此，Poulin建议在把BPM这样的东西转移到云之前，业务执行者应该谨慎，并且遵循Peter Drucker的建议：

　　“没有什么比有效地做那些根本不需要做的事更无用的了。”